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 marcel.a@redhat.com Cc: "Michael S. Tsirkin" mst@redhat.com Cc: Paolo Bonzini pbonzini@redhat.com Cc: Gerd Hoffmann kraxel@redhat.com Cc: Eric Blake eblake@redhat.com Cc: "Daniel P. Berrange" berrange@redhat.com Cc: Andreas Färber afaerber@suse.de Signed-off-by: Hu Tao hutao@cn.fujitsu.com ---
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) } }
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 marcel.a@redhat.com Cc: "Michael S. Tsirkin" mst@redhat.com Cc: Paolo Bonzini pbonzini@redhat.com Cc: Gerd Hoffmann kraxel@redhat.com Cc: Eric Blake eblake@redhat.com Cc: "Daniel P. Berrange" berrange@redhat.com Cc: Andreas Färber afaerber@suse.de Signed-off-by: Hu Tao hutao@cn.fujitsu.com
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) } }-- 1.8.1.4
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 marcel.a@redhat.com Cc: "Michael S. Tsirkin" mst@redhat.com Cc: Paolo Bonzini pbonzini@redhat.com Cc: Gerd Hoffmann kraxel@redhat.com Cc: Eric Blake eblake@redhat.com Cc: "Daniel P. Berrange" berrange@redhat.com Cc: Andreas Färber afaerber@suse.de Signed-off-by: Hu Tao hutao@cn.fujitsu.com
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.
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 marcel.a@redhat.com Cc: "Michael S. Tsirkin" mst@redhat.com Cc: Paolo Bonzini pbonzini@redhat.com Cc: Gerd Hoffmann kraxel@redhat.com Cc: Eric Blake eblake@redhat.com Cc: "Daniel P. Berrange" berrange@redhat.com Cc: Andreas Färber afaerber@suse.de Signed-off-by: Hu Tao hutao@cn.fujitsu.com
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
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 marcel.a@redhat.com Cc: "Michael S. Tsirkin" mst@redhat.com Cc: Paolo Bonzini pbonzini@redhat.com Cc: Gerd Hoffmann kraxel@redhat.com Cc: Eric Blake eblake@redhat.com Cc: "Daniel P. Berrange" berrange@redhat.com Cc: Andreas Färber afaerber@suse.de Signed-off-by: Hu Tao hutao@cn.fujitsu.com
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.
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
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.
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
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.
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
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.
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.
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
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.
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
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.
-- MST
SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
-- Gleb.
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?
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.
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
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?
-- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
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.
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.
-- Gleb.
pvpanic presents itself as a separate device, this is different from PV ACPI hotplug which is part of PIIX.
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
Andreas Färber afaerber@suse.de 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 shoulddisable 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 wouldneed 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.
On Tue, Aug 06, 2013 at 11:56:11AM +0200, Markus Armbruster wrote:
Andreas Färber afaerber@suse.de 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.
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.
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.
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.
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.
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
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.
Gleb Natapov gleb@redhat.com 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.
On Tue, Aug 06, 2013 at 01:48:17PM +0200, Markus Armbruster wrote:
Gleb Natapov gleb@redhat.com 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... :)
-- Gleb.
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
-- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
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
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
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
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.
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
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.
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
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.
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
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.
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.
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
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.
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.
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.
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.
-- Gleb.
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.
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.
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.
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.
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 marcel.a@redhat.com Cc: "Michael S. Tsirkin" mst@redhat.com Cc: Paolo Bonzini pbonzini@redhat.com Cc: Gerd Hoffmann kraxel@redhat.com Cc: Eric Blake eblake@redhat.com Cc: "Daniel P. Berrange" berrange@redhat.com Cc: Andreas Färber afaerber@suse.de Signed-off-by: Hu Tao hutao@cn.fujitsu.com
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.
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 marcel.a@redhat.com Cc: "Michael S. Tsirkin" mst@redhat.com Cc: Paolo Bonzini pbonzini@redhat.com Cc: Gerd Hoffmann kraxel@redhat.com Cc: Eric Blake eblake@redhat.com Cc: "Daniel P. Berrange" berrange@redhat.com Cc: Andreas Färber afaerber@suse.de Signed-off-by: Hu Tao hutao@cn.fujitsu.com
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.
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 marcel.a@redhat.com Cc: "Michael S. Tsirkin" mst@redhat.com Cc: Paolo Bonzini pbonzini@redhat.com Cc: Gerd Hoffmann kraxel@redhat.com Cc: Eric Blake eblake@redhat.com Cc: "Daniel P. Berrange" berrange@redhat.com Cc: Andreas Färber afaerber@suse.de Signed-off-by: Hu Tao hutao@cn.fujitsu.com
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.
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 marcel.a@redhat.com Cc: "Michael S. Tsirkin" mst@redhat.com Cc: Paolo Bonzini pbonzini@redhat.com Cc: Gerd Hoffmann kraxel@redhat.com Cc: Eric Blake eblake@redhat.com Cc: "Daniel P. Berrange" berrange@redhat.com Cc: Andreas Färber afaerber@suse.de Signed-off-by: Hu Tao hutao@cn.fujitsu.com
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.
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 marcel.a@redhat.com > Cc: "Michael S. Tsirkin" mst@redhat.com > Cc: Paolo Bonzini pbonzini@redhat.com > Cc: Gerd Hoffmann kraxel@redhat.com > Cc: Eric Blake eblake@redhat.com > Cc: "Daniel P. Berrange" berrange@redhat.com > Cc: Andreas Färber afaerber@suse.de > Signed-off-by: Hu Tao hutao@cn.fujitsu.com
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.
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.
----- Original Message ----- From: "Gleb Natapov" gleb@redhat.com To: "Michael S. Tsirkin" mst@redhat.com Cc: "Daniel P. Berrange" berrange@redhat.com, "Marcel Apfelbaum" marcel.a@redhat.com, seabios@seabios.org, qemu-devel@nongnu.org, "Gerd Hoffmann" kraxel@redhat.com, "Paolo Bonzini" pbonzini@redhat.com, "Eric Blake" eblake@redhat.com, "Andreas Färber" afaerber@suse.de 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 SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
On Tue, Aug 06, 2013 at 04:03:17AM -0400, Vadim Rozenfeld wrote:
----- Original Message ----- From: "Gleb Natapov" gleb@redhat.com To: "Michael S. Tsirkin" mst@redhat.com Cc: "Daniel P. Berrange" berrange@redhat.com, "Marcel Apfelbaum" marcel.a@redhat.com, seabios@seabios.org, qemu-devel@nongnu.org, "Gerd Hoffmann" kraxel@redhat.com, "Paolo Bonzini" pbonzini@redhat.com, "Eric Blake" eblake@redhat.com, "Andreas Färber" afaerber@suse.de 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.
----- Original Message ----- From: "Gleb Natapov" gleb@redhat.com To: "Vadim Rozenfeld" vrozenfe@redhat.com Cc: "Michael S. Tsirkin" mst@redhat.com, "Daniel P. Berrange" berrange@redhat.com, "Marcel Apfelbaum" marcel.a@redhat.com, seabios@seabios.org, qemu-devel@nongnu.org, "Gerd Hoffmann" kraxel@redhat.com, "Paolo Bonzini" pbonzini@redhat.com, "Eric Blake" eblake@redhat.com, "Andreas Färber" afaerber@suse.de 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" gleb@redhat.com To: "Michael S. Tsirkin" mst@redhat.com Cc: "Daniel P. Berrange" berrange@redhat.com, "Marcel Apfelbaum" marcel.a@redhat.com, seabios@seabios.org, qemu-devel@nongnu.org, "Gerd Hoffmann" kraxel@redhat.com, "Paolo Bonzini" pbonzini@redhat.com, "Eric Blake" eblake@redhat.com, "Andreas Färber" afaerber@suse.de 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.
On Tue, Aug 06, 2013 at 04:14:36AM -0400, Vadim Rozenfeld wrote:
----- Original Message ----- From: "Gleb Natapov" gleb@redhat.com To: "Vadim Rozenfeld" vrozenfe@redhat.com Cc: "Michael S. Tsirkin" mst@redhat.com, "Daniel P. Berrange" berrange@redhat.com, "Marcel Apfelbaum" marcel.a@redhat.com, seabios@seabios.org, qemu-devel@nongnu.org, "Gerd Hoffmann" kraxel@redhat.com, "Paolo Bonzini" pbonzini@redhat.com, "Eric Blake" eblake@redhat.com, "Andreas Färber" afaerber@suse.de 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" gleb@redhat.com To: "Michael S. Tsirkin" mst@redhat.com Cc: "Daniel P. Berrange" berrange@redhat.com, "Marcel Apfelbaum" marcel.a@redhat.com, seabios@seabios.org, qemu-devel@nongnu.org, "Gerd Hoffmann" kraxel@redhat.com, "Paolo Bonzini" pbonzini@redhat.com, "Eric Blake" eblake@redhat.com, "Andreas Färber" afaerber@suse.de 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.
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
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.
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
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.
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.
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 hutao@cn.fujitsu.com Date: Fri, 9 Aug 2013 16:23:54 +0800 Subject: [PATCH] pvpanic: disable pvpanic for some Windows versions
Signed-off-by: Hu Tao hutao@cn.fujitsu.com --- 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)
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 hutao@cn.fujitsu.com Date: Fri, 9 Aug 2013 16:23:54 +0800 Subject: [PATCH] pvpanic: disable pvpanic for some Windows versions
Signed-off-by: Hu Tao hutao@cn.fujitsu.com
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)
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 hutao@cn.fujitsu.com Date: Fri, 9 Aug 2013 16:23:54 +0800 Subject: [PATCH] pvpanic: disable pvpanic for some Windows versions
Signed-off-by: Hu Tao hutao@cn.fujitsu.com
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)
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 hutao@cn.fujitsu.com Date: Fri, 9 Aug 2013 16:23:54 +0800 Subject: [PATCH] pvpanic: disable pvpanic for some Windows versions
Signed-off-by: Hu Tao hutao@cn.fujitsu.com
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)
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
-
Andreas Färber -
Eric Blake -
Gerd Hoffmann -
Gleb Natapov -
Hu Tao -
Marcel Apfelbaum -
Markus Armbruster -
Michael S. Tsirkin -
Paolo Bonzini -
Stefan Hajnoczi -
Vadim Rozenfeld