Re: [Xen-devel] [PATCH v6 08/16] x86/hvm: unify stdvga mmio intercept with standard mmio intercept

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.07.15 at 11:00, <Paul.Durrant@xxxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 09 July 2015 09:53
>> >>> On 03.07.15 at 18:25, <paul.durrant@xxxxxxxxxx> wrote:
>> > --- a/xen/arch/x86/hvm/emulate.c
>> > +++ b/xen/arch/x86/hvm/emulate.c
>> > @@ -266,6 +266,15 @@ static int hvmemul_acquire_page(unsigned long
>> gmfn, struct page_info **page)
>> >          return X86EMUL_RETRY;
>> >      }
>> >
>> > +    /* This code should not be reached if the gmfn is not RAM */
>> > +    if ( p2m_is_mmio(p2mt) )
>> > +    {
>> > +        domain_crash(curr_d);
>> > +
>> > +        put_page(*page);
>> > +        return X86EMUL_UNHANDLEABLE;
>> > +    }
>> > +
>> >      return X86EMUL_OKAY;
>> >  }
>> 
>> Does this change really belong here, not in an earlier patch?
>> 
> 
> It could be, but it's always been in this patch because this is the one 
> where I apparently remove code that handled MMIO <-> MMIO copying so I think 
> it's most illustrative to leave it here.

Okay then.

>> > +    if ( !s->cache )
>> > +        goto done;
>> 
>> Why is this not being dealt with by stdvga_mem_accept()?
>> 
> 
> Because, as the big lock comment below states:
> 
> "Single-cycle write transactions are accepted even if the cache is
> not active since we can assert, when in stdvga mode, that writes
> to VRAM have no side effect and thus we can try to buffer them"

Ah, right, thanks for connecting the two together for me.

Jan


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