All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ryan Harper <ryanh@us.ibm.com>
To: Keir Fraser <keir@xensource.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <Christoph.Egger@amd.com>,
	xen-devel@lists.xensource.com
Subject: Re: [PATCH 2/4] [HVM] introduce CPU affinity for allocate_physmap call
Date: Mon, 13 Aug 2007 15:49:47 -0500	[thread overview]
Message-ID: <20070813204947.GC1228@us.ibm.com> (raw)
In-Reply-To: <C2E623FF.1419B%keir@xensource.com>

* Keir Fraser <keir@xensource.com> [2007-08-13 09:08]:
> On 13/8/07 13:59, "Christoph Egger" <Christoph.Egger@amd.com> wrote:
> 
> >> We cannot change the size of existing hypercall structures.
> > 
> > Except Xen bumps major version number to 4 ? :-)
> > 
> > You are worrying about PV guests that lag behind with syncing
> > pulic headers such as NetBSD/Xen ?
> 
> It's not merely an API issue, it's an ABI compatibility issue. Existing
> guests will provide structures that are too small (and thus have trailing
> garbage, or potentially even cross over into an unmapped page causing
> copy_from_guest() to fail). Also this particular structure is included
> inside others (like struct xen_memory_exchange) and will change all the
> field offsets. Not good.
> 
> > Making struct xen_machphys_mapping NUMA-aware is also a no-go, right?
> > It would additionally need a min_mfn and a vnodeid member.
> 
> Actually I think it can stay as is. Guests are supposed to be robust against
> unmapped holes in the m2p table. So we can continue to have one big virtual
> address range covering all valid MFNs. This is only going to fail if virtual
> address space is scarce compared with machine address space (e.g., we kind
> of run up against this in a mild way with x86 PAE).
> 
> > Oh, and how should the guest query how many vnode's exist?
> 
> I think we should add topology discovery hypercalls. Xen needs to know this
> stuff anyway, so we just provide a mechanism for guests to extract it. An
> alternative is to start exporting virtual ACPI tables to PV guests.

One concern has been the static nature of the ACPI SRAT data versus the
dynamic ability of the vcpu to cpu mapping.  If the scheduler is
migrating the guest vcpu to various cpus, then the SRAT information is
likely to be incorrect.

That said, if one creates a vnode, and it sufficiently restricts the
vcpu affinity, then accurate SRAT information can be exported for the
guest to utilize.


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh@us.ibm.com

  reply	other threads:[~2007-08-13 20:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-13 10:02 [PATCH 2/4] [HVM] introduce CPU affinity for allocate_physmap call Andre Przywara
2007-08-13 10:30 ` Keir Fraser
2007-08-13 12:59   ` Christoph Egger
2007-08-13 14:00     ` Isaku Yamahata
2007-08-13 14:06     ` Keir Fraser
2007-08-13 20:49       ` Ryan Harper [this message]
2007-08-15 10:12         ` Andre Przywara
2007-08-15 11:18           ` Andi Kleen
2007-08-15 10:13       ` Andre Przywara
2007-08-15 10:43         ` Keir Fraser

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=20070813204947.GC1228@us.ibm.com \
    --to=ryanh@us.ibm.com \
    --cc=Christoph.Egger@amd.com \
    --cc=andre.przywara@amd.com \
    --cc=keir@xensource.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.