[PATCH] don't expose pvpanic device in the UI

[Hu Tao]

pvpanic device is an internal default device in qemu. It may cause
problem when upgrading qemu from a version without pvpanic.

for example: in Windows(let's say XP) the Device manager will open a
"new device" wizard and the device will appear as an unrecognized
device.  On a cluster with hundreds of such VMs, If that cluster has
a health monitoring service it may show all the VMs in a "not healthy"
state.

This patch is a workaround to not show pvpanic in UI to avoid the
problem in Windows.

Cc: Marcel Apfelbaum <[e-mail]>
Cc: "Michael S. Tsirkin" <[e-mail]>
Cc: Paolo Bonzini <[e-mail]>
Cc: Gerd Hoffmann <[e-mail]>
Cc: Eric Blake <[e-mail]>
Cc: "Daniel P. Berrange" <[e-mail]>
Cc: Andreas Färber <[e-mail]>
Signed-off-by: Hu Tao <[e-mail]>
---

See discussion at: http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg00036.html
and follow-ups.

 src/ssdt-misc.dsl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/ssdt-misc.dsl b/src/ssdt-misc.dsl
index acc850e..19a2058 100644
--- a/src/ssdt-misc.dsl
+++ b/src/ssdt-misc.dsl
@@ -75,7 +75,7 @@ DefinitionBlock ("ssdt-misc.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1)
                 If (LEqual(Local0, Zero)) {
                     Return (0x00)
                 } Else {
-                    Return (0x0F)
+                    Return (0x0B)
                 }
             }
 
-- 
1.8.1.4

[Michael S. Tsirkin]

On Mon, Aug 05, 2013 at 03:47:23PM +0800, Hu Tao wrote:
> pvpanic device is an internal default device in qemu. It may cause
> problem when upgrading qemu from a version without pvpanic.
>
> for example: in Windows(let's say XP) the Device manager will open a
> "new device" wizard and the device will appear as an unrecognized
> device.  On a cluster with hundreds of such VMs, If that cluster has
> a health monitoring service it may show all the VMs in a "not healthy"
> state.
>
> This patch is a workaround to not show pvpanic in UI to avoid the
> problem in Windows.
>
> Cc: Marcel Apfelbaum <[e-mail]>
> Cc: "Michael S. Tsirkin" <[e-mail]>
> Cc: Paolo Bonzini <[e-mail]>
> Cc: Gerd Hoffmann <[e-mail]>
> Cc: Eric Blake <[e-mail]>
> Cc: "Daniel P. Berrange" <[e-mail]>
> Cc: Andreas Färber <[e-mail]>
> Signed-off-by: Hu Tao <[e-mail]>

Quoting from this discussion:
	>That may "fix" the issue of a windows guest showing the yellow ! mark,
	>but what if, down the road, someone writes an actual windows driver that
	>is aware of that port and how to make a windows BSOD write a panic
	>notification to the port?  How does a user go about installing such a
	>driver if the device is not exposed in the user interface list of
	>devices?

I think the correct way to address this is:
- don't create the device by default, only when -device pvpanic is
  present
- teach management to supply said -device pvpanic for guests which
  support the pvpanic device
> ---
>
> See discussion at: http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg00036.html
> and follow-ups.
>
> src/ssdt-misc.dsl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/ssdt-misc.dsl b/src/ssdt-misc.dsl
> index acc850e..19a2058 100644
> --- a/src/ssdt-misc.dsl
> +++ b/src/ssdt-misc.dsl
> @@ -75,7 +75,7 @@ DefinitionBlock ("ssdt-misc.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1)
>                  If (LEqual(Local0, Zero)) {
>                      Return (0x00)
>                  } Else {
> -                    Return (0x0F)
> +                    Return (0x0B)
>                  }
>              }

[Gleb Natapov]

On Mon, Aug 05, 2013 at 11:10:55AM +0300, Michael S. Tsirkin wrote:
> On Mon, Aug 05, 2013 at 03:47:23PM +0800, Hu Tao wrote:
> > pvpanic device is an internal default device in qemu. It may cause
> > problem when upgrading qemu from a version without pvpanic.
> >
> > for example: in Windows(let's say XP) the Device manager will open a
> > "new device" wizard and the device will appear as an unrecognized
> > device.  On a cluster with hundreds of such VMs, If that cluster has
> > a health monitoring service it may show all the VMs in a "not healthy"
> > state.
> >
> > This patch is a workaround to not show pvpanic in UI to avoid the
> > problem in Windows.
> >
> > Cc: Marcel Apfelbaum <[e-mail]>
> > Cc: "Michael S. Tsirkin" <[e-mail]>
> > Cc: Paolo Bonzini <[e-mail]>
> > Cc: Gerd Hoffmann <[e-mail]>
> > Cc: Eric Blake <[e-mail]>
> > Cc: "Daniel P. Berrange" <[e-mail]>
> > Cc: Andreas Färber <[e-mail]>
> > Signed-off-by: Hu Tao <[e-mail]>
>
> Quoting from this discussion:
> > That may "fix" the issue of a windows guest showing the yellow ! mark,
> > but what if, down the road, someone writes an actual windows driver that
> > is aware of that port and how to make a windows BSOD write a panic
> > notification to the port?  How does a user go about installing such a
> > driver if the device is not exposed in the user interface list of
> > devices?
>
> I think the correct way to address this is:
> - don't create the device by default, only when -device pvpanic is
>   present
> - teach management to supply said -device pvpanic for guests which
>   support the pvpanic device

That's just pushing the problem elsewhere. How management suppose to know if
guest support pvpanic device? What if initially guest did not have a
driver, but the it was installed? If device appears for old machine
models this is bug, otherwise I fail to see any problem.

--
			Gleb.

[Gerd Hoffmann]

On 08/05/13 10:16, Gleb Natapov wrote:
> On Mon, Aug 05, 2013 at 11:10:55AM +0300, Michael S. Tsirkin wrote:
> > On Mon, Aug 05, 2013 at 03:47:23PM +0800, Hu Tao wrote:
> > > pvpanic device is an internal default device in qemu. It may cause
> > > problem when upgrading qemu from a version without pvpanic.
> > >
> > > for example: in Windows(let's say XP) the Device manager will open a
> > > "new device" wizard and the device will appear as an unrecognized
> > > device.  On a cluster with hundreds of such VMs, If that cluster has
> > > a health monitoring service it may show all the VMs in a "not healthy"
> > > state.
> > >
> > > This patch is a workaround to not show pvpanic in UI to avoid the
> > > problem in Windows.
> > >
> > > Cc: Marcel Apfelbaum <[e-mail]>
> > > Cc: "Michael S. Tsirkin" <[e-mail]>
> > > Cc: Paolo Bonzini <[e-mail]>
> > > Cc: Gerd Hoffmann <[e-mail]>
> > > Cc: Eric Blake <[e-mail]>
> > > Cc: "Daniel P. Berrange" <[e-mail]>
> > > Cc: Andreas Färber <[e-mail]>
> > > Signed-off-by: Hu Tao <[e-mail]>
> >
> > Quoting from this discussion:
> > > That may "fix" the issue of a windows guest showing the yellow ! mark,
> > > but what if, down the road, someone writes an actual windows driver that
> > > is aware of that port and how to make a windows BSOD write a panic
> > > notification to the port?  How does a user go about installing such a
> > > driver if the device is not exposed in the user interface list of
> > > devices?
> >
> > I think the correct way to address this is:
> > - don't create the device by default, only when -device pvpanic is
> >   present
> > - teach management to supply said -device pvpanic for guests which
> >   support the pvpanic device
>
> That's just pushing the problem elsewhere. How management suppose to know if
> guest support pvpanic device?

The problem isn't new and management already does that when figuring
whenever the guest should get ide/ahci/virtio-blk/virtio-scsi storage,
ac97 or intel-hda sound, rtl8139/e1000/virtio nic, ...
> What if initially guest did not have a
> driver, but the it was installed?

Update the machine config then?  What is so special about the pvpanic
device that it should be treated differently from everything else?

cheers,
  Gerd

[Gleb Natapov]

On Mon, Aug 05, 2013 at 11:03:53AM +0200, Gerd Hoffmann wrote:
> On 08/05/13 10:16, Gleb Natapov wrote:
> > On Mon, Aug 05, 2013 at 11:10:55AM +0300, Michael S. Tsirkin wrote:
> > > On Mon, Aug 05, 2013 at 03:47:23PM +0800, Hu Tao wrote:
> > > > pvpanic device is an internal default device in qemu. It may cause
> > > > problem when upgrading qemu from a version without pvpanic.
> > > >
> > > > for example: in Windows(let's say XP) the Device manager will open a
> > > > "new device" wizard and the device will appear as an unrecognized
> > > > device.  On a cluster with hundreds of such VMs, If that cluster has
> > > > a health monitoring service it may show all the VMs in a "not healthy"
> > > > state.
> > > >
> > > > This patch is a workaround to not show pvpanic in UI to avoid the
> > > > problem in Windows.
> > > >
> > > > Cc: Marcel Apfelbaum <[e-mail]>
> > > > Cc: "Michael S. Tsirkin" <[e-mail]>
> > > > Cc: Paolo Bonzini <[e-mail]>
> > > > Cc: Gerd Hoffmann <[e-mail]>
> > > > Cc: Eric Blake <[e-mail]>
> > > > Cc: "Daniel P. Berrange" <[e-mail]>
> > > > Cc: Andreas Färber <[e-mail]>
> > > > Signed-off-by: Hu Tao <[e-mail]>
> > >
> > > Quoting from this discussion:
> > > > That may "fix" the issue of a windows guest showing the yellow ! mark,
> > > > but what if, down the road, someone writes an actual windows driver that
> > > > is aware of that port and how to make a windows BSOD write a panic
> > > > notification to the port?  How does a user go about installing such a
> > > > driver if the device is not exposed in the user interface list of
> > > > devices?
> > >
> > > I think the correct way to address this is:
> > > - don't create the device by default, only when -device pvpanic is
> > >   present
> > > - teach management to supply said -device pvpanic for guests which
> > >   support the pvpanic device
> >
> > That's just pushing the problem elsewhere. How management suppose to know if
> > guest support pvpanic device?
>
> The problem isn't new and management already does that when figuring
> whenever the guest should get ide/ahci/virtio-blk/virtio-scsi storage,
> ac97 or intel-hda sound, rtl8139/e1000/virtio nic, ...

All of those are multiple choses and some of then expect you to install
drivers actually since they also do not work out of the box with all guests.
> > What if initially guest did not have a
> > driver, but the it was installed?
>
> Update the machine config then?  What is so special about the pvpanic
> You cannot change HW after machine is installed without risking Windows
> reactivation.
> device that it should be treated differently from everything else?

It is simple, it does not have alternative, there is not reason to not
have it. So your options are: having the device and installing driver if
functionality is needed, or never have it.

--
			Gleb.

[Paolo Bonzini]

> > That's just pushing the problem elsewhere. How management suppose to know
> > if guest support pvpanic device?
>
> The problem isn't new and management already does that when figuring
> whenever the guest should get ide/ahci/virtio-blk/virtio-scsi storage,
> ac97 or intel-hda sound, rtl8139/e1000/virtio nic, ...

Depending on the management, "management" could just be the user.
Most of the time the user simply says to use virtio in the XML.

If it had to be specified manually every time, pvpanic would be
just another knob that nobody uses.  The point of pvpanic was to
be as automatic and unobtrusive as possible.

Replying to Eric's concerns, drivers can be installed anyway even
if the devices are hidden.  Windows will detect that the driver
matches the ACPI ID of pvpanic (QEMU0001) and install it.

Resetting bit 2 is Microsoft's suggested way to hide devices, even
broken ones (i.e. with bit 3 = 0 in _STA).  See
http://msdn.microsoft.com/en-us/library/windows/hardware/ff547032(v=vs.85).a...
for more information.  The document also mentions that it is
possible to show hidden devices, at which point the user will
see pvpanic.  In this case, having the exclamation mark is good
and expected, since the lack of a driver is real.

(Besides, I would not be much worried about Microsoft's choice of
icons.  I doubt a machine would be considered "not healthy" just
because the "missing driver" icon looks worrisome).

Paolo

[Michael S. Tsirkin]

On Mon, Aug 05, 2013 at 06:10:47AM -0400, Paolo Bonzini wrote:
> > > That's just pushing the problem elsewhere. How management suppose to know
> > > if guest support pvpanic device?
> >
> > The problem isn't new and management already does that when figuring
> > whenever the guest should get ide/ahci/virtio-blk/virtio-scsi storage,
> > ac97 or intel-hda sound, rtl8139/e1000/virtio nic, ...
>
> Depending on the management, "management" could just be the user.
> Most of the time the user simply says to use virtio in the XML.
>
> If it had to be specified manually every time, pvpanic would be
> just another knob that nobody uses.

Management tools already set XML appropriately depending
on the guest. If users are happy to leave the device alone,
we are also happy.
> The point of pvpanic was to
> be as automatic and unobtrusive as possible.
>
> Replying to Eric's concerns, drivers can be installed anyway even
> if the devices are hidden.  Windows will detect that the driver
> matches the ACPI ID of pvpanic (QEMU0001) and install it.
>
> Resetting bit 2 is Microsoft's suggested way to hide devices, even
> broken ones (i.e. with bit 3 = 0 in _STA).  See
> http://msdn.microsoft.com/en-us/library/windows/hardware/ff547032(v=vs.85).a...
> for more information.  The document also mentions that it is
> possible to show hidden devices, at which point the user will
> see pvpanic.  In this case, having the exclamation mark is good
> and expected, since the lack of a driver is real.
>
> (Besides, I would not be much worried about Microsoft's choice of
> icons.  I doubt a machine would be considered "not healthy" just
> because the "missing driver" icon looks worrisome).
>
> Paolo

I think Marcel commented on events in event manager, not
about the icon.

[Paolo Bonzini]

> > > > That's just pushing the problem elsewhere. How management suppose to
> > > > know
> > > > if guest support pvpanic device?
> > >
> > > The problem isn't new and management already does that when figuring
> > > whenever the guest should get ide/ahci/virtio-blk/virtio-scsi storage,
> > > ac97 or intel-hda sound, rtl8139/e1000/virtio nic, ...
> >
> > Depending on the management, "management" could just be the user.
> > Most of the time the user simply says to use virtio in the XML.
> >
> > If it had to be specified manually every time, pvpanic would be
> > just another knob that nobody uses.
>
> Management tools already set XML appropriately depending
> on the guest. If users are happy to leave the device alone,
> we are also happy.

What if the guest is upgraded?  How does the user know they have
to add a magic device?  This is really against the original purpose
of pvpanic.
> > (Besides, I would not be much worried about Microsoft's choice of
> > icons.  I doubt a machine would be considered "not healthy" just
> > because the "missing driver" icon looks worrisome).
>
> I think Marcel commented on events in event manager, not
> about the icon.

I didn't see any remark about the event log.  His original message
went from "The outcome may be, for example: in Windows [...] the device
will appear as an unrecognized device" straight to "a health
monitoring service it may show all the VMs in a 'not healthy' state".

Really, all guests handle the missing driver without asking the user.
At some point MSFT even issued a hotfix to disable the pesky Found
New Hardware wizard.  Let's treat it as a guest bug, hide the device
altogether with _OSI (detecting Vista or 2008 or Linux), and declare
that Windows 2000/XP/2003 lack support for pvpanic.

Paolo

[Michael S. Tsirkin]

On Mon, Aug 05, 2013 at 12:01:57PM -0400, Paolo Bonzini wrote:
> > > > > That's just pushing the problem elsewhere. How management suppose to
> > > > > know
> > > > > if guest support pvpanic device?
> > > >
> > > > The problem isn't new and management already does that when figuring
> > > > whenever the guest should get ide/ahci/virtio-blk/virtio-scsi storage,
> > > > ac97 or intel-hda sound, rtl8139/e1000/virtio nic, ...
> > >
> > > Depending on the management, "management" could just be the user.
> > > Most of the time the user simply says to use virtio in the XML.
> > >
> > > If it had to be specified manually every time, pvpanic would be
> > > just another knob that nobody uses.
> >
> > Management tools already set XML appropriately depending
> > on the guest. If users are happy to leave the device alone,
> > we are also happy.
>
> What if the guest is upgraded?  How does the user know they have
> to add a magic device?

Device is useless without a driver anyway.
How does user know there's need to install a driver?
Same thing really.
> This is really against the original purpose
> of pvpanic.

Then the purpose was wrong.

It's useful to be able to have a virtual
machine that looks like a physical machine.  From this point of view,
any PV that can't be disabled is a bug.

It's easy enough to add random stuff to the default
machine but it just does not scale.

So let's add -device pvpanic to QEMU, same as any device, if
you think everyone absolutely wants this device explain this
to libvirt guys and they'll add it by default, they
are much closer to real users and can treat this appropriately.
> > > (Besides, I would not be much worried about Microsoft's choice of
> > > icons.  I doubt a machine would be considered "not healthy" just
> > > because the "missing driver" icon looks worrisome).
> >
> > I think Marcel commented on events in event manager, not
> > about the icon.
>
> I didn't see any remark about the event log.  His original message
> went from "The outcome may be, for example: in Windows [...] the device
> will appear as an unrecognized device" straight to "a health
> monitoring service it may show all the VMs in a 'not healthy' state".
>
> Really, all guests handle the missing driver without asking the user.

Did you really check them all?
> At some point MSFT even issued a hotfix to disable the pesky Found
> New Hardware wizard.  Let's treat it as a guest bug, hide the device
> altogether with _OSI (detecting Vista or 2008 or Linux),
> and declare
> that Windows 2000/XP/2003 lack support for pvpanic.

Sounds like you merely mean all windows guests.
> Paolo

If we go that route, we really must detect 2000/XP/2003.
Blacklist specific bad guests, don't whitelist
guests.


-- 
MST

[Paolo Bonzini]

On 08/05/2013 06:18 PM, Michael S. Tsirkin wrote:
> > > > Depending on the management, "management" could just be the user.
> > > > Most of the time the user simply says to use virtio in the XML.
> > > >
> > > > If it had to be specified manually every time, pvpanic would be
> > > > just another knob that nobody uses.
> > >
> > > Management tools already set XML appropriately depending
> > > on the guest. If users are happy to leave the device alone,
> > > we are also happy.
> >
> > What if the guest is upgraded?  How does the user know they have
> > to add a magic device?
>
> Device is useless without a driver anyway.

Who cares?  It doesn't eat valuable resources.  (20 bytes in the DSDT 
are not valuable, a PCI slot is).
> How does user know there's need to install a driver?

Apparently that was not a problem in Vista and later, when Microsoft 
stopped bugging users with the wizard by default.  And it's never been a 
problem in Linux.

But they don't need to know that, since probably no one will write a 
driver for pvpanic that runs on Windows XP (6 months before EOL) or 2003 
(18 months before EOL).
> So let's add -device pvpanic to QEMU, same as any device, if
> you think everyone absolutely wants this device explain this
> to libvirt guys and they'll add it by default, they
> are much closer to real users and can treat this appropriately.

It will be exactly the same problem, just thrown further from where you 
can find a real solution---which is not QEMU and is not libvirt, it is 
in the firmware.
> > Really, all guests handle the missing driver without asking the user.
>
> Did you really check them all?

All those that have a GUI that runs by default, and manage drivers in 
said GUI...
> > At some point MSFT even issued a hotfix to disable the pesky Found
> > New Hardware wizard.  Let's treat it as a guest bug, hide the device
> > altogether with _OSI (detecting Vista or 2008 or Linux),
> > and declare
> > that Windows 2000/XP/2003 lack support for pvpanic.
>
> Sounds like you merely mean all windows guests.

... which means all Windows guests, yes.

Paolo

[Michael S. Tsirkin]

On Mon, Aug 05, 2013 at 06:46:06PM +0200, Paolo Bonzini wrote:
> On 08/05/2013 06:18 PM, Michael S. Tsirkin wrote:
> > > > > Depending on the management, "management" could just be the user.
> > > > > Most of the time the user simply says to use virtio in the XML.
> > > > >
> > > > > If it had to be specified manually every time, pvpanic would be
> > > > > just another knob that nobody uses.
> > > >
> > > > Management tools already set XML appropriately depending
> > > > on the guest. If users are happy to leave the device alone,
> > > > we are also happy.
> > >
> > > What if the guest is upgraded?  How does the user know they have
> > > to add a magic device?
> >
> > Device is useless without a driver anyway.
>
> Who cares?  It doesn't eat valuable resources.  (20 bytes in the
> DSDT are not valuable, a PCI slot is).

IO ports are a bit more valuable.

But I was responding to
what you said "how does the user know they have to add
a magic device" - in the same way that they know
they need a driver.
> > How does user know there's need to install a driver?
>
> Apparently that was not a problem in Vista and later, when Microsoft
> stopped bugging users with the wizard by default.  And it's never
> been a problem in Linux.
>
> But they don't need to know that, since probably no one will write a
> driver for pvpanic that runs on Windows XP (6 months before EOL) or
> 2003 (18 months before EOL).
> > So let's add -device pvpanic to QEMU, same as any device, if
> > you think everyone absolutely wants this device explain this
> > to libvirt guys and they'll add it by default, they
> > are much closer to real users and can treat this appropriately.
>
> It will be exactly the same problem, just thrown further from where
> you can find a real solution---which is not QEMU and is not libvirt,
> it is in the firmware.
> > > Really, all guests handle the missing driver without asking the user.
> >
> > Did you really check them all?
>
> All those that have a GUI that runs by default, and manage drivers
> in said GUI...

What does GUI have to do with it?
Guests can log errors or fail in a variety of ways.
GUI is not required.
> > > At some point MSFT even issued a hotfix to disable the pesky Found
> > > New Hardware wizard.  Let's treat it as a guest bug, hide the device
> > > altogether with _OSI (detecting Vista or 2008 or Linux),
> > > and declare
> > > that Windows 2000/XP/2003 lack support for pvpanic.
> >
> > Sounds like you merely mean all windows guests.
>
> ... which means all Windows guests, yes.
>
> Paolo

Which are the ones where we noticed there's a problem.
But there could be other guests which are problematic.

If you see a mouse in a room, how likely is it that there's
a single mouse there?

This is a PV technology which to me looks like it was
rushed through and not only set on by default, but
without a way to disable it - apparently on the assumption
there's 0 chance it can cause any damage. Now that
we do know the chance it's not there, why not go back
to the standard interface, and why not give
users a chance to enable/disable it?

In other words, let's do the standard thing, and make the new device
available with -device pvpanic.
And in BIOS, let's just obey what QEMU tells us to do,
and not create the device if it's not there.

-- 
MST

[Eric Blake]

On 08/05/2013 12:26 PM, Michael S. Tsirkin wrote:
> This is a PV technology which to me looks like it was
> rushed through and not only set on by default, but
> without a way to disable it - apparently on the assumption
> there's 0 chance it can cause any damage. Now that
> we do know the chance it's not there, why not go back
> to the standard interface, and why not give
> users a chance to enable/disable it?
>
> In other words, let's do the standard thing, and make the new device
> available with -device pvpanic.
> And in BIOS, let's just obey what QEMU tells us to do,
> and not create the device if it's not there.

Libvirt has no problem enabling -device pvpanic for all guests where
<on_crash> is set to a non-default value, since the use of <on_crash> is
a sufficient hint that the user expects the guest to be able to notify
of a crash in the first place.  But I definitely agree that it is more
conservative to ask libvirt to always provide -device pvpanic than it is
to blindly enable the device and hope that it never causes damage.

-- 
Eric Blake   eblake redhat com    [phone]
Libvirt virtualization library http://libvirt.org

[Paolo Bonzini]

> Libvirt has no problem enabling -device pvpanic for all guests where
> <on_crash> is set to a non-default value, since the use of <on_crash> is
> a sufficient hint that the user expects the guest to be able to notify
> of a crash in the first place.  But I definitely agree that it is more
> conservative to ask libvirt to always provide -device pvpanic than it is
> to blindly enable the device and hope that it never causes damage.

Changing guest ABI depending on <on_crash> is a much much worse
cure than the disease.

Paolo

[Eric Blake]

On 08/05/2013 01:04 PM, Paolo Bonzini wrote:
> > Libvirt has no problem enabling -device pvpanic for all guests where
> > <on_crash> is set to a non-default value, since the use of <on_crash> is
> > a sufficient hint that the user expects the guest to be able to notify
> > of a crash in the first place.  But I definitely agree that it is more
> > conservative to ask libvirt to always provide -device pvpanic than it is
> > to blindly enable the device and hope that it never causes damage.
>
> Changing guest ABI depending on <on_crash> is a much much worse
> cure than the disease.

I'm not sure I follow.  If the user requests <on_crash> but qemu is too
old to provide -device pvpanic, then libvirt can fail to create the
guest by telling the user their request can't be honored.  If the user
requests <on_crash> and qemu is new enough, then libvirt requests the
pvpanic device as part of starting the guest.  If the user doesn't
requst <on_crash> handling, then the presence or absence of the device
doesn't matter, and it is more conservative to omit the device.  The
only time the guest ABI would change is if the user changes XML - but
that's exactly what the user is already capable of doing in any number
of other situations.

-- 
Eric Blake   eblake redhat com    [phone]
Libvirt virtualization library http://libvirt.org

[Paolo Bonzini]

On 08/05/2013 09:19 PM, Eric Blake wrote:
> On 08/05/2013 01:04 PM, Paolo Bonzini wrote:
> > > Libvirt has no problem enabling -device pvpanic for all guests where
> > > <on_crash> is set to a non-default value, since the use of <on_crash> is
> > > a sufficient hint that the user expects the guest to be able to notify
> > > of a crash in the first place.  But I definitely agree that it is more
> > > conservative to ask libvirt to always provide -device pvpanic than it is
> > > to blindly enable the device and hope that it never causes damage.
> >
> > Changing guest ABI depending on <on_crash> is a much much worse
> > cure than the disease.
>
> I'm not sure I follow.  If the user requests <on_crash> but qemu is too
> old to provide -device pvpanic, then libvirt can fail to create the
> guest by telling the user their request can't be honored.  If the user
> requests <on_crash> and qemu is new enough, then libvirt requests the
> pvpanic device as part of starting the guest.  If the user doesn't
> requst <on_crash> handling, then the presence or absence of the device
> doesn't matter, and it is more conservative to omit the device.  The
> only time the guest ABI would change is if the user changes XML - but
> that's exactly what the user is already capable of doing in any number
> of other situations.

Not all XML changes are also changes to the guest hardware.  The 
simplest case is perhaps changing the disk source; it doesn't change the 
hardware seen by the guest, only the contents.

Also, even with a default <on_crash> (is it "preserve"? that's the 
behavior without pvpanic) it is useful to have the device because 
libvirt then can properly mark the domain as "crashed" instead of "running".

Paolo

[Gleb Natapov]

On Mon, Aug 05, 2013 at 09:26:28PM +0300, Michael S. Tsirkin wrote:
> On Mon, Aug 05, 2013 at 06:46:06PM +0200, Paolo Bonzini wrote:
> > On 08/05/2013 06:18 PM, Michael S. Tsirkin wrote:
> > > > > > Depending on the management, "management" could just be the user.
> > > > > > Most of the time the user simply says to use virtio in the XML.
> > > > > >
> > > > > > If it had to be specified manually every time, pvpanic would be
> > > > > > just another knob that nobody uses.
> > > > >
> > > > > Management tools already set XML appropriately depending
> > > > > on the guest. If users are happy to leave the device alone,
> > > > > we are also happy.
> > > >
> > > > What if the guest is upgraded?  How does the user know they have
> > > > to add a magic device?
> > >
> > > Device is useless without a driver anyway.
> >
> > Who cares?  It doesn't eat valuable resources.  (20 bytes in the
> > DSDT are not valuable, a PCI slot is).
>
> IO ports are a bit more valuable.
>
> But I was responding to
> what you said "how does the user know they have to add
> a magic device" - in the same way that they know
> they need a driver.

They see yellow exclamation mark in a gui.
> > > How does user know there's need to install a driver?
> >
> > Apparently that was not a problem in Vista and later, when Microsoft
> > stopped bugging users with the wizard by default.  And it's never
> > been a problem in Linux.
> >
> > But they don't need to know that, since probably no one will write a
> > driver for pvpanic that runs on Windows XP (6 months before EOL) or
> > 2003 (18 months before EOL).
> > > So let's add -device pvpanic to QEMU, same as any device, if
> > > you think everyone absolutely wants this device explain this
> > > to libvirt guys and they'll add it by default, they
> > > are much closer to real users and can treat this appropriately.
> >
> > It will be exactly the same problem, just thrown further from where
> > you can find a real solution---which is not QEMU and is not libvirt,
> > it is in the firmware.
> > > > Really, all guests handle the missing driver without asking the user.
> > >
> > > Did you really check them all?
> >
> > All those that have a GUI that runs by default, and manage drivers
> > in said GUI...
>
> What does GUI have to do with it?
> Guests can log errors or fail in a variety of ways.
> GUI is not required.
> This is pure speculations. Why OS would fail if it finds HW it does not
> have driver for if said HW is not needed for the OS to function?
> > > > At some point MSFT even issued a hotfix to disable the pesky Found
> > > > New Hardware wizard.  Let's treat it as a guest bug, hide the device
> > > > altogether with _OSI (detecting Vista or 2008 or Linux),
> > > > and declare
> > > > that Windows 2000/XP/2003 lack support for pvpanic.
> > >
> > > Sounds like you merely mean all windows guests.
> >
> > ... which means all Windows guests, yes.
> >
> > Paolo
>
> Which are the ones where we noticed there's a problem.

What is problematic about guest telling a user that it has HW without a
driver? I is just OS doing what OS should do.
> But there could be other guests which are problematic.

FUD :)
> If you see a mouse in a room, how likely is it that there's
> a single mouse there?
>
> This is a PV technology which to me looks like it was
> rushed through and not only set on by default, but
> without a way to disable it - apparently on the assumption
> there's 0 chance it can cause any damage. Now that
> we do know the chance it's not there, why not go back
> to the standard interface, and why not give
> users a chance to enable/disable it?
> You should be able to disable it with: -device pvpanic,ioport=0
> We have different definition of "damage" though.
> In other words, let's do the standard thing, and make the new device
> available with -device pvpanic.
> And in BIOS, let's just obey what QEMU tells us to do,
> and not create the device if it's not there.
>
> _______________________________________________
> SeaBIOS mailing list
> [e-mail]
> http://www.seabios.org/mailman/listinfo/seabios

[Michael S. Tsirkin]

On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > If you see a mouse in a room, how likely is it that there's
> > a single mouse there?
> >
> > This is a PV technology which to me looks like it was
> > rushed through and not only set on by default, but
> > without a way to disable it - apparently on the assumption
> > there's 0 chance it can cause any damage. Now that
> > we do know the chance it's not there, why not go back
> > to the standard interface, and why not give
> > users a chance to enable/disable it?
> > You should be able to disable it with: -device pvpanic,ioport=0

Doesn't work for me.
Besides, both -device pvpanic and use of ioport=0 to disable it
are completely undocumented.

BTW pls keep qemu-devel Cc'd.
> We have different definition of "damage" though.

Driver bugs, qemu bugs, OSPM bugs all can cause issues
like OS crashes, suspend/resume issues, bad
performance ... What's your definition of damage?

-- 
MST

[Gleb Natapov]

On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > If you see a mouse in a room, how likely is it that there's
> > > a single mouse there?
> > >
> > > This is a PV technology which to me looks like it was
> > > rushed through and not only set on by default, but
> > > without a way to disable it - apparently on the assumption
> > > there's 0 chance it can cause any damage. Now that
> > > we do know the chance it's not there, why not go back
> > > to the standard interface, and why not give
> > > users a chance to enable/disable it?
> > > You should be able to disable it with: -device pvpanic,ioport=0
>
> Doesn't work for me.
> Bug that should be fixed. With this command line _STA should return
> zero.
> Besides, both -device pvpanic and use of ioport=0 to disable it
> are completely undocumented.

Not the only undocumented thing in QEMU command line :)
> BTW pls keep qemu-devel Cc'd.

Haven't touched CC list.
> > We have different definition of "damage" though.
>
> Driver bugs, qemu bugs, OSPM bugs all can cause issues
> like OS crashes, suspend/resume issues, bad
> performance ... What's your definition of damage?

None of those cover the case at hand.

--
			Gleb.

[Andreas Färber]

Am 06.08.2013 10:36, schrieb Gleb Natapov:
> On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> > On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > > If you see a mouse in a room, how likely is it that there's
> > > > a single mouse there?
> > > >
> > > > This is a PV technology which to me looks like it was
> > > > rushed through and not only set on by default, but
> > > > without a way to disable it - apparently on the assumption
> > > > there's 0 chance it can cause any damage. Now that
> > > > we do know the chance it's not there, why not go back
> > > > to the standard interface, and why not give
> > > > users a chance to enable/disable it?
> > > > You should be able to disable it with: -device pvpanic,ioport=0
> >
> > Doesn't work for me.
> > Bug that should be fixed. With this command line _STA should return
> > zero.
> > Besides, both -device pvpanic and use of ioport=0 to disable it
> > are completely undocumented.
>
> Not the only undocumented thing in QEMU command line :)
> [snip]

I disagree: -device adds a device, not removes one. It will still be
present.

I am neutral as to whether qemu-system-x86_64 should have it enabled by
default or not. But if we want to suppress it, then -nodefaults should
disable it. Since libvirt uses that though, it would mean libvirt would
need to add it back, whether via user's XML domain config or by libvirt
itself based on some version/etc. heuristics.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

[Michael S. Tsirkin]

On Tue, Aug 06, 2013 at 10:45:01AM +0200, Andreas Färber wrote:
> Am 06.08.2013 10:36, schrieb Gleb Natapov:
> > On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> > > On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > > > If you see a mouse in a room, how likely is it that there's
> > > > > a single mouse there?
> > > > >
> > > > > This is a PV technology which to me looks like it was
> > > > > rushed through and not only set on by default, but
> > > > > without a way to disable it - apparently on the assumption
> > > > > there's 0 chance it can cause any damage. Now that
> > > > > we do know the chance it's not there, why not go back
> > > > > to the standard interface, and why not give
> > > > > users a chance to enable/disable it?
> > > > > You should be able to disable it with: -device pvpanic,ioport=0
> > >
> > > Doesn't work for me.
> > > Bug that should be fixed. With this command line _STA should return
> > > zero.
> > > Besides, both -device pvpanic and use of ioport=0 to disable it
> > > are completely undocumented.
> >
> > Not the only undocumented thing in QEMU command line :)
> > [snip]
>
> I disagree: -device adds a device, not removes one. It will still be
> present.
>
> I am neutral as to whether qemu-system-x86_64 should have it enabled by
> default or not. But if we want to suppress it, then -nodefaults should
> disable it. Since libvirt uses that though, it would mean libvirt would
> need to add it back, whether via user's XML domain config or by libvirt
> itself based on some version/etc. heuristics.
>
> Andreas

Do you agree that this (-nodefaults does not have pvpanic device by
default, -device pvpanic adds it) makes more sense than the
proposed alternative: -nodefaults has pvpanic unless an old
-M type is specified, ioport=0 removes the device?
>

[Gleb Natapov]

On Tue, Aug 06, 2013 at 10:45:01AM +0200, Andreas Färber wrote:
> Am 06.08.2013 10:36, schrieb Gleb Natapov:
> > On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> > > On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > > > If you see a mouse in a room, how likely is it that there's
> > > > > a single mouse there?
> > > > >
> > > > > This is a PV technology which to me looks like it was
> > > > > rushed through and not only set on by default, but
> > > > > without a way to disable it - apparently on the assumption
> > > > > there's 0 chance it can cause any damage. Now that
> > > > > we do know the chance it's not there, why not go back
> > > > > to the standard interface, and why not give
> > > > > users a chance to enable/disable it?
> > > > > You should be able to disable it with: -device pvpanic,ioport=0
> > >
> > > Doesn't work for me.
> > > Bug that should be fixed. With this command line _STA should return
> > > zero.
> > > Besides, both -device pvpanic and use of ioport=0 to disable it
> > > are completely undocumented.
> >
> > Not the only undocumented thing in QEMU command line :)
> > [snip]
>
> I disagree: -device adds a device, not removes one. It will still be
> present.

I assume you are answering to the quote about ioport=0, not
documentation here. ioport=0 does not removes the device, it disables
it. The claim was it cannot be disabled, it can (assuming no bugs), but
it should not be.
> I am neutral as to whether qemu-system-x86_64 should have it enabled by
> default or not. But if we want to suppress it, then -nodefaults should
> disable it. Since libvirt uses that though, it would mean libvirt would
> need to add it back, whether via user's XML domain config or by libvirt
> itself based on some version/etc. heuristics.

There is no clear definition of what -nodefaults should or should not
do. Should it disable PV ACPI hotplug device? Should it create a machine
with no mmio/io regions registered at all?

--
			Gleb.

[Michael S. Tsirkin]

