qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/22] Refactor machine support


From: Paul Brook
Subject: Re: [Qemu-devel] [PATCH 0/22] Refactor machine support
Date: Tue, 8 Jun 2010 04:12:08 +0100
User-agent: KMail/1.13.3 (Linux/2.6.33-2-amd64; KDE/4.4.3; x86_64; ; )

> This series introduces a rather radical change in the way we deal with
> machine definitions in QEMU.

I think we should aim to eliminate machine_register_core, and design 
appropriately.  In particular I'd try and avoid adding options that become 
trivially redundant once you can easily change the device trees.

I'm undecided how much parameterisation it's worth trying to support in the 
device tree. IMO the current code has way too much magic, because creating a 
new variant involves hacking and rebuilding pc.c.

I'm extremely tempted by the extreme approach of punting everything to an 
external device tree builder. i.e. remove automagical device reation 
altogether. If you want USB and 6 virtio disks then ask your device tree 
builder to create a machine description that includes pci-ohci and a bunch of 
virtio-blk-pci devices. The virtio-blk devices reference "drives" by id, so 
the same host configuration can be used with a scsi HBA. A small shell script 
should be sufficient to replicate the limited machine variants currently 
supported.

The problem with doing clever device tree generation/manipulation inside qemu 
is that for anything vaguely nonstandard you're likely to have to hack your 
own device tree anyway. Even ram allocation is nontrivial, e.g. the hole below 
4G on the PC, and that's before you start with numa-like layouts.

On a similar note, I don't see any point having machine_create_from_core,
we can just ship appropriate config files.

Paul



reply via email to

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