Re: [Qemu-devel] [PATCH 09/26] ehci: Use uframe precision for interrupt threshold checking

[Hans de Goede]

Hi,

On 12/17/2012 03:51 PM, Gerd Hoffmann wrote:
> On 12/17/12 15:47, Hans de Goede wrote:
> > Hi,
> >
> > On 12/17/2012 03:39 PM, Gerd Hoffmann wrote:
> > > On 12/17/12 15:23, Hans de Goede wrote:
> > > > Hi,
> > > >
> > > > On 12/17/2012 02:16 PM, Gerd Hoffmann wrote:
> > > > > On 12/14/12 14:35, Hans de Goede wrote:
> > > > > > Note that a shadow variable is used instead of changing frindex to
> > > > > > uframe accuracy because we must send a frindex which is a multiple
> > > > > > of 8
> > > > > > during migration for migration compatibility, and rounding it down to
> > > > > > a multiple of 8 pre-migration, can lead to frindex going backwards
> > > > > > from
> > > > > > the guest pov.
> > > > >
> > > > > Jumping forward instead?
> > > >
> > > > You mean rounding the send frindex up pre-migration, I didn't really
> > > > consider
> > > > that as it will cause us skipping processing an entry in the periodic
> > > > frame
> > > > list. I guess doing that on migration isn't too bad. OTOH giving the
> > > > guest
> > > > only frame accuracy like we've been doing till now also works fine...
> > > >
> > > > Your choice :)
> > >
> > > I'm looking for a way to avoid the shadow variable, but of course
> > > without breaking migration.  giving the guest only frame accuracy looks
> > > good to me.
> >
> > Ok, but then we need the shadow variable, iow then the patch stays as is
> > ...
>
> Can't we (a) switch frindex to microframe resolution, (b) round to frame
> resolution in pre_save and (c) return frindex & ~7 on guest register reads?

Ah yes we can. I thought about that myself, but I was under the impression
that we were using mmap tricks to allow the guest to read the ioregs directly
without going through a vmexit. But it turns out we've:

static uint64_t ehci_opreg_read(void *ptr, hwaddr addr,
                                unsigned size)
{
    EHCIState *s = ptr;
    uint32_t val;

    val = s->opreg[addr >> 2];
    trace_usb_ehci_opreg_read(addr + s->opregbase, addr2str(addr), val);
    return val;
}

Can qemu not handle an mmio range where writes are trapped, but reads are
not? That would force the use of the shadow variable, but should otherwise
provide a nice speedup.

Regards,

Hans