Re: [PATCH v2 3/3] 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: "Tian, Kevin" <kevin.tian@intel.com>,
	Jan Beulich <jbeulich@suse.com>,
	"paul.durrant@citrix.com" <paul.durrant@citrix.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>
Cc: "keir@xen.org" <keir@xen.org>,
	"george.dunlap@eu.citrix.com" <george.dunlap@eu.citrix.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"tim@xen.org" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Lv, Zhiyuan" <zhiyuan.lv@intel.com>
Subject: Re: [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
Date: Tue, 19 Apr 2016 17:15:18 +0800	[thread overview]
Message-ID: <5715F726.5070306@linux.intel.com> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D15F821907@SHSMSX101.ccr.corp.intel.com>

On 4/19/2016 12:50 PM, Tian, Kevin wrote:
>> From: Yu, Zhang [mailto:yu.c.zhang@linux.intel.com]
>> Sent: Thursday, April 14, 2016 5:57 PM
>>>>>>> And with all three bits now possibly being clear, aren't we risking the
>>>>>>> entries to be mis-treated as not-present ones?
>>>>>>
>>>>>> Hah. You got me. Thanks! :)
>>>>>> Now I realized it would be difficult if we wanna to emulate the read
>>>>>> operations for HVM. According to Intel mannual, entry->r is to be
>>>>>> cleared, so should entry->w if we do not want ept misconfig. And
>>>>>> with both read and write permissions being forbidden, entry->x can be
>>>>>> set only on processors with EXECUTE_ONLY capability.
>>>>>> To avoid any entry to be mis-treated as not-present. We have several
>>>>>> solutions:
>>>>>> a> do not support the read emulation for now - we have no such usage
>>>>>> case;
>>>>>> b> add the check of p2m_t against p2m_ioreq_server in is_epte_present -
>>>>>> a bit weird to me.
>>>>>> Which one do you prefer? or any other suggestions?
>>>>>
>>>>> That question would also need to be asked to others who had
>>>>> suggested supporting both. I'd be fine with a, but I also don't view
>>>>> b as too awkward.
>>>>
>>>> According to Intel mannual, an entry is regarded as not present, if
>>>> bit0:2 is 0. So adding a p2m type check in is_epte_present() means we
>>>> will change its semantics, if this is acceptable(with no hurt to
>>>> hypervisor). I'd prefer option b>
>>>
>>> Perhaps time for the VMX maintainers to chime in - such a change is acceptable
>>> only if it doesn't result in changed hardware behavior. I can't think of any such off
>>> the top of my head, but this really should be confirmed by the maintainers before
>>> deciding to go such a route.
>>>
>>
>> Thanks, Jan. :)
>> Jun & Kevin, any suggestions?
>>
>
> I'm a bit worried about this change, since it's a fundamental EPT
> interface. Can we avoid supporting read emulation now?
>

Thanks for your reply, Kevin.
For XenGT, either waY would be fine. But I do not think changing
is_epte_present will introduce any bug.

Paul, do you have any preference?

Yu

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