Re: [Xen-devel] [PATCH v4 17/17] x86/hvm: track large memory mapped accesses by buffer offset

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.06.15 at 12:51, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 25 June 2015 11:47
>> To: Paul Durrant
>> Cc: Andrew Cooper; xen-devel@xxxxxxxxxxxxxxxxxxxx; Keir (Xen.org)
>> Subject: Re: [PATCH v4 17/17] x86/hvm: track large memory mapped
>> accesses by buffer offset
>> 
>> >>> On 24.06.15 at 13:24, <paul.durrant@xxxxxxxxxx> wrote:
>> > @@ -621,14 +574,41 @@ static int hvmemul_phys_mmio_access(
>> >
>> >      for ( ;; )
>> >      {
>> > -        rc = hvmemul_do_mmio_buffer(gpa, &one_rep, chunk, dir, 0,
>> > -                                    *buffer);
>> > -        if ( rc != X86EMUL_OKAY )
>> > -            break;
>> > +        /* Have we already done this chunk? */
>> > +        if ( (*off + chunk) <= vio->mmio_cache[dir].size )
>> 
>> I can see why you would like to get rid of the address check, but
>> I'm afraid you can't: You have to avoid getting mixed up multiple
>> same kind (reads or writes) memory accesses that a single
>> instruction can do. While generally I would assume that
>> secondary accesses (like the I/O bitmap read associated with an
>> OUTS) wouldn't go to MMIO, CMPS with both operands being
>> in MMIO would break even if neither crosses a page boundary
>> (not to think of when the emulator starts supporting the
>> scatter/gather instructions, albeit supporting them will require
>> further changes, or we could choose to do them one element at
>> a time).
> 
> Ok. Can I assume at most two distinct set of addresses for read or write? If 
> so then I can just keep two sets of caches in the hvm_io struct.

If we can leave out implicit accesses (like the one mentioned)
as well as stack ones, then there shouldn't be more than two
(disjoint) reads and one write per instruction, but each possibly
crossing a page boundary. 

If we want to support stacks in MMIO, enter and leave would
extend that set, as would said implicit accesses. Of course we
should take into consideration what currently works, and I
think both stack and implicit accesses would currently work as
long as they're aligned (as misalignment would be the only
reason for them to get split up - they're never wider than a
long). I.e. you may want to consider avoiding any ASSERT()s
or other conditionals potentially breaking these special cases.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel