> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Trolle Selander
> Sent: 07 December 2006 09:51
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [HVM] Corruption of buffered_io_page
>
> I thought i had replied to the list, but apparently gmail's
> default reply action goes to the last poster, not the mailing
> list. Ian got these answers already, but I'll cut & paste to
> make sure it gets to the general list as well:
>
>
>
> Distro is FC6, compiler is gcc-4.1.1, guest os is OS/2,
> worload is the boot process. :)
> No drivers are loaded yet at this stage - it happens
> fairly early in the boot. However, after I added the
> corruption-catching "padding" struct member, the boot does in
> fact progress to the driver loading stage, although with
> severely corrupted boot-logo graphics.
> Since it currently happens reproducibly after a
> specific "no op" vmexit (read from an unused port), Mats's
> suggestion of marking the iopage read-only sounds doable if I
> insert code to set the page readonly when this specific
> vmexit occurs. From what I saw when running qemu in the
> debugger, there's no "proper" use of the page about to occur,
> so the only thing that will write to it should be whatever is
> doing it erroneously. I'll try that tomorrow.
>
> One correction: I managed to confuse myself a bit here.
> The very last vmexit_ioio at which the guest stalls is a read
> from 0x1f7, but when that io happens, the iopage is already
> corrupted, and that's why it stalls - qemu-dm is "stuck" and
> never performs the io. The port 0x23 is the io preceeding
> that one - the last one that "gets through", which is why
> that was the one I've used to trace things.
>
> I don't know if it's any clue to anyone, but the bad
> value that gets written into read_pointer is 0x1df1000.
One thing is for sure, it's not a page-table entry. But it could be the
value of a physical page-address. Is this value in any of the registers
around the time of the crash?
>
>
>
> Now to what you said - I thought Keir's patch to fixed up all
> the segment base = 0 assumptions in x86_emulate? At least
> we're past the problem that was causing that I posted about
> before. I must confess I never actually looked at the code,
> because Keir said the patch would fix all the segment base =
> 0 assumptions, and once the patch showed up in mercurial and
> I built from that changeset, I didn't hit the seg.base != 0
> problem anymore.
There was patch(es) from Jan Beulich to fix the HVM side of seg.base !=
0, but as far as I've seen, Keir hasn't posted his "big patch" yet -
it's possible that Keir could send you a "private patch". This patch
fixed x86_emulate.c, which isn't in the HVM section, it's the part that
fixes up page-table writes (which you may not see many of at the early
part of boot, so it may not be an issue, of course).
Whilst marking the page read-only and trapping on the page-fault is
indeed doable, I'd also add a check on every vmexit and just at the time
of doing vmrun (in the C code just before calling svm_asm_do_resume() or
some such).
--
Mats
>
>
> On 12/7/06, Petersson, Mats <Mats.Petersson@xxxxxxx> wrote:
>
>
>
> > -----Original Message-----
> > From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > [mailto: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> <mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx> ] On Behalf Of
> Ian Pratt
> > Sent: 06 December 2006 22:05
> > To: Trolle Selander; xen-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [Xen-devel] [HVM] Corruption of buffered_io_page
> >
> > > read_pointer is the first member of buffered_ioreq_t, so on
> > the hunch
> > that
> > > the corruption was occuring by something other than
> a wrong value
> > actually
> > > being written into the structure member, either overflowing
> > a previous
> > > structure in memory or a pointer var mistake. I
> thus added a 64bit
> > dummy
> > > member to "pad" the buffered_ioreq_t structure at the
> > start, and as I
> > had
> > > suspected, the bad value does get written into this
> dummy member
> > rather
> > > than the read_pointer. I haven't (yet) been able to track
> > down what it
> > is
> > > that actually writes the bad value, and any help
> finding it would be
> > > welcome.
> >
> > What compiler are you using? What guest OS? Are you using PV
> > or emulated
> > drivers? Any idea if there are particular workloads
> that provoke the
> > problem?
>
> I'll answer for Trolle as best as I can:
> Compiler: gcc 4.1 I believe.
> Guest OS: OS/2
> Drivers would be emulated ones.
> I think it's failing during initial boot, as Trolle
> hasn't told me "It
> works" yet... ;-)
>
> By the way, I'm still a bit worried that this is caused
> by segment base
> != 0 in x86_emulate.c - this can cause all sorts of
> "interesting"
> interaction between the page-table updates and actual
> memory being
> affected.
>
> --
> Mats
> >
> > Best,
> > Ian
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> <mailto:Xen-devel@xxxxxxxxxxxxxxxxxxx>
> > http://lists.xensource.com/xen-devel
> >
> >
> >
>
>
>
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home