Re: [Qemu-devel] Slow kernel/initrd loading via fw_cfg; Was Re: Hack integrating SeaBios / LinuxBoot option rom with QEMU trace backends

[Anthony Liguori <anthony@codemonkey.ws>]

On 10/11/2011 09:01 AM, Daniel P. Berrange wrote:
> On Tue, Oct 11, 2011 at 08:19:14AM -0500, Anthony Liguori wrote:
>> On 10/11/2011 08:14 AM, Alexander Graf wrote:
>>>>>>> And I don't see the point why we would have to shoot yet another hole into the guest just because we're too unwilling to make an interface that's perfectly valid horribly slow.
>>>>>>
>>>>>> rep/ins is exactly like dma+wait for this use case: provide an address, get a memory image in return.  There's no need to add another interface, we should just optimize the existing one.
>>>>>
>>>>> Whatever we do, the interface will never be as fast as DMA. We will always have to do sanity / permission checks for every IO operation, can batch up only so many IO requests and in QEMU again have to call our callbacks in a loop.
>>>>
>>>> rep/ins is effectively equivalent to DMA except in how it's handled within QEMU.
>>>
>>> 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
>
> Adding a PCI device doesn't sound very appealing, unless you
> can guarentee it is never visible to the guest once LinuxBoot
> has finished its dirty work,

It'll definitely be guest visible just like fwcfg is guest visible.

Regards,

Anthony Liguori

  so mgmt apps don't have to worry
> about PCI addressing wrt guest ABI.
>
>
> Daniel