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

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

[Michael S. Tsirkin]

On Mon, Aug 05, 2013 at 07:04:22PM +0300, Gleb Natapov wrote:
> On Mon, Aug 05, 2013 at 06:03:34PM +0300, Michael S. Tsirkin wrote:
> > On Mon, Aug 05, 2013 at 12:20:44PM +0300, Gleb Natapov wrote:
> > > On Mon, Aug 05, 2013 at 12:18:26PM +0300, Michael S. Tsirkin wrote:
> > > > On Mon, Aug 05, 2013 at 11:16:17AM +0300, Gleb Natapov wrote:
> > > > > On Mon, Aug 05, 2013 at 11:10:55AM +0300, Michael S. Tsirkin wrote:
> > > > > > On Mon, Aug 05, 2013 at 03:47:23PM +0800, Hu Tao wrote:
> > > > > > > pvpanic device is an internal default device in qemu. It may cause
> > > > > > > problem when upgrading qemu from a version without pvpanic.
> > > > > > > 
> > > > > > > for example: in Windows(let's say XP) the Device manager will open a
> > > > > > > "new device" wizard and the device will appear as an unrecognized
> > > > > > > device.  On a cluster with hundreds of such VMs, If that cluster has
> > > > > > > a health monitoring service it may show all the VMs in a "not healthy"
> > > > > > > state.
> > > > > > > 
> > > > > > > This patch is a workaround to not show pvpanic in UI to avoid the
> > > > > > > problem in Windows.
> > > > > > > 
> > > > > > > Cc: Marcel Apfelbaum <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.

-- 
MST

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

[Gleb Natapov]

On Mon, Aug 05, 2013 at 09:32:18PM +0300, Michael S. Tsirkin wrote:
> > > As you see we do let people change many parameters
> > > that do affect activation.
> > By editing XML user can shoot himself in the foot, we should not prevent
> > that.
> 
> So that's what I'm saying basically.
> At the moment there's no way to remove this device from XML.
> That's just wrong.
Can say the same about PV acpi hotpulg device.

> In QEMU, we have a standard way to specify devices with -device.
> That should be the interface for anything new really
> unless there's a very compelling reason for something else.
We are disagree on compelling reason in this case obviously.

> *Not* building it into the PC machine type.
> 
> > It should not be required though.
> 
> libvirt can pass -device pvpanic by default if nothing
> is specified in XML. That discussion really has to happen
> on libvirt list.
> 
As Paolo said you are just pushing the "problem" up the stack
where it is harder to "solve". I put "problem" and "solve" in
quotes because I disagree that the problem that need to be solved
is identified correctly. The correct problem to be solved IMO is
writing Windows driver for the device.

--
			Gleb.

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

[Vadim Rozenfeld]

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

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

[Gleb Natapov]

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.

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

[Vadim Rozenfeld]

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

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

[Gleb Natapov]

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.

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

[Michael S. Tsirkin]

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

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

BTW pls keep qemu-devel Cc'd.

> We have different definition of "damage" though.

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

-- 
MST

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

[Gleb Natapov]

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

> Besides, both -device pvpanic and use of ioport=0 to disable it
> are completely undocumented.
> 
Not the only undocumented thing in QEMU command line :)

> BTW pls keep qemu-devel Cc'd.
> 
Haven't touched CC list.

> > We have different definition of "damage" though.
> 
> Driver bugs, qemu bugs, OSPM bugs all can cause issues
> like OS crashes, suspend/resume issues, bad
> performance ... What's your definition of damage?
> 
None of those cover the case at hand.

--
			Gleb.

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

[Andreas Färber]

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

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

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

Andreas

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

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

[Michael S. Tsirkin]

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

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


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

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

[Gleb Natapov]

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

> I am neutral as to whether qemu-system-x86_64 should have it enabled by
> default or not. But if we want to suppress it, then -nodefaults should
> disable it. Since libvirt uses that though, it would mean libvirt would
> need to add it back, whether via user's XML domain config or by libvirt
> itself based on some version/etc. heuristics.
> 
There is no clear definition of what -nodefaults should or should not
do. Should it disable PV ACPI hotplug device? Should it create a machine
with no mmio/io regions registered at all?

--
			Gleb.

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

[Michael S. Tsirkin]

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

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

> 
> --
> 			Gleb.

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

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

[Andreas Färber]

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

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

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

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

Andreas

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

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

[Markus Armbruster]

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 should
> disable it.

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

ioport=0 affecting _STA is *not* "removing" the device, it's changing
how the device is exposed to the guest.  No opinion on whether it's a
good idea or not.

>             Since libvirt uses that though, it would mean libvirt would
> need to add it back, whether via user's XML domain config or by libvirt
> itself based on some version/etc. heuristics.

Doubt that'll be a problem for libvirt.

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

[Michael S. Tsirkin]

On Tue, Aug 06, 2013 at 11:56:11AM +0200, Markus Armbruster wrote:
> Andreas Färber <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.

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

[Michael S. Tsirkin]

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

It doesn't have anything to do with _STA: device still appears in QOM.
It's a QEMU issue, devices that are added with -device are
documented in -device help and removed by dropping them from
command line. Devices added by default have no way to
be dropped from QOM except -nodefaults.

> > Besides, both -device pvpanic and use of ioport=0 to disable it
> > are completely undocumented.
> > 
> Not the only undocumented thing in QEMU command line :)

All -device fields are documented with -device help.
This was supposed to be the right way to add
all new devices.


> > BTW pls keep qemu-devel Cc'd.
> > 
> Haven't touched CC list.
> 
> > > We have different definition of "damage" though.
> > 
> > Driver bugs, qemu bugs, OSPM bugs all can cause issues
> > like OS crashes, suspend/resume issues, bad
> > performance ... What's your definition of damage?
> > 
> None of those cover the case at hand.

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


