On Tue, Oct 11, 2011 at 08:17:28AM -0500, Anthony Liguori wrote:
> On 10/11/2011 04:55 AM, Avi Kivity wrote:
> >On 10/11/2011 11:50 AM, Gleb Natapov wrote:
> >>On Tue, Oct 11, 2011 at 11:26:14AM +0200, Avi Kivity wrote:
> >>> 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.
> >>>
> >>rep/ins cannot be optimized to be as efficient as dma and remain to
> >>be correct at the same time. There are various corner cases that
> >>simplified "fast" implementation will likely miss. Like DF flag
> >>settings, delaying interrupts for too much, doing ins/outs to/from
> >>iomem (this is may be not a big problem unless userspace finds a way
> >>to trigger it). There are ways that current implementation can be
> >>optimized still though.
> >
> >These can all go through the slow path, except interrupts, which need to be
> >checked after every access.
> >
> >>But loading MBs of data through fw_cfg interface is just abusing it.
> >>You wouldn't use pio on real HW to move megabytes of data and expect
> >>good performance.
> >
> >True, this is a point in favour of a true dma interface.
>
> Doing kernel loading through fw_cfg has always been a bit ugly.
>
> A better approach would be to implement a PCI device with a ROM bar
> that contained an option ROM that read additional bars from the
> device to get at the kernel and initrd.
I thought about this too. But sizes of initrd people mentioning here
a crazy. We can run out of pci space very quickly. We can implement one
of the BARs as sliding window into initrd though.
>
> That also enables some potentially interesting models like having
> the additional bars be optionally persisted letting a user have
> direct control over which kernel/initrds were loaded. It's
> essentially a PCI device with a flash chip on it that contains a
> kernel/initrd.
>
--
Gleb.
