Re: [Xen-devel] [PATCH RFC] VT-d: honor firmware-first mode in XSA-59 workaround code

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.05.14 at 08:46, <yang.z.zhang@xxxxxxxxx> wrote:
> Jan Beulich wrote on 2014-05-23:
>>>>> On 23.05.14 at 04:32, <yang.z.zhang@xxxxxxxxx> wrote:
>>> Jan Beulich wrote on 2014-05-22:
>>>> @@ -447,18 +448,26 @@ void pci_vtd_quirk(const struct pci_dev
>>>>          }
>>>>          
>>>>          val = pci_conf_read32(seg, bus, dev, func, pos +
>>>> PCI_ERR_UNCOR_MASK); -        pci_conf_write32(seg, bus, dev, func,
>>>> pos + PCI_ERR_UNCOR_MASK, -                         val |
>>>> PCI_ERR_UNC_UNSUP); -        val = pci_conf_read32(seg, bus, dev,
>>>> func, pos + PCI_ERR_COR_MASK); -        pci_conf_write32(seg, bus,
>>>> dev, func, pos + PCI_ERR_COR_MASK, -                         val |
>>>> PCI_ERR_COR_ADV_NFAT); +        val2 = pci_conf_read32(seg, bus, dev,
>>>> func, pos + PCI_ERR_COR_MASK); +        if ( (val & PCI_ERR_UNC_UNSUP)
>>>> && (val2 & PCI_ERR_COR_ADV_NFAT) ) +            action = "Found
>>>> masked";
>>> 
>>> What happened if dom0 unmasked it later?
>> 
>> That question you should have raised on the first of the XSA-59
>> related patch sets, but the answer is we expect Dom0 to be well
>> behaved. Of course, if you have a non-intrusive suggestion on how to enforce 
> this in Xen, I'm all ears.
> 
> So you mean we need to stare at Linux upstream to make sure it doesn't do 
> any un-friendly modification to Xen.

Not sure what you mean by "stare", but relying on Dom0 to not do
bad things is a fundamental model with Xen - if the Dom0 kernel
wanted, it'd have other ways of doing bad things.

Jan


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