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

Re: [PATCH v8 4/6] AMD/IOMMU: respect AtsDisabled device flag


  • To: paul@xxxxxxx
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 28 Sep 2021 09:47:21 +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; bh=LxtsIan1PrQvtx+gwpLNKBF0Z/WvVABN8IPG8rsHM0s=; b=ZnaEN9F+ixnXvrWDnoDY9zH8d8g4RI7TXOwEjMK2lf+LG3AjxQM07qkhVnMO1fBC/8QcGptXEIpJKWhMDxsm88OWyXl+BRsBYUJiCj9xA9Mww/6RoyacBGFBuNFrfeuc1ODq2thy/N9gTmpVT98F96wKKrdx6fsK+aRDJTIc1yqPETZByaeeZr+FqO8U+919Ri4WivKSK9rq+gyiWT3kiDRG505Y0+wWpCvsJmxaynv5ihkojt0USphBdDKk1XoiGjLhIGmancRyeSgqBUblcu9Ch0seK9ILSipVDiyOKp5FfzqLe0dWJ++IZxCAlhlfRZbojOcyfm0JQu0QQqTJGQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Rx7RTimmKan4Xvj3IKNCHnIYPiRGMMHBF6nXBzHPRORCbf8/hq9LURACLkIfeAtX1wSK1CumzCAleXSHDsKyOENW3mbvbGkYjsuv+B6DhRf9ooMEsyrkmYc4KkMXgvOY5mMax+FEz0Bsr4H6/YWG+rr54RWaJAj9Agw4GrUxSPlj01M8OOvdJcZtg2nYdGIj4uJEPSxr94QEEdk8cKd/sQgBXP/c0DqO0AcP2tUMfQOoASJdOW2OvbUE9psWK+xfJB0+i4wZVIJSN5k4RjDt85CLrW6XbWaIYC77/kaqBctzFpP35OFIHni2U8xNy8rX/wSzgtvxO6nZgTpQvOAg8w==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 28 Sep 2021 07:47:30 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 28.09.2021 09:34, Durrant, Paul wrote:
> On 22/09/2021 15:37, Jan Beulich wrote:
>> IVHD entries may specify that ATS is to be blocked for a device or range
>> of devices. Honor firmware telling us so.
>>
>> While adding respective checks I noticed that the 2nd conditional in
>> amd_iommu_setup_domain_device() failed to check the IOMMU's capability.
>> Add the missing part of the condition there, as no good can come from
>> enabling ATS on a device when the IOMMU is not capable of dealing with
>> ATS requests.
>>
>> For actually using ACPI_IVHD_ATS_DISABLED, make its expansion no longer
>> exhibit UB.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> TBD: As an alternative to adding the missing IOMMU capability check, we
>>       may want to consider simply using dte->i in the 2nd conditional in
>>       amd_iommu_setup_domain_device().
>> Note that while ATS enabling/disabling gets invoked without any locks
>> held, the two functions should not be possible to race with one another
>> for any individual device (or else we'd be in trouble already, as ATS
>> might then get re-enabled immediately after it was disabled, with the
>> DTE out of sync with this setting).
>> ---
>> v7: New.
>>
>> --- a/xen/drivers/passthrough/amd/iommu.h
>> +++ b/xen/drivers/passthrough/amd/iommu.h
>> @@ -120,6 +120,7 @@ struct ivrs_mappings {
>>       uint16_t dte_requestor_id;
>>       bool valid:1;
>>       bool dte_allow_exclusion:1;
>> +    bool block_ats:1;
>>   
>>       /* ivhd device data settings */
>>       uint8_t device_flags;
>> --- a/xen/drivers/passthrough/amd/iommu_acpi.c
>> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
>> @@ -55,8 +55,8 @@ union acpi_ivhd_device {
>>   };
>>   
>>   static void __init add_ivrs_mapping_entry(
>> -    uint16_t bdf, uint16_t alias_id, uint8_t flags, bool alloc_irt,
>> -    struct amd_iommu *iommu)
>> +    uint16_t bdf, uint16_t alias_id, uint8_t flags, unsigned int ext_flags,
>> +    bool alloc_irt, struct amd_iommu *iommu)
>>   {
>>       struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(iommu->seg);
>>   
>> @@ -66,6 +66,7 @@ static void __init add_ivrs_mapping_entr
>>       ivrs_mappings[bdf].dte_requestor_id = alias_id;
>>   
>>       /* override flags for range of devices */
>> +    ivrs_mappings[bdf].block_ats = ext_flags & ACPI_IVHD_ATS_DISABLED;
>>       ivrs_mappings[bdf].device_flags = flags;
> 
> I'm assuming the above indentation problem (which appears to be repeated 
> in a few places below) is more to do with patch email generation rather 
> than the actual code modifications so...

Hmm, I first suspected a Thunderbird regression, but checking the list
archives I don't see any corruption. I'm therefore now suspecting the
problem may be at your end ...

> Reviewed-by: Paul Durrant <paul@xxxxxxx>

Thanks.

Jan




 


Rackspace

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