On Tue, Aug 06, 2013 at 12:20:27PM +0300, Gleb Natapov wrote:
> On Tue, Aug 06, 2013 at 10:45:01AM +0200, Andreas Färber wrote:
> > Am 06.08.2013 10:36, schrieb Gleb Natapov:
> > > On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> > > > On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > > > > If you see a mouse in a room, how likely is it that there's
> > > > > > a single mouse there?
> > > > > >
> > > > > > This is a PV technology which to me looks like it was
> > > > > > rushed through and not only set on by default, but
> > > > > > without a way to disable it - apparently on the assumption
> > > > > > there's 0 chance it can cause any damage. Now that
> > > > > > we do know the chance it's not there, why not go back
> > > > > > to the standard interface, and why not give
> > > > > > users a chance to enable/disable it?
> > > > > > You should be able to disable it with: -device pvpanic,ioport=0
> > > >
> > > > Doesn't work for me.
> > > > Bug that should be fixed. With this command line _STA should return
> > > > zero.
> > > > Besides, both -device pvpanic and use of ioport=0 to disable it
> > > > are completely undocumented.
> > >
> > > Not the only undocumented thing in QEMU command line :)
> > > [snip]
> >
> > I disagree: -device adds a device, not removes one. It will still be
> > present.
>
> I assume you are answering to the quote about ioport=0, not
> documentation here. ioport=0 does not removes the device, it disables
> it. The claim was it cannot be disabled, it can (assuming no bugs), but
> it should not be.
> > I am neutral as to whether qemu-system-x86_64 should have it enabled by
> > default or not. But if we want to suppress it, then -nodefaults should
> > disable it. Since libvirt uses that though, it would mean libvirt would
> > need to add it back, whether via user's XML domain config or by libvirt
> > itself based on some version/etc. heuristics.
>
> There is no clear definition of what -nodefaults should or should not
> do.
> Should it disable PV ACPI hotplug device?
> Should it create a machine
> with no mmio/io regions registered at all?

We can't change the meaning for existing devices.
So we need to keep everything that it historically
included.
But it's a good question whether e.g. ACPI hotplug
for q35 should be a separate device, and disabled
with -nodefaults.
>

pvpanic presents itself as a separate device, this is different from
PV ACPI hotplug which is part of PIIX.

[Qemu-devel] [PATCH] don't expose pvpanic device in the UI

[Andreas Färber]

Am 06.08.2013 11:20, schrieb Gleb Natapov:
> On Tue, Aug 06, 2013 at 10:45:01AM +0200, Andreas Färber wrote:
> > Am 06.08.2013 10:36, schrieb Gleb Natapov:
> > > On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> > > > On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > > > > If you see a mouse in a room, how likely is it that there's
> > > > > > a single mouse there?
> > > > > >
> > > > > > This is a PV technology which to me looks like it was
> > > > > > rushed through and not only set on by default, but
> > > > > > without a way to disable it - apparently on the assumption
> > > > > > there's 0 chance it can cause any damage. Now that
> > > > > > we do know the chance it's not there, why not go back
> > > > > > to the standard interface, and why not give
> > > > > > users a chance to enable/disable it?
> > > > > > You should be able to disable it with: -device pvpanic,ioport=0
> > > >
> > > > Doesn't work for me.
> > > > Bug that should be fixed. With this command line _STA should return
> > > > zero.
> > > > Besides, both -device pvpanic and use of ioport=0 to disable it
> > > > are completely undocumented.
> > >
> > > Not the only undocumented thing in QEMU command line :)
> > > [snip]
> >
> > I disagree: -device adds a device, not removes one. It will still be
> > present.
>
> I assume you are answering to the quote about ioport=0, not
> documentation here.

Answering to all of i) additional -device pvpanic,ioport=0 to disable
another one, ii) ioport=0 to disable a certain device and iii) either
being an undocumented feature to disable devices. ;)

"Disabled" here referring both to not in PIO/ACPI/etc. and to not
present in the QOM composition tree.

In the end with pvpanic being an ISADevice, this goes back to my large
series for Hervé's i87312 Super I/O chipset, where we discussed what
would be involved in having a reconfigurable ISADevice not listen on
some port/IRQ. We haven't decided on a solution yet (reconfiguring the
i87312 from guest will assert or be ignored), and I strongly disagree to
the solution of ioport=0 magic as general solution - either we should
use realized=false (which then drops any VMStateDescription from
migration) or revive my earlier attempts to add an explicit boolean
ISADevice::enabled state, which would correspond to EEPROM-based
reconfiguration of the plugged-in ISA card. Which of course would only
help ISADevices but not MMIO-based SysBusDevices...

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

[Qemu-devel] [PATCH] don't expose pvpanic device in the UI

[Markus Armbruster]

Andreas Färber <[e-mail]> writes:
> Am 06.08.2013 10:36, schrieb Gleb Natapov:
> > On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> > > On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > > > If you see a mouse in a room, how likely is it that there's
> > > > > a single mouse there?
> > > > >
> > > > > This is a PV technology which to me looks like it was
> > > > > rushed through and not only set on by default, but
> > > > > without a way to disable it - apparently on the assumption
> > > > > there's 0 chance it can cause any damage. Now that
> > > > > we do know the chance it's not there, why not go back
> > > > > to the standard interface, and why not give
> > > > > users a chance to enable/disable it?
> > > > > You should be able to disable it with: -device pvpanic,ioport=0
> > >
> > > Doesn't work for me.
> > > Bug that should be fixed. With this command line _STA should return
> > > zero.
> > > Besides, both -device pvpanic and use of ioport=0 to disable it
> > > are completely undocumented.
> >
> > Not the only undocumented thing in QEMU command line :)
> > [snip]
>
> I disagree: -device adds a device, not removes one. It will still be
> present.
>
> I am neutral as to whether qemu-system-x86_64 should have it enabled by
> default or not.

Me too.
> But if we want to suppress it, then -nodefaults should
> disable it.

ACK: that's how we do optional devices that are there by default.

ioport=0 affecting _STA is *not* "removing" the device, it's changing
how the device is exposed to the guest.  No opinion on whether it's a
good idea or not.
> Since libvirt uses that though, it would mean libvirt would
> need to add it back, whether via user's XML domain config or by libvirt
> itself based on some version/etc. heuristics.

Doubt that'll be a problem for libvirt.

[Qemu-devel] [PATCH] don't expose pvpanic device in the UI

[Michael S. Tsirkin]

On Tue, Aug 06, 2013 at 11:56:11AM +0200, Markus Armbruster wrote:
> Andreas Färber <[e-mail]> writes:
> > Am 06.08.2013 10:36, schrieb Gleb Natapov:
> > > On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> > > > On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > > > > If you see a mouse in a room, how likely is it that there's
> > > > > > a single mouse there?
> > > > > >
> > > > > > This is a PV technology which to me looks like it was
> > > > > > rushed through and not only set on by default, but
> > > > > > without a way to disable it - apparently on the assumption
> > > > > > there's 0 chance it can cause any damage. Now that
> > > > > > we do know the chance it's not there, why not go back
> > > > > > to the standard interface, and why not give
> > > > > > users a chance to enable/disable it?
> > > > > > You should be able to disable it with: -device pvpanic,ioport=0
> > > >
> > > > Doesn't work for me.
> > > > Bug that should be fixed. With this command line _STA should return
> > > > zero.
> > > > Besides, both -device pvpanic and use of ioport=0 to disable it
> > > > are completely undocumented.
> > >
> > > Not the only undocumented thing in QEMU command line :)
> > > [snip]
> >
> > I disagree: -device adds a device, not removes one. It will still be
> > present.
> >
> > I am neutral as to whether qemu-system-x86_64 should have it enabled by
> > default or not.
>
> Me too.

In general, me neither.
But we have -device to add a device, it's nicely self-documenting,
We don't have -nodevice to remove a device except the big -nodefaults,
and -nodefaults is not self-documenting, and it's not clear
how it can be made self-documenting.

[Michael S. Tsirkin]

On Tue, Aug 06, 2013 at 11:36:25AM +0300, Gleb Natapov wrote:
> On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> > On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > > If you see a mouse in a room, how likely is it that there's
> > > > a single mouse there?
> > > >
> > > > This is a PV technology which to me looks like it was
> > > > rushed through and not only set on by default, but
> > > > without a way to disable it - apparently on the assumption
> > > > there's 0 chance it can cause any damage. Now that
> > > > we do know the chance it's not there, why not go back
> > > > to the standard interface, and why not give
> > > > users a chance to enable/disable it?
> > > > You should be able to disable it with: -device pvpanic,ioport=0
> >
> > Doesn't work for me.
> > Bug that should be fixed. With this command line _STA should return
> > zero.

It doesn't have anything to do with _STA: device still appears in QOM.
It's a QEMU issue, devices that are added with -device are
documented in -device help and removed by dropping them from
command line. Devices added by default have no way to
be dropped from QOM except -nodefaults.
> > Besides, both -device pvpanic and use of ioport=0 to disable it
> > are completely undocumented.
>
> Not the only undocumented thing in QEMU command line :)

All -device fields are documented with -device help.
This was supposed to be the right way to add
all new devices.
> > BTW pls keep qemu-devel Cc'd.
>
> Haven't touched CC list.
> > > We have different definition of "damage" though.
> >
> > Driver bugs, qemu bugs, OSPM bugs all can cause issues
> > like OS crashes, suspend/resume issues, bad
> > performance ... What's your definition of damage?
>
> None of those cover the case at hand.

Sigh. These examples demonstrate why would user want to run
QEMU without the pvpanic device.
>

[Gleb Natapov]

On Tue, Aug 06, 2013 at 12:21:48PM +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 06, 2013 at 11:36:25AM +0300, Gleb Natapov wrote:
> > On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> > > On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > > > If you see a mouse in a room, how likely is it that there's
> > > > > a single mouse there?
> > > > >
> > > > > This is a PV technology which to me looks like it was
> > > > > rushed through and not only set on by default, but
> > > > > without a way to disable it - apparently on the assumption
> > > > > there's 0 chance it can cause any damage. Now that
> > > > > we do know the chance it's not there, why not go back
> > > > > to the standard interface, and why not give
> > > > > users a chance to enable/disable it?
> > > > > You should be able to disable it with: -device pvpanic,ioport=0
> > >
> > > Doesn't work for me.
> > > Bug that should be fixed. With this command line _STA should return
> > > zero.
>
> It doesn't have anything to do with _STA: device still appears in QOM.
> You said disabled, not removed. So does -global pvpanic,ioport=0
> disables the device for you?
> It's a QEMU issue, devices that are added with -device are
> documented in -device help and removed by dropping them from
> command line. Devices added by default have no way to
> be dropped from QOM except -nodefaults.

Are you saying that because pvpanic is added automatically QEMU -device
help does not print help about it? Why not fix that? What QEMU --help
issues has to do with deciding which devices should or should not be
present by default?
> > > Besides, both -device pvpanic and use of ioport=0 to disable it
> > > are completely undocumented.
> >
> > Not the only undocumented thing in QEMU command line :)
>
> All -device fields are documented with -device help.
> This was supposed to be the right way to add
> all new devices.
> > > BTW pls keep qemu-devel Cc'd.
> >
> > Haven't touched CC list.
> > > > We have different definition of "damage" though.
> > >
> > > Driver bugs, qemu bugs, OSPM bugs all can cause issues
> > > like OS crashes, suspend/resume issues, bad
> > > performance ... What's your definition of damage?
> >
> > None of those cover the case at hand.
>
> Sigh. These examples demonstrate why would user want to run
> QEMU without the pvpanic device.

He can disable it, but chances the device will cause aforementioned
problems are so much smaller (by design mind you) than PV APIC hotplug
device that it makes me wonder why haven't you advocate to make PV APIC
hotplug device to be configurable with -device too.

--
			Gleb.

[Michael S. Tsirkin]

On Tue, Aug 06, 2013 at 12:32:47PM +0300, Gleb Natapov wrote:
> On Tue, Aug 06, 2013 at 12:21:48PM +0300, Michael S. Tsirkin wrote:
> > On Tue, Aug 06, 2013 at 11:36:25AM +0300, Gleb Natapov wrote:
> > > On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> > > > On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > > > > If you see a mouse in a room, how likely is it that there's
> > > > > > a single mouse there?
> > > > > >
> > > > > > This is a PV technology which to me looks like it was
> > > > > > rushed through and not only set on by default, but
> > > > > > without a way to disable it - apparently on the assumption
> > > > > > there's 0 chance it can cause any damage. Now that
> > > > > > we do know the chance it's not there, why not go back
> > > > > > to the standard interface, and why not give
> > > > > > users a chance to enable/disable it?
> > > > > > You should be able to disable it with: -device pvpanic,ioport=0
> > > >
> > > > Doesn't work for me.
> > > > Bug that should be fixed. With this command line _STA should return
> > > > zero.
> >
> > It doesn't have anything to do with _STA: device still appears in QOM.
> > You said disabled, not removed.

I really meant disable adding it.
> So does -global pvpanic,ioport=0
> disables the device for you?

What do you mean by disabled?
> > It's a QEMU issue, devices that are added with -device are
> > documented in -device help and removed by dropping them from
> > command line. Devices added by default have no way to
> > be dropped from QOM except -nodefaults.
>
> Are you saying that because pvpanic is added automatically QEMU -device
> help does not print help about it? Why not fix that? What QEMU --help
> issues has to do with deciding which devices should or should not be
> present by default?

No, I'm saying what I said: that there's no way to remove a device
added by default except -nodefaults, and no way to
find out what does -nodefaults exclude so you
can add things you need back selectively.

We wanted to fix the later issue for a long time, it's
hard to fix - that's why we don't fix that.
Just using -device for everything is a work-around for now.
> > > > Besides, both -device pvpanic and use of ioport=0 to disable it
> > > > are completely undocumented.
> > >
> > > Not the only undocumented thing in QEMU command line :)
> >
> > All -device fields are documented with -device help.
> > This was supposed to be the right way to add
> > all new devices.
> > > > BTW pls keep qemu-devel Cc'd.
> > >
> > > Haven't touched CC list.
> > > > > We have different definition of "damage" though.
> > > >
> > > > Driver bugs, qemu bugs, OSPM bugs all can cause issues
> > > > like OS crashes, suspend/resume issues, bad
> > > > performance ... What's your definition of damage?
> > >
> > > None of those cover the case at hand.
> >
> > Sigh. These examples demonstrate why would user want to run
> > QEMU without the pvpanic device.
>
> He can disable it, but chances the device will cause aforementioned
> problems are so much smaller (by design mind you) than PV APIC hotplug
> device that it makes me wonder why haven't you advocate to make PV APIC
> hotplug device to be configurable with -device too.

This might be a good idea for Q35.
We probably want to keep it as is for PIIX for compatibility.
Then again, different behaviour for Q35/PIIX might confuse people.
>

[Gleb Natapov]

On Tue, Aug 06, 2013 at 01:19:53PM +0300, Michael S. Tsirkin wrote:
> > > It's a QEMU issue, devices that are added with -device are
> > > documented in -device help and removed by dropping them from
> > > command line. Devices added by default have no way to
> > > be dropped from QOM except -nodefaults.
> >
> > Are you saying that because pvpanic is added automatically QEMU -device
> > help does not print help about it? Why not fix that? What QEMU --help
> > issues has to do with deciding which devices should or should not be
> > present by default?
>
> No, I'm saying what I said: that there's no way to remove a device
> added by default except -nodefaults, and no way to
> find out what does -nodefaults exclude so you
> can add things you need back selectively.

And what are the rules that govern device exclusion from -nodefaults
list? Why -nodefaults does not create empty machine?
> We wanted to fix the later issue for a long time, it's
> hard to fix - that's why we don't fix that.
> Just using -device for everything is a work-around for now.

That's workaround that makes usability suffer, not a good compromise.

Anyway the thread is started by assertion that the device breaks guests
which it does not, now we moved to documentation realm which should not
have any say about default machine functionality.
> > > > > Besides, both -device pvpanic and use of ioport=0 to disable it
> > > > > are completely undocumented.
> > > >
> > > > Not the only undocumented thing in QEMU command line :)
> > >
> > > All -device fields are documented with -device help.
> > > This was supposed to be the right way to add
> > > all new devices.
> > > > > BTW pls keep qemu-devel Cc'd.
> > > >
> > > > Haven't touched CC list.
> > > > > > We have different definition of "damage" though.
> > > > >
> > > > > Driver bugs, qemu bugs, OSPM bugs all can cause issues
> > > > > like OS crashes, suspend/resume issues, bad
> > > > > performance ... What's your definition of damage?
> > > >
> > > > None of those cover the case at hand.
> > >
> > > Sigh. These examples demonstrate why would user want to run
> > > QEMU without the pvpanic device.
> >
> > He can disable it, but chances the device will cause aforementioned
> > problems are so much smaller (by design mind you) than PV APIC hotplug
> > device that it makes me wonder why haven't you advocate to make PV APIC
> > hotplug device to be configurable with -device too.
>
> This might be a good idea for Q35.
> We probably want to keep it as is for PIIX for compatibility.
> Then again, different behaviour for Q35/PIIX might confuse people.

There is nothing more confusing for people than find out that -cdrom is
not usable with Q35. Really, after that nothing can surprise Q35 user
any more :)

--
			Gleb.

[Andreas Färber]

Am 06.08.2013 12:44, schrieb Gleb Natapov:
> On Tue, Aug 06, 2013 at 01:19:53PM +0300, Michael S. Tsirkin wrote:
> > > > It's a QEMU issue, devices that are added with -device are
> > > > documented in -device help and removed by dropping them from
> > > > command line. Devices added by default have no way to
> > > > be dropped from QOM except -nodefaults.
> > >
> > > Are you saying that because pvpanic is added automatically QEMU -device
> > > help does not print help about it? Why not fix that? What QEMU --help
> > > issues has to do with deciding which devices should or should not be
> > > present by default?
> >
> > No, I'm saying what I said: that there's no way to remove a device
> > added by default except -nodefaults, and no way to
> > find out what does -nodefaults exclude so you
> > can add things you need back selectively.
>
> And what are the rules that govern device exclusion from -nodefaults
> list? Why -nodefaults does not create empty machine?

We have -M none to create an empty machine.

FWIW -M q35 does not create all Q35 devices, there's -readconfig
docs/q35-chipset.cfg for the rest. The criteria certainly is not
migratability, since ICH9 AHCI (part of -M q35) is unmigratable,
unfortunately.
One practical reason not to create everything via config is that we
cannot create SysBusDevices via -device when they require MMIO mapping
or IRQ setup. For ISADevices such as pvpanic that's not a problem.
Anthony has proposed QOM'ifying MemoryRegions and qemu_irq as solution
to do the wiring-up from command line or config file, but those attempts
got stuck a long time ago.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

[Gleb Natapov]

