[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 26.04.16 at 16:37, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----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.

It's an optimization, yes, but one that is quite important for keeping
certain (iirc) Windows versions running even with reasonably high
vCPU counts.

> 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?

That would be an option, but would duplicate state being tracked.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.