[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Turning off default storage devices?
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] Turning off default storage devices? |
Date: |
Thu, 17 Apr 2014 08:29:38 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) |
Andy Lutomirski <address@hidden> writes:
> On Mon, Apr 14, 2014 at 1:15 AM, Markus Armbruster <address@hidden> wrote:
>> Peter Crosthwaite <address@hidden> writes:
>>
>>> 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.
>>
>> USB has always been off by default, at least for the boards I'm familiar
>> with, due to the USB emulation's non-trivial CPU use.
>>
>> There's no such thing as a Q35 board without USB in the physical world.
>> Can't stop us from making a virtual one, of course.
>>
>> Likewise, there's no such thing as a Q35 board without AHCI in the
>> physical world, and again that can't stop us from making a virtual one.
>>
>> The difference to USB is that our q35 machines have always had AHCI even
>> with -nodefaults. You seem to propose adding a switch to disable AHCI,
>> yet leave it enabled with -nodefaults.
>>
>> -nodefaults should give you a board with all the optional components
>> suppressed.
>
> Will this break libvirt, which may expect -nodefaults to still come
> with an IDE bus?
Possibly.
>> On the one hand, I'd rather not add exceptions to -nodefaults "give me
>> the board with all its optional components suppressed" semantics.
>>
>> On the other hand, a few hundred ms are a long time.
>
> That's why I proposed a new option. Yes, it's ugly :/
Does real hardware take that long, too? Or is the delay some
virtualization artifact?