From: "Michael S. Tsirkin" <mst@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: Alexey Korolev <alexey.korolev@endace.com>,
sfd@endace.com, Alex Williamson <alex.williamson@redhat.com>,
Kevin O'Connor <kevin@koconnor.net>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [RFC/PATCH] Fix guest OS panic when 64bit BAR is present
Date: Thu, 26 Jan 2012 16:05:43 +0200 [thread overview]
Message-ID: <20120126140543.GC17198@redhat.com> (raw)
In-Reply-To: <4F215A4A.1000400@redhat.com>
On Thu, Jan 26, 2012 at 03:51:06PM +0200, Avi Kivity wrote:
> > Please look at HPET lines. HPET is mapped to 0xfed00000.
> > Size of ivshmem is 32MB. During pci enumeration ivshmem will corrupt the range from 0xfe000000 - 0xffffffff.
> > It overlaps HPET memory. When Linux does late_hpet init, it finds garbage and this is causing panic.
> >
>
> Let me see if I get this right: during BAR sizing, the guest sets the
> BAR to ~1, which means 4GB-32MB -> 4GB, which overlaps the HPET. If so,
> that's expected behaviour.
Yes BAR sizing temporarily sets the BAR to an invalid value then
restores it. What I don't understand is how come something accesses the
HPET range in between.
> If the guest doesn't want this memory there,
> it should disable mmio.
Recent kernels do this for most devices, but not for
platform devices.
> --
> error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2012-01-26 14:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-25 5:46 [Qemu-devel] [RFC/PATCH] Fix guest OS panic when 64bit BAR is present Alexey Korolev
2012-01-25 12:51 ` Michael S. Tsirkin
2012-01-26 3:20 ` Alexey Korolev
2012-01-25 15:38 ` Michael S. Tsirkin
2012-01-25 18:59 ` Alex Williamson
2012-01-26 3:19 ` Alexey Korolev
2012-01-26 13:51 ` Avi Kivity
2012-01-26 14:05 ` Michael S. Tsirkin [this message]
2012-01-26 14:33 ` Avi Kivity
2012-01-26 9:14 ` Michael S. Tsirkin
2012-01-26 13:52 ` Avi Kivity
2012-01-26 14:36 ` Michael S. Tsirkin
2012-01-26 15:12 ` Avi Kivity
2012-01-27 4:42 ` Alexey Korolev
2012-01-31 9:40 ` Avi Kivity
2012-01-31 9:43 ` Avi Kivity
2012-02-01 5:44 ` Alexey Korolev
2012-02-01 7:04 ` Michael S. Tsirkin
2012-02-02 2:22 ` Alexey Korolev
2012-01-31 10:51 ` Avi Kivity
2012-01-27 4:40 ` Alexey Korolev
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=20120126140543.GC17198@redhat.com \
--to=mst@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=alexey.korolev@endace.com \
--cc=avi@redhat.com \
--cc=kevin@koconnor.net \
--cc=qemu-devel@nongnu.org \
--cc=sfd@endace.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.