Re: [Xen-devel] [PATCH]RFC: VGA accleration using shadow PTE D-bit to construct LFB dirty bitmap

[Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>]

Hi,

At 18:41 +0800 on 30 Jul (1185820874), Huang, Xinmei wrote:
> > - Figure out the VA of the writable mapping of the LFB.
> > - When asked for the bitmap, walk the shadow linear page tables of the
> 
> When current != vcpu-of-guest, can we use this mechanism or map_shadow_page() 
> to access shadow pages?

Ah, yes, we'd need to either walk the guest's shadow pagetable
explicitly or cause the bitmap to be generated by one of guest's vcpus
(ugh!).

> >That involves a single equality test in sh_page_fault() to spot the VA,
> 
> Guest's va mapped to LFB is assumed to be invariable? 

Not necessarily.  Every time we see a write fault to new VA mapping the
LFB we can move it.  (I expect that not to happen very often.)

> Any more comments on this patch?  Does the Pinned-LFB-shadow idea make sense?

It would be possible, but at the moment "pinnable" pages are defined
entirely by their type, with this one hack to allow 64bit l3s to be
pinnable if we think we're looking at an old linux kernel.  So you'd
either need another shadow type, or for all users of the up-pointer to
be able to check whether the l1 they're looking at has vram mapping in it.

If there is one kernel-mode mapping of the LFB, though, I'd expect it to
be fairly rarely torn down; it would need the shadows of all processes
that were ever running when the kernel touched the video RAM to be
reaped.  So just marking the page dirty when you make or tear down a
vram mapping should be better.

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, XenSource UK Limited
Registered office c/o EC2Y 5EB, UK; company number 05334508

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel