qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC 0/9] Introduce light weight PC platform pc-lite


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC 0/9] Introduce light weight PC platform pc-lite
Date: Mon, 20 Jun 2016 08:54:10 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0


On 20/06/2016 08:01, Chao Peng wrote:
> On Fri, Jun 17, 2016 at 03:24:59PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 17/06/2016 10:14, Chao Peng wrote:
>>> Basically:
>>> - it removes old ISA devices and support only PCI devices;
>>
>> I think you need to keep at least the RTC, otherwise where does Linux
>> get the time of day from?
> 
> PV clock will provide that.

It's KVM only, though.  Sometimes TCG is useful for debugging.

>> Lack of 8250/16550 means lack of earlyprintk.  I know the driver is slow
>> though, so I understand that.
> 
> Understand, it might be a little bit hard for debugging, one solution
> would be adding 8250/16550 in debug build?

The serial port is optional anyway, it's not there unless you specify
"-serial stdio" or similar.

> We actually have patches for Q35 + ICH9 and it does exactly the same
> thing you described here. Adding a new one is just:
>  1). to keep both Q35 and 'lite' code clean, and
>  2). don't expose two different Q35 implementations to guest.

It would be nice to at least see the patches. :)

I think a lightweight q35 platform that can run the usual firmware could
be acceptable in QEMU.

>> 2) this:
>>
>>> - it loads guest kernel directly, no BIOS, no bootloader, no realmode
>>>   code;
>>
>> ... which is related to Linux-only support.  How much does this gain
>> over a minimal firmware (either SeaBIOS with the fw_cfg DMA interface,
>> or qboot with cbfs in parallel flash)?
> 
> We have tried Q35 version (as described above) with both SeaBIOS and qboot.
> The 'perfect' time with optimized BIOS we have seen is ~15ms, with the
> additional time in kernel real mode code, the total time overhead comparing
> to current Linux-aware implementation is more than 40ms. This sounds still
> a little too much for us.

I guess it is related to real mode decompression code?

My main issue is that there are other things that the firmware does.
Not all of them are necessary (e.g. SMRAM is not needed, most PCI
devices need not be initialized), but in general we don't like putting
code in QEMU that modifies the guest state.  For example another Intel
person is adding code to SeaBIOS that initializes the feature control MSR.

I wonder if Linux could run as a multiboot-compliant ELF file, and what
the performance would be...  Multiboot omits the real mode stub.

Paolo



reply via email to

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