[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] xc_domain_translate_gpfn_list vanished from unstable

  • To: James Pendergrass <James.Pendergrass@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Wed, 10 Jan 2007 10:09:34 +0000
  • Delivery-date: Wed, 10 Jan 2007 02:09:20 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acc0n201q/A3CqCSEduNDgAX8io7RQ==
  • Thread-topic: [Xen-devel] xc_domain_translate_gpfn_list vanished from unstable

On 9/1/07 20:48, "James Pendergrass" <James.Pendergrass@xxxxxxxxxx> wrote:

> but this fails for
> HVM's (changeset 13282:9865145e53eb)
> when xc_translate_foreign_address claims that it is unable to map the
> PD of the HVM.
> Presumably this is because the cr3 value returned by
> xc_vcpu_getcontext holds the machine frame number
> page tables (presumably this is the guest cr3 so the page tables map
> gvas to gpfns and not the host cr3 that
> is used by the hardware to map gvas to gmfns).

No, CR3 is a pseudophysical address (it's the value that the guest wrote,
with no translation done on it). If the failure message mentions 'PD' rather
than 'PML4' then I think it's the table 2 levels down that isn't getting
mapped. Add some extra tracing to the function and check that the PDEs
you've seen on the pagetable walk actually look sane.

> Can you suggest an approach that would actually work?

Expect to need to fix up functions in libxc. Some of these are only used by
debug/diagnostic tools so they're not always up to date.

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.