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

From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, Yu Zhang <yu.c.zhang@linux.intel.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, Paul Durrant <paul.durrant@citrix.com>,
	zhiyuan.lv@intel.com, JunNakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.
Date: Tue, 21 Jun 2016 15:38:37 +0100	[thread overview]
Message-ID: <bb16927e-ff21-d1e6-81d9-ae038856de52@citrix.com> (raw)
In-Reply-To: <5769296002000078000F7250@prv-mh.provo.novell.com>

On 21/06/16 10:47, Jan Beulich wrote:
>>>>> And then - didn't we mean to disable that part of XenGT during
>>>>> migration, i.e. temporarily accept the higher performance
>>>>> overhead without the p2m_ioreq_server entries? In which case
>>>>> flipping everything back to p2m_ram_rw after (completed or
>>>>> canceled) migration would be exactly what we want. The (new
>>>>> or previous) ioreq server should attach only afterwards, and
>>>>> can then freely re-establish any p2m_ioreq_server entries it
>>>>> deems necessary.
>>>>>
>>>> Well, I agree this part of XenGT should be disabled during migration.
>>>> But in such
>>>> case I think it's device model's job to trigger the p2m type
>>>> flipping(i.e. by calling
>>>> HVMOP_set_mem_type).
>>> I agree - this would seem to be the simpler model here, despite (as
>>> George validly says) the more consistent model would be for the
>>> hypervisor to do the cleanup. Such cleanup would imo be reasonable
>>> only if there was an easy way for the hypervisor to enumerate all
>>> p2m_ioreq_server pages.
>>
>> Well, for me, the "easy way" means we should avoid traversing the whole ept
>> paging structure all at once, right?
> 
> Yes.

Does calling p2m_change_entry_type_global() not satisfy this requirement?

>> I have not figured out any clean 
>> solution
>> in hypervisor side, that's one reason I'd like to left this job to 
>> device model
>> side(another reason is that I do think device model should take this 
>> responsibility).
> 
> Let's see if we can get George to agree.

Well I had in principle already agreed to letting this be the interface
on the previous round of patches; we're having this discussion because
you (Jan) asked about what happens if an ioreq server is de-registered
while there are still outstanding p2m types. :-)

I do think having Xen change the type makes the most sense, but if
you're happy to leave that up to the ioreq server, I'm OK with things
being done that way as well.  I think we can probably change it later if
we want.

 -George

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