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

Re: [PATCH v5 4/5] [FUTURE] xen/arm: enable vPCI for domUs


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
  • Date: Mon, 13 Nov 2023 16:10:36 -0500
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • 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=z1BwwMCrX3zZeK2ry3Zu5Y5Nz7sZjmcAyzm0oAA1wO0=; b=GW1nxZ9Xx4XD8eFyYP4vl38H8pap2DMk1/jhru3SU1LdjWpXzo5YCymmJUHKil8lO8PKE9jAVeCN7ex1u1nd0v9wSNNWnxOuBPOJxCVB3BT1x0Ln1ptRG8Vk1cH/KU2/a6qSs0vFkQBJr2GODrJoNT9SK2USI6BbS1p17pVv2TU4ToksdOec2tBLE7nPSdn1D0olGx9av1x5zk2urqR346V/pxwZQ6dGZOvtj20MlTyqCOduNIG3PMIJSYviL2+fQXg4K5jVrtYHQUVN+HunvACadrJY289Tt3YO7V7m82Hq56NiculHpfq2EDmM7iPw4qrowWUuQOEI6wEHHfaoNg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PmJACO+7ozQUDefe31FRQrwQZaouYUdqUvNLv3OjCDp7v8wBd1FCTRLrNY/4iQP4pUDltS7eP59QwXwJtHfVOLI4CsTGJWf4xFGESEYKCK/0iy583vYZwlRslM9JQbF4E6Htdj1GPskBMUD4jaDY1kdPeQ5ahsEDZF74j2hd0mB35b3/V+yGYj9k+uzMMyTRnsBoqDxZMJXLS+yL+x7cOzIp73zdoO4fHX8F6P/xilhDuAvQgy9yn1+mJfStExet+lZcSsRwnsvTszbsC3vY87mTx7UWj4rrtZ1KkVqLK5YlqDSYzcG31HZXiiboL/fHEvK/IVjcWRPNiOF5mZk20A==
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, "Volodymyr Babchuk" <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, "Wei Liu" <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 13 Nov 2023 21:11:02 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 11/6/23 04:26, Jan Beulich wrote:
> On 02.11.2023 20:59, Stewart Hildebrand wrote:
>> --- a/xen/arch/x86/include/asm/domain.h
>> +++ b/xen/arch/x86/include/asm/domain.h
>> @@ -503,6 +503,15 @@ struct arch_domain
>>  #define has_vpit(d)        (!!((d)->arch.emulation_flags & X86_EMU_PIT))
>>  #define has_pirq(d)        (!!((d)->arch.emulation_flags & 
>> X86_EMU_USE_PIRQ))
>>  
>> +#define is_pvh_domain(d) ({                                  \
>> +    unsigned int _emflags = (d)->arch.emulation_flags;       \
>> +    IS_ENABLED(CONFIG_HVM) &&                                \
>> +        ((_emflags == X86_EMU_LAPIC) ||                      \
>> +         (_emflags == (X86_EMU_LAPIC | X86_EMU_IOAPIC))); })
> 
> I'm not convinced we want to re-introduce such a predicate; it'll be at
> risk of going stale when the boundary between HVM and PVH becomes more
> "fuzzy".

OK, I'll drop it

> 
>> +/* PCI passthrough may be backed by qemu for non-PVH domains */
>> +#define arch_needs_vpci(d) is_pvh_domain(d)
> 
> Wouldn't we want to check for exactly what the comment alludes to then,
> i.e. whether the domain has any (specific?) device model attached?

This patch is primarily dealing with Arm, so I'm considering simply making it 
return false for now:

#define arch_needs_vpci(d) ({ (void)(d); false; })

If it needs to be changed in the future when we enable vPCI for PVH domUs, we 
can deal with it at that time.

> 
>> --- a/xen/include/xen/domain.h
>> +++ b/xen/include/xen/domain.h
>> @@ -51,8 +51,17 @@ void arch_get_domain_info(const struct domain *d,
>>  
>>  #define is_domain_using_staticmem(d) ((d)->cdf & CDF_staticmem)
>>  
>> -#define has_vpci(d) (((d)->options & XEN_DOMCTL_CDF_vpci) && \
>> -                     IS_ENABLED(CONFIG_HAS_VPCI))
>> +#define has_vpci(d) ({                                                      
>>   \
>> +    const struct domain *_d = (d);                                          
>>   \
>> +    bool _has_vpci = false;                                                 
>>   \
>> +    if ( (_d->options & XEN_DOMCTL_CDF_vpci) && IS_ENABLED(CONFIG_HAS_VPCI) 
>> ) \
>> +    {                                                                       
>>   \
>> +        if ( is_hardware_domain(_d) )                                       
>>   \
>> +            _has_vpci = true;                                               
>>   \
>> +        else if ( IS_ENABLED(CONFIG_HAS_VPCI_GUEST_SUPPORT) )               
>>   \
>> +            _has_vpci = true;                                               
>>   \
>> +    }                                                                       
>>   \
>> +    _has_vpci; })
> 
> This is a commonly executed check, and as such wants to remain as simple as
> possible. Wouldn't it be better anyway to prevent XEN_DOMCTL_CDF_vpci getting
> set for a domain which cannot possibly have vPCI?

Yes, agreed, I'll leave has_vpci alone

> 
> Jan



 


Rackspace

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