On Tue, Aug 06, 2013 at 01:03:34PM +0200, Andreas Färber wrote:
> Am 06.08.2013 12:44, schrieb Gleb Natapov:
> > On Tue, Aug 06, 2013 at 01:19:53PM +0300, Michael S. Tsirkin wrote:
> > > > > It's a QEMU issue, devices that are added with -device are
> > > > > documented in -device help and removed by dropping them from
> > > > > command line. Devices added by default have no way to
> > > > > be dropped from QOM except -nodefaults.
> > > >
> > > > Are you saying that because pvpanic is added automatically QEMU -device
> > > > help does not print help about it? Why not fix that? What QEMU --help
> > > > issues has to do with deciding which devices should or should not be
> > > > present by default?
> > >
> > > No, I'm saying what I said: that there's no way to remove a device
> > > added by default except -nodefaults, and no way to
> > > find out what does -nodefaults exclude so you
> > > can add things you need back selectively.
> >
> > And what are the rules that govern device exclusion from -nodefaults
> > list? Why -nodefaults does not create empty machine?
>
> We have -M none to create an empty machine.
>
> FWIW -M q35 does not create all Q35 devices, there's -readconfig
> docs/q35-chipset.cfg for the rest. The criteria certainly is not
> migratability, since ICH9 AHCI (part of -M q35) is unmigratable,
> unfortunately.
> One practical reason not to create everything via config is that we
> cannot create SysBusDevices via -device when they require MMIO mapping
> or IRQ setup. For ISADevices such as pvpanic that's not a problem.
> Anthony has proposed QOM'ifying MemoryRegions and qemu_irq as solution
> to do the wiring-up from command line or config file, but those attempts
> got stuck a long time ago.

But -M creates not only things that cannot be created from a command
line, it includes some default set of devices, so what is the criteria
for those?

--
			Gleb.

[Qemu-devel] [PATCH] don't expose pvpanic device in the UI

[Markus Armbruster]

Gleb Natapov <[e-mail]> writes:
> On Tue, Aug 06, 2013 at 01:03:34PM +0200, Andreas Färber wrote:
> > Am 06.08.2013 12:44, schrieb Gleb Natapov:
> > > On Tue, Aug 06, 2013 at 01:19:53PM +0300, Michael S. Tsirkin wrote:
> > > > > > It's a QEMU issue, devices that are added with -device are
> > > > > > documented in -device help and removed by dropping them from
> > > > > > command line. Devices added by default have no way to
> > > > > > be dropped from QOM except -nodefaults.
> > > > >
> > > > > Are you saying that because pvpanic is added automatically QEMU -device
> > > > > help does not print help about it? Why not fix that? What QEMU --help
> > > > > issues has to do with deciding which devices should or should not be
> > > > > present by default?
> > > >
> > > > No, I'm saying what I said: that there's no way to remove a device
> > > > added by default except -nodefaults, and no way to
> > > > find out what does -nodefaults exclude so you
> > > > can add things you need back selectively.
> > >
> > > And what are the rules that govern device exclusion from -nodefaults
> > > list? Why -nodefaults does not create empty machine?
> >
> > We have -M none to create an empty machine.
> >
> > FWIW -M q35 does not create all Q35 devices, there's -readconfig
> > docs/q35-chipset.cfg for the rest. The criteria certainly is not
> > migratability, since ICH9 AHCI (part of -M q35) is unmigratable,
> > unfortunately.
> > One practical reason not to create everything via config is that we
> > cannot create SysBusDevices via -device when they require MMIO mapping
> > or IRQ setup.

Support wiring up a machine without board code, just configuration has
been the ever-distant goal of the qdev effort.
> > For ISADevices such as pvpanic that's not a problem.
> > Anthony has proposed QOM'ifying MemoryRegions and qemu_irq as solution
> > to do the wiring-up from command line or config file, but those attempts
> > got stuck a long time ago.
>
> But -M creates not only things that cannot be created from a command
> line, it includes some default set of devices, so what is the criteria
> for those?

I'm not aware of defined, coherent criteria.

I can give you descriptive rather than prescriptive, though.  Used to be
"whatever anyone felt users would want".  It's now "whatever has always
been there, plus whatever survives interminable bikeshedding^W^Wvigorous
debate.

[Qemu-devel] [PATCH] don't expose pvpanic device in the UI

[Gleb Natapov]

On Tue, Aug 06, 2013 at 01:48:17PM +0200, Markus Armbruster wrote:
> Gleb Natapov <[e-mail]> writes:
> > On Tue, Aug 06, 2013 at 01:03:34PM +0200, Andreas Färber wrote:
> > > Am 06.08.2013 12:44, schrieb Gleb Natapov:
> > > > On Tue, Aug 06, 2013 at 01:19:53PM +0300, Michael S. Tsirkin wrote:
> > > > > > > It's a QEMU issue, devices that are added with -device are
> > > > > > > documented in -device help and removed by dropping them from
> > > > > > > command line. Devices added by default have no way to
> > > > > > > be dropped from QOM except -nodefaults.
> > > > > > >
> > > > > > Are you saying that because pvpanic is added automatically QEMU -device
> > > > > > help does not print help about it? Why not fix that? What QEMU --help
> > > > > > issues has to do with deciding which devices should or should not be
> > > > > > present by default?
> > > > >
> > > > > No, I'm saying what I said: that there's no way to remove a device
> > > > > added by default except -nodefaults, and no way to
> > > > > find out what does -nodefaults exclude so you
> > > > > can add things you need back selectively.
> > > >
> > > > And what are the rules that govern device exclusion from -nodefaults
> > > > list? Why -nodefaults does not create empty machine?
> > >
> > > We have -M none to create an empty machine.
> > >
> > > FWIW -M q35 does not create all Q35 devices, there's -readconfig
> > > docs/q35-chipset.cfg for the rest. The criteria certainly is not
> > > migratability, since ICH9 AHCI (part of -M q35) is unmigratable,
> > > unfortunately.
> > > One practical reason not to create everything via config is that we
> > > cannot create SysBusDevices via -device when they require MMIO mapping
> > > or IRQ setup.
>
> Support wiring up a machine without board code, just configuration has
> been the ever-distant goal of the qdev effort.
> > > For ISADevices such as pvpanic that's not a problem.
> > > Anthony has proposed QOM'ifying MemoryRegions and qemu_irq as solution
> > > to do the wiring-up from command line or config file, but those attempts
> > > got stuck a long time ago.
> >
> > But -M creates not only things that cannot be created from a command
> > line, it includes some default set of devices, so what is the criteria
> > for those?
>
> I'm not aware of defined, coherent criteria.
>
> I can give you descriptive rather than prescriptive, though.  Used to be
> "whatever anyone felt users would want".  It's now "whatever has always
> been there, plus whatever survives interminable bikeshedding^W^Wvigorous
> debate.
> No need to for ^W! It is like disputes in court: whoever has more
> money wins. In out case whoever has more times wins and I am going on
> vocation, so... :)

[Michael S. Tsirkin]

On Tue, Aug 06, 2013 at 01:03:34PM +0200, Andreas Färber wrote:
> Am 06.08.2013 12:44, schrieb Gleb Natapov:
> > On Tue, Aug 06, 2013 at 01:19:53PM +0300, Michael S. Tsirkin wrote:
> > > > > It's a QEMU issue, devices that are added with -device are
> > > > > documented in -device help and removed by dropping them from
> > > > > command line. Devices added by default have no way to
> > > > > be dropped from QOM except -nodefaults.
> > > >
> > > > Are you saying that because pvpanic is added automatically QEMU -device
> > > > help does not print help about it? Why not fix that? What QEMU --help
> > > > issues has to do with deciding which devices should or should not be
> > > > present by default?
> > >
> > > No, I'm saying what I said: that there's no way to remove a device
> > > added by default except -nodefaults, and no way to
> > > find out what does -nodefaults exclude so you
> > > can add things you need back selectively.
> >
> > And what are the rules that govern device exclusion from -nodefaults
> > list? Why -nodefaults does not create empty machine?
>
> We have -M none to create an empty machine.
>
> FWIW -M q35 does not create all Q35 devices, there's -readconfig
> docs/q35-chipset.cfg for the rest. The criteria certainly is not
> migratability, since ICH9 AHCI (part of -M q35) is unmigratable,
> unfortunately.

Wasn't this fixed recently?
> One practical reason not to create everything via config is that we
> cannot create SysBusDevices via -device when they require MMIO mapping
> or IRQ setup. For ISADevices such as pvpanic that's not a problem.
> Anthony has proposed QOM'ifying MemoryRegions and qemu_irq as solution
> to do the wiring-up from command line or config file, but those attempts
> got stuck a long time ago.
>
> Andreas

[Andreas Färber]

Am 06.08.2013 14:09, schrieb Michael S. Tsirkin:
> On Tue, Aug 06, 2013 at 01:03:34PM +0200, Andreas Färber wrote:
> > FWIW -M q35 does not create all Q35 devices, there's -readconfig
> > docs/q35-chipset.cfg for the rest. The criteria certainly is not
> > migratability, since ICH9 AHCI (part of -M q35) is unmigratable,
> > unfortunately.
>
> Wasn't this fixed recently?

Not in qemu.git at least, that's why I couldn't test PCIe migration with
q35 recently and resorted to picking random devices into i440fx.

Jason had added a VMStateDescription with fields extending my initial
work, but it is .unmigratable = 1 /* Still buggy under I/O load */.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

[Stefan Hajnoczi]

On Tue, Aug 06, 2013 at 02:45:48PM +0200, Andreas Färber wrote:
> Am 06.08.2013 14:09, schrieb Michael S. Tsirkin:
> > On Tue, Aug 06, 2013 at 01:03:34PM +0200, Andreas Färber wrote:
> > > FWIW -M q35 does not create all Q35 devices, there's -readconfig
> > > docs/q35-chipset.cfg for the rest. The criteria certainly is not
> > > migratability, since ICH9 AHCI (part of -M q35) is unmigratable,
> > > unfortunately.
> >
> > Wasn't this fixed recently?
>
> Not in qemu.git at least, that's why I couldn't test PCIe migration with
> q35 recently and resorted to picking random devices into i440fx.
>
> Jason had added a VMStateDescription with fields extending my initial
> work, but it is .unmigratable = 1 /* Still buggy under I/O load */.

I haven't read the whole discussion but the recent AHCI fix I'm aware of
is making FLUSH commands work correctly.  That wasn't specifically aimed
at fixing migration.

Stefan

[Gerd Hoffmann]

Hi,
> And what are the rules that govern device exclusion from -nodefaults
> list? Why -nodefaults does not create empty machine?

"qemu -nodefaults" should give you just cpu + northbridge + southbridge.

"qemu" should give you a usable virtual machine, so qemu adds some
optional devices which are (or used to be) standard in a pc: floppy,
cdrom, serial port, parallel port, vga card, nic.

Sometimes things are a bit odd for historical reasons:

USB controllers are only present in case you ask for them via '-usb' or
add them via '-device', even though they are part of the southbridge.

vmport is there unconditionally.  And I'd rather make that one
configurable instead of adding more hard-coded devices.

cheers,
  Gerd

[Gleb Natapov]

On Tue, Aug 06, 2013 at 01:54:17PM +0200, Gerd Hoffmann wrote:
> Hi,
> > And what are the rules that govern device exclusion from -nodefaults
> > list? Why -nodefaults does not create empty machine?
>
> "qemu -nodefaults" should give you just cpu + northbridge + southbridge.

On modern machine this is everything that most will ever have.
> "qemu" should give you a usable virtual machine, so qemu adds some
> optional devices which are (or used to be) standard in a pc: floppy,
> cdrom, serial port, parallel port, vga card, nic.
>
> Sometimes things are a bit odd for historical reasons:
>
> USB controllers are only present in case you ask for them via '-usb' or
> add them via '-device', even though they are part of the southbridge.
>
> vmport is there unconditionally.  And I'd rather make that one
> configurable instead of adding more hard-coded devices.

There are more, as I already said hotplug device (I am to lazy to search
for more, so I always bring this one).

--
			Gleb.

[Andreas Färber]

Am 06.08.2013 11:32, schrieb Gleb Natapov:
> On Tue, Aug 06, 2013 at 12:21:48PM +0300, Michael S. Tsirkin wrote:
> > On Tue, Aug 06, 2013 at 11:36:25AM +0300, Gleb Natapov wrote:
> > > On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> > > > On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > > > > This is a PV technology which to me looks like it was
> > > > > > rushed through and not only set on by default, but
> > > > > > without a way to disable it - apparently on the assumption
> > > > > > there's 0 chance it can cause any damage. Now that
> > > > > > we do know the chance it's not there, why not go back
> > > > > > to the standard interface, and why not give
> > > > > > users a chance to enable/disable it?
> > > > > > You should be able to disable it with: -device pvpanic,ioport=0
> > > >
> > > > Doesn't work for me.
> > > > Bug that should be fixed. With this command line _STA should return
> > > > zero.
> >
> > It doesn't have anything to do with _STA: device still appears in QOM.
> > You said disabled, not removed. So does -global pvpanic,ioport=0
> > disables the device for you?
> > It's a QEMU issue, devices that are added with -device are
> > documented in -device help and removed by dropping them from
> > command line. Devices added by default have no way to
> > be dropped from QOM except -nodefaults.
>
> Are you saying that because pvpanic is added automatically QEMU -device
> help does not print help about it? Why not fix that? What QEMU --help
> issues has to do with deciding which devices should or should not be
> present by default?

You misunderstand: -device pvpanic,? will document that there is a
numeric port property, which as such is self-documenting. But there's no
way for us to document there that port=0 has special meaning of "disable
this device in ACPI".

Disabling a device usually requires to not include that device (or in
the future to "unrealize" it), which would require some way to suppress
having the device created internally by default. As done for floppy,
serial, etc. devices in x86 IIUC, which are in the same PIO situation as
the pvpanic device, except that they represent physical devices.
Adding some -no-pvpanic switch might be an alternative. And if not done
already, disabling the pvpanic device should definitely be documented
for the man page.

To me this is less a concrete problem with Windows guests but a
conceptual question of how we go about enabling/disabling QEMU devices
in a hopefully consistent way.

Writing a driver does not solve it fully, you'd still need to actively
install that driver, same issue as with virtio. virtio is opt-in, so for
customers not using our VM Driver Pack we offer AHCI as driver-less
alternative.

I wonder if IPMI might be such an alternative in the future, in which
case we should come up with some way to fully disable pvpanic device
creation. CC'ing Corey.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

[Gleb Natapov]

On Tue, Aug 06, 2013 at 12:35:10PM +0200, Andreas Färber wrote:
> Am 06.08.2013 11:32, schrieb Gleb Natapov:
> > On Tue, Aug 06, 2013 at 12:21:48PM +0300, Michael S. Tsirkin wrote:
> > > On Tue, Aug 06, 2013 at 11:36:25AM +0300, Gleb Natapov wrote:
> > > > On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> > > > > On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > > > > > This is a PV technology which to me looks like it was
> > > > > > > rushed through and not only set on by default, but
> > > > > > > without a way to disable it - apparently on the assumption
> > > > > > > there's 0 chance it can cause any damage. Now that
> > > > > > > we do know the chance it's not there, why not go back
> > > > > > > to the standard interface, and why not give
> > > > > > > users a chance to enable/disable it?
> > > > > > You should be able to disable it with: -device pvpanic,ioport=0
> > > > >
> > > > > Doesn't work for me.
> > > > > Bug that should be fixed. With this command line _STA should return
> > > > > zero.
> > >
> > > It doesn't have anything to do with _STA: device still appears in QOM.
> > > You said disabled, not removed. So does -global pvpanic,ioport=0
> > > disables the device for you?
> > > It's a QEMU issue, devices that are added with -device are
> > > documented in -device help and removed by dropping them from
> > > command line. Devices added by default have no way to
> > > be dropped from QOM except -nodefaults.
> >
> > Are you saying that because pvpanic is added automatically QEMU -device
> > help does not print help about it? Why not fix that? What QEMU --help
> > issues has to do with deciding which devices should or should not be
> > present by default?
>
> You misunderstand: -device pvpanic,? will document that there is a
> numeric port property, which as such is self-documenting. But there's no
> Yes, this is how I found it.
> way for us to document there that port=0 has special meaning of "disable
> this device in ACPI".

Adding capability to describe a property should solve that and is a good
idea regardless, no? "pvpanic.ioport=uint16" is not very descriptive.
> Disabling a device usually requires to not include that device (or in
> the future to "unrealize" it), which would require some way to suppress
> having the device created internally by default. As done for floppy,
> serial, etc. devices in x86 IIUC, which are in the same PIO situation as
> the pvpanic device, except that they represent physical devices.
> Adding some -no-pvpanic switch might be an alternative. And if not done
> already, disabling the pvpanic device should definitely be documented
> for the man page.
> We should not add -no-pvpanic! If there is a legitimate use for
> -no-pvpanic we should go with MST suggestion and do not create it by
> default. The question is why would anyone use -no-pvpanic? Legit reason,
> not just "to remove pvpanic".
> To me this is less a concrete problem with Windows guests but a
> conceptual question of how we go about enabling/disabling QEMU devices
> in a hopefully consistent way.

Agree. Now I see that some devises always present (even with -nodefualts)
and some do not. The logic is not clear, but seams to be: if there is
not legit reason to disable device or for stable topology device
placemen need to be controlled, disable it with -nodefualts. In that
case I do not see why pvpanic would not be always present.

The reason this whole thread started with is non issue.
> Writing a driver does not solve it fully, you'd still need to actively
> install that driver, same issue as with virtio. virtio is opt-in, so for
> customers not using our VM Driver Pack we offer AHCI as driver-less
> alternative.

There is no functionality loss without a driver. User is not required
to install drivers.
> I wonder if IPMI might be such an alternative in the future, in which
> case we should come up with some way to fully disable pvpanic device
> creation. CC'ing Corey.

IPMI was considered, to complicated for what was needed.

--
			Gleb.

[Andreas Färber]

Am 06.08.2013 13:00, schrieb Gleb Natapov:
> On Tue, Aug 06, 2013 at 12:35:10PM +0200, Andreas Färber wrote:
> > I wonder if IPMI might be such an alternative in the future, in which
> > case we should come up with some way to fully disable pvpanic device
> > creation. CC'ing Corey.
>
> IPMI was considered, to complicated for what was needed.

Sorry? There's nothing wrong with going for pvpanic as a simple
implementation.

There have been IPMI patchsets on qemu-devel though, and SUSE will be
investigating adding some IPMI support too (not sure if identical to the
scope of those patchsets), whether IPMI is complicated or not. It's a
standard present on physical servers, facilitating unified management of
virtual and physical servers, and there's OpenIPMI as implementation.

