Re: [PATCH kernel 8/9] RFC: PCI: Avoid needless touching of Command register

[Alexey Kardashevskiy <aik@amd.com>]

On 26/2/26 11:24, Bjorn Helgaas wrote:
> On Wed, Feb 25, 2026 at 04:37:51PM +1100, Alexey Kardashevskiy wrote:
>> Once locked, a TDI's MSE and BME are not allowed to be cleared.
> 
> Disallowed by hardware, by spec, by convention?  Spec reference would
> be helpful.

By the PCIe spec, the TDISP part. Once the device in CONFIG_LOCKED or RUN, clearing MSE or BME will destroy this state == will go to the ERROR state. PCIe r7, "Figure 11-5 TDISP State Machine".

Then, if it was CONFIG_LOCKED - the device won't be able to go to the RUN state which allows DMA to/from encrypted memory and encrypted MMIO. If it was RUN - the device will lose those encrypted DMA/MMIO abilities.

>> Skip INTx test as TEE-capable PCI functions are most likely IOV VFs
>> anyway and those do not support INTx at all.
> 
> "Most likely" doesn't sound like a convincing argument for skipping
> something.
> 
>> Add a quirk preventing the probing code from disabling MSE when
>> updating 64bit BAR (which cannot be done atomically).
> 
> Say more about this please.  If there's something special about this
> device, I'd like to know exactly what that is.
> 
>> Note that normally this happens too early and likely not really
>> needed for the device attestation happening long after PCI probing.
> 
> I don't follow this either.  Please make it meaningful for
> non-TEE/TDI/whatever experts.  And mention that context in the subject
> line.

Well, frankly, I have this patch for ages and originally QEMU did not intercept zeroing of BME/MSE and just by having this patch, I could get my prototype working without that QEMU hack.

Then, even though the QEMU hack works, it is kind of muddy as when a device driver wants to clear BME to, say, stop DMA - and in reality it won't stop. So I suspect the QEMU hack won't always be enough and we will have to teach the PCI subsystem to not clear BME/MSE in some cases.

Hence the patch, to highlight rather unexpected writes to the PCI command register which are not that harmless anymore.

I'll drop it if it is no use to anyone even with the above.

>> @@ -1930,6 +1930,11 @@ static int pci_intx_mask_broken(struct pci_dev *dev)
>>   {
>>   	u16 orig, toggle, new;
>>   
>> +	if (dev->devcap & PCI_EXP_DEVCAP_TEE) {
>> +		pci_warn_once(dev, "(TIO) Disable check for broken INTX");
>> +		return 1;
> 
> s/INTX/INTx/
> 
> Why do users need to know this?  Why as a warning?  What can they do
> about it?  "TIO"?

ah, sorry, a leftover. Thanks,


-- 
Alexey