Re: [Xen-devel] libxl: problem with devices in PV

[Roger Pau Monnà <roger.pau@xxxxxxxxxxxxx>]

BTW, would it be ok to create a new disk backend, like LOOP or VND
(LIBXL_DISK_BACKEND_VND)?

Now it's a bit hackish, since type is always set to phy, I have to
guess the real type by checking if  'params' starts with '/dev' on
xenbackend. I think it would be clearer to set the type to
LIBXL_DISK_BACKEND_VND if passed file is not a block device and OS is
NetBSD in disk_try_backend.

Regards, Roger.

2011/7/21 Roger Pau Monnà <roger.pau@xxxxxxxxxxxxx>:
> 2011/7/21 Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>:
>> On Thu, 2011-07-21 at 09:39 +0100, Roger Pau Monnà wrote:
>>> Hello,
>>>
>>> Thanks for the help, I have a preliminary patch that allows booting PV
>>> machines with xl on NetBSD, but there seems to be some issues with PCI
>>> devices, the guest takes a very long time to start, and I think it's
>>> because it's waiting for PCI devices to initialize.
>>>
>>> [ Â Â5.280068] XENBUS: Waiting for devices to initialise:
>>> 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...245s...240s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s...
>>> [ Â300.280078] XENBUS: Device with no driver: device/vbd/51714
>>> [ Â300.280086] XENBUS: Device with no driver: device/vbd/51713
>>> [ Â300.280495] XENBUS: Timeout connecting to device: device/pci/0
>>> (local state 3, remote state 1)
>>>
>>> xm didn't add pci entries to xenstore, and I don't know what should be
>>> the status of those entries, or if it's best to disable the adding of
>>> pci entries to xenstore in libxl if no devices are configured?
>>>
>>> I've looked at http://wiki.xensource.com/xenwiki/XenStoreReference,
>>> but the wiki doesn't have any information regarding PCI xenstore
>>> entries.
>>>
>>> The status of those entries in xenstore is the following:
>>>
>>> /local/domain/0/backend/pci = "" Â (n0)
>>> /local/domain/0/backend/pci/1 = "" Â (n0)
>>> /local/domain/0/backend/pci/1/0 = "" Â (n0,r1)
>>> /local/domain/0/backend/pci/1/0/frontend =
>>> "/local/domain/1/device/pci/0" Â (n0,r1)
>>> /local/domain/0/backend/pci/1/0/frontend-id = "1" Â (n0,r1)
>>> /local/domain/0/backend/pci/1/0/online = "1" Â (n0,r1)
>>> /local/domain/0/backend/pci/1/0/state = "1" Â (n0,r1)
>>> /local/domain/0/backend/pci/1/0/domain = "debian" Â (n0,r1)
>>> /local/domain/0/backend/pci/1/0/num_devs = "0" Â (n0,r1)
>>
>> num_devs = 0, is it the case that you don't actually have any pci
>> devices in your configuration?
>
> No, I didn't have any PCI devices set.
>
>>
>> I wonder if perhaps the netbsd pciback doesn't like seeing a backend
>> directory with no actual devices in it.
>>
>> Could you try experimentally commenting out the call to
>> libxl__create_pci_backend in do_domain_create, or gating it on "if
>> (d_config->num_pcidevs)".
>
> Disabling or setting it with a if condition makes the guest boot, I
> through that setting the appropriate values in the status of xenstore
> should also work, but it's useless to have references to PCI devices
> in xenstore if no devices are actually configured.
>
>>
>> That call was added in 23565:72eafe80ebc1 but I don't think adding the
>> if would invalidate it.
>>
>>> /local/domain/1/device/pci = "" Â (n0,r1)
>>> /local/domain/1/device/pci/0 = "" Â (n1,r0)
>>> /local/domain/1/device/pci/0/backend =
>>> "/local/domain/0/backend/pci/1/0" Â (n1,r0)
>>> /local/domain/1/device/pci/0/backend-id = "0" Â (n1,r0)
>>> /local/domain/1/device/pci/0/state = "3" Â (n1,r0)
>>> /local/domain/1/device/pci/0/pci-op-ref = "8" Â (n1,r0)
>>> /local/domain/1/device/pci/0/event-channel = "8" Â (n1,r0)
>>> /local/domain/1/device/pci/0/magic = "7" Â (n1,r0)
>>>
>>> The patch attached breaks linux support, it is only attached for
>>> informative purposes.
>>>
>>> Regards, Roger.
>
> Thanks again for all the help, I would prepare a new proper patch to
> be added to mainline Xen.
>
> Regards, Roger.
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel