Re: [Xen-devel] [RFC 0 PATCH 3/3] PVH dom0: construct_dom0 changes

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.10.13 at 03:06, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> On Fri, 4 Oct 2013 16:59:53 -0400
> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
>> On Fri, Oct 04, 2013 at 05:07:59PM +0100, Jan Beulich wrote:
>> > >>> On 04.10.13 at 18:02, Konrad Rzeszutek Wilk
>> > >>> <konrad.wilk@xxxxxxxxxx> wrote:
>> > > Can't one also trap for the configuration changes on the PCI
>> > > devices and extract the physical locations then?
>> > 
>> > Yes, of course we could be snooping the CFG writes, but that's
>> > as simple as it sounds only for the port CF8 based accesses. For
>> > MCFG based accesses it would mean we'd have to write protect
>> > the whole MCFG range, and use emulation there. Not very
>> > pretty, but doable.
>> 
>> Hypervisor call is then a more appropiate if it can be done (Mukesh
>> says that v0 of the patch had something like that in so he will try
>> to recreate it) and then as a fallback we could do the emulation.
> 
> Right, looks like it has to be guest driven. xen can provide the
> facility via the PHYSDEVOP_map_iomem I had in V0. For linux, we will do 
> such mappings above the highest e820 entry via the ioremap path. 

As I tried to make clear before - this is wrong both conceptually and
technically: Conceptually because there's no need for a driver to
ioremap() all MMIO ranges in order for a device to make use of them.
And technically because you would allow bad arguments passed to
ioremap() propagate into bad IOMMU mappings, while the IOMMU is
precisely there to catch bad accesses (even for Dom0, at least in
dom0-strict mode).

Jan


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