From: Wei Wang2 <wei.wang2@amd.com>
To: "Jiang, Yunhong" <yunhong.jiang@intel.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] passthru: Fix pci bar remapping for passthru devices
Date: Mon, 20 Jul 2009 18:29:42 +0200 [thread overview]
Message-ID: <200907201829.42618.wei.wang2@amd.com> (raw)
In-Reply-To: <E2263E4A5B2284449EEBD0AAB751098402CD29FF37@PDSMSX501.ccr.corp.intel.com>
Hi Yunhong
Thanks for the comment. Regarding the reason of guest hang, my guess is: guest
OS might be trying to access guest memory at "0xfe000000" after remapping
this address to mmio and guest memory may be corrupted after this access.
For devices with large mmio, the complement code of mmio block size is more
likely to be a real guest RAM. I saw the same issue when I assigned a graphic
device with 256MB mmio to Linux guest. But devices with small mmio seems to
work well. I did not see the problem on a broadcom NIC with 64K mmio.
Thanks,
Wei
On Monday 20 July 2009 17:48:46 Jiang, Yunhong wrote:
> Wei Wang2 wrote:
> > Hi Yunhong
> > My testing shows that Linux guests will try to probe pci bar with
> > MMIO being enabled. When I assign a broadcom NIC with 32MB MMIO a
> > Linux guest, guest will hang after remapping a guest address
>
> Yes, I remember I saw this bug in kernel before.
>
> I suspect the issue here is the local APIC address, which should not be
> intercepted before MMIO/RAM address in native. i.e. the p2m table should
> not cover the local APIC address as RAM, but I think your change in the
> qemu side is more straightforward (otherwise, we may need consider IOAPIC,
> HPET etc, which is complex).
>
> One thing left is, why it will hang, after all, guest will try to restore
> the BAR address later, and at that time, the local apic access can be
> intercepted again.
>
> --jyh
>
> > "0xfe000000" to physical mmio. However, windows and BSD guests do not
> > have this issue. They alway probe mmio size after disabling mmio.
> > Thanks,
> > Wei
> >
> > On Monday 20 July 2009 16:26:00 Jiang, Yunhong wrote:
> >> I assume guest should disable the MMIO in PCI_COMMAND before writing
> >> all "1"s to bar register. Otherwise, what will happen on native if
> >> guest try to access 0xFFFFFFF0? And if we do update the P2M, will it
> >> cause trouble to Xen HV?
> >>
> >> Thanks
> >> Yunhong Jiang
> >>
> >> xen-devel-bounces@lists.xensource.com wrote:
> >>> 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@amd.com>
> >>> --
> >>> 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
next prev parent reply other threads:[~2009-07-20 16:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-20 14:03 [PATCH] passthru: Fix pci bar remapping for passthru devices Wei Wang2
2009-07-20 14:26 ` Jiang, Yunhong
2009-07-20 14:47 ` Wei Wang2
2009-07-20 15:48 ` Jiang, Yunhong
2009-07-20 16:29 ` Wei Wang2 [this message]
2009-07-21 9:06 ` Jiang, Yunhong
2009-07-21 14:31 ` Ian Jackson
2009-07-20 14:48 ` Keir Fraser
2009-07-20 15:49 ` Jiang, Yunhong
2009-07-20 23:39 ` Kay, Allen M
2009-07-21 9:57 ` Wei Wang2
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200907201829.42618.wei.wang2@amd.com \
--to=wei.wang2@amd.com \
--cc=xen-devel@lists.xensource.com \
--cc=yunhong.jiang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.