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

Re: [Xen-devel] [PATCH] docs/design: introduce HVMMEM_ioreq_serverX types





On 2/26/2016 5:50 PM, Paul Durrant wrote:
-----Original Message-----
From: Yu, Zhang [mailto:yu.c.zhang@xxxxxxxxxxxxxxx]
Sent: 26 February 2016 09:37
To: Jan Beulich
Cc: Paul Durrant; xen-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH] docs/design: introduce
HVMMEM_ioreq_serverX types

On 2/26/2016 5:18 PM, Jan Beulich wrote:
On 26.02.16 at 07:59, <yu.c.zhang@xxxxxxxxxxxxxxx> wrote:
+Proposal
+========
+
+Because the number of spare types available in the P2M type-space is
+currently very limited it is proposed that
HVMMEM\_mmio\_write\_dm be
+replaced by a single new type HVMMEM\_ioreq\_server. In future, if
the
+P2M type-space is increased, this can be renamed to
HVMMEM\_ioreq\_server0
+and new HVMMEM\_ioreq\_server1, HVMMEM\_ioreq\_server2, etc.
types
+can be added.
+
+Accesses to a page of type HVMMEM\_ioreq\_serverX should be the
same as
+HVMMEM\_ram\_rw until the type is _claimed_ by an IOREQ server.
Furthermore

Sorry, do you mean even when a gfn is set to HVMMEM_ioreq_serverX
type,
its access rights in P2M still remains unchanged? So the new hypercall
pair, HVMOP_[un]map_mem_type_to_ioreq_server, are also
responsible for
the PTE updates on the access bits?

If it is true, I'm afraid this would be time consuming, because the
map/unmap will have to traverse all P2M structures to detect the PTEs
with HVMMEM_ioreq_serverX flag set. Yet in XenGT, setting this flag is
triggered dynamically with the construction/destruction of shadow
PPGTT.
But I'm not sure to which degree the performance casualties will be,
with frequent EPT table walk and EPT tlb flush.

No walking of EPT trees will be necessary in that case, just like it
already has been made unnecessary for other changes resulting
in various PTE attributes needing re-calculation. We'll only need
to extend the p2m_memory_type_changed() mechanism to cover
changes like this one.

So you mean when the access bits are to be updated, we can leverage
something like p2m_memory_type_changed(which I guess only deals with
memory types, not access bits) to avoid the walking of EPT trees? I'll
need to study this part.

No, the P2M is walked when the map/unmap hypercall is issued but, in the XenGT 
use-case, that hypercall is issued once at start of day and - if everything is 
working as it I believe it should - there won't actually be any pages of type 
HVMMEM_ioreq_server at that point, so no EPT flush is required.

Anyway, thanks for your advice. :)

I will post an implementation hopefully in the next few days once I've proved 
it works in my XenGT rig.

Great. Looking forward to this implementation, and thanks for your
help. :)

B.R.
Yu


_______________________________________________
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®.