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

Re: [PATCH v3 5/8] domain: map/unmap GADDR based shared guest areas


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 27 Sep 2023 17:29:26 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5fE17IRb2bZSAHcW8CQfpBVm8HAfBvc4YS6fVJ++ivY=; b=K0Npc6LZZ6zdAYpHcT0DzR6J3EHFq5MXahVS72+ndM1slhrVcb4voteidTbQKXp47K+4hKEL/UYB9dNciQAe6A+B5hxyr4Ol3xQ3X7plaiBvdrtopolfEEyY7KBQIMSC5lCTRX1xQzTPiewY2Zvnu7+v0iJVQoULJthMakhOrrC4V1H9gYK10iaTVeb7lPHAJw98AhIKD00qwBMRV6jdKwSbULApKT5degCisZcT7po4HKhAHRyOZ2WU+YNn1hvUNkeHg/QSlE15P2wDg4gZIKffB4UGChdzr78j9vZG+3PslPNrd6x+sL9o35jhY6JXBqb5ExIO2VRXJc1SSWXhgw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EagsTpodPH0F3Mlk+HpSoKNd2KNHF7p8yk9EXXw+d6i0svvG8qsAE/gjFPV1p/nBNcs1qpcmn100cZcUGMF4mdEuVqc19TjBylhmNEQP2jcepY/C8aFVx45TlMPkOTTWA1MYApaWsqdGPooUjIPgde2aAR3MceV6F3vtUVTEL6zxAI9YHQ6VFQDGGbBarm3G3yKywwv+SNgpjLciZJRGOaJVvoLV2+L3HreWUtleLvVvNE3a44Tl6KhCeqeAZECh/7Enr0gAgx3svE6mZBGtkli7TQF3bAOCUx1i29esRF3YvrwaV8DbT2tUZMR/pNmsRsU2AI4CRd9YWVq1c7LaQg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Wed, 27 Sep 2023 15:29:35 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 27.09.2023 16:53, Roger Pau Monné wrote:
> On Wed, May 03, 2023 at 05:57:09PM +0200, Jan Beulich wrote:
>> RFC: In map_guest_area() I'm not checking the P2M type, instead - just
>>      like map_vcpu_info() - solely relying on the type ref acquisition.
>>      Checking for p2m_ram_rw alone would be wrong, as at least
>>      p2m_ram_logdirty ought to also be okay to use here (and in similar
>>      cases, e.g. in Argo's find_ring_mfn()). p2m_is_pageable() could be
>>      used here (like altp2m_vcpu_enable_ve() does) as well as in
>>      map_vcpu_info(), yet then again the P2M type is stale by the time
>>      it is being looked at anyway without the P2M lock held.
> 
> check_get_page_from_gfn() already does some type checks on the page.

But that's still of no help without holding the p2m lock for long enough.
Also the checks there all are to fail the call, whereas the remark above
talks about distinguishing when to permit and when to fail the request
here.

>> ---
>> v2: currd -> d, to cover mem-sharing's copy_guest_area(). Re-base over
>>     change(s) earlier in the series. Use ~0 as "unmap" request indicator.
>>
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -1576,7 +1576,82 @@ int map_guest_area(struct vcpu *v, paddr
>>                     struct guest_area *area,
>>                     void (*populate)(void *dst, struct vcpu *v))
>>  {
>> -    return -EOPNOTSUPP;
>> +    struct domain *d = v->domain;
>> +    void *map = NULL;
>> +    struct page_info *pg = NULL;
>> +    int rc = 0;
> 
> Should you check/assert that size != 0?

Not really, no, the more that this is an internal interface, and we
don't (and shouldn't) check similar aspects elsewhere. There's just
a single use of the value (see below).

>> +    if ( ~gaddr )
> 
> I guess I will find in future patches, but why this special handling
> for ~0 address?

Future patches aren't very likely to make this explicit. The most
explicit indicator for now was the revision log entry for v2.

> Might be worth to add a comment here, or in the patch description.
> Otherwise I would expect that when passed a ~0 address the first check
> for page boundary crossing to fail.

I've added "/* Map (i.e. not just unmap)? */" on the same line.

>> +    {
>> +        unsigned long gfn = PFN_DOWN(gaddr);
>> +        unsigned int align;
>> +        p2m_type_t p2mt;
>> +
>> +        if ( gfn != PFN_DOWN(gaddr + size - 1) )
>> +            return -ENXIO;

This is the only use of size. If size is 0 and gaddr is on a page boundary,
the call will fail. For any other gaddr nothing bad will happen (afaict).

>> +#ifdef CONFIG_COMPAT
>> +        if ( has_32bit_shinfo(d) )
>> +            align = alignof(compat_ulong_t);
>> +        else
>> +#endif
>> +            align = alignof(xen_ulong_t);
>> +        if ( gaddr & (align - 1) )
> 
> IS_ALIGNED() might be clearer.

Can switch, sure.

>> +            return -ENXIO;
>> +
>> +        rc = check_get_page_from_gfn(d, _gfn(gfn), false, &p2mt, &pg);
>> +        if ( rc )
>> +            return rc;
>> +
>> +        if ( !get_page_type(pg, PGT_writable_page) )
>> +        {
>> +            put_page(pg);
>> +            return -EACCES;
>> +        }
>> +
>> +        map = __map_domain_page_global(pg);
>> +        if ( !map )
>> +        {
>> +            put_page_and_type(pg);
>> +            return -ENOMEM;
>> +        }
>> +        map += PAGE_OFFSET(gaddr);
>> +    }
>> +
>> +    if ( v != current )
>> +    {
>> +        if ( !spin_trylock(&d->hypercall_deadlock_mutex) )
>> +        {
>> +            rc = -ERESTART;
>> +            goto unmap;
>> +        }
>> +
>> +        vcpu_pause(v);
>> +
>> +        spin_unlock(&d->hypercall_deadlock_mutex);
>> +    }
>> +
>> +    domain_lock(d);
>> +
>> +    if ( map )
>> +        populate(map, v);
> 
> The call to map_guest_area() in copy_guest_area() does pass NULL as
> the populate parameter, hence this will crash?
> 
> Should you either assert that populate != NULL or change the if
> condition to be map && populate?

Oh, yes - the latter.

>> @@ -1587,9 +1662,24 @@ int map_guest_area(struct vcpu *v, paddr
>>  void unmap_guest_area(struct vcpu *v, struct guest_area *area)
>>  {
>>      struct domain *d = v->domain;
>> +    void *map;
>> +    struct page_info *pg;
>>  
>>      if ( v != current )
>>          ASSERT(atomic_read(&v->pause_count) | atomic_read(&d->pause_count));
>> +
>> +    domain_lock(d);
>> +    map = area->map;
>> +    area->map = NULL;
>> +    pg = area->pg;
>> +    area->pg = NULL;
> 
> FWIW you could also use SWAP() here by initializing both map and pg to
> NULL (I know it uses one extra local variable).

When truly exchanging two values (like further up), I'm fine with using
SWAP() (and as you saw I do use it), but here I think it would be more
heavy than wanted/needed.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.