My point was, there may be alternative, non-PV implementations to suck
such information out of a guest, IPMI being one example of a management
interface that exists for physical servers. So it's not necessarily
black-or-white, but choices similar to virtio vs. IDE vs. AHCI vs. SCSI.

HTE,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

[Gleb Natapov]

On Tue, Aug 06, 2013 at 01:23:49PM +0200, Andreas Färber wrote:
> Am 06.08.2013 13:00, schrieb Gleb Natapov:
> > On Tue, Aug 06, 2013 at 12:35:10PM +0200, Andreas Färber wrote:
> > > I wonder if IPMI might be such an alternative in the future, in which
> > > case we should come up with some way to fully disable pvpanic device
> > > creation. CC'ing Corey.
> >
> > IPMI was considered, to complicated for what was needed.
>
> Sorry? There's nothing wrong with going for pvpanic as a simple
> implementation.

Sure, why "sorry" then? :) PV has its benefits.
> There have been IPMI patchsets on qemu-devel though, and SUSE will be
> investigating adding some IPMI support too (not sure if identical to the
> scope of those patchsets), whether IPMI is complicated or not. It's a
> standard present on physical servers, facilitating unified management of
> virtual and physical servers, and there's OpenIPMI as implementation.

Of course, there is nothing wrong with implementing IPMI either. Many
problems that IPMI solves are much simpler to solve in virtualized
environment with management software and pvpanic closes one gap
between what IPMI provides and virtual machine management can do.
> My point was, there may be alternative, non-PV implementations to suck
> such information out of a guest, IPMI being one example of a management
> interface that exists for physical servers. So it's not necessarily
> black-or-white, but choices similar to virtio vs. IDE vs. AHCI vs. SCSI.

pvpanic not meant to replace IPMI though.

--
			Gleb.

[Gerd Hoffmann]

Hi,
> > My point was, there may be alternative, non-PV implementations to suck
> > such information out of a guest, IPMI being one example of a management
> > interface that exists for physical servers. So it's not necessarily
> > black-or-white, but choices similar to virtio vs. IDE vs. AHCI vs. SCSI.
>
> pvpanic not meant to replace IPMI though.

You probably don't want use both though, and if you want to pick one of
the two you need a way to turn off pvpanic.

cheers,
  Gerd

[Michael S. Tsirkin]

On Tue, Aug 06, 2013 at 03:00:06PM +0300, Gleb Natapov wrote:
> On Tue, Aug 06, 2013 at 01:23:49PM +0200, Andreas Färber wrote:
> > Am 06.08.2013 13:00, schrieb Gleb Natapov:
> > > On Tue, Aug 06, 2013 at 12:35:10PM +0200, Andreas Färber wrote:
> > > > I wonder if IPMI might be such an alternative in the future, in which
> > > > case we should come up with some way to fully disable pvpanic device
> > > > creation. CC'ing Corey.
> > >
> > > IPMI was considered, to complicated for what was needed.
> >
> > Sorry? There's nothing wrong with going for pvpanic as a simple
> > implementation.
>
> Sure, why "sorry" then? :) PV has its benefits.

PV always seems easier. It sometimes becomes a maintainance problem
down the way though.
> > There have been IPMI patchsets on qemu-devel though, and SUSE will be
> > investigating adding some IPMI support too (not sure if identical to the
> > scope of those patchsets), whether IPMI is complicated or not. It's a
> > standard present on physical servers, facilitating unified management of
> > virtual and physical servers, and there's OpenIPMI as implementation.
>
> Of course, there is nothing wrong with implementing IPMI either. Many
> problems that IPMI solves are much simpler to solve in virtualized
> environment with management software and pvpanic closes one gap
> between what IPMI provides and virtual machine management can do.
> > My point was, there may be alternative, non-PV implementations to suck
> > such information out of a guest, IPMI being one example of a management
> > interface that exists for physical servers. So it's not necessarily
> > black-or-white, but choices similar to virtio vs. IDE vs. AHCI vs. SCSI.
>
> pvpanic not meant to replace IPMI though.

But will you want pvpanic if you have IPMI?
>

[Gleb Natapov]

On Tue, Aug 06, 2013 at 03:05:52PM +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 06, 2013 at 03:00:06PM +0300, Gleb Natapov wrote:
> > On Tue, Aug 06, 2013 at 01:23:49PM +0200, Andreas Färber wrote:
> > > Am 06.08.2013 13:00, schrieb Gleb Natapov:
> > > > On Tue, Aug 06, 2013 at 12:35:10PM +0200, Andreas Färber wrote:
> > > > > I wonder if IPMI might be such an alternative in the future, in which
> > > > > case we should come up with some way to fully disable pvpanic device
> > > > > creation. CC'ing Corey.
> > > >
> > > > IPMI was considered, to complicated for what was needed.
> > >
> > > Sorry? There's nothing wrong with going for pvpanic as a simple
> > > implementation.
> >
> > Sure, why "sorry" then? :) PV has its benefits.
>
> PV always seems easier. It sometimes becomes a maintainance problem
> down the way though.

If it is modelled as proper device, why? What PV devices we have that are pain?
> > > There have been IPMI patchsets on qemu-devel though, and SUSE will be
> > > investigating adding some IPMI support too (not sure if identical to the
> > > scope of those patchsets), whether IPMI is complicated or not. It's a
> > > standard present on physical servers, facilitating unified management of
> > > virtual and physical servers, and there's OpenIPMI as implementation.
> >
> > Of course, there is nothing wrong with implementing IPMI either. Many
> > problems that IPMI solves are much simpler to solve in virtualized
> > environment with management software and pvpanic closes one gap
> > between what IPMI provides and virtual machine management can do.
> > > My point was, there may be alternative, non-PV implementations to suck
> > > such information out of a guest, IPMI being one example of a management
> > > interface that exists for physical servers. So it's not necessarily
> > > black-or-white, but choices similar to virtio vs. IDE vs. AHCI vs. SCSI.
> >
> > pvpanic not meant to replace IPMI though.
>
> But will you want pvpanic if you have IPMI?

Why not? They report to different components.

--
			Gleb.

[Qemu-devel] [PATCH] don't expose pvpanic device in the UI

[Andreas Färber]

Am 06.08.2013 14:00, schrieb Gleb Natapov:
> On Tue, Aug 06, 2013 at 01:23:49PM +0200, Andreas Färber wrote:
> > Am 06.08.2013 13:00, schrieb Gleb Natapov:
> > > On Tue, Aug 06, 2013 at 12:35:10PM +0200, Andreas Färber wrote:
> > > > I wonder if IPMI might be such an alternative in the future, in which
> > > > case we should come up with some way to fully disable pvpanic device
> > > > creation. CC'ing Corey.
> > >
> > > IPMI was considered, to complicated for what was needed.
> >
> > Sorry? There's nothing wrong with going for pvpanic as a simple
> > implementation.
>
> Sure, why "sorry" then? :)

Because I don't understand what IPMI being too complicated has to do
with me saying that because, for example, a future IPMI emulation may be
able to fulfill the same function, we may want to disable pvpanic at
that point. :)

[...]
> > My point was, there may be alternative, non-PV implementations to suck
> > such information out of a guest, IPMI being one example of a management
> > interface that exists for physical servers. So it's not necessarily
> > black-or-white, but choices similar to virtio vs. IDE vs. AHCI vs. SCSI.
>
> pvpanic not meant to replace IPMI though.

That's a matter of definition: Is vmmouse meant to replace USB tablets?
They have similar functions for the user but are implemented in a way
they can coexist in software.

It is handy to have vmmouse enabled if my guest X11 and VNC have support
for vmmouse or ignore it, but if my guest has broken vmmouse drivers
then it may well be handy to be able to turn off vmmouse emulation in
QEMU rather than insisting that all PV interfaces always stay enabled.
Question is how to do that best, beyond the pvpanic-specific ioport=0.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

[Michael S. Tsirkin]

On Tue, Aug 06, 2013 at 02:00:35PM +0300, Gleb Natapov wrote:
> On Tue, Aug 06, 2013 at 12:35:10PM +0200, Andreas Färber wrote:
> > Am 06.08.2013 11:32, schrieb Gleb Natapov:
> > > On Tue, Aug 06, 2013 at 12:21:48PM +0300, Michael S. Tsirkin wrote:
> > > > On Tue, Aug 06, 2013 at 11:36:25AM +0300, Gleb Natapov wrote:
> > > > > On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> > > > > > On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > > > > >> This is a PV technology which to me looks like it was
> > > > > > >> rushed through and not only set on by default, but
> > > > > > >> without a way to disable it - apparently on the assumption
> > > > > > >> there's 0 chance it can cause any damage. Now that
> > > > > > >> we do know the chance it's not there, why not go back
> > > > > > >> to the standard interface, and why not give
> > > > > > >> users a chance to enable/disable it?
> > > > > > > You should be able to disable it with: -device pvpanic,ioport=0
> > > > > >
> > > > > > Doesn't work for me.
> > > > > > Bug that should be fixed. With this command line _STA should return
> > > > > > zero.
> > > >
> > > > It doesn't have anything to do with _STA: device still appears in QOM.
> > > > You said disabled, not removed. So does -global pvpanic,ioport=0
> > > > disables the device for you?
> > > > It's a QEMU issue, devices that are added with -device are
> > > > documented in -device help and removed by dropping them from
> > > > command line. Devices added by default have no way to
> > > > be dropped from QOM except -nodefaults.
> > >
> > > Are you saying that because pvpanic is added automatically QEMU -device
> > > help does not print help about it? Why not fix that? What QEMU --help
> > > issues has to do with deciding which devices should or should not be
> > > present by default?
> >
> > You misunderstand: -device pvpanic,? will document that there is a
> > numeric port property, which as such is self-documenting. But there's no
> > Yes, this is how I found it.
> > way for us to document there that port=0 has special meaning of "disable
> > this device in ACPI".
>
> Adding capability to describe a property should solve that and is a good
> idea regardless, no? "pvpanic.ioport=uint16" is not very descriptive.
> > Disabling a device usually requires to not include that device (or in
> > the future to "unrealize" it), which would require some way to suppress
> > having the device created internally by default. As done for floppy,
> > serial, etc. devices in x86 IIUC, which are in the same PIO situation as
> > the pvpanic device, except that they represent physical devices.
> > Adding some -no-pvpanic switch might be an alternative. And if not done
> > already, disabling the pvpanic device should definitely be documented
> > for the man page.
> > We should not add -no-pvpanic! If there is a legitimate use for
> > -no-pvpanic we should go with MST suggestion and do not create it by
> > default. The question is why would anyone use -no-pvpanic? Legit reason,
> > not just "to remove pvpanic".

To be able to emulate a real hardware system without any PV devices.
I think it's a reasonable requirement.
> > To me this is less a concrete problem with Windows guests but a
> > conceptual question of how we go about enabling/disabling QEMU devices
> > in a hopefully consistent way.
>
> Agree. Now I see that some devises always present (even with -nodefualts)
> and some do not. The logic is not clear, but seams to be: if there is
> not legit reason to disable device or for stable topology device
> placemen need to be controlled, disable it with -nodefualts. In that
> case I do not see why pvpanic would not be always present.
>
> The reason this whole thread started with is non issue.
> > Writing a driver does not solve it fully, you'd still need to actively
> > install that driver, same issue as with virtio. virtio is opt-in, so for
> > customers not using our VM Driver Pack we offer AHCI as driver-less
> > alternative.
>
> There is no functionality loss without a driver. User is not required
> to install drivers.
> > I wonder if IPMI might be such an alternative in the future, in which
> > case we should come up with some way to fully disable pvpanic device
> > creation. CC'ing Corey.
>
> IPMI was considered, to complicated for what was needed.

[Gleb Natapov]

On Tue, Aug 06, 2013 at 03:08:32PM +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 06, 2013 at 02:00:35PM +0300, Gleb Natapov wrote:
> > On Tue, Aug 06, 2013 at 12:35:10PM +0200, Andreas Färber wrote:
> > > Am 06.08.2013 11:32, schrieb Gleb Natapov:
> > > > On Tue, Aug 06, 2013 at 12:21:48PM +0300, Michael S. Tsirkin wrote:
> > > > > On Tue, Aug 06, 2013 at 11:36:25AM +0300, Gleb Natapov wrote:
> > > > > > On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> > > > > > > On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > > > > >>> This is a PV technology which to me looks like it was
> > > > > > >>> rushed through and not only set on by default, but
> > > > > > >>> without a way to disable it - apparently on the assumption
> > > > > > >>> there's 0 chance it can cause any damage. Now that
> > > > > > >>> we do know the chance it's not there, why not go back
> > > > > > >>> to the standard interface, and why not give
> > > > > > >>> users a chance to enable/disable it?
> > > > > > >> You should be able to disable it with: -device pvpanic,ioport=0
> > > > > > >
> > > > > > > Doesn't work for me.
> > > > > > Bug that should be fixed. With this command line _STA should return
> > > > > > zero.
> > > > >
> > > > > It doesn't have anything to do with _STA: device still appears in QOM.
> > > > > You said disabled, not removed. So does -global pvpanic,ioport=0
> > > > > disables the device for you?
> > > > > It's a QEMU issue, devices that are added with -device are
> > > > > documented in -device help and removed by dropping them from
> > > > > command line. Devices added by default have no way to
> > > > > be dropped from QOM except -nodefaults.
> > > >
> > > > Are you saying that because pvpanic is added automatically QEMU -device
> > > > help does not print help about it? Why not fix that? What QEMU --help
> > > > issues has to do with deciding which devices should or should not be
> > > > present by default?
> > >
> > > You misunderstand: -device pvpanic,? will document that there is a
> > > numeric port property, which as such is self-documenting. But there's no
> > > Yes, this is how I found it.
> > > way for us to document there that port=0 has special meaning of "disable
> > > this device in ACPI".
> >
> > Adding capability to describe a property should solve that and is a good
> > idea regardless, no? "pvpanic.ioport=uint16" is not very descriptive.
> > > Disabling a device usually requires to not include that device (or in
> > > the future to "unrealize" it), which would require some way to suppress
> > > having the device created internally by default. As done for floppy,
> > > serial, etc. devices in x86 IIUC, which are in the same PIO situation as
> > > the pvpanic device, except that they represent physical devices.
> > > Adding some -no-pvpanic switch might be an alternative. And if not done
> > > already, disabling the pvpanic device should definitely be documented
> > > for the man page.
> > > We should not add -no-pvpanic! If there is a legitimate use for
> > > -no-pvpanic we should go with MST suggestion and do not create it by
> > > default. The question is why would anyone use -no-pvpanic? Legit reason,
> > > not just "to remove pvpanic".
>
> To be able to emulate a real hardware system without any PV devices.
> I think it's a reasonable requirement.

Qemu is so far from able to do so that I do not consider it such.

--
			Gleb.

[Hu Tao]

On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > If you see a mouse in a room, how likely is it that there's
> > > a single mouse there?
> > >
> > > This is a PV technology which to me looks like it was
> > > rushed through and not only set on by default, but
> > > without a way to disable it - apparently on the assumption
> > > there's 0 chance it can cause any damage. Now that
> > > we do know the chance it's not there, why not go back
> > > to the standard interface, and why not give
> > > users a chance to enable/disable it?
> > > You should be able to disable it with: -device pvpanic,ioport=0
>
> Doesn't work for me.

The internal pvpanic can be disabled by -global pvpanic.ioport=0.
-device pvpanic,ioport=0 just adds another pvpanic device.

[Gleb Natapov]

On Tue, Aug 06, 2013 at 05:26:46PM +0800, Hu Tao wrote:
> On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> > On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > > If you see a mouse in a room, how likely is it that there's
> > > > a single mouse there?
> > > >
> > > > This is a PV technology which to me looks like it was
> > > > rushed through and not only set on by default, but
> > > > without a way to disable it - apparently on the assumption
> > > > there's 0 chance it can cause any damage. Now that
> > > > we do know the chance it's not there, why not go back
> > > > to the standard interface, and why not give
> > > > users a chance to enable/disable it?
> > > > You should be able to disable it with: -device pvpanic,ioport=0
> >
> > Doesn't work for me.
>
> The internal pvpanic can be disabled by -global pvpanic.ioport=0.
> -device pvpanic,ioport=0 just adds another pvpanic device.
> Yeah, good point.

[Michael S. Tsirkin]

On Tue, Aug 06, 2013 at 12:29:27PM +0300, Gleb Natapov wrote:
> On Tue, Aug 06, 2013 at 05:26:46PM +0800, Hu Tao wrote:
> > On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> > > On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > > > If you see a mouse in a room, how likely is it that there's
> > > > > a single mouse there?
> > > > >
> > > > > This is a PV technology which to me looks like it was
> > > > > rushed through and not only set on by default, but
> > > > > without a way to disable it - apparently on the assumption
> > > > > there's 0 chance it can cause any damage. Now that
> > > > > we do know the chance it's not there, why not go back
> > > > > to the standard interface, and why not give
> > > > > users a chance to enable/disable it?
> > > > > You should be able to disable it with: -device pvpanic,ioport=0
> > >
> > > Doesn't work for me.
> >
> > The internal pvpanic can be disabled by -global pvpanic.ioport=0.
> > -device pvpanic,ioport=0 just adds another pvpanic device.
> > Yeah, good point.

I tried this, this doesn't remove the device - merely sets the
port to 0.
>

[Gleb Natapov]

On Tue, Aug 06, 2013 at 01:13:17PM +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 06, 2013 at 12:29:27PM +0300, Gleb Natapov wrote:
> > On Tue, Aug 06, 2013 at 05:26:46PM +0800, Hu Tao wrote:
> > > On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> > > > On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > > > > If you see a mouse in a room, how likely is it that there's
> > > > > > a single mouse there?
> > > > > >
> > > > > > This is a PV technology which to me looks like it was
> > > > > > rushed through and not only set on by default, but
> > > > > > without a way to disable it - apparently on the assumption
> > > > > > there's 0 chance it can cause any damage. Now that
> > > > > > we do know the chance it's not there, why not go back
> > > > > > to the standard interface, and why not give
> > > > > > users a chance to enable/disable it?
> > > > > > You should be able to disable it with: -device pvpanic,ioport=0
> > > >
> > > > Doesn't work for me.
> > >
> > > The internal pvpanic can be disabled by -global pvpanic.ioport=0.
> > > -device pvpanic,ioport=0 just adds another pvpanic device.
> > > Yeah, good point.
>
> I tried this, this doesn't remove the device - merely sets the
> port to 0.

That's the point. And _STA will report it as disabled. You asked if the device
can be enable/disable above, not removed. It can.

--
			Gleb.

