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

[Hans de Goede <hdegoede@redhat.com>]

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