On 26.07.2023 15:37, Roger Pau Monné wrote: > On Wed, Jul 26, 2023 at 02:36:17PM +0200, Jan Beulich wrote: >> Another Dom0 related concern can probably be put off until we actually >> get a report of this failing (which may be more likely because of the >> XSM check below): The function being used as a callback passed to >> rangeset_consume_ranges(), failure may affect just a single BAR, while >> the incoming range may cover multiple of them in one go. Depending on >> what functionality such a BAR covers, the device may remain usable (a >> typical example of what I'm thinking of is a multi-function device >> having serial and/or parallel port on it, which are fine to be driven >> via I/O ports even if driving via MMIO is possible [and would likely >> be more efficient]). Of course, to allow some MMIO bars to be used >> while prohibiting use of some others, further trickery may be needed. >> But not exposing the device to Dom0 at all doesn't seem very nice in >> such a case. > > Hm, I see. For dom0 we might want to consider ignoring mapping > failures, the problem is that we would need to narrow down the pages > not allowed to be mapped, as part of the range passed to map_range() > might be allowed. We would need to resort to checking permissions on > a page by page basis, which is not overly nice.
Right, all of which is why I prefixed the while paragraph with "can probably be put off until ...". > I think it's more likely for such BARs to be marked as read-only > (instead of denying access), in which case the checking here would > still be OK. Maybe, but (a) granting r/o access may still be beyond what an XSM policy intends and (b) might be a problem when reads have side effects. Jan
