qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Turning off default storage devices?


From: Andy Lutomirski
Subject: Re: [Qemu-devel] Turning off default storage devices?
Date: Sun, 13 Apr 2014 09:44:11 -0700

On Wed, Apr 9, 2014 at 8:13 PM, Peter Crosthwaite
<address@hidden> wrote:
> On Thu, Apr 10, 2014 at 9:57 AM, Andy Lutomirski <address@hidden> wrote:
>> On Wed, Apr 9, 2014 at 4:53 PM, Peter Crosthwaite
>> <address@hidden> wrote:
>>> Hi Andy,
>>>
>>> On Thu, Apr 10, 2014 at 5:55 AM, Andy Lutomirski <address@hidden> wrote:
>>>> Currently, -M q35 boots linux quite a bit slower than the default
>>>> machine type.  This seems to be because it takes a few hundred ms to
>>>> determine that there's nothing attached to the AHCI controller.
>>>>
>>>> In virtio setups, there will probably never be anything attached to
>>>> the AHCI controller.  Would it be possible to add something like
>>>> -machine default_storage=off to turn off default storage devices?
>>>> This could include the AHCI on q35 and the cdrom and such on pc.
>>>>
>>>> There's precedent: -machine usb=off turns off the default USB
>>>> controllers, which is great for setups that use xhci.
>>>>
>>>
>>> Is there a more generic solution to your problem? Can you implement
>>> command line device removal in a non specific way and avoid having to
>>> invent AHCI or even "storage" specific arguments. You could
>>> considering bringing the xhci use case you mentioned under the same
>>> umbrella.
>>
>> An option like -suppress-default-device foobar to turn off the device
>> named foobar would work, but what happens if that device is a bus?
>
> Lets call that a misuse in the first instance. But in general, when
> attaching devices QEMU should be able to gracefully fail on unresolved
> deps. So it would be reasonable to work on that assumption given that
> every device should be able to handle a missing bus/gpio/interrupt
> etc. due to -device misuseability.
>
>> Will this just cause QEMU to crash?  Maybe the machine code would have
>> to opt in to allowing this kind of suppression, and there could be a
>> general error of you try to suppress a device that can't be
>> suppressed.
>>
>
> I would argue that there is no such thing. You may end up with a
> useless machine but its still valid to supress something and then by
> extension all its dependants are non functional.

The q35 code is:

    /* ahci and SATA device, for q35 1 ahci controller is built-in */
    ahci = pci_create_simple_multifunction(host_bus,
                                           PCI_DEVFN(ICH9_SATA1_DEV,
                                                     ICH9_SATA1_FUNC),
                                           true, "ich9-ahci");
    idebus[0] = qdev_get_child_bus(&ahci->qdev, "ide.0");
    idebus[1] = qdev_get_child_bus(&ahci->qdev, "ide.1");

It looks like making pci_create_simple_multifunction return null will
crash quite quickly.  Even fixing the next two lines will just cause
null pointer dereferences later on.

Is there a different way to indicate that a device wasn't actually created?

--Andy



reply via email to

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