From: Tim Deegan <tim@xen.org>
To: Paul Durrant <Paul.Durrant@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH 4 of 5] Add code to track the address of the VM generation id buffer across a
Date: Mon, 28 Nov 2011 13:48:34 +0000 [thread overview]
Message-ID: <20111128134834.GC79829@ocelot.phlegethon.org> (raw)
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4DCC@LONPMAILBOX01.citrite.net>
At 13:26 +0000 on 28 Nov (1322486771), Paul Durrant wrote:
> > > +/* Address of VM generation id buffer */ #define
> > > +HVM_PARAM_VM_GENERATION_ID_ADDR 27
> > > +
> > > +#define HVM_NR_PARAMS 28
> > >
> > > #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
> >
> > Since the hypervisor doesn't use this value, I don't think this is
> > the right place for it to live. Tools-only VM metadata should
> > probably go in xenstore or in the toolstacks' own datastructures.
> >
>
> Yes, I was a little unsure about that. Is there any precedent for
> getting information from hvmloader out to the tools? Writing guest
> physical addresses into xenstore seems like the wrong thing to but
> apart from HVM params or the shared hvm info page, I couldn't think of
> another way apart from putting the VM generation id in a static
> well-known place.
Presumably in this case the tools can find the address by walking the
ACPI tables, just like the guest OS would. :P Not very pretty, though.
I don't think there's anything wrong with putting a GPA into
xenstore. All the other tools interactions are in guest-physical
addressing already. IIRC HVMloader's xenbus client doesn't have a
xenstore_write() but it shouldn't be hard to add.
I can't think of another way to pass data from hvmloader to the
tools right now -- I think the hvm-info page should probably be
replaced entirely with xenstore keys at some point.
Tim.
next prev parent reply other threads:[~2011-11-28 13:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-28 12:15 [PATCH 0 of 5] Add support for a VM generation ID virtual device Paul Durrant
2011-11-28 12:15 ` [PATCH 1 of 5] Add an ACPI device exposing a package called ADDR, evaluating to two Paul Durrant
2011-11-28 12:15 ` [PATCH 2 of 5] Add 'ctype' infrastructure to hvmloader Paul Durrant
2011-11-28 12:28 ` Tim Deegan
2011-11-28 13:21 ` Paul Durrant
2011-11-28 12:15 ` [PATCH 3 of 5] Allocate an 8 byte buffer to contain the VM generation id and populate it Paul Durrant
2011-11-28 12:15 ` [PATCH 4 of 5] Add code to track the address of the VM generation id buffer across a Paul Durrant
2011-11-28 12:32 ` Tim Deegan
2011-11-28 13:26 ` Paul Durrant
2011-11-28 13:48 ` Tim Deegan [this message]
2011-11-28 14:36 ` Paul Durrant
2011-11-28 12:15 ` [PATCH 5 of 5] Modify init_vm86_tss() to take advantage of the new set_param() function Paul Durrant
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=20111128134834.GC79829@ocelot.phlegethon.org \
--to=tim@xen.org \
--cc=Paul.Durrant@citrix.com \
--cc=xen-devel@lists.xensource.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.