Re: [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Jan Beulich <JBeulich@suse.com>, Paul Durrant <paul.durrant@citrix.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>,
	xen-devel@lists.xen.org, zhiyuan.lv@intel.com,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.
Date: Thu, 11 Aug 2016 17:19:10 +0800	[thread overview]
Message-ID: <57AC430E.7050101@linux.intel.com> (raw)
In-Reply-To: <57AC5A3B0200007800104E81@prv-mh.provo.novell.com>

On 8/11/2016 4:58 PM, Jan Beulich wrote:
>>>> On 11.08.16 at 10:47, <yu.c.zhang@linux.intel.com> wrote:
>> On 8/10/2016 6:43 PM, Yu Zhang wrote:
>>> For " && p2mt != p2m_ioreq_server" condition, it is just to guarantee
>>> that if a write
>>> operation is trapped, and at the same period, device model changed the
>>> status of
>>> ioreq server, it should be discarded.
>> Hi Paul & Jan, any comments?
> Didn't Paul's "should behave like p2m_ram_rw" reply clarify things
> sufficiently?

Oh, I may have misunderstood. I thought he was talking about the p2m 
change race condition. :)

So please allow me to give a summary about my next to do for this:
1> To prevent p2m type change race condition, 
hvm_hap_nested_page_fault() need to
be changed so that p2m_unlock() can be triggered after the write 
operation is handled;

2> If a gfn with p2m_ioreq_server is trapped, but the current ioreq 
server has been unmapped,
it will be treated as a p2m_ram_rw;

3> If a gfn with p2m_ioreq_server is trapped, but the  dir is 
IOREQ_READ, it will be treated as a
read-modify-write case.

>>> A second thought is, I am now more worried about the " && dir ==
>>> IOREQ_WRITE"
>>> condition, which we used previously to set s to NULL if it is not a
>>> write operation.
>>> However, if HVM uses a read-modify-write instruction to operate on a
>>> write-protected
>>> address, it will be treated as both read and write accesses in
>>> ept_handle_violation(). In
>>> such situation, we need to emulate the read access first(by just
>>> returning the value being
>>> fetched either in hypervisor or in device model), instead of
>>> discarding the read access.
>> Any suggestions about this guest read-modify-write instruction situation?
>> Is my depiction clear? :)
> Well, from your earlier reply I concluded that you'd just go ahead
> and put this into patch form, which we'd then look at.

OK, thanks. I have give a rough summary in 3> above.

I will have to take several days annual leave from this weekend due to 
some family
urgency, and will be back after Aug 23. Can hardly seen the mailing list 
during this
period, sorry for the inconvenience.  :(

Yu

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