> --
> 			Gleb.

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

[Gleb Natapov]

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

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

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

--
			Gleb.

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

[Michael S. Tsirkin]

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

I really meant disable adding it.

> So does -global pvpanic,ioport=0
> disables the device for you?

What do you mean by disabled?

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

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

We wanted to fix the later issue for a long time, it's
hard to fix - that's why we don't fix that.
Just using -device for everything is a work-around for now.

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

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

> --
> 			Gleb.

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

[Gleb Natapov]

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

> We wanted to fix the later issue for a long time, it's
> hard to fix - that's why we don't fix that.
> Just using -device for everything is a work-around for now.
> 
That's workaround that makes usability suffer, not a good compromise.

Anyway the thread is started by assertion that the device breaks guests
which it does not, now we moved to documentation realm which should not
have any say about default machine functionality.

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

--
			Gleb.

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

[Andreas Färber]

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

We have -M none to create an empty machine.

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

Andreas

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

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

[Gleb Natapov]

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

--
			Gleb.

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

[Markus Armbruster]

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.

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

[Gleb Natapov]

On Tue, Aug 06, 2013 at 01:48:17PM +0200, Markus Armbruster wrote:
> Gleb Natapov <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.

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

[Michael S. Tsirkin]

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

Wasn't this fixed recently?

> One practical reason not to create everything via config is that we
> cannot create SysBusDevices via -device when they require MMIO mapping
> or IRQ setup. For ISADevices such as pvpanic that's not a problem.
> Anthony has proposed QOM'ifying MemoryRegions and qemu_irq as solution
> to do the wiring-up from command line or config file, but those attempts
> got stuck a long time ago.
> 
> Andreas
> 
> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

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

[Andreas Färber]

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

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

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

Andreas

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

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

[Stefan Hajnoczi]

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

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

Stefan

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

[Gerd Hoffmann]

  Hi,

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

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

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

Sometimes things are a bit odd for historical reasons:

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

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

cheers,
  Gerd

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

[Gleb Natapov]

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

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

--
			Gleb.

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

[Andreas Färber]

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

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

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

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

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

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

Andreas

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

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

[Gleb Natapov]

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

> way for us to document there that port=0 has special meaning of "disable
> this device in ACPI".
> 
Adding capability to describe a property should solve that and is a good
idea regardless, no? "pvpanic.ioport=uint16" is not very descriptive.


> Disabling a device usually requires to not include that device (or in
> the future to "unrealize" it), which would require some way to suppress
> having the device created internally by default. As done for floppy,
> serial, etc. devices in x86 IIUC, which are in the same PIO situation as
> the pvpanic device, except that they represent physical devices.
> Adding some -no-pvpanic switch might be an alternative. And if not done
> already, disabling the pvpanic device should definitely be documented
> for the man page.
We should not add -no-pvpanic! If there is a legitimate use for
-no-pvpanic we should go with MST suggestion and do not create it by
default. The question is why would anyone use -no-pvpanic? Legit reason,
not just "to remove pvpanic".

> 
> To me this is less a concrete problem with Windows guests but a
> conceptual question of how we go about enabling/disabling QEMU devices
> in a hopefully consistent way.
Agree. Now I see that some devises always present (even with -nodefualts)
and some do not. The logic is not clear, but seams to be: if there is
not legit reason to disable device or for stable topology device
placemen need to be controlled, disable it with -nodefualts. In that
case I do not see why pvpanic would not be always present.

The reason this whole thread started with is non issue.

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

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

--
			Gleb.

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

[Andreas Färber]

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

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

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

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

HTE,
Andreas

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

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

[Gleb Natapov]

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

> There have been IPMI patchsets on qemu-devel though, and SUSE will be
> investigating adding some IPMI support too (not sure if identical to the
> scope of those patchsets), whether IPMI is complicated or not. It's a
> standard present on physical servers, facilitating unified management of
> virtual and physical servers, and there's OpenIPMI as implementation.
> 
Of course, there is nothing wrong with implementing IPMI either. Many
problems that IPMI solves are much simpler to solve in virtualized
environment with management software and pvpanic closes one gap
between what IPMI provides and virtual machine management can do.

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

--
			Gleb.

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

[Gerd Hoffmann]

  Hi,

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

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

cheers,
  Gerd

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

[Michael S. Tsirkin]

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

PV always seems easier. It sometimes becomes a maintainance problem
down the way though.

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

But will you want pvpanic if you have IPMI?

> --
> 			Gleb.

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

[Gleb Natapov]

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

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

--
			Gleb.

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

[Andreas Färber]

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

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

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

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

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

Andreas

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

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

[Michael S. Tsirkin]

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

To be able to emulate a real hardware system without any PV devices.
I think it's a reasonable requirement.

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

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

[Gleb Natapov]

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

--
			Gleb.

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

[Hu Tao]

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

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

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

[Gleb Natapov]

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

--
			Gleb.

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

[Michael S. Tsirkin]

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

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

> --
> 			Gleb.

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

[Gleb Natapov]

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

--
			Gleb.

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

[Michael S. Tsirkin]

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

In ACPI? Why have it at all?

> You asked if the device
> can be enable/disable above, not removed. It can.

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

> --
> 			Gleb.

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

[Gleb Natapov]

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

> > You asked if the device
> > can be enable/disable above, not removed. It can.
> 
> I really meant QOM/QMP. _STA is only seen by OSPM.
> 
Then you should have said "removed". No you cannot, this is not the only
such device. I do not see why would you want to though.

--
			Gleb.