qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 1/2] hw: report invalid disable-legacy|modern


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH v2 1/2] hw: report invalid disable-legacy|modern usage for virtio-1-only devs
Date: Mon, 20 May 2019 17:59:59 -0300
User-agent: Mutt/1.10.1 (2018-07-13)

On Mon, May 20, 2019 at 10:56:11AM +0100, Daniel P. Berrangé wrote:
> On Fri, May 17, 2019 at 04:01:29PM -0300, Eduardo Habkost wrote:
> > Hi,
> > 
> > Sorry for taking so long to look at this more closely:
> > 
> > On Fri, Feb 15, 2019 at 10:32:38AM +0000, Daniel P. Berrangé wrote:
> > > A number of virtio devices (gpu, crypto, mouse, keyboard, tablet) only
> > > support the virtio-1 (aka modern) mode. Currently if the user launches
> > > QEMU, setting those devices to enable legacy mode, QEMU will silently
> > > create them in modern mode, ignoring the user's (mistaken) request.
> > > 
> > > This patch introduces proper data validation so that an attempt to
> > > configure a virtio-1-only devices in legacy mode gets reported as an
> > > error to the user.
> > > 
> > > Checking this required introduction of a new field to explicitly track
> > > what operating model is to be used for a device, separately from the
> > > disable_modern and disable_legacy fields that record the user's
> > > requested configuration.
> > 
> > I'm still trying to understand why we need to add a new field.
> > 
> > If disable_modern, disable_legacy and mode are always expected to
> > be consistent with each other, why do we need another field?
> > 
> > If they are not always consistent with each other, when exactly
> > do we want them to be inconsistent, and why?
> 
> The pain point is that we're using the existing variables to record
> two distinct pieces of information
> 
>  - The user's request for modern vs legacy
>  - The PCI bus requirements for modern vs legacy
> 
> The existing code would overwrite the user's setting for
> "disable_legacy" when deciding whether the device is in
> a PCI or PCIe port. This happens in virtio_pci_realize.
> 
> We can only report errors with the user's requested config
> after the sub-classes call virtio_pci_force_virtio_1, but
> this doesn't happen until virtio_${subclass}_pci_release.
> 
> So by the time we're able to report errors, virtio_pci_realize
> has already overwritten the user's disable_legacy setting, so
> we've lost the very piece of info we need to check to report
> errors with.

Oh, that's the information I was missing.  Thanks!

> 
> Given the ordering of virtio_pci_realize vs the calls
> to virtio_pci_force_virtio_1 by subclasses, I don't see any
> option other than to use separate variables for the two
> distinct pieces of information.

We could replace the virtio_pci_force_virtio_1() calls with a new
VirtioDeviceClass::virtio_1_only boolean field, to be handled by
virtio_pci_realize() before overriding disable_legacy.

But this can be done as a follow up patch, so:

Reviewed-by: Eduardo Habkost <address@hidden>

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]