Re: [Xen-devel] Possible issue with x86_emulate when writing results back to memory

[Simon Graham <simon.graham@xxxxxxxxxx>]

> > Well, that one is tough and I don't have a good answer... the only thing I
> would say is that in our system we ALWAYS have the shadow memory
> tracking enabled (to track changes to framebuffers)
> 
> Full shadow, or just logdirty?
> 
> With logdirty, frequent pagefaults will occur (which are costly in terms
> of vmexits), but I would not expect emulation to occur.
> 
> Even with full shadow, emulation only kicks in for non-standard RAM,
> which is basically IO to qemu, and instructions trying to write to the
> pagetables themselves, which are trapped and emulated for safety reasons.
> 

logdirty (somewhat modified to enable multiple framebuffers to be tracked).

I agree that it _shouldn't_ end up emulating -- but the shadow page fault 
routine has a ton of code paths that I've never managed to fully grok 

(As an aside, I've previously looked at other cases where the shadow code ends 
up emulating instructions that are unexpected that cause VMs to hang because 
the shadow module doesn't have a proper implementation of the x86_emulate 
callbacks... e.g. if you try to run the old MS Virtual Server product inside a 
Xen VM that has logdirty enabled it _will_ hard hang).

> > My concern was that memcpy is (I assume!) highly optimized - it certainly
> should be if it isn't and I would worry that a change to make it atomic for 
> the
> purposes of instruction emulation would result in an across the board perf hit
> when in most cases it isn't necessary that it be atomic.
> >
> > This would be fine for the writeback code in the shadow module BUT the
> __hvm_copy routine is used generically in situations where atomicity is not
> required...
> 
> __hvm_copy() is probably too low to be thinking about this.  There are
> many things such as grant_copy() which do not want "hardware like" copy
> properties, preferring instead to have less overhead.
> 

Yeah... I'll rework the patch to do this...

> ~Andrew

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