Hi Allen,
Pls find my explanations inline.
> I thought the originally code already handles sizing of the BAR operations
> (writing all 1's and reading the size back). How did it work before? Did it
> work because we are relying on the a well behaved guest to restore the
> original value of the BAR after the sizing operation?
In early qemu, remapping mmio was only allowed by pt_cmd_reg_write(). But
currently, guest code can also trigger mmio remapping from pt_bar_reg_write()
and pt_exp_rom_bar_reg_write() and this will cause the problem.
> By reading the code, it is not obvious to me how does not doing r->addr =
> cfg_entry->data operation prevents calling of pt_bar_mapping_one() to
> create p2m mapping.
Guest OS probes pci bar after guest bios doing this, so r->addr will still
have the old mmio base address assigned by guest bios before guest OS
writing '1's. If we prevent r->addr from being updated by cfg_entry->data,
pt_bar_mapping_one() will not trigger any actual p2m updates because it will
check whether r->addr has already been changed before calling r->map_func().
Thanks,
Wei
> Allen
>
> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Wei Wang2 Sent:
> Monday, July 20, 2009 7:04 AM
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] [PATCH] passthru: Fix pci bar remapping for passthru
> devices
>
> Hi,
> When guest code tries to get the block size of mmio, it will write all "1"s
> into pci bar register and then qemu will return all "0"s to the don't care
> bits in the emulated bar register to indicate the block size to guest code.
> In this case, we should not create p2m mapping in pt_bar_reg_write() and
> pt_exp_rom_bar_reg_write(). Attached patch fixes this issue, additional
> comment can be found in the patch.
>
> Thanks,
> Wei
>
> Signed-off-by: Wei Wang <wei.wang2@xxxxxxx>
> --
> AMD GmbH, Germany
> Operating System Research Center
>
> Legal Information:
> Advanced Micro Devices GmbH
> Karl-Hammerschmidt-Str. 34
> 85609 Dornach b. München
>
> Geschäftsführer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni
> Sitz: Dornach, Gemeinde Aschheim, Landkreis München
> Registergericht München, HRB Nr. 43632
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|