[Xen-devel] [ovmf test] 58156: regressions - FAIL
flight 58156 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/58156/ 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 version targeted for testing: ovmf 5d832d62165e1f27173167df74e13a2d6871815b baseline version: ovmf f1f0f0deb6e64df6b7c04ead7330afecf5537e46 People who touched revisions under test: Ma, Maurice maurice...@intel.com Mudusuru, Giri P giri.p.mudus...@intel.com Yao, Jiewen jiewen@intel.com Zachary Bobroff zacha...@ami.com Ard Biesheuvel ard.biesheu...@linaro.org Chao Zhang chao.b.zh...@intel.com Dandan Bi dandan...@intel.com David Wei david@intel.com David Wei david@intel.com Eric Dong eric.d...@intel.com Feng Tian feng.t...@intel.com Guo Dong guo.d...@intel.com Hao Wu hao.a...@intel.com Heyi Guo heyi@linaro.org Jaben Carsey jaben.car...@intel.com Jeff Fan jeff@intel.com jiaxinwu jiaxin...@intel.com Jordan Justen jordan.l.jus...@intel.com Laszlo Ersek ler...@redhat.com Liming Gao liming@intel.com Long Qin qin.l...@intel.com Ludovic Rousseau ludovic.rouss...@gmail.com Ma, Maurice maurice...@intel.com Maurice Ma maurice...@intel.com Mudusuru, Giri P giri.p.mudus...@intel.com Olivier Martin olivier.mar...@arm.com Qiu Shumin shumin@intel.com Ruiyu Ni ruiyu...@intel.com Shifei Lu shifeix.a...@intel.com Star Zeng star.z...@intel.com Tapan Shah tapands...@hp.com Yao, Jiewen jiewen@intel.com Yingke Liu yingke.d@intel.com Zachary Bobroff zacha...@ami.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-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass 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. (No revision log; it would be 1658 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 5/5] libxl: spawns two QEMUs for HVM guests
On Mon, 8 Jun 2015, Ian Jackson wrote: Stefano Stabellini writes (Re: [PATCH v2 5/5] libxl: spawns two QEMUs for HVM guests): Do you have any suggestions on how I could fix this function for the purpose of this series? I would be quite happy to leave fixing qdisk_spawn_outcome in libxl.c to you :-) Sure. TBH as I wrote earlier, the failure of starting pv QEMU is not fatal from the guest POV, so we could also leave it as is. You need to collect the result anyway to avoid potentially leaking a pending callback and tearing down a still-active ao. I think the right answer is probably to start all the qemus in parallel, and count (or otherwise record) the spawn outcomes. They are already started in parallel with this patch. Where should libxl_create.c:qdisk_spawn_outcome store the outcome? Somewhere in dcs-build_state? Who would check for that? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v2] Stubdom test case
Currently only QEMU traditional supports stubdom, so we only create test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm Note that stubdom only supports serial='pty'. Piping serial to stderr causes stubdom to exit abnormally. Signed-off-by: Wei Liu wei.l...@citrix.com --- Changes in v2: 1. Don't set stubdom runvar for every test case. 2. If enable_stubdom is not defined, use toolstack default. diff -ub (sort ../master-runvars) (sort ../stubdom-runvars) | sed 's/[ \t]*$//' | egrep '^[\+|-]' --- /dev/fd/63 2015-06-08 18:14:40.700792651 +0100 +++ /dev/fd/62 2015-06-08 18:14:40.700792651 +0100 +xen-unstable test-amd64-amd64-xl-qemut-debianhvm-amd64 enable_stubdom false +xen-unstable test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm enable_stubdom false +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64 all_hostflags arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test,hvm +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64 archamd64 +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64 biosrombios +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64 buildjobbuild-amd64 +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64 debianhvm_image debian-7.2.0-amd64-CD-1.iso +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64 device_model_versionqemu-xen-traditional +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64 enable_stubdom true +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64 enable_xsm false +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64 kernbuildjobbuild-amd64-pvops +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64 kernkindpvops +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64 toolstack xl +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64 xenbuildjob build-amd64 +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm all_hostflags arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test,hvm +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm arch amd64 +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm bios rombios +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm buildjob build-amd64-xsm +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm debianhvm_image debian-7.2.0-amd64-CD-1.iso +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm device_model_version qemu-xen-traditional +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm enable_stubdom true +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm enable_xsm true +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm kernbuildjob build-amd64-pvops +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm kernkind pvops +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm toolstack xl +xen-unstable test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm xenbuildjob build-amd64-xsm +xen-unstable test-amd64-amd64-xl-qemuu-debianhvm-amd64 enable_stubdom +xen-unstable test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm enable_stubdom +xen-unstable test-amd64-amd64-xl-qemuu-ovmf-amd64 enable_stubdom +xen-unstable test-amd64-i386-xl-qemut-debianhvm-amd64 enable_stubdom false +xen-unstable test-amd64-i386-xl-qemut-debianhvm-amd64-xsm enable_stubdom false +xen-unstable test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64 all_hostflags arch-i386,arch-xen-amd64,suite-wheezy,purpose-test,hvm +xen-unstable test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64 archi386 +xen-unstable test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64 biosrombios +xen-unstable
[Xen-devel] Status of Improve RTDS scheduler
... == Hypervisor == [...] * Improve RTDS scheduler (none) Change RTDS from quantum driven to event driven - Dagaen Golomb, Meng Xu, Chong Li ... Ok. The patch for this is out: http://osdir.com/ml/general/2015-06/msg10265.html Looking forward to comments. Regards, Dagaen Golomb ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 0/4] 'reset everything' approach to PVHVM guest kexec
On Mon, Jun 08, 2015 at 04:53:46PM +0100, Wei Liu wrote: On Wed, Jun 03, 2015 at 03:35:18PM +0200, Vitaly Kuznetsov wrote: Jan and Tim, last week you expressed some concerns about if the toolstack-based approach to PVHVM guest kexec is the best. Here you can see the 'reset everything' approach to the same problem. It is the bare minimum of what should be done to make it possible for the new kernel to boot. Despite the fact that this implementation is much smaller in size and that it doesn't require any toolstack changes I'm personally in favor of the previous toolstack-based approach as it looks more general, less fragile and easier to support to me. Please let me know your thoughts. I used SCHEDOP_ interface here as DOMCTL_* is not currently supported in Linux kernel and I seriously doubt we need to support something different from DOMID_SELF for soft reset. Current Linux kernel requires two changes to make use of these hypervisor changes: 1) As XS_RESET_WATCHES is not supported by oxenstored we need to try removing the watch in case add operation failed, e.g.: The changeset to implement XS_RESET_WATCHES in cxenstored is 1f9d04fb021cbf35cc420d401a88c696d6524c14 It doesn't look too complicated to do that in oxenstored. Dave (oxenstored maintainer, CC'ed) might have insight. Wei. And I took a stab at it. Here is my oxenstored patch. May contain bugs. :-) ---8--- From 8dd35370442340493f856b0be8d99c87243e79f6 Mon Sep 17 00:00:00 2001 From: Wei Liu wei.l...@citrix.com Date: Mon, 8 Jun 2015 18:39:45 +0100 Subject: [PATCH] oxenstored: implement XS_RESET_WATCHES Signed-off-by: Wei Liu wei.l...@citrix.com --- tools/ocaml/libs/xb/op.ml | 6 -- tools/ocaml/libs/xb/xb.mli | 1 + tools/ocaml/xenstored/connection.ml | 8 tools/ocaml/xenstored/process.ml| 6 ++ 4 files changed, 19 insertions(+), 2 deletions(-) diff --git a/tools/ocaml/libs/xb/op.ml b/tools/ocaml/libs/xb/op.ml index 0ee8666..69346d8 100644 --- a/tools/ocaml/libs/xb/op.ml +++ b/tools/ocaml/libs/xb/op.ml @@ -19,7 +19,8 @@ type operation = Debug | Directory | Read | Getperms | Transaction_end | Introduce | Release | Getdomainpath | Write | Mkdir | Rm | Setperms | Watchevent | Error | Isintroduced | - Resume | Set_target | Restrict | Invalid + Resume | Set_target | Restrict | Reset_watches | + Invalid let operation_c_mapping = [| Debug; Directory; Read; Getperms; @@ -27,7 +28,7 @@ let operation_c_mapping = Transaction_end; Introduce; Release; Getdomainpath; Write; Mkdir; Rm; Setperms; Watchevent; Error; Isintroduced; - Resume; Set_target; Restrict |] + Resume; Set_target; Restrict; Reset_watches |] let size = Array.length operation_c_mapping let array_search el a = @@ -68,4 +69,5 @@ let to_string ty = | Resume- RESUME | Set_target- SET_TARGET | Restrict - RESTRICT + | Reset_watches - RESET_WATCHES | Invalid - INVALID diff --git a/tools/ocaml/libs/xb/xb.mli b/tools/ocaml/libs/xb/xb.mli index 4e1f833..6c242da 100644 --- a/tools/ocaml/libs/xb/xb.mli +++ b/tools/ocaml/libs/xb/xb.mli @@ -23,6 +23,7 @@ module Op : | Resume | Set_target | Restrict + | Reset_watches | Invalid val operation_c_mapping : operation array val size : int diff --git a/tools/ocaml/xenstored/connection.ml b/tools/ocaml/xenstored/connection.ml index b4dc9cb..5e31588 100644 --- a/tools/ocaml/xenstored/connection.ml +++ b/tools/ocaml/xenstored/connection.ml @@ -186,6 +186,14 @@ let del_watch con path token = con.nb_watches - con.nb_watches - 1; apath, w +let del_watches con = + Hashtbl.clear con.watches; + con.next_tid - initial_next_tid + +let del_transactions con = + Hashtbl.clear con.transactions; + con.nb_watches - 0 + let list_watches con = let ll = Hashtbl.fold (fun _ watches acc - List.map (fun watch - watch.path, watch.token) watches :: acc) diff --git a/tools/ocaml/xenstored/process.ml b/tools/ocaml/xenstored/process.ml index 0620585..e827678 100644 --- a/tools/ocaml/xenstored/process.ml +++ b/tools/ocaml/xenstored/process.ml @@ -272,6 +272,11 @@ let do_restrict con t domains cons data = in Connection.restrict con domid +(* only in xen = 4.2 *) +let do_reset_watches con t domains cons data = + Connection.del_watches con; + Connection.del_transactions con + (* only in = xen3.3 *) (* we ensure backward compatibility with restrict by counting the number of argument of set_target ... *) (* This is not very elegant, but it is safe as 'restrict' only restricts permission of dom0 connections *) @@ -324,6 +329,7 @@ let
Re: [Xen-devel] [PATCH v2 for Xen 4.6 3/4] libxl: enabling XL to set per-VCPU parameters of a domain for RTDS scheduler
On Mon, Jun 8, 2015 at 10:56 AM, Dario Faggioli
dario.faggi...@citrix.com wrote:
On Fri, 2015-06-05 at 12:37 +0100, Ian Campbell wrote:
On Mon, 2015-05-25 at 19:09 -0500, Chong Li wrote:
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 117b61d..d28d274 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -347,6 +347,17 @@ libxl_domain_restore_params =
Struct(domain_restore_params, [
(checkpointed_stream, integer),
])
Alternatevily we can just add the per-vcpu stuff (as in 'option 0'), for
all schedulers, and really leave libxl_domain_sched_params alone (let's
call this 'option 2'):
libxl_sched_params = Struct(sched_params,[
(weight, integer, {'init_val': 'LIBXL_PARAM_WEIGHT_DEFAULT'}),
(cap, integer, {'init_val': 'LIBXL_PARAM_CAP_DEFAULT'}),
(period, integer, {'init_val': 'LIBXL_PARAM_PERIOD_DEFAULT'}),
(slice,integer, {'init_val': 'LIBXL_PARAM_SLICE_DEFAULT'}),
(latency, integer, {'init_val': 'LIBXL_PARAM_LATENCY_DEFAULT'}),
(extratime,integer, {'init_val': 'LIBXL_PARAM_EXTRATIME_DEFAULT'}),
(budget, integer, {'init_val': 'LIBXL_PARAM_BUDGET_DEFAULT'}),
])
libxl_vcpu_sched_params = Struct(vcpu_sched_params,[
(sched,libxl_scheduler),
(vcpus,Array(libxl_sched_params, num_vcpus)),
])
In this case the redundancy comes from having libxl_domain_sched_params
and libxl_sched_params looking a lot similar, but not shared code in
declaring them.
Maybe we can also consider putting an union inside
libl_domain_sched_params... but again, quite a severe breakage, and I
wouldn't be sure about how to 'key it'...
So, Thoughts? What do you think the best way forward could be?
I like option 2 more. But I think we may also need a 'vcpuid' field in
libxl_sched_params.
Chong
Regards,
Dario
--
This happens because I choose it to happen! (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK)
--
Chong Li
Department of Computer Science and Engineering
Washington University in St.louis
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 31/41] arm : acpi estimate memory required for acpi/efi tables
Hi Parth,
I think it misses a : between acpi and estimate.
On 17/05/2015 21:03, Parth Dixit wrote:
Estimate the memory required for loading acpi/efi tablee
in DOM0. Initialize the size of acpi/efi tables.
It needs more description...
Signed-off-by: Parth Dixit parth.di...@linaro.org
---
xen/arch/arm/domain_build.c | 54 -
1 file changed, 53 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9d98f64..f2ca525 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -69,6 +69,9 @@ struct meminfo __initdata acpi_mem;
#ifdef CONFIG_ACPI
/* Reserve DOM0 FDT size in ACPI case only */
#define DOM0_FDT_MIN_SIZE 4096
+#define NR_NEW_XEN_TABLES 2
New table of what?
+/* Constant to indicate Xen in unicode u16 format */
+static const u16 XEN_EFI_FW_VENDOR[] ={0x0058,0x0065,0x006E,0x};
I think you have to rework the order of your patch in this series. This
kind of variable should appear where you add the EFI table and not where
you estimate the size.
It would be easier to understand what it's used for.
#endif
struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
@@ -1222,6 +1225,51 @@ static int handle_node(struct domain *d, struct
kernel_info *kinfo,
return res;
}
#ifdef CONFIG_ACPI
+static int estimate_acpi_size(struct domain *d,struct kernel_info *kinfo,
struct membank tbl_add[])
+{
+int size = 0;
+u64 addr;
+struct acpi_table_header *table;
+struct acpi_table_rsdp *rsdp_tbl;
+
+set_acpi_size(size);
+tbl_add[TBL_EFIT].size = sizeof(struct efi_system_table)
++ sizeof(struct efi_config_table)
++ sizeof(XEN_EFI_FW_VENDOR);
+
+tbl_add[TBL_MMAP].size = sizeof(struct efi_memory_desc)
+*(kinfo-mem.nr_banks + acpi_mem.nr_banks + TBL_MMAX);
+tbl_add[TBL_XENV].size = sizeof(struct acpi_table_xenv);
+tbl_add[TBL_STAO].size = sizeof(struct acpi_table_stao);
+
+addr = acpi_os_get_root_pointer();
+if( !addr )
+return -ENODEV;
+
+rsdp_tbl = acpi_os_map_memory(addr, sizeof(struct acpi_table_rsdp));
+if( !rsdp_tbl )
+return -ENOMEM;
+
+table = acpi_os_map_memory(rsdp_tbl-xsdt_physical_address,
+ sizeof(struct acpi_table_header));
+if ( !table )
+return -ENOMEM;
+
+tbl_add[TBL_XSDT].size = table-length
++( NR_NEW_XEN_TABLES*sizeof(acpi_native_uint) );
Coding style:
+ (NR_NEW_XEN_TABLES * sizeof(acpi_native_uint);
This is also needs some explanation of the acpi_native_uint. We should
be able to understand the code without have to search on the web. A
reference to the doc would works too...
+tbl_add[TBL_XSDT].start = rsdp_tbl-xsdt_physical_address;
+acpi_os_unmap_memory(table, sizeof(struct acpi_table_header));
+acpi_os_unmap_memory(rsdp_tbl, sizeof(struct acpi_table_rsdp));
+size = tbl_add[TBL_EFIT].size
The size is used to set acpi_size but this is EFI table... Please be
consistent.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 41/41] arm : acpi route irq's at time of boot
Hi,
On 17/05/2015 21:04, Parth Dixit wrote:
NOTE: This is a wrokaround to be fixed later.
How do you plan to fix it?
Route all the irq's to Dom0 at the time of booting.
Trigger and polarity will be set dyanmaically when
s/dyanmaically/dynamically/
Dom0 request's for it.
Signed-off-by: Parth Dixit parth.di...@linaro.org
---
xen/arch/arm/domain_build.c | 20
1 file changed, 20 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 2ce30bf..cdad86b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1481,6 +1481,26 @@ static int prepare_acpi(struct domain *d, struct
kernel_info *kinfo, struct memb
acpi_os_unmap_memory(rsdp_tbl, sizeof(struct acpi_table_rsdp) );
prepare_efi_table(d, kinfo, tbl_add);
+
+/* configure interrupts gicv2 only */
The indentation seems wrong.
Also, why GICv2 only? I don't see anything GICv2 specific...
+ for( i = 32 ; i 255 ; i++ )
+ {
+struct irq_desc *desc;
Newline.
+desc = irq_to_desc(i);
+if( desc-action != NULL)
+continue;
+
+vgic_reserve_virq(d, i);
This function returns an error code. If you don't use it explain why in
a comment.
+set_irq_type(i, ACPI_IRQ_TYPE_NONE);
+res = route_irq_to_guest(d, i, i, NULL);
+if ( res )
+{
+printk(XENLOG_ERR Unable to route IRQ %u to domain %u\n,
+i, d-domain_id);
+continue;
Shouldn't we bail out here?
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 33/41] arm : acpi prepare acpi tables for dom0
On 17/05/2015 21:04, Parth Dixit wrote:
Map acpi tables described in uefi table to DOM0 address space
Signed-off-by: Parth Dixit parth.di...@linaro.org
---
xen/arch/arm/domain_build.c | 59 -
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f2ca525..90bdd01 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1225,6 +1225,50 @@ static int handle_node(struct domain *d, struct
kernel_info *kinfo,
return res;
}
#ifdef CONFIG_ACPI
+static int prepare_acpi(struct domain *d, struct kernel_info *kinfo, struct
membank tbl_add[])
+{
+unsigned long res;
+u64 addr, size;
+int i = 0;
+
+addr = acpi_os_get_root_pointer();
+if( !addr )
+return -ENODEV;
+
+size = sizeof(struct acpi_table_rsdp);
+
+res = map_regions(d,
+ paddr_to_pfn(addr PAGE_MASK),
+ DIV_ROUND_UP(size, PAGE_SIZE),
+ paddr_to_pfn(addr PAGE_MASK));
+if ( res )
+{
+ printk(XENLOG_ERR Unable to map 0x%PRIx64
+ - 0x%PRIx64 in domain \n,
+addr PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ return res;
+}
+
+for( i = 0; i acpi_gbl_root_table_list.count; i++ )
The description of the patch suggest that you will use acpi_mem
introduced in patch #29 but you are using acpi_glb_root_table_list.
Please either update the commit message or change the loop.
IHMO, the latter would be cleaner.
+{
+addr = acpi_gbl_root_table_list.tables[i].address;
+size = acpi_gbl_root_table_list.tables[i].length;
+res = map_regions(d,
+ paddr_to_pfn(addr PAGE_MASK),
+ DIV_ROUND_UP(size, PAGE_SIZE),
+ paddr_to_pfn(addr PAGE_MASK));
+if ( res )
+{
+ printk(XENLOG_ERR Unable to map 0x%PRIx64
+ - 0x%PRIx64 in domain \n,
+addr PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ return res;
+}
+}
+
+return 0;
+}
+
static int estimate_acpi_size(struct domain *d,struct kernel_info *kinfo,
struct membank tbl_add[])
{
int size = 0;
@@ -1429,6 +1473,10 @@ static int create_acpi_dtb(struct domain *d, struct
kernel_info *kinfo, struct m
{
return -EINVAL;
}
+static int prepare_acpi(struct domain *d, struct kernel_info *kinfo, struct
membank tbl_add[])
+{
BUG();
+return -EINVAL;
+}
#endif
static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
{
@@ -1647,10 +1695,19 @@ int construct_dom0(struct domain *d)
* as the initrd fdt in RAM, so call it first.
*/
kernel_load(kinfo);
+
+if ( !acpi_disabled )
+{
+rc = prepare_acpi(d, kinfo, tbl_add);
+if ( rc 0 )
+return rc;
+}
+
/* initrd_load will fix up the fdt, so call it before dtb_load */
initrd_load(kinfo);
/* Allocate the event channel IRQ and fix up the device tree */
-evtchn_fixup(d, kinfo);
+if( acpi_disabled )
+evtchn_fixup(d, kinfo);
This change doesn't belong to this patch.
dtb_load(kinfo);
/* Now that we are done restore the original p2m and current. */
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 29/41] arm : acpi read acpi memory info from uefi
Hi Parth,
On 17/05/2015 21:03, Parth Dixit wrote:
ACPI memory is seperate from conventional memory and should
s/seperate/separate/
be marked as reserved while passing to DOM0. Create a new meminfo
structure to store all the acpi tables listed in uefi.
Signed-off-by: Parth Dixit parth.di...@linaro.org
---
xen/arch/arm/domain_build.c | 2 ++
xen/arch/arm/efi/efi-boot.h | 20 +---
xen/include/asm-arm/setup.h | 1 +
3 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 865b81a..9d98f64 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -42,6 +42,8 @@ static void __init parse_dom0_mem(const char *s)
}
custom_param(dom0_mem, parse_dom0_mem);
+struct meminfo __initdata acpi_mem;
+
Please protect it with an CONFIG_ACPI and please keep all the ACPI
variable in the same place within this file.
//#define DEBUG_DT
#ifdef DEBUG_DT
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index b02cc02..d21cba5 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -127,14 +127,16 @@ static EFI_STATUS __init
efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
{
int Index;
int i = 0;
+int j = 0;
EFI_MEMORY_DESCRIPTOR *desc_ptr = map;
for ( Index = 0; Index (mmap_size / desc_size); Index++ )
{
-if ( desc_ptr-Type == EfiConventionalMemory
- || desc_ptr-Type == EfiBootServicesCode
- || desc_ptr-Type == EfiBootServicesData )
+switch( desc_ptr-Type )
{
+case EfiConventionalMemory:
+case EfiBootServicesCode:
+case EfiBootServicesData:
if ( i = NR_MEM_BANKS )
{
PrintStr(LWarning: All __stringify(NR_MEM_BANKS)
@@ -144,11 +146,23 @@ static EFI_STATUS __init
efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
bootinfo.mem.bank[i].start = desc_ptr-PhysicalStart;
bootinfo.mem.bank[i].size = desc_ptr-NumberOfPages *
EFI_PAGE_SIZE;
++i;
+break;
#ifdef CONFIG_ACPI
+case EfiACPIReclaimMemory:
+if ( j = NR_MEM_BANKS )
+{
+PrintStr(LWarning: All __stringify(NR_MEM_BANKS)
+ acpi meminfo mem banks exhausted.\r\n);
DOM0 will likely fail to boot if one of the ACPI region is not present
because there is not enough place in the array.
Either you allocate dynamically the array or you stop booting on the
platform. But a warning is not enough...
+break;
+}
+acpi_mem.bank[j].start = desc_ptr-PhysicalStart;
+acpi_mem.bank[j].size = desc_ptr-NumberOfPages * EFI_PAGE_SIZE;
+++j;
}
desc_ptr = NextMemoryDescriptor(desc_ptr, desc_size);
}
bootinfo.mem.nr_banks = i;
+acpi_mem.nr_banks = j;
return EFI_SUCCESS;
}
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index ba5a67d..1865b72 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -46,6 +46,7 @@ struct bootinfo {
};
extern struct bootinfo bootinfo;
+extern struct meminfo acpi_mem;
#ifdef CONFIG_ACPI
...
#endif
void arch_init_memory(void);
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 35/41] arm : acpi add helper function to calculate crc32
Hi, On 17/05/2015 21:04, Parth Dixit wrote: Add helper functions for calculating crc32. This is required for computing crc of efi table. These functions are copied from here http://mirrors.neusoft.edu.cn/rpi-kernel/lib/xz/xz_crc32.c Original author's are Lasse Collin and Igor Pavlov. I'm nearly sure this patch will break compilation during bisection... Anyway, the function xz_crc32_* already exist in the tree. Please use them. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 39/41] arm : acpi configure interrupts dynamically
Hi Parth,
On 17/05/2015 21:04, Parth Dixit wrote:
Interrupt information is described in DSDT and is not available at
the time of booting. Configure the interrupts dynamically when requested
by Dom0
Missing .
Also, I'm sure we talked about it multiple time. I'd like to keep the
ACPI changes very contained to Xen boot. Your change is not ACPI
specific and could be used for DT.
Signed-off-by: Parth Dixit parth.di...@linaro.org
---
xen/arch/arm/vgic.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 73a6f7e..f63deb4 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -25,6 +25,7 @@
#include xen/irq.h
#include xen/sched.h
#include xen/perfc.h
+#include xen/acpi.h
#include asm/current.h
@@ -285,6 +286,8 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
}
}
+#define VGIC_ICFG_MASK(intr) ( 1 ( ( 2 * ( intr % 16 ) ) + 1 ) )
+
void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
{
struct domain *d = v-domain;
@@ -296,7 +299,22 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
struct vcpu *v_target;
while ( (i = find_next_bit(mask, 32, i)) 32 ) {
+#ifdef CONFIG_ACPI
+struct vgic_irq_rank *vr = vgic_get_rank(v, n);
+uint32_t tr;
New line.
+irq = i + (32 * n);
+if( ( !acpi_disabled ) ( n != 0 ) is_hardware_domain(d) )
You need to add a comment explaining the ( n != 0 ) i.e we don't SGIs
and PPIs are RO. It's implementation defined for PPI but it's preferable
to let Xen take care of it.
Also, we should set the type only for IRQ assigned to DOM0 (i.e p-desc
!= NULL). With your current solution, DOM0 may change the configuration
of the serial IRQ by mistake and take down Xen because the physical IRQ
is enabled and the behavior will be unpredictable.
Furthermore, during passthrough, the IRQ may not have been configured by
DOM0. So we have to let the guest configure the IRQ.
+{
+tr = vr-icfg[i 4] ;
+
+if( ( tr VGIC_ICFG_MASK(i) ) )
+set_irq_type(irq, ACPI_IRQ_TYPE_EDGE_BOTH);
+else
+set_irq_type(irq, ACPI_IRQ_TYPE_LEVEL_MASK);
Given that only SPI can be configured it would have been better to call
irq_set_type.
Although, those 2 functions don't do what you think. They are setting
the type internally in Xen but don't change the GIC interrupt
configuration register.
Lastly, they may fail because the configuration as been set earlier (as
you did in patch #41.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 27/41] arm : add helper functions to map memory regions
Hi Parth, On 17/05/2015 21:03, Parth Dixit wrote: creates a helper function for mapping with cached attributes Signed-off-by: Parth Dixit parth.di...@linaro.org --- xen/arch/arm/p2m.c| 26 ++ xen/include/asm-arm/p2m.h | 10 ++ 2 files changed, 36 insertions(+) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index 903fa3f..fcb8116 100644 --- a/xen/arch/arm/p2m.c +++ b/xen/arch/arm/p2m.c @@ -1140,6 +1140,32 @@ int p2m_populate_ram(struct domain *d, d-arch.p2m.default_access); } +int map_regions(struct domain *d, + unsigned long start_gfn, + unsigned long nr, + unsigned long mfn) The name doesn't match the behavior. How the user will know that map_regions is actually using cached attribute. Also, I would prefer a function taking the caching attribute in parameter. I would be more generic that trying to introduce a new function every time is a new attribute is required. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 30/41] arm : acpi add placeholder for acpi load address
Hi Parth,
On 17/05/2015 21:03, Parth Dixit wrote:
EFI table, memory description table and some of acpi tables
will reside in DOM0 memory. Add placeholder for starting
address for loading in DOM0 and get/set acpi size helpers.
Signed-off-by: Parth Dixit parth.di...@linaro.org
---
xen/arch/arm/acpi/lib.c| 12
xen/arch/arm/kernel.c | 5 -
xen/arch/arm/kernel.h | 1 +
xen/include/asm-arm/acpi.h | 4
4 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
index fd9bfa4..9b9f059 100644
--- a/xen/arch/arm/acpi/lib.c
+++ b/xen/arch/arm/acpi/lib.c
@@ -1,6 +1,8 @@
#include xen/acpi.h
#include asm/mm.h
+static int acpi_len = 0;
+
There is no reason to type this variable signed int. Please use unsigned
int.
Even better, paddr_t as you use like that after.
void __iomem *
acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
{
@@ -17,3 +19,13 @@ inline bool_t acpi_psci_hvc_present(void)
{
return acpi_gbl_FADT.arm_boot_flags ACPI_FADT_PSCI_USE_HVC;
}
+
+inline int get_acpi_size(void)
+{
+return acpi_len;
+}
+
+inline void set_acpi_size(int size)
+{
+acpi_len = size;
+}
The variable name is misleading, acpi_len doesn't correspond to the real
size of the ACPI but only whole size of the table generated by Xen.
Furthermore, based the usage I was able to find within the other patch,
this variable is only used during dom0 creation and should live in kinfo.
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 32/41] arm : acpi dynamically map mmio regions
Hi Parth, On 17/05/2015 21:03, Parth Dixit wrote: In ACPI mmio regions are described in DSDT which requires AML interpreter. Defer the mapping of mmio until DSDT is parsed in DOM0 and map mmio's dynamically at the time of request. I'm against a such solution. Even though it's DOM0 we should avoid to allow him to map anything (RAM,...) on data abort. During DOM0 creation, we should map anything that is not RAM and not used by Xen to DOM0. IIRC, this is how it works on x86. I'm nearly sure we talked about it during the Linaro Connect. Please give details if you thing it won't work... Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 37/41] arm : acpi add acpi parameter to enable/disable acpi
Hi Parth, On 17/05/2015 21:04, Parth Dixit wrote: ACPI will be disabled by default. Define new command line parameter acpi for enabling it. I don't think this is right. We have to be able to boot platform where there is only ACPI provided without adding a command line option. Overall, it would be better if we follow the same behavior as Linux i.e ACPI is enabled instead off DT unless: - ACPI has been disabled (acpi=off) - the DT is not empty (it has more than just a /chosen node) and ACPI has not been forced enabled (acpi=force). Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: Propagate clock-frequency to DOMU if present in the DT timer node
Hi Julien, My test was limited as I don't have a platform where CNTFRQ/CNTFRQ_EL0 is not valid. I may have done a mistake in the code. Understood. That's why I thought it would be worthwhile posting my results :-) What I see is that in preinit_xen_time(), the call to dt_property_read_u32() returns zero. When I built Xen, I set CONFIG_DTB_FILE, and looking at the corresponding dts file it has a timer node with a clock-frequency property. I know that our bootloader also creates a DTB, though, and it looks like that one does *not* have a clock-frequency property in the timer node, so I guess Xen ends up using that one somehow. CNTFRQ on core 0 (only) is also set to the correct frequency, so I end up with the correct frequency in my Dom0 kernel anyway. dt_property_read_u32 returns 0 when it cannot find a property or because the size of the value is not valid. The device tree provided via CONFIG_DTB_FILE will always take precedence to the one pass by the bootloader. How do you set CONFIG_DTB_FILE? A simple export CONFIG_DTB_FILE= I would also look to see if by any chance the wrong device tree is set via CONFIG_DTB_FILE. I did double-check before I posted, and everything looks right to me. I certainly could have missed something. It does look like it's *somehow* getting the DT generated by the bootloader. You can check what is the device tree used by dumping it from DOM0. Thought, it may be slightly different (some nodes are rewritten). You can dump it using dtc -I fs /proc/device-tree -O dts When I do that (at a shell prompt in Dom0), the timer node does not have a clock-frequency property. So your patch isn't designed to help in this case (CNTFRQ set on core 0 only, no clock-frequency property in timer node of DT). Chris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [edk2] The size of memory is wrong inside of virtual machine(VM) when using OVMF
On 06/07/15 14:29, Wei Liu wrote: On Mon, Jun 01, 2015 at 09:13:08AM +, Maoming wrote: Hi all: I encountered a troublesome problem about OVMF. I used OVMF.fd as a BIOS of virtual machine(VM). 1、my environment: xen_version: 4.6-unstable I git clone xen from git://xenbits.xen.org/xen.git. configure it and parameters as below: ./configure --prefix=/usr/ --libdir=/usr/lib/ --enable-ovmf then make make install, after that I reboot my host OS(suse11sp3). There is a same problem in KVM too. 2、problem: I started a VM whose memory is 64G in the host. The size of memory inside of the VM is wrong while it is OK when I check it in the host using xl list. But, when I changed the memory to 63G,it was both OK. (1)64G memory inside of VM using free to check: total used free sharedbuffers cached Mem: 3715640 4959163219724 0 22060 175136 -/+ buffers/cache: 2987203416920 Swap: 4046840 04046840 It is only 3.5G. in the host using xl list to check: NameID Mem VCPUs State Time(s) Domain-0 0 305516 r- 861.2 redhat 4 65536 2 r- 5.9 (2)63G memory inside of VM using free to check: total used free sharedbuffers cached Mem: 649182241083912 63834312 0 22188 175344 -/+ buffers/cache: 886380 64031844 Swap: 4046840 04046840 It is OK. in the host using xl list to check: NameID Mem VCPUs State Time(s) Domain-0 0 305516 r- 821.2 redhat 3 64512 2 -b 48.5 3、my cfg file: builder = hvm name = redhat memory = 65536 maxmem = 65536 vcpus = 2 bios = ovmf boot = dc sdl=0 disk = [ 'file:/test/image/redhat6_3.img,xvda,w' ] vnc = 1 vnclisten = '9.61.1.31' vncdisplay = 0 Any thought on this? Any help will be appreciated. If you need some other information, please let me know. :) It looks like there is some kind of truncation inside OVMF. But I don't have a test box that has so much memory so I cannot try it myself. The issue is real. I've been working on some patches today for this. I'll soon send an RFC series. It's actually easy to *test* this scenario: just create a 128GB or so file, with fallocate, on a sufficiently big filesystem. Then format it with mkswap and add it with swapon. I have strict memory overcommit settings on my laptop (/proc/sys/vm/overcommit_memory = 2), but with such a swap file, a = 64GB guest can easily be started. (I used my old spindle disk for the swap file. Since the guest is doing practically nothing, it doesn't cause the disk to thrash.) Thanks Laszlo Since it manifests on both Xen and KVM I don't really have an idea about what's going on. The only thing I can say is that the tested OVMF tree for Xen is http://xenbits.xen.org/gitweb/?p=osstest/ovmf.git;a=summary xen-tested-master The one in xen.git is updated periodically. Make sure you use our latest tested branch so you can get fixes from upstream. Wei. Thanks! -mao ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel -- ___ edk2-devel mailing list edk2-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [BUGFIX][PATCH v2 1/4] exec: Do not use MemoryRegion after free
Here is gdb output that shows this happening:
Breakpoint 3, object_finalize (data=0x7fdf32a14010) at qom/object.c:417
417 obj-free(obj);
(gdb) bt
#0 object_finalize (data=0x7fdf32a14010) at qom/object.c:417
#1 0x007329d4 in object_unref (obj=0x7fdf32a14010) at
qom/object.c:720
#2 0x00468a65 in memory_region_unref (mr=0x7fdf32a168b0) at
xen/tools/qemu-xen-dir/memory.c:1359
#3 0x0040eb52 in phys_section_destroy (mr=0x7fdf32a168b0) at
xen/tools/qemu-xen-dir/exec.c:960
#4 0x0040ec0a in phys_sections_free (map=0x3e51fc8) at
xen/tools/qemu-xen-dir/exec.c:973
#5 0x00411cc9 in address_space_dispatch_free (d=0x3e51fb0) at
xen/tools/qemu-xen-dir/exec.c:2133
#6 0x00840ae2 in call_rcu_thread (opaque=0x0) at util/rcu.c:256
#7 0x0032fdc07d14 in start_thread (arg=0x7fdf34866700) at
pthread_create.c:309
#8 0x0032fd4f168d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) p obj
$5 = (Object *) 0x7fdf32a14010
(gdb) p *obj
$6 = {class = 0x302f380, free = 0x40a1e0 g_free@plt, properties =
{tqh_first = 0x0, tqh_last = 0x7fdf32a14020},
ref = 0, parent = 0x0}
(gdb) up
#1 0x007329d4 in object_unref (obj=0x7fdf32a14010) at
qom/object.c:720
720 object_finalize(obj);
(gdb) up
#2 0x00468a65 in memory_region_unref (mr=0x7fdf32a168b0) at
xen/tools/qemu-xen-dir/memory.c:1359
1359object_unref(obj-parent);
(gdb) up
#3 0x0040eb52 in phys_section_destroy (mr=0x7fdf32a168b0) at
xen/tools/qemu-xen-dir/exec.c:960
960 memory_region_unref(mr);
(gdb) l
955 return map-sections_nb++;
956 }
957
958 static void phys_section_destroy(MemoryRegion *mr)
959 {
960 memory_region_unref(mr);
961
962 if (mr-subpage) {
963 subpage_t *subpage = container_of(mr, subpage_t, iomem);
964 object_unref(OBJECT(subpage-iomem));
(gdb) p mr
$7 = (MemoryRegion *) 0x7fdf32a168b0
(gdb) p mr-subpage
$9 = false
(gdb) n
419 }
(gdb) n
object_unref (obj=0x7fdf32a14010) at qom/object.c:722
722 }
(gdb) n
memory_region_unref (mr=0x7fdf32a168b0) at
xen/tools/qemu-xen-dir/memory.c:1363
1363}
(gdb) n
phys_section_destroy (mr=0x7fdf32a168b0) at xen/tools/qemu-xen-dir/exec.c:962
962 if (mr-subpage) {
(gdb) p mr
$10 = (MemoryRegion *) 0x7fdf32a168b0
(gdb) p *mr
Cannot access memory at address 0x7fdf32a168b0
Signed-off-by: Don Slutz dsl...@verizon.com
CC: Don Slutz don.sl...@gmail.com
---
exec.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/exec.c b/exec.c
index 487583b..2f44a80 100644
--- a/exec.c
+++ b/exec.c
@@ -957,10 +957,14 @@ static uint16_t phys_section_add(PhysPageMap *map,
static void phys_section_destroy(MemoryRegion *mr)
{
-memory_region_unref(mr);
+subpage_t *subpage = NULL;
if (mr-subpage) {
-subpage_t *subpage = container_of(mr, subpage_t, iomem);
+subpage = container_of(mr, subpage_t, iomem);
+}
+memory_region_unref(mr);
+
+if (subpage) {
object_unref(OBJECT(subpage-iomem));
g_free(subpage);
}
--
1.8.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 4/4] xen: Fix map/unmap of pcidev to ioreq server
The commit 707ff80021ccd7a68f4b3d2c44eebf87efbb41c4 added usage of
xc_hvm_map_pcidev_from_ioreq_server() and
xc_hvm_unmap_pcidev_from_ioreq_server(). These routines only
correctly work if the PCI BDF of a PCI device is unique. The 3
parts (bus, device, and function) of a PCI BDF are not required to
be unique.
The PCI BDF is accessed in QEMU:
buspci_bus_num()
device PCI_SLOT()
function PCI_FUNC()
Add a hash table to track the current set of PCI BDFs and only call
on xc_hvm_map_pcidev_from_ioreq_server() and
xc_hvm_unmap_pcidev_from_ioreq_server() when needed.
Also fix the PCI BDF default stderr trace output: bus is seperated
by ':', and function is only 1 digit.
Here is an example of stderr trace output:
xen_map_pcidev id: 1 bdf: 00:00.0
xen_map_pcidev id: 1 bdf: 00:01.0
xen_map_pcidev id: 1 bdf: 00:01.1
xen_map_pcidev id: 1 bdf: 00:01.3
xen_map_pcidev id: 1 bdf: 00:02.0
xen_map_pcidev id: 1 bdf: 00:03.0
xen_map_pcidev id: 1 bdf: 00:04.0
xen_map_pcidev id: 1 bdf: 00:05.0
xen_map_pcidev id: 1 bdf: 00:11.0
xen_map_pcidev id: 1 bdf: 00:15.0
xen_map_pcidev id: 1 bdf: 00:16.0
xen_map_pcidev id: 1 bdf: 00:17.0
xen_map_pcidev id: 1 bdf: 00:18.0
xen_map_pcidev_dup id: 1 bdf: 00:01.0 dup: 2
xen_map_pcidev_dup id: 1 bdf: 00:01.0 dup: 3
xen_map_pcidev_dup id: 1 bdf: 00:03.0 dup: 2
xen_map_pcidev_dup id: 1 bdf: 00:03.0 dup: 3
xen_map_pcidev_dup id: 1 bdf: 00:04.0 dup: 2
xen_unmap_pcidev_dup id: 1 bdf: 00:03.0 dup: 2
xen_map_pcidev id: 1 bdf: ff:03.0
xen_unmap_pcidev id: 1 bdf: 00:17.0
xen_map_pcidev id: 1 bdf: ff:17.0
xen_unmap_pcidev_dup id: 1 bdf: 00:01.0 dup: 2
xen_map_pcidev id: 1 bdf: ff:01.0
xen_unmap_pcidev_dup id: 1 bdf: 00:03.0 dup: 1
xen_map_pcidev_dup id: 1 bdf: ff:03.0 dup: 2
xen_unmap_pcidev_dup id: 1 bdf: 00:04.0 dup: 1
xen_map_pcidev id: 1 bdf: ff:04.0
xen_unmap_pcidev_dup id: 1 bdf: ff:03.0 dup: 1
xen_map_pcidev id: 1 bdf: 01:03.0
xen_unmap_pcidev id: 1 bdf: ff:17.0
xen_map_pcidev id: 1 bdf: 01:17.0
xen_unmap_pcidev_dup id: 1 bdf: 00:01.0 dup: 1
xen_map_pcidev_dup id: 1 bdf: ff:01.0 dup: 2
xen_unmap_pcidev_dup id: 1 bdf: ff:01.0 dup: 1
xen_map_pcidev id: 1 bdf: 02:01.0
xen_unmap_pcidev id: 1 bdf: ff:01.0
xen_map_pcidev id: 1 bdf: 03:01.0
xen_unmap_pcidev id: 1 bdf: ff:03.0
xen_map_pcidev id: 1 bdf: 03:03.0
xen_unmap_pcidev id: 1 bdf: ff:04.0
xen_map_pcidev id: 1 bdf: 03:04.0
xen_unmap_pcidev id: 1 bdf: 00:04.0
xen_unmap_pcidev id: 1 bdf: 00:05.0
xen_unmap_pcidev id: 1 bdf: 01:03.0
xen_map_pcidev_dup id: 1 bdf: 00:03.0 dup: 2
xen_unmap_pcidev id: 1 bdf: 01:17.0
xen_map_pcidev id: 1 bdf: 00:17.0
xen_unmap_pcidev id: 1 bdf: 03:01.0
xen_map_pcidev_dup id: 1 bdf: 00:01.0 dup: 2
xen_unmap_pcidev id: 1 bdf: 03:03.0
xen_map_pcidev_dup id: 1 bdf: 00:03.0 dup: 3
xen_unmap_pcidev id: 1 bdf: 03:04.0
xen_map_pcidev id: 1 bdf: 00:04.0
xen_unmap_pcidev_dup id: 1 bdf: 00:03.0 dup: 2
xen_map_pcidev id: 1 bdf: 01:03.0
xen_unmap_pcidev id: 1 bdf: 00:17.0
xen_map_pcidev id: 1 bdf: 01:17.0
xen_unmap_pcidev id: 1 bdf: 02:01.0
xen_map_pcidev_dup id: 1 bdf: 00:01.0 dup: 3
xen_unmap_pcidev_dup id: 1 bdf: 00:01.0 dup: 2
xen_map_pcidev id: 1 bdf: 02:01.0
xen_unmap_pcidev_dup id: 1 bdf: 00:01.0 dup: 1
xen_map_pcidev id: 1 bdf: 03:01.0
xen_unmap_pcidev_dup id: 1 bdf: 00:03.0 dup: 1
xen_map_pcidev id: 1 bdf: 03:03.0
xen_unmap_pcidev id: 1 bdf: 00:04.0
xen_map_pcidev id: 1 bdf: 03:04.0
Signed-off-by: Don Slutz dsl...@verizon.com
CC: Don Slutz don.sl...@gmail.com
---
include/hw/xen/xen_common.h | 53 +++--
trace-events| 6 +++--
xen-hvm.c | 15 -
3 files changed, 55 insertions(+), 19 deletions(-)
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 6579b78..260ee58 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -223,12 +223,14 @@ static inline void xen_unmap_io_section(XenXC xc, domid_t
dom,
static inline void xen_map_pcidev(XenXC xc, domid_t dom,
ioservid_t ioservid,
+ GHashTable *pci_bdf,
PCIDevice *pci_dev)
{
}
static inline void xen_unmap_pcidev(XenXC xc, domid_t dom,
ioservid_t ioservid,
+GHashTable *pci_bdf,
PCIDevice *pci_dev,
uint8_t oldbus)
{
@@ -346,27 +348,54 @@ static inline void xen_unmap_io_section(XenXC xc, domid_t
dom,
static inline void xen_map_pcidev(XenXC xc, domid_t dom,
ioservid_t ioservid,
+ GHashTable *pci_bdf,
PCIDevice *pci_dev)
{
-trace_xen_map_pcidev(ioservid, pci_bus_num(pci_dev-bus),
- PCI_SLOT(pci_dev-devfn), PCI_FUNC(pci_dev-devfn));
-xc_hvm_map_pcidev_to_ioreq_server(xc, dom, ioservid,
- 0,
[Xen-devel] [PATCH v2 3/4] xen: Add usage of device listener interface for PCI to PCI bridges
Signed-off-by: Don Slutz dsl...@verizon.com
CC: Don Slutz don.sl...@gmail.com
---
include/hw/xen/xen_common.h | 10 ++
xen-hvm.c | 13 -
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 38f29fb..6579b78 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -229,7 +229,8 @@ static inline void xen_map_pcidev(XenXC xc, domid_t dom,
static inline void xen_unmap_pcidev(XenXC xc, domid_t dom,
ioservid_t ioservid,
-PCIDevice *pci_dev)
+PCIDevice *pci_dev,
+uint8_t oldbus)
{
}
@@ -357,12 +358,13 @@ static inline void xen_map_pcidev(XenXC xc, domid_t dom,
static inline void xen_unmap_pcidev(XenXC xc, domid_t dom,
ioservid_t ioservid,
-PCIDevice *pci_dev)
+PCIDevice *pci_dev,
+uint8_t oldbus)
{
-trace_xen_unmap_pcidev(ioservid, pci_bus_num(pci_dev-bus),
+trace_xen_unmap_pcidev(ioservid, oldbus,
PCI_SLOT(pci_dev-devfn), PCI_FUNC(pci_dev-devfn));
xc_hvm_unmap_pcidev_from_ioreq_server(xc, dom, ioservid,
- 0, pci_bus_num(pci_dev-bus),
+ 0, oldbus,
PCI_SLOT(pci_dev-devfn),
PCI_FUNC(pci_dev-devfn));
}
diff --git a/xen-hvm.c b/xen-hvm.c
index 42356b8..7b6d8f1 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -590,10 +590,20 @@ static void xen_device_unrealize(DeviceListener *listener,
if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
PCIDevice *pci_dev = PCI_DEVICE(dev);
-xen_unmap_pcidev(xen_xc, xen_domid, state-ioservid, pci_dev);
+xen_unmap_pcidev(xen_xc, xen_domid, state-ioservid, pci_dev,
+ pci_bus_num(pci_dev-bus));
}
}
+static void xen_device_change_pci_bus_num(DeviceListener *listener,
+ PCIDevice *pci_dev, uint8_t oldbus)
+{
+XenIOState *state = container_of(listener, XenIOState, device_listener);
+
+xen_unmap_pcidev(xen_xc, xen_domid, state-ioservid, pci_dev, oldbus);
+xen_map_pcidev(xen_xc, xen_domid, state-ioservid, pci_dev);
+}
+
static void xen_sync_dirty_bitmap(XenIOState *state,
hwaddr start_addr,
ram_addr_t size)
@@ -709,6 +719,7 @@ static MemoryListener xen_io_listener = {
static DeviceListener xen_device_listener = {
.realize = xen_device_realize,
.unrealize = xen_device_unrealize,
+.change_pci_bus_num = xen_device_change_pci_bus_num,
};
/* get the ioreq packets from share mem */
--
1.8.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/4] Extend device listener interface for PCI to PCI bridges
The commit 707ff80021ccd7a68f4b3d2c44eebf87efbb41c4 assumed that a
PCI device has a static address. This is not true for PCI devices
that are on the secondary bus of a PCI to PCI bridge.
BIOS and/or guest OS can change the secondary bus number to a new
value at any time.
Extend the device listener interface to be called when ever the
secondary bus number is set to a new value. This new interface
is called for all PCI devices that are on the secondary bridge.
Signed-off-by: Don Slutz dsl...@verizon.com
CC: Don Slutz don.sl...@gmail.com
---
hw/core/qdev.c | 7 +++
hw/pci/pci_bridge.c| 18 ++
include/hw/qdev-core.h | 3 +++
3 files changed, 28 insertions(+)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index b0f0f84..7728ee7 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -239,6 +239,13 @@ void device_listener_unregister(DeviceListener *listener)
QTAILQ_REMOVE(device_listeners, listener, link);
}
+void device_listener_change_pci_bus_num(PCIBus *b, PCIDevice *d, void *opaque)
+{
+uint8_t oldbus = GPOINTER_TO_INT(opaque);
+
+DEVICE_LISTENER_CALL(change_pci_bus_num, Forward, d, oldbus);
+}
+
static void device_realize(DeviceState *dev, Error **errp)
{
DeviceClass *dc = DEVICE_GET_CLASS(dev);
diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
index 40c97b1..742c4d8 100644
--- a/hw/pci/pci_bridge.c
+++ b/hw/pci/pci_bridge.c
@@ -248,6 +248,7 @@ void pci_bridge_write_config(PCIDevice *d,
PCIBridge *s = PCI_BRIDGE(d);
uint16_t oldctl = pci_get_word(d-config + PCI_BRIDGE_CONTROL);
uint16_t newctl;
+uint8_t oldbus = pci_get_byte(d-config + PCI_SECONDARY_BUS);
pci_default_write_config(d, address, val, len);
@@ -265,6 +266,14 @@ void pci_bridge_write_config(PCIDevice *d,
pci_bridge_update_mappings(s);
}
+if (oldbus != pci_get_byte(d-config + PCI_SECONDARY_BUS)) {
+PCIBus *sec_bus = pci_bridge_get_sec_bus(s);
+
+pci_for_each_device(sec_bus, pci_bus_num(sec_bus),
+device_listener_change_pci_bus_num,
+GINT_TO_POINTER(oldbus));
+}
+
newctl = pci_get_word(d-config + PCI_BRIDGE_CONTROL);
if (~oldctl newctl PCI_BRIDGE_CTL_BUS_RESET) {
/* Trigger hot reset on 0-1 transition. */
@@ -297,6 +306,7 @@ void pci_bridge_reset(DeviceState *qdev)
{
PCIDevice *dev = PCI_DEVICE(qdev);
uint8_t *conf = dev-config;
+uint8_t oldbus = conf[PCI_SECONDARY_BUS];
conf[PCI_PRIMARY_BUS] = 0;
conf[PCI_SECONDARY_BUS] = 0;
@@ -329,6 +339,14 @@ void pci_bridge_reset(DeviceState *qdev)
pci_set_long(conf + PCI_PREF_LIMIT_UPPER32, 0);
pci_set_word(conf + PCI_BRIDGE_CONTROL, 0);
+
+if (oldbus) {
+PCIBus *sec_bus = pci_bridge_get_sec_bus(PCI_BRIDGE(dev));
+
+pci_for_each_device(sec_bus, pci_bus_num(sec_bus),
+device_listener_change_pci_bus_num,
+GINT_TO_POINTER(oldbus));
+}
}
/* default qdev initialization function for PCI-to-PCI bridge */
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index d4be92f..154b4c1 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -168,6 +168,8 @@ struct DeviceState {
struct DeviceListener {
void (*realize)(DeviceListener *listener, DeviceState *dev);
void (*unrealize)(DeviceListener *listener, DeviceState *dev);
+void (*change_pci_bus_num)(DeviceListener *listener, PCIDevice *d,
+ uint8_t oldbus);
QTAILQ_ENTRY(DeviceListener) link;
};
@@ -387,5 +389,6 @@ static inline bool qbus_is_hotpluggable(BusState *bus)
void device_listener_register(DeviceListener *listener);
void device_listener_unregister(DeviceListener *listener);
+void device_listener_change_pci_bus_num(PCIBus *b, PCIDevice *d, void *opaque);
#endif
--
1.8.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 for Xen 4.6 4/4] xl: enabling XL to set per-VCPU parameters of a domain for RTDS scheduler
On Mon, Jun 8, 2015 at 11:21 AM, Dario Faggioli
dario.faggi...@citrix.com wrote:
On Mon, 2015-05-25 at 19:11 -0500, Chong Li wrote:
Change main_sched_rtds and related output functions to support per-VCPU
settings
for xl sched-rtds tool.
Signed-off-by: Chong Li chong...@wustl.edu
Signed-off-by: Meng Xu men...@cis.upenn.edu
Signed-off-by: Sisu Xi xis...@gmail.com
---
tools/libxl/xl_cmdimpl.c | 261
+--
1 file changed, 230 insertions(+), 31 deletions(-)
You must be changing tools/libxl/xl_cmdtable.c as well, or new options
won't work (at least they won't show up in the command's help).
Yes, you are right. Without this change, the complete command help
doesn't show up. It'll be fixed in v3.
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -6120,76 +6186,209 @@ int main_sched_rtds(int argc, char **argv)
{
const char *dom = NULL;
const char *cpupool = NULL;
-int period = 0; /* period is in microsecond */
-int budget = 0; /* budget is in microsecond */
+
+int *vcpus = (int *)xmalloc(sizeof(int)); /* IDs of VCPUs that change */
+int *periods = (int *)xmalloc(sizeof(int)); /* period is in microsecond
*/
+int *budgets = (int *)xmalloc(sizeof(int)); /* budget is in microsecond
*/
+int vcpus_size = 1; /* size of vcpus array */
+int periods_size = 1; /* size of periods array */
+int budgets_size = 1; /* size of budgets array */
+int input_size = 0; /* number of the input param set (v, p, b) */
+bool flag_b = false;
+bool flag_p = false;
+bool flag_v = false;
bool opt_p = false;
bool opt_b = false;
-int opt, rc;
+bool opt_v = false;
+bool opt_o = false; /* get per-domain info instead of per-vcpu info */
+int opt, i;
+int rc = 0;
static struct option opts[] = {
{domain, 1, 0, 'd'},
{period, 1, 0, 'p'},
{budget, 1, 0, 'b'},
+{vcpu,1, 0, 'v'},
{cpupool, 1, 0, 'c'},
+{output, 1, 0, 'o'},
COMMON_LONG_OPTS,
{0, 0, 0, 0}
};
I don't like -o/--output as the name of the config switch for this.
Also, what is the semantic of passing -o, in case one has given
different parameters to each vcpus? What would the command print in that
case?
I think that, while it makes sense to have the interface in place for
the setting part, as a shortcut of setting all the parameters of all the
vcpus to the same values, for the getting and printing side of things,
it make much less sense.
I appreciate just now that this probably affect other bits of the
interface, as well as other interfaces, and I think we should handle it
consistently...
What do you think?
For example (although this belong to patch 3's review) what
libxl_domain_sched_params_get() does in the case I jus described?
Here, -o/--output is used for the users who only do per-dom
settings. In those cases, -o is provided to show per-dom parameters,
and the output is just the same as what the old RTDS tool does.
When -o is set, libxl_domain_sched_params_get() and
sched_rtds_domain_get() (both two functions in libxl.c) are called.
Without -o, then sched_rtds_domain_get() should be deleted because
it will never be touched. I'm also fine with that.
Chong
Regards,
Dario
--
This happens because I choose it to happen! (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK)
--
Chong Li
Department of Computer Science and Engineering
Washington University in St.louis
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 0/4] Fix device listener interface for PCI to PCI bridges
changes v1 to v2: Split v1 patch into 3. Added a BUG FIX patch (#1: exec: Do not use MemoryRegion after free). Technically this bug fix should be a separate patch, however this issue only seems to reproduce when this patch set is applied. Michael S. Tsirkin: You need some other API that makes sense, probably PCI specific. This is basically patch #2: Extend device listener interface... This is relying on undocumented assumptions and how specific firmware works. There's nothing special about bus number 255, and 0 is not very special either (except it happens to be the reset value). Dropped all checking of 0 and 255. Open question by Michael S. Tsirkin: On Thu, May 28, 2015 at 07:25:50AM -0400, Don Slutz wrote: ... It is not clear to me that the complexity of tracking bus visibility make sense. Clearly you do. Well what was the point of the change? To get config cycles that are valid that you do not get today. If you don't care that we get irrelevant config cycles why not just send them all to QEMU? That would need to be answered by Paul Durrant and/or other people (see below) We could broadcast config space ioreqs to all emulators, the problem is how do we know (in the case of a read) which emulator is actually the one supplying the data? At some level Xen needs to know who is implementing what. Paul Durrant So this patch set just adjusts Xen to correctly know the current set of PCI devices and their bus, device, and function. It does not attempt to calculate the visibility of the PCI devices. v1: Note: Right now hvmloader in Xen does not handle PCI to PCI bridges and so SeaBIOS does not have access to PCI device(s) on secondary buses. How ever domU can setup the secondary bus(es) and this patch will restore access to these PCI devices. Don Slutz (4): exec: Do not use MemoryRegion after free Extend device listener interface for PCI to PCI bridges xen: Add usage of device listener interface for PCI to PCI bridges xen: Fix map/unmap of pcidev to ioreq server exec.c | 8 -- hw/core/qdev.c | 7 ++ hw/pci/pci_bridge.c | 18 + include/hw/qdev-core.h | 3 +++ include/hw/xen/xen_common.h | 61 ++--- trace-events| 6 +++-- xen-hvm.c | 20 +-- 7 files changed, 102 insertions(+), 21 deletions(-) -- 1.8.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 58161: regressions - FAIL
flight 58161 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/58161/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt 11 guest-start fail REGR. vs. 53854 test-amd64-amd64-libvirt 11 guest-start fail REGR. vs. 53854 test-armhf-armhf-libvirt 11 guest-start fail REGR. vs. 53854 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt-xsm 11 guest-start fail like 53854 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 11 guest-start fail never pass version targeted for testing: libvirt 568aba88111541447e7d7163f7683f0daf2a684a baseline version: libvirt fd74e231751334b64af0934b680c5cc62f652453 People who touched revisions under test: Andrea Bolognani abolo...@redhat.com Boris Fiuczynski fiu...@linux.vnet.ibm.com Cole Robinson crobi...@redhat.com Daniel Hansel daniel.han...@linux.vnet.ibm.com Daniel P. Berrange berra...@redhat.com Daniel Veillard veill...@redhat.com Eric Blake ebl...@redhat.com Erik Skultety eskul...@redhat.com Jim Fehlig jfeh...@suse.com Jiri Denemark jdene...@redhat.com John Ferlan jfer...@redhat.com Ján Tomko jto...@redhat.com Kothapally Madhu Pavan k...@linux.vnet.ibm.com Laine Stump la...@laine.org Lubomir Rintel lkund...@v3.sk Luyao Huang lhu...@redhat.com Martin Kletzander mklet...@redhat.com Maxim Nestratov mnestra...@parallels.com Michal Privoznik mpriv...@redhat.com Nikolay Shirokovskiy nshirokovs...@parallels.com Pavel Fedin p.fe...@samsung.com Pavel Hrdina phrd...@redhat.com Peter Krempa pkre...@redhat.com Richard W.M. Jones rjo...@redhat.com Roman Bogorodskiy bogorods...@gmail.com Shivaprasad G Bhat sb...@linux.vnet.ibm.com Shivaprasad G Bhat shivaprasadb...@gmail.com Tony Krowiak aekro...@us.ibm.com Tony Krowiak akrow...@linux.vnet.ibm.com Viktor Mihajlovski mihaj...@linux.vnet.ibm.com Wang Yufei james.wangyu...@huawei.com Zhang Bo oscar.zhan...@huawei.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-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail 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 3296 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Clarifying the state of ARINC653 scheduler (and other components) in Xen 4.5 and beyond
On Mon, 2015-06-08 at 14:01 +0100, Lars Kurth wrote: On 8 Jun 2015, at 13:19, Ian Campbell ian.campb...@citrix.com wrote: In MAINTAINERS S: Supported means: Someone is actually paid to look after this., which I think is distinct from This works well enough that the project is happy to recommend it is used in production. It's a shame that Supported can be taken to mean both things. For reference Maintained is Someone actually looks after it.. Alternatively if someone can think of another way to express paid maintainer we could switch to that. And then there is of course the question what we do with ARINC653. Not sure we actually need to do something. The status in MAINTAINERS is consistent with the existing semantic, as there's actually people actively looking after the scheduler (and paid to do so, AFAIK). Wrt the wiki page, the best way of capturing the state of things is, basing on what's in there for the other schedulers, 'Supported' there too. The scheduler has a very limited scope, and is useful only in a handful of situations, and that's by design. But for those situations it works pretty well, AFAIK. Moreover, there is people in the community providing help to interested users on how to set it up (there has been a thread on xen-users about this rather recently). Whether we should recommend to use it in production, well, I think we could, of course for those people and only for them having a requirement for compliance with the ARINC653 standard, which certainly is not the most common thing around. Whether it's actually being used in production by anyone, I don't know... although they may not be allowed to say much/everything, maybe Robbie and Josh could comment on this... but is this that relevant? Regards, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] libxl: Add timestamp to the libxl driver log.
Signed-off-by: Anthony PERARD anthony.per...@citrix.com
---
src/libxl/libxl_conf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index 9b258ac..e845759 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -1541,7 +1541,7 @@ libxlDriverConfigNew(void)
cfg-logger =
(xentoollog_logger *)xtl_createlogger_stdiostream(cfg-logger_file,
- XTL_DEBUG, 0);
+ XTL_DEBUG, XTL_STDIOSTREAM_SHOW_DATE);
if (!cfg-logger) {
VIR_ERROR(_(cannot create logger for libxenlight, disabling driver));
goto error;
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 3/3] IB/ipath: use arch_phys_wc_add() and require PAT disabled
From: Luis R. Rodriguez mcg...@suse.com
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.
This is a worthy compromise given that the ipath device
driver powers the old HTX bus cards that only work in
AMD systems, while the newer IB/qib device driver
powers all PCI-e cards. The ipath device driver is
obsolete, hardware hard to find and because of this
this its a reasonable compromise to make to require
users of ipath to boot with nopat.
Acked-by: Doug Ledford dledf...@redhat.com
Cc: Doug Ledford dledf...@redhat.com
Cc: Andy Walls awa...@md.metrocast.net
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Sean Hefty sean.he...@intel.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
Cc: Mike Marciniszyn mike.marcinis...@intel.com
Cc: Roland Dreier rol...@purestorage.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Ingo Molnar mi...@elte.hu
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Ville Syrjälä syrj...@sci.fi
Cc: Mel Gorman mgor...@suse.de
Cc: Vlastimil Babka vba...@suse.cz
Cc: Borislav Petkov b...@suse.de
Cc: Davidlohr Bueso dbu...@suse.de
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: infinip...@intel.com
Cc: linux-r...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/infiniband/hw/ipath/Kconfig | 3 ++
drivers/infiniband/hw/ipath/ipath_driver.c| 18 +++
drivers/infiniband/hw/ipath/ipath_kernel.h| 4 +--
drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 43 ++-
4 files changed, 26 insertions(+), 42 deletions(-)
diff --git a/drivers/infiniband/hw/ipath/Kconfig
b/drivers/infiniband/hw/ipath/Kconfig
index 1d9bb11..8fe54ff 100644
--- a/drivers/infiniband/hw/ipath/Kconfig
+++ b/drivers/infiniband/hw/ipath/Kconfig
@@ -9,3 +9,6 @@ config INFINIBAND_IPATH
as IP-over-InfiniBand as well as with userspace applications
(in conjunction with InfiniBand userspace access).
For QLogic PCIe QLE based cards, use the QIB driver instead.
+
+ If you have this hardware you will need to boot with PAT disabled
+ on your x86-64 systems, use the nopat kernel parameter.
diff --git a/drivers/infiniband/hw/ipath/ipath_driver.c
b/drivers/infiniband/hw/ipath/ipath_driver.c
index bd0caed..441cfe5 100644
--- a/drivers/infiniband/hw/ipath/ipath_driver.c
+++ b/drivers/infiniband/hw/ipath/ipath_driver.c
@@ -42,6 +42,9 @@
#include linux/bitmap.h
#include linux/slab.h
#include linux/module.h
+#ifdef CONFIG_X86_64
+#include asm/pat.h
+#endif
#include ipath_kernel.h
#include ipath_verbs.h
@@ -395,6 +398,14 @@ static int ipath_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
unsigned long long addr;
u32 bar0 = 0, bar1 = 0;
+#ifdef CONFIG_X86_64
+ if (WARN(pat_enabled(),
+ipath needs PAT disabled, boot with nopat kernel
parameter\n)) {
+ ret = EINVAL;
+ goto bail;
+ }
+#endif
+
dd = ipath_alloc_devdata(pdev);
if (IS_ERR(dd)) {
ret = PTR_ERR(dd);
@@ -542,6 +553,7 @@ static int ipath_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
dd-ipath_kregbase = __ioremap(addr, len,
(_PAGE_NO_CACHE|_PAGE_WRITETHRU));
#else
+ /* XXX: split this properly to enable on PAT */
dd-ipath_kregbase = ioremap_nocache(addr, len);
#endif
@@ -587,12 +599,8 @@ static int ipath_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
ret = ipath_enable_wc(dd);
- if (ret) {
- ipath_dev_err(dd, Write combining not enabled
- (err %d): performance may be poor\n,
- -ret);
+ if (ret)
ret = 0;
- }
[Xen-devel] [linux-3.18 test] 58185: regressions - FAIL
flight 58185 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/58185/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 58064 REGR. vs. 57312 Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-xsm 3 host-install(3) broken in 57490 pass in 58185 test-armhf-armhf-xl-cubietruck 3 host-install(3) broken in 57490 pass in 58185 test-armhf-armhf-xl 3 host-install(3) broken in 57490 pass in 58185 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 18 guest-start/win.repeat fail in 57713 pass in 58185 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail in 58064 pass in 57788 test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail in 58146 pass in 58185 test-amd64-i386-libvirt 11 guest-start fail pass in 57490 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail pass in 57490 test-armhf-armhf-xl-sedf-pin 6 xen-bootfail pass in 57713 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail pass in 58064 test-armhf-armhf-xl-multivcpu 6 xen-boot fail pass in 58111 test-amd64-amd64-xl-qemut-win7-amd64 9 windows-install fail pass in 58146 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-xsm 3 host-install(3) broken in 57490 like 57312 test-armhf-armhf-xl-credit2 3 host-install(3) broken in 57490 like 57312 test-armhf-armhf-xl-sedf 6 xen-boot fail REGR. vs. 57312 test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail blocked in 57312 test-armhf-armhf-libvirt 11 guest-start fail blocked in 57312 test-armhf-armhf-xl-xsm 6 xen-boot fail blocked in 57312 test-armhf-armhf-xl-credit2 6 xen-boot fail blocked in 57312 test-amd64-amd64-xl-xsm 14 guest-localmigrate fail in 57490 blocked in 57312 test-amd64-i386-xl-xsm14 guest-localmigrate fail in 57490 blocked in 57312 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 12 guest-localmigrate fail in 57490 blocked in 57312 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail in 57490 blocked in 57312 test-armhf-armhf-xl-multivcpu 17 leak-check/check fail in 57490 blocked in 57312 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 12 guest-localmigrate fail in 57490 blocked in 57312 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail in 57490 blocked in 57312 test-amd64-amd64-xl-pvh-intel 11 guest-start fail in 57490 like 57312 test-armhf-armhf-libvirt-xsm 11 guest-start fail in 58064 blocked in 57312 test-amd64-amd64-libvirt-xsm 11 guest-start fail like 57312 test-armhf-armhf-libvirt-xsm 6 xen-boot fail like 57312 test-armhf-armhf-xl 6 xen-boot fail like 57312 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 12 migrate-support-check fail in 57490 never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail in 57490 never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-check fail in 57490 never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail in 57490 never pass test-armhf-armhf-xl-xsm 12 migrate-support-check fail in 57713 never pass test-armhf-armhf-xl 12 migrate-support-check fail in 57713 never pass test-armhf-armhf-xl-credit2 12 migrate-support-check fail in 57713 never pass test-armhf-armhf-libvirt 12 migrate-support-check fail in 58111 never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail in 58111 never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 13 guest-saverestorefail never pass test-amd64-i386-freebsd10-i386 9 freebsd-install fail never pass test-amd64-i386-freebsd10-amd64 9 freebsd-install fail never pass test-amd64-i386-libvirt-xsm 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-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 6 xen-boot fail never pass version targeted for testing: linux51af817611f2c0987030d024f24fc7ea95dd33e6 baseline version: linuxb2776bf7149bddd1f4161f14f79520f17fc1d71d 900 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-armhf-xsm
Re: [Xen-devel] [PATCH v2 COLOPre 03/13] libxc/restore: zero ioreq page only one time
On 06/08/2015 06:15 PM, Andrew Cooper wrote: On 08/06/15 10:58, Yang Hongyang wrote: On 06/08/2015 05:46 PM, Andrew Cooper wrote: On 08/06/15 04:43, Yang Hongyang wrote: ioreq page contains evtchn which will be set when we resume the secondary vm the first time. The hypervisor will check if the evtchn is corrupted, so we cannot zero the ioreq page more than one time. The ioreq-state is always STATE_IOREQ_NONE after the vm is suspended, so it is OK if we only zero it one time. Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com Signed-off-by: Wen congyang we...@cn.fujitsu.com CC: Andrew Cooper andrew.coop...@citrix.com The issue here is that we are running the restore algorithm over a domain which has already been running in Xen for a while. This is a brand new usecase, as far as I am aware. Exactly. Does the qemu process associated with this domain get frozen while the secondary is being reset, or does the process get destroyed and recreated. What do you mean by reset? do you mean secondary is suspended at checkpoint? Well - at the point that the buffered records are being processed, we are in the process of resetting the state of the secondary to match the primary. Yes, at this point, the qemu process associated with this domain is frozen. the suspend callback will call libxl__qmp_stop(vm_stop() in qemu) to pause qemu. After we processed all records, qemu will be restored with the received state, that's why we add a libxl__qmp_restore(qemu_load_vmstate() in qemu) api to restore qemu with received state. Currently in libxl, qemu only start with the received state, there's no api to load received state while qemu is running for a while. ~Andrew I have a gut feeling that it would be safer to clear all of the page other than the event channel, but that depends on exactly what else is going on. We absolutely don't want to do is have an update to this page from the primary with an in-progress IOREQ. ~Andrew --- tools/libxc/xc_sr_restore_x86_hvm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/libxc/xc_sr_restore_x86_hvm.c b/tools/libxc/xc_sr_restore_x86_hvm.c index 6f5af0e..06177e0 100644 --- a/tools/libxc/xc_sr_restore_x86_hvm.c +++ b/tools/libxc/xc_sr_restore_x86_hvm.c @@ -78,7 +78,8 @@ static int handle_hvm_params(struct xc_sr_context *ctx, break; case HVM_PARAM_IOREQ_PFN: case HVM_PARAM_BUFIOREQ_PFN: -xc_clear_domain_page(xch, ctx-domid, entry-value); +if ( !ctx-restore.buffer_all_records ) +xc_clear_domain_page(xch, ctx-domid, entry-value); break; } . . -- Thanks, Yang. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 58167: trouble: broken/fail/pass
flight 58167 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/58167/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-rumpuserxen-amd64 3 host-install(3) broken REGR. vs. 58128 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken REGR. vs. 58128 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 58128 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 58128 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 58128 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 3 host-install(3) broken REGR. vs. 58128 test-amd64-i386-libvirt 11 guest-start fail like 58128 test-amd64-amd64-libvirt 11 guest-start fail like 58128 test-amd64-i386-freebsd10-amd64 9 freebsd-install fail like 58128 test-amd64-i386-freebsd10-i386 9 freebsd-install fail like 58128 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 58128 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 58128 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 13 guest-saverestorefail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 11 guest-start fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail 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-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-libvirt 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 version targeted for testing: linuxd4a4f75cd8f29cd9464a5a32e9224a91571d6649 baseline version: linux37ef1647b7f73d4ff4c7993984599b6c4f26443a People who touched revisions under test: Alban Bedel al...@free.fr Huacai Chen che...@lemote.com James Hogan james.ho...@imgtec.com Jonas Gorski j...@openwrt.org Joshua Kinard ku...@gentoo.org Linus Torvalds torva...@linux-foundation.org Maciej W. Rozycki ma...@linux-mips.org Markos Chandras markos.chand...@imgtec.com Nicholas Mc Guire hof...@osadl.org Ralf Baechle r...@linux-mips.org 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-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-xsmpass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm broken test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm
[Xen-devel] [PATCH v6 1/3] ivtv: use arch_phys_wc_add() and require PAT disabled
From: Luis R. Rodriguez mcg...@suse.com
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.
This is a worthy comprmise given that the hardware is
really rare these days, and perhaps only some lost souls
in some third world country are expected to be using this
feature of the device driver.
Acked-by: Andy Walls awa...@md.metrocast.net
Cc: Andy Walls awa...@md.metrocast.net
Cc: Doug Ledford dledf...@redhat.com
Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: Ville Syrjälä syrj...@sci.fi
Cc: Mel Gorman mgor...@suse.de
Cc: Vlastimil Babka vba...@suse.cz
Cc: Borislav Petkov b...@suse.de
Cc: Davidlohr Bueso dbu...@suse.de
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-me...@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/media/pci/ivtv/Kconfig | 3 +++
drivers/media/pci/ivtv/ivtvfb.c | 58 -
2 files changed, 26 insertions(+), 35 deletions(-)
diff --git a/drivers/media/pci/ivtv/Kconfig b/drivers/media/pci/ivtv/Kconfig
index dd6ee57e..b2a7f88 100644
--- a/drivers/media/pci/ivtv/Kconfig
+++ b/drivers/media/pci/ivtv/Kconfig
@@ -57,5 +57,8 @@ config VIDEO_FB_IVTV
This is used in the Hauppauge PVR-350 card. There is a driver
homepage at http://www.ivtvdriver.org.
+ If you have this hardware you will need to boot with PAT disabled
+ on your x86 systems, use the nopat kernel parameter.
+
To compile this driver as a module, choose M here: the
module will be called ivtvfb.
diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 9ff1230..7685ae3 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -44,8 +44,8 @@
#include linux/ivtvfb.h
#include linux/slab.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
+#ifdef CONFIG_X86_64
+#include asm/pat.h
#endif
#include ivtv-driver.h
@@ -155,12 +155,11 @@ struct osd_info {
/* Buffer size */
u32 video_buffer_size;
-#ifdef CONFIG_MTRR
/* video_base rounded down as required by hardware MTRRs */
unsigned long fb_start_aligned_physaddr;
/* video_base rounded up as required by hardware MTRRs */
unsigned long fb_end_aligned_physaddr;
-#endif
+ int wc_cookie;
/* Store the buffer offset */
int set_osd_coords_x;
@@ -1099,6 +1098,8 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
static int ivtvfb_init_io(struct ivtv *itv)
{
struct osd_info *oi = itv-osd_info;
+ /* Find the largest power of two that maps the whole buffer */
+ int size_shift = 31;
mutex_lock(itv-serialize_lock);
if (ivtv_init_on_first_open(itv)) {
@@ -1132,29 +1133,16 @@ static int ivtvfb_init_io(struct ivtv *itv)
oi-video_pbase, oi-video_vbase,
oi-video_buffer_size / 1024);
-#ifdef CONFIG_MTRR
- {
- /* Find the largest power of two that maps the whole buffer */
- int size_shift = 31;
-
- while (!(oi-video_buffer_size (1 size_shift))) {
- size_shift--;
- }
- size_shift++;
- oi-fb_start_aligned_physaddr = oi-video_pbase ~((1
size_shift) - 1);
- oi-fb_end_aligned_physaddr = oi-video_pbase +
oi-video_buffer_size;
- oi-fb_end_aligned_physaddr += (1 size_shift) - 1;
- oi-fb_end_aligned_physaddr = ~((1 size_shift) - 1);
- if (mtrr_add(oi-fb_start_aligned_physaddr,
- oi-fb_end_aligned_physaddr -
oi-fb_start_aligned_physaddr,
-
Re: [Xen-devel] [PATCH v6 0/2] kconfig: add xenconfig
On Thu, May 28, 2015 at 2:50 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: On Thu, May 21, 2015 at 11:32 AM, Luis R. Rodriguez mcg...@suse.com wrote: On Thu, May 21, 2015 at 04:20:27PM +0800, Michal Marek wrote: Dne 21.5.2015 v 02:53 Luis R. Rodriguez napsal(a): From: Luis R. Rodriguez mcg...@suse.com Michal Marek, Xen folks (David Vrabel, Konrad, Ian), which tree should these go through? Not kbuild, if I may ask :). Otherwise people will find me in get_maintainer.pl output and keep CCing me on updates to the xen.config files, which is something I am not at all familiar with. As you wish :) David, Konrad, Ian, Michal prefers this to go through the Xen tree. Please let me know if there any issues with the patches. Hey folks, any feedback? Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 COLO 06/15] libxc/save: support COLO save
On 06/08/2015 09:04 PM, Andrew Cooper wrote:
On 08/06/15 04:45, Yang Hongyang wrote:
call callbacks-get_dirty_pfn() after suspend primary vm to
get dirty pages on secondary vm, and send pages both dirty on
primary/secondary to secondary.
Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
CC: Andrew Cooper andrew.coop...@citrix.com
---
tools/libxc/xc_sr_save.c | 49 +++-
1 file changed, 48 insertions(+), 1 deletion(-)
diff --git a/tools/libxc/xc_sr_save.c b/tools/libxc/xc_sr_save.c
index d63b783..cda61ed 100644
--- a/tools/libxc/xc_sr_save.c
+++ b/tools/libxc/xc_sr_save.c
@@ -515,6 +515,31 @@ static int send_memory_live(struct xc_sr_context *ctx)
return rc;
}
+static int update_dirty_bitmap(uint8_t *(*get_dirty_pfn)(void *), void *data,
+ unsigned long p2m_size, unsigned long *bitmap)
This function should take a ctx rather than having the caller expand 3
parameters. Also, update_dirty_bitmap is a little misleading, as it
isn't querying the hypervisor for the dirty bitmap.
ok.
+{
+uint64_t *pfn_list;
+uint64_t count, i;
+uint64_t pfn;
+
+pfn_list = (uint64_t *)get_dirty_pfn(data);
This looks like a recipe for width-errors. The get_dirty_pfn() call
should take a pointer to a struct for it to fill.
but the size is unknown for the caller.pfn_list[0] is the count of
pfn.
+assert(pfn_list);
This should turn into an error rather than an abort().
Even if there are no dirty pages on secondary, pfn_list shouldn't be
NULL, it's just that pfn_list[0] will be 0. if pfn_list is NULL,
there might be unexpected error happened.
+
+count = pfn_list[0];
+for (i = 0; i count; i++) {
style
+pfn = pfn_list[i + 1];
+if (pfn p2m_size) {
+errno = EINVAL;
+return -1;
+}
+
+set_bit(pfn, bitmap);
+}
+
+free(pfn_list);
+return 0;
+}
+
/*
* Suspend the domain and send dirty memory.
* This is the last iteration of the live migration and the
@@ -555,6 +580,19 @@ static int suspend_and_send_dirty(struct xc_sr_context
*ctx)
bitmap_or(dirty_bitmap, ctx-save.deferred_pages, ctx-save.p2m_size);
+if ( !ctx-save.live ctx-save.callbacks-get_dirty_pfn )
+{
Shouldn't get_dirty_pfn be mandatory for COLO streams (even if it is a
noop to start with) ?
It should be mandatory, it shouldn't be noop under COLO. perhaps we should
add sanity check at the beginning. But problem is save side do not have a param
passed from libxl to indicate the stream type(like checkpointed_stream in
restore side). So we may need to add another XCFLAGS? Currently there is
XCFLAGS_CHECKPOINTED which represents Remus, we might need to change this to
XCFLAGS_STREAM_REMUS
XCFLAGS_STREAM_COLO
so that we can know what kind of stream we are handling?
~Andrew
+rc = update_dirty_bitmap(ctx-save.callbacks-get_dirty_pfn,
+ ctx-save.callbacks-data,
+ ctx-save.p2m_size,
+ dirty_bitmap);
+if ( rc )
+{
+PERROR(Failed to get secondary vm's dirty pages);
+goto out;
+}
+}
+
rc = send_dirty_pages(ctx, stats.dirty_count +
ctx-save.nr_deferred_pages);
if ( rc )
goto out;
@@ -784,7 +822,16 @@ static int save(struct xc_sr_context *ctx, uint16_t
guest_type)
if ( rc )
goto err;
-ctx-save.callbacks-postcopy(ctx-save.callbacks-data);
+rc = ctx-save.callbacks-postcopy(ctx-save.callbacks-data);
+if ( !rc ) {
+if ( !errno )
+{
+/* Postcopy request failed (without errno, using EINVAL) */
+errno = EINVAL;
+}
+rc = -1;
+goto err;
+}
rc = ctx-save.callbacks-checkpoint(ctx-save.callbacks-data);
if ( rc = 0 )
.
--
Thanks,
Yang.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 COLO 06/15] libxc/save: support COLO save
On 06/08/2015 09:04 PM, Andrew Cooper wrote:
On 08/06/15 04:45, Yang Hongyang wrote:
call callbacks-get_dirty_pfn() after suspend primary vm to
get dirty pages on secondary vm, and send pages both dirty on
primary/secondary to secondary.
Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
CC: Andrew Cooper andrew.coop...@citrix.com
---
tools/libxc/xc_sr_save.c | 49 +++-
1 file changed, 48 insertions(+), 1 deletion(-)
diff --git a/tools/libxc/xc_sr_save.c b/tools/libxc/xc_sr_save.c
index d63b783..cda61ed 100644
--- a/tools/libxc/xc_sr_save.c
+++ b/tools/libxc/xc_sr_save.c
@@ -515,6 +515,31 @@ static int send_memory_live(struct xc_sr_context *ctx)
return rc;
}
+static int update_dirty_bitmap(uint8_t *(*get_dirty_pfn)(void *), void *data,
+ unsigned long p2m_size, unsigned long *bitmap)
This function should take a ctx rather than having the caller expand 3
parameters. Also, update_dirty_bitmap is a little misleading, as it
isn't querying the hypervisor for the dirty bitmap.
how about merge_secondary_dirty_bitmap()?
+{
+uint64_t *pfn_list;
+uint64_t count, i;
+uint64_t pfn;
+
+pfn_list = (uint64_t *)get_dirty_pfn(data);
This looks like a recipe for width-errors. The get_dirty_pfn() call
should take a pointer to a struct for it to fill.
+assert(pfn_list);
This should turn into an error rather than an abort().
+
+count = pfn_list[0];
+for (i = 0; i count; i++) {
style
+pfn = pfn_list[i + 1];
+if (pfn p2m_size) {
+errno = EINVAL;
+return -1;
+}
+
+set_bit(pfn, bitmap);
+}
+
+free(pfn_list);
+return 0;
+}
+
/*
* Suspend the domain and send dirty memory.
* This is the last iteration of the live migration and the
@@ -555,6 +580,19 @@ static int suspend_and_send_dirty(struct xc_sr_context
*ctx)
bitmap_or(dirty_bitmap, ctx-save.deferred_pages, ctx-save.p2m_size);
+if ( !ctx-save.live ctx-save.callbacks-get_dirty_pfn )
+{
Shouldn't get_dirty_pfn be mandatory for COLO streams (even if it is a
noop to start with) ?
~Andrew
+rc = update_dirty_bitmap(ctx-save.callbacks-get_dirty_pfn,
+ ctx-save.callbacks-data,
+ ctx-save.p2m_size,
+ dirty_bitmap);
+if ( rc )
+{
+PERROR(Failed to get secondary vm's dirty pages);
+goto out;
+}
+}
+
rc = send_dirty_pages(ctx, stats.dirty_count +
ctx-save.nr_deferred_pages);
if ( rc )
goto out;
@@ -784,7 +822,16 @@ static int save(struct xc_sr_context *ctx, uint16_t
guest_type)
if ( rc )
goto err;
-ctx-save.callbacks-postcopy(ctx-save.callbacks-data);
+rc = ctx-save.callbacks-postcopy(ctx-save.callbacks-data);
+if ( !rc ) {
+if ( !errno )
+{
+/* Postcopy request failed (without errno, using EINVAL) */
+errno = EINVAL;
+}
+rc = -1;
+goto err;
+}
rc = ctx-save.callbacks-checkpoint(ctx-save.callbacks-data);
if ( rc = 0 )
.
--
Thanks,
Yang.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.4 test] 58178: regressions - trouble: broken/fail/pass
flight 58178 linux-3.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/58178/ 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-i386-qemut-rhel6hvm-amd 3 host-install(3) broken blocked in 56366-bisect test-amd64-i386-libvirt 9 debian-installfail blocked in 56366-bisect test-amd64-amd64-xl-sedf 9 debian-installfail blocked in 56366-bisect test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-libvirt 9 debian-installfail 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 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-amd64-rumpuserxen-amd64 6 xen-bootfail blocked in 56366-bisect test-amd64-i386-qemut-rhel6hvm-intel 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-i386-freebsd10-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-i386-xl-qemuu-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-amd64-xl-multivcpu 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-rumpuserxen-i386 6 xen-boot 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-libvirt-xsm 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-bootfail blocked in 56366-bisect test-amd64-amd64-xl-qemut-winxpsp3 6 xen-bootfail blocked in 56366-bisect test-amd64-i386-freebsd10-i386 6 xen-bootfail blocked in 56366-bisect test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop 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-amd64-xl-sedf-pin 9 debian-installfail blocked in 56366-bisect test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-bootfail like 53709-bisect Tests which did not succeed, but are not blocking: test-amd64-i386-xl-xsm9 debian-install fail never pass test-amd64-amd64-xl-credit2 9 debian-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-pvh-amd 9 debian-install fail never pass test-amd64-amd64-xl-xsm 9 debian-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-xsmpass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm
Re: [Xen-devel] [OSSTEST Nested PATCH v11 4/7] Changes on test step of Debian hvm guest install
-Original Message-
From: Ian Campbell [mailto:ian.campb...@citrix.com]
Sent: Monday, June 08, 2015 6:31 PM
To: Pang, LongtaoX
Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; wei.l...@citrix.com;
Hu,
Robert
Subject: Re: [OSSTEST Nested PATCH v11 4/7] Changes on test step of Debian hvm
guest install
On Tue, 2015-05-26 at 17:08 +0800, longtao.pang wrote:
1. The default disk size for guest is '1M' which is not sufficient
for nested HVM guest, using larger disk size for nested guest
to accommodate to nested test requirement, the specific disk_size is
defined by make-flight.
2. In L1 installation context, assign more memory (defined in runvar) to
it; Since it acts as a nested hypervisor anyway.
3. Comment out CDROM entry in sources.list to make HTTP URL entry
available for L1 hvm guest.
4. Enable nestedhvm feature in 'ExtraConfig' for nested job.
Signed-off-by: longtao.pang longtaox.p...@intel.com
Acked-by: Ian Campbell ian.campb...@citrix.com
One query:
[...]
@@ -174,13 +185,18 @@ sub prep () {
if ($host_freemem_mb $ram_lots * 2 + $ram_minslop) {
$ram_mb = $ram_lots;
} else {
-$ram_mb = 768;
+# Use guest_var to get specific memsize, or will use default '768'
+$ram_mb= guest_var($gho,'memsize',768);
I think this only happens if the host has less than $ram_lots * 2 +
$ram_minslop (==10100M) free, otherwise you get $ram_lots (5000M),
which might be less than the runvar asked for...
For nested job, the specific 'memsize' for L1 guest is 3072M which is defined
by make-flight.
If the $ram_lots equal to 5000M which is larger than 3072M, that's suitable
for nested L1 guest.
The condition for nested L1 guest's memory size that should not be less than
3072M, that's why we
add the code of $ram_mb =guest_var($gho,'memsize',768) here.
Perhaps what we really want (maybe in a followup patch is):
$ram_mb = guest_var($gho,'memsize',undef);
if (!$ram_mb) {
if ($host_freemem_mb $ram_lots * 2 + $ram_minslop) {
$ram_mb = $ram_lots;
} else {
$ram_mb = 768;
}
}
?
So, I think maybe it's no need to change that.
Please correct me, if I am wrong.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC][v2][PATCH 08/14] tools: extend xc_assign_device() to support rdm reservation policy
On 2015/6/7 19:27, Wei Liu wrote: On Wed, Jun 03, 2015 at 10:58:31AM +0800, Chen, Tiejun wrote: On 2015/6/3 0:36, Wei Liu wrote: On Fri, May 22, 2015 at 05:35:08PM +0800, Tiejun Chen wrote: This patch passes rdm reservation policy to xc_assign_device() so the policy is checked when assigning devices to a VM. Signed-off-by: Tiejun Chen tiejun.c...@intel.com --- tools/libxc/include/xenctrl.h | 3 ++- tools/libxc/xc_domain.c | 4 +++- tools/libxl/libxl_pci.c | 11 ++- tools/libxl/xl_cmdimpl.c| 23 +++ tools/libxl/xl_cmdtable.c | 2 +- Where is document for the new options you added to xl pci commands? Looks I'm missing to describe something specific to pci-attach? diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1 index 4eb929d..2ebfd54 100644 --- a/docs/man/xl.pod.1 +++ b/docs/man/xl.pod.1 @@ -1368,10 +1368,15 @@ it will also attempt to re-bind the device to its original driver, making it usable by Domain 0 again. If the device is not bound to pciback, it will return success. -=item Bpci-attach Idomain-id IBDF +=item Bpci-attach Idomain-id IBDF Irdm policy The way you put it here suggests that rdm policy is mandatory. I don't think this is the case? If it is not mandatory, write [Irdm]. Yes, thanks for you correction. Hot-plug a new pass-through pci device to the specified domain. BBDF is the PCI Bus/Device/Function of the physical device to pass-through. +Brdm policy is about how to handle conflict between reserving reserved device +memory and guest address space. strict means an unsolved conflict leads to +immediate VM crash, while relaxed allows VM moving forward with a warning +message thrown out. Here strict is default. + =item Bpci-detach [I-f] Idomain-id IBDF BTW you might want to consider rearrange patches in this series so that Yes, this is really what I intend to do. you keep the tree bisectable. Overall, I can separate this series as several parts, #1. Introduce our policy configuration on tools side #2. Interact with Hypervisor to get rdm info #3. Implement our policy with rdm info on tool side #4. Make hvmloader to align our policy If you already see something obviously wrong, let me know. I think all toolstack patches should come after hypervisor and hvmloader patches. And then within toolstack patches, libxc patches should come before libxl patches, libxl patches should come before xl patches. The pattern is clear. Patches that are late in the series make use of functionalities provided by early patches. Breaking this pattern is definitely going to break bisection. I tried to rearrange these patches as follows: #1. hypervisor 0001-xen-introduce-XENMEM_reserved_device_memory_map.patch 0002-xen-x86-p2m-introduce-set_identity_p2m_entry.patch 0003-xen-vtd-create-RMRR-mapping.patch 0004-xen-passthrough-extend-hypercall-to-support-rdm-rese.patch 0005-xen-enable-XENMEM_memory_map-in-hvm.patch #2. hvmloader 0006-hvmloader-get-guest-memory-map-into-memory_map.patch 0007-hvmloader-pci-skip-reserved-ranges.patch 0008-hvmloader-e820-construct-guest-e820-table.patch #3. tools/libxc 0009-tools-libxc-Expose-new-hypercall-xc_reserved_device_.patch 0010-tools-extend-xc_assign_device-to-support-rdm-reserva.patch 0011-tools-introduce-some-new-parameters-to-set-rdm-polic.patch #4. tools/linxl 0012-tools-libxl-passes-rdm-reservation-policy.patch 0013-tools-libxl-detect-and-avoid-conflicts-with-RDM.patch 0014-tools-libxl-extend-XENMEM_set_memory_map.patch #5. Misc 0015-xen-vtd-enable-USB-device-assignment.patch 0016-xen-vtd-prevent-from-assign-the-device-with-shared-r.patch Thanks Tiejun ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-next test] 58175: regressions - trouble: broken/fail/pass
flight 58175 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/58175/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-rumpuserxen-amd64 3 host-install(3) broken REGR. vs. 57931 test-amd64-amd64-xl-credit2 3 host-install(3) broken REGR. vs. 57931 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 57931 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken REGR. vs. 57931 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken REGR. vs. 57931 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 57931 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-libvirt 11 guest-start fail like 57931 test-amd64-i386-freebsd10-amd64 9 freebsd-install fail like 57931 test-amd64-i386-freebsd10-i386 9 freebsd-install fail like 57931 test-amd64-i386-libvirt 11 guest-start fail like 57931 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 57931 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 57931 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 57931 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 13 guest-saverestorefail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass version targeted for testing: linux68840022ea0c98a770ecd1965ade4d8ca27bc62f baseline version: linuxff25ea8f4eeea252bfcaf65289fa57ba6de080dd 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-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-xsmpass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-armhf-armhf-xl-xsm pass test-amd64-i386-xl-xsm 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
Re: [Xen-devel] [PATCHv11 4/4] gnttab: use per-VCPU maptrack free lists
On 05.06.15 at 18:42, david.vra...@citrix.com wrote: On 05/06/15 17:11, Jan Beulich wrote: On 05.06.15 at 17:55, david.vra...@citrix.com wrote: On 05/06/15 15:51, Jan Beulich wrote: On 02.06.15 at 18:26, david.vra...@citrix.com wrote: +/* + * max_maptrack_frames is per domain so each VCPU gets a share of + * the maximum, but allow at least one frame per VCPU. + */ +if ( v-maptrack_frames + v-maptrack_frames = max_maptrack_frames / v-domain-max_vcpus ) +return -1; So with e.g. max_maptrack_frames being 256 and -max_vcpus being 129 you'd potentially allow each vCPU to only have exactly one page despite there being 127 more to use. There's a limit to how many wacky combinations we can support with a single default limit. With the standard defaults and 129 VCPUs: Before 131072 entries (256 * 4096 / 8) After 231168 entries (1024 / 129 * 129 * 4096 / 16) 1792 entries per vcpu. And that's why I'm putting the currently proposed resource management model under question. The new default of 1024 frames ensures that with any number of VCPUs results in the domain having /more/ entries than then old default (256 frames). It's not at all clear what you want here. Can you provide a proposal? There being more frames per domain doesn't help a guest e.g. first doing one or more mappings on each vCPU and then wanting to do very many mappings on a single vCPU. I think there needs to be a (slow) fallback path where using foreign vCPU-s' maptrack entries is possible. Or something else to avoid regressing in scenarios that work prior to your change. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register
On 07.06.15 at 08:23, m...@redhat.com wrote: On Mon, Apr 20, 2015 at 04:32:12PM +0200, Michael S. Tsirkin wrote: On Mon, Apr 20, 2015 at 03:08:09PM +0100, Jan Beulich wrote: On 20.04.15 at 15:43, m...@redhat.com wrote: On Mon, Apr 13, 2015 at 01:51:06PM +0100, Jan Beulich wrote: On 13.04.15 at 14:47, m...@redhat.com wrote: Can you check device capabilities register, offset 0x4 within pci express capability structure? Bit 15 is 15 Role-Based Error Reporting. Is it set? The spec says: 15 On platforms where robust error handling and PC-compatible Configuration Space probing is required, it is suggested that software or firmware have the Unsupported Request Reporting Enable bit Set for Role-Based Error Reporting Functions, but clear for 1.0a Functions. Software or firmware can distinguish the two classes of Functions by examining the Role-Based Error Reporting bit in the Device Capabilities register. Yes, that bit is set. curiouser and curiouser. So with functions that do support Role-Based Error Reporting, we have this: With device Functions implementing Role-Based Error Reporting, setting the Unsupported Request Reporting Enable bit will not interfere with PC-compatible Configuration Space probing, assuming that the severity for UR is left at its default of non-fatal. However, setting the Unsupported Request Reporting Enable bit will enable the Function to report UR errors 97 detected with posted Requests, helping avoid this case for potential silent data corruption. I still don't see what the PC-compatible config space probing has to do with our issue. I'm not sure but I think it's listed here because it causes a ton of URs when device scan probes unimplemented functions. did firmware reconfigure this device to report URs as fatal errors then? No, the Unsupported Request Error Serverity flag is zero. OK, that's the correct configuration, so how come the box crashes when there's a UR then? Ping - any update on this? Not really. All we concluded so far is that _maybe_ the bridge, upon seeing the UR, generates a Master Abort, rendering the whole thing fatal. Otoh the respective root port also has - Received Master Abort set in its Secondary Status register (but that's also already the case in the log that we have before the UR occurs, i.e. that doesn't mean all that much), - Received System Error set in its Secondary Status register (and after the UR the sibling endpoint [UR originating from 83:00.0, sibling being 83:00.1] also shows Signaled System Error set). Do we can chalk this up to hardware bugs on a specific box? I have to admit that I'm still very uncertain whether to consider all this correct behavior, a firmware flaw, or a hardware bug. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] save restore failed when tmem enabled in Xen 4.1 Xen 4.3
Hi Andrew, Thank you for your reply! I do not know much about migration V2. Was it integrated to Xen? If integrated, from which version? Thank you!! Best Regards, Yunfang 2015-06-06 3:00 GMT+08:00 Andrew Cooper andrew.coop...@citrix.com: On 05/06/15 19:45, Konrad Rzeszutek Wilk wrote: On Thu, Jun 04, 2015 at 10:27:06PM +0800, yunfang tai wrote: Hi all, Hey! Recently, I am testing the TMEM support on Xen. I discovered that when enabled TMEM in ubuntu 14.10 as guest on Xen 4.1 Xen 4.3, xm save xm restore“ failed after there are more than 1000 pages put in persistent pool of TMEM in Xen. My operations are list as follows: Is it exactly 1000 or just about? I presume it does not matter how much but that you discovered it by having 1000 of them? In ubuntu guest (8 cores , 8GB): sudo modprobe tmem (than wait for the selfballoon to finish) dd if=/dev/zero of=/tmp/test.img bs=10M count=1000 dd if=/tmp/test.img of=/dev/null bs=10M dd if=/tmp/test.img of=/dev/null bs=10M . (until more than 1000 pages put in persistent pool) In Domain 0: (add tmem in grub.cfg) xm save ubuntu test.save xm restore ubuntu test.save When TMEM is not enabled, save restore success after these operations. But if TMEM is enabled, save restore fail. Are there any errors from the logs? Anything? Does anyone test about save restore when enabled TMEM in Xen?? Is there anything I do wrong? Well lets see what broke. But I think Andrew discovered that the migration protocol when it came to 'tmem' was not up to snuff. CC-ing him just to confirm. (Andrew, for the persistent part of this - it conceptually should get all of the tmem memory that pushed to the hypervisor back in the image. When you were looking at migrationv2 did you just skim through that or mostly ignored it?) Took a look at the code, attempted to figure out what was going on, then decided to ignore it for the time being. As a baseline, there is no error checking of hypercalls or their returned data putting the data into the stream. Migration v2 currently has no TMEM support, and I would suggest re-implementing it from scratch over attempting to port what currently exists for legacy. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] PCI Passthrough ARM Design : Draft1
PCI Pass-through in Xen ARM
--
Index
1. Background
2. Basic PCI Support in Xen ARM
2.1 pci_hostbridge and pci_hostbridge_ops
2.2 PHYSDEVOP_pci_host_bridge_add hypercall
3. Dom0 Access PCI devices
4. DomU assignment of PCI device
5. NUMA and PCI passthrough
6. DomU pci device attach flow
1. Background of PCI passthrough
Passthrough refers to assigning a pci device to a guest domain (domU)
such that
the guest has full control over the device.The MMIO space and interrupts
are
managed by the guest itself, close to how a bare kernel manages a device.
Device's access to guest address space needs to be isolated and
protected. SMMU
(System MMU - IOMMU in ARM) is programmed by xen hypervisor to allow device
access guest memory for data transfer and sending MSI/X interrupts. In
case of
MSI/X the device writes to GITS (ITS address space) Interrupt Translation
Register.
2. Basic PCI Support for ARM
The apis to read write from pci configuration space are based on
segment:bdf.
How the sbdf is mapped to a physical address is under the realm of the pci
host controller.
ARM PCI support in Xen, introduces pci host controller similar to what
exists
in Linux. Each drivers registers callbacks, which are invoked on
matching the
compatible property in pci device tree node.
2.1:
The init function in the pci host driver calls to register hostbridge
callbacks:
int pci_hostbridge_register(pci_hostbridge_t *pcihb);
struct pci_hostbridge_ops {
u32 (*pci_conf_read)(struct pci_hostbridge*, u32 bus, u32 devfn,
u32 reg, u32 bytes);
void (*pci_conf_write)(struct pci_hostbridge*, u32 bus, u32 devfn,
u32 reg, u32 bytes, u32 val);
};
struct pci_hostbridge{
u32 segno;
paddr_t cfg_base;
paddr_t cfg_size;
struct dt_device_node *dt_node;
struct pci_hostbridge_ops ops;
struct list_head list;
};
A pci conf read function would internally be as follows:
u32 pcihb_conf_read(u32 seg, u32 bus, u32 devfn,u32 reg, u32 bytes)
{
pci_hostbridge_t *pcihb;
list_for_each_entry(pcihb, pci_hostbridge_list, list)
{
if(pcihb-segno == seg)
return pcihb-ops.pci_conf_read(pcihb, bus, devfn, reg, bytes);
}
return -1;
}
2.2 PHYSDEVOP_pci_host_bridge_add hypercall
Xen code accesses PCI configuration space based on the sbdf received
from the
guest. The order in which the pci device tree node appear may not be the
same
order of device enumeration in dom0. Thus there needs to be a mechanism
to bind
the segment number assigned by dom0 to the pci host controller. The
hypercall
is introduced:
#define PHYSDEVOP_pci_host_bridge_add44
struct physdev_pci_host_bridge_add {
/* IN */
uint16_t seg;
uint64_t cfg_base;
uint64_t cfg_size;
};
This hypercall is invoked before dom0 invokes the PHYSDEVOP_pci_device_add
hypercall. The handler code invokes to update segment number in
pci_hostbridge:
int pci_hostbridge_setup(uint32_t segno, uint64_t cfg_base, uint64_t
cfg_size);
Subsequent calls to pci_conf_read/write are completed by the
pci_hostbridge_ops
of the respective pci_hostbridge.
3. Dom0 access PCI device
-
As per the design of xen hypervisor, dom0 enumerates the PCI devices.
For each
device the MMIO space has to be mapped in the Stage2 translation for
dom0. For
dom0 xen maps the ranges in pci nodes in stage 2 translation.
GITS_ITRANSLATER space (4k( must be programmed in Stage2 translation so
that MSI/X
must work. This is done in vits intitialization in dom0/domU.
4. DomU access / assignment PCI device
--
When a device is attached to a domU, provision has to be made such that
it can
access the MMIO space of the device and xen is able to identify the mapping
between guest bdf and system bdf. Two hypercalls are introduced
#define PHYSDEVOP_map_mmio 40
#define PHYSDEVOP_unmap_mmio41
struct physdev_map_mmio {
/* IN */
uint64_t addr;
uint64_t size;
};
Xen adds the mmio space to the stage2 translation for domU. The
restrction is
that xen creates 1:1 mapping of the MMIO address.
#define PHYSDEVOP_map_sbdf 43
struct physdev_map_sbdf {
int domain_id;
int sbdf_s;
int sbdf_b;
int sbdf_d;
int sbdf_f;
int gsbdf_s;
int gsbdf_b;
int gsbdf_d;
int gsbdf_f;
};
Each domain has a pdev list, which contains the list of all pci devices. The
pdev structure already has a sbdf information. The arch_pci_dev is
updated to
contain the gsbdf information. (gs- guest segment id)
Whenever there is trap from guest or an interrupt has to be injected,
the pdev
list is iterated to find the gsbdf.
Change in PCI ForntEnd - backend driver for MSI/X programming
-
On the Pci
Re: [Xen-devel] [PATCH v2 6/9] x86/intel_pstate: the main boby of the intel_pstate driver
On 08.06.15 at 03:47, wei.w.w...@intel.com wrote:
On 26/05/2015 21:58, Jan Beulich wrote
On 13.05.16 at 09:50, wei.w.w...@intel.com wrote:
+static int byt_get_min_pstate(void)
+{
+u64 value;
+
+rdmsrl(BYT_RATIOS, value);
+return (value 8) 0x7F;
+}
+
+static int byt_get_max_pstate(void)
+{
+u64 value;
+
+rdmsrl(BYT_RATIOS, value);
+return (value 16) 0x7F;
+}
+
+static int byt_get_turbo_pstate(void) {
+u64 value;
+
+rdmsrl(BYT_TURBO_RATIOS, value);
+return value 0x7F;
+}
+
+static void byt_set_pstate(struct cpudata *cpudata, int pstate) {
+u64 val;
+int32_t vid_fp;
+u32 vid;
+
+val = pstate 8;
+if (limits.no_turbo !limits.turbo_disabled)
+val |= (u64)1 32;
All of the literal numbers above (and there are more further down) would
better become self-documenting manifest constants.
I just realized that it would be better to remove these bay trail platform
related code. What do you think?
First of all - why? Unless these are 32-bit only systems, I don't see
why we wouldn't want to support Atoms at least on a best effort
basis. And if you consider removal of code present in Linux, then
this also needs to be done with the earlier mentioned as little
changes as possible compared to the Linux original in mind.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 58128: tolerable FAIL - PUSHED
flight 58128 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/58128/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-sedf-pin 6 xen-boot fail REGR. vs. 57931 test-amd64-i386-libvirt 11 guest-start fail like 57931 test-amd64-amd64-libvirt 11 guest-start fail like 57931 test-amd64-i386-freebsd10-amd64 9 freebsd-install fail like 57931 test-amd64-i386-freebsd10-i386 9 freebsd-install fail like 57931 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 57931 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 57931 test-armhf-armhf-libvirt 11 guest-start fail like 57931 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 13 guest-saverestorefail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 11 guest-start fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail 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-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass version targeted for testing: linux37ef1647b7f73d4ff4c7993984599b6c4f26443a baseline version: linuxff25ea8f4eeea252bfcaf65289fa57ba6de080dd People who touched revisions under test: Alex Deucher alexander.deuc...@amd.com Alexander Shishkin alexander.shish...@linux.intel.com Alexandre Courbot acour...@nvidia.com Alexei Starovoitov a...@plumgrid.com Alexey Skidanov alexey.skida...@amd.com Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com Andy Lutomirski l...@kernel.org Arek Rusniak arek.r...@gmail.com Arthur Demchenkov spinal...@gmail.com Arun Siluvery arun.siluv...@linux.intel.com Axel Lin axel@ingics.com Ben Hutchings b...@decadent.org.uk Bjorn Helgaas bhelg...@google.com Chris Bainbridge chris.bainbri...@gmail.com Chris Leech cle...@redhat.com Clemens Ladisch clem...@ladisch.de Dan Carpenter dan.carpen...@oracle.com Dave Airlie airl...@redhat.com Dave Martin dave.mar...@arm.com Dmitry Torokhov dmitry.torok...@gmail.com Don Zickus dzic...@redhat.com Eric Wong normalper...@yhbt.net Fabio Estevam fabio.este...@freescale.com Felipe Balbi ba...@ti.com Geert Uytterhoeven geert+rene...@glider.be Grant Likely grant.lik...@linaro.org Greg Kroah-Hartman gre...@linuxfoundation.org H. Peter Anvin h...@linux.intel.com Hans de Goede hdego...@redhat.com Helge Deller del...@gmx.de Ingo Molnar mi...@kernel.org Jan Beulich jbeul...@suse.com Jani Nikula jani.nik...@intel.com Jason A. Donenfeld ja...@zx2c4.com Jim Bride jim.br...@linux.intel.com Jingoo Han jingooh...@gmail.com Joerg Roedel jroe...@suse.de Johan Hovold jo...@kernel.org John D. Blair jo...@candicontrols.com Jonathan Cameron ji...@kernel.org Kailang Yang kail...@realtek.com Kazuya Mizuguchi kazuya.mizuguchi...@renesas.com Kishon Vijay Abraham I kis...@ti.com Konrad Rzeszutek Wilk konrad.w...@oracle.com Krzysztof Opasiak k.opas...@samsung.com Lars-Peter Clausen l...@metafoo.de Laura Abbott labb...@fedoraproject.org Linus Torvalds torva...@linux-foundation.org Mark Rutland mark.rutl...@arm.com Mark Tomlinson mark.tomlin...@alliedtelesis.co.nz Mathias Nyman mathias.ny...@linux.intel.com Michael Trimarchi mich...@amarulasolutions.com nightmixes nightmi...@gmail.com Oded Gabbay oded.gab...@gmail.com Patrick Riphagen patrick.ripha...@xsens.com Paul Cercueil paul.cercu...@analog.com Pawel Szewczyk p.szewc...@samsung.com Peter Zijlstra (Intel) pet...@infradead.org Peter Zijlstra pet...@infradead.org Philipp Zabel p.za...@pengutronix.de Pratyush Anand pratyush.an...@gmail.com Rob Herring r...@kernel.org Robert Schwebel r.schwe...@pengutronix.de Rui Miguel Silva rui.si...@linaro.org Russell King rmk+ker...@arm.linux.org.uk Sam Hung sam.h...@emc.com.tw Sebastian Andrzej Siewior bige...@linutronix.de Sergiy Kibrik sa...@meta.ua Stephen Boyd sb...@codeaurora.org
Re: [Xen-devel] [PATCH] xen/pass-through: ROM BAR handling adjustments
On 05.06.15 at 18:41, stefano.stabell...@eu.citrix.com wrote:
On Fri, 5 Jun 2015, Jan Beulich wrote:
On 05.06.15 at 13:32, stefano.stabell...@eu.citrix.com wrote:
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -248,7 +248,9 @@ static void xen_pt_pci_write_config(PCID
/* check unused BAR register */
index = xen_pt_bar_offset_to_index(addr);
-if ((index = 0) (val 0 val XEN_PT_BAR_ALLF)
+if ((index = 0) (val != 0)
+(((index != PCI_ROM_SLOT) ?
+ val : (val | (uint32_t)~PCI_ROM_ADDRESS_MASK)) !=
XEN_PT_BAR_ALLF)
The change seems looks good and in line with the commit message. But
this if statement looks like acrobatic circus to me now.
I think the alternative of splitting it up into multiple if()-s would not
be any better readable.
Would you be OK if I rewrote the statement as follows?
if ((index = 0) (val != 0)) {
uint32_t vu;
if (index == PCI_ROM_SLOT) {
vu = val | (uint32_t)~PCI_ROM_ADDRESS_MASK;
} else {
vu = val;
}
if ((vu != XEN_PT_BAR_ALLF)
(s-bases[index].bar_flag == XEN_PT_BAR_FLAG_UNUSED)) {
XEN_PT_WARN(d, Guest attempt to set address to unused Base
Address
Register. (addr: 0x%02x, len: %d)\n, addr, len);
}
}
Actually I agree that this indeed looks better. If I were to make the
change, I'd do
if ((index = 0) (val != 0)) {
uint32_t vu = val;
if (index == PCI_ROM_SLOT) {
vu |= (uint32_t)~PCI_ROM_ADDRESS_MASK;
}
if ((vu != XEN_PT_BAR_ALLF)
...
though. But if you're going to do the edit without wanting me to
re-submit, I'll certainly leave this to you. Just let me know which
way you prefer it to be handled.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (five months reminder, 5 WEEKS TO FREEZE)
From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] Sent: Friday, June 05, 2015 10:28 PM On 06/05/2015 09:53 AM, wei.l...@citrix.com wrote: * VPMU - 'perf' support in Xen (good) v21 posted Need reviews/final ack. - Boris Ostrovsky I posted a version last week with very few changes. Besides Jan's review I think it needs Intel's ACK on a few patches that touched VMX (Kevin, can you take a look at patches 4, 6, 10, 12 and 15 --- you probably already saw them before but I must have made some changes to them so I dropped your ACKs. Thanks.). No problem. I'll complete my review within this week. Thanks Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 57852: regressions - FAIL
On 05.06.15 at 12:48, ian.campb...@citrix.com wrote: On Fri, 2015-06-05 at 10:18 +0100, Jan Beulich wrote: On 05.06.15 at 11:07, ian.campb...@citrix.com wrote: WRT the move to the colo, flights in 5 are in the new one, while 3 are in the old one, http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64 -xl-qemuu-win7-amd64.xen-unstable.html shows that things seemed ok for 8 consecutive runs after the move (ignoring blockages). And when it went live, all systems being in use now got immediately deployed? All the flights in the new colo seem to have been on fiano[01]. So are there just two hosts to run all x86 tests on? I thought one of the purposes of the switch was to have a wider pool of test systems... But having looked at the page again the early success was all on fiano0 while the later failures were all on fiano1. But that's for the unstable install failures only as it looks. At the example of flight 57955 (testing 4.2) a local migration failure was observed on fiano0. Which would seem to support your earlier assumption that the install and migration issues are likely unrelated (yet their coincidence still strikes me as odd). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [rumpuserxen test] 58157: regressions - FAIL
flight 58157 rumpuserxen real [real] http://logs.test-lab.xenproject.org/osstest/logs/58157/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866 build-i386-rumpuserxen5 rumpuserxen-build fail REGR. vs. 33866 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a version targeted for testing: rumpuserxen 3b91e44996ea6ae1276bce1cc44f38701c53ee6f baseline version: rumpuserxen 30d72f3fc5e35cd53afd82c8179cc0e0b11146ad People who touched revisions under test: Antti Kantee po...@iki.fi Ian Jackson ian.jack...@eu.citrix.com Martin Lucina mar...@lucina.net Wei Liu l...@liuw.name jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-i386-rumpuserxen-i386 blocked 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 535 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline bisection] complete test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm
branch xen-unstable xen branch xen-unstable job test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm test guest-saverestore Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://git.qemu.org/qemu.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: qemuu git://git.qemu.org/qemu.git Bug introduced: a67bfbb9e41e089caec61384c625e8a61a5f270f Bug not present: 42d58e7c6760cb9c55627c28ae538e27dcf2f144 commit a67bfbb9e41e089caec61384c625e8a61a5f270f Merge: 42d58e7 489653b Author: Peter Maydell peter.mayd...@linaro.org Date: Tue Jun 2 18:23:28 2015 +0100 Merge remote-tracking branch 'remotes/armbru/tags/pull-monitor-2015-06-02' into staging Monitor patches # gpg: Signature made Tue Jun 2 09:16:07 2015 BST using RSA key ID EB918653 # gpg: Good signature from Markus Armbruster arm...@redhat.com # gpg: aka Markus Armbruster arm...@pond.sub.org * remotes/armbru/tags/pull-monitor-2015-06-02: (21 commits) monitor: Change return type of monitor_cur_is_qmp() to bool monitor: Rename monitor_ctrl_mode() to monitor_is_qmp() monitor: Turn int command_mode into bool in_command_mode monitor: Drop do_qmp_capabilities()'s superfluous QMP check monitor: Unbox Monitor member mc and rename to qmp monitor: Rename monitor_control_read(), monitor_control_event() monitor: Rename handle_user_command() to handle_hmp_command() monitor: Limit QError use to command handlers monitor: Inline monitor_has_error() into its only caller monitor: Wean monitor_protocol_emitter() off mon-error monitor: Propagate errors through invalid_qmp_mode() monitor: Propagate errors through qmp_check_input_obj() monitor: Propagate errors through qmp_check_client_args() monitor: Drop unused new HMP command interface monitor: Use trad. command interface for HMP pcie_aer_inject_error monitor: Use traditional command interface for HMP device_add monitor: Use traditional command interface for HMP drive_del monitor: Convert client_migrate_info to QAPI monitor: Improve and document client_migrate_info protocol error monitor: Clean up after previous commit ... Signed-off-by: Peter Maydell peter.mayd...@linaro.org commit 489653b5db17679fd61b740dd289c798bb25d7b9 Author: Markus Armbruster arm...@redhat.com Date: Fri Mar 6 20:01:05 2015 +0100 monitor: Change return type of monitor_cur_is_qmp() to bool Signed-off-by: Markus Armbruster arm...@redhat.com Reviewed-by: Eric Blake ebl...@redhat.com Reviewed-by: Luiz Capitulino lcapitul...@redhat.com commit 9f3982f2dcd96753d57d0ac64bd1ae3b37a90eb3 Author: Markus Armbruster arm...@redhat.com Date: Fri Mar 6 19:56:38 2015 +0100 monitor: Rename monitor_ctrl_mode() to monitor_is_qmp() ... and change return type to bool. Signed-off-by: Markus Armbruster arm...@redhat.com Reviewed-by: Eric Blake ebl...@redhat.com Reviewed-by: Luiz Capitulino lcapitul...@redhat.com commit f994b2587f081693b017ebd03b362d162d3108b3 Author: Markus Armbruster arm...@redhat.com Date: Fri Mar 6 19:51:51 2015 +0100 monitor: Turn int command_mode into bool in_command_mode While there, inline the pointless qmp_cmd_mode() wrapper. Signed-off-by: Markus Armbruster arm...@redhat.com Reviewed-by: Eric Blake ebl...@redhat.com Reviewed-by: Luiz Capitulino lcapitul...@redhat.com commit 6a50636f35ba677c747f2f6127b0dba994b039ca Author: Markus Armbruster arm...@redhat.com Date: Fri Mar 6 19:49:41 2015 +0100 monitor: Drop do_qmp_capabilities()'s superfluous QMP check Superfluous since commit 30f5041 removed it from HMP. Signed-off-by: Markus Armbruster arm...@redhat.com Reviewed-by: Eric Blake ebl...@redhat.com Reviewed-by: Luiz Capitulino lcapitul...@redhat.com commit 74358f2a1647b239d87340ea0024f9d2efa266ca Author: Markus Armbruster arm...@redhat.com Date: Fri Mar 6 19:35:59 2015 +0100 monitor: Unbox Monitor member mc and rename to qmp While there, rename its type as well, from MonitorControl to MonitorQMP. Signed-off-by: Markus Armbruster arm...@redhat.com Reviewed-by: Eric Blake ebl...@redhat.com Reviewed-by: Luiz Capitulino lcapitul...@redhat.com commit c83fe23b58199a6d4a938305cb0fc45fe7729b61 Author: Markus Armbruster arm...@redhat.com Date: Fri Mar 6 19:20:51 2015 +0100 monitor: Rename monitor_control_read(), monitor_control_event() ... to monitor_qmp_read(), monitor_qmp_event().
Re: [Xen-devel] save restore failed when tmem enabled in Xen 4.1 Xen 4.3
Hi Konrad, Thank you for your reply! It does not matter whether it is 1000 or not. Most of the save restore operations will be failed when there are more than 1000 pages put in the persistent pool. Some of the operations will be success when there are not so much pages put in the persistent pool. Attached file is the screenshot of the error message (no log files), and it seems to be panic in libnss-files. Migration operations have the same phenomenon as save restore operations, and some of them are success when there are not so much pages put in the persistent pool. Also, my test environment is as follows: Xen server: Xen 4.1 (Oracle VM server release 3.2.6), Xen 4.3 (Oracle VM server release 3.3.1) Guest:Ubuntu 14.10 (kernel 3.16.0) Params: 8cores, 8G ram， 100G disk (using file protocol). Best Regards, Yunfang 2015-06-06 2:45 GMT+08:00 Konrad Rzeszutek Wilk konrad.w...@oracle.com: On Thu, Jun 04, 2015 at 10:27:06PM +0800, yunfang tai wrote: Hi all, Hey! Recently, I am testing the TMEM support on Xen. I discovered that when enabled TMEM in ubuntu 14.10 as guest on Xen 4.1 Xen 4.3, xm save xm restore“ failed after there are more than 1000 pages put in persistent pool of TMEM in Xen. My operations are list as follows: Is it exactly 1000 or just about? I presume it does not matter how much but that you discovered it by having 1000 of them? In ubuntu guest (8 cores , 8GB): sudo modprobe tmem (than wait for the selfballoon to finish) dd if=/dev/zero of=/tmp/test.img bs=10M count=1000 dd if=/tmp/test.img of=/dev/null bs=10M dd if=/tmp/test.img of=/dev/null bs=10M . (until more than 1000 pages put in persistent pool) In Domain 0: (add tmem in grub.cfg) xm save ubuntu test.save xm restore ubuntu test.save When TMEM is not enabled, save restore success after these operations. But if TMEM is enabled, save restore fail. Are there any errors from the logs? Anything? Does anyone test about save restore when enabled TMEM in Xen?? Is there anything I do wrong? Well lets see what broke. But I think Andrew discovered that the migration protocol when it came to 'tmem' was not up to snuff. CC-ing him just to confirm. (Andrew, for the persistent part of this - it conceptually should get all of the tmem memory that pushed to the hypervisor back in the image. When you were looking at migrationv2 did you just skim through that or mostly ignored it?) Thanks. Thanks!! Best Regards, Yunfang ___ 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] [Qemu-devel] qemu mainline regression with xen-unstable: unable to start QMP
Eric Blake ebl...@redhat.com writes:
[adding Markus, as author of the regression]
On 06/04/2015 03:59 PM, Don Slutz wrote:
On 06/04/15 11:04, Fabio Fantoni wrote:
Today after trying xen-unstable build (tested many hours) of some days
ago I tried update qemu to latest development version (from git master
commit 6fa6b312765f698dc81b2c30e7eeb9683804a05b) and seems that there is
a regression:
xl create /etc/xen/W7.cfg
Parsing config from /etc/xen/W7.cfg
libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an
error message from QMP server: QMP input object member 'id' is unexpected
libxl: error: libxl_qmp.c:715:libxl__qmp_initialize: Failed to connect
to QMP
This is caused by:
commit 65207c59d99f2260c5f1d3b9c491146616a522aa
Author: Markus Armbruster arm...@redhat.com
Date: Thu Mar 5 14:35:26 2015 +0100
monitor: Drop broken, unused asynchronous command interface
Yes. I screwed up.
The patch:
From 1b0221078353870fe530e49de158cae205f9bce5 Mon Sep 17 00:00:00 2001
From: Don Slutz dsl...@verizon.com
Date: Thu, 4 Jun 2015 17:04:42 -0400
Subject: [PATCH 01/14] monitor: Allow Xen's (broken) usage of asynchronous
command interface.
commit 65207c59d99f2260c5f1d3b9c491146616a522aa
Author: Markus Armbruster arm...@redhat.com
Date: Thu Mar 5 14:35:26 2015 +0100
monitor: Drop broken, unused asynchronous command interface
Breaks Xen. Add a hack un unbreak it.
s/un /to /
Xen is only doing synchronous commands, but is including an id.
QMP also uses id, but apparently removes it up front before calling into
this function; so another fix would be having xen remove it up front.
I don't think so:
{QMP: {version: {qemu: {micro: 50, minor: 3, major: 2},
package: }, capabilities: []}}
{ execute: qmp_capabilities }
{return: {}}
{execute: system_reset, id: 1}
{error: {class: GenericError, desc: QMP input object member 'id'
is unexpected}}
Signed-off-by: Don Slutz dsl...@verizon.com
---
monitor.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/monitor.c b/monitor.c
index c7baa91..e9a0747 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4955,6 +4955,15 @@ static QDict *qmp_check_input_obj(QObject
*input_obj, Error **errp)
arguments, object);
return NULL;
}
+} else if (!strcmp(arg_name, id)) {
+/*
+ * Fixup Xen's usage. Just ignore the id. See point #5
+ * above. This was an attempt at an asynchronous
+ * command interface. However commit
+ * 65207c59d99f2260c5f1d3b9c491146616a522aa is
+ * wrong. Xen does not expect an error when it passes in
+ * id:1, so just continue to ignore it.
+ */
The comment is a bit verbose, particularly since 'id' is a
well-established usage pattern in QMP. Also, we don't need to call out
why it changed in the comment here, the commit message is sufficient for
that.
Yes. I'll post a patch with a more suitable comment and commit message.
} else {
error_set(errp, QERR_QMP_EXTRA_MEMBER, arg_name);
return NULL;
I apologize for the mess I made, and my slow reply (offline since
Wednesday night).
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register
On 08/06/15 08:42, Jan Beulich wrote: On 07.06.15 at 08:23, m...@redhat.com wrote: On Mon, Apr 20, 2015 at 04:32:12PM +0200, Michael S. Tsirkin wrote: On Mon, Apr 20, 2015 at 03:08:09PM +0100, Jan Beulich wrote: On 20.04.15 at 15:43, m...@redhat.com wrote: On Mon, Apr 13, 2015 at 01:51:06PM +0100, Jan Beulich wrote: On 13.04.15 at 14:47, m...@redhat.com wrote: Can you check device capabilities register, offset 0x4 within pci express capability structure? Bit 15 is 15 Role-Based Error Reporting. Is it set? The spec says: 15 On platforms where robust error handling and PC-compatible Configuration Space probing is required, it is suggested that software or firmware have the Unsupported Request Reporting Enable bit Set for Role-Based Error Reporting Functions, but clear for 1.0a Functions. Software or firmware can distinguish the two classes of Functions by examining the Role-Based Error Reporting bit in the Device Capabilities register. Yes, that bit is set. curiouser and curiouser. So with functions that do support Role-Based Error Reporting, we have this: With device Functions implementing Role-Based Error Reporting, setting the Unsupported Request Reporting Enable bit will not interfere with PC-compatible Configuration Space probing, assuming that the severity for UR is left at its default of non-fatal. However, setting the Unsupported Request Reporting Enable bit will enable the Function to report UR errors 97 detected with posted Requests, helping avoid this case for potential silent data corruption. I still don't see what the PC-compatible config space probing has to do with our issue. I'm not sure but I think it's listed here because it causes a ton of URs when device scan probes unimplemented functions. did firmware reconfigure this device to report URs as fatal errors then? No, the Unsupported Request Error Serverity flag is zero. OK, that's the correct configuration, so how come the box crashes when there's a UR then? Ping - any update on this? Not really. All we concluded so far is that _maybe_ the bridge, upon seeing the UR, generates a Master Abort, rendering the whole thing fatal. Otoh the respective root port also has - Received Master Abort set in its Secondary Status register (but that's also already the case in the log that we have before the UR occurs, i.e. that doesn't mean all that much), - Received System Error set in its Secondary Status register (and after the UR the sibling endpoint [UR originating from 83:00.0, sibling being 83:00.1] also shows Signaled System Error set). Disabling the Memory decode in the command register could also result in a completion timeout on the root port issuing a transaction towards the PCI device in question. PCIE completion timeouts can be escalated to Fatal AER errors which trigger system firmware to inject NMI's into the host. Unsupported requests can also be escalated to be Fatal AER errors (which would again trigger system firmware to inject an NMI). Here is an example AER setup for a PCIE root port. You can see UnsupReq errors are masked and so do not trigger errors. CmpltTO ( completion timeout) errors are not masked and the errors are treated as Fatal because the corresponding bit in the Uncorrectable Severity register is set. Capabilities: [148 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt+ UnxCmplt+ RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol+ UESvrt: DLP+ SDES+ TLP+ FCP+ CmpltTO+ CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk: RxErr+ BadTLP+ BadDLLP+ Rollover+ Timeout+ NonFatalErr+ AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn- A root port completion timeout will also result in the master abort bit being set. Typically system firmware clears the error in the AER registers after it's processed it. So the operating system may not be able to determine what error triggered the NMI in the first place. Do we can chalk this up to hardware bugs on a specific box? I have to admit that I'm still very uncertain whether to consider all this correct behavior, a firmware flaw, or a hardware bug. I believe the correct behaviour is happening but a PCIE completion timeout is occurring instead of a unsupported request. Malcolm 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] [PATCH v2 6/9] x86/intel_pstate: the main boby of the intel_pstate driver
On 08/06/2015 14:50, Jan Beulich wrote:
On 08.06.15 at 03:47, wei.w.w...@intel.com wrote:
On 26/05/2015 21:58, Jan Beulich wrote
On 13.05.16 at 09:50, wei.w.w...@intel.com wrote:
+static int byt_get_min_pstate(void) {
+u64 value;
+
+rdmsrl(BYT_RATIOS, value);
+return (value 8) 0x7F;
+}
+
+static int byt_get_max_pstate(void) {
+u64 value;
+
+rdmsrl(BYT_RATIOS, value);
+return (value 16) 0x7F;
+}
+
+static int byt_get_turbo_pstate(void) {
+u64 value;
+
+rdmsrl(BYT_TURBO_RATIOS, value);
+return value 0x7F;
+}
+
+static void byt_set_pstate(struct cpudata *cpudata, int pstate) {
+u64 val;
+int32_t vid_fp;
+u32 vid;
+
+val = pstate 8;
+if (limits.no_turbo !limits.turbo_disabled)
+val |= (u64)1 32;
All of the literal numbers above (and there are more further down)
would better become self-documenting manifest constants.
I just realized that it would be better to remove these bay trail
platform related code. What do you think?
First of all - why? Unless these are 32-bit only systems, I don't see why we
wouldn't want to support Atoms at least on a best effort basis. And if you
consider removal of code present in Linux, then this also needs to be done
with the earlier mentioned as little changes as possible compared to the
Linux original in mind.
I don't have an objection to keeping it. Probably, some people are running Xen
on tablets.
Regarding the self-documenting related comment here, which of the following do
you think is better?
1)
#define BYT_MIN_PSTATE_SHIFT8
#define BYT_MAX_PSTATE_SHIFT 16
#define BYT_PSTATE_MASK 0x7f
#define BYT_TURBO_CONTROL_BIT32
2)
#define BYT_MIN_PSTATE(value) (((value) 8) 0x7F)
#define BYT_MAX_PSTATE(value)(((value) 16) 0x7F)
#define BYT_SET_TURBO_CONTROL_BIT(value)((val) |= (u64)1 32)
Best,
Wei
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (five months reminder, 5 WEEKS TO FREEZE)
On 6/5/2015 9:53 PM, wei.l...@citrix.com wrote: (Note, please trim your quotes when replying, and also trim the CC list if necessary. You might also consider changing the subject line of your reply to Status of (Was: Xen 4.6 Development Update (X months reminder)) Hi all We are now four months into 4.6 development window. This is an email to keep track of all the patch series I gathered. It is by no means complete and / or acurate. Feel free to reply this email with new projects or correct my misunderstanding. = Timeline = We are planning on a 9-month release cycle, but we could also release a bit earlier if everything goes well (no blocker, no critical bug). * Development start: 6 Jan 2015 === We are here === * Feature Freeze: 10 Jul 2015 * RCs: TBD * Release Date: 9 Oct 2015 (could release earlier) The RCs and release will of course depend on stability and bugs, and will therefore be fairly unpredictable. Bug-fixes, if Acked-by by maintainer, can go anytime before the First RC. Later on we will need to figure out the risk of regression/reward to eliminate the possiblity of a bug introducing another bug. = Prognosis = The states are: none - fair - ok - good - done none - nothing yet fair - still working on it, patches are prototypes or RFC ok - patches posted, acting on review good - some last minute pieces done - all done, might have bugs = Bug Fixes = Bug fixes can be checked in without a freeze exception throughout the freeze, unless the maintainer thinks they are particularly high risk. In later RC's, we may even begin rejecting bug fixes if the broken functionality is small and the risk to other functionality is high. Document changes can go in anytime if the maintainer is OK with it. These are guidelines and principles to give you an idea where we're coming from; if you think there's a good reason why making an exception for you will help us make Xen better than not doing so, feel free to make your case. == Hypervisor == * Alternate p2m: support multiple copies of host p2m (ok) - Ed White * Improve RTDS scheduler (none) Change RTDS from quantum driven to event driven - Dagaen Golomb, Meng Xu, Chong Li * Credit2: introduce per-vcpu soft affinity (good) - Justin T. Weaver * Credit2: introduce per-vcpu hard affinity (fair) - Justin T. Weaver * sndif: add API for para-virtual sound (fair) v7 posted - Oleksandr Dmytryshyn * gnttab: improve scalability (good) - David Vrabel * Xen multiboot2-EFI support (ok) See http://lists.xen.org/archives/html/xen-devel/2015-01/msg03962.html http://lists.xen.org/archives/html/xen-devel/2015-01/msg03982.html - Daniel Kiper * Credit2 production ready (none) cpu reservation - George Dunlap * VM event patches (none) Add support for XSETBV vm_events, Support hybernating guests Support for VMCALL-based vm_events - Razvan Cojocaru === Hypervisor X86 === * Intel Cache Allocation Technology (good) - Chao Peng * Intel GVT-g (none) requires refactoring ioreq-server, fixing 16-byte MMIO emulation and optional PV IOMMU support - Yu, Zhang ioreq-server: still in development. Previously tried to refactor the ioreq-server to track the IO resources by using radix tree. Yet this approach would consume too much memory space. Now trying to use the interval rbtree. Will send the patch out ASAP. fixing 16-byte MMIO emulation: Paul Durrant has been working on this. PV IOMMU support: Malcolm Crossley has been preparing the draft design. We had several rounds internal discussion about how this design covers the basic requirement of XenGT. Will continue the discussion and prepare the patch once the design is sent to the community. BTW, thank you Paul Malcolm. :-) Yu * Porting Intel P-state driver to Xen (fair) - Wang, Wei * VT-d Posted-interrupt (PI) (good) v2 posted - Wu, Feng * Support controlling the max C-state sub-state (fair) v3 posted Hadn't see the patch reposted. - Ross Lagerwall * IOMMU ABI for guests to map their DMA regions (fair) - Malcolm Crossley * RMRR fix (fair) RFC posted - Tiejun Chen * VPMU - 'perf' support in Xen (good) v21 posted Need reviews/final ack. - Boris Ostrovsky * PVH domU (fair) RFC posted - Elena Ufimtseva === Hypervisor ARM === * ITS support (fair ) - Vijaya Kumar K * Add ACPI support for arm64 on Xen (fair) RFC posted - Parth Dixit * ARM remote processor iommu module (GPUs + IPUs) (fair) v3 posted - Andrii Tseglytskyi * ARM VM save/restore/live migration (none) Need to rebased against migrationv2 - no code posted. - None * ARM GICv2m support (none) - Suravee Suthikulanit * ARM PCI passthrough (fair) - Manish Jaggi * ARM GICv2 on GICv3 support (none) - Julien Grall - Vijay Kilari == Xen toolstack == * Split libxc into multiple libraries (none) - Ian Campbell * Remus using migration-v2
Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register
On 08.06.15 at 10:09, malcolm.cross...@citrix.com wrote: On 08/06/15 08:42, Jan Beulich wrote: Not really. All we concluded so far is that _maybe_ the bridge, upon seeing the UR, generates a Master Abort, rendering the whole thing fatal. Otoh the respective root port also has - Received Master Abort set in its Secondary Status register (but that's also already the case in the log that we have before the UR occurs, i.e. that doesn't mean all that much), - Received System Error set in its Secondary Status register (and after the UR the sibling endpoint [UR originating from 83:00.0, sibling being 83:00.1] also shows Signaled System Error set). Disabling the Memory decode in the command register could also result in a completion timeout on the root port issuing a transaction towards the PCI device in question. PCIE completion timeouts can be escalated to Fatal AER errors which trigger system firmware to inject NMI's into the host. And how does all that play with PC compatibility (where writes into no-where get dropped, and reads from no-where get all ones returned)? Remember - we#re talking about CPU side accesses here. Here is an example AER setup for a PCIE root port. You can see UnsupReq errors are masked and so do not trigger errors. CmpltTO ( completion timeout) errors are not masked and the errors are treated as Fatal because the corresponding bit in the Uncorrectable Severity register is set. Capabilities: [148 v1] Advanced Error Reporting UESta:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt+ UnxCmplt+ RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol+ UESvrt: DLP+ SDES+ TLP+ FCP+ CmpltTO+ CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta:RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk:RxErr+ BadTLP+ BadDLLP+ Rollover+ Timeout+ NonFatalErr+ AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn- A root port completion timeout will also result in the master abort bit being set. Typically system firmware clears the error in the AER registers after it's processed it. So the operating system may not be able to determine what error triggered the NMI in the first place. Right, but in the case at hand we have an ITP log available, which increases the hope that we see a reasonably complete picture. Do we can chalk this up to hardware bugs on a specific box? I have to admit that I'm still very uncertain whether to consider all this correct behavior, a firmware flaw, or a hardware bug. I believe the correct behaviour is happening but a PCIE completion timeout is occurring instead of a unsupported request. Might it be that with the supposedly correct device returning UR the root port reissues the request to the sibling device, which then fails it in a more dramatic way (albeit the sibling's Uncorrectable Error Status Register also has only Unsupported Request Error Status set)? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 57852: regressions - FAIL
On 08.06.15 at 10:53, ian.campb...@citrix.com wrote: That's 6/14 (43%) failure rate on fiano0 and 2/10 (20%) on fiano1. Which differs form the apparent xen-unstable failure rate. But I wouldn't take this as evidence that the two systems differ significantly, despite how the unstable results looked at first glance. So we can basically rule out just one of the hosts being the culprit; it's either both or our software. Considering that (again at the example of the recent 4.2 flight) the guest is apparently waiting for a timer (or other) interrupt (on a HLT instruction), this is very likely interrupt delivery related, yet (as said before, albeit wrongly for 4.3) 4.2 doesn't have APICV support yet (4.3 only lack the option to disable it), so it can't be that (alone). Looking at the hardware - are fiano[01], in terms of CPU and chipset, perhaps the newest or oldest in the pool? (I'm trying to make myself a picture of what debugging options we have.) Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [qemu-mainline test] 57925: regressions - FAIL
On Sun, 2015-06-07 at 11:28 +, osstest service user wrote: flight 57925 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/57925/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: I think it is pretty safe to say that something has broken save/restore. test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 11 guest-saverestore fail REGR. vs. 57815 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 11 guest-saverestore fail REGR. vs. 57815 test-amd64-i386-freebsd10-amd64 12 guest-saverestore fail REGR. vs. 57815 test-amd64-i386-freebsd10-i386 12 guest-saverestore fail REGR. vs. 57815 test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 57815 test-amd64-amd64-xl-qemuu-debianhvm-amd64 11 guest-saverestore fail REGR. vs. 57815 test-amd64-i386-xl-qemuu-debianhvm-amd64 11 guest-saverestore fail REGR. vs. 57815 test-amd64-amd64-xl-qemuu-ovmf-amd64 11 guest-saverestore fail REGR. vs. 57815 test-amd64-i386-xl-qemuu-ovmf-amd64 11 guest-saverestore fail REGR. vs. 57815 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 11 guest-saverestore fail REGR. vs. 57815 test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 57815 test-amd64-i386-xl-qemuu-win7-amd64 11 guest-saverestore fail REGR. vs. 57815 test-amd64-i386-xl-qemuu-winxpsp3 11 guest-saverestorefail REGR. vs. 57815 test-amd64-amd64-xl-qemuu-winxpsp3 11 guest-saverestore fail REGR. vs. 57815 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt 11 guest-start fail like 57815 test-amd64-amd64-libvirt 11 guest-start fail like 57815 test-armhf-armhf-libvirt 11 guest-start fail like 57815 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-xsm 14 guest-localmigrate fail never pass test-amd64-amd64-xl-xsm 14 guest-localmigrate fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 11 guest-start fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 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 version targeted for testing: qemuu3b730f570c5872ceea2137848f1d4554d4847441 baseline version: qemuu3fc827d591679f3e262b9d1f8b34528eabfca8c0 People who touched revisions under test: Alex Bennée alex.ben...@linaro.org Alexander Graf ag...@suse.de Alexey Kardashevskiy a...@ozlabs.ru Andreas Färber afaer...@suse.de Chen Hanxiao chenhanx...@cn.fujitsu.com Christoffer Dall christoffer.d...@linaro.org Cornelia Huck cornelia.h...@de.ibm.com David Gibson da...@gibson.dropbear.id.au Dr. David Alan Gilbert dgilb...@redhat.com Edgar E. Iglesias edgar.igles...@xilinx.com Eduardo Habkost ehabk...@redhat.com Eric Auger eric.au...@linaro.org Fam Zheng f...@redhat.com Ian Campbell ian.campb...@citrix.com Ikey Doherty michael.i.dohe...@intel.com Jan Beulich jbeul...@suse.com Markus Armbruster arm...@redhat.com Michael Roth mdr...@linux.vnet.ibm.com Michael S. Tsirkin m...@redhat.com Michael Tokarev m...@tls.msk.ru Mike Day ncm...@ncultra.org Nathan Fontenot nf...@linux.vnet.ibm.com Nikunj A Dadhania nik...@linux.vnet.ibm.com Paolo Bonzini pbonz...@redhat.com Peter Crosthwaite crosthwaite.pe...@gmail.com Peter Crosthwaite crosthwaitepe...@gmail.com Peter Krempa pkre...@redhat.com Peter Maydell peter.mayd...@linaro.org Sai Pavan Boddu sai.pavan.bo...@xilinx.com Sai Pavan Boddu saip...@xilinx.com Shannon Zhao shannon.z...@linaro.org Shannon Zhao zhaoshengl...@huawei.com Stefano Stabellini stefano.stabell...@eu.citrix.com Thomas Huth th...@redhat.com Tyrel Datwyler tyr...@linux.vnet.ibm.com Victor CLEMENT victor.clem...@openwide.fr Zhu Guihua zhugh.f...@cn.fujitsu.com jobs: build-amd64-xsm pass
Re: [Xen-devel] [libvirt test] 58119: regressions - FAIL
On Mon, 2015-06-08 at 04:37 +, osstest service user wrote: flight 58119 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/58119/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: This has been failing for a while now, sorry for not brining it to your attention sooner. amd64 and arm look like: 2015-06-08 02:25:15 Z executing ssh ... root@172.16.144.21 virsh create --file /etc/xen/debian.guest.osstest.cfg.xml error: Failed to create domain from /etc/xen/debian.guest.osstest.cfg.xml error: internal error: libxenlight failed to create new domain 'debian.guest.osstest' and from the driver log: libxl: debug: libxl_event.c:638:libxl__ev_xswatch_deregister: watch w=0x7f805c25b248 wpath=/local/domain/0/device-model/1/state token=3/0: deregister slotnum=3 libxl: error: libxl_exec.c:393:spawn_watch_event: domain 1 device model: startup timed out libxl: debug: libxl_event.c:652:libxl__ev_xswatch_deregister: watch w=0x7f805c25b248: deregister unregistered libxl: debug: libxl_event.c:652:libxl__ev_xswatch_deregister: watch w=0x7f805c25b248: deregister unregistered libxl: error: libxl_dm.c:1564:device_model_spawn_outcome: domain 1 device model: spawn failed (rc=-3) libxl: error: libxl_create.c:1373:domcreate_devmodel_started: device model did not start: -3 i386 is: 2015-06-07 21:45:32 Z executing ssh ... root@172.16.144.44 virsh create --file /etc/xen/debian.guest.osstest.cfg.xml 2015-06-07 21:46:12.853+: 16327: info : libvirt version: 1.2.17 2015-06-07 21:46:12.853+: 16327: warning : virKeepAliveTimerInternal:143 : No response from client 0xb6fe7c38 after 6 keepalive messages in 35 seconds 2015-06-07 21:46:12.854+: 16326: warning : virKeepAliveTimerInternal:143 : No response from client 0xb6fe7c38 after 6 keepalive messages in 35 seconds error: Failed to create domain from /etc/xen/debian.guest.osstest.cfg.xml error: internal error: received hangup / error event on socket libvirtd is still there in the ps log. Histories: http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-libvirt.libvirt.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-libvirt.libvirt.html http://logs.test-lab.xenproject.org/osstest/results/history.test-armhf-armhf-libvirt.libvirt.html Ian. test-amd64-i386-libvirt 11 guest-start fail REGR. vs. 53854 test-amd64-amd64-libvirt 11 guest-start fail REGR. vs. 53854 test-armhf-armhf-libvirt 11 guest-start fail REGR. vs. 53854 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt-xsm 11 guest-start fail like 53854 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 11 guest-start fail never pass version targeted for testing: libvirt 568aba88111541447e7d7163f7683f0daf2a684a baseline version: libvirt fd74e231751334b64af0934b680c5cc62f652453 People who touched revisions under test: Andrea Bolognani abolo...@redhat.com Boris Fiuczynski fiu...@linux.vnet.ibm.com Cole Robinson crobi...@redhat.com Daniel Hansel daniel.han...@linux.vnet.ibm.com Daniel P. Berrange berra...@redhat.com Daniel Veillard veill...@redhat.com Eric Blake ebl...@redhat.com Erik Skultety eskul...@redhat.com Jim Fehlig jfeh...@suse.com Jiri Denemark jdene...@redhat.com John Ferlan jfer...@redhat.com Ján Tomko jto...@redhat.com Kothapally Madhu Pavan k...@linux.vnet.ibm.com Laine Stump la...@laine.org Lubomir Rintel lkund...@v3.sk Luyao Huang lhu...@redhat.com Martin Kletzander mklet...@redhat.com Maxim Nestratov mnestra...@parallels.com Michal Privoznik mpriv...@redhat.com Nikolay Shirokovskiy nshirokovs...@parallels.com Pavel Fedin p.fe...@samsung.com Pavel Hrdina phrd...@redhat.com Peter Krempa pkre...@redhat.com Richard W.M. Jones rjo...@redhat.com Roman Bogorodskiy bogorods...@gmail.com Shivaprasad G Bhat sb...@linux.vnet.ibm.com Shivaprasad G Bhat shivaprasadb...@gmail.com Tony Krowiak aekro...@us.ibm.com Tony Krowiak akrow...@linux.vnet.ibm.com Viktor Mihajlovski mihaj...@linux.vnet.ibm.com Wang Yufei james.wangyu...@huawei.com Zhang Bo oscar.zhan...@huawei.com jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386
Re: [Xen-devel] [PATCH v23 11/15] VPMU/AMD: Check MSR values before writing to hardware
On 05.06.15 at 18:32, boris.ostrov...@oracle.com wrote:
On 06/05/2015 12:03 PM, Jan Beulich wrote:
On 29.05.15 at 20:42, boris.ostrov...@oracle.com wrote:
@@ -289,19 +302,24 @@ static int amd_vpmu_do_wrmsr(unsigned int msr,
uint64_t
msr_content,
{
struct vcpu *v = current;
struct vpmu_struct *vpmu = vcpu_vpmu(v);
+unsigned int idx = 0;
+int type = get_pmu_reg_type(msr, idx);
ASSERT(!supported);
/* For all counters, enable guest only mode for HVM guest */
-if ( has_hvm_container_vcpu(v)
- (get_pmu_reg_type(msr) == MSR_TYPE_CTRL)
+if ( has_hvm_container_vcpu(v) (type == MSR_TYPE_CTRL)
!is_guest_mode(msr_content) )
{
set_guest_mode(msr_content);
}
+if ( (type == MSR_TYPE_CTRL )
+ ((msr_content CTRL_RSVD_MASK) != ctrl_rsvd[idx]) )
+return 1;
I think the check should go before the use of the value for anything,
i.e. including the set_guest_mode() above.
Also I'm pretty sure I asked about the meaning of 1 as a return
value of a function returning int: If this is a boolean, the function
should return bool_t (and probably use 1 as success indicator,
while the case at hand appears to be a failure one). If this is an
error indicator, -E... values should be used. Of course, if for some
reason this is meant to represent success, considering the function
being that way even before your change, I'd not insist on you
re-working the return value aspects of it.
One means error (which is the reverse of what it is now), this is
described in patch 8. We did talk about this a while ago (not during
latest round) when IIRC you requested me to clarify this in the commit
message.
I can replace these 1s with -EINVAL (or -EFAULT).
Yes please - using 1 to indicate an error is pretty odd looking at
most other hypervisor code.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] osstest: reduce FreeBSD install timeouts
On Fri, 2015-05-29 at 11:38 +0100, Roger Pau Monne wrote: Only the first block is expected to take longer (because it decompresses the image and writes it to a LVM volume), the remaining commands should execute much faster, so reduce the timeout. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: making the PVH 64bit ABI as stableo
On Fri, 2015-06-05 at 18:21 +0100, Andrew Cooper wrote: However, I expect it to turn into (HVM - Qemu + very few extra PV hypercalls) Don't forget - in Xen device models (e.g. PIT etc) and - some other stuff which I'm sure I'm forgetting from Tim's original list of things to be made conditional. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] 答复： Re: [PATCH V3 3/6] libxl: add pvusb API
在 2:06 的 2015/5/20 上，在讯息
caflbxzzhffwo6tm7602y3+x5kx65-w4obfs1vdvb8kqnzda...@mail.gmail.com 中，George
Dunlap george.dun...@eu.citrix.com 写入：
On Sun, Apr 19, 2015 at 4:50 AM, Chunyan Liu cy...@suse.com wrote:
Add pvusb APIs, including:
- attach/detach (create/destroy) virtual usb controller.
- attach/detach usb device
- list usb controller and usb devices
- some other helper functions
Signed-off-by: Chunyan Liu cy...@suse.com
Signed-off-by: Simon Cao caobosi...@gmail.com
OK, getting closer. :-)
A number of comments:
Hi, George, thanks very much!
I'm so sorry for missing the message and not reply immediately.
Before sending new version, I'm answering some of your questions here.
And there are a couple of comments, I still have some hesitation to follow.
All others, I agree and will update as you suggested.
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 6bc75c5..cbe3519 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -114,6 +114,12 @@
#define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1
/*
+ * LIBXL_HAVE_PVUSB indicates the functions for doing hot-plug of
+ * USB devices through pvusb.
+ */
+#define LIBXL_HAVE_PVUSB 1
It seems like we should document somewhere how we expect these to be
used -- namely the connection between usbctrl and usb devices. In
particular, that you can either add a usbctrl, and then add a usb
device to it specifically; or if you don't specify a usbctrl when
calling usb_add, it will find the most reasonable one to add it to,
even creating one for you if you didn't have one.
diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_pvusb.c
new file mode 100644
index 000..4e4975a
--- /dev/null
+++ b/tools/libxl/libxl_pvusb.c
+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) {
Hmm, I was doing to say that this shouldn't be a magic constant, but
it looks like that's what all the other devices do :-/
+static bool is_usb_in_array(libxl_device_usb *usbs, int num,
+libxl_device_usb *usb)
+{
+int i;
+
+for (i = 0; i num; i++) {
+if (!strcmp(usbs[i].busid, usb-busid) )
Here (and elsewhere) you should probably use the COMPARE_USB() macro
you define in this patch.
+/* check if USB device type is assignable */
+static bool is_usb_assignable(libxl__gc *gc, libxl_device_usb *usb)
+{
+libxl_ctx *ctx = libxl__gc_owner(gc);
+int classcode;
+char *filename;
+void *buf;
+
+assert(usb-busid);
+
+filename = GCSPRINTF(SYSFS_USB_DEV/%s/bDeviceClass, usb-busid);
+if (libxl_read_file_contents(ctx, filename, buf, NULL) 0)
+return false;
+
+sscanf(buf, %x, classcode);
+if (classcode == USBHUB_CLASS_CODE)
+return false;
+
+return true;
Just checking, is it really the case that *all* USB classes are
assignable, *except* for hubs?
Referring to xm pvusb implementation, only HUB is excluded, so I
just keep the same.
This is a minor thing, but this might be simper to do this:
return classcode != USBHUB_CLASS_CODE;
+/* get usb devices under certain usb controller */
+static int libxl__device_usb_list(libxl__gc *gc, uint32_t domid, int
usbctrl,
+ libxl_device_usb **usbs, int *num)
+{
+char *be_path, *num_devs;
+int n, i;
+
+*usbs = NULL;
+*num = 0;
+
+be_path = GCSPRINTF(%s/backend/vusb/%d/%d,
+libxl__xs_get_dompath(gc, 0), domid, usbctrl);
+num_devs = libxl__xs_read(gc, XBT_NULL,
+ GCSPRINTF(%s/num-ports, be_path));
+if (!num_devs)
+return 0;
+
+n = atoi(num_devs);
+*usbs = calloc(n, sizeof(libxl_device_usb));
+
+for (i = 0; i n; i++) {
+char *busid;
+libxl_device_usb *usb = NULL;
+
+busid = libxl__xs_read(gc, XBT_NULL,
+ GCSPRINTF(%s/port/%d, be_path, i + 1));
+if (busid strcmp(busid, )) {
+usb = *usbs + *num;
+usb-ctrl = usbctrl;
+usb-port = i + 1;
+usb-busid = strdup(busid);
This needs to populate the hostbus / hostaddr as well; busid is pretty
useless to users / external callers.
I thought about that when implementing, but finally not added to codes
considering:
* for all libxl pvusb internal usage, busid is enough.
* for toolstack usage, if we want to expose users useful information about
bus:addr,
vendorID:devieID, we have libxl_device_usb_getinfo API, with this API callers
can get
all information including hostbus, hostaddr.
If that couldn't satisfy qemu usage, I can add a translating to
Re: [Xen-devel] [qemu-mainline test] 57925: regressions - FAIL
Il 08/06/2015 11:16, Ian Campbell ha scritto: On Sun, 2015-06-07 at 11:28 +, osstest service user wrote: flight 57925 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/57925/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: I think it is pretty safe to say that something has broken save/restore. Already found some days ago, reported and today will be push in qemu upstream the fix (already tested): http://lists.gnu.org/archive/html/qemu-devel/2015-06/msg02104.html test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 11 guest-saverestore fail REGR. vs. 57815 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 11 guest-saverestore fail REGR. vs. 57815 test-amd64-i386-freebsd10-amd64 12 guest-saverestore fail REGR. vs. 57815 test-amd64-i386-freebsd10-i386 12 guest-saverestore fail REGR. vs. 57815 test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 57815 test-amd64-amd64-xl-qemuu-debianhvm-amd64 11 guest-saverestore fail REGR. vs. 57815 test-amd64-i386-xl-qemuu-debianhvm-amd64 11 guest-saverestore fail REGR. vs. 57815 test-amd64-amd64-xl-qemuu-ovmf-amd64 11 guest-saverestore fail REGR. vs. 57815 test-amd64-i386-xl-qemuu-ovmf-amd64 11 guest-saverestore fail REGR. vs. 57815 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 11 guest-saverestore fail REGR. vs. 57815 test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 57815 test-amd64-i386-xl-qemuu-win7-amd64 11 guest-saverestore fail REGR. vs. 57815 test-amd64-i386-xl-qemuu-winxpsp3 11 guest-saverestorefail REGR. vs. 57815 test-amd64-amd64-xl-qemuu-winxpsp3 11 guest-saverestore fail REGR. vs. 57815 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt 11 guest-start fail like 57815 test-amd64-amd64-libvirt 11 guest-start fail like 57815 test-armhf-armhf-libvirt 11 guest-start fail like 57815 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-xsm 14 guest-localmigrate fail never pass test-amd64-amd64-xl-xsm 14 guest-localmigrate fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 11 guest-start fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 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 version targeted for testing: qemuu3b730f570c5872ceea2137848f1d4554d4847441 baseline version: qemuu3fc827d591679f3e262b9d1f8b34528eabfca8c0 People who touched revisions under test: Alex Bennée alex.ben...@linaro.org Alexander Graf ag...@suse.de Alexey Kardashevskiy a...@ozlabs.ru Andreas Färber afaer...@suse.de Chen Hanxiao chenhanx...@cn.fujitsu.com Christoffer Dall christoffer.d...@linaro.org Cornelia Huck cornelia.h...@de.ibm.com David Gibson da...@gibson.dropbear.id.au Dr. David Alan Gilbert dgilb...@redhat.com Edgar E. Iglesias edgar.igles...@xilinx.com Eduardo Habkost ehabk...@redhat.com Eric Auger eric.au...@linaro.org Fam Zheng f...@redhat.com Ian Campbell ian.campb...@citrix.com Ikey Doherty michael.i.dohe...@intel.com Jan Beulich jbeul...@suse.com Markus Armbruster arm...@redhat.com Michael Roth mdr...@linux.vnet.ibm.com Michael S. Tsirkin m...@redhat.com Michael Tokarev m...@tls.msk.ru Mike Day ncm...@ncultra.org Nathan Fontenot nf...@linux.vnet.ibm.com Nikunj A Dadhania nik...@linux.vnet.ibm.com Paolo Bonzini pbonz...@redhat.com Peter Crosthwaite crosthwaite.pe...@gmail.com Peter Crosthwaite crosthwaitepe...@gmail.com Peter Krempa pkre...@redhat.com Peter Maydell peter.mayd...@linaro.org Sai Pavan Boddu sai.pavan.bo...@xilinx.com Sai Pavan Boddu saip...@xilinx.com Shannon Zhao shannon.z...@linaro.org Shannon Zhao zhaoshengl...@huawei.com Stefano Stabellini stefano.stabell...@eu.citrix.com Thomas Huth th...@redhat.com Tyrel Datwyler tyr...@linux.vnet.ibm.com Victor CLEMENT victor.clem...@openwide.fr Zhu Guihua
Re: [Xen-devel] [PATCH v2 COLOPre 01/13] libxc/restore: fix error handle of process_record
On 08/06/15 10:37, Yang Hongyang wrote:
On 06/08/2015 05:24 PM, Andrew Cooper wrote:
On 08/06/15 04:43, Yang Hongyang wrote:
If the err is RECORD_NOT_PROCESSED, and it is an optional record,
restore will still fail. The patch fix this.
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/libxc/xc_sr_restore.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c
index 9e27dba..2d2edd3 100644
--- a/tools/libxc/xc_sr_restore.c
+++ b/tools/libxc/xc_sr_restore.c
@@ -560,19 +560,6 @@ static int process_record(struct xc_sr_context
*ctx, struct xc_sr_record *rec)
free(rec-data);
rec-data = NULL;
-if ( rc == RECORD_NOT_PROCESSED )
-{
-if ( rec-type REC_TYPE_OPTIONAL )
-DPRINTF(Ignoring optional record %#x (%s),
-rec-type, rec_type_to_str(rec-type));
You would be best setting rc to 0 here, rather than moving the logic out
of process_record().
There will be another error type in COLO, which indicates a failover,
that
needs to be handled in restore(), so I moved the error handling down to
avoid duplex code...Otherwise, in process_record, RECORD_NOT_PROCESSED is
handled, and in restore another error type returned from
process_record is
handled...
Ah ok - I will wait till I get that far through the series.
~Andrew
~Andrew
-else
-{
-ERROR(Mandatory record %#x (%s) not handled,
- rec-type, rec_type_to_str(rec-type));
-rc = -1;
-}
-}
-
return rc;
}
@@ -678,7 +665,20 @@ static int restore(struct xc_sr_context *ctx)
else
{
rc = process_record(ctx, rec);
-if ( rc )
+if ( rc == RECORD_NOT_PROCESSED )
+{
+if ( rec.type REC_TYPE_OPTIONAL )
+DPRINTF(Ignoring optional record %#x (%s),
+rec.type, rec_type_to_str(rec.type));
+else
+{
+ERROR(Mandatory record %#x (%s) not handled,
+ rec.type, rec_type_to_str(rec.type));
+rc = -1;
+goto err;
+}
+}
+else if ( rc )
goto err;
}
.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 COLOPre 03/13] libxc/restore: zero ioreq page only one time
On 08/06/15 10:46, Andrew Cooper wrote: On 08/06/15 04:43, Yang Hongyang wrote: ioreq page contains evtchn which will be set when we resume the secondary vm the first time. The hypervisor will check if the evtchn is corrupted, so we cannot zero the ioreq page more than one time. The ioreq-state is always STATE_IOREQ_NONE after the vm is suspended, so it is OK if we only zero it one time. Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com Signed-off-by: Wen congyang we...@cn.fujitsu.com CC: Andrew Cooper andrew.coop...@citrix.com The issue here is that we are running the restore algorithm over a domain which has already been running in Xen for a while. This is a brand new usecase, as far as I am aware. Does the qemu process associated with this domain get frozen while the secondary is being reset, or does the process get destroyed and recreated. I have a gut feeling that it would be safer to clear all of the page other than the event channel, but that depends on exactly what else is going on. We absolutely don't want to do is have an update to this page from the primary with an in-progress IOREQ. Or actually worse, an update from the primary with a different event channel in it. There is no requirement or guarantee that the bufioreq event channels are the same on either side. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/5] xen/vm_access: Support for memory-content hiding
On 08.06.15 at 12:02, rcojoc...@bitdefender.com wrote: On 05/08/2015 07:07 PM, Jan Beulich wrote: --- a/xen/include/asm-x86/domain.h +++ b/xen/include/asm-x86/domain.h @@ -512,6 +513,7 @@ struct arch_vcpu uint32_t emulate_flags; unsigned long gpa; unsigned long eip; +struct vm_event_emul_read_data emul_read_data; Considering the size of this structure I don't think this should be there for all vCPU-s of all guests. IOW - please allocate this dynamically only on domains where it's needed. Looking at the code, it's not immediately clear how to differentiate between a domain where this is needed and one where it is not. At domain init time we don't know, because it might become needed as soon as a vm_event client becomes attached to the domain. Then again, even once a vm_event client attaches to the domain, it might still not be necessary to allocate that structure, as the client might never reply with MEM_ACCESS_SET_EMUL_READ_DATA. The only place where we know for sure that it's needed is in p2m_mem_access_check(), when receiving a vm_event response with MEM_ACCESS_SET_EMUL_READ_DATA (lazy allocation). Would this be alright? I can't really judge about that; the farther you can safely defer it, the better. For the sake of addressing my complaint it would probably suffice to defer it until a vm_event client attaches to the guest. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Backport request libxl: In libxl_set_vcpuonline check for maximum number of VCPUs against the cpumap. (Was: Re: [Bug report] Security issue in xl vcpu-set)
On Mon, 2015-06-08 at 11:35 +0100, Ian Jackson wrote: Luwei Cheng writes (Re: Backport request libxl: In libxl_set_vcpuonline check for maximum number of VCPUs against the cpumap. (Was: Re: [Bug report] Security issue in xl vcpu-set)): Some third-part management tools might be built directly above xl. Perhaps they can not rely on Ctrl-C.. In general callers of libxl will not be built to raise SIGINT. For example, if libvirt called this function in a way that triggers the bug, there wouldn't be any reasonable way to recover control. I'm afraid I'm still not clear about when the failure can be triggered by an attacker. I was able to reproduce by pressing a key at a pygrub prompt to drop to a prompt and then leaving the guest in that state, where the domain exists but does not yet have any vcpus etc. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v2] xSplice design
On 05.06.2015 17:27, Jan Beulich wrote: On 05.06.15 at 17:00, konrad.w...@oracle.com wrote: On Wed, May 20, 2015 at 05:11:20PM +0200, Martin Pohlack wrote: * Xen as it is now, has a couple of non-unique symbol names which will make runtime symbol identification hard. Sometimes, static symbols simply have the same name in C files, sometimes such symbols get included via header files, and some C files are also compiled multiple times and linked under different names (guest_walk.c). I think the Linux kernel solves this by aiming at unique symbol names even for local symbols. nm xen-syms | cut -f3- -d\ | sort | uniq -c | sort -nr | head Oh my. Looks like a couple of prepartion patches will be in order! Just because nm doesn't express this doesn't mean we have to special case them: In ELF (and in COFF too, which is relevant as long as xen.efi still remains to be a separate binary) static symbols can easily be qualified by their source or object file name - the symbol table certainly has that information available. As said on the hackathon, our current kallsyms mechanism - using nm output - suffers from this too, yet I personally view it as rather bad practice to add a globally unique prefix to local symbol names. Instead, as also said there, we should switch to consuming the full ELF symbol table. That's been on my todo list for two years or more - if only I would ever get the time to do things like that... Hmm, in my experience, you have file-type symbols in the symbol table that refer to source-code files and you have source-file references in the dwarf debug information. I have *not* seen references to object-files in either place and as some C-files are compiled multiple times in Xen (guest_walk.c), the mapping is not unique. Further, as soon as non-trivial linker scripts are used, the symbol ordering in the final xen-syms does not necessarily reflect original object-file contents anymore. I might be missing some mechanism here? Martin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (five months reminder, 5 WEEKS TO FREEZE)
-Original Message- * Intel GVT-g (none) requires refactoring ioreq-server, fixing 16-byte MMIO emulation and optional PV IOMMU support - Yu, Zhang ioreq-server: still in development. Previously tried to refactor the ioreq-server to track the IO resources by using radix tree. Yet this approach would consume too much memory space. Now trying to use the interval rbtree. Will send the patch out ASAP. fixing 16-byte MMIO emulation: Paul Durrant has been working on this. I have what I believe is a complete patch series. Now trying to write some targeted test cases, but will try to clean up the series and post for review today whilst I continue working on the tests. Paul PV IOMMU support: Malcolm Crossley has been preparing the draft design. We had several rounds internal discussion about how this design covers the basic requirement of XenGT. Will continue the discussion and prepare the patch once the design is sent to the community. BTW, thank you Paul Malcolm. :-) Yu * Porting Intel P-state driver to Xen (fair) - Wang, Wei * VT-d Posted-interrupt (PI) (good) v2 posted - Wu, Feng * Support controlling the max C-state sub-state (fair) v3 posted Hadn't see the patch reposted. - Ross Lagerwall * IOMMU ABI for guests to map their DMA regions (fair) - Malcolm Crossley * RMRR fix (fair) RFC posted - Tiejun Chen * VPMU - 'perf' support in Xen (good) v21 posted Need reviews/final ack. - Boris Ostrovsky * PVH domU (fair) RFC posted - Elena Ufimtseva === Hypervisor ARM === * ITS support (fair ) - Vijaya Kumar K * Add ACPI support for arm64 on Xen (fair) RFC posted - Parth Dixit * ARM remote processor iommu module (GPUs + IPUs) (fair) v3 posted - Andrii Tseglytskyi * ARM VM save/restore/live migration (none) Need to rebased against migrationv2 - no code posted. - None * ARM GICv2m support (none) - Suravee Suthikulanit * ARM PCI passthrough (fair) - Manish Jaggi * ARM GICv2 on GICv3 support (none) - Julien Grall - Vijay Kilari == Xen toolstack == * Split libxc into multiple libraries (none) - Ian Campbell * Remus using migration-v2 (good) RFC posted - depends on v6 of 'New Migration' - Yang Hongyang * Migration v2 (libxl) (none) - Andrew Cooper * toolstack-based approach to pvhvm guest kexec (fair) also contains hypervisor side change, v6 - Vitaly Kuznetsov * libxl: cancelling asynchronous operations (fair) RFC posted - Ian Jackson * VMware tools support (ok) - Don Slutz * PV USB support in libxl (fair) - Chunyan Liu * HVM USB support in libxl (fair) depend on PV USB support - George Dunlap * Blktap2 support (fair) - George Dunlap * pvscsi in libxl (fair) - Juergen Gross and Olaf * COarse-grain LOck-stepping Virtual Machines in Xen (fair) RFC v5 posted - Wen Congyang - Gui Jianfeng - Yang Hongyang - Dong, Eddie * tmem migrationv2 patches. (none) - Bob Liu Andrew Cooper David Vrabel * snapshot API extension (checkpointing disk) (fair) v10 - Chunyan Liu * PVH - Migration of PVH DomUs. (none) Depends on migration2 code v1 posted - Roger Pau Monné * PVH - Migration of guests from a PVH dom0 (fair) Depends on migration2 code - Roger Pau Monné == QEMU == * Restrict QEMU - Stefano Stabellini * Linux-based QEMU upstream stub domain (fair) RFC posted - Eric Shelton * Using qemu-upstream in a stubdomain (none) Will use rump kernels. - Wei Liu * Intel IGD PCI GPU passthrough (ok) v5 posted - Chen, Tiejun == Linux == * VPMU - 'perf' support in Linux (ok) Depends on Xen patches Acked by David Vrabel - Boris Ostrovsky * vNUMA in Linux (ok) v6 posted - Wei Liu * COLO Agent in Linux (fair) - Gui Jianfeng - Yang Hongyang - Dong, Eddie * ARM64 - support 64K guest (none) - Julien Grall == OpenStack == == FreeBSD == * PVH FreeBSD dom0 (ok) FreeBSD 11 goal. Toolstack side done in Xen 4.5 - Roger Pau Monné == Other OSes (MiniOS, QNX) == * ARM - MiniOS (fair) v7 posted - Thomas Leonard * PV drivers for automotive kernels (fair) - Artem Mygaiev == OSSTEST == * OSSTest: stubdom test case (fair) - Wei Liu * OSSTest: libvirt migration (fair) - Wei Liu * OSSTest: upgrade to Debian Jessie (none) - Wei Liu * OSSTest: performance test (fair) - Dario Faggioli * CPU pool test case (fair) - Dario Faggioli * Add a FreeBSD host (fair) - Roger Pau Monné * Nested virt
Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register
On Mon, Jun 08, 2015 at 09:09:15AM +0100, Malcolm Crossley wrote: On 08/06/15 08:42, Jan Beulich wrote: On 07.06.15 at 08:23, m...@redhat.com wrote: On Mon, Apr 20, 2015 at 04:32:12PM +0200, Michael S. Tsirkin wrote: On Mon, Apr 20, 2015 at 03:08:09PM +0100, Jan Beulich wrote: On 20.04.15 at 15:43, m...@redhat.com wrote: On Mon, Apr 13, 2015 at 01:51:06PM +0100, Jan Beulich wrote: On 13.04.15 at 14:47, m...@redhat.com wrote: Can you check device capabilities register, offset 0x4 within pci express capability structure? Bit 15 is 15 Role-Based Error Reporting. Is it set? The spec says: 15 On platforms where robust error handling and PC-compatible Configuration Space probing is required, it is suggested that software or firmware have the Unsupported Request Reporting Enable bit Set for Role-Based Error Reporting Functions, but clear for 1.0a Functions. Software or firmware can distinguish the two classes of Functions by examining the Role-Based Error Reporting bit in the Device Capabilities register. Yes, that bit is set. curiouser and curiouser. So with functions that do support Role-Based Error Reporting, we have this: With device Functions implementing Role-Based Error Reporting, setting the Unsupported Request Reporting Enable bit will not interfere with PC-compatible Configuration Space probing, assuming that the severity for UR is left at its default of non-fatal. However, setting the Unsupported Request Reporting Enable bit will enable the Function to report UR errors 97 detected with posted Requests, helping avoid this case for potential silent data corruption. I still don't see what the PC-compatible config space probing has to do with our issue. I'm not sure but I think it's listed here because it causes a ton of URs when device scan probes unimplemented functions. did firmware reconfigure this device to report URs as fatal errors then? No, the Unsupported Request Error Serverity flag is zero. OK, that's the correct configuration, so how come the box crashes when there's a UR then? Ping - any update on this? Not really. All we concluded so far is that _maybe_ the bridge, upon seeing the UR, generates a Master Abort, rendering the whole thing fatal. Otoh the respective root port also has - Received Master Abort set in its Secondary Status register (but that's also already the case in the log that we have before the UR occurs, i.e. that doesn't mean all that much), - Received System Error set in its Secondary Status register (and after the UR the sibling endpoint [UR originating from 83:00.0, sibling being 83:00.1] also shows Signaled System Error set). Disabling the Memory decode in the command register could also result in a completion timeout on the root port issuing a transaction towards the PCI device in question. Can it really? Such device would violate the PCIE spec, which says: If the request is not claimed, then it is handled as an Unsupported Request, which is the PCI Express equivalent of conventional PCI’s Master Abort termination. PCIE completion timeouts can be escalated to Fatal AER errors which trigger system firmware to inject NMI's into the host. Unsupported requests can also be escalated to be Fatal AER errors (which would again trigger system firmware to inject an NMI). Only if the system is misconfigured. We found out the system in question is not configured to do this. Here is an example AER setup for a PCIE root port. You can see UnsupReq errors are masked and so do not trigger errors. CmpltTO ( completion timeout) errors are not masked and the errors are treated as Fatal because the corresponding bit in the Uncorrectable Severity register is set. Capabilities: [148 v1] Advanced Error Reporting UESta:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt+ UnxCmplt+ RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol+ UESvrt: DLP+ SDES+ TLP+ FCP+ CmpltTO+ CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta:RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk:RxErr+ BadTLP+ BadDLLP+ Rollover+ Timeout+ NonFatalErr+ AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn- A root port completion timeout will also result in the master abort bit being set. How do you figure this one out? The spec I have says master abort is the equivalent of UR. Typically system firmware clears the error in the AER registers after it's processed it. So the operating system may not be able to determine what error triggered the NMI in the first place. At least for debugging, just disable firmware and handle everything in
Re: [Xen-devel] [xen-unstable test] 57852: regressions - FAIL
On Mon, 2015-06-08 at 10:15 +0100, Jan Beulich wrote: On 08.06.15 at 10:53, ian.campb...@citrix.com wrote: That's 6/14 (43%) failure rate on fiano0 and 2/10 (20%) on fiano1. Which differs form the apparent xen-unstable failure rate. But I wouldn't take this as evidence that the two systems differ significantly, despite how the unstable results looked at first glance. So we can basically rule out just one of the hosts being the culprit; it's either both or our software. Considering that (again at the example of the recent 4.2 flight) the guest is apparently waiting for a timer (or other) interrupt (on a HLT instruction), this is very likely interrupt delivery related, yet (as said before, albeit wrongly for 4.3) 4.2 doesn't have APICV support yet (4.3 only lack the option to disable it), so it can't be that (alone). Looking at the hardware - are fiano[01], in terms of CPU and chipset, perhaps the newest or oldest in the pool? (I'm trying to make myself a picture of what debugging options we have.) I don't know much about the hardware in the pool other than what can be gathered from the serial and dmesg logs. http://logs.test-lab.xenproject.org/osstest/logs/58028/test-amd64-amd64-xl-qemuu-win7-amd64/info.html From the serial log and this: Jun 6 12:09:27.089020 (XEN) VMX: Supported advanced features: Jun 6 12:09:27.089052 (XEN) - APIC MMIO access virtualisation Jun 6 12:09:27.097051 (XEN) - APIC TPR shadow Jun 6 12:09:27.097088 (XEN) - Extended Page Tables (EPT) Jun 6 12:09:27.097118 (XEN) - Virtual-Processor Identifiers (VPID) Jun 6 12:09:27.105066 (XEN) - Virtual NMI Jun 6 12:09:27.105100 (XEN) - MSR direct-access bitmap Jun 6 12:09:27.105130 (XEN) - Unrestricted Guest Jun 6 12:09:27.113269 (XEN) - APIC Register Virtualization Jun 6 12:09:27.113290 (XEN) - Virtual Interrupt Delivery Jun 6 12:09:27.113328 (XEN) - Posted Interrupt Processing Jun 6 12:09:27.121180 (XEN) HVM: ASIDs enabled. Jun 6 12:09:27.121235 (XEN) HVM: VMX enabled Jun 6 12:09:27.121267 (XEN) HVM: Hardware Assisted Paging (HAP) detected Jun 6 12:09:27.129069 (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB I guess they are pretty new? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register
On Mon, Jun 08, 2015 at 10:03:18AM +0100, Jan Beulich wrote: On 08.06.15 at 10:09, malcolm.cross...@citrix.com wrote: On 08/06/15 08:42, Jan Beulich wrote: Not really. All we concluded so far is that _maybe_ the bridge, upon seeing the UR, generates a Master Abort, rendering the whole thing fatal. Otoh the respective root port also has - Received Master Abort set in its Secondary Status register (but that's also already the case in the log that we have before the UR occurs, i.e. that doesn't mean all that much), - Received System Error set in its Secondary Status register (and after the UR the sibling endpoint [UR originating from 83:00.0, sibling being 83:00.1] also shows Signaled System Error set). Disabling the Memory decode in the command register could also result in a completion timeout on the root port issuing a transaction towards the PCI device in question. PCIE completion timeouts can be escalated to Fatal AER errors which trigger system firmware to inject NMI's into the host. And how does all that play with PC compatibility (where writes into no-where get dropped, and reads from no-where get all ones returned)? Remember - we#re talking about CPU side accesses here. Here is an example AER setup for a PCIE root port. You can see UnsupReq errors are masked and so do not trigger errors. CmpltTO ( completion timeout) errors are not masked and the errors are treated as Fatal because the corresponding bit in the Uncorrectable Severity register is set. Capabilities: [148 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt+ UnxCmplt+ RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol+ UESvrt: DLP+ SDES+ TLP+ FCP+ CmpltTO+ CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk: RxErr+ BadTLP+ BadDLLP+ Rollover+ Timeout+ NonFatalErr+ AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn- A root port completion timeout will also result in the master abort bit being set. Typically system firmware clears the error in the AER registers after it's processed it. So the operating system may not be able to determine what error triggered the NMI in the first place. Right, but in the case at hand we have an ITP log available, which increases the hope that we see a reasonably complete picture. Do we can chalk this up to hardware bugs on a specific box? I have to admit that I'm still very uncertain whether to consider all this correct behavior, a firmware flaw, or a hardware bug. I believe the correct behaviour is happening but a PCIE completion timeout is occurring instead of a unsupported request. Might it be that with the supposedly correct device returning UR the root port reissues the request to the sibling device, which then fails it in a more dramatic way (albeit the sibling's Uncorrectable Error Status Register also has only Unsupported Request Error Status set)? Jan Isn't the sibling a function on the same device? And is the request causing the UR a memory read? If so doesn't this use address routing? What does it mean that the request is to the sibling device then? Does the sibling device have a BAR overlapping the address? -- MST ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 COLOPre 03/13] libxc/restore: zero ioreq page only one time
On 06/08/2015 05:46 PM, Andrew Cooper wrote: On 08/06/15 04:43, Yang Hongyang wrote: ioreq page contains evtchn which will be set when we resume the secondary vm the first time. The hypervisor will check if the evtchn is corrupted, so we cannot zero the ioreq page more than one time. The ioreq-state is always STATE_IOREQ_NONE after the vm is suspended, so it is OK if we only zero it one time. Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com Signed-off-by: Wen congyang we...@cn.fujitsu.com CC: Andrew Cooper andrew.coop...@citrix.com The issue here is that we are running the restore algorithm over a domain which has already been running in Xen for a while. This is a brand new usecase, as far as I am aware. Exactly. Does the qemu process associated with this domain get frozen while the secondary is being reset, or does the process get destroyed and recreated. What do you mean by reset? do you mean secondary is suspended at checkpoint? I have a gut feeling that it would be safer to clear all of the page other than the event channel, but that depends on exactly what else is going on. We absolutely don't want to do is have an update to this page from the primary with an in-progress IOREQ. ~Andrew --- tools/libxc/xc_sr_restore_x86_hvm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/libxc/xc_sr_restore_x86_hvm.c b/tools/libxc/xc_sr_restore_x86_hvm.c index 6f5af0e..06177e0 100644 --- a/tools/libxc/xc_sr_restore_x86_hvm.c +++ b/tools/libxc/xc_sr_restore_x86_hvm.c @@ -78,7 +78,8 @@ static int handle_hvm_params(struct xc_sr_context *ctx, break; case HVM_PARAM_IOREQ_PFN: case HVM_PARAM_BUFIOREQ_PFN: -xc_clear_domain_page(xch, ctx-domid, entry-value); +if ( !ctx-restore.buffer_all_records ) +xc_clear_domain_page(xch, ctx-domid, entry-value); break; } . -- Thanks, Yang. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] Osstest: stop testing SEDF, start testing RTDS
On Fri, 2015-05-22 at 11:55 +0200, Dario Faggioli wrote: the SEDF scheduler is about to be deprecated and go away (see [1]). OTOH, the RTDS scheduler is here to stay. It therefore makes sense to stop smoke testing the former in favour of the latter. Note that the -sedf-pin jobs where only added in order to try to debug a long standing issue with SEDF; it is not necessary to have anything like that for RTDS. For now, as RTDS is still marked as experimental, test failures are allowed, as it was for SEDF. [1] http://lists.xen.org/archives/html/xen-devel/2015-05/msg02874.html Signed-off-by: Dario Faggioli dario.faggi...@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 v11 4/7] Changes on test step of Debian hvm guest install
On Tue, 2015-05-26 at 17:08 +0800, longtao.pang wrote:
1. The default disk size for guest is '1M' which is not sufficient
for nested HVM guest, using larger disk size for nested guest
to accommodate to nested test requirement, the specific disk_size is
defined by make-flight.
2. In L1 installation context, assign more memory (defined in runvar) to
it; Since it acts as a nested hypervisor anyway.
3. Comment out CDROM entry in sources.list to make HTTP URL entry
available for L1 hvm guest.
4. Enable nestedhvm feature in 'ExtraConfig' for nested job.
Signed-off-by: longtao.pang longtaox.p...@intel.com
Acked-by: Ian Campbell ian.campb...@citrix.com
One query:
[...]
@@ -174,13 +185,18 @@ sub prep () {
if ($host_freemem_mb $ram_lots * 2 + $ram_minslop) {
$ram_mb = $ram_lots;
} else {
-$ram_mb = 768;
+# Use guest_var to get specific memsize, or will use default '768'
+$ram_mb= guest_var($gho,'memsize',768);
I think this only happens if the host has less than $ram_lots * 2 +
$ram_minslop (==10100M) free, otherwise you get $ram_lots (5000M),
which might be less than the runvar asked for...
Perhaps what we really want (maybe in a followup patch is):
$ram_mb = guest_var($gho,'memsize',undef);
if (!$ram_mb) {
if ($host_freemem_mb $ram_lots * 2 + $ram_minslop) {
$ram_mb = $ram_lots;
} else {
$ram_mb = 768;
}
}
?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.4 test] 58137: regressions - FAIL
flight 58137 linux-3.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/58137/ 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-i386-libvirt 9 debian-installfail blocked in 56366-bisect test-amd64-amd64-xl-sedf 9 debian-installfail blocked in 56366-bisect test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-libvirt 9 debian-installfail 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 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-amd64-rumpuserxen-amd64 6 xen-bootfail blocked in 56366-bisect test-amd64-i386-qemut-rhel6hvm-intel 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-i386-freebsd10-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-i386-xl-qemuu-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-amd64-xl-multivcpu 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-rumpuserxen-i386 6 xen-boot 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-libvirt-xsm 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-bootfail blocked in 56366-bisect test-amd64-amd64-xl-qemut-winxpsp3 6 xen-bootfail blocked in 56366-bisect test-amd64-i386-freebsd10-i386 6 xen-bootfail blocked in 56366-bisect test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop 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-amd64-xl-sedf-pin 9 debian-installfail blocked in 56366-bisect test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-bootfail like 53709-bisect Tests which did not succeed, but are not blocking: test-amd64-i386-xl-xsm9 debian-install fail never pass test-amd64-amd64-xl-credit2 9 debian-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-pvh-amd 9 debian-install fail never pass test-amd64-amd64-xl-xsm 9 debian-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-xsmpass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm fail test-amd64-i386-libvirt-xsm
Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register
On 08.06.15 at 11:36, m...@redhat.com wrote: On Mon, Jun 08, 2015 at 10:03:18AM +0100, Jan Beulich wrote: On 08.06.15 at 10:09, malcolm.cross...@citrix.com wrote: I believe the correct behaviour is happening but a PCIE completion timeout is occurring instead of a unsupported request. Might it be that with the supposedly correct device returning UR the root port reissues the request to the sibling device, which then fails it in a more dramatic way (albeit the sibling's Uncorrectable Error Status Register also has only Unsupported Request Error Status set)? Isn't the sibling a function on the same device? Yes. And is the request causing the UR a memory read? No, it's a write according to the ITP log. If so doesn't this use address routing? What does it mean that the request is to the sibling device then? The way I expressed things above may simply be due to my limited knowledge of PCIe terminology: I simply don't know (and can't find this spelled out in the spec) what the root port's behavior ought to be when a transaction comes in with an address that's within one of its base/limit regions, but none of the endpoints can fulfill the request. But you asking this made me look more closely at the memory ranges dumped out to the ITP log: The root port has 0x20: Memory Base = 0xca40 0x22: Memory Limit = 0xca40 0x24: Prefetchable Mem Base= 0xca21 0x26: Prefetchable Mem Limit = 0xca21 while function 0 has 0x10: Base Address Register 0 = 0xca23000c (Memory space, 64-bit access, prefetchable) 0x18: Base Address Register 2 = 0xca24000c (Memory space, 64-bit access, prefetchable) 0x20: Base Address Register 4 = 0xca25000c (Memory space, 64-bit access, prefetchable) and function 1 0x10: Base Address Register 0 = 0xca2c (Memory space, 64-bit access, prefetchable) 0x18: Base Address Register 2 = 0xca21000c (Memory space, 64-bit access, prefetchable) 0x20: Base Address Register 4 = 0xca22000c (Memory space, 64-bit access, prefetchable) Isn't is bogus for all but one of the BARs being outside the root ports prefetchable memory window (the MSI-X tables being inside the BAR 4 region in both cases)? Does the sibling device have a BAR overlapping the address? No, its BARs are fully separate. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Clarifying the state of ARINC653 scheduler (and other components) in Xen 4.5 and beyond
Hi, I wanted to point out that there is some discrepancy on the supported state of the ARINC653 scheduler * http://wiki.xenproject.org/wiki/Xen_Project_Release_Features http://wiki.xenproject.org/wiki/Xen_Project_Release_Features not listed at all * http://wiki.xenproject.org/wiki/Xen_Project_Schedulers#5._ARINC_653_.28Xen_4.0.29 http://wiki.xenproject.org/wiki/Xen_Project_Schedulers#5._ARINC_653_.28Xen_4.0.29 says it's supported Note that I create the page in the run-up to the 4.5 release copying information from http://xenbits.xenproject.org/gitweb/?p=xen.git;a=blob;f=MAINTAINERS;hb=HEAD http://xenbits.xenproject.org/gitweb/?p=xen.git;a=blob;f=MAINTAINERS;hb=HEAD It seems that I tripped over the different definitions of supported in the maintainers file and in Release Features. \ I guess this raises a few questions: a) What feature status should the ARINC653 scheduler be in (and what was its history related to states ) - we should add it to http://wiki.xenproject.org/wiki/Xen_Project_Release_Features http://wiki.xenproject.org/wiki/Xen_Project_Release_Features b) Do we actually have or should have a definition of experimental/preview/supported/deprecated. I don't think this was ever written down and was defined before I joined. Also, there are no real conventions related to changing the state. c) How does b) map to the definitions in http://xenbits.xenproject.org/gitweb/?p=xen.git;a=blob;f=MAINTAINERS;hb=HEAD http://xenbits.xenproject.org/gitweb/?p=xen.git;a=blob;f=MAINTAINERS;hb=HEAD And then there are probably other areas where we may have similar mismatches Best Regards Lars___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] 答复： Re: [PATCH V3 3/6] libxl: add pvusb API
在 2:16 的 2015/5/20 上，在讯息
caflbxzaw3zcsq-8tjph+3cvg4xs-j15_na930hcry8x4grb...@mail.gmail.com 中，George
Dunlap george.dun...@eu.citrix.com 写入：
On Sun, Apr 19, 2015 at 4:50 AM, Chunyan Liu cy...@suse.com wrote:
+int libxl_device_usb_getinfo(libxl_ctx *ctx, char *busid, libxl_usbinfo
*usbinfo)
+{
Sorry, missed something. This function is wrong. It gives you
information about a *host* USB device; but should properly give you
information about a *guest* USB device. The
libxl_device_disk_getinfo() counterpart, for example, takes a domid
and a virtual device (from within a libxl_disk structure) and returns
information about that virtual device.
Maybe the name should be changed as libxl_device_usb_host_info.
Returning *host* USB device info itself is what we need, should not changed.
ctrl, port is the most important information to the virtual device. But like
in 'xl list', it will first list USB controller, and then each port, USB device
appears in some port, it doesn't need to show ctrl, port info again, but
host information is more useful. e.g.:
#xl usb-list test
Devid Type BE state usb-ver ports BE-path
0pv 0 4 1 4 /local/domain/0/backend/vusb/1/0
port 1: Bus 003 Device 005 ID: 8087:07dc Intel Corp.
- Chunyan
Hrm... which makes me wonder whether we should use ctrl,port as a
unique handle for usb devices in the interface, or have a separate
devid for the devices themselves.
-George
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] xen-unstable build fails with XEN_DUMP_DIR undeclader in xl_cmdimpl.c
I saw that config/Paths.mk contains: XEN_DUMP_DIR := /var/lib/xen/dump But build fails with: xl_cmdimpl.c: In function âhandle_domain_deathâ: xl_cmdimpl.c:2330:33: error: âXEN_DUMP_DIRâ undeclared (first use in this function) xl_cmdimpl.c:2330:33: note: each undeclared identifier is reported only once for each function it appears in xl_cmdimpl.c:2330:46: error: expected â)â before string constant With a fast look in code I not found the right cause. Thanks for any reply and sorry for my bad english. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 8/9] Add IOREQ_TYPE_VMWARE_PORT
On 06/04/2015 12:28 PM, Don Slutz wrote: On 06/03/15 13:09, George Dunlap wrote: On 05/22/2015 04:50 PM, Don Slutz wrote: This adds synchronization of the 6 vcpu registers (only 32bits of them) that vmport.c needs between Xen and QEMU. This is to avoid a 2nd and 3rd exchange between QEMU and Xen to fetch and put these 6 vcpu registers used by the code in vmport.c and vmmouse.c In the tools, enable usage of QEMU's vmport code. The currently most useful VMware port support that QEMU has is the VMware mouse support. Xorg included a VMware mouse support that uses absolute mode. This make using a mouse in X11 much nicer. Signed-off-by: Don Slutz dsl...@verizon.com Acked-by: Ian Campbell ian.campb...@citrix.com Sorry for coming a bit late to this party. On a high level I think this is good, but there doesn't seem to be anything in here in particular that is vmware-specific. Would it make more sense to give this a more generic name, and have it include all of the general-purpose registers? I do not know of a more general case. The code here is very VMware in (%dx),%eax specific. The x86 architecture does not have an in/out case where registers other then rax get used and/or changed that need to be sent to QEMU. There already is code to handle ins better then 1 byte at a time. VMWare-specific doesn't mean VMWare is *currently* the only one that uses it; it means that the data passed is so VMWare specific that VMWare is likely to *always* be the only user. All this additional functionality does (as I understand it) is ship over some registers verbatim, and restore them on completion. You could imagine other functionality which might be implemented in qemu (or another ioreq server) that could use functionality like that. For example, this functionality might potentially be of use to the XenGT guys, who need to emulate writes to some pages to shadow the graphics card pagetables; or to someone wanting to implement some sort of introspection feature that is meant to work in both KVM and Xen. The only thing vmware-specific about this at the moment is the particular subset of registers you're copying over. There is also a data size issue. The register data sent over is smaller then the ioreq data. Therefore the number of vCPUs that are supported is the the same. Changing the amount of data sent would effect this (like requiring more then 1 page). Hmm... so it looks like the ioreq struct is about the size of 8 uint32_t's, or 4 uint64_ts. So you could easily include eax, ebx, ecx, edx, esi, edi, eip, esp. But it's not clear that you could do general-purpose emulation without things like ebp, eflags, and so on. Nor is it clear that it would be useful to do only emulation for 32-bit instructions. Would it be terribly bad to make it 4 pages long -- long enough to get most of the 64-bit registers in there if wanted? Or alternately, would it be possible to allow the contents of this page to be changed in the future, perhaps with a domctl? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 COLOPre 04/13] tools/libxc: export xc_bitops.h
Just to note that xc_bitops.h needs cleanup as Andy pointed out in v1...
It will done in v3.
On 06/08/2015 11:43 AM, Yang Hongyang wrote:
When we are under COLO, we will send dirty page bitmap info from
secondary to primary at every checkpoint. So we need to get/test
the dirty page bitmap. We just expose xc_bitops.h for libxl use.
NOTE:
Need to make clean and rerun configure to get it compiled.
Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com
---
tools/libxc/include/xc_bitops.h | 76 +
tools/libxc/xc_bitops.h | 76 -
2 files changed, 76 insertions(+), 76 deletions(-)
create mode 100644 tools/libxc/include/xc_bitops.h
delete mode 100644 tools/libxc/xc_bitops.h
diff --git a/tools/libxc/include/xc_bitops.h b/tools/libxc/include/xc_bitops.h
new file mode 100644
index 000..cd749f4
--- /dev/null
+++ b/tools/libxc/include/xc_bitops.h
@@ -0,0 +1,76 @@
+#ifndef XC_BITOPS_H
+#define XC_BITOPS_H 1
+
+/* bitmap operations for single threaded access */
+
+#include stdlib.h
+#include string.h
+
+#define BITS_PER_LONG (sizeof(unsigned long) * 8)
+#define ORDER_LONG (sizeof(unsigned long) == 4 ? 5 : 6)
+
+#define BITMAP_ENTRY(_nr,_bmap) ((_bmap))[(_nr)/BITS_PER_LONG]
+#define BITMAP_SHIFT(_nr) ((_nr) % BITS_PER_LONG)
+
+/* calculate required space for number of longs needed to hold nr_bits */
+static inline int bitmap_size(int nr_bits)
+{
+int nr_long, nr_bytes;
+nr_long = (nr_bits + BITS_PER_LONG - 1) ORDER_LONG;
+nr_bytes = nr_long * sizeof(unsigned long);
+return nr_bytes;
+}
+
+static inline unsigned long *bitmap_alloc(int nr_bits)
+{
+return calloc(1, bitmap_size(nr_bits));
+}
+
+static inline void bitmap_set(unsigned long *addr, int nr_bits)
+{
+memset(addr, 0xff, bitmap_size(nr_bits));
+}
+
+static inline void bitmap_clear(unsigned long *addr, int nr_bits)
+{
+memset(addr, 0, bitmap_size(nr_bits));
+}
+
+static inline int test_bit(int nr, unsigned long *addr)
+{
+return (BITMAP_ENTRY(nr, addr) BITMAP_SHIFT(nr)) 1;
+}
+
+static inline void clear_bit(int nr, unsigned long *addr)
+{
+BITMAP_ENTRY(nr, addr) = ~(1UL BITMAP_SHIFT(nr));
+}
+
+static inline void set_bit(int nr, unsigned long *addr)
+{
+BITMAP_ENTRY(nr, addr) |= (1UL BITMAP_SHIFT(nr));
+}
+
+static inline int test_and_clear_bit(int nr, unsigned long *addr)
+{
+int oldbit = test_bit(nr, addr);
+clear_bit(nr, addr);
+return oldbit;
+}
+
+static inline int test_and_set_bit(int nr, unsigned long *addr)
+{
+int oldbit = test_bit(nr, addr);
+set_bit(nr, addr);
+return oldbit;
+}
+
+static inline void bitmap_or(unsigned long *dst, const unsigned long *other,
+ int nr_bits)
+{
+int i, nr_longs = (bitmap_size(nr_bits) / sizeof(unsigned long));
+for ( i = 0; i nr_longs; ++i )
+dst[i] |= other[i];
+}
+
+#endif /* XC_BITOPS_H */
diff --git a/tools/libxc/xc_bitops.h b/tools/libxc/xc_bitops.h
deleted file mode 100644
index cd749f4..000
--- a/tools/libxc/xc_bitops.h
+++ /dev/null
@@ -1,76 +0,0 @@
-#ifndef XC_BITOPS_H
-#define XC_BITOPS_H 1
-
-/* bitmap operations for single threaded access */
-
-#include stdlib.h
-#include string.h
-
-#define BITS_PER_LONG (sizeof(unsigned long) * 8)
-#define ORDER_LONG (sizeof(unsigned long) == 4 ? 5 : 6)
-
-#define BITMAP_ENTRY(_nr,_bmap) ((_bmap))[(_nr)/BITS_PER_LONG]
-#define BITMAP_SHIFT(_nr) ((_nr) % BITS_PER_LONG)
-
-/* calculate required space for number of longs needed to hold nr_bits */
-static inline int bitmap_size(int nr_bits)
-{
-int nr_long, nr_bytes;
-nr_long = (nr_bits + BITS_PER_LONG - 1) ORDER_LONG;
-nr_bytes = nr_long * sizeof(unsigned long);
-return nr_bytes;
-}
-
-static inline unsigned long *bitmap_alloc(int nr_bits)
-{
-return calloc(1, bitmap_size(nr_bits));
-}
-
-static inline void bitmap_set(unsigned long *addr, int nr_bits)
-{
-memset(addr, 0xff, bitmap_size(nr_bits));
-}
-
-static inline void bitmap_clear(unsigned long *addr, int nr_bits)
-{
-memset(addr, 0, bitmap_size(nr_bits));
-}
-
-static inline int test_bit(int nr, unsigned long *addr)
-{
-return (BITMAP_ENTRY(nr, addr) BITMAP_SHIFT(nr)) 1;
-}
-
-static inline void clear_bit(int nr, unsigned long *addr)
-{
-BITMAP_ENTRY(nr, addr) = ~(1UL BITMAP_SHIFT(nr));
-}
-
-static inline void set_bit(int nr, unsigned long *addr)
-{
-BITMAP_ENTRY(nr, addr) |= (1UL BITMAP_SHIFT(nr));
-}
-
-static inline int test_and_clear_bit(int nr, unsigned long *addr)
-{
-int oldbit = test_bit(nr, addr);
-clear_bit(nr, addr);
-return oldbit;
-}
-
-static inline int test_and_set_bit(int nr, unsigned long *addr)
-{
-int oldbit = test_bit(nr, addr);
-set_bit(nr, addr);
-return oldbit;
-}
-
-static inline void bitmap_or(unsigned long *dst, const unsigned long *other,
- int nr_bits)
-{
-int i, nr_longs = (bitmap_size(nr_bits) / sizeof(unsigned long));
-for
[Xen-devel] [PATCH v2] VPMU: add lost Intel processor
From: Alan Robinson alan.robin...@ts.fujitsu.com commit 6d112f2b50 (x86/vPMU: change Intel model numbers from decimal to hex) translated 47 to 0x27, now corrected to 0x2f. Signed-off-by: Alan Robinson alan.robin...@ts.fujitsu.com Signed-off-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com --- Changed since v1: (after talking to Dietmar, he's away from his email for a while) * removed non existent model number 0x27 as suggested by Jan Beulich * included reference to when the problem was introduced (also from Jan) xen/arch/x86/hvm/vmx/vpmu_core2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c index 8ad522a..311f35f 100644 --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c @@ -848,7 +848,7 @@ int vmx_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags) /* Westmere: */ case 0x25: /* 32 nm nehalem, Clarkdale, Arrandale */ case 0x2c: /* 32 nm nehalem, Gulftown, Westmere-EP */ -case 0x27: /* 32 nm Westmere-EX */ +case 0x2f: /* 32 nm Westmere-EX */ case 0x3a: /* IvyBridge */ case 0x3e: /* IvyBridge EP */ -- 2.2.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V6 03/10] xen/arm: Use the new functions for vCPUID/vaffinity transformation
On Fri, 2015-06-05 at 19:18 +0100, Julien Grall wrote: On 05/06/2015 16:56, Ian Campbell wrote: On Mon, 2015-06-01 at 20:56 +0800, Chen Baozi wrote: From: Chen Baozi baoz...@gmail.com There are 3 places to change: * Initialise vMPIDR value in vcpu_initialise() * Find the vCPU from vMPIDR affinity information when accessing GICD registers in vGIC * Find the vCPU from vMPIDR affinity information when booting with vPSCI in vGIC - Also make the code for PSCI 0.1 use MPIDR-like value as the cpuid. Does this - Also ... not need to be done at the same time as the change to how we describe things in the FDT? Since that is where the guest gets the parameter from, isn't it? Well, we only support 8 CPUs. I was assuming this would change later in the patch. I don't think PSCI 0.1 is limited to gic v2, is it? (If it is then this is worth mentioning in the commit message too) So this changes will return the same value as before. It may be worth to mention it. In another side, both PSCI 0.1 and PSCI 0.2 are modified to respect the MPIDR like within this patch. The working in the commit message may be misleading. Yes, possibly. Somehow the code path slightly differ when the PSCI 0.2 for guest has been added. The spec says (PSCI 0.1 Section 6.3 (ARM DEN 0022A)): Ideally platform discovery mechanism such as firmware tables would be used by secure firmware to describe the set of valid CPUIDs to the hypervisor or Rich OS, if the former is not present. The hypervisor in turn can create and supply virtual discovery mechanisms to its guests. I interpreted this as CPUID is equal to the reg register in DT (which is an MPIDR-like value). FWIW, this is the interpretation made by Linux too. Documentation/devicetree/bindings/arm/cpus.txt requires it to be the MPIDR value on armv7 and v8. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V6 05/10] xen/arm64: gicv3: Use AFF1 when translating ICC_SGI1R_EL1 to cpumask
On Fri, 2015-06-05 at 19:25 +0100, Julien Grall wrote:
On 05/06/2015 17:09, Ian Campbell wrote:
+ * injection, ignoring level 2 3.
+ */
+if ( gicv3_sgir_to_cpumask(vcpu_mask, sgir) )
+{
+gprintk(XENLOG_WARNING, Wrong affinity in SGI1R_EL
register\n);
I don't think we need to log this. The guest has asked to send an SGI to
a VCPU which we know can't possibly exist. I'm not sure what real h/w
would do, but if it is e.g. UNPREDICTABLE then we should consider
killing the guest here. I suspect it's actually just ignored, in which
case we can silently do the same.
From the spec:
Note: if a bit is one and the bit does not correspond to a valid target
processor, the bit must be ignored by the Distributor. In such cases, a
Distributor may optionally generate an SEI.
The implementation of SEI is implementation defined. I'm not sure what
would be the right behavior to adopt here.
In general I'm in favour of being as harsh as allowed by default (i.e.
without a good reason to do otherwise), to avoid guests coming to rely
on lenient behaviour which we might find we want to change in the
future.
Ian
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [Formal Vote] Changes to Xen Project Security Vulnerability Process - Open until June 8th, 2015
On 5 Jun 2015, at 12:43, Ian Campbell ian.campb...@citrix.com wrote: On Fri, 2015-06-05 at 12:32 +0100, Lars Kurth wrote: On 3 Jun 2015, at 10:35, Ian Campbell ian.campb...@citrix.com wrote: On Mon, 2015-06-01 at 10:36 +0100, Lars Kurth wrote: In the event that we do not have a patch available two working weeks before the disclosure date, we aim to send an advisory that reflects the current state of knowledge to the Xen security pre-disclosure list. An updated advisory will be published as soon as available. I'm a bit concerned about the conditions and frequency with which updated advisories would be expected, but not enough to object, +1. Ian. Ian, would expect that this clause will only really kick in in rare situations, as in the Venom case, where we were waiting for a patch from a 3rd party. For example, if the security team almost has an advisory ready 2 weeks before the disclosure date, I wouldn't expect that anything would change and you just do what you have always done. I think the phrase aim to gives the security team enough flexibility. That was my interpretation of the text (or the intention). I just didn't want to over-codify the text. Does this make sense? Yep, and more importantly I can point to this mail if there is any disagreement about the spirit of the text ;-) Ian. Any more votes from committers? As far was I can see we had Konrad, Ian C and Tim voting. Ian J was on vacation last week and I forgot to CC Jan (apologies). Regards Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 57852: regressions - FAIL
On Mon, 2015-06-08 at 10:15 +0100, Jan Beulich wrote: (I'm trying to make myself a picture of what debugging options we have.) In the meantime I've kicked off an adhoc job using no-apicv as suggested by Andy (on IIRC last week IIRC). Assuming that my tweak takes effect in practice I'll run a bunch of those to hopefully come up with a significant result. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 COLOPre 03/13] libxc/restore: zero ioreq page only one time
On 08/06/15 10:58, Yang Hongyang wrote: On 06/08/2015 05:46 PM, Andrew Cooper wrote: On 08/06/15 04:43, Yang Hongyang wrote: ioreq page contains evtchn which will be set when we resume the secondary vm the first time. The hypervisor will check if the evtchn is corrupted, so we cannot zero the ioreq page more than one time. The ioreq-state is always STATE_IOREQ_NONE after the vm is suspended, so it is OK if we only zero it one time. Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com Signed-off-by: Wen congyang we...@cn.fujitsu.com CC: Andrew Cooper andrew.coop...@citrix.com The issue here is that we are running the restore algorithm over a domain which has already been running in Xen for a while. This is a brand new usecase, as far as I am aware. Exactly. Does the qemu process associated with this domain get frozen while the secondary is being reset, or does the process get destroyed and recreated. What do you mean by reset? do you mean secondary is suspended at checkpoint? Well - at the point that the buffered records are being processed, we are in the process of resetting the state of the secondary to match the primary. ~Andrew I have a gut feeling that it would be safer to clear all of the page other than the event channel, but that depends on exactly what else is going on. We absolutely don't want to do is have an update to this page from the primary with an in-progress IOREQ. ~Andrew --- tools/libxc/xc_sr_restore_x86_hvm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/libxc/xc_sr_restore_x86_hvm.c b/tools/libxc/xc_sr_restore_x86_hvm.c index 6f5af0e..06177e0 100644 --- a/tools/libxc/xc_sr_restore_x86_hvm.c +++ b/tools/libxc/xc_sr_restore_x86_hvm.c @@ -78,7 +78,8 @@ static int handle_hvm_params(struct xc_sr_context *ctx, break; case HVM_PARAM_IOREQ_PFN: case HVM_PARAM_BUFIOREQ_PFN: -xc_clear_domain_page(xch, ctx-domid, entry-value); +if ( !ctx-restore.buffer_all_records ) +xc_clear_domain_page(xch, ctx-domid, entry-value); break; } . ___ 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 19/05/15 07:08, 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. Applied to for-linus-4.2, thanks. This patch is a bit redundant in a commit message so I tweaked it to read: struct timeval uses a 32-bit field for representing seconds, which will overflow in the year 2038 and beyond. Replace struct timeval with 64-bit ktime_t which is 2038 safe. This 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 -- Use 3 hyphens as a separator here. Changes in v2: David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 57852: regressions - FAIL
On 08.06.15 at 11:27, ian.campb...@citrix.com wrote: I don't know much about the hardware in the pool other than what can be gathered from the serial and dmesg logs. Right - this is useful for learning details of an individual system, but isn't really helpful when wanting to compare all system kinds that are in the pool. From the serial log and this: Jun 6 12:09:27.089020 (XEN) VMX: Supported advanced features: Jun 6 12:09:27.089052 (XEN) - APIC MMIO access virtualisation Jun 6 12:09:27.097051 (XEN) - APIC TPR shadow Jun 6 12:09:27.097088 (XEN) - Extended Page Tables (EPT) Jun 6 12:09:27.097118 (XEN) - Virtual-Processor Identifiers (VPID) Jun 6 12:09:27.105066 (XEN) - Virtual NMI Jun 6 12:09:27.105100 (XEN) - MSR direct-access bitmap Jun 6 12:09:27.105130 (XEN) - Unrestricted Guest Jun 6 12:09:27.113269 (XEN) - APIC Register Virtualization Jun 6 12:09:27.113290 (XEN) - Virtual Interrupt Delivery Jun 6 12:09:27.113328 (XEN) - Posted Interrupt Processing Jun 6 12:09:27.121180 (XEN) HVM: ASIDs enabled. Jun 6 12:09:27.121235 (XEN) HVM: VMX enabled Jun 6 12:09:27.121267 (XEN) HVM: Hardware Assisted Paging (HAP) detected Jun 6 12:09:27.129069 (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB I guess they are pretty new? Looks like so, yes. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register
On 08.06.15 at 11:30, m...@redhat.com wrote: On Mon, Jun 08, 2015 at 08:42:57AM +0100, Jan Beulich wrote: Otoh the respective root port also has - Received Master Abort set in its Secondary Status register (but that's also already the case in the log that we have before the UR occurs, i.e. that doesn't mean all that much), - Received System Error set in its Secondary Status register (and after the UR the sibling endpoint [UR originating from 83:00.0, sibling being 83:00.1] also shows Signaled System Error set). It's another function of the same physical device, correct? Yes (obviously with their BDF only differing in the function). So is this sibling the only function sending SERR? Yes, albeit I can't tell whether the root port generated SERR on its own or in response to the endpoint doing so. What happens if you disable SERR# in the command register of 83:00.1? Any experiments with that system will be quite difficult, as they're only accessible by partners or ours. But I'll ask to try this if you think this can provide useful insight. Do we can chalk this up to hardware bugs on a specific box? I have to admit that I'm still very uncertain whether to consider all this correct behavior, a firmware flaw, or a hardware bug. Questions: 1. Does this only happen with a specific endpoint? What if you add another endpoint to the same system? We've got reports of this for two systems (two different vendors) using a Broadcomm NIC in one case and an Intel one in the other. 2. Has a driver initialized this endpoint? What if you don't load a driver before sending the transaction resulting in the UR? I'd have to ask for this to be tried too, and getting an answer may take some time. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v2] xSplice design
On 08.06.15 at 10:34, mpohl...@amazon.com wrote: On 05.06.2015 17:27, Jan Beulich wrote: On 05.06.15 at 17:00, konrad.w...@oracle.com wrote: On Wed, May 20, 2015 at 05:11:20PM +0200, Martin Pohlack wrote: * Xen as it is now, has a couple of non-unique symbol names which will make runtime symbol identification hard. Sometimes, static symbols simply have the same name in C files, sometimes such symbols get included via header files, and some C files are also compiled multiple times and linked under different names (guest_walk.c). I think the Linux kernel solves this by aiming at unique symbol names even for local symbols. nm xen-syms | cut -f3- -d\ | sort | uniq -c | sort -nr | head Oh my. Looks like a couple of prepartion patches will be in order! Just because nm doesn't express this doesn't mean we have to special case them: In ELF (and in COFF too, which is relevant as long as xen.efi still remains to be a separate binary) static symbols can easily be qualified by their source or object file name - the symbol table certainly has that information available. As said on the hackathon, our current kallsyms mechanism - using nm output - suffers from this too, yet I personally view it as rather bad practice to add a globally unique prefix to local symbol names. Instead, as also said there, we should switch to consuming the full ELF symbol table. That's been on my todo list for two years or more - if only I would ever get the time to do things like that... Hmm, in my experience, you have file-type symbols in the symbol table that refer to source-code files and you have source-file references in the dwarf debug information. I have *not* seen references to object-files in either place The linker can insert such. But the case likely isn't of interest in our scenario anyway. and as some C-files are compiled multiple times in Xen (guest_walk.c), the mapping is not unique. And I suppose there are always going to be cases where manual intervention is required. All we can aim for is making as little of such necessary as possible. Further, as soon as non-trivial linker scripts are used, the symbol ordering in the final xen-syms does not necessarily reflect original object-file contents anymore. But the linker should ensure that static symbols don't lose their association with the respective STT_FILE symbol. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 COLOPre 03/13] libxc/restore: zero ioreq page only one time
On 08/06/15 04:43, Yang Hongyang wrote: ioreq page contains evtchn which will be set when we resume the secondary vm the first time. The hypervisor will check if the evtchn is corrupted, so we cannot zero the ioreq page more than one time. The ioreq-state is always STATE_IOREQ_NONE after the vm is suspended, so it is OK if we only zero it one time. Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com Signed-off-by: Wen congyang we...@cn.fujitsu.com CC: Andrew Cooper andrew.coop...@citrix.com The issue here is that we are running the restore algorithm over a domain which has already been running in Xen for a while. This is a brand new usecase, as far as I am aware. Does the qemu process associated with this domain get frozen while the secondary is being reset, or does the process get destroyed and recreated. I have a gut feeling that it would be safer to clear all of the page other than the event channel, but that depends on exactly what else is going on. We absolutely don't want to do is have an update to this page from the primary with an in-progress IOREQ. ~Andrew --- tools/libxc/xc_sr_restore_x86_hvm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/libxc/xc_sr_restore_x86_hvm.c b/tools/libxc/xc_sr_restore_x86_hvm.c index 6f5af0e..06177e0 100644 --- a/tools/libxc/xc_sr_restore_x86_hvm.c +++ b/tools/libxc/xc_sr_restore_x86_hvm.c @@ -78,7 +78,8 @@ static int handle_hvm_params(struct xc_sr_context *ctx, break; case HVM_PARAM_IOREQ_PFN: case HVM_PARAM_BUFIOREQ_PFN: -xc_clear_domain_page(xch, ctx-domid, entry-value); +if ( !ctx-restore.buffer_all_records ) +xc_clear_domain_page(xch, ctx-domid, entry-value); break; } ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Draft D] Xen on ARM vITS Handling
On Fri, 2015-06-05 at 22:41 +0530, Vijay Kilari wrote: On Fri, Jun 5, 2015 at 10:08 PM, Ian Campbell ian.campb...@citrix.com wrote: On Fri, 2015-06-05 at 21:25 +0530, Vijay Kilari wrote: Let xen mark those phantom devices added using MAPD as dummy and just emulate and does not translate ITS commands for these devices. But we think guests might use this mechanism to drive completion (instead of polling), so we have to translate INT commands for such devices, don't we? Otherwise such guests won't work. I propose, for guests that use completion INT, the XEN can inject lpi by calling vgic_interrupt_inject instead of ITS HW raising interrupt. Have you read this draft? It says exactly that. This draft is significantly different from the one which came before, it is worth rereading the whole thing since most assumption made based on draft C will now be invalid. So deviceid of any MAPD command for all the guests should be have been within pre-identified list. I don't think that is true for a domU, not necessarily for a dom0 given that any device id can be used with INT. If the INT command is with valid device (not phantom) then Xen can translate and send to ITS hardware That is not what this design says, Xen will translate and call vgic_interrupt_inject, which doesn't go via the hardware ITS at all, since it doesn't need to. I mean, For valid devices, LPI interrupt will be raised when ITS hw process INT command. from there interrupt handler will inject to domain For phantom devices, Xen will inject to directly to domain on seeing INT command. (we have to ensure that all ITS commands are processed before injecting INT to domain) The design says to use vgic_interrupt_inject for INT commands on any device, whether phantom or real. It makes no distinction, because it doesn't need to. [...] Sorry. I correct it as So effectively no physical commands are sent to ITS hardware that are related to dummy/phantom devices Remember that in this design the vits doesn't generate any commands to the physical its _at all_ even for real devices. It just calls core/generic APIs. OK. you mean pITS driver owns translation and sending ITS commands to HW instead of vITS? No, there is no translation in this design. e.g. the vits sees a command which should enable an interrupt. After figuring out which plpi corresponds it just calls enable_irq(plpi). It doesn't care what that turns into, core interrupt handling core and the backend pgic driver will take care of doing what is requested. That same is true for all commands in this design. In draft D of this design there is _no_ linkage between vits and pits at all. It is completely abstracted. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 4/5] libxl: change xs path for pv qemu
On Thu, Jun 04, 2015 at 12:28:18PM +0100, Stefano Stabellini wrote:
If QEMU is ran just to provide PV backends, change the xenstore path to
/local/domain/0/device-model/$DOMID/pv.
Add a parameter to libxl__device_model_xs_path to distinguish the device
model from the pv backends provider.
Store the device model binary path under
/local/domain/$DOMID/device-model on xenstore, so that we can fetch it
later and retrieve the list of supported options from
/local/domain/0/libxl/$device_model_binary, introduce in the previous
path.
TBH this protocol works, but it is not very extensible.
I envisaged we need to assign $emulator_id to different device models
when I fixed stubdom, but I never got to that since there weren't need
for multiple emulators.
That is, as an example:
/local/domain/$backend_domid/device-model/$domid/$emulator_id/xxx
That way we can:
1. Have something like multidev in libxl to wait for several device
models to be ready without writing tedious code for every single one.
2. Fit into libxl migration stream, which naturally uses $emulator_id to
distinguish different emulators.
The downside of this is we need to add an extra option to QEMU to accept
the emulator id assigned by toolstack.
Just my two cents.
Wei.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
tools/libxl/libxl.c |2 +-
tools/libxl/libxl_device.c |2 +-
tools/libxl/libxl_dm.c | 20
tools/libxl/libxl_dom.c | 12 ++--
tools/libxl/libxl_internal.c | 19 +++
tools/libxl/libxl_internal.h |5 ++---
tools/libxl/libxl_pci.c | 14 +++---
7 files changed, 44 insertions(+), 30 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 516713e..bca4c88 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1035,7 +1035,7 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
if (type == LIBXL_DOMAIN_TYPE_HVM) {
uint32_t dm_domid = libxl_get_stubdom_id(ctx, domid);
-path = libxl__device_model_xs_path(gc, dm_domid, domid, /state);
+path = libxl__device_model_xs_path(gc, false, dm_domid, domid,
/state);
state = libxl__xs_read(gc, XBT_NULL, path);
if (state != NULL !strcmp(state, paused)) {
libxl__qemu_traditional_cmd(gc, domid, continue);
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 93bb41e..aadcd08 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -1190,7 +1190,7 @@ int libxl__wait_for_device_model_deprecated(libxl__gc
*gc,
char *path;
uint32_t dm_domid = libxl_get_stubdom_id(CTX, domid);
-path = libxl__device_model_xs_path(gc, dm_domid, domid, /state);
+path = libxl__device_model_xs_path(gc, false, dm_domid, domid, /state);
return libxl__xenstore_child_wait_deprecated(gc, domid,
LIBXL_DEVICE_MODEL_START_TIMEOUT,
Device Model, path, state, spawning,
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index b37a84a..29ef8ae 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1267,9 +1267,9 @@ void libxl__spawn_stub_dm(libxl__egc *egc,
libxl__stub_dm_spawn_state *sdss)
retry_transaction:
t = xs_transaction_start(ctx-xsh);
xs_mkdir(ctx-xsh, t,
- libxl__device_model_xs_path(gc, dm_domid, guest_domid, ));
+ libxl__device_model_xs_path(gc, false, dm_domid, guest_domid,
));
xs_set_permissions(ctx-xsh, t,
- libxl__device_model_xs_path(gc, dm_domid,
+ libxl__device_model_xs_path(gc, false, dm_domid,
guest_domid, ),
perm, ARRAY_SIZE(perm));
if (!xs_transaction_end(ctx-xsh, t, 0))
@@ -1430,7 +1430,7 @@ static void stubdom_pvqemu_cb(libxl__egc *egc,
sdss-xswait.what = GCSPRINTF(Stubdom %u for %u startup,
dm_domid, sdss-dm.guest_domid);
sdss-xswait.path =
-libxl__device_model_xs_path(gc, dm_domid, sdss-dm.guest_domid,
+libxl__device_model_xs_path(gc, true, dm_domid, sdss-dm.guest_domid,
/state);
sdss-xswait.timeout_ms = LIBXL_STUBDOM_START_TIMEOUT * 1000;
sdss-xswait.callback = stubdom_xswait_cb;
@@ -1566,7 +1566,8 @@ void libxl__spawn_local_dm(libxl__egc *egc,
libxl__dm_spawn_state *dmss)
free(path);
}
-path = libxl__device_model_xs_path(gc, LIBXL_TOOLSTACK_DOMID, domid, );
+path = libxl__device_model_xs_path(gc, b_info-type ==
LIBXL_DOMAIN_TYPE_PV,
+ LIBXL_TOOLSTACK_DOMID, domid, );
rwperm[0].id = LIBXL_TOOLSTACK_DOMID;
rwperm[0].perms = XS_PERM_NONE;
rwperm[1].id = domid;
@@ -1595,6 +1596,8 @@ void
Re: [Xen-devel] Backport request libxl: In libxl_set_vcpuonline check for maximum number of VCPUs against the cpumap. (Was: Re: [Bug report] Security issue in xl vcpu-set)
Luwei Cheng writes (Re: Backport request libxl: In libxl_set_vcpuonline check for maximum number of VCPUs against the cpumap. (Was: Re: [Bug report] Security issue in xl vcpu-set)): Some third-part management tools might be built directly above xl. Perhaps they can not rely on Ctrl-C.. In general callers of libxl will not be built to raise SIGINT. For example, if libvirt called this function in a way that triggers the bug, there wouldn't be any reasonable way to recover control. I'm afraid I'm still not clear about when the failure can be triggered by an attacker. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 57852: regressions - FAIL
On Mon, 2015-06-08 at 09:07 +0100, Jan Beulich wrote: On 05.06.15 at 12:48, ian.campb...@citrix.com wrote: On Fri, 2015-06-05 at 10:18 +0100, Jan Beulich wrote: On 05.06.15 at 11:07, ian.campb...@citrix.com wrote: WRT the move to the colo, flights in 5 are in the new one, while 3 are in the old one, http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64 -xl-qemuu-win7-amd64.xen-unstable.html shows that things seemed ok for 8 consecutive runs after the move (ignoring blockages). And when it went live, all systems being in use now got immediately deployed? All the flights in the new colo seem to have been on fiano[01]. So are there just two hosts to run all x86 tests on? I thought one of the purposes of the switch was to have a wider pool of test systems... There are about a dozen, but when a test is failing osstest will have a preference for the host on which it failed last time (i.e. failures become sticky to the host), in order to catch host specific failures I think. I think it was just coincidence that the first group of runs which passed were on fiano0, although perhaps the pool was smaller then since the colo was in the process of being commissioned. The stickiness does make it a bit harder to know if a failure is host specific though, since you often don't get results for other systems. But having looked at the page again the early success was all on fiano0 while the later failures were all on fiano1. But that's for the unstable install failures only as it looks. At the example of flight 57955 (testing 4.2) a local migration failure was observed on fiano0. Which would seem to support your earlier assumption that the install and migration issues are likely unrelated (yet their coincidence still strikes me as odd). http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemuu-win7-amd64.html has the cross branch history for this test case. With one exception (on chardonay0, in a linux-next test) all the fails were on fiano[01] and they were all on branches which would use xen-unstable as the Xen version (xen-unstable itself and linux-* + qemu-mainline which both use the current xen.git#master as their Xen). I've got some adhoc results over the weekend, all can be found at http://logs.test-lab.xenproject.org/osstest/logs/N/test-amd64-amd64-xl-qemuu-win7-amd64/info.html for flight N. All of them are using the binaries from 57852. I messed up my first command line and ran them all on fiano0 by mistake, so there are more results than I was planning for. Flight HostFailed at Install step duration 57940 fiano0 ts-guest-stop 1483 57945 fiano0 ts-guest-stop 1640 57953 fiano0 ts-guest-stop 1473 57958 fiano0 ts-guest-stop 1472 57962 fiano0 windows-install 7512 57973 fiano0 windows-install 7693 57080 fiano0 ts-guest-stop 1534 57986 fiano0 windows-install 7203 57933 fiano0 ts-guest-stop 1529 57997 fiano0 ts-guest-stop 1494 58004 fiano0 ts-guest-stop 1492 58011 fiano1 ts-guest-stop 1408 58012 fiano1 ts-guest-stop 1529 58017 fiano1 ts-guest-stop 1466 58023 fiano1 ts-guest-stop 1624 58028 fiano1 windows-install 7208 58038 fiano1 ts-guest-stop 1479 58043 fiano1 ts-guest-stop 1493 58053 fiano0 windows-install 7439 58062 fiano0 windows-install 1916 58063 fiano0 windows-install 1477 58067 fiano1 ts-guest-stop 1453 58071 fiano1 ts-guest-stop 1550 58077 fiano1 windows-install 7156 That's 6/14 (43%) failure rate on fiano0 and 2/10 (20%) on fiano1. Which differs form the apparent xen-unstable failure rate. But I wouldn't take this as evidence that the two systems differ significantly, despite how the unstable results looked at first glance. On successful install the test step takes 1450-1650s, with one outlier at 1916. The failures take 7000-7500s (test case timeout is 7000, so with slop that fits). So on success it takes 30mins and on fail it has been given nearly 2hours. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 6/9] x86/intel_pstate: the main boby of the intel_pstate driver
On 08.06.15 at 10:18, wei.w.w...@intel.com wrote: Regarding the self-documenting related comment here, which of the following do you think is better? 1) #define BYT_MIN_PSTATE_SHIFT8 #define BYT_MAX_PSTATE_SHIFT 16 #define BYT_PSTATE_MASK 0x7f #define BYT_TURBO_CONTROL_BIT32 2) #define BYT_MIN_PSTATE(value) (((value) 8) 0x7F) #define BYT_MAX_PSTATE(value)(((value) 16) 0x7F) #define BYT_SET_TURBO_CONTROL_BIT(value)((val) |= (u64)1 32) I think the first two of 2) and the fourth one of 1) are the best combination, but I'd really leave it up to you (with, if using it, the val vs value issue fixed in the last one). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 COLOPre 01/13] libxc/restore: fix error handle of process_record
On 06/08/2015 05:24 PM, Andrew Cooper wrote:
On 08/06/15 04:43, Yang Hongyang wrote:
If the err is RECORD_NOT_PROCESSED, and it is an optional record,
restore will still fail. The patch fix this.
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/libxc/xc_sr_restore.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c
index 9e27dba..2d2edd3 100644
--- a/tools/libxc/xc_sr_restore.c
+++ b/tools/libxc/xc_sr_restore.c
@@ -560,19 +560,6 @@ static int process_record(struct xc_sr_context *ctx,
struct xc_sr_record *rec)
free(rec-data);
rec-data = NULL;
-if ( rc == RECORD_NOT_PROCESSED )
-{
-if ( rec-type REC_TYPE_OPTIONAL )
-DPRINTF(Ignoring optional record %#x (%s),
-rec-type, rec_type_to_str(rec-type));
You would be best setting rc to 0 here, rather than moving the logic out
of process_record().
There will be another error type in COLO, which indicates a failover, that
needs to be handled in restore(), so I moved the error handling down to
avoid duplex code...Otherwise, in process_record, RECORD_NOT_PROCESSED is
handled, and in restore another error type returned from process_record is
handled...
~Andrew
-else
-{
-ERROR(Mandatory record %#x (%s) not handled,
- rec-type, rec_type_to_str(rec-type));
-rc = -1;
-}
-}
-
return rc;
}
@@ -678,7 +665,20 @@ static int restore(struct xc_sr_context *ctx)
else
{
rc = process_record(ctx, rec);
-if ( rc )
+if ( rc == RECORD_NOT_PROCESSED )
+{
+if ( rec.type REC_TYPE_OPTIONAL )
+DPRINTF(Ignoring optional record %#x (%s),
+rec.type, rec_type_to_str(rec.type));
+else
+{
+ERROR(Mandatory record %#x (%s) not handled,
+ rec.type, rec_type_to_str(rec.type));
+rc = -1;
+goto err;
+}
+}
+else if ( rc )
goto err;
}
.
--
Thanks,
Yang.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
