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: Markus Armbruster
Subject: Re: [Qemu-devel] Turning off default storage devices?
Date: Thu, 17 Apr 2014 16:21:56 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Eric Blake <address@hidden> writes:

> On 04/16/2014 09:40 AM, Andy Lutomirski wrote:
>
>>> 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?
>
> Libvirt can be taught to deal with whatever default devices are present
> vs. mising according to -nodefaults; although the IDEAL situation is
> that there would be some QMP command for querying what devices are
> present when -nodefaults is used, so that libvirt can reliably supply
> all remaining devices.  As long as there is a way to tell between older
> qemu that always supplied AHCI and your proposed newer qemu that omits
> it for -nodefaults, libvirt should be fine with this proposal.

Right now, the only way to learn about a machine type's devices is to
create a machine, then inspect the result.  Likely to remain that way as
long as the definite machine specification is the code that builds it.

Same for finding out what the many options that influence the machine
building actually do.

You should be able to inspect with qom-get & friends.  If that's not
enough, we should talk.



reply via email to

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