[Michael S. Tsirkin]

On Tue, Aug 06, 2013 at 01:14:14PM +0300, Gleb Natapov wrote:
> On Tue, Aug 06, 2013 at 01:13:17PM +0300, Michael S. Tsirkin wrote:
> > On Tue, Aug 06, 2013 at 12:29:27PM +0300, Gleb Natapov wrote:
> > > On Tue, Aug 06, 2013 at 05:26:46PM +0800, Hu Tao wrote:
> > > > On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> > > > > On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > > > > > If you see a mouse in a room, how likely is it that there's
> > > > > > > a single mouse there?
> > > > > > > 
> > > > > > > This is a PV technology which to me looks like it was
> > > > > > > rushed through and not only set on by default, but
> > > > > > > without a way to disable it - apparently on the assumption
> > > > > > > there's 0 chance it can cause any damage. Now that
> > > > > > > we do know the chance it's not there, why not go back
> > > > > > > to the standard interface, and why not give
> > > > > > > users a chance to enable/disable it?
> > > > > > You should be able to disable it with: -device pvpanic,ioport=0
> > > > >
> > > > > Doesn't work for me.
> > > >
> > > > The internal pvpanic can be disabled by -global pvpanic.ioport=0.
> > > > -device pvpanic,ioport=0 just adds another pvpanic device.
> > > > Yeah, good point.
> >
> > I tried this, this doesn't remove the device - merely sets the
> > port to 0.
>
> That's the point. And _STA will report it as disabled.

In ACPI? Why have it at all?
> You asked if the device
> can be enable/disable above, not removed. It can.

I really meant QOM/QMP. _STA is only seen by OSPM.
>

[Gleb Natapov]

On Tue, Aug 06, 2013 at 01:23:26PM +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 06, 2013 at 01:14:14PM +0300, Gleb Natapov wrote:
> > On Tue, Aug 06, 2013 at 01:13:17PM +0300, Michael S. Tsirkin wrote:
> > > On Tue, Aug 06, 2013 at 12:29:27PM +0300, Gleb Natapov wrote:
> > > > On Tue, Aug 06, 2013 at 05:26:46PM +0800, Hu Tao wrote:
> > > > > On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
> > > > > > On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
> > > > > > > > If you see a mouse in a room, how likely is it that there's
> > > > > > > > a single mouse there?
> > > > > > > > 
> > > > > > > > This is a PV technology which to me looks like it was
> > > > > > > > rushed through and not only set on by default, but
> > > > > > > > without a way to disable it - apparently on the assumption
> > > > > > > > there's 0 chance it can cause any damage. Now that
> > > > > > > > we do know the chance it's not there, why not go back
> > > > > > > > to the standard interface, and why not give
> > > > > > > > users a chance to enable/disable it?
> > > > > > > You should be able to disable it with: -device pvpanic,ioport=0
> > > > > >
> > > > > > Doesn't work for me.
> > > > >
> > > > > The internal pvpanic can be disabled by -global pvpanic.ioport=0.
> > > > > -device pvpanic,ioport=0 just adds another pvpanic device.
> > > > > Yeah, good point.
> > >
> > > I tried this, this doesn't remove the device - merely sets the
> > > port to 0.
> >
> > That's the point. And _STA will report it as disabled.
>
> In ACPI? Why have it at all?

You can put whatever you want into ACPI as long as _STA returns disabled
status. What's the problem?
> > You asked if the device
> > can be enable/disable above, not removed. It can.
>
> I really meant QOM/QMP. _STA is only seen by OSPM.

Then you should have said "removed". No you cannot, this is not the only
such device. I do not see why would you want to though.

--
			Gleb.

[Michael S. Tsirkin]

