Add a new xc function to destroy the shadow pages table for a given guest. Signed-off-by: Jean Guyader <jean.guyader@gmail.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Add a new xc function to destroy the shadow pages table for a given guest from userspace. Signed-off-by: Jean Guyader <jean.guyader@gmail.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
At 10:57 +0100 on 10 May (1336647456), Jean Guyader wrote:> Add a new xc function to destroy the shadow pages table for a given > guest from userspace.Looks OK, but what will it be used for? There might be some more appropriate semantics at the hypercall interface than exposing the shadow internals as such. Cheers, Tim.
Jean Guyader
2012-May-10 10:49 UTC
Re: [PATCH] xen: expose shadow_blow_tables to userspace
On 10 May 2012 11:37, Tim Deegan <tim@xen.org> wrote:> At 10:57 +0100 on 10 May (1336647456), Jean Guyader wrote: >> Add a new xc function to destroy the shadow pages table for a given >> guest from userspace. > > Looks OK, but what will it be used for? There might be some more > appropriate semantics at the hypercall interface than exposing the > shadow internals as such. >It''s related to the use of hvm_set_mem_pinned_cacheattr to set the default caching policy when a guest starts to use a given gfn. If this function is called after the guest has mapped the gfn it won''t have any affect. The easy and surely not the best way to fix this is to destroy all the shadow page tables for this domain. Maybe the ideal thing to do would be to make the cacheattr code aware of the shadow page table and only clear the relevant set of shadow pages. Jean
At 11:49 +0100 on 10 May (1336650549), Jean Guyader wrote:> On 10 May 2012 11:37, Tim Deegan <tim@xen.org> wrote: > > Looks OK, but what will it be used for? There might be some more > > appropriate semantics at the hypercall interface than exposing the > > shadow internals as such. > > It''s related to the use of hvm_set_mem_pinned_cacheattr to set the default > caching policy when a guest starts to use a given gfn. > > If this function is called after the guest has mapped the gfn it won''t > have any affect. > The easy and surely not the best way to fix this is to destroy all the > shadow page > tables for this domain. > > Maybe the ideal thing to do would be to make the cacheattr code aware > of the shadow page table and only clear the relevant set of shadow pages.Yes, I think that would be much better. That way we don''t rely on the tools to maintain cache-attribute consistency within the hypervisor. You could use sh_remove_shadows() to unmap just the frames you want, but that will only make sense if the number of frames is small, since it may end up walking all the shadows searching for mappings each time. So if the hvm_set_mem_pinned_cacheattr() isn''t going to be called very often, it would be OK just to call shadow_blow_tables_per_domain(). Cheers, Tim.