[Xen-devel] 答复: Windows 2008 r2 smp guest booting hang with viridian=true on ovmf(xen latest version 4.5.1-rc1 + latest edk2)
Can anyone have idea about how to boot window 2008 r2 smp guest in ovmf with
viridian flag is true?
Thanks!
发件人: Fanhenglong
发送时间: 2015年5月19日 23:22
收件人: xen-devel@lists.xen.org
抄送: 'k...@xen.org'; 'paul.durr...@citrix.com'; 'jbeul...@suse.com';
edk2-de...@lists.sourceforge.net; Hanweidong (Randy); Liuqiming (John);
Liuqiming (John)
主题: Windows 2008 r2 smp guest booting hang with viridian=true on ovmf(xen
latest version 4.5.1-rc1 + latest edk2)
Hi all,
I have test win2008 r2 guest on ovmf with xen latest version + edk2 latest
Xen :
4.5.1-rc1http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=0c4e0ef608c98abef6220b0b027d9ce8ec65fd5f
Edk2 : e2ab3f819f4e8165c24bd6f4fdc24ef17bdf458b (date:2015/5/18)
and come across a problem:
when the viridian flag is true,win2008 r2 guest can boot success with unique
processor, but will hang with smp processor on ovmf;
the viridian flag is false, win2008 r2 guest can boot success both in unique
and smp processor on ovmf;
if win2008 r2 with viridian=faulse, it may bring 0x101 bluescreen
http://old-list-archives.xenproject.org/archives/html/xen-users/2009-07/msg00661.html
I try to resolve the problem,
I also run the same testcase on kvm and vmvare ,vm also have the same question,
vmare is ok;
so I print the cupid function return value in vmvare guest os,
the below table show the detailed information in vmvare guest os,
get cpu id 0 : 000b 756e6547 6c65746e 49656e69
get cpu id 1 : 000106a5 00010800 80982201 0fabfbff
get cpu id 2 : 55035a01 00f0b2e4 09ca212c
get cpu id 3 :
get cpu id 4 :
get cpu id 5 :
get cpu id 4000 : 4010 61774d56 4d566572 65726177
get cpu id 4001 :
get cpu id 4002 :
get cpu id 4003 :
get cpu id 4004 :
get cpu id 4005 :
get cpu id 4006 :
get cpu id 4070 : 00ac 0012
get cpu id 4071 : 00ac 0012
get cpu id 4072 : 00ac 0012
get cpu id 4073 : 00ac 0012
get cpu id 4100 : 00ac
get cpu id 4101 : 00ac
get cpu id 4102 : 00ac
get cpu id 4103 : 00ac
get cpu id 4104 : 00ac
get cpu id 4105 : 00ac
get cpu id 4106 : 00ac
get cpu id 8000 : 8008
get cpu id 8001 : 0001 2810
get cpu id 8002 : 65746e49 2952286c 6f655820 2952286e
get cpu id 8003 : 55504320 20202020 20202020 45202020
get cpu id 8004 : 30323535 20402020 37322e32 007a4847
get cpu id 8005 :
get cpu id 8006 : 01006040
get cpu id 8007 : 0100
get cpu id 8008 : 3028
get cpu id 8009 : 00ac
I modified cpuid_viridian_leaves function in xen/arch/x86/hvm/viridian.c (as
the following red bold code)
to return value 0 for cupid (function=4001), and win2008 r2 smp guest
can boot success on ovmf;
int cpuid_viridian_leaves(unsigned int leaf, unsigned int *eax,
unsigned int *ebx, unsigned int *ecx,
unsigned int *edx)
{
struct domain *d = current-domain;
if ( !is_viridian_domain(d) )
return 0;
leaf -= 0x4000;
if ( leaf 6 )
return 0;
*eax = *ebx = *ecx = *edx = 0;
switch ( leaf )
{
case 0:
*eax = 0x4006; /* Maximum leaf */
*ebx = 0x7263694d; /* Magic numbers */
*ecx = 0x666F736F;
*edx = 0x76482074;
break;
case 1:
//original code *eax = 0x31237648; /* Version number */
*eax = 0; //code after modified
break;
based on hyperv spec, Microsoft Hypervisor CPUID Leaves,
0x4001
Hypervisor vendor-neutral interface identification. This determines the
semantics of the leaves from 0x4002 through 0x40FF.
EAX 0x31237648―“Hv#1”
EBX Reserved
ECX Reserved
EDX Reserved
May be in xen platform, if window 2008 r2 guest os boot in ovmf, the
cupid(function=0x4001) must not return EAX 0x31237648―“Hv#1”,
Can anyone have idea about how to boot window 2008 r2 guest in ovmf and do not
bring other problem(eg,0x101 bluescreen)?
Thanks!
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 1/5] pci: add pci_iomap_wc() variants
On Tue, May 19, 2015 at 4:02 PM, Bjorn Helgaas bhelg...@google.com wrote: [-cc Venkatesh (bouncing) On Tue, May 19, 2015 at 5:46 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas bhelg...@google.com wrote: Acked-by: Bjorn Helgaas bhelg...@google.com Thanks! Who's tree should this go through? I don't know. This is the only patch that went to linux-pci, so I haven't seen the rest. Oh I only rev'd a v5 for 1/5 as that's the only one that had feedback asking for changes. Patch v4 2/5 was for lib: devres: add pcim_iomap_wc() variants, you had questions about EXPORT_SYMBOL_GPL() and the fact that this is not yet used. I replied. This patch can then be ignored but again, I'd hate for folks to go in and try to add a non EXPORT_SYMBOL_GPL() symbol of this. Patches v4 3-5 remain intact, I had addressed it to you, but failed to Cc linux-pci, I'll go ahead and bounce those now. Just today Dave Arlie provided a Reviewed-by to some simple framebuffer device driver changes. I wonder if these changes should go through the framebuffer tree provided you already gave the Acked-by for the PCI parts, or if the PCI parts should go in first and only later (I guess we'd have to wait) then intake the driver changes that use the symbol. What we decide should likely also apply to the series that adds pci_ioremap_wc_bar() and makes use of it on drivers. Dave, Tomi, any preference? Maybe send Bjorn a pull request with a tree with the pci changes, and the fb changes reviewed-by me and acked by Tomi. Seems like it could be the simplest path forward. Dave. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/pci: correct comment of pci_device_detect()
Actually we always return 1 if pci device exists.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
xen/drivers/passthrough/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 862e20f..6cb6e00 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -905,7 +905,7 @@ out:
}
/*
- * detect pci device, return 0 if it exists, or return 0
+ * detect pci device, return 1 if it exists, or return 0
*/
int __init pci_device_detect(u16 seg, u8 bus, u8 dev, u8 func)
{
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 56745: regressions - FAIL
flight 56745 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/56745/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 56492 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 56492 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass version targeted for testing: ovmf aee257db53c87e5657b9e2c8aa558b58c4ec0fb4 baseline version: ovmf f1f0f0deb6e64df6b7c04ead7330afecf5537e46 People who touched revisions under test: Yao, Jiewen jiewen@intel.com Eric Dong eric.d...@intel.com Jeff Fan jeff@intel.com Liming Gao liming@intel.com Ruiyu Ni ruiyu...@intel.com Star Zeng star.z...@intel.com Yao, Jiewen jiewen@intel.com jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-xl-qemuu-winxpsp3 pass test-amd64-i386-xl-qemuu-winxpsp3pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit aee257db53c87e5657b9e2c8aa558b58c4ec0fb4 Author: Eric Dong eric.d...@intel.com Date: Tue May 19 09:26:25 2015 + MdeModulePkg: Fix potential buffer overflow issues. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong eric.d...@intel.com Reviewed-by: Liming Gao liming@intel.com git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17472 6f19259b-4bc3-4df7-8a09-765794883524 commit 5f25ead991ad34f5d11b6b7f5f6a50479142934f Author: Eric Dong eric.d...@intel.com Date: Tue May 19 09:22:59 2015 + MdeModulePkg: Enumerate all string packages in one driver when search the keyword. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong eric.d...@intel.com Reviewed-by: Liming Gao liming@intel.com git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17471 6f19259b-4bc3-4df7-8a09-765794883524 commit ee50ff41a6bdb32bc6fb37f75a856047b97d4df6 Author: Liming Gao liming@intel.com Date: Tue May 19 07:22:14 2015 + MdeModulePkg: Update the short name for persistent memory type. This change will make DEBUG information be aligned with DEBUG_GCD enabled. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao liming@intel.com Reviewed-by: Star Zeng star.z...@intel.com git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17470 6f19259b-4bc3-4df7-8a09-765794883524 commit 0e44e86191db803becf31626addcaf1a866cc8ad Author: Yao, Jiewen jiewen@intel.com Date: Tue May 19 03:16:09 2015 + Add comments for INF file to declare guid/protocol usage. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yao, Jiewen jiewen@intel.com git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17469
[Xen-devel] XEN same page merging.
Dear all, Could you please advise me whether XEN has a mechanism to merge/map same memory pages of different VMs into a single physical page in the available physical address space. If yes, is there a compilation flag to disable such feature? Please note I am running hardware-assisted XEN on an ARM Cortex-A15. Thank you so much. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/4] x86: move syscall trampolines off the stack
On 19.05.15 at 18:59, andrew.coop...@citrix.com wrote:
On 18/05/15 13:46, Jan Beulich wrote:
+unsigned long alloc_stub_page(unsigned int cpu, unsigned long *mfn)
+{
+unsigned long stub_va;
+struct page_info *pg;
+
+if ( *mfn )
+pg = mfn_to_page(*mfn);
+else
+{
+nodeid_t node = cpu_to_node(cpu);
+unsigned int memflags = node != NUMA_NO_NODE ? MEMF_node(node) : 0;
+
+pg = alloc_domheap_page(NULL, memflags);
+if ( !pg )
+return 0;
+
+unmap_domain_page(memset(__map_domain_page(pg), 0xcc, PAGE_SIZE));
Seems like memset_page(pg, int val) might be a nice piece of cleanup.
Except for this one (which, if at all, should be a follow-up patch) I'll
see to address all of your comments for v2.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 56759: regressions - FAIL
flight 56759 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/56759/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 17 leak-check/check fail REGR. vs. 56375 Regressions which are regarded as allowable (not blocking): test-amd64-i386-freebsd10-amd64 13 guest-localmigrate fail REGR. vs. 56375 test-amd64-amd64-libvirt 11 guest-start fail REGR. vs. 56375 test-amd64-i386-freebsd10-i386 16 guest-localmigrate/x10 fail blocked in 56375 test-armhf-armhf-libvirt 11 guest-start fail like 56375 test-amd64-i386-libvirt 11 guest-start fail like 56375 test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 56544-bisect Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-xsm 11 guest-start fail never pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-xsm 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 11 guest-start fail never pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-armhf-armhf-libvirt-xsm 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-xsm 11 guest-start fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: xen 1037e33c88bb0e1fe530c164f242df17030102e1 baseline version: xen e13013dbf1d5997915548a3b5f1c39594d8c1d7b People who touched revisions under test: David Vrabel david.vra...@citrix.com George Dunlap george.dun...@eu.citrix.com Ian Campbell ian.campb...@citrix.com Jan Beulich jbeul...@suse.com Julien Grall julien.gr...@citrix.com (ARM) Konrad Rzeszutek Wilk konrad.w...@oracle.com Roger Pau Monné roger@citrix.com jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemut-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-libvirt-xsm fail test-armhf-armhf-libvirt-xsm fail
Re: [Xen-devel] [PATCH v6 02/10] libxl: support SHUTDOWN_soft_reset shutdown reason
On Wed, May 13, 2015 at 11:49:37AM +0200, Vitaly Kuznetsov wrote:
Use letter 'S' to indicate a domain in such state.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
tools/libxl/libxl.h | 7 +++
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c | 2 +-
tools/python/xen/lowlevel/xl/xl.c | 1 +
4 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index efc0617..8be0840 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -192,6 +192,13 @@
* is not present, instead of ERROR_INVAL.
*/
#define LIBXL_HAVE_ERROR_DOMAIN_NOTFOUND 1
+
+/*
+ * LIBXL_HAVE_SHUTDWON_REASON_SOFT_RESET indicates that libxl supports
+ * 'soft reset' shutdown reason in enum libxl_shutdown_reason.
+ */
+#define LIBXL_HAVE_SHUTDWON_REASON_SOFT_RESET 1
+
This #define is too fine-grained. And you didn't have any #define in
your last patch to advertise the new functionality.
You can just use LIBXL_HAVE_SOFT_RESET in your last patch.
Wei.
/*
* libxl ABI compatibility
*
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 023b21e..986c4d3 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -177,6 +177,7 @@ libxl_shutdown_reason = Enumeration(shutdown_reason, [
(2, suspend),
(3, crash),
(4, watchdog),
+(5, soft_reset),
], init_val = LIBXL_SHUTDOWN_REASON_UNKNOWN)
libxl_vga_interface_type = Enumeration(vga_interface_type, [
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 526a1f6..c8cdf6e 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3704,7 +3704,7 @@ static void list_domains(bool verbose, bool context,
bool claim, bool numa,
bool cpupool, const libxl_dominfo *info, int
nb_domain)
{
int i;
-static const char shutdown_reason_letters[]= -rscw;
+static const char shutdown_reason_letters[]= -rscwS;
libxl_bitmap nodemap;
libxl_physinfo physinfo;
diff --git a/tools/python/xen/lowlevel/xl/xl.c
b/tools/python/xen/lowlevel/xl/xl.c
index 32f982a..7c61160 100644
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -784,6 +784,7 @@ PyMODINIT_FUNC initxl(void)
_INT_CONST_LIBXL(m, SHUTDOWN_REASON_SUSPEND);
_INT_CONST_LIBXL(m, SHUTDOWN_REASON_CRASH);
_INT_CONST_LIBXL(m, SHUTDOWN_REASON_WATCHDOG);
+_INT_CONST_LIBXL(m, SHUTDOWN_REASON_SOFT_RESET);
genwrap__init(m);
}
--
1.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 3/5] tools/libxl: move remus codes into libxl_remus.c
move remus codes into libxl_remus.c
Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
CC: Andrew Cooper andrew.coop...@citrix.com
---
tools/libxl/Makefile | 2 +-
tools/libxl/libxl.c | 55 +---
tools/libxl/libxl_dom.c | 223 ++-
tools/libxl/libxl_internal.h | 11 ++
tools/libxl/libxl_remus.c| 306 +++
5 files changed, 327 insertions(+), 270 deletions(-)
create mode 100644 tools/libxl/libxl_remus.c
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 21558b0..a9abdbc 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -56,7 +56,7 @@ else
LIBXL_OBJS-y += libxl_nonetbuffer.o
endif
-LIBXL_OBJS-y += libxl_remus_device.o libxl_remus_disk_drbd.o
+LIBXL_OBJS-y += libxl_remus.o libxl_remus_device.o libxl_remus_disk_drbd.o
LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 7259061..43a4b88 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -825,10 +825,6 @@ out:
return ptr;
}
-static void libxl__remus_setup_done(libxl__egc *egc,
-libxl__remus_devices_state *rds, int rc);
-static void libxl__remus_setup_failed(libxl__egc *egc,
- libxl__remus_devices_state *rds, int rc);
static void remus_failover_cb(libxl__egc *egc,
libxl__domain_save_state *dss, int rc);
@@ -877,63 +873,14 @@ int libxl_domain_remus_start(libxl_ctx *ctx,
libxl_domain_remus_info *info,
assert(info);
-/* Convenience aliases */
-libxl__remus_devices_state *const rds = dss-rds;
-
-if (libxl_defbool_val(info-netbuf)) {
-if (!libxl__netbuffer_enabled(gc)) {
-LOG(ERROR, Remus: No support for network buffering);
-rc = ERROR_FAIL;
-goto out;
-}
-rds-device_kind_flags |= (1 LIBXL__DEVICE_KIND_VIF);
-}
-
-if (libxl_defbool_val(info-diskbuf))
-rds-device_kind_flags |= (1 LIBXL__DEVICE_KIND_VBD);
-
-rds-ao = ao;
-rds-domid = domid;
-rds-callback = libxl__remus_setup_done;
-
/* Point of no return */
-libxl__remus_devices_setup(egc, rds);
+libxl__remus_setup(egc, dss);
return AO_INPROGRESS;
out:
return AO_ABORT(rc);
}
-static void libxl__remus_setup_done(libxl__egc *egc,
-libxl__remus_devices_state *rds, int rc)
-{
-libxl__domain_save_state *dss = CONTAINER_OF(rds, *dss, rds);
-STATE_AO_GC(dss-ao);
-
-if (!rc) {
-libxl__domain_save(egc, dss);
-return;
-}
-
-LOG(ERROR, Remus: failed to setup device for guest with domid %u, rc %d,
-dss-domid, rc);
-rds-callback = libxl__remus_setup_failed;
-libxl__remus_devices_teardown(egc, rds);
-}
-
-static void libxl__remus_setup_failed(libxl__egc *egc,
- libxl__remus_devices_state *rds, int rc)
-{
-libxl__domain_save_state *dss = CONTAINER_OF(rds, *dss, rds);
-STATE_AO_GC(dss-ao);
-
-if (rc)
-LOG(ERROR, Remus: failed to teardown device after setup failed
- for guest with domid %u, rc %d, dss-domid, rc);
-
-dss-callback(egc, dss, rc);
-}
-
static void remus_failover_cb(libxl__egc *egc,
libxl__domain_save_state *dss, int rc)
{
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 1681a12..b937d99 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1405,192 +1405,6 @@ int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
return 0;
}
-/*- remus callbacks -*/
-static void remus_domain_suspend_callback_common_done(libxl__egc *egc,
-libxl__domain_suspend_state *dss, int ok);
-static void remus_devices_postsuspend_cb(libxl__egc *egc,
- libxl__remus_devices_state *rds,
- int rc);
-static void remus_devices_preresume_cb(libxl__egc *egc,
- libxl__remus_devices_state *rds,
- int rc);
-
-static void libxl__remus_domain_suspend_callback(void *data)
-{
-libxl__save_helper_state *shs = data;
-libxl__egc *egc = shs-egc;
-libxl__domain_save_state *dss = CONTAINER_OF(shs, *dss, shs);
-libxl__domain_suspend_state *dss2 = dss-dss;
-
-dss2-callback_common_done = remus_domain_suspend_callback_common_done;
-libxl__domain_suspend(egc, dss2);
-}
-
-static void remus_domain_suspend_callback_common_done(libxl__egc *egc,
-libxl__domain_suspend_state *dss, int ok)
-{
-libxl__domain_save_state *dsvs = CONTAINER_OF(dss, *dsvs, dss);
-
[Xen-devel] [PATCH v1 0/5] Misc cleanups for libxl
This patchset mainly focus on libxl save, most of the patches are simply move codes out of libxl_dom.c, no functional changes, may conflict with Andrew Cooper's libxl work for migration v2, so CCed Andrew for comments. For convenience, my previous sent patch [PATCH v1] libxl/save: Refactor libxl__domain_suspend_state is included in this series because all the other patches in this series are based on that. Please see individual patch for detail. Can get the whole patchset from: https://github.com/macrosheep/xen/tree/misc-libxl-v1 Yang Hongyang (5): libxl/save: Refactor libxl__domain_suspend_state tools/libxl: move domain suspend codes into a separate file tools/libxl: move remus codes into libxl_remus.c tools/libxl: move toolstack code into libxl_toolstack.c tools/libxl: move domain save codes into libxl_dom_save.c tools/libxl/Makefile |5 +- tools/libxl/libxl.c | 67 +-- tools/libxl/libxl_dom.c | 1202 -- tools/libxl/libxl_dom_save.c | 493 tools/libxl/libxl_dom_suspend.c | 400 + tools/libxl/libxl_internal.h | 62 +- tools/libxl/libxl_netbuffer.c|2 +- tools/libxl/libxl_remus.c| 306 ++ tools/libxl/libxl_save_callout.c |2 +- tools/libxl/libxl_toolstack.c| 196 +++ 10 files changed, 1452 insertions(+), 1283 deletions(-) create mode 100644 tools/libxl/libxl_dom_save.c create mode 100644 tools/libxl/libxl_dom_suspend.c create mode 100644 tools/libxl/libxl_remus.c create mode 100644 tools/libxl/libxl_toolstack.c -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ARM-Xen customization of stage two translation.
On 20/05/15 09:39, Mazen Ezzeddine (Student) wrote: Dear all, Hello, I am using hardware assisted XEN on ARM cortex A-15, could you please hint me on the below: I want the stage two translation from IPA to PA through the stage two translation to exclude a particular small contiguous region (some physical frames) of the physical memory ? is this achievable? could you please hint me on how can I accomplish? Is this physical region belong to the RAM or a device? Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen BUG at page_alloc.c:1738 (Xen 4.5)
On 19.05.15 at 20:06, ma...@mhtx.net wrote: I've been doing some testing of Xen 4.5 on Fedora 22 (due out within a week) and I have an error that prevents the server from booting in the very early boot process: (XEN) Xen call trace: (XEN)[82d08011d160] free_domheap_pages+0x240/0x430 (XEN)[82d08018c944] mmio_ro_do_page_fault+0x114/0x160 (XEN)[82d0801a4c10] do_page_fault+0x1a0/0x4f0 (XEN)[82d080239768] handle_exception_saved+0x2e/0x6c (XEN) (XEN) (XEN) (XEN) Panic on CPU 0: (XEN) Xen BUG at page_alloc.c:1738 (XEN) The full output is over in a Github Gist[1]. I've tested this on some physical machines (Dell, HP, and SuperMicro servers) as well as within a KVM virtual machine but I get the same boot error each time. Considering that no-one else is seeing this - is this perhaps connected to you building Xen with pre-release gcc 5.0.1? This is also because in order for the above to indeed occur, mmio_ro_do_page_fault()'s put_page() would need to drop the last reference of a page, yet page_get_owner_and_reference() doesn't obtain a reference when a page is unallocated (and hence unowned), i.e. normally a page would have a refcount of at least 2 here. Hence this would be possible only due to a race, but the exact same race to be observed on different hardware _and_ under an emulator is extremely unlikely. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/pci: correct comment of pci_device_detect()
On 2015/5/20 18:06, Jan Beulich wrote: On 20.05.15 at 08:53, tiejun.c...@intel.com wrote: --- a/xen/drivers/passthrough/pci.c +++ b/xen/drivers/passthrough/pci.c @@ -905,7 +905,7 @@ out: } /* - * detect pci device, return 0 if it exists, or return 0 + * detect pci device, return 1 if it exists, or return 0 */ int __init pci_device_detect(u16 seg, u8 bus, u8 dev, u8 func) The comment is pretty pointless, and could go away altogether if the function's return type was switched to bool_t. Care to do such Yeah, I also consider this change initially but I'm not sure if this is necessary. Now I think I'd like to follow this. an alternative patch (including replacing some of the callers using == 0 on the result to use ! instead)? Sure. Thanks Tiejun ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 56805: regressions - FAIL
flight 56805 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/56805/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 56492 build-amd64 5 xen-build fail REGR. vs. 56492 build-i3865 xen-build fail REGR. vs. 56492 build-amd64-xsm 5 xen-build fail REGR. vs. 56492 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 9d02f824bb50646d32bfa3ffadf0f8d6a896fdc3 baseline version: ovmf f1f0f0deb6e64df6b7c04ead7330afecf5537e46 People who touched revisions under test: Yao, Jiewen jiewen@intel.com Chao Zhang chao.b.zh...@intel.com Eric Dong eric.d...@intel.com Feng Tian feng.t...@intel.com Hao Wu hao.a...@intel.com Jeff Fan jeff@intel.com jiaxinwu jiaxin...@intel.com Liming Gao liming@intel.com Ruiyu Ni ruiyu...@intel.com Star Zeng star.z...@intel.com Yao, Jiewen jiewen@intel.com jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmblocked test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 blocked test-amd64-amd64-xl-qemuu-winxpsp3 blocked test-amd64-i386-xl-qemuu-winxpsp3blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 351 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ARM-Xen customization of stage two translation.
Hello, Please keep xen-devel CCed and avoid to top-post. On 20/05/15 12:47, Mazen Ezzeddine (Student) wrote: Thanks Jlien, Mainly it belongs to a device. I can't see why it would be problematic for a device and not for RAM or vice-versa? could you please hint me on what is the difference? Because you have to do it differently. For avoiding DOM0 to use a device, you can blacklist it per platform (see blacklist_dev xen/arch/arm/platforms/vexpress.c). While for the RAM you can update your device tree (see /memreserve/). Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Slective IRQ trapping.
Dear experts, Does Xen-ARM support selective IRQ trapping i.e. configure some devices IRQ to trap to hypervisor while the rest to be directly handled in the guest. Does ARM virtualization extensions support such a use-case? Thank you so much. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 1/2] xen/pvh: use a custom IO bitmap for PVH hardware domains
On 20.05.15 at 14:03, roger@citrix.com wrote: El 20/05/15 a les 13.46, Jan Beulich ha escrit: On 20.05.15 at 12:11, roger@citrix.com wrote: --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -42,6 +42,7 @@ #include xsm/xsm.h #include xen/trace.h #include xen/tmem.h +#include asm/setup.h This caused the ARM build to fail. Instead of once again reverting I applied the trivial fix eab0647587 without asking for permission by you ARM maintainers - I hope that's okay in a case like this. I'm sorry but I'm not sure what's wrong with this chunk, and AFAICT you seem to have applied it unmodified. The code added in xen/common/domain.c is protected with #ifdef CONFIG_X86 and ARM has a setup.h header. Right, but I suppose you then also looked at my fixup patch, which I think explains what was wrong? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Slective IRQ trapping.
On Wed, 2015-05-20 at 12:07 +, Mazen Ezzeddine (Student) wrote: Does Xen-ARM support selective IRQ trapping i.e. configure some devices IRQ to trap to hypervisor while the rest to be directly handled in the guest. Does ARM virtualization extensions support such a use-case? Please take a look at http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] x86/domctl: Fix getpageframeinfo* handling
In tree, there is one single caller of XEN_DOMCTL_getpageframeinfo3
(xc_get_pfn_type_batch()), and no callers of the older variants.
getpageframeinfo3 and getpageframeinfo2 are compatible if the parameter
contents are considered to be unsigned long, and indeed, a compat guest
calling getpageframeinfo3 falls through into the getpageframeinfo2 handler.
However, getpageframeinfo3 and getpageframeinfo2 have different algorithms for
calculating the eventual frame type, which means that a toolstack will get
different answers depending on whether it is compat or not.
Rewrite getpageframeinfo3 such that the code block can handle both regular and
compat guests, and use the original getpageframeinfo3 algorithm for frame
time, which is more complete.
Remove getpageframeinfo2 and getpageframeinfo1, as they are unused and
obsolete.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Keir Fraser k...@xen.org
CC: Jan Beulich jbeul...@suse.com
CC: Daniel De Graaf dgde...@tycho.nsa.gov
---
v2: Drop RFC, fix width, insert unlikely()
---
xen/arch/x86/domctl.c | 306 +--
xen/include/public/domctl.h | 27 +---
xen/xsm/flask/hooks.c |2 -
xen/xsm/flask/policy/access_vectors |2 +-
4 files changed, 78 insertions(+), 259 deletions(-)
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 20cdccb..684259b 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -91,237 +91,6 @@ long arch_do_domctl(
break;
}
-case XEN_DOMCTL_getpageframeinfo:
-{
-struct page_info *page;
-unsigned long mfn = domctl-u.getpageframeinfo.gmfn;
-
-ret = -EINVAL;
-if ( unlikely(!mfn_valid(mfn)) )
-break;
-
-page = mfn_to_page(mfn);
-
-if ( likely(get_page(page, d)) )
-{
-ret = 0;
-
-domctl-u.getpageframeinfo.type = XEN_DOMCTL_PFINFO_NOTAB;
-
-if ( (page-u.inuse.type_info PGT_count_mask) != 0 )
-{
-switch ( page-u.inuse.type_info PGT_type_mask )
-{
-case PGT_l1_page_table:
-domctl-u.getpageframeinfo.type = XEN_DOMCTL_PFINFO_L1TAB;
-break;
-case PGT_l2_page_table:
-domctl-u.getpageframeinfo.type = XEN_DOMCTL_PFINFO_L2TAB;
-break;
-case PGT_l3_page_table:
-domctl-u.getpageframeinfo.type = XEN_DOMCTL_PFINFO_L3TAB;
-break;
-case PGT_l4_page_table:
-domctl-u.getpageframeinfo.type = XEN_DOMCTL_PFINFO_L4TAB;
-break;
-}
-}
-
-put_page(page);
-}
-
-copyback = 1;
-break;
-}
-
-case XEN_DOMCTL_getpageframeinfo3:
-if ( !has_32bit_shinfo(currd) )
-{
-unsigned int n, j;
-unsigned int num = domctl-u.getpageframeinfo3.num;
-struct page_info *page;
-xen_pfn_t *arr;
-
-if ( unlikely(num 1024) ||
- unlikely(num != domctl-u.getpageframeinfo3.num) )
-{
-ret = -E2BIG;
-break;
-}
-
-page = alloc_domheap_page(currd, MEMF_no_owner);
-if ( !page )
-{
-ret = -ENOMEM;
-break;
-}
-arr = __map_domain_page(page);
-
-for ( n = ret = 0; n num; )
-{
-unsigned int k = min_t(unsigned int, num - n,
- PAGE_SIZE / sizeof(*arr));
-
-if ( copy_from_guest_offset(arr,
-domctl-u.getpageframeinfo3.array,
-n, k) )
-{
-ret = -EFAULT;
-break;
-}
-
-for ( j = 0; j k; j++ )
-{
-unsigned long type = 0;
-p2m_type_t t;
-
-page = get_page_from_gfn(d, arr[j], t, P2M_ALLOC);
-
-if ( unlikely(!page) ||
- unlikely(is_xen_heap_page(page)) )
-{
-if ( p2m_is_broken(t) )
-type = XEN_DOMCTL_PFINFO_BROKEN;
-else
-type = XEN_DOMCTL_PFINFO_XTAB;
-}
-else
-{
-switch( page-u.inuse.type_info PGT_type_mask )
-{
-case PGT_l1_page_table:
-type = XEN_DOMCTL_PFINFO_L1TAB;
-break;
-case PGT_l2_page_table:
-type = XEN_DOMCTL_PFINFO_L2TAB;
-break;
-
Re: [Xen-devel] ARM-Xen customization of stage two translation.
Thanks so much. I will ensure to keep xen-devel cced and avoid top-post. Sorry and thanks for notifying me. However, my use-case will involve a scenario where the the page frames excluded from the second stage translation are to be allocated on the fly (through a slightly modified second stage translation) to a special guest when scheduled. Does mreserve work in such scenario? Best regards, ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] XEN same page merging.
On 20/05/15 09:41, Mazen Ezzeddine (Student) wrote: Dear all, Hello, Could you please advise me whether XEN has a mechanism to merge/map same memory pages of different VMs into a single physical page in the available physical address space. If yes, is there a compilation flag to disable such feature? Xen doesn't merge/map automatically the same physical memory page in different VMs. Although, it may be possible for a guest to map a page from another domain in order to copy data. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 1/2] xen/pvh: use a custom IO bitmap for PVH hardware domains
On 20.05.15 at 12:11, roger@citrix.com wrote: --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -42,6 +42,7 @@ #include xsm/xsm.h #include xen/trace.h #include xen/tmem.h +#include asm/setup.h This caused the ARM build to fail. Instead of once again reverting I applied the trivial fix eab0647587 without asking for permission by you ARM maintainers - I hope that's okay in a case like this. But Roger, considering how many issues recent patches of yours introduced - please apply a little more care. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 1/2] xen/pvh: use a custom IO bitmap for PVH hardware domains
On 20.05.15 at 14:05, ian.campb...@citrix.com wrote: On Wed, 2015-05-20 at 12:46 +0100, Jan Beulich wrote: On 20.05.15 at 12:11, roger@citrix.com wrote: --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -42,6 +42,7 @@ #include xsm/xsm.h #include xen/trace.h #include xen/tmem.h +#include asm/setup.h This caused the ARM build to fail. Instead of once again reverting I applied the trivial fix eab0647587 without asking for permission by you ARM maintainers - I hope that's okay in a case like this. No problem, I'd have deleted it myself rather than commenting it out. I'm going to push just such a change momentarily, also without waiting for acks etc. I actually meant to (I commented it out only for checking that things build afterwards), but then forgot before committing. I'm sorry for the extra work this causes. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 1/2] xen/pvh: use a custom IO bitmap for PVH hardware domains
El 20/05/15 a les 14.07, Jan Beulich ha escrit: On 20.05.15 at 14:03, roger@citrix.com wrote: El 20/05/15 a les 13.46, Jan Beulich ha escrit: On 20.05.15 at 12:11, roger@citrix.com wrote: --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -42,6 +42,7 @@ #include xsm/xsm.h #include xen/trace.h #include xen/tmem.h +#include asm/setup.h This caused the ARM build to fail. Instead of once again reverting I applied the trivial fix eab0647587 without asking for permission by you ARM maintainers - I hope that's okay in a case like this. I'm sorry but I'm not sure what's wrong with this chunk, and AFAICT you seem to have applied it unmodified. The code added in xen/common/domain.c is protected with #ifdef CONFIG_X86 and ARM has a setup.h header. Right, but I suppose you then also looked at my fixup patch, which I think explains what was wrong? Yes, sorry for that, I've understood that you modified the patch in order to prevent ARM breakage, not that you pushed another on top. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 1/2] xen/pvh: use a custom IO bitmap for PVH hardware domains
Since a PVH hardware domain has access to the physical hardware create a
custom more permissive IO bitmap. The permissions set on the bitmap are
populated based on the contents of the ioports rangeset.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Suravee Suthikulpanit suravee.suthikulpa...@amd.com
Cc: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
Cc: Jun Nakajima jun.nakaj...@intel.com
Cc: Eddie Dong eddie.d...@intel.com
Cc: Kevin Tian kevin.t...@intel.com
Cc: Daniel De Graaf dgde...@tycho.nsa.gov
---
Changes since v6:
- Remove unneded check for hardware_domain.
- Reset Dom0 bitmap if using a late hardware domain.
Changes since v5:
- Fix build with XSM (CONFIG_LATE_HWDOM).
Changes since v4:
- Split changes also affecting PV to a separate patch.
- Use int with __clear_bit.
- Drop pointless cast in vmcb.c.
- Make HVM_IOBITMAP_SIZE contain the size of the io bitmap pages in bytes.
- Make setup_io_bitmap a hardware domain specific function, and allow it to
work with late hw domain init.
Changes since v3:
- Add the RTC IO ports to the list of blocked ports.
- Remove admin_io_okay since it's just a wrapper around
ioports_access_permitted.
Changes since v2:
- Add 0xcf8-0xcfb to the range of blocked (trapped) IO ports.
- Use rangeset_report_ranges in order to iterate over the range of not
trapped IO ports.
- Allocate the Dom0 PVH IO bitmap with _xmalloc_array, which allows setting
the alignment to PAGE_SIZE.
- Tested with Linux PV/PVH using 3.18 and FreeBSD PVH HEAD.
Changes since v1:
- Dynamically allocate PVH Dom0 IO bitmap if needed.
- Drop cast from construct_vmcs when writing the IO bitmap.
- Create a new function that sets up the bitmap before launching Dom0. This
is needed because ns16550_endboot is called after construct_dom0.
---
xen/arch/x86/hvm/hvm.c | 23 +--
xen/arch/x86/hvm/svm/vmcb.c | 2 +-
xen/arch/x86/hvm/vmx/vmcs.c | 5 +++--
xen/arch/x86/setup.c | 28
xen/common/domain.c | 3 +++
xen/include/asm-x86/hvm/domain.h | 2 ++
xen/include/asm-x86/hvm/hvm.h| 5 +
xen/include/asm-x86/setup.h | 1 +
8 files changed, 64 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 689e402..6ca8f35 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -77,9 +77,12 @@ integer_param(hvm_debug, opt_hvm_debug_level);
struct hvm_function_table hvm_funcs __read_mostly;
-/* I/O permission bitmap is globally shared by all HVM guests. */
+/*
+ * The I/O permission bitmap is globally shared by all HVM guests except
+ * the hardware domain that has a more permissive IO bitmap.
+ */
unsigned long __attribute__ ((__section__ (.bss.page_aligned)))
-hvm_io_bitmap[3*PAGE_SIZE/BYTES_PER_LONG];
+hvm_io_bitmap[HVM_IOBITMAP_SIZE/BYTES_PER_LONG];
/* Xen command-line option to enable HAP */
static bool_t __initdata opt_hap_enabled = 1;
@@ -1461,6 +1464,20 @@ int hvm_domain_initialise(struct domain *d)
goto fail1;
d-arch.hvm_domain.io_handler-num_slot = 0;
+/* Set the default IO Bitmap */
+if ( is_hardware_domain(d) )
+{
+d-arch.hvm_domain.io_bitmap = _xmalloc(HVM_IOBITMAP_SIZE, PAGE_SIZE);
+if ( d-arch.hvm_domain.io_bitmap == NULL )
+{
+rc = -ENOMEM;
+goto fail1;
+}
+memset(d-arch.hvm_domain.io_bitmap, ~0, HVM_IOBITMAP_SIZE);
+}
+else
+d-arch.hvm_domain.io_bitmap = hvm_io_bitmap;
+
if ( is_pvh_domain(d) )
{
register_portio_handler(d, 0, 0x10003, handle_pvh_io);
@@ -1496,6 +1513,8 @@ int hvm_domain_initialise(struct domain *d)
stdvga_deinit(d);
vioapic_deinit(d);
fail1:
+if ( is_hardware_domain(d) )
+xfree(d-arch.hvm_domain.io_bitmap);
xfree(d-arch.hvm_domain.io_handler);
xfree(d-arch.hvm_domain.params);
fail0:
diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 21292bb..10afd44 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -118,7 +118,7 @@ static int construct_vmcb(struct vcpu *v)
svm_disable_intercept_for_msr(v, MSR_AMD64_LWP_CBADDR);
vmcb-_msrpm_base_pa = (u64)virt_to_maddr(arch_svm-msrpm);
-vmcb-_iopm_base_pa = (u64)virt_to_maddr(hvm_io_bitmap);
+vmcb-_iopm_base_pa = virt_to_maddr(v-domain-arch.hvm_domain.io_bitmap);
/* Virtualise EFLAGS.IF and LAPIC TPR (CR8). */
vmcb-_vintr.fields.intr_masking = 1;
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 3123706..a714549 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1032,8 +1032,9 @@ static int construct_vmcs(struct vcpu *v)
}
/* I/O access bitmap. */
-__vmwrite(IO_BITMAP_A, virt_to_maddr((char
[Xen-devel] [PATCH v7 2/2] xen/pvh: trap access to sensitive IO ports
This is needed so Xen can properly trap 4 byte accesses to 0xcf8 in order to keep consistency with accesses to 0xcfc. The access to RTC ports also needs to be trapped in order to keep consistency, this includes RTC_PORT(0) and RTC_PORT(1) (0x70 and 0x71 respectively). Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Jan Beulich jbeul...@suse.com Cc: Andrew Cooper andrew.coop...@citrix.com --- Changes since v2: - Trap RTC ports. Changes since v1: - Only trap on accesses to 0xcf8. --- xen/arch/x86/setup.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index 44e7e2e..321500b 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -49,6 +49,7 @@ #include xen/cpu.h #include asm/nmi.h #include asm/alternative.h +#include asm/mc146818rtc.h /* opt_nosmp: If true, secondary processors are ignored. */ static bool_t __initdata opt_nosmp; @@ -1534,6 +1535,16 @@ void __hwdom_init setup_io_bitmap(struct domain *d) rc = rangeset_report_ranges(d-arch.ioport_caps, 0, 0x1, io_bitmap_cb, d); BUG_ON(rc); +/* + * NB: we need to trap accesses to 0xcf8 in order + * to intercept 4 byte accesses, that need to be + * handled by Xen in order to keep consistency. + * Access to 1 byte RTC ports also needs to be + * trapped in order to keep consistency. + */ +__set_bit(0xcf8, d-arch.hvm_domain.io_bitmap); +__set_bit(RTC_PORT(0), d-arch.hvm_domain.io_bitmap); +__set_bit(RTC_PORT(1), d-arch.hvm_domain.io_bitmap); } } -- 1.9.5 (Apple Git-50.3) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 0/2] xen/pvh: use a custom IO bitmap for PVH hardware domains
The only change in this version is to allow the io bitmap of Dom0 to be exchanged if a late hardware domain is used. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [v2][PATCH] xen/pci: make pci_device_detect() return as bool_t
This function should better return as bool_t and
remove that pointless comment.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
v2:
* Instead of correcting that comment directly, we make this function
return as bool_t.
xen/drivers/passthrough/pci.c | 7 ++-
xen/drivers/passthrough/vtd/dmar.c | 4 ++--
xen/include/xen/pci.h | 2 +-
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 862e20f..e30be43 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -904,10 +904,7 @@ out:
return ret;
}
-/*
- * detect pci device, return 0 if it exists, or return 0
- */
-int __init pci_device_detect(u16 seg, u8 bus, u8 dev, u8 func)
+bool_t __init pci_device_detect(u16 seg, u8 bus, u8 dev, u8 func)
{
u32 vendor;
@@ -965,7 +962,7 @@ static int __init _scan_pci_devices(struct pci_seg *pseg,
void *arg)
{
for ( func = 0; func 8; func++ )
{
-if ( pci_device_detect(pseg-nr, bus, dev, func) == 0 )
+if ( !pci_device_detect(pseg-nr, bus, dev, func) )
{
if ( !func )
break;
diff --git a/xen/drivers/passthrough/vtd/dmar.c
b/xen/drivers/passthrough/vtd/dmar.c
index 18d7903..2b07be9 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -524,7 +524,7 @@ acpi_parse_one_drhd(struct acpi_dmar_header *header)
d = PCI_SLOT(dmaru-scope.devices[i]);
f = PCI_FUNC(dmaru-scope.devices[i]);
-if ( pci_device_detect(drhd-segment, b, d, f) == 0 )
+if ( !pci_device_detect(drhd-segment, b, d, f) )
{
dprintk(XENLOG_WARNING VTDPREFIX,
Non-existent device (%04x:%02x:%02x.%u) is reported
@@ -636,7 +636,7 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
d = PCI_SLOT(rmrru-scope.devices[i]);
f = PCI_FUNC(rmrru-scope.devices[i]);
-if ( pci_device_detect(rmrr-segment, b, d, f) == 0 )
+if ( !pci_device_detect(rmrr-segment, b, d, f) )
{
dprintk(XENLOG_WARNING VTDPREFIX,
Non-existent device (%04x:%02x:%02x.%u) is reported
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 4377f3e..3908146 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -93,7 +93,7 @@ struct pci_dev {
extern spinlock_t pcidevs_lock;
bool_t pci_known_segment(u16 seg);
-int pci_device_detect(u16 seg, u8 bus, u8 dev, u8 func);
+bool_t pci_device_detect(u16 seg, u8 bus, u8 dev, u8 func);
int scan_pci_devices(void);
enum pdev_type pdev_type(u16 seg, u8 bus, u8 devfn);
int find_upstream_bridge(u16 seg, u8 *bus, u8 *devfn, u8 *secbus);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 1/2] xen/pvh: use a custom IO bitmap for PVH hardware domains
On Wed, 2015-05-20 at 12:46 +0100, Jan Beulich wrote: On 20.05.15 at 12:11, roger@citrix.com wrote: --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -42,6 +42,7 @@ #include xsm/xsm.h #include xen/trace.h #include xen/tmem.h +#include asm/setup.h This caused the ARM build to fail. Instead of once again reverting I applied the trivial fix eab0647587 without asking for permission by you ARM maintainers - I hope that's okay in a case like this. No problem, I'd have deleted it myself rather than commenting it out. I'm going to push just such a change momentarily, also without waiting for acks etc. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 1/2] xen/pvh: use a custom IO bitmap for PVH hardware domains
El 20/05/15 a les 13.46, Jan Beulich ha escrit: On 20.05.15 at 12:11, roger@citrix.com wrote: --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -42,6 +42,7 @@ #include xsm/xsm.h #include xen/trace.h #include xen/tmem.h +#include asm/setup.h This caused the ARM build to fail. Instead of once again reverting I applied the trivial fix eab0647587 without asking for permission by you ARM maintainers - I hope that's okay in a case like this. I'm sorry but I'm not sure what's wrong with this chunk, and AFAICT you seem to have applied it unmodified. The code added in xen/common/domain.c is protected with #ifdef CONFIG_X86 and ARM has a setup.h header. But Roger, considering how many issues recent patches of yours introduced - please apply a little more care. Yes, and I'm really sorry for that. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 56456: regressions - FAIL
El 19/05/15 a les 17.07, Roger Pau Monné ha escrit:
El 19/05/15 a les 12.29, Jan Beulich ha escrit:
On 19.05.15 at 12:20, t...@xen.org wrote:
At 12:19 +0100 on 18 May (1431951570), Jan Beulich wrote:
On 18.05.15 at 12:50, roger@citrix.com wrote:
El 18/05/15 a les 12.17, Tim Deegan ha escrit:
- have map_dirty_bitmap() DTRT, with something like access_ok() +
a linear-pagetable lookup to find the frame.
That was my first intention, but AFAICT we have no function in tree to
resolve a PV guest VA into a GFN/MFN. The closest thing I could find was
using guest_walk_tables + guest_walk_to_gfn in order to obtain the gfn.
Should I send a patch to introduce a pv_gva_to_gfn function based on that?
Isn't that what we have the linear page table and guest_map_l1e()
for?
Yes, or in this case guest_get_eff_l1e(). We'd want to make sure we
get_page() the underlying page as well to guard against it being freed
and reused while we have a mapping.
That won't check user/supervisor or write permissions in the upper
levels of the tree. OTOH, __copy_to_user() doesn't either, so maybe
we don't care.
Hmm, permissions are being checked by __copy_to_user() afaict
(due to us using the actual page tables), so that being bypassed
here would seem wrong then.
The only way I see to check for permissions of all levels is to use
guest_walk_tables instead of guest_get_eff_l1e, but that's going to make
this quite slow (as compared to the previous implementation).
After looking into this a little bit more, I'm afraid I don't see a
straight forward way to check for the permissions of all paging levels.
Here are the options I've found in order to deal with this:
- Use guest_get_eff_l1e and only check for the permissions of the L1
entry. Is it possible that the guest places an invalid entry in the
linear l1 table without Xen realizing?
- Add a new function hook somewhere (pv_domain maybe?) that can be
used to translate GVA to PFN for PV guests (mimicking what
paging_gva_to_gfn does). This would be implemented using
guest_walk_X_level, where X is the paging levels of the guest.
- Use some glue to be able to call guest_walk_{3/4}_level from
paging.c directly, and correctly choose which one to use based on
the guest bitness. IMHO this looks quite wacky, and I'm not even
sure if it's possible given the amount of preprocessor foo in
guest_pt.h.
I have the first option already implemented, but I would appreciate some
advice regarding the security implications of it.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 1/5] pci: add pci_iomap_wc() variants
On 20/05/15 02:45, Luis R. Rodriguez wrote: On Tue, May 19, 2015 at 4:29 PM, David Airlie airl...@redhat.com wrote: On Tue, May 19, 2015 at 4:02 PM, Bjorn Helgaas bhelg...@google.com wrote: [-cc Venkatesh (bouncing) On Tue, May 19, 2015 at 5:46 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas bhelg...@google.com wrote: Acked-by: Bjorn Helgaas bhelg...@google.com Thanks! Who's tree should this go through? I don't know. This is the only patch that went to linux-pci, so I haven't seen the rest. Oh I only rev'd a v5 for 1/5 as that's the only one that had feedback asking for changes. Patch v4 2/5 was for lib: devres: add pcim_iomap_wc() variants, you had questions about EXPORT_SYMBOL_GPL() and the fact that this is not yet used. I replied. This patch can then be ignored but again, I'd hate for folks to go in and try to add a non EXPORT_SYMBOL_GPL() symbol of this. Patches v4 3-5 remain intact, I had addressed it to you, but failed to Cc linux-pci, I'll go ahead and bounce those now. Just today Dave Arlie provided a Reviewed-by to some simple framebuffer device driver changes. I wonder if these changes should go through the framebuffer tree provided you already gave the Acked-by for the PCI parts, or if the PCI parts should go in first and only later (I guess we'd have to wait) then intake the driver changes that use the symbol. What we decide should likely also apply to the series that adds pci_ioremap_wc_bar() and makes use of it on drivers. Dave, Tomi, any preference? Maybe send Bjorn a pull request with a tree with the pci changes, and the fb changes reviewed-by me and acked by Tomi. Seems like it could be the simplest path forward. Works with me, Bjorn, are you OK with that? Dave, Tomi, I still need your Reviewed-by and Acked-by's Tomi on these two PCI series. Please let me know if I should resend those first, but I think I had Cc'd you folks already on them. For the fb parts: Acked-by: Tomi Valkeinen tomi.valkei...@ti.com I don't have anything in my fbdev-next branch touching the fbdev drivers changed in this series, so merging via some other tree might go fine without conflicts. Tomi signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V3 3/6] libxl: add pvusb API
On Wed, 2015-05-20 at 10:04 +0100, Wei Liu wrote:
On Mon, May 18, 2015 at 09:20:43PM -0600, Chun Yan Liu wrote:
[...]
+for (;;) {
+rc = libxl__xs_transaction_start(gc, t);
+if (rc) goto out;
+
+rc = libxl__device_exists(gc, t, device);
+if (rc 0) goto out;
+if (rc == 1) {
+/* already exists in xenstore */
+LOG(ERROR, device already exists in xenstore);
+rc = ERROR_DEVICE_EXISTS;
+goto out;
+}
+
+rc = libxl__set_domain_configuration(gc, domid, d_config);
+if (rc) goto out;
+
+libxl__device_generic_add(gc, t, device,
+ libxl__xs_kvs_of_flexarray(gc, back,
+
back-count),
+ libxl__xs_kvs_of_flexarray(gc,
front,
+
front-count),
+ NULL);
+libxl__usbport_add_xenstore(gc, t, domid, usbctrl);
+rc = libxl__xs_transaction_commit(gc, t);
+if (!rc) break;
+if (rc 0) goto out;
+}
+
You don't have aodev so you cannot check update_json. Maybe you need
aodev?
That field update_json is set to true when doing hotplug. It's set to
false during domain creation.
The same comment applies to other add functions as well.
Thanks, I'm updating that. But maybe like pci_add and pci_remove functions,
will add a 'starting' flag to indicate hotplug or creation.
Looking at DEFINE_DEVICE_ADD and DEFINE_DEVICE_REMOVE, usbctrl_add
and usb_add can use DEFINE_DEVICE_ADD; but usbctrl_remove and usb_remove
cannot use DEFINE_DEVICE_REMOVE directly, need some extra handling. So,
finally turned to not use these macros but refer to pci functions.
TBH I prefer to have only one way to deal with devices. I personally
prefer the async style that every other devices use. Maybe that's just
because I mostly worked with those.
I don't know the full history of libxl_pci.c so I will wait for Ian and
Ian's comments on which way to go.
libxl_pci.c should not be used as an example of the right way to do
things (to say the least).
I think one merit of determining whether to use sync or async is that
whether the operation is long running (slow). Long running one should be
asyn. I guess usb passthrough is not slow so we are probably fine in
this regard.
Device add/remove is expected to be async at least at the public API
level , all the others appear to be and it seems logical to me that they
would be.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 56456: regressions - FAIL
On 20.05.15 at 10:58, roger@citrix.com wrote:
After looking into this a little bit more, I'm afraid I don't see a
straight forward way to check for the permissions of all paging levels.
Here are the options I've found in order to deal with this:
- Use guest_get_eff_l1e and only check for the permissions of the L1
entry. Is it possible that the guest places an invalid entry in the
linear l1 table without Xen realizing?
No - all page table changes are being validated by Xen.
- Add a new function hook somewhere (pv_domain maybe?) that can be
used to translate GVA to PFN for PV guests (mimicking what
paging_gva_to_gfn does). This would be implemented using
guest_walk_X_level, where X is the paging levels of the guest.
- Use some glue to be able to call guest_walk_{3/4}_level from
paging.c directly, and correctly choose which one to use based on
the guest bitness. IMHO this looks quite wacky, and I'm not even
sure if it's possible given the amount of preprocessor foo in
guest_pt.h.
I have the first option already implemented, but I would appreciate some
advice regarding the security implications of it.
I think with all of the options here being unsatisfactory we should
reconsider your original option of restoring previous behavior
(without any mapping) for the PV case. Tim?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] x86: switch default mapping attributes to non-executable
On 19.05.15 at 20:53, andrew.coop...@citrix.com wrote:
On 18/05/15 13:47, Jan Beulich wrote:
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -895,6 +895,33 @@ void __init subarch_init_memory(void)
share_xen_page_with_privileged_guests(page, XENSHARE_readonly);
}
}
+
+/* Mark low 16Mb of direct map NX if hardware supports it. */
+if ( !cpu_has_nx )
+return;
+
+v = DIRECTMAP_VIRT_START + (1UL 20);
What about 0-1MB ?
I'd like to avoid fiddling with that range, as the trampoline living there
will want to continue to be RWX anyway.
+l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(v)])[l3_table_offset(v)];
+ASSERT(l3e_get_flags(l3e) _PAGE_PRESENT);
+do {
+l2e = l3e_to_l2e(l3e)[l2_table_offset(v)];
+ASSERT(l2e_get_flags(l2e) _PAGE_PRESENT);
+if ( l2e_get_flags(l2e) _PAGE_PSE )
+{
+l2e_add_flags(l2e, _PAGE_NX_BIT);
+l3e_to_l2e(l3e)[l2_table_offset(v)] = l2e;
+v += 1 L2_PAGETABLE_SHIFT;
+}
+else
+{
+l1_pgentry_t l1e = l2e_to_l1e(l2e)[l1_table_offset(v)];
+
+ASSERT(l1e_get_flags(l1e) _PAGE_PRESENT);
+l1e_add_flags(l1e, _PAGE_NX_BIT);
+l2e_to_l1e(l2e)[l1_table_offset(v)] = l1e;
+v += 1 L1_PAGETABLE_SHIFT;
+}
+} while ( v DIRECTMAP_VIRT_START + (16UL 20) );
How about just setting l3e.nx and leaving all lower tables alone?
Apart from the trampoline aspect (see above) I don't think it's a
good idea to restrict permissions in non-leaf entries - that just
calls for more intrusive patches if later an individual page needs
them lifted.
--- a/xen/include/asm-x86/x86_64/page.h
+++ b/xen/include/asm-x86/x86_64/page.h
@@ -147,9 +147,20 @@ typedef l4_pgentry_t root_pgentry_t;
*/
#define _PAGE_GUEST_KERNEL (1U12)
-#define PAGE_HYPERVISOR (__PAGE_HYPERVISOR | _PAGE_GLOBAL)
+#define PAGE_HYPERVISOR_RO (__PAGE_HYPERVISOR_RO | _PAGE_GLOBAL)
+#define PAGE_HYPERVISOR_RW (__PAGE_HYPERVISOR_RW | _PAGE_GLOBAL)
#define PAGE_HYPERVISOR_RX (__PAGE_HYPERVISOR_RX | _PAGE_GLOBAL)
-#define PAGE_HYPERVISOR_NOCACHE (__PAGE_HYPERVISOR_NOCACHE | _PAGE_GLOBAL)
+#define PAGE_HYPERVISOR_RWX (__PAGE_HYPERVISOR | _PAGE_GLOBAL)
+
+#ifdef __ASSEMBLY__
+/* Dependency on NX being available can't be expressed. */
+# define PAGE_HYPERVISOR PAGE_HYPERVISOR_RWX
+# define PAGE_HYPERVISOR_NOCACHE (__PAGE_HYPERVISOR_NOCACHE | _PAGE_GLOBAL)
+#else
+# define PAGE_HYPERVISOR PAGE_HYPERVISOR_RW
+# define PAGE_HYPERVISOR_NOCACHE (__PAGE_HYPERVISOR_NOCACHE | \
+ _PAGE_GLOBAL | _PAGE_NX)
+#endif
This patch is clearly an improvement, so my comments can possibly be
deferred to subsequent patches.
After boot, I can't think of a legitimate reason for Xen to have a RWX
mapping. As such, leaving __PAGE_HYPERVISOR around constitutes a risk
that RWX mappings will be used. It would be nice if we could remove all
constants (which aren't BOOT_*) which could lead to accidental use of
RWX mappings on NX-enabled hardware.
But you realize that __PAGE_HYPERVISOR is particularly used for
intermediate page table entry permissions?
I think we also want a warning on boot if we find NX unavailable. The
only 64bit capable CPUs which do not support NX are now 11 years old,
and I don't expect many of those to be running Xen these days. However,
given that disable NX is a common BIOS option for compatibility
reasons, we should press people to alter their settings if possible.
Sure, easily done.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 21/23] net/xen-netback: Make it running on 64KB page granularity
On Tue, May 19, 2015 at 11:56:39PM +0100, Julien Grall wrote:
diff --git a/drivers/net/xen-netback/common.h
b/drivers/net/xen-netback/common.h
index 0eda6e9..c2a5402 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -204,7 +204,7 @@ struct xenvif_queue { /* Per-queue data for xenvif */
/* Maximum number of Rx slots a to-guest packet may use, including the
* slot needed for GSO meta-data.
*/
-#define XEN_NETBK_RX_SLOTS_MAX (MAX_SKB_FRAGS + 1)
+#define XEN_NETBK_RX_SLOTS_MAX ((MAX_SKB_FRAGS + 1) * XEN_PFN_PER_PAGE)
enum state_bit_shift {
/* This bit marks that the vif is connected */
The function xenvif_wait_for_rx_work never returns. I guess it's because
there
is not enough slot available.
For 64KB page granularity we ask for 16 times more slots than 4KB page
granularity. Although, it's very unlikely that all the slot will be used.
FWIW I pointed out the same problem on blkfront.
This is not going to work. The ring in netfront / netback has only 256
slots. Now you ask for netback to reserve more than 256 slots -- (17 +
1) * (64 / 4) = 288, which can never be fulfilled. See the call to
xenvif_rx_ring_slots_available.
I think XEN_NETBK_RX_SLOTS_MAX derived from the fact the each packet to
the guest cannot be larger than 64K. So you might be able to
#define XEN_NETBK_RX_SLOTS_MAX ((65536 / XEN_PAGE_SIZE) + 1)
I didn't know that packet cannot be larger than 64KB. That's simply a lot
the problem.
I think about this more, you will need one more slot for GSO
information, so make it ((65536 / XEN_PAGE_SIZE) + 1 + 1).
Blk driver may have a different story. But the default ring size (1
page) yields even less slots than net (given that sizeof(union(req/rsp))
is larger IIRC).
I will see with Roger for Blkback.
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [V5] x86/cpuidle: get accurate C0 value with xenpm tool
On Wed, 2015-05-20 at 02:42 +, Han, Huaitong wrote:
On Tue, 2015-05-19 at 10:01 +0100, Jan Beulich wrote:
On 14.05.15 at 07:23, huaitong@intel.com wrote:
@@ -1172,7 +1196,10 @@ int pmstat_get_cx_stat(uint32_t cpuid, struct
pm_cx_stat *stat)
{
struct acpi_processor_power *power = processor_powers[cpuid];
uint64_t idle_usage = 0, idle_res = 0;
-uint64_t usage[ACPI_PROCESSOR_MAX_POWER],
res[ACPI_PROCESSOR_MAX_POWER];
+uint64_t last_state_update_tick, current_stime, current_tick;
+uint64_t usage[ACPI_PROCESSOR_MAX_POWER] = { 0 };
+uint64_t res_ticks[ACPI_PROCESSOR_MAX_POWER] = { 0 };
+uint64_t res[ACPI_PROCESSOR_MAX_POWER] = { 0 };
Not yet another array on the stack please - I can't see why you
can't get away with just res[].
res_ticks just is a temp array. I can use a temp variable for
ticks_to_ns transform, like tmp=res[i];res[i]=ticks_to_ns(tmp);, and
the array named res[] is better in terms of origin source code.
use res[i]=ticks_to_ns((uint64_t)res[i]) without tmp varialbe.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC][PATCH 01/13] tools: introduce some new parameters to set rdm policy
On Wed, May 20, 2015 at 01:27:56PM +0800, Chen, Tiejun wrote:
[...]
We have this definition,
+libxl_rdm_reserve_type = Enumeration(rdm_reserve_type, [
+(0, none),
+(1, host),
+])
If we set 'type=none', this means we would do nothing actually since we
don't expose any rdms to guest. This behavior will ensue we go back the
existing scenario without our patch.
But this only works with global configuration and individual
configuration in PCI spec trumps this, right?
You're right.
Think about how an old configuration migrated to newer version of Xen
should work. For example, I don't have rdm= but have pci=['']. Do we
need to make sure this still work? I guess the answer is if it already
Definitely.
works before RDM it should continue to work as there is really no
conflict before. In this case whether we enable RDM or not doesn't make
a difference to a guest that's already working before. Am I right?
You haven't answered this question... I'm trying to determine what
should be a sensible default value.
If the answer to that question is yes, then we should enable RDM by
default, because it does no harm to guests that are already working and
fix problem for the guests that are not working; if the answer is no
or not sure, we should use none. Don't worry, we can change the
default value later if necessary.
Using none as default leaves us on the safe side but it would make it
less nicer to use Xen. But well, safety comes first.
Wei.
I think we can set the default 'type' to NONE,
libxl__rdm_setdefault()
{
b_info-rdm.type = LIBXL_RDM_RESERVE_TYPE_NONE;
and then,
libxl__domain_device_construct_rdm()
{
...
/* Might not expose rdm. */
if (type == LIBXL_RDM_RESERVE_TYPE_NONE)
return 0;
This means we don't expose any rdm so we would never concern any policy
anymore.
Thanks
Tiejun
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] RFC: Proposal to improve error reporting in libxl
Hi, Several of us at Citrix are currently working on rewriting xenopsd - the component of the Xapi toolstack which handles domain creation, destruction, device attachment and so on - to use libxl instead of libxc. One of the problems we have run into is that error reporting in libxl is not detailed and expressive enough to let us take corrective action or present meaningful high level error messages to users. In particular: 1 Many API calls return error codes, but these codes don't tell us very much about what went wrong. In most cases the error code is ERROR_FAIL, ERROR_INVAL or ERROR_NOMEM. The code may also have been returned by a utility function and passed back unaltered by the API call. Examples: libxl_domain_resume, libxl_domain_remus_start (mostly ERROR_FAIL). libxl_domain_rename uses ERROR_NOMEM, ERROR_INVAL and ERROR_FAIL. 2 A few API calls return pointers. In some cases a null pointer indicates that an error occured, but in others null could possibly be a normal return value. If null does indicate an error, it still does not give us any information about what happened. Examples: libxl_list_domain, libxl_list_cpupool, libxl_list_vm 3 A few API calls have no return value but may still log errors. Examples: libxl_disable_domain_death, 4 Most API calls log detailed error messages through XTL, but there does not seem to be a way for the caller to make use of them. Some error messages may also have been logged by utility functions, not by the API call itself. We would like to make libxl's error reporting more regular and informative for callers.We think we need to: * Make a list of the error conditions which can be encountered by all the current API calls and define a set of error codes to cover them. Some codes will be generally applicable, but give more information than a bare 'fail'; others may be specific to a particular API call. We may keep the existing FAIL, INVAL and NOMEM codes for times when they are appropriate. The error messages logged by each API call are a good starting point for this list. I have included a partial list below. * Change the API calls in point 1 above to use the new, more detailed error codes. These changes will break client code which checks for particular error codes, rather than just checking whether the return code is non-zero. * For the API calls in points 2 and 3 which can encounter errors which callers might care about, change their interfaces to return error codes. For functions which previously returned pointers, add pointer-to-pointer parameters. * For error codes returned by utility functions, described in point 4, decide whether the code can be reported directly or an API-level error should be reported instead. These changes will certainly require a new version of the libxl API. We have considered other options which would be less likely to break existing code - in particular the option of keeping the existing return codes but adding an errno-like field which could contain a more specific error number. This approach would not break existing client code and would allow API calls which return void or pointers to report errors. However there is no obvious place to put the errno field - the ctx struct is not suitable because it might be used by several callers simultaneously.The API-breaking change outlined above seems to be the cleanest option, although it requires work on both libxl and its clients. All comments on this proposal are very welcome. Examples of API calls which would not fit well into the new design would be particularly useful. We are also keen to hear whether or not these changes would be useful for libvirt and other toolstacks using libxl, and whether those toolstacks have encountered any other error reporting problems which we have missed. Thanks, Euan Notes on some API functions defined in libxl.c. 'ERROR_FOO, string' means that when ERROR_FOO is returned, string is also logged. In most non-trivial functions, error reporting is handled as follows: * store the error code in 'rc' or a similar local variable * log the error string * goto the 'out' or 'out_err' label at the end of the function libxl_ctx_alloc: success: 0 failure: ERROR_VERSION ERROR_FAIL, Failed to initialize mutex ERROR_FAIL, cannot open libxc handle ERROR_FAIL, cannot connect to xenstore ERROR_FAIL, cannot open libxc evtchn handle (from libxl__ctx_evtchn_init) libxl_ctx_free: success: 0 no errors libxl_string_list_dispose: no return value no interesting failure modes apart from segfault libxl_string_list_copy: libxl_key_value_list_copy no return value if calloc fails, logs libxl: FATAL ERROR: memory allocation failure and exits if strdup fails, logs libxl: FATAL ERROR: memory allocation failure and exits
Re: [Xen-devel] [PATCH v7 01/14] x86: add socket_to_cpumask
On 20.05.15 at 05:13, chao.p.p...@linux.intel.com wrote: I do have a problem when coming up with the final codes, there are two possible ways: 1) Make both num_processors and disabled_cpus public so that they can be used when calculating nr_sockets. 2) Add another public function set_nr_sockets in mpparse.c (just like set_nr_cpu_ids does). Which do you prefer? The latter. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 03/14] x86: detect and initialize Intel CAT feature
On 20.05.15 at 05:21, chao.p.p...@linux.intel.com wrote: On Tue, May 19, 2015 at 11:22:54AM +0100, Jan Beulich wrote: On 19.05.15 at 11:33, chao.p.p...@linux.intel.com wrote: On Tue, May 19, 2015 at 09:42:07AM +0100, Jan Beulich wrote: On 19.05.15 at 09:40, chao.p.p...@linux.intel.com wrote: On Mon, May 18, 2015 at 02:33:51PM +0100, Jan Beulich wrote: On 08.05.15 at 10:56, chao.p.p...@linux.intel.com wrote: +static unsigned long *__read_mostly cat_socket_init_bitmap; +static unsigned long *__read_mostly cat_socket_enable_bitmap; Didn't we agree to fold these two into one? Apart from that the _bitmap name tag doesn't seem very useful... Looks like this? static unsigned long *__read_mostly cat_socket_init, *__read_mostly cat_socket_enable; Yes, except that you will want to drop one (or make clear why you need both). As said in the previous version, cat_socket_enable is the actual CAT enabled status. And cat_socket_init is used for performance optimization purpose only. It indicate if the socket has been initialized, so that initialization happens only once for each socket, but not __cpus_in_socket__ times. There are three possibilities: 1) Not initialized; 2) Initialized, CAT disabled; 3) Initialized, CAT enabled; So it's not possible to use only one bit to represent three values. Why? The two bits get set together, and get cleared together. Even if they have formally different meaning, there is - afaict - no case where their values will differ (except for the brief period between setting one and then the other). Do you want to try the failure initialization(both because CAT is not even supported on the machine or fails to allocate cos_to_cbm) on and on? I don't see any harm - all you save is a cpuid_count() invocation. But again - only the allocation/freeing should be done in the alternative named notifications, not the actual data setup (as that iirc needs to run on the CPU). I know this is the general rules, but for this case, I don't think it's going to work to allocate memory in CPU_UP_PREPARE while do the initialization later(in CPU_STARTING). As said, the allocation has dependency on the result of the initialization. E.g. before info-cos_to_cbm = xzalloc_array(struct psr_cat_cbm, info-cos_max + 1UL); info-cos_max must have been known. Ah, yes. Otoh, considering that everywhere else we expect symmetry across CPUs, do you really think there are going to be systems with different CPUs having different cos_max values? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 03/14] x86: detect and initialize Intel CAT feature
On Wed, May 20, 2015 at 10:06:32AM +0100, Jan Beulich wrote: On 20.05.15 at 05:21, chao.p.p...@linux.intel.com wrote: On Tue, May 19, 2015 at 11:22:54AM +0100, Jan Beulich wrote: On 19.05.15 at 11:33, chao.p.p...@linux.intel.com wrote: On Tue, May 19, 2015 at 09:42:07AM +0100, Jan Beulich wrote: On 19.05.15 at 09:40, chao.p.p...@linux.intel.com wrote: On Mon, May 18, 2015 at 02:33:51PM +0100, Jan Beulich wrote: On 08.05.15 at 10:56, chao.p.p...@linux.intel.com wrote: +static unsigned long *__read_mostly cat_socket_init_bitmap; +static unsigned long *__read_mostly cat_socket_enable_bitmap; Didn't we agree to fold these two into one? Apart from that the _bitmap name tag doesn't seem very useful... Looks like this? static unsigned long *__read_mostly cat_socket_init, *__read_mostly cat_socket_enable; Yes, except that you will want to drop one (or make clear why you need both). As said in the previous version, cat_socket_enable is the actual CAT enabled status. And cat_socket_init is used for performance optimization purpose only. It indicate if the socket has been initialized, so that initialization happens only once for each socket, but not __cpus_in_socket__ times. There are three possibilities: 1) Not initialized; 2) Initialized, CAT disabled; 3) Initialized, CAT enabled; So it's not possible to use only one bit to represent three values. Why? The two bits get set together, and get cleared together. Even if they have formally different meaning, there is - afaict - no case where their values will differ (except for the brief period between setting one and then the other). Do you want to try the failure initialization(both because CAT is not even supported on the machine or fails to allocate cos_to_cbm) on and on? I don't see any harm - all you save is a cpuid_count() invocation. Then I will remove cat_socket_init. But again - only the allocation/freeing should be done in the alternative named notifications, not the actual data setup (as that iirc needs to run on the CPU). I know this is the general rules, but for this case, I don't think it's going to work to allocate memory in CPU_UP_PREPARE while do the initialization later(in CPU_STARTING). As said, the allocation has dependency on the result of the initialization. E.g. before info-cos_to_cbm = xzalloc_array(struct psr_cat_cbm, info-cos_max + 1UL); info-cos_max must have been known. Ah, yes. Otoh, considering that everywhere else we expect symmetry across CPUs, do you really think there are going to be systems with different CPUs having different cos_max values? I agree, such systems should be rare, or even doesn't exist in the real world. But as we are trying to support it, then I have to make it working. Chao ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V3 3/6] libxl: add pvusb API
On 5/20/2015 at 05:04 PM, in message
20150520090407.gw26...@zion.uk.xensource.com, Wei Liu wei.l...@citrix.com
wrote:
On Mon, May 18, 2015 at 09:20:43PM -0600, Chun Yan Liu wrote:
[...]
+for (;;) {
+rc = libxl__xs_transaction_start(gc, t);
+if (rc) goto out;
+
+rc = libxl__device_exists(gc, t, device);
+if (rc 0) goto out;
+if (rc == 1) {
+/* already exists in xenstore */
+LOG(ERROR, device already exists in xenstore);
+rc = ERROR_DEVICE_EXISTS;
+goto out;
+}
+
+rc = libxl__set_domain_configuration(gc, domid, d_config);
+if (rc) goto out;
+
+libxl__device_generic_add(gc, t, device,
+ libxl__xs_kvs_of_flexarray(gc, back,
+
back-count),
+ libxl__xs_kvs_of_flexarray(gc,
front,
+
front-count),
+ NULL);
+libxl__usbport_add_xenstore(gc, t, domid, usbctrl);
+rc = libxl__xs_transaction_commit(gc, t);
+if (!rc) break;
+if (rc 0) goto out;
+}
+
You don't have aodev so you cannot check update_json. Maybe you need
aodev?
That field update_json is set to true when doing hotplug. It's set to
false during domain creation.
The same comment applies to other add functions as well.
Thanks, I'm updating that. But maybe like pci_add and pci_remove functions,
will add a 'starting' flag to indicate hotplug or creation.
Looking at DEFINE_DEVICE_ADD and DEFINE_DEVICE_REMOVE, usbctrl_add
and usb_add can use DEFINE_DEVICE_ADD; but usbctrl_remove and usb_remove
cannot use DEFINE_DEVICE_REMOVE directly, need some extra handling. So,
finally turned to not use these macros but refer to pci functions.
TBH I prefer to have only one way to deal with devices. I personally
prefer the async style that every other devices use. Maybe that's just
because I mostly worked with those.
I don't know the full history of libxl_pci.c so I will wait for Ian and
Ian's comments on which way to go.
I think one merit of determining whether to use sync or async is that
whether the operation is long running (slow). Long running one should be
asyn. I guess usb passthrough is not slow so we are probably fine in
this regard.
BTW if you find the macros can't meet your need you can either extend
them or not use them.
Got you and Ian. I'll update codes then.
Chunyan
+out:
+if (lock) libxl__unlock_domain_userdata(lock);
+libxl_device_usbctrl_dispose(usbctrl_saved);
+libxl_domain_config_dispose(d_config);
+return rc;
+}
+
+int libxl__device_usbctrl_add(libxl__gc *gc, uint32_t domid,
+ libxl_device_usbctrl *usbctrl)
+{
+int rc = 0;
+
+rc = libxl__device_usbctrl_setdefault(gc, domid, usbctrl);
+if (rc 0) goto out;
+
+if (usbctrl-devid == -1) {
+usbctrl-devid = libxl__device_nextid(gc, domid, vusb);
+if (usbctrl-devid 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+}
+
+if (libxl__usbctrl_add_xenstore(gc, domid, usbctrl) 0){
+rc = ERROR_FAIL;
+goto out;
+}
+
+out:
+return rc;
+}
+
+int libxl_device_usbctrl_add(libxl_ctx *ctx, uint32_t domid,
+ libxl_device_usbctrl *usbctrl,
+ const libxl_asyncop_how *ao_how)
+{
+AO_CREATE(ctx, domid, ao_how);
+int rc;
+
+rc = libxl__device_usbctrl_add(gc, domid, usbctrl);
Hmm... Your remove function is async while this one is sync, why?
Hmm, maybe not proper here, just referred to pci_add implementation.
Current calling places only use sync mode.
Yeah, I only ask for consistency.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [V5] x86/cpuidle: get accurate C0 value with xenpm tool
On 20.05.15 at 10:36, huaitong@intel.com wrote:
On Wed, 2015-05-20 at 02:42 +, Han, Huaitong wrote:
On Tue, 2015-05-19 at 10:01 +0100, Jan Beulich wrote:
On 14.05.15 at 07:23, huaitong@intel.com wrote:
@@ -1172,7 +1196,10 @@ int pmstat_get_cx_stat(uint32_t cpuid, struct
pm_cx_stat *stat)
{
struct acpi_processor_power *power = processor_powers[cpuid];
uint64_t idle_usage = 0, idle_res = 0;
-uint64_t usage[ACPI_PROCESSOR_MAX_POWER],
res[ACPI_PROCESSOR_MAX_POWER];
+uint64_t last_state_update_tick, current_stime, current_tick;
+uint64_t usage[ACPI_PROCESSOR_MAX_POWER] = { 0 };
+uint64_t res_ticks[ACPI_PROCESSOR_MAX_POWER] = { 0 };
+uint64_t res[ACPI_PROCESSOR_MAX_POWER] = { 0 };
Not yet another array on the stack please - I can't see why you
can't get away with just res[].
res_ticks just is a temp array. I can use a temp variable for
ticks_to_ns transform, like tmp=res[i];res[i]=ticks_to_ns(tmp);, and
the array named res[] is better in terms of origin source code.
use res[i]=ticks_to_ns((uint64_t)res[i]) without tmp varialbe.
Exactly.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v10 02/10] xen: Add support for VMware cpuid leaves
Hi,
On 19/05/2015 21:02, Andrew Cooper wrote:
diff --git a/xen/include/public/arch-x86/xen.h
b/xen/include/public/arch-x86/xen.h
index cea3fe7..5a5bad6 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -263,7 +263,7 @@ struct arch_shared_info {
typedef struct arch_shared_info arch_shared_info_t;
struct xen_arch_domainconfig {
-char dummy;
+uint64_t vmware_hwver;
Julien: (as the author of the introducing patch) Given that this
structure is used as part of a domain_create hypercall only, I think a
comment is warrented stating that its API/ABI is covered by the
DOMCTL_INTERFACE_VERSION.
It's part of DOMCTL_INTERFACE_VERSION. Feel free to send a patch to add
a comment.
Strictly speaking, this is currently part of the public ABI which must
always maintain backwards compatibility.
I don't think it's necessary to maintain backwards compatibility. This
has been added during this is release cycle.
Don: Feel free to retain my Reviewed-by, subject to the adjustments listed.
It's rather strange to have a separate patch for adding vmware_hwver
version in the tools. You are relying on the fact that the toolstack
memset zero xen_arch_domainconfig to zero which is hidden in the maze of
the code (the memset is done on an upper container).
It would be worth to add an explicit vmware_hwver = 0 in the
libxl__arch_domain_prepare_config.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC][PATCH 01/13] tools: introduce some new parameters to set rdm policy
On 2015/5/20 16:36, Wei Liu wrote:
On Wed, May 20, 2015 at 01:27:56PM +0800, Chen, Tiejun wrote:
[...]
We have this definition,
+libxl_rdm_reserve_type = Enumeration(rdm_reserve_type, [
+(0, none),
+(1, host),
+])
If we set 'type=none', this means we would do nothing actually since we
don't expose any rdms to guest. This behavior will ensue we go back the
existing scenario without our patch.
But this only works with global configuration and individual
configuration in PCI spec trumps this, right?
You're right.
Think about how an old configuration migrated to newer version of Xen
should work. For example, I don't have rdm= but have pci=['']. Do we
need to make sure this still work? I guess the answer is if it already
Definitely.
works before RDM it should continue to work as there is really no
conflict before. In this case whether we enable RDM or not doesn't make
a difference to a guest that's already working before. Am I right?
You haven't answered this question... I'm trying to determine what
should be a sensible default value.
I think I should say 'no' here. RDM (RMRR) already exists and its also
being enabled before I'm trying to introduce this series of patch. But
we have some legacy or potential problems to really work well with RMRR.
If the answer to that question is yes, then we should enable RDM by
default, because it does no harm to guests that are already working and
fix problem for the guests that are not working; if the answer is no
or not sure, we should use none. Don't worry, we can change the
default value later if necessary.
So we're going to the latter :)
Using none as default leaves us on the safe side but it would make it
less nicer to use Xen. But well, safety comes first.
Actually RMRR doesn't matter in most cases unless you're trying to do
pass through with a device which owns RMRR and also really use RMRR
indeed. So from my point of view, I agree NONE should be default since
we really should make sure we have a way to approach our original
behavior in accordance with your concern.
Thanks
Tiejun
Wei.
I think we can set the default 'type' to NONE,
libxl__rdm_setdefault()
{
b_info-rdm.type = LIBXL_RDM_RESERVE_TYPE_NONE;
and then,
libxl__domain_device_construct_rdm()
{
...
/* Might not expose rdm. */
if (type == LIBXL_RDM_RESERVE_TYPE_NONE)
return 0;
This means we don't expose any rdm so we would never concern any policy
anymore.
Thanks
Tiejun
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/4] x86emul: move stubs off the stack
On 19.05.15 at 19:33, andrew.coop...@citrix.com wrote:
On 18/05/15 13:46, Jan Beulich wrote:
@@ -17,8 +18,22 @@
/* Avoid namespace pollution. */
#undef cmpxchg
#undef cpuid
+#undef wbinvd
#define cpu_has_amd_erratum(nr) \
cpu_has_amd_erratum(current_cpu_data, AMD_ERRATUM_##nr)
+#define get_stub(stb) ({ \
+(stb).addr = this_cpu(stubs.addr) + STUB_BUF_SIZE / 2; \
+((stb).ptr = map_domain_page(this_cpu(stubs.mfn))) + \
+((stb).addr (PAGE_SIZE - 1));\
+})
+#define put_stub(stb) ({ \
+if ( (stb).ptr ) \
+{ \
+unmap_domain_page((stb).ptr); \
+(stb).ptr = NULL; \
+} \
+})
+
These don't need to be macros, and I suspect a compiler would choose to
out-of-line get_stub() if it could.
But afaict there's also nothing wrong with them being macros.
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -429,6 +429,18 @@ struct x86_emulate_ctxt
} retire;
};
+struct x86_emulate_stub {
+union {
+void (*func)(void);
+uintptr_t addr;
+};
+#ifdef __XEN__
+void *ptr;
+#else
+uint8_t buf[32];
16 is surely enough? The emulator will #GP if it attempts to fetch more
than 15 bytes, and only a 'ret' is needed after that.
Maybe, right now. I wanted to leave room for there perhaps being
a case where two instructions could be generated. But of course we
can grow the buffer later. I'll use MAX_INST_LEN + 1 for now.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] ARM-Xen customization of stage two translation.
Dear all, I am using hardware assisted XEN on ARM cortex A-15, could you please hint me on the below: I want the stage two translation from IPA to PA through the stage two translation to exclude a particular small contiguous region (some physical frames) of the physical memory ? is this achievable? could you please hint me on how can I accomplish? Please share your experience experts. Thank you so much. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 5/6] flask/policy: Add SECINITSID_DOMU as default domU SSID
On Tue, 2015-05-19 at 13:02 -0400, Daniel De Graaf wrote: On 05/19/2015 09:44 AM, Ian Campbell wrote: From: Daniel De Graaf dgde...@tycho.nsa.gov Acked-by: Ian Campbell ian.campb...@citrix.com --- Daniel -- this is from your example patch in 2b0e.8050...@tycho.nsa.gov and so needs your S-o-b, please. Signed-off-by: Daniel De Graaf dgde...@tycho.nsa.gov Thanks. I think patches #2, #3 and #4 need your Ack too and I think it would be useful if you could take a look at #6 (in the forthcoming v3 series) too if you have time. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC][PATCH 01/13] tools: introduce some new parameters to set rdm policy
On Wed, May 20, 2015 at 04:51:44PM +0800, Chen, Tiejun wrote: On 2015/5/20 16:36, Wei Liu wrote: On Wed, May 20, 2015 at 01:27:56PM +0800, Chen, Tiejun wrote: [...] We have this definition, +libxl_rdm_reserve_type = Enumeration(rdm_reserve_type, [ +(0, none), +(1, host), +]) If we set 'type=none', this means we would do nothing actually since we don't expose any rdms to guest. This behavior will ensue we go back the existing scenario without our patch. But this only works with global configuration and individual configuration in PCI spec trumps this, right? You're right. Think about how an old configuration migrated to newer version of Xen should work. For example, I don't have rdm= but have pci=['']. Do we need to make sure this still work? I guess the answer is if it already Definitely. works before RDM it should continue to work as there is really no conflict before. In this case whether we enable RDM or not doesn't make a difference to a guest that's already working before. Am I right? You haven't answered this question... I'm trying to determine what should be a sensible default value. I think I should say 'no' here. RDM (RMRR) already exists and its also being enabled before I'm trying to introduce this series of patch. But we have some legacy or potential problems to really work well with RMRR. If the answer to that question is yes, then we should enable RDM by default, because it does no harm to guests that are already working and fix problem for the guests that are not working; if the answer is no or not sure, we should use none. Don't worry, we can change the default value later if necessary. So we're going to the latter :) Using none as default leaves us on the safe side but it would make it less nicer to use Xen. But well, safety comes first. Actually RMRR doesn't matter in most cases unless you're trying to do pass through with a device which owns RMRR and also really use RMRR indeed. So from my point of view, I agree NONE should be default since we really should make sure we have a way to approach our original behavior in accordance with your concern. Makes sense. Thanks for your reply. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/pci: correct comment of pci_device_detect()
On 20.05.15 at 08:53, tiejun.c...@intel.com wrote: --- a/xen/drivers/passthrough/pci.c +++ b/xen/drivers/passthrough/pci.c @@ -905,7 +905,7 @@ out: } /* - * detect pci device, return 0 if it exists, or return 0 + * detect pci device, return 1 if it exists, or return 0 */ int __init pci_device_detect(u16 seg, u8 bus, u8 dev, u8 func) The comment is pretty pointless, and could go away altogether if the function's return type was switched to bool_t. Care to do such an alternative patch (including replacing some of the callers using == 0 on the result to use ! instead)? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/2] xen/block: add multi-page ring support
El 15/05/15 a les 14.06, Bob Liu ha escrit:
On 05/15/2015 07:13 PM, Roger Pau Monné wrote:
El 12/05/15 a les 13.01, Bob Liu ha escrit:
Extend xen/block to support multi-page ring, so that more requests can be
issued
by using more than one pages as the request ring between blkfront and
backend.
As a result, the performance can get improved significantly.
^ s/can get improved/improves/
We got some impressive improvements on our highend iscsi storage cluster
backend.
If using 64 pages as the ring, the IOPS increased about 15 times for the
throughput testing and above doubled for the latency testing.
The reason was the limit on outstanding requests is 32 if use only one-page
ring, but in our case the iscsi lun was spread across about 100 physical
drives,
32 was really not enough to keep them busy.
Changes in v2:
- Rebased to 4.0-rc6
- Added description on how this protocol works into io/blkif.h
I don't see any changes to io/blkif.h in this patch, is something missing?
Sorry, I should mention in v3 that these changed were removed because I
followed the protocol
already defined in XEN git tree: xen/include/public/io/blkif.h
So since you were reusing the old protocol specification there was no
need to add anything to blkif.h?
AFAICT from the conversation in the other thread (the one about updating
blkif.h in Xen tree) if you want to reuse an existing protocol you need
to make sure it's compatible with the previous implementation.
Also you use XENBUS_MAX_RING_PAGES which AFAICT it's not defined anywhere.
It was defined in include/xen/xenbus.h.
Changes in v3:
- Follow the protocol defined in io/blkif.h on XEN tree
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/block/xen-blkback/blkback.c | 14 -
drivers/block/xen-blkback/common.h | 4 +-
drivers/block/xen-blkback/xenbus.c | 83 ++---
drivers/block/xen-blkfront.c| 102
+++-
4 files changed, 156 insertions(+), 47 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
b/drivers/block/xen-blkback/blkback.c
index 713fc9f..f191083 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -84,6 +84,12 @@ MODULE_PARM_DESC(max_persistent_grants,
Maximum number of grants to map persistently);
/*
+ * Maximum number of pages to be used as the ring between front and backend
+ */
+unsigned int xen_blkif_max_ring_pages = XENBUS_MAX_RING_PAGES;
+module_param_named(max_ring_pages, xen_blkif_max_ring_pages, int, S_IRUGO);
+MODULE_PARM_DESC(max_ring_pages, Maximum amount of pages to be used as
the ring);
+/*
* The LRU mechanism to clean the lists of persistent grants needs to
* be executed periodically. The time interval between consecutive
executions
* of the purge mechanism is set in ms.
@@ -630,7 +636,7 @@ purge_gnt_list:
}
/* Shrink if we have more than xen_blkif_max_buffer_pages */
- shrink_free_pagepool(blkif, xen_blkif_max_buffer_pages);
+ shrink_free_pagepool(blkif, xen_blkif_max_buffer_pages *
blkif-nr_ring_pages);
You are greatly increasing the buffer of free (ballooned) pages.
Possibly making it 32 times bigger than it used to be, is this really
needed?
Hmm.. it's a bit aggressive.
How about (xen_blkif_max_buffer_pages * blkif-nr_ring_pages) / 2?
IMHO I'm not sure about the best solution here.
xen_blkif_max_buffer_pages is set by the user and should represent the
buffer pages used by blkback. Modifying it this way means that we are
effectively lifting the limit without the user consent, which looks wrong.
I think we should change the meaning, so that it's better suited for
your proposes.
if (log_stats time_after(jiffies, blkif-st_print))
print_stats(blkif);
@@ -1435,6 +1441,12 @@ static int __init xen_blkif_init(void)
{
int rc = 0;
+ if (xen_blkif_max_ring_pages XENBUS_MAX_RING_PAGES) {
+ pr_info(Invalid max_ring_pages (%d), will use default max:
%d.\n,
+ xen_blkif_max_ring_pages, XENBUS_MAX_RING_PAGES);
+ xen_blkif_max_ring_pages = XENBUS_MAX_RING_PAGES;
+ }
+
if (!xen_domain())
return -ENODEV;
diff --git a/drivers/block/xen-blkback/common.h
b/drivers/block/xen-blkback/common.h
index f620b5d..84a964c 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -44,6 +44,7 @@
#include xen/interface/io/blkif.h
#include xen/interface/io/protocols.h
+extern unsigned int xen_blkif_max_ring_pages;
/*
* This is the maximum number of segments that would be allowed in indirect
* requests. This value will also be passed to the frontend.
@@ -248,7 +249,7 @@ struct backend_info;
#define PERSISTENT_GNT_WAS_ACTIVE 1
/* Number of requests that we can fit in a ring */
[Xen-devel] [Patch v2 08/14] genirq: Introduce helper function irq_data_get_affinity_mask()
Introduce helper function irq_data_get_affinity_mask() and
irq_get_affinity_mask() to hide implementation details,
so we could move field 'affinity' from struct irq_data into
struct irq_common_data later.
Signed-off-by: Jiang Liu jiang@linux.intel.com
---
arch/alpha/kernel/irq.c |2 +-
arch/arm/kernel/irq.c |4 ++--
arch/arm64/kernel/irq.c |4 ++--
arch/blackfin/mach-common/ints-priority.c |3 ++-
arch/ia64/kernel/iosapic.c|2 +-
arch/ia64/kernel/irq.c|6 +++---
arch/ia64/kernel/msi_ia64.c |4 ++--
arch/ia64/sn/kernel/msi_sn.c |2 +-
arch/metag/kernel/irq.c | 10 ++
arch/mips/bcm63xx/irq.c |2 +-
arch/mips/cavium-octeon/octeon-irq.c | 14 --
arch/mips/pmcs-msp71xx/msp_irq_cic.c |3 ++-
arch/mn10300/kernel/cevt-mn10300.c|2 +-
arch/mn10300/kernel/irq.c | 13 +++--
arch/parisc/kernel/irq.c | 12 ++--
arch/powerpc/kernel/irq.c |2 +-
arch/powerpc/sysdev/xics/ics-opal.c |2 +-
arch/powerpc/sysdev/xics/ics-rtas.c |2 +-
arch/sh/kernel/irq.c |7 ---
arch/sparc/kernel/irq_64.c| 12 +++-
arch/sparc/kernel/leon_kernel.c |6 +++---
arch/x86/kernel/apic/io_apic.c|2 +-
arch/x86/kernel/apic/vector.c |5 ++---
arch/x86/kernel/irq.c |5 +++--
arch/xtensa/kernel/irq.c | 10 ++
drivers/irqchip/irq-mips-gic.c|2 +-
drivers/parisc/iosapic.c |2 +-
drivers/sh/intc/chip.c|6 +++---
drivers/xen/events/events_base.c |4 ++--
include/linux/irq.h | 12
30 files changed, 93 insertions(+), 69 deletions(-)
diff --git a/arch/alpha/kernel/irq.c b/arch/alpha/kernel/irq.c
index 7b2be251c30f..bd8e47699cad 100644
--- a/arch/alpha/kernel/irq.c
+++ b/arch/alpha/kernel/irq.c
@@ -60,7 +60,7 @@ int irq_select_affinity(unsigned int irq)
cpu = (cpu (NR_CPUS-1) ? cpu + 1 : 0);
last_cpu = cpu;
- cpumask_copy(data-affinity, cpumask_of(cpu));
+ cpumask_copy(irq_data_get_affinity_mask(data), cpumask_of(cpu));
chip-irq_set_affinity(data, cpumask_of(cpu), false);
return 0;
}
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 350f188c92d2..baf8edebe26f 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -140,7 +140,7 @@ int __init arch_probe_nr_irqs(void)
static bool migrate_one_irq(struct irq_desc *desc)
{
struct irq_data *d = irq_desc_get_irq_data(desc);
- const struct cpumask *affinity = d-affinity;
+ const struct cpumask *affinity = irq_data_get_affinity_mask(d);
struct irq_chip *c;
bool ret = false;
@@ -160,7 +160,7 @@ static bool migrate_one_irq(struct irq_desc *desc)
if (!c-irq_set_affinity)
pr_debug(IRQ%u: unable to set affinity\n, d-irq);
else if (c-irq_set_affinity(d, affinity, false) == IRQ_SET_MASK_OK
ret)
- cpumask_copy(d-affinity, affinity);
+ cpumask_copy(irq_data_get_affinity_mask(d), affinity);
return ret;
}
diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index 240b75c0e94f..463fa2e7e34c 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -61,7 +61,7 @@ void __init init_IRQ(void)
static bool migrate_one_irq(struct irq_desc *desc)
{
struct irq_data *d = irq_desc_get_irq_data(desc);
- const struct cpumask *affinity = d-affinity;
+ const struct cpumask *affinity = irq_data_get_affinity_mask(d);
struct irq_chip *c;
bool ret = false;
@@ -81,7 +81,7 @@ static bool migrate_one_irq(struct irq_desc *desc)
if (!c-irq_set_affinity)
pr_debug(IRQ%u: unable to set affinity\n, d-irq);
else if (c-irq_set_affinity(d, affinity, false) == IRQ_SET_MASK_OK
ret)
- cpumask_copy(d-affinity, affinity);
+ cpumask_copy(irq_data_get_affinity_mask(d), affinity);
return ret;
}
diff --git a/arch/blackfin/mach-common/ints-priority.c
b/arch/blackfin/mach-common/ints-priority.c
index 7236bdfc71e6..332a434b4669 100644
--- a/arch/blackfin/mach-common/ints-priority.c
+++ b/arch/blackfin/mach-common/ints-priority.c
@@ -194,7 +194,8 @@ void bfin_internal_unmask_irq(unsigned int irq)
#ifdef CONFIG_SMP
static void bfin_internal_unmask_irq_chip(struct irq_data *d)
{
- bfin_internal_unmask_irq_affinity(d-irq, d-affinity);
+ bfin_internal_unmask_irq_affinity(d-irq,
+ irq_data_get_affinity_mask(d));
}
static int bfin_internal_set_affinity(struct irq_data *d,
diff --git
Re: [Xen-devel] [xen-unstable test] 56456: regressions - FAIL
At 10:12 +0100 on 20 May (1432116766), Jan Beulich wrote:
On 20.05.15 at 10:58, roger@citrix.com wrote:
After looking into this a little bit more, I'm afraid I don't see a
straight forward way to check for the permissions of all paging levels.
Here are the options I've found in order to deal with this:
- Use guest_get_eff_l1e and only check for the permissions of the L1
entry. Is it possible that the guest places an invalid entry in the
linear l1 table without Xen realizing?
No - all page table changes are being validated by Xen.
Yes, using guest_get_eff_l1e() is safe for Xen. The only concern is
whether it's safe for the guest -- Xen might not honour an upper-level
read-only mark (which copy_to_guest() would) or a supervisor-mode-only
mark (which it wouldn't).
- Add a new function hook somewhere (pv_domain maybe?) that can be
used to translate GVA to PFN for PV guests (mimicking what
paging_gva_to_gfn does). This would be implemented using
guest_walk_X_level, where X is the paging levels of the guest.
- Use some glue to be able to call guest_walk_{3/4}_level from
paging.c directly, and correctly choose which one to use based on
the guest bitness. IMHO this looks quite wacky, and I'm not even
sure if it's possible given the amount of preprocessor foo in
guest_pt.h.
I have the first option already implemented, but I would appreciate some
advice regarding the security implications of it.
I think with all of the options here being unsatisfactory we should
reconsider your original option of restoring previous behavior
(without any mapping) for the PV case. Tim?
Yeah, I don't think it's worth adding a bunch mode pagetable-walk
machinery just to keep this function clean. So I suppose we have to
have two paths. in this code.
Cheers,
Tim.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 56456: regressions - FAIL
El 20/05/15 a les 11.43, Tim Deegan ha escrit:
At 10:12 +0100 on 20 May (1432116766), Jan Beulich wrote:
On 20.05.15 at 10:58, roger@citrix.com wrote:
After looking into this a little bit more, I'm afraid I don't see a
straight forward way to check for the permissions of all paging levels.
Here are the options I've found in order to deal with this:
- Use guest_get_eff_l1e and only check for the permissions of the L1
entry. Is it possible that the guest places an invalid entry in the
linear l1 table without Xen realizing?
No - all page table changes are being validated by Xen.
Yes, using guest_get_eff_l1e() is safe for Xen. The only concern is
whether it's safe for the guest -- Xen might not honour an upper-level
read-only mark (which copy_to_guest() would) or a supervisor-mode-only
mark (which it wouldn't).
- Add a new function hook somewhere (pv_domain maybe?) that can be
used to translate GVA to PFN for PV guests (mimicking what
paging_gva_to_gfn does). This would be implemented using
guest_walk_X_level, where X is the paging levels of the guest.
- Use some glue to be able to call guest_walk_{3/4}_level from
paging.c directly, and correctly choose which one to use based on
the guest bitness. IMHO this looks quite wacky, and I'm not even
sure if it's possible given the amount of preprocessor foo in
guest_pt.h.
I have the first option already implemented, but I would appreciate some
advice regarding the security implications of it.
I think with all of the options here being unsatisfactory we should
reconsider your original option of restoring previous behavior
(without any mapping) for the PV case. Tim?
Yeah, I don't think it's worth adding a bunch mode pagetable-walk
machinery just to keep this function clean. So I suppose we have to
have two paths. in this code.
FWIW there's also the option of taking the callers p2m lock if it's a
HVM guest:
http://lists.xen.org/archives/html/xen-devel/2014-10/msg01769.html
And avoid doing any modifications of the code paths.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 56759: regressions - FAIL
On Wed, 2015-05-20 at 09:34 +, osstest service user wrote: flight 56759 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/56759/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 17 leak-check/check fail REGR. vs. 56375 I'm pretty hard pressed to explain this from the set of commits currently under test, but it has happened a few times now (e.g. 56700 56576) so it does seem to be real. http://logs.test-lab.xenproject.org/osstest/results/bisect.xen-unstable.test-armhf-armhf-xl-multivcpu.leak-check--check.html is working on it and is currently consider the set of changes from: ianc@cosworth:xen.git$ git log --oneline 9ab42~1...45fcc4 45fcc45 use ticket locks for spin locks e13013d libxc/restore: add checkpointed flag to the restore context ce44b40 libxc/restore: introduce setup() and cleanup() on restore c5c5a04 libxc/restore: split read/handle qemu info 9ab42c9 libxc/restore: introduce process_record() where e13013d is current master which was pushed in by flight 56375. I think it unlikely the libxl stuff is responible, given we don't migrate on ARM, which would seem to point to the ticket locks... Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 4/5] tools/libxl: move toolstack code into libxl_toolstack.c
move toolstack code into libxl_toolstack.c
Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
CC: Andrew Cooper andrew.coop...@citrix.com
---
tools/libxl/Makefile | 2 +-
tools/libxl/libxl_dom.c | 171
tools/libxl/libxl_toolstack.c | 196 ++
3 files changed, 197 insertions(+), 172 deletions(-)
create mode 100644 tools/libxl/libxl_toolstack.c
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index a9abdbc..48f2cbb 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -96,7 +96,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o
libxl_pci.o \
libxl_json.o libxl_aoutils.o libxl_numa.o libxl_vnuma.o
\
libxl_save_callout.o _libxl_save_msgs_callout.o \
libxl_qmp.o libxl_event.o libxl_fork.o
libxl_dom_suspend.o \
- $(LIBXL_OBJS-y)
+ libxl_toolstack.o $(LIBXL_OBJS-y)
LIBXL_OBJS += libxl_genid.o
LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index b937d99..1caf21c 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1020,87 +1020,6 @@ int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t
domid,
return libxl__xs_write(gc, XBT_NULL, path, %s, cmd);
}
-struct libxl__physmap_info {
-uint64_t phys_offset;
-uint64_t start_addr;
-uint64_t size;
-uint32_t namelen;
-char name[];
-};
-
-#define TOOLSTACK_SAVE_VERSION 1
-
-static inline char *restore_helper(libxl__gc *gc, uint32_t dm_domid,
- uint32_t domid,
- uint64_t phys_offset, char *node)
-{
-return libxl__device_model_xs_path(gc, dm_domid, domid,
- /physmap/%PRIx64/%s,
- phys_offset, node);
-}
-
-int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
- uint32_t size, void *user)
-{
-libxl__save_helper_state *shs = user;
-libxl__domain_create_state *dcs = CONTAINER_OF(shs, *dcs, shs);
-STATE_AO_GC(dcs-ao);
-int i, ret;
-const uint8_t *ptr = buf;
-uint32_t count = 0, version = 0;
-struct libxl__physmap_info* pi;
-char *xs_path;
-uint32_t dm_domid;
-
-LOG(DEBUG,domain=%PRIu32 toolstack data size=%PRIu32, domid, size);
-
-if (size sizeof(version) + sizeof(count)) {
-LOG(ERROR, wrong size);
-return -1;
-}
-
-memcpy(version, ptr, sizeof(version));
-ptr += sizeof(version);
-
-if (version != TOOLSTACK_SAVE_VERSION) {
-LOG(ERROR, wrong version);
-return -1;
-}
-
-memcpy(count, ptr, sizeof(count));
-ptr += sizeof(count);
-
-if (size sizeof(version) + sizeof(count) +
-count * (sizeof(struct libxl__physmap_info))) {
-LOG(ERROR, wrong size);
-return -1;
-}
-
-dm_domid = libxl_get_stubdom_id(CTX, domid);
-for (i = 0; i count; i++) {
-pi = (struct libxl__physmap_info*) ptr;
-ptr += sizeof(struct libxl__physmap_info) + pi-namelen;
-
-xs_path = restore_helper(gc, dm_domid, domid,
- pi-phys_offset, start_addr);
-ret = libxl__xs_write(gc, 0, xs_path, %PRIx64, pi-start_addr);
-if (ret)
-return -1;
-xs_path = restore_helper(gc, dm_domid, domid, pi-phys_offset, size);
-ret = libxl__xs_write(gc, 0, xs_path, %PRIx64, pi-size);
-if (ret)
-return -1;
-if (pi-namelen 0) {
-xs_path = restore_helper(gc, dm_domid, domid,
- pi-phys_offset, name);
-ret = libxl__xs_write(gc, 0, xs_path, %s, pi-name);
-if (ret)
-return -1;
-}
-}
-return 0;
-}
-
/*- complicated callback, called by xc_domain_save -*/
/*
@@ -1315,96 +1234,6 @@ static void switch_logdirty_done(libxl__egc *egc,
libxl__xc_domain_saverestore_async_callback_done(egc, dss-shs, broke);
}
-static inline char *physmap_path(libxl__gc *gc, uint32_t dm_domid,
- uint32_t domid,
- char *phys_offset, char *node)
-{
-return libxl__device_model_xs_path(gc, dm_domid, domid,
- /physmap/%s/%s,
- phys_offset, node);
-}
-
-int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
-uint32_t *len, void *dss_void)
-{
-libxl__domain_suspend_state *dss = dss_void;
-STATE_AO_GC(dss-ao);
-int i = 0;
-char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
-unsigned int num = 0;
-uint32_t count = 0, version =
[Xen-devel] [PATCH v1 2/5] tools/libxl: move domain suspend codes into a separate file
move domain suspend codes into a separate file libxl_dom_suspend.c
Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
CC: Andrew Cooper andrew.coop...@citrix.com
---
tools/libxl/Makefile| 3 +-
tools/libxl/libxl_dom.c | 376 +
tools/libxl/libxl_dom_suspend.c | 400
tools/libxl/libxl_internal.h| 6 +
4 files changed, 412 insertions(+), 373 deletions(-)
create mode 100644 tools/libxl/libxl_dom_suspend.c
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 1b16598..21558b0 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -95,7 +95,8 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o
libxl_pci.o \
libxl_internal.o libxl_utils.o libxl_uuid.o \
libxl_json.o libxl_aoutils.o libxl_numa.o libxl_vnuma.o
\
libxl_save_callout.o _libxl_save_msgs_callout.o \
- libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
+ libxl_qmp.o libxl_event.o libxl_fork.o
libxl_dom_suspend.o \
+ $(LIBXL_OBJS-y)
LIBXL_OBJS += libxl_genid.o
LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 1f64285..1681a12 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1101,13 +1101,6 @@ int libxl__toolstack_restore(uint32_t domid, const
uint8_t *buf,
return 0;
}
-/* Domain suspend (save) */
-
-static void domain_save_done(libxl__egc *egc,
- libxl__domain_save_state *dss, int rc);
-static void domain_suspend_callback_common_done(libxl__egc *egc,
-libxl__domain_suspend_state *dss, int ok);
-
/*- complicated callback, called by xc_domain_save -*/
/*
@@ -1322,352 +1315,6 @@ static void switch_logdirty_done(libxl__egc *egc,
libxl__xc_domain_saverestore_async_callback_done(egc, dss-shs, broke);
}
-/*- callbacks, called by xc_domain_save -*/
-
-int libxl__domain_suspend_device_model(libxl__gc *gc,
- libxl__domain_suspend_state *dss)
-{
-int ret = 0;
-uint32_t const domid = dss-domid;
-const char *const filename = dss-dm_savefile;
-
-switch (libxl__device_model_version_running(gc, domid)) {
-case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-LOG(DEBUG, Saving device model state to %s, filename);
-libxl__qemu_traditional_cmd(gc, domid, save);
-libxl__wait_for_device_model_deprecated(gc, domid, paused, NULL,
NULL, NULL);
-break;
-}
-case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-if (libxl__qmp_stop(gc, domid))
-return ERROR_FAIL;
-/* Save DM state into filename */
-ret = libxl__qmp_save(gc, domid, filename);
-if (ret)
-unlink(filename);
-break;
-default:
-return ERROR_INVAL;
-}
-
-return ret;
-}
-
-int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
-{
-
-switch (libxl__device_model_version_running(gc, domid)) {
-case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-libxl__qemu_traditional_cmd(gc, domid, continue);
-libxl__wait_for_device_model_deprecated(gc, domid, running, NULL,
NULL, NULL);
-break;
-}
-case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-if (libxl__qmp_resume(gc, domid))
-return ERROR_FAIL;
-break;
-default:
-return ERROR_INVAL;
-}
-
-return 0;
-}
-
-static void domain_suspend_common_wait_guest(libxl__egc *egc,
- libxl__domain_suspend_state *dss);
-static void domain_suspend_common_guest_suspended(libxl__egc *egc,
- libxl__domain_suspend_state *dss);
-
-static void domain_suspend_common_pvcontrol_suspending(libxl__egc *egc,
- libxl__xswait_state *xswa, int rc, const char *state);
-static void domain_suspend_common_wait_guest_evtchn(libxl__egc *egc,
-libxl__ev_evtchn *evev);
-static void suspend_common_wait_guest_watch(libxl__egc *egc,
- libxl__ev_xswatch *xsw, const char *watch_path, const char *event_path);
-static void suspend_common_wait_guest_check(libxl__egc *egc,
-libxl__domain_suspend_state *dss);
-static void suspend_common_wait_guest_timeout(libxl__egc *egc,
- libxl__ev_time *ev, const struct timeval *requested_abs);
-
-static void domain_suspend_common_failed(libxl__egc *egc,
- libxl__domain_suspend_state *dss);
-static void domain_suspend_common_done(libxl__egc *egc,
- libxl__domain_suspend_state *dss,
-
[Xen-devel] [PATCH v1 5/5] tools/libxl: move domain save codes into libxl_dom_save.c
move domain save codes into libxl_dom_save.c
Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
CC: Andrew Cooper andrew.coop...@citrix.com
---
tools/libxl/Makefile | 2 +-
tools/libxl/libxl_dom.c | 468
tools/libxl/libxl_dom_save.c | 493 +++
3 files changed, 494 insertions(+), 469 deletions(-)
create mode 100644 tools/libxl/libxl_dom_save.c
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 48f2cbb..105a989 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -96,7 +96,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o
libxl_pci.o \
libxl_json.o libxl_aoutils.o libxl_numa.o libxl_vnuma.o
\
libxl_save_callout.o _libxl_save_msgs_callout.o \
libxl_qmp.o libxl_event.o libxl_fork.o
libxl_dom_suspend.o \
- libxl_toolstack.o $(LIBXL_OBJS-y)
+ libxl_toolstack.o libxl_dom_save.o $(LIBXL_OBJS-y)
LIBXL_OBJS += libxl_genid.o
LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 1caf21c..d536475 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1020,474 +1020,6 @@ int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t
domid,
return libxl__xs_write(gc, XBT_NULL, path, %s, cmd);
}
-/*- complicated callback, called by xc_domain_save -*/
-
-/*
- * We implement the other end of protocol for controlling qemu-dm's
- * logdirty. There is no documentation for this protocol, but our
- * counterparty's implementation is in
- * qemu-xen-traditional.git:xenstore.c in the function
- * xenstore_process_logdirty_event
- */
-
-static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
-const struct timeval *requested_abs);
-static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch*,
-const char *watch_path, const char *event_path);
-static void switch_logdirty_done(libxl__egc *egc,
- libxl__domain_save_state *dss, int ok);
-
-static void logdirty_init(libxl__logdirty_switch *lds)
-{
-lds-cmd_path = 0;
-libxl__ev_xswatch_init(lds-watch);
-libxl__ev_time_init(lds-timeout);
-}
-
-static void domain_suspend_switch_qemu_xen_traditional_logdirty
- (int domid, unsigned enable,
-libxl__save_helper_state *shs)
-{
-libxl__egc *egc = shs-egc;
-libxl__domain_save_state *dss = CONTAINER_OF(shs, *dss, shs);
-libxl__logdirty_switch *lds = dss-logdirty;
-STATE_AO_GC(dss-ao);
-int rc;
-xs_transaction_t t = 0;
-const char *got;
-
-if (!lds-cmd_path) {
-uint32_t dm_domid = libxl_get_stubdom_id(CTX, domid);
-lds-cmd_path = libxl__device_model_xs_path(gc, dm_domid, domid,
-/logdirty/cmd);
-lds-ret_path = libxl__device_model_xs_path(gc, dm_domid, domid,
-/logdirty/ret);
-}
-lds-cmd = enable ? enable : disable;
-
-rc = libxl__ev_xswatch_register(gc, lds-watch,
-switch_logdirty_xswatch, lds-ret_path);
-if (rc) goto out;
-
-rc = libxl__ev_time_register_rel(gc, lds-timeout,
-switch_logdirty_timeout, 10*1000);
-if (rc) goto out;
-
-for (;;) {
-rc = libxl__xs_transaction_start(gc, t);
-if (rc) goto out;
-
-rc = libxl__xs_read_checked(gc, t, lds-cmd_path, got);
-if (rc) goto out;
-
-if (got) {
-const char *got_ret;
-rc = libxl__xs_read_checked(gc, t, lds-ret_path, got_ret);
-if (rc) goto out;
-
-if (!got_ret || strcmp(got, got_ret)) {
-LOG(ERROR,controlling logdirty: qemu was already sent
- command `%s' (xenstore path `%s') but result is `%s',
-got, lds-cmd_path, got_ret ? got_ret : none);
-rc = ERROR_FAIL;
-goto out;
-}
-rc = libxl__xs_rm_checked(gc, t, lds-cmd_path);
-if (rc) goto out;
-}
-
-rc = libxl__xs_rm_checked(gc, t, lds-ret_path);
-if (rc) goto out;
-
-rc = libxl__xs_write_checked(gc, t, lds-cmd_path, lds-cmd);
-if (rc) goto out;
-
-rc = libxl__xs_transaction_commit(gc, t);
-if (!rc) break;
-if (rc0) goto out;
-}
-
-/* OK, wait for some callback */
-return;
-
- out:
-LOG(ERROR,logdirty switch failed (rc=%d), aborting suspend,rc);
-libxl__xs_transaction_abort(gc, t);
-switch_logdirty_done(egc,dss,-1);
-}
-
-static void
[Xen-devel] [PATCH v1 1/5] libxl/save: Refactor libxl__domain_suspend_state
Currently struct libxl__domain_suspend_state contains 2 type of states,
one is save state, another is suspend state. This patch separate it out.
Also rename libxl__domain_suspend() to libxl__domain_save() since it
actually do the save domain work.
Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
CC: Andrew Cooper andrew.coop...@citrix.com
---
tools/libxl/libxl.c | 18 +++---
tools/libxl/libxl_dom.c | 126 +--
tools/libxl/libxl_internal.h | 45 --
tools/libxl/libxl_netbuffer.c| 2 +-
tools/libxl/libxl_save_callout.c | 2 +-
5 files changed, 108 insertions(+), 85 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index a6eb2df..7259061 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -830,7 +830,7 @@ static void libxl__remus_setup_done(libxl__egc *egc,
static void libxl__remus_setup_failed(libxl__egc *egc,
libxl__remus_devices_state *rds, int rc);
static void remus_failover_cb(libxl__egc *egc,
- libxl__domain_suspend_state *dss, int rc);
+ libxl__domain_save_state *dss, int rc);
/* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
@@ -838,7 +838,7 @@ int libxl_domain_remus_start(libxl_ctx *ctx,
libxl_domain_remus_info *info,
const libxl_asyncop_how *ao_how)
{
AO_CREATE(ctx, domid, ao_how);
-libxl__domain_suspend_state *dss;
+libxl__domain_save_state *dss;
int rc;
libxl_domain_type type = libxl__domain_type(gc, domid);
@@ -907,11 +907,11 @@ int libxl_domain_remus_start(libxl_ctx *ctx,
libxl_domain_remus_info *info,
static void libxl__remus_setup_done(libxl__egc *egc,
libxl__remus_devices_state *rds, int rc)
{
-libxl__domain_suspend_state *dss = CONTAINER_OF(rds, *dss, rds);
+libxl__domain_save_state *dss = CONTAINER_OF(rds, *dss, rds);
STATE_AO_GC(dss-ao);
if (!rc) {
-libxl__domain_suspend(egc, dss);
+libxl__domain_save(egc, dss);
return;
}
@@ -924,7 +924,7 @@ static void libxl__remus_setup_done(libxl__egc *egc,
static void libxl__remus_setup_failed(libxl__egc *egc,
libxl__remus_devices_state *rds, int rc)
{
-libxl__domain_suspend_state *dss = CONTAINER_OF(rds, *dss, rds);
+libxl__domain_save_state *dss = CONTAINER_OF(rds, *dss, rds);
STATE_AO_GC(dss-ao);
if (rc)
@@ -935,7 +935,7 @@ static void libxl__remus_setup_failed(libxl__egc *egc,
}
static void remus_failover_cb(libxl__egc *egc,
- libxl__domain_suspend_state *dss, int rc)
+ libxl__domain_save_state *dss, int rc)
{
STATE_AO_GC(dss-ao);
/*
@@ -947,7 +947,7 @@ static void remus_failover_cb(libxl__egc *egc,
}
static void domain_suspend_cb(libxl__egc *egc,
- libxl__domain_suspend_state *dss, int rc)
+ libxl__domain_save_state *dss, int rc)
{
STATE_AO_GC(dss-ao);
libxl__ao_complete(egc,ao,rc);
@@ -966,7 +966,7 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid,
int fd, int flags,
goto out_err;
}
-libxl__domain_suspend_state *dss;
+libxl__domain_save_state *dss;
GCNEW(dss);
dss-ao = ao;
@@ -978,7 +978,7 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid,
int fd, int flags,
dss-live = flags LIBXL_SUSPEND_LIVE;
dss-debug = flags LIBXL_SUSPEND_DEBUG;
-libxl__domain_suspend(egc, dss);
+libxl__domain_save(egc, dss);
return AO_INPROGRESS;
out_err:
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index a0c9850..1f64285 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1103,8 +1103,8 @@ int libxl__toolstack_restore(uint32_t domid, const
uint8_t *buf,
/* Domain suspend (save) */
-static void domain_suspend_done(libxl__egc *egc,
-libxl__domain_suspend_state *dss, int rc);
+static void domain_save_done(libxl__egc *egc,
+ libxl__domain_save_state *dss, int rc);
static void domain_suspend_callback_common_done(libxl__egc *egc,
libxl__domain_suspend_state *dss, int ok);
@@ -1123,7 +1123,7 @@ static void switch_logdirty_timeout(libxl__egc *egc,
libxl__ev_time *ev,
static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch*,
const char *watch_path, const char *event_path);
static void switch_logdirty_done(libxl__egc *egc,
- libxl__domain_suspend_state *dss, int ok);
+
Re: [Xen-devel] ARM-Xen customization of stage two translation.
On 20/05/15 13:05, Mazen Ezzeddine (Student) wrote:
Thanks so much.
I will ensure to keep xen-devel cced and avoid top-post. Sorry and thanks for
notifying me.
However, my use-case will involve a scenario where the the page frames
excluded from the second stage translation are to be allocated on the fly
(through a slightly modified second stage translation) to a special guest
when scheduled. Does mreserve work in such scenario?
Give a look to {,un}map_mmio_regions and
guest_physmap_add_entry/guest_physmap_remove_page in xen/arch/arm/p2m.c
regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [GIT PULL] xen: bug fixes for 4.1-rc4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.1b-rc4-tag xen: bug fixes for 4.1-rc4 - - Fix ARM build regression. - - Fix VIRQ_CONSOLE related oops. Thanks. David arch/arm/xen/enlighten.c |1 + drivers/tty/hvc/hvc_xen.c|2 +- drivers/xen/events/events_base.c | 12 include/xen/events.h |2 +- 4 files changed, 11 insertions(+), 6 deletions(-) Boris Ostrovsky (1): xen/arm: Define xen_arch_suspend() David Vrabel (1): xen/events: don't bind non-percpu VIRQs with percpu chip -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJVXHwtAAoJEFxbo/MsZsTRIlYH/RZHTXZgOs1tGqn+vCyM/0LZ qvmhi4Zl1I6soTLqvszyhMNu7fKlRxppxdAC3+TQhj/vtgtBheBmvjRyUzpgCdGw xKH+zYAjtxMPZLVlI5vYO6z9hVwhOk5ncht2DzJGtSUhyFl4ADgQ+maZ74kdgcet V4h2OsEOIZcvQ+XpTt8iT0zZGC1w0M0gidLU+/ZiAjWxKEOviiZUp7eYSwwLAiRY p/SIdYjHaxuNaMnYROcmTGsj6FH6TIFH56YQxiDo1n+ekFH4ca0wNH5xDILn8vtk Ize5iKhLXdMu5mlHxcQIpW76fFxOlF8uQY7Wcm39yhXPIzWXDhz29L8pkUZkWXE= =sMnK -END PGP SIGNATURE- ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.4 test] 56764: regressions - FAIL
flight 56764 linux-3.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/56764/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 9 debian-install fail REGR. vs. 52209-bisect test-amd64-amd64-pair 15 debian-install/dst_host fail REGR. vs. 52715-bisect test-amd64-i386-pair15 debian-install/dst_host fail REGR. vs. 56366-bisect Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 9 debian-installfail blocked in 56366-bisect test-amd64-amd64-libvirt 9 debian-installfail blocked in 56366-bisect test-amd64-amd64-xl-multivcpu 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-libvirt-xsm 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-libvirt 9 debian-installfail blocked in 56366-bisect test-amd64-i386-freebsd10-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-sedf-pin 9 debian-installfail blocked in 56366-bisect test-amd64-i386-freebsd10-i386 16 guest-localmigrate/x10 fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl9 debian-installfail blocked in 56366-bisect test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail blocked in 56366-bisect test-amd64-i386-rumpuserxen-i386 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail blocked in 56366-bisect test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail blocked in 56366-bisect Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-credit2 9 debian-install fail never pass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-pvh-amd 9 debian-install fail never pass test-amd64-i386-xl-xsm9 debian-install fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-pvh-intel 9 debian-install fail never pass test-amd64-amd64-libvirt-xsm 9 debian-install fail never pass test-amd64-amd64-xl-xsm 9 debian-install fail never pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass version targeted for testing: linux56b48fcda5076d4070ab00df32ff5ff834e0be86 baseline version: linuxbb4a05a0400ed6d2f1e13d1f82f289ff74300a70 370 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemut-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm
Re: [Xen-devel] [PATCH v9 1/6] tools/libxl: Check if fdt_{first, next}_subnode are present in libfdt
Hi,
new version of this patch below.
I have also pushed a new branch will all the series:
git://xenbits.xen.org/people/julieng/xen-unstable.git branch passthrough-v9.1
Regards,
From d4f0ea84f26649b61bc6afb550348069b71d41c5 Mon Sep 17 00:00:00 2001
From: Julien Grall julien.gr...@linaro.org
Date: Tue, 17 Mar 2015 17:58:14 +
Subject: [PATCH] tools/libxl: Check if fdt_{first,next}_subnode are present in
libfdt
The functions fdt_{first,next}_subnode may not be available because:
* It has been introduced in 2013 = Doesn't work on Wheezy
* The prototype exists but the functions are not exposed. Don't ask
why...
The later has been fixed recently in the dtc repo [1]
When the functions are not available, implement our own in order to use
them in a following patch.
Note that the _hidden attribute is placed in both the prototype and the
declaration because some version of libfdt expose the prototype but not
the declaration.
[1] git://git.kernel.org/pub/scm/utils/dtc/dtc.git
commit a4b093f7366fdb429ca1781144d3985fa50d0fbb
Signed-off-by: Julien Grall julien.gr...@linaro.org
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
Cc: Wei Liu wei.l...@citrix.com
---
tools/configure needs to be regenerate as this patch is modifying
tools/configure.ac
Changes in v9.1:
- Mark hidden the new function.
Changes in v9:
- Remove spurious change in libxl_internal.h
- Add _hidden on the imported fdt_* functions
- Typo in the commit message
Changes in v8:
- Forgot to add the new header file libxl_libfdt_compat.h on the
previous version
Changes in v7:
- Drop Ian's ack as he request some changes due to build issue
- Check if the declaration are present if not add declaration
- Remove changes config.h.in as it will be regenerate before
committed
Changes in v6:
- Add Ian's Ack
Changes in v5:
- Add Ian's Signed-off-by for the license part and update the
license
- Rename libxl_fdt to libxl_libfdt_compat.c
Changes in v4:
- Patch added
---
tools/configure.ac| 6 +++
tools/libxl/Makefile | 2 +-
tools/libxl/libxl_libfdt_compat.c | 94 +++
tools/libxl/libxl_libfdt_compat.h | 82 ++
4 files changed, 183 insertions(+), 1 deletion(-)
create mode 100644 tools/libxl/libxl_libfdt_compat.c
create mode 100644 tools/libxl/libxl_libfdt_compat.h
diff --git a/tools/configure.ac b/tools/configure.ac
index d31c2f3..5b48ab2 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -355,6 +355,12 @@ AC_SUBST(libiconv)
case $host_cpu in
arm*|aarch64)
AC_CHECK_LIB([fdt], [fdt_create], [], [AC_MSG_ERROR([Could not find libfdt])])
+
+# The functions fdt_{first,next}_subnode may not be available because:
+# * It has been introduced in 2013 = Doesn't work on Wheezy
+# * The prototype exists but the functions are not exposed. Don't ask why...
+AC_CHECK_FUNCS([fdt_first_subnode fdt_next_subnode])
+AC_CHECK_DECLS([fdt_first_subnode, fdt_next_subnode],,,[#include libfdt.h])
esac
# Checks for header files.
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 1b16598..2afb146 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -59,7 +59,7 @@ endif
LIBXL_OBJS-y += libxl_remus_device.o libxl_remus_disk_drbd.o
LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
-LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
ifeq ($(CONFIG_NetBSD),y)
LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_libfdt_compat.c
b/tools/libxl/libxl_libfdt_compat.c
new file mode 100644
index 000..02b8f74
--- /dev/null
+++ b/tools/libxl/libxl_libfdt_compat.c
@@ -0,0 +1,94 @@
+/*
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This file is part of libxl, and was originally taken from libfdt.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Lesser General Public License for more details.
+ *
+ * Additionally, this particular file is dual licensed. That is,
+ * alternatively, at your option:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above
+ * copyright notice, this list of conditions and the following
+ *
Re: [Xen-devel] [PATCH] xen/public: Clarify xen_arch_domainconfig ABI statement
Hi Andrew, On 20/05/15 14:10, Andrew Cooper wrote: This structure is used by XEN_DOMCTL_createdomain, and is liable to be modified going forwards. Explicitly state that it falls under the XEN_DOMCTL_INTERFACE_VERSION. Signed-off-by: Andrew Cooper andrew.coop...@citrix.com CC: Keir Fraser k...@xen.org CC: Jan Beulich jbeul...@suse.com CC: Ian Campbell ian.campb...@citrix.com CC: Stefano Stabellini stefano.stabell...@citrix.com CC: Tim Deegan t...@xen.org CC: Julien Grall julien.gr...@citrix.com CC: Don Slutz dsl...@verizon.com Reviewed-by: Julien Grall julien.gr...@citrix.com Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 2/2] xen/block: add multi-page ring support
Hi, On 20/05/15 14:10, Bob Liu wrote: --- drivers/block/xen-blkback/blkback.c | 12 drivers/block/xen-blkback/common.h | 3 +- drivers/block/xen-blkback/xenbus.c | 85 +--- drivers/block/xen-blkfront.c| 110 ++-- 4 files changed, 161 insertions(+), 49 deletions(-) diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c index 713fc9f..057890f 100644 --- a/drivers/block/xen-blkback/blkback.c +++ b/drivers/block/xen-blkback/blkback.c @@ -84,6 +84,12 @@ MODULE_PARM_DESC(max_persistent_grants, Maximum number of grants to map persistently); /* + * Maximum number of pages to be used as the ring between front and backend + */ +unsigned int xen_blkif_max_ring_order = XENBUS_MAX_RING_PAGE_ORDER; We will soon support 64KB page granularity with ARM64, although the PV protocol will keep a 4KB page granularity. Can you clarify with granularity is used here? The one of the host or the one of the PV protocol? +module_param_named(max_ring_page_order, xen_blkif_max_ring_order, int, S_IRUGO); +MODULE_PARM_DESC(max_ring_page_order, Maximum order of pages to be used as the ring); +/* * The LRU mechanism to clean the lists of persistent grants needs to * be executed periodically. The time interval between consecutive executions * of the purge mechanism is set in ms. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Slective IRQ trapping.
Thanks Ian. I have already taken a look at Asking Developer Questions (upon registration) and have reread after you email . But I can not see what's the issue? is that my question not not understandable or ...? Thank you so much and best regards. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 5/6] cs-bisection-step: Do not treat repro attempts as flail
The need_repro machinery deliberarely makes attempts to reproduce
various results.
This can cause the flail detector to trigger when not intended. In
particular, the bisector may have (for some reason[1]) restarted with
a new baseline, and the temporarally-stripy pass/fail requirement
would then require the basis fail to be repro'd, again.
[1] Currently this happens much more often than is desirable. This
will be fixed in a moment.
Fix this by only considering, for the purposes of flail, flights which
are no older than the first repro (the basis pass).
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
cs-bisection-step |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/cs-bisection-step b/cs-bisection-step
index 743a3e5..da13927 100755
--- a/cs-bisection-step
+++ b/cs-bisection-step
@@ -742,6 +742,7 @@ sub conflicted_warning ($$) {
}
our $repro_lastflight;
+our $repro_firstflight = 0;
our $repro_count;
sub need_repro_sequence ($$) {
@@ -780,6 +781,7 @@ sub need_repro ($$$) {
($repro_count ? Repro : Result).
found: flight $f-{Flight} ($st), for $what\n;
$repro_lastflight= $f-{Flight};
+$repro_firstflight ||= $f-{Flight};
return 0;
}
print STDERR Need to reproduce $what ($st); had $repro_count already.\n;
@@ -1246,12 +1248,13 @@ END
my $equalflightsq = $dbh_tests-prepare($equalflightsqt);
db_retry($popflight,'constructing', $dbh_tests,[qw(flights)], sub {
-print STDERR Checking for flail...\n;
+print STDERR Checking for flail (since $repro_firstflight)...\n;
my ($minflight) = $dbh_tests-selectrow_array(END, {}, $branch);
SELECT flight FROM (
SELECT flight FROM flights
WHERE branch=? AND $blessingscond $maxflight_cond
+ AND flight = $repro_firstflight
ORDER BY flight DESC
LIMIT 100
) last100 ORDER BY FLIGHT ASC LIMIT 1
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 2/6] cs-bisection-step: Clarify and correct flailing message
There are many other possible reasons for this, besides a bug in the
build version machinery.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
cs-bisection-step |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/cs-bisection-step b/cs-bisection-step
index e8b95ca..4891e93 100755
--- a/cs-bisection-step
+++ b/cs-bisection-step
@@ -1275,10 +1275,9 @@ END
print DEBUG nequalflights=$nequalflights\n$explanation\n;
if ($nequalflights $maxequalflights) {
summary_report(END, END, 32);
-Flailing - $nequalflights identical flights to no useful effect
+Flailing - =$nequalflights identical flights to no useful effect
END
-Bisector is flailing: $nequalflights identical flights generated.
-Perhaps machinery for building correct version is broken ?
+Bisector is flailing: =$nequalflights identical flights generated.
Problem occurs when attempting to test this revision:
$choose-{Rtuple}
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 1/6] cs-bisection-step: Refer to jobs we create just by job name
When we make a fresh build job, rather than referring to an existing
job in another flight, pass to the rest of the machinery only the job
name, not flight.job.
This means that the generated flight refers to its own jobs without
specifying the flight name. This allows the flail detector to operate
properly: without this, we might have repeated attempts to test and
build the same thing, but they would look identical because their
self-referential runvars would be different due to their different
flight numbers.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
cs-bisection-step |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cs-bisection-step b/cs-bisection-step
index 99dbcf2..e8b95ca 100755
--- a/cs-bisection-step
+++ b/cs-bisection-step
@@ -1152,7 +1152,7 @@ END
)
END
-$usejob= $popflight.$popjob;
+$usejob= $popjob;
$jobs_created{$popjob}= $usejob;
}
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 3/6] cs-bisection-step: Flail detection: look only at our blessing
When looking for identical previously flights, consider only ones
which have the same blessing as our prospective flight will have.
There are good reasons why apparently identical flights might appear
with other in-scope blessings: notably, a single-test-job main branch
might produce many failures from its push gate, which would all have
the main branch blessing (rather than the bisector's blessing).
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
cs-bisection-step |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/cs-bisection-step b/cs-bisection-step
index 4891e93..3035912 100755
--- a/cs-bisection-step
+++ b/cs-bisection-step
@@ -1230,7 +1230,10 @@ END
# one side is NULL (runvar was missing) it still counts.
my $equalflightsqt = END;
SELECT flight, blessing, started FROM flights
- WHERE branch=? AND $blessingscond $maxflight_cond
+ WHERE branch=? $maxflight_cond
+ AND blessing = (
+ SELECT intended FROM flights WHERE flight = ?
+)
AND NOT EXISTS (
SELECT 1
FROM $runvarsqt1 r1 FULL OUTER JOIN
@@ -1260,7 +1263,7 @@ END
$minflight //= 0;
print DEBUG minflight=$minflight\n;
- $equalflightsq-execute($branch, $popflight, $minflight);
+ $equalflightsq-execute($branch, $popflight, $popflight, $minflight);
my $nequalflights = 0;
my $explanation = '';
while (my $identical = $equalflightsq-fetchrow_hashref()) {
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 6/6] Revert cs-bisection-step: allow -bisect blessed flights for basis pass
If the bisector is allowed to consider its own output flights as
candidates for the basis pass, then it will (generally) restart with a
new basis each time it finds a pass.
This is very slow and wasteful.
There is not much explanation in 01edca47 of the change I am now
reverting, but I think I probably created by some semi-manual process
a flight to serve as the basis. I now think that my mistake was to
bless that flight `adhoc-bisect' or some such, rather than `adhoc'.
This reverts commit 01edca47be3742a1660b1956c1f06ca934b97352.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
cs-bisection-step |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cs-bisection-step b/cs-bisection-step
index da13927..67a92b7 100755
--- a/cs-bisection-step
+++ b/cs-bisection-step
@@ -320,7 +320,7 @@ END
SELECT * FROM flights JOIN steps USING (flight)
WHERE job = ?
AND testid = ?
-AND $blessingscond
+AND blessing = ?
AND status = 'pass'
AND branch = ?
AND $flight_is_not_broken
@@ -371,7 +371,7 @@ END
print STDERR /;
my ($basisrow,$trybasis);
-$basisq-execute($job,$testid,$branch);
+$basisq-execute($job,$testid,$blessings[0],$branch);
while ($trybasis= $basisq-fetchrow_hashref()) {
print STDERR $trybasis-{flight};
my $basishosts= relevant_hosts($trybasis-{flight});
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 0/6] Bisector fixes
This series seems to me to fix some problems with the bisector that Ian C observed and which he and I have discussed in person. I have done various ad-hoc tests in the Cambridge instance, but the bisector itself is not tested by the osstest self-push-gate, and it is of course difficult to foresee all the implications. So after this goes in we should keep an eye on the progress of the bisector in the various branches. Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 4/6] Revert cs-bisection-step: Abandon repro attempts after a bit
This safety catch is unnecessary and unhelpful.
It is unnecessary because 489773b4 Detect flailing will detect
attempts by the bisector to repeatedly run the same flight and hope
for different results.
It is unhelpful because it can happen for good reasons that a
particular revision has been tested many times. In particular:
- The osstest push gate input tree may have not been advanced for a
long time and been failing its push gate.
- The bisector may have (for some reason[1]) restarted with a new
baseline, and the temporarally-stripy pass/fail requirement would
then require the basis fail to be repro'd, again.
[1] Currently this happens much more often than is desirable. This
will be fixed in a moment.
This reverts commit 2676277181599a889657354028b992379aa6142b.
---
cs-bisection-step |4
1 file changed, 4 deletions(-)
diff --git a/cs-bisection-step b/cs-bisection-step
index 3035912..743a3e5 100755
--- a/cs-bisection-step
+++ b/cs-bisection-step
@@ -769,10 +769,6 @@ sub need_repro ($$$) {
return 1 if conflicted_warning($n, $what);
my $fl= $n-{Flights} || [];
-
-return report_conflict($n, $what, 'Too many attempts')
- if @$fl 5;
-
foreach my $f (sort { $a-{Flight} = $b-{Flight} } @$fl) {
next unless $f-{Flight} $repro_lastflight;
if ($f-{Result} ne $st) {
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] tools/libx: Don't export libxl__arch_* to the library
From: Julien Grall julien.gr...@linaro.org libxl__arch_* should only be used internally by libxl. Signed-off-by: Julien Grall julien.gr...@linaro.org --- tools/libxl/libxl_arch.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h index 77b1f2a..d04871c 100644 --- a/tools/libxl/libxl_arch.h +++ b/tools/libxl/libxl_arch.h @@ -16,31 +16,37 @@ #define LIBXL_ARCH_H /* fill the arch specific configuration for the domain */ +_hidden int libxl__arch_domain_prepare_config(libxl__gc *gc, libxl_domain_config *d_config, xc_domain_configuration_t *xc_config); /* arch specific internal domain creation function */ +_hidden int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config, uint32_t domid); /* setup arch specific hardware description, i.e. DTB on ARM */ +_hidden int libxl__arch_domain_init_hw_description(libxl__gc *gc, libxl_domain_build_info *info, libxl__domain_build_state *state, struct xc_dom_image *dom); /* finalize arch specific hardware description. */ +_hidden int libxl__arch_domain_finalise_hw_description(libxl__gc *gc, libxl_domain_build_info *info, struct xc_dom_image *dom); /* build vNUMA vmemrange with arch specific information */ +_hidden int libxl__arch_vnuma_build_vmemrange(libxl__gc *gc, uint32_t domid, libxl_domain_build_info *b_info, libxl__domain_build_state *state); /* arch specific irq map function */ +_hidden int libxl__arch_domain_map_irq(libxl__gc *gc, uint32_t domid, int irq); #endif -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 3/6] cs-bisection-step: Flail detection: look only at our blessing
On Wed, 2015-05-20 at 13:54 +0100, Ian Jackson wrote: When looking for identical previously flights, consider only ones which have the same blessing as our prospective flight will have. There are good reasons why apparently identical flights might appear with other in-scope blessings: notably, a single-test-job main branch might produce many failures from its push gate, which would all have the main branch blessing (rather than the bisector's blessing). Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 5/6] cs-bisection-step: Do not treat repro attempts as flail
On Wed, 2015-05-20 at 13:54 +0100, Ian Jackson wrote: The need_repro machinery deliberarely makes attempts to reproduce various results. This can cause the flail detector to trigger when not intended. In particular, the bisector may have (for some reason[1]) restarted with a new baseline, and the temporarally-stripy pass/fail requirement would then require the basis fail to be repro'd, again. [1] Currently this happens much more often than is desirable. This will be fixed in a moment. Fix this by only considering, for the purposes of flail, flights which are no older than the first repro (the basis pass). Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/public: Clarify xen_arch_domainconfig ABI statement
This structure is used by XEN_DOMCTL_createdomain, and is liable to be
modified going forwards. Explicitly state that it falls under the
XEN_DOMCTL_INTERFACE_VERSION.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Keir Fraser k...@xen.org
CC: Jan Beulich jbeul...@suse.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Stefano Stabellini stefano.stabell...@citrix.com
CC: Tim Deegan t...@xen.org
CC: Julien Grall julien.gr...@citrix.com
CC: Don Slutz dsl...@verizon.com
---
xen/include/public/arch-arm.h |4
xen/include/public/arch-x86/xen.h |4
2 files changed, 8 insertions(+)
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index c029e0f..6e38638 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -309,6 +309,10 @@ struct arch_shared_info {
typedef struct arch_shared_info arch_shared_info_t;
typedef uint64_t xen_callback_t;
+/*
+ * struct xen_arch_domainconfig's ABI is covered by the
+ * XEN_DOMCTL_INTERFACE_VERSION.
+ */
#define XEN_DOMCTL_CONFIG_GIC_DEFAULT 0
#define XEN_DOMCTL_CONFIG_GIC_V21
#define XEN_DOMCTL_CONFIG_GIC_V32
diff --git a/xen/include/public/arch-x86/xen.h
b/xen/include/public/arch-x86/xen.h
index cea3fe7..b4ba233 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -262,6 +262,10 @@ struct arch_shared_info {
};
typedef struct arch_shared_info arch_shared_info_t;
+/*
+ * struct xen_arch_domainconfig's ABI is covered by the
+ * XEN_DOMCTL_INTERFACE_VERSION.
+ */
struct xen_arch_domainconfig {
char dummy;
};
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [Y2038] [PATCH v2] xen/pcifront: Remove usage of struct timeval
On Tuesday 19 May 2015 11:38:09 Tina Ruchandani wrote: struct timeval uses a 32-bit field for representing seconds, which will overflow in the year 2038 and beyond. This patch replaces struct timeval with 64-bit ktime_t which is 2038 safe. The patch is part of a larger effort to remove instances of 32-bit timekeeping variables (timeval, time_t and timespec) from the kernel. Signed-off-by: Tina Ruchandani ruchandani.t...@gmail.com Suggested-by: Arnd Bergmann a...@arndb.de Reviewed-by: Arnd Bergmann a...@arndb.de ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Slective IRQ trapping.
Thanks for the feedback. I will arrange to respect the community etiquette as I will write frequently to the list in the upcoming period :). Best wishes. From: Ian Campbell ian.campb...@citrix.com Sent: Wednesday, May 20, 2015 3:46 PM To: Mazen Ezzeddine (Student) Cc: xen-de...@lists.xenproject.org Subject: Re: [Xen-devel] Slective IRQ trapping. On Wed, 2015-05-20 at 12:31 +, Mazen Ezzeddine (Student) wrote: Thanks Ian. I have already taken a look at Asking Developer Questions (upon registration) and have reread after you email . But I can not see what's the issue? is that my question not not understandable or ...? You've posted a several questions to the list over the last day with little indication that you have considered many of the points on that wiki page, e.g. reading the (hardware) docs, using tools to search the source code, doing web searches etc. You've not given any background to what you are trying to actual do as recommended. You haven't followed the nettiquette guide. Ian. Thank you so much and best regards. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [edk2] 答复: Windows 2008 r2 smp guest booting hang with viridian=true on ovmf(xen latest version 4.5.1-rc1 + latest edk2)
On 05/20/15 09:24, Fanhenglong wrote:
Can anyone have idea about how to boot window 2008 r2 smp guest in ovmf
with viridian flag is true?
I had to confirm first that viridian means Hyper-V,
http://en.wikipedia.org/wiki/Hyper-V:
Hyper-V, codenamed Viridian, ...
With that out of the way, I can refer you to
https://bugzilla.redhat.com/show_bug.cgi?id=1185253
Short version: don't set the viridian flag; the guest you're trying to
run like that was never meant to be run on Hyper-V.
Thanks
Laszlo
*发件人:*Fanhenglong
*发送时间:*2015年5月19日23:22
*收件人:*xen-devel@lists.xen.org
*抄送:*'k...@xen.org'; 'paul.durr...@citrix.com'; 'jbeul...@suse.com';
edk2-de...@lists.sourceforge.net; Hanweidong (Randy); Liuqiming (John);
Liuqiming (John)
*主题:*Windows 2008 r2 smp guest booting hang with viridian=true on
ovmf(xen latest version 4.5.1-rc1 + latest edk2)
Hi all,
I have test win2008 r2 guest on ovmf with xen latest version + edk2 latest
Xen : 4.5.1-rc1
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=0c4e0ef608c98abef6220b0b027d9ce8ec65fd5f
Edk2 : e2ab3f819f4e8165c24bd6f4fdc24ef17bdf458b (date:2015/5/18)
and come across a problem:
when the viridian flag is true,win2008 r2 guest can boot success with
unique processor, but will hang with smp processor on ovmf;
the viridian flag is false, win2008 r2 guest can boot success both in
unique and smp processor on ovmf;
if win2008 r2 with viridian=faulse, it may bring 0x101 bluescreen
http://old-list-archives.xenproject.org/archives/html/xen-users/2009-07/msg00661.html
I try to resolve the problem,
I also run the same testcase on kvm and vmvare ,vm also have the same
question, vmare is ok;
so I print the cupid function return value in vmvare guest os,
the below table show the detailed information in vmvare guest os,
get cpu id 0 : 000b 756e6547 6c65746e 49656e69
get cpu id 1 : 000106a5 00010800 80982201 0fabfbff
get cpu id 2 : 55035a01 00f0b2e4 09ca212c
get cpu id 3 :
get cpu id 4 :
get cpu id 5 :
get cpu id 4000 : 4010 61774d56 4d566572 65726177
get cpu id 4001 :
get cpu id 4002 :
get cpu id 4003 :
get cpu id 4004 :
get cpu id 4005 :
get cpu id 4006 :
get cpu id 4070 : 00ac 0012
get cpu id 4071 : 00ac 0012
get cpu id 4072 : 00ac 0012
get cpu id 4073 : 00ac 0012
get cpu id 4100 : 00ac
get cpu id 4101 : 00ac
get cpu id 4102 : 00ac
get cpu id 4103 : 00ac
get cpu id 4104 : 00ac
get cpu id 4105 : 00ac
get cpu id 4106 : 00ac
get cpu id 8000 : 8008
get cpu id 8001 : 0001 2810
get cpu id 8002 : 65746e49 2952286c 6f655820 2952286e
get cpu id 8003 : 55504320 20202020 20202020 45202020
get cpu id 8004 : 30323535 20402020 37322e32 007a4847
get cpu id 8005 :
get cpu id 8006 : 01006040
get cpu id 8007 : 0100
get cpu id 8008 : 3028
get cpu id 8009 : 00ac
I modified cpuid_viridian_leaves function in
xen/arch/x86/hvm/viridian.c (as the following red bold code)
to return value 0 for cupid (function=4001), and win2008 r2 smp
guest can boot success on ovmf;
int cpuid_viridian_leaves(unsigned int leaf, unsigned int *eax,
unsigned int *ebx, unsigned int *ecx,
unsigned int *edx)
{
struct domain *d = current-domain;
if ( !is_viridian_domain(d) )
return 0;
leaf -= 0x4000;
if ( leaf 6 )
return 0;
*eax = *ebx = *ecx = *edx = 0;
switch ( leaf )
{
case 0:
*eax = 0x4006; /* Maximum leaf */
*ebx = 0x7263694d; /* Magic numbers */
*ecx = 0x666F736F;
*edx = 0x76482074;
break;
case 1:
//original code **eax = 0x31237648; /* Version number */*
* *eax = 0; //code after modified*
break;
based on hyperv spec, Microsoft Hypervisor CPUID Leaves,
0x4001
Re: [Xen-devel] [OSSTEST PATCH 6/6] Revert cs-bisection-step: allow -bisect blessed flights for basis pass
On Wed, 2015-05-20 at 13:54 +0100, Ian Jackson wrote: If the bisector is allowed to consider its own output flights as candidates for the basis pass, then it will (generally) restart with a new basis each time it finds a pass. This is very slow and wasteful. There is not much explanation in 01edca47 of the change I am now reverting, but I think I probably created by some semi-manual process a flight to serve as the basis. I now think that my mistake was to bless that flight `adhoc-bisect' or some such, rather than `adhoc'. This reverts commit 01edca47be3742a1660b1956c1f06ca934b97352. Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v10 3/9] Refactor installation of overlays
On Wed, 2015-05-13 at 11:36 +0800, longtao.pang wrote: Apply overlay to guests as well as hosts by moving to preseed_base. We do this because we want to be able to: * Use '/etc/init.d/osstest-confirm-booted' for guests as well as hosts (in particular when testing nestedhvm we sometimes want to treat a guest as a host). * Use grub's 20_linux_xen which is harmless unless Xen is installed in the guest which is the case only for nestedhvm testing when we want these changes. The other things in the overlay are some initscripts (xenbridge and xenlightdaemons) which are not enabled for guests and hence are therefore harmless. Signed-off-by: longtao.pang longtaox.p...@intel.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Slective IRQ trapping.
On Wed, 2015-05-20 at 12:31 +, Mazen Ezzeddine (Student) wrote: Thanks Ian. I have already taken a look at Asking Developer Questions (upon registration) and have reread after you email . But I can not see what's the issue? is that my question not not understandable or ...? You've posted a several questions to the list over the last day with little indication that you have considered many of the points on that wiki page, e.g. reading the (hardware) docs, using tools to search the source code, doing web searches etc. You've not given any background to what you are trying to actual do as recommended. You haven't followed the nettiquette guide. Ian. Thank you so much and best regards. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 2/6] cs-bisection-step: Clarify and correct flailing message
On Wed, 2015-05-20 at 13:54 +0100, Ian Jackson wrote: There are many other possible reasons for this, besides a bug in the build version machinery. Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 1/6] cs-bisection-step: Refer to jobs we create just by job name
On Wed, 2015-05-20 at 13:54 +0100, Ian Jackson wrote: When we make a fresh build job, rather than referring to an existing job in another flight, pass to the rest of the machinery only the job name, not flight.job. This means that the generated flight refers to its own jobs without specifying the flight name. This allows the flail detector to operate properly: without this, we might have repeated attempts to test and build the same thing, but they would look identical because their self-referential runvars would be different due to their different flight numbers. Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] tools/configure: Missing [ in the aio check
There was a missing [ in the aio check which lead to never check if aio is present on the platform. Signed-off-by: Julien Grall julien.gr...@citrix.com --- tools/configure needs to be regenerate before pushing this patch. --- tools/configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/configure.ac b/tools/configure.ac index d31c2f3..a24f23a 100644 --- a/tools/configure.ac +++ b/tools/configure.ac @@ -335,7 +335,7 @@ AC_CHECK_HEADER([lzo/lzo1x.h], [ AC_CHECK_LIB([lzo2], [lzo1x_decompress], [zlib=$zlib -DHAVE_LZO1X -llzo2]) ]) AC_SUBST(zlib) -AS_IF(test x$enable_blktap2 = xyes], [ +AS_IF([test x$enable_blktap2 = xyes], [ AC_CHECK_LIB([aio], [io_setup], [], [AC_MSG_ERROR([Could not find libaio])]) ]) AC_SUBST(system_aio) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 2/2] xen/block: add multi-page ring support
Extend xen/block to support multi-page ring, so that more requests can be issued
by using more than one pages as the request ring between blkfront and backend.
As a result, the performance can get improved significantly.
We got some impressive improvements on our highend iscsi storage cluster
backend.
If using 64 pages as the ring, the IOPS increased about 15 times for the
throughput testing and above doubled for the latency testing.
The reason was the limit on outstanding requests is 32 if use only one-page
ring, but in our case the iscsi lun was spread across about 100 physical drives,
32 was really not enough to keep them busy.
Changes in v2:
- Rebased to 4.0-rc6.
- Document on how mutli-page ring feature working to linux io/blkif.h.
Changes in v3:
- Remove changes to linux io/blkif.h and follow the protocol defined
in io/blkif.h of XEN tree.
- Rebased to 4.1-rc3
Changes in v4:
- Turn to use 'ring-page-order' and 'max-ring-page-order'.
- A few comments from Roger.
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/block/xen-blkback/blkback.c | 12
drivers/block/xen-blkback/common.h | 3 +-
drivers/block/xen-blkback/xenbus.c | 85 +---
drivers/block/xen-blkfront.c| 110 ++--
4 files changed, 161 insertions(+), 49 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
b/drivers/block/xen-blkback/blkback.c
index 713fc9f..057890f 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -84,6 +84,12 @@ MODULE_PARM_DESC(max_persistent_grants,
Maximum number of grants to map persistently);
/*
+ * Maximum number of pages to be used as the ring between front and backend
+ */
+unsigned int xen_blkif_max_ring_order = XENBUS_MAX_RING_PAGE_ORDER;
+module_param_named(max_ring_page_order, xen_blkif_max_ring_order, int,
S_IRUGO);
+MODULE_PARM_DESC(max_ring_page_order, Maximum order of pages to be used as
the ring);
+/*
* The LRU mechanism to clean the lists of persistent grants needs to
* be executed periodically. The time interval between consecutive executions
* of the purge mechanism is set in ms.
@@ -1435,6 +1441,12 @@ static int __init xen_blkif_init(void)
{
int rc = 0;
+ if (xen_blkif_max_ring_order XENBUS_MAX_RING_PAGE_ORDER) {
+ pr_info(Invalid max_ring_order (%d), will use default max:
%d.\n,
+ xen_blkif_max_ring_order, XENBUS_MAX_RING_PAGE_ORDER);
+ xen_blkif_max_ring_order = XENBUS_MAX_RING_PAGE_ORDER;
+ }
+
if (!xen_domain())
return -ENODEV;
diff --git a/drivers/block/xen-blkback/common.h
b/drivers/block/xen-blkback/common.h
index f620b5d..edc0992 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -44,6 +44,7 @@
#include xen/interface/io/blkif.h
#include xen/interface/io/protocols.h
+extern unsigned int xen_blkif_max_ring_order;
/*
* This is the maximum number of segments that would be allowed in indirect
* requests. This value will also be passed to the frontend.
@@ -248,7 +249,7 @@ struct backend_info;
#define PERSISTENT_GNT_WAS_ACTIVE 1
/* Number of requests that we can fit in a ring */
-#define XEN_BLKIF_REQS 32
+#define XEN_BLKIF_REQS (32 * XENBUS_MAX_RING_PAGES)
struct persistent_gnt {
struct page *page;
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkback/xenbus.c
index 6ab69ad..1ec05eb 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -25,6 +25,7 @@
/* Enlarge the array size in order to fully show blkback name. */
#define BLKBACK_NAME_LEN (20)
+#define RINGREF_NAME_LEN (20)
struct backend_info {
struct xenbus_device*dev;
@@ -198,8 +199,8 @@ fail:
return ERR_PTR(-ENOMEM);
}
-static int xen_blkif_map(struct xen_blkif *blkif, grant_ref_t gref,
-unsigned int evtchn)
+static int xen_blkif_map(struct xen_blkif *blkif, grant_ref_t *gref,
+unsigned int nr_grefs, unsigned int evtchn)
{
int err;
@@ -207,7 +208,7 @@ static int xen_blkif_map(struct xen_blkif *blkif,
grant_ref_t gref,
if (blkif-irq)
return 0;
- err = xenbus_map_ring_valloc(blkif-be-dev, gref, 1,
+ err = xenbus_map_ring_valloc(blkif-be-dev, gref, nr_grefs,
blkif-blk_ring);
if (err 0)
return err;
@@ -217,21 +218,21 @@ static int xen_blkif_map(struct xen_blkif *blkif,
grant_ref_t gref,
{
struct blkif_sring *sring;
sring = (struct blkif_sring *)blkif-blk_ring;
- BACK_RING_INIT(blkif-blk_rings.native, sring, PAGE_SIZE);
+ BACK_RING_INIT(blkif-blk_rings.native, sring, PAGE_SIZE *
nr_grefs);
break;
}
case BLKIF_PROTOCOL_X86_32:
[Xen-devel] [PATCH v2 1/2] driver: xen-blkfront: move talk_to_blkback to a more suitable place
The major responsibility of talk_to_blkback() is allocate and initialize the
request ring and writes the ring info stuff out.
But this work should be done after backend entered 'XenbusStateInitWait' as
defined in the protocol file.
See xen/include/public/io/blkif.h in XEN git tree:
FrontBack
==
XenbusStateInitialising XenbusStateInitialising
o Query virtual device o Query backend device identification
properties. data.
o Setup OS device instance. o Open and validate backend device.
o Publish backend features and
transport parameters.
|
|
V
XenbusStateInitWait
o Query backend features and
transport parameters.
o Allocate and initialize the
request ring.
There is no problem with this yet, but it is an violation of the design and
furthermore it would not allow frontend/backend to negotiate 'multi-page' and
'multi-queue' features.
Changes in v2:
- Re-write the commit message to be more clear.
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/block/xen-blkfront.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2c61cf8..88e23fd 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1430,13 +1430,6 @@ static int blkfront_probe(struct xenbus_device *dev,
info-handle = simple_strtoul(strrchr(dev-nodename, '/')+1, NULL, 0);
dev_set_drvdata(dev-dev, info);
- err = talk_to_blkback(dev, info);
- if (err) {
- kfree(info);
- dev_set_drvdata(dev-dev, NULL);
- return err;
- }
-
return 0;
}
@@ -1906,8 +1899,13 @@ static void blkback_changed(struct xenbus_device *dev,
dev_dbg(dev-dev, blkfront:blkback_changed to state %d.\n,
backend_state);
switch (backend_state) {
- case XenbusStateInitialising:
case XenbusStateInitWait:
+ if (talk_to_blkback(dev, info)) {
+ kfree(info);
+ dev_set_drvdata(dev-dev, NULL);
+ break;
+ }
+ case XenbusStateInitialising:
case XenbusStateInitialised:
case XenbusStateReconfiguring:
case XenbusStateReconfigured:
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen/pcifront: Remove usage of struct timeval
On Tue, May 19, 2015 at 1:08 AM, Tina Ruchandani
ruchandani.t...@gmail.com wrote:
struct timeval uses a 32-bit field for representing seconds,
which will overflow in the year 2038 and beyond. This patch replaces
struct timeval with 64-bit ktime_t which is 2038 safe.
The patch is part of a larger effort to remove instances of
32-bit timekeeping variables (timeval, time_t and timespec)
from the kernel.
Signed-off-by: Tina Ruchandani ruchandani.t...@gmail.com
Suggested-by: Arnd Bergmann a...@arndb.de
Acked-by: Bjorn Helgaas bhelg...@google.com
This isn't PCI-related, so I expect Konrad, Boris, or David will merge this.
--
Changes in v2:
- Use monotonic time (ktime_get_ns()) instead of real time
since we only care about elapsed delta here.
- Use macro ktime_get_ns() instead of getting ktime_t and
converting it to ns.
---
drivers/pci/xen-pcifront.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 7cfd2db..c4796c8 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -20,6 +20,7 @@
#include linux/workqueue.h
#include linux/bitops.h
#include linux/time.h
+#include linux/ktime.h
#include xen/platform_pci.h
#include asm/xen/swiotlb-xen.h
@@ -115,7 +116,6 @@ static int do_pci_op(struct pcifront_device *pdev, struct
xen_pci_op *op)
evtchn_port_t port = pdev-evtchn;
unsigned irq = pdev-irq;
s64 ns, ns_timeout;
- struct timeval tv;
spin_lock_irqsave(pdev-sh_info_lock, irq_flags);
@@ -132,8 +132,7 @@ static int do_pci_op(struct pcifront_device *pdev, struct
xen_pci_op *op)
* (in the latter case we end up continually re-executing poll() with
a
* timeout in the past). 1s difference gives plenty of slack for
error.
*/
- do_gettimeofday(tv);
- ns_timeout = timeval_to_ns(tv) + 2 * (s64)NSEC_PER_SEC;
+ ns_timeout = ktime_get_ns() + 2 * (s64)NSEC_PER_SEC;
xen_clear_irq_pending(irq);
@@ -141,8 +140,7 @@ static int do_pci_op(struct pcifront_device *pdev, struct
xen_pci_op *op)
(unsigned long *)pdev-sh_info-flags)) {
xen_poll_irq_timeout(irq, jiffies + 3*HZ);
xen_clear_irq_pending(irq);
- do_gettimeofday(tv);
- ns = timeval_to_ns(tv);
+ ns = ktime_get_ns();
if (ns ns_timeout) {
dev_err(pdev-xdev-dev,
pciback not responding!!!\n);
--
2.2.0.rc0.207.ga3a616c
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/4] x86: move syscall trampolines off the stack
On 19.05.15 at 18:59, andrew.coop...@citrix.com wrote:
On 18/05/15 13:46, Jan Beulich wrote:
@@ -616,6 +653,24 @@ static void cpu_smpboot_free(unsigned in
free_cpumask_var(per_cpu(cpu_sibling_mask, cpu));
free_cpumask_var(per_cpu(cpu_core_mask, cpu));
+if ( per_cpu(stubs.addr, cpu) )
+{
+unsigned long mfn = per_cpu(stubs.mfn, cpu);
+unsigned char *stub_page = map_domain_page(mfn);
+unsigned int i;
+
+memset(stub_page + (cpu (STUBS_PER_PAGE - 1)) * STUB_BUF_SIZE,
+ 0xcc, STUB_BUF_SIZE);
+for ( i = 0; i STUBS_PER_PAGE; ++i )
+if ( stub_page[i * STUB_BUF_SIZE] != 0xcc)
+break;
There is a race condition between allocate and free, as
write_stub_trampoline() is written by the cpu itself. Just finding 0xcc
here doesn't mean there isn't a different cpu in the process of coming
up and intending to use the stub page.
No, there is no race afaict: percpu_traps_init() gets called before
a CPU is marked online and hence before __cpu_up() returns, and
thus before the CPU hotplug lock gets dropped, so there can't be
any CPUs going down concurrently.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] x86: move I/O emulation stubs off the stack
On 19.05.15 at 19:48, andrew.coop...@citrix.com wrote: On 18/05/15 13:47, Jan Beulich wrote: @@ -2212,7 +2215,7 @@ static int emulate_privileged_op(struct io_emul_stub[15] = 0xc3; /* Handy function-typed pointer to the stub. */ -io_emul = (void *)io_emul_stub; +io_emul = (void *)(this_cpu(stubs.addr) + STUB_BUF_SIZE / 2); As an unrelated observation during review, the two gpr switch functions should probably gain some knowledge of TRAP_regs_partial You mean adding a respective assertion? This code shouldn't otherwise need to know of that flag, as execution must not make it here with a partial frame. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/public: Clarify xen_arch_domainconfig ABI statement
On 05/20/15 09:10, Andrew Cooper wrote:
This structure is used by XEN_DOMCTL_createdomain, and is liable to be
modified going forwards. Explicitly state that it falls under the
XEN_DOMCTL_INTERFACE_VERSION.
Looks good to me.
Reviewed-by: Don Slutz dsl...@verizon.com
-Don Slutz
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Keir Fraser k...@xen.org
CC: Jan Beulich jbeul...@suse.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Stefano Stabellini stefano.stabell...@citrix.com
CC: Tim Deegan t...@xen.org
CC: Julien Grall julien.gr...@citrix.com
CC: Don Slutz dsl...@verizon.com
---
xen/include/public/arch-arm.h |4
xen/include/public/arch-x86/xen.h |4
2 files changed, 8 insertions(+)
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index c029e0f..6e38638 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -309,6 +309,10 @@ struct arch_shared_info {
typedef struct arch_shared_info arch_shared_info_t;
typedef uint64_t xen_callback_t;
+/*
+ * struct xen_arch_domainconfig's ABI is covered by the
+ * XEN_DOMCTL_INTERFACE_VERSION.
+ */
#define XEN_DOMCTL_CONFIG_GIC_DEFAULT 0
#define XEN_DOMCTL_CONFIG_GIC_V21
#define XEN_DOMCTL_CONFIG_GIC_V32
diff --git a/xen/include/public/arch-x86/xen.h
b/xen/include/public/arch-x86/xen.h
index cea3fe7..b4ba233 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -262,6 +262,10 @@ struct arch_shared_info {
};
typedef struct arch_shared_info arch_shared_info_t;
+/*
+ * struct xen_arch_domainconfig's ABI is covered by the
+ * XEN_DOMCTL_INTERFACE_VERSION.
+ */
struct xen_arch_domainconfig {
char dummy;
};
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] xen/arm: On chip memory mappings
On 20/05/15 14:40, Edgar E. Iglesias wrote: Thanks for the pointers, I agree that fundamental differences like these beteween v7 and v8 wouldn't be good. I didn't find any fundamental differences for device memory behavior in the spec. Possible unpredictable behaviour is worrysome... I'm not aware of anything in the ARM architecture specs that would cause it in this respect, but I may be missing something. AFAICT there is nothing in the spec which describe the behavior of a region access with wrong memory attribute (i.e normal, device, strong). I guess this would be described in the memory bus or processor spec. There might also very well be device/slave specific unpredictability. E.g unpredictable behaviour on specific AXI access patterns (bursts, sizes etc) to specific devices... On the other hand, I suppose giving direct device access to a guest carries some kind of trust to behave nicely with the device. The trust to the device is very limited. We got several Xen Security Advisory ([1] [2] ...) related to PCI passthrough. I agree that the guest may act badly with the device, although we don't want to give him the opportunity to act more badly with a device and the possibility to access another guest memory. I'm not sure I understand Christoffers arguments though. It's not clear what is the behavior of a device memory mapped with normal attribute. Many issue can appear. Unless the behavior is clearly written in the spec, we should take the worst case and not the best. A well behaved guest will map it's devices as DEVICE and there won't be any difference at all wether S2 maps them as dev or mem. Agree. A malicious guest could map things as cached memory and try to cause cached accesses from other guests to flush out. But these cached accesses would only contain data for other guests mapped as cacheable memory. AFAICT, to really hurt another guest, the guest under attack has to participate in the plot (by incorrectly mapping it's own devs as mem). Why not RAM? Anyway, at the moment it seems like doing a device-tree compatiblity prop match for mmio-sram would be the path with least resistance... I think this is a good solution until we figure out the behavior of device memory mapped with wrong attribute. Regards, [1] http://xenbits.xen.org/xsa/advisory-124.html [2] http://xenbits.xen.org/xsa/advisory-126.html -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands
On Mon, Apr 20, 2015 at 9:12 AM, Juergen Gross jgr...@suse.com wrote: On 04/19/2015 05:50 AM, Chunyan Liu wrote: Add pvusb commands: usb-ctrl-attach, usb-ctrl-detach, usb-list, usb-attach and usb-detach. To attach a usb device to guest through pvusb, one could follow following example: #xl usb-ctrl-attach test_vm version=1 num_ports=8 #xl usb-list test_vm will show the usb controllers and port usage under the domain. #xl usb-attach test_vm 1.6 will find the first usable controller:port, and attach usb device whose bus address is 1.6 (busnum is 1, devnum is 6) to it. One could also specify which controller and which port. #xl usb-detach test_vm 1.6 #xl usb-ctrl-detach test_vm dev_id will destroy the controller with specified dev_id. Dev_id can be traced in usb-list info. Signed-off-by: Chunyan Liu cy...@suse.com Signed-off-by: Simon Cao caobosi...@gmail.com --- Changes to v2: * use bus.addr as user interface instead of busid in usb-attach|detach * remove usb-assignable-list interface Why? While lsusb in combination with xl usb-list for each domain will give the same information, having to iterate through all domains can be quite annoying. An alternative would be to accept omitting the domain for xl usb-list and list all domains with assigned usb devices in this case. I don't understand what information it is that you want. Do you want a list of devices *not already assigned* to domains? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen/arm: On chip memory mappings
On Tue, May 19, 2015 at 10:23:05AM +0100, Julien Grall wrote: On 19/05/2015 10:09, Ian Campbell wrote: On Tue, 2015-05-19 at 15:16 +1000, Edgar E. Iglesias wrote: Hi, Hi, The rules for combining the memory attributes from S1 and S2 translations suggest that mapping things at S2 with Normal memory Inner/Outer WB cacheable would give the guest/S1 flexibility in choosing the final attributes. It seems to me like guest drivers have the best knowledge to decide how to map the node memory regions. Keeping the S2 shareability set to inner (like we already do for memory) seems to be a good idea though. So the question I had is, why do we map nodes at S2 with DEVICE attributes at all? Am I missing something? I think the concern was exposing potentially UNPREDICTABLE / IMPLEMENTATION DEFINED etc behaviour via a guest which maps MMIO regions as normal memory in S1. By using a device memory mapping in S2 we force a safe overall result. I've not refreshed my memory on the way round this goes though, perhaps the worry is/was unfounded. In particular perhaps on v8 this ends up as CONSTRAINED UNPREDICTABLE which might be safe enough (again, I've not checked). I'd rather not have v7 and v8 differ in such a fundamental default, but it might be justified I suppose. Likewise for e.g. doing something different for dom0/hw-dom vs. others. I remember a similar discussion with Christoffer few months ago (it was for ACPI). And the answer was: No, real access to MMIO regions of devices must be mapped as device type in stage-2 if you don't want potential information leaks or weird things to happen where a guest can tweak and time memory operations such that they happen in a different context than the VM executing the memory access. You can argue that the latter is not necessary for Dom0 as Xen trusts Dom0 completely, but I would still argue that it is the right approach to take proper care of it, thus; Regards, Thanks for the pointers, I agree that fundamental differences like these beteween v7 and v8 wouldn't be good. Possible unpredictable behaviour is worrysome... I'm not aware of anything in the ARM architecture specs that would cause it in this respect, but I may be missing something. There might also very well be device/slave specific unpredictability. E.g unpredictable behaviour on specific AXI access patterns (bursts, sizes etc) to specific devices... On the other hand, I suppose giving direct device access to a guest carries some kind of trust to behave nicely with the device. I'm not sure I understand Christoffers arguments though. A well behaved guest will map it's devices as DEVICE and there won't be any difference at all wether S2 maps them as dev or mem. A malicious guest could map things as cached memory and try to cause cached accesses from other guests to flush out. But these cached accesses would only contain data for other guests mapped as cacheable memory. AFAICT, to really hurt another guest, the guest under attack has to participate in the plot (by incorrectly mapping it's own devs as mem). Anyway, at the moment it seems like doing a device-tree compatiblity prop match for mmio-sram would be the path with least resistance... Cheers, Edgar ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.5-testing test] 56776: regressions - FAIL
flight 56776 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/56776/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 56728 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail REGR. vs. 56728 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 56728 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 56728 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 11 guest-start fail REGR. vs. 56728 test-amd64-i386-freebsd10-amd64 13 guest-localmigrate fail like 56728 test-amd64-i386-freebsd10-i386 13 guest-localmigrate fail like 56728 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass version targeted for testing: xen ddfe333aef87e6c5f52b84c8beb3277be4663313 baseline version: xen 0c4e0ef608c98abef6220b0b027d9ce8ec65fd5f People who touched revisions under test: Eugene Korenevsky ekorenev...@gmail.com Jan Beulich jbeul...@suse.com Paul Durrant paul.durr...@citrix.com Ross Lagerwall ross.lagerw...@citrix.com Suravee Suthikulpanit suravee.suthikulpa...@amd.com jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64 fail test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 pass test-amd64-i386-xl-qemuu-win7-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 fail test-amd64-i386-rumpuserxen-i386 pass test-amd64-amd64-xl-pvh-intelfail
Re: [Xen-devel] [OSSTEST Nested PATCH v10 6/9] Changes on test step of Debian hvm guest install
On Wed, 2015-05-13 at 11:36 +0800, longtao.pang wrote:
@@ -59,7 +59,7 @@ d-i partman-auto/expert_recipe string \\
use_filesystem{ } filesystem{ vfat } \\
mountpoint{ /boot/efi } \\
. \\
-5000 50 5000 ext4 \\
+1 50 1 ext4 \\
These three numbers are
limits::=minimal size_priority_maximal size_parted fs
(from
http://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/doc/devel/partman-auto-recipe.txt)
So here you are increasing the minimum size of the root partition for
all debianhvm domains (including non-nested ones and L2 guests) from 5G
to 10G.
Did you test this with a normal L1 debianhvm guest (not one destined to
be an L1 host). i.e. using test-amd64-amd64-xl-qemuu-debianhvm-amd64 ?
The new size you have given is the same size as the entire disk in that
case. I'm not sure what will then happen...
Perhaps 5000 50 -1 ext4 does what you need, namely leaves the minimum
alone and sets the maximum to unlimited, which I think will end up
making this partition as big as the disk less the configured swap space.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/4] x86: move syscall trampolines off the stack
On 20/05/15 14:37, Jan Beulich wrote:
On 19.05.15 at 18:59, andrew.coop...@citrix.com wrote:
On 18/05/15 13:46, Jan Beulich wrote:
@@ -616,6 +653,24 @@ static void cpu_smpboot_free(unsigned in
free_cpumask_var(per_cpu(cpu_sibling_mask, cpu));
free_cpumask_var(per_cpu(cpu_core_mask, cpu));
+if ( per_cpu(stubs.addr, cpu) )
+{
+unsigned long mfn = per_cpu(stubs.mfn, cpu);
+unsigned char *stub_page = map_domain_page(mfn);
+unsigned int i;
+
+memset(stub_page + (cpu (STUBS_PER_PAGE - 1)) * STUB_BUF_SIZE,
+ 0xcc, STUB_BUF_SIZE);
+for ( i = 0; i STUBS_PER_PAGE; ++i )
+if ( stub_page[i * STUB_BUF_SIZE] != 0xcc)
+break;
There is a race condition between allocate and free, as
write_stub_trampoline() is written by the cpu itself. Just finding 0xcc
here doesn't mean there isn't a different cpu in the process of coming
up and intending to use the stub page.
No, there is no race afaict: percpu_traps_init() gets called before
a CPU is marked online and hence before __cpu_up() returns, and
thus before the CPU hotplug lock gets dropped, so there can't be
any CPUs going down concurrently.
Thinking out loud...
cpu_up/down have excusion due to the recursive spinlock used by
cpu_hotplug_begin/end.
The allocate is done by the CPU_UP_PREPARE notifier chain, and
__cpu_up() does wait until the AP has marked itself as online.
Therefore, so long as no CPU_UP_PREPARE action triggers a
CPU_UP_CANCELED or CPU_DEAD chain against the same cpu, we are safe.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/VT-x: Align segment table columns when dumping a VMCS
This makes it more succinct and easier to read. Before: (XEN) Sysenter RSP= CS:RIP=: (XEN) CS: sel=0x0008, attr=0x0c09b, limit=0x, base=0x (XEN) DS: sel=0x0010, attr=0x0c093, limit=0x, base=0x (XEN) SS: sel=0x0010, attr=0x0c093, limit=0x, base=0x (XEN) ES: sel=0x0010, attr=0x0c093, limit=0x, base=0x (XEN) FS: sel=0x, attr=0x00093, limit=0x, base=0x (XEN) GS: sel=0x, attr=0x00093, limit=0x, base=0x (XEN) GDTR: limit=0x0017, base=0x00102eb8 (XEN) LDTR: sel=0x, attr=0x00082, limit=0x, base=0x (XEN) IDTR: limit=0x, base=0x (XEN) TR: sel=0x, attr=0x0008b, limit=0x, base=0x (XEN) EFER = 0x PAT = 0x0007040600070406 After: (XEN) Sysenter RSP= CS:RIP=: (XEN)sel attr limit base (XEN) CS: 0008 0c09b (XEN) DS: 0010 0c093 (XEN) SS: 0010 0c093 (XEN) ES: 0010 0c093 (XEN) FS: 00093 (XEN) GS: 00093 (XEN) GDTR:0017 00102eb8 (XEN) LDTR: 00082 (XEN) IDTR: (XEN) TR: 0008b (XEN) EFER = 0x PAT = 0x0007040600070406 Signed-off-by: Andrew Cooper andrew.coop...@citrix.com CC: Keir Fraser k...@xen.org CC: Jan Beulich jbeul...@suse.com CC: Jun Nakajima jun.nakaj...@intel.com CC: Eddie Dong eddie.d...@intel.com CC: Kevin Tian kevin.t...@intel.com --- xen/arch/x86/hvm/vmx/vmcs.c | 21 ++--- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c index 355d1b5..877ec10 100644 --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c @@ -1639,8 +1639,7 @@ static void vmx_dump_sel(char *name, uint32_t selector) attr = vmr(selector + (GUEST_ES_AR_BYTES - GUEST_ES_SELECTOR)); limit = vmr(selector + (GUEST_ES_LIMIT - GUEST_ES_SELECTOR)); base = vmr(selector + (GUEST_ES_BASE - GUEST_ES_SELECTOR)); -printk(%s: sel=0x%04x, attr=0x%05x, limit=0x%08x, base=0x%016PRIx64\n, - name, sel, attr, limit, base); +printk(%s: %04x %05x %08x %016PRIx64\n, name, sel, attr, limit, base); } static void vmx_dump_sel2(char *name, uint32_t lim) @@ -1649,8 +1648,7 @@ static void vmx_dump_sel2(char *name, uint32_t lim) uint64_t base; limit = vmr(lim); base = vmr(lim + (GUEST_GDTR_BASE - GUEST_GDTR_LIMIT)); -printk(%s: limit=0x%08x, base=0x%016PRIx64\n, - name, limit, base); +printk(%s:%08x %016PRIx64\n, name, limit, base); } void vmcs_dump_vcpu(struct vcpu *v) @@ -1695,16 +1693,17 @@ void vmcs_dump_vcpu(struct vcpu *v) printk(Sysenter RSP=%016lx CS:RIP=%04x:%016lx\n, vmr(GUEST_SYSENTER_ESP), vmr32(GUEST_SYSENTER_CS), vmr(GUEST_SYSENTER_EIP)); -vmx_dump_sel(CS, GUEST_CS_SELECTOR); -vmx_dump_sel(DS, GUEST_DS_SELECTOR); -vmx_dump_sel(SS, GUEST_SS_SELECTOR); -vmx_dump_sel(ES, GUEST_ES_SELECTOR); -vmx_dump_sel(FS, GUEST_FS_SELECTOR); -vmx_dump_sel(GS, GUEST_GS_SELECTOR); +printk( sel attr limit base\n); +vmx_dump_sel( CS, GUEST_CS_SELECTOR); +vmx_dump_sel( DS, GUEST_DS_SELECTOR); +vmx_dump_sel( SS, GUEST_SS_SELECTOR); +vmx_dump_sel( ES, GUEST_ES_SELECTOR); +vmx_dump_sel( FS, GUEST_FS_SELECTOR); +vmx_dump_sel( GS, GUEST_GS_SELECTOR); vmx_dump_sel2(GDTR, GUEST_GDTR_LIMIT); vmx_dump_sel(LDTR, GUEST_LDTR_SELECTOR); vmx_dump_sel2(IDTR, GUEST_IDTR_LIMIT); -vmx_dump_sel(TR, GUEST_TR_SELECTOR); +vmx_dump_sel( TR, GUEST_TR_SELECTOR); if ( (vmexit_ctl (VM_EXIT_SAVE_GUEST_PAT | VM_EXIT_SAVE_GUEST_EFER)) || (vmentry_ctl (VM_ENTRY_LOAD_GUEST_PAT | VM_ENTRY_LOAD_GUEST_EFER)) ) printk(EFER = 0x%016lx PAT = 0x%016lx\n, efer, vmr(GUEST_PAT)); -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
