Re: [Xen-devel] [xen-unstable-smoke test] 92827: regressions - FAIL

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
[snip]
> >> Apr 26 10:56:02.583602 (XEN)    [<ffff82d0801d6b2c>]
> >> hvm_mmio_internal+0x37/0x61
> >
> > Ah. Crap. I forgot about this path....
> 
> So did I. And my testing didn't catch it because I have a post-4.7
> patch in place avoiding registration of the vMSI-X handler when
> there are no passed through devices, and on the box where I do
> use pass-through I normally run with debug=n.
> 
> >   I think the best way round this is to have vmsi register as an full io
> > interceptor so its accept method can use the passed in ioreq, which is faked
> > up to be a copy in this case. Either that or get rid of hvm_mmio_internal()
> > altogether.
> 
> Getting rid of it is not possible afaict.

IIRC it's an optimization to avoid p2m lookups (or other overhead) that would 
be pointless when the address is MMIO. Perhaps this could be avoided in another 
way e.g. by having certain emulators add their address ranges to a list and 
checking against that instead?

> And converting to a full I/O
> interceptor is a bad idea not just because of the backporting issue,
> but also because we really don't _want_ to snoop accesses coming
> through hvm_mmio_internal().
> 

True. I guess a small workaround is to check the vcpu ioreq state and make sure 
it's not 'none' before checking the type. In the case where hvm_mmio_internal 
is called there should be no emulation in progress so I think that would work.

  Paul

> Jan

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