[Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

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.

Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[John Snow]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[John Snow]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Kevin Wolf]

[ 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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

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.

Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu

[Ian Campbell]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Ian Campbell]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Kevin Wolf]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Paul Durrant]

> -----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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

[-- 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"]

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

[-- 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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Anthony PERARD]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Anthony PERARD]

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

Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

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.
> 

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

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.
> 

Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu

[Kevin O'Connor]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Kevin O'Connor]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

[-- 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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

[-- 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

Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

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.

Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

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
> 

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

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
> 

Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

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

Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

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.

Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu

[Ian Campbell]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Ian Campbell]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Anthony PERARD]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

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?

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

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?

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

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?

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

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?

Re: [Qemu-devel] [Xen-devel] Question about xen disk unplug support for ahci missed in qemu

[Kevin O'Connor]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Kevin O'Connor]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Kevin Wolf]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Kevin Wolf]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Paul Durrant]

> -----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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Paul Durrant]

> -----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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Kevin Wolf]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Kevin Wolf]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Paul Durrant]

> -----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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Kevin Wolf]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Kevin Wolf]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Paul Durrant]

> -----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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Paul Durrant]

> -----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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Kevin Wolf]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Kevin Wolf]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Eric Blake]

[-- 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 --]

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Eric Blake]

[-- 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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Paul Durrant]

> -----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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Paul Durrant]

> -----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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Kevin Wolf]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Kevin Wolf]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[John Snow]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[John Snow]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Gerd Hoffmann]

  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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Gerd Hoffmann]

  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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

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!

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

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!

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[John Snow]

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.
> 

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[John Snow]

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.
> 

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

[-- 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 --]

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Fabio Fantoni]

[-- 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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

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.

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

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.
> 

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

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.
> 

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

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

Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

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