On Sat, 2011-12-10 at 01:51 +0000, Mukesh Rathor wrote:> Hi,
>
> I have hybrid smp running with autoxlate. However, without autoxlate, I am
> running into issues realted to TLB flush. The guest in this case makes
> multicalls as part of which cache is flushed (__do_update_va_mapping,
> etc..). However, the guest is using VPIDs and it is getting complicated.
> I can just xen not do any TLB management and let the guest just do it
> after return from the hypercall. That would be simpler than hacking xen
> further to put in hooks for hybrid. However, before doing that, I am
wondering
> if there is even a usecase for hybrid without HAP. The only case I can
think
> of is dom0. For backend grant frames mapping with autoxlate/HAP, it would
> need to update the HAP for every frame, and don''t know if that
would be
> a significant overhead.
I hadn''t thought of that case. There was a talk on a related topic
("Moving Backend Drivers from Dom0 to HVM Domain") at XenSummit NA
2010
[0] by Jun Nakajima. I think this involved PV protocol changes though.
My (relatively uninformed) intuition is that a grant mapping for a HAP
domain is not going to be much different to a grant mapping for a PV
domain, it''s effectively the same operation, you are just modifying a
different set of pagetables is all. The relative cost of hypercalls in
PV vs Hybrid might be a factor. I think just measuring it is the way to
go.
[0] http://xen.org/xensummit/xensummit_spring_2010.html
> If not, then we don''t really have a use case for
> running hybrid autoxlate off, and no point in spending time on it.
My expectation (until you mentioned the above) was that the option to
run without HAP would be only really used as a debug aid or to measure
the specific impact of HAP so it wasn''t really that important if it
turned out to be hard.
I suppose there is also the use case of hardware where HAP is not
available although I think your numbers previously suggested that you
would be better off with full-PV rather than hybrid in this case?
Ian.
> Thanks for any input.
> Mukesh
>