Keir Fraser wrote:
On 4/7/08 08:57, "Andre Przywara" <andre.przywara@xxxxxxx> wrote:
This patch extends the memops hypercall in a compatible way to transport
a desired NUMA node number. The address_bits field will be limited to 8
bits and is now embedded in the mem_flags member, which additionally
contains the node number (limited to 8 bit). Passing a node number of
'0' (currently the default) will revert to automatic node selection
(based on currently scheduled node).
Should unprivileged domUs be allowed to specify the NUMA node they allocate
from, regardless of whether they even run there? Seems like a breakage of
guest isolation to me.
Good catch (I code in HVM land most of the time), I hope this small
(attached) patch fixes this.
Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx>
Regards,
Andre.
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 277-84917
----to satisfy European Law for business letters:
AMD Saxony Limited Liability Company & Co. KG,
Wilschdorfer Landstr. 101, 01109 Dresden, Germany
Register Court Dresden: HRA 4896, General Partner authorized
to represent: AMD Saxony LLC (Wilmington, Delaware, US)
General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
diff -r aa69281c1ecf xen/common/memory.c
--- a/xen/common/memory.c Thu Jul 03 13:20:35 2008 +0200
+++ b/xen/common/memory.c Fri Jul 04 13:13:12 2008 +0200
@@ -528,7 +528,8 @@
args.memflags = MEMF_bits(XENMEM_addr_bits(reservation.mem_flags));
}
- args.memflags |= MEMF_node(XENMEM_get_node(reservation.mem_flags));
+ if (IS_PRIV(current->domain))
+ args.memflags |= MEMF_node(XENMEM_get_node(reservation.mem_flags));
if ( likely(reservation.domid == DOMID_SELF) )
{
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home