* [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu @ 2015-10-13 15:55 ` Fabio Fantoni 0 siblings, 0 replies; 95+ messages in thread From: Fabio Fantoni @ 2015-10-13 15:55 UTC (permalink / raw) To: xen-devel, qemu-devel; +Cc: Anthony.Perard, Stefano Stabellini I added ahci disk support in libxl and using it for week seems that was ok, after a reply of Stefano Stabellini seems that xen disk unplug support only ide disks: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 Today Paul Durrant told me that even if pv disk is ok also with ahci and the emulated one is offline can be a risk: http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html I tried to take a fast look in qemu code but I not understand the needed thing for add the xen disk unplug support also for ahci, can someone do it or tell me useful information for do it please? Thanks for any reply and sorry for my bad english. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Question about xen disk unplug support for ahci missed in qemu @ 2015-10-13 15:55 ` Fabio Fantoni 0 siblings, 0 replies; 95+ messages in thread From: Fabio Fantoni @ 2015-10-13 15:55 UTC (permalink / raw) To: xen-devel, qemu-devel; +Cc: Anthony.Perard, Stefano Stabellini I added ahci disk support in libxl and using it for week seems that was ok, after a reply of Stefano Stabellini seems that xen disk unplug support only ide disks: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 Today Paul Durrant told me that even if pv disk is ok also with ahci and the emulated one is offline can be a risk: http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html I tried to take a fast look in qemu code but I not understand the needed thing for add the xen disk unplug support also for ahci, can someone do it or tell me useful information for do it please? Thanks for any reply and sorry for my bad english. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-13 15:55 ` Fabio Fantoni (?) @ 2015-10-13 16:45 ` John Snow -1 siblings, 0 replies; 95+ messages in thread From: John Snow @ 2015-10-13 16:45 UTC (permalink / raw) To: Fabio Fantoni, xen-devel, qemu-devel; +Cc: Anthony.Perard, Stefano Stabellini On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > I added ahci disk support in libxl and using it for week seems that was > ok, after a reply of Stefano Stabellini seems that xen disk unplug > support only ide disks: > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 > > Today Paul Durrant told me that even if pv disk is ok also with ahci and > the emulated one is offline can be a risk: > http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html > > > I tried to take a fast look in qemu code but I not understand the needed > thing for add the xen disk unplug support also for ahci, can someone do > it or tell me useful information for do it please? > > Thanks for any reply and sorry for my bad english. > I'm not entirely sure what features you need AHCI to support in order for Xen to be happy. I'd guess hotplugging, but where I get confused is that IDE disks don't support hotplugging either, so I guess I'm not sure sure what you need. Stefano, can you help bridge my Xen knowledge gap? --js ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-13 15:55 ` Fabio Fantoni (?) (?) @ 2015-10-13 16:45 ` John Snow 2015-10-13 17:10 ` Stefano Stabellini -1 siblings, 1 reply; 95+ messages in thread From: John Snow @ 2015-10-13 16:45 UTC (permalink / raw) To: Fabio Fantoni, xen-devel, qemu-devel; +Cc: Anthony.Perard, Stefano Stabellini On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > I added ahci disk support in libxl and using it for week seems that was > ok, after a reply of Stefano Stabellini seems that xen disk unplug > support only ide disks: > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 > > Today Paul Durrant told me that even if pv disk is ok also with ahci and > the emulated one is offline can be a risk: > http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html > > > I tried to take a fast look in qemu code but I not understand the needed > thing for add the xen disk unplug support also for ahci, can someone do > it or tell me useful information for do it please? > > Thanks for any reply and sorry for my bad english. > I'm not entirely sure what features you need AHCI to support in order for Xen to be happy. I'd guess hotplugging, but where I get confused is that IDE disks don't support hotplugging either, so I guess I'm not sure sure what you need. Stefano, can you help bridge my Xen knowledge gap? --js ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-13 16:45 ` John Snow @ 2015-10-13 17:10 ` Stefano Stabellini 2015-10-14 9:47 ` Kevin Wolf ` (2 more replies) 0 siblings, 3 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-13 17:10 UTC (permalink / raw) To: John Snow Cc: Anthony.Perard, Fabio Fantoni, qemu-devel, Stefano Stabellini, xen-devel On Tue, 13 Oct 2015, John Snow wrote: > On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > I added ahci disk support in libxl and using it for week seems that was > > ok, after a reply of Stefano Stabellini seems that xen disk unplug > > support only ide disks: > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 > > > > Today Paul Durrant told me that even if pv disk is ok also with ahci and > > the emulated one is offline can be a risk: > > http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html > > > > > > I tried to take a fast look in qemu code but I not understand the needed > > thing for add the xen disk unplug support also for ahci, can someone do > > it or tell me useful information for do it please? > > > > Thanks for any reply and sorry for my bad english. > > > > I'm not entirely sure what features you need AHCI to support in order > for Xen to be happy. > > I'd guess hotplugging, but where I get confused is that IDE disks don't > support hotplugging either, so I guess I'm not sure sure what you need. > > Stefano, can you help bridge my Xen knowledge gap? Hi John, we need something like hw/i386/xen/xen_platform.c:unplug_disks but that can unplug AHCI disk. And by unplug, I mean "make disappear" like pci_piix3_xen_ide_unplug does for ide. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-13 17:10 ` Stefano Stabellini @ 2015-10-14 9:47 ` Kevin Wolf 2015-10-14 11:06 ` Stefano Stabellini 2015-10-14 11:11 ` Fabio Fantoni 2015-10-16 20:40 ` John Snow 2015-10-16 20:40 ` John Snow 2 siblings, 2 replies; 95+ messages in thread From: Kevin Wolf @ 2015-10-14 9:47 UTC (permalink / raw) To: Stefano Stabellini Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, John Snow [ CC qemu-block ] Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > On Tue, 13 Oct 2015, John Snow wrote: > > On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > > I added ahci disk support in libxl and using it for week seems that was > > > ok, after a reply of Stefano Stabellini seems that xen disk unplug > > > support only ide disks: > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 > > > > > > Today Paul Durrant told me that even if pv disk is ok also with ahci and > > > the emulated one is offline can be a risk: > > > http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html > > > > > > > > > I tried to take a fast look in qemu code but I not understand the needed > > > thing for add the xen disk unplug support also for ahci, can someone do > > > it or tell me useful information for do it please? > > > > > > Thanks for any reply and sorry for my bad english. > > > > > > > I'm not entirely sure what features you need AHCI to support in order > > for Xen to be happy. > > > > I'd guess hotplugging, but where I get confused is that IDE disks don't > > support hotplugging either, so I guess I'm not sure sure what you need. > > > > Stefano, can you help bridge my Xen knowledge gap? > > Hi John, > > we need something like hw/i386/xen/xen_platform.c:unplug_disks but that > can unplug AHCI disk. And by unplug, I mean "make disappear" like > pci_piix3_xen_ide_unplug does for ide. Maybe this would be the right time to stop the craziness with your hybrid IDE/xendisk setup. It's a horrible thing that would never happen on real hardware. Can't you just teach SeaBIOS how to deal with your PV disks and then only add that to your VM and forget about IDE/AHCI? I mean, that's how it's done for virtio-blk, and it doesn't involve any insanities like ripping out non-hotpluggable devices. Hm... How does a reboot of a machine that had its IDE already removed actually work? Do you restart the qemu process on reboot? Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-14 9:47 ` Kevin Wolf @ 2015-10-14 11:06 ` Stefano Stabellini 2015-10-14 11:27 ` [Qemu-devel] " Ian Campbell ` (2 more replies) 2015-10-14 11:11 ` Fabio Fantoni 1 sibling, 3 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-14 11:06 UTC (permalink / raw) To: Kevin Wolf Cc: qemu-block, Stefano Stabellini, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, John Snow On Wed, 14 Oct 2015, Kevin Wolf wrote: > [ CC qemu-block ] > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > > On Tue, 13 Oct 2015, John Snow wrote: > > > On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > > > I added ahci disk support in libxl and using it for week seems that was > > > > ok, after a reply of Stefano Stabellini seems that xen disk unplug > > > > support only ide disks: > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 > > > > > > > > Today Paul Durrant told me that even if pv disk is ok also with ahci and > > > > the emulated one is offline can be a risk: > > > > http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html > > > > > > > > > > > > I tried to take a fast look in qemu code but I not understand the needed > > > > thing for add the xen disk unplug support also for ahci, can someone do > > > > it or tell me useful information for do it please? > > > > > > > > Thanks for any reply and sorry for my bad english. > > > > > > > > > > I'm not entirely sure what features you need AHCI to support in order > > > for Xen to be happy. > > > > > > I'd guess hotplugging, but where I get confused is that IDE disks don't > > > support hotplugging either, so I guess I'm not sure sure what you need. > > > > > > Stefano, can you help bridge my Xen knowledge gap? > > > > Hi John, > > > > we need something like hw/i386/xen/xen_platform.c:unplug_disks but that > > can unplug AHCI disk. And by unplug, I mean "make disappear" like > > pci_piix3_xen_ide_unplug does for ide. > > Maybe this would be the right time to stop the craziness with your > hybrid IDE/xendisk setup. It's a horrible thing that would never happen > on real hardware. I would be quite happy to stop (or even get rid of) the craziness. > Can't you just teach SeaBIOS how to deal with your PV disks and then > only add that to your VM and forget about IDE/AHCI? I mean, that's how > it's done for virtio-blk, and it doesn't involve any insanities like > ripping out non-hotpluggable devices. Teaching SeaBIOS to deal with PV disks can be done, in fact we already support PV disks in OVMF. It is possible to boot Windows with OVMF without any IDE disks (patch pending for libxl to create a VM without emulated IDE disks). However we have to be honest that implementing PV disk support in SeaBIOS is a different magnitude of effort compared to implementing AHCI "unplug". I would suggest Fabio to avoid AHCI disks altogether and just use OVMF with PV disks only and Anthony's patch to libxl to avoid creating any IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. Would that work for you? > Hm... How does a reboot of a machine that had its IDE already removed > actually work? Do you restart the qemu process on reboot? Restart QEMU, yes. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-14 11:06 ` Stefano Stabellini @ 2015-10-14 11:27 ` Ian Campbell 2015-10-14 11:32 ` Kevin Wolf 2015-10-15 16:27 ` Fabio Fantoni 2 siblings, 0 replies; 95+ messages in thread From: Ian Campbell @ 2015-10-14 11:27 UTC (permalink / raw) To: Stefano Stabellini, Kevin Wolf Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, John Snow On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote: > > Can't you just teach SeaBIOS how to deal with your PV disks and then > > only add that to your VM and forget about IDE/AHCI? I mean, that's how > > it's done for virtio-blk, and it doesn't involve any insanities like > > ripping out non-hotpluggable devices. > > Teaching SeaBIOS to deal with PV disks can be done, in fact we already > support PV disks in OVMF. It is possible to boot Windows with OVMF > without any IDE disks (patch pending for libxl to create a VM without > emulated IDE disks). One stumbling block in the past has been how to know when the PV drivers in the BIOS are no longer required, such that the ring can be torn down and/or the connection etc handed over to the OS driver. I think we deal with this in OVMF using ExitBootServices? (TBH I'm not sure how). AFAIK the BIOS interfaces do not have anything as reliable as that. How does virtio deal with this in the BIOS case? Ian. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu @ 2015-10-14 11:27 ` Ian Campbell 0 siblings, 0 replies; 95+ messages in thread From: Ian Campbell @ 2015-10-14 11:27 UTC (permalink / raw) To: Stefano Stabellini, Kevin Wolf Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, John Snow On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote: > > Can't you just teach SeaBIOS how to deal with your PV disks and then > > only add that to your VM and forget about IDE/AHCI? I mean, that's how > > it's done for virtio-blk, and it doesn't involve any insanities like > > ripping out non-hotpluggable devices. > > Teaching SeaBIOS to deal with PV disks can be done, in fact we already > support PV disks in OVMF. It is possible to boot Windows with OVMF > without any IDE disks (patch pending for libxl to create a VM without > emulated IDE disks). One stumbling block in the past has been how to know when the PV drivers in the BIOS are no longer required, such that the ring can be torn down and/or the connection etc handed over to the OS driver. I think we deal with this in OVMF using ExitBootServices? (TBH I'm not sure how). AFAIK the BIOS interfaces do not have anything as reliable as that. How does virtio deal with this in the BIOS case? Ian. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-14 11:27 ` [Qemu-devel] " Ian Campbell (?) @ 2015-10-15 23:10 ` Laszlo Ersek -1 siblings, 0 replies; 95+ messages in thread From: Laszlo Ersek @ 2015-10-15 23:10 UTC (permalink / raw) To: Ian Campbell, Stefano Stabellini, Kevin Wolf Cc: Kevin O'Connor, Matt Fleming, qemu-block, Ard Biesheuvel, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, John Snow CC'ing Kevin O'Connor On 10/14/15 13:27, Ian Campbell wrote: > On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote: >>> Can't you just teach SeaBIOS how to deal with your PV disks and then >>> only add that to your VM and forget about IDE/AHCI? I mean, that's how >>> it's done for virtio-blk, and it doesn't involve any insanities like >>> ripping out non-hotpluggable devices. >> >> Teaching SeaBIOS to deal with PV disks can be done, in fact we already >> support PV disks in OVMF. It is possible to boot Windows with OVMF >> without any IDE disks (patch pending for libxl to create a VM without >> emulated IDE disks). > > One stumbling block in the past has been how to know when the PV drivers in > the BIOS are no longer required, such that the ring can be torn down and/or > the connection etc handed over to the OS driver. > > I think we deal with this in OVMF using ExitBootServices? (TBH I'm not sure how). Search "XenBusDxe/XenBusDxe.c" in edk2 for "EVT_SIGNAL_EXIT_BOOT_SERVICES". TBH, the code in NotifyExitBoot() doesn't seem valid. If you check the UEFI spec (for example, v2.5, but the requirement I'm about to quote is very old), in the specification of EFI_BOOT_SERVICES.CreateEvent() you find: EVT_SIGNAL_EXIT_BOOT_SERVICES This event is to be notified by the system when ExitBootServices() is invoked. This event is of type EVT_NOTIFY_SIGNAL and should not be combined with any other event types. The notification function for this event is not allowed to use the Memory Allocation Services, or call any functions that use the Memory Allocation Services and must only call functions that are known not to use Memory Allocation Services, because these services modify the current memory map.The notification function must not depend on timer events since timer services will be deactivated before any notification functions are called. NotifyExitBoot() in "XenBusDxe/XenBusDxe.c" calls the DisconnectController() boot service. That in turn leads to calls to EFI_DRIVER_BINDING_PROTOCOL.Stop() functions (speaking generally), which inevitably free memory as part of unbinding the device, thereby breaking the above requirement. The right solution is the following: - when a driver binds a device (a "handle"), a piece of the resources allocated for that binding should be a new event, to be signaled at ExitBootServices() time. The handler function can be shared by all such devices. The context passed to the handler should be the (driver- specific) structure that represents the binding and the state of the device in general. - When the driver unbinds the device, the event should be closed. This will automatically unregister the callback as well. - Now, when the callback is entered at all, you can be sure that the binding still exists. In this case, you should probe into the various fields of the context (the device state, practically), to figure out if this device "lives" or is dormant. For simpler devices, the answer is always "alive", but some devices could have configuration states where they are bound yet not configured (using no hw resources etc). - In case the device is alive, the action to take is to make it abort any in-flight transfers or other operations, and re-set / deconfigure it *without* touching any memory allocations. You can see this in the virtio-net driver in OVMF. In the "OvmfPkg/VirtioNetDxe" directory, see the "TechNotes.txt", "DriverBinding.c" and "Events.c" files. The callback function is VirtioNetExitBoot(), and the event registration / deregistration happens in: VirtioNetDriverBindingStart() VirtioNetSnpPopulate() gBS->CreateEvent(EVT_SIGNAL_EXIT_BOOT_SERVICES) vs. VirtioNetDriverBindingStop() VirtioNetSnpEvacuate() gBS->CloseEvent() What VirtioNetExitBoot() does is very simple: resetting the virtio device is a small action, and it covers the responsibilities. I'll admit that the virtio-scsi and virtio-block drivers play a bit dirty here. (I've known this for a long time, but been silent about it.) They should have similar callbacks, but don't (In theory, all devices that are bound & alive at ExitBootServices() should be re-set, without touching the memory services.) There are two mitigating factors here: - unlike with virtio-net, the scsi and block drivers in OVMF support only synchronous operations. When you are not calling their functions, there are no transfers in flight. And when something calls ExitBootServices(), that thing is not calling virtio-block / virtio-scsi functions. - The first thing the OS-level virtio drivers do (certainly in Linux, hopefully in Windows) is a virtio-reset on each virtio device found. (This is actually required by the virtio specification, both old and new.) Now, there's one small window for issues here. If something in the guest scribbled over the memory that, according to QEMU, still hosts a live virtio ring, between ExitBootServices() and said OS-level virtio-reset, QEMU *could* interpret that -- even without an explicit virtio kick -- as garbage virtio operations, and abort the guest (or the device would enter a failed state, not sure what happens in today's QEMU). This window is very very small in practice however. OVMF allocates the virtio rings in EfiBootServicesData type memory. The OS is allowed to reuse that kind of memory right after ExitBootServices(). However, Linux developers have found that many buggy UEFI drivers :) allow those areas to be used by hardware even after ExitBootServices(), at least for a while. So they have some reservation code in place to deal with that. (I'm fuzzy on the details, sorry. CC'ing Ard and Matt.) In any case, this decreases the chance that virtio ring corruption could occur between ExitBootServices() and the OS-level virtio-reset, for OVMF's virtio-block and virtio-scsi drivers. For purity, I should really write those few tens of lines of ExitBootServices() handler code for both drivers... but you know how it works; you make time for what really matters. I have never seen (occur, or be reported) such a problem with OVMF. However, what I *have* seen is a similar ring corruption in SeaBIOS. There was a quirky error path in the code that enabled SeaBIOS to internally release (and later, reuse) the memory that from QEMU's POV still hosted a live virtio ring. As you can imagine, the release and the "reuse" (-> abort by QEMU) were quite distanced from each other. Fixed it in SeaBIOS commit 5f2d17d35b23. See also later commit 5e03881f98b3. > AFAIK the BIOS interfaces do not have anything as reliable as that. > > How does virtio deal with this in the BIOS case? It doesn't, as far as I can tell. I don't think it has to, though! On a BIOS box, you can always boot DOS, or another operating system that continues to use the BIOS interfaces forever. (Same as if you never call ExitBootServices() in UEFI.) Given that no starter pistol gets fired between the firmware and the OS on such a platform, they must always respect each other. I guess this could occur through the E820 map, or some such. No clue in what kind of E820 memory SeaBIOS allocates the virtio rings, but I guess the Linux kernel stays away from those areas until it's past device probing and binding. In other words, I guess it is exactly the existence of ExitBootServices() that *gives rise* to this issue. Without ExitBootServices(), the BIOS can never know when its services are no longer needed, so it keeps them alive. For which reason, the OS -- without means to tell the BIOS to go away *now* -- must stay away for a reasonably long time too. (I'm speculating of course.) With ExitBootServices(), there's a clear separation, but when only one side adheres to it, things can break badly. Long story short, here's my unwashed recommendation for Xen PV: - In OVMF, fix the current ExitBootServices() handler. Only de-configure the device using the XenBus protocol, without allocating or freeing any dynamic memory, directly or indirectly. I'll also add writing ExitBootServices() handlers for virtio-block and virtio-scsi to my TODO list. (Now that you've forced me to own up to their lack.) Sigh. :) - In SeaBIOS, allocate the ring in normal memory, and trust that the kernel stays away until the Xen guest driver binds the device, and resets it (as the very first step) If you're worried (or else, if I'm simply wrong!), allocate the ring in reserved memory. A few lost pages are a small price to pay for XenPV in SeaBIOS! ;) ... It's 1AM again. Sigh. Someone steal my keyboard, please. (And hit me with it too if I wrote many incorrect statements above...) Cheers Laszlo ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-14 11:27 ` [Qemu-devel] " Ian Campbell (?) (?) @ 2015-10-15 23:10 ` Laszlo Ersek 2015-10-16 2:38 ` [Qemu-devel] " Kevin O'Connor 2015-10-16 2:38 ` [Qemu-devel] [Xen-devel] " Kevin O'Connor -1 siblings, 2 replies; 95+ messages in thread From: Laszlo Ersek @ 2015-10-15 23:10 UTC (permalink / raw) To: Ian Campbell, Stefano Stabellini, Kevin Wolf Cc: Kevin O'Connor, Matt Fleming, qemu-block, Ard Biesheuvel, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, John Snow CC'ing Kevin O'Connor On 10/14/15 13:27, Ian Campbell wrote: > On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote: >>> Can't you just teach SeaBIOS how to deal with your PV disks and then >>> only add that to your VM and forget about IDE/AHCI? I mean, that's how >>> it's done for virtio-blk, and it doesn't involve any insanities like >>> ripping out non-hotpluggable devices. >> >> Teaching SeaBIOS to deal with PV disks can be done, in fact we already >> support PV disks in OVMF. It is possible to boot Windows with OVMF >> without any IDE disks (patch pending for libxl to create a VM without >> emulated IDE disks). > > One stumbling block in the past has been how to know when the PV drivers in > the BIOS are no longer required, such that the ring can be torn down and/or > the connection etc handed over to the OS driver. > > I think we deal with this in OVMF using ExitBootServices? (TBH I'm not sure how). Search "XenBusDxe/XenBusDxe.c" in edk2 for "EVT_SIGNAL_EXIT_BOOT_SERVICES". TBH, the code in NotifyExitBoot() doesn't seem valid. If you check the UEFI spec (for example, v2.5, but the requirement I'm about to quote is very old), in the specification of EFI_BOOT_SERVICES.CreateEvent() you find: EVT_SIGNAL_EXIT_BOOT_SERVICES This event is to be notified by the system when ExitBootServices() is invoked. This event is of type EVT_NOTIFY_SIGNAL and should not be combined with any other event types. The notification function for this event is not allowed to use the Memory Allocation Services, or call any functions that use the Memory Allocation Services and must only call functions that are known not to use Memory Allocation Services, because these services modify the current memory map.The notification function must not depend on timer events since timer services will be deactivated before any notification functions are called. NotifyExitBoot() in "XenBusDxe/XenBusDxe.c" calls the DisconnectController() boot service. That in turn leads to calls to EFI_DRIVER_BINDING_PROTOCOL.Stop() functions (speaking generally), which inevitably free memory as part of unbinding the device, thereby breaking the above requirement. The right solution is the following: - when a driver binds a device (a "handle"), a piece of the resources allocated for that binding should be a new event, to be signaled at ExitBootServices() time. The handler function can be shared by all such devices. The context passed to the handler should be the (driver- specific) structure that represents the binding and the state of the device in general. - When the driver unbinds the device, the event should be closed. This will automatically unregister the callback as well. - Now, when the callback is entered at all, you can be sure that the binding still exists. In this case, you should probe into the various fields of the context (the device state, practically), to figure out if this device "lives" or is dormant. For simpler devices, the answer is always "alive", but some devices could have configuration states where they are bound yet not configured (using no hw resources etc). - In case the device is alive, the action to take is to make it abort any in-flight transfers or other operations, and re-set / deconfigure it *without* touching any memory allocations. You can see this in the virtio-net driver in OVMF. In the "OvmfPkg/VirtioNetDxe" directory, see the "TechNotes.txt", "DriverBinding.c" and "Events.c" files. The callback function is VirtioNetExitBoot(), and the event registration / deregistration happens in: VirtioNetDriverBindingStart() VirtioNetSnpPopulate() gBS->CreateEvent(EVT_SIGNAL_EXIT_BOOT_SERVICES) vs. VirtioNetDriverBindingStop() VirtioNetSnpEvacuate() gBS->CloseEvent() What VirtioNetExitBoot() does is very simple: resetting the virtio device is a small action, and it covers the responsibilities. I'll admit that the virtio-scsi and virtio-block drivers play a bit dirty here. (I've known this for a long time, but been silent about it.) They should have similar callbacks, but don't (In theory, all devices that are bound & alive at ExitBootServices() should be re-set, without touching the memory services.) There are two mitigating factors here: - unlike with virtio-net, the scsi and block drivers in OVMF support only synchronous operations. When you are not calling their functions, there are no transfers in flight. And when something calls ExitBootServices(), that thing is not calling virtio-block / virtio-scsi functions. - The first thing the OS-level virtio drivers do (certainly in Linux, hopefully in Windows) is a virtio-reset on each virtio device found. (This is actually required by the virtio specification, both old and new.) Now, there's one small window for issues here. If something in the guest scribbled over the memory that, according to QEMU, still hosts a live virtio ring, between ExitBootServices() and said OS-level virtio-reset, QEMU *could* interpret that -- even without an explicit virtio kick -- as garbage virtio operations, and abort the guest (or the device would enter a failed state, not sure what happens in today's QEMU). This window is very very small in practice however. OVMF allocates the virtio rings in EfiBootServicesData type memory. The OS is allowed to reuse that kind of memory right after ExitBootServices(). However, Linux developers have found that many buggy UEFI drivers :) allow those areas to be used by hardware even after ExitBootServices(), at least for a while. So they have some reservation code in place to deal with that. (I'm fuzzy on the details, sorry. CC'ing Ard and Matt.) In any case, this decreases the chance that virtio ring corruption could occur between ExitBootServices() and the OS-level virtio-reset, for OVMF's virtio-block and virtio-scsi drivers. For purity, I should really write those few tens of lines of ExitBootServices() handler code for both drivers... but you know how it works; you make time for what really matters. I have never seen (occur, or be reported) such a problem with OVMF. However, what I *have* seen is a similar ring corruption in SeaBIOS. There was a quirky error path in the code that enabled SeaBIOS to internally release (and later, reuse) the memory that from QEMU's POV still hosted a live virtio ring. As you can imagine, the release and the "reuse" (-> abort by QEMU) were quite distanced from each other. Fixed it in SeaBIOS commit 5f2d17d35b23. See also later commit 5e03881f98b3. > AFAIK the BIOS interfaces do not have anything as reliable as that. > > How does virtio deal with this in the BIOS case? It doesn't, as far as I can tell. I don't think it has to, though! On a BIOS box, you can always boot DOS, or another operating system that continues to use the BIOS interfaces forever. (Same as if you never call ExitBootServices() in UEFI.) Given that no starter pistol gets fired between the firmware and the OS on such a platform, they must always respect each other. I guess this could occur through the E820 map, or some such. No clue in what kind of E820 memory SeaBIOS allocates the virtio rings, but I guess the Linux kernel stays away from those areas until it's past device probing and binding. In other words, I guess it is exactly the existence of ExitBootServices() that *gives rise* to this issue. Without ExitBootServices(), the BIOS can never know when its services are no longer needed, so it keeps them alive. For which reason, the OS -- without means to tell the BIOS to go away *now* -- must stay away for a reasonably long time too. (I'm speculating of course.) With ExitBootServices(), there's a clear separation, but when only one side adheres to it, things can break badly. Long story short, here's my unwashed recommendation for Xen PV: - In OVMF, fix the current ExitBootServices() handler. Only de-configure the device using the XenBus protocol, without allocating or freeing any dynamic memory, directly or indirectly. I'll also add writing ExitBootServices() handlers for virtio-block and virtio-scsi to my TODO list. (Now that you've forced me to own up to their lack.) Sigh. :) - In SeaBIOS, allocate the ring in normal memory, and trust that the kernel stays away until the Xen guest driver binds the device, and resets it (as the very first step) If you're worried (or else, if I'm simply wrong!), allocate the ring in reserved memory. A few lost pages are a small price to pay for XenPV in SeaBIOS! ;) ... It's 1AM again. Sigh. Someone steal my keyboard, please. (And hit me with it too if I wrote many incorrect statements above...) Cheers Laszlo ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-15 23:10 ` [Qemu-devel] [Xen-devel] " Laszlo Ersek @ 2015-10-16 2:38 ` Kevin O'Connor 2015-10-16 2:38 ` [Qemu-devel] [Xen-devel] " Kevin O'Connor 1 sibling, 0 replies; 95+ messages in thread From: Kevin O'Connor @ 2015-10-16 2:38 UTC (permalink / raw) To: Laszlo Ersek Cc: Kevin Wolf, Matt Fleming, Ian Campbell, qemu-block, Stefano Stabellini, Ard Biesheuvel, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, John Snow On Fri, Oct 16, 2015 at 01:10:54AM +0200, Laszlo Ersek wrote: > On 10/14/15 13:27, Ian Campbell wrote: > > On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote: > >>> Can't you just teach SeaBIOS how to deal with your PV disks and then > >>> only add that to your VM and forget about IDE/AHCI? I mean, that's how > >>> it's done for virtio-blk, and it doesn't involve any insanities like > >>> ripping out non-hotpluggable devices. > >> > >> Teaching SeaBIOS to deal with PV disks can be done, in fact we already > >> support PV disks in OVMF. It is possible to boot Windows with OVMF > >> without any IDE disks (patch pending for libxl to create a VM without > >> emulated IDE disks). > > > > One stumbling block in the past has been how to know when the PV drivers in > > the BIOS are no longer required, such that the ring can be torn down and/or > > the connection etc handed over to the OS driver. [...] > > AFAIK the BIOS interfaces do not have anything as reliable as that. > > > > How does virtio deal with this in the BIOS case? > > It doesn't, as far as I can tell. > > I don't think it has to, though! On a BIOS box, you can always boot DOS, > or another operating system that continues to use the BIOS interfaces > forever. (Same as if you never call ExitBootServices() in UEFI.) > > Given that no starter pistol gets fired between the firmware and the OS > on such a platform, they must always respect each other. I guess this > could occur through the E820 map, or some such. One can use the "ACPI enable" SMI event to detect this if they really wanted to. In SeaBIOS one could do this from src/fw/smm.c:handle_smi() - however, no other drivers need this notification today and it would be a bit ugly to have to handle it from an SMI. (Assuming Xen were to support SMIs.) > No clue in what kind of E820 memory SeaBIOS allocates the virtio rings, > but I guess the Linux kernel stays away from those areas until it's past > device probing and binding. In SeaBIOS, the virtio memory is allocated from reserved memory. (See the memalign_high() call in src/hw/virtio-pci.c - the "high" memory zone is taken from reserved memory: http://seabios.org/Memory_Model#Memory_available_during_initialization ) What's the reason for the "stumbling block" that requires the BIOS to tear down the Xen ring prior to the OS being able to replace it? The BIOS disk calls are all synchronous, so the ring wont be active when the OS brings up its own ring. Is there some low-level interaction that prevents the OS from just resetting the ring prior to enabling it? -Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-15 23:10 ` [Qemu-devel] [Xen-devel] " Laszlo Ersek 2015-10-16 2:38 ` [Qemu-devel] " Kevin O'Connor @ 2015-10-16 2:38 ` Kevin O'Connor 2015-10-16 9:06 ` [Qemu-devel] " Stefano Stabellini 2015-10-16 9:13 ` [Qemu-devel] " Laszlo Ersek 1 sibling, 2 replies; 95+ messages in thread From: Kevin O'Connor @ 2015-10-16 2:38 UTC (permalink / raw) To: Laszlo Ersek Cc: Kevin Wolf, Matt Fleming, Ian Campbell, qemu-block, Stefano Stabellini, Ard Biesheuvel, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, John Snow On Fri, Oct 16, 2015 at 01:10:54AM +0200, Laszlo Ersek wrote: > On 10/14/15 13:27, Ian Campbell wrote: > > On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote: > >>> Can't you just teach SeaBIOS how to deal with your PV disks and then > >>> only add that to your VM and forget about IDE/AHCI? I mean, that's how > >>> it's done for virtio-blk, and it doesn't involve any insanities like > >>> ripping out non-hotpluggable devices. > >> > >> Teaching SeaBIOS to deal with PV disks can be done, in fact we already > >> support PV disks in OVMF. It is possible to boot Windows with OVMF > >> without any IDE disks (patch pending for libxl to create a VM without > >> emulated IDE disks). > > > > One stumbling block in the past has been how to know when the PV drivers in > > the BIOS are no longer required, such that the ring can be torn down and/or > > the connection etc handed over to the OS driver. [...] > > AFAIK the BIOS interfaces do not have anything as reliable as that. > > > > How does virtio deal with this in the BIOS case? > > It doesn't, as far as I can tell. > > I don't think it has to, though! On a BIOS box, you can always boot DOS, > or another operating system that continues to use the BIOS interfaces > forever. (Same as if you never call ExitBootServices() in UEFI.) > > Given that no starter pistol gets fired between the firmware and the OS > on such a platform, they must always respect each other. I guess this > could occur through the E820 map, or some such. One can use the "ACPI enable" SMI event to detect this if they really wanted to. In SeaBIOS one could do this from src/fw/smm.c:handle_smi() - however, no other drivers need this notification today and it would be a bit ugly to have to handle it from an SMI. (Assuming Xen were to support SMIs.) > No clue in what kind of E820 memory SeaBIOS allocates the virtio rings, > but I guess the Linux kernel stays away from those areas until it's past > device probing and binding. In SeaBIOS, the virtio memory is allocated from reserved memory. (See the memalign_high() call in src/hw/virtio-pci.c - the "high" memory zone is taken from reserved memory: http://seabios.org/Memory_Model#Memory_available_during_initialization ) What's the reason for the "stumbling block" that requires the BIOS to tear down the Xen ring prior to the OS being able to replace it? The BIOS disk calls are all synchronous, so the ring wont be active when the OS brings up its own ring. Is there some low-level interaction that prevents the OS from just resetting the ring prior to enabling it? -Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 2:38 ` [Qemu-devel] [Xen-devel] " Kevin O'Connor @ 2015-10-16 9:06 ` Stefano Stabellini 2015-10-16 9:13 ` [Qemu-devel] " Laszlo Ersek 1 sibling, 0 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-16 9:06 UTC (permalink / raw) To: Kevin O'Connor Cc: Kevin Wolf, Matt Fleming, Ian Campbell, qemu-block, Stefano Stabellini, John Snow, Ard Biesheuvel, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, Laszlo Ersek On Thu, 15 Oct 2015, Kevin O'Connor wrote: > On Fri, Oct 16, 2015 at 01:10:54AM +0200, Laszlo Ersek wrote: > > On 10/14/15 13:27, Ian Campbell wrote: > > > On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote: > > >>> Can't you just teach SeaBIOS how to deal with your PV disks and then > > >>> only add that to your VM and forget about IDE/AHCI? I mean, that's how > > >>> it's done for virtio-blk, and it doesn't involve any insanities like > > >>> ripping out non-hotpluggable devices. > > >> > > >> Teaching SeaBIOS to deal with PV disks can be done, in fact we already > > >> support PV disks in OVMF. It is possible to boot Windows with OVMF > > >> without any IDE disks (patch pending for libxl to create a VM without > > >> emulated IDE disks). > > > > > > One stumbling block in the past has been how to know when the PV drivers in > > > the BIOS are no longer required, such that the ring can be torn down and/or > > > the connection etc handed over to the OS driver. > [...] > > > AFAIK the BIOS interfaces do not have anything as reliable as that. > > > > > > How does virtio deal with this in the BIOS case? > > > > It doesn't, as far as I can tell. > > > > I don't think it has to, though! On a BIOS box, you can always boot DOS, > > or another operating system that continues to use the BIOS interfaces > > forever. (Same as if you never call ExitBootServices() in UEFI.) > > > > Given that no starter pistol gets fired between the firmware and the OS > > on such a platform, they must always respect each other. I guess this > > could occur through the E820 map, or some such. > > One can use the "ACPI enable" SMI event to detect this if they really > wanted to. In SeaBIOS one could do this from > src/fw/smm.c:handle_smi() - however, no other drivers need this > notification today and it would be a bit ugly to have to handle it > from an SMI. (Assuming Xen were to support SMIs.) > > > No clue in what kind of E820 memory SeaBIOS allocates the virtio rings, > > but I guess the Linux kernel stays away from those areas until it's past > > device probing and binding. > > In SeaBIOS, the virtio memory is allocated from reserved memory. (See > the memalign_high() call in src/hw/virtio-pci.c - the "high" memory > zone is taken from reserved memory: > http://seabios.org/Memory_Model#Memory_available_during_initialization > ) > > What's the reason for the "stumbling block" that requires the BIOS to > tear down the Xen ring prior to the OS being able to replace it? The > BIOS disk calls are all synchronous, so the ring wont be active when > the OS brings up its own ring. Is there some low-level interaction > that prevents the OS from just resetting the ring prior to enabling > it? Xen only exports one PV disk interface for each disk to the guest, and each PV interface only supports one frontend -- only SeaBIOS or the OS can be connected to one PV disk, not both. In the case of OVMF, we handle that by disconnecting the PV frontend in OVMF when ExitBootServices is called, so that the OS driver can reconnect later. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu @ 2015-10-16 9:06 ` Stefano Stabellini 0 siblings, 0 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-16 9:06 UTC (permalink / raw) To: Kevin O'Connor Cc: Kevin Wolf, Matt Fleming, Ian Campbell, qemu-block, Stefano Stabellini, John Snow, Ard Biesheuvel, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, Laszlo Ersek On Thu, 15 Oct 2015, Kevin O'Connor wrote: > On Fri, Oct 16, 2015 at 01:10:54AM +0200, Laszlo Ersek wrote: > > On 10/14/15 13:27, Ian Campbell wrote: > > > On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote: > > >>> Can't you just teach SeaBIOS how to deal with your PV disks and then > > >>> only add that to your VM and forget about IDE/AHCI? I mean, that's how > > >>> it's done for virtio-blk, and it doesn't involve any insanities like > > >>> ripping out non-hotpluggable devices. > > >> > > >> Teaching SeaBIOS to deal with PV disks can be done, in fact we already > > >> support PV disks in OVMF. It is possible to boot Windows with OVMF > > >> without any IDE disks (patch pending for libxl to create a VM without > > >> emulated IDE disks). > > > > > > One stumbling block in the past has been how to know when the PV drivers in > > > the BIOS are no longer required, such that the ring can be torn down and/or > > > the connection etc handed over to the OS driver. > [...] > > > AFAIK the BIOS interfaces do not have anything as reliable as that. > > > > > > How does virtio deal with this in the BIOS case? > > > > It doesn't, as far as I can tell. > > > > I don't think it has to, though! On a BIOS box, you can always boot DOS, > > or another operating system that continues to use the BIOS interfaces > > forever. (Same as if you never call ExitBootServices() in UEFI.) > > > > Given that no starter pistol gets fired between the firmware and the OS > > on such a platform, they must always respect each other. I guess this > > could occur through the E820 map, or some such. > > One can use the "ACPI enable" SMI event to detect this if they really > wanted to. In SeaBIOS one could do this from > src/fw/smm.c:handle_smi() - however, no other drivers need this > notification today and it would be a bit ugly to have to handle it > from an SMI. (Assuming Xen were to support SMIs.) > > > No clue in what kind of E820 memory SeaBIOS allocates the virtio rings, > > but I guess the Linux kernel stays away from those areas until it's past > > device probing and binding. > > In SeaBIOS, the virtio memory is allocated from reserved memory. (See > the memalign_high() call in src/hw/virtio-pci.c - the "high" memory > zone is taken from reserved memory: > http://seabios.org/Memory_Model#Memory_available_during_initialization > ) > > What's the reason for the "stumbling block" that requires the BIOS to > tear down the Xen ring prior to the OS being able to replace it? The > BIOS disk calls are all synchronous, so the ring wont be active when > the OS brings up its own ring. Is there some low-level interaction > that prevents the OS from just resetting the ring prior to enabling > it? Xen only exports one PV disk interface for each disk to the guest, and each PV interface only supports one frontend -- only SeaBIOS or the OS can be connected to one PV disk, not both. In the case of OVMF, we handle that by disconnecting the PV frontend in OVMF when ExitBootServices is called, so that the OS driver can reconnect later. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 9:06 ` [Qemu-devel] " Stefano Stabellini @ 2015-10-16 9:21 ` Laszlo Ersek -1 siblings, 0 replies; 95+ messages in thread From: Laszlo Ersek @ 2015-10-16 9:21 UTC (permalink / raw) To: Stefano Stabellini, Kevin O'Connor Cc: Kevin Wolf, Matt Fleming, Ian Campbell, qemu-block, Ard Biesheuvel, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, John Snow On 10/16/15 11:06, Stefano Stabellini wrote: > On Thu, 15 Oct 2015, Kevin O'Connor wrote: >> On Fri, Oct 16, 2015 at 01:10:54AM +0200, Laszlo Ersek wrote: >>> On 10/14/15 13:27, Ian Campbell wrote: >>>> On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote: >>>>>> Can't you just teach SeaBIOS how to deal with your PV disks and then >>>>>> only add that to your VM and forget about IDE/AHCI? I mean, that's how >>>>>> it's done for virtio-blk, and it doesn't involve any insanities like >>>>>> ripping out non-hotpluggable devices. >>>>> >>>>> Teaching SeaBIOS to deal with PV disks can be done, in fact we already >>>>> support PV disks in OVMF. It is possible to boot Windows with OVMF >>>>> without any IDE disks (patch pending for libxl to create a VM without >>>>> emulated IDE disks). >>>> >>>> One stumbling block in the past has been how to know when the PV drivers in >>>> the BIOS are no longer required, such that the ring can be torn down and/or >>>> the connection etc handed over to the OS driver. >> [...] >>>> AFAIK the BIOS interfaces do not have anything as reliable as that. >>>> >>>> How does virtio deal with this in the BIOS case? >>> >>> It doesn't, as far as I can tell. >>> >>> I don't think it has to, though! On a BIOS box, you can always boot DOS, >>> or another operating system that continues to use the BIOS interfaces >>> forever. (Same as if you never call ExitBootServices() in UEFI.) >>> >>> Given that no starter pistol gets fired between the firmware and the OS >>> on such a platform, they must always respect each other. I guess this >>> could occur through the E820 map, or some such. >> >> One can use the "ACPI enable" SMI event to detect this if they really >> wanted to. In SeaBIOS one could do this from >> src/fw/smm.c:handle_smi() - however, no other drivers need this >> notification today and it would be a bit ugly to have to handle it >> from an SMI. (Assuming Xen were to support SMIs.) >> >>> No clue in what kind of E820 memory SeaBIOS allocates the virtio rings, >>> but I guess the Linux kernel stays away from those areas until it's past >>> device probing and binding. >> >> In SeaBIOS, the virtio memory is allocated from reserved memory. (See >> the memalign_high() call in src/hw/virtio-pci.c - the "high" memory >> zone is taken from reserved memory: >> http://seabios.org/Memory_Model#Memory_available_during_initialization >> ) >> >> What's the reason for the "stumbling block" that requires the BIOS to >> tear down the Xen ring prior to the OS being able to replace it? The >> BIOS disk calls are all synchronous, so the ring wont be active when >> the OS brings up its own ring. Is there some low-level interaction >> that prevents the OS from just resetting the ring prior to enabling >> it? > > Xen only exports one PV disk interface for each disk to the guest, and > each PV interface only supports one frontend -- only SeaBIOS or the OS > can be connected to one PV disk, not both. In the case of OVMF, we > handle that by disconnecting the PV frontend in OVMF when > ExitBootServices is called, so that the OS driver can reconnect later. Does the XenBus protocol support a device reset operation, regardless of what state the device is currently in? (I don't remember all the state transitions any longer, sorry.) Thanks Laszlo ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu @ 2015-10-16 9:21 ` Laszlo Ersek 0 siblings, 0 replies; 95+ messages in thread From: Laszlo Ersek @ 2015-10-16 9:21 UTC (permalink / raw) To: Stefano Stabellini, Kevin O'Connor Cc: Kevin Wolf, Matt Fleming, Ian Campbell, qemu-block, Ard Biesheuvel, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, John Snow On 10/16/15 11:06, Stefano Stabellini wrote: > On Thu, 15 Oct 2015, Kevin O'Connor wrote: >> On Fri, Oct 16, 2015 at 01:10:54AM +0200, Laszlo Ersek wrote: >>> On 10/14/15 13:27, Ian Campbell wrote: >>>> On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote: >>>>>> Can't you just teach SeaBIOS how to deal with your PV disks and then >>>>>> only add that to your VM and forget about IDE/AHCI? I mean, that's how >>>>>> it's done for virtio-blk, and it doesn't involve any insanities like >>>>>> ripping out non-hotpluggable devices. >>>>> >>>>> Teaching SeaBIOS to deal with PV disks can be done, in fact we already >>>>> support PV disks in OVMF. It is possible to boot Windows with OVMF >>>>> without any IDE disks (patch pending for libxl to create a VM without >>>>> emulated IDE disks). >>>> >>>> One stumbling block in the past has been how to know when the PV drivers in >>>> the BIOS are no longer required, such that the ring can be torn down and/or >>>> the connection etc handed over to the OS driver. >> [...] >>>> AFAIK the BIOS interfaces do not have anything as reliable as that. >>>> >>>> How does virtio deal with this in the BIOS case? >>> >>> It doesn't, as far as I can tell. >>> >>> I don't think it has to, though! On a BIOS box, you can always boot DOS, >>> or another operating system that continues to use the BIOS interfaces >>> forever. (Same as if you never call ExitBootServices() in UEFI.) >>> >>> Given that no starter pistol gets fired between the firmware and the OS >>> on such a platform, they must always respect each other. I guess this >>> could occur through the E820 map, or some such. >> >> One can use the "ACPI enable" SMI event to detect this if they really >> wanted to. In SeaBIOS one could do this from >> src/fw/smm.c:handle_smi() - however, no other drivers need this >> notification today and it would be a bit ugly to have to handle it >> from an SMI. (Assuming Xen were to support SMIs.) >> >>> No clue in what kind of E820 memory SeaBIOS allocates the virtio rings, >>> but I guess the Linux kernel stays away from those areas until it's past >>> device probing and binding. >> >> In SeaBIOS, the virtio memory is allocated from reserved memory. (See >> the memalign_high() call in src/hw/virtio-pci.c - the "high" memory >> zone is taken from reserved memory: >> http://seabios.org/Memory_Model#Memory_available_during_initialization >> ) >> >> What's the reason for the "stumbling block" that requires the BIOS to >> tear down the Xen ring prior to the OS being able to replace it? The >> BIOS disk calls are all synchronous, so the ring wont be active when >> the OS brings up its own ring. Is there some low-level interaction >> that prevents the OS from just resetting the ring prior to enabling >> it? > > Xen only exports one PV disk interface for each disk to the guest, and > each PV interface only supports one frontend -- only SeaBIOS or the OS > can be connected to one PV disk, not both. In the case of OVMF, we > handle that by disconnecting the PV frontend in OVMF when > ExitBootServices is called, so that the OS driver can reconnect later. Does the XenBus protocol support a device reset operation, regardless of what state the device is currently in? (I don't remember all the state transitions any longer, sorry.) Thanks Laszlo ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 9:21 ` [Qemu-devel] " Laszlo Ersek (?) @ 2015-10-16 9:33 ` Stefano Stabellini -1 siblings, 0 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-16 9:33 UTC (permalink / raw) To: Laszlo Ersek Cc: Kevin Wolf, Matt Fleming, Ian Campbell, qemu-block, Stefano Stabellini, Ard Biesheuvel, qemu-devel, xen-devel, Fabio Fantoni, Kevin O'Connor, Anthony.Perard, John Snow On Fri, 16 Oct 2015, Laszlo Ersek wrote: > On 10/16/15 11:06, Stefano Stabellini wrote: > > On Thu, 15 Oct 2015, Kevin O'Connor wrote: > >> On Fri, Oct 16, 2015 at 01:10:54AM +0200, Laszlo Ersek wrote: > >>> On 10/14/15 13:27, Ian Campbell wrote: > >>>> On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote: > >>>>>> Can't you just teach SeaBIOS how to deal with your PV disks and then > >>>>>> only add that to your VM and forget about IDE/AHCI? I mean, that's how > >>>>>> it's done for virtio-blk, and it doesn't involve any insanities like > >>>>>> ripping out non-hotpluggable devices. > >>>>> > >>>>> Teaching SeaBIOS to deal with PV disks can be done, in fact we already > >>>>> support PV disks in OVMF. It is possible to boot Windows with OVMF > >>>>> without any IDE disks (patch pending for libxl to create a VM without > >>>>> emulated IDE disks). > >>>> > >>>> One stumbling block in the past has been how to know when the PV drivers in > >>>> the BIOS are no longer required, such that the ring can be torn down and/or > >>>> the connection etc handed over to the OS driver. > >> [...] > >>>> AFAIK the BIOS interfaces do not have anything as reliable as that. > >>>> > >>>> How does virtio deal with this in the BIOS case? > >>> > >>> It doesn't, as far as I can tell. > >>> > >>> I don't think it has to, though! On a BIOS box, you can always boot DOS, > >>> or another operating system that continues to use the BIOS interfaces > >>> forever. (Same as if you never call ExitBootServices() in UEFI.) > >>> > >>> Given that no starter pistol gets fired between the firmware and the OS > >>> on such a platform, they must always respect each other. I guess this > >>> could occur through the E820 map, or some such. > >> > >> One can use the "ACPI enable" SMI event to detect this if they really > >> wanted to. In SeaBIOS one could do this from > >> src/fw/smm.c:handle_smi() - however, no other drivers need this > >> notification today and it would be a bit ugly to have to handle it > >> from an SMI. (Assuming Xen were to support SMIs.) > >> > >>> No clue in what kind of E820 memory SeaBIOS allocates the virtio rings, > >>> but I guess the Linux kernel stays away from those areas until it's past > >>> device probing and binding. > >> > >> In SeaBIOS, the virtio memory is allocated from reserved memory. (See > >> the memalign_high() call in src/hw/virtio-pci.c - the "high" memory > >> zone is taken from reserved memory: > >> http://seabios.org/Memory_Model#Memory_available_during_initialization > >> ) > >> > >> What's the reason for the "stumbling block" that requires the BIOS to > >> tear down the Xen ring prior to the OS being able to replace it? The > >> BIOS disk calls are all synchronous, so the ring wont be active when > >> the OS brings up its own ring. Is there some low-level interaction > >> that prevents the OS from just resetting the ring prior to enabling > >> it? > > > > Xen only exports one PV disk interface for each disk to the guest, and > > each PV interface only supports one frontend -- only SeaBIOS or the OS > > can be connected to one PV disk, not both. In the case of OVMF, we > > handle that by disconnecting the PV frontend in OVMF when > > ExitBootServices is called, so that the OS driver can reconnect later. > > Does the XenBus protocol support a device reset operation, regardless of > what state the device is currently in? (I don't remember all the state > transitions any longer, sorry.) The PV block protocol doesn't unfortunately. At least the block backend in QEMU doesn't support it. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 9:21 ` [Qemu-devel] " Laszlo Ersek (?) (?) @ 2015-10-16 9:33 ` Stefano Stabellini -1 siblings, 0 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-16 9:33 UTC (permalink / raw) To: Laszlo Ersek Cc: Kevin Wolf, Matt Fleming, Ian Campbell, qemu-block, Stefano Stabellini, Ard Biesheuvel, qemu-devel, xen-devel, Fabio Fantoni, Kevin O'Connor, Anthony.Perard, John Snow On Fri, 16 Oct 2015, Laszlo Ersek wrote: > On 10/16/15 11:06, Stefano Stabellini wrote: > > On Thu, 15 Oct 2015, Kevin O'Connor wrote: > >> On Fri, Oct 16, 2015 at 01:10:54AM +0200, Laszlo Ersek wrote: > >>> On 10/14/15 13:27, Ian Campbell wrote: > >>>> On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote: > >>>>>> Can't you just teach SeaBIOS how to deal with your PV disks and then > >>>>>> only add that to your VM and forget about IDE/AHCI? I mean, that's how > >>>>>> it's done for virtio-blk, and it doesn't involve any insanities like > >>>>>> ripping out non-hotpluggable devices. > >>>>> > >>>>> Teaching SeaBIOS to deal with PV disks can be done, in fact we already > >>>>> support PV disks in OVMF. It is possible to boot Windows with OVMF > >>>>> without any IDE disks (patch pending for libxl to create a VM without > >>>>> emulated IDE disks). > >>>> > >>>> One stumbling block in the past has been how to know when the PV drivers in > >>>> the BIOS are no longer required, such that the ring can be torn down and/or > >>>> the connection etc handed over to the OS driver. > >> [...] > >>>> AFAIK the BIOS interfaces do not have anything as reliable as that. > >>>> > >>>> How does virtio deal with this in the BIOS case? > >>> > >>> It doesn't, as far as I can tell. > >>> > >>> I don't think it has to, though! On a BIOS box, you can always boot DOS, > >>> or another operating system that continues to use the BIOS interfaces > >>> forever. (Same as if you never call ExitBootServices() in UEFI.) > >>> > >>> Given that no starter pistol gets fired between the firmware and the OS > >>> on such a platform, they must always respect each other. I guess this > >>> could occur through the E820 map, or some such. > >> > >> One can use the "ACPI enable" SMI event to detect this if they really > >> wanted to. In SeaBIOS one could do this from > >> src/fw/smm.c:handle_smi() - however, no other drivers need this > >> notification today and it would be a bit ugly to have to handle it > >> from an SMI. (Assuming Xen were to support SMIs.) > >> > >>> No clue in what kind of E820 memory SeaBIOS allocates the virtio rings, > >>> but I guess the Linux kernel stays away from those areas until it's past > >>> device probing and binding. > >> > >> In SeaBIOS, the virtio memory is allocated from reserved memory. (See > >> the memalign_high() call in src/hw/virtio-pci.c - the "high" memory > >> zone is taken from reserved memory: > >> http://seabios.org/Memory_Model#Memory_available_during_initialization > >> ) > >> > >> What's the reason for the "stumbling block" that requires the BIOS to > >> tear down the Xen ring prior to the OS being able to replace it? The > >> BIOS disk calls are all synchronous, so the ring wont be active when > >> the OS brings up its own ring. Is there some low-level interaction > >> that prevents the OS from just resetting the ring prior to enabling > >> it? > > > > Xen only exports one PV disk interface for each disk to the guest, and > > each PV interface only supports one frontend -- only SeaBIOS or the OS > > can be connected to one PV disk, not both. In the case of OVMF, we > > handle that by disconnecting the PV frontend in OVMF when > > ExitBootServices is called, so that the OS driver can reconnect later. > > Does the XenBus protocol support a device reset operation, regardless of > what state the device is currently in? (I don't remember all the state > transitions any longer, sorry.) The PV block protocol doesn't unfortunately. At least the block backend in QEMU doesn't support it. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 9:06 ` [Qemu-devel] " Stefano Stabellini @ 2015-10-16 9:34 ` Ian Campbell -1 siblings, 0 replies; 95+ messages in thread From: Ian Campbell @ 2015-10-16 9:34 UTC (permalink / raw) To: Stefano Stabellini, Kevin O'Connor Cc: Kevin Wolf, Matt Fleming, qemu-block, Ard Biesheuvel, John Snow, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, Laszlo Ersek On Fri, 2015-10-16 at 10:06 +0100, Stefano Stabellini wrote: > > What's the reason for the "stumbling block" that requires the BIOS to > > tear down the Xen ring prior to the OS being able to replace it? The > > BIOS disk calls are all synchronous, so the ring wont be active when > > the OS brings up its own ring. Is there some low-level interaction > > that prevents the OS from just resetting the ring prior to enabling > > it? > > Xen only exports one PV disk interface for each disk to the guest, and > each PV interface only supports one frontend -- only SeaBIOS or the OS > can be connected to one PV disk, not both. Which I think is just another way of saying that the Xen PV protocol currently lacks an explicit requirement for the OS to reset the device (or indeed the general PV infrastructure, grant tables etc) before use. Retrofitting that requirement is of course a little tricky. The unplug protocol might be extensible neough though. IIRC it does include provisions for the OS to specify a version and the reject the unplug, so upreving that to include a reset requirement _might_ be possible. At which point it can at least be made a config option which can be switch on for new enough guests. i.e. if the guest is configured to use PV drivers from SeaBIOS the unplug protocol would reject the attempt to unplug the (non-existent) IDE devices and the guest therefore should fail to bind to the PV devices, while a newer guest which knows it has to do a reset would declare itself to be newer and succeed in the unplug. (NB: details of the protocol are sketchy in my memory, and the above may need actual though applied to make it practical, but you get the gist I hope). Then you are just into some sort of multiyear transition/deprecation sequence before you make it the default. > In the case of OVMF, we > handle that by disconnecting the PV frontend in OVMF when > ExitBootServices is called, so that the OS driver can reconnect later. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu @ 2015-10-16 9:34 ` Ian Campbell 0 siblings, 0 replies; 95+ messages in thread From: Ian Campbell @ 2015-10-16 9:34 UTC (permalink / raw) To: Stefano Stabellini, Kevin O'Connor Cc: Kevin Wolf, Matt Fleming, qemu-block, Ard Biesheuvel, John Snow, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, Laszlo Ersek On Fri, 2015-10-16 at 10:06 +0100, Stefano Stabellini wrote: > > What's the reason for the "stumbling block" that requires the BIOS to > > tear down the Xen ring prior to the OS being able to replace it? The > > BIOS disk calls are all synchronous, so the ring wont be active when > > the OS brings up its own ring. Is there some low-level interaction > > that prevents the OS from just resetting the ring prior to enabling > > it? > > Xen only exports one PV disk interface for each disk to the guest, and > each PV interface only supports one frontend -- only SeaBIOS or the OS > can be connected to one PV disk, not both. Which I think is just another way of saying that the Xen PV protocol currently lacks an explicit requirement for the OS to reset the device (or indeed the general PV infrastructure, grant tables etc) before use. Retrofitting that requirement is of course a little tricky. The unplug protocol might be extensible neough though. IIRC it does include provisions for the OS to specify a version and the reject the unplug, so upreving that to include a reset requirement _might_ be possible. At which point it can at least be made a config option which can be switch on for new enough guests. i.e. if the guest is configured to use PV drivers from SeaBIOS the unplug protocol would reject the attempt to unplug the (non-existent) IDE devices and the guest therefore should fail to bind to the PV devices, while a newer guest which knows it has to do a reset would declare itself to be newer and succeed in the unplug. (NB: details of the protocol are sketchy in my memory, and the above may need actual though applied to make it practical, but you get the gist I hope). Then you are just into some sort of multiyear transition/deprecation sequence before you make it the default. > In the case of OVMF, we > handle that by disconnecting the PV frontend in OVMF when > ExitBootServices is called, so that the OS driver can reconnect later. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 9:06 ` [Qemu-devel] " Stefano Stabellini ` (2 preceding siblings ...) (?) @ 2015-10-16 13:03 ` Kevin O'Connor -1 siblings, 0 replies; 95+ messages in thread From: Kevin O'Connor @ 2015-10-16 13:03 UTC (permalink / raw) To: Stefano Stabellini Cc: Kevin Wolf, Matt Fleming, Ian Campbell, qemu-block, Ard Biesheuvel, John Snow, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, Laszlo Ersek On Fri, Oct 16, 2015 at 10:06:48AM +0100, Stefano Stabellini wrote: > On Thu, 15 Oct 2015, Kevin O'Connor wrote: > > What's the reason for the "stumbling block" that requires the BIOS to > > tear down the Xen ring prior to the OS being able to replace it? The > > BIOS disk calls are all synchronous, so the ring wont be active when > > the OS brings up its own ring. Is there some low-level interaction > > that prevents the OS from just resetting the ring prior to enabling > > it? > > Xen only exports one PV disk interface for each disk to the guest, and > each PV interface only supports one frontend -- only SeaBIOS or the OS > can be connected to one PV disk, not both. In the case of OVMF, we > handle that by disconnecting the PV frontend in OVMF when > ExitBootServices is called, so that the OS driver can reconnect later. Well, there isn't a requirement for both SeaBIOS and the OS to be connected at the same time - it's fine for the OS to replace SeaBIOS. With the hardware I'm familiar with (eg, usb, ahci, virtio) the OS just ends up replacing SeaBIOS' DMA rings when it configures its own. I guess something in the low-level interface of Xen makes that not work. Is plugging/unplugging very high overhead? Since the SeaBIOS disk interface is fully synchronous, in theory one could have it plug/unplug on every read request. -Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 9:06 ` [Qemu-devel] " Stefano Stabellini ` (3 preceding siblings ...) (?) @ 2015-10-16 13:03 ` Kevin O'Connor -1 siblings, 0 replies; 95+ messages in thread From: Kevin O'Connor @ 2015-10-16 13:03 UTC (permalink / raw) To: Stefano Stabellini Cc: Kevin Wolf, Matt Fleming, Ian Campbell, qemu-block, Ard Biesheuvel, John Snow, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, Laszlo Ersek On Fri, Oct 16, 2015 at 10:06:48AM +0100, Stefano Stabellini wrote: > On Thu, 15 Oct 2015, Kevin O'Connor wrote: > > What's the reason for the "stumbling block" that requires the BIOS to > > tear down the Xen ring prior to the OS being able to replace it? The > > BIOS disk calls are all synchronous, so the ring wont be active when > > the OS brings up its own ring. Is there some low-level interaction > > that prevents the OS from just resetting the ring prior to enabling > > it? > > Xen only exports one PV disk interface for each disk to the guest, and > each PV interface only supports one frontend -- only SeaBIOS or the OS > can be connected to one PV disk, not both. In the case of OVMF, we > handle that by disconnecting the PV frontend in OVMF when > ExitBootServices is called, so that the OS driver can reconnect later. Well, there isn't a requirement for both SeaBIOS and the OS to be connected at the same time - it's fine for the OS to replace SeaBIOS. With the hardware I'm familiar with (eg, usb, ahci, virtio) the OS just ends up replacing SeaBIOS' DMA rings when it configures its own. I guess something in the low-level interface of Xen makes that not work. Is plugging/unplugging very high overhead? Since the SeaBIOS disk interface is fully synchronous, in theory one could have it plug/unplug on every read request. -Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 2:38 ` [Qemu-devel] [Xen-devel] " Kevin O'Connor @ 2015-10-16 9:13 ` Laszlo Ersek 2015-10-16 9:13 ` [Qemu-devel] " Laszlo Ersek 1 sibling, 0 replies; 95+ messages in thread From: Laszlo Ersek @ 2015-10-16 9:13 UTC (permalink / raw) To: Kevin O'Connor Cc: Kevin Wolf, Matt Fleming, Ian Campbell, qemu-block, Stefano Stabellini, Ard Biesheuvel, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, John Snow On 10/16/15 04:38, Kevin O'Connor wrote: > On Fri, Oct 16, 2015 at 01:10:54AM +0200, Laszlo Ersek wrote: >> On 10/14/15 13:27, Ian Campbell wrote: >>> On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote: >>>>> Can't you just teach SeaBIOS how to deal with your PV disks and then >>>>> only add that to your VM and forget about IDE/AHCI? I mean, that's how >>>>> it's done for virtio-blk, and it doesn't involve any insanities like >>>>> ripping out non-hotpluggable devices. >>>> >>>> Teaching SeaBIOS to deal with PV disks can be done, in fact we already >>>> support PV disks in OVMF. It is possible to boot Windows with OVMF >>>> without any IDE disks (patch pending for libxl to create a VM without >>>> emulated IDE disks). >>> >>> One stumbling block in the past has been how to know when the PV drivers in >>> the BIOS are no longer required, such that the ring can be torn down and/or >>> the connection etc handed over to the OS driver. > [...] >>> AFAIK the BIOS interfaces do not have anything as reliable as that. >>> >>> How does virtio deal with this in the BIOS case? >> >> It doesn't, as far as I can tell. >> >> I don't think it has to, though! On a BIOS box, you can always boot DOS, >> or another operating system that continues to use the BIOS interfaces >> forever. (Same as if you never call ExitBootServices() in UEFI.) >> >> Given that no starter pistol gets fired between the firmware and the OS >> on such a platform, they must always respect each other. I guess this >> could occur through the E820 map, or some such. > > One can use the "ACPI enable" SMI event to detect this if they really > wanted to. In SeaBIOS one could do this from > src/fw/smm.c:handle_smi() - however, no other drivers need this > notification today and it would be a bit ugly to have to handle it > from an SMI. (Assuming Xen were to support SMIs.) > >> No clue in what kind of E820 memory SeaBIOS allocates the virtio rings, >> but I guess the Linux kernel stays away from those areas until it's past >> device probing and binding. > > In SeaBIOS, the virtio memory is allocated from reserved memory. Perfect! That gives Xen drivers precedence to do the same. > (See > the memalign_high() call in src/hw/virtio-pci.c - the "high" memory > zone is taken from reserved memory: > http://seabios.org/Memory_Model#Memory_available_during_initialization > ) > > What's the reason for the "stumbling block" that requires the BIOS to > tear down the Xen ring prior to the OS being able to replace it? The > BIOS disk calls are all synchronous, so the ring wont be active when > the OS brings up its own ring. Yes, that's an argument that works well in practice. However... > Is there some low-level interaction > that prevents the OS from just resetting the ring prior to enabling > it? the assumption was that the ring would be placed into normal memory. If GRUB or the kernel overwrote the memory (reallocating the same pages for completely unrelated purposes) that used to contain the ring while SeaBIOS was serving requests, the hypervisor would be allowed to notice and act upon writes to those pages *without* any explicit "kick" (= guest-to-host notification). The hypervisor is allowed to look at the ring any time it wishes, so guest code uses barriers while populating the ring, and kicks the hypervisor "just in case it's not looking right now". But if the firmware's ring is in reserved memory, then the OS will stay away forever. That's great -- it answers the question for virtio, and should also guide a Xen PV driver implementation. Thanks! Laszlo > > -Kevin > ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu @ 2015-10-16 9:13 ` Laszlo Ersek 0 siblings, 0 replies; 95+ messages in thread From: Laszlo Ersek @ 2015-10-16 9:13 UTC (permalink / raw) To: Kevin O'Connor Cc: Kevin Wolf, Matt Fleming, Ian Campbell, qemu-block, Stefano Stabellini, Ard Biesheuvel, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, John Snow On 10/16/15 04:38, Kevin O'Connor wrote: > On Fri, Oct 16, 2015 at 01:10:54AM +0200, Laszlo Ersek wrote: >> On 10/14/15 13:27, Ian Campbell wrote: >>> On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote: >>>>> Can't you just teach SeaBIOS how to deal with your PV disks and then >>>>> only add that to your VM and forget about IDE/AHCI? I mean, that's how >>>>> it's done for virtio-blk, and it doesn't involve any insanities like >>>>> ripping out non-hotpluggable devices. >>>> >>>> Teaching SeaBIOS to deal with PV disks can be done, in fact we already >>>> support PV disks in OVMF. It is possible to boot Windows with OVMF >>>> without any IDE disks (patch pending for libxl to create a VM without >>>> emulated IDE disks). >>> >>> One stumbling block in the past has been how to know when the PV drivers in >>> the BIOS are no longer required, such that the ring can be torn down and/or >>> the connection etc handed over to the OS driver. > [...] >>> AFAIK the BIOS interfaces do not have anything as reliable as that. >>> >>> How does virtio deal with this in the BIOS case? >> >> It doesn't, as far as I can tell. >> >> I don't think it has to, though! On a BIOS box, you can always boot DOS, >> or another operating system that continues to use the BIOS interfaces >> forever. (Same as if you never call ExitBootServices() in UEFI.) >> >> Given that no starter pistol gets fired between the firmware and the OS >> on such a platform, they must always respect each other. I guess this >> could occur through the E820 map, or some such. > > One can use the "ACPI enable" SMI event to detect this if they really > wanted to. In SeaBIOS one could do this from > src/fw/smm.c:handle_smi() - however, no other drivers need this > notification today and it would be a bit ugly to have to handle it > from an SMI. (Assuming Xen were to support SMIs.) > >> No clue in what kind of E820 memory SeaBIOS allocates the virtio rings, >> but I guess the Linux kernel stays away from those areas until it's past >> device probing and binding. > > In SeaBIOS, the virtio memory is allocated from reserved memory. Perfect! That gives Xen drivers precedence to do the same. > (See > the memalign_high() call in src/hw/virtio-pci.c - the "high" memory > zone is taken from reserved memory: > http://seabios.org/Memory_Model#Memory_available_during_initialization > ) > > What's the reason for the "stumbling block" that requires the BIOS to > tear down the Xen ring prior to the OS being able to replace it? The > BIOS disk calls are all synchronous, so the ring wont be active when > the OS brings up its own ring. Yes, that's an argument that works well in practice. However... > Is there some low-level interaction > that prevents the OS from just resetting the ring prior to enabling > it? the assumption was that the ring would be placed into normal memory. If GRUB or the kernel overwrote the memory (reallocating the same pages for completely unrelated purposes) that used to contain the ring while SeaBIOS was serving requests, the hypervisor would be allowed to notice and act upon writes to those pages *without* any explicit "kick" (= guest-to-host notification). The hypervisor is allowed to look at the ring any time it wishes, so guest code uses barriers while populating the ring, and kicks the hypervisor "just in case it's not looking right now". But if the firmware's ring is in reserved memory, then the OS will stay away forever. That's great -- it answers the question for virtio, and should also guide a Xen PV driver implementation. Thanks! Laszlo > > -Kevin > ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-14 11:06 ` Stefano Stabellini 2015-10-14 11:27 ` [Qemu-devel] " Ian Campbell @ 2015-10-14 11:32 ` Kevin Wolf 2015-10-14 11:44 ` Stefano Stabellini 2015-10-15 16:27 ` Fabio Fantoni 2 siblings, 1 reply; 95+ messages in thread From: Kevin Wolf @ 2015-10-14 11:32 UTC (permalink / raw) To: Stefano Stabellini Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, John Snow Am 14.10.2015 um 13:06 hat Stefano Stabellini geschrieben: > On Wed, 14 Oct 2015, Kevin Wolf wrote: > > [ CC qemu-block ] > > > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > > > On Tue, 13 Oct 2015, John Snow wrote: > > > > On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > > > > I added ahci disk support in libxl and using it for week seems that was > > > > > ok, after a reply of Stefano Stabellini seems that xen disk unplug > > > > > support only ide disks: > > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 > > > > > > > > > > Today Paul Durrant told me that even if pv disk is ok also with ahci and > > > > > the emulated one is offline can be a risk: > > > > > http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html > > > > > > > > > > > > > > > I tried to take a fast look in qemu code but I not understand the needed > > > > > thing for add the xen disk unplug support also for ahci, can someone do > > > > > it or tell me useful information for do it please? > > > > > > > > > > Thanks for any reply and sorry for my bad english. > > > > > > > > > > > > > I'm not entirely sure what features you need AHCI to support in order > > > > for Xen to be happy. > > > > > > > > I'd guess hotplugging, but where I get confused is that IDE disks don't > > > > support hotplugging either, so I guess I'm not sure sure what you need. > > > > > > > > Stefano, can you help bridge my Xen knowledge gap? > > > > > > Hi John, > > > > > > we need something like hw/i386/xen/xen_platform.c:unplug_disks but that > > > can unplug AHCI disk. And by unplug, I mean "make disappear" like > > > pci_piix3_xen_ide_unplug does for ide. > > > > Maybe this would be the right time to stop the craziness with your > > hybrid IDE/xendisk setup. It's a horrible thing that would never happen > > on real hardware. > > I would be quite happy to stop (or even get rid of) the craziness. > > > > Can't you just teach SeaBIOS how to deal with your PV disks and then > > only add that to your VM and forget about IDE/AHCI? I mean, that's how > > it's done for virtio-blk, and it doesn't involve any insanities like > > ripping out non-hotpluggable devices. > > Teaching SeaBIOS to deal with PV disks can be done, in fact we already > support PV disks in OVMF. It is possible to boot Windows with OVMF > without any IDE disks (patch pending for libxl to create a VM without > emulated IDE disks). > > However we have to be honest that implementing PV disk support in > SeaBIOS is a different magnitude of effort compared to implementing AHCI > "unplug". Agreed. But we generally try to do the right thing and not the easy thing. Maybe I'm missing something, but my impression was that the hybrid setup was only used so that you can boot from a PV disk even though the BIOS doesn't have a PV driver. In that case, why would you even want to use AHCI instead of IDE? During the early boot performance shouldn't be much different as there is no parallelism, and afterwards the PV driver is used. > I would suggest Fabio to avoid AHCI disks altogether and just use OVMF > with PV disks only and Anthony's patch to libxl to avoid creating any > IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. > > Would that work for you? That sounds certainly like a better step forward than adding a crude hack to AHCI. And if you want to make me completely happy, plan to extend SeaBIOS so that we can even drop the existing hack in IDE. Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-14 11:32 ` Kevin Wolf @ 2015-10-14 11:44 ` Stefano Stabellini 0 siblings, 0 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-14 11:44 UTC (permalink / raw) To: Kevin Wolf Cc: qemu-block, Stefano Stabellini, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, John Snow On Wed, 14 Oct 2015, Kevin Wolf wrote: > Am 14.10.2015 um 13:06 hat Stefano Stabellini geschrieben: > > On Wed, 14 Oct 2015, Kevin Wolf wrote: > > > [ CC qemu-block ] > > > > > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > > > > On Tue, 13 Oct 2015, John Snow wrote: > > > > > On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > > > > > I added ahci disk support in libxl and using it for week seems that was > > > > > > ok, after a reply of Stefano Stabellini seems that xen disk unplug > > > > > > support only ide disks: > > > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 > > > > > > > > > > > > Today Paul Durrant told me that even if pv disk is ok also with ahci and > > > > > > the emulated one is offline can be a risk: > > > > > > http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html > > > > > > > > > > > > > > > > > > I tried to take a fast look in qemu code but I not understand the needed > > > > > > thing for add the xen disk unplug support also for ahci, can someone do > > > > > > it or tell me useful information for do it please? > > > > > > > > > > > > Thanks for any reply and sorry for my bad english. > > > > > > > > > > > > > > > > I'm not entirely sure what features you need AHCI to support in order > > > > > for Xen to be happy. > > > > > > > > > > I'd guess hotplugging, but where I get confused is that IDE disks don't > > > > > support hotplugging either, so I guess I'm not sure sure what you need. > > > > > > > > > > Stefano, can you help bridge my Xen knowledge gap? > > > > > > > > Hi John, > > > > > > > > we need something like hw/i386/xen/xen_platform.c:unplug_disks but that > > > > can unplug AHCI disk. And by unplug, I mean "make disappear" like > > > > pci_piix3_xen_ide_unplug does for ide. > > > > > > Maybe this would be the right time to stop the craziness with your > > > hybrid IDE/xendisk setup. It's a horrible thing that would never happen > > > on real hardware. > > > > I would be quite happy to stop (or even get rid of) the craziness. > > > > > > > Can't you just teach SeaBIOS how to deal with your PV disks and then > > > only add that to your VM and forget about IDE/AHCI? I mean, that's how > > > it's done for virtio-blk, and it doesn't involve any insanities like > > > ripping out non-hotpluggable devices. > > > > Teaching SeaBIOS to deal with PV disks can be done, in fact we already > > support PV disks in OVMF. It is possible to boot Windows with OVMF > > without any IDE disks (patch pending for libxl to create a VM without > > emulated IDE disks). > > > > However we have to be honest that implementing PV disk support in > > SeaBIOS is a different magnitude of effort compared to implementing AHCI > > "unplug". > > Agreed. But we generally try to do the right thing and not the easy > thing. Sure. I am quite happy to let other people do it though :-) > Maybe I'm missing something, but my impression was that the hybrid setup > was only used so that you can boot from a PV disk even though the BIOS > doesn't have a PV driver. In that case, why would you even want to use > AHCI instead of IDE? During the early boot performance shouldn't be much > different as there is no parallelism, and afterwards the PV driver is > used. The "unplug" code and the design choice predate me -- I am not sure why it was done like that. In those days there was no SeaBIOS: maybe they thought that writing a PV disk frontend in rombios would be madness? In addition isn't it true that some guests, once they see a PIIX3 chipset and they know that there is one disk, they might just try to access it directly via the IDE interface? I am thinking of some old versions of Windows. Are they really able to cope with the case where they can only access the disk via the legacy BIOS until non-IDE drivers come along? > > I would suggest Fabio to avoid AHCI disks altogether and just use OVMF > > with PV disks only and Anthony's patch to libxl to avoid creating any > > IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. > > > > Would that work for you? > > That sounds certainly like a better step forward than adding a crude > hack to AHCI. > > And if you want to make me completely happy, plan to extend SeaBIOS so > that we can even drop the existing hack in IDE. There are lots of existing guests which write to the magic ioport to "unplug" disks. We would need some sort of deprecation plan. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-14 11:06 ` Stefano Stabellini @ 2015-10-15 16:27 ` Fabio Fantoni 2015-10-14 11:32 ` Kevin Wolf 2015-10-15 16:27 ` Fabio Fantoni 2 siblings, 0 replies; 95+ messages in thread From: Fabio Fantoni @ 2015-10-15 16:27 UTC (permalink / raw) To: Stefano Stabellini, Kevin Wolf Cc: qemu-block, qemu-devel, xen-devel, Paul Durrant, Anthony.Perard, John Snow [-- Attachment #1: Type: text/plain, Size: 3451 bytes --] Il 14/10/2015 13:06, Stefano Stabellini ha scritto: > On Wed, 14 Oct 2015, Kevin Wolf wrote: >> [ CC qemu-block ] >> >> Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: >>> On Tue, 13 Oct 2015, John Snow wrote: >>>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: >>>>> I added ahci disk support in libxl and using it for week seems that was >>>>> ok, after a reply of Stefano Stabellini seems that xen disk unplug >>>>> support only ide disks: >>>>> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 >>>>> >>>>> Today Paul Durrant told me that even if pv disk is ok also with ahci and >>>>> the emulated one is offline can be a risk: >>>>> http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html >>>>> >>>>> >>>>> I tried to take a fast look in qemu code but I not understand the needed >>>>> thing for add the xen disk unplug support also for ahci, can someone do >>>>> it or tell me useful information for do it please? >>>>> >>>>> Thanks for any reply and sorry for my bad english. >>>>> >>>> I'm not entirely sure what features you need AHCI to support in order >>>> for Xen to be happy. >>>> >>>> I'd guess hotplugging, but where I get confused is that IDE disks don't >>>> support hotplugging either, so I guess I'm not sure sure what you need. >>>> >>>> Stefano, can you help bridge my Xen knowledge gap? >>> >>> Hi John, >>> >>> we need something like hw/i386/xen/xen_platform.c:unplug_disks but that >>> can unplug AHCI disk. And by unplug, I mean "make disappear" like >>> pci_piix3_xen_ide_unplug does for ide. >> Maybe this would be the right time to stop the craziness with your >> hybrid IDE/xendisk setup. It's a horrible thing that would never happen >> on real hardware. > I would be quite happy to stop (or even get rid of) the craziness. > > >> Can't you just teach SeaBIOS how to deal with your PV disks and then >> only add that to your VM and forget about IDE/AHCI? I mean, that's how >> it's done for virtio-blk, and it doesn't involve any insanities like >> ripping out non-hotpluggable devices. > Teaching SeaBIOS to deal with PV disks can be done, in fact we already > support PV disks in OVMF. It is possible to boot Windows with OVMF > without any IDE disks (patch pending for libxl to create a VM without > emulated IDE disks). > > However we have to be honest that implementing PV disk support in > SeaBIOS is a different magnitude of effort compared to implementing AHCI > "unplug". > > I would suggest Fabio to avoid AHCI disks altogether and just use OVMF > with PV disks only and Anthony's patch to libxl to avoid creating any > IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. > > Would that work for you? Thanks for the advice, I tried it: https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 I installed W10 pro 64 bit with ide disk, installed the win pv drivers and after changed to xvdX instead hdX, is the only change needed, right? Initial boot is ok (ovmf part about pv disks seems ok) but windows boot fails with problem with pv drivers. In attachment full qemu log with xen_platform trace and domU's xl cfg. Someone have windows domUs with ovmf and pv disks only working? If yes can tell me the difference to understand what can be the problem please? > > >> Hm... How does a reboot of a machine that had its IDE already removed >> actually work? Do you restart the qemu process on reboot? > Restart QEMU, yes. [-- Attachment #2: qemu-dm-W10UEFI.log --] [-- Type: text/plain, Size: 15711 bytes --] main_channel_link: add main channel client main_channel_handle_parsed: net test: latency 8.258000 ms, bitrate 727789623 bps (694.074271 Mbps) inputs_connect: inputs channel client create red_dispatcher_set_cursor_peer: xen_platform_log xen platform: XEN|DllInitialize: 8.2.0 (80) (17.09.2015) xen_platform_log xen platform: XEN|AcpiFindRsdp: 0x00000000000EA020 xen_platform_log xen platform: XEN|SystemGetStartOptions: TESTSIGNING NOEXECUTE=OPTIN NOVGA xen_platform_log xen platform: XEN|SystemGetVersionInformation: KERNEL: 10.0 (BUILD 10240) PLATFORM WIN32_NT (x64) xen_platform_log xen platform: XEN|SystemGetVersionInformation: SUITES: xen_platform_log xen platform: XEN|SystemGetVersionInformation: - TERMINAL xen_platform_log xen platform: XEN|SystemGetVersionInformation: - SINGLEUSERTS xen_platform_log xen platform: XEN|SystemGetVersionInformation: TYPE: WORKSTATION xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[0] 00000000.00001000 - 00000000.0009efff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[1] 00000000.00100000 - 00000000.eed94fff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[2] 00000000.eee12000 - 00000000.efe91fff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[3] 00000000.efef6000 - 00000000.effcffff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[4] 00000000.efff0000 - 00000000.efffffff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[5] 00000001.00000000 - 00000001.07eaafff xen_platform_log xen platform: XEN|AcpiGetXsdt: 0x00000000FC012BA0 xen_platform_log xen platform: XEN|SystemProcessorInformation: ====> (0:0) xen_platform_log xen platform: XEN|SystemProcessorInformation: Manufacturer: GenuineIntel xen_platform_log xen platform: XEN|SystemProcessorInformation: APIC ID: 00 xen_platform_log xen platform: XEN|SystemProcessorInformation: PROCESSOR ID: 00 xen_platform_log xen platform: XEN|SystemProcessorInformation: <==== (0:0) xen_platform_log xen platform: XEN|SystemProcessorInformation: ====> (0:1) xen_platform_log xen platform: XEN|SystemProcessorInformation: Manufacturer: GenuineIntel xen_platform_log xen platform: XEN|SystemProcessorInformation: APIC ID: 02 xen_platform_log xen platform: XEN|SystemProcessorInformation: PROCESSOR ID: 01 xen_platform_log xen platform: XEN|SystemProcessorInformation: <==== (0:1) xen_platform_log xen platform: XEN: HYPERCALL PAGE 0 @ 00000001.03dd4000 xen_platform_log xen platform: XENFILT|DriverEntry: 8.2.0 (80) (17.09.2015) xen_platform_log xen platform: XEN: 4.6.0 (__XEN_INTERFACE_VERSION__ = 00040600) xen_platform_log xen platform: XENFILT|FdoCreate: FFFFE000CCF88C60 (ACPI\PNP0A03\0) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCEA9250 (PCI\VEN_8086&DEV_1237&SUBSYS_11001AF4&REV_02\00) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCEE2450 (PCI\VEN_8086&DEV_7000&SUBSYS_11001AF4&REV_00\08) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCED4BE0 (PCI\VEN_8086&DEV_7010&SUBSYS_11001AF4&REV_00\09) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCFC0C60 (PCI\VEN_5853&DEV_0001&SUBSYS_00015853&REV_01\10) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCFC0880 (PCI\VEN_8086&DEV_2668&SUBSYS_11001AF4&REV_01\18) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCFBFC60 (PCI\VEN_1AF4&DEV_1003&SUBSYS_00031AF4&REV_00\20) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCFBEC60 (PCI\VEN_1B36&DEV_0100&SUBSYS_11001AF4&REV_04\28) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCFBDC60 (PCI\VEN_10EC&DEV_8139&SUBSYS_11001AF4&REV_20\30) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCFBD880 (PCI\VEN_8086&DEV_2934&SUBSYS_11001AF4&REV_03\E8) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCFBC9F0 (PCI\VEN_8086&DEV_2935&SUBSYS_11001AF4&REV_03\E9) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCFBBB30 (PCI\VEN_8086&DEV_2936&SUBSYS_11001AF4&REV_03\EA) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCEA3C60 (PCI\VEN_8086&DEV_293A&SUBSYS_11001AF4&REV_03\EF) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCF04C60 (ACPI\PNP0103\0) xen_platform_log xen platform: XENFILT|DriverSetFilterState: PENDING xen_platform_log xen platform: XENFILT|DriverSetFilterState: DISABLED xen_platform_log xen platform: XENBUS|DriverEntry: 8.2.0 (80) (17.09.2015) xen_platform_log xen platform: XENFILT|PdoQueryInterface: PCI\VEN_5853&DEV_0001&SUBSYS_00015853&REV_01\10: PVDEVICE_INTERFACE (VERSION 1) xen_platform_log xen platform: XENFILT|PvdeviceSetActive: PCI\VEN_5853&DEV_0001&SUBSYS_00015853&REV_01\10 xen_platform_log xen platform: XENBUS|FdoSetFriendlyName: Xen PV Bus (0001) xen_platform_log xen platform: XENBUS|FdoCreate: FFFFE000CCEF3040 (XP0001 XENBUS) [ACTIVE] xen_platform_log xen platform: XENBUS|FdoConnectInterrupt: FFFFE000CCEF2A88: Shared LevelSensitive CPU 0:0 VECTOR b1 xen_platform_log xen platform: XENBUS|FdoConnectInterrupt: FFFFE000CCEF1E98: DeviceExclusive Latched CPU 0:0 VECTOR 50 xen_platform_log xen platform: XENBUS|FdoConnectInterrupt: FFFFE000CCEF1AC8: DeviceExclusive Latched CPU 0:1 VECTOR 50 xen_platform_log xen platform: XENBUS|FdoScan: ====> xen_platform_log xen platform: XENBUS|FdoCreateIoSpace: 00000000.f8000000 - 00000000.f8ffffff xen_platform_log xen platform: XENBUS|FdoSuspend: ====> xen_platform_log xen platform: XEN|HvmSetParam: fail1 (c0000022) xen_platform_log xen platform: SHARED_INFO: MAP XENMAPSPACE_shared_info @ 00000000.f8000000 xen_platform_log xen platform: XENBUS|FdoBalloon: ====> xen_platform_log xen platform: EVTCHN_FIFO: CONTROLBLOCK[0] @ 00000000.01019000 xen_platform_log xen platform: EVTCHN_FIFO: CONTROLBLOCK[1] @ 00000000.0109a000 xen_platform_log xen platform: XENBUS|EvtchnAbiAcquire: FIFO xen_platform_log xen platform: XENBUS|EvtchnInterruptEnable: CPU 0:0 (Vector = 80) xen_platform_log xen platform: XENBUS|EvtchnInterruptEnable: CPU 0:1 (Vector = 80) xen_platform_log xen platform: XENBUS|EvtchnInterruptEnable: CALLBACK VIA (Vector = 24) xen_platform_log xen platform: STORE: PAGE @ 00000000.feffc000 xen_platform_log xen platform: STORE: EVTCHN 1 xen_platform_log xen platform: EVTCHN_FIFO: EVENTARRAY[0] @ 00000000.0109b000 xen_platform_log xen platform: XENBUS|EvtchnFifoExpand: added ports [00000000 - 000003ff] xen_platform_log xen platform: XENBUS|PdoCreate: FFFFE000CCEA2D40 (VBD) xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 08000009 -> SUSPEND v1 SHARED_INFO v2 EVTCHN v4 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000A -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000B -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v2 RANGE_SET v1 CACHE v1 GNTTAB v2 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoCreate: FFFFE000CCEA2A20 (VIF) xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 08000009 -> SUSPEND v1 SHARED_INFO v2 EVTCHN v4 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000A -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000B -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v2 RANGE_SET v1 CACHE v1 GNTTAB v2 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoCreate: FFFFE000CCEF0D40 (IFACE) xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 08000009 -> SUSPEND v1 SHARED_INFO v2 EVTCHN v4 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000A -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000B -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v2 RANGE_SET v1 CACHE v1 GNTTAB v2 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENFILT|FdoCreate: FFFFE000CCEC7040 (PCIIDE\IDEChannel\0) xen_platform_log xen platform: XENFILT|FdoCreate: FFFFE000CCEC7430 (PCIIDE\IDEChannel\1) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCEC3C60 (IDE\CdRomQEMU_QEMU_DVD-ROM_______________________2.2.____\0.1.0) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 00000000000154F0) xen_platform_log xen platform: XENBUS|SUSPEND: Count = 0 xen_platform_log xen platform: XENBUS|SUSPEND: EARLY: xenbus.sys + 0000000000008474 (FFFFE000CCEF2E30) xen_platform_log xen platform: XENBUS|SUSPEND: EARLY: xenbus.sys + 0000000000011FA8 (FFFFE000CCF1C820) xen_platform_log xen platform: XENBUS|SUSPEND: EARLY: xenbus.sys + 0000000000014D10 (FFFFE000CBDCC000) xen_platform_log xen platform: XENBUS|SUSPEND: LATE: xenbus.sys + 00000000000084C4 (FFFFE000CCEF2E30) xen_platform_log xen platform: XENBUS|SUSPEND: LATE: xenbus.sys + 0000000000014D50 (FFFFE000CBDCC000) xen_platform_log xen platform: XENBUS|SUSPEND: LATE: xenbus.sys + 000000000000E080 (FFFFE000CCEF3B10) xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 00000000000154F0) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 000000000001655C) xen_platform_log xen platform: XENBUS|RANGE_SET: RANGE SETS: xen_platform_log xen platform: XENBUS|RANGE_SET: - io_space: xen_platform_log xen platform: XENBUS|RANGE_SET: {f8001000 - f8ffffff}* xen_platform_log xen platform: XENBUS|RANGE_SET: - balloon: xen_platform_log xen platform: XENBUS|RANGE_SET: EMPTY xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 000000000001655C) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 0000000000007800) xen_platform_log xen platform: XENBUS|EVTCHN: EVENT CHANNELS: xen_platform_log xen platform: XENBUS|EVTCHN: - (0001) BY xenbus.sys + 000000000001417D ACTIVE xen_platform_log xen platform: XENBUS|EVTCHN: FIXED xen_platform_log xen platform: XENBUS|EVTCHN: Events = 17 xen_platform_log xen platform: XENBUS|EVTCHN: - (0006) BY xenbus.sys + 000000000000AC7C ACTIVE xen_platform_log xen platform: XENBUS|EVTCHN: VIRQ: Index = 1 xen_platform_log xen platform: XENBUS|EVTCHN: Events = 0 xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 0000000000007800) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 0000000000011C08) xen_platform_log xen platform: XENBUS|SHARED_INFO: Address = 00000000.f8000000 xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 0000000000011C08) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 0000000000013E64) xen_platform_log xen platform: XENBUS|STORE: Address = 00000000.feffc000 xen_platform_log xen platform: XENBUS|STORE: Events = 17 Dpcs = 1 Polls = 20 xen_platform_log xen platform: XENBUS|STORE: WATCHES: xen_platform_log xen platform: XENBUS|STORE: - (E306) ON device BY xenbus.sys + 000000000000ACCD [ACTIVE] xen_platform_log xen platform: XENBUS|STORE: - (E307) ON control/shutdown BY xenbus.sys + 000000000000AD09 [ACTIVE] xen_platform_log xen platform: XENBUS|STORE: - (E308) ON memory/target BY xenbus.sys + 000000000000AD7C [ACTIVE] xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 0000000000013E64) xen_platform_log xen platform: XEN|BUGCHECK: ====> xen_platform_log xen platform: XEN|BUGCHECK: INACCESSIBLE_BOOT_DEVICE: FFFFD001452E27F0 FFFFFFFFC0000034 0000000000000000 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: \ArcName\multi(0)disk(0)rdisk(0)partition(4) xen_platform_log xen platform: XEN|BUGCHECK: CONTEXT (FFFFD001452E1B00): xen_platform_log xen platform: XEN|BUGCHECK: - GS = 002B xen_platform_log xen platform: XEN|BUGCHECK: - FS = 0053 xen_platform_log xen platform: XEN|BUGCHECK: - ES = 002B xen_platform_log xen platform: XEN|BUGCHECK: - DS = 002B xen_platform_log xen platform: XEN|BUGCHECK: - SS = 0018 xen_platform_log xen platform: XEN|BUGCHECK: - CS = 0010 xen_platform_log xen platform: XEN|BUGCHECK: - EFLAGS = 00000086 xen_platform_log xen platform: XEN|BUGCHECK: - RDI = 00000000452E27F0 xen_platform_log xen platform: XEN|BUGCHECK: - RSI = 00000000C0000034 xen_platform_log xen platform: XEN|BUGCHECK: - RBX = 000000008EFF0A30 xen_platform_log xen platform: XEN|BUGCHECK: - RDX = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - RCX = 00000000452E1B00 xen_platform_log xen platform: XEN|BUGCHECK: - RAX = 000000000000000F xen_platform_log xen platform: XEN|BUGCHECK: - RBP = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - RIP = 000000008EFE5C42 xen_platform_log xen platform: XEN|BUGCHECK: - RSP = 00000000452E1AE0 xen_platform_log xen platform: XEN|BUGCHECK: - R8 = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - R9 = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - R10 = 0000000000000100 xen_platform_log xen platform: XEN|BUGCHECK: - R11 = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - R12 = 0000000000000003 xen_platform_log xen platform: XEN|BUGCHECK: - R13 = 000000000000007B xen_platform_log xen platform: XEN|BUGCHECK: - R14 = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - R15 = 00000000CBBFF040 xen_platform_log xen platform: XEN|BUGCHECK: STACK: xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E1FF0: (0000000000000003 000000008EFE9790 000000008EFE8F20 000000008EFEE3A0) xen.sys + 0000000000005FDD xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2040: (000000008EFF1460 00000000452E2170 0000000000000001 0000000017132EA0) ntoskrnl.exe + 00000000001F49CB xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2070: (000000008EFF1460 0000000017132EA0 0000000000000000 0000000000000000) ntoskrnl.exe + 00000000001F3CCC xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2780: (00000000452E27F0 00000000172A409D 0000000000000000 0000000000000000) ntoskrnl.exe + 000000000014E3E4 xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E27C0: (000000000000007B 00000000452E27F0 00000000C0000034 0000000000000000) ntoskrnl.exe + 0000000000163ABF xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2840: (0000000050E07FF0 0000000080000284 0000000000000001 00000000FFE17B80) ntoskrnl.exe + 00000000007C7C33 xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2A80: (00000000CBD7B040 0000000000000000 0000000000000006 0000000015D035A0) ntoskrnl.exe + 00000000007D2DBF xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2BA0: (00000000173836A0 0000000015D035A0 00000000CBBFBB18 00000000171E0700) ntoskrnl.exe + 00000000007DE931 xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2BD0: (0000000000000000 0000000015D035A0 00000000CBBFBB18 00000000171E0740) ntoskrnl.exe + 000000000057C6CA xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2C00: (00000000CBBFF040 0000000000000000 0000000000000000 00000000FFFFFFFF) ntoskrnl.exe + 00000000000E6558 xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2C60: (000000001716A180 00000000CBBFF040 00000000171E0740 00000000000000FE) ntoskrnl.exe + 00000000001533C6 xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2C90: (00000000452E3000 00000000452DD000 0000000000000000 0000000000000000) 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: <==== Issued domain 8 reboot qemu: terminating on signal 1 from pid 4167 red_channel_client_disconnect_dummy: rcc=0x7fa45abfc640 (channel=0x7fa45a860650 type=5 id=0) snd_channel_put: SndChannel=0x7fa45abf1bd0 freed red_channel_client_disconnect_dummy: rcc=0x7fa45ab70110 (channel=0x7fa45a8b1260 type=6 id=0) snd_channel_put: SndChannel=0x7fa45abe1390 freed [-- Attachment #3: W10UEFI.cfg --] [-- Type: text/plain, Size: 912 bytes --] name='W10UEFI' builder="hvm" #device_model_override="/usr/lib/xen/bin/qemu-gdb" memory=4096 bios="ovmf" vcpus=2 acpi_s3=0 acpi_s4=0 #hdtype="ahci" vif=['bridge=xenbr0,mac=00:16:3e:33:44:09'] disk=['/mnt/vm/disks/W10UEFI.disk1.xm,raw,xvda,rw','/mnt/vm/iso/Windows10pro64bit.iso,raw,xvdb,ro,cdrom'] #disk=['/mnt/vm/disks/W10.disk1.cow-sn1,qcow2,hda,rw',',raw,hdb,ro,cdrom'] boot='cd' device_model_version="qemu-xen" viridian=1 xen_platform_pci=1 vnc=0 #vncunused=1 #vnclisten="0.0.0.0" keymap="it" on_crash="destroy" vga="qxl" spice=1 spicehost='0.0.0.0' spiceport=6000 spicedisable_ticketing=1 spicevdagent=1 spice_clipboard_sharing=0 #spice_image_compression="lz4" #spice_streaming_video="off" #spice_streaming_video="all" #spice_video_codecs="gstreamer:vp8" spiceusbredirection=4 soundhw="hda" localtime=1 #usbversion=3 ms_vm_genid="generate" device_model_args=["-trace","events=/etc/xen/qemu-trace-options"] ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu @ 2015-10-15 16:27 ` Fabio Fantoni 0 siblings, 0 replies; 95+ messages in thread From: Fabio Fantoni @ 2015-10-15 16:27 UTC (permalink / raw) To: Stefano Stabellini, Kevin Wolf Cc: qemu-block, qemu-devel, xen-devel, Paul Durrant, Anthony.Perard, John Snow [-- Attachment #1: Type: text/plain, Size: 3451 bytes --] Il 14/10/2015 13:06, Stefano Stabellini ha scritto: > On Wed, 14 Oct 2015, Kevin Wolf wrote: >> [ CC qemu-block ] >> >> Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: >>> On Tue, 13 Oct 2015, John Snow wrote: >>>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: >>>>> I added ahci disk support in libxl and using it for week seems that was >>>>> ok, after a reply of Stefano Stabellini seems that xen disk unplug >>>>> support only ide disks: >>>>> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 >>>>> >>>>> Today Paul Durrant told me that even if pv disk is ok also with ahci and >>>>> the emulated one is offline can be a risk: >>>>> http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html >>>>> >>>>> >>>>> I tried to take a fast look in qemu code but I not understand the needed >>>>> thing for add the xen disk unplug support also for ahci, can someone do >>>>> it or tell me useful information for do it please? >>>>> >>>>> Thanks for any reply and sorry for my bad english. >>>>> >>>> I'm not entirely sure what features you need AHCI to support in order >>>> for Xen to be happy. >>>> >>>> I'd guess hotplugging, but where I get confused is that IDE disks don't >>>> support hotplugging either, so I guess I'm not sure sure what you need. >>>> >>>> Stefano, can you help bridge my Xen knowledge gap? >>> >>> Hi John, >>> >>> we need something like hw/i386/xen/xen_platform.c:unplug_disks but that >>> can unplug AHCI disk. And by unplug, I mean "make disappear" like >>> pci_piix3_xen_ide_unplug does for ide. >> Maybe this would be the right time to stop the craziness with your >> hybrid IDE/xendisk setup. It's a horrible thing that would never happen >> on real hardware. > I would be quite happy to stop (or even get rid of) the craziness. > > >> Can't you just teach SeaBIOS how to deal with your PV disks and then >> only add that to your VM and forget about IDE/AHCI? I mean, that's how >> it's done for virtio-blk, and it doesn't involve any insanities like >> ripping out non-hotpluggable devices. > Teaching SeaBIOS to deal with PV disks can be done, in fact we already > support PV disks in OVMF. It is possible to boot Windows with OVMF > without any IDE disks (patch pending for libxl to create a VM without > emulated IDE disks). > > However we have to be honest that implementing PV disk support in > SeaBIOS is a different magnitude of effort compared to implementing AHCI > "unplug". > > I would suggest Fabio to avoid AHCI disks altogether and just use OVMF > with PV disks only and Anthony's patch to libxl to avoid creating any > IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. > > Would that work for you? Thanks for the advice, I tried it: https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 I installed W10 pro 64 bit with ide disk, installed the win pv drivers and after changed to xvdX instead hdX, is the only change needed, right? Initial boot is ok (ovmf part about pv disks seems ok) but windows boot fails with problem with pv drivers. In attachment full qemu log with xen_platform trace and domU's xl cfg. Someone have windows domUs with ovmf and pv disks only working? If yes can tell me the difference to understand what can be the problem please? > > >> Hm... How does a reboot of a machine that had its IDE already removed >> actually work? Do you restart the qemu process on reboot? > Restart QEMU, yes. [-- Attachment #2: qemu-dm-W10UEFI.log --] [-- Type: text/plain, Size: 15711 bytes --] main_channel_link: add main channel client main_channel_handle_parsed: net test: latency 8.258000 ms, bitrate 727789623 bps (694.074271 Mbps) inputs_connect: inputs channel client create red_dispatcher_set_cursor_peer: xen_platform_log xen platform: XEN|DllInitialize: 8.2.0 (80) (17.09.2015) xen_platform_log xen platform: XEN|AcpiFindRsdp: 0x00000000000EA020 xen_platform_log xen platform: XEN|SystemGetStartOptions: TESTSIGNING NOEXECUTE=OPTIN NOVGA xen_platform_log xen platform: XEN|SystemGetVersionInformation: KERNEL: 10.0 (BUILD 10240) PLATFORM WIN32_NT (x64) xen_platform_log xen platform: XEN|SystemGetVersionInformation: SUITES: xen_platform_log xen platform: XEN|SystemGetVersionInformation: - TERMINAL xen_platform_log xen platform: XEN|SystemGetVersionInformation: - SINGLEUSERTS xen_platform_log xen platform: XEN|SystemGetVersionInformation: TYPE: WORKSTATION xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[0] 00000000.00001000 - 00000000.0009efff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[1] 00000000.00100000 - 00000000.eed94fff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[2] 00000000.eee12000 - 00000000.efe91fff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[3] 00000000.efef6000 - 00000000.effcffff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[4] 00000000.efff0000 - 00000000.efffffff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[5] 00000001.00000000 - 00000001.07eaafff xen_platform_log xen platform: XEN|AcpiGetXsdt: 0x00000000FC012BA0 xen_platform_log xen platform: XEN|SystemProcessorInformation: ====> (0:0) xen_platform_log xen platform: XEN|SystemProcessorInformation: Manufacturer: GenuineIntel xen_platform_log xen platform: XEN|SystemProcessorInformation: APIC ID: 00 xen_platform_log xen platform: XEN|SystemProcessorInformation: PROCESSOR ID: 00 xen_platform_log xen platform: XEN|SystemProcessorInformation: <==== (0:0) xen_platform_log xen platform: XEN|SystemProcessorInformation: ====> (0:1) xen_platform_log xen platform: XEN|SystemProcessorInformation: Manufacturer: GenuineIntel xen_platform_log xen platform: XEN|SystemProcessorInformation: APIC ID: 02 xen_platform_log xen platform: XEN|SystemProcessorInformation: PROCESSOR ID: 01 xen_platform_log xen platform: XEN|SystemProcessorInformation: <==== (0:1) xen_platform_log xen platform: XEN: HYPERCALL PAGE 0 @ 00000001.03dd4000 xen_platform_log xen platform: XENFILT|DriverEntry: 8.2.0 (80) (17.09.2015) xen_platform_log xen platform: XEN: 4.6.0 (__XEN_INTERFACE_VERSION__ = 00040600) xen_platform_log xen platform: XENFILT|FdoCreate: FFFFE000CCF88C60 (ACPI\PNP0A03\0) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCEA9250 (PCI\VEN_8086&DEV_1237&SUBSYS_11001AF4&REV_02\00) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCEE2450 (PCI\VEN_8086&DEV_7000&SUBSYS_11001AF4&REV_00\08) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCED4BE0 (PCI\VEN_8086&DEV_7010&SUBSYS_11001AF4&REV_00\09) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCFC0C60 (PCI\VEN_5853&DEV_0001&SUBSYS_00015853&REV_01\10) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCFC0880 (PCI\VEN_8086&DEV_2668&SUBSYS_11001AF4&REV_01\18) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCFBFC60 (PCI\VEN_1AF4&DEV_1003&SUBSYS_00031AF4&REV_00\20) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCFBEC60 (PCI\VEN_1B36&DEV_0100&SUBSYS_11001AF4&REV_04\28) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCFBDC60 (PCI\VEN_10EC&DEV_8139&SUBSYS_11001AF4&REV_20\30) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCFBD880 (PCI\VEN_8086&DEV_2934&SUBSYS_11001AF4&REV_03\E8) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCFBC9F0 (PCI\VEN_8086&DEV_2935&SUBSYS_11001AF4&REV_03\E9) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCFBBB30 (PCI\VEN_8086&DEV_2936&SUBSYS_11001AF4&REV_03\EA) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCEA3C60 (PCI\VEN_8086&DEV_293A&SUBSYS_11001AF4&REV_03\EF) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCF04C60 (ACPI\PNP0103\0) xen_platform_log xen platform: XENFILT|DriverSetFilterState: PENDING xen_platform_log xen platform: XENFILT|DriverSetFilterState: DISABLED xen_platform_log xen platform: XENBUS|DriverEntry: 8.2.0 (80) (17.09.2015) xen_platform_log xen platform: XENFILT|PdoQueryInterface: PCI\VEN_5853&DEV_0001&SUBSYS_00015853&REV_01\10: PVDEVICE_INTERFACE (VERSION 1) xen_platform_log xen platform: XENFILT|PvdeviceSetActive: PCI\VEN_5853&DEV_0001&SUBSYS_00015853&REV_01\10 xen_platform_log xen platform: XENBUS|FdoSetFriendlyName: Xen PV Bus (0001) xen_platform_log xen platform: XENBUS|FdoCreate: FFFFE000CCEF3040 (XP0001 XENBUS) [ACTIVE] xen_platform_log xen platform: XENBUS|FdoConnectInterrupt: FFFFE000CCEF2A88: Shared LevelSensitive CPU 0:0 VECTOR b1 xen_platform_log xen platform: XENBUS|FdoConnectInterrupt: FFFFE000CCEF1E98: DeviceExclusive Latched CPU 0:0 VECTOR 50 xen_platform_log xen platform: XENBUS|FdoConnectInterrupt: FFFFE000CCEF1AC8: DeviceExclusive Latched CPU 0:1 VECTOR 50 xen_platform_log xen platform: XENBUS|FdoScan: ====> xen_platform_log xen platform: XENBUS|FdoCreateIoSpace: 00000000.f8000000 - 00000000.f8ffffff xen_platform_log xen platform: XENBUS|FdoSuspend: ====> xen_platform_log xen platform: XEN|HvmSetParam: fail1 (c0000022) xen_platform_log xen platform: SHARED_INFO: MAP XENMAPSPACE_shared_info @ 00000000.f8000000 xen_platform_log xen platform: XENBUS|FdoBalloon: ====> xen_platform_log xen platform: EVTCHN_FIFO: CONTROLBLOCK[0] @ 00000000.01019000 xen_platform_log xen platform: EVTCHN_FIFO: CONTROLBLOCK[1] @ 00000000.0109a000 xen_platform_log xen platform: XENBUS|EvtchnAbiAcquire: FIFO xen_platform_log xen platform: XENBUS|EvtchnInterruptEnable: CPU 0:0 (Vector = 80) xen_platform_log xen platform: XENBUS|EvtchnInterruptEnable: CPU 0:1 (Vector = 80) xen_platform_log xen platform: XENBUS|EvtchnInterruptEnable: CALLBACK VIA (Vector = 24) xen_platform_log xen platform: STORE: PAGE @ 00000000.feffc000 xen_platform_log xen platform: STORE: EVTCHN 1 xen_platform_log xen platform: EVTCHN_FIFO: EVENTARRAY[0] @ 00000000.0109b000 xen_platform_log xen platform: XENBUS|EvtchnFifoExpand: added ports [00000000 - 000003ff] xen_platform_log xen platform: XENBUS|PdoCreate: FFFFE000CCEA2D40 (VBD) xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 08000009 -> SUSPEND v1 SHARED_INFO v2 EVTCHN v4 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000A -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000B -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v2 RANGE_SET v1 CACHE v1 GNTTAB v2 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoCreate: FFFFE000CCEA2A20 (VIF) xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 08000009 -> SUSPEND v1 SHARED_INFO v2 EVTCHN v4 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000A -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000B -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v2 RANGE_SET v1 CACHE v1 GNTTAB v2 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoCreate: FFFFE000CCEF0D40 (IFACE) xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 08000009 -> SUSPEND v1 SHARED_INFO v2 EVTCHN v4 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000A -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000B -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v2 RANGE_SET v1 CACHE v1 GNTTAB v2 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENFILT|FdoCreate: FFFFE000CCEC7040 (PCIIDE\IDEChannel\0) xen_platform_log xen platform: XENFILT|FdoCreate: FFFFE000CCEC7430 (PCIIDE\IDEChannel\1) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE000CCEC3C60 (IDE\CdRomQEMU_QEMU_DVD-ROM_______________________2.2.____\0.1.0) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 00000000000154F0) xen_platform_log xen platform: XENBUS|SUSPEND: Count = 0 xen_platform_log xen platform: XENBUS|SUSPEND: EARLY: xenbus.sys + 0000000000008474 (FFFFE000CCEF2E30) xen_platform_log xen platform: XENBUS|SUSPEND: EARLY: xenbus.sys + 0000000000011FA8 (FFFFE000CCF1C820) xen_platform_log xen platform: XENBUS|SUSPEND: EARLY: xenbus.sys + 0000000000014D10 (FFFFE000CBDCC000) xen_platform_log xen platform: XENBUS|SUSPEND: LATE: xenbus.sys + 00000000000084C4 (FFFFE000CCEF2E30) xen_platform_log xen platform: XENBUS|SUSPEND: LATE: xenbus.sys + 0000000000014D50 (FFFFE000CBDCC000) xen_platform_log xen platform: XENBUS|SUSPEND: LATE: xenbus.sys + 000000000000E080 (FFFFE000CCEF3B10) xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 00000000000154F0) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 000000000001655C) xen_platform_log xen platform: XENBUS|RANGE_SET: RANGE SETS: xen_platform_log xen platform: XENBUS|RANGE_SET: - io_space: xen_platform_log xen platform: XENBUS|RANGE_SET: {f8001000 - f8ffffff}* xen_platform_log xen platform: XENBUS|RANGE_SET: - balloon: xen_platform_log xen platform: XENBUS|RANGE_SET: EMPTY xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 000000000001655C) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 0000000000007800) xen_platform_log xen platform: XENBUS|EVTCHN: EVENT CHANNELS: xen_platform_log xen platform: XENBUS|EVTCHN: - (0001) BY xenbus.sys + 000000000001417D ACTIVE xen_platform_log xen platform: XENBUS|EVTCHN: FIXED xen_platform_log xen platform: XENBUS|EVTCHN: Events = 17 xen_platform_log xen platform: XENBUS|EVTCHN: - (0006) BY xenbus.sys + 000000000000AC7C ACTIVE xen_platform_log xen platform: XENBUS|EVTCHN: VIRQ: Index = 1 xen_platform_log xen platform: XENBUS|EVTCHN: Events = 0 xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 0000000000007800) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 0000000000011C08) xen_platform_log xen platform: XENBUS|SHARED_INFO: Address = 00000000.f8000000 xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 0000000000011C08) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 0000000000013E64) xen_platform_log xen platform: XENBUS|STORE: Address = 00000000.feffc000 xen_platform_log xen platform: XENBUS|STORE: Events = 17 Dpcs = 1 Polls = 20 xen_platform_log xen platform: XENBUS|STORE: WATCHES: xen_platform_log xen platform: XENBUS|STORE: - (E306) ON device BY xenbus.sys + 000000000000ACCD [ACTIVE] xen_platform_log xen platform: XENBUS|STORE: - (E307) ON control/shutdown BY xenbus.sys + 000000000000AD09 [ACTIVE] xen_platform_log xen platform: XENBUS|STORE: - (E308) ON memory/target BY xenbus.sys + 000000000000AD7C [ACTIVE] xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 0000000000013E64) xen_platform_log xen platform: XEN|BUGCHECK: ====> xen_platform_log xen platform: XEN|BUGCHECK: INACCESSIBLE_BOOT_DEVICE: FFFFD001452E27F0 FFFFFFFFC0000034 0000000000000000 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: \ArcName\multi(0)disk(0)rdisk(0)partition(4) xen_platform_log xen platform: XEN|BUGCHECK: CONTEXT (FFFFD001452E1B00): xen_platform_log xen platform: XEN|BUGCHECK: - GS = 002B xen_platform_log xen platform: XEN|BUGCHECK: - FS = 0053 xen_platform_log xen platform: XEN|BUGCHECK: - ES = 002B xen_platform_log xen platform: XEN|BUGCHECK: - DS = 002B xen_platform_log xen platform: XEN|BUGCHECK: - SS = 0018 xen_platform_log xen platform: XEN|BUGCHECK: - CS = 0010 xen_platform_log xen platform: XEN|BUGCHECK: - EFLAGS = 00000086 xen_platform_log xen platform: XEN|BUGCHECK: - RDI = 00000000452E27F0 xen_platform_log xen platform: XEN|BUGCHECK: - RSI = 00000000C0000034 xen_platform_log xen platform: XEN|BUGCHECK: - RBX = 000000008EFF0A30 xen_platform_log xen platform: XEN|BUGCHECK: - RDX = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - RCX = 00000000452E1B00 xen_platform_log xen platform: XEN|BUGCHECK: - RAX = 000000000000000F xen_platform_log xen platform: XEN|BUGCHECK: - RBP = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - RIP = 000000008EFE5C42 xen_platform_log xen platform: XEN|BUGCHECK: - RSP = 00000000452E1AE0 xen_platform_log xen platform: XEN|BUGCHECK: - R8 = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - R9 = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - R10 = 0000000000000100 xen_platform_log xen platform: XEN|BUGCHECK: - R11 = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - R12 = 0000000000000003 xen_platform_log xen platform: XEN|BUGCHECK: - R13 = 000000000000007B xen_platform_log xen platform: XEN|BUGCHECK: - R14 = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - R15 = 00000000CBBFF040 xen_platform_log xen platform: XEN|BUGCHECK: STACK: xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E1FF0: (0000000000000003 000000008EFE9790 000000008EFE8F20 000000008EFEE3A0) xen.sys + 0000000000005FDD xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2040: (000000008EFF1460 00000000452E2170 0000000000000001 0000000017132EA0) ntoskrnl.exe + 00000000001F49CB xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2070: (000000008EFF1460 0000000017132EA0 0000000000000000 0000000000000000) ntoskrnl.exe + 00000000001F3CCC xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2780: (00000000452E27F0 00000000172A409D 0000000000000000 0000000000000000) ntoskrnl.exe + 000000000014E3E4 xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E27C0: (000000000000007B 00000000452E27F0 00000000C0000034 0000000000000000) ntoskrnl.exe + 0000000000163ABF xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2840: (0000000050E07FF0 0000000080000284 0000000000000001 00000000FFE17B80) ntoskrnl.exe + 00000000007C7C33 xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2A80: (00000000CBD7B040 0000000000000000 0000000000000006 0000000015D035A0) ntoskrnl.exe + 00000000007D2DBF xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2BA0: (00000000173836A0 0000000015D035A0 00000000CBBFBB18 00000000171E0700) ntoskrnl.exe + 00000000007DE931 xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2BD0: (0000000000000000 0000000015D035A0 00000000CBBFBB18 00000000171E0740) ntoskrnl.exe + 000000000057C6CA xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2C00: (00000000CBBFF040 0000000000000000 0000000000000000 00000000FFFFFFFF) ntoskrnl.exe + 00000000000E6558 xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2C60: (000000001716A180 00000000CBBFF040 00000000171E0740 00000000000000FE) ntoskrnl.exe + 00000000001533C6 xen_platform_log xen platform: XEN|BUGCHECK: 00000000452E2C90: (00000000452E3000 00000000452DD000 0000000000000000 0000000000000000) 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: <==== Issued domain 8 reboot qemu: terminating on signal 1 from pid 4167 red_channel_client_disconnect_dummy: rcc=0x7fa45abfc640 (channel=0x7fa45a860650 type=5 id=0) snd_channel_put: SndChannel=0x7fa45abf1bd0 freed red_channel_client_disconnect_dummy: rcc=0x7fa45ab70110 (channel=0x7fa45a8b1260 type=6 id=0) snd_channel_put: SndChannel=0x7fa45abe1390 freed [-- Attachment #3: W10UEFI.cfg --] [-- Type: text/plain, Size: 912 bytes --] name='W10UEFI' builder="hvm" #device_model_override="/usr/lib/xen/bin/qemu-gdb" memory=4096 bios="ovmf" vcpus=2 acpi_s3=0 acpi_s4=0 #hdtype="ahci" vif=['bridge=xenbr0,mac=00:16:3e:33:44:09'] disk=['/mnt/vm/disks/W10UEFI.disk1.xm,raw,xvda,rw','/mnt/vm/iso/Windows10pro64bit.iso,raw,xvdb,ro,cdrom'] #disk=['/mnt/vm/disks/W10.disk1.cow-sn1,qcow2,hda,rw',',raw,hdb,ro,cdrom'] boot='cd' device_model_version="qemu-xen" viridian=1 xen_platform_pci=1 vnc=0 #vncunused=1 #vnclisten="0.0.0.0" keymap="it" on_crash="destroy" vga="qxl" spice=1 spicehost='0.0.0.0' spiceport=6000 spicedisable_ticketing=1 spicevdagent=1 spice_clipboard_sharing=0 #spice_image_compression="lz4" #spice_streaming_video="off" #spice_streaming_video="all" #spice_video_codecs="gstreamer:vp8" spiceusbredirection=4 soundhw="hda" localtime=1 #usbversion=3 ms_vm_genid="generate" device_model_args=["-trace","events=/etc/xen/qemu-trace-options"] [-- Attachment #4: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-15 16:27 ` Fabio Fantoni (?) @ 2015-10-15 18:02 ` Anthony PERARD -1 siblings, 0 replies; 95+ messages in thread From: Anthony PERARD @ 2015-10-15 18:02 UTC (permalink / raw) To: Fabio Fantoni Cc: Kevin Wolf, qemu-block, Stefano Stabellini, qemu-devel, xen-devel, Paul Durrant, John Snow On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: > Il 14/10/2015 13:06, Stefano Stabellini ha scritto: > >I would suggest Fabio to avoid AHCI disks altogether and just use OVMF > >with PV disks only and Anthony's patch to libxl to avoid creating any > >IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. > > > >Would that work for you? > > Thanks for the advice, I tried it: > https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 > > I installed W10 pro 64 bit with ide disk, installed the win pv drivers and > after changed to xvdX instead hdX, is the only change needed, right? > Initial boot is ok (ovmf part about pv disks seems ok) but windows boot > fails with problem with pv drivers. > In attachment full qemu log with xen_platform trace and domU's xl cfg. > > Someone have windows domUs with ovmf and pv disks only working? If yes can > tell me the difference to understand what can be the problem please? When I worked on the PV disk implementation in OVMF, I was able to boot a Windows 8 with pv disk only. I don't have access to the guest configuration I was using, but I think one difference would be the viridian setting, I'm pretty sure I did not set it. -- Anthony PERARD ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-15 16:27 ` Fabio Fantoni (?) (?) @ 2015-10-15 18:02 ` Anthony PERARD 2015-10-16 8:32 ` Fabio Fantoni 2015-10-16 8:32 ` Fabio Fantoni -1 siblings, 2 replies; 95+ messages in thread From: Anthony PERARD @ 2015-10-15 18:02 UTC (permalink / raw) To: Fabio Fantoni Cc: Kevin Wolf, qemu-block, Stefano Stabellini, qemu-devel, xen-devel, Paul Durrant, John Snow On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: > Il 14/10/2015 13:06, Stefano Stabellini ha scritto: > >I would suggest Fabio to avoid AHCI disks altogether and just use OVMF > >with PV disks only and Anthony's patch to libxl to avoid creating any > >IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. > > > >Would that work for you? > > Thanks for the advice, I tried it: > https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 > > I installed W10 pro 64 bit with ide disk, installed the win pv drivers and > after changed to xvdX instead hdX, is the only change needed, right? > Initial boot is ok (ovmf part about pv disks seems ok) but windows boot > fails with problem with pv drivers. > In attachment full qemu log with xen_platform trace and domU's xl cfg. > > Someone have windows domUs with ovmf and pv disks only working? If yes can > tell me the difference to understand what can be the problem please? When I worked on the PV disk implementation in OVMF, I was able to boot a Windows 8 with pv disk only. I don't have access to the guest configuration I was using, but I think one difference would be the viridian setting, I'm pretty sure I did not set it. -- Anthony PERARD ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-15 18:02 ` Anthony PERARD @ 2015-10-16 8:32 ` Fabio Fantoni 2015-10-16 8:32 ` Fabio Fantoni 1 sibling, 0 replies; 95+ messages in thread From: Fabio Fantoni @ 2015-10-16 8:32 UTC (permalink / raw) To: Anthony PERARD Cc: Kevin Wolf, qemu-block, Stefano Stabellini, qemu-devel, xen-devel, Paul Durrant, John Snow [-- Attachment #1: Type: text/plain, Size: 1744 bytes --] Il 15/10/2015 20:02, Anthony PERARD ha scritto: > On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: >> Il 14/10/2015 13:06, Stefano Stabellini ha scritto: >>> I would suggest Fabio to avoid AHCI disks altogether and just use OVMF >>> with PV disks only and Anthony's patch to libxl to avoid creating any >>> IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. >>> >>> Would that work for you? >> Thanks for the advice, I tried it: >> https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 >> >> I installed W10 pro 64 bit with ide disk, installed the win pv drivers and >> after changed to xvdX instead hdX, is the only change needed, right? >> Initial boot is ok (ovmf part about pv disks seems ok) but windows boot >> fails with problem with pv drivers. >> In attachment full qemu log with xen_platform trace and domU's xl cfg. >> >> Someone have windows domUs with ovmf and pv disks only working? If yes can >> tell me the difference to understand what can be the problem please? > When I worked on the PV disk implementation in OVMF, I was able to boot > a Windows 8 with pv disk only. > > I don't have access to the guest configuration I was using, but I think one > difference would be the viridian setting, I'm pretty sure I did not set it. > I tried with viridian disabled but did the same thing, looking cdrom as latest thing before xenbug trace in qemu log I tried also to remove it but also in this case don't boot correctly, full qemu log in attachment. I don't know if is a ovmf thing to improve (like what seems in Laszlo and Kevin mails) or xen winpv drivers unexpected case, have you tried also with latest winpv builds? (for exclude regression) Thanks for any reply and sorry for my bad english. [-- Attachment #2: qemu-dm-W10UEFI.log --] [-- Type: text/plain, Size: 15579 bytes --] main_channel_link: add main channel client main_channel_handle_parsed: net test: latency 17.727000 ms, bitrate 578858111 bps (552.042113 Mbps) inputs_connect: inputs channel client create red_dispatcher_set_cursor_peer: xen_platform_log xen platform: XEN|DllInitialize: 8.2.0 (80) (17.09.2015) xen_platform_log xen platform: XEN|AcpiFindRsdp: 0x00000000000EA020 xen_platform_log xen platform: XEN|SystemGetStartOptions: TESTSIGNING NOEXECUTE=OPTIN NOVGA xen_platform_log xen platform: XEN|SystemGetVersionInformation: KERNEL: 10.0 (BUILD 10240) PLATFORM WIN32_NT (x64) xen_platform_log xen platform: XEN|SystemGetVersionInformation: SUITES: xen_platform_log xen platform: XEN|SystemGetVersionInformation: - TERMINAL xen_platform_log xen platform: XEN|SystemGetVersionInformation: - SINGLEUSERTS xen_platform_log xen platform: XEN|SystemGetVersionInformation: TYPE: WORKSTATION xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[0] 00000000.00001000 - 00000000.0009efff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[1] 00000000.00100000 - 00000000.eed94fff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[2] 00000000.eee12000 - 00000000.efe91fff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[3] 00000000.efef6000 - 00000000.effcffff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[4] 00000000.efff0000 - 00000000.efffffff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[5] 00000001.00000000 - 00000001.07eaafff xen_platform_log xen platform: XEN|AcpiGetXsdt: 0x00000000FC012BA0 xen_platform_log xen platform: XEN|SystemProcessorInformation: ====> (0:0) xen_platform_log xen platform: XEN|SystemProcessorInformation: Manufacturer: GenuineIntel xen_platform_log xen platform: XEN|SystemProcessorInformation: APIC ID: 00 xen_platform_log xen platform: XEN|SystemProcessorInformation: PROCESSOR ID: 00 xen_platform_log xen platform: XEN|SystemProcessorInformation: <==== (0:0) xen_platform_log xen platform: XEN|SystemProcessorInformation: ====> (0:1) xen_platform_log xen platform: XEN|SystemProcessorInformation: Manufacturer: GenuineIntel xen_platform_log xen platform: XEN|SystemProcessorInformation: APIC ID: 02 xen_platform_log xen platform: XEN|SystemProcessorInformation: PROCESSOR ID: 01 xen_platform_log xen platform: XEN|SystemProcessorInformation: <==== (0:1) xen_platform_log xen platform: XEN: HYPERCALL PAGE 0 @ 00000001.03dd4000 xen_platform_log xen platform: XENFILT|DriverEntry: 8.2.0 (80) (17.09.2015) xen_platform_log xen platform: XEN: 4.6.0 (__XEN_INTERFACE_VERSION__ = 00040600) xen_platform_log xen platform: XENFILT|FdoCreate: FFFFE0006B7A7C60 (ACPI\PNP0A03\0) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B786A60 (PCI\VEN_8086&DEV_1237&SUBSYS_11001AF4&REV_02\00) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7DBC60 (PCI\VEN_8086&DEV_7000&SUBSYS_11001AF4&REV_00\08) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7DB880 (PCI\VEN_8086&DEV_7010&SUBSYS_11001AF4&REV_00\09) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7DCC60 (PCI\VEN_5853&DEV_0001&SUBSYS_00015853&REV_01\10) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7DC880 (PCI\VEN_8086&DEV_2668&SUBSYS_11001AF4&REV_01\18) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7DDC60 (PCI\VEN_1AF4&DEV_1003&SUBSYS_00031AF4&REV_00\20) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7DD880 (PCI\VEN_1B36&DEV_0100&SUBSYS_11001AF4&REV_04\28) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B720B30 (PCI\VEN_10EC&DEV_8139&SUBSYS_11001AF4&REV_20\30) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7DEC60 (PCI\VEN_8086&DEV_2934&SUBSYS_11001AF4&REV_03\E8) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7DFC60 (PCI\VEN_8086&DEV_2935&SUBSYS_11001AF4&REV_03\E9) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7EEC60 (PCI\VEN_8086&DEV_2936&SUBSYS_11001AF4&REV_03\EA) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7EE880 (PCI\VEN_8086&DEV_293A&SUBSYS_11001AF4&REV_03\EF) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7EF9F0 (ACPI\PNP0103\0) xen_platform_log xen platform: XENFILT|DriverSetFilterState: PENDING xen_platform_log xen platform: XENFILT|DriverSetFilterState: DISABLED xen_platform_log xen platform: XENBUS|DriverEntry: 8.2.0 (80) (17.09.2015) xen_platform_log xen platform: XENFILT|PdoQueryInterface: PCI\VEN_5853&DEV_0001&SUBSYS_00015853&REV_01\10: PVDEVICE_INTERFACE (VERSION 1) xen_platform_log xen platform: XENFILT|PvdeviceSetActive: PCI\VEN_5853&DEV_0001&SUBSYS_00015853&REV_01\10 xen_platform_log xen platform: XENBUS|FdoSetFriendlyName: Xen PV Bus (0001) xen_platform_log xen platform: XENBUS|FdoCreate: FFFFE0006B6C8040 (XP0001 XENBUS) [ACTIVE] xen_platform_log xen platform: XENBUS|FdoConnectInterrupt: FFFFE0006B6A2A88: Shared LevelSensitive CPU 0:0 VECTOR b1 xen_platform_log xen platform: XENBUS|FdoConnectInterrupt: FFFFE0006B6E7E98: DeviceExclusive Latched CPU 0:0 VECTOR 50 xen_platform_log xen platform: XENBUS|FdoConnectInterrupt: FFFFE0006B6E7BA8: DeviceExclusive Latched CPU 0:1 VECTOR 50 xen_platform_log xen platform: XENBUS|FdoScan: ====> xen_platform_log xen platform: XENBUS|FdoCreateIoSpace: 00000000.f8000000 - 00000000.f8ffffff xen_platform_log xen platform: XENBUS|FdoSuspend: ====> xen_platform_log xen platform: XEN|HvmSetParam: fail1 (c0000022) xen_platform_log xen platform: XENBUS|FdoBalloon: ====> xen_platform_log xen platform: SHARED_INFO: MAP XENMAPSPACE_shared_info @ 00000000.f8000000 xen_platform_log xen platform: EVTCHN_FIFO: CONTROLBLOCK[0] @ 00000000.00f25000 xen_platform_log xen platform: EVTCHN_FIFO: CONTROLBLOCK[1] @ 00000000.00d26000 xen_platform_log xen platform: XENBUS|EvtchnAbiAcquire: FIFO xen_platform_log xen platform: XENBUS|EvtchnInterruptEnable: CPU 0:0 (Vector = 80) xen_platform_log xen platform: XENBUS|EvtchnInterruptEnable: CPU 0:1 (Vector = 80) xen_platform_log xen platform: XENBUS|EvtchnInterruptEnable: CALLBACK VIA (Vector = 24) xen_platform_log xen platform: STORE: PAGE @ 00000000.feffc000 xen_platform_log xen platform: STORE: EVTCHN 1 xen_platform_log xen platform: EVTCHN_FIFO: EVENTARRAY[0] @ 00000000.00d27000 xen_platform_log xen platform: XENBUS|EvtchnFifoExpand: added ports [00000000 - 000003ff] xen_platform_log xen platform: XENBUS|PdoCreate: FFFFE0006B6E6D40 (VBD) xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 08000009 -> SUSPEND v1 SHARED_INFO v2 EVTCHN v4 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000A -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000B -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v2 RANGE_SET v1 CACHE v1 GNTTAB v2 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoCreate: FFFFE0006B6E6A20 (VIF) xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 08000009 -> SUSPEND v1 SHARED_INFO v2 EVTCHN v4 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000A -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000B -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v2 RANGE_SET v1 CACHE v1 GNTTAB v2 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoCreate: FFFFE0006B6E4D40 (IFACE) xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 08000009 -> SUSPEND v1 SHARED_INFO v2 EVTCHN v4 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000A -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000B -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v2 RANGE_SET v1 CACHE v1 GNTTAB v2 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENFILT|FdoCreate: FFFFE0006B6C4C60 (PCIIDE\IDEChannel\0) xen_platform_log xen platform: XENFILT|FdoCreate: FFFFE0006B6A5C60 (PCIIDE\IDEChannel\1) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 00000000000154F0) xen_platform_log xen platform: XENBUS|SUSPEND: Count = 0 xen_platform_log xen platform: XENBUS|SUSPEND: EARLY: xenbus.sys + 0000000000008474 (FFFFE0006B6A2E30) xen_platform_log xen platform: XENBUS|SUSPEND: EARLY: xenbus.sys + 0000000000011FA8 (FFFFE0006B7DA920) xen_platform_log xen platform: XENBUS|SUSPEND: EARLY: xenbus.sys + 0000000000014D10 (FFFFE0006A5CC000) xen_platform_log xen platform: XENBUS|SUSPEND: LATE: xenbus.sys + 00000000000084C4 (FFFFE0006B6A2E30) xen_platform_log xen platform: XENBUS|SUSPEND: LATE: xenbus.sys + 0000000000014D50 (FFFFE0006A5CC000) xen_platform_log xen platform: XENBUS|SUSPEND: LATE: xenbus.sys + 000000000000E080 (FFFFE0006B6C8320) xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 00000000000154F0) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 000000000001655C) xen_platform_log xen platform: XENBUS|RANGE_SET: RANGE SETS: xen_platform_log xen platform: XENBUS|RANGE_SET: - io_space: xen_platform_log xen platform: XENBUS|RANGE_SET: {f8001000 - f8ffffff}* xen_platform_log xen platform: XENBUS|RANGE_SET: - balloon: xen_platform_log xen platform: XENBUS|RANGE_SET: EMPTY xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 000000000001655C) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 0000000000007800) xen_platform_log xen platform: XENBUS|EVTCHN: EVENT CHANNELS: xen_platform_log xen platform: XENBUS|EVTCHN: - (0001) BY xenbus.sys + 000000000001417D ACTIVE xen_platform_log xen platform: XENBUS|EVTCHN: FIXED xen_platform_log xen platform: XENBUS|EVTCHN: Events = 17 xen_platform_log xen platform: XENBUS|EVTCHN: - (0006) BY xenbus.sys + 000000000000AC7C ACTIVE xen_platform_log xen platform: XENBUS|EVTCHN: VIRQ: Index = 1 xen_platform_log xen platform: XENBUS|EVTCHN: Events = 0 xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 0000000000007800) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 0000000000011C08) xen_platform_log xen platform: XENBUS|SHARED_INFO: Address = 00000000.f8000000 xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 0000000000011C08) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 0000000000013E64) xen_platform_log xen platform: XENBUS|STORE: Address = 00000000.feffc000 xen_platform_log xen platform: XENBUS|STORE: Events = 17 Dpcs = 1 Polls = 17 xen_platform_log xen platform: XENBUS|STORE: WATCHES: xen_platform_log xen platform: XENBUS|STORE: - (FDE9) ON device BY xenbus.sys + 000000000000ACCD [ACTIVE] xen_platform_log xen platform: XENBUS|STORE: - (FDEA) ON control/shutdown BY xenbus.sys + 000000000000AD09 [ACTIVE] xen_platform_log xen platform: XENBUS|STORE: - (FDEB) ON memory/target BY xenbus.sys + 000000000000AD7C [ACTIVE] xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 0000000000013E64) xen_platform_log xen platform: XEN|BUGCHECK: ====> xen_platform_log xen platform: XEN|BUGCHECK: INACCESSIBLE_BOOT_DEVICE: FFFFD00128AE27F0 FFFFFFFFC0000034 0000000000000000 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: \ArcName\multi(0)disk(0)rdisk(0)partition(4) xen_platform_log xen platform: XEN|BUGCHECK: CONTEXT (FFFFD00128AE1B00): xen_platform_log xen platform: XEN|BUGCHECK: - GS = 002B xen_platform_log xen platform: XEN|BUGCHECK: - FS = 0053 xen_platform_log xen platform: XEN|BUGCHECK: - ES = 002B xen_platform_log xen platform: XEN|BUGCHECK: - DS = 002B xen_platform_log xen platform: XEN|BUGCHECK: - SS = 0018 xen_platform_log xen platform: XEN|BUGCHECK: - CS = 0010 xen_platform_log xen platform: XEN|BUGCHECK: - EFLAGS = 00000086 xen_platform_log xen platform: XEN|BUGCHECK: - RDI = 0000000028AE27F0 xen_platform_log xen platform: XEN|BUGCHECK: - RSI = 00000000C0000034 xen_platform_log xen platform: XEN|BUGCHECK: - RBX = 000000000D010A30 xen_platform_log xen platform: XEN|BUGCHECK: - RDX = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - RCX = 0000000028AE1B00 xen_platform_log xen platform: XEN|BUGCHECK: - RAX = 000000000000000F xen_platform_log xen platform: XEN|BUGCHECK: - RBP = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - RIP = 000000000D005C42 xen_platform_log xen platform: XEN|BUGCHECK: - RSP = 0000000028AE1AE0 xen_platform_log xen platform: XEN|BUGCHECK: - R8 = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - R9 = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - R10 = 0000000000000100 xen_platform_log xen platform: XEN|BUGCHECK: - R11 = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - R12 = 0000000000000003 xen_platform_log xen platform: XEN|BUGCHECK: - R13 = 000000000000007B xen_platform_log xen platform: XEN|BUGCHECK: - R14 = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - R15 = 000000006A400840 xen_platform_log xen platform: XEN|BUGCHECK: STACK: xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE1FF0: (0000000000000003 000000000D009790 000000000D008F20 000000000D00E3A0) xen.sys + 0000000000005FDD xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2040: (000000000D011460 0000000028AE2170 0000000000000001 00000000DA5ADEA0) ntoskrnl.exe + 00000000001F49CB xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2070: (000000000D011460 00000000DA5ADEA0 0000000000000000 0000000000000000) ntoskrnl.exe + 00000000001F3CCC xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2780: (0000000028AE27F0 00000000DA71F09D 0000000000000000 0000000000000000) ntoskrnl.exe + 000000000014E3E4 xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE27C0: (000000000000007B 0000000028AE27F0 00000000C0000034 0000000000000000) ntoskrnl.exe + 0000000000163ABF xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2840: (00000000B8008750 0000000080000284 0000000000000001 00000000FFE17B80) ntoskrnl.exe + 00000000007C7C33 xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2A80: (000000006A57B040 0000000000000000 0000000000000006 00000000D8FFDD30) ntoskrnl.exe + 00000000007D2DBF xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2BA0: (00000000DA7FE6A0 00000000D8FFDD30 000000006A3F8B18 00000000DA65B700) ntoskrnl.exe + 00000000007DE931 xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2BD0: (0000000000000000 00000000D8FFDD30 000000006A3F8B18 00000000DA65B740) ntoskrnl.exe + 000000000057C6CA xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2C00: (000000006A400840 0000000000000000 0000000000000000 00000000FFFFFFFF) ntoskrnl.exe + 00000000000E6558 xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2C60: (00000000DA5E5180 000000006A400840 00000000DA65B740 00000000000000FE) ntoskrnl.exe + 00000000001533C6 xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2C90: (0000000028AE3000 0000000028ADD000 0000000000000000 0000000000000000) 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: <==== Issued domain 3 reboot qemu: terminating on signal 1 from pid 1959 red_channel_client_disconnect_dummy: rcc=0x7eff5ff298e0 (channel=0x7eff5fbf36e0 type=5 id=0) snd_channel_put: SndChannel=0x7eff5ff1ff70 freed red_channel_client_disconnect_dummy: rcc=0x7eff5ff1bd30 (channel=0x7eff5fbcc470 type=6 id=0) snd_channel_put: SndChannel=0x7eff5ff0b4f0 freed [-- Attachment #3: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-15 18:02 ` Anthony PERARD 2015-10-16 8:32 ` Fabio Fantoni @ 2015-10-16 8:32 ` Fabio Fantoni 2015-10-16 10:13 ` Anthony PERARD 1 sibling, 1 reply; 95+ messages in thread From: Fabio Fantoni @ 2015-10-16 8:32 UTC (permalink / raw) To: Anthony PERARD Cc: Kevin Wolf, qemu-block, Stefano Stabellini, qemu-devel, xen-devel, Paul Durrant, John Snow [-- Attachment #1: Type: text/plain, Size: 1744 bytes --] Il 15/10/2015 20:02, Anthony PERARD ha scritto: > On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: >> Il 14/10/2015 13:06, Stefano Stabellini ha scritto: >>> I would suggest Fabio to avoid AHCI disks altogether and just use OVMF >>> with PV disks only and Anthony's patch to libxl to avoid creating any >>> IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. >>> >>> Would that work for you? >> Thanks for the advice, I tried it: >> https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 >> >> I installed W10 pro 64 bit with ide disk, installed the win pv drivers and >> after changed to xvdX instead hdX, is the only change needed, right? >> Initial boot is ok (ovmf part about pv disks seems ok) but windows boot >> fails with problem with pv drivers. >> In attachment full qemu log with xen_platform trace and domU's xl cfg. >> >> Someone have windows domUs with ovmf and pv disks only working? If yes can >> tell me the difference to understand what can be the problem please? > When I worked on the PV disk implementation in OVMF, I was able to boot > a Windows 8 with pv disk only. > > I don't have access to the guest configuration I was using, but I think one > difference would be the viridian setting, I'm pretty sure I did not set it. > I tried with viridian disabled but did the same thing, looking cdrom as latest thing before xenbug trace in qemu log I tried also to remove it but also in this case don't boot correctly, full qemu log in attachment. I don't know if is a ovmf thing to improve (like what seems in Laszlo and Kevin mails) or xen winpv drivers unexpected case, have you tried also with latest winpv builds? (for exclude regression) Thanks for any reply and sorry for my bad english. [-- Attachment #2: qemu-dm-W10UEFI.log --] [-- Type: text/plain, Size: 15579 bytes --] main_channel_link: add main channel client main_channel_handle_parsed: net test: latency 17.727000 ms, bitrate 578858111 bps (552.042113 Mbps) inputs_connect: inputs channel client create red_dispatcher_set_cursor_peer: xen_platform_log xen platform: XEN|DllInitialize: 8.2.0 (80) (17.09.2015) xen_platform_log xen platform: XEN|AcpiFindRsdp: 0x00000000000EA020 xen_platform_log xen platform: XEN|SystemGetStartOptions: TESTSIGNING NOEXECUTE=OPTIN NOVGA xen_platform_log xen platform: XEN|SystemGetVersionInformation: KERNEL: 10.0 (BUILD 10240) PLATFORM WIN32_NT (x64) xen_platform_log xen platform: XEN|SystemGetVersionInformation: SUITES: xen_platform_log xen platform: XEN|SystemGetVersionInformation: - TERMINAL xen_platform_log xen platform: XEN|SystemGetVersionInformation: - SINGLEUSERTS xen_platform_log xen platform: XEN|SystemGetVersionInformation: TYPE: WORKSTATION xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[0] 00000000.00001000 - 00000000.0009efff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[1] 00000000.00100000 - 00000000.eed94fff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[2] 00000000.eee12000 - 00000000.efe91fff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[3] 00000000.efef6000 - 00000000.effcffff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[4] 00000000.efff0000 - 00000000.efffffff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[5] 00000001.00000000 - 00000001.07eaafff xen_platform_log xen platform: XEN|AcpiGetXsdt: 0x00000000FC012BA0 xen_platform_log xen platform: XEN|SystemProcessorInformation: ====> (0:0) xen_platform_log xen platform: XEN|SystemProcessorInformation: Manufacturer: GenuineIntel xen_platform_log xen platform: XEN|SystemProcessorInformation: APIC ID: 00 xen_platform_log xen platform: XEN|SystemProcessorInformation: PROCESSOR ID: 00 xen_platform_log xen platform: XEN|SystemProcessorInformation: <==== (0:0) xen_platform_log xen platform: XEN|SystemProcessorInformation: ====> (0:1) xen_platform_log xen platform: XEN|SystemProcessorInformation: Manufacturer: GenuineIntel xen_platform_log xen platform: XEN|SystemProcessorInformation: APIC ID: 02 xen_platform_log xen platform: XEN|SystemProcessorInformation: PROCESSOR ID: 01 xen_platform_log xen platform: XEN|SystemProcessorInformation: <==== (0:1) xen_platform_log xen platform: XEN: HYPERCALL PAGE 0 @ 00000001.03dd4000 xen_platform_log xen platform: XENFILT|DriverEntry: 8.2.0 (80) (17.09.2015) xen_platform_log xen platform: XEN: 4.6.0 (__XEN_INTERFACE_VERSION__ = 00040600) xen_platform_log xen platform: XENFILT|FdoCreate: FFFFE0006B7A7C60 (ACPI\PNP0A03\0) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B786A60 (PCI\VEN_8086&DEV_1237&SUBSYS_11001AF4&REV_02\00) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7DBC60 (PCI\VEN_8086&DEV_7000&SUBSYS_11001AF4&REV_00\08) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7DB880 (PCI\VEN_8086&DEV_7010&SUBSYS_11001AF4&REV_00\09) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7DCC60 (PCI\VEN_5853&DEV_0001&SUBSYS_00015853&REV_01\10) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7DC880 (PCI\VEN_8086&DEV_2668&SUBSYS_11001AF4&REV_01\18) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7DDC60 (PCI\VEN_1AF4&DEV_1003&SUBSYS_00031AF4&REV_00\20) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7DD880 (PCI\VEN_1B36&DEV_0100&SUBSYS_11001AF4&REV_04\28) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B720B30 (PCI\VEN_10EC&DEV_8139&SUBSYS_11001AF4&REV_20\30) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7DEC60 (PCI\VEN_8086&DEV_2934&SUBSYS_11001AF4&REV_03\E8) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7DFC60 (PCI\VEN_8086&DEV_2935&SUBSYS_11001AF4&REV_03\E9) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7EEC60 (PCI\VEN_8086&DEV_2936&SUBSYS_11001AF4&REV_03\EA) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7EE880 (PCI\VEN_8086&DEV_293A&SUBSYS_11001AF4&REV_03\EF) xen_platform_log xen platform: XENFILT|PdoCreate: FFFFE0006B7EF9F0 (ACPI\PNP0103\0) xen_platform_log xen platform: XENFILT|DriverSetFilterState: PENDING xen_platform_log xen platform: XENFILT|DriverSetFilterState: DISABLED xen_platform_log xen platform: XENBUS|DriverEntry: 8.2.0 (80) (17.09.2015) xen_platform_log xen platform: XENFILT|PdoQueryInterface: PCI\VEN_5853&DEV_0001&SUBSYS_00015853&REV_01\10: PVDEVICE_INTERFACE (VERSION 1) xen_platform_log xen platform: XENFILT|PvdeviceSetActive: PCI\VEN_5853&DEV_0001&SUBSYS_00015853&REV_01\10 xen_platform_log xen platform: XENBUS|FdoSetFriendlyName: Xen PV Bus (0001) xen_platform_log xen platform: XENBUS|FdoCreate: FFFFE0006B6C8040 (XP0001 XENBUS) [ACTIVE] xen_platform_log xen platform: XENBUS|FdoConnectInterrupt: FFFFE0006B6A2A88: Shared LevelSensitive CPU 0:0 VECTOR b1 xen_platform_log xen platform: XENBUS|FdoConnectInterrupt: FFFFE0006B6E7E98: DeviceExclusive Latched CPU 0:0 VECTOR 50 xen_platform_log xen platform: XENBUS|FdoConnectInterrupt: FFFFE0006B6E7BA8: DeviceExclusive Latched CPU 0:1 VECTOR 50 xen_platform_log xen platform: XENBUS|FdoScan: ====> xen_platform_log xen platform: XENBUS|FdoCreateIoSpace: 00000000.f8000000 - 00000000.f8ffffff xen_platform_log xen platform: XENBUS|FdoSuspend: ====> xen_platform_log xen platform: XEN|HvmSetParam: fail1 (c0000022) xen_platform_log xen platform: XENBUS|FdoBalloon: ====> xen_platform_log xen platform: SHARED_INFO: MAP XENMAPSPACE_shared_info @ 00000000.f8000000 xen_platform_log xen platform: EVTCHN_FIFO: CONTROLBLOCK[0] @ 00000000.00f25000 xen_platform_log xen platform: EVTCHN_FIFO: CONTROLBLOCK[1] @ 00000000.00d26000 xen_platform_log xen platform: XENBUS|EvtchnAbiAcquire: FIFO xen_platform_log xen platform: XENBUS|EvtchnInterruptEnable: CPU 0:0 (Vector = 80) xen_platform_log xen platform: XENBUS|EvtchnInterruptEnable: CPU 0:1 (Vector = 80) xen_platform_log xen platform: XENBUS|EvtchnInterruptEnable: CALLBACK VIA (Vector = 24) xen_platform_log xen platform: STORE: PAGE @ 00000000.feffc000 xen_platform_log xen platform: STORE: EVTCHN 1 xen_platform_log xen platform: EVTCHN_FIFO: EVENTARRAY[0] @ 00000000.00d27000 xen_platform_log xen platform: XENBUS|EvtchnFifoExpand: added ports [00000000 - 000003ff] xen_platform_log xen platform: XENBUS|PdoCreate: FFFFE0006B6E6D40 (VBD) xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 08000009 -> SUSPEND v1 SHARED_INFO v2 EVTCHN v4 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000A -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000B -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v2 RANGE_SET v1 CACHE v1 GNTTAB v2 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoCreate: FFFFE0006B6E6A20 (VIF) xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 08000009 -> SUSPEND v1 SHARED_INFO v2 EVTCHN v4 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000A -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000B -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v2 RANGE_SET v1 CACHE v1 GNTTAB v2 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoCreate: FFFFE0006B6E4D40 (IFACE) xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 08000009 -> SUSPEND v1 SHARED_INFO v2 EVTCHN v4 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000A -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v1 RANGE_SET v1 CACHE v1 GNTTAB v1 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENBUS|PdoDumpRevisions: 0800000B -> SUSPEND v1 SHARED_INFO v2 EVTCHN v5 DEBUG v1 STORE v2 RANGE_SET v1 CACHE v1 GNTTAB v2 UNPLUG v1 EMULATED v1 xen_platform_log xen platform: XENFILT|FdoCreate: FFFFE0006B6C4C60 (PCIIDE\IDEChannel\0) xen_platform_log xen platform: XENFILT|FdoCreate: FFFFE0006B6A5C60 (PCIIDE\IDEChannel\1) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 00000000000154F0) xen_platform_log xen platform: XENBUS|SUSPEND: Count = 0 xen_platform_log xen platform: XENBUS|SUSPEND: EARLY: xenbus.sys + 0000000000008474 (FFFFE0006B6A2E30) xen_platform_log xen platform: XENBUS|SUSPEND: EARLY: xenbus.sys + 0000000000011FA8 (FFFFE0006B7DA920) xen_platform_log xen platform: XENBUS|SUSPEND: EARLY: xenbus.sys + 0000000000014D10 (FFFFE0006A5CC000) xen_platform_log xen platform: XENBUS|SUSPEND: LATE: xenbus.sys + 00000000000084C4 (FFFFE0006B6A2E30) xen_platform_log xen platform: XENBUS|SUSPEND: LATE: xenbus.sys + 0000000000014D50 (FFFFE0006A5CC000) xen_platform_log xen platform: XENBUS|SUSPEND: LATE: xenbus.sys + 000000000000E080 (FFFFE0006B6C8320) xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 00000000000154F0) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 000000000001655C) xen_platform_log xen platform: XENBUS|RANGE_SET: RANGE SETS: xen_platform_log xen platform: XENBUS|RANGE_SET: - io_space: xen_platform_log xen platform: XENBUS|RANGE_SET: {f8001000 - f8ffffff}* xen_platform_log xen platform: XENBUS|RANGE_SET: - balloon: xen_platform_log xen platform: XENBUS|RANGE_SET: EMPTY xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 000000000001655C) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 0000000000007800) xen_platform_log xen platform: XENBUS|EVTCHN: EVENT CHANNELS: xen_platform_log xen platform: XENBUS|EVTCHN: - (0001) BY xenbus.sys + 000000000001417D ACTIVE xen_platform_log xen platform: XENBUS|EVTCHN: FIXED xen_platform_log xen platform: XENBUS|EVTCHN: Events = 17 xen_platform_log xen platform: XENBUS|EVTCHN: - (0006) BY xenbus.sys + 000000000000AC7C ACTIVE xen_platform_log xen platform: XENBUS|EVTCHN: VIRQ: Index = 1 xen_platform_log xen platform: XENBUS|EVTCHN: Events = 0 xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 0000000000007800) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 0000000000011C08) xen_platform_log xen platform: XENBUS|SHARED_INFO: Address = 00000000.f8000000 xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 0000000000011C08) xen_platform_log xen platform: XEN|DEBUG: ====> (xenbus.sys + 0000000000013E64) xen_platform_log xen platform: XENBUS|STORE: Address = 00000000.feffc000 xen_platform_log xen platform: XENBUS|STORE: Events = 17 Dpcs = 1 Polls = 17 xen_platform_log xen platform: XENBUS|STORE: WATCHES: xen_platform_log xen platform: XENBUS|STORE: - (FDE9) ON device BY xenbus.sys + 000000000000ACCD [ACTIVE] xen_platform_log xen platform: XENBUS|STORE: - (FDEA) ON control/shutdown BY xenbus.sys + 000000000000AD09 [ACTIVE] xen_platform_log xen platform: XENBUS|STORE: - (FDEB) ON memory/target BY xenbus.sys + 000000000000AD7C [ACTIVE] xen_platform_log xen platform: XEN|DEBUG: <==== (xenbus.sys + 0000000000013E64) xen_platform_log xen platform: XEN|BUGCHECK: ====> xen_platform_log xen platform: XEN|BUGCHECK: INACCESSIBLE_BOOT_DEVICE: FFFFD00128AE27F0 FFFFFFFFC0000034 0000000000000000 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: \ArcName\multi(0)disk(0)rdisk(0)partition(4) xen_platform_log xen platform: XEN|BUGCHECK: CONTEXT (FFFFD00128AE1B00): xen_platform_log xen platform: XEN|BUGCHECK: - GS = 002B xen_platform_log xen platform: XEN|BUGCHECK: - FS = 0053 xen_platform_log xen platform: XEN|BUGCHECK: - ES = 002B xen_platform_log xen platform: XEN|BUGCHECK: - DS = 002B xen_platform_log xen platform: XEN|BUGCHECK: - SS = 0018 xen_platform_log xen platform: XEN|BUGCHECK: - CS = 0010 xen_platform_log xen platform: XEN|BUGCHECK: - EFLAGS = 00000086 xen_platform_log xen platform: XEN|BUGCHECK: - RDI = 0000000028AE27F0 xen_platform_log xen platform: XEN|BUGCHECK: - RSI = 00000000C0000034 xen_platform_log xen platform: XEN|BUGCHECK: - RBX = 000000000D010A30 xen_platform_log xen platform: XEN|BUGCHECK: - RDX = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - RCX = 0000000028AE1B00 xen_platform_log xen platform: XEN|BUGCHECK: - RAX = 000000000000000F xen_platform_log xen platform: XEN|BUGCHECK: - RBP = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - RIP = 000000000D005C42 xen_platform_log xen platform: XEN|BUGCHECK: - RSP = 0000000028AE1AE0 xen_platform_log xen platform: XEN|BUGCHECK: - R8 = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - R9 = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - R10 = 0000000000000100 xen_platform_log xen platform: XEN|BUGCHECK: - R11 = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - R12 = 0000000000000003 xen_platform_log xen platform: XEN|BUGCHECK: - R13 = 000000000000007B xen_platform_log xen platform: XEN|BUGCHECK: - R14 = 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: - R15 = 000000006A400840 xen_platform_log xen platform: XEN|BUGCHECK: STACK: xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE1FF0: (0000000000000003 000000000D009790 000000000D008F20 000000000D00E3A0) xen.sys + 0000000000005FDD xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2040: (000000000D011460 0000000028AE2170 0000000000000001 00000000DA5ADEA0) ntoskrnl.exe + 00000000001F49CB xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2070: (000000000D011460 00000000DA5ADEA0 0000000000000000 0000000000000000) ntoskrnl.exe + 00000000001F3CCC xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2780: (0000000028AE27F0 00000000DA71F09D 0000000000000000 0000000000000000) ntoskrnl.exe + 000000000014E3E4 xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE27C0: (000000000000007B 0000000028AE27F0 00000000C0000034 0000000000000000) ntoskrnl.exe + 0000000000163ABF xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2840: (00000000B8008750 0000000080000284 0000000000000001 00000000FFE17B80) ntoskrnl.exe + 00000000007C7C33 xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2A80: (000000006A57B040 0000000000000000 0000000000000006 00000000D8FFDD30) ntoskrnl.exe + 00000000007D2DBF xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2BA0: (00000000DA7FE6A0 00000000D8FFDD30 000000006A3F8B18 00000000DA65B700) ntoskrnl.exe + 00000000007DE931 xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2BD0: (0000000000000000 00000000D8FFDD30 000000006A3F8B18 00000000DA65B740) ntoskrnl.exe + 000000000057C6CA xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2C00: (000000006A400840 0000000000000000 0000000000000000 00000000FFFFFFFF) ntoskrnl.exe + 00000000000E6558 xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2C60: (00000000DA5E5180 000000006A400840 00000000DA65B740 00000000000000FE) ntoskrnl.exe + 00000000001533C6 xen_platform_log xen platform: XEN|BUGCHECK: 0000000028AE2C90: (0000000028AE3000 0000000028ADD000 0000000000000000 0000000000000000) 0000000000000000 xen_platform_log xen platform: XEN|BUGCHECK: <==== Issued domain 3 reboot qemu: terminating on signal 1 from pid 1959 red_channel_client_disconnect_dummy: rcc=0x7eff5ff298e0 (channel=0x7eff5fbf36e0 type=5 id=0) snd_channel_put: SndChannel=0x7eff5ff1ff70 freed red_channel_client_disconnect_dummy: rcc=0x7eff5ff1bd30 (channel=0x7eff5fbcc470 type=6 id=0) snd_channel_put: SndChannel=0x7eff5ff0b4f0 freed ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 8:32 ` Fabio Fantoni @ 2015-10-16 10:13 ` Anthony PERARD 2015-10-16 10:23 ` Fabio Fantoni 2015-10-16 10:23 ` Fabio Fantoni 0 siblings, 2 replies; 95+ messages in thread From: Anthony PERARD @ 2015-10-16 10:13 UTC (permalink / raw) To: Fabio Fantoni Cc: Kevin Wolf, qemu-block, Stefano Stabellini, qemu-devel, xen-devel, Paul Durrant, John Snow On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote: > Il 15/10/2015 20:02, Anthony PERARD ha scritto: > >On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: > >>Il 14/10/2015 13:06, Stefano Stabellini ha scritto: > >>>I would suggest Fabio to avoid AHCI disks altogether and just use OVMF > >>>with PV disks only and Anthony's patch to libxl to avoid creating any > >>>IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. > >>> > >>>Would that work for you? > >>Thanks for the advice, I tried it: > >>https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 > >> > >>I installed W10 pro 64 bit with ide disk, installed the win pv drivers and > >>after changed to xvdX instead hdX, is the only change needed, right? > >>Initial boot is ok (ovmf part about pv disks seems ok) but windows boot > >>fails with problem with pv drivers. > >>In attachment full qemu log with xen_platform trace and domU's xl cfg. > >> > >>Someone have windows domUs with ovmf and pv disks only working? If yes can > >>tell me the difference to understand what can be the problem please? > >When I worked on the PV disk implementation in OVMF, I was able to boot > >a Windows 8 with pv disk only. > > > >I don't have access to the guest configuration I was using, but I think one > >difference would be the viridian setting, I'm pretty sure I did not set it. > > > I tried with viridian disabled but did the same thing, looking cdrom as > latest thing before xenbug trace in qemu log I tried also to remove it but > also in this case don't boot correctly, full qemu log in attachment. > I don't know if is a ovmf thing to improve (like what seems in Laszlo and > Kevin mails) or xen winpv drivers unexpected case, have you tried also with > latest winpv builds? (for exclude regression) No, I did not tried the latest winpv drivers. Sorry I can help much more that that. When I install this win8 guest tried to boot it with pv drivers only, that was more than a year ago. I have not check if it's still working. (Also I can not try anything more recent, right now.) -- Anthony PERARD ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 10:13 ` Anthony PERARD @ 2015-10-16 10:23 ` Fabio Fantoni 2015-10-16 10:47 ` Stefano Stabellini 2015-10-16 10:47 ` Stefano Stabellini 2015-10-16 10:23 ` Fabio Fantoni 1 sibling, 2 replies; 95+ messages in thread From: Fabio Fantoni @ 2015-10-16 10:23 UTC (permalink / raw) To: Anthony PERARD Cc: Kevin Wolf, qemu-block, Stefano Stabellini, qemu-devel, xen-devel, Paul Durrant, John Snow Il 16/10/2015 12:13, Anthony PERARD ha scritto: > On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote: >> Il 15/10/2015 20:02, Anthony PERARD ha scritto: >>> On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: >>>> Il 14/10/2015 13:06, Stefano Stabellini ha scritto: >>>>> I would suggest Fabio to avoid AHCI disks altogether and just use OVMF >>>>> with PV disks only and Anthony's patch to libxl to avoid creating any >>>>> IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. >>>>> >>>>> Would that work for you? >>>> Thanks for the advice, I tried it: >>>> https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 >>>> >>>> I installed W10 pro 64 bit with ide disk, installed the win pv drivers and >>>> after changed to xvdX instead hdX, is the only change needed, right? >>>> Initial boot is ok (ovmf part about pv disks seems ok) but windows boot >>>> fails with problem with pv drivers. >>>> In attachment full qemu log with xen_platform trace and domU's xl cfg. >>>> >>>> Someone have windows domUs with ovmf and pv disks only working? If yes can >>>> tell me the difference to understand what can be the problem please? >>> When I worked on the PV disk implementation in OVMF, I was able to boot >>> a Windows 8 with pv disk only. >>> >>> I don't have access to the guest configuration I was using, but I think one >>> difference would be the viridian setting, I'm pretty sure I did not set it. >>> >> I tried with viridian disabled but did the same thing, looking cdrom as >> latest thing before xenbug trace in qemu log I tried also to remove it but >> also in this case don't boot correctly, full qemu log in attachment. >> I don't know if is a ovmf thing to improve (like what seems in Laszlo and >> Kevin mails) or xen winpv drivers unexpected case, have you tried also with >> latest winpv builds? (for exclude regression) > No, I did not tried the latest winpv drivers. > > Sorry I can help much more that that. When I install this win8 guest tried > to boot it with pv drivers only, that was more than a year ago. I have not > check if it's still working. (Also I can not try anything more recent, > right now.) > I did many other tests, retrying with ide first boot working but show pv devices not working, I did another reboot (with ide) and pv devices was working, after I retried with pv (xvdX) and boot correctly. After other tests I found that with empty cdrom device (required for xl cd-insert/cd-eject) boot stop at start (tianocore image), same result with ide instead. From xl cfg: disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom'] With seabios domU boot also with empty cdrom. In qemu log I found only these that can be related: > xen be: qdisk-51728: error: Could not open image: No such file or > directory > xen be: qdisk-51728: initialise() failed And latest xl dmesg line is: > (d1) Invoking OVMF ... If you need more informations/test tell me and I'll post them. Thanks for any reply and sorry for my bad english. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 10:23 ` Fabio Fantoni @ 2015-10-16 10:47 ` Stefano Stabellini 2015-10-16 10:47 ` Stefano Stabellini 1 sibling, 0 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-16 10:47 UTC (permalink / raw) To: Fabio Fantoni Cc: Kevin Wolf, qemu-block, Stefano Stabellini, qemu-devel, xen-devel, Paul Durrant, Anthony PERARD, John Snow On Fri, 16 Oct 2015, Fabio Fantoni wrote: > Il 16/10/2015 12:13, Anthony PERARD ha scritto: > > On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote: > > > Il 15/10/2015 20:02, Anthony PERARD ha scritto: > > > > On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: > > > > > Il 14/10/2015 13:06, Stefano Stabellini ha scritto: > > > > > > I would suggest Fabio to avoid AHCI disks altogether and just use > > > > > > OVMF > > > > > > with PV disks only and Anthony's patch to libxl to avoid creating > > > > > > any > > > > > > IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. > > > > > > > > > > > > Would that work for you? > > > > > Thanks for the advice, I tried it: > > > > > https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 > > > > > > > > > > I installed W10 pro 64 bit with ide disk, installed the win pv drivers > > > > > and > > > > > after changed to xvdX instead hdX, is the only change needed, right? > > > > > Initial boot is ok (ovmf part about pv disks seems ok) but windows > > > > > boot > > > > > fails with problem with pv drivers. > > > > > In attachment full qemu log with xen_platform trace and domU's xl cfg. > > > > > > > > > > Someone have windows domUs with ovmf and pv disks only working? If yes > > > > > can > > > > > tell me the difference to understand what can be the problem please? > > > > When I worked on the PV disk implementation in OVMF, I was able to boot > > > > a Windows 8 with pv disk only. > > > > > > > > I don't have access to the guest configuration I was using, but I think > > > > one > > > > difference would be the viridian setting, I'm pretty sure I did not set > > > > it. > > > > > > > I tried with viridian disabled but did the same thing, looking cdrom as > > > latest thing before xenbug trace in qemu log I tried also to remove it but > > > also in this case don't boot correctly, full qemu log in attachment. > > > I don't know if is a ovmf thing to improve (like what seems in Laszlo and > > > Kevin mails) or xen winpv drivers unexpected case, have you tried also > > > with > > > latest winpv builds? (for exclude regression) > > No, I did not tried the latest winpv drivers. > > > > Sorry I can help much more that that. When I install this win8 guest tried > > to boot it with pv drivers only, that was more than a year ago. I have not > > check if it's still working. (Also I can not try anything more recent, > > right now.) > > > > I did many other tests, retrying with ide first boot working but show pv > devices not working, I did another reboot (with ide) and pv devices was > working, after I retried with pv (xvdX) and boot correctly. > After other tests I found that with empty cdrom device (required for xl > cd-insert/cd-eject) boot stop at start (tianocore image), same result with ide > instead. > From xl cfg: > disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom'] > With seabios domU boot also with empty cdrom. > In qemu log I found only these that can be related: > > xen be: qdisk-51728: error: Could not open image: No such file or directory > > xen be: qdisk-51728: initialise() failed > And latest xl dmesg line is: > > (d1) Invoking OVMF ... > > If you need more informations/test tell me and I'll post them. Are you saying that without any cdrom drives, it works correctly? ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 10:23 ` Fabio Fantoni 2015-10-16 10:47 ` Stefano Stabellini @ 2015-10-16 10:47 ` Stefano Stabellini 2015-10-16 11:34 ` Fabio Fantoni 2015-10-16 11:34 ` Fabio Fantoni 1 sibling, 2 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-16 10:47 UTC (permalink / raw) To: Fabio Fantoni Cc: Kevin Wolf, qemu-block, Stefano Stabellini, qemu-devel, xen-devel, Paul Durrant, Anthony PERARD, John Snow On Fri, 16 Oct 2015, Fabio Fantoni wrote: > Il 16/10/2015 12:13, Anthony PERARD ha scritto: > > On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote: > > > Il 15/10/2015 20:02, Anthony PERARD ha scritto: > > > > On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: > > > > > Il 14/10/2015 13:06, Stefano Stabellini ha scritto: > > > > > > I would suggest Fabio to avoid AHCI disks altogether and just use > > > > > > OVMF > > > > > > with PV disks only and Anthony's patch to libxl to avoid creating > > > > > > any > > > > > > IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. > > > > > > > > > > > > Would that work for you? > > > > > Thanks for the advice, I tried it: > > > > > https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 > > > > > > > > > > I installed W10 pro 64 bit with ide disk, installed the win pv drivers > > > > > and > > > > > after changed to xvdX instead hdX, is the only change needed, right? > > > > > Initial boot is ok (ovmf part about pv disks seems ok) but windows > > > > > boot > > > > > fails with problem with pv drivers. > > > > > In attachment full qemu log with xen_platform trace and domU's xl cfg. > > > > > > > > > > Someone have windows domUs with ovmf and pv disks only working? If yes > > > > > can > > > > > tell me the difference to understand what can be the problem please? > > > > When I worked on the PV disk implementation in OVMF, I was able to boot > > > > a Windows 8 with pv disk only. > > > > > > > > I don't have access to the guest configuration I was using, but I think > > > > one > > > > difference would be the viridian setting, I'm pretty sure I did not set > > > > it. > > > > > > > I tried with viridian disabled but did the same thing, looking cdrom as > > > latest thing before xenbug trace in qemu log I tried also to remove it but > > > also in this case don't boot correctly, full qemu log in attachment. > > > I don't know if is a ovmf thing to improve (like what seems in Laszlo and > > > Kevin mails) or xen winpv drivers unexpected case, have you tried also > > > with > > > latest winpv builds? (for exclude regression) > > No, I did not tried the latest winpv drivers. > > > > Sorry I can help much more that that. When I install this win8 guest tried > > to boot it with pv drivers only, that was more than a year ago. I have not > > check if it's still working. (Also I can not try anything more recent, > > right now.) > > > > I did many other tests, retrying with ide first boot working but show pv > devices not working, I did another reboot (with ide) and pv devices was > working, after I retried with pv (xvdX) and boot correctly. > After other tests I found that with empty cdrom device (required for xl > cd-insert/cd-eject) boot stop at start (tianocore image), same result with ide > instead. > From xl cfg: > disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom'] > With seabios domU boot also with empty cdrom. > In qemu log I found only these that can be related: > > xen be: qdisk-51728: error: Could not open image: No such file or directory > > xen be: qdisk-51728: initialise() failed > And latest xl dmesg line is: > > (d1) Invoking OVMF ... > > If you need more informations/test tell me and I'll post them. Are you saying that without any cdrom drives, it works correctly? ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 10:47 ` Stefano Stabellini @ 2015-10-16 11:34 ` Fabio Fantoni 2015-10-16 11:34 ` Fabio Fantoni 1 sibling, 0 replies; 95+ messages in thread From: Fabio Fantoni @ 2015-10-16 11:34 UTC (permalink / raw) To: Stefano Stabellini Cc: Kevin Wolf, qemu-block, qemu-devel, xen-devel, Paul Durrant, Anthony PERARD, John Snow Il 16/10/2015 12:47, Stefano Stabellini ha scritto: > On Fri, 16 Oct 2015, Fabio Fantoni wrote: >> Il 16/10/2015 12:13, Anthony PERARD ha scritto: >>> On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote: >>>> Il 15/10/2015 20:02, Anthony PERARD ha scritto: >>>>> On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: >>>>>> Il 14/10/2015 13:06, Stefano Stabellini ha scritto: >>>>>>> I would suggest Fabio to avoid AHCI disks altogether and just use >>>>>>> OVMF >>>>>>> with PV disks only and Anthony's patch to libxl to avoid creating >>>>>>> any >>>>>>> IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. >>>>>>> >>>>>>> Would that work for you? >>>>>> Thanks for the advice, I tried it: >>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 >>>>>> >>>>>> I installed W10 pro 64 bit with ide disk, installed the win pv drivers >>>>>> and >>>>>> after changed to xvdX instead hdX, is the only change needed, right? >>>>>> Initial boot is ok (ovmf part about pv disks seems ok) but windows >>>>>> boot >>>>>> fails with problem with pv drivers. >>>>>> In attachment full qemu log with xen_platform trace and domU's xl cfg. >>>>>> >>>>>> Someone have windows domUs with ovmf and pv disks only working? If yes >>>>>> can >>>>>> tell me the difference to understand what can be the problem please? >>>>> When I worked on the PV disk implementation in OVMF, I was able to boot >>>>> a Windows 8 with pv disk only. >>>>> >>>>> I don't have access to the guest configuration I was using, but I think >>>>> one >>>>> difference would be the viridian setting, I'm pretty sure I did not set >>>>> it. >>>>> >>>> I tried with viridian disabled but did the same thing, looking cdrom as >>>> latest thing before xenbug trace in qemu log I tried also to remove it but >>>> also in this case don't boot correctly, full qemu log in attachment. >>>> I don't know if is a ovmf thing to improve (like what seems in Laszlo and >>>> Kevin mails) or xen winpv drivers unexpected case, have you tried also >>>> with >>>> latest winpv builds? (for exclude regression) >>> No, I did not tried the latest winpv drivers. >>> >>> Sorry I can help much more that that. When I install this win8 guest tried >>> to boot it with pv drivers only, that was more than a year ago. I have not >>> check if it's still working. (Also I can not try anything more recent, >>> right now.) >>> >> I did many other tests, retrying with ide first boot working but show pv >> devices not working, I did another reboot (with ide) and pv devices was >> working, after I retried with pv (xvdX) and boot correctly. >> After other tests I found that with empty cdrom device (required for xl >> cd-insert/cd-eject) boot stop at start (tianocore image), same result with ide >> instead. >> From xl cfg: >> disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom'] >> With seabios domU boot also with empty cdrom. >> In qemu log I found only these that can be related: >>> xen be: qdisk-51728: error: Could not open image: No such file or directory >>> xen be: qdisk-51728: initialise() failed >> And latest xl dmesg line is: >>> (d1) Invoking OVMF ... >> If you need more informations/test tell me and I'll post them. > Are you saying that without any cdrom drives, it works correctly? Yes, I did also another test to be sure, starting with ide, installing windows, the pv drivers, rebooting 2 times (with one at boot of time boot with ide only and without net and disks pv drivers working) and after rebooting with pv disks (xvdX) works. With cdrom not empty (with iso) works, with empty not, tried with both ide (hdX) and pv (xvdX). Empty cdrom not working with ovmf I suppose is ovmf bug or inexpected case. About major of winpv drivers problem at boot I suppose can be solved improving ovmf and winpv driver removing bad hybrid thing actually, but I have too low knowledge to be sure. About the problem of pv start after install that requiring at least 2 reboot can be also a windows 10 problem (only a suppose). About empty cdrom with ovmf can be solved please? ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 10:47 ` Stefano Stabellini 2015-10-16 11:34 ` Fabio Fantoni @ 2015-10-16 11:34 ` Fabio Fantoni 2015-10-16 19:09 ` Laszlo Ersek 2015-10-16 19:09 ` Laszlo Ersek 1 sibling, 2 replies; 95+ messages in thread From: Fabio Fantoni @ 2015-10-16 11:34 UTC (permalink / raw) To: Stefano Stabellini Cc: Kevin Wolf, qemu-block, qemu-devel, xen-devel, Paul Durrant, Anthony PERARD, John Snow Il 16/10/2015 12:47, Stefano Stabellini ha scritto: > On Fri, 16 Oct 2015, Fabio Fantoni wrote: >> Il 16/10/2015 12:13, Anthony PERARD ha scritto: >>> On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote: >>>> Il 15/10/2015 20:02, Anthony PERARD ha scritto: >>>>> On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: >>>>>> Il 14/10/2015 13:06, Stefano Stabellini ha scritto: >>>>>>> I would suggest Fabio to avoid AHCI disks altogether and just use >>>>>>> OVMF >>>>>>> with PV disks only and Anthony's patch to libxl to avoid creating >>>>>>> any >>>>>>> IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. >>>>>>> >>>>>>> Would that work for you? >>>>>> Thanks for the advice, I tried it: >>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 >>>>>> >>>>>> I installed W10 pro 64 bit with ide disk, installed the win pv drivers >>>>>> and >>>>>> after changed to xvdX instead hdX, is the only change needed, right? >>>>>> Initial boot is ok (ovmf part about pv disks seems ok) but windows >>>>>> boot >>>>>> fails with problem with pv drivers. >>>>>> In attachment full qemu log with xen_platform trace and domU's xl cfg. >>>>>> >>>>>> Someone have windows domUs with ovmf and pv disks only working? If yes >>>>>> can >>>>>> tell me the difference to understand what can be the problem please? >>>>> When I worked on the PV disk implementation in OVMF, I was able to boot >>>>> a Windows 8 with pv disk only. >>>>> >>>>> I don't have access to the guest configuration I was using, but I think >>>>> one >>>>> difference would be the viridian setting, I'm pretty sure I did not set >>>>> it. >>>>> >>>> I tried with viridian disabled but did the same thing, looking cdrom as >>>> latest thing before xenbug trace in qemu log I tried also to remove it but >>>> also in this case don't boot correctly, full qemu log in attachment. >>>> I don't know if is a ovmf thing to improve (like what seems in Laszlo and >>>> Kevin mails) or xen winpv drivers unexpected case, have you tried also >>>> with >>>> latest winpv builds? (for exclude regression) >>> No, I did not tried the latest winpv drivers. >>> >>> Sorry I can help much more that that. When I install this win8 guest tried >>> to boot it with pv drivers only, that was more than a year ago. I have not >>> check if it's still working. (Also I can not try anything more recent, >>> right now.) >>> >> I did many other tests, retrying with ide first boot working but show pv >> devices not working, I did another reboot (with ide) and pv devices was >> working, after I retried with pv (xvdX) and boot correctly. >> After other tests I found that with empty cdrom device (required for xl >> cd-insert/cd-eject) boot stop at start (tianocore image), same result with ide >> instead. >> From xl cfg: >> disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom'] >> With seabios domU boot also with empty cdrom. >> In qemu log I found only these that can be related: >>> xen be: qdisk-51728: error: Could not open image: No such file or directory >>> xen be: qdisk-51728: initialise() failed >> And latest xl dmesg line is: >>> (d1) Invoking OVMF ... >> If you need more informations/test tell me and I'll post them. > Are you saying that without any cdrom drives, it works correctly? Yes, I did also another test to be sure, starting with ide, installing windows, the pv drivers, rebooting 2 times (with one at boot of time boot with ide only and without net and disks pv drivers working) and after rebooting with pv disks (xvdX) works. With cdrom not empty (with iso) works, with empty not, tried with both ide (hdX) and pv (xvdX). Empty cdrom not working with ovmf I suppose is ovmf bug or inexpected case. About major of winpv drivers problem at boot I suppose can be solved improving ovmf and winpv driver removing bad hybrid thing actually, but I have too low knowledge to be sure. About the problem of pv start after install that requiring at least 2 reboot can be also a windows 10 problem (only a suppose). About empty cdrom with ovmf can be solved please? ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 11:34 ` Fabio Fantoni @ 2015-10-16 19:09 ` Laszlo Ersek 2015-10-16 19:09 ` Laszlo Ersek 1 sibling, 0 replies; 95+ messages in thread From: Laszlo Ersek @ 2015-10-16 19:09 UTC (permalink / raw) To: Fabio Fantoni, Stefano Stabellini Cc: Kevin Wolf, qemu-block, qemu-devel, xen-devel, Paul Durrant, Anthony PERARD, John Snow On 10/16/15 13:34, Fabio Fantoni wrote: > Il 16/10/2015 12:47, Stefano Stabellini ha scritto: >> On Fri, 16 Oct 2015, Fabio Fantoni wrote: >>> Il 16/10/2015 12:13, Anthony PERARD ha scritto: >>>> On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote: >>>>> Il 15/10/2015 20:02, Anthony PERARD ha scritto: >>>>>> On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: >>>>>>> Il 14/10/2015 13:06, Stefano Stabellini ha scritto: >>>>>>>> I would suggest Fabio to avoid AHCI disks altogether and just use >>>>>>>> OVMF >>>>>>>> with PV disks only and Anthony's patch to libxl to avoid creating >>>>>>>> any >>>>>>>> IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. >>>>>>>> >>>>>>>> Would that work for you? >>>>>>> Thanks for the advice, I tried it: >>>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 >>>>>>> >>>>>>> I installed W10 pro 64 bit with ide disk, installed the win pv >>>>>>> drivers >>>>>>> and >>>>>>> after changed to xvdX instead hdX, is the only change needed, right? >>>>>>> Initial boot is ok (ovmf part about pv disks seems ok) but windows >>>>>>> boot >>>>>>> fails with problem with pv drivers. >>>>>>> In attachment full qemu log with xen_platform trace and domU's xl >>>>>>> cfg. >>>>>>> >>>>>>> Someone have windows domUs with ovmf and pv disks only working? >>>>>>> If yes >>>>>>> can >>>>>>> tell me the difference to understand what can be the problem please? >>>>>> When I worked on the PV disk implementation in OVMF, I was able to >>>>>> boot >>>>>> a Windows 8 with pv disk only. >>>>>> >>>>>> I don't have access to the guest configuration I was using, but I >>>>>> think >>>>>> one >>>>>> difference would be the viridian setting, I'm pretty sure I did >>>>>> not set >>>>>> it. >>>>>> >>>>> I tried with viridian disabled but did the same thing, looking >>>>> cdrom as >>>>> latest thing before xenbug trace in qemu log I tried also to remove >>>>> it but >>>>> also in this case don't boot correctly, full qemu log in attachment. >>>>> I don't know if is a ovmf thing to improve (like what seems in >>>>> Laszlo and >>>>> Kevin mails) or xen winpv drivers unexpected case, have you tried also >>>>> with >>>>> latest winpv builds? (for exclude regression) >>>> No, I did not tried the latest winpv drivers. >>>> >>>> Sorry I can help much more that that. When I install this win8 guest >>>> tried >>>> to boot it with pv drivers only, that was more than a year ago. I >>>> have not >>>> check if it's still working. (Also I can not try anything more recent, >>>> right now.) >>>> >>> I did many other tests, retrying with ide first boot working but show pv >>> devices not working, I did another reboot (with ide) and pv devices was >>> working, after I retried with pv (xvdX) and boot correctly. >>> After other tests I found that with empty cdrom device (required for xl >>> cd-insert/cd-eject) boot stop at start (tianocore image), same result >>> with ide >>> instead. >>> From xl cfg: >>> disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom'] >>> >>> With seabios domU boot also with empty cdrom. >>> In qemu log I found only these that can be related: >>>> xen be: qdisk-51728: error: Could not open image: No such file or >>>> directory >>>> xen be: qdisk-51728: initialise() failed >>> And latest xl dmesg line is: >>>> (d1) Invoking OVMF ... >>> If you need more informations/test tell me and I'll post them. >> Are you saying that without any cdrom drives, it works correctly? > Yes, I did also another test to be sure, starting with ide, installing > windows, the pv drivers, rebooting 2 times (with one at boot of time > boot with ide only and without net and disks pv drivers working) and > after rebooting with pv disks (xvdX) works. > With cdrom not empty (with iso) works, with empty not, tried with both > ide (hdX) and pv (xvdX). > Empty cdrom not working with ovmf I suppose is ovmf bug or inexpected case. > About major of winpv drivers problem at boot I suppose can be solved > improving ovmf and winpv driver removing bad hybrid thing actually, but > I have too low knowledge to be sure. > About the problem of pv start after install that requiring at least 2 > reboot can be also a windows 10 problem (only a suppose). > > About empty cdrom with ovmf can be solved please? > Sorry, I find your problem report impenetrable. :( Please slow down and try to spend time on punctuation at least. For me to make heads or tails of this, I'll need the following: - The debug output of an OVMF binary built with the DEBUG_VERBOSE bit (0x00400000) enabled in PcdDebugPrintErrorLevel, in addition to the default setting. - Preferably, I'll need two logs, one for the "working" case, and another for the "non-working" case. - A description of the virtual hardware (disks etc) that is understandable to someone who hasn't booted Xen in several years; for both cases above. - Please try to make an exact, itemized list of the steps you perform before executing the successful vs. failing test. - It would also help if you entered the UEFI shell in both the successful and the failing case, and ran the MAP command. The output can be snarfed from the virtual serial port too. - another command to run from the UEFI shell, in both cases: dh -d -v -p SimpleFileSystem Thanks Laszlo ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 11:34 ` Fabio Fantoni 2015-10-16 19:09 ` Laszlo Ersek @ 2015-10-16 19:09 ` Laszlo Ersek 2015-10-19 20:32 ` Laszlo Ersek 2015-10-19 20:32 ` Laszlo Ersek 1 sibling, 2 replies; 95+ messages in thread From: Laszlo Ersek @ 2015-10-16 19:09 UTC (permalink / raw) To: Fabio Fantoni, Stefano Stabellini Cc: Kevin Wolf, qemu-block, qemu-devel, xen-devel, Paul Durrant, Anthony PERARD, John Snow On 10/16/15 13:34, Fabio Fantoni wrote: > Il 16/10/2015 12:47, Stefano Stabellini ha scritto: >> On Fri, 16 Oct 2015, Fabio Fantoni wrote: >>> Il 16/10/2015 12:13, Anthony PERARD ha scritto: >>>> On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote: >>>>> Il 15/10/2015 20:02, Anthony PERARD ha scritto: >>>>>> On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: >>>>>>> Il 14/10/2015 13:06, Stefano Stabellini ha scritto: >>>>>>>> I would suggest Fabio to avoid AHCI disks altogether and just use >>>>>>>> OVMF >>>>>>>> with PV disks only and Anthony's patch to libxl to avoid creating >>>>>>>> any >>>>>>>> IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. >>>>>>>> >>>>>>>> Would that work for you? >>>>>>> Thanks for the advice, I tried it: >>>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 >>>>>>> >>>>>>> I installed W10 pro 64 bit with ide disk, installed the win pv >>>>>>> drivers >>>>>>> and >>>>>>> after changed to xvdX instead hdX, is the only change needed, right? >>>>>>> Initial boot is ok (ovmf part about pv disks seems ok) but windows >>>>>>> boot >>>>>>> fails with problem with pv drivers. >>>>>>> In attachment full qemu log with xen_platform trace and domU's xl >>>>>>> cfg. >>>>>>> >>>>>>> Someone have windows domUs with ovmf and pv disks only working? >>>>>>> If yes >>>>>>> can >>>>>>> tell me the difference to understand what can be the problem please? >>>>>> When I worked on the PV disk implementation in OVMF, I was able to >>>>>> boot >>>>>> a Windows 8 with pv disk only. >>>>>> >>>>>> I don't have access to the guest configuration I was using, but I >>>>>> think >>>>>> one >>>>>> difference would be the viridian setting, I'm pretty sure I did >>>>>> not set >>>>>> it. >>>>>> >>>>> I tried with viridian disabled but did the same thing, looking >>>>> cdrom as >>>>> latest thing before xenbug trace in qemu log I tried also to remove >>>>> it but >>>>> also in this case don't boot correctly, full qemu log in attachment. >>>>> I don't know if is a ovmf thing to improve (like what seems in >>>>> Laszlo and >>>>> Kevin mails) or xen winpv drivers unexpected case, have you tried also >>>>> with >>>>> latest winpv builds? (for exclude regression) >>>> No, I did not tried the latest winpv drivers. >>>> >>>> Sorry I can help much more that that. When I install this win8 guest >>>> tried >>>> to boot it with pv drivers only, that was more than a year ago. I >>>> have not >>>> check if it's still working. (Also I can not try anything more recent, >>>> right now.) >>>> >>> I did many other tests, retrying with ide first boot working but show pv >>> devices not working, I did another reboot (with ide) and pv devices was >>> working, after I retried with pv (xvdX) and boot correctly. >>> After other tests I found that with empty cdrom device (required for xl >>> cd-insert/cd-eject) boot stop at start (tianocore image), same result >>> with ide >>> instead. >>> From xl cfg: >>> disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom'] >>> >>> With seabios domU boot also with empty cdrom. >>> In qemu log I found only these that can be related: >>>> xen be: qdisk-51728: error: Could not open image: No such file or >>>> directory >>>> xen be: qdisk-51728: initialise() failed >>> And latest xl dmesg line is: >>>> (d1) Invoking OVMF ... >>> If you need more informations/test tell me and I'll post them. >> Are you saying that without any cdrom drives, it works correctly? > Yes, I did also another test to be sure, starting with ide, installing > windows, the pv drivers, rebooting 2 times (with one at boot of time > boot with ide only and without net and disks pv drivers working) and > after rebooting with pv disks (xvdX) works. > With cdrom not empty (with iso) works, with empty not, tried with both > ide (hdX) and pv (xvdX). > Empty cdrom not working with ovmf I suppose is ovmf bug or inexpected case. > About major of winpv drivers problem at boot I suppose can be solved > improving ovmf and winpv driver removing bad hybrid thing actually, but > I have too low knowledge to be sure. > About the problem of pv start after install that requiring at least 2 > reboot can be also a windows 10 problem (only a suppose). > > About empty cdrom with ovmf can be solved please? > Sorry, I find your problem report impenetrable. :( Please slow down and try to spend time on punctuation at least. For me to make heads or tails of this, I'll need the following: - The debug output of an OVMF binary built with the DEBUG_VERBOSE bit (0x00400000) enabled in PcdDebugPrintErrorLevel, in addition to the default setting. - Preferably, I'll need two logs, one for the "working" case, and another for the "non-working" case. - A description of the virtual hardware (disks etc) that is understandable to someone who hasn't booted Xen in several years; for both cases above. - Please try to make an exact, itemized list of the steps you perform before executing the successful vs. failing test. - It would also help if you entered the UEFI shell in both the successful and the failing case, and ran the MAP command. The output can be snarfed from the virtual serial port too. - another command to run from the UEFI shell, in both cases: dh -d -v -p SimpleFileSystem Thanks Laszlo ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 19:09 ` Laszlo Ersek @ 2015-10-19 20:32 ` Laszlo Ersek 2015-10-20 11:59 ` Stefano Stabellini 2015-10-20 11:59 ` Stefano Stabellini 2015-10-19 20:32 ` Laszlo Ersek 1 sibling, 2 replies; 95+ messages in thread From: Laszlo Ersek @ 2015-10-19 20:32 UTC (permalink / raw) To: Fabio Fantoni, Stefano Stabellini Cc: Kevin Wolf, qemu-block, Jordan Justen (Intel address), qemu-devel, xen-devel, Paul Durrant, Samuel Thibault, Anthony PERARD, John Snow On 10/16/15 21:09, Laszlo Ersek wrote: > On 10/16/15 13:34, Fabio Fantoni wrote: >> Il 16/10/2015 12:47, Stefano Stabellini ha scritto: >>> On Fri, 16 Oct 2015, Fabio Fantoni wrote: >>>> Il 16/10/2015 12:13, Anthony PERARD ha scritto: >>>>> On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote: >>>>>> Il 15/10/2015 20:02, Anthony PERARD ha scritto: >>>>>>> On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: >>>>>>>> Il 14/10/2015 13:06, Stefano Stabellini ha scritto: >>>>>>>>> I would suggest Fabio to avoid AHCI disks altogether and just use >>>>>>>>> OVMF >>>>>>>>> with PV disks only and Anthony's patch to libxl to avoid creating >>>>>>>>> any >>>>>>>>> IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. >>>>>>>>> >>>>>>>>> Would that work for you? >>>>>>>> Thanks for the advice, I tried it: >>>>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 >>>>>>>> >>>>>>>> I installed W10 pro 64 bit with ide disk, installed the win pv >>>>>>>> drivers >>>>>>>> and >>>>>>>> after changed to xvdX instead hdX, is the only change needed, right? >>>>>>>> Initial boot is ok (ovmf part about pv disks seems ok) but windows >>>>>>>> boot >>>>>>>> fails with problem with pv drivers. >>>>>>>> In attachment full qemu log with xen_platform trace and domU's xl >>>>>>>> cfg. >>>>>>>> >>>>>>>> Someone have windows domUs with ovmf and pv disks only working? >>>>>>>> If yes >>>>>>>> can >>>>>>>> tell me the difference to understand what can be the problem please? >>>>>>> When I worked on the PV disk implementation in OVMF, I was able to >>>>>>> boot >>>>>>> a Windows 8 with pv disk only. >>>>>>> >>>>>>> I don't have access to the guest configuration I was using, but I >>>>>>> think >>>>>>> one >>>>>>> difference would be the viridian setting, I'm pretty sure I did >>>>>>> not set >>>>>>> it. >>>>>>> >>>>>> I tried with viridian disabled but did the same thing, looking >>>>>> cdrom as >>>>>> latest thing before xenbug trace in qemu log I tried also to remove >>>>>> it but >>>>>> also in this case don't boot correctly, full qemu log in attachment. >>>>>> I don't know if is a ovmf thing to improve (like what seems in >>>>>> Laszlo and >>>>>> Kevin mails) or xen winpv drivers unexpected case, have you tried also >>>>>> with >>>>>> latest winpv builds? (for exclude regression) >>>>> No, I did not tried the latest winpv drivers. >>>>> >>>>> Sorry I can help much more that that. When I install this win8 guest >>>>> tried >>>>> to boot it with pv drivers only, that was more than a year ago. I >>>>> have not >>>>> check if it's still working. (Also I can not try anything more recent, >>>>> right now.) >>>>> >>>> I did many other tests, retrying with ide first boot working but show pv >>>> devices not working, I did another reboot (with ide) and pv devices was >>>> working, after I retried with pv (xvdX) and boot correctly. >>>> After other tests I found that with empty cdrom device (required for xl >>>> cd-insert/cd-eject) boot stop at start (tianocore image), same result >>>> with ide >>>> instead. >>>> From xl cfg: >>>> disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom'] >>>> >>>> With seabios domU boot also with empty cdrom. >>>> In qemu log I found only these that can be related: >>>>> xen be: qdisk-51728: error: Could not open image: No such file or >>>>> directory >>>>> xen be: qdisk-51728: initialise() failed >>>> And latest xl dmesg line is: >>>>> (d1) Invoking OVMF ... >>>> If you need more informations/test tell me and I'll post them. >>> Are you saying that without any cdrom drives, it works correctly? >> Yes, I did also another test to be sure, starting with ide, installing >> windows, the pv drivers, rebooting 2 times (with one at boot of time >> boot with ide only and without net and disks pv drivers working) and >> after rebooting with pv disks (xvdX) works. >> With cdrom not empty (with iso) works, with empty not, tried with both >> ide (hdX) and pv (xvdX). >> Empty cdrom not working with ovmf I suppose is ovmf bug or inexpected case. >> About major of winpv drivers problem at boot I suppose can be solved >> improving ovmf and winpv driver removing bad hybrid thing actually, but >> I have too low knowledge to be sure. >> About the problem of pv start after install that requiring at least 2 >> reboot can be also a windows 10 problem (only a suppose). >> >> About empty cdrom with ovmf can be solved please? >> > > Sorry, I find your problem report impenetrable. :( Please slow down and > try to spend time on punctuation at least. > > For me to make heads or tails of this, I'll need the following: > > - The debug output of an OVMF binary built with the DEBUG_VERBOSE bit > (0x00400000) enabled in PcdDebugPrintErrorLevel, in addition to the > default setting. > > - Preferably, I'll need two logs, one for the "working" case, and > another for the "non-working" case. > > - A description of the virtual hardware (disks etc) that is > understandable to someone who hasn't booted Xen in several years; for > both cases above. > > - Please try to make an exact, itemized list of the steps you perform > before executing the successful vs. failing test. > > - It would also help if you entered the UEFI shell in both the > successful and the failing case, and ran the MAP command. The output can > be snarfed from the virtual serial port too. > > - another command to run from the UEFI shell, in both cases: > > dh -d -v -p SimpleFileSystem Okay, despite none of the info having surfaced that I asked for, John and I continued discussing this. >From the vague memories of a RHEL-5 Xen dom0 bug (blkback) that I fixed on Aug 19 *2011*, I now managed to remember the VDISK_CDROM flag, and that we had had many issues with CD-ROMs. So I looked at the current guest kernel driver now, "drivers/block/xen-blkfront.c", to see if there were any CD-ROM related "hacks" in place still. Apparently so; please consider the following "git blame" snippet (excuse me for the long lines), from the blkfront_probe() function: b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1427) if (xen_hvm_domain()) { b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1428) char *type; b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1429) int len; b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1430) /* no unplug has been done: do not hook devices != xen vbds */ 51c71a3b (Konrad Rzeszutek Wilk 2013-11-26 15:05:40 -0500 1431) if (xen_has_pv_and_legacy_disk_devices()) { b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1432) int major; b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1433) b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1434) if (!VDEV_IS_EXTENDED(vdevice)) b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1435) major = BLKIF_MAJOR(vdevice); b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1436) else b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1437) major = XENVBD_MAJOR; b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1438) b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1439) if (major != XENVBD_MAJOR) { b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1440) printk(KERN_INFO b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1441) "%s: HVM does not support vbd %d as xen block device\n", 02f1f217 (Rasmus Villemoes 2015-02-12 15:01:31 -0800 1442) __func__, vdevice); b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1443) return -ENODEV; b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1444) } b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1445) } b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1446) /* do not create a PV cdrom device if we are an HVM guest */ b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1447) type = xenbus_read(XBT_NIL, dev->nodename, "device-type", &len); b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1448) if (IS_ERR(type)) b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1449) return -ENODEV; b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1450) if (strncmp(type, "cdrom", 5) == 0) { b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1451) kfree(type); c1c5413a (Stefano Stabellini 2010-05-14 12:44:30 +0100 1452) return -ENODEV; c1c5413a (Stefano Stabellini 2010-05-14 12:44:30 +0100 1453) } b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1454) kfree(type); c1c5413a (Stefano Stabellini 2010-05-14 12:44:30 +0100 1455) } Side point: commit 51c71a3b from Konrad <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=51c71a3b> should be instrumental for those who are looking for more background on emulated device / driver unplugging in Xen domUs. But, the really interesting bit here is the commit message of b98a409b <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b98a409b>, from 2010, authored by Stefano: blkfront: do not create a PV cdrom device if xen_hvm_guest It is not possible to unplug emulated cdrom devices, and PV cdroms don't handle media insert, eject and stream, so we are better off disabling PV cdroms when running as a Xen HVM guest. Could that be related to the issue you are experiencing with OVMF? Because, OVMF implies HVM (or PV-on-HVM), and your report ("empty paravirt CD-ROM" or some such -- sorry, the report remains unclear) appears to match the above message. Given that this is guest code, shouldn't the same logic be mirrored in the OVMF guest driver? /* do not create a PV cdrom device if we are an HVM guest */ In other words, given that OVMF implies HVM, shouldn't OVMF too forego driving a paravirt CD-ROM entirely? Now, the Xen guest code in OVMF, from <https://github.com/tianocore/edk2/commit/5cce8524>, function XenPvBlockFrontInitialization(), *does* look for "cdrom" in "device-type": XenBusIo->XsRead (XenBusIo, XST_NIL, "device-type", (VOID**)&DeviceType); if (AsciiStrCmp (DeviceType, "cdrom") == 0) { Dev->MediaInfo.CdRom = TRUE; } else { Dev->MediaInfo.CdRom = FALSE; } but the *only* thing that the CdRom field is used for is to force a 2KB block size in XenPvBlkDxeDriverBindingStart(), for ElTorito compatibility: if (Dev->MediaInfo.CdRom) { // // If it's a cdrom, the blocksize value need to be 2048 for OVMF to // recognize it as a cdrom: // MdeModulePkg/Universal/Disk/PartitionDxe/ElTorito.c // Media->BlockSize = 2048; Media->LastBlock = DivU64x32 (Dev->MediaInfo.Sectors, Media->BlockSize / Dev->MediaInfo.SectorSize) - 1; } else { While in the same situation (i.e., in an HVM guest), the guest kernel driver does not report a paravirt CD-ROM at all; instead it forces an emulated (IDE) CD-ROM. ... Sorry if the above turns out fully irrelevant, but I still have no info from you to go on. Thanks Laszlo ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-19 20:32 ` Laszlo Ersek @ 2015-10-20 11:59 ` Stefano Stabellini 2015-10-20 11:59 ` Stefano Stabellini 1 sibling, 0 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-20 11:59 UTC (permalink / raw) To: Laszlo Ersek Cc: Kevin Wolf, qemu-block, Stefano Stabellini, Jordan Justen (Intel address), qemu-devel, xen-devel, Fabio Fantoni, Samuel Thibault, Anthony PERARD, John Snow, Paul Durrant On Mon, 19 Oct 2015, Laszlo Ersek wrote: > On 10/16/15 21:09, Laszlo Ersek wrote: > > On 10/16/15 13:34, Fabio Fantoni wrote: > >> Il 16/10/2015 12:47, Stefano Stabellini ha scritto: > >>> On Fri, 16 Oct 2015, Fabio Fantoni wrote: > >>>> Il 16/10/2015 12:13, Anthony PERARD ha scritto: > >>>>> On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote: > >>>>>> Il 15/10/2015 20:02, Anthony PERARD ha scritto: > >>>>>>> On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: > >>>>>>>> Il 14/10/2015 13:06, Stefano Stabellini ha scritto: > >>>>>>>>> I would suggest Fabio to avoid AHCI disks altogether and just use > >>>>>>>>> OVMF > >>>>>>>>> with PV disks only and Anthony's patch to libxl to avoid creating > >>>>>>>>> any > >>>>>>>>> IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. > >>>>>>>>> > >>>>>>>>> Would that work for you? > >>>>>>>> Thanks for the advice, I tried it: > >>>>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 > >>>>>>>> > >>>>>>>> I installed W10 pro 64 bit with ide disk, installed the win pv > >>>>>>>> drivers > >>>>>>>> and > >>>>>>>> after changed to xvdX instead hdX, is the only change needed, right? > >>>>>>>> Initial boot is ok (ovmf part about pv disks seems ok) but windows > >>>>>>>> boot > >>>>>>>> fails with problem with pv drivers. > >>>>>>>> In attachment full qemu log with xen_platform trace and domU's xl > >>>>>>>> cfg. > >>>>>>>> > >>>>>>>> Someone have windows domUs with ovmf and pv disks only working? > >>>>>>>> If yes > >>>>>>>> can > >>>>>>>> tell me the difference to understand what can be the problem please? > >>>>>>> When I worked on the PV disk implementation in OVMF, I was able to > >>>>>>> boot > >>>>>>> a Windows 8 with pv disk only. > >>>>>>> > >>>>>>> I don't have access to the guest configuration I was using, but I > >>>>>>> think > >>>>>>> one > >>>>>>> difference would be the viridian setting, I'm pretty sure I did > >>>>>>> not set > >>>>>>> it. > >>>>>>> > >>>>>> I tried with viridian disabled but did the same thing, looking > >>>>>> cdrom as > >>>>>> latest thing before xenbug trace in qemu log I tried also to remove > >>>>>> it but > >>>>>> also in this case don't boot correctly, full qemu log in attachment. > >>>>>> I don't know if is a ovmf thing to improve (like what seems in > >>>>>> Laszlo and > >>>>>> Kevin mails) or xen winpv drivers unexpected case, have you tried also > >>>>>> with > >>>>>> latest winpv builds? (for exclude regression) > >>>>> No, I did not tried the latest winpv drivers. > >>>>> > >>>>> Sorry I can help much more that that. When I install this win8 guest > >>>>> tried > >>>>> to boot it with pv drivers only, that was more than a year ago. I > >>>>> have not > >>>>> check if it's still working. (Also I can not try anything more recent, > >>>>> right now.) > >>>>> > >>>> I did many other tests, retrying with ide first boot working but show pv > >>>> devices not working, I did another reboot (with ide) and pv devices was > >>>> working, after I retried with pv (xvdX) and boot correctly. > >>>> After other tests I found that with empty cdrom device (required for xl > >>>> cd-insert/cd-eject) boot stop at start (tianocore image), same result > >>>> with ide > >>>> instead. > >>>> From xl cfg: > >>>> disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom'] > >>>> > >>>> With seabios domU boot also with empty cdrom. > >>>> In qemu log I found only these that can be related: > >>>>> xen be: qdisk-51728: error: Could not open image: No such file or > >>>>> directory > >>>>> xen be: qdisk-51728: initialise() failed > >>>> And latest xl dmesg line is: > >>>>> (d1) Invoking OVMF ... > >>>> If you need more informations/test tell me and I'll post them. > >>> Are you saying that without any cdrom drives, it works correctly? > >> Yes, I did also another test to be sure, starting with ide, installing > >> windows, the pv drivers, rebooting 2 times (with one at boot of time > >> boot with ide only and without net and disks pv drivers working) and > >> after rebooting with pv disks (xvdX) works. > >> With cdrom not empty (with iso) works, with empty not, tried with both > >> ide (hdX) and pv (xvdX). > >> Empty cdrom not working with ovmf I suppose is ovmf bug or inexpected case. > >> About major of winpv drivers problem at boot I suppose can be solved > >> improving ovmf and winpv driver removing bad hybrid thing actually, but > >> I have too low knowledge to be sure. > >> About the problem of pv start after install that requiring at least 2 > >> reboot can be also a windows 10 problem (only a suppose). > >> > >> About empty cdrom with ovmf can be solved please? > >> > > > > Sorry, I find your problem report impenetrable. :( Please slow down and > > try to spend time on punctuation at least. > > > > For me to make heads or tails of this, I'll need the following: > > > > - The debug output of an OVMF binary built with the DEBUG_VERBOSE bit > > (0x00400000) enabled in PcdDebugPrintErrorLevel, in addition to the > > default setting. > > > > - Preferably, I'll need two logs, one for the "working" case, and > > another for the "non-working" case. > > > > - A description of the virtual hardware (disks etc) that is > > understandable to someone who hasn't booted Xen in several years; for > > both cases above. > > > > - Please try to make an exact, itemized list of the steps you perform > > before executing the successful vs. failing test. > > > > - It would also help if you entered the UEFI shell in both the > > successful and the failing case, and ran the MAP command. The output can > > be snarfed from the virtual serial port too. > > > > - another command to run from the UEFI shell, in both cases: > > > > dh -d -v -p SimpleFileSystem > > Okay, despite none of the info having surfaced that I asked for, John > and I continued discussing this. Many thanks for spending time on this > >From the vague memories of a RHEL-5 Xen dom0 bug (blkback) that I fixed > on Aug 19 *2011*, I now managed to remember the VDISK_CDROM flag, and > that we had had many issues with CD-ROMs. > > So I looked at the current guest kernel driver now, > "drivers/block/xen-blkfront.c", to see if there were any CD-ROM related > "hacks" in place still. Apparently so; please consider the following > "git blame" snippet (excuse me for the long lines), from the > blkfront_probe() function: > > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1427) if (xen_hvm_domain()) { > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1428) char *type; > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1429) int len; > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1430) /* no unplug has been done: do not hook devices != xen vbds */ > 51c71a3b (Konrad Rzeszutek Wilk 2013-11-26 15:05:40 -0500 1431) if (xen_has_pv_and_legacy_disk_devices()) { > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1432) int major; > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1433) > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1434) if (!VDEV_IS_EXTENDED(vdevice)) > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1435) major = BLKIF_MAJOR(vdevice); > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1436) else > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1437) major = XENVBD_MAJOR; > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1438) > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1439) if (major != XENVBD_MAJOR) { > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1440) printk(KERN_INFO > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1441) "%s: HVM does not support vbd %d as xen block device\n", > 02f1f217 (Rasmus Villemoes 2015-02-12 15:01:31 -0800 1442) __func__, vdevice); > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1443) return -ENODEV; > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1444) } > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1445) } > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1446) /* do not create a PV cdrom device if we are an HVM guest */ > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1447) type = xenbus_read(XBT_NIL, dev->nodename, "device-type", &len); > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1448) if (IS_ERR(type)) > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1449) return -ENODEV; > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1450) if (strncmp(type, "cdrom", 5) == 0) { > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1451) kfree(type); > c1c5413a (Stefano Stabellini 2010-05-14 12:44:30 +0100 1452) return -ENODEV; > c1c5413a (Stefano Stabellini 2010-05-14 12:44:30 +0100 1453) } > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1454) kfree(type); > c1c5413a (Stefano Stabellini 2010-05-14 12:44:30 +0100 1455) } /me hides in a corner > Side point: commit 51c71a3b from Konrad > <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=51c71a3b> > should be instrumental for those who are looking for more background on > emulated device / driver unplugging in Xen domUs. > > But, the really interesting bit here is the commit message of b98a409b > <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b98a409b>, > from 2010, authored by Stefano: > > blkfront: do not create a PV cdrom device if xen_hvm_guest > > It is not possible to unplug emulated cdrom devices, and PV cdroms don't > handle media insert, eject and stream, so we are better off disabling PV > cdroms when running as a Xen HVM guest. I think it all comes from the way PV drivers for HVM guests were originally written: the cdrom device was emulated rather than paravirtualized. So the unplug protocol in QEMU was implemented like this: int pci_piix3_xen_ide_unplug(DeviceState *dev) { PCIIDEState *pci_ide; DriveInfo *di; int i; IDEDevice *idedev; pci_ide = PCI_IDE(dev); for (i = 0; i < 4; i++) { di = drive_get_by_index(IF_IDE, i); if (di != NULL && !di->media_cd) { <unplug> In particular see the !di->media_cd. As a consequence cdroms are left emulated. Given that they cannot be unplugged and given that the PV block protocol is lacking in terms of cdrom-like functionalities, I disabled blkfront in Linux for PV interfaces corresponding to cdrom devices. But it could work. > Could that be related to the issue you are experiencing with OVMF? > Because, OVMF implies HVM (or PV-on-HVM), and your report ("empty > paravirt CD-ROM" or some such -- sorry, the report remains unclear) > appears to match the above message. > > Given that this is guest code, shouldn't the same logic be mirrored in > the OVMF guest driver? > > /* do not create a PV cdrom device if we are an HVM guest */ > > In other words, given that OVMF implies HVM, shouldn't OVMF too forego > driving a paravirt CD-ROM entirely? In the case of OVMF I think we can use the PV block interface to access the cdrom, the problem is just that it cannot handle empty cdrom drives at the moment and XenPvBlockFrontInitialization simply returns an error. A simple patch like this one should prevent OVMF from getting stuck with an error when an empty cdrom is found: diff --git a/OvmfPkg/XenPvBlkDxe/BlockFront.c b/OvmfPkg/XenPvBlkDxe/BlockFront.c index 256ac55..ae7cab9 100644 --- a/OvmfPkg/XenPvBlkDxe/BlockFront.c +++ b/OvmfPkg/XenPvBlkDxe/BlockFront.c @@ -186,6 +186,10 @@ XenPvBlockFrontInitialization ( } FreePool (DeviceType); + Status = XenBusReadUint64 (XenBusIo, "sectors", TRUE, &Value); + if (Dev->MediaInfo.CdRom && Status != XENSTORE_STATUS_SUCCESS) + return EFI_NO_MEDIA; + Status = XenBusReadUint64 (XenBusIo, "backend-id", FALSE, &Value); if (Status != XENSTORE_STATUS_SUCCESS || Value > MAX_UINT16) { DEBUG ((EFI_D_ERROR, "XenPvBlk: Failed to get backend-id (%d)\n", > Now, the Xen guest code in OVMF, from > <https://github.com/tianocore/edk2/commit/5cce8524>, function > XenPvBlockFrontInitialization(), *does* look for "cdrom" in > "device-type": > > XenBusIo->XsRead (XenBusIo, XST_NIL, "device-type", (VOID**)&DeviceType); > if (AsciiStrCmp (DeviceType, "cdrom") == 0) { > Dev->MediaInfo.CdRom = TRUE; > } else { > Dev->MediaInfo.CdRom = FALSE; > } > > but the *only* thing that the CdRom field is used for is to force a 2KB > block size in XenPvBlkDxeDriverBindingStart(), for ElTorito > compatibility: > > if (Dev->MediaInfo.CdRom) { > // > // If it's a cdrom, the blocksize value need to be 2048 for OVMF to > // recognize it as a cdrom: > // MdeModulePkg/Universal/Disk/PartitionDxe/ElTorito.c > // > Media->BlockSize = 2048; > Media->LastBlock = DivU64x32 (Dev->MediaInfo.Sectors, > Media->BlockSize / Dev->MediaInfo.SectorSize) - 1; > } else { > > While in the same situation (i.e., in an HVM guest), the guest kernel > driver does not report a paravirt CD-ROM at all; instead it forces an > emulated (IDE) CD-ROM. > > ... Sorry if the above turns out fully irrelevant, but I still have no > info from you to go on. Actually it was helpful, thank you. ^ permalink raw reply related [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-19 20:32 ` Laszlo Ersek 2015-10-20 11:59 ` Stefano Stabellini @ 2015-10-20 11:59 ` Stefano Stabellini 2015-10-20 12:45 ` Laszlo Ersek 2015-10-20 12:45 ` Laszlo Ersek 1 sibling, 2 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-20 11:59 UTC (permalink / raw) To: Laszlo Ersek Cc: Kevin Wolf, qemu-block, Stefano Stabellini, Jordan Justen (Intel address), qemu-devel, xen-devel, Fabio Fantoni, Samuel Thibault, Anthony PERARD, John Snow, Paul Durrant On Mon, 19 Oct 2015, Laszlo Ersek wrote: > On 10/16/15 21:09, Laszlo Ersek wrote: > > On 10/16/15 13:34, Fabio Fantoni wrote: > >> Il 16/10/2015 12:47, Stefano Stabellini ha scritto: > >>> On Fri, 16 Oct 2015, Fabio Fantoni wrote: > >>>> Il 16/10/2015 12:13, Anthony PERARD ha scritto: > >>>>> On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote: > >>>>>> Il 15/10/2015 20:02, Anthony PERARD ha scritto: > >>>>>>> On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: > >>>>>>>> Il 14/10/2015 13:06, Stefano Stabellini ha scritto: > >>>>>>>>> I would suggest Fabio to avoid AHCI disks altogether and just use > >>>>>>>>> OVMF > >>>>>>>>> with PV disks only and Anthony's patch to libxl to avoid creating > >>>>>>>>> any > >>>>>>>>> IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. > >>>>>>>>> > >>>>>>>>> Would that work for you? > >>>>>>>> Thanks for the advice, I tried it: > >>>>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 > >>>>>>>> > >>>>>>>> I installed W10 pro 64 bit with ide disk, installed the win pv > >>>>>>>> drivers > >>>>>>>> and > >>>>>>>> after changed to xvdX instead hdX, is the only change needed, right? > >>>>>>>> Initial boot is ok (ovmf part about pv disks seems ok) but windows > >>>>>>>> boot > >>>>>>>> fails with problem with pv drivers. > >>>>>>>> In attachment full qemu log with xen_platform trace and domU's xl > >>>>>>>> cfg. > >>>>>>>> > >>>>>>>> Someone have windows domUs with ovmf and pv disks only working? > >>>>>>>> If yes > >>>>>>>> can > >>>>>>>> tell me the difference to understand what can be the problem please? > >>>>>>> When I worked on the PV disk implementation in OVMF, I was able to > >>>>>>> boot > >>>>>>> a Windows 8 with pv disk only. > >>>>>>> > >>>>>>> I don't have access to the guest configuration I was using, but I > >>>>>>> think > >>>>>>> one > >>>>>>> difference would be the viridian setting, I'm pretty sure I did > >>>>>>> not set > >>>>>>> it. > >>>>>>> > >>>>>> I tried with viridian disabled but did the same thing, looking > >>>>>> cdrom as > >>>>>> latest thing before xenbug trace in qemu log I tried also to remove > >>>>>> it but > >>>>>> also in this case don't boot correctly, full qemu log in attachment. > >>>>>> I don't know if is a ovmf thing to improve (like what seems in > >>>>>> Laszlo and > >>>>>> Kevin mails) or xen winpv drivers unexpected case, have you tried also > >>>>>> with > >>>>>> latest winpv builds? (for exclude regression) > >>>>> No, I did not tried the latest winpv drivers. > >>>>> > >>>>> Sorry I can help much more that that. When I install this win8 guest > >>>>> tried > >>>>> to boot it with pv drivers only, that was more than a year ago. I > >>>>> have not > >>>>> check if it's still working. (Also I can not try anything more recent, > >>>>> right now.) > >>>>> > >>>> I did many other tests, retrying with ide first boot working but show pv > >>>> devices not working, I did another reboot (with ide) and pv devices was > >>>> working, after I retried with pv (xvdX) and boot correctly. > >>>> After other tests I found that with empty cdrom device (required for xl > >>>> cd-insert/cd-eject) boot stop at start (tianocore image), same result > >>>> with ide > >>>> instead. > >>>> From xl cfg: > >>>> disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom'] > >>>> > >>>> With seabios domU boot also with empty cdrom. > >>>> In qemu log I found only these that can be related: > >>>>> xen be: qdisk-51728: error: Could not open image: No such file or > >>>>> directory > >>>>> xen be: qdisk-51728: initialise() failed > >>>> And latest xl dmesg line is: > >>>>> (d1) Invoking OVMF ... > >>>> If you need more informations/test tell me and I'll post them. > >>> Are you saying that without any cdrom drives, it works correctly? > >> Yes, I did also another test to be sure, starting with ide, installing > >> windows, the pv drivers, rebooting 2 times (with one at boot of time > >> boot with ide only and without net and disks pv drivers working) and > >> after rebooting with pv disks (xvdX) works. > >> With cdrom not empty (with iso) works, with empty not, tried with both > >> ide (hdX) and pv (xvdX). > >> Empty cdrom not working with ovmf I suppose is ovmf bug or inexpected case. > >> About major of winpv drivers problem at boot I suppose can be solved > >> improving ovmf and winpv driver removing bad hybrid thing actually, but > >> I have too low knowledge to be sure. > >> About the problem of pv start after install that requiring at least 2 > >> reboot can be also a windows 10 problem (only a suppose). > >> > >> About empty cdrom with ovmf can be solved please? > >> > > > > Sorry, I find your problem report impenetrable. :( Please slow down and > > try to spend time on punctuation at least. > > > > For me to make heads or tails of this, I'll need the following: > > > > - The debug output of an OVMF binary built with the DEBUG_VERBOSE bit > > (0x00400000) enabled in PcdDebugPrintErrorLevel, in addition to the > > default setting. > > > > - Preferably, I'll need two logs, one for the "working" case, and > > another for the "non-working" case. > > > > - A description of the virtual hardware (disks etc) that is > > understandable to someone who hasn't booted Xen in several years; for > > both cases above. > > > > - Please try to make an exact, itemized list of the steps you perform > > before executing the successful vs. failing test. > > > > - It would also help if you entered the UEFI shell in both the > > successful and the failing case, and ran the MAP command. The output can > > be snarfed from the virtual serial port too. > > > > - another command to run from the UEFI shell, in both cases: > > > > dh -d -v -p SimpleFileSystem > > Okay, despite none of the info having surfaced that I asked for, John > and I continued discussing this. Many thanks for spending time on this > >From the vague memories of a RHEL-5 Xen dom0 bug (blkback) that I fixed > on Aug 19 *2011*, I now managed to remember the VDISK_CDROM flag, and > that we had had many issues with CD-ROMs. > > So I looked at the current guest kernel driver now, > "drivers/block/xen-blkfront.c", to see if there were any CD-ROM related > "hacks" in place still. Apparently so; please consider the following > "git blame" snippet (excuse me for the long lines), from the > blkfront_probe() function: > > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1427) if (xen_hvm_domain()) { > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1428) char *type; > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1429) int len; > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1430) /* no unplug has been done: do not hook devices != xen vbds */ > 51c71a3b (Konrad Rzeszutek Wilk 2013-11-26 15:05:40 -0500 1431) if (xen_has_pv_and_legacy_disk_devices()) { > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1432) int major; > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1433) > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1434) if (!VDEV_IS_EXTENDED(vdevice)) > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1435) major = BLKIF_MAJOR(vdevice); > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1436) else > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1437) major = XENVBD_MAJOR; > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1438) > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1439) if (major != XENVBD_MAJOR) { > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1440) printk(KERN_INFO > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1441) "%s: HVM does not support vbd %d as xen block device\n", > 02f1f217 (Rasmus Villemoes 2015-02-12 15:01:31 -0800 1442) __func__, vdevice); > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1443) return -ENODEV; > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1444) } > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1445) } > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1446) /* do not create a PV cdrom device if we are an HVM guest */ > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1447) type = xenbus_read(XBT_NIL, dev->nodename, "device-type", &len); > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1448) if (IS_ERR(type)) > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1449) return -ENODEV; > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1450) if (strncmp(type, "cdrom", 5) == 0) { > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1451) kfree(type); > c1c5413a (Stefano Stabellini 2010-05-14 12:44:30 +0100 1452) return -ENODEV; > c1c5413a (Stefano Stabellini 2010-05-14 12:44:30 +0100 1453) } > b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1454) kfree(type); > c1c5413a (Stefano Stabellini 2010-05-14 12:44:30 +0100 1455) } /me hides in a corner > Side point: commit 51c71a3b from Konrad > <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=51c71a3b> > should be instrumental for those who are looking for more background on > emulated device / driver unplugging in Xen domUs. > > But, the really interesting bit here is the commit message of b98a409b > <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b98a409b>, > from 2010, authored by Stefano: > > blkfront: do not create a PV cdrom device if xen_hvm_guest > > It is not possible to unplug emulated cdrom devices, and PV cdroms don't > handle media insert, eject and stream, so we are better off disabling PV > cdroms when running as a Xen HVM guest. I think it all comes from the way PV drivers for HVM guests were originally written: the cdrom device was emulated rather than paravirtualized. So the unplug protocol in QEMU was implemented like this: int pci_piix3_xen_ide_unplug(DeviceState *dev) { PCIIDEState *pci_ide; DriveInfo *di; int i; IDEDevice *idedev; pci_ide = PCI_IDE(dev); for (i = 0; i < 4; i++) { di = drive_get_by_index(IF_IDE, i); if (di != NULL && !di->media_cd) { <unplug> In particular see the !di->media_cd. As a consequence cdroms are left emulated. Given that they cannot be unplugged and given that the PV block protocol is lacking in terms of cdrom-like functionalities, I disabled blkfront in Linux for PV interfaces corresponding to cdrom devices. But it could work. > Could that be related to the issue you are experiencing with OVMF? > Because, OVMF implies HVM (or PV-on-HVM), and your report ("empty > paravirt CD-ROM" or some such -- sorry, the report remains unclear) > appears to match the above message. > > Given that this is guest code, shouldn't the same logic be mirrored in > the OVMF guest driver? > > /* do not create a PV cdrom device if we are an HVM guest */ > > In other words, given that OVMF implies HVM, shouldn't OVMF too forego > driving a paravirt CD-ROM entirely? In the case of OVMF I think we can use the PV block interface to access the cdrom, the problem is just that it cannot handle empty cdrom drives at the moment and XenPvBlockFrontInitialization simply returns an error. A simple patch like this one should prevent OVMF from getting stuck with an error when an empty cdrom is found: diff --git a/OvmfPkg/XenPvBlkDxe/BlockFront.c b/OvmfPkg/XenPvBlkDxe/BlockFront.c index 256ac55..ae7cab9 100644 --- a/OvmfPkg/XenPvBlkDxe/BlockFront.c +++ b/OvmfPkg/XenPvBlkDxe/BlockFront.c @@ -186,6 +186,10 @@ XenPvBlockFrontInitialization ( } FreePool (DeviceType); + Status = XenBusReadUint64 (XenBusIo, "sectors", TRUE, &Value); + if (Dev->MediaInfo.CdRom && Status != XENSTORE_STATUS_SUCCESS) + return EFI_NO_MEDIA; + Status = XenBusReadUint64 (XenBusIo, "backend-id", FALSE, &Value); if (Status != XENSTORE_STATUS_SUCCESS || Value > MAX_UINT16) { DEBUG ((EFI_D_ERROR, "XenPvBlk: Failed to get backend-id (%d)\n", > Now, the Xen guest code in OVMF, from > <https://github.com/tianocore/edk2/commit/5cce8524>, function > XenPvBlockFrontInitialization(), *does* look for "cdrom" in > "device-type": > > XenBusIo->XsRead (XenBusIo, XST_NIL, "device-type", (VOID**)&DeviceType); > if (AsciiStrCmp (DeviceType, "cdrom") == 0) { > Dev->MediaInfo.CdRom = TRUE; > } else { > Dev->MediaInfo.CdRom = FALSE; > } > > but the *only* thing that the CdRom field is used for is to force a 2KB > block size in XenPvBlkDxeDriverBindingStart(), for ElTorito > compatibility: > > if (Dev->MediaInfo.CdRom) { > // > // If it's a cdrom, the blocksize value need to be 2048 for OVMF to > // recognize it as a cdrom: > // MdeModulePkg/Universal/Disk/PartitionDxe/ElTorito.c > // > Media->BlockSize = 2048; > Media->LastBlock = DivU64x32 (Dev->MediaInfo.Sectors, > Media->BlockSize / Dev->MediaInfo.SectorSize) - 1; > } else { > > While in the same situation (i.e., in an HVM guest), the guest kernel > driver does not report a paravirt CD-ROM at all; instead it forces an > emulated (IDE) CD-ROM. > > ... Sorry if the above turns out fully irrelevant, but I still have no > info from you to go on. Actually it was helpful, thank you. ^ permalink raw reply related [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-20 11:59 ` Stefano Stabellini @ 2015-10-20 12:45 ` Laszlo Ersek 2015-10-20 12:45 ` Laszlo Ersek 1 sibling, 0 replies; 95+ messages in thread From: Laszlo Ersek @ 2015-10-20 12:45 UTC (permalink / raw) To: Stefano Stabellini Cc: Kevin Wolf, qemu-block, Jordan Justen (Intel address), qemu-devel, xen-devel, Fabio Fantoni, Paul Durrant, Samuel Thibault, Anthony PERARD, John Snow On 10/20/15 13:59, Stefano Stabellini wrote: > On Mon, 19 Oct 2015, Laszlo Ersek wrote: >> On 10/16/15 21:09, Laszlo Ersek wrote: >>> On 10/16/15 13:34, Fabio Fantoni wrote: >>>> Il 16/10/2015 12:47, Stefano Stabellini ha scritto: >>>>> On Fri, 16 Oct 2015, Fabio Fantoni wrote: >>>>>> Il 16/10/2015 12:13, Anthony PERARD ha scritto: >>>>>>> On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote: >>>>>>>> Il 15/10/2015 20:02, Anthony PERARD ha scritto: >>>>>>>>> On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: >>>>>>>>>> Il 14/10/2015 13:06, Stefano Stabellini ha scritto: >>>>>>>>>>> I would suggest Fabio to avoid AHCI disks altogether and just use >>>>>>>>>>> OVMF >>>>>>>>>>> with PV disks only and Anthony's patch to libxl to avoid creating >>>>>>>>>>> any >>>>>>>>>>> IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. >>>>>>>>>>> >>>>>>>>>>> Would that work for you? >>>>>>>>>> Thanks for the advice, I tried it: >>>>>>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 >>>>>>>>>> >>>>>>>>>> I installed W10 pro 64 bit with ide disk, installed the win pv >>>>>>>>>> drivers >>>>>>>>>> and >>>>>>>>>> after changed to xvdX instead hdX, is the only change needed, right? >>>>>>>>>> Initial boot is ok (ovmf part about pv disks seems ok) but windows >>>>>>>>>> boot >>>>>>>>>> fails with problem with pv drivers. >>>>>>>>>> In attachment full qemu log with xen_platform trace and domU's xl >>>>>>>>>> cfg. >>>>>>>>>> >>>>>>>>>> Someone have windows domUs with ovmf and pv disks only working? >>>>>>>>>> If yes >>>>>>>>>> can >>>>>>>>>> tell me the difference to understand what can be the problem please? >>>>>>>>> When I worked on the PV disk implementation in OVMF, I was able to >>>>>>>>> boot >>>>>>>>> a Windows 8 with pv disk only. >>>>>>>>> >>>>>>>>> I don't have access to the guest configuration I was using, but I >>>>>>>>> think >>>>>>>>> one >>>>>>>>> difference would be the viridian setting, I'm pretty sure I did >>>>>>>>> not set >>>>>>>>> it. >>>>>>>>> >>>>>>>> I tried with viridian disabled but did the same thing, looking >>>>>>>> cdrom as >>>>>>>> latest thing before xenbug trace in qemu log I tried also to remove >>>>>>>> it but >>>>>>>> also in this case don't boot correctly, full qemu log in attachment. >>>>>>>> I don't know if is a ovmf thing to improve (like what seems in >>>>>>>> Laszlo and >>>>>>>> Kevin mails) or xen winpv drivers unexpected case, have you tried also >>>>>>>> with >>>>>>>> latest winpv builds? (for exclude regression) >>>>>>> No, I did not tried the latest winpv drivers. >>>>>>> >>>>>>> Sorry I can help much more that that. When I install this win8 guest >>>>>>> tried >>>>>>> to boot it with pv drivers only, that was more than a year ago. I >>>>>>> have not >>>>>>> check if it's still working. (Also I can not try anything more recent, >>>>>>> right now.) >>>>>>> >>>>>> I did many other tests, retrying with ide first boot working but show pv >>>>>> devices not working, I did another reboot (with ide) and pv devices was >>>>>> working, after I retried with pv (xvdX) and boot correctly. >>>>>> After other tests I found that with empty cdrom device (required for xl >>>>>> cd-insert/cd-eject) boot stop at start (tianocore image), same result >>>>>> with ide >>>>>> instead. >>>>>> From xl cfg: >>>>>> disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom'] >>>>>> >>>>>> With seabios domU boot also with empty cdrom. >>>>>> In qemu log I found only these that can be related: >>>>>>> xen be: qdisk-51728: error: Could not open image: No such file or >>>>>>> directory >>>>>>> xen be: qdisk-51728: initialise() failed >>>>>> And latest xl dmesg line is: >>>>>>> (d1) Invoking OVMF ... >>>>>> If you need more informations/test tell me and I'll post them. >>>>> Are you saying that without any cdrom drives, it works correctly? >>>> Yes, I did also another test to be sure, starting with ide, installing >>>> windows, the pv drivers, rebooting 2 times (with one at boot of time >>>> boot with ide only and without net and disks pv drivers working) and >>>> after rebooting with pv disks (xvdX) works. >>>> With cdrom not empty (with iso) works, with empty not, tried with both >>>> ide (hdX) and pv (xvdX). >>>> Empty cdrom not working with ovmf I suppose is ovmf bug or inexpected case. >>>> About major of winpv drivers problem at boot I suppose can be solved >>>> improving ovmf and winpv driver removing bad hybrid thing actually, but >>>> I have too low knowledge to be sure. >>>> About the problem of pv start after install that requiring at least 2 >>>> reboot can be also a windows 10 problem (only a suppose). >>>> >>>> About empty cdrom with ovmf can be solved please? >>>> >>> >>> Sorry, I find your problem report impenetrable. :( Please slow down and >>> try to spend time on punctuation at least. >>> >>> For me to make heads or tails of this, I'll need the following: >>> >>> - The debug output of an OVMF binary built with the DEBUG_VERBOSE bit >>> (0x00400000) enabled in PcdDebugPrintErrorLevel, in addition to the >>> default setting. >>> >>> - Preferably, I'll need two logs, one for the "working" case, and >>> another for the "non-working" case. >>> >>> - A description of the virtual hardware (disks etc) that is >>> understandable to someone who hasn't booted Xen in several years; for >>> both cases above. >>> >>> - Please try to make an exact, itemized list of the steps you perform >>> before executing the successful vs. failing test. >>> >>> - It would also help if you entered the UEFI shell in both the >>> successful and the failing case, and ran the MAP command. The output can >>> be snarfed from the virtual serial port too. >>> >>> - another command to run from the UEFI shell, in both cases: >>> >>> dh -d -v -p SimpleFileSystem >> >> Okay, despite none of the info having surfaced that I asked for, John >> and I continued discussing this. > > Many thanks for spending time on this > > >> >From the vague memories of a RHEL-5 Xen dom0 bug (blkback) that I fixed >> on Aug 19 *2011*, I now managed to remember the VDISK_CDROM flag, and >> that we had had many issues with CD-ROMs. >> >> So I looked at the current guest kernel driver now, >> "drivers/block/xen-blkfront.c", to see if there were any CD-ROM related >> "hacks" in place still. Apparently so; please consider the following >> "git blame" snippet (excuse me for the long lines), from the >> blkfront_probe() function: >> >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1427) if (xen_hvm_domain()) { >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1428) char *type; >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1429) int len; >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1430) /* no unplug has been done: do not hook devices != xen vbds */ >> 51c71a3b (Konrad Rzeszutek Wilk 2013-11-26 15:05:40 -0500 1431) if (xen_has_pv_and_legacy_disk_devices()) { >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1432) int major; >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1433) >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1434) if (!VDEV_IS_EXTENDED(vdevice)) >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1435) major = BLKIF_MAJOR(vdevice); >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1436) else >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1437) major = XENVBD_MAJOR; >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1438) >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1439) if (major != XENVBD_MAJOR) { >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1440) printk(KERN_INFO >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1441) "%s: HVM does not support vbd %d as xen block device\n", >> 02f1f217 (Rasmus Villemoes 2015-02-12 15:01:31 -0800 1442) __func__, vdevice); >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1443) return -ENODEV; >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1444) } >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1445) } >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1446) /* do not create a PV cdrom device if we are an HVM guest */ >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1447) type = xenbus_read(XBT_NIL, dev->nodename, "device-type", &len); >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1448) if (IS_ERR(type)) >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1449) return -ENODEV; >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1450) if (strncmp(type, "cdrom", 5) == 0) { >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1451) kfree(type); >> c1c5413a (Stefano Stabellini 2010-05-14 12:44:30 +0100 1452) return -ENODEV; >> c1c5413a (Stefano Stabellini 2010-05-14 12:44:30 +0100 1453) } >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1454) kfree(type); >> c1c5413a (Stefano Stabellini 2010-05-14 12:44:30 +0100 1455) } > > /me hides in a corner > > >> Side point: commit 51c71a3b from Konrad >> <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=51c71a3b> >> should be instrumental for those who are looking for more background on >> emulated device / driver unplugging in Xen domUs. >> >> But, the really interesting bit here is the commit message of b98a409b >> <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b98a409b>, >> from 2010, authored by Stefano: >> >> blkfront: do not create a PV cdrom device if xen_hvm_guest >> >> It is not possible to unplug emulated cdrom devices, and PV cdroms don't >> handle media insert, eject and stream, so we are better off disabling PV >> cdroms when running as a Xen HVM guest. > > I think it all comes from the way PV drivers for HVM guests were > originally written: the cdrom device was emulated rather than > paravirtualized. So the unplug protocol in QEMU was implemented like > this: > > int pci_piix3_xen_ide_unplug(DeviceState *dev) > { > PCIIDEState *pci_ide; > DriveInfo *di; > int i; > IDEDevice *idedev; > > pci_ide = PCI_IDE(dev); > > for (i = 0; i < 4; i++) { > di = drive_get_by_index(IF_IDE, i); > if (di != NULL && !di->media_cd) { > <unplug> > > In particular see the !di->media_cd. As a consequence cdroms are left > emulated. Given that they cannot be unplugged and given that the PV > block protocol is lacking in terms of cdrom-like functionalities, I > disabled blkfront in Linux for PV interfaces corresponding to cdrom > devices. But it could work. > > >> Could that be related to the issue you are experiencing with OVMF? >> Because, OVMF implies HVM (or PV-on-HVM), and your report ("empty >> paravirt CD-ROM" or some such -- sorry, the report remains unclear) >> appears to match the above message. >> >> Given that this is guest code, shouldn't the same logic be mirrored in >> the OVMF guest driver? >> >> /* do not create a PV cdrom device if we are an HVM guest */ >> >> In other words, given that OVMF implies HVM, shouldn't OVMF too forego >> driving a paravirt CD-ROM entirely? > > In the case of OVMF I think we can use the PV block interface to access > the cdrom, the problem is just that it cannot handle empty cdrom drives > at the moment and XenPvBlockFrontInitialization simply returns an error. (*) > A simple patch like this one should prevent OVMF from getting stuck with > an error when an empty cdrom is found: > > diff --git a/OvmfPkg/XenPvBlkDxe/BlockFront.c b/OvmfPkg/XenPvBlkDxe/BlockFront.c > index 256ac55..ae7cab9 100644 > --- a/OvmfPkg/XenPvBlkDxe/BlockFront.c > +++ b/OvmfPkg/XenPvBlkDxe/BlockFront.c > @@ -186,6 +186,10 @@ XenPvBlockFrontInitialization ( > } > FreePool (DeviceType); > > + Status = XenBusReadUint64 (XenBusIo, "sectors", TRUE, &Value); > + if (Dev->MediaInfo.CdRom && Status != XENSTORE_STATUS_SUCCESS) > + return EFI_NO_MEDIA; > + > Status = XenBusReadUint64 (XenBusIo, "backend-id", FALSE, &Value); > if (Status != XENSTORE_STATUS_SUCCESS || Value > MAX_UINT16) { > DEBUG ((EFI_D_ERROR, "XenPvBlk: Failed to get backend-id (%d)\n", (1) Directly returning at that point will leak "Dev". I think you should set Status, and then goto Error. XenPvBlockFree() under that label will free Dev. (2) I agree that returning an error code here will propagate through XenPvBlkDxeDriverBindingStart() to the caller, and ultimately prevent the binding. That's probably the right thing to do. But, how does it differ from what you wrote above (*): > [...] the problem is just that it cannot handle empty cdrom drives > at the moment and XenPvBlockFrontInitialization simply returns an > error. If XenPvBlockFrontInitialization() simply returned an error right now, then that would achieve the exact same thing as your proposal -- the driver wouldn't bind the device. So either your idea wouldn't make a difference, or your analysis that XenPvBlockFrontInitialization() currently fails is incorrect. I think it's the latter though, and that this patch should be tested. If it works in your testing, please submit it to <edk2-devel@lists.01.org>. (You have to be subscribed to post, sorry about that.) Please fix the leak (1), and add the following line to the commit message just before your signoff: Contributed-under: TianoCore Contribution Agreement 1.0 What it means is explained in "OvmfPkg/Contributions.txt". Thank you! Laszlo > > >> Now, the Xen guest code in OVMF, from >> <https://github.com/tianocore/edk2/commit/5cce8524>, function >> XenPvBlockFrontInitialization(), *does* look for "cdrom" in >> "device-type": >> >> XenBusIo->XsRead (XenBusIo, XST_NIL, "device-type", (VOID**)&DeviceType); >> if (AsciiStrCmp (DeviceType, "cdrom") == 0) { >> Dev->MediaInfo.CdRom = TRUE; >> } else { >> Dev->MediaInfo.CdRom = FALSE; >> } >> >> but the *only* thing that the CdRom field is used for is to force a 2KB >> block size in XenPvBlkDxeDriverBindingStart(), for ElTorito >> compatibility: >> >> if (Dev->MediaInfo.CdRom) { >> // >> // If it's a cdrom, the blocksize value need to be 2048 for OVMF to >> // recognize it as a cdrom: >> // MdeModulePkg/Universal/Disk/PartitionDxe/ElTorito.c >> // >> Media->BlockSize = 2048; >> Media->LastBlock = DivU64x32 (Dev->MediaInfo.Sectors, >> Media->BlockSize / Dev->MediaInfo.SectorSize) - 1; >> } else { >> >> While in the same situation (i.e., in an HVM guest), the guest kernel >> driver does not report a paravirt CD-ROM at all; instead it forces an >> emulated (IDE) CD-ROM. >> >> ... Sorry if the above turns out fully irrelevant, but I still have no >> info from you to go on. > > Actually it was helpful, thank you. > ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-20 11:59 ` Stefano Stabellini 2015-10-20 12:45 ` Laszlo Ersek @ 2015-10-20 12:45 ` Laszlo Ersek 2015-10-20 14:52 ` Stefano Stabellini 2015-10-20 14:52 ` Stefano Stabellini 1 sibling, 2 replies; 95+ messages in thread From: Laszlo Ersek @ 2015-10-20 12:45 UTC (permalink / raw) To: Stefano Stabellini Cc: Kevin Wolf, qemu-block, Jordan Justen (Intel address), qemu-devel, xen-devel, Fabio Fantoni, Paul Durrant, Samuel Thibault, Anthony PERARD, John Snow On 10/20/15 13:59, Stefano Stabellini wrote: > On Mon, 19 Oct 2015, Laszlo Ersek wrote: >> On 10/16/15 21:09, Laszlo Ersek wrote: >>> On 10/16/15 13:34, Fabio Fantoni wrote: >>>> Il 16/10/2015 12:47, Stefano Stabellini ha scritto: >>>>> On Fri, 16 Oct 2015, Fabio Fantoni wrote: >>>>>> Il 16/10/2015 12:13, Anthony PERARD ha scritto: >>>>>>> On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote: >>>>>>>> Il 15/10/2015 20:02, Anthony PERARD ha scritto: >>>>>>>>> On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: >>>>>>>>>> Il 14/10/2015 13:06, Stefano Stabellini ha scritto: >>>>>>>>>>> I would suggest Fabio to avoid AHCI disks altogether and just use >>>>>>>>>>> OVMF >>>>>>>>>>> with PV disks only and Anthony's patch to libxl to avoid creating >>>>>>>>>>> any >>>>>>>>>>> IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. >>>>>>>>>>> >>>>>>>>>>> Would that work for you? >>>>>>>>>> Thanks for the advice, I tried it: >>>>>>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 >>>>>>>>>> >>>>>>>>>> I installed W10 pro 64 bit with ide disk, installed the win pv >>>>>>>>>> drivers >>>>>>>>>> and >>>>>>>>>> after changed to xvdX instead hdX, is the only change needed, right? >>>>>>>>>> Initial boot is ok (ovmf part about pv disks seems ok) but windows >>>>>>>>>> boot >>>>>>>>>> fails with problem with pv drivers. >>>>>>>>>> In attachment full qemu log with xen_platform trace and domU's xl >>>>>>>>>> cfg. >>>>>>>>>> >>>>>>>>>> Someone have windows domUs with ovmf and pv disks only working? >>>>>>>>>> If yes >>>>>>>>>> can >>>>>>>>>> tell me the difference to understand what can be the problem please? >>>>>>>>> When I worked on the PV disk implementation in OVMF, I was able to >>>>>>>>> boot >>>>>>>>> a Windows 8 with pv disk only. >>>>>>>>> >>>>>>>>> I don't have access to the guest configuration I was using, but I >>>>>>>>> think >>>>>>>>> one >>>>>>>>> difference would be the viridian setting, I'm pretty sure I did >>>>>>>>> not set >>>>>>>>> it. >>>>>>>>> >>>>>>>> I tried with viridian disabled but did the same thing, looking >>>>>>>> cdrom as >>>>>>>> latest thing before xenbug trace in qemu log I tried also to remove >>>>>>>> it but >>>>>>>> also in this case don't boot correctly, full qemu log in attachment. >>>>>>>> I don't know if is a ovmf thing to improve (like what seems in >>>>>>>> Laszlo and >>>>>>>> Kevin mails) or xen winpv drivers unexpected case, have you tried also >>>>>>>> with >>>>>>>> latest winpv builds? (for exclude regression) >>>>>>> No, I did not tried the latest winpv drivers. >>>>>>> >>>>>>> Sorry I can help much more that that. When I install this win8 guest >>>>>>> tried >>>>>>> to boot it with pv drivers only, that was more than a year ago. I >>>>>>> have not >>>>>>> check if it's still working. (Also I can not try anything more recent, >>>>>>> right now.) >>>>>>> >>>>>> I did many other tests, retrying with ide first boot working but show pv >>>>>> devices not working, I did another reboot (with ide) and pv devices was >>>>>> working, after I retried with pv (xvdX) and boot correctly. >>>>>> After other tests I found that with empty cdrom device (required for xl >>>>>> cd-insert/cd-eject) boot stop at start (tianocore image), same result >>>>>> with ide >>>>>> instead. >>>>>> From xl cfg: >>>>>> disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom'] >>>>>> >>>>>> With seabios domU boot also with empty cdrom. >>>>>> In qemu log I found only these that can be related: >>>>>>> xen be: qdisk-51728: error: Could not open image: No such file or >>>>>>> directory >>>>>>> xen be: qdisk-51728: initialise() failed >>>>>> And latest xl dmesg line is: >>>>>>> (d1) Invoking OVMF ... >>>>>> If you need more informations/test tell me and I'll post them. >>>>> Are you saying that without any cdrom drives, it works correctly? >>>> Yes, I did also another test to be sure, starting with ide, installing >>>> windows, the pv drivers, rebooting 2 times (with one at boot of time >>>> boot with ide only and without net and disks pv drivers working) and >>>> after rebooting with pv disks (xvdX) works. >>>> With cdrom not empty (with iso) works, with empty not, tried with both >>>> ide (hdX) and pv (xvdX). >>>> Empty cdrom not working with ovmf I suppose is ovmf bug or inexpected case. >>>> About major of winpv drivers problem at boot I suppose can be solved >>>> improving ovmf and winpv driver removing bad hybrid thing actually, but >>>> I have too low knowledge to be sure. >>>> About the problem of pv start after install that requiring at least 2 >>>> reboot can be also a windows 10 problem (only a suppose). >>>> >>>> About empty cdrom with ovmf can be solved please? >>>> >>> >>> Sorry, I find your problem report impenetrable. :( Please slow down and >>> try to spend time on punctuation at least. >>> >>> For me to make heads or tails of this, I'll need the following: >>> >>> - The debug output of an OVMF binary built with the DEBUG_VERBOSE bit >>> (0x00400000) enabled in PcdDebugPrintErrorLevel, in addition to the >>> default setting. >>> >>> - Preferably, I'll need two logs, one for the "working" case, and >>> another for the "non-working" case. >>> >>> - A description of the virtual hardware (disks etc) that is >>> understandable to someone who hasn't booted Xen in several years; for >>> both cases above. >>> >>> - Please try to make an exact, itemized list of the steps you perform >>> before executing the successful vs. failing test. >>> >>> - It would also help if you entered the UEFI shell in both the >>> successful and the failing case, and ran the MAP command. The output can >>> be snarfed from the virtual serial port too. >>> >>> - another command to run from the UEFI shell, in both cases: >>> >>> dh -d -v -p SimpleFileSystem >> >> Okay, despite none of the info having surfaced that I asked for, John >> and I continued discussing this. > > Many thanks for spending time on this > > >> >From the vague memories of a RHEL-5 Xen dom0 bug (blkback) that I fixed >> on Aug 19 *2011*, I now managed to remember the VDISK_CDROM flag, and >> that we had had many issues with CD-ROMs. >> >> So I looked at the current guest kernel driver now, >> "drivers/block/xen-blkfront.c", to see if there were any CD-ROM related >> "hacks" in place still. Apparently so; please consider the following >> "git blame" snippet (excuse me for the long lines), from the >> blkfront_probe() function: >> >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1427) if (xen_hvm_domain()) { >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1428) char *type; >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1429) int len; >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1430) /* no unplug has been done: do not hook devices != xen vbds */ >> 51c71a3b (Konrad Rzeszutek Wilk 2013-11-26 15:05:40 -0500 1431) if (xen_has_pv_and_legacy_disk_devices()) { >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1432) int major; >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1433) >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1434) if (!VDEV_IS_EXTENDED(vdevice)) >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1435) major = BLKIF_MAJOR(vdevice); >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1436) else >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1437) major = XENVBD_MAJOR; >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1438) >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1439) if (major != XENVBD_MAJOR) { >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1440) printk(KERN_INFO >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1441) "%s: HVM does not support vbd %d as xen block device\n", >> 02f1f217 (Rasmus Villemoes 2015-02-12 15:01:31 -0800 1442) __func__, vdevice); >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1443) return -ENODEV; >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1444) } >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1445) } >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1446) /* do not create a PV cdrom device if we are an HVM guest */ >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1447) type = xenbus_read(XBT_NIL, dev->nodename, "device-type", &len); >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1448) if (IS_ERR(type)) >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1449) return -ENODEV; >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1450) if (strncmp(type, "cdrom", 5) == 0) { >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1451) kfree(type); >> c1c5413a (Stefano Stabellini 2010-05-14 12:44:30 +0100 1452) return -ENODEV; >> c1c5413a (Stefano Stabellini 2010-05-14 12:44:30 +0100 1453) } >> b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1454) kfree(type); >> c1c5413a (Stefano Stabellini 2010-05-14 12:44:30 +0100 1455) } > > /me hides in a corner > > >> Side point: commit 51c71a3b from Konrad >> <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=51c71a3b> >> should be instrumental for those who are looking for more background on >> emulated device / driver unplugging in Xen domUs. >> >> But, the really interesting bit here is the commit message of b98a409b >> <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b98a409b>, >> from 2010, authored by Stefano: >> >> blkfront: do not create a PV cdrom device if xen_hvm_guest >> >> It is not possible to unplug emulated cdrom devices, and PV cdroms don't >> handle media insert, eject and stream, so we are better off disabling PV >> cdroms when running as a Xen HVM guest. > > I think it all comes from the way PV drivers for HVM guests were > originally written: the cdrom device was emulated rather than > paravirtualized. So the unplug protocol in QEMU was implemented like > this: > > int pci_piix3_xen_ide_unplug(DeviceState *dev) > { > PCIIDEState *pci_ide; > DriveInfo *di; > int i; > IDEDevice *idedev; > > pci_ide = PCI_IDE(dev); > > for (i = 0; i < 4; i++) { > di = drive_get_by_index(IF_IDE, i); > if (di != NULL && !di->media_cd) { > <unplug> > > In particular see the !di->media_cd. As a consequence cdroms are left > emulated. Given that they cannot be unplugged and given that the PV > block protocol is lacking in terms of cdrom-like functionalities, I > disabled blkfront in Linux for PV interfaces corresponding to cdrom > devices. But it could work. > > >> Could that be related to the issue you are experiencing with OVMF? >> Because, OVMF implies HVM (or PV-on-HVM), and your report ("empty >> paravirt CD-ROM" or some such -- sorry, the report remains unclear) >> appears to match the above message. >> >> Given that this is guest code, shouldn't the same logic be mirrored in >> the OVMF guest driver? >> >> /* do not create a PV cdrom device if we are an HVM guest */ >> >> In other words, given that OVMF implies HVM, shouldn't OVMF too forego >> driving a paravirt CD-ROM entirely? > > In the case of OVMF I think we can use the PV block interface to access > the cdrom, the problem is just that it cannot handle empty cdrom drives > at the moment and XenPvBlockFrontInitialization simply returns an error. (*) > A simple patch like this one should prevent OVMF from getting stuck with > an error when an empty cdrom is found: > > diff --git a/OvmfPkg/XenPvBlkDxe/BlockFront.c b/OvmfPkg/XenPvBlkDxe/BlockFront.c > index 256ac55..ae7cab9 100644 > --- a/OvmfPkg/XenPvBlkDxe/BlockFront.c > +++ b/OvmfPkg/XenPvBlkDxe/BlockFront.c > @@ -186,6 +186,10 @@ XenPvBlockFrontInitialization ( > } > FreePool (DeviceType); > > + Status = XenBusReadUint64 (XenBusIo, "sectors", TRUE, &Value); > + if (Dev->MediaInfo.CdRom && Status != XENSTORE_STATUS_SUCCESS) > + return EFI_NO_MEDIA; > + > Status = XenBusReadUint64 (XenBusIo, "backend-id", FALSE, &Value); > if (Status != XENSTORE_STATUS_SUCCESS || Value > MAX_UINT16) { > DEBUG ((EFI_D_ERROR, "XenPvBlk: Failed to get backend-id (%d)\n", (1) Directly returning at that point will leak "Dev". I think you should set Status, and then goto Error. XenPvBlockFree() under that label will free Dev. (2) I agree that returning an error code here will propagate through XenPvBlkDxeDriverBindingStart() to the caller, and ultimately prevent the binding. That's probably the right thing to do. But, how does it differ from what you wrote above (*): > [...] the problem is just that it cannot handle empty cdrom drives > at the moment and XenPvBlockFrontInitialization simply returns an > error. If XenPvBlockFrontInitialization() simply returned an error right now, then that would achieve the exact same thing as your proposal -- the driver wouldn't bind the device. So either your idea wouldn't make a difference, or your analysis that XenPvBlockFrontInitialization() currently fails is incorrect. I think it's the latter though, and that this patch should be tested. If it works in your testing, please submit it to <edk2-devel@lists.01.org>. (You have to be subscribed to post, sorry about that.) Please fix the leak (1), and add the following line to the commit message just before your signoff: Contributed-under: TianoCore Contribution Agreement 1.0 What it means is explained in "OvmfPkg/Contributions.txt". Thank you! Laszlo > > >> Now, the Xen guest code in OVMF, from >> <https://github.com/tianocore/edk2/commit/5cce8524>, function >> XenPvBlockFrontInitialization(), *does* look for "cdrom" in >> "device-type": >> >> XenBusIo->XsRead (XenBusIo, XST_NIL, "device-type", (VOID**)&DeviceType); >> if (AsciiStrCmp (DeviceType, "cdrom") == 0) { >> Dev->MediaInfo.CdRom = TRUE; >> } else { >> Dev->MediaInfo.CdRom = FALSE; >> } >> >> but the *only* thing that the CdRom field is used for is to force a 2KB >> block size in XenPvBlkDxeDriverBindingStart(), for ElTorito >> compatibility: >> >> if (Dev->MediaInfo.CdRom) { >> // >> // If it's a cdrom, the blocksize value need to be 2048 for OVMF to >> // recognize it as a cdrom: >> // MdeModulePkg/Universal/Disk/PartitionDxe/ElTorito.c >> // >> Media->BlockSize = 2048; >> Media->LastBlock = DivU64x32 (Dev->MediaInfo.Sectors, >> Media->BlockSize / Dev->MediaInfo.SectorSize) - 1; >> } else { >> >> While in the same situation (i.e., in an HVM guest), the guest kernel >> driver does not report a paravirt CD-ROM at all; instead it forces an >> emulated (IDE) CD-ROM. >> >> ... Sorry if the above turns out fully irrelevant, but I still have no >> info from you to go on. > > Actually it was helpful, thank you. > ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-20 12:45 ` Laszlo Ersek @ 2015-10-20 14:52 ` Stefano Stabellini 2015-10-20 14:52 ` Stefano Stabellini 1 sibling, 0 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-20 14:52 UTC (permalink / raw) To: Laszlo Ersek Cc: Kevin Wolf, qemu-block, Stefano Stabellini, Jordan Justen (Intel address), qemu-devel, xen-devel, Fabio Fantoni, Samuel Thibault, Anthony PERARD, John Snow, Paul Durrant On Tue, 20 Oct 2015, Laszlo Ersek wrote: > On 10/20/15 13:59, Stefano Stabellini wrote: > > On Mon, 19 Oct 2015, Laszlo Ersek wrote: > >> Could that be related to the issue you are experiencing with OVMF? > >> Because, OVMF implies HVM (or PV-on-HVM), and your report ("empty > >> paravirt CD-ROM" or some such -- sorry, the report remains unclear) > >> appears to match the above message. > >> > >> Given that this is guest code, shouldn't the same logic be mirrored in > >> the OVMF guest driver? > >> > >> /* do not create a PV cdrom device if we are an HVM guest */ > >> > >> In other words, given that OVMF implies HVM, shouldn't OVMF too forego > >> driving a paravirt CD-ROM entirely? > > > > In the case of OVMF I think we can use the PV block interface to access > > the cdrom, the problem is just that it cannot handle empty cdrom drives > > at the moment and XenPvBlockFrontInitialization simply returns an error. > > (*) > > > A simple patch like this one should prevent OVMF from getting stuck with > > an error when an empty cdrom is found: > > > > diff --git a/OvmfPkg/XenPvBlkDxe/BlockFront.c b/OvmfPkg/XenPvBlkDxe/BlockFront.c > > index 256ac55..ae7cab9 100644 > > --- a/OvmfPkg/XenPvBlkDxe/BlockFront.c > > +++ b/OvmfPkg/XenPvBlkDxe/BlockFront.c > > @@ -186,6 +186,10 @@ XenPvBlockFrontInitialization ( > > } > > FreePool (DeviceType); > > > > + Status = XenBusReadUint64 (XenBusIo, "sectors", TRUE, &Value); > > + if (Dev->MediaInfo.CdRom && Status != XENSTORE_STATUS_SUCCESS) > > + return EFI_NO_MEDIA; > > + > > Status = XenBusReadUint64 (XenBusIo, "backend-id", FALSE, &Value); > > if (Status != XENSTORE_STATUS_SUCCESS || Value > MAX_UINT16) { > > DEBUG ((EFI_D_ERROR, "XenPvBlk: Failed to get backend-id (%d)\n", > > (1) Directly returning at that point will leak "Dev". I think you should > set Status, and then goto Error. XenPvBlockFree() under that label will > free Dev. Good idea > (2) I agree that returning an error code here will propagate through > XenPvBlkDxeDriverBindingStart() to the caller, and ultimately prevent > the binding. That's probably the right thing to do. > > But, how does it differ from what you wrote above (*): > > > [...] the problem is just that it cannot handle empty cdrom drives > > at the moment and XenPvBlockFrontInitialization simply returns an > > error. > > If XenPvBlockFrontInitialization() simply returned an error right now, > then that would achieve the exact same thing as your proposal -- the > driver wouldn't bind the device. So either your idea wouldn't make a > difference, or your analysis that XenPvBlockFrontInitialization() > currently fails is incorrect. > > I think it's the latter though, and that this patch should be tested. The patch works, but you are right, the analysis of the problem was wrong: it gets stuck in XenPvBlkWaitForBackendState, rather than returning an error. > If it works in your testing, please submit it to > <edk2-devel@lists.01.org>. (You have to be subscribed to post, sorry > about that.) Please fix the leak (1), and add the following line to the > commit message just before your signoff: > > Contributed-under: TianoCore Contribution Agreement 1.0 > > What it means is explained in "OvmfPkg/Contributions.txt". I'll rework the patch and send it to the list. Thanks, Stefano ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-20 12:45 ` Laszlo Ersek 2015-10-20 14:52 ` Stefano Stabellini @ 2015-10-20 14:52 ` Stefano Stabellini 1 sibling, 0 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-20 14:52 UTC (permalink / raw) To: Laszlo Ersek Cc: Kevin Wolf, qemu-block, Stefano Stabellini, Jordan Justen (Intel address), qemu-devel, xen-devel, Fabio Fantoni, Samuel Thibault, Anthony PERARD, John Snow, Paul Durrant On Tue, 20 Oct 2015, Laszlo Ersek wrote: > On 10/20/15 13:59, Stefano Stabellini wrote: > > On Mon, 19 Oct 2015, Laszlo Ersek wrote: > >> Could that be related to the issue you are experiencing with OVMF? > >> Because, OVMF implies HVM (or PV-on-HVM), and your report ("empty > >> paravirt CD-ROM" or some such -- sorry, the report remains unclear) > >> appears to match the above message. > >> > >> Given that this is guest code, shouldn't the same logic be mirrored in > >> the OVMF guest driver? > >> > >> /* do not create a PV cdrom device if we are an HVM guest */ > >> > >> In other words, given that OVMF implies HVM, shouldn't OVMF too forego > >> driving a paravirt CD-ROM entirely? > > > > In the case of OVMF I think we can use the PV block interface to access > > the cdrom, the problem is just that it cannot handle empty cdrom drives > > at the moment and XenPvBlockFrontInitialization simply returns an error. > > (*) > > > A simple patch like this one should prevent OVMF from getting stuck with > > an error when an empty cdrom is found: > > > > diff --git a/OvmfPkg/XenPvBlkDxe/BlockFront.c b/OvmfPkg/XenPvBlkDxe/BlockFront.c > > index 256ac55..ae7cab9 100644 > > --- a/OvmfPkg/XenPvBlkDxe/BlockFront.c > > +++ b/OvmfPkg/XenPvBlkDxe/BlockFront.c > > @@ -186,6 +186,10 @@ XenPvBlockFrontInitialization ( > > } > > FreePool (DeviceType); > > > > + Status = XenBusReadUint64 (XenBusIo, "sectors", TRUE, &Value); > > + if (Dev->MediaInfo.CdRom && Status != XENSTORE_STATUS_SUCCESS) > > + return EFI_NO_MEDIA; > > + > > Status = XenBusReadUint64 (XenBusIo, "backend-id", FALSE, &Value); > > if (Status != XENSTORE_STATUS_SUCCESS || Value > MAX_UINT16) { > > DEBUG ((EFI_D_ERROR, "XenPvBlk: Failed to get backend-id (%d)\n", > > (1) Directly returning at that point will leak "Dev". I think you should > set Status, and then goto Error. XenPvBlockFree() under that label will > free Dev. Good idea > (2) I agree that returning an error code here will propagate through > XenPvBlkDxeDriverBindingStart() to the caller, and ultimately prevent > the binding. That's probably the right thing to do. > > But, how does it differ from what you wrote above (*): > > > [...] the problem is just that it cannot handle empty cdrom drives > > at the moment and XenPvBlockFrontInitialization simply returns an > > error. > > If XenPvBlockFrontInitialization() simply returned an error right now, > then that would achieve the exact same thing as your proposal -- the > driver wouldn't bind the device. So either your idea wouldn't make a > difference, or your analysis that XenPvBlockFrontInitialization() > currently fails is incorrect. > > I think it's the latter though, and that this patch should be tested. The patch works, but you are right, the analysis of the problem was wrong: it gets stuck in XenPvBlkWaitForBackendState, rather than returning an error. > If it works in your testing, please submit it to > <edk2-devel@lists.01.org>. (You have to be subscribed to post, sorry > about that.) Please fix the leak (1), and add the following line to the > commit message just before your signoff: > > Contributed-under: TianoCore Contribution Agreement 1.0 > > What it means is explained in "OvmfPkg/Contributions.txt". I'll rework the patch and send it to the list. Thanks, Stefano ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 19:09 ` Laszlo Ersek 2015-10-19 20:32 ` Laszlo Ersek @ 2015-10-19 20:32 ` Laszlo Ersek 1 sibling, 0 replies; 95+ messages in thread From: Laszlo Ersek @ 2015-10-19 20:32 UTC (permalink / raw) To: Fabio Fantoni, Stefano Stabellini Cc: Kevin Wolf, qemu-block, Jordan Justen (Intel address), qemu-devel, xen-devel, Paul Durrant, Samuel Thibault, Anthony PERARD, John Snow On 10/16/15 21:09, Laszlo Ersek wrote: > On 10/16/15 13:34, Fabio Fantoni wrote: >> Il 16/10/2015 12:47, Stefano Stabellini ha scritto: >>> On Fri, 16 Oct 2015, Fabio Fantoni wrote: >>>> Il 16/10/2015 12:13, Anthony PERARD ha scritto: >>>>> On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote: >>>>>> Il 15/10/2015 20:02, Anthony PERARD ha scritto: >>>>>>> On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: >>>>>>>> Il 14/10/2015 13:06, Stefano Stabellini ha scritto: >>>>>>>>> I would suggest Fabio to avoid AHCI disks altogether and just use >>>>>>>>> OVMF >>>>>>>>> with PV disks only and Anthony's patch to libxl to avoid creating >>>>>>>>> any >>>>>>>>> IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. >>>>>>>>> >>>>>>>>> Would that work for you? >>>>>>>> Thanks for the advice, I tried it: >>>>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 >>>>>>>> >>>>>>>> I installed W10 pro 64 bit with ide disk, installed the win pv >>>>>>>> drivers >>>>>>>> and >>>>>>>> after changed to xvdX instead hdX, is the only change needed, right? >>>>>>>> Initial boot is ok (ovmf part about pv disks seems ok) but windows >>>>>>>> boot >>>>>>>> fails with problem with pv drivers. >>>>>>>> In attachment full qemu log with xen_platform trace and domU's xl >>>>>>>> cfg. >>>>>>>> >>>>>>>> Someone have windows domUs with ovmf and pv disks only working? >>>>>>>> If yes >>>>>>>> can >>>>>>>> tell me the difference to understand what can be the problem please? >>>>>>> When I worked on the PV disk implementation in OVMF, I was able to >>>>>>> boot >>>>>>> a Windows 8 with pv disk only. >>>>>>> >>>>>>> I don't have access to the guest configuration I was using, but I >>>>>>> think >>>>>>> one >>>>>>> difference would be the viridian setting, I'm pretty sure I did >>>>>>> not set >>>>>>> it. >>>>>>> >>>>>> I tried with viridian disabled but did the same thing, looking >>>>>> cdrom as >>>>>> latest thing before xenbug trace in qemu log I tried also to remove >>>>>> it but >>>>>> also in this case don't boot correctly, full qemu log in attachment. >>>>>> I don't know if is a ovmf thing to improve (like what seems in >>>>>> Laszlo and >>>>>> Kevin mails) or xen winpv drivers unexpected case, have you tried also >>>>>> with >>>>>> latest winpv builds? (for exclude regression) >>>>> No, I did not tried the latest winpv drivers. >>>>> >>>>> Sorry I can help much more that that. When I install this win8 guest >>>>> tried >>>>> to boot it with pv drivers only, that was more than a year ago. I >>>>> have not >>>>> check if it's still working. (Also I can not try anything more recent, >>>>> right now.) >>>>> >>>> I did many other tests, retrying with ide first boot working but show pv >>>> devices not working, I did another reboot (with ide) and pv devices was >>>> working, after I retried with pv (xvdX) and boot correctly. >>>> After other tests I found that with empty cdrom device (required for xl >>>> cd-insert/cd-eject) boot stop at start (tianocore image), same result >>>> with ide >>>> instead. >>>> From xl cfg: >>>> disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom'] >>>> >>>> With seabios domU boot also with empty cdrom. >>>> In qemu log I found only these that can be related: >>>>> xen be: qdisk-51728: error: Could not open image: No such file or >>>>> directory >>>>> xen be: qdisk-51728: initialise() failed >>>> And latest xl dmesg line is: >>>>> (d1) Invoking OVMF ... >>>> If you need more informations/test tell me and I'll post them. >>> Are you saying that without any cdrom drives, it works correctly? >> Yes, I did also another test to be sure, starting with ide, installing >> windows, the pv drivers, rebooting 2 times (with one at boot of time >> boot with ide only and without net and disks pv drivers working) and >> after rebooting with pv disks (xvdX) works. >> With cdrom not empty (with iso) works, with empty not, tried with both >> ide (hdX) and pv (xvdX). >> Empty cdrom not working with ovmf I suppose is ovmf bug or inexpected case. >> About major of winpv drivers problem at boot I suppose can be solved >> improving ovmf and winpv driver removing bad hybrid thing actually, but >> I have too low knowledge to be sure. >> About the problem of pv start after install that requiring at least 2 >> reboot can be also a windows 10 problem (only a suppose). >> >> About empty cdrom with ovmf can be solved please? >> > > Sorry, I find your problem report impenetrable. :( Please slow down and > try to spend time on punctuation at least. > > For me to make heads or tails of this, I'll need the following: > > - The debug output of an OVMF binary built with the DEBUG_VERBOSE bit > (0x00400000) enabled in PcdDebugPrintErrorLevel, in addition to the > default setting. > > - Preferably, I'll need two logs, one for the "working" case, and > another for the "non-working" case. > > - A description of the virtual hardware (disks etc) that is > understandable to someone who hasn't booted Xen in several years; for > both cases above. > > - Please try to make an exact, itemized list of the steps you perform > before executing the successful vs. failing test. > > - It would also help if you entered the UEFI shell in both the > successful and the failing case, and ran the MAP command. The output can > be snarfed from the virtual serial port too. > > - another command to run from the UEFI shell, in both cases: > > dh -d -v -p SimpleFileSystem Okay, despite none of the info having surfaced that I asked for, John and I continued discussing this. >From the vague memories of a RHEL-5 Xen dom0 bug (blkback) that I fixed on Aug 19 *2011*, I now managed to remember the VDISK_CDROM flag, and that we had had many issues with CD-ROMs. So I looked at the current guest kernel driver now, "drivers/block/xen-blkfront.c", to see if there were any CD-ROM related "hacks" in place still. Apparently so; please consider the following "git blame" snippet (excuse me for the long lines), from the blkfront_probe() function: b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1427) if (xen_hvm_domain()) { b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1428) char *type; b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1429) int len; b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1430) /* no unplug has been done: do not hook devices != xen vbds */ 51c71a3b (Konrad Rzeszutek Wilk 2013-11-26 15:05:40 -0500 1431) if (xen_has_pv_and_legacy_disk_devices()) { b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1432) int major; b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1433) b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1434) if (!VDEV_IS_EXTENDED(vdevice)) b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1435) major = BLKIF_MAJOR(vdevice); b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1436) else b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1437) major = XENVBD_MAJOR; b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1438) b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1439) if (major != XENVBD_MAJOR) { b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1440) printk(KERN_INFO b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1441) "%s: HVM does not support vbd %d as xen block device\n", 02f1f217 (Rasmus Villemoes 2015-02-12 15:01:31 -0800 1442) __func__, vdevice); b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1443) return -ENODEV; b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1444) } b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1445) } b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1446) /* do not create a PV cdrom device if we are an HVM guest */ b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1447) type = xenbus_read(XBT_NIL, dev->nodename, "device-type", &len); b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1448) if (IS_ERR(type)) b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1449) return -ENODEV; b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1450) if (strncmp(type, "cdrom", 5) == 0) { b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1451) kfree(type); c1c5413a (Stefano Stabellini 2010-05-14 12:44:30 +0100 1452) return -ENODEV; c1c5413a (Stefano Stabellini 2010-05-14 12:44:30 +0100 1453) } b98a409b (Stefano Stabellini 2010-07-29 14:53:16 +0100 1454) kfree(type); c1c5413a (Stefano Stabellini 2010-05-14 12:44:30 +0100 1455) } Side point: commit 51c71a3b from Konrad <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=51c71a3b> should be instrumental for those who are looking for more background on emulated device / driver unplugging in Xen domUs. But, the really interesting bit here is the commit message of b98a409b <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b98a409b>, from 2010, authored by Stefano: blkfront: do not create a PV cdrom device if xen_hvm_guest It is not possible to unplug emulated cdrom devices, and PV cdroms don't handle media insert, eject and stream, so we are better off disabling PV cdroms when running as a Xen HVM guest. Could that be related to the issue you are experiencing with OVMF? Because, OVMF implies HVM (or PV-on-HVM), and your report ("empty paravirt CD-ROM" or some such -- sorry, the report remains unclear) appears to match the above message. Given that this is guest code, shouldn't the same logic be mirrored in the OVMF guest driver? /* do not create a PV cdrom device if we are an HVM guest */ In other words, given that OVMF implies HVM, shouldn't OVMF too forego driving a paravirt CD-ROM entirely? Now, the Xen guest code in OVMF, from <https://github.com/tianocore/edk2/commit/5cce8524>, function XenPvBlockFrontInitialization(), *does* look for "cdrom" in "device-type": XenBusIo->XsRead (XenBusIo, XST_NIL, "device-type", (VOID**)&DeviceType); if (AsciiStrCmp (DeviceType, "cdrom") == 0) { Dev->MediaInfo.CdRom = TRUE; } else { Dev->MediaInfo.CdRom = FALSE; } but the *only* thing that the CdRom field is used for is to force a 2KB block size in XenPvBlkDxeDriverBindingStart(), for ElTorito compatibility: if (Dev->MediaInfo.CdRom) { // // If it's a cdrom, the blocksize value need to be 2048 for OVMF to // recognize it as a cdrom: // MdeModulePkg/Universal/Disk/PartitionDxe/ElTorito.c // Media->BlockSize = 2048; Media->LastBlock = DivU64x32 (Dev->MediaInfo.Sectors, Media->BlockSize / Dev->MediaInfo.SectorSize) - 1; } else { While in the same situation (i.e., in an HVM guest), the guest kernel driver does not report a paravirt CD-ROM at all; instead it forces an emulated (IDE) CD-ROM. ... Sorry if the above turns out fully irrelevant, but I still have no info from you to go on. Thanks Laszlo ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 10:13 ` Anthony PERARD 2015-10-16 10:23 ` Fabio Fantoni @ 2015-10-16 10:23 ` Fabio Fantoni 1 sibling, 0 replies; 95+ messages in thread From: Fabio Fantoni @ 2015-10-16 10:23 UTC (permalink / raw) To: Anthony PERARD Cc: Kevin Wolf, qemu-block, Stefano Stabellini, qemu-devel, xen-devel, Paul Durrant, John Snow Il 16/10/2015 12:13, Anthony PERARD ha scritto: > On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote: >> Il 15/10/2015 20:02, Anthony PERARD ha scritto: >>> On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: >>>> Il 14/10/2015 13:06, Stefano Stabellini ha scritto: >>>>> I would suggest Fabio to avoid AHCI disks altogether and just use OVMF >>>>> with PV disks only and Anthony's patch to libxl to avoid creating any >>>>> IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. >>>>> >>>>> Would that work for you? >>>> Thanks for the advice, I tried it: >>>> https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 >>>> >>>> I installed W10 pro 64 bit with ide disk, installed the win pv drivers and >>>> after changed to xvdX instead hdX, is the only change needed, right? >>>> Initial boot is ok (ovmf part about pv disks seems ok) but windows boot >>>> fails with problem with pv drivers. >>>> In attachment full qemu log with xen_platform trace and domU's xl cfg. >>>> >>>> Someone have windows domUs with ovmf and pv disks only working? If yes can >>>> tell me the difference to understand what can be the problem please? >>> When I worked on the PV disk implementation in OVMF, I was able to boot >>> a Windows 8 with pv disk only. >>> >>> I don't have access to the guest configuration I was using, but I think one >>> difference would be the viridian setting, I'm pretty sure I did not set it. >>> >> I tried with viridian disabled but did the same thing, looking cdrom as >> latest thing before xenbug trace in qemu log I tried also to remove it but >> also in this case don't boot correctly, full qemu log in attachment. >> I don't know if is a ovmf thing to improve (like what seems in Laszlo and >> Kevin mails) or xen winpv drivers unexpected case, have you tried also with >> latest winpv builds? (for exclude regression) > No, I did not tried the latest winpv drivers. > > Sorry I can help much more that that. When I install this win8 guest tried > to boot it with pv drivers only, that was more than a year ago. I have not > check if it's still working. (Also I can not try anything more recent, > right now.) > I did many other tests, retrying with ide first boot working but show pv devices not working, I did another reboot (with ide) and pv devices was working, after I retried with pv (xvdX) and boot correctly. After other tests I found that with empty cdrom device (required for xl cd-insert/cd-eject) boot stop at start (tianocore image), same result with ide instead. From xl cfg: disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom'] With seabios domU boot also with empty cdrom. In qemu log I found only these that can be related: > xen be: qdisk-51728: error: Could not open image: No such file or > directory > xen be: qdisk-51728: initialise() failed And latest xl dmesg line is: > (d1) Invoking OVMF ... If you need more informations/test tell me and I'll post them. Thanks for any reply and sorry for my bad english. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-14 9:47 ` Kevin Wolf 2015-10-14 11:06 ` Stefano Stabellini @ 2015-10-14 11:11 ` Fabio Fantoni 2015-10-14 12:48 ` Paul Durrant 1 sibling, 1 reply; 95+ messages in thread From: Fabio Fantoni @ 2015-10-14 11:11 UTC (permalink / raw) To: Kevin Wolf, Stefano Stabellini Cc: qemu-block, qemu-devel, xen-devel, Paul Durrant, Anthony.Perard, John Snow Il 14/10/2015 11:47, Kevin Wolf ha scritto: > [ CC qemu-block ] > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: >> On Tue, 13 Oct 2015, John Snow wrote: >>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: >>>> I added ahci disk support in libxl and using it for week seems that was >>>> ok, after a reply of Stefano Stabellini seems that xen disk unplug >>>> support only ide disks: >>>> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 >>>> >>>> Today Paul Durrant told me that even if pv disk is ok also with ahci and >>>> the emulated one is offline can be a risk: >>>> http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html >>>> >>>> >>>> I tried to take a fast look in qemu code but I not understand the needed >>>> thing for add the xen disk unplug support also for ahci, can someone do >>>> it or tell me useful information for do it please? >>>> >>>> Thanks for any reply and sorry for my bad english. >>>> >>> I'm not entirely sure what features you need AHCI to support in order >>> for Xen to be happy. >>> >>> I'd guess hotplugging, but where I get confused is that IDE disks don't >>> support hotplugging either, so I guess I'm not sure sure what you need. >>> >>> Stefano, can you help bridge my Xen knowledge gap? >> >> Hi John, >> >> we need something like hw/i386/xen/xen_platform.c:unplug_disks but that >> can unplug AHCI disk. And by unplug, I mean "make disappear" like >> pci_piix3_xen_ide_unplug does for ide. > Maybe this would be the right time to stop the craziness with your > hybrid IDE/xendisk setup. It's a horrible thing that would never happen > on real hardware. > > Can't you just teach SeaBIOS how to deal with your PV disks and then > only add that to your VM and forget about IDE/AHCI? I mean, that's how > it's done for virtio-blk, and it doesn't involve any insanities like > ripping out non-hotpluggable devices. > > Hm... How does a reboot of a machine that had its IDE already removed > actually work? Do you restart the qemu process on reboot? > > Kevin I thinkthat would be a good idea, unfortunately I'm not able to do that and I do not know if the developers of xen would agree to such modification. If will be done, for example having new disk type "xenpv" require the pv drivers installed, with linux having drivers included should not be a problem but on windows yes FWIK. Like virtio driver should be installed before (or adding them in windows install), I don't know if will be ok specifying them in install for with xen driver, another possibility can be start domU with ide disk type, install the xen pv drivers and reboot selecting xenpv disk type instead. Doing it FWIK require not only xen and qemu changes but also pv drivers change, I added on cc also Paul Durrant for see what think about. With actual unplug based on my tests in some years I had many problem with windows domUs (with both old and new pv drivers) resulting in "windows boot blue screen error", I suppose that changing/improving unplug method can decrease them, is it correct? About reboot xen do different from kvm recreating full domU each time (and new qemu process), I don't know if is possible and good change the method. Thanks for any reply and sorry for my bad english. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-14 11:11 ` Fabio Fantoni @ 2015-10-14 12:48 ` Paul Durrant 2015-10-15 23:35 ` Laszlo Ersek ` (3 more replies) 0 siblings, 4 replies; 95+ messages in thread From: Paul Durrant @ 2015-10-14 12:48 UTC (permalink / raw) To: Fabio Fantoni, Kevin Wolf, Stefano Stabellini Cc: Anthony Perard, John Snow, qemu-devel, qemu-block, xen-devel > -----Original Message----- > From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] > Sent: 14 October 2015 12:12 > To: Kevin Wolf; Stefano Stabellini > Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; xen- > devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant > Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci > missed in qemu > > > > Il 14/10/2015 11:47, Kevin Wolf ha scritto: > > [ CC qemu-block ] > > > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > >> On Tue, 13 Oct 2015, John Snow wrote: > >>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > >>>> I added ahci disk support in libxl and using it for week seems that was > >>>> ok, after a reply of Stefano Stabellini seems that xen disk unplug > >>>> support only ide disks: > >>>> > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 > c905374ee8663d5d8 > >>>> > >>>> Today Paul Durrant told me that even if pv disk is ok also with ahci and > >>>> the emulated one is offline can be a risk: > >>>> http://lists.xenproject.org/archives/html/win-pv-devel/2015- > 10/msg00021.html > >>>> > >>>> > >>>> I tried to take a fast look in qemu code but I not understand the > needed > >>>> thing for add the xen disk unplug support also for ahci, can someone do > >>>> it or tell me useful information for do it please? > >>>> > >>>> Thanks for any reply and sorry for my bad english. > >>>> > >>> I'm not entirely sure what features you need AHCI to support in order > >>> for Xen to be happy. > >>> > >>> I'd guess hotplugging, but where I get confused is that IDE disks don't > >>> support hotplugging either, so I guess I'm not sure sure what you need. > >>> > >>> Stefano, can you help bridge my Xen knowledge gap? > >> > >> Hi John, > >> > >> we need something like hw/i386/xen/xen_platform.c:unplug_disks but > that > >> can unplug AHCI disk. And by unplug, I mean "make disappear" like > >> pci_piix3_xen_ide_unplug does for ide. > > Maybe this would be the right time to stop the craziness with your > > hybrid IDE/xendisk setup. It's a horrible thing that would never happen > > on real hardware. Unfortunately, it's going to be difficult to remove such 'craziness' when you don't know a priori whether the VM has PV drivers or not. > > > > Can't you just teach SeaBIOS how to deal with your PV disks and then > > only add that to your VM and forget about IDE/AHCI? I mean, that's how > > it's done for virtio-blk, and it doesn't involve any insanities like > > ripping out non-hotpluggable devices. > > Does Windows have in-box virtio-blk drivers? If not, how does it boot? > > Hm... How does a reboot of a machine that had its IDE already removed > > actually work? Do you restart the qemu process on reboot? > > The IDE disks are always present during boot, but before the OS enumerates them they are 'unplugged' and then PV drivers are used instead. The only other way would be to somehow obscure them from OS enumeration so they could be left lying around but remain unused. That's feasible for Windows, but I don't know about other OS. Paul > > Kevin > I thinkthat would be a good idea, unfortunately I'm not able to do that > and I do not know if the developers of xen would agree to such modification. > > If will be done, for example having new disk type "xenpv" require the pv > drivers installed, with linux having drivers included should not be a > problem but on windows yes FWIK. > Like virtio driver should be installed before (or adding them in windows > install), I don't know if will be ok specifying them in install for with > xen driver, another possibility can be start domU with ide disk type, > install the xen pv drivers and reboot selecting xenpv disk type instead. > Doing it FWIK require not only xen and qemu changes but also pv drivers > change, I added on cc also Paul Durrant for see what think about. > With actual unplug based on my tests in some years I had many problem > with windows domUs (with both old and new pv drivers) resulting in > "windows boot blue screen error", I suppose that changing/improving > unplug method can decrease them, is it correct? > > About reboot xen do different from kvm recreating full domU each time > (and new qemu process), I don't know if is possible and good change the > method. > > Thanks for any reply and sorry for my bad english. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-14 12:48 ` Paul Durrant @ 2015-10-15 23:35 ` Laszlo Ersek 2015-10-15 23:35 ` Laszlo Ersek ` (2 subsequent siblings) 3 siblings, 0 replies; 95+ messages in thread From: Laszlo Ersek @ 2015-10-15 23:35 UTC (permalink / raw) To: Paul Durrant, Fabio Fantoni, Kevin Wolf, Stefano Stabellini Cc: qemu-block, qemu-devel, xen-devel, Anthony Perard, Vitaly Kuznetsov, John Snow On 10/14/15 14:48, Paul Durrant wrote: >> -----Original Message----- >> From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] >> Sent: 14 October 2015 12:12 >> To: Kevin Wolf; Stefano Stabellini >> Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; xen- >> devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant >> Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci >> missed in qemu >> >> >> >> Il 14/10/2015 11:47, Kevin Wolf ha scritto: >>> [ CC qemu-block ] >>> >>> Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: >>>> On Tue, 13 Oct 2015, John Snow wrote: >>>>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: >>>>>> I added ahci disk support in libxl and using it for week seems that was >>>>>> ok, after a reply of Stefano Stabellini seems that xen disk unplug >>>>>> support only ide disks: >>>>>> >> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 >> c905374ee8663d5d8 >>>>>> >>>>>> Today Paul Durrant told me that even if pv disk is ok also with ahci and >>>>>> the emulated one is offline can be a risk: >>>>>> http://lists.xenproject.org/archives/html/win-pv-devel/2015- >> 10/msg00021.html >>>>>> >>>>>> >>>>>> I tried to take a fast look in qemu code but I not understand the >> needed >>>>>> thing for add the xen disk unplug support also for ahci, can someone do >>>>>> it or tell me useful information for do it please? >>>>>> >>>>>> Thanks for any reply and sorry for my bad english. >>>>>> >>>>> I'm not entirely sure what features you need AHCI to support in order >>>>> for Xen to be happy. >>>>> >>>>> I'd guess hotplugging, but where I get confused is that IDE disks don't >>>>> support hotplugging either, so I guess I'm not sure sure what you need. >>>>> >>>>> Stefano, can you help bridge my Xen knowledge gap? >>>> >>>> Hi John, >>>> >>>> we need something like hw/i386/xen/xen_platform.c:unplug_disks but >> that >>>> can unplug AHCI disk. And by unplug, I mean "make disappear" like >>>> pci_piix3_xen_ide_unplug does for ide. >>> Maybe this would be the right time to stop the craziness with your >>> hybrid IDE/xendisk setup. It's a horrible thing that would never happen >>> on real hardware. > > Unfortunately, it's going to be difficult to remove such 'craziness' when you don't know a priori whether the VM has PV drivers or not. > >>> >>> Can't you just teach SeaBIOS how to deal with your PV disks and then >>> only add that to your VM and forget about IDE/AHCI? I mean, that's how >>> it's done for virtio-blk, and it doesn't involve any insanities like >>> ripping out non-hotpluggable devices. >>> > > Does Windows have in-box virtio-blk drivers? If not, how does it boot? The firmwares have virtio drivers (SeaBIOS and OVMF). The Windows installer can be booted far enough, on top of the firmware services, that Windows explicitly asks for a driver disk -- not only for the installation *target* disk, but even for the CD-ROM that it is being installed *from*. In practice, you can install modern Windows (Windows 8 and later definitely, I *think* maybe even Windows 7), from a virtio-scsi CD-ROM, to, say, a virtio-block disk, and provide *only* the virtio drivers on a separate IDE CD-ROM (which you can later remove completely, on the device level). The Windows installer's boot loader loads an initial ramdisk into memory, using firmware services. Then its kernel starts and has access to a number of basic drivers, like IDE CD-ROM drivers. That is sufficient to load the virtio-scsi driver from the virtio-win ISO, and then the installation can continue from the original virtio-scsi CD-ROM. I always install windows guests like this; it is quite flexible. (In brief: 1 virtio-block target disk, 1 virtio-scsi CD-ROM holding the Windows ISO, 1 IDE CD-ROM (to be removed permanently from the guest config, later) holding the virtio-win driver ISO.) > >>> Hm... How does a reboot of a machine that had its IDE already removed >>> actually work? Do you restart the qemu process on reboot? >>> > > The IDE disks are always present during boot, but before the OS > enumerates them they are 'unplugged' and then PV drivers are used > instead. Supporting this in RHEL-5 and RHEL-6 guests was *incredible* pain. Also, when you consider kexec / kdump in the guest, that was an unending source of bug reports. If I recall correctly, the PV devices (net and block) could not be used by the kdump kernel, because the main (crashed) kernel may have left them in a bad state (and I'm not sure if it was possible to reinit them.) And the emulated devices were slow... assuming the kdump kernel didn't try to unplug them first! (Maybe Vitaly (CC'd) knows more about the current status in this area; I'm admittedly fuzzy, sorry. My intent is not to spread FUD.) (I'll also admit that running kdump in the guest (that's already crashed) is a bad idea in general, given that the host is there right under it, capable of dumping the guests memory without issues. Maybe not so flexible for some cloud setups. Whatever.) > The only other way would be to somehow obscure them from OS > enumeration so they could be left lying around but remain unused. > That's feasible for Windows, but I don't know about other OS. I think it can be solved if you remove the emulated devices completely (on the guest configuration level), and teach the firmware(s) to boot off the PV devices. Thanks Laszlo > > Paul > >>> Kevin >> I thinkthat would be a good idea, unfortunately I'm not able to do that >> and I do not know if the developers of xen would agree to such modification. >> >> If will be done, for example having new disk type "xenpv" require the pv >> drivers installed, with linux having drivers included should not be a >> problem but on windows yes FWIK. >> Like virtio driver should be installed before (or adding them in windows >> install), I don't know if will be ok specifying them in install for with >> xen driver, another possibility can be start domU with ide disk type, >> install the xen pv drivers and reboot selecting xenpv disk type instead. >> Doing it FWIK require not only xen and qemu changes but also pv drivers >> change, I added on cc also Paul Durrant for see what think about. >> With actual unplug based on my tests in some years I had many problem >> with windows domUs (with both old and new pv drivers) resulting in >> "windows boot blue screen error", I suppose that changing/improving >> unplug method can decrease them, is it correct? >> >> About reboot xen do different from kvm recreating full domU each time >> (and new qemu process), I don't know if is possible and good change the >> method. >> >> Thanks for any reply and sorry for my bad english. > ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-14 12:48 ` Paul Durrant 2015-10-15 23:35 ` Laszlo Ersek @ 2015-10-15 23:35 ` Laszlo Ersek 2015-10-16 14:04 ` Kevin Wolf 2015-10-16 14:04 ` Kevin Wolf 3 siblings, 0 replies; 95+ messages in thread From: Laszlo Ersek @ 2015-10-15 23:35 UTC (permalink / raw) To: Paul Durrant, Fabio Fantoni, Kevin Wolf, Stefano Stabellini Cc: qemu-block, qemu-devel, xen-devel, Anthony Perard, Vitaly Kuznetsov, John Snow On 10/14/15 14:48, Paul Durrant wrote: >> -----Original Message----- >> From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] >> Sent: 14 October 2015 12:12 >> To: Kevin Wolf; Stefano Stabellini >> Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; xen- >> devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant >> Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci >> missed in qemu >> >> >> >> Il 14/10/2015 11:47, Kevin Wolf ha scritto: >>> [ CC qemu-block ] >>> >>> Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: >>>> On Tue, 13 Oct 2015, John Snow wrote: >>>>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: >>>>>> I added ahci disk support in libxl and using it for week seems that was >>>>>> ok, after a reply of Stefano Stabellini seems that xen disk unplug >>>>>> support only ide disks: >>>>>> >> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 >> c905374ee8663d5d8 >>>>>> >>>>>> Today Paul Durrant told me that even if pv disk is ok also with ahci and >>>>>> the emulated one is offline can be a risk: >>>>>> http://lists.xenproject.org/archives/html/win-pv-devel/2015- >> 10/msg00021.html >>>>>> >>>>>> >>>>>> I tried to take a fast look in qemu code but I not understand the >> needed >>>>>> thing for add the xen disk unplug support also for ahci, can someone do >>>>>> it or tell me useful information for do it please? >>>>>> >>>>>> Thanks for any reply and sorry for my bad english. >>>>>> >>>>> I'm not entirely sure what features you need AHCI to support in order >>>>> for Xen to be happy. >>>>> >>>>> I'd guess hotplugging, but where I get confused is that IDE disks don't >>>>> support hotplugging either, so I guess I'm not sure sure what you need. >>>>> >>>>> Stefano, can you help bridge my Xen knowledge gap? >>>> >>>> Hi John, >>>> >>>> we need something like hw/i386/xen/xen_platform.c:unplug_disks but >> that >>>> can unplug AHCI disk. And by unplug, I mean "make disappear" like >>>> pci_piix3_xen_ide_unplug does for ide. >>> Maybe this would be the right time to stop the craziness with your >>> hybrid IDE/xendisk setup. It's a horrible thing that would never happen >>> on real hardware. > > Unfortunately, it's going to be difficult to remove such 'craziness' when you don't know a priori whether the VM has PV drivers or not. > >>> >>> Can't you just teach SeaBIOS how to deal with your PV disks and then >>> only add that to your VM and forget about IDE/AHCI? I mean, that's how >>> it's done for virtio-blk, and it doesn't involve any insanities like >>> ripping out non-hotpluggable devices. >>> > > Does Windows have in-box virtio-blk drivers? If not, how does it boot? The firmwares have virtio drivers (SeaBIOS and OVMF). The Windows installer can be booted far enough, on top of the firmware services, that Windows explicitly asks for a driver disk -- not only for the installation *target* disk, but even for the CD-ROM that it is being installed *from*. In practice, you can install modern Windows (Windows 8 and later definitely, I *think* maybe even Windows 7), from a virtio-scsi CD-ROM, to, say, a virtio-block disk, and provide *only* the virtio drivers on a separate IDE CD-ROM (which you can later remove completely, on the device level). The Windows installer's boot loader loads an initial ramdisk into memory, using firmware services. Then its kernel starts and has access to a number of basic drivers, like IDE CD-ROM drivers. That is sufficient to load the virtio-scsi driver from the virtio-win ISO, and then the installation can continue from the original virtio-scsi CD-ROM. I always install windows guests like this; it is quite flexible. (In brief: 1 virtio-block target disk, 1 virtio-scsi CD-ROM holding the Windows ISO, 1 IDE CD-ROM (to be removed permanently from the guest config, later) holding the virtio-win driver ISO.) > >>> Hm... How does a reboot of a machine that had its IDE already removed >>> actually work? Do you restart the qemu process on reboot? >>> > > The IDE disks are always present during boot, but before the OS > enumerates them they are 'unplugged' and then PV drivers are used > instead. Supporting this in RHEL-5 and RHEL-6 guests was *incredible* pain. Also, when you consider kexec / kdump in the guest, that was an unending source of bug reports. If I recall correctly, the PV devices (net and block) could not be used by the kdump kernel, because the main (crashed) kernel may have left them in a bad state (and I'm not sure if it was possible to reinit them.) And the emulated devices were slow... assuming the kdump kernel didn't try to unplug them first! (Maybe Vitaly (CC'd) knows more about the current status in this area; I'm admittedly fuzzy, sorry. My intent is not to spread FUD.) (I'll also admit that running kdump in the guest (that's already crashed) is a bad idea in general, given that the host is there right under it, capable of dumping the guests memory without issues. Maybe not so flexible for some cloud setups. Whatever.) > The only other way would be to somehow obscure them from OS > enumeration so they could be left lying around but remain unused. > That's feasible for Windows, but I don't know about other OS. I think it can be solved if you remove the emulated devices completely (on the guest configuration level), and teach the firmware(s) to boot off the PV devices. Thanks Laszlo > > Paul > >>> Kevin >> I thinkthat would be a good idea, unfortunately I'm not able to do that >> and I do not know if the developers of xen would agree to such modification. >> >> If will be done, for example having new disk type "xenpv" require the pv >> drivers installed, with linux having drivers included should not be a >> problem but on windows yes FWIK. >> Like virtio driver should be installed before (or adding them in windows >> install), I don't know if will be ok specifying them in install for with >> xen driver, another possibility can be start domU with ide disk type, >> install the xen pv drivers and reboot selecting xenpv disk type instead. >> Doing it FWIK require not only xen and qemu changes but also pv drivers >> change, I added on cc also Paul Durrant for see what think about. >> With actual unplug based on my tests in some years I had many problem >> with windows domUs (with both old and new pv drivers) resulting in >> "windows boot blue screen error", I suppose that changing/improving >> unplug method can decrease them, is it correct? >> >> About reboot xen do different from kvm recreating full domU each time >> (and new qemu process), I don't know if is possible and good change the >> method. >> >> Thanks for any reply and sorry for my bad english. > ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-14 12:48 ` Paul Durrant 2015-10-15 23:35 ` Laszlo Ersek 2015-10-15 23:35 ` Laszlo Ersek @ 2015-10-16 14:04 ` Kevin Wolf 2015-10-16 14:24 ` Paul Durrant 2015-10-16 14:24 ` Paul Durrant 2015-10-16 14:04 ` Kevin Wolf 3 siblings, 2 replies; 95+ messages in thread From: Kevin Wolf @ 2015-10-16 14:04 UTC (permalink / raw) To: Paul Durrant Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Stefano Stabellini, Anthony Perard, John Snow Am 14.10.2015 um 14:48 hat Paul Durrant geschrieben: > > -----Original Message----- > > From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] > > Sent: 14 October 2015 12:12 > > To: Kevin Wolf; Stefano Stabellini > > Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; xen- > > devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci > > missed in qemu > > > > > > > > Il 14/10/2015 11:47, Kevin Wolf ha scritto: > > > [ CC qemu-block ] > > > > > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > > >> On Tue, 13 Oct 2015, John Snow wrote: > > >>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > >>>> I added ahci disk support in libxl and using it for week seems that was > > >>>> ok, after a reply of Stefano Stabellini seems that xen disk unplug > > >>>> support only ide disks: > > >>>> > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 > > c905374ee8663d5d8 > > >>>> > > >>>> Today Paul Durrant told me that even if pv disk is ok also with ahci and > > >>>> the emulated one is offline can be a risk: > > >>>> http://lists.xenproject.org/archives/html/win-pv-devel/2015- > > 10/msg00021.html > > >>>> > > >>>> > > >>>> I tried to take a fast look in qemu code but I not understand the > > needed > > >>>> thing for add the xen disk unplug support also for ahci, can someone do > > >>>> it or tell me useful information for do it please? > > >>>> > > >>>> Thanks for any reply and sorry for my bad english. > > >>>> > > >>> I'm not entirely sure what features you need AHCI to support in order > > >>> for Xen to be happy. > > >>> > > >>> I'd guess hotplugging, but where I get confused is that IDE disks don't > > >>> support hotplugging either, so I guess I'm not sure sure what you need. > > >>> > > >>> Stefano, can you help bridge my Xen knowledge gap? > > >> > > >> Hi John, > > >> > > >> we need something like hw/i386/xen/xen_platform.c:unplug_disks but > > that > > >> can unplug AHCI disk. And by unplug, I mean "make disappear" like > > >> pci_piix3_xen_ide_unplug does for ide. > > > Maybe this would be the right time to stop the craziness with your > > > hybrid IDE/xendisk setup. It's a horrible thing that would never happen > > > on real hardware. > > Unfortunately, it's going to be difficult to remove such 'craziness' when you don't know a priori whether the VM has PV drivers or not. Why wouldn't you know that beforehand? I mean, even on real hardware you can have different disk interfaces (IDE, AHCI, SCSI) and you install the exact driver that your hardware needs. You just do the same thing on VM: If your hardware is PV, you install a PV driver. If your hardware is IDE, you install an IDE driver. Whether it's PV or IDE is something that you, the user, decided when configuring the VM, so you definitely know. Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 14:04 ` Kevin Wolf @ 2015-10-16 14:24 ` Paul Durrant 2015-10-16 15:02 ` Kevin Wolf 2015-10-16 15:02 ` Kevin Wolf 2015-10-16 14:24 ` Paul Durrant 1 sibling, 2 replies; 95+ messages in thread From: Paul Durrant @ 2015-10-16 14:24 UTC (permalink / raw) To: Kevin Wolf Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Stefano Stabellini, Anthony Perard, John Snow > -----Original Message----- > From: Kevin Wolf [mailto:kwolf@redhat.com] > Sent: 16 October 2015 15:04 > To: Paul Durrant > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci > missed in qemu > > Am 14.10.2015 um 14:48 hat Paul Durrant geschrieben: > > > -----Original Message----- > > > From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] > > > Sent: 14 October 2015 12:12 > > > To: Kevin Wolf; Stefano Stabellini > > > Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; xen- > > > devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for > ahci > > > missed in qemu > > > > > > > > > > > > Il 14/10/2015 11:47, Kevin Wolf ha scritto: > > > > [ CC qemu-block ] > > > > > > > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > > > >> On Tue, 13 Oct 2015, John Snow wrote: > > > >>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > > >>>> I added ahci disk support in libxl and using it for week seems that > was > > > >>>> ok, after a reply of Stefano Stabellini seems that xen disk unplug > > > >>>> support only ide disks: > > > >>>> > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 > > > c905374ee8663d5d8 > > > >>>> > > > >>>> Today Paul Durrant told me that even if pv disk is ok also with ahci > and > > > >>>> the emulated one is offline can be a risk: > > > >>>> http://lists.xenproject.org/archives/html/win-pv-devel/2015- > > > 10/msg00021.html > > > >>>> > > > >>>> > > > >>>> I tried to take a fast look in qemu code but I not understand the > > > needed > > > >>>> thing for add the xen disk unplug support also for ahci, can > someone do > > > >>>> it or tell me useful information for do it please? > > > >>>> > > > >>>> Thanks for any reply and sorry for my bad english. > > > >>>> > > > >>> I'm not entirely sure what features you need AHCI to support in > order > > > >>> for Xen to be happy. > > > >>> > > > >>> I'd guess hotplugging, but where I get confused is that IDE disks don't > > > >>> support hotplugging either, so I guess I'm not sure sure what you > need. > > > >>> > > > >>> Stefano, can you help bridge my Xen knowledge gap? > > > >> > > > >> Hi John, > > > >> > > > >> we need something like hw/i386/xen/xen_platform.c:unplug_disks > but > > > that > > > >> can unplug AHCI disk. And by unplug, I mean "make disappear" like > > > >> pci_piix3_xen_ide_unplug does for ide. > > > > Maybe this would be the right time to stop the craziness with your > > > > hybrid IDE/xendisk setup. It's a horrible thing that would never happen > > > > on real hardware. > > > > Unfortunately, it's going to be difficult to remove such 'craziness' when you > don't know a priori whether the VM has PV drivers or not. > > Why wouldn't you know that beforehand? I mean, even on real hardware > you > can have different disk interfaces (IDE, AHCI, SCSI) and you install > the exact driver that your hardware needs. You just do the same thing on > VM: If your hardware is PV, you install a PV driver. If your hardware is > IDE, you install an IDE driver. Whether it's PV or IDE is something that > you, the user, decided when configuring the VM, so you definitely know. > That's not necessarily true. The host admin that provisions the VM does not necessarily know what OS the user of that VM will install. The admin may just be providing a generic VM with an emulated CD drive that the user can point at any ISO they want. So, as a host admin, if you provide a VM with only PV backends and your user is trying to boot an OS with no PV drivers they are not going to be happy, so you provide emulated devices. Then, at some point later, when the user installs PV drivers, there really should be some way for those drivers to start up without any need to contact the host admin and have the VM reconfigured. Paul > Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 14:24 ` Paul Durrant @ 2015-10-16 15:02 ` Kevin Wolf 2015-10-16 15:10 ` Paul Durrant 2015-10-16 15:02 ` Kevin Wolf 1 sibling, 1 reply; 95+ messages in thread From: Kevin Wolf @ 2015-10-16 15:02 UTC (permalink / raw) To: Paul Durrant Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Stefano Stabellini, Anthony Perard, John Snow Am 16.10.2015 um 16:24 hat Paul Durrant geschrieben: > > -----Original Message----- > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > Sent: 16 October 2015 15:04 > > To: Paul Durrant > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci > > missed in qemu > > > > Am 14.10.2015 um 14:48 hat Paul Durrant geschrieben: > > > > -----Original Message----- > > > > From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] > > > > Sent: 14 October 2015 12:12 > > > > To: Kevin Wolf; Stefano Stabellini > > > > Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; xen- > > > > devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for > > ahci > > > > missed in qemu > > > > > > > > > > > > > > > > Il 14/10/2015 11:47, Kevin Wolf ha scritto: > > > > > [ CC qemu-block ] > > > > > > > > > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > > > > >> On Tue, 13 Oct 2015, John Snow wrote: > > > > >>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > > > >>>> I added ahci disk support in libxl and using it for week seems that > > was > > > > >>>> ok, after a reply of Stefano Stabellini seems that xen disk unplug > > > > >>>> support only ide disks: > > > > >>>> > > > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 > > > > c905374ee8663d5d8 > > > > >>>> > > > > >>>> Today Paul Durrant told me that even if pv disk is ok also with ahci > > and > > > > >>>> the emulated one is offline can be a risk: > > > > >>>> http://lists.xenproject.org/archives/html/win-pv-devel/2015- > > > > 10/msg00021.html > > > > >>>> > > > > >>>> > > > > >>>> I tried to take a fast look in qemu code but I not understand the > > > > needed > > > > >>>> thing for add the xen disk unplug support also for ahci, can > > someone do > > > > >>>> it or tell me useful information for do it please? > > > > >>>> > > > > >>>> Thanks for any reply and sorry for my bad english. > > > > >>>> > > > > >>> I'm not entirely sure what features you need AHCI to support in > > order > > > > >>> for Xen to be happy. > > > > >>> > > > > >>> I'd guess hotplugging, but where I get confused is that IDE disks don't > > > > >>> support hotplugging either, so I guess I'm not sure sure what you > > need. > > > > >>> > > > > >>> Stefano, can you help bridge my Xen knowledge gap? > > > > >> > > > > >> Hi John, > > > > >> > > > > >> we need something like hw/i386/xen/xen_platform.c:unplug_disks > > but > > > > that > > > > >> can unplug AHCI disk. And by unplug, I mean "make disappear" like > > > > >> pci_piix3_xen_ide_unplug does for ide. > > > > > Maybe this would be the right time to stop the craziness with your > > > > > hybrid IDE/xendisk setup. It's a horrible thing that would never happen > > > > > on real hardware. > > > > > > Unfortunately, it's going to be difficult to remove such 'craziness' when you > > don't know a priori whether the VM has PV drivers or not. > > > > Why wouldn't you know that beforehand? I mean, even on real hardware > > you > > can have different disk interfaces (IDE, AHCI, SCSI) and you install > > the exact driver that your hardware needs. You just do the same thing on > > VM: If your hardware is PV, you install a PV driver. If your hardware is > > IDE, you install an IDE driver. Whether it's PV or IDE is something that > > you, the user, decided when configuring the VM, so you definitely know. > > > > That's not necessarily true. The host admin that provisions the VM does not necessarily know what OS the user of that VM will install. The admin may just be providing a generic VM with an emulated CD drive that the user can point at any ISO they want. > > So, as a host admin, if you provide a VM with only PV backends and your user is trying to boot an OS with no PV drivers they are not going to be happy, so you provide emulated devices. Then, at some point later, when the user installs PV drivers, there really should be some way for those drivers to start up without any need to contact the host admin and have the VM reconfigured. Why only IDE and xendisk then? Maybe I have an OS that works great with AHCI, or virtio-blk, or an LSI SCSI controller, or a Megasas SCSI controller, or USB sticks, or... (and IDE will hardly ever be the optimal one) What about network cards? My OS might support the Xen PV one, or it might support rtl8139, or e1000, or virtio-net, or pcnet, or... Should we always put all of the hardware that can possibly be emulated in a VM just so that the one right device is definitely included even though we don't know what OS will be running? This is ridiculous. Just tell your admin what virtual hardware you really need. (Or tell them to give you a proper interface to configure your VMs yourself.) Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 15:02 ` Kevin Wolf @ 2015-10-16 15:10 ` Paul Durrant 2015-10-16 16:11 ` Kevin Wolf 2015-10-16 16:11 ` Kevin Wolf 0 siblings, 2 replies; 95+ messages in thread From: Paul Durrant @ 2015-10-16 15:10 UTC (permalink / raw) To: Kevin Wolf Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Stefano Stabellini, Anthony Perard, John Snow > -----Original Message----- > From: Kevin Wolf [mailto:kwolf@redhat.com] > Sent: 16 October 2015 16:02 > To: Paul Durrant > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci > missed in qemu > > Am 16.10.2015 um 16:24 hat Paul Durrant geschrieben: > > > -----Original Message----- > > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > > Sent: 16 October 2015 15:04 > > > To: Paul Durrant > > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > > > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for > ahci > > > missed in qemu > > > > > > Am 14.10.2015 um 14:48 hat Paul Durrant geschrieben: > > > > > -----Original Message----- > > > > > From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] > > > > > Sent: 14 October 2015 12:12 > > > > > To: Kevin Wolf; Stefano Stabellini > > > > > Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; xen- > > > > > devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant > > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support > for > > > ahci > > > > > missed in qemu > > > > > > > > > > > > > > > > > > > > Il 14/10/2015 11:47, Kevin Wolf ha scritto: > > > > > > [ CC qemu-block ] > > > > > > > > > > > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > > > > > >> On Tue, 13 Oct 2015, John Snow wrote: > > > > > >>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > > > > >>>> I added ahci disk support in libxl and using it for week seems > that > > > was > > > > > >>>> ok, after a reply of Stefano Stabellini seems that xen disk unplug > > > > > >>>> support only ide disks: > > > > > >>>> > > > > > > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 > > > > > c905374ee8663d5d8 > > > > > >>>> > > > > > >>>> Today Paul Durrant told me that even if pv disk is ok also with > ahci > > > and > > > > > >>>> the emulated one is offline can be a risk: > > > > > >>>> http://lists.xenproject.org/archives/html/win-pv-devel/2015- > > > > > 10/msg00021.html > > > > > >>>> > > > > > >>>> > > > > > >>>> I tried to take a fast look in qemu code but I not understand the > > > > > needed > > > > > >>>> thing for add the xen disk unplug support also for ahci, can > > > someone do > > > > > >>>> it or tell me useful information for do it please? > > > > > >>>> > > > > > >>>> Thanks for any reply and sorry for my bad english. > > > > > >>>> > > > > > >>> I'm not entirely sure what features you need AHCI to support in > > > order > > > > > >>> for Xen to be happy. > > > > > >>> > > > > > >>> I'd guess hotplugging, but where I get confused is that IDE disks > don't > > > > > >>> support hotplugging either, so I guess I'm not sure sure what you > > > need. > > > > > >>> > > > > > >>> Stefano, can you help bridge my Xen knowledge gap? > > > > > >> > > > > > >> Hi John, > > > > > >> > > > > > >> we need something like > hw/i386/xen/xen_platform.c:unplug_disks > > > but > > > > > that > > > > > >> can unplug AHCI disk. And by unplug, I mean "make disappear" like > > > > > >> pci_piix3_xen_ide_unplug does for ide. > > > > > > Maybe this would be the right time to stop the craziness with your > > > > > > hybrid IDE/xendisk setup. It's a horrible thing that would never > happen > > > > > > on real hardware. > > > > > > > > Unfortunately, it's going to be difficult to remove such 'craziness' when > you > > > don't know a priori whether the VM has PV drivers or not. > > > > > > Why wouldn't you know that beforehand? I mean, even on real > hardware > > > you > > > can have different disk interfaces (IDE, AHCI, SCSI) and you install > > > the exact driver that your hardware needs. You just do the same thing on > > > VM: If your hardware is PV, you install a PV driver. If your hardware is > > > IDE, you install an IDE driver. Whether it's PV or IDE is something that > > > you, the user, decided when configuring the VM, so you definitely know. > > > > > > > That's not necessarily true. The host admin that provisions the VM does not > necessarily know what OS the user of that VM will install. The admin may just > be providing a generic VM with an emulated CD drive that the user can point > at any ISO they want. > > > > So, as a host admin, if you provide a VM with only PV backends and your > user is trying to boot an OS with no PV drivers they are not going to be > happy, so you provide emulated devices. Then, at some point later, when > the user installs PV drivers, there really should be some way for those drivers > to start up without any need to contact the host admin and have the VM > reconfigured. > > Why only IDE and xendisk then? Maybe I have an OS that works great with > AHCI, or virtio-blk, or an LSI SCSI controller, or a Megasas SCSI > controller, or USB sticks, or... (and IDE will hardly ever be the > optimal one) > > What about network cards? My OS might support the Xen PV one, or it > might support rtl8139, or e1000, or virtio-net, or pcnet, or... > > Should we always put all of the hardware that can possibly be emulated > in a VM just so that the one right device is definitely included even > though we don't know what OS will be running? > > This is ridiculous. It might be, but to some extent it's reality. The reason that the default emulated network device chosen by xl is rtl8193 is that it has drivers in just about every OS. The same reason for IDE being the default choice for storage. > > Just tell your admin what virtual hardware you really need. (Or tell > them to give you a proper interface to configure your VMs yourself.) > My point is that the virtual hardware that the OS user wants will change. Before they install PV drivers, they will need emulated device. After installing PV drivers they will want PV devices. Should they really have to contact their cloud provider to make the switch, when at the moment it happens automatically and transparently (the AHCI problem aside)? Paul > Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 15:10 ` Paul Durrant @ 2015-10-16 16:11 ` Kevin Wolf 2015-10-16 16:11 ` Kevin Wolf 1 sibling, 0 replies; 95+ messages in thread From: Kevin Wolf @ 2015-10-16 16:11 UTC (permalink / raw) To: Paul Durrant Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Stefano Stabellini, Anthony Perard, John Snow Am 16.10.2015 um 17:10 hat Paul Durrant geschrieben: > > -----Original Message----- > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > Sent: 16 October 2015 16:02 > > To: Paul Durrant > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci > > missed in qemu > > > > Am 16.10.2015 um 16:24 hat Paul Durrant geschrieben: > > > > -----Original Message----- > > > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > > > Sent: 16 October 2015 15:04 > > > > To: Paul Durrant > > > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > > > > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for > > ahci > > > > missed in qemu > > > > > > > > Am 14.10.2015 um 14:48 hat Paul Durrant geschrieben: > > > > > > -----Original Message----- > > > > > > From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] > > > > > > Sent: 14 October 2015 12:12 > > > > > > To: Kevin Wolf; Stefano Stabellini > > > > > > Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; xen- > > > > > > devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant > > > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support > > for > > > > ahci > > > > > > missed in qemu > > > > > > > > > > > > > > > > > > > > > > > > Il 14/10/2015 11:47, Kevin Wolf ha scritto: > > > > > > > [ CC qemu-block ] > > > > > > > > > > > > > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > > > > > > >> On Tue, 13 Oct 2015, John Snow wrote: > > > > > > >>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > > > > > >>>> I added ahci disk support in libxl and using it for week seems > > that > > > > was > > > > > > >>>> ok, after a reply of Stefano Stabellini seems that xen disk unplug > > > > > > >>>> support only ide disks: > > > > > > >>>> > > > > > > > > > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 > > > > > > c905374ee8663d5d8 > > > > > > >>>> > > > > > > >>>> Today Paul Durrant told me that even if pv disk is ok also with > > ahci > > > > and > > > > > > >>>> the emulated one is offline can be a risk: > > > > > > >>>> http://lists.xenproject.org/archives/html/win-pv-devel/2015- > > > > > > 10/msg00021.html > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> I tried to take a fast look in qemu code but I not understand the > > > > > > needed > > > > > > >>>> thing for add the xen disk unplug support also for ahci, can > > > > someone do > > > > > > >>>> it or tell me useful information for do it please? > > > > > > >>>> > > > > > > >>>> Thanks for any reply and sorry for my bad english. > > > > > > >>>> > > > > > > >>> I'm not entirely sure what features you need AHCI to support in > > > > order > > > > > > >>> for Xen to be happy. > > > > > > >>> > > > > > > >>> I'd guess hotplugging, but where I get confused is that IDE disks > > don't > > > > > > >>> support hotplugging either, so I guess I'm not sure sure what you > > > > need. > > > > > > >>> > > > > > > >>> Stefano, can you help bridge my Xen knowledge gap? > > > > > > >> > > > > > > >> Hi John, > > > > > > >> > > > > > > >> we need something like > > hw/i386/xen/xen_platform.c:unplug_disks > > > > but > > > > > > that > > > > > > >> can unplug AHCI disk. And by unplug, I mean "make disappear" like > > > > > > >> pci_piix3_xen_ide_unplug does for ide. > > > > > > > Maybe this would be the right time to stop the craziness with your > > > > > > > hybrid IDE/xendisk setup. It's a horrible thing that would never > > happen > > > > > > > on real hardware. > > > > > > > > > > Unfortunately, it's going to be difficult to remove such 'craziness' when > > you > > > > don't know a priori whether the VM has PV drivers or not. > > > > > > > > Why wouldn't you know that beforehand? I mean, even on real > > hardware > > > > you > > > > can have different disk interfaces (IDE, AHCI, SCSI) and you install > > > > the exact driver that your hardware needs. You just do the same thing on > > > > VM: If your hardware is PV, you install a PV driver. If your hardware is > > > > IDE, you install an IDE driver. Whether it's PV or IDE is something that > > > > you, the user, decided when configuring the VM, so you definitely know. > > > > > > > > > > That's not necessarily true. The host admin that provisions the VM does not > > necessarily know what OS the user of that VM will install. The admin may just > > be providing a generic VM with an emulated CD drive that the user can point > > at any ISO they want. > > > > > > So, as a host admin, if you provide a VM with only PV backends and your > > user is trying to boot an OS with no PV drivers they are not going to be > > happy, so you provide emulated devices. Then, at some point later, when > > the user installs PV drivers, there really should be some way for those drivers > > to start up without any need to contact the host admin and have the VM > > reconfigured. > > > > Why only IDE and xendisk then? Maybe I have an OS that works great with > > AHCI, or virtio-blk, or an LSI SCSI controller, or a Megasas SCSI > > controller, or USB sticks, or... (and IDE will hardly ever be the > > optimal one) > > > > What about network cards? My OS might support the Xen PV one, or it > > might support rtl8139, or e1000, or virtio-net, or pcnet, or... > > > > Should we always put all of the hardware that can possibly be emulated > > in a VM just so that the one right device is definitely included even > > though we don't know what OS will be running? > > > > This is ridiculous. > > It might be, but to some extent it's reality. The reason that the > default emulated network device chosen by xl is rtl8193 is that it has > drivers in just about every OS. The same reason for IDE being the > default choice for storage. So what does this mean for a justification for the AHCI + xendisk hybrid proposal? > > Just tell your admin what virtual hardware you really need. (Or tell > > them to give you a proper interface to configure your VMs yourself.) > > > > My point is that the virtual hardware that the OS user wants will > change. Before they install PV drivers, they will need emulated > device. After installing PV drivers they will want PV devices. Should > they really have to contact their cloud provider to make the switch, > when at the moment it happens automatically and transparently (the > AHCI problem aside)? My point is that such a magic change shouldn't happen. It doesn't happen on real hardware either and people still get things installed to non-IDE disks. There is no reason to install the OS onto a different device than will be used later. With Linux, it's no problem at all because the PV drivers are already included on the installation media anyway, and on Windows or presumably any other OS you can load and install the drivers right from the beginning. In fact, I would be surprised if using xendisk instead of IDE for installing Windows didn't result in a noticably faster installation. Now, if you really insist on providing a legacy interface even to guests that eventually use PV drivers, there actually are sane ways to implement this. It will be tricky to make that transition now without breaking compatibility, but it could have been done from the start. Sane means for example that you don't open the same image twice (and even read-write!) at the same time. This is a recipe for disaster and it's surprising that you don't see corrupted images more often. So if you wanted to have a clean solution, try to think how real hardware would solve the problem. If you want me to suggest something off the top of my head, I would come up with an extended IDE device (one single device!) that provides the IDE I/O ports and additionally some MMIO BAR that enables access to PV functionality. Once you enable PV functionality, the IDE ports stop working; device reset disables the PV ring and goes back to IDE mode. No hard disk suddenly disappearing from the machine, no image corruption if the IDE device is written to before enabling PV, etc. But it's your choice. You can keep your broken hack in IDE. Just don't expect anyone to support adding new broken hacks to other devices. Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 15:10 ` Paul Durrant 2015-10-16 16:11 ` Kevin Wolf @ 2015-10-16 16:11 ` Kevin Wolf 2015-10-16 16:20 ` Paul Durrant 2015-10-16 16:20 ` Paul Durrant 1 sibling, 2 replies; 95+ messages in thread From: Kevin Wolf @ 2015-10-16 16:11 UTC (permalink / raw) To: Paul Durrant Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Stefano Stabellini, Anthony Perard, John Snow Am 16.10.2015 um 17:10 hat Paul Durrant geschrieben: > > -----Original Message----- > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > Sent: 16 October 2015 16:02 > > To: Paul Durrant > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci > > missed in qemu > > > > Am 16.10.2015 um 16:24 hat Paul Durrant geschrieben: > > > > -----Original Message----- > > > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > > > Sent: 16 October 2015 15:04 > > > > To: Paul Durrant > > > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > > > > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for > > ahci > > > > missed in qemu > > > > > > > > Am 14.10.2015 um 14:48 hat Paul Durrant geschrieben: > > > > > > -----Original Message----- > > > > > > From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] > > > > > > Sent: 14 October 2015 12:12 > > > > > > To: Kevin Wolf; Stefano Stabellini > > > > > > Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; xen- > > > > > > devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant > > > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support > > for > > > > ahci > > > > > > missed in qemu > > > > > > > > > > > > > > > > > > > > > > > > Il 14/10/2015 11:47, Kevin Wolf ha scritto: > > > > > > > [ CC qemu-block ] > > > > > > > > > > > > > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > > > > > > >> On Tue, 13 Oct 2015, John Snow wrote: > > > > > > >>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > > > > > >>>> I added ahci disk support in libxl and using it for week seems > > that > > > > was > > > > > > >>>> ok, after a reply of Stefano Stabellini seems that xen disk unplug > > > > > > >>>> support only ide disks: > > > > > > >>>> > > > > > > > > > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 > > > > > > c905374ee8663d5d8 > > > > > > >>>> > > > > > > >>>> Today Paul Durrant told me that even if pv disk is ok also with > > ahci > > > > and > > > > > > >>>> the emulated one is offline can be a risk: > > > > > > >>>> http://lists.xenproject.org/archives/html/win-pv-devel/2015- > > > > > > 10/msg00021.html > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> I tried to take a fast look in qemu code but I not understand the > > > > > > needed > > > > > > >>>> thing for add the xen disk unplug support also for ahci, can > > > > someone do > > > > > > >>>> it or tell me useful information for do it please? > > > > > > >>>> > > > > > > >>>> Thanks for any reply and sorry for my bad english. > > > > > > >>>> > > > > > > >>> I'm not entirely sure what features you need AHCI to support in > > > > order > > > > > > >>> for Xen to be happy. > > > > > > >>> > > > > > > >>> I'd guess hotplugging, but where I get confused is that IDE disks > > don't > > > > > > >>> support hotplugging either, so I guess I'm not sure sure what you > > > > need. > > > > > > >>> > > > > > > >>> Stefano, can you help bridge my Xen knowledge gap? > > > > > > >> > > > > > > >> Hi John, > > > > > > >> > > > > > > >> we need something like > > hw/i386/xen/xen_platform.c:unplug_disks > > > > but > > > > > > that > > > > > > >> can unplug AHCI disk. And by unplug, I mean "make disappear" like > > > > > > >> pci_piix3_xen_ide_unplug does for ide. > > > > > > > Maybe this would be the right time to stop the craziness with your > > > > > > > hybrid IDE/xendisk setup. It's a horrible thing that would never > > happen > > > > > > > on real hardware. > > > > > > > > > > Unfortunately, it's going to be difficult to remove such 'craziness' when > > you > > > > don't know a priori whether the VM has PV drivers or not. > > > > > > > > Why wouldn't you know that beforehand? I mean, even on real > > hardware > > > > you > > > > can have different disk interfaces (IDE, AHCI, SCSI) and you install > > > > the exact driver that your hardware needs. You just do the same thing on > > > > VM: If your hardware is PV, you install a PV driver. If your hardware is > > > > IDE, you install an IDE driver. Whether it's PV or IDE is something that > > > > you, the user, decided when configuring the VM, so you definitely know. > > > > > > > > > > That's not necessarily true. The host admin that provisions the VM does not > > necessarily know what OS the user of that VM will install. The admin may just > > be providing a generic VM with an emulated CD drive that the user can point > > at any ISO they want. > > > > > > So, as a host admin, if you provide a VM with only PV backends and your > > user is trying to boot an OS with no PV drivers they are not going to be > > happy, so you provide emulated devices. Then, at some point later, when > > the user installs PV drivers, there really should be some way for those drivers > > to start up without any need to contact the host admin and have the VM > > reconfigured. > > > > Why only IDE and xendisk then? Maybe I have an OS that works great with > > AHCI, or virtio-blk, or an LSI SCSI controller, or a Megasas SCSI > > controller, or USB sticks, or... (and IDE will hardly ever be the > > optimal one) > > > > What about network cards? My OS might support the Xen PV one, or it > > might support rtl8139, or e1000, or virtio-net, or pcnet, or... > > > > Should we always put all of the hardware that can possibly be emulated > > in a VM just so that the one right device is definitely included even > > though we don't know what OS will be running? > > > > This is ridiculous. > > It might be, but to some extent it's reality. The reason that the > default emulated network device chosen by xl is rtl8193 is that it has > drivers in just about every OS. The same reason for IDE being the > default choice for storage. So what does this mean for a justification for the AHCI + xendisk hybrid proposal? > > Just tell your admin what virtual hardware you really need. (Or tell > > them to give you a proper interface to configure your VMs yourself.) > > > > My point is that the virtual hardware that the OS user wants will > change. Before they install PV drivers, they will need emulated > device. After installing PV drivers they will want PV devices. Should > they really have to contact their cloud provider to make the switch, > when at the moment it happens automatically and transparently (the > AHCI problem aside)? My point is that such a magic change shouldn't happen. It doesn't happen on real hardware either and people still get things installed to non-IDE disks. There is no reason to install the OS onto a different device than will be used later. With Linux, it's no problem at all because the PV drivers are already included on the installation media anyway, and on Windows or presumably any other OS you can load and install the drivers right from the beginning. In fact, I would be surprised if using xendisk instead of IDE for installing Windows didn't result in a noticably faster installation. Now, if you really insist on providing a legacy interface even to guests that eventually use PV drivers, there actually are sane ways to implement this. It will be tricky to make that transition now without breaking compatibility, but it could have been done from the start. Sane means for example that you don't open the same image twice (and even read-write!) at the same time. This is a recipe for disaster and it's surprising that you don't see corrupted images more often. So if you wanted to have a clean solution, try to think how real hardware would solve the problem. If you want me to suggest something off the top of my head, I would come up with an extended IDE device (one single device!) that provides the IDE I/O ports and additionally some MMIO BAR that enables access to PV functionality. Once you enable PV functionality, the IDE ports stop working; device reset disables the PV ring and goes back to IDE mode. No hard disk suddenly disappearing from the machine, no image corruption if the IDE device is written to before enabling PV, etc. But it's your choice. You can keep your broken hack in IDE. Just don't expect anyone to support adding new broken hacks to other devices. Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 16:11 ` Kevin Wolf @ 2015-10-16 16:20 ` Paul Durrant 2015-10-16 16:42 ` Kevin Wolf ` (3 more replies) 2015-10-16 16:20 ` Paul Durrant 1 sibling, 4 replies; 95+ messages in thread From: Paul Durrant @ 2015-10-16 16:20 UTC (permalink / raw) To: Kevin Wolf Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Stefano Stabellini, Anthony Perard, John Snow > -----Original Message----- > From: Kevin Wolf [mailto:kwolf@redhat.com] > Sent: 16 October 2015 17:12 > To: Paul Durrant > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci > missed in qemu > > Am 16.10.2015 um 17:10 hat Paul Durrant geschrieben: > > > -----Original Message----- > > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > > Sent: 16 October 2015 16:02 > > > To: Paul Durrant > > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > > > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for > ahci > > > missed in qemu > > > > > > Am 16.10.2015 um 16:24 hat Paul Durrant geschrieben: > > > > > -----Original Message----- > > > > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > > > > Sent: 16 October 2015 15:04 > > > > > To: Paul Durrant > > > > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; > qemu- > > > > > devel@nongnu.org; xen-devel@lists.xen.org; qemu- > block@nongnu.org > > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support > for > > > ahci > > > > > missed in qemu > > > > > > > > > > Am 14.10.2015 um 14:48 hat Paul Durrant geschrieben: > > > > > > > -----Original Message----- > > > > > > > From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] > > > > > > > Sent: 14 October 2015 12:12 > > > > > > > To: Kevin Wolf; Stefano Stabellini > > > > > > > Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; xen- > > > > > > > devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant > > > > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug > support > > > for > > > > > ahci > > > > > > > missed in qemu > > > > > > > > > > > > > > > > > > > > > > > > > > > > Il 14/10/2015 11:47, Kevin Wolf ha scritto: > > > > > > > > [ CC qemu-block ] > > > > > > > > > > > > > > > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > > > > > > > >> On Tue, 13 Oct 2015, John Snow wrote: > > > > > > > >>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > > > > > > >>>> I added ahci disk support in libxl and using it for week seems > > > that > > > > > was > > > > > > > >>>> ok, after a reply of Stefano Stabellini seems that xen disk > unplug > > > > > > > >>>> support only ide disks: > > > > > > > >>>> > > > > > > > > > > > > > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 > > > > > > > c905374ee8663d5d8 > > > > > > > >>>> > > > > > > > >>>> Today Paul Durrant told me that even if pv disk is ok also > with > > > ahci > > > > > and > > > > > > > >>>> the emulated one is offline can be a risk: > > > > > > > >>>> http://lists.xenproject.org/archives/html/win-pv- > devel/2015- > > > > > > > 10/msg00021.html > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> I tried to take a fast look in qemu code but I not understand > the > > > > > > > needed > > > > > > > >>>> thing for add the xen disk unplug support also for ahci, can > > > > > someone do > > > > > > > >>>> it or tell me useful information for do it please? > > > > > > > >>>> > > > > > > > >>>> Thanks for any reply and sorry for my bad english. > > > > > > > >>>> > > > > > > > >>> I'm not entirely sure what features you need AHCI to support > in > > > > > order > > > > > > > >>> for Xen to be happy. > > > > > > > >>> > > > > > > > >>> I'd guess hotplugging, but where I get confused is that IDE > disks > > > don't > > > > > > > >>> support hotplugging either, so I guess I'm not sure sure what > you > > > > > need. > > > > > > > >>> > > > > > > > >>> Stefano, can you help bridge my Xen knowledge gap? > > > > > > > >> > > > > > > > >> Hi John, > > > > > > > >> > > > > > > > >> we need something like > > > hw/i386/xen/xen_platform.c:unplug_disks > > > > > but > > > > > > > that > > > > > > > >> can unplug AHCI disk. And by unplug, I mean "make disappear" > like > > > > > > > >> pci_piix3_xen_ide_unplug does for ide. > > > > > > > > Maybe this would be the right time to stop the craziness with > your > > > > > > > > hybrid IDE/xendisk setup. It's a horrible thing that would never > > > happen > > > > > > > > on real hardware. > > > > > > > > > > > > Unfortunately, it's going to be difficult to remove such 'craziness' > when > > > you > > > > > don't know a priori whether the VM has PV drivers or not. > > > > > > > > > > Why wouldn't you know that beforehand? I mean, even on real > > > hardware > > > > > you > > > > > can have different disk interfaces (IDE, AHCI, SCSI) and you install > > > > > the exact driver that your hardware needs. You just do the same > thing on > > > > > VM: If your hardware is PV, you install a PV driver. If your hardware is > > > > > IDE, you install an IDE driver. Whether it's PV or IDE is something that > > > > > you, the user, decided when configuring the VM, so you definitely > know. > > > > > > > > > > > > > That's not necessarily true. The host admin that provisions the VM does > not > > > necessarily know what OS the user of that VM will install. The admin may > just > > > be providing a generic VM with an emulated CD drive that the user can > point > > > at any ISO they want. > > > > > > > > So, as a host admin, if you provide a VM with only PV backends and > your > > > user is trying to boot an OS with no PV drivers they are not going to be > > > happy, so you provide emulated devices. Then, at some point later, when > > > the user installs PV drivers, there really should be some way for those > drivers > > > to start up without any need to contact the host admin and have the VM > > > reconfigured. > > > > > > Why only IDE and xendisk then? Maybe I have an OS that works great > with > > > AHCI, or virtio-blk, or an LSI SCSI controller, or a Megasas SCSI > > > controller, or USB sticks, or... (and IDE will hardly ever be the > > > optimal one) > > > > > > What about network cards? My OS might support the Xen PV one, or it > > > might support rtl8139, or e1000, or virtio-net, or pcnet, or... > > > > > > Should we always put all of the hardware that can possibly be emulated > > > in a VM just so that the one right device is definitely included even > > > though we don't know what OS will be running? > > > > > > This is ridiculous. > > > > It might be, but to some extent it's reality. The reason that the > > default emulated network device chosen by xl is rtl8193 is that it has > > drivers in just about every OS. The same reason for IDE being the > > default choice for storage. > > So what does this mean for a justification for the AHCI + xendisk hybrid > proposal? > > > > Just tell your admin what virtual hardware you really need. (Or tell > > > them to give you a proper interface to configure your VMs yourself.) > > > > > > > My point is that the virtual hardware that the OS user wants will > > change. Before they install PV drivers, they will need emulated > > device. After installing PV drivers they will want PV devices. Should > > they really have to contact their cloud provider to make the switch, > > when at the moment it happens automatically and transparently (the > > AHCI problem aside)? > > My point is that such a magic change shouldn't happen. It doesn't happen > on real hardware either and people still get things installed to non-IDE > disks. > > There is no reason to install the OS onto a different device than will > be used later. With Linux, it's no problem at all because the PV drivers > are already included on the installation media anyway, and on Windows or > presumably any other OS you can load and install the drivers right from > the beginning. > > In fact, I would be surprised if using xendisk instead of IDE for > installing Windows didn't result in a noticably faster installation. > It most certainly would, but requiring users do it this way is likely to meet some resistance I suspect. > > Now, if you really insist on providing a legacy interface even to guests > that eventually use PV drivers, there actually are sane ways to > implement this. It will be tricky to make that transition now without > breaking compatibility, but it could have been done from the start. > > Sane means for example that you don't open the same image twice (and > even read-write!) at the same time. This is a recipe for disaster and > it's surprising that you don't see corrupted images more often. > We don't because unplug is supposed to ensure the emulated device is gone before the PV frontend is started > So if you wanted to have a clean solution, try to think how real > hardware would solve the problem. If you want me to suggest something > off the top of my head, I would come up with an extended IDE device (one > single device!) that provides the IDE I/O ports and additionally some > MMIO BAR that enables access to PV functionality. > > Once you enable PV functionality, the IDE ports stop working; device > reset disables the PV ring and goes back to IDE mode. No hard disk > suddenly disappearing from the machine, no image corruption if the IDE > device is written to before enabling PV, etc. > That's not sufficient though. The IDE device must not be enumerated by the OS and, in Windows at least, that enumeration occurs before the PV frontend has started up. > > But it's your choice. You can keep your broken hack in IDE. Just don't > expect anyone to support adding new broken hacks to other devices. > I'd prefer to have a cleaner solution and I believe can achieve that in Windows by obscuring the emulated disks using filter drivers, so that's the way I'll probably go. Paul > Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 16:20 ` Paul Durrant @ 2015-10-16 16:42 ` Kevin Wolf 2015-10-16 16:42 ` Kevin Wolf ` (2 subsequent siblings) 3 siblings, 0 replies; 95+ messages in thread From: Kevin Wolf @ 2015-10-16 16:42 UTC (permalink / raw) To: Paul Durrant Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Stefano Stabellini, Anthony Perard, John Snow Am 16.10.2015 um 18:20 hat Paul Durrant geschrieben: > > -----Original Message----- > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > Sent: 16 October 2015 17:12 > > To: Paul Durrant > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci > > missed in qemu > > > > Am 16.10.2015 um 17:10 hat Paul Durrant geschrieben: > > > > -----Original Message----- > > > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > > > Sent: 16 October 2015 16:02 > > > > To: Paul Durrant > > > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > > > > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for > > ahci > > > > missed in qemu > > > > > > > > Am 16.10.2015 um 16:24 hat Paul Durrant geschrieben: > > > > > > -----Original Message----- > > > > > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > > > > > Sent: 16 October 2015 15:04 > > > > > > To: Paul Durrant > > > > > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; > > qemu- > > > > > > devel@nongnu.org; xen-devel@lists.xen.org; qemu- > > block@nongnu.org > > > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support > > for > > > > ahci > > > > > > missed in qemu > > > > > > > > > > > > Am 14.10.2015 um 14:48 hat Paul Durrant geschrieben: > > > > > > > > -----Original Message----- > > > > > > > > From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] > > > > > > > > Sent: 14 October 2015 12:12 > > > > > > > > To: Kevin Wolf; Stefano Stabellini > > > > > > > > Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; xen- > > > > > > > > devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant > > > > > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug > > support > > > > for > > > > > > ahci > > > > > > > > missed in qemu > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Il 14/10/2015 11:47, Kevin Wolf ha scritto: > > > > > > > > > [ CC qemu-block ] > > > > > > > > > > > > > > > > > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > > > > > > > > >> On Tue, 13 Oct 2015, John Snow wrote: > > > > > > > > >>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > > > > > > > >>>> I added ahci disk support in libxl and using it for week seems > > > > that > > > > > > was > > > > > > > > >>>> ok, after a reply of Stefano Stabellini seems that xen disk > > unplug > > > > > > > > >>>> support only ide disks: > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 > > > > > > > > c905374ee8663d5d8 > > > > > > > > >>>> > > > > > > > > >>>> Today Paul Durrant told me that even if pv disk is ok also > > with > > > > ahci > > > > > > and > > > > > > > > >>>> the emulated one is offline can be a risk: > > > > > > > > >>>> http://lists.xenproject.org/archives/html/win-pv- > > devel/2015- > > > > > > > > 10/msg00021.html > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> I tried to take a fast look in qemu code but I not understand > > the > > > > > > > > needed > > > > > > > > >>>> thing for add the xen disk unplug support also for ahci, can > > > > > > someone do > > > > > > > > >>>> it or tell me useful information for do it please? > > > > > > > > >>>> > > > > > > > > >>>> Thanks for any reply and sorry for my bad english. > > > > > > > > >>>> > > > > > > > > >>> I'm not entirely sure what features you need AHCI to support > > in > > > > > > order > > > > > > > > >>> for Xen to be happy. > > > > > > > > >>> > > > > > > > > >>> I'd guess hotplugging, but where I get confused is that IDE > > disks > > > > don't > > > > > > > > >>> support hotplugging either, so I guess I'm not sure sure what > > you > > > > > > need. > > > > > > > > >>> > > > > > > > > >>> Stefano, can you help bridge my Xen knowledge gap? > > > > > > > > >> > > > > > > > > >> Hi John, > > > > > > > > >> > > > > > > > > >> we need something like > > > > hw/i386/xen/xen_platform.c:unplug_disks > > > > > > but > > > > > > > > that > > > > > > > > >> can unplug AHCI disk. And by unplug, I mean "make disappear" > > like > > > > > > > > >> pci_piix3_xen_ide_unplug does for ide. > > > > > > > > > Maybe this would be the right time to stop the craziness with > > your > > > > > > > > > hybrid IDE/xendisk setup. It's a horrible thing that would never > > > > happen > > > > > > > > > on real hardware. > > > > > > > > > > > > > > Unfortunately, it's going to be difficult to remove such 'craziness' > > when > > > > you > > > > > > don't know a priori whether the VM has PV drivers or not. > > > > > > > > > > > > Why wouldn't you know that beforehand? I mean, even on real > > > > hardware > > > > > > you > > > > > > can have different disk interfaces (IDE, AHCI, SCSI) and you install > > > > > > the exact driver that your hardware needs. You just do the same > > thing on > > > > > > VM: If your hardware is PV, you install a PV driver. If your hardware is > > > > > > IDE, you install an IDE driver. Whether it's PV or IDE is something that > > > > > > you, the user, decided when configuring the VM, so you definitely > > know. > > > > > > > > > > > > > > > > That's not necessarily true. The host admin that provisions the VM does > > not > > > > necessarily know what OS the user of that VM will install. The admin may > > just > > > > be providing a generic VM with an emulated CD drive that the user can > > point > > > > at any ISO they want. > > > > > > > > > > So, as a host admin, if you provide a VM with only PV backends and > > your > > > > user is trying to boot an OS with no PV drivers they are not going to be > > > > happy, so you provide emulated devices. Then, at some point later, when > > > > the user installs PV drivers, there really should be some way for those > > drivers > > > > to start up without any need to contact the host admin and have the VM > > > > reconfigured. > > > > > > > > Why only IDE and xendisk then? Maybe I have an OS that works great > > with > > > > AHCI, or virtio-blk, or an LSI SCSI controller, or a Megasas SCSI > > > > controller, or USB sticks, or... (and IDE will hardly ever be the > > > > optimal one) > > > > > > > > What about network cards? My OS might support the Xen PV one, or it > > > > might support rtl8139, or e1000, or virtio-net, or pcnet, or... > > > > > > > > Should we always put all of the hardware that can possibly be emulated > > > > in a VM just so that the one right device is definitely included even > > > > though we don't know what OS will be running? > > > > > > > > This is ridiculous. > > > > > > It might be, but to some extent it's reality. The reason that the > > > default emulated network device chosen by xl is rtl8193 is that it has > > > drivers in just about every OS. The same reason for IDE being the > > > default choice for storage. > > > > So what does this mean for a justification for the AHCI + xendisk hybrid > > proposal? > > > > > > Just tell your admin what virtual hardware you really need. (Or tell > > > > them to give you a proper interface to configure your VMs yourself.) > > > > > > > > > > My point is that the virtual hardware that the OS user wants will > > > change. Before they install PV drivers, they will need emulated > > > device. After installing PV drivers they will want PV devices. Should > > > they really have to contact their cloud provider to make the switch, > > > when at the moment it happens automatically and transparently (the > > > AHCI problem aside)? > > > > My point is that such a magic change shouldn't happen. It doesn't happen > > on real hardware either and people still get things installed to non-IDE > > disks. > > > > There is no reason to install the OS onto a different device than will > > be used later. With Linux, it's no problem at all because the PV drivers > > are already included on the installation media anyway, and on Windows or > > presumably any other OS you can load and install the drivers right from > > the beginning. > > > > In fact, I would be surprised if using xendisk instead of IDE for > > installing Windows didn't result in a noticably faster installation. > > > > It most certainly would, but requiring users do it this way is likely to meet some resistance I suspect. Why do you think so? Installing the PV drivers afterwards doesn't seem easier than just providing them during the installation. > > Now, if you really insist on providing a legacy interface even to guests > > that eventually use PV drivers, there actually are sane ways to > > implement this. It will be tricky to make that transition now without > > breaking compatibility, but it could have been done from the start. > > > > Sane means for example that you don't open the same image twice (and > > even read-write!) at the same time. This is a recipe for disaster and > > it's surprising that you don't see corrupted images more often. > > > > We don't because unplug is supposed to ensure the emulated device is > gone before the PV frontend is started The important part is the backend, but it seems that you open the second instance of the image only when starting the PV frontend? As long as you don't enable the user to use most of qemu's functionality like starting block jobs (which would keep the IDE instance around even after unplugging the disk), it might actually be safe assuming that the guest cooperates. Not sure what a malicious guest could do, though, as nobody seems to check whether IDE is really unplugged before the second instance is opened. raw and qcow2 should be safe these days, but in earlier times it would probably have been possible for the guest to overwrite the image header and access arbitrary files on the host as backing file. It might still be true for other image formats. > > So if you wanted to have a clean solution, try to think how real > > hardware would solve the problem. If you want me to suggest something > > off the top of my head, I would come up with an extended IDE device (one > > single device!) that provides the IDE I/O ports and additionally some > > MMIO BAR that enables access to PV functionality. > > > > Once you enable PV functionality, the IDE ports stop working; device > > reset disables the PV ring and goes back to IDE mode. No hard disk > > suddenly disappearing from the machine, no image corruption if the IDE > > device is written to before enabling PV, etc. > > > > That's not sufficient though. The IDE device must not be enumerated by > the OS and, in Windows at least, that enumeration occurs before the PV > frontend has started up. The trick is that it's only a single device, so there is no second device that must be prevented from being enumerated. You provide a driver for this specific IDE controller, so Windows wouldn't even try the generic IDE driver when your driver is available. It's kind of the same sort of IDE controller extension as Bus Master DMA, which just added a new BAR. If you had an old driver, it would just ignore the new registers. If you had a new one, it would use them. But in no way would the old appearance of the device simply disappear, you just use an extended register set on the same device. > > But it's your choice. You can keep your broken hack in IDE. Just don't > > expect anyone to support adding new broken hacks to other devices. > > > > I'd prefer to have a cleaner solution and I believe can achieve that in Windows by obscuring the emulated disks using filter drivers, so that's the way I'll probably go. I wouldn't consider anything that works with two distinct disk devices and two separate BlockDriverStates for the same image file a clean solution. Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 16:20 ` Paul Durrant 2015-10-16 16:42 ` Kevin Wolf @ 2015-10-16 16:42 ` Kevin Wolf 2015-10-16 16:53 ` Paul Durrant 2015-10-16 16:53 ` Paul Durrant 2015-10-16 16:53 ` Eric Blake 2015-10-16 16:53 ` Eric Blake 3 siblings, 2 replies; 95+ messages in thread From: Kevin Wolf @ 2015-10-16 16:42 UTC (permalink / raw) To: Paul Durrant Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Stefano Stabellini, Anthony Perard, John Snow Am 16.10.2015 um 18:20 hat Paul Durrant geschrieben: > > -----Original Message----- > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > Sent: 16 October 2015 17:12 > > To: Paul Durrant > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci > > missed in qemu > > > > Am 16.10.2015 um 17:10 hat Paul Durrant geschrieben: > > > > -----Original Message----- > > > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > > > Sent: 16 October 2015 16:02 > > > > To: Paul Durrant > > > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > > > > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for > > ahci > > > > missed in qemu > > > > > > > > Am 16.10.2015 um 16:24 hat Paul Durrant geschrieben: > > > > > > -----Original Message----- > > > > > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > > > > > Sent: 16 October 2015 15:04 > > > > > > To: Paul Durrant > > > > > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; > > qemu- > > > > > > devel@nongnu.org; xen-devel@lists.xen.org; qemu- > > block@nongnu.org > > > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support > > for > > > > ahci > > > > > > missed in qemu > > > > > > > > > > > > Am 14.10.2015 um 14:48 hat Paul Durrant geschrieben: > > > > > > > > -----Original Message----- > > > > > > > > From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] > > > > > > > > Sent: 14 October 2015 12:12 > > > > > > > > To: Kevin Wolf; Stefano Stabellini > > > > > > > > Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; xen- > > > > > > > > devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant > > > > > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug > > support > > > > for > > > > > > ahci > > > > > > > > missed in qemu > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Il 14/10/2015 11:47, Kevin Wolf ha scritto: > > > > > > > > > [ CC qemu-block ] > > > > > > > > > > > > > > > > > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > > > > > > > > >> On Tue, 13 Oct 2015, John Snow wrote: > > > > > > > > >>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > > > > > > > >>>> I added ahci disk support in libxl and using it for week seems > > > > that > > > > > > was > > > > > > > > >>>> ok, after a reply of Stefano Stabellini seems that xen disk > > unplug > > > > > > > > >>>> support only ide disks: > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 > > > > > > > > c905374ee8663d5d8 > > > > > > > > >>>> > > > > > > > > >>>> Today Paul Durrant told me that even if pv disk is ok also > > with > > > > ahci > > > > > > and > > > > > > > > >>>> the emulated one is offline can be a risk: > > > > > > > > >>>> http://lists.xenproject.org/archives/html/win-pv- > > devel/2015- > > > > > > > > 10/msg00021.html > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> I tried to take a fast look in qemu code but I not understand > > the > > > > > > > > needed > > > > > > > > >>>> thing for add the xen disk unplug support also for ahci, can > > > > > > someone do > > > > > > > > >>>> it or tell me useful information for do it please? > > > > > > > > >>>> > > > > > > > > >>>> Thanks for any reply and sorry for my bad english. > > > > > > > > >>>> > > > > > > > > >>> I'm not entirely sure what features you need AHCI to support > > in > > > > > > order > > > > > > > > >>> for Xen to be happy. > > > > > > > > >>> > > > > > > > > >>> I'd guess hotplugging, but where I get confused is that IDE > > disks > > > > don't > > > > > > > > >>> support hotplugging either, so I guess I'm not sure sure what > > you > > > > > > need. > > > > > > > > >>> > > > > > > > > >>> Stefano, can you help bridge my Xen knowledge gap? > > > > > > > > >> > > > > > > > > >> Hi John, > > > > > > > > >> > > > > > > > > >> we need something like > > > > hw/i386/xen/xen_platform.c:unplug_disks > > > > > > but > > > > > > > > that > > > > > > > > >> can unplug AHCI disk. And by unplug, I mean "make disappear" > > like > > > > > > > > >> pci_piix3_xen_ide_unplug does for ide. > > > > > > > > > Maybe this would be the right time to stop the craziness with > > your > > > > > > > > > hybrid IDE/xendisk setup. It's a horrible thing that would never > > > > happen > > > > > > > > > on real hardware. > > > > > > > > > > > > > > Unfortunately, it's going to be difficult to remove such 'craziness' > > when > > > > you > > > > > > don't know a priori whether the VM has PV drivers or not. > > > > > > > > > > > > Why wouldn't you know that beforehand? I mean, even on real > > > > hardware > > > > > > you > > > > > > can have different disk interfaces (IDE, AHCI, SCSI) and you install > > > > > > the exact driver that your hardware needs. You just do the same > > thing on > > > > > > VM: If your hardware is PV, you install a PV driver. If your hardware is > > > > > > IDE, you install an IDE driver. Whether it's PV or IDE is something that > > > > > > you, the user, decided when configuring the VM, so you definitely > > know. > > > > > > > > > > > > > > > > That's not necessarily true. The host admin that provisions the VM does > > not > > > > necessarily know what OS the user of that VM will install. The admin may > > just > > > > be providing a generic VM with an emulated CD drive that the user can > > point > > > > at any ISO they want. > > > > > > > > > > So, as a host admin, if you provide a VM with only PV backends and > > your > > > > user is trying to boot an OS with no PV drivers they are not going to be > > > > happy, so you provide emulated devices. Then, at some point later, when > > > > the user installs PV drivers, there really should be some way for those > > drivers > > > > to start up without any need to contact the host admin and have the VM > > > > reconfigured. > > > > > > > > Why only IDE and xendisk then? Maybe I have an OS that works great > > with > > > > AHCI, or virtio-blk, or an LSI SCSI controller, or a Megasas SCSI > > > > controller, or USB sticks, or... (and IDE will hardly ever be the > > > > optimal one) > > > > > > > > What about network cards? My OS might support the Xen PV one, or it > > > > might support rtl8139, or e1000, or virtio-net, or pcnet, or... > > > > > > > > Should we always put all of the hardware that can possibly be emulated > > > > in a VM just so that the one right device is definitely included even > > > > though we don't know what OS will be running? > > > > > > > > This is ridiculous. > > > > > > It might be, but to some extent it's reality. The reason that the > > > default emulated network device chosen by xl is rtl8193 is that it has > > > drivers in just about every OS. The same reason for IDE being the > > > default choice for storage. > > > > So what does this mean for a justification for the AHCI + xendisk hybrid > > proposal? > > > > > > Just tell your admin what virtual hardware you really need. (Or tell > > > > them to give you a proper interface to configure your VMs yourself.) > > > > > > > > > > My point is that the virtual hardware that the OS user wants will > > > change. Before they install PV drivers, they will need emulated > > > device. After installing PV drivers they will want PV devices. Should > > > they really have to contact their cloud provider to make the switch, > > > when at the moment it happens automatically and transparently (the > > > AHCI problem aside)? > > > > My point is that such a magic change shouldn't happen. It doesn't happen > > on real hardware either and people still get things installed to non-IDE > > disks. > > > > There is no reason to install the OS onto a different device than will > > be used later. With Linux, it's no problem at all because the PV drivers > > are already included on the installation media anyway, and on Windows or > > presumably any other OS you can load and install the drivers right from > > the beginning. > > > > In fact, I would be surprised if using xendisk instead of IDE for > > installing Windows didn't result in a noticably faster installation. > > > > It most certainly would, but requiring users do it this way is likely to meet some resistance I suspect. Why do you think so? Installing the PV drivers afterwards doesn't seem easier than just providing them during the installation. > > Now, if you really insist on providing a legacy interface even to guests > > that eventually use PV drivers, there actually are sane ways to > > implement this. It will be tricky to make that transition now without > > breaking compatibility, but it could have been done from the start. > > > > Sane means for example that you don't open the same image twice (and > > even read-write!) at the same time. This is a recipe for disaster and > > it's surprising that you don't see corrupted images more often. > > > > We don't because unplug is supposed to ensure the emulated device is > gone before the PV frontend is started The important part is the backend, but it seems that you open the second instance of the image only when starting the PV frontend? As long as you don't enable the user to use most of qemu's functionality like starting block jobs (which would keep the IDE instance around even after unplugging the disk), it might actually be safe assuming that the guest cooperates. Not sure what a malicious guest could do, though, as nobody seems to check whether IDE is really unplugged before the second instance is opened. raw and qcow2 should be safe these days, but in earlier times it would probably have been possible for the guest to overwrite the image header and access arbitrary files on the host as backing file. It might still be true for other image formats. > > So if you wanted to have a clean solution, try to think how real > > hardware would solve the problem. If you want me to suggest something > > off the top of my head, I would come up with an extended IDE device (one > > single device!) that provides the IDE I/O ports and additionally some > > MMIO BAR that enables access to PV functionality. > > > > Once you enable PV functionality, the IDE ports stop working; device > > reset disables the PV ring and goes back to IDE mode. No hard disk > > suddenly disappearing from the machine, no image corruption if the IDE > > device is written to before enabling PV, etc. > > > > That's not sufficient though. The IDE device must not be enumerated by > the OS and, in Windows at least, that enumeration occurs before the PV > frontend has started up. The trick is that it's only a single device, so there is no second device that must be prevented from being enumerated. You provide a driver for this specific IDE controller, so Windows wouldn't even try the generic IDE driver when your driver is available. It's kind of the same sort of IDE controller extension as Bus Master DMA, which just added a new BAR. If you had an old driver, it would just ignore the new registers. If you had a new one, it would use them. But in no way would the old appearance of the device simply disappear, you just use an extended register set on the same device. > > But it's your choice. You can keep your broken hack in IDE. Just don't > > expect anyone to support adding new broken hacks to other devices. > > > > I'd prefer to have a cleaner solution and I believe can achieve that in Windows by obscuring the emulated disks using filter drivers, so that's the way I'll probably go. I wouldn't consider anything that works with two distinct disk devices and two separate BlockDriverStates for the same image file a clean solution. Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 16:42 ` Kevin Wolf @ 2015-10-16 16:53 ` Paul Durrant 2015-10-16 17:03 ` Kevin Wolf ` (3 more replies) 2015-10-16 16:53 ` Paul Durrant 1 sibling, 4 replies; 95+ messages in thread From: Paul Durrant @ 2015-10-16 16:53 UTC (permalink / raw) To: Kevin Wolf Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Stefano Stabellini, Anthony Perard, John Snow > -----Original Message----- > From: Kevin Wolf [mailto:kwolf@redhat.com] > Sent: 16 October 2015 17:43 > To: Paul Durrant > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci > missed in qemu > > Am 16.10.2015 um 18:20 hat Paul Durrant geschrieben: > > > -----Original Message----- > > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > > Sent: 16 October 2015 17:12 > > > To: Paul Durrant > > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > > > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for > ahci > > > missed in qemu > > > > > > Am 16.10.2015 um 17:10 hat Paul Durrant geschrieben: > > > > > -----Original Message----- > > > > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > > > > Sent: 16 October 2015 16:02 > > > > > To: Paul Durrant > > > > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; > qemu- > > > > > devel@nongnu.org; xen-devel@lists.xen.org; qemu- > block@nongnu.org > > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support > for > > > ahci > > > > > missed in qemu > > > > > > > > > > Am 16.10.2015 um 16:24 hat Paul Durrant geschrieben: > > > > > > > -----Original Message----- > > > > > > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > > > > > > Sent: 16 October 2015 15:04 > > > > > > > To: Paul Durrant > > > > > > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; > > > qemu- > > > > > > > devel@nongnu.org; xen-devel@lists.xen.org; qemu- > > > block@nongnu.org > > > > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug > support > > > for > > > > > ahci > > > > > > > missed in qemu > > > > > > > > > > > > > > Am 14.10.2015 um 14:48 hat Paul Durrant geschrieben: > > > > > > > > > -----Original Message----- > > > > > > > > > From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] > > > > > > > > > Sent: 14 October 2015 12:12 > > > > > > > > > To: Kevin Wolf; Stefano Stabellini > > > > > > > > > Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; > xen- > > > > > > > > > devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant > > > > > > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug > > > support > > > > > for > > > > > > > ahci > > > > > > > > > missed in qemu > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Il 14/10/2015 11:47, Kevin Wolf ha scritto: > > > > > > > > > > [ CC qemu-block ] > > > > > > > > > > > > > > > > > > > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > > > > > > > > > >> On Tue, 13 Oct 2015, John Snow wrote: > > > > > > > > > >>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > > > > > > > > >>>> I added ahci disk support in libxl and using it for week > seems > > > > > that > > > > > > > was > > > > > > > > > >>>> ok, after a reply of Stefano Stabellini seems that xen disk > > > unplug > > > > > > > > > >>>> support only ide disks: > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > > > > > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 > > > > > > > > > c905374ee8663d5d8 > > > > > > > > > >>>> > > > > > > > > > >>>> Today Paul Durrant told me that even if pv disk is ok also > > > with > > > > > ahci > > > > > > > and > > > > > > > > > >>>> the emulated one is offline can be a risk: > > > > > > > > > >>>> http://lists.xenproject.org/archives/html/win-pv- > > > devel/2015- > > > > > > > > > 10/msg00021.html > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > > >>>> I tried to take a fast look in qemu code but I not > understand > > > the > > > > > > > > > needed > > > > > > > > > >>>> thing for add the xen disk unplug support also for ahci, > can > > > > > > > someone do > > > > > > > > > >>>> it or tell me useful information for do it please? > > > > > > > > > >>>> > > > > > > > > > >>>> Thanks for any reply and sorry for my bad english. > > > > > > > > > >>>> > > > > > > > > > >>> I'm not entirely sure what features you need AHCI to > support > > > in > > > > > > > order > > > > > > > > > >>> for Xen to be happy. > > > > > > > > > >>> > > > > > > > > > >>> I'd guess hotplugging, but where I get confused is that IDE > > > disks > > > > > don't > > > > > > > > > >>> support hotplugging either, so I guess I'm not sure sure > what > > > you > > > > > > > need. > > > > > > > > > >>> > > > > > > > > > >>> Stefano, can you help bridge my Xen knowledge gap? > > > > > > > > > >> > > > > > > > > > >> Hi John, > > > > > > > > > >> > > > > > > > > > >> we need something like > > > > > hw/i386/xen/xen_platform.c:unplug_disks > > > > > > > but > > > > > > > > > that > > > > > > > > > >> can unplug AHCI disk. And by unplug, I mean "make > disappear" > > > like > > > > > > > > > >> pci_piix3_xen_ide_unplug does for ide. > > > > > > > > > > Maybe this would be the right time to stop the craziness > with > > > your > > > > > > > > > > hybrid IDE/xendisk setup. It's a horrible thing that would > never > > > > > happen > > > > > > > > > > on real hardware. > > > > > > > > > > > > > > > > Unfortunately, it's going to be difficult to remove such 'craziness' > > > when > > > > > you > > > > > > > don't know a priori whether the VM has PV drivers or not. > > > > > > > > > > > > > > Why wouldn't you know that beforehand? I mean, even on real > > > > > hardware > > > > > > > you > > > > > > > can have different disk interfaces (IDE, AHCI, SCSI) and you install > > > > > > > the exact driver that your hardware needs. You just do the same > > > thing on > > > > > > > VM: If your hardware is PV, you install a PV driver. If your > hardware is > > > > > > > IDE, you install an IDE driver. Whether it's PV or IDE is something > that > > > > > > > you, the user, decided when configuring the VM, so you definitely > > > know. > > > > > > > > > > > > > > > > > > > That's not necessarily true. The host admin that provisions the VM > does > > > not > > > > > necessarily know what OS the user of that VM will install. The admin > may > > > just > > > > > be providing a generic VM with an emulated CD drive that the user > can > > > point > > > > > at any ISO they want. > > > > > > > > > > > > So, as a host admin, if you provide a VM with only PV backends and > > > your > > > > > user is trying to boot an OS with no PV drivers they are not going to be > > > > > happy, so you provide emulated devices. Then, at some point later, > when > > > > > the user installs PV drivers, there really should be some way for those > > > drivers > > > > > to start up without any need to contact the host admin and have the > VM > > > > > reconfigured. > > > > > > > > > > Why only IDE and xendisk then? Maybe I have an OS that works great > > > with > > > > > AHCI, or virtio-blk, or an LSI SCSI controller, or a Megasas SCSI > > > > > controller, or USB sticks, or... (and IDE will hardly ever be the > > > > > optimal one) > > > > > > > > > > What about network cards? My OS might support the Xen PV one, or > it > > > > > might support rtl8139, or e1000, or virtio-net, or pcnet, or... > > > > > > > > > > Should we always put all of the hardware that can possibly be > emulated > > > > > in a VM just so that the one right device is definitely included even > > > > > though we don't know what OS will be running? > > > > > > > > > > This is ridiculous. > > > > > > > > It might be, but to some extent it's reality. The reason that the > > > > default emulated network device chosen by xl is rtl8193 is that it has > > > > drivers in just about every OS. The same reason for IDE being the > > > > default choice for storage. > > > > > > So what does this mean for a justification for the AHCI + xendisk hybrid > > > proposal? > > > > > > > > Just tell your admin what virtual hardware you really need. (Or tell > > > > > them to give you a proper interface to configure your VMs yourself.) > > > > > > > > > > > > > My point is that the virtual hardware that the OS user wants will > > > > change. Before they install PV drivers, they will need emulated > > > > device. After installing PV drivers they will want PV devices. Should > > > > they really have to contact their cloud provider to make the switch, > > > > when at the moment it happens automatically and transparently (the > > > > AHCI problem aside)? > > > > > > My point is that such a magic change shouldn't happen. It doesn't happen > > > on real hardware either and people still get things installed to non-IDE > > > disks. > > > > > > There is no reason to install the OS onto a different device than will > > > be used later. With Linux, it's no problem at all because the PV drivers > > > are already included on the installation media anyway, and on Windows > or > > > presumably any other OS you can load and install the drivers right from > > > the beginning. > > > > > > In fact, I would be surprised if using xendisk instead of IDE for > > > installing Windows didn't result in a noticably faster installation. > > > > > > > It most certainly would, but requiring users do it this way is likely to meet > some resistance I suspect. > > Why do you think so? Installing the PV drivers afterwards doesn't seem > easier than just providing them during the installation. > My experience of XenServer customers tells me that any form of manual intervention during guest install is likely to meet with resistance, unfortunately. > > > Now, if you really insist on providing a legacy interface even to guests > > > that eventually use PV drivers, there actually are sane ways to > > > implement this. It will be tricky to make that transition now without > > > breaking compatibility, but it could have been done from the start. > > > > > > Sane means for example that you don't open the same image twice (and > > > even read-write!) at the same time. This is a recipe for disaster and > > > it's surprising that you don't see corrupted images more often. > > > > > > > We don't because unplug is supposed to ensure the emulated device is > > gone before the PV frontend is started > > The important part is the backend, but it seems that you open the second > instance of the image only when starting the PV frontend? I believe this is the case, yes. > > As long as you don't enable the user to use most of qemu's functionality > like starting block jobs (which would keep the IDE instance around even > after unplugging the disk), it might actually be safe assuming that the > guest cooperates. Not sure what a malicious guest could do, though, as > nobody seems to check whether IDE is really unplugged before the second > instance is opened. The Windows drivers do check. After the unplug Windows is asked to re-enumerate the IDE buses and we make sure the disks we expect to be gone are really gone. > raw and qcow2 should be safe these days, but in > earlier times it would probably have been possible for the guest to > overwrite the image header and access arbitrary files on the host as > backing file. It might still be true for other image formats. > > > > So if you wanted to have a clean solution, try to think how real > > > hardware would solve the problem. If you want me to suggest something > > > off the top of my head, I would come up with an extended IDE device > (one > > > single device!) that provides the IDE I/O ports and additionally some > > > MMIO BAR that enables access to PV functionality. > > > > > > Once you enable PV functionality, the IDE ports stop working; device > > > reset disables the PV ring and goes back to IDE mode. No hard disk > > > suddenly disappearing from the machine, no image corruption if the IDE > > > device is written to before enabling PV, etc. > > > > > > > That's not sufficient though. The IDE device must not be enumerated by > > the OS and, in Windows at least, that enumeration occurs before the PV > > frontend has started up. > > The trick is that it's only a single device, so there is no second > device that must be prevented from being enumerated. You provide a > driver for this specific IDE controller, so Windows wouldn't even try > the generic IDE driver when your driver is available. > But the whole point is that we want Windows to use the generic IDE driver. If we had a driver in Windows from the outset then it would be pure PV and there'd be no problem :-) Paul > It's kind of the same sort of IDE controller extension as Bus Master > DMA, which just added a new BAR. If you had an old driver, it would just > ignore the new registers. If you had a new one, it would use them. But > in no way would the old appearance of the device simply disappear, you > just use an extended register set on the same device. > > > > But it's your choice. You can keep your broken hack in IDE. Just don't > > > expect anyone to support adding new broken hacks to other devices. > > > > > > > I'd prefer to have a cleaner solution and I believe can achieve that in > Windows by obscuring the emulated disks using filter drivers, so that's the > way I'll probably go. > > I wouldn't consider anything that works with two distinct disk devices > and two separate BlockDriverStates for the same image file a clean > solution. > > Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 16:53 ` Paul Durrant @ 2015-10-16 17:03 ` Kevin Wolf 2015-10-16 17:03 ` Kevin Wolf ` (2 subsequent siblings) 3 siblings, 0 replies; 95+ messages in thread From: Kevin Wolf @ 2015-10-16 17:03 UTC (permalink / raw) To: Paul Durrant Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Stefano Stabellini, Anthony Perard, John Snow Am 16.10.2015 um 18:53 hat Paul Durrant geschrieben: > > > > > > Just tell your admin what virtual hardware you really need. (Or tell > > > > > > them to give you a proper interface to configure your VMs yourself.) > > > > > > > > > > > > > > > > My point is that the virtual hardware that the OS user wants will > > > > > change. Before they install PV drivers, they will need emulated > > > > > device. After installing PV drivers they will want PV devices. Should > > > > > they really have to contact their cloud provider to make the switch, > > > > > when at the moment it happens automatically and transparently (the > > > > > AHCI problem aside)? > > > > > > > > My point is that such a magic change shouldn't happen. It doesn't happen > > > > on real hardware either and people still get things installed to non-IDE > > > > disks. > > > > > > > > There is no reason to install the OS onto a different device than will > > > > be used later. With Linux, it's no problem at all because the PV drivers > > > > are already included on the installation media anyway, and on Windows > > or > > > > presumably any other OS you can load and install the drivers right from > > > > the beginning. > > > > > > > > In fact, I would be surprised if using xendisk instead of IDE for > > > > installing Windows didn't result in a noticably faster installation. > > > > > > > > > > It most certainly would, but requiring users do it this way is likely to meet > > some resistance I suspect. > > > > Why do you think so? Installing the PV drivers afterwards doesn't seem > > easier than just providing them during the installation. > > > > My experience of XenServer customers tells me that any form of manual > intervention during guest install is likely to meet with resistance, > unfortunately. Do they consider the guest install complete before they manually intervene for installing the PV drivers? I'm no Windows expert, but I'm sure there is a way to automate installation even when a driver disk is needed. > > > > Now, if you really insist on providing a legacy interface even to guests > > > > that eventually use PV drivers, there actually are sane ways to > > > > implement this. It will be tricky to make that transition now without > > > > breaking compatibility, but it could have been done from the start. > > > > > > > > Sane means for example that you don't open the same image twice (and > > > > even read-write!) at the same time. This is a recipe for disaster and > > > > it's surprising that you don't see corrupted images more often. > > > > > > > > > > We don't because unplug is supposed to ensure the emulated device is > > > gone before the PV frontend is started > > > > The important part is the backend, but it seems that you open the second > > instance of the image only when starting the PV frontend? > > I believe this is the case, yes. > > > > > As long as you don't enable the user to use most of qemu's functionality > > like starting block jobs (which would keep the IDE instance around even > > after unplugging the disk), it might actually be safe assuming that the > > guest cooperates. Not sure what a malicious guest could do, though, as > > nobody seems to check whether IDE is really unplugged before the second > > instance is opened. > > The Windows drivers do check. After the unplug Windows is asked to > re-enumerate the IDE buses and we make sure the disks we expect to be > gone are really gone. You can't use guest code to protect against malicious guests. > > raw and qcow2 should be safe these days, but in > > earlier times it would probably have been possible for the guest to > > overwrite the image header and access arbitrary files on the host as > > backing file. It might still be true for other image formats. > > > > > > So if you wanted to have a clean solution, try to think how real > > > > hardware would solve the problem. If you want me to suggest something > > > > off the top of my head, I would come up with an extended IDE device > > (one > > > > single device!) that provides the IDE I/O ports and additionally some > > > > MMIO BAR that enables access to PV functionality. > > > > > > > > Once you enable PV functionality, the IDE ports stop working; device > > > > reset disables the PV ring and goes back to IDE mode. No hard disk > > > > suddenly disappearing from the machine, no image corruption if the IDE > > > > device is written to before enabling PV, etc. > > > > > > > > > > That's not sufficient though. The IDE device must not be enumerated by > > > the OS and, in Windows at least, that enumeration occurs before the PV > > > frontend has started up. > > > > The trick is that it's only a single device, so there is no second > > device that must be prevented from being enumerated. You provide a > > driver for this specific IDE controller, so Windows wouldn't even try > > the generic IDE driver when your driver is available. > > > > But the whole point is that we want Windows to use the generic IDE > driver. If we had a driver in Windows from the outset then it would be > pure PV and there'd be no problem :-) And it would do that when your driver isn't available. This fallback is the difference from a pure PV device. But as soon as your driver is available, it will be preferred and the generic IDE driver won't be used any more. Kevin > > It's kind of the same sort of IDE controller extension as Bus Master > > DMA, which just added a new BAR. If you had an old driver, it would just > > ignore the new registers. If you had a new one, it would use them. But > > in no way would the old appearance of the device simply disappear, you > > just use an extended register set on the same device. > > > > > > But it's your choice. You can keep your broken hack in IDE. Just don't > > > > expect anyone to support adding new broken hacks to other devices. > > > > > > > > > > I'd prefer to have a cleaner solution and I believe can achieve that in > > Windows by obscuring the emulated disks using filter drivers, so that's the > > way I'll probably go. > > > > I wouldn't consider anything that works with two distinct disk devices > > and two separate BlockDriverStates for the same image file a clean > > solution. > > > > Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 16:53 ` Paul Durrant 2015-10-16 17:03 ` Kevin Wolf @ 2015-10-16 17:03 ` Kevin Wolf 2015-10-19 13:42 ` Fabio Fantoni 2015-10-19 13:42 ` Fabio Fantoni 3 siblings, 0 replies; 95+ messages in thread From: Kevin Wolf @ 2015-10-16 17:03 UTC (permalink / raw) To: Paul Durrant Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Stefano Stabellini, Anthony Perard, John Snow Am 16.10.2015 um 18:53 hat Paul Durrant geschrieben: > > > > > > Just tell your admin what virtual hardware you really need. (Or tell > > > > > > them to give you a proper interface to configure your VMs yourself.) > > > > > > > > > > > > > > > > My point is that the virtual hardware that the OS user wants will > > > > > change. Before they install PV drivers, they will need emulated > > > > > device. After installing PV drivers they will want PV devices. Should > > > > > they really have to contact their cloud provider to make the switch, > > > > > when at the moment it happens automatically and transparently (the > > > > > AHCI problem aside)? > > > > > > > > My point is that such a magic change shouldn't happen. It doesn't happen > > > > on real hardware either and people still get things installed to non-IDE > > > > disks. > > > > > > > > There is no reason to install the OS onto a different device than will > > > > be used later. With Linux, it's no problem at all because the PV drivers > > > > are already included on the installation media anyway, and on Windows > > or > > > > presumably any other OS you can load and install the drivers right from > > > > the beginning. > > > > > > > > In fact, I would be surprised if using xendisk instead of IDE for > > > > installing Windows didn't result in a noticably faster installation. > > > > > > > > > > It most certainly would, but requiring users do it this way is likely to meet > > some resistance I suspect. > > > > Why do you think so? Installing the PV drivers afterwards doesn't seem > > easier than just providing them during the installation. > > > > My experience of XenServer customers tells me that any form of manual > intervention during guest install is likely to meet with resistance, > unfortunately. Do they consider the guest install complete before they manually intervene for installing the PV drivers? I'm no Windows expert, but I'm sure there is a way to automate installation even when a driver disk is needed. > > > > Now, if you really insist on providing a legacy interface even to guests > > > > that eventually use PV drivers, there actually are sane ways to > > > > implement this. It will be tricky to make that transition now without > > > > breaking compatibility, but it could have been done from the start. > > > > > > > > Sane means for example that you don't open the same image twice (and > > > > even read-write!) at the same time. This is a recipe for disaster and > > > > it's surprising that you don't see corrupted images more often. > > > > > > > > > > We don't because unplug is supposed to ensure the emulated device is > > > gone before the PV frontend is started > > > > The important part is the backend, but it seems that you open the second > > instance of the image only when starting the PV frontend? > > I believe this is the case, yes. > > > > > As long as you don't enable the user to use most of qemu's functionality > > like starting block jobs (which would keep the IDE instance around even > > after unplugging the disk), it might actually be safe assuming that the > > guest cooperates. Not sure what a malicious guest could do, though, as > > nobody seems to check whether IDE is really unplugged before the second > > instance is opened. > > The Windows drivers do check. After the unplug Windows is asked to > re-enumerate the IDE buses and we make sure the disks we expect to be > gone are really gone. You can't use guest code to protect against malicious guests. > > raw and qcow2 should be safe these days, but in > > earlier times it would probably have been possible for the guest to > > overwrite the image header and access arbitrary files on the host as > > backing file. It might still be true for other image formats. > > > > > > So if you wanted to have a clean solution, try to think how real > > > > hardware would solve the problem. If you want me to suggest something > > > > off the top of my head, I would come up with an extended IDE device > > (one > > > > single device!) that provides the IDE I/O ports and additionally some > > > > MMIO BAR that enables access to PV functionality. > > > > > > > > Once you enable PV functionality, the IDE ports stop working; device > > > > reset disables the PV ring and goes back to IDE mode. No hard disk > > > > suddenly disappearing from the machine, no image corruption if the IDE > > > > device is written to before enabling PV, etc. > > > > > > > > > > That's not sufficient though. The IDE device must not be enumerated by > > > the OS and, in Windows at least, that enumeration occurs before the PV > > > frontend has started up. > > > > The trick is that it's only a single device, so there is no second > > device that must be prevented from being enumerated. You provide a > > driver for this specific IDE controller, so Windows wouldn't even try > > the generic IDE driver when your driver is available. > > > > But the whole point is that we want Windows to use the generic IDE > driver. If we had a driver in Windows from the outset then it would be > pure PV and there'd be no problem :-) And it would do that when your driver isn't available. This fallback is the difference from a pure PV device. But as soon as your driver is available, it will be preferred and the generic IDE driver won't be used any more. Kevin > > It's kind of the same sort of IDE controller extension as Bus Master > > DMA, which just added a new BAR. If you had an old driver, it would just > > ignore the new registers. If you had a new one, it would use them. But > > in no way would the old appearance of the device simply disappear, you > > just use an extended register set on the same device. > > > > > > But it's your choice. You can keep your broken hack in IDE. Just don't > > > > expect anyone to support adding new broken hacks to other devices. > > > > > > > > > > I'd prefer to have a cleaner solution and I believe can achieve that in > > Windows by obscuring the emulated disks using filter drivers, so that's the > > way I'll probably go. > > > > I wouldn't consider anything that works with two distinct disk devices > > and two separate BlockDriverStates for the same image file a clean > > solution. > > > > Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 16:53 ` Paul Durrant 2015-10-16 17:03 ` Kevin Wolf 2015-10-16 17:03 ` Kevin Wolf @ 2015-10-19 13:42 ` Fabio Fantoni 2015-10-19 13:42 ` Fabio Fantoni 3 siblings, 0 replies; 95+ messages in thread From: Fabio Fantoni @ 2015-10-19 13:42 UTC (permalink / raw) To: Paul Durrant, Kevin Wolf Cc: qemu-block, qemu-devel, xen-devel, Stefano Stabellini, Anthony Perard, John Snow Il 16/10/2015 18:53, Paul Durrant ha scritto: >> -----Original Message----- >> From: Kevin Wolf [mailto:kwolf@redhat.com] >> Sent: 16 October 2015 17:43 >> To: Paul Durrant >> Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- >> devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org >> Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci >> missed in qemu >> >> Am 16.10.2015 um 18:20 hat Paul Durrant geschrieben: >>>> -----Original Message----- >>>> From: Kevin Wolf [mailto:kwolf@redhat.com] >>>> Sent: 16 October 2015 17:12 >>>> To: Paul Durrant >>>> Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- >>>> devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org >>>> Subject: Re: [Qemu-devel] Question about xen disk unplug support for >> ahci >>>> missed in qemu >>>> >>>> Am 16.10.2015 um 17:10 hat Paul Durrant geschrieben: >>>>>> -----Original Message----- >>>>>> From: Kevin Wolf [mailto:kwolf@redhat.com] >>>>>> Sent: 16 October 2015 16:02 >>>>>> To: Paul Durrant >>>>>> Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; >> qemu- >>>>>> devel@nongnu.org; xen-devel@lists.xen.org; qemu- >> block@nongnu.org >>>>>> Subject: Re: [Qemu-devel] Question about xen disk unplug support >> for >>>> ahci >>>>>> missed in qemu >>>>>> >>>>>> Am 16.10.2015 um 16:24 hat Paul Durrant geschrieben: >>>>>>>> -----Original Message----- >>>>>>>> From: Kevin Wolf [mailto:kwolf@redhat.com] >>>>>>>> Sent: 16 October 2015 15:04 >>>>>>>> To: Paul Durrant >>>>>>>> Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; >>>> qemu- >>>>>>>> devel@nongnu.org; xen-devel@lists.xen.org; qemu- >>>> block@nongnu.org >>>>>>>> Subject: Re: [Qemu-devel] Question about xen disk unplug >> support >>>> for >>>>>> ahci >>>>>>>> missed in qemu >>>>>>>> >>>>>>>> Am 14.10.2015 um 14:48 hat Paul Durrant geschrieben: >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] >>>>>>>>>> Sent: 14 October 2015 12:12 >>>>>>>>>> To: Kevin Wolf; Stefano Stabellini >>>>>>>>>> Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; >> xen- >>>>>>>>>> devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant >>>>>>>>>> Subject: Re: [Qemu-devel] Question about xen disk unplug >>>> support >>>>>> for >>>>>>>> ahci >>>>>>>>>> missed in qemu >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Il 14/10/2015 11:47, Kevin Wolf ha scritto: >>>>>>>>>>> [ CC qemu-block ] >>>>>>>>>>> >>>>>>>>>>> Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: >>>>>>>>>>>> On Tue, 13 Oct 2015, John Snow wrote: >>>>>>>>>>>>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: >>>>>>>>>>>>>> I added ahci disk support in libxl and using it for week >> seems >>>>>> that >>>>>>>> was >>>>>>>>>>>>>> ok, after a reply of Stefano Stabellini seems that xen disk >>>> unplug >>>>>>>>>>>>>> support only ide disks: >>>>>>>>>>>>>> >> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 >>>>>>>>>> c905374ee8663d5d8 >>>>>>>>>>>>>> Today Paul Durrant told me that even if pv disk is ok also >>>> with >>>>>> ahci >>>>>>>> and >>>>>>>>>>>>>> the emulated one is offline can be a risk: >>>>>>>>>>>>>> http://lists.xenproject.org/archives/html/win-pv- >>>> devel/2015- >>>>>>>>>> 10/msg00021.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> I tried to take a fast look in qemu code but I not >> understand >>>> the >>>>>>>>>> needed >>>>>>>>>>>>>> thing for add the xen disk unplug support also for ahci, >> can >>>>>>>> someone do >>>>>>>>>>>>>> it or tell me useful information for do it please? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for any reply and sorry for my bad english. >>>>>>>>>>>>>> >>>>>>>>>>>>> I'm not entirely sure what features you need AHCI to >> support >>>> in >>>>>>>> order >>>>>>>>>>>>> for Xen to be happy. >>>>>>>>>>>>> >>>>>>>>>>>>> I'd guess hotplugging, but where I get confused is that IDE >>>> disks >>>>>> don't >>>>>>>>>>>>> support hotplugging either, so I guess I'm not sure sure >> what >>>> you >>>>>>>> need. >>>>>>>>>>>>> Stefano, can you help bridge my Xen knowledge gap? >>>>>>>>>>>> Hi John, >>>>>>>>>>>> >>>>>>>>>>>> we need something like >>>>>> hw/i386/xen/xen_platform.c:unplug_disks >>>>>>>> but >>>>>>>>>> that >>>>>>>>>>>> can unplug AHCI disk. And by unplug, I mean "make >> disappear" >>>> like >>>>>>>>>>>> pci_piix3_xen_ide_unplug does for ide. >>>>>>>>>>> Maybe this would be the right time to stop the craziness >> with >>>> your >>>>>>>>>>> hybrid IDE/xendisk setup. It's a horrible thing that would >> never >>>>>> happen >>>>>>>>>>> on real hardware. >>>>>>>>> Unfortunately, it's going to be difficult to remove such 'craziness' >>>> when >>>>>> you >>>>>>>> don't know a priori whether the VM has PV drivers or not. >>>>>>>> >>>>>>>> Why wouldn't you know that beforehand? I mean, even on real >>>>>> hardware >>>>>>>> you >>>>>>>> can have different disk interfaces (IDE, AHCI, SCSI) and you install >>>>>>>> the exact driver that your hardware needs. You just do the same >>>> thing on >>>>>>>> VM: If your hardware is PV, you install a PV driver. If your >> hardware is >>>>>>>> IDE, you install an IDE driver. Whether it's PV or IDE is something >> that >>>>>>>> you, the user, decided when configuring the VM, so you definitely >>>> know. >>>>>>> That's not necessarily true. The host admin that provisions the VM >> does >>>> not >>>>>> necessarily know what OS the user of that VM will install. The admin >> may >>>> just >>>>>> be providing a generic VM with an emulated CD drive that the user >> can >>>> point >>>>>> at any ISO they want. >>>>>>> So, as a host admin, if you provide a VM with only PV backends and >>>> your >>>>>> user is trying to boot an OS with no PV drivers they are not going to be >>>>>> happy, so you provide emulated devices. Then, at some point later, >> when >>>>>> the user installs PV drivers, there really should be some way for those >>>> drivers >>>>>> to start up without any need to contact the host admin and have the >> VM >>>>>> reconfigured. >>>>>> >>>>>> Why only IDE and xendisk then? Maybe I have an OS that works great >>>> with >>>>>> AHCI, or virtio-blk, or an LSI SCSI controller, or a Megasas SCSI >>>>>> controller, or USB sticks, or... (and IDE will hardly ever be the >>>>>> optimal one) >>>>>> >>>>>> What about network cards? My OS might support the Xen PV one, or >> it >>>>>> might support rtl8139, or e1000, or virtio-net, or pcnet, or... >>>>>> >>>>>> Should we always put all of the hardware that can possibly be >> emulated >>>>>> in a VM just so that the one right device is definitely included even >>>>>> though we don't know what OS will be running? >>>>>> >>>>>> This is ridiculous. >>>>> It might be, but to some extent it's reality. The reason that the >>>>> default emulated network device chosen by xl is rtl8193 is that it has >>>>> drivers in just about every OS. The same reason for IDE being the >>>>> default choice for storage. >>>> So what does this mean for a justification for the AHCI + xendisk hybrid >>>> proposal? >>>> >>>>>> Just tell your admin what virtual hardware you really need. (Or tell >>>>>> them to give you a proper interface to configure your VMs yourself.) >>>>>> >>>>> My point is that the virtual hardware that the OS user wants will >>>>> change. Before they install PV drivers, they will need emulated >>>>> device. After installing PV drivers they will want PV devices. Should >>>>> they really have to contact their cloud provider to make the switch, >>>>> when at the moment it happens automatically and transparently (the >>>>> AHCI problem aside)? >>>> My point is that such a magic change shouldn't happen. It doesn't happen >>>> on real hardware either and people still get things installed to non-IDE >>>> disks. >>>> >>>> There is no reason to install the OS onto a different device than will >>>> be used later. With Linux, it's no problem at all because the PV drivers >>>> are already included on the installation media anyway, and on Windows >> or >>>> presumably any other OS you can load and install the drivers right from >>>> the beginning. >>>> >>>> In fact, I would be surprised if using xendisk instead of IDE for >>>> installing Windows didn't result in a noticably faster installation. >>>> >>> It most certainly would, but requiring users do it this way is likely to meet >> some resistance I suspect. >> >> Why do you think so? Installing the PV drivers afterwards doesn't seem >> easier than just providing them during the installation. >> > My experience of XenServer customers tells me that any form of manual intervention during guest install is likely to meet with resistance, unfortunately. > >>>> Now, if you really insist on providing a legacy interface even to guests >>>> that eventually use PV drivers, there actually are sane ways to >>>> implement this. It will be tricky to make that transition now without >>>> breaking compatibility, but it could have been done from the start. >>>> >>>> Sane means for example that you don't open the same image twice (and >>>> even read-write!) at the same time. This is a recipe for disaster and >>>> it's surprising that you don't see corrupted images more often. >>>> >>> We don't because unplug is supposed to ensure the emulated device is >>> gone before the PV frontend is started >> The important part is the backend, but it seems that you open the second >> instance of the image only when starting the PV frontend? > I believe this is the case, yes. > >> As long as you don't enable the user to use most of qemu's functionality >> like starting block jobs (which would keep the IDE instance around even >> after unplugging the disk), it might actually be safe assuming that the >> guest cooperates. Not sure what a malicious guest could do, though, as >> nobody seems to check whether IDE is really unplugged before the second >> instance is opened. > The Windows drivers do check. After the unplug Windows is asked to re-enumerate the IDE buses and we make sure the disks we expect to be gone are really gone. > >> raw and qcow2 should be safe these days, but in >> earlier times it would probably have been possible for the guest to >> overwrite the image header and access arbitrary files on the host as >> backing file. It might still be true for other image formats. >> >>>> So if you wanted to have a clean solution, try to think how real >>>> hardware would solve the problem. If you want me to suggest something >>>> off the top of my head, I would come up with an extended IDE device >> (one >>>> single device!) that provides the IDE I/O ports and additionally some >>>> MMIO BAR that enables access to PV functionality. >>>> >>>> Once you enable PV functionality, the IDE ports stop working; device >>>> reset disables the PV ring and goes back to IDE mode. No hard disk >>>> suddenly disappearing from the machine, no image corruption if the IDE >>>> device is written to before enabling PV, etc. >>>> >>> That's not sufficient though. The IDE device must not be enumerated by >>> the OS and, in Windows at least, that enumeration occurs before the PV >>> frontend has started up. >> The trick is that it's only a single device, so there is no second >> device that must be prevented from being enumerated. You provide a >> driver for this specific IDE controller, so Windows wouldn't even try >> the generic IDE driver when your driver is available. >> > But the whole point is that we want Windows to use the generic IDE driver. If we had a driver in Windows from the outset then it would be pure PV and there'd be no problem :-) > > Paul I understand the goals of the actual 'hybrid' xen pv for disks and net, made in order to have older emulated hardware (compatible with the most of the common outofthebox systems) and the advantage to switch to pv without change domU's settings. It would a great thing if it is working without problems in most of cases, but unfortunately it is not. For the linux hvm domUs i haven't found any problems with that, apart from the boot speed (which can be solved using ahci), while with windows domUs (which are the major of my guest domUs), the problems are always there... In specific the problems i have are almost always with installation/update/remove of the pv drivers. Unsing gplPVs, taking grate care in removing e install new versions, i've found an acceptable way to get the task done. With the new winPV drivers, the problems arises. Some of these problems were fixed by Durrant, while others seem to be persistent and it is very difficult if not impossible to gain logs to report back. Despite all of my reports, it seems there aren't any possible solutions to these kind of problems. The problems i've mentioned are almost about disks, where i'm unable to boot windows domUs, due to blue screens etc., but i've had also problems on the network side (ie. pv network still there but not functioning and emulated network functioning intead). These kind of problems are becoming very frequantly on windows 10 guests and even more with unsigned pv drivers. For these and other reasons, i think the actual 'hybrid' solution it is not a very good solution. I suppose that on xenserver, these kind of problems come fixed by specific operations made by the installer, isnt'it? I'm wondering if the problems i've described are only 'mine' or if there are methods or solutions out there that i've not be able to find form myself... For example as reported in a old win-pv-devel mail some months ago when I thinked to found a valid solution to install/upgrade problems what after I saw that wasn't: http://fantu.info/xen/Notes_new_xen_winpv_drivers.7z On the other hand i've gave a try to kvm with virtio and found that even if i must to install dedicated drivers for install the system or boot it, i've never found problems in installing/updating the drivers and/or booting the guests or problems on network adapters and so on... Thanks for any reply and sorry for my bad english. > >> It's kind of the same sort of IDE controller extension as Bus Master >> DMA, which just added a new BAR. If you had an old driver, it would just >> ignore the new registers. If you had a new one, it would use them. But >> in no way would the old appearance of the device simply disappear, you >> just use an extended register set on the same device. >> >>>> But it's your choice. You can keep your broken hack in IDE. Just don't >>>> expect anyone to support adding new broken hacks to other devices. >>>> >>> I'd prefer to have a cleaner solution and I believe can achieve that in >> Windows by obscuring the emulated disks using filter drivers, so that's the >> way I'll probably go. >> >> I wouldn't consider anything that works with two distinct disk devices >> and two separate BlockDriverStates for the same image file a clean >> solution. >> >> Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 16:53 ` Paul Durrant ` (2 preceding siblings ...) 2015-10-19 13:42 ` Fabio Fantoni @ 2015-10-19 13:42 ` Fabio Fantoni 3 siblings, 0 replies; 95+ messages in thread From: Fabio Fantoni @ 2015-10-19 13:42 UTC (permalink / raw) To: Paul Durrant, Kevin Wolf Cc: qemu-block, qemu-devel, xen-devel, Stefano Stabellini, Anthony Perard, John Snow Il 16/10/2015 18:53, Paul Durrant ha scritto: >> -----Original Message----- >> From: Kevin Wolf [mailto:kwolf@redhat.com] >> Sent: 16 October 2015 17:43 >> To: Paul Durrant >> Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- >> devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org >> Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci >> missed in qemu >> >> Am 16.10.2015 um 18:20 hat Paul Durrant geschrieben: >>>> -----Original Message----- >>>> From: Kevin Wolf [mailto:kwolf@redhat.com] >>>> Sent: 16 October 2015 17:12 >>>> To: Paul Durrant >>>> Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- >>>> devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org >>>> Subject: Re: [Qemu-devel] Question about xen disk unplug support for >> ahci >>>> missed in qemu >>>> >>>> Am 16.10.2015 um 17:10 hat Paul Durrant geschrieben: >>>>>> -----Original Message----- >>>>>> From: Kevin Wolf [mailto:kwolf@redhat.com] >>>>>> Sent: 16 October 2015 16:02 >>>>>> To: Paul Durrant >>>>>> Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; >> qemu- >>>>>> devel@nongnu.org; xen-devel@lists.xen.org; qemu- >> block@nongnu.org >>>>>> Subject: Re: [Qemu-devel] Question about xen disk unplug support >> for >>>> ahci >>>>>> missed in qemu >>>>>> >>>>>> Am 16.10.2015 um 16:24 hat Paul Durrant geschrieben: >>>>>>>> -----Original Message----- >>>>>>>> From: Kevin Wolf [mailto:kwolf@redhat.com] >>>>>>>> Sent: 16 October 2015 15:04 >>>>>>>> To: Paul Durrant >>>>>>>> Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; >>>> qemu- >>>>>>>> devel@nongnu.org; xen-devel@lists.xen.org; qemu- >>>> block@nongnu.org >>>>>>>> Subject: Re: [Qemu-devel] Question about xen disk unplug >> support >>>> for >>>>>> ahci >>>>>>>> missed in qemu >>>>>>>> >>>>>>>> Am 14.10.2015 um 14:48 hat Paul Durrant geschrieben: >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] >>>>>>>>>> Sent: 14 October 2015 12:12 >>>>>>>>>> To: Kevin Wolf; Stefano Stabellini >>>>>>>>>> Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; >> xen- >>>>>>>>>> devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant >>>>>>>>>> Subject: Re: [Qemu-devel] Question about xen disk unplug >>>> support >>>>>> for >>>>>>>> ahci >>>>>>>>>> missed in qemu >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Il 14/10/2015 11:47, Kevin Wolf ha scritto: >>>>>>>>>>> [ CC qemu-block ] >>>>>>>>>>> >>>>>>>>>>> Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: >>>>>>>>>>>> On Tue, 13 Oct 2015, John Snow wrote: >>>>>>>>>>>>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: >>>>>>>>>>>>>> I added ahci disk support in libxl and using it for week >> seems >>>>>> that >>>>>>>> was >>>>>>>>>>>>>> ok, after a reply of Stefano Stabellini seems that xen disk >>>> unplug >>>>>>>>>>>>>> support only ide disks: >>>>>>>>>>>>>> >> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 >>>>>>>>>> c905374ee8663d5d8 >>>>>>>>>>>>>> Today Paul Durrant told me that even if pv disk is ok also >>>> with >>>>>> ahci >>>>>>>> and >>>>>>>>>>>>>> the emulated one is offline can be a risk: >>>>>>>>>>>>>> http://lists.xenproject.org/archives/html/win-pv- >>>> devel/2015- >>>>>>>>>> 10/msg00021.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> I tried to take a fast look in qemu code but I not >> understand >>>> the >>>>>>>>>> needed >>>>>>>>>>>>>> thing for add the xen disk unplug support also for ahci, >> can >>>>>>>> someone do >>>>>>>>>>>>>> it or tell me useful information for do it please? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for any reply and sorry for my bad english. >>>>>>>>>>>>>> >>>>>>>>>>>>> I'm not entirely sure what features you need AHCI to >> support >>>> in >>>>>>>> order >>>>>>>>>>>>> for Xen to be happy. >>>>>>>>>>>>> >>>>>>>>>>>>> I'd guess hotplugging, but where I get confused is that IDE >>>> disks >>>>>> don't >>>>>>>>>>>>> support hotplugging either, so I guess I'm not sure sure >> what >>>> you >>>>>>>> need. >>>>>>>>>>>>> Stefano, can you help bridge my Xen knowledge gap? >>>>>>>>>>>> Hi John, >>>>>>>>>>>> >>>>>>>>>>>> we need something like >>>>>> hw/i386/xen/xen_platform.c:unplug_disks >>>>>>>> but >>>>>>>>>> that >>>>>>>>>>>> can unplug AHCI disk. And by unplug, I mean "make >> disappear" >>>> like >>>>>>>>>>>> pci_piix3_xen_ide_unplug does for ide. >>>>>>>>>>> Maybe this would be the right time to stop the craziness >> with >>>> your >>>>>>>>>>> hybrid IDE/xendisk setup. It's a horrible thing that would >> never >>>>>> happen >>>>>>>>>>> on real hardware. >>>>>>>>> Unfortunately, it's going to be difficult to remove such 'craziness' >>>> when >>>>>> you >>>>>>>> don't know a priori whether the VM has PV drivers or not. >>>>>>>> >>>>>>>> Why wouldn't you know that beforehand? I mean, even on real >>>>>> hardware >>>>>>>> you >>>>>>>> can have different disk interfaces (IDE, AHCI, SCSI) and you install >>>>>>>> the exact driver that your hardware needs. You just do the same >>>> thing on >>>>>>>> VM: If your hardware is PV, you install a PV driver. If your >> hardware is >>>>>>>> IDE, you install an IDE driver. Whether it's PV or IDE is something >> that >>>>>>>> you, the user, decided when configuring the VM, so you definitely >>>> know. >>>>>>> That's not necessarily true. The host admin that provisions the VM >> does >>>> not >>>>>> necessarily know what OS the user of that VM will install. The admin >> may >>>> just >>>>>> be providing a generic VM with an emulated CD drive that the user >> can >>>> point >>>>>> at any ISO they want. >>>>>>> So, as a host admin, if you provide a VM with only PV backends and >>>> your >>>>>> user is trying to boot an OS with no PV drivers they are not going to be >>>>>> happy, so you provide emulated devices. Then, at some point later, >> when >>>>>> the user installs PV drivers, there really should be some way for those >>>> drivers >>>>>> to start up without any need to contact the host admin and have the >> VM >>>>>> reconfigured. >>>>>> >>>>>> Why only IDE and xendisk then? Maybe I have an OS that works great >>>> with >>>>>> AHCI, or virtio-blk, or an LSI SCSI controller, or a Megasas SCSI >>>>>> controller, or USB sticks, or... (and IDE will hardly ever be the >>>>>> optimal one) >>>>>> >>>>>> What about network cards? My OS might support the Xen PV one, or >> it >>>>>> might support rtl8139, or e1000, or virtio-net, or pcnet, or... >>>>>> >>>>>> Should we always put all of the hardware that can possibly be >> emulated >>>>>> in a VM just so that the one right device is definitely included even >>>>>> though we don't know what OS will be running? >>>>>> >>>>>> This is ridiculous. >>>>> It might be, but to some extent it's reality. The reason that the >>>>> default emulated network device chosen by xl is rtl8193 is that it has >>>>> drivers in just about every OS. The same reason for IDE being the >>>>> default choice for storage. >>>> So what does this mean for a justification for the AHCI + xendisk hybrid >>>> proposal? >>>> >>>>>> Just tell your admin what virtual hardware you really need. (Or tell >>>>>> them to give you a proper interface to configure your VMs yourself.) >>>>>> >>>>> My point is that the virtual hardware that the OS user wants will >>>>> change. Before they install PV drivers, they will need emulated >>>>> device. After installing PV drivers they will want PV devices. Should >>>>> they really have to contact their cloud provider to make the switch, >>>>> when at the moment it happens automatically and transparently (the >>>>> AHCI problem aside)? >>>> My point is that such a magic change shouldn't happen. It doesn't happen >>>> on real hardware either and people still get things installed to non-IDE >>>> disks. >>>> >>>> There is no reason to install the OS onto a different device than will >>>> be used later. With Linux, it's no problem at all because the PV drivers >>>> are already included on the installation media anyway, and on Windows >> or >>>> presumably any other OS you can load and install the drivers right from >>>> the beginning. >>>> >>>> In fact, I would be surprised if using xendisk instead of IDE for >>>> installing Windows didn't result in a noticably faster installation. >>>> >>> It most certainly would, but requiring users do it this way is likely to meet >> some resistance I suspect. >> >> Why do you think so? Installing the PV drivers afterwards doesn't seem >> easier than just providing them during the installation. >> > My experience of XenServer customers tells me that any form of manual intervention during guest install is likely to meet with resistance, unfortunately. > >>>> Now, if you really insist on providing a legacy interface even to guests >>>> that eventually use PV drivers, there actually are sane ways to >>>> implement this. It will be tricky to make that transition now without >>>> breaking compatibility, but it could have been done from the start. >>>> >>>> Sane means for example that you don't open the same image twice (and >>>> even read-write!) at the same time. This is a recipe for disaster and >>>> it's surprising that you don't see corrupted images more often. >>>> >>> We don't because unplug is supposed to ensure the emulated device is >>> gone before the PV frontend is started >> The important part is the backend, but it seems that you open the second >> instance of the image only when starting the PV frontend? > I believe this is the case, yes. > >> As long as you don't enable the user to use most of qemu's functionality >> like starting block jobs (which would keep the IDE instance around even >> after unplugging the disk), it might actually be safe assuming that the >> guest cooperates. Not sure what a malicious guest could do, though, as >> nobody seems to check whether IDE is really unplugged before the second >> instance is opened. > The Windows drivers do check. After the unplug Windows is asked to re-enumerate the IDE buses and we make sure the disks we expect to be gone are really gone. > >> raw and qcow2 should be safe these days, but in >> earlier times it would probably have been possible for the guest to >> overwrite the image header and access arbitrary files on the host as >> backing file. It might still be true for other image formats. >> >>>> So if you wanted to have a clean solution, try to think how real >>>> hardware would solve the problem. If you want me to suggest something >>>> off the top of my head, I would come up with an extended IDE device >> (one >>>> single device!) that provides the IDE I/O ports and additionally some >>>> MMIO BAR that enables access to PV functionality. >>>> >>>> Once you enable PV functionality, the IDE ports stop working; device >>>> reset disables the PV ring and goes back to IDE mode. No hard disk >>>> suddenly disappearing from the machine, no image corruption if the IDE >>>> device is written to before enabling PV, etc. >>>> >>> That's not sufficient though. The IDE device must not be enumerated by >>> the OS and, in Windows at least, that enumeration occurs before the PV >>> frontend has started up. >> The trick is that it's only a single device, so there is no second >> device that must be prevented from being enumerated. You provide a >> driver for this specific IDE controller, so Windows wouldn't even try >> the generic IDE driver when your driver is available. >> > But the whole point is that we want Windows to use the generic IDE driver. If we had a driver in Windows from the outset then it would be pure PV and there'd be no problem :-) > > Paul I understand the goals of the actual 'hybrid' xen pv for disks and net, made in order to have older emulated hardware (compatible with the most of the common outofthebox systems) and the advantage to switch to pv without change domU's settings. It would a great thing if it is working without problems in most of cases, but unfortunately it is not. For the linux hvm domUs i haven't found any problems with that, apart from the boot speed (which can be solved using ahci), while with windows domUs (which are the major of my guest domUs), the problems are always there... In specific the problems i have are almost always with installation/update/remove of the pv drivers. Unsing gplPVs, taking grate care in removing e install new versions, i've found an acceptable way to get the task done. With the new winPV drivers, the problems arises. Some of these problems were fixed by Durrant, while others seem to be persistent and it is very difficult if not impossible to gain logs to report back. Despite all of my reports, it seems there aren't any possible solutions to these kind of problems. The problems i've mentioned are almost about disks, where i'm unable to boot windows domUs, due to blue screens etc., but i've had also problems on the network side (ie. pv network still there but not functioning and emulated network functioning intead). These kind of problems are becoming very frequantly on windows 10 guests and even more with unsigned pv drivers. For these and other reasons, i think the actual 'hybrid' solution it is not a very good solution. I suppose that on xenserver, these kind of problems come fixed by specific operations made by the installer, isnt'it? I'm wondering if the problems i've described are only 'mine' or if there are methods or solutions out there that i've not be able to find form myself... For example as reported in a old win-pv-devel mail some months ago when I thinked to found a valid solution to install/upgrade problems what after I saw that wasn't: http://fantu.info/xen/Notes_new_xen_winpv_drivers.7z On the other hand i've gave a try to kvm with virtio and found that even if i must to install dedicated drivers for install the system or boot it, i've never found problems in installing/updating the drivers and/or booting the guests or problems on network adapters and so on... Thanks for any reply and sorry for my bad english. > >> It's kind of the same sort of IDE controller extension as Bus Master >> DMA, which just added a new BAR. If you had an old driver, it would just >> ignore the new registers. If you had a new one, it would use them. But >> in no way would the old appearance of the device simply disappear, you >> just use an extended register set on the same device. >> >>>> But it's your choice. You can keep your broken hack in IDE. Just don't >>>> expect anyone to support adding new broken hacks to other devices. >>>> >>> I'd prefer to have a cleaner solution and I believe can achieve that in >> Windows by obscuring the emulated disks using filter drivers, so that's the >> way I'll probably go. >> >> I wouldn't consider anything that works with two distinct disk devices >> and two separate BlockDriverStates for the same image file a clean >> solution. >> >> Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 16:42 ` Kevin Wolf 2015-10-16 16:53 ` Paul Durrant @ 2015-10-16 16:53 ` Paul Durrant 1 sibling, 0 replies; 95+ messages in thread From: Paul Durrant @ 2015-10-16 16:53 UTC (permalink / raw) To: Kevin Wolf Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Stefano Stabellini, Anthony Perard, John Snow > -----Original Message----- > From: Kevin Wolf [mailto:kwolf@redhat.com] > Sent: 16 October 2015 17:43 > To: Paul Durrant > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci > missed in qemu > > Am 16.10.2015 um 18:20 hat Paul Durrant geschrieben: > > > -----Original Message----- > > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > > Sent: 16 October 2015 17:12 > > > To: Paul Durrant > > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > > > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for > ahci > > > missed in qemu > > > > > > Am 16.10.2015 um 17:10 hat Paul Durrant geschrieben: > > > > > -----Original Message----- > > > > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > > > > Sent: 16 October 2015 16:02 > > > > > To: Paul Durrant > > > > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; > qemu- > > > > > devel@nongnu.org; xen-devel@lists.xen.org; qemu- > block@nongnu.org > > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support > for > > > ahci > > > > > missed in qemu > > > > > > > > > > Am 16.10.2015 um 16:24 hat Paul Durrant geschrieben: > > > > > > > -----Original Message----- > > > > > > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > > > > > > Sent: 16 October 2015 15:04 > > > > > > > To: Paul Durrant > > > > > > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; > > > qemu- > > > > > > > devel@nongnu.org; xen-devel@lists.xen.org; qemu- > > > block@nongnu.org > > > > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug > support > > > for > > > > > ahci > > > > > > > missed in qemu > > > > > > > > > > > > > > Am 14.10.2015 um 14:48 hat Paul Durrant geschrieben: > > > > > > > > > -----Original Message----- > > > > > > > > > From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] > > > > > > > > > Sent: 14 October 2015 12:12 > > > > > > > > > To: Kevin Wolf; Stefano Stabellini > > > > > > > > > Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; > xen- > > > > > > > > > devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant > > > > > > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug > > > support > > > > > for > > > > > > > ahci > > > > > > > > > missed in qemu > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Il 14/10/2015 11:47, Kevin Wolf ha scritto: > > > > > > > > > > [ CC qemu-block ] > > > > > > > > > > > > > > > > > > > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > > > > > > > > > >> On Tue, 13 Oct 2015, John Snow wrote: > > > > > > > > > >>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > > > > > > > > >>>> I added ahci disk support in libxl and using it for week > seems > > > > > that > > > > > > > was > > > > > > > > > >>>> ok, after a reply of Stefano Stabellini seems that xen disk > > > unplug > > > > > > > > > >>>> support only ide disks: > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > > > > > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 > > > > > > > > > c905374ee8663d5d8 > > > > > > > > > >>>> > > > > > > > > > >>>> Today Paul Durrant told me that even if pv disk is ok also > > > with > > > > > ahci > > > > > > > and > > > > > > > > > >>>> the emulated one is offline can be a risk: > > > > > > > > > >>>> http://lists.xenproject.org/archives/html/win-pv- > > > devel/2015- > > > > > > > > > 10/msg00021.html > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > > >>>> I tried to take a fast look in qemu code but I not > understand > > > the > > > > > > > > > needed > > > > > > > > > >>>> thing for add the xen disk unplug support also for ahci, > can > > > > > > > someone do > > > > > > > > > >>>> it or tell me useful information for do it please? > > > > > > > > > >>>> > > > > > > > > > >>>> Thanks for any reply and sorry for my bad english. > > > > > > > > > >>>> > > > > > > > > > >>> I'm not entirely sure what features you need AHCI to > support > > > in > > > > > > > order > > > > > > > > > >>> for Xen to be happy. > > > > > > > > > >>> > > > > > > > > > >>> I'd guess hotplugging, but where I get confused is that IDE > > > disks > > > > > don't > > > > > > > > > >>> support hotplugging either, so I guess I'm not sure sure > what > > > you > > > > > > > need. > > > > > > > > > >>> > > > > > > > > > >>> Stefano, can you help bridge my Xen knowledge gap? > > > > > > > > > >> > > > > > > > > > >> Hi John, > > > > > > > > > >> > > > > > > > > > >> we need something like > > > > > hw/i386/xen/xen_platform.c:unplug_disks > > > > > > > but > > > > > > > > > that > > > > > > > > > >> can unplug AHCI disk. And by unplug, I mean "make > disappear" > > > like > > > > > > > > > >> pci_piix3_xen_ide_unplug does for ide. > > > > > > > > > > Maybe this would be the right time to stop the craziness > with > > > your > > > > > > > > > > hybrid IDE/xendisk setup. It's a horrible thing that would > never > > > > > happen > > > > > > > > > > on real hardware. > > > > > > > > > > > > > > > > Unfortunately, it's going to be difficult to remove such 'craziness' > > > when > > > > > you > > > > > > > don't know a priori whether the VM has PV drivers or not. > > > > > > > > > > > > > > Why wouldn't you know that beforehand? I mean, even on real > > > > > hardware > > > > > > > you > > > > > > > can have different disk interfaces (IDE, AHCI, SCSI) and you install > > > > > > > the exact driver that your hardware needs. You just do the same > > > thing on > > > > > > > VM: If your hardware is PV, you install a PV driver. If your > hardware is > > > > > > > IDE, you install an IDE driver. Whether it's PV or IDE is something > that > > > > > > > you, the user, decided when configuring the VM, so you definitely > > > know. > > > > > > > > > > > > > > > > > > > That's not necessarily true. The host admin that provisions the VM > does > > > not > > > > > necessarily know what OS the user of that VM will install. The admin > may > > > just > > > > > be providing a generic VM with an emulated CD drive that the user > can > > > point > > > > > at any ISO they want. > > > > > > > > > > > > So, as a host admin, if you provide a VM with only PV backends and > > > your > > > > > user is trying to boot an OS with no PV drivers they are not going to be > > > > > happy, so you provide emulated devices. Then, at some point later, > when > > > > > the user installs PV drivers, there really should be some way for those > > > drivers > > > > > to start up without any need to contact the host admin and have the > VM > > > > > reconfigured. > > > > > > > > > > Why only IDE and xendisk then? Maybe I have an OS that works great > > > with > > > > > AHCI, or virtio-blk, or an LSI SCSI controller, or a Megasas SCSI > > > > > controller, or USB sticks, or... (and IDE will hardly ever be the > > > > > optimal one) > > > > > > > > > > What about network cards? My OS might support the Xen PV one, or > it > > > > > might support rtl8139, or e1000, or virtio-net, or pcnet, or... > > > > > > > > > > Should we always put all of the hardware that can possibly be > emulated > > > > > in a VM just so that the one right device is definitely included even > > > > > though we don't know what OS will be running? > > > > > > > > > > This is ridiculous. > > > > > > > > It might be, but to some extent it's reality. The reason that the > > > > default emulated network device chosen by xl is rtl8193 is that it has > > > > drivers in just about every OS. The same reason for IDE being the > > > > default choice for storage. > > > > > > So what does this mean for a justification for the AHCI + xendisk hybrid > > > proposal? > > > > > > > > Just tell your admin what virtual hardware you really need. (Or tell > > > > > them to give you a proper interface to configure your VMs yourself.) > > > > > > > > > > > > > My point is that the virtual hardware that the OS user wants will > > > > change. Before they install PV drivers, they will need emulated > > > > device. After installing PV drivers they will want PV devices. Should > > > > they really have to contact their cloud provider to make the switch, > > > > when at the moment it happens automatically and transparently (the > > > > AHCI problem aside)? > > > > > > My point is that such a magic change shouldn't happen. It doesn't happen > > > on real hardware either and people still get things installed to non-IDE > > > disks. > > > > > > There is no reason to install the OS onto a different device than will > > > be used later. With Linux, it's no problem at all because the PV drivers > > > are already included on the installation media anyway, and on Windows > or > > > presumably any other OS you can load and install the drivers right from > > > the beginning. > > > > > > In fact, I would be surprised if using xendisk instead of IDE for > > > installing Windows didn't result in a noticably faster installation. > > > > > > > It most certainly would, but requiring users do it this way is likely to meet > some resistance I suspect. > > Why do you think so? Installing the PV drivers afterwards doesn't seem > easier than just providing them during the installation. > My experience of XenServer customers tells me that any form of manual intervention during guest install is likely to meet with resistance, unfortunately. > > > Now, if you really insist on providing a legacy interface even to guests > > > that eventually use PV drivers, there actually are sane ways to > > > implement this. It will be tricky to make that transition now without > > > breaking compatibility, but it could have been done from the start. > > > > > > Sane means for example that you don't open the same image twice (and > > > even read-write!) at the same time. This is a recipe for disaster and > > > it's surprising that you don't see corrupted images more often. > > > > > > > We don't because unplug is supposed to ensure the emulated device is > > gone before the PV frontend is started > > The important part is the backend, but it seems that you open the second > instance of the image only when starting the PV frontend? I believe this is the case, yes. > > As long as you don't enable the user to use most of qemu's functionality > like starting block jobs (which would keep the IDE instance around even > after unplugging the disk), it might actually be safe assuming that the > guest cooperates. Not sure what a malicious guest could do, though, as > nobody seems to check whether IDE is really unplugged before the second > instance is opened. The Windows drivers do check. After the unplug Windows is asked to re-enumerate the IDE buses and we make sure the disks we expect to be gone are really gone. > raw and qcow2 should be safe these days, but in > earlier times it would probably have been possible for the guest to > overwrite the image header and access arbitrary files on the host as > backing file. It might still be true for other image formats. > > > > So if you wanted to have a clean solution, try to think how real > > > hardware would solve the problem. If you want me to suggest something > > > off the top of my head, I would come up with an extended IDE device > (one > > > single device!) that provides the IDE I/O ports and additionally some > > > MMIO BAR that enables access to PV functionality. > > > > > > Once you enable PV functionality, the IDE ports stop working; device > > > reset disables the PV ring and goes back to IDE mode. No hard disk > > > suddenly disappearing from the machine, no image corruption if the IDE > > > device is written to before enabling PV, etc. > > > > > > > That's not sufficient though. The IDE device must not be enumerated by > > the OS and, in Windows at least, that enumeration occurs before the PV > > frontend has started up. > > The trick is that it's only a single device, so there is no second > device that must be prevented from being enumerated. You provide a > driver for this specific IDE controller, so Windows wouldn't even try > the generic IDE driver when your driver is available. > But the whole point is that we want Windows to use the generic IDE driver. If we had a driver in Windows from the outset then it would be pure PV and there'd be no problem :-) Paul > It's kind of the same sort of IDE controller extension as Bus Master > DMA, which just added a new BAR. If you had an old driver, it would just > ignore the new registers. If you had a new one, it would use them. But > in no way would the old appearance of the device simply disappear, you > just use an extended register set on the same device. > > > > But it's your choice. You can keep your broken hack in IDE. Just don't > > > expect anyone to support adding new broken hacks to other devices. > > > > > > > I'd prefer to have a cleaner solution and I believe can achieve that in > Windows by obscuring the emulated disks using filter drivers, so that's the > way I'll probably go. > > I wouldn't consider anything that works with two distinct disk devices > and two separate BlockDriverStates for the same image file a clean > solution. > > Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 16:20 ` Paul Durrant 2015-10-16 16:42 ` Kevin Wolf 2015-10-16 16:42 ` Kevin Wolf @ 2015-10-16 16:53 ` Eric Blake 2015-10-16 16:53 ` Eric Blake 3 siblings, 0 replies; 95+ messages in thread From: Eric Blake @ 2015-10-16 16:53 UTC (permalink / raw) To: Paul Durrant, Kevin Wolf Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Stefano Stabellini, Anthony Perard, John Snow [-- Attachment #1.1: Type: text/plain, Size: 1238 bytes --] On 10/16/2015 10:20 AM, Paul Durrant wrote: >> -----Original Message----- >>>>>>>>>>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: >>>>>>>>>>>> I added ahci disk support in libxl and using it for week seems Do we really need this many levels of quoting... >>>> that >>>>>> was >>>>>>>>>>>> ok, after a reply of Stefano Stabellini seems that xen disk >> unplug coupled with the result of poor mail clients that don't know how to properly reflow lines when quoting... >> Once you enable PV functionality, the IDE ports stop working; device >> reset disables the PV ring and goes back to IDE mode. No hard disk >> suddenly disappearing from the machine, no image corruption if the IDE >> device is written to before enabling PV, etc. >> > > That's not sufficient though. The IDE device must not be enumerated by the OS and, in Windows at least, that enumeration occurs before the PV frontend has started up. ...all before getting to the real new content of the message? It is not only okay to trim message, but actually encouraged on technical lists, so that you aren't wasting reader's time. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 604 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 16:20 ` Paul Durrant ` (2 preceding siblings ...) 2015-10-16 16:53 ` Eric Blake @ 2015-10-16 16:53 ` Eric Blake 3 siblings, 0 replies; 95+ messages in thread From: Eric Blake @ 2015-10-16 16:53 UTC (permalink / raw) To: Paul Durrant, Kevin Wolf Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Stefano Stabellini, Anthony Perard, John Snow [-- Attachment #1: Type: text/plain, Size: 1238 bytes --] On 10/16/2015 10:20 AM, Paul Durrant wrote: >> -----Original Message----- >>>>>>>>>>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: >>>>>>>>>>>> I added ahci disk support in libxl and using it for week seems Do we really need this many levels of quoting... >>>> that >>>>>> was >>>>>>>>>>>> ok, after a reply of Stefano Stabellini seems that xen disk >> unplug coupled with the result of poor mail clients that don't know how to properly reflow lines when quoting... >> Once you enable PV functionality, the IDE ports stop working; device >> reset disables the PV ring and goes back to IDE mode. No hard disk >> suddenly disappearing from the machine, no image corruption if the IDE >> device is written to before enabling PV, etc. >> > > That's not sufficient though. The IDE device must not be enumerated by the OS and, in Windows at least, that enumeration occurs before the PV frontend has started up. ...all before getting to the real new content of the message? It is not only okay to trim message, but actually encouraged on technical lists, so that you aren't wasting reader's time. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 604 bytes --] ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 16:11 ` Kevin Wolf 2015-10-16 16:20 ` Paul Durrant @ 2015-10-16 16:20 ` Paul Durrant 1 sibling, 0 replies; 95+ messages in thread From: Paul Durrant @ 2015-10-16 16:20 UTC (permalink / raw) To: Kevin Wolf Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Stefano Stabellini, Anthony Perard, John Snow > -----Original Message----- > From: Kevin Wolf [mailto:kwolf@redhat.com] > Sent: 16 October 2015 17:12 > To: Paul Durrant > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci > missed in qemu > > Am 16.10.2015 um 17:10 hat Paul Durrant geschrieben: > > > -----Original Message----- > > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > > Sent: 16 October 2015 16:02 > > > To: Paul Durrant > > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > > > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for > ahci > > > missed in qemu > > > > > > Am 16.10.2015 um 16:24 hat Paul Durrant geschrieben: > > > > > -----Original Message----- > > > > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > > > > Sent: 16 October 2015 15:04 > > > > > To: Paul Durrant > > > > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; > qemu- > > > > > devel@nongnu.org; xen-devel@lists.xen.org; qemu- > block@nongnu.org > > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support > for > > > ahci > > > > > missed in qemu > > > > > > > > > > Am 14.10.2015 um 14:48 hat Paul Durrant geschrieben: > > > > > > > -----Original Message----- > > > > > > > From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] > > > > > > > Sent: 14 October 2015 12:12 > > > > > > > To: Kevin Wolf; Stefano Stabellini > > > > > > > Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; xen- > > > > > > > devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant > > > > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug > support > > > for > > > > > ahci > > > > > > > missed in qemu > > > > > > > > > > > > > > > > > > > > > > > > > > > > Il 14/10/2015 11:47, Kevin Wolf ha scritto: > > > > > > > > [ CC qemu-block ] > > > > > > > > > > > > > > > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > > > > > > > >> On Tue, 13 Oct 2015, John Snow wrote: > > > > > > > >>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > > > > > > >>>> I added ahci disk support in libxl and using it for week seems > > > that > > > > > was > > > > > > > >>>> ok, after a reply of Stefano Stabellini seems that xen disk > unplug > > > > > > > >>>> support only ide disks: > > > > > > > >>>> > > > > > > > > > > > > > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 > > > > > > > c905374ee8663d5d8 > > > > > > > >>>> > > > > > > > >>>> Today Paul Durrant told me that even if pv disk is ok also > with > > > ahci > > > > > and > > > > > > > >>>> the emulated one is offline can be a risk: > > > > > > > >>>> http://lists.xenproject.org/archives/html/win-pv- > devel/2015- > > > > > > > 10/msg00021.html > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> I tried to take a fast look in qemu code but I not understand > the > > > > > > > needed > > > > > > > >>>> thing for add the xen disk unplug support also for ahci, can > > > > > someone do > > > > > > > >>>> it or tell me useful information for do it please? > > > > > > > >>>> > > > > > > > >>>> Thanks for any reply and sorry for my bad english. > > > > > > > >>>> > > > > > > > >>> I'm not entirely sure what features you need AHCI to support > in > > > > > order > > > > > > > >>> for Xen to be happy. > > > > > > > >>> > > > > > > > >>> I'd guess hotplugging, but where I get confused is that IDE > disks > > > don't > > > > > > > >>> support hotplugging either, so I guess I'm not sure sure what > you > > > > > need. > > > > > > > >>> > > > > > > > >>> Stefano, can you help bridge my Xen knowledge gap? > > > > > > > >> > > > > > > > >> Hi John, > > > > > > > >> > > > > > > > >> we need something like > > > hw/i386/xen/xen_platform.c:unplug_disks > > > > > but > > > > > > > that > > > > > > > >> can unplug AHCI disk. And by unplug, I mean "make disappear" > like > > > > > > > >> pci_piix3_xen_ide_unplug does for ide. > > > > > > > > Maybe this would be the right time to stop the craziness with > your > > > > > > > > hybrid IDE/xendisk setup. It's a horrible thing that would never > > > happen > > > > > > > > on real hardware. > > > > > > > > > > > > Unfortunately, it's going to be difficult to remove such 'craziness' > when > > > you > > > > > don't know a priori whether the VM has PV drivers or not. > > > > > > > > > > Why wouldn't you know that beforehand? I mean, even on real > > > hardware > > > > > you > > > > > can have different disk interfaces (IDE, AHCI, SCSI) and you install > > > > > the exact driver that your hardware needs. You just do the same > thing on > > > > > VM: If your hardware is PV, you install a PV driver. If your hardware is > > > > > IDE, you install an IDE driver. Whether it's PV or IDE is something that > > > > > you, the user, decided when configuring the VM, so you definitely > know. > > > > > > > > > > > > > That's not necessarily true. The host admin that provisions the VM does > not > > > necessarily know what OS the user of that VM will install. The admin may > just > > > be providing a generic VM with an emulated CD drive that the user can > point > > > at any ISO they want. > > > > > > > > So, as a host admin, if you provide a VM with only PV backends and > your > > > user is trying to boot an OS with no PV drivers they are not going to be > > > happy, so you provide emulated devices. Then, at some point later, when > > > the user installs PV drivers, there really should be some way for those > drivers > > > to start up without any need to contact the host admin and have the VM > > > reconfigured. > > > > > > Why only IDE and xendisk then? Maybe I have an OS that works great > with > > > AHCI, or virtio-blk, or an LSI SCSI controller, or a Megasas SCSI > > > controller, or USB sticks, or... (and IDE will hardly ever be the > > > optimal one) > > > > > > What about network cards? My OS might support the Xen PV one, or it > > > might support rtl8139, or e1000, or virtio-net, or pcnet, or... > > > > > > Should we always put all of the hardware that can possibly be emulated > > > in a VM just so that the one right device is definitely included even > > > though we don't know what OS will be running? > > > > > > This is ridiculous. > > > > It might be, but to some extent it's reality. The reason that the > > default emulated network device chosen by xl is rtl8193 is that it has > > drivers in just about every OS. The same reason for IDE being the > > default choice for storage. > > So what does this mean for a justification for the AHCI + xendisk hybrid > proposal? > > > > Just tell your admin what virtual hardware you really need. (Or tell > > > them to give you a proper interface to configure your VMs yourself.) > > > > > > > My point is that the virtual hardware that the OS user wants will > > change. Before they install PV drivers, they will need emulated > > device. After installing PV drivers they will want PV devices. Should > > they really have to contact their cloud provider to make the switch, > > when at the moment it happens automatically and transparently (the > > AHCI problem aside)? > > My point is that such a magic change shouldn't happen. It doesn't happen > on real hardware either and people still get things installed to non-IDE > disks. > > There is no reason to install the OS onto a different device than will > be used later. With Linux, it's no problem at all because the PV drivers > are already included on the installation media anyway, and on Windows or > presumably any other OS you can load and install the drivers right from > the beginning. > > In fact, I would be surprised if using xendisk instead of IDE for > installing Windows didn't result in a noticably faster installation. > It most certainly would, but requiring users do it this way is likely to meet some resistance I suspect. > > Now, if you really insist on providing a legacy interface even to guests > that eventually use PV drivers, there actually are sane ways to > implement this. It will be tricky to make that transition now without > breaking compatibility, but it could have been done from the start. > > Sane means for example that you don't open the same image twice (and > even read-write!) at the same time. This is a recipe for disaster and > it's surprising that you don't see corrupted images more often. > We don't because unplug is supposed to ensure the emulated device is gone before the PV frontend is started > So if you wanted to have a clean solution, try to think how real > hardware would solve the problem. If you want me to suggest something > off the top of my head, I would come up with an extended IDE device (one > single device!) that provides the IDE I/O ports and additionally some > MMIO BAR that enables access to PV functionality. > > Once you enable PV functionality, the IDE ports stop working; device > reset disables the PV ring and goes back to IDE mode. No hard disk > suddenly disappearing from the machine, no image corruption if the IDE > device is written to before enabling PV, etc. > That's not sufficient though. The IDE device must not be enumerated by the OS and, in Windows at least, that enumeration occurs before the PV frontend has started up. > > But it's your choice. You can keep your broken hack in IDE. Just don't > expect anyone to support adding new broken hacks to other devices. > I'd prefer to have a cleaner solution and I believe can achieve that in Windows by obscuring the emulated disks using filter drivers, so that's the way I'll probably go. Paul > Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 14:24 ` Paul Durrant 2015-10-16 15:02 ` Kevin Wolf @ 2015-10-16 15:02 ` Kevin Wolf 1 sibling, 0 replies; 95+ messages in thread From: Kevin Wolf @ 2015-10-16 15:02 UTC (permalink / raw) To: Paul Durrant Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Stefano Stabellini, Anthony Perard, John Snow Am 16.10.2015 um 16:24 hat Paul Durrant geschrieben: > > -----Original Message----- > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > Sent: 16 October 2015 15:04 > > To: Paul Durrant > > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci > > missed in qemu > > > > Am 14.10.2015 um 14:48 hat Paul Durrant geschrieben: > > > > -----Original Message----- > > > > From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] > > > > Sent: 14 October 2015 12:12 > > > > To: Kevin Wolf; Stefano Stabellini > > > > Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; xen- > > > > devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant > > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for > > ahci > > > > missed in qemu > > > > > > > > > > > > > > > > Il 14/10/2015 11:47, Kevin Wolf ha scritto: > > > > > [ CC qemu-block ] > > > > > > > > > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > > > > >> On Tue, 13 Oct 2015, John Snow wrote: > > > > >>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > > > >>>> I added ahci disk support in libxl and using it for week seems that > > was > > > > >>>> ok, after a reply of Stefano Stabellini seems that xen disk unplug > > > > >>>> support only ide disks: > > > > >>>> > > > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 > > > > c905374ee8663d5d8 > > > > >>>> > > > > >>>> Today Paul Durrant told me that even if pv disk is ok also with ahci > > and > > > > >>>> the emulated one is offline can be a risk: > > > > >>>> http://lists.xenproject.org/archives/html/win-pv-devel/2015- > > > > 10/msg00021.html > > > > >>>> > > > > >>>> > > > > >>>> I tried to take a fast look in qemu code but I not understand the > > > > needed > > > > >>>> thing for add the xen disk unplug support also for ahci, can > > someone do > > > > >>>> it or tell me useful information for do it please? > > > > >>>> > > > > >>>> Thanks for any reply and sorry for my bad english. > > > > >>>> > > > > >>> I'm not entirely sure what features you need AHCI to support in > > order > > > > >>> for Xen to be happy. > > > > >>> > > > > >>> I'd guess hotplugging, but where I get confused is that IDE disks don't > > > > >>> support hotplugging either, so I guess I'm not sure sure what you > > need. > > > > >>> > > > > >>> Stefano, can you help bridge my Xen knowledge gap? > > > > >> > > > > >> Hi John, > > > > >> > > > > >> we need something like hw/i386/xen/xen_platform.c:unplug_disks > > but > > > > that > > > > >> can unplug AHCI disk. And by unplug, I mean "make disappear" like > > > > >> pci_piix3_xen_ide_unplug does for ide. > > > > > Maybe this would be the right time to stop the craziness with your > > > > > hybrid IDE/xendisk setup. It's a horrible thing that would never happen > > > > > on real hardware. > > > > > > Unfortunately, it's going to be difficult to remove such 'craziness' when you > > don't know a priori whether the VM has PV drivers or not. > > > > Why wouldn't you know that beforehand? I mean, even on real hardware > > you > > can have different disk interfaces (IDE, AHCI, SCSI) and you install > > the exact driver that your hardware needs. You just do the same thing on > > VM: If your hardware is PV, you install a PV driver. If your hardware is > > IDE, you install an IDE driver. Whether it's PV or IDE is something that > > you, the user, decided when configuring the VM, so you definitely know. > > > > That's not necessarily true. The host admin that provisions the VM does not necessarily know what OS the user of that VM will install. The admin may just be providing a generic VM with an emulated CD drive that the user can point at any ISO they want. > > So, as a host admin, if you provide a VM with only PV backends and your user is trying to boot an OS with no PV drivers they are not going to be happy, so you provide emulated devices. Then, at some point later, when the user installs PV drivers, there really should be some way for those drivers to start up without any need to contact the host admin and have the VM reconfigured. Why only IDE and xendisk then? Maybe I have an OS that works great with AHCI, or virtio-blk, or an LSI SCSI controller, or a Megasas SCSI controller, or USB sticks, or... (and IDE will hardly ever be the optimal one) What about network cards? My OS might support the Xen PV one, or it might support rtl8139, or e1000, or virtio-net, or pcnet, or... Should we always put all of the hardware that can possibly be emulated in a VM just so that the one right device is definitely included even though we don't know what OS will be running? This is ridiculous. Just tell your admin what virtual hardware you really need. (Or tell them to give you a proper interface to configure your VMs yourself.) Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 14:04 ` Kevin Wolf 2015-10-16 14:24 ` Paul Durrant @ 2015-10-16 14:24 ` Paul Durrant 1 sibling, 0 replies; 95+ messages in thread From: Paul Durrant @ 2015-10-16 14:24 UTC (permalink / raw) To: Kevin Wolf Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Stefano Stabellini, Anthony Perard, John Snow > -----Original Message----- > From: Kevin Wolf [mailto:kwolf@redhat.com] > Sent: 16 October 2015 15:04 > To: Paul Durrant > Cc: Fabio Fantoni; Stefano Stabellini; John Snow; Anthony Perard; qemu- > devel@nongnu.org; xen-devel@lists.xen.org; qemu-block@nongnu.org > Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci > missed in qemu > > Am 14.10.2015 um 14:48 hat Paul Durrant geschrieben: > > > -----Original Message----- > > > From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] > > > Sent: 14 October 2015 12:12 > > > To: Kevin Wolf; Stefano Stabellini > > > Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; xen- > > > devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant > > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for > ahci > > > missed in qemu > > > > > > > > > > > > Il 14/10/2015 11:47, Kevin Wolf ha scritto: > > > > [ CC qemu-block ] > > > > > > > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > > > >> On Tue, 13 Oct 2015, John Snow wrote: > > > >>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > > >>>> I added ahci disk support in libxl and using it for week seems that > was > > > >>>> ok, after a reply of Stefano Stabellini seems that xen disk unplug > > > >>>> support only ide disks: > > > >>>> > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 > > > c905374ee8663d5d8 > > > >>>> > > > >>>> Today Paul Durrant told me that even if pv disk is ok also with ahci > and > > > >>>> the emulated one is offline can be a risk: > > > >>>> http://lists.xenproject.org/archives/html/win-pv-devel/2015- > > > 10/msg00021.html > > > >>>> > > > >>>> > > > >>>> I tried to take a fast look in qemu code but I not understand the > > > needed > > > >>>> thing for add the xen disk unplug support also for ahci, can > someone do > > > >>>> it or tell me useful information for do it please? > > > >>>> > > > >>>> Thanks for any reply and sorry for my bad english. > > > >>>> > > > >>> I'm not entirely sure what features you need AHCI to support in > order > > > >>> for Xen to be happy. > > > >>> > > > >>> I'd guess hotplugging, but where I get confused is that IDE disks don't > > > >>> support hotplugging either, so I guess I'm not sure sure what you > need. > > > >>> > > > >>> Stefano, can you help bridge my Xen knowledge gap? > > > >> > > > >> Hi John, > > > >> > > > >> we need something like hw/i386/xen/xen_platform.c:unplug_disks > but > > > that > > > >> can unplug AHCI disk. And by unplug, I mean "make disappear" like > > > >> pci_piix3_xen_ide_unplug does for ide. > > > > Maybe this would be the right time to stop the craziness with your > > > > hybrid IDE/xendisk setup. It's a horrible thing that would never happen > > > > on real hardware. > > > > Unfortunately, it's going to be difficult to remove such 'craziness' when you > don't know a priori whether the VM has PV drivers or not. > > Why wouldn't you know that beforehand? I mean, even on real hardware > you > can have different disk interfaces (IDE, AHCI, SCSI) and you install > the exact driver that your hardware needs. You just do the same thing on > VM: If your hardware is PV, you install a PV driver. If your hardware is > IDE, you install an IDE driver. Whether it's PV or IDE is something that > you, the user, decided when configuring the VM, so you definitely know. > That's not necessarily true. The host admin that provisions the VM does not necessarily know what OS the user of that VM will install. The admin may just be providing a generic VM with an emulated CD drive that the user can point at any ISO they want. So, as a host admin, if you provide a VM with only PV backends and your user is trying to boot an OS with no PV drivers they are not going to be happy, so you provide emulated devices. Then, at some point later, when the user installs PV drivers, there really should be some way for those drivers to start up without any need to contact the host admin and have the VM reconfigured. Paul > Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-14 12:48 ` Paul Durrant ` (2 preceding siblings ...) 2015-10-16 14:04 ` Kevin Wolf @ 2015-10-16 14:04 ` Kevin Wolf 3 siblings, 0 replies; 95+ messages in thread From: Kevin Wolf @ 2015-10-16 14:04 UTC (permalink / raw) To: Paul Durrant Cc: qemu-block, qemu-devel, xen-devel, Fabio Fantoni, Stefano Stabellini, Anthony Perard, John Snow Am 14.10.2015 um 14:48 hat Paul Durrant geschrieben: > > -----Original Message----- > > From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] > > Sent: 14 October 2015 12:12 > > To: Kevin Wolf; Stefano Stabellini > > Cc: John Snow; Anthony Perard; qemu-devel@nongnu.org; xen- > > devel@lists.xen.org; qemu-block@nongnu.org; Paul Durrant > > Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci > > missed in qemu > > > > > > > > Il 14/10/2015 11:47, Kevin Wolf ha scritto: > > > [ CC qemu-block ] > > > > > > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: > > >> On Tue, 13 Oct 2015, John Snow wrote: > > >>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > >>>> I added ahci disk support in libxl and using it for week seems that was > > >>>> ok, after a reply of Stefano Stabellini seems that xen disk unplug > > >>>> support only ide disks: > > >>>> > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39 > > c905374ee8663d5d8 > > >>>> > > >>>> Today Paul Durrant told me that even if pv disk is ok also with ahci and > > >>>> the emulated one is offline can be a risk: > > >>>> http://lists.xenproject.org/archives/html/win-pv-devel/2015- > > 10/msg00021.html > > >>>> > > >>>> > > >>>> I tried to take a fast look in qemu code but I not understand the > > needed > > >>>> thing for add the xen disk unplug support also for ahci, can someone do > > >>>> it or tell me useful information for do it please? > > >>>> > > >>>> Thanks for any reply and sorry for my bad english. > > >>>> > > >>> I'm not entirely sure what features you need AHCI to support in order > > >>> for Xen to be happy. > > >>> > > >>> I'd guess hotplugging, but where I get confused is that IDE disks don't > > >>> support hotplugging either, so I guess I'm not sure sure what you need. > > >>> > > >>> Stefano, can you help bridge my Xen knowledge gap? > > >> > > >> Hi John, > > >> > > >> we need something like hw/i386/xen/xen_platform.c:unplug_disks but > > that > > >> can unplug AHCI disk. And by unplug, I mean "make disappear" like > > >> pci_piix3_xen_ide_unplug does for ide. > > > Maybe this would be the right time to stop the craziness with your > > > hybrid IDE/xendisk setup. It's a horrible thing that would never happen > > > on real hardware. > > Unfortunately, it's going to be difficult to remove such 'craziness' when you don't know a priori whether the VM has PV drivers or not. Why wouldn't you know that beforehand? I mean, even on real hardware you can have different disk interfaces (IDE, AHCI, SCSI) and you install the exact driver that your hardware needs. You just do the same thing on VM: If your hardware is PV, you install a PV driver. If your hardware is IDE, you install an IDE driver. Whether it's PV or IDE is something that you, the user, decided when configuring the VM, so you definitely know. Kevin ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-13 17:10 ` Stefano Stabellini 2015-10-14 9:47 ` Kevin Wolf @ 2015-10-16 20:40 ` John Snow 2015-10-16 20:40 ` John Snow 2 siblings, 0 replies; 95+ messages in thread From: John Snow @ 2015-10-16 20:40 UTC (permalink / raw) To: Stefano Stabellini; +Cc: Anthony.Perard, Fabio Fantoni, qemu-devel, xen-devel On 10/13/2015 01:10 PM, Stefano Stabellini wrote: > On Tue, 13 Oct 2015, John Snow wrote: >> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: >>> I added ahci disk support in libxl and using it for week seems that was >>> ok, after a reply of Stefano Stabellini seems that xen disk unplug >>> support only ide disks: >>> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 >>> >>> Today Paul Durrant told me that even if pv disk is ok also with ahci and >>> the emulated one is offline can be a risk: >>> http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html >>> >>> >>> I tried to take a fast look in qemu code but I not understand the needed >>> thing for add the xen disk unplug support also for ahci, can someone do >>> it or tell me useful information for do it please? >>> >>> Thanks for any reply and sorry for my bad english. >>> >> >> I'm not entirely sure what features you need AHCI to support in order >> for Xen to be happy. >> >> I'd guess hotplugging, but where I get confused is that IDE disks don't >> support hotplugging either, so I guess I'm not sure sure what you need. >> >> Stefano, can you help bridge my Xen knowledge gap? > > Hi John, > > we need something like hw/i386/xen/xen_platform.c:unplug_disks but that > can unplug AHCI disk. And by unplug, I mean "make disappear" like > pci_piix3_xen_ide_unplug does for ide. > I'm trying to follow this discussion as best as I am able, but my lack of experience with Xen prevents me from really participating in a meaningful way. (I see that Laszlo is still discussing some CD-ROM issues with Fabio which may be of interest to me...) At any rate, I won't be authoring any Xen-specific hacks to the AHCI device, but I do have plans to implement hot-plugging emulation as per the AHCI spec. Perhaps this is sufficient for the Xen layer, but someone else will need to author the appropriate glue code. If "real" hot-plugging is not sufficient, we'll need to discuss further, preferably over some RFC patches. Thanks, --js ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-13 17:10 ` Stefano Stabellini 2015-10-14 9:47 ` Kevin Wolf 2015-10-16 20:40 ` John Snow @ 2015-10-16 20:40 ` John Snow 2015-10-19 10:18 ` Stefano Stabellini 2015-10-19 10:18 ` Stefano Stabellini 2 siblings, 2 replies; 95+ messages in thread From: John Snow @ 2015-10-16 20:40 UTC (permalink / raw) To: Stefano Stabellini; +Cc: Anthony.Perard, Fabio Fantoni, qemu-devel, xen-devel On 10/13/2015 01:10 PM, Stefano Stabellini wrote: > On Tue, 13 Oct 2015, John Snow wrote: >> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: >>> I added ahci disk support in libxl and using it for week seems that was >>> ok, after a reply of Stefano Stabellini seems that xen disk unplug >>> support only ide disks: >>> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 >>> >>> Today Paul Durrant told me that even if pv disk is ok also with ahci and >>> the emulated one is offline can be a risk: >>> http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html >>> >>> >>> I tried to take a fast look in qemu code but I not understand the needed >>> thing for add the xen disk unplug support also for ahci, can someone do >>> it or tell me useful information for do it please? >>> >>> Thanks for any reply and sorry for my bad english. >>> >> >> I'm not entirely sure what features you need AHCI to support in order >> for Xen to be happy. >> >> I'd guess hotplugging, but where I get confused is that IDE disks don't >> support hotplugging either, so I guess I'm not sure sure what you need. >> >> Stefano, can you help bridge my Xen knowledge gap? > > Hi John, > > we need something like hw/i386/xen/xen_platform.c:unplug_disks but that > can unplug AHCI disk. And by unplug, I mean "make disappear" like > pci_piix3_xen_ide_unplug does for ide. > I'm trying to follow this discussion as best as I am able, but my lack of experience with Xen prevents me from really participating in a meaningful way. (I see that Laszlo is still discussing some CD-ROM issues with Fabio which may be of interest to me...) At any rate, I won't be authoring any Xen-specific hacks to the AHCI device, but I do have plans to implement hot-plugging emulation as per the AHCI spec. Perhaps this is sufficient for the Xen layer, but someone else will need to author the appropriate glue code. If "real" hot-plugging is not sufficient, we'll need to discuss further, preferably over some RFC patches. Thanks, --js ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 20:40 ` John Snow @ 2015-10-19 10:18 ` Stefano Stabellini 2015-10-19 10:18 ` Stefano Stabellini 1 sibling, 0 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-19 10:18 UTC (permalink / raw) To: John Snow Cc: Anthony.Perard, Fabio Fantoni, xen-devel, qemu-devel, Stefano Stabellini On Fri, 16 Oct 2015, John Snow wrote: > On 10/13/2015 01:10 PM, Stefano Stabellini wrote: > > On Tue, 13 Oct 2015, John Snow wrote: > >> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > >>> I added ahci disk support in libxl and using it for week seems that was > >>> ok, after a reply of Stefano Stabellini seems that xen disk unplug > >>> support only ide disks: > >>> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 > >>> > >>> Today Paul Durrant told me that even if pv disk is ok also with ahci and > >>> the emulated one is offline can be a risk: > >>> http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html > >>> > >>> > >>> I tried to take a fast look in qemu code but I not understand the needed > >>> thing for add the xen disk unplug support also for ahci, can someone do > >>> it or tell me useful information for do it please? > >>> > >>> Thanks for any reply and sorry for my bad english. > >>> > >> > >> I'm not entirely sure what features you need AHCI to support in order > >> for Xen to be happy. > >> > >> I'd guess hotplugging, but where I get confused is that IDE disks don't > >> support hotplugging either, so I guess I'm not sure sure what you need. > >> > >> Stefano, can you help bridge my Xen knowledge gap? > > > > Hi John, > > > > we need something like hw/i386/xen/xen_platform.c:unplug_disks but that > > can unplug AHCI disk. And by unplug, I mean "make disappear" like > > pci_piix3_xen_ide_unplug does for ide. > > > > I'm trying to follow this discussion as best as I am able, but my lack > of experience with Xen prevents me from really participating in a > meaningful way. > > (I see that Laszlo is still discussing some CD-ROM issues with Fabio > which may be of interest to me...) > > At any rate, I won't be authoring any Xen-specific hacks to the AHCI > device, but I do have plans to implement hot-plugging emulation as per > the AHCI spec. Perhaps this is sufficient for the Xen layer, but someone > else will need to author the appropriate glue code. > > If "real" hot-plugging is not sufficient, we'll need to discuss further, > preferably over some RFC patches. That's fine. AHCI hot-plugging would go a long way and once we have that, the rest is easy. Thanks, Stefano ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-16 20:40 ` John Snow 2015-10-19 10:18 ` Stefano Stabellini @ 2015-10-19 10:18 ` Stefano Stabellini 2015-10-19 11:27 ` Gerd Hoffmann ` (3 more replies) 1 sibling, 4 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-19 10:18 UTC (permalink / raw) To: John Snow Cc: Anthony.Perard, Fabio Fantoni, xen-devel, qemu-devel, Stefano Stabellini On Fri, 16 Oct 2015, John Snow wrote: > On 10/13/2015 01:10 PM, Stefano Stabellini wrote: > > On Tue, 13 Oct 2015, John Snow wrote: > >> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > >>> I added ahci disk support in libxl and using it for week seems that was > >>> ok, after a reply of Stefano Stabellini seems that xen disk unplug > >>> support only ide disks: > >>> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 > >>> > >>> Today Paul Durrant told me that even if pv disk is ok also with ahci and > >>> the emulated one is offline can be a risk: > >>> http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html > >>> > >>> > >>> I tried to take a fast look in qemu code but I not understand the needed > >>> thing for add the xen disk unplug support also for ahci, can someone do > >>> it or tell me useful information for do it please? > >>> > >>> Thanks for any reply and sorry for my bad english. > >>> > >> > >> I'm not entirely sure what features you need AHCI to support in order > >> for Xen to be happy. > >> > >> I'd guess hotplugging, but where I get confused is that IDE disks don't > >> support hotplugging either, so I guess I'm not sure sure what you need. > >> > >> Stefano, can you help bridge my Xen knowledge gap? > > > > Hi John, > > > > we need something like hw/i386/xen/xen_platform.c:unplug_disks but that > > can unplug AHCI disk. And by unplug, I mean "make disappear" like > > pci_piix3_xen_ide_unplug does for ide. > > > > I'm trying to follow this discussion as best as I am able, but my lack > of experience with Xen prevents me from really participating in a > meaningful way. > > (I see that Laszlo is still discussing some CD-ROM issues with Fabio > which may be of interest to me...) > > At any rate, I won't be authoring any Xen-specific hacks to the AHCI > device, but I do have plans to implement hot-plugging emulation as per > the AHCI spec. Perhaps this is sufficient for the Xen layer, but someone > else will need to author the appropriate glue code. > > If "real" hot-plugging is not sufficient, we'll need to discuss further, > preferably over some RFC patches. That's fine. AHCI hot-plugging would go a long way and once we have that, the rest is easy. Thanks, Stefano ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-19 10:18 ` Stefano Stabellini @ 2015-10-19 11:27 ` Gerd Hoffmann 2015-10-19 11:27 ` Gerd Hoffmann ` (2 subsequent siblings) 3 siblings, 0 replies; 95+ messages in thread From: Gerd Hoffmann @ 2015-10-19 11:27 UTC (permalink / raw) To: Stefano Stabellini Cc: Anthony.Perard, Fabio Fantoni, John Snow, qemu-devel, xen-devel Hi, > > I'm trying to follow this discussion as best as I am able, but my lack > > of experience with Xen prevents me from really participating in a > > meaningful way. > > > > (I see that Laszlo is still discussing some CD-ROM issues with Fabio > > which may be of interest to me...) > > > > At any rate, I won't be authoring any Xen-specific hacks to the AHCI > > device, but I do have plans to implement hot-plugging emulation as per > > the AHCI spec. Perhaps this is sufficient for the Xen layer, but someone > > else will need to author the appropriate glue code. > > > > If "real" hot-plugging is not sufficient, we'll need to discuss further, > > preferably over some RFC patches. > > That's fine. AHCI hot-plugging would go a long way and once we have > that, the rest is easy. Can we get some more background on this? IIRC the IDE bits are needed to boot hvm guests, which goes like this: (1) boot disk is hooked up using both xenbus and ide. (2) seabios boots using ide. (3) linux kernel activates xenbus, at which point qemu zaps the ide disks to avoid the disk being present twice in the system. Correct? Do we really want repeat this exercise for AHCI? Alot has changed since this boot hack for ide was added ... As far I know OVMF has xenbus drivers, so OVMF should already boot xen guests just fine without this, correct? Can we just have xenbus drivers for seabios too? seabios can run disk drivers in 32bit mode meanwhile, so this should not be as difficult any more as it used to be. cheers, Gerd ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-19 10:18 ` Stefano Stabellini 2015-10-19 11:27 ` Gerd Hoffmann @ 2015-10-19 11:27 ` Gerd Hoffmann 2015-10-19 11:44 ` Stefano Stabellini 2015-10-19 11:44 ` Stefano Stabellini 2015-10-19 14:17 ` Fabio Fantoni 2015-10-19 14:17 ` Fabio Fantoni 3 siblings, 2 replies; 95+ messages in thread From: Gerd Hoffmann @ 2015-10-19 11:27 UTC (permalink / raw) To: Stefano Stabellini Cc: Anthony.Perard, Fabio Fantoni, John Snow, qemu-devel, xen-devel Hi, > > I'm trying to follow this discussion as best as I am able, but my lack > > of experience with Xen prevents me from really participating in a > > meaningful way. > > > > (I see that Laszlo is still discussing some CD-ROM issues with Fabio > > which may be of interest to me...) > > > > At any rate, I won't be authoring any Xen-specific hacks to the AHCI > > device, but I do have plans to implement hot-plugging emulation as per > > the AHCI spec. Perhaps this is sufficient for the Xen layer, but someone > > else will need to author the appropriate glue code. > > > > If "real" hot-plugging is not sufficient, we'll need to discuss further, > > preferably over some RFC patches. > > That's fine. AHCI hot-plugging would go a long way and once we have > that, the rest is easy. Can we get some more background on this? IIRC the IDE bits are needed to boot hvm guests, which goes like this: (1) boot disk is hooked up using both xenbus and ide. (2) seabios boots using ide. (3) linux kernel activates xenbus, at which point qemu zaps the ide disks to avoid the disk being present twice in the system. Correct? Do we really want repeat this exercise for AHCI? Alot has changed since this boot hack for ide was added ... As far I know OVMF has xenbus drivers, so OVMF should already boot xen guests just fine without this, correct? Can we just have xenbus drivers for seabios too? seabios can run disk drivers in 32bit mode meanwhile, so this should not be as difficult any more as it used to be. cheers, Gerd ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-19 11:27 ` Gerd Hoffmann @ 2015-10-19 11:44 ` Stefano Stabellini 2015-10-19 11:44 ` Stefano Stabellini 1 sibling, 0 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-19 11:44 UTC (permalink / raw) To: Gerd Hoffmann Cc: Stefano Stabellini, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, John Snow On Mon, 19 Oct 2015, Gerd Hoffmann wrote: > Hi, > > > > I'm trying to follow this discussion as best as I am able, but my lack > > > of experience with Xen prevents me from really participating in a > > > meaningful way. > > > > > > (I see that Laszlo is still discussing some CD-ROM issues with Fabio > > > which may be of interest to me...) > > > > > > At any rate, I won't be authoring any Xen-specific hacks to the AHCI > > > device, but I do have plans to implement hot-plugging emulation as per > > > the AHCI spec. Perhaps this is sufficient for the Xen layer, but someone > > > else will need to author the appropriate glue code. > > > > > > If "real" hot-plugging is not sufficient, we'll need to discuss further, > > > preferably over some RFC patches. > > > > That's fine. AHCI hot-plugging would go a long way and once we have > > that, the rest is easy. > > Can we get some more background on this? > > IIRC the IDE bits are needed to boot hvm guests, which goes like this: > > (1) boot disk is hooked up using both xenbus and ide. > (2) seabios boots using ide. > (3) linux kernel activates xenbus, at which point qemu zaps the ide > disks to avoid the disk being present twice in the system. > > Correct? > > Do we really want repeat this exercise for AHCI? Alot has changed since > this boot hack for ide was added ... > > As far I know OVMF has xenbus drivers, so OVMF should already boot xen > guests just fine without this, correct? I agree with you that the current unplug in nasty. Also I don't care much about AHCI, in fact I don't think we should be spending efforts into making that scenario work better. I think we should be working on OVMF instead and fix the bug about empty cdrom drives reported by Fabio. > Can we just have xenbus drivers for seabios too? seabios can run disk > drivers in 32bit mode meanwhile, so this should not be as difficult any > more as it used to be. Sure, I would be happy to see that happen, but I won't be working on it. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-19 11:27 ` Gerd Hoffmann 2015-10-19 11:44 ` Stefano Stabellini @ 2015-10-19 11:44 ` Stefano Stabellini 2015-10-19 16:54 ` John Snow 2015-10-19 16:54 ` John Snow 1 sibling, 2 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-19 11:44 UTC (permalink / raw) To: Gerd Hoffmann Cc: Stefano Stabellini, qemu-devel, xen-devel, Fabio Fantoni, Anthony.Perard, John Snow On Mon, 19 Oct 2015, Gerd Hoffmann wrote: > Hi, > > > > I'm trying to follow this discussion as best as I am able, but my lack > > > of experience with Xen prevents me from really participating in a > > > meaningful way. > > > > > > (I see that Laszlo is still discussing some CD-ROM issues with Fabio > > > which may be of interest to me...) > > > > > > At any rate, I won't be authoring any Xen-specific hacks to the AHCI > > > device, but I do have plans to implement hot-plugging emulation as per > > > the AHCI spec. Perhaps this is sufficient for the Xen layer, but someone > > > else will need to author the appropriate glue code. > > > > > > If "real" hot-plugging is not sufficient, we'll need to discuss further, > > > preferably over some RFC patches. > > > > That's fine. AHCI hot-plugging would go a long way and once we have > > that, the rest is easy. > > Can we get some more background on this? > > IIRC the IDE bits are needed to boot hvm guests, which goes like this: > > (1) boot disk is hooked up using both xenbus and ide. > (2) seabios boots using ide. > (3) linux kernel activates xenbus, at which point qemu zaps the ide > disks to avoid the disk being present twice in the system. > > Correct? > > Do we really want repeat this exercise for AHCI? Alot has changed since > this boot hack for ide was added ... > > As far I know OVMF has xenbus drivers, so OVMF should already boot xen > guests just fine without this, correct? I agree with you that the current unplug in nasty. Also I don't care much about AHCI, in fact I don't think we should be spending efforts into making that scenario work better. I think we should be working on OVMF instead and fix the bug about empty cdrom drives reported by Fabio. > Can we just have xenbus drivers for seabios too? seabios can run disk > drivers in 32bit mode meanwhile, so this should not be as difficult any > more as it used to be. Sure, I would be happy to see that happen, but I won't be working on it. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-19 11:44 ` Stefano Stabellini @ 2015-10-19 16:54 ` John Snow 2015-10-19 16:57 ` Stefano Stabellini 2015-10-19 16:57 ` Stefano Stabellini 2015-10-19 16:54 ` John Snow 1 sibling, 2 replies; 95+ messages in thread From: John Snow @ 2015-10-19 16:54 UTC (permalink / raw) To: Stefano Stabellini, Gerd Hoffmann Cc: Anthony.Perard, Fabio Fantoni, qemu-devel, xen-devel On 10/19/2015 07:44 AM, Stefano Stabellini wrote: > On Mon, 19 Oct 2015, Gerd Hoffmann wrote: >> Hi, >> >>>> I'm trying to follow this discussion as best as I am able, but my lack >>>> of experience with Xen prevents me from really participating in a >>>> meaningful way. >>>> >>>> (I see that Laszlo is still discussing some CD-ROM issues with Fabio >>>> which may be of interest to me...) >>>> >>>> At any rate, I won't be authoring any Xen-specific hacks to the AHCI >>>> device, but I do have plans to implement hot-plugging emulation as per >>>> the AHCI spec. Perhaps this is sufficient for the Xen layer, but someone >>>> else will need to author the appropriate glue code. >>>> >>>> If "real" hot-plugging is not sufficient, we'll need to discuss further, >>>> preferably over some RFC patches. >>> >>> That's fine. AHCI hot-plugging would go a long way and once we have >>> that, the rest is easy. >> >> Can we get some more background on this? >> >> IIRC the IDE bits are needed to boot hvm guests, which goes like this: >> >> (1) boot disk is hooked up using both xenbus and ide. >> (2) seabios boots using ide. >> (3) linux kernel activates xenbus, at which point qemu zaps the ide >> disks to avoid the disk being present twice in the system. >> >> Correct? >> >> Do we really want repeat this exercise for AHCI? Alot has changed since >> this boot hack for ide was added ... >> >> As far I know OVMF has xenbus drivers, so OVMF should already boot xen >> guests just fine without this, correct? > > I agree with you that the current unplug in nasty. Also I don't care > much about AHCI, in fact I don't think we should be spending efforts > into making that scenario work better. I think we should be working on > OVMF instead and fix the bug about empty cdrom drives reported by Fabio. > OVMF and AHCI go hand in hand here from my viewpoint. I'm happy to debug any OVMF+SATA/AHCI problems that are reported. Last I saw, Laszlo asked Fabio for some more information on this problem, so I am waiting for that information to start work on that issue. Thanks, --js > >> Can we just have xenbus drivers for seabios too? seabios can run disk >> drivers in 32bit mode meanwhile, so this should not be as difficult any >> more as it used to be. > > Sure, I would be happy to see that happen, but I won't be working on it. > ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-19 16:54 ` John Snow @ 2015-10-19 16:57 ` Stefano Stabellini 2015-10-19 18:29 ` Fabio Fantoni 2015-10-19 18:29 ` Fabio Fantoni 2015-10-19 16:57 ` Stefano Stabellini 1 sibling, 2 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-19 16:57 UTC (permalink / raw) To: John Snow Cc: Stefano Stabellini, qemu-devel, xen-devel, Fabio Fantoni, Gerd Hoffmann, Anthony.Perard On Mon, 19 Oct 2015, John Snow wrote: > On 10/19/2015 07:44 AM, Stefano Stabellini wrote: > > On Mon, 19 Oct 2015, Gerd Hoffmann wrote: > >> Hi, > >> > >>>> I'm trying to follow this discussion as best as I am able, but my lack > >>>> of experience with Xen prevents me from really participating in a > >>>> meaningful way. > >>>> > >>>> (I see that Laszlo is still discussing some CD-ROM issues with Fabio > >>>> which may be of interest to me...) > >>>> > >>>> At any rate, I won't be authoring any Xen-specific hacks to the AHCI > >>>> device, but I do have plans to implement hot-plugging emulation as per > >>>> the AHCI spec. Perhaps this is sufficient for the Xen layer, but someone > >>>> else will need to author the appropriate glue code. > >>>> > >>>> If "real" hot-plugging is not sufficient, we'll need to discuss further, > >>>> preferably over some RFC patches. > >>> > >>> That's fine. AHCI hot-plugging would go a long way and once we have > >>> that, the rest is easy. > >> > >> Can we get some more background on this? > >> > >> IIRC the IDE bits are needed to boot hvm guests, which goes like this: > >> > >> (1) boot disk is hooked up using both xenbus and ide. > >> (2) seabios boots using ide. > >> (3) linux kernel activates xenbus, at which point qemu zaps the ide > >> disks to avoid the disk being present twice in the system. > >> > >> Correct? > >> > >> Do we really want repeat this exercise for AHCI? Alot has changed since > >> this boot hack for ide was added ... > >> > >> As far I know OVMF has xenbus drivers, so OVMF should already boot xen > >> guests just fine without this, correct? > > > > I agree with you that the current unplug in nasty. Also I don't care > > much about AHCI, in fact I don't think we should be spending efforts > > into making that scenario work better. I think we should be working on > > OVMF instead and fix the bug about empty cdrom drives reported by Fabio. > > > > OVMF and AHCI go hand in hand here from my viewpoint. I'm happy to debug > any OVMF+SATA/AHCI problems that are reported. > > Last I saw, Laszlo asked Fabio for some more information on this > problem, so I am waiting for that information to start work on that issue. Fabio reported a bug using OVFM+xen_disk, no AHCI involved. OVFM has already support for the Xen PV disk protocol, see OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-19 16:57 ` Stefano Stabellini @ 2015-10-19 18:29 ` Fabio Fantoni 2015-10-19 18:29 ` Fabio Fantoni 1 sibling, 0 replies; 95+ messages in thread From: Fabio Fantoni @ 2015-10-19 18:29 UTC (permalink / raw) To: Stefano Stabellini Cc: Anthony PERARD, qemu-devel, John Snow, Gerd Hoffmann, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 3068 bytes --] 2015-10-19 18:57 GMT+02:00 Stefano Stabellini < stefano.stabellini@eu.citrix.com>: > On Mon, 19 Oct 2015, John Snow wrote: > > On 10/19/2015 07:44 AM, Stefano Stabellini wrote: > > > On Mon, 19 Oct 2015, Gerd Hoffmann wrote: > > >> Hi, > > >> > > >>>> I'm trying to follow this discussion as best as I am able, but my > lack > > >>>> of experience with Xen prevents me from really participating in a > > >>>> meaningful way. > > >>>> > > >>>> (I see that Laszlo is still discussing some CD-ROM issues with Fabio > > >>>> which may be of interest to me...) > > >>>> > > >>>> At any rate, I won't be authoring any Xen-specific hacks to the AHCI > > >>>> device, but I do have plans to implement hot-plugging emulation as > per > > >>>> the AHCI spec. Perhaps this is sufficient for the Xen layer, but > someone > > >>>> else will need to author the appropriate glue code. > > >>>> > > >>>> If "real" hot-plugging is not sufficient, we'll need to discuss > further, > > >>>> preferably over some RFC patches. > > >>> > > >>> That's fine. AHCI hot-plugging would go a long way and once we have > > >>> that, the rest is easy. > > >> > > >> Can we get some more background on this? > > >> > > >> IIRC the IDE bits are needed to boot hvm guests, which goes like this: > > >> > > >> (1) boot disk is hooked up using both xenbus and ide. > > >> (2) seabios boots using ide. > > >> (3) linux kernel activates xenbus, at which point qemu zaps the ide > > >> disks to avoid the disk being present twice in the system. > > >> > > >> Correct? > > >> > > >> Do we really want repeat this exercise for AHCI? Alot has changed > since > > >> this boot hack for ide was added ... > > >> > > >> As far I know OVMF has xenbus drivers, so OVMF should already boot xen > > >> guests just fine without this, correct? > > > > > > I agree with you that the current unplug in nasty. Also I don't care > > > much about AHCI, in fact I don't think we should be spending efforts > > > into making that scenario work better. I think we should be working on > > > OVMF instead and fix the bug about empty cdrom drives reported by > Fabio. > > > > > > > OVMF and AHCI go hand in hand here from my viewpoint. I'm happy to debug > > any OVMF+SATA/AHCI problems that are reported. > > > > Last I saw, Laszlo asked Fabio for some more information on this > > problem, so I am waiting for that information to start work on that > issue. > > Fabio reported a bug using OVFM+xen_disk, no AHCI involved. OVFM has > already support for the Xen PV disk protocol, see > OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c. > I not tried with ahci in ovmf in latest because as you told that is a missing unplug case in qemu. I tried with xendisk and ide, the empty cdrom problem is with both, from xl domU cfg: ',raw,xvdb,ro,cdrom' for xendisk and ',raw,hdb,ro,cdrom' for ide. Using seabios instead boot correctly, with ovmf not: http://lists.xen.org/archives/html/xen-devel/2015-10/msg01833.html If I remember good also in latest test persist also the problem that ovmf not respect the boot order parameter. [-- Attachment #1.2: Type: text/html, Size: 4359 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-19 16:57 ` Stefano Stabellini 2015-10-19 18:29 ` Fabio Fantoni @ 2015-10-19 18:29 ` Fabio Fantoni 2015-10-19 19:55 ` Laszlo Ersek 2015-10-19 19:55 ` Laszlo Ersek 1 sibling, 2 replies; 95+ messages in thread From: Fabio Fantoni @ 2015-10-19 18:29 UTC (permalink / raw) To: Stefano Stabellini Cc: Anthony PERARD, qemu-devel, John Snow, Gerd Hoffmann, xen-devel [-- Attachment #1: Type: text/plain, Size: 3068 bytes --] 2015-10-19 18:57 GMT+02:00 Stefano Stabellini < stefano.stabellini@eu.citrix.com>: > On Mon, 19 Oct 2015, John Snow wrote: > > On 10/19/2015 07:44 AM, Stefano Stabellini wrote: > > > On Mon, 19 Oct 2015, Gerd Hoffmann wrote: > > >> Hi, > > >> > > >>>> I'm trying to follow this discussion as best as I am able, but my > lack > > >>>> of experience with Xen prevents me from really participating in a > > >>>> meaningful way. > > >>>> > > >>>> (I see that Laszlo is still discussing some CD-ROM issues with Fabio > > >>>> which may be of interest to me...) > > >>>> > > >>>> At any rate, I won't be authoring any Xen-specific hacks to the AHCI > > >>>> device, but I do have plans to implement hot-plugging emulation as > per > > >>>> the AHCI spec. Perhaps this is sufficient for the Xen layer, but > someone > > >>>> else will need to author the appropriate glue code. > > >>>> > > >>>> If "real" hot-plugging is not sufficient, we'll need to discuss > further, > > >>>> preferably over some RFC patches. > > >>> > > >>> That's fine. AHCI hot-plugging would go a long way and once we have > > >>> that, the rest is easy. > > >> > > >> Can we get some more background on this? > > >> > > >> IIRC the IDE bits are needed to boot hvm guests, which goes like this: > > >> > > >> (1) boot disk is hooked up using both xenbus and ide. > > >> (2) seabios boots using ide. > > >> (3) linux kernel activates xenbus, at which point qemu zaps the ide > > >> disks to avoid the disk being present twice in the system. > > >> > > >> Correct? > > >> > > >> Do we really want repeat this exercise for AHCI? Alot has changed > since > > >> this boot hack for ide was added ... > > >> > > >> As far I know OVMF has xenbus drivers, so OVMF should already boot xen > > >> guests just fine without this, correct? > > > > > > I agree with you that the current unplug in nasty. Also I don't care > > > much about AHCI, in fact I don't think we should be spending efforts > > > into making that scenario work better. I think we should be working on > > > OVMF instead and fix the bug about empty cdrom drives reported by > Fabio. > > > > > > > OVMF and AHCI go hand in hand here from my viewpoint. I'm happy to debug > > any OVMF+SATA/AHCI problems that are reported. > > > > Last I saw, Laszlo asked Fabio for some more information on this > > problem, so I am waiting for that information to start work on that > issue. > > Fabio reported a bug using OVFM+xen_disk, no AHCI involved. OVFM has > already support for the Xen PV disk protocol, see > OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c. > I not tried with ahci in ovmf in latest because as you told that is a missing unplug case in qemu. I tried with xendisk and ide, the empty cdrom problem is with both, from xl domU cfg: ',raw,xvdb,ro,cdrom' for xendisk and ',raw,hdb,ro,cdrom' for ide. Using seabios instead boot correctly, with ovmf not: http://lists.xen.org/archives/html/xen-devel/2015-10/msg01833.html If I remember good also in latest test persist also the problem that ovmf not respect the boot order parameter. [-- Attachment #2: Type: text/html, Size: 4359 bytes --] ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-19 18:29 ` Fabio Fantoni @ 2015-10-19 19:55 ` Laszlo Ersek 2015-10-19 19:55 ` Laszlo Ersek 1 sibling, 0 replies; 95+ messages in thread From: Laszlo Ersek @ 2015-10-19 19:55 UTC (permalink / raw) To: Fabio Fantoni, Stefano Stabellini Cc: Jordan Justen (Intel address), qemu-devel, xen-devel, Gerd Hoffmann, Anthony PERARD, John Snow On 10/19/15 20:29, Fabio Fantoni wrote: > 2015-10-19 18:57 GMT+02:00 Stefano Stabellini > <stefano.stabellini@eu.citrix.com > <mailto:stefano.stabellini@eu.citrix.com>>: > > On Mon, 19 Oct 2015, John Snow wrote: > > On 10/19/2015 07:44 AM, Stefano Stabellini wrote: > > > On Mon, 19 Oct 2015, Gerd Hoffmann wrote: > > >> Hi, > > >> > > >>>> I'm trying to follow this discussion as best as I am able, > but my lack > > >>>> of experience with Xen prevents me from really participating in a > > >>>> meaningful way. > > >>>> > > >>>> (I see that Laszlo is still discussing some CD-ROM issues > with Fabio > > >>>> which may be of interest to me...) > > >>>> > > >>>> At any rate, I won't be authoring any Xen-specific hacks to > the AHCI > > >>>> device, but I do have plans to implement hot-plugging > emulation as per > > >>>> the AHCI spec. Perhaps this is sufficient for the Xen layer, > but someone > > >>>> else will need to author the appropriate glue code. > > >>>> > > >>>> If "real" hot-plugging is not sufficient, we'll need to > discuss further, > > >>>> preferably over some RFC patches. > > >>> > > >>> That's fine. AHCI hot-plugging would go a long way and once we > have > > >>> that, the rest is easy. > > >> > > >> Can we get some more background on this? > > >> > > >> IIRC the IDE bits are needed to boot hvm guests, which goes > like this: > > >> > > >> (1) boot disk is hooked up using both xenbus and ide. > > >> (2) seabios boots using ide. > > >> (3) linux kernel activates xenbus, at which point qemu zaps > the ide > > >> disks to avoid the disk being present twice in the system. > > >> > > >> Correct? > > >> > > >> Do we really want repeat this exercise for AHCI? Alot has > changed since > > >> this boot hack for ide was added ... > > >> > > >> As far I know OVMF has xenbus drivers, so OVMF should already > boot xen > > >> guests just fine without this, correct? > > > > > > I agree with you that the current unplug in nasty. Also I don't care > > > much about AHCI, in fact I don't think we should be spending efforts > > > into making that scenario work better. I think we should be > working on > > > OVMF instead and fix the bug about empty cdrom drives reported > by Fabio. > > > > > > > OVMF and AHCI go hand in hand here from my viewpoint. I'm happy to > debug > > any OVMF+SATA/AHCI problems that are reported. > > > > Last I saw, Laszlo asked Fabio for some more information on this > > problem, so I am waiting for that information to start work on > that issue. > > Fabio reported a bug using OVFM+xen_disk, no AHCI involved. OVFM has > already support for the Xen PV disk protocol, see > OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c. > > > I not tried with ahci in ovmf in latest because as you told that is a > missing unplug case in qemu. > > I tried with xendisk and ide, the empty cdrom problem is with both, from > xl domU cfg: > > ',raw,xvdb,ro,cdrom' for xendisk and ',raw,hdb,ro,cdrom' for ide. > > Using seabios instead boot correctly, with ovmf not: > http://lists.xen.org/archives/html/xen-devel/2015-10/msg01833.html I'll reply in that thread soon, with more info I might have. > If I remember good also in latest test persist also the problem that ovmf not respect the boot order parameter. OVMF has *utter* respect for the boot order that comes from QEMU via fw_cfg. The code that is in place has taken many-many hours, and it's one of the major features of OVMF. You are welcome to review both the code / git history: OvmfPkg/Library/QemuBootOrderLib/ and its extensive documentation: http://www.linux-kvm.org/page/OVMF (the OVMF whitepaper) section "Platform-specific boot policy" The topic is complex, which is why it requires elaborate code, and similarly elaborate documentation. The code works in ARM guests as well (QEMU or KVM), and has been repeatedly updated to recognize QEMU's OpenFirmware device paths for more and more device types. (Most recently in <https://github.com/tianocore/edk2/commit/0febef91bf83>.) The library doesn't work in Xen guests for two reasons: - I'm not a Xen developer, - no Xen developer has contributed patches for boot order processing on Xen. (If you are interested, *please* read the whitepaper section above, before asking questions.) The immediate technical reason is that Xen guests don't have an fw_cfg device. Thanks Laszlo ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-19 18:29 ` Fabio Fantoni 2015-10-19 19:55 ` Laszlo Ersek @ 2015-10-19 19:55 ` Laszlo Ersek 1 sibling, 0 replies; 95+ messages in thread From: Laszlo Ersek @ 2015-10-19 19:55 UTC (permalink / raw) To: Fabio Fantoni, Stefano Stabellini Cc: Jordan Justen (Intel address), qemu-devel, xen-devel, Gerd Hoffmann, Anthony PERARD, John Snow On 10/19/15 20:29, Fabio Fantoni wrote: > 2015-10-19 18:57 GMT+02:00 Stefano Stabellini > <stefano.stabellini@eu.citrix.com > <mailto:stefano.stabellini@eu.citrix.com>>: > > On Mon, 19 Oct 2015, John Snow wrote: > > On 10/19/2015 07:44 AM, Stefano Stabellini wrote: > > > On Mon, 19 Oct 2015, Gerd Hoffmann wrote: > > >> Hi, > > >> > > >>>> I'm trying to follow this discussion as best as I am able, > but my lack > > >>>> of experience with Xen prevents me from really participating in a > > >>>> meaningful way. > > >>>> > > >>>> (I see that Laszlo is still discussing some CD-ROM issues > with Fabio > > >>>> which may be of interest to me...) > > >>>> > > >>>> At any rate, I won't be authoring any Xen-specific hacks to > the AHCI > > >>>> device, but I do have plans to implement hot-plugging > emulation as per > > >>>> the AHCI spec. Perhaps this is sufficient for the Xen layer, > but someone > > >>>> else will need to author the appropriate glue code. > > >>>> > > >>>> If "real" hot-plugging is not sufficient, we'll need to > discuss further, > > >>>> preferably over some RFC patches. > > >>> > > >>> That's fine. AHCI hot-plugging would go a long way and once we > have > > >>> that, the rest is easy. > > >> > > >> Can we get some more background on this? > > >> > > >> IIRC the IDE bits are needed to boot hvm guests, which goes > like this: > > >> > > >> (1) boot disk is hooked up using both xenbus and ide. > > >> (2) seabios boots using ide. > > >> (3) linux kernel activates xenbus, at which point qemu zaps > the ide > > >> disks to avoid the disk being present twice in the system. > > >> > > >> Correct? > > >> > > >> Do we really want repeat this exercise for AHCI? Alot has > changed since > > >> this boot hack for ide was added ... > > >> > > >> As far I know OVMF has xenbus drivers, so OVMF should already > boot xen > > >> guests just fine without this, correct? > > > > > > I agree with you that the current unplug in nasty. Also I don't care > > > much about AHCI, in fact I don't think we should be spending efforts > > > into making that scenario work better. I think we should be > working on > > > OVMF instead and fix the bug about empty cdrom drives reported > by Fabio. > > > > > > > OVMF and AHCI go hand in hand here from my viewpoint. I'm happy to > debug > > any OVMF+SATA/AHCI problems that are reported. > > > > Last I saw, Laszlo asked Fabio for some more information on this > > problem, so I am waiting for that information to start work on > that issue. > > Fabio reported a bug using OVFM+xen_disk, no AHCI involved. OVFM has > already support for the Xen PV disk protocol, see > OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c. > > > I not tried with ahci in ovmf in latest because as you told that is a > missing unplug case in qemu. > > I tried with xendisk and ide, the empty cdrom problem is with both, from > xl domU cfg: > > ',raw,xvdb,ro,cdrom' for xendisk and ',raw,hdb,ro,cdrom' for ide. > > Using seabios instead boot correctly, with ovmf not: > http://lists.xen.org/archives/html/xen-devel/2015-10/msg01833.html I'll reply in that thread soon, with more info I might have. > If I remember good also in latest test persist also the problem that ovmf not respect the boot order parameter. OVMF has *utter* respect for the boot order that comes from QEMU via fw_cfg. The code that is in place has taken many-many hours, and it's one of the major features of OVMF. You are welcome to review both the code / git history: OvmfPkg/Library/QemuBootOrderLib/ and its extensive documentation: http://www.linux-kvm.org/page/OVMF (the OVMF whitepaper) section "Platform-specific boot policy" The topic is complex, which is why it requires elaborate code, and similarly elaborate documentation. The code works in ARM guests as well (QEMU or KVM), and has been repeatedly updated to recognize QEMU's OpenFirmware device paths for more and more device types. (Most recently in <https://github.com/tianocore/edk2/commit/0febef91bf83>.) The library doesn't work in Xen guests for two reasons: - I'm not a Xen developer, - no Xen developer has contributed patches for boot order processing on Xen. (If you are interested, *please* read the whitepaper section above, before asking questions.) The immediate technical reason is that Xen guests don't have an fw_cfg device. Thanks Laszlo ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-19 16:54 ` John Snow 2015-10-19 16:57 ` Stefano Stabellini @ 2015-10-19 16:57 ` Stefano Stabellini 1 sibling, 0 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-19 16:57 UTC (permalink / raw) To: John Snow Cc: Stefano Stabellini, qemu-devel, xen-devel, Fabio Fantoni, Gerd Hoffmann, Anthony.Perard On Mon, 19 Oct 2015, John Snow wrote: > On 10/19/2015 07:44 AM, Stefano Stabellini wrote: > > On Mon, 19 Oct 2015, Gerd Hoffmann wrote: > >> Hi, > >> > >>>> I'm trying to follow this discussion as best as I am able, but my lack > >>>> of experience with Xen prevents me from really participating in a > >>>> meaningful way. > >>>> > >>>> (I see that Laszlo is still discussing some CD-ROM issues with Fabio > >>>> which may be of interest to me...) > >>>> > >>>> At any rate, I won't be authoring any Xen-specific hacks to the AHCI > >>>> device, but I do have plans to implement hot-plugging emulation as per > >>>> the AHCI spec. Perhaps this is sufficient for the Xen layer, but someone > >>>> else will need to author the appropriate glue code. > >>>> > >>>> If "real" hot-plugging is not sufficient, we'll need to discuss further, > >>>> preferably over some RFC patches. > >>> > >>> That's fine. AHCI hot-plugging would go a long way and once we have > >>> that, the rest is easy. > >> > >> Can we get some more background on this? > >> > >> IIRC the IDE bits are needed to boot hvm guests, which goes like this: > >> > >> (1) boot disk is hooked up using both xenbus and ide. > >> (2) seabios boots using ide. > >> (3) linux kernel activates xenbus, at which point qemu zaps the ide > >> disks to avoid the disk being present twice in the system. > >> > >> Correct? > >> > >> Do we really want repeat this exercise for AHCI? Alot has changed since > >> this boot hack for ide was added ... > >> > >> As far I know OVMF has xenbus drivers, so OVMF should already boot xen > >> guests just fine without this, correct? > > > > I agree with you that the current unplug in nasty. Also I don't care > > much about AHCI, in fact I don't think we should be spending efforts > > into making that scenario work better. I think we should be working on > > OVMF instead and fix the bug about empty cdrom drives reported by Fabio. > > > > OVMF and AHCI go hand in hand here from my viewpoint. I'm happy to debug > any OVMF+SATA/AHCI problems that are reported. > > Last I saw, Laszlo asked Fabio for some more information on this > problem, so I am waiting for that information to start work on that issue. Fabio reported a bug using OVFM+xen_disk, no AHCI involved. OVFM has already support for the Xen PV disk protocol, see OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-19 11:44 ` Stefano Stabellini 2015-10-19 16:54 ` John Snow @ 2015-10-19 16:54 ` John Snow 1 sibling, 0 replies; 95+ messages in thread From: John Snow @ 2015-10-19 16:54 UTC (permalink / raw) To: Stefano Stabellini, Gerd Hoffmann Cc: Anthony.Perard, Fabio Fantoni, qemu-devel, xen-devel On 10/19/2015 07:44 AM, Stefano Stabellini wrote: > On Mon, 19 Oct 2015, Gerd Hoffmann wrote: >> Hi, >> >>>> I'm trying to follow this discussion as best as I am able, but my lack >>>> of experience with Xen prevents me from really participating in a >>>> meaningful way. >>>> >>>> (I see that Laszlo is still discussing some CD-ROM issues with Fabio >>>> which may be of interest to me...) >>>> >>>> At any rate, I won't be authoring any Xen-specific hacks to the AHCI >>>> device, but I do have plans to implement hot-plugging emulation as per >>>> the AHCI spec. Perhaps this is sufficient for the Xen layer, but someone >>>> else will need to author the appropriate glue code. >>>> >>>> If "real" hot-plugging is not sufficient, we'll need to discuss further, >>>> preferably over some RFC patches. >>> >>> That's fine. AHCI hot-plugging would go a long way and once we have >>> that, the rest is easy. >> >> Can we get some more background on this? >> >> IIRC the IDE bits are needed to boot hvm guests, which goes like this: >> >> (1) boot disk is hooked up using both xenbus and ide. >> (2) seabios boots using ide. >> (3) linux kernel activates xenbus, at which point qemu zaps the ide >> disks to avoid the disk being present twice in the system. >> >> Correct? >> >> Do we really want repeat this exercise for AHCI? Alot has changed since >> this boot hack for ide was added ... >> >> As far I know OVMF has xenbus drivers, so OVMF should already boot xen >> guests just fine without this, correct? > > I agree with you that the current unplug in nasty. Also I don't care > much about AHCI, in fact I don't think we should be spending efforts > into making that scenario work better. I think we should be working on > OVMF instead and fix the bug about empty cdrom drives reported by Fabio. > OVMF and AHCI go hand in hand here from my viewpoint. I'm happy to debug any OVMF+SATA/AHCI problems that are reported. Last I saw, Laszlo asked Fabio for some more information on this problem, so I am waiting for that information to start work on that issue. Thanks, --js > >> Can we just have xenbus drivers for seabios too? seabios can run disk >> drivers in 32bit mode meanwhile, so this should not be as difficult any >> more as it used to be. > > Sure, I would be happy to see that happen, but I won't be working on it. > ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-19 10:18 ` Stefano Stabellini 2015-10-19 11:27 ` Gerd Hoffmann 2015-10-19 11:27 ` Gerd Hoffmann @ 2015-10-19 14:17 ` Fabio Fantoni 2015-10-19 14:17 ` Fabio Fantoni 3 siblings, 0 replies; 95+ messages in thread From: Fabio Fantoni @ 2015-10-19 14:17 UTC (permalink / raw) To: Stefano Stabellini, John Snow Cc: Anthony.Perard, Gerd Hoffmann, qemu-devel, xen-devel Il 19/10/2015 12:18, Stefano Stabellini ha scritto: > On Fri, 16 Oct 2015, John Snow wrote: >> On 10/13/2015 01:10 PM, Stefano Stabellini wrote: >>> On Tue, 13 Oct 2015, John Snow wrote: >>>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: >>>>> I added ahci disk support in libxl and using it for week seems that was >>>>> ok, after a reply of Stefano Stabellini seems that xen disk unplug >>>>> support only ide disks: >>>>> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 >>>>> >>>>> Today Paul Durrant told me that even if pv disk is ok also with ahci and >>>>> the emulated one is offline can be a risk: >>>>> http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html >>>>> >>>>> >>>>> I tried to take a fast look in qemu code but I not understand the needed >>>>> thing for add the xen disk unplug support also for ahci, can someone do >>>>> it or tell me useful information for do it please? >>>>> >>>>> Thanks for any reply and sorry for my bad english. >>>>> >>>> I'm not entirely sure what features you need AHCI to support in order >>>> for Xen to be happy. >>>> >>>> I'd guess hotplugging, but where I get confused is that IDE disks don't >>>> support hotplugging either, so I guess I'm not sure sure what you need. >>>> >>>> Stefano, can you help bridge my Xen knowledge gap? >>> >>> Hi John, >>> >>> we need something like hw/i386/xen/xen_platform.c:unplug_disks but that >>> can unplug AHCI disk. And by unplug, I mean "make disappear" like >>> pci_piix3_xen_ide_unplug does for ide. >>> >> I'm trying to follow this discussion as best as I am able, but my lack >> of experience with Xen prevents me from really participating in a >> meaningful way. >> >> (I see that Laszlo is still discussing some CD-ROM issues with Fabio >> which may be of interest to me...) >> >> At any rate, I won't be authoring any Xen-specific hacks to the AHCI >> device, but I do have plans to implement hot-plugging emulation as per >> the AHCI spec. Perhaps this is sufficient for the Xen layer, but someone >> else will need to author the appropriate glue code. >> >> If "real" hot-plugging is not sufficient, we'll need to discuss further, >> preferably over some RFC patches. > That's fine. AHCI hot-plugging would go a long way and once we have > that, the rest is easy. > > Thanks, > > Stefano Thanks for any improvement you will do. About AHCI hotplugging will remove bad thing of actual "xen unplug" in seabios/ovmf but not the hybrid pv solution right? Doing without hybrid like what I tried you told me with ovmf probably is better solution after solving other bugs but probably someone don't want plain remove it. About empty cdrom not working in ovmf but needed by xl cd-insert/cd-eject I suppose that is easly reproducible, I had it in any case I tested. If not and more details are needed tell me and I'll rebuild and test following Lazslo instructions. Thanks for any reply and sorry for my bad english. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-19 10:18 ` Stefano Stabellini ` (2 preceding siblings ...) 2015-10-19 14:17 ` Fabio Fantoni @ 2015-10-19 14:17 ` Fabio Fantoni 2015-10-19 14:57 ` Stefano Stabellini 2015-10-19 14:57 ` Stefano Stabellini 3 siblings, 2 replies; 95+ messages in thread From: Fabio Fantoni @ 2015-10-19 14:17 UTC (permalink / raw) To: Stefano Stabellini, John Snow Cc: Anthony.Perard, Gerd Hoffmann, qemu-devel, xen-devel Il 19/10/2015 12:18, Stefano Stabellini ha scritto: > On Fri, 16 Oct 2015, John Snow wrote: >> On 10/13/2015 01:10 PM, Stefano Stabellini wrote: >>> On Tue, 13 Oct 2015, John Snow wrote: >>>> On 10/13/2015 11:55 AM, Fabio Fantoni wrote: >>>>> I added ahci disk support in libxl and using it for week seems that was >>>>> ok, after a reply of Stefano Stabellini seems that xen disk unplug >>>>> support only ide disks: >>>>> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 >>>>> >>>>> Today Paul Durrant told me that even if pv disk is ok also with ahci and >>>>> the emulated one is offline can be a risk: >>>>> http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html >>>>> >>>>> >>>>> I tried to take a fast look in qemu code but I not understand the needed >>>>> thing for add the xen disk unplug support also for ahci, can someone do >>>>> it or tell me useful information for do it please? >>>>> >>>>> Thanks for any reply and sorry for my bad english. >>>>> >>>> I'm not entirely sure what features you need AHCI to support in order >>>> for Xen to be happy. >>>> >>>> I'd guess hotplugging, but where I get confused is that IDE disks don't >>>> support hotplugging either, so I guess I'm not sure sure what you need. >>>> >>>> Stefano, can you help bridge my Xen knowledge gap? >>> >>> Hi John, >>> >>> we need something like hw/i386/xen/xen_platform.c:unplug_disks but that >>> can unplug AHCI disk. And by unplug, I mean "make disappear" like >>> pci_piix3_xen_ide_unplug does for ide. >>> >> I'm trying to follow this discussion as best as I am able, but my lack >> of experience with Xen prevents me from really participating in a >> meaningful way. >> >> (I see that Laszlo is still discussing some CD-ROM issues with Fabio >> which may be of interest to me...) >> >> At any rate, I won't be authoring any Xen-specific hacks to the AHCI >> device, but I do have plans to implement hot-plugging emulation as per >> the AHCI spec. Perhaps this is sufficient for the Xen layer, but someone >> else will need to author the appropriate glue code. >> >> If "real" hot-plugging is not sufficient, we'll need to discuss further, >> preferably over some RFC patches. > That's fine. AHCI hot-plugging would go a long way and once we have > that, the rest is easy. > > Thanks, > > Stefano Thanks for any improvement you will do. About AHCI hotplugging will remove bad thing of actual "xen unplug" in seabios/ovmf but not the hybrid pv solution right? Doing without hybrid like what I tried you told me with ovmf probably is better solution after solving other bugs but probably someone don't want plain remove it. About empty cdrom not working in ovmf but needed by xl cd-insert/cd-eject I suppose that is easly reproducible, I had it in any case I tested. If not and more details are needed tell me and I'll rebuild and test following Lazslo instructions. Thanks for any reply and sorry for my bad english. ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-19 14:17 ` Fabio Fantoni @ 2015-10-19 14:57 ` Stefano Stabellini 2015-10-19 14:57 ` Stefano Stabellini 1 sibling, 0 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-19 14:57 UTC (permalink / raw) To: Fabio Fantoni Cc: Stefano Stabellini, qemu-devel, xen-devel, Gerd Hoffmann, Anthony.Perard, John Snow On Mon, 19 Oct 2015, Fabio Fantoni wrote: > Il 19/10/2015 12:18, Stefano Stabellini ha scritto: > > On Fri, 16 Oct 2015, John Snow wrote: > > > On 10/13/2015 01:10 PM, Stefano Stabellini wrote: > > > > On Tue, 13 Oct 2015, John Snow wrote: > > > > > On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > > > > > I added ahci disk support in libxl and using it for week seems that > > > > > > was > > > > > > ok, after a reply of Stefano Stabellini seems that xen disk unplug > > > > > > support only ide disks: > > > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 > > > > > > > > > > > > Today Paul Durrant told me that even if pv disk is ok also with ahci > > > > > > and > > > > > > the emulated one is offline can be a risk: > > > > > > http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html > > > > > > > > > > > > > > > > > > I tried to take a fast look in qemu code but I not understand the > > > > > > needed > > > > > > thing for add the xen disk unplug support also for ahci, can someone > > > > > > do > > > > > > it or tell me useful information for do it please? > > > > > > > > > > > > Thanks for any reply and sorry for my bad english. > > > > > > > > > > > I'm not entirely sure what features you need AHCI to support in order > > > > > for Xen to be happy. > > > > > > > > > > I'd guess hotplugging, but where I get confused is that IDE disks > > > > > don't > > > > > support hotplugging either, so I guess I'm not sure sure what you > > > > > need. > > > > > > > > > > Stefano, can you help bridge my Xen knowledge gap? > > > > Hi John, > > > > > > > > we need something like hw/i386/xen/xen_platform.c:unplug_disks but that > > > > can unplug AHCI disk. And by unplug, I mean "make disappear" like > > > > pci_piix3_xen_ide_unplug does for ide. > > > > > > > I'm trying to follow this discussion as best as I am able, but my lack > > > of experience with Xen prevents me from really participating in a > > > meaningful way. > > > > > > (I see that Laszlo is still discussing some CD-ROM issues with Fabio > > > which may be of interest to me...) > > > > > > At any rate, I won't be authoring any Xen-specific hacks to the AHCI > > > device, but I do have plans to implement hot-plugging emulation as per > > > the AHCI spec. Perhaps this is sufficient for the Xen layer, but someone > > > else will need to author the appropriate glue code. > > > > > > If "real" hot-plugging is not sufficient, we'll need to discuss further, > > > preferably over some RFC patches. > > That's fine. AHCI hot-plugging would go a long way and once we have > > that, the rest is easy. > > > > Thanks, > > > > Stefano > > Thanks for any improvement you will do. > About AHCI hotplugging will remove bad thing of actual "xen unplug" in > seabios/ovmf but not the hybrid pv solution right? Yeah, it would still be an hybrid solution > Doing without hybrid like what I tried you told me with ovmf probably is > better solution after solving other bugs but probably someone don't want plain > remove it. Yes, I think OVMF with PV disks is a better approach and we'll fix any bugs you find. If you find other bugs, send them to the list! > About empty cdrom not working in ovmf but needed by xl cd-insert/cd-eject I > suppose that is easly reproducible, I had it in any case I tested. > If not and more details are needed tell me and I'll rebuild and test following > Lazslo instructions. No worries, we should be able to repro and fix it, thanks for the report! ^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu 2015-10-19 14:17 ` Fabio Fantoni 2015-10-19 14:57 ` Stefano Stabellini @ 2015-10-19 14:57 ` Stefano Stabellini 1 sibling, 0 replies; 95+ messages in thread From: Stefano Stabellini @ 2015-10-19 14:57 UTC (permalink / raw) To: Fabio Fantoni Cc: Stefano Stabellini, qemu-devel, xen-devel, Gerd Hoffmann, Anthony.Perard, John Snow On Mon, 19 Oct 2015, Fabio Fantoni wrote: > Il 19/10/2015 12:18, Stefano Stabellini ha scritto: > > On Fri, 16 Oct 2015, John Snow wrote: > > > On 10/13/2015 01:10 PM, Stefano Stabellini wrote: > > > > On Tue, 13 Oct 2015, John Snow wrote: > > > > > On 10/13/2015 11:55 AM, Fabio Fantoni wrote: > > > > > > I added ahci disk support in libxl and using it for week seems that > > > > > > was > > > > > > ok, after a reply of Stefano Stabellini seems that xen disk unplug > > > > > > support only ide disks: > > > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 > > > > > > > > > > > > Today Paul Durrant told me that even if pv disk is ok also with ahci > > > > > > and > > > > > > the emulated one is offline can be a risk: > > > > > > http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html > > > > > > > > > > > > > > > > > > I tried to take a fast look in qemu code but I not understand the > > > > > > needed > > > > > > thing for add the xen disk unplug support also for ahci, can someone > > > > > > do > > > > > > it or tell me useful information for do it please? > > > > > > > > > > > > Thanks for any reply and sorry for my bad english. > > > > > > > > > > > I'm not entirely sure what features you need AHCI to support in order > > > > > for Xen to be happy. > > > > > > > > > > I'd guess hotplugging, but where I get confused is that IDE disks > > > > > don't > > > > > support hotplugging either, so I guess I'm not sure sure what you > > > > > need. > > > > > > > > > > Stefano, can you help bridge my Xen knowledge gap? > > > > Hi John, > > > > > > > > we need something like hw/i386/xen/xen_platform.c:unplug_disks but that > > > > can unplug AHCI disk. And by unplug, I mean "make disappear" like > > > > pci_piix3_xen_ide_unplug does for ide. > > > > > > > I'm trying to follow this discussion as best as I am able, but my lack > > > of experience with Xen prevents me from really participating in a > > > meaningful way. > > > > > > (I see that Laszlo is still discussing some CD-ROM issues with Fabio > > > which may be of interest to me...) > > > > > > At any rate, I won't be authoring any Xen-specific hacks to the AHCI > > > device, but I do have plans to implement hot-plugging emulation as per > > > the AHCI spec. Perhaps this is sufficient for the Xen layer, but someone > > > else will need to author the appropriate glue code. > > > > > > If "real" hot-plugging is not sufficient, we'll need to discuss further, > > > preferably over some RFC patches. > > That's fine. AHCI hot-plugging would go a long way and once we have > > that, the rest is easy. > > > > Thanks, > > > > Stefano > > Thanks for any improvement you will do. > About AHCI hotplugging will remove bad thing of actual "xen unplug" in > seabios/ovmf but not the hybrid pv solution right? Yeah, it would still be an hybrid solution > Doing without hybrid like what I tried you told me with ovmf probably is > better solution after solving other bugs but probably someone don't want plain > remove it. Yes, I think OVMF with PV disks is a better approach and we'll fix any bugs you find. If you find other bugs, send them to the list! > About empty cdrom not working in ovmf but needed by xl cd-insert/cd-eject I > suppose that is easly reproducible, I had it in any case I tested. > If not and more details are needed tell me and I'll rebuild and test following > Lazslo instructions. No worries, we should be able to repro and fix it, thanks for the report! ^ permalink raw reply [flat|nested] 95+ messages in thread
end of thread, other threads:[~2015-10-20 14:53 UTC | newest] Thread overview: 95+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-10-13 15:55 [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu Fabio Fantoni 2015-10-13 15:55 ` Fabio Fantoni 2015-10-13 16:45 ` [Qemu-devel] " John Snow 2015-10-13 16:45 ` John Snow 2015-10-13 17:10 ` Stefano Stabellini 2015-10-14 9:47 ` Kevin Wolf 2015-10-14 11:06 ` Stefano Stabellini 2015-10-14 11:27 ` [Qemu-devel] [Xen-devel] " Ian Campbell 2015-10-14 11:27 ` [Qemu-devel] " Ian Campbell 2015-10-15 23:10 ` Laszlo Ersek 2015-10-15 23:10 ` [Qemu-devel] [Xen-devel] " Laszlo Ersek 2015-10-16 2:38 ` [Qemu-devel] " Kevin O'Connor 2015-10-16 2:38 ` [Qemu-devel] [Xen-devel] " Kevin O'Connor 2015-10-16 9:06 ` Stefano Stabellini 2015-10-16 9:06 ` [Qemu-devel] " Stefano Stabellini 2015-10-16 9:21 ` [Qemu-devel] [Xen-devel] " Laszlo Ersek 2015-10-16 9:21 ` [Qemu-devel] " Laszlo Ersek 2015-10-16 9:33 ` [Qemu-devel] [Xen-devel] " Stefano Stabellini 2015-10-16 9:33 ` [Qemu-devel] " Stefano Stabellini 2015-10-16 9:34 ` [Qemu-devel] [Xen-devel] " Ian Campbell 2015-10-16 9:34 ` [Qemu-devel] " Ian Campbell 2015-10-16 13:03 ` [Qemu-devel] [Xen-devel] " Kevin O'Connor 2015-10-16 13:03 ` [Qemu-devel] " Kevin O'Connor 2015-10-16 9:13 ` [Qemu-devel] [Xen-devel] " Laszlo Ersek 2015-10-16 9:13 ` [Qemu-devel] " Laszlo Ersek 2015-10-14 11:32 ` Kevin Wolf 2015-10-14 11:44 ` Stefano Stabellini 2015-10-15 16:27 ` Fabio Fantoni 2015-10-15 16:27 ` Fabio Fantoni 2015-10-15 18:02 ` Anthony PERARD 2015-10-15 18:02 ` Anthony PERARD 2015-10-16 8:32 ` Fabio Fantoni 2015-10-16 8:32 ` Fabio Fantoni 2015-10-16 10:13 ` Anthony PERARD 2015-10-16 10:23 ` Fabio Fantoni 2015-10-16 10:47 ` Stefano Stabellini 2015-10-16 10:47 ` Stefano Stabellini 2015-10-16 11:34 ` Fabio Fantoni 2015-10-16 11:34 ` Fabio Fantoni 2015-10-16 19:09 ` Laszlo Ersek 2015-10-16 19:09 ` Laszlo Ersek 2015-10-19 20:32 ` Laszlo Ersek 2015-10-20 11:59 ` Stefano Stabellini 2015-10-20 11:59 ` Stefano Stabellini 2015-10-20 12:45 ` Laszlo Ersek 2015-10-20 12:45 ` Laszlo Ersek 2015-10-20 14:52 ` Stefano Stabellini 2015-10-20 14:52 ` Stefano Stabellini 2015-10-19 20:32 ` Laszlo Ersek 2015-10-16 10:23 ` Fabio Fantoni 2015-10-14 11:11 ` Fabio Fantoni 2015-10-14 12:48 ` Paul Durrant 2015-10-15 23:35 ` Laszlo Ersek 2015-10-15 23:35 ` Laszlo Ersek 2015-10-16 14:04 ` Kevin Wolf 2015-10-16 14:24 ` Paul Durrant 2015-10-16 15:02 ` Kevin Wolf 2015-10-16 15:10 ` Paul Durrant 2015-10-16 16:11 ` Kevin Wolf 2015-10-16 16:11 ` Kevin Wolf 2015-10-16 16:20 ` Paul Durrant 2015-10-16 16:42 ` Kevin Wolf 2015-10-16 16:42 ` Kevin Wolf 2015-10-16 16:53 ` Paul Durrant 2015-10-16 17:03 ` Kevin Wolf 2015-10-16 17:03 ` Kevin Wolf 2015-10-19 13:42 ` Fabio Fantoni 2015-10-19 13:42 ` Fabio Fantoni 2015-10-16 16:53 ` Paul Durrant 2015-10-16 16:53 ` Eric Blake 2015-10-16 16:53 ` Eric Blake 2015-10-16 16:20 ` Paul Durrant 2015-10-16 15:02 ` Kevin Wolf 2015-10-16 14:24 ` Paul Durrant 2015-10-16 14:04 ` Kevin Wolf 2015-10-16 20:40 ` John Snow 2015-10-16 20:40 ` John Snow 2015-10-19 10:18 ` Stefano Stabellini 2015-10-19 10:18 ` Stefano Stabellini 2015-10-19 11:27 ` Gerd Hoffmann 2015-10-19 11:27 ` Gerd Hoffmann 2015-10-19 11:44 ` Stefano Stabellini 2015-10-19 11:44 ` Stefano Stabellini 2015-10-19 16:54 ` John Snow 2015-10-19 16:57 ` Stefano Stabellini 2015-10-19 18:29 ` Fabio Fantoni 2015-10-19 18:29 ` Fabio Fantoni 2015-10-19 19:55 ` Laszlo Ersek 2015-10-19 19:55 ` Laszlo Ersek 2015-10-19 16:57 ` Stefano Stabellini 2015-10-19 16:54 ` John Snow 2015-10-19 14:17 ` Fabio Fantoni 2015-10-19 14:17 ` Fabio Fantoni 2015-10-19 14:57 ` Stefano Stabellini 2015-10-19 14:57 ` Stefano Stabellini
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.