RE: [Xen-devel] pciback: question about the permissive flag

[Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>]

> So, you're saying that, if we have a device that allows us to set some of
> its PCI config register (some BAR) to tell where to MMIO-map some of the
> device's additional config range, and if we "asked it" to map it over,
> say, some physical addresses belonging to the hypervisor, then the MCH
> would allow for that? And the CPU would happily redirect access to those
> addresses over to the device memory? Why would it? That would clearly be a
> CPU/chipset bug, as we normally would have to mark this memory range as
> MMIOed in the first place...

Mapping it over memory might be prevented by the MCH (would you want to rely on 
that?), but mapping it over another device is likely going to create system 
instability if not a vulnerability.

> And even if we wanted to instruct the device to map its memory over some
> already MMIOed memory in a hypervisor, shouldn't VT-d prevent the
> read/write transactions going to this device?

VT-d only deals with DMAs coming from the device, not CPU MMIOs.

> As for the SMI generation: that stinks indeed. But, does it offer any
> control over the generated #SMI, e.g. what we write into the 0xb2 port, or
> something like that? 

No idea. Discarding such config writes just seems like a good default.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel