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: Anthony Liguori
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 08:58:41 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

On 10/11/2011 08:45 AM, Avi Kivity wrote:
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?

tftp over slirp is probably slower than fwcfg.  It's been every time I looked.

Regards,

Anthony Liguori






reply via email to

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