qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Slow kernel/initrd loading via fw_cfg; Was Re: Hack int


From: Avi Kivity
Subject: Re: [Qemu-devel] Slow kernel/initrd loading via fw_cfg; Was Re: Hack integrating SeaBios / LinuxBoot option rom with QEMU trace backends
Date: Tue, 11 Oct 2011 15:45:48 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0

On 10/11/2011 03:29 PM, Anthony Liguori wrote:
> On 10/11/2011 08:23 AM, Avi Kivity wrote:
>> On 10/11/2011 03:19 PM, Anthony Liguori wrote:
>>>> No, DMA has a lot bigger granularities in kvm/user interaction. We
>>>> can easily DMA a 50MB region with a single kvm/user exit. For PIO we
>>>> can at most do page granularity.
>>>
>>>
>>> So make a proper PCI device for kernel loading.  It's a much more
>>> natural approach and let's use alias -kernel/-initrd/-append to
>>> -device kernel-pci,kernel=PATH,initrd=PATH
>>
>> This is overkill.  First let's optimize rep/movs before introducing any
>> more interfaces.  If that doesn't work, then we can have a dma interface
>> for fwcfg.  But a new pci device?
>
> This is how it would work on bare metal.  Why is a PCI device overkill
> compared to a dma interface for fwcfg?
>

Because it's a limited use case, despite all the talk around it.

> If we're adding dma to fwcfg, then fwcfg has become far too complex
> for it's intended purpose.
>

I have to agree to that.

btw, -net nic,model=virtio -net user is an internal DMA interface we
already have.  We can boot from it. Why not use it?

-- 
error compiling committee.c: too many arguments to function




reply via email to

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