[SeaBIOS] ohci bulk?

[Avi Kivity]

  On 09/27/2010 07:33 PM, H. Peter Anvin wrote:
> On 09/27/2010 10:00 AM, Avi Kivity wrote:
> >>
> >>  The standard way to deal with this in the BIOS (and *only* the BIOS can
> >>  do this!) is to trap into SMM and have an SMI handler do the I/O.
> >>  Taking an SMI drops the CPU into big real mode regardless of what the
> >>  previous CPU mode was.
> >
> >  One problem is that kvm doesn't implement SMM at this point.
> >
> >  While we could do it (not going to be pleasant), it's not going to be
> >  present on many deployed machines.  I also don't see a way to detect SMM
> >  (I guess we could expose it via fwcfg).
> >
> >  What about the ISA DMA engine?
> >
>
> The ISA DMA engine can only access the bottom 16 MiB since it only has
> 24 address bits.

qemu's hw/dma.c appears to support 31 bits:

   int DMA_read_memory (int nchan, void *buf, int pos, int len)
   {
       struct dma_regs *r = &dma_controllers[nchan > 3].regs[nchan & 3];
       target_phys_addr_t addr = ((r->pageh & 0x7f) << 24) | (r->page << 
16) | r->now[ADDR];

(which may still not be enough)

> As far as KVM is concerned, if KVM doesn't wish to implement SMM (which
> really isn't all that hard -- it's pretty much a matter of dumping the
> state and undumping it on RSM; since SMM code is restricted to the
> firmware it doesn't necessarily have to be compatible with the native
> CPU)

SMM runs in big real mode, which we're only just starting to support on 
Intel.  Effectively it means we have to emulate every instruction.  
Dumping the state and restoring it is the simple part.

> KVM could simply implement a custom memory-moving device -- which
> would be faster to boot.

A virtio dma engine would be useful for other things as well.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.