On 12.02.2024 16:38, Roger Pau Monné wrote: > On Mon, Feb 12, 2024 at 11:45:33AM +0100, Jan Beulich wrote: >> On 12.02.2024 10:39, Roger Pau Monné wrote: >>> On Thu, Feb 08, 2024 at 04:49:46PM +0100, Jan Beulich wrote: >>>> On 08.02.2024 12:49, Roger Pau Monné wrote: >>>>> On Mon, Feb 05, 2024 at 02:55:43PM +0100, Jan Beulich wrote: >>>>>> Make the variable a tristate, with (as done elsewhere) a negative value >>>>>> meaning "default". Since all use sites need looking at, also rename it >>>>>> to match our usual "opt_*" pattern. While touching it, also move it to >>>>>> .data.ro_after_init. >>>>>> >>>>>> The only place it retains boolean nature is pci_ats_device(), for now. >>>>> >>>>> Why does it retain the boolean nature in pci_ats_device()? >>>>> >>>>> I assume this is to avoid having to touch the line again in a further >>>>> patch, as given the current logic pci_ats_device() would also want to >>>>> treat -1 as ATS disabled. >>>> >>>> No, then I would need to touch the line. The function wants to treat >>>> -1 as "maybe enabled", so the caller can know whether a device is an >>>> ATS device regardless of whether ATS use is fully off, or only >>>> "soft-off". >>> >>> I have to admit I'm slightly concerned about this soft-off. Given the >>> current status of ATS itself in Xen, and the technology itself, I >>> think a user should always opt-in to ATS usage. >> >> The plan is to follow your suggestion in patch 3 and require explicit >> enabling for passing through of such devices. For Dom0, however, I >> think it is important that we respect the firmware request by default. >> The only viable(?!) alternative would be to panic() instead. > > Or assign to domIO?
Not behind Dom0's back - I can't see how that would work if then Dom0 tried to load a driver for the device. Jan
