Re: [PATCH v10 5/6] x86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries.

From: "Jan Beulich" <JBeulich@suse.com>
To: 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>,
	xen-devel@lists.xen.org, Paul Durrant <paul.durrant@citrix.com>,
	zhiyuan.lv@intel.com, Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH v10 5/6] x86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries.
Date: Mon, 03 Apr 2017 08:38:29 -0600	[thread overview]
Message-ID: <58E27A85020000780014C29B@prv-mh.provo.novell.com> (raw)
In-Reply-To: <58E279F3020000780014C28B@prv-mh.provo.novell.com>

>>> On 03.04.17 at 16:36, <JBeulich@suse.com> wrote:
>>>> On 02.04.17 at 14:24, <yu.c.zhang@linux.intel.com> wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -317,6 +317,15 @@ int p2m_set_ioreq_server(struct domain *d,
>>          if ( p2m->ioreq.server != NULL )
>>              goto out;
>>  
>> +        /*
>> +         * It is possible that an ioreq server has just been unmapped,
>> +         * released the spin lock, with some p2m_ioreq_server entries
>> +         * in p2m table remained. We shall refuse another ioreq server
>> +         * mapping request in such case.
>> +         */
>> +        if ( read_atomic(&p2m->ioreq.entry_count) )
>> +            goto out;
> 
> So this produces the same -EINVAL as the earlier check in context
> above. I think it would be nice if neither did - -EINUSE for the first
> (which we don't have, so -EOPNOTSUPP would seem the second
> bets option there) and -EBUSY for the second would seem more
> appropriate. If you agree, respective adjustments could be done
> while committing, if no other reason for a v11 arises.

Oh, and with that
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan


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