Hi, I''m working on save/restore for domains using translated shadow page tables. I''ve added support so that page tables are not (un)canonicalized during save/restore, but when the new context is being loaded, the set_gdt call is failing. Specifically, the get_page_and_type() call fails. Any ideas on what would cause this error? It''s not clear to me what part of the normal restore code sets page types so that this call usually works. The basic steps of my restore routine are: -read in pages -enable shadow mode -add grant tables to physmap -clear events/copy shared info frame -set vcpu context (this step fails) Thanks for any pointers, -Tim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 11/12/06 01:03, "Tim Wood" <twwood@gmail.com> wrote:> I''m working on save/restore for domains using translated shadow page > tables. I''ve added support so that page tables are not > (un)canonicalized during save/restore, but when the new context is > being loaded, the set_gdt call is failing. Specifically, the > get_page_and_type() call fails.What''s the error (try adding guest_loglvl=all as a Xen boot parameter)? Most likely Xen thinks the GDT pages are already mapped writable. Or there could be a PFN vs. MFN mixup. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12/11/06, Keir Fraser <keir@xensource.com> wrote:> On 11/12/06 01:03, "Tim Wood" <twwood@gmail.com> wrote: > > > I''m working on save/restore for domains using translated shadow page > > tables. I''ve added support so that page tables are not > > (un)canonicalized during save/restore, but when the new context is > > being loaded, the set_gdt call is failing. Specifically, the > > get_page_and_type() call fails. > > What''s the error (try adding guest_loglvl=all as a Xen boot parameter)? Most > likely Xen thinks the GDT pages are already mapped writable. Or there could > be a PFN vs. MFN mixup. >In get_page_type, I am getting this error message: Error while validating mfn 53be (pfn 1091) for type a0000000: caf=80000002 taf=00000000 Digging down as deep as I can, the root error is in check_descriptor() because [b & _SEGMENT_TYPE) != 0xc00] is true, so the call fails. I''m not 100% sure on the significance of that yet. I see that alloc_segdesc_page is calling check_descriptor() multiple times and that the first 30 iterations succeed. any advice? --thanks in advance, Tim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 11/12/06 8:12 pm, "Tim Wood" <twwood@gmail.com> wrote:> In get_page_type, I am getting this error message: > Error while validating mfn 53be (pfn 1091) for type a0000000: > caf=80000002 taf=00000000 > > Digging down as deep as I can, the root error is in check_descriptor() > because [b & _SEGMENT_TYPE) != 0xc00] is true, so the call fails. I''m > not 100% sure on the significance of that yet. > > I see that alloc_segdesc_page is calling check_descriptor() multiple > times and that the first 30 iterations succeed. > > any advice? --thanks in advance,What segment type are you seeing? Can you dump the offending descriptor? The likely fix is to ensure that the guest does not poke this particular descriptor type into its GDT, but if necessary we may be able to make the descriptor-validation code a little bit more flexible. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12/12/06, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:> On 11/12/06 8:12 pm, "Tim Wood" <twwood@gmail.com> wrote: > > > ... > > What segment type are you seeing? Can you dump the offending descriptor? The > likely fix is to ensure that the guest does not poke this particular > descriptor type into its GDT, but if necessary we may be able to make the > descriptor-validation code a little bit more flexible. > > -- Keir >I''ve attached a full dump of the descriptors checked during restore. There are 10 that cause errors. Most of the errors fail the check [b & _SEGMENT_TYPE) != 0xc00], for example: #Format: descriptor# a b 31 0 C03CA604 80 C007D0F4 C03CA0F4 110 0 C03CAB14 159 0 C03CA618 208 C007D108 C03CA108 238 0 C03CAB28 Some others seem to fail during truncation ( !(b & _SEGMENT_G): 114 0 C00DB604 242 0 C00DB618 370 0 C00DB62C 498 0 C00DB640 I''m not using PAE or 64bit, so I''m not sure why the truncation errors would be occurring. The attached file gives all the descriptors and if there was an error thanks, Tim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12/12/06 5:24 pm, "Tim Wood" <twwood@gmail.com> wrote:> I''ve attached a full dump of the descriptors checked during restore. > There are 10 that cause errors. Most of the errors fail the check [b > & _SEGMENT_TYPE) != 0xc00], for example:That''s not a GDT page. It''s a page apparently containing kernel virtual addresses. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel