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