On Mon, Aug 05, 2013 at 11:16:17AM +0300, Gleb Natapov wrote:
> On Mon, Aug 05, 2013 at 11:10:55AM +0300, Michael S. Tsirkin wrote:
> > On Mon, Aug 05, 2013 at 03:47:23PM +0800, Hu Tao wrote:
> > > pvpanic device is an internal default device in qemu. It may cause
> > > problem when upgrading qemu from a version without pvpanic.
> > >
> > > for example: in Windows(let's say XP) the Device manager will open a
> > > "new device" wizard and the device will appear as an unrecognized
> > > device.  On a cluster with hundreds of such VMs, If that cluster has
> > > a health monitoring service it may show all the VMs in a "not healthy"
> > > state.
> > >
> > > This patch is a workaround to not show pvpanic in UI to avoid the
> > > problem in Windows.
> > >
> > > Cc: Marcel Apfelbaum <[e-mail]>
> > > Cc: "Michael S. Tsirkin" <[e-mail]>
> > > Cc: Paolo Bonzini <[e-mail]>
> > > Cc: Gerd Hoffmann <[e-mail]>
> > > Cc: Eric Blake <[e-mail]>
> > > Cc: "Daniel P. Berrange" <[e-mail]>
> > > Cc: Andreas Färber <[e-mail]>
> > > Signed-off-by: Hu Tao <[e-mail]>
> >
> > Quoting from this discussion:
> > > That may "fix" the issue of a windows guest showing the yellow ! mark,
> > > but what if, down the road, someone writes an actual windows driver that
> > > is aware of that port and how to make a windows BSOD write a panic
> > > notification to the port?  How does a user go about installing such a
> > > driver if the device is not exposed in the user interface list of
> > > devices?
> >
> > I think the correct way to address this is:
> > - don't create the device by default, only when -device pvpanic is
> >   present
> > - teach management to supply said -device pvpanic for guests which
> >   support the pvpanic device
>
> That's just pushing the problem elsewhere. How management suppose to know if
> guest support pvpanic device?

Same as any PV device really. It's exactly the same problem
as with virtio: user configures the XML properly.
> What if initially guest did not have a
> driver, but the it was installed?

You can reconfigure XML and reboot.
> If device appears for old machine
> models this is bug, otherwise I fail to see any problem.

Care answering the question that Eric Blake posed (above)?
>

[Gleb Natapov]

On Mon, Aug 05, 2013 at 12:18:26PM +0300, Michael S. Tsirkin wrote:
> On Mon, Aug 05, 2013 at 11:16:17AM +0300, Gleb Natapov wrote:
> > On Mon, Aug 05, 2013 at 11:10:55AM +0300, Michael S. Tsirkin wrote:
> > > On Mon, Aug 05, 2013 at 03:47:23PM +0800, Hu Tao wrote:
> > > > pvpanic device is an internal default device in qemu. It may cause
> > > > problem when upgrading qemu from a version without pvpanic.
> > > >
> > > > for example: in Windows(let's say XP) the Device manager will open a
> > > > "new device" wizard and the device will appear as an unrecognized
> > > > device.  On a cluster with hundreds of such VMs, If that cluster has
> > > > a health monitoring service it may show all the VMs in a "not healthy"
> > > > state.
> > > >
> > > > This patch is a workaround to not show pvpanic in UI to avoid the
> > > > problem in Windows.
> > > >
> > > > Cc: Marcel Apfelbaum <[e-mail]>
> > > > Cc: "Michael S. Tsirkin" <[e-mail]>
> > > > Cc: Paolo Bonzini <[e-mail]>
> > > > Cc: Gerd Hoffmann <[e-mail]>
> > > > Cc: Eric Blake <[e-mail]>
> > > > Cc: "Daniel P. Berrange" <[e-mail]>
> > > > Cc: Andreas Färber <[e-mail]>
> > > > Signed-off-by: Hu Tao <[e-mail]>
> > >
> > > Quoting from this discussion:
> > > > That may "fix" the issue of a windows guest showing the yellow ! mark,
> > > > but what if, down the road, someone writes an actual windows driver that
> > > > is aware of that port and how to make a windows BSOD write a panic
> > > > notification to the port?  How does a user go about installing such a
> > > > driver if the device is not exposed in the user interface list of
> > > > devices?
> > >
> > > I think the correct way to address this is:
> > > - don't create the device by default, only when -device pvpanic is
> > >   present
> > > - teach management to supply said -device pvpanic for guests which
> > >   support the pvpanic device
> >
> > That's just pushing the problem elsewhere. How management suppose to know if
> > guest support pvpanic device?
>
> Same as any PV device really. It's exactly the same problem
> as with virtio: user configures the XML properly.

Virtio has alternatives.
> > What if initially guest did not have a
> > driver, but the it was installed?
>
> You can reconfigure XML and reboot.

Will it cause Windows reactivation? Maybe after adding several devices?
> > If device appears for old machine
> > models this is bug, otherwise I fail to see any problem.
>
> Care answering the question that Eric Blake posed (above)?

Which one? About how to install driver if device is not shown in the
gui? I suppose clicking on device driver installer should do the job.

--
			Gleb.

[Michael S. Tsirkin]

On Mon, Aug 05, 2013 at 12:20:44PM +0300, Gleb Natapov wrote:
> On Mon, Aug 05, 2013 at 12:18:26PM +0300, Michael S. Tsirkin wrote:
> > On Mon, Aug 05, 2013 at 11:16:17AM +0300, Gleb Natapov wrote:
> > > On Mon, Aug 05, 2013 at 11:10:55AM +0300, Michael S. Tsirkin wrote:
> > > > On Mon, Aug 05, 2013 at 03:47:23PM +0800, Hu Tao wrote:
> > > > > pvpanic device is an internal default device in qemu. It may cause
> > > > > problem when upgrading qemu from a version without pvpanic.
> > > > >
> > > > > for example: in Windows(let's say XP) the Device manager will open a
> > > > > "new device" wizard and the device will appear as an unrecognized
> > > > > device.  On a cluster with hundreds of such VMs, If that cluster has
> > > > > a health monitoring service it may show all the VMs in a "not healthy"
> > > > > state.
> > > > >
> > > > > This patch is a workaround to not show pvpanic in UI to avoid the
> > > > > problem in Windows.
> > > > >
> > > > > Cc: Marcel Apfelbaum <[e-mail]>
> > > > > Cc: "Michael S. Tsirkin" <[e-mail]>
> > > > > Cc: Paolo Bonzini <[e-mail]>
> > > > > Cc: Gerd Hoffmann <[e-mail]>
> > > > > Cc: Eric Blake <[e-mail]>
> > > > > Cc: "Daniel P. Berrange" <[e-mail]>
> > > > > Cc: Andreas Färber <[e-mail]>
> > > > > Signed-off-by: Hu Tao <[e-mail]>
> > > >
> > > > Quoting from this discussion:
> > > > > That may "fix" the issue of a windows guest showing the yellow ! mark,
> > > > > but what if, down the road, someone writes an actual windows driver that
> > > > > is aware of that port and how to make a windows BSOD write a panic
> > > > > notification to the port?  How does a user go about installing such a
> > > > > driver if the device is not exposed in the user interface list of
> > > > > devices?
> > > >
> > > > I think the correct way to address this is:
> > > > - don't create the device by default, only when -device pvpanic is
> > > >   present
> > > > - teach management to supply said -device pvpanic for guests which
> > > >   support the pvpanic device
> > >
> > > That's just pushing the problem elsewhere. How management suppose to know if
> > > guest support pvpanic device?
> >
> > Same as any PV device really. It's exactly the same problem
> > as with virtio: user configures the XML properly.
>
> Virtio has alternatives.

I don't see why does it matter. In any case, only
*some* virtio devices have alternatives.
What about the balloon device? VIRTIO_9P? There are more examples.
What about e.g. ivshmem?
> > > What if initially guest did not have a
> > > driver, but the it was installed?
> >
> > You can reconfigure XML and reboot.
>
> Will it cause Windows reactivation? Maybe after adding several devices?

I don't think it will.
https://en.wikipedia.org/wiki/Microsoft_Product_Activation
says:
    Display adapter
    SCSI adapter
    IDE adapter
    Network adapter MAC address
    RAM amount range (e.g. 0-512 MB)
    Processor type and serial number
    Hard drive device and volume serial number
    Optical drive (e.g. DVD-ROM)

As you see we do let people change many parameters
that do affect activation.
> > > If device appears for old machine
> > > models this is bug, otherwise I fail to see any problem.
> >
> > Care answering the question that Eric Blake posed (above)?
>
> Which one? About how to install driver if device is not shown in the
> gui? I suppose clicking on device driver installer should do the job.

Did you try?
I think this requires an EXE installer. Being prompted for driver makes it
possible to install one from INF.
How about changing drivers? Selecting one driver from multiple variants?
How do you disable it if it's causing trouble, or for testing?
>

[Gleb Natapov]

On Mon, Aug 05, 2013 at 06:03:34PM +0300, Michael S. Tsirkin wrote:
> On Mon, Aug 05, 2013 at 12:20:44PM +0300, Gleb Natapov wrote:
> > On Mon, Aug 05, 2013 at 12:18:26PM +0300, Michael S. Tsirkin wrote:
> > > On Mon, Aug 05, 2013 at 11:16:17AM +0300, Gleb Natapov wrote:
> > > > On Mon, Aug 05, 2013 at 11:10:55AM +0300, Michael S. Tsirkin wrote:
> > > > > On Mon, Aug 05, 2013 at 03:47:23PM +0800, Hu Tao wrote:
> > > > > > pvpanic device is an internal default device in qemu. It may cause
> > > > > > problem when upgrading qemu from a version without pvpanic.
> > > > > >
> > > > > > for example: in Windows(let's say XP) the Device manager will open a
> > > > > > "new device" wizard and the device will appear as an unrecognized
> > > > > > device.  On a cluster with hundreds of such VMs, If that cluster has
> > > > > > a health monitoring service it may show all the VMs in a "not healthy"
> > > > > > state.
> > > > > >
> > > > > > This patch is a workaround to not show pvpanic in UI to avoid the
> > > > > > problem in Windows.
> > > > > >
> > > > > > Cc: Marcel Apfelbaum <[e-mail]>
> > > > > > Cc: "Michael S. Tsirkin" <[e-mail]>
> > > > > > Cc: Paolo Bonzini <[e-mail]>
> > > > > > Cc: Gerd Hoffmann <[e-mail]>
> > > > > > Cc: Eric Blake <[e-mail]>
> > > > > > Cc: "Daniel P. Berrange" <[e-mail]>
> > > > > > Cc: Andreas Färber <[e-mail]>
> > > > > > Signed-off-by: Hu Tao <[e-mail]>
> > > > >
> > > > > Quoting from this discussion:
> > > > > > That may "fix" the issue of a windows guest showing the yellow ! mark,
> > > > > > but what if, down the road, someone writes an actual windows driver that
> > > > > > is aware of that port and how to make a windows BSOD write a panic
> > > > > > notification to the port?  How does a user go about installing such a
> > > > > > driver if the device is not exposed in the user interface list of
> > > > > > devices?
> > > > >
> > > > > I think the correct way to address this is:
> > > > > - don't create the device by default, only when -device pvpanic is
> > > > >   present
> > > > > - teach management to supply said -device pvpanic for guests which
> > > > >   support the pvpanic device
> > > >
> > > > That's just pushing the problem elsewhere. How management suppose to know if
> > > > guest support pvpanic device?
> > >
> > > Same as any PV device really. It's exactly the same problem
> > > as with virtio: user configures the XML properly.
> >
> > Virtio has alternatives.
>
> I don't see why does it matter. In any case, only
> *some* virtio devices have alternatives.
> What about the balloon device? VIRTIO_9P? There are more examples.
> What about e.g. ivshmem?

They take very limited pci resources and/or provide functionality that
should not be available for all guests. We do provide ACPI hotplug
device unconditionally.
> > > > What if initially guest did not have a
> > > > driver, but the it was installed?
> > >
> > > You can reconfigure XML and reboot.
> >
> > Will it cause Windows reactivation? Maybe after adding several devices?
>
> I don't think it will.
> https://en.wikipedia.org/wiki/Microsoft_Product_Activation
> says:
>     Display adapter
>     SCSI adapter
>     IDE adapter
>     Network adapter MAC address
>     RAM amount range (e.g. 0-512 MB)
>     Processor type and serial number
>     Hard drive device and volume serial number
>     Optical drive (e.g. DVD-ROM)
>
> As you see we do let people change many parameters
> that do affect activation.
> By editing XML user can shoot himself in the foot, we should not prevent
> that. It should not be required though.
> > > > If device appears for old machine
> > > > models this is bug, otherwise I fail to see any problem.
> > >
> > > Care answering the question that Eric Blake posed (above)?
> >
> > Which one? About how to install driver if device is not shown in the
> > gui? I suppose clicking on device driver installer should do the job.
>
> Did you try?

I do not see any reasonable doubt to even question the possibility :)
But see Paolo's reply.
> I think this requires an EXE installer. Being prompted for driver makes it
> possible to install one from INF.
> AFAIK INF is clickable file, but regardless I do not think even _this_
> patch is needed. What is needed is Windows driver for the device.
> How about changing drivers? Selecting one driver from multiple variants?
> How do you disable it if it's causing trouble, or for testing?

Again, as Paolo says you can see it if you really wish.

--
			Gleb.

[Michael S. Tsirkin]

On Mon, Aug 05, 2013 at 07:04:22PM +0300, Gleb Natapov wrote:
> On Mon, Aug 05, 2013 at 06:03:34PM +0300, Michael S. Tsirkin wrote:
> > On Mon, Aug 05, 2013 at 12:20:44PM +0300, Gleb Natapov wrote:
> > > On Mon, Aug 05, 2013 at 12:18:26PM +0300, Michael S. Tsirkin wrote:
> > > > On Mon, Aug 05, 2013 at 11:16:17AM +0300, Gleb Natapov wrote:
> > > > > On Mon, Aug 05, 2013 at 11:10:55AM +0300, Michael S. Tsirkin wrote:
> > > > > > On Mon, Aug 05, 2013 at 03:47:23PM +0800, Hu Tao wrote:
> > > > > > > pvpanic device is an internal default device in qemu. It may cause
> > > > > > > problem when upgrading qemu from a version without pvpanic.
> > > > > > > 
> > > > > > > for example: in Windows(let's say XP) the Device manager will open a
> > > > > > > "new device" wizard and the device will appear as an unrecognized
> > > > > > > device.  On a cluster with hundreds of such VMs, If that cluster has
> > > > > > > a health monitoring service it may show all the VMs in a "not healthy"
> > > > > > > state.
> > > > > > > 
> > > > > > > This patch is a workaround to not show pvpanic in UI to avoid the
> > > > > > > problem in Windows.
> > > > > > > 
> > > > > > > Cc: Marcel Apfelbaum <[e-mail]>
> > > > > > > Cc: "Michael S. Tsirkin" <[e-mail]>
> > > > > > > Cc: Paolo Bonzini <[e-mail]>
> > > > > > > Cc: Gerd Hoffmann <[e-mail]>
> > > > > > > Cc: Eric Blake <[e-mail]>
> > > > > > > Cc: "Daniel P. Berrange" <[e-mail]>
> > > > > > > Cc: Andreas Färber <[e-mail]>
> > > > > > > Signed-off-by: Hu Tao <[e-mail]>
> > > > > >
> > > > > > Quoting from this discussion:
> > > > > >   >That may "fix" the issue of a windows guest showing the yellow ! mark,
> > > > > >   >but what if, down the road, someone writes an actual windows driver that
> > > > > >   >is aware of that port and how to make a windows BSOD write a panic
> > > > > >   >notification to the port?  How does a user go about installing such a
> > > > > >   >driver if the device is not exposed in the user interface list of
> > > > > >   >devices?
> > > > > >
> > > > > > I think the correct way to address this is:
> > > > > > - don't create the device by default, only when -device pvpanic is
> > > > > >   present
> > > > > > - teach management to supply said -device pvpanic for guests which
> > > > > >   support the pvpanic device
> > > > >
> > > > > That's just pushing the problem elsewhere. How management suppose to know if
> > > > > guest support pvpanic device?
> > > >
> > > > Same as any PV device really. It's exactly the same problem
> > > > as with virtio: user configures the XML properly.
> > >
> > > Virtio has alternatives.
> >
> > I don't see why does it matter. In any case, only
> > *some* virtio devices have alternatives.
> > What about the balloon device? VIRTIO_9P? There are more examples.
> > What about e.g. ivshmem?
>
> They take very limited pci resources and/or provide functionality that
> should not be available for all guests. We do provide ACPI hotplug
> device unconditionally.
> > > > > What if initially guest did not have a
> > > > > driver, but the it was installed?
> > > >
> > > > You can reconfigure XML and reboot.
> > >
> > > Will it cause Windows reactivation? Maybe after adding several devices?
> >
> > I don't think it will.
> > https://en.wikipedia.org/wiki/Microsoft_Product_Activation
> > says:
> >     Display adapter
> >     SCSI adapter
> >     IDE adapter
> >     Network adapter MAC address
> >     RAM amount range (e.g. 0-512 MB)
> >     Processor type and serial number
> >     Hard drive device and volume serial number
> >     Optical drive (e.g. DVD-ROM)
> >
> > As you see we do let people change many parameters
> > that do affect activation.
> > By editing XML user can shoot himself in the foot, we should not prevent
> > that.

So that's what I'm saying basically.
At the moment there's no way to remove this device from XML.
That's just wrong.
In QEMU, we have a standard way to specify devices with -device.
That should be the interface for anything new really
unless there's a very compelling reason for something else.
*Not* building it into the PC machine type.
> It should not be required though.

libvirt can pass -device pvpanic by default if nothing
is specified in XML. That discussion really has to happen
on libvirt list.

-- 
MST

[Gleb Natapov]

On Mon, Aug 05, 2013 at 09:32:18PM +0300, Michael S. Tsirkin wrote:
> > > As you see we do let people change many parameters
> > > that do affect activation.
> > > By editing XML user can shoot himself in the foot, we should not prevent
> > > that.
>
> So that's what I'm saying basically.
> At the moment there's no way to remove this device from XML.
> That's just wrong.
> Can say the same about PV acpi hotpulg device.
> In QEMU, we have a standard way to specify devices with -device.
> That should be the interface for anything new really
> unless there's a very compelling reason for something else.
> We are disagree on compelling reason in this case obviously.
> *Not* building it into the PC machine type.
> > It should not be required though.
>
> libvirt can pass -device pvpanic by default if nothing
> is specified in XML. That discussion really has to happen
> on libvirt list.

As Paolo said you are just pushing the "problem" up the stack
where it is harder to "solve". I put "problem" and "solve" in
quotes because I disagree that the problem that need to be solved
is identified correctly. The correct problem to be solved IMO is
writing Windows driver for the device.

--
			Gleb.

[Vadim Rozenfeld]

----- Original Message -----
From: "Gleb Natapov" <[e-mail]>
To: "Michael S. Tsirkin" <[e-mail]>
Cc: "Daniel P. Berrange" <[e-mail]>, "Marcel Apfelbaum" <[e-mail]>, [e-mail], [e-mail], "Gerd Hoffmann" <[e-mail]>, "Paolo Bonzini" <[e-mail]>, "Eric Blake" <[e-mail]>, "Andreas Färber" <[e-mail]>
Sent: Tuesday, August 6, 2013 5:34:06 PM
Subject: Re: [SeaBIOS] [PATCH] don't expose pvpanic device in the UI

On Mon, Aug 05, 2013 at 09:32:18PM +0300, Michael S. Tsirkin wrote:
> > > As you see we do let people change many parameters
> > > that do affect activation.
> > > By editing XML user can shoot himself in the foot, we should not prevent
> > > that.
>
> So that's what I'm saying basically.
> At the moment there's no way to remove this device from XML.
> That's just wrong.
> Can say the same about PV acpi hotpulg device.
> In QEMU, we have a standard way to specify devices with -device.
> That should be the interface for anything new really
> unless there's a very compelling reason for something else.
> We are disagree on compelling reason in this case obviously.
> *Not* building it into the PC machine type.
> > It should not be required though.
>
> libvirt can pass -device pvpanic by default if nothing
> is specified in XML. That discussion really has to happen
> on libvirt list.

As Paolo said you are just pushing the "problem" up the stack
where it is harder to "solve". I put "problem" and "solve" in
quotes because I disagree that the problem that need to be solved
is identified correctly. The correct problem to be solved IMO is
writing Windows driver for the device.

[VR]
This one shouldn't be too complicated. Can be done on weekend.
--
			Gleb.

_______________________________________________
SeaBIOS mailing list
[e-mail]
http://www.seabios.org/mailman/listinfo/seabios

[Gleb Natapov]

On Tue, Aug 06, 2013 at 04:03:17AM -0400, Vadim Rozenfeld wrote:
> ----- Original Message -----
> From: "Gleb Natapov" <[e-mail]>
> To: "Michael S. Tsirkin" <[e-mail]>
> Cc: "Daniel P. Berrange" <[e-mail]>, "Marcel Apfelbaum" <[e-mail]>, [e-mail], [e-mail], "Gerd Hoffmann" <[e-mail]>, "Paolo Bonzini" <[e-mail]>, "Eric Blake" <[e-mail]>, "Andreas Färber" <[e-mail]>
> Sent: Tuesday, August 6, 2013 5:34:06 PM
> Subject: Re: [SeaBIOS] [PATCH] don't expose pvpanic device in the UI
>
> On Mon, Aug 05, 2013 at 09:32:18PM +0300, Michael S. Tsirkin wrote:
> > > > As you see we do let people change many parameters
> > > > that do affect activation.
> > > > By editing XML user can shoot himself in the foot, we should not prevent
> > > > that.
> >
> > So that's what I'm saying basically.
> > At the moment there's no way to remove this device from XML.
> > That's just wrong.
> > Can say the same about PV acpi hotpulg device.
> > In QEMU, we have a standard way to specify devices with -device.
> > That should be the interface for anything new really
> > unless there's a very compelling reason for something else.
> > We are disagree on compelling reason in this case obviously.
> > *Not* building it into the PC machine type.
> > > It should not be required though.
> >
> > libvirt can pass -device pvpanic by default if nothing
> > is specified in XML. That discussion really has to happen
> > on libvirt list.
>
> As Paolo said you are just pushing the "problem" up the stack
> where it is harder to "solve". I put "problem" and "solve" in
> quotes because I disagree that the problem that need to be solved
> is identified correctly. The correct problem to be solved IMO is
> writing Windows driver for the device.
>
> [VR]
> This one shouldn't be too complicated. Can be done on weekend.

Gal says he did it already.

--
			Gleb.

[Vadim Rozenfeld]

----- Original Message -----
From: "Gleb Natapov" <[e-mail]>
To: "Vadim Rozenfeld" <[e-mail]>
Cc: "Michael S. Tsirkin" <[e-mail]>, "Daniel P. Berrange" <[e-mail]>, "Marcel Apfelbaum" <[e-mail]>, [e-mail], [e-mail], "Gerd Hoffmann" <[e-mail]>, "Paolo Bonzini" <[e-mail]>, "Eric Blake" <[e-mail]>, "Andreas Färber" <[e-mail]>
Sent: Tuesday, August 6, 2013 6:05:27 PM
Subject: Re: [SeaBIOS] [PATCH] don't expose pvpanic device in the UI

On Tue, Aug 06, 2013 at 04:03:17AM -0400, Vadim Rozenfeld wrote:
> ----- Original Message -----
> From: "Gleb Natapov" <[e-mail]>
> To: "Michael S. Tsirkin" <[e-mail]>
> Cc: "Daniel P. Berrange" <[e-mail]>, "Marcel Apfelbaum" <[e-mail]>, [e-mail], [e-mail], "Gerd Hoffmann" <[e-mail]>, "Paolo Bonzini" <[e-mail]>, "Eric Blake" <[e-mail]>, "Andreas Färber" <[e-mail]>
> Sent: Tuesday, August 6, 2013 5:34:06 PM
> Subject: Re: [SeaBIOS] [PATCH] don't expose pvpanic device in the UI
>
> On Mon, Aug 05, 2013 at 09:32:18PM +0300, Michael S. Tsirkin wrote:
> > > > As you see we do let people change many parameters
> > > > that do affect activation.
> > > > By editing XML user can shoot himself in the foot, we should not prevent
> > > > that.
> >
> > So that's what I'm saying basically.
> > At the moment there's no way to remove this device from XML.
> > That's just wrong.
> > Can say the same about PV acpi hotpulg device.
> > In QEMU, we have a standard way to specify devices with -device.
> > That should be the interface for anything new really
> > unless there's a very compelling reason for something else.
> > We are disagree on compelling reason in this case obviously.
> > *Not* building it into the PC machine type.
> > > It should not be required though.
> >
> > libvirt can pass -device pvpanic by default if nothing
> > is specified in XML. That discussion really has to happen
> > on libvirt list.
>
> As Paolo said you are just pushing the "problem" up the stack
> where it is harder to "solve". I put "problem" and "solve" in
> quotes because I disagree that the problem that need to be solved
> is identified correctly. The correct problem to be solved IMO is
> writing Windows driver for the device.
>
> [VR]
> This one shouldn't be too complicated. Can be done on weekend.

Gal says he did it already.

[VR]
If so, we can add it to our build and make it public.

--
			Gleb.

[Gleb Natapov]

On Tue, Aug 06, 2013 at 04:14:36AM -0400, Vadim Rozenfeld wrote:
> ----- Original Message -----
> From: "Gleb Natapov" <[e-mail]>
> To: "Vadim Rozenfeld" <[e-mail]>
> Cc: "Michael S. Tsirkin" <[e-mail]>, "Daniel P. Berrange" <[e-mail]>, "Marcel Apfelbaum" <[e-mail]>, [e-mail], [e-mail], "Gerd Hoffmann" <[e-mail]>, "Paolo Bonzini" <[e-mail]>, "Eric Blake" <[e-mail]>, "Andreas Färber" <[e-mail]>
> Sent: Tuesday, August 6, 2013 6:05:27 PM
> Subject: Re: [SeaBIOS] [PATCH] don't expose pvpanic device in the UI
>
> On Tue, Aug 06, 2013 at 04:03:17AM -0400, Vadim Rozenfeld wrote:
> > ----- Original Message -----
> > From: "Gleb Natapov" <[e-mail]>
> > To: "Michael S. Tsirkin" <[e-mail]>
> > Cc: "Daniel P. Berrange" <[e-mail]>, "Marcel Apfelbaum" <[e-mail]>, [e-mail], [e-mail], "Gerd Hoffmann" <[e-mail]>, "Paolo Bonzini" <[e-mail]>, "Eric Blake" <[e-mail]>, "Andreas Färber" <[e-mail]>
> > Sent: Tuesday, August 6, 2013 5:34:06 PM
> > Subject: Re: [SeaBIOS] [PATCH] don't expose pvpanic device in the UI
> >
> > On Mon, Aug 05, 2013 at 09:32:18PM +0300, Michael S. Tsirkin wrote:
> > > > > As you see we do let people change many parameters
> > > > > that do affect activation.
> > > > > By editing XML user can shoot himself in the foot, we should not prevent
> > > > > that.
> > >
> > > So that's what I'm saying basically.
> > > At the moment there's no way to remove this device from XML.
> > > That's just wrong.
> > > Can say the same about PV acpi hotpulg device.
> > > In QEMU, we have a standard way to specify devices with -device.
> > > That should be the interface for anything new really
> > > unless there's a very compelling reason for something else.
> > > We are disagree on compelling reason in this case obviously.
> > > *Not* building it into the PC machine type.
> > > > It should not be required though.
> > >
> > > libvirt can pass -device pvpanic by default if nothing
> > > is specified in XML. That discussion really has to happen
> > > on libvirt list.
> >
> > As Paolo said you are just pushing the "problem" up the stack
> > where it is harder to "solve". I put "problem" and "solve" in
> > quotes because I disagree that the problem that need to be solved
> > is identified correctly. The correct problem to be solved IMO is
> > writing Windows driver for the device.
> >
> > [VR]
> > This one shouldn't be too complicated. Can be done on weekend.
>
> Gal says he did it already.
>
> [VR]
> If so, we can add it to our build and make it public.

That's the plan :)

--
			Gleb.

[Paolo Bonzini]

> > for example: in Windows(let's say XP) the Device manager will open a
> > "new device" wizard and the device will appear as an unrecognized
> > device.  On a cluster with hundreds of such VMs, If that cluster has
> > a health monitoring service it may show all the VMs in a "not healthy"
> > state.

Is this just a hypothesis, or is there really such broken monitoring
software?
> > This patch is a workaround to not show pvpanic in UI to avoid the
> > problem in Windows.

It's not a workaround, it is a proper bugfix.

What versions of Windows did you test it on?  Did it hide the New
Hardware wizard properly (I think it appears only on XP/2003)?

Paolo

[Hu Tao]

On Mon, Aug 05, 2013 at 06:13:39AM -0400, Paolo Bonzini wrote:
> > > for example: in Windows(let's say XP) the Device manager will open a
> > > "new device" wizard and the device will appear as an unrecognized
> > > device.  On a cluster with hundreds of such VMs, If that cluster has
> > > a health monitoring service it may show all the VMs in a "not healthy"
> > > state.
>
> Is this just a hypothesis, or is there really such broken monitoring
> software?

Marcel?
> > > This patch is a workaround to not show pvpanic in UI to avoid the
> > > problem in Windows.
>
> It's not a workaround, it is a proper bugfix.
>
> What versions of Windows did you test it on?  Did it hide the New
> Hardware wizard properly (I think it appears only on XP/2003)?

Windows XP. I didn't see hardware wizard, maybe it is because I tested
the same VM before and XP remembered the device and wasn't boring to
prompt again.

Tested in a freshly installed Windows XP, the device is hidden but
the hardware wizard is shown.

[Paolo Bonzini]

> > > > This patch is a workaround to not show pvpanic in UI to avoid the
> > > > problem in Windows.
> >
> > It's not a workaround, it is a proper bugfix.
> >
> > What versions of Windows did you test it on?  Did it hide the New
> > Hardware wizard properly (I think it appears only on XP/2003)?
>
> Windows XP. I didn't see hardware wizard, maybe it is because I tested
> the same VM before and XP remembered the device and wasn't boring to
> prompt again.
>
> Tested in a freshly installed Windows XP, the device is hidden but
> the hardware wizard is shown.

Then unfortunately this patch alone is useless. :(

What would work is treat this as a 2000/XP bug and use _OSI to probe
for Vista/2008 or later ("Windows 2006" and "Windows 2006.1", says
drivers/acpi/acpica/utosi.c).  Perhaps on top of this one.

Paolo

[Michael S. Tsirkin]

On Mon, Aug 05, 2013 at 09:26:32AM -0400, Paolo Bonzini wrote:
> > > > > This patch is a workaround to not show pvpanic in UI to avoid the
> > > > > problem in Windows.
> > >
> > > It's not a workaround, it is a proper bugfix.
> > >
> > > What versions of Windows did you test it on?  Did it hide the New
> > > Hardware wizard properly (I think it appears only on XP/2003)?
> >
> > Windows XP. I didn't see hardware wizard, maybe it is because I tested
> > the same VM before and XP remembered the device and wasn't boring to
> > prompt again.
> >
> > Tested in a freshly installed Windows XP, the device is hidden but
> > the hardware wizard is shown.
>
> Then unfortunately this patch alone is useless. :(
>
> What would work is treat this as a 2000/XP bug and use _OSI to probe
> for Vista/2008 or later ("Windows 2006" and "Windows 2006.1", says
> drivers/acpi/acpica/utosi.c).  Perhaps on top of this one.
>
> Paolo

I don't see what's wrong with making user make the decision through XML.
Management tools are aware of specific windows versions and can do the
right thing to set XML properly.

-- 
MST

[Hu Tao]

On Mon, Aug 05, 2013 at 09:26:32AM -0400, Paolo Bonzini wrote:
> > > > > This patch is a workaround to not show pvpanic in UI to avoid the
> > > > > problem in Windows.
> > >
> > > It's not a workaround, it is a proper bugfix.
> > >
> > > What versions of Windows did you test it on?  Did it hide the New
> > > Hardware wizard properly (I think it appears only on XP/2003)?
> >
> > Windows XP. I didn't see hardware wizard, maybe it is because I tested
> > the same VM before and XP remembered the device and wasn't boring to
> > prompt again.
> >
> > Tested in a freshly installed Windows XP, the device is hidden but
> > the hardware wizard is shown.
>
> Then unfortunately this patch alone is useless. :(
>
> What would work is treat this as a 2000/XP bug and use _OSI to probe
> for Vista/2008 or later ("Windows 2006" and "Windows 2006.1", says
> drivers/acpi/acpica/utosi.c).  Perhaps on top of this one.

Tested on Windows Server 2008, Windows Server 2008 R2 and Windows Server
2012. On Windows Server 2008, the New Hardware Wizward still shows up.
On the latter two, the New Hardware Wizward doesn't show up.
So we should test for "Windows 2009" and later? How can I know from
which version of Windows the New Hardware Wizward is fixed? I searched
on google but couldn't find a related page.

[Hu Tao]

On Fri, Aug 09, 2013 at 04:02:24PM +0800, Hu Tao wrote:
> On Mon, Aug 05, 2013 at 09:26:32AM -0400, Paolo Bonzini wrote:
> > > > > > This patch is a workaround to not show pvpanic in UI to avoid the
> > > > > > problem in Windows.
> > > >
> > > > It's not a workaround, it is a proper bugfix.
> > > >
> > > > What versions of Windows did you test it on?  Did it hide the New
> > > > Hardware wizard properly (I think it appears only on XP/2003)?
> > >
> > > Windows XP. I didn't see hardware wizard, maybe it is because I tested
> > > the same VM before and XP remembered the device and wasn't boring to
> > > prompt again.
> > >
> > > Tested in a freshly installed Windows XP, the device is hidden but
> > > the hardware wizard is shown.
> >
> > Then unfortunately this patch alone is useless. :(
> >
> > What would work is treat this as a 2000/XP bug and use _OSI to probe
> > for Vista/2008 or later ("Windows 2006" and "Windows 2006.1", says
> > drivers/acpi/acpica/utosi.c).  Perhaps on top of this one.
>
> Tested on Windows Server 2008, Windows Server 2008 R2 and Windows Server
> 2012. On Windows Server 2008, the New Hardware Wizward still shows up.
> On the latter two, the New Hardware Wizward doesn't show up.
> So we should test for "Windows 2009" and later? How can I know from
> which version of Windows the New Hardware Wizward is fixed? I searched
> on google but couldn't find a related page.

The patch for test is:
> From 8fe044e39d6de0e1999e48cf4e2e371beec3b861 Mon Sep 17 00:00:00 2001
> From: Hu Tao <[e-mail]>
> Date: Fri, 9 Aug 2013 16:23:54 +0800
> Subject: [PATCH] pvpanic: disable pvpanic for some Windows versions

Signed-off-by: Hu Tao <[e-mail]>
---
 src/acpi-dsdt.dsl | 19 +++++++++++++++++++
 src/ssdt-misc.dsl |  4 ++++
 2 files changed, 23 insertions(+)

diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl
index 158f6b4..e6cede7 100644
--- a/src/acpi-dsdt.dsl
+++ b/src/acpi-dsdt.dsl
@@ -340,4 +340,23 @@ DefinitionBlock (
         Method(_L0F) {
         }
     }
+
+    Scope(\_SB) {
+        Name (TOOS, 0x00)
+        Method (_INI, 0, NotSerialized)
+        {
+            If (\_OSI ("Windows 2006"))
+            {
+                Store (0x01, TOOS)
+            }
+            ElseIf (\_OSI ("Windows 2000"))
+            {
+                Store (0x00, TOOS)
+            }
+            Else
+            {
+                Store (0x01, TOOS)
+            }
+        }
+    }
 }
diff --git a/src/ssdt-misc.dsl b/src/ssdt-misc.dsl
index 19a2058..62b13a2 100644
--- a/src/ssdt-misc.dsl
+++ b/src/ssdt-misc.dsl
@@ -58,6 +58,7 @@ DefinitionBlock ("ssdt-misc.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1)
 
     External(\_SB.PCI0, DeviceObj)
     External(\_SB.PCI0.ISA, DeviceObj)
+    External(\_SB.TOOS, IntObj)
 
     Scope(\_SB.PCI0.ISA) {
         Device(PEVT) {
@@ -71,6 +72,9 @@ DefinitionBlock ("ssdt-misc.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1)
             }
 
             Method(_STA, 0, NotSerialized) {
+                If (LEqual(TOOS, Zero)) {
+                    Return (0x00)
+                }
                 Store(PEST, Local0)
                 If (LEqual(Local0, Zero)) {
                     Return (0x00)
-- 
1.8.1.4

[Paolo Bonzini]

Il 09/08/2013 11:02, Hu Tao ha scritto:
> On Fri, Aug 09, 2013 at 04:02:24PM +0800, Hu Tao wrote:
> > On Mon, Aug 05, 2013 at 09:26:32AM -0400, Paolo Bonzini wrote:
> > > > > > > This patch is a workaround to not show pvpanic in UI to avoid the
> > > > > > > problem in Windows.
> > > > >
> > > > > It's not a workaround, it is a proper bugfix.
> > > > >
> > > > > What versions of Windows did you test it on?  Did it hide the New
> > > > > Hardware wizard properly (I think it appears only on XP/2003)?
> > > >
> > > > Windows XP. I didn't see hardware wizard, maybe it is because I tested
> > > > the same VM before and XP remembered the device and wasn't boring to
> > > > prompt again.
> > > >
> > > > Tested in a freshly installed Windows XP, the device is hidden but
> > > > the hardware wizard is shown.
> > >
> > > Then unfortunately this patch alone is useless. :(
> > >
> > > What would work is treat this as a 2000/XP bug and use _OSI to probe
> > > for Vista/2008 or later ("Windows 2006" and "Windows 2006.1", says
> > > drivers/acpi/acpica/utosi.c).  Perhaps on top of this one.
> >
> > Tested on Windows Server 2008, Windows Server 2008 R2 and Windows Server
> > 2012. On Windows Server 2008, the New Hardware Wizward still shows up.
> > On the latter two, the New Hardware Wizward doesn't show up.
> > So we should test for "Windows 2009" and later? How can I know from
> > which version of Windows the New Hardware Wizward is fixed? I searched
> > on google but couldn't find a related page.
>
> The patch for test is:
>
> From 8fe044e39d6de0e1999e48cf4e2e371beec3b861 Mon Sep 17 00:00:00 2001
> From: Hu Tao <[e-mail]>
> Date: Fri, 9 Aug 2013 16:23:54 +0800
> Subject: [PATCH] pvpanic: disable pvpanic for some Windows versions
>
> Signed-off-by: Hu Tao <[e-mail]>
> ---
>  src/acpi-dsdt.dsl | 19 +++++++++++++++++++
>  src/ssdt-misc.dsl |  4 ++++
>  2 files changed, 23 insertions(+)
>
> diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl
> index 158f6b4..e6cede7 100644
> --- a/src/acpi-dsdt.dsl
> +++ b/src/acpi-dsdt.dsl
> @@ -340,4 +340,23 @@ DefinitionBlock (
>          Method(_L0F) {
>          }
>      }
> +
> +    Scope(\_SB) {
> +        Name (TOOS, 0x00)
> +        Method (_INI, 0, NotSerialized)
> +        {
> +            If (\_OSI ("Windows 2006"))

So perhaps it should test 2009 here, given the result of your testing?
Though IIRC the wizard in 2008 is much less intrusive than the one in
XP, and we will have a driver sooner or later, so it would be a fine
compromise.

Paolo
> +            {
> +                Store (0x01, TOOS)
> +            }
> +            ElseIf (\_OSI ("Windows 2000"))
> +            {
> +                Store (0x00, TOOS)
> +            }
> +            Else
> +            {
> +                Store (0x01, TOOS)
> +            }
> +        }
> +    }
>  }
> diff --git a/src/ssdt-misc.dsl b/src/ssdt-misc.dsl
> index 19a2058..62b13a2 100644
> --- a/src/ssdt-misc.dsl
> +++ b/src/ssdt-misc.dsl
> @@ -58,6 +58,7 @@ DefinitionBlock ("ssdt-misc.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1)
>
> External(\_SB.PCI0, DeviceObj)
>      External(\_SB.PCI0.ISA, DeviceObj)
> +    External(\_SB.TOOS, IntObj)
>
> Scope(\_SB.PCI0.ISA) {
>          Device(PEVT) {
> @@ -71,6 +72,9 @@ DefinitionBlock ("ssdt-misc.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1)
>              }
>
> Method(_STA, 0, NotSerialized) {
> +                If (LEqual(TOOS, Zero)) {
> +                    Return (0x00)
> +                }
>                  Store(PEST, Local0)
>                  If (LEqual(Local0, Zero)) {
>                      Return (0x00)

[Hu Tao]

On Fri, Aug 09, 2013 at 11:43:29AM +0200, Paolo Bonzini wrote:
> Il 09/08/2013 11:02, Hu Tao ha scritto:
> > On Fri, Aug 09, 2013 at 04:02:24PM +0800, Hu Tao wrote:
> > > On Mon, Aug 05, 2013 at 09:26:32AM -0400, Paolo Bonzini wrote:
> > > > > > >> This patch is a workaround to not show pvpanic in UI to avoid the
> > > > > > >> problem in Windows.
> > > > > >
> > > > > > It's not a workaround, it is a proper bugfix.
> > > > > >
> > > > > > What versions of Windows did you test it on?  Did it hide the New
> > > > > > Hardware wizard properly (I think it appears only on XP/2003)?
> > > > >
> > > > > Windows XP. I didn't see hardware wizard, maybe it is because I tested
> > > > > the same VM before and XP remembered the device and wasn't boring to
> > > > > prompt again.
> > > > >
> > > > > Tested in a freshly installed Windows XP, the device is hidden but
> > > > > the hardware wizard is shown.
> > > >
> > > > Then unfortunately this patch alone is useless. :(
> > > >
> > > > What would work is treat this as a 2000/XP bug and use _OSI to probe
> > > > for Vista/2008 or later ("Windows 2006" and "Windows 2006.1", says
> > > > drivers/acpi/acpica/utosi.c).  Perhaps on top of this one.
> > >
> > > Tested on Windows Server 2008, Windows Server 2008 R2 and Windows Server
> > > 2012. On Windows Server 2008, the New Hardware Wizward still shows up.
> > > On the latter two, the New Hardware Wizward doesn't show up.
> > > So we should test for "Windows 2009" and later? How can I know from
> > > which version of Windows the New Hardware Wizward is fixed? I searched
> > > on google but couldn't find a related page.
> >
> > The patch for test is:
> >
> > From 8fe044e39d6de0e1999e48cf4e2e371beec3b861 Mon Sep 17 00:00:00 2001
> > From: Hu Tao <[e-mail]>
> > Date: Fri, 9 Aug 2013 16:23:54 +0800
> > Subject: [PATCH] pvpanic: disable pvpanic for some Windows versions
> >
> > Signed-off-by: Hu Tao <[e-mail]>
> > ---
> >  src/acpi-dsdt.dsl | 19 +++++++++++++++++++
> >  src/ssdt-misc.dsl |  4 ++++
> >  2 files changed, 23 insertions(+)
> >
> > diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl
> > index 158f6b4..e6cede7 100644
> > --- a/src/acpi-dsdt.dsl
> > +++ b/src/acpi-dsdt.dsl
> > @@ -340,4 +340,23 @@ DefinitionBlock (
> >          Method(_L0F) {
> >          }
> >      }
> > +
> > +    Scope(\_SB) {
> > +        Name (TOOS, 0x00)
> > +        Method (_INI, 0, NotSerialized)
> > +        {
> > +            If (\_OSI ("Windows 2006"))
>
> So perhaps it should test 2009 here, given the result of your testing?

Yeah. I'll send an updated patch.

Another question, this patch disables pvpanic for Windows 2008 and prior
unconditionally, do we have to worry about the case that user wants
pvpanic even for these OSes?
> Though IIRC the wizard in 2008 is much less intrusive than the one in
> XP, and we will have a driver sooner or later, so it would be a fine
> compromise.
>
> Paolo
> > +            {
> > +                Store (0x01, TOOS)
> > +            }
> > +            ElseIf (\_OSI ("Windows 2000"))
> > +            {
> > +                Store (0x00, TOOS)
> > +            }
> > +            Else
> > +            {
> > +                Store (0x01, TOOS)
> > +            }
> > +        }
> > +    }
> >  }
> > diff --git a/src/ssdt-misc.dsl b/src/ssdt-misc.dsl
> > index 19a2058..62b13a2 100644
> > --- a/src/ssdt-misc.dsl
> > +++ b/src/ssdt-misc.dsl
> > @@ -58,6 +58,7 @@ DefinitionBlock ("ssdt-misc.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1)
> >
> > External(\_SB.PCI0, DeviceObj)
> >      External(\_SB.PCI0.ISA, DeviceObj)
> > +    External(\_SB.TOOS, IntObj)
> >
> > Scope(\_SB.PCI0.ISA) {
> >          Device(PEVT) {
> > @@ -71,6 +72,9 @@ DefinitionBlock ("ssdt-misc.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1)
> >              }
> >
> > Method(_STA, 0, NotSerialized) {
> > +                If (LEqual(TOOS, Zero)) {
> > +                    Return (0x00)
> > +                }
> >                  Store(PEST, Local0)
> >                  If (LEqual(Local0, Zero)) {
> >                      Return (0x00)

[Michael S. Tsirkin]

On Mon, Aug 12, 2013 at 10:23:58AM +0800, Hu Tao wrote:
> On Fri, Aug 09, 2013 at 11:43:29AM +0200, Paolo Bonzini wrote:
> > Il 09/08/2013 11:02, Hu Tao ha scritto:
> > > On Fri, Aug 09, 2013 at 04:02:24PM +0800, Hu Tao wrote:
> > > > On Mon, Aug 05, 2013 at 09:26:32AM -0400, Paolo Bonzini wrote:
> > > > > > >>> This patch is a workaround to not show pvpanic in UI to avoid the
> > > > > > >>> problem in Windows.
> > > > > > >
> > > > > > > It's not a workaround, it is a proper bugfix.
> > > > > > >
> > > > > > > What versions of Windows did you test it on?  Did it hide the New
> > > > > > > Hardware wizard properly (I think it appears only on XP/2003)?
> > > > > >
> > > > > > Windows XP. I didn't see hardware wizard, maybe it is because I tested
> > > > > > the same VM before and XP remembered the device and wasn't boring to
> > > > > > prompt again.
> > > > > >
> > > > > > Tested in a freshly installed Windows XP, the device is hidden but
> > > > > > the hardware wizard is shown.
> > > > >
> > > > > Then unfortunately this patch alone is useless. :(
> > > > >
> > > > > What would work is treat this as a 2000/XP bug and use _OSI to probe
> > > > > for Vista/2008 or later ("Windows 2006" and "Windows 2006.1", says
> > > > > drivers/acpi/acpica/utosi.c).  Perhaps on top of this one.
> > > >
> > > > Tested on Windows Server 2008, Windows Server 2008 R2 and Windows Server
> > > > 2012. On Windows Server 2008, the New Hardware Wizward still shows up.
> > > > On the latter two, the New Hardware Wizward doesn't show up.
> > > > So we should test for "Windows 2009" and later? How can I know from
> > > > which version of Windows the New Hardware Wizward is fixed? I searched
> > > > on google but couldn't find a related page.
> > >
> > > The patch for test is:
> > >
> > > From 8fe044e39d6de0e1999e48cf4e2e371beec3b861 Mon Sep 17 00:00:00 2001
> > > From: Hu Tao <[e-mail]>
> > > Date: Fri, 9 Aug 2013 16:23:54 +0800
> > > Subject: [PATCH] pvpanic: disable pvpanic for some Windows versions
> > >
> > > Signed-off-by: Hu Tao <[e-mail]>
> > > ---
> > >  src/acpi-dsdt.dsl | 19 +++++++++++++++++++
> > >  src/ssdt-misc.dsl |  4 ++++
> > >  2 files changed, 23 insertions(+)
> > >
> > > diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl
> > > index 158f6b4..e6cede7 100644
> > > --- a/src/acpi-dsdt.dsl
> > > +++ b/src/acpi-dsdt.dsl
> > > @@ -340,4 +340,23 @@ DefinitionBlock (
> > >          Method(_L0F) {
> > >          }
> > >      }
> > > +
> > > +    Scope(\_SB) {
> > > +        Name (TOOS, 0x00)
> > > +        Method (_INI, 0, NotSerialized)
> > > +        {
> > > +            If (\_OSI ("Windows 2006"))
> >
> > So perhaps it should test 2009 here, given the result of your testing?
>
> Yeah. I'll send an updated patch.
> Another question, this patch disables pvpanic for Windows 2008 and prior
> unconditionally, do we have to worry about the case that user wants
> pvpanic even for these OSes?

In fact, now that pvpanic is specified explicitly, there doesn't appear
to be any need for these patches.  Just implement a driver for all
OS-es.
> > Though IIRC the wizard in 2008 is much less intrusive than the one in
> > XP, and we will have a driver sooner or later, so it would be a fine
> > compromise.
> >
> > Paolo
> > > +            {
> > > +                Store (0x01, TOOS)
> > > +            }
> > > +            ElseIf (\_OSI ("Windows 2000"))
> > > +            {
> > > +                Store (0x00, TOOS)
> > > +            }
> > > +            Else
> > > +            {
> > > +                Store (0x01, TOOS)
> > > +            }
> > > +        }
> > > +    }
> > >  }
> > > diff --git a/src/ssdt-misc.dsl b/src/ssdt-misc.dsl
> > > index 19a2058..62b13a2 100644
> > > --- a/src/ssdt-misc.dsl
> > > +++ b/src/ssdt-misc.dsl
> > > @@ -58,6 +58,7 @@ DefinitionBlock ("ssdt-misc.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1)
> > >
> > > External(\_SB.PCI0, DeviceObj)
> > >      External(\_SB.PCI0.ISA, DeviceObj)
> > > +    External(\_SB.TOOS, IntObj)
> > >
> > > Scope(\_SB.PCI0.ISA) {
> > >          Device(PEVT) {
> > > @@ -71,6 +72,9 @@ DefinitionBlock ("ssdt-misc.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1)
> > >              }
> > >
> > > Method(_STA, 0, NotSerialized) {
> > > +                If (LEqual(TOOS, Zero)) {
> > > +                    Return (0x00)
> > > +                }
> > >                  Store(PEST, Local0)
> > >                  If (LEqual(Local0, Zero)) {
> > >                      Return (0x00)

[Marcel Apfelbaum]

On Mon, 2013-08-05 at 20:24 +0800, Hu Tao wrote:
> On Mon, Aug 05, 2013 at 06:13:39AM -0400, Paolo Bonzini wrote:
> > > > for example: in Windows(let's say XP) the Device manager will open a
> > > > "new device" wizard and the device will appear as an unrecognized
> > > > device.  On a cluster with hundreds of such VMs, If that cluster has
> > > > a health monitoring service it may show all the VMs in a "not healthy"
> > > > state.
> >
> > Is this just a hypothesis, or is there really such broken monitoring
> > software?
>
> Marcel?
> I am not aware of a specific software management tool, but Windows
> WMI API make this so easily to implement and I am sure that a least
> a part of them implements this.
> > > > This patch is a workaround to not show pvpanic in UI to avoid the
> > > > problem in Windows.
> >
> > It's not a workaround, it is a proper bugfix.
> >
> > What versions of Windows did you test it on?  Did it hide the New
> > Hardware wizard properly (I think it appears only on XP/2003)?
>
> Windows XP. I didn't see hardware wizard, maybe it is because I tested
> the same VM before and XP remembered the device and wasn't boring to
> prompt again.
>
> Tested in a freshly installed Windows XP, the device is hidden but
> the hardware wizard is shown.

I think I also saw the unknown device. I'll have another look.
Marcel