> > 2) c/s 16728
> > Removing 16728 allows guests to start up. Get a "bad address" error
> > currently, but removing only the
> > xc_domain_memory_decrease_reservation(... [shared_page_nr-3]) call
> > (which frees up the guard page), then allows HVM guests to
> start up. I
> With this patch, couldn't create HVM guest with VT-d, prompted "Error:
> (14, 'Bad addrees')".
>
> Randy (Weidong)
Randy, thanks for trying this patch out. Yes, this error occurs
currently with unstable, and is not a problem with VT-d specifically.
This "bad address" error occurs if c/s 16728 is not removed prior to the
test.
Sorry about the confusion. If you remove c/s 16728 (the guard page),
then the code seems to work well.
I am in process of determing root cause for why the call in 16728 to:
xc_domain_memory_decrease_reservation(...page_array[shared_page_nr-3])
then causes the function:
xc_clear_domain_page(xc_handle, dom, shared_page_nr)
To fail in the
xc_map_foreign_range()/ioctl(xc_handle, IOCTL_PRIVCMD_MMAP, &ioctlx)
Function w/ -EFAULT.
Soon as this is fixed, I'll repost the patch(es).
tom
> -----Original Message-----
> From: Han, Weidong [mailto:weidong.han@xxxxxxxxx]
> Sent: Thursday, January 24, 2008 9:16 PM
> To: Woller, Thomas; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] [PATCH] Super Pages (2meg/4meg) patch
>
> With this patch, couldn't create HVM guest with VT-d, prompted "Error:
> (14, 'Bad addrees')".
>
> Randy (Weidong)
>
> Woller, Thomas wrote:
> > Attached is the latest super pages patch with the modifications
> > requested, the main content is consistent with Wei Huang's previous
> > post of this patch.
> >
> > applies to unstable 16877 cleanly.
> >
> > There is a problem that I am working that is related to c/s
> 16728 (see
> > below), so the patch doesn't function quite yet with latest
> > unstable/staging (i.e. don't apply to staging quite yet).
> >
> > Modifications from last patch:
> > xc_hvm_build.c/setup_guest
> > 1) all the *_2MB variables are now *_super
> > 2) the superpage size is now calculated (currently
> > hardcoded to PAGE_SHIFT + 9 etc) from a single variable
> > describing the order of a superpage (21 or 22)
> > 3) the superpage size is determined by querying the xen
> capabilities:
> > if Xen supports PAE HVM guests then superpages are 2MB, else 4MB.
> > Currently using "if ( strstr(caps, "x86_32p") )" as a
> string match.
> >
> > What is not done:
> > 1) I don't have crosscompile for IA64 and PowerPC
> compilation, I added
> > what I think are enough modifications to allow compilation without
> > runtime failure, but actual compiling will tell.
> >
> > 2) c/s 16728
> > Removing 16728 allows guests to start up. Get a "bad address" error
> > currently, but removing only the
> > xc_domain_memory_decrease_reservation(... [shared_page_nr-3]) call
> > (which frees up the guard page), then allows HVM guests to
> start up. I
> > am looking at the issue now, any ideas appreciated.
> >
> > Testing:
> > 1) ran over a week with PAE x86 hv without issue on 16656 base with
> > HVM guests.
> > 64b hv (sans 16728) does not show any issues starting up
> various HVM
> > guests with more limited testing. Used both shadow paging
> and nested
> > paging during the testing.
> >
> > 2) in process of starting up 64b hv with patch for extended testing
> > once issue with 16728 resolved
> >
> > 3) don't plan on testing any 32b hv
> >
> > Jan's recent 1Gig patch applies without failure on top of
> this latest
> > patch.
> >
> > Please take a look at it, esp the newer mods to
> xc_hvm_build.c and the
> > powerpc/ia64 areas, and provide any comments. it *should*
> be almost
> > ready to apply.
> >
> > Cheers,
> >
> > Signed-off-by: Tom Woller <thomas.woller@.com>
> >
> > --Tom
> >
> > thomas.woller@xxxxxxx +1-512-602-0059 AMD Corporation - Operating
> > Systems Research Center
> > 5204 E. Ben White Blvd. UBC1
> > Austin, Texas 78741
>
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home