Re: [Xen-devel] [PULL 0/5] xen-220615
On 23 June 2015 at 11:30, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: On Tue, 23 Jun 2015, Peter Maydell wrote: I'm afraid I can't apply this -- this revert commit is missing a signed-off-by line. Can you respin, please? I thought that being a straight revert, didn't need a SOB line. xen-220615-2 is the tag with SOB line on the last commit: git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-220615-2 xen/pass-through: fold host PCI command register writes only has Jan's signoff, not yours too... (apologies for not noticing that first time around.) I have a bit in my pull-request-creation script that automatically checks that every commit has my signoff, to avoid this kind of mistake: https://git.linaro.org/people/peter.maydell/misc-scripts.git/blob/HEAD:/make-pullreq#l98 thanks -- PMM ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] Revert libxl: fix xl mem-set regression from 0c029c4da2
On Tue, 2015-06-23 at 15:52 +0100, Wei Liu wrote: On Tue, Jun 23, 2015 at 03:45:14PM +0100, Jan Beulich wrote: On 23.06.15 at 16:16, wei.l...@citrix.com wrote: This reverts commit f5b43e95facdc17f925cb56a8963cd4531074034. Even if the patch having introduced the regression this fixed is being reverted, it's not clear to me why this change needs to be reverted too - it seems correct to me to use 64-bit types for the calculations. Or are you planning to do a more comprehensive adjustments to all of the types later on? I was thinking more about giving Ian (who is looking at making things consistent) a clean state to start with. He may end up touching those types. This patch itself looks correct to me. Ian, I think I will send a patch to revert the only offending commit and fix up conflicts. Are you OK with that. Yes, it's the right thing to do, I didn't correctly remember what Jan's fixup was doing when I thought we should revert it. I've just sent out a locking patch fix, which may not now apply due to this change. I'll rebase if that turns out to be needed, I think it'll just be some lite-contextual differences. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/3] x86: further is_..._...() adjustments
1: drop is_pv_32on64_vcpu() 2: drop is_pv_32on64_domain() 3: use is_..._vcpu() instead of open coding it Some of this extends into common code, hence the wider Cc list. Signed-off-by: Jan Beulich jbeul...@suse.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/3] x86: drop is_pv_32on64_vcpu()
... as being identical to is_pv_32bit_vcpu() after the x86-32 removal.
In a few cases this includes an additional is_pv_32bit_vcpu() -
is_pv_32bit_domain() conversion.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1339,7 +1339,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_m
mctelem_cookie_t cookie = ID2COOKIE(mc_fetch.nat-fetch_id);
mctelem_ack(which, cookie);
} else {
-if (!is_pv_32on64_vcpu(v)
+if (!is_pv_32bit_vcpu(v)
? guest_handle_is_null(mc_fetch.nat-data)
: compat_handle_is_null(mc_fetch.cmp-data))
return x86_mcerr(do_mca fetch: guest buffer
@@ -1347,7 +1347,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_m
if ((mctc = mctelem_consume_oldest_begin(which))) {
struct mc_info *mcip = mctelem_dataptr(mctc);
-if (!is_pv_32on64_vcpu(v)
+if (!is_pv_32bit_vcpu(v)
? copy_to_guest(mc_fetch.nat-data, mcip, 1)
: copy_to_compat(mc_fetch.cmp-data,
mcip, 1)) {
@@ -1378,7 +1378,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_m
mc_physcpuinfo.nat = op-u.mc_physcpuinfo;
nlcpu = num_online_cpus();
-if (!is_pv_32on64_vcpu(v)
+if (!is_pv_32bit_vcpu(v)
? !guest_handle_is_null(mc_physcpuinfo.nat-info)
: !compat_handle_is_null(mc_physcpuinfo.cmp-info)) {
if (mc_physcpuinfo.nat-ncpus = 0)
@@ -1389,7 +1389,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_m
if (log_cpus == NULL)
return x86_mcerr(do_mca cpuinfo, -ENOMEM);
on_each_cpu(do_mc_get_cpu_info, log_cpus, 1);
-if (!is_pv_32on64_vcpu(v)
+if (!is_pv_32bit_vcpu(v)
? copy_to_guest(mc_physcpuinfo.nat-info,
log_cpus, nlcpu)
: copy_to_compat(mc_physcpuinfo.cmp-info,
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -496,7 +496,7 @@ int vcpu_initialise(struct vcpu *v)
void vcpu_destroy(struct vcpu *v)
{
-if ( is_pv_32on64_vcpu(v) )
+if ( is_pv_32bit_vcpu(v) )
release_compat_l4(v);
vcpu_destroy_fpu(v);
@@ -1705,7 +1705,7 @@ unsigned long hypercall_create_continuat
curr-arch.hvm_vcpu.hcall_preempted = 1;
if ( is_pv_vcpu(curr) ?
- !is_pv_32on64_vcpu(curr) :
+ !is_pv_32bit_vcpu(curr) :
curr-arch.hvm_vcpu.hcall_64bit )
{
for ( i = 0; *p != '\0'; i++ )
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2652,7 +2652,7 @@ int vcpu_destroy_pagetables(struct vcpu
if ( rc )
return rc;
-if ( is_pv_32on64_vcpu(v) )
+if ( is_pv_32bit_vcpu(v) )
{
l4tab = map_domain_page(mfn);
mfn = l4e_get_pfn(*l4tab);
--- a/xen/arch/x86/trace.c
+++ b/xen/arch/x86/trace.c
@@ -11,7 +11,7 @@ void __trace_hypercall_entry(void)
struct cpu_user_regs *regs = guest_cpu_user_regs();
unsigned long args[6];
-if ( is_pv_32on64_vcpu(current) )
+if ( is_pv_32bit_vcpu(current) )
{
args[0] = regs-ebx;
args[1] = regs-ecx;
@@ -36,7 +36,7 @@ void __trace_hypercall_entry(void)
void __trace_pv_trap(int trapnr, unsigned long eip,
int use_error_code, unsigned error_code)
{
-if ( is_pv_32on64_vcpu(current) )
+if ( is_pv_32bit_vcpu(current) )
{
struct __packed {
unsigned eip:32,
@@ -77,7 +77,7 @@ void __trace_pv_page_fault(unsigned long
{
unsigned long eip = guest_cpu_user_regs()-eip;
-if ( is_pv_32on64_vcpu(current) )
+if ( is_pv_32bit_vcpu(current) )
{
struct __packed {
u32 eip, addr, error_code;
@@ -108,7 +108,7 @@ void __trace_pv_page_fault(unsigned long
void __trace_trap_one_addr(unsigned event, unsigned long va)
{
-if ( is_pv_32on64_vcpu(current) )
+if ( is_pv_32bit_vcpu(current) )
{
u32 d = va;
__trace_var(event, 1, sizeof(d), d);
@@ -123,7 +123,7 @@ void __trace_trap_one_addr(unsigned even
void __trace_trap_two_addr(unsigned event, unsigned long va1,
unsigned long va2)
{
-if ( is_pv_32on64_vcpu(current) )
+if ( is_pv_32bit_vcpu(current) )
{
struct __packed {
u32 va1, va2;
@@ -156,7 +156,7 @@ void __trace_ptwr_emulation(unsigned lon
* cases, unsigned long is the size of a guest virtual address.
*/
-if ( is_pv_32on64_vcpu(current) )
+if ( is_pv_32bit_vcpu(current) )
{
struct __packed {
l1_pgentry_t pte;
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -124,7 +124,7 @@ static void show_guest_stack(struct vcpu
if ( is_hvm_vcpu(v) )
return;
-if ( is_pv_32on64_vcpu(v) )
+if ( is_pv_32bit_vcpu(v) )
{
Re: [Xen-devel] [PATCH 3/3] x86/mm: use is_..._vcpu() instead of open coding it
On 23/06/15 16:20, Jan Beulich wrote: Signed-off-by: Jan Beulich jbeul...@suse.com Reviewed-by: Andrew Cooper andrew.coop...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 00/18] x86/hvm: I/O emulation cleanup and fix
Il 23/06/2015 12:39, Paul Durrant ha scritto: This patch series re-works much of the code involved in emulation of port and memory mapped I/O for HVM guests. The code has become very convoluted and, at least by inspection, certain emulations will apparently malfunction. The series is broken down into 18 patches (which are also available in my xenbits repo: http://xenbits.xen.org/gitweb/?p=people/pauldu/xen.git on the emulation25 branch) as follows: 0001-x86-hvm-simplify-hvmemul_do_io.patch 0002-x86-hvm-remove-hvm_io_pending-check-in-hvmemul_do_io.patch 0003-x86-hvm-remove-extraneous-parameter-from-hvmtrace_io.patch 0004-x86-hvm-make-sure-translated-MMIO-reads-or-writes-fa.patch 0005-x86-hvm-remove-multiple-open-coded-chunking-loops.patch 0006-x86-hvm-re-name-struct-hvm_mmio_handler-to-hvm_mmio_.patch 0007-x86-hvm-unify-internal-portio-and-mmio-intercepts.patch 0008-x86-hvm-add-length-to-mmio-check-op.patch 0009-x86-hvm-unify-dpci-portio-intercept-with-standard-po.patch 0010-x86-hvm-unify-stdvga-mmio-intercept-with-standard-mm.patch 0011-x86-hvm-revert-82ed8716b-fix-direct-PCI-port-I-O-emu.patch 0012-x86-hvm-only-call-hvm_io_assist-from-hvm_wait_for_io.patch 0013-x86-hvm-split-I-O-completion-handling-from-state-mod.patch 0014-x86-hvm-remove-HVMIO_dispatched-I-O-state.patch 0015-x86-hvm-remove-hvm_io_state-enumeration.patch 0016-x86-hvm-use-ioreq_t-to-track-in-flight-state.patch 0017-x86-hvm-always-re-emulate-I-O-from-a-buffer.patch 0018-x86-hvm-track-large-memory-mapped-accesses-by-buffer.patch v2: - Removed bogus assertion from patch 16 - Re-worked patch 17 after basic testing of back-port onto XenServer v3: - Addressed comments from Jan - Re-ordered series to bring a couple of more trivial patches to the front - Backport to XenServer (4.5) now passing automated tests - Tested on unstable with QEMU upstream and trad, with and without HAP (to force shadow emulation) Thanks, I tested this serie emulation25 branch of your git. I not found regression for now but trying qxl linux domUs that before caused qemu crash on sse2 operations now qemu didn't crashed but screen showed nothing and qemu process of domU with cpu at 100% and I'm unable to found details in dom0 about the problem, seems similar to xen-unstable of one year ago. Someone can tell me a way to know if sse2 istructions are now fully working (including operations with videoram) and/or how to debug this problem without nothing that crashes where take datas with gdb? 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
[Xen-devel] [PATCH 3/3] x86/mm: use is_..._vcpu() instead of open coding it
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1851,9 +1851,7 @@ unsigned long paging_gva_to_gfn(struct v
struct p2m_domain *hostp2m = p2m_get_hostp2m(v-domain);
const struct paging_mode *hostmode = paging_get_hostmode(v);
-if ( is_hvm_domain(v-domain)
- paging_mode_hap(v-domain)
- nestedhvm_is_n2(v) )
+if ( is_hvm_vcpu(v) paging_mode_hap(v-domain) nestedhvm_is_n2(v) )
{
unsigned long gfn;
struct p2m_domain *p2m;
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -971,7 +971,7 @@ int sh_unsync(struct vcpu *v, mfn_t gmfn
if ( pg-shadow_flags
((SHF_page_type_mask ~SHF_L1_ANY) | SHF_out_of_sync)
|| sh_page_has_multiple_shadows(pg)
- || is_pv_domain(v-domain)
+ || is_pv_vcpu(v)
|| !v-domain-arch.paging.shadow.oos_active )
return 0;
--- a/xen/arch/x86/mm/shadow/none.c
+++ b/xen/arch/x86/mm/shadow/none.c
@@ -73,6 +73,6 @@ static const struct paging_mode sh_pagin
void shadow_vcpu_init(struct vcpu *v)
{
-ASSERT(is_pv_domain(v-domain));
+ASSERT(is_pv_vcpu(v));
v-arch.paging.mode = sh_paging_none;
}
x86/mm: use is_..._vcpu() instead of open coding it
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1851,9 +1851,7 @@ unsigned long paging_gva_to_gfn(struct v
struct p2m_domain *hostp2m = p2m_get_hostp2m(v-domain);
const struct paging_mode *hostmode = paging_get_hostmode(v);
-if ( is_hvm_domain(v-domain)
- paging_mode_hap(v-domain)
- nestedhvm_is_n2(v) )
+if ( is_hvm_vcpu(v) paging_mode_hap(v-domain) nestedhvm_is_n2(v) )
{
unsigned long gfn;
struct p2m_domain *p2m;
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -971,7 +971,7 @@ int sh_unsync(struct vcpu *v, mfn_t gmfn
if ( pg-shadow_flags
((SHF_page_type_mask ~SHF_L1_ANY) | SHF_out_of_sync)
|| sh_page_has_multiple_shadows(pg)
- || is_pv_domain(v-domain)
+ || is_pv_vcpu(v)
|| !v-domain-arch.paging.shadow.oos_active )
return 0;
--- a/xen/arch/x86/mm/shadow/none.c
+++ b/xen/arch/x86/mm/shadow/none.c
@@ -73,6 +73,6 @@ static const struct paging_mode sh_pagin
void shadow_vcpu_init(struct vcpu *v)
{
-ASSERT(is_pv_domain(v-domain));
+ASSERT(is_pv_vcpu(v));
v-arch.paging.mode = sh_paging_none;
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [DESIGN] Feature Levelling improvements
* Leaf 0x0007[ECX=0].EAX * `mask_l7s0_ebx` Those 'l' look like '1' in the PDF. Can it be called something else? If you can suggest a better name, yes. As for now, these are the variable names used in-tree (top of xen/arch/x86/cpu/amd.c) low? * Leaf 0x0007[ECX=0].EBX At the time of writing, these are all the masking MSRs known by Xen. The bitmap shall be extended as new MSRs become available. New 'featureset' API for use by the toolstack - A featureset is a defined as a collection of words covering the cpuid leaves which report features to the caller. It is variable length, and expected to grow over time as processors gain more features, or Xen starts supporting exposing more features to guests. At the time of writing, the leaves containing feature bits are: * 0x0001.ECX * 0x0001.EDX * 0x8001.ECX * 0x8001.EDX * 0x000D[ECX=1].EAX * 0x0007[ECX=0].EBX * 0x0006.EAX * 0x0006.ECX * 0x000A.EAX * 0x000A.EBX * 0x000F[ECX=0].EDX * 0x000F[ECX=1].EDX XEN_SYSCTL_get_featureset - Xen shall on boot create a featureset for itself, and the maximum available features for each type of guest, based on hardware features, command line options etc. A toolstack shall be able to query all of these. maximum available features? Maximum set of features Xen is able to provide to particular guests on this specific host. As in two sets of features - one for PV and another for HVM. The PV being a subset of HVM (since it is more constrained)? Three really (including the host featureset), but yes. Command line options being the same old ones (the cpuid_mask..?) and then more? Or just rewrite this to be: cpuid=mask_therm_ecx=[blahbla],mask_xsave_eax=[blahbal] ? No. What I meant by that is that something like no-xsave will turn off whole swathes of features in all sets. The maximum set of features available to Xen, PV and HVM guests alike depends on the hardware, firmware settings and command line options provided to Xen enabling or disabling functionality. It is specifically not guaranteed to remain the same across reboot, which is why Xen shall recalculate it on each boot. Cpuid feature-verification library -- There shall be a new library (shared between Xen and libxc in the same way as libelf etc.) which can verify the a featureset. In particular, it will s/ a // confirm that no features are enabled without their dependent features. And presumarily can compare these features and do a and-subset (or an or-subset) ? At the end of the day, these are just bitmaps with a (unknown but fixed) integer length. XEN_DOMCTL_set_cpuid This is an existing hypercall. Currently it just stashes the policy from userspace. It shall be extended to provide verification of the policy, and reject attempts to advertise features which Xen is incapable of providing (via hardware or emulation support). Where would be the code to trim the 'maximum available features' in the subsets (like PV) with some cpuid=X flags from user-space? There is already code to do this in both libxl and libxc. There will of course be some changes as part of this work, but nothing major (I hope). The important point is that the hypercall shall now check Xen's ability to provide what the toolstack has requested, and say no if it can't. This will avoid the current situation which exists where the domain cpuid code in Xen is always needing to second-guess what is present in the domain policy, due to it usually being junk. VCPU context switch --- Xen shall be updated to lazily context switch all available masking MSRs. It is noted that this shall incur a performance overhead if restricted featuresets are assigned to PV guests, and _CPUID Faulting_ is not available. It shall be the responsibility of the host administrator to avoid creating such a scenario, if the performance overhead is a concern. .. and perhaps add warnings in the toolstack to tell the admin? How and where would this surface? xl/libxl is not designed to run the system as a whole. Not sure. We have some code for silly NUMA configuration that tells the user when they are picking the wrong option. Future work === The above is a minimum quantity of work to support feature levelling, but further problems exist. They are acknowledged as being issues, but are not in scope for fixing as part of feature levelling. * Xen has no notion of per-cpu and per-package data in the cpuid policy. In particular, this causes issues for VMs attempting to detect topology, which find inconsistent/incorrect cache information. * In the case that `domain_cpuid()`
[Xen-devel] [PATCH 2/3] x86: drop is_pv_32on64_domain()
... as being identical to is_pv_32bit_domain() after the x86-32
removal.
In a few cases this includes no longer open-coding is_pv_32bit_vcpu().
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -367,7 +367,7 @@ int switch_native(struct domain *d)
if ( !may_switch_mode(d) )
return -EACCES;
-if ( !is_pv_32on64_domain(d) )
+if ( !is_pv_32bit_domain(d) )
return 0;
d-arch.is_32bit_pv = d-arch.has_32bit_shinfo = 0;
@@ -392,7 +392,7 @@ int switch_compat(struct domain *d)
if ( !may_switch_mode(d) )
return -EACCES;
-if ( is_pv_32on64_domain(d) )
+if ( is_pv_32bit_domain(d) )
return 0;
d-arch.is_32bit_pv = d-arch.has_32bit_shinfo = 1;
@@ -481,7 +481,7 @@ int vcpu_initialise(struct vcpu *v)
v-arch.pv_vcpu.ctrlreg[4] = real_cr4_to_pv_guest_cr4(mmu_cr4_features);
-rc = is_pv_32on64_domain(d) ? setup_compat_l4(v) : 0;
+rc = is_pv_32bit_domain(d) ? setup_compat_l4(v) : 0;
done:
if ( rc )
{
@@ -689,7 +689,7 @@ unsigned long pv_guest_cr4_fixup(const s
hv_cr4_mask = ~X86_CR4_TSD;
if ( cpu_has_de )
hv_cr4_mask = ~X86_CR4_DE;
-if ( cpu_has_fsgsbase !is_pv_32bit_domain(v-domain) )
+if ( cpu_has_fsgsbase !is_pv_32bit_vcpu(v) )
hv_cr4_mask = ~X86_CR4_FSGSBASE;
if ( cpu_has_xsave )
hv_cr4_mask = ~X86_CR4_OSXSAVE;
@@ -721,7 +721,7 @@ int arch_set_info_guest(
/* The context is a compat-mode one if the target domain is compat-mode;
* we expect the tools to DTRT even in compat-mode callers. */
-compat = is_pv_32on64_domain(d);
+compat = is_pv_32bit_domain(d);
#define c(fld) (compat ? (c.cmp-fld) : (c.nat-fld))
flags = c(flags);
@@ -1195,7 +1195,7 @@ static void load_segments(struct vcpu *n
all_segs_okay = loadsegment(gs, uregs-gs);
}
-if ( !is_pv_32on64_domain(n-domain) )
+if ( !is_pv_32bit_vcpu(n) )
{
/* This can only be non-zero if selector is NULL. */
if ( n-arch.pv_vcpu.fs_base )
@@ -1224,7 +1224,7 @@ static void load_segments(struct vcpu *n
(unsigned long *)pv-kernel_sp;
unsigned long cs_and_mask, rflags;
-if ( is_pv_32on64_domain(n-domain) )
+if ( is_pv_32bit_vcpu(n) )
{
unsigned int *esp = ring_1(regs) ?
(unsigned int *)regs-rsp :
@@ -1340,7 +1340,7 @@ static void save_segments(struct vcpu *v
if ( regs-es )
dirty_segment_mask |= DIRTY_ES;
-if ( regs-fs || is_pv_32on64_domain(v-domain) )
+if ( regs-fs || is_pv_32bit_vcpu(v) )
{
dirty_segment_mask |= DIRTY_FS;
v-arch.pv_vcpu.fs_base = 0; /* != 0 selector kills fs_base */
@@ -1350,7 +1350,7 @@ static void save_segments(struct vcpu *v
dirty_segment_mask |= DIRTY_FS_BASE;
}
-if ( regs-gs || is_pv_32on64_domain(v-domain) )
+if ( regs-gs || is_pv_32bit_vcpu(v) )
{
dirty_segment_mask |= DIRTY_GS;
v-arch.pv_vcpu.gs_base_user = 0; /* != 0 selector kills gs_base_user
*/
@@ -1483,8 +1483,8 @@ static void __context_switch(void)
psr_ctxt_switch_to(nd);
-gdt = !is_pv_32on64_domain(nd) ? per_cpu(gdt_table, cpu) :
- per_cpu(compat_gdt_table, cpu);
+gdt = !is_pv_32bit_domain(nd) ? per_cpu(gdt_table, cpu) :
+per_cpu(compat_gdt_table, cpu);
if ( need_full_gdt(nd) )
{
unsigned long mfn = virt_to_mfn(gdt);
@@ -1568,7 +1568,7 @@ void context_switch(struct vcpu *prev, s
if ( is_pv_domain(nextd)
(is_idle_domain(prevd) ||
has_hvm_container_domain(prevd) ||
- is_pv_32on64_domain(prevd) != is_pv_32on64_domain(nextd)) )
+ is_pv_32bit_domain(prevd) != is_pv_32bit_domain(nextd)) )
{
uint64_t efer = read_efer();
if ( !(efer EFER_SCE) )
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -293,7 +293,7 @@ static unsigned long __init compute_dom0
avail -= (d-max_vcpus - 1UL)
get_order_from_bytes(sizeof(struct vcpu));
/* ...and compat_l4's, if needed. */
-if ( is_pv_32on64_domain(d) )
+if ( is_pv_32bit_domain(d) )
avail -= d-max_vcpus - 1;
/* Reserve memory for iommu_dom0_init() (rough estimate). */
@@ -608,7 +608,7 @@ static __init void dom0_update_physmap(s
BUG_ON(rc);
return;
}
-if ( !is_pv_32on64_domain(d) )
+if ( !is_pv_32bit_domain(d) )
((unsigned long *)vphysmap_s)[pfn] = mfn;
else
((unsigned int *)vphysmap_s)[pfn] = mfn;
@@ -718,7 +718,7 @@ static __init void mark_pv_pt_pages_rdon
/* Top-level p.t. is pinned. */
if ( (page-u.inuse.type_info PGT_type_mask) ==
- (!is_pv_32on64_domain(d) ?
+ (!is_pv_32bit_domain(d) ?
PGT_l4_page_table :
Re: [Xen-devel] [PATCH] minor shared/vcpu info adjustments
On 23/06/15 16:09, Jan Beulich wrote: - remove vcpu_info from xlat.lst (it isn't and can't be checked) - drop pointless (redundant) casts - make dummy_vcpu_info static Signed-off-by: Jan Beulich jbeul...@suse.com Reviewed-by: Andrew Cooper andrew.coop...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] Revert libxl: fix xl mem-set regression from 0c029c4da2
On Tue, Jun 23, 2015 at 03:45:14PM +0100, Jan Beulich wrote: On 23.06.15 at 16:16, wei.l...@citrix.com wrote: This reverts commit f5b43e95facdc17f925cb56a8963cd4531074034. Even if the patch having introduced the regression this fixed is being reverted, it's not clear to me why this change needs to be reverted too - it seems correct to me to use 64-bit types for the calculations. Or are you planning to do a more comprehensive adjustments to all of the types later on? I was thinking more about giving Ian (who is looking at making things consistent) a clean state to start with. He may end up touching those types. This patch itself looks correct to me. Ian, I think I will send a patch to revert the only offending commit and fix up conflicts. Are you OK with that. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.2-testing test] 58833: FAIL
flight 58833 xen-4.2-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/58833/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 3 host-install(3) broken in 58584 REGR. vs. 58411 Tests which are failing intermittently (not blocking): test-i386-i386-libvirt3 host-install(3) broken in 58584 pass in 58833 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 58584 pass in 58833 test-amd64-i386-qemuu-freebsd10-amd64 3 host-install(3) broken in 58584 pass in 58833 test-amd64-i386-pair 4 host-install/dst_host(4) broken in 58584 pass in 58833 test-amd64-i386-xl-win7-amd64 3 host-install(3) broken in 58584 pass in 58833 test-amd64-i386-xl-winxpsp3-vcpus1 3 host-install(3) broken in 58584 pass in 58833 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 58584 pass in 58833 test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-boot fail in 58584 pass in 58833 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail in 58824 pass in 58833 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-localmigrate.2 fail in 58824 pass in 58833 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 58824 pass in 58833 test-amd64-amd64-xl-win7-amd64 16 guest-stopfail pass in 58584 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail pass in 58824 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 58411 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 58411 test-amd64-i386-xl-win7-amd64 16 guest-stop fail like 58411 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1)blocked in 58584 n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-i386-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail in 58824 never pass test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass build-amd64-rumpuserxen 5 rumpuserxen-buildfail never pass build-i386-rumpuserxen5 rumpuserxen-buildfail never pass test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-i386-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 20 leak-check/check fail never pass test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass version targeted for testing: xen 97134c441d6d81ba0d7cdcfdc4d8315115b99dce baseline version: xen 21a8344ca38a2797a13b4bf57031b6f49ae12ccb People who touched revisions under test: Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Jan Beulich jbeul...@suse.com Stefano Stabellini stefano.stabell...@eu.citrix.com jobs: build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xlpass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-qemuu-freebsd10-amd64pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64
Re: [Xen-devel] [PATCH 2/3] x86: drop is_pv_32on64_domain()
On 23/06/15 16:19, Jan Beulich wrote: ... as being identical to is_pv_32bit_domain() after the x86-32 removal. In a few cases this includes no longer open-coding is_pv_32bit_vcpu(). Signed-off-by: Jan Beulich jbeul...@suse.com Reviewed-by: Andrew Cooper andrew.coop...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 6/6] AMD-PVH: enable pvh if requirements met
On 22.06.15 at 18:37, elena.ufimts...@oracle.com wrote: --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -1444,6 +1444,9 @@ const struct hvm_function_table * __init start_svm(void) svm_function_table.hap_capabilities = HVM_HAP_SUPERPAGE_2MB | ((cpuid_edx(0x8001) 0x0400) ? HVM_HAP_SUPERPAGE_1GB : 0); +if ( cpu_has_svm_npt cpu_has_svm_decode ) +svm_function_table.pvh_supported = 1; If svm_decode indeed is a prereq, then the earlier patch dealing with the handle_mmio() invocations doesn't need to fiddle with VMEXIT_INVLPG other than to maybe add a documenting ASSERT(). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] xen/block: add multi-page ring support
On 22/06/15 02:20, Bob Liu wrote: On 06/09/2015 10:07 PM, Roger Pau Monné wrote: El 09/06/15 a les 15.39, Konrad Rzeszutek Wilk ha escrit: ... Roger, I put them (patches) on devel/for-jens-4.2 on git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git I think these two patches: drivers: xen-blkback: delay pending_req allocation to connect_ring xen/block: add multi-page ring support are the only ones that haven't been Acked by you (or maybe they have and I missed the Ack?) Hello, I was waiting to Ack those because the XenServer storage performance folks found out that these patches cause a performance regression on some of their tests. I'm adding them to the conversation so they can provide more details about the issues they found, and whether we should hold pushing this patches or not. Hey, Are there any updates? What's the performance regression problem? Hi, We were using the 2 last weeks to finish measurements on the multipage ring v5 patches in a range of diverse conditions. The measurements were obtained under the following conditions: - using blkback as the dom0 backend with a back-ported multipage ring v5 applied to our dom0 kernel 3.10. - using a recent Ubuntu 15.04 kernel 3.19 with v5 frontend applied to be used as guest - using a micron RealSSD P320h as the underlying local storage on a Dell PowerEdge R720 with 2 Xeon E5-2643 v2 cpus. - fio 2.2.7-22-g36870 as the generator of synthetic loads in the guest. We used direct_io to skip caching in the guest and ran fio for 60s for a number of block sizes ranging from 512 bytes to 4MiB. We also tried pure random and pure sequential reads. Random reads were used to counter-act read-ahead prefetching at the underlying storage. We noticed that using large (16) queue depths in fio would saturate individual vcpus in the guest, so to better utilise the cpu resources in the guest, we chose to (a) fix the queue depth to 4 for each fio thread, (b) increase the guest vcpus to 16 and (c) vary the number of fio threads from 1 to 64. We were interested in observing storage iops and throughput for different values of in-flight requests (= io depth * fio threads) generated by the guest. Our expectation was that iops and throughput with single-page and multi-page rings would be the same up to 32 in-flight requests (the number of requests that fit in a single-page ring), and then the single-page ring case would flat-line with 32 in-flight requests, whereas the multi-page ring case would continue to show improvements until hitting some other bottleneck. The effect should be more visible when using requests with smaller block sizes because the measurements are less likely to be affected by memory copy delays or large data transfer delays to storage. These are the results we got for the conditions above with 4KiB blocks and random reads: fio_threads io_depth in_flight 1-page_IOPS 8-page_IOPS 14 4 19K 19K 4416 89K 89K 8432 149K 149K 16464 131K 198K 324 128 127K 208K 644 256 132K 209K We believe that this data shows that there's a clear improvement when using multi-page rings when there are more than 32 in-flight requests. We observed similar improvements when writing, and across all small block sizes. For block sizes =16KiB, the results were similar between single- and multi-page rings, and we attribute that to bottlenecks when transferring large amounts of data that is not present with smaller block sizes. Another reason for using random reads in the synthetic fio tests above is that we noticed that when sequential reads are used there were some anomalies that we believe would affect a fair comparison: (A)- in some situations with sequential read, we observed a decreasing number of merges in the guest (according to 'iostat -x -m 1') with small block sizes =4KiB when increasing the number of ring pages. There were no merges whenever in_flight ring_pages * 32. With larger in_flight requests (=128) -- visible with both 8 fio_threads x 32 io_depth and 32 fio_threads x 8 io_depth -- storage throughput with 1 page was around 25% better than with 8 pages. This is the regression that Roger was talking about previously in this discussion. It seems related to the merges of requests occurring much more frequently with 1 page than with 8 pages. During the measurements, the average request queue size in iostat has always a similar value as the number of requests in the ring. I would appreciate potential explanations of why the guest kernel would behave like that. We believe that this regression is a corner-case that would be difficult to spot in a real-world load, where random reads are interspersed with sequential reads of many different block sizes
Re: [Xen-devel] [PATCH v4 RFC 1/6] x86/PCI: add config space write abstract intercept logic
On 23.06.15 at 13:06, konrad.w...@oracle.com wrote: On June 23, 2015 3:21:17 AM EDT, Jan Beulich jbeul...@suse.com wrote: On 22.06.15 at 21:31, konrad.w...@oracle.com wrote: @@ -1804,8 +1804,12 @@ static bool_t pci_cfg_ok(struct domain * start |= CF8_ADDR_HI(currd-arch.pci_cf8); } -return !xsm_pci_config_permission(XSM_HOOK, currd, machine_bdf, - start, start + size - 1, write); +if ( xsm_pci_config_permission(XSM_HOOK, currd, machine_bdf, + start, start + size - 1, !!write) != 0 ) + return 0; + +return !write || + pci_conf_write_intercept(0, machine_bdf, start, size, write) = 0; Won't the 'write' parameter cause an compiler error as it expects an pointer? No, certainly not - !write means the same as write != NULL, but is (imo) easier to read. I meant the pci_conf_write_intercept(...,write). The prototype for the last parameter is for *uint32? But the write parameter is being changed to this very type in this patch. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 23/23] arm/xen: Add support for 64KB page granularity
On Tue, 23 Jun 2015, Julien Grall wrote: Hi, On 23/06/15 15:19, Stefano Stabellini wrote: diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index 224081c..dcfe251 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -93,8 +93,8 @@ static void xen_percpu_init(void) pr_info(Xen: initializing cpu%d\n, cpu); vcpup = per_cpu_ptr(xen_vcpu_info, cpu); - info.mfn = __pa(vcpup) PAGE_SHIFT; - info.offset = offset_in_page(vcpup); + info.mfn = __pa(vcpup) XEN_PAGE_SHIFT; + info.offset = xen_offset_in_page(vcpup); err = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_info, cpu, info); BUG_ON(err); @@ -204,7 +204,7 @@ static int __init xen_guest_init(void) xatp.domid = DOMID_SELF; xatp.idx = 0; xatp.space = XENMAPSPACE_shared_info; - xatp.gpfn = __pa(shared_info_page) PAGE_SHIFT; + xatp.gpfn = __pa(shared_info_page) XEN_PAGE_SHIFT; if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, xatp)) BUG(); What about xen_remap_domain_mfn_range? I guess we don't support that use case on 64K guests? If so, I would appreaciate an assert and/or an error message. The implementation of xen_remap_domain_mfn_range return -ENOSYS no matter the page granularity. This function is PV specific and has been added few months ago just for a stub. See comment in the code: /* Not used by XENFEAT_auto_translated guests */ Any logging/BUG_ON within this function is out of scope for this series. And I don't think this will be really useful. Feel free to send a patch for it. Yes, you are right, I was reading an older version of Linux that still had xen_remap_domain_mfn_range properly implemented. The new function is called xen_remap_domain_mfn_array which calls xen_xlate_remap_gfn_array. I'll rephrase my question then: What about xen_remap_domain_mfn_array? I guess we don't support that use case on 64K guests? If so, I would appreaciate an assert and/or an error message. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] tools: libxl: Take the userdata lock around maxmem changes
There is an issue in libxl_set_memory_target whereby the target and
the max mem can get out of sync, this is because the call the
xc_domain_setmaxmem is not tied in any way to the xenstore transaction
which controls updates to the xenstore side of things.
Consider a domain with 1M of RAM (==target and maxmem for the sake of
argument) and two simultaneous calls to libxl_set_memory_target, both
with relative=0 and enforce=1, one with target=3 and the other with
target=5.
target=5 call target=3 call
transaction start
transaction start
write target=5 to xenstore
write target=3 to xenstore
setmaxmem(5)
setmaxmem(3)
transaction commit = success
transaction commit = EAGAIN
At this point maxmem=3 while target=5.
In reality the target=3 case will the retry and eventually (hopefully)
succeed with target=maxmem=3, however the bad state will persist for
some window which is undesirable. On failure other than EAGAIN all
bets are off anyway, but in that case we will likely stick in the bad
state until someone else sets the memory).
To fix this we slightly abuse the userdata lock which is used to
protect updates to the domain's json configuration. Abused because
maxmem is not actually stored in there, but is kept by Xen. However
the lock protects some semantically similar things and is convenient
to use here too.
libxl_domain_setmaxmem also takes the lock, since it reads
memory/target from xenstore before calling xc_domain_setmaxmem there
is a small (but perhaps not very interesting) race there too.
There is on more use of xc_domain_setmaxmem in libxl__build_pre.
However taking a lock around this would be tricky since the xenstore
parts are not done until libxl__build_post. I think this one could be
argued to be OK since the domid is not public yet, that is it has
not been returned to the application yet (as the result of the create
operation). Toolstacks which go round fiddling with random domid's
which they find lying on the floor should be taught to do better.
Add a doc note that taking the userdata lock requires the CTX_LOCK to
be held.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
This applies on top of Wei's revert of libxl_set_memory_target:
retain the same maxmem offset on top of the current target
I couldn't quite rule out some race (for transaction=EAGAIN, for
!EAGAIN there are obvious ones) which resulted in the incorrect state
being in place after both entities exit, but couldn't construct an
actual case.
---
tools/libxl/libxl.c | 22 ++
tools/libxl/libxl_internal.h |1 +
2 files changed, 23 insertions(+)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index e3e63b5..0559e47 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4621,6 +4621,15 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t
domid, uint32_t max_memkb)
uint32_t memorykb;
char *dompath = libxl__xs_get_dompath(gc, domid);
int rc = 1;
+libxl__domain_userdata_lock *lock = NULL;
+
+CTX_LOCK;
+
+lock = libxl__lock_domain_userdata(gc, domid);
+if (!lock) {
+rc = ERROR_LOCK_FAIL;
+goto out;
+}
mem = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, %s/memory/target,
dompath));
if (!mem) {
@@ -4647,6 +4656,8 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t
domid, uint32_t max_memkb)
rc = 0;
out:
+if (lock) libxl__unlock_domain_userdata(lock);
+CTX_UNLOCK;
GC_FREE;
return rc;
}
@@ -4745,6 +4756,15 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t
domid,
libxl_dominfo ptr;
char *uuid;
xs_transaction_t t;
+libxl__domain_userdata_lock *lock;
+
+CTX_LOCK;
+
+lock = libxl__lock_domain_userdata(gc, domid);
+if (!lock) {
+rc = ERROR_LOCK_FAIL;
+goto out_no_transaction;
+}
retry_transaction:
t = xs_transaction_start(ctx-xsh);
@@ -4866,6 +4886,8 @@ out:
goto retry_transaction;
out_no_transaction:
+if (lock) libxl__unlock_domain_userdata(lock);
+CTX_UNLOCK;
GC_FREE;
return rc;
}
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e96d6b5..5594b54 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3600,6 +3600,7 @@ typedef struct {
libxl__carefd *carefd;
char *path; /* path of the lock file itself */
} libxl__domain_userdata_lock;
+/* The CTX_LOCK must be held around uses of this lock */
libxl__domain_userdata_lock *libxl__lock_domain_userdata(libxl__gc *gc,
uint32_t domid);
void libxl__unlock_domain_userdata(libxl__domain_userdata_lock *lock);
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 04/18] x86/hvm: make sure translated MMIO reads or writes fall within a page
On 23.06.15 at 12:39, paul.durr...@citrix.com wrote: ...otherwise they will simply carry on to the next page using a normal linear-to-phys translation. And what's wrong about this? --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -586,7 +586,6 @@ static int __hvmemul_read( p_data); if ( rc != X86EMUL_OKAY || bytes == chunk ) return rc; -addr += chunk; off += chunk; gpa += chunk; p_data += chunk; @@ -594,6 +593,8 @@ static int __hvmemul_read( if ( bytes chunk ) chunk = bytes; } + +return X86EMUL_UNHANDLEABLE; } All the loop above does is leverage that we don't need to do a translation, as we already know the physical address. Continuing if the access crosses a page boundary is not wrong at all afaict. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH v3 07/18] xen/arm: ITS: implement hw_irq_controller for LPIs
Hi Vijay,
On 22/06/15 13:01, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Implements hw_irq_controller api's required
to handle LPI's
This patch doesn't hw_irq_controller for LPI but just hack around the
current GICv3 host hw_irq_controller.
As said on the previous version, the goal of hw_irq_controller is too
keep things simple (i.e few conditional code). Please introduce a
separate hw_irq_controller for LPIs.
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/gic-v3-its.c | 39 +++
xen/arch/arm/gic-v3.c | 26 +++---
xen/arch/arm/irq.c| 16
xen/include/asm-arm/gic-its.h | 10 ++
xen/include/asm-arm/gic.h |4
xen/include/asm-arm/irq.h |4 +++-
6 files changed, 91 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 349d0bb..535fc53 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -508,6 +508,45 @@ static void its_send_invall(struct its_node *its, struct
its_collection *col)
its_send_single_command(its, its_build_invall_cmd, desc);
}
+void lpi_set_config(struct irq_desc *desc, int enable)
Any function exported should have their prototype defined within the
same patch...
+{
+struct its_collection *col;
+struct its_device *its_dev = get_irq_device(desc);
+u8 *cfg;
+u32 virq = irq_to_virq(desc);
+
+ASSERT(virq its_dev-nr_lpis);
+
+cfg = gic_rdists-prop_page + desc-irq - NR_GIC_LPI;
+if ( enable )
+*cfg |= LPI_PROP_ENABLED;
+else
+*cfg = ~LPI_PROP_ENABLED;
+
+/*
+ * Make the above write visible to the redistributors.
+ * And yes, we're flushing exactly: One. Single. Byte.
+ * Humpf...
+ */
+if ( gic_rdists-flags RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING )
+clean_and_invalidate_dcache_va_range(cfg, sizeof(*cfg));
+else
+dsb(ishst);
+
+/* Get collection id for this event id */
+col = its_dev-its-collections[virq % num_online_cpus()];
This is fragile, you are assuming that num_online_cpus() will never
change. Why don't you store the collection in every irq_desc?
+its_send_inv(its_dev, col, virq);
+}
+
+void its_set_affinity(struct irq_desc *desc, int cpu)
+{
+struct its_device *its_dev = get_irq_device(desc);
+struct its_collection *target_col;
+
+/* Physical collection id */
+target_col = its_dev-its-collections[cpu];
+its_send_movi(its_dev, target_col, irq_to_virq(desc));
The field virq in the structure irq_guest refers to the guest virtual
IRQ and not the event ID. As Ian suggested in the proposal [1], please
use an union to make this code clears.
Furthermore, when you set the LPI configuration (see lpi_set_config) you
are using a round robin to get the collection. This won't work anymore
if Xen decides to change the affinity... So you may want to drop
affinity support for now.
+}
Missing newline.
[..]
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 2dd43ee..9dbdf7d 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -36,6 +36,7 @@ struct irq_guest
{
struct domain *d;
unsigned int virq;
+struct its_device *dev;
I know that this was suggested in the proposal [1]. But the goal of
irq_guest is to store anything specific to the guest. The event ID and
the its_device assigned are known when the device is added to Xen and
hence can be set in irq_desc (with a small memory impact, but we have
plenty of memory on ARM64).
This would avoid you to set dev and virq every time the device is
passthrough to a guest.
};
static void ack_none(struct irq_desc *irq)
@@ -143,6 +144,21 @@ static inline struct domain *irq_get_domain(struct
irq_desc *desc)
return irq_get_guest_info(desc)-d;
}
+unsigned int irq_to_virq(struct irq_desc *desc)
+{
+return irq_get_guest_info(desc)-virq;
+}
+
+struct its_device *get_irq_device(struct irq_desc *desc)
+{
+return irq_get_guest_info(desc)-dev;
+}
+
+void set_irq_device(struct irq_desc *desc, struct its_device *dev)
+{
+irq_get_guest_info(desc)-dev = dev;
+}
The goal of route_irq_guest is to setup correctly irq_guest. If the
current version doesn't fit your usage please update it or add a new
helper and no workaround the code.
+
void irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_mask)
{
if ( desc != NULL )
diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
index 59a6490..a47cf26 100644
--- a/xen/include/asm-arm/gic-its.h
+++ b/xen/include/asm-arm/gic-its.h
@@ -205,6 +205,16 @@ static inline uint8_t its_decode_cmd(its_cmd_block *cmd)
return cmd-raw_cmd[0] 0xff;
}
+static inline uint32_t its_decode_devid(struct domain *d, its_cmd_block *cmd)
+{
+/* TODO:
Re: [Xen-devel] [RFC 23/23] arm/xen: Add support for 64KB page granularity
Hi, On 23/06/15 15:19, Stefano Stabellini wrote: diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index 224081c..dcfe251 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -93,8 +93,8 @@ static void xen_percpu_init(void) pr_info(Xen: initializing cpu%d\n, cpu); vcpup = per_cpu_ptr(xen_vcpu_info, cpu); -info.mfn = __pa(vcpup) PAGE_SHIFT; -info.offset = offset_in_page(vcpup); +info.mfn = __pa(vcpup) XEN_PAGE_SHIFT; +info.offset = xen_offset_in_page(vcpup); err = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_info, cpu, info); BUG_ON(err); @@ -204,7 +204,7 @@ static int __init xen_guest_init(void) xatp.domid = DOMID_SELF; xatp.idx = 0; xatp.space = XENMAPSPACE_shared_info; -xatp.gpfn = __pa(shared_info_page) PAGE_SHIFT; +xatp.gpfn = __pa(shared_info_page) XEN_PAGE_SHIFT; if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, xatp)) BUG(); What about xen_remap_domain_mfn_range? I guess we don't support that use case on 64K guests? If so, I would appreaciate an assert and/or an error message. The implementation of xen_remap_domain_mfn_range return -ENOSYS no matter the page granularity. This function is PV specific and has been added few months ago just for a stub. See comment in the code: /* Not used by XENFEAT_auto_translated guests */ Any logging/BUG_ON within this function is out of scope for this series. And I don't think this will be really useful. Feel free to send a patch for it. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] minor shared/vcpu info adjustments
- remove vcpu_info from xlat.lst (it isn't and can't be checked)
- drop pointless (redundant) casts
- make dummy_vcpu_info static
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -70,7 +70,7 @@ integer_param(hardware_dom, hardware_d
struct vcpu *idle_vcpu[NR_CPUS] __read_mostly;
-vcpu_info_t dummy_vcpu_info;
+static vcpu_info_t dummy_vcpu_info;
static void __domain_finalise_shutdown(struct domain *d)
{
--- a/xen/include/xen/shared.h
+++ b/xen/include/xen/shared.h
@@ -18,7 +18,7 @@ typedef union {
#define __shared_info(d, s, field) \
(*(!has_32bit_shinfo(d) ? \
(typeof((s)-compat.field))(s)-native.field : \
- (typeof((s)-compat.field))(s)-compat.field))
+ (s)-compat.field))
typedef union {
struct vcpu_info native;
@@ -29,7 +29,7 @@ typedef union {
#define __vcpu_info(v, i, field)\
(*(!has_32bit_shinfo((v)-domain) ? \
(typeof((i)-compat.field))(i)-native.field : \
- (typeof((i)-compat.field))(i)-compat.field))
+ (i)-compat.field))
#else
@@ -41,8 +41,6 @@ typedef struct vcpu_info vcpu_info_t;
#endif
-extern vcpu_info_t dummy_vcpu_info;
-
#define shared_info(d, field) __shared_info(d, (d)-shared_info, field)
#define vcpu_info(v, field)__vcpu_info(v, (v)-vcpu_info, field)
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -6,7 +6,6 @@
? mmu_update xen.h
! mmuext_op xen.h
! start_info xen.h
-? vcpu_info xen.h
? vcpu_time_info xen.h
! cpu_user_regs arch-x86/xen-@arch@.h
! trap_info arch-x86/xen.h
minor shared/vcpu info adjustments
- remove vcpu_info from xlat.lst (it isn't and can't be checked)
- drop pointless (redundant) casts
- make dummy_vcpu_info static
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -70,7 +70,7 @@ integer_param(hardware_dom, hardware_d
struct vcpu *idle_vcpu[NR_CPUS] __read_mostly;
-vcpu_info_t dummy_vcpu_info;
+static vcpu_info_t dummy_vcpu_info;
static void __domain_finalise_shutdown(struct domain *d)
{
--- a/xen/include/xen/shared.h
+++ b/xen/include/xen/shared.h
@@ -18,7 +18,7 @@ typedef union {
#define __shared_info(d, s, field) \
(*(!has_32bit_shinfo(d) ? \
(typeof((s)-compat.field))(s)-native.field : \
- (typeof((s)-compat.field))(s)-compat.field))
+ (s)-compat.field))
typedef union {
struct vcpu_info native;
@@ -29,7 +29,7 @@ typedef union {
#define __vcpu_info(v, i, field)\
(*(!has_32bit_shinfo((v)-domain) ? \
(typeof((i)-compat.field))(i)-native.field : \
- (typeof((i)-compat.field))(i)-compat.field))
+ (i)-compat.field))
#else
@@ -41,8 +41,6 @@ typedef struct vcpu_info vcpu_info_t;
#endif
-extern vcpu_info_t dummy_vcpu_info;
-
#define shared_info(d, field) __shared_info(d, (d)-shared_info, field)
#define vcpu_info(v, field)__vcpu_info(v, (v)-vcpu_info, field)
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -6,7 +6,6 @@
? mmu_update xen.h
! mmuext_op xen.h
! start_info xen.h
-? vcpu_info xen.h
? vcpu_time_info xen.h
! cpu_user_regs arch-x86/xen-@arch@.h
! trap_info arch-x86/xen.h
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] Revert libxl: fix xl mem-set regression from 0c029c4da2
On 23.06.15 at 16:16, wei.l...@citrix.com wrote:
This reverts commit f5b43e95facdc17f925cb56a8963cd4531074034.
Even if the patch having introduced the regression this fixed is
being reverted, it's not clear to me why this change needs to be
reverted too - it seems correct to me to use 64-bit types for the
calculations. Or are you planning to do a more comprehensive
adjustments to all of the types later on?
Jan
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1285,7 +1285,7 @@ int xc_getcpuinfo(xc_interface *xch, int max_cpus,
int xc_domain_setmaxmem(xc_interface *xch,
uint32_t domid,
-uint64_t max_memkb);
+unsigned int max_memkb);
int xc_domain_set_memmap_limit(xc_interface *xch,
uint32_t domid,
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index ce51e69..5b1a52d 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -635,7 +635,7 @@ int xc_shadow_control(xc_interface *xch,
int xc_domain_setmaxmem(xc_interface *xch,
uint32_t domid,
-uint64_t max_memkb)
+unsigned int max_memkb)
{
DECLARE_DOMCTL;
domctl.cmd = XEN_DOMCTL_max_mem;
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index d86ea62..35caf42 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4736,8 +4736,7 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t
domid,
{
GC_INIT(ctx);
int rc = 1, abort_transaction = 0;
-uint64_t memorykb;
-uint32_t videoram = 0;
+uint32_t memorykb = 0, videoram = 0;
uint32_t current_target_memkb = 0, new_target_memkb = 0;
uint32_t current_max_memkb = 0;
char *memmax, *endptr, *videoram_s = NULL, *target = NULL;
@@ -4831,7 +4830,7 @@ retry_transaction:
rc = xc_domain_setmaxmem(ctx-xch, domid, memorykb);
if (rc != 0) {
LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-xc_domain_setmaxmem domid=%u memkb=%PRIu64 failed
+xc_domain_setmaxmem domid=%d memkb=%d failed
rc=%d\n, domid, memorykb, rc);
abort_transaction = 1;
goto out;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 23/23] arm/xen: Add support for 64KB page granularity
On 23/06/15 15:49, Stefano Stabellini wrote: Yes, you are right, I was reading an older version of Linux that still had xen_remap_domain_mfn_range properly implemented. The new function is called xen_remap_domain_mfn_array which calls xen_xlate_remap_gfn_array. I'll rephrase my question then: What about xen_remap_domain_mfn_array? I guess we don't support that use case on 64K guests? If so, I would appreaciate an assert and/or an error message. See https://lkml.org/lkml/2015/5/14/563 -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] x86: drop is_pv_32on64_vcpu()
On 23/06/15 16:18, Jan Beulich wrote: ... as being identical to is_pv_32bit_vcpu() after the x86-32 removal. In a few cases this includes an additional is_pv_32bit_vcpu() - is_pv_32bit_domain() conversion. Signed-off-by: Jan Beulich jbeul...@suse.com Reviewed-by: Andrew Cooper andrew.coop...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-4.2-testing test] 58817: FAIL [and 2 more messages]
Jan Beulich writes (Re: [Xen-devel] [xen-4.2-testing test] 58817: FAIL): On 22.06.15 at 08:54, osst...@xenbits.xen.org wrote: flight 58817 xen-4.2-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/58817/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 3 host-install(3) broken in 58584 REGR. vs. 58411 This has been repeating for like half a dozen (or even more) flights. Why is this state not getting cleared, considering that all these newer flights were successful, and there were no other blocking failures? The way to interpret this is to look for something which _passed_ in the flight regarded as a problem. In this case: osstest service user writes ([xen-4.2-testing test] 58817: FAIL): flight 58817 xen-4.2-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/58817/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 3 host-install(3) broken in 58584 REGR. vs. 58411 Tests which are failing intermittently (not blocking): ... test-amd64-amd64-xl-win7-amd64 16 guest-stop fail pass in 58584 So: the heisenbug compensator needed to justify the failure of test-amd64-amd64-xl-win7-amd64 step guest-stop, and found a pass in 58584. But 58584 is broken in other ways, and brokennesses aren't regarded as justifiable (because they can cause other tests not to run). I think it would be better if the heisenbug compensator did not consider flights with broken jobs. But that's a reporting problem, not a wrong push gate answer problem. And with that - will it ever clear? Not unless we get lucky and that guest-stop passes. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
On Tue, 2015-06-23 at 11:55 +0100, Stefano Stabellini wrote: I don't know if we should introduce a new name for this, but I wanted to point out that this is different from PVH from Xen point of view. In particular most of the outstanding PVH work items (32bit, AMD) on the hypervisor would be redudant if we get this to work, right? If that is the case, then I think it is best we agree on which road we want to take going forward as soon as possible to avoid duplicated or wasted efforts. I think what you are saying is we either want to pursue this path _or_ PVH, but not both, and I would be inclined to agree, it seems to me like duplication of both effort and functionality to do both. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt test] 58119: regressions - FAIL
On Tue, 2015-06-23 at 12:15 +0100, Anthony PERARD wrote: On Mon, Jun 08, 2015 at 10:22:28AM +0100, Ian Campbell wrote: 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. 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 Hi, I've tried to debug this device model: startup time out issue that I'm seeing on OpenStack. What I've done is strace every single QEMU. It appear that QEMU take more than 10s to load... FWIW I've started running some adhoc osstest jobs on the Cambridge instance too, first time everything passed. The second attempt I forced onto the *-frog machines which are AMD Opteron(tm) Processor 6168 processors which is as close as I can get to the AMD Opteron(tm) Processor 6376 ones in merlot* and they also passed. That's not enough data to really be going on though. Do you happen to know what h/w the openstack tests run on? It is using nested virt, is that right? Given that merlot* seems to have some sort of barking NUMA configuration SNAFU I wouldn't necessarily rule out it's just really slow. 10s does seem _very_ slow though, on an essentially idle system, no matter how bad it's NUMA-ness is setup... Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc
On 6/22/2015 10:02 PM, Julien Grall wrote:
On 22/06/15 12:17, Peng Fan wrote:
I add debug log in this piece of code:
void __init sanity_check_meminfo(void)
{
phys_addr_t memblock_limit = 0;
int i, j, highmem = 0;
phys_addr_t vmalloc_limit = __pa(vmalloc_min - 1) + 1;
printk(vmalloc_min virt %x phys %x\n, vmalloc_min - 1,
__pa(vmalloc_min - 1));
printk(vmalloc_limit %x\n, vmalloc_limit);
If use 512M for Dom0, I found vmalloc_limit is 0xf80, vmalloc_min is
0xef80, This comes to a question, why __pa(vmalloc_min - 1) + will
make vmalloc_limit only 0xf80 which is less than 128M. the pv stub
does some runtime fixup for virt_to_phys here.
Since vmalloc_limit is small, then all other memory bank in my platform
is recoginied as highmem, then arm_lowmem_limit is 0, then kernel panic:
dma_contiguous_reserve_area(size 180, base , limit )
CMA: failed to reserve 32 MiB
Memory policy: Data cache writealloc
Kernel panic - not syncing: ERROR: Failed to allocate 0x2000 bytes below
0x0.
0x - 0xef800 is about 264M. So I choose 256M as the Dom0
memory size. I do not have clear idea about this, current I am trying to
use xl to boot DomU, so just use 256M for Dom0 here.
There use to be some issue with the way how the offset between physical
and virtual address was computed.
Do you use LPAE or short page table? Can you provide the xen log when
DOM0 is using 512MB?
I did not enable LPAE for DOM0 kernel, use shor page table.
Following is the full log from uboot to kernel with DOM0 512M:
U-Boot 2015.04-rc4-00145-gf12a16e-dirty (Jun 19 2015 - 15:26:52)
CPU: Freescale i.MX7D rev1.0 at 792 MHz
CPU: Thermal invalid data, fuse: 0x1b800
CPU: Temperature: Can't find sensor device
Reset cause: POR
Board: MX7D 12x12 LPDDR3 ARM2
I2C: ready
DRAM: 2 GiB
PMIC: PFUZE300 DEV_ID=0x30 REV_ID=0x10
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Display: MCIMX28LCD (800x480)
Video: 800x480x24
In:serial
Out: serial
Err: serial
switch to partitions #0, OK
mmc0 is current device
Net: FEC0
Error: FEC0 address not set.
Normal Boot
Hit any key to stop autoboot: 0
= setenv xen_addr_r 0x8000
= setenv bootargs console=dtuart
dtuart=/soc/aips-bus@3080/serial@3086 dom0_mem=256M
= fatload mmc 0:1 0x8000 xen.image
reading xen.image
754544 bytes read in 129 ms (5.6 MiB/s)
= setenv bootargs console=dtuart
dtuart=/soc/aips-bus@3080/serial@3086 dom0_mem=512M
= run loadfdt
reading imx7d-12x12-lpddr3-arm2.dtb
40966 bytes read in 26 ms (1.5 MiB/s)
= fatload mmc 0:1 0x8400 zImage
reading zImage
6250016 bytes read in 286 ms (20.8 MiB/s)
= setenv kernel_addr_r 0x8400
= setenv fdt_high 0x
= setenv fdt_addr 0x8300
= fdt addr ${fdt_addr} 0x4
= fdt resize
= fdt chosen
= fdt set /chosen \#address-cells 1
= fdt set /chosen \#size-cells 1
= fdt set /chosen/module@0 compatible xen,linux-zimage
xen,multiboot-module
= fdt set /chosen/module@0 reg ${kernel_addr_r} 0x${filesize}
= fdt set /chosen/module@0 bootargs console=hvc0 ro
root=/dev/mmcblk0p2 clk_ignore_unused uart_from_osc loglevel=8 earlyprintk
= bootz ${xen_addr_r} - ${fdt_addr}
Kernel image @ 0x8000 [ 0x00 - 0x101700 ]
## Flattened Device Tree blob at 8300
Booting using the fdt blob at 0x8300
reserving fdt memory region: addr=8300 size=b000
Using Device Tree in place at 8300, end 8300dfff
Starting kernel ...
- UART enabled -
- CPU booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 8000 -
(XEN)
(XEN) MODULE[0]: 8300 - 8300b000 Device Tree
(XEN) MODULE[1]: 8400 - 845f5e20 Kernel
console=hvc0 ro root=/dev/mmcblk0p2 clk_ignore_unused uart_from_osc
loglevel=8 earlyprintk
(XEN) RESVD[0]: 8300 - 8300b000
(XEN)
(XEN) Command line: console=dtuart
dtuart=/soc/aips-bus@3080/serial@3086 dom0_mem=512M
(XEN) Placing Xen at 0xffe0-0x0001
(XEN) Update BOOTMOD_XEN from 8000-80101701 =
ffe0-fff01701
(XEN) Xen heap: fa00-fe00 (16384 pages)
(XEN) Dom heap: 507904 pages
(XEN) Domain heap initialised
(XEN) Platform: i.MX 7Dual
(XEN) Looking for dtuart at /soc/aips-bus@3080/serial@3086,
options
(XEN) imx-uart.c:226: xx 3086
(XEN) imx-uart.c:98: ===UFCR USR1 a01 2050
Xen 4.6-unstable
(XEN) Xen version 4.6-unstable (Freenix@(none))
(arm-poky-linux-gnueabi-gcc (GCC) 4.8.2) debug=y Fri Jun 19 18:30:50 CST
2015
(XEN) Latest ChangeSet: Mon Jun 15 18:25:34 2015 +0800 git:c01e139-dirty
(XEN) Processor: 410fc075: ARM Limited, variant: 0x0, part 0xc07, rev 0x5
(XEN) 32-bit Execution:
(XEN) Processor Features: 1131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
Re: [Xen-devel] [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
On Tue, 23 Jun 2015, Ian Campbell wrote: On Tue, 2015-06-23 at 11:55 +0100, Stefano Stabellini wrote: I don't know if we should introduce a new name for this, but I wanted to point out that this is different from PVH from Xen point of view. In particular most of the outstanding PVH work items (32bit, AMD) on the hypervisor would be redudant if we get this to work, right? If that is the case, then I think it is best we agree on which road we want to take going forward as soon as possible to avoid duplicated or wasted efforts. I think what you are saying is we either want to pursue this path _or_ PVH, but not both, and I would be inclined to agree, it seems to me like duplication of both effort and functionality to do both. Right, especially given that they both seem to provide similar functionalities. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Tools backports for 4.5 [and 1 more messages]
Ian Jackson writes (Re: [Xen-devel] Tools backports for 4.5 [and 1 more messages]): Jan Beulich writes (Re: [Xen-devel] Tools backports for 4.5): 3380f5b6270e ocaml/xenctrl: Check return values from hypercalls c8945d516134 ocaml/xenctrl: Make failwith_xc() thread safe 1a010ca99e9b ocaml/xenctrl: Fix stub_xc_readconsolering() 96e0ee8386cf tools/hotplug: systemd: Don't ever kill xenstored 588df84c0d70 tools/xenconsoled: Increase file descriptor limit ... The above backports (771f857e..9d5b2b01) need to go to 4.4 and earlier as applicable. I will look at that soon (probably tomorrow). These: libxl: Domain destroy: unlock userdata earlier libxl: Domain destroy: fork tools/hotplug: systemd: Don't ever kill xenstored libxl: In libxl_set_vcpuonline check for maximum number of VCPUs against the cpumap Did not apply cleanly to 4.4. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc
Hi, On 23/06/15 14:03, Peng Fan wrote: I did not enable LPAE for DOM0 kernel, use shor page table. Following is the full log from uboot to kernel with DOM0 512M: Which CONFIG_VMSPLIT_* do you use? Can you try to use another one? I remembered it had some effect on the offset between physical and virtual address. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc
Hi, On 6/23/2015 9:36 PM, Julien Grall wrote: Hi, On 23/06/15 14:03, Peng Fan wrote: I did not enable LPAE for DOM0 kernel, use shor page table. Following is the full log from uboot to kernel with DOM0 512M: Which CONFIG_VMSPLIT_* do you use? Can you try to use another one? I remembered it had some effect on the offset between physical and virtual address. CONFIG_VMSPLIT_2G=y CONFIG_PAGE_OFFSET=0x8000 ok. Will try 3G:1G split. Regards, Thanks, Peng. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] [XEN-4.4] tools/libxc: Fix build of 32bit toolstacks on CentOS 5.x following XSA-125
Ian Jackson writes (Re: [Xen-devel] [PATCH] [XEN-4.4] tools/libxc: Fix build of 32bit toolstacks on CentOS 5.x following XSA-125): Andrew Cooper writes ([Xen-devel] [PATCH] [XEN-4.4] tools/libxc: Fix build of 32bit toolstacks on CentOS 5.x following XSA-125): gcc 4.1 of CentOS 5.x era does not like the typecheck in min() between uint64_t and unsigned long. Signed-off-by: Andrew Cooper andrew.coop...@citrix.com CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@eu.citrix.com CC: Wei Liu wei.l...@citrix.com --- This needs backporting to 4.2 This doesn't seem to apply to my staging-4.5. Sorry, I meant, to my staging-4.4. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/5] New maintainer for x86/mm
On 06/23/2015 02:22 PM, Tim Deegan wrote: George has a long record of contributions to the x86 memory management and p2m code. He will be taking over as the primary maintainer of x86/mm; I will still help out with the shadow pagetable code. Signed-off-by: Tim Deegan t...@xen.org Cc: George Dunlap george.dun...@eu.citrix.com Acked-by: George Dunlap george.dun...@eu.citrix.com --- MAINTAINERS | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 319df75..b0f43d1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -362,7 +362,7 @@ F:tools/firmware/hvmloader/ F: tools/tests/x86_emulator/ X86 MEMORY MANAGEMENT -M: Tim Deegan t...@xen.org +M: George Dunlap george.dun...@eu.citrix.com S: Supported F: xen/arch/x86/mm/ @@ -374,6 +374,11 @@ F: xen/arch/x86/mm/mem_sharing.c F: xen/arch/x86/mm/mem_paging.c F: tools/memshr +X86 SHADOW PAGETABLES +M: Tim Deegan t...@xen.org +S: Maintained +F: xen/arch/x86/mm/shadow/ + VM EVENT AND MEM ACCESS M: Razvan Cojocaru rcojoc...@bitdefender.com M: Tamas K Lengyel tleng...@novetta.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] [XEN-4.4] tools/libxc: Fix build of 32bit toolstacks on CentOS 5.x following XSA-125
On 23/06/15 15:16, Ian Jackson wrote: Ian Jackson writes (Re: [Xen-devel] [PATCH] [XEN-4.4] tools/libxc: Fix build of 32bit toolstacks on CentOS 5.x following XSA-125): Andrew Cooper writes (Re: [Xen-devel] [PATCH] [XEN-4.4] tools/libxc: Fix build of 32bit toolstacks on CentOS 5.x following XSA-125): On 23/06/15 14:21, Ian Jackson wrote: Sorry, I meant, to my staging-4.4. You appear to have committed half of it as staging-4.4~2 Nnnngg. Sorry. I think I am trying to do too many different things at once. Now fixed. Ian. Thanks. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] Revert libxl: fix xl mem-set regression from 0c029c4da2
On Tue, Jun 23, 2015 at 03:16:23PM +0100, Wei Liu wrote:
This reverts commit f5b43e95facdc17f925cb56a8963cd4531074034.
Could you include some detail of why the revert is needed?
Thanks.
Signed-off-by: Wei Liu wei.l...@citrix.com
---
tools/libxc/include/xenctrl.h | 2 +-
tools/libxc/xc_domain.c | 2 +-
tools/libxl/libxl.c | 5 ++---
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index d1d2ab3..db5d028 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1285,7 +1285,7 @@ int xc_getcpuinfo(xc_interface *xch, int max_cpus,
int xc_domain_setmaxmem(xc_interface *xch,
uint32_t domid,
-uint64_t max_memkb);
+unsigned int max_memkb);
int xc_domain_set_memmap_limit(xc_interface *xch,
uint32_t domid,
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index ce51e69..5b1a52d 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -635,7 +635,7 @@ int xc_shadow_control(xc_interface *xch,
int xc_domain_setmaxmem(xc_interface *xch,
uint32_t domid,
-uint64_t max_memkb)
+unsigned int max_memkb)
{
DECLARE_DOMCTL;
domctl.cmd = XEN_DOMCTL_max_mem;
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index d86ea62..35caf42 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4736,8 +4736,7 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t
domid,
{
GC_INIT(ctx);
int rc = 1, abort_transaction = 0;
-uint64_t memorykb;
-uint32_t videoram = 0;
+uint32_t memorykb = 0, videoram = 0;
uint32_t current_target_memkb = 0, new_target_memkb = 0;
uint32_t current_max_memkb = 0;
char *memmax, *endptr, *videoram_s = NULL, *target = NULL;
@@ -4831,7 +4830,7 @@ retry_transaction:
rc = xc_domain_setmaxmem(ctx-xch, domid, memorykb);
if (rc != 0) {
LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-xc_domain_setmaxmem domid=%u memkb=%PRIu64 failed
+xc_domain_setmaxmem domid=%d memkb=%d failed
rc=%d\n, domid, memorykb, rc);
abort_transaction = 1;
goto out;
--
1.9.1
___
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
[Xen-devel] [PATCH 3/5] Change kdd to 'Odd Fixes'.
kdd's knowledge of Windows kernel internals is several releases out of date now. However the underlying implementation of the serial protocol is still sound. I have heard that some people are using it, and I'm happy to answer questions/bug reports, so don't deprecate it just yet. Signed-off-by: Tim Deegan t...@xen.org --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index b0f43d1..7f0e96e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -182,7 +182,7 @@ F: tools/debugger/gdbsx/ KDD DEBUGGER M: Tim Deegan t...@xen.org -S: Supported +S: Odd Fixes F: tools/debugger/kdd/ INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT) -- 2.3.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/5] New maintainers for VM events and memory access.
Razvan and Tamas have been working on this code for a while now, and have kindly agreed to act as maintainers. Signed-off-by: Tim Deegan t...@xen.org Cc: Razvan Cojocaru rcojoc...@bitdefender.com Cc: Tamas K Lengyel tleng...@novetta.com --- MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 0372ef7..319df75 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -375,7 +375,8 @@ F: xen/arch/x86/mm/mem_paging.c F: tools/memshr VM EVENT AND MEM ACCESS -M: Tim Deegan t...@xen.org +M: Razvan Cojocaru rcojoc...@bitdefender.com +M: Tamas K Lengyel tleng...@novetta.com S: Supported F: xen/common/vm_event.c F: xen/common/mem_access.c -- 2.3.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 5/5] Remove me from ARM/DT maintainers list.
In practice I haven't been actively involved in this code for some time. Signed-off-by: Tim Deegan t...@xen.org Cc: Ian Campbell ian.campb...@citrix.com Cc: Stefano Stabellini stefano.stabell...@citrix.com --- MAINTAINERS | 2 -- 1 file changed, 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index d1bec17..6b1068e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -127,7 +127,6 @@ F: tools/libxc/xc_arinc653.c ARM (W/ VIRTUALISATION EXTENSIONS) ARCHITECTURE M: Ian Campbell ian.campb...@citrix.com M: Stefano Stabellini stefano.stabell...@citrix.com -M: Tim Deegan t...@xen.org S: Supported L: xen-devel@lists.xen.org F: xen/arch/arm/ @@ -151,7 +150,6 @@ F: xen/common/cpupool.c DEVICE TREE M: Ian Campbell ian.campb...@citrix.com M: Stefano Stabellini stefano.stabell...@citrix.com -M: Tim Deegan t...@xen.org S: Supported F: xen/common/libfdt/ F: xen/common/device_tree.c -- 2.3.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/5] New maintainer for x86/mm
George has a long record of contributions to the x86 memory management and p2m code. He will be taking over as the primary maintainer of x86/mm; I will still help out with the shadow pagetable code. Signed-off-by: Tim Deegan t...@xen.org Cc: George Dunlap george.dun...@eu.citrix.com --- MAINTAINERS | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 319df75..b0f43d1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -362,7 +362,7 @@ F: tools/firmware/hvmloader/ F: tools/tests/x86_emulator/ X86 MEMORY MANAGEMENT -M: Tim Deegan t...@xen.org +M: George Dunlap george.dun...@eu.citrix.com S: Supported F: xen/arch/x86/mm/ @@ -374,6 +374,11 @@ F: xen/arch/x86/mm/mem_sharing.c F: xen/arch/x86/mm/mem_paging.c F: tools/memshr +X86 SHADOW PAGETABLES +M: Tim Deegan t...@xen.org +S: Maintained +F: xen/arch/x86/mm/shadow/ + VM EVENT AND MEM ACCESS M: Razvan Cojocaru rcojoc...@bitdefender.com M: Tamas K Lengyel tleng...@novetta.com -- 2.3.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 5/9] x86/pvh: Set PVH guest's mode in XEN_DOMCTL_set_address_size
On 20.06.15 at 05:09, boris.ostrov...@oracle.com wrote:
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -141,6 +141,13 @@ static struct vcpu *__init setup_dom0_vcpu(struct domain
*d,
if ( !d-is_pinned !dom0_affinity_relaxed )
cpumask_copy(v-cpu_hard_affinity, dom0_cpus);
cpumask_copy(v-cpu_soft_affinity, dom0_cpus);
+
+if ( is_pvh_vcpu(v) )
+if ( hvm_set_mode(v, is_pv_32bit_domain(d) ? 4 : 8) )
This should be just one if().
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2320,12 +2320,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
v-arch.hvm_vcpu.inject_trap.vector = -1;
if ( is_pvh_domain(d) )
-{
-v-arch.hvm_vcpu.hcall_64bit = 1;/* PVH 32bitfixme. */
-/* This is for hvm_long_mode_enabled(v). */
-v-arch.hvm_vcpu.guest_efer = EFER_LMA | EFER_LME;
return 0;
-}
With this removed, is there any guarantee that hvm_set_mode()
will be called for each vCPU?
Anyway, while I'll apply the previous patch as a cleanup one, I'll
defer this and later ones until a decision between pursuing PVH
vs going the HVMlite route was made.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 4/5] Change x86 paging/sharing to 'Orphaned'.
This code now has no active maintainers, as neither Andres nor I can commit the time. Signed-off-by: Tim Deegan t...@xen.org Cc: Andres Lagar-Cavilla and...@lagarcavilla.org --- MAINTAINERS | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 7f0e96e..d1bec17 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -367,9 +367,7 @@ S: Supported F: xen/arch/x86/mm/ X86 MEMORY SHARING AND PAGING -M: Andres Lagar-Cavilla and...@lagarcavilla.org -M: Tim Deegan t...@xen.org -S: Supported +S: Orphaned F: xen/arch/x86/mm/mem_sharing.c F: xen/arch/x86/mm/mem_paging.c F: tools/memshr -- 2.3.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/5] MAINTAINERS updates
Hi, As I'll be stepping down from paid work on Xen soon, this is a good time to introduce some new maintainers: George will be taking over x86/mm and Tamas and Razvan will be taking over vm-event/mem-access. Andres has said he doesn't have time to pick up paging/sharing code, so that will be orphaned for now -- anyone using that code is encouraged to volunteer! Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 00/23] arm64: Add support for 64KB page granularity in Xen guest
On Tue, 23 Jun 2015, Stefano Stabellini wrote: On Mon, 18 May 2015, Julien Grall wrote: Hi David, On 15/05/15 16:45, David Vrabel wrote: On 14/05/15 18:00, Julien Grall wrote: Hi all, ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen hypercall interface and PV protocol are always based on 4KB page granularity. Any attempt to boot a Linux guest with 64KB pages enabled will result to a guest crash. This series is a first attempt to allow those Linux running with the current hypercall interface and PV protocol. This solution has been chosen because we want to run Linux 64KB in released Xen ARM version or/and platform using an old version of Linux DOM0. The key problem I see with this approach is the confusion between guest page size and Xen page size. This is going to be particularly problematic since the majority of development/usage will remain on x86 where PAGE_SIZE == XEN_PAGE_SIZE. I think it would be nice to keep XEN_PAGE_SIZE etc out of front and backend drivers. Perhaps with a suitable set of helper functions? Even with the helpers, we are not protected from any change in the frontend/backend that will impact 64K. It won't be possible to remove all the XEN_PAGE_* usage (there is a lots of places where adding helpers would not be possible) and we would still have to carefully review any changes. We could at least introduce a few asserts, so that an ARM64 kernel build, that any x86 maintainers can easily and quickly do on their x86 machines, would spot these errors. I actually meant BUILD_BUG_ON ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] [XEN-4.4] tools/libxc: Fix build of 32bit toolstacks on CentOS 5.x following XSA-125
Andrew Cooper writes (Re: [Xen-devel] [PATCH] [XEN-4.4] tools/libxc: Fix build of 32bit toolstacks on CentOS 5.x following XSA-125): On 23/06/15 14:21, Ian Jackson wrote: Sorry, I meant, to my staging-4.4. You appear to have committed half of it as staging-4.4~2 Nnnngg. Sorry. I think I am trying to do too many different things at once. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 5/5] Remove me from ARM/DT maintainers list.
On Tue, 2015-06-23 at 14:22 +0100, Tim Deegan wrote: In practice I haven't been actively involved in this code for some time. Signed-off-by: Tim Deegan t...@xen.org Acked-by: Ian Campbell ian.campb...@citrix.com Cc: Stefano Stabellini stefano.stabell...@citrix.com --- MAINTAINERS | 2 -- 1 file changed, 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index d1bec17..6b1068e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -127,7 +127,6 @@ F:tools/libxc/xc_arinc653.c ARM (W/ VIRTUALISATION EXTENSIONS) ARCHITECTURE M: Ian Campbell ian.campb...@citrix.com M: Stefano Stabellini stefano.stabell...@citrix.com -M: Tim Deegan t...@xen.org S: Supported L: xen-devel@lists.xen.org F: xen/arch/arm/ @@ -151,7 +150,6 @@ F:xen/common/cpupool.c DEVICE TREE M: Ian Campbell ian.campb...@citrix.com M: Stefano Stabellini stefano.stabell...@citrix.com -M: Tim Deegan t...@xen.org S: Supported F: xen/common/libfdt/ F: xen/common/device_tree.c ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] Revert libxl: fix xl mem-set regression from 0c029c4da2
This reverts commit f5b43e95facdc17f925cb56a8963cd4531074034.
Signed-off-by: Wei Liu wei.l...@citrix.com
---
tools/libxc/include/xenctrl.h | 2 +-
tools/libxc/xc_domain.c | 2 +-
tools/libxl/libxl.c | 5 ++---
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index d1d2ab3..db5d028 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1285,7 +1285,7 @@ int xc_getcpuinfo(xc_interface *xch, int max_cpus,
int xc_domain_setmaxmem(xc_interface *xch,
uint32_t domid,
-uint64_t max_memkb);
+unsigned int max_memkb);
int xc_domain_set_memmap_limit(xc_interface *xch,
uint32_t domid,
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index ce51e69..5b1a52d 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -635,7 +635,7 @@ int xc_shadow_control(xc_interface *xch,
int xc_domain_setmaxmem(xc_interface *xch,
uint32_t domid,
-uint64_t max_memkb)
+unsigned int max_memkb)
{
DECLARE_DOMCTL;
domctl.cmd = XEN_DOMCTL_max_mem;
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index d86ea62..35caf42 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4736,8 +4736,7 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t
domid,
{
GC_INIT(ctx);
int rc = 1, abort_transaction = 0;
-uint64_t memorykb;
-uint32_t videoram = 0;
+uint32_t memorykb = 0, videoram = 0;
uint32_t current_target_memkb = 0, new_target_memkb = 0;
uint32_t current_max_memkb = 0;
char *memmax, *endptr, *videoram_s = NULL, *target = NULL;
@@ -4831,7 +4830,7 @@ retry_transaction:
rc = xc_domain_setmaxmem(ctx-xch, domid, memorykb);
if (rc != 0) {
LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-xc_domain_setmaxmem domid=%u memkb=%PRIu64 failed
+xc_domain_setmaxmem domid=%d memkb=%d failed
rc=%d\n, domid, memorykb, rc);
abort_transaction = 1;
goto out;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] [XEN-4.4] tools/libxc: Fix build of 32bit toolstacks on CentOS 5.x following XSA-125
On 23/06/15 11:55, Ian Jackson wrote: Andrew Cooper writes ([Xen-devel] [PATCH] [XEN-4.4] tools/libxc: Fix build of 32bit toolstacks on CentOS 5.x following XSA-125): gcc 4.1 of CentOS 5.x era does not like the typecheck in min() between uint64_t and unsigned long. Signed-off-by: Andrew Cooper andrew.coop...@citrix.com CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@eu.citrix.com CC: Wei Liu wei.l...@citrix.com --- This needs backporting to 4.2 This doesn't seem to apply to my staging-4.5. Ian. It wont. This patch is for 4.4 and earlier. The previously-committed version for staging is a clean cherrypick back to 4.5 ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 8/9] x86/pvh: Don't try to get l4 table for PVH guests in vcpu_destroy_pagetables()
On 20.06.15 at 05:09, boris.ostrov...@oracle.com wrote: --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -2652,7 +2652,7 @@ int vcpu_destroy_pagetables(struct vcpu *v) if ( rc ) return rc; -if ( is_pv_32on64_vcpu(v) ) +if ( is_pv_32on64_vcpu(v) !is_pvh_vcpu(v) ) This looks wrong - is_pv_32on64_vcpu() should imply is_pv_vcpu() and hence !is_pvh_vcpu(). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt test] 58119: regressions - FAIL
On Tue, 2015-06-23 at 12:15 +0100, Anthony PERARD wrote: On Mon, Jun 08, 2015 at 10:22:28AM +0100, Ian Campbell wrote: 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. 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 Hi, I've tried to debug this device model: startup time out issue that I'm seeing on OpenStack. What I've done is strace every single QEMU. It appear that QEMU take more than 10s to load... Looking through http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-libvirt/ALL.html when it passes the collected var-log-libvirt-libxl-libxl-driver.log.gz seems to indicate that the device model is successfully spawned in 2-4s. The same is true of the tests run on the Cambridge instance. Now, I do think the 10s timeout is a bit aggressive, on a system doing some sort of boot storm (100s of parallel vm starts) it's not out of the question that spawning qemu might take a little while. _But_ osstest is not doing that, the single virsh create is essentially the only thing happening on the box. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 00/23] arm64: Add support for 64KB page granularity in Xen guest
On Mon, 18 May 2015, Julien Grall wrote: Hi David, On 15/05/15 16:45, David Vrabel wrote: On 14/05/15 18:00, Julien Grall wrote: Hi all, ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen hypercall interface and PV protocol are always based on 4KB page granularity. Any attempt to boot a Linux guest with 64KB pages enabled will result to a guest crash. This series is a first attempt to allow those Linux running with the current hypercall interface and PV protocol. This solution has been chosen because we want to run Linux 64KB in released Xen ARM version or/and platform using an old version of Linux DOM0. The key problem I see with this approach is the confusion between guest page size and Xen page size. This is going to be particularly problematic since the majority of development/usage will remain on x86 where PAGE_SIZE == XEN_PAGE_SIZE. I think it would be nice to keep XEN_PAGE_SIZE etc out of front and backend drivers. Perhaps with a suitable set of helper functions? Even with the helpers, we are not protected from any change in the frontend/backend that will impact 64K. It won't be possible to remove all the XEN_PAGE_* usage (there is a lots of places where adding helpers would not be possible) and we would still have to carefully review any changes. We could at least introduce a few asserts, so that an ARM64 kernel build, that any x86 maintainers can easily and quickly do on their x86 machines, would spot these errors. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 5/6] AMD-PVH: Support TSC_MODE_NEVER_EMULATE for PVH
On 22.06.15 at 18:37, elena.ufimts...@oracle.com wrote:
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1923,6 +1923,7 @@ void tsc_set_info(struct domain *d,
* but always_emulate does not for some reason. Figure out
* why.
*/
+d-arch.tsc_khz = cpu_khz;
switch ( tsc_mode )
{
case TSC_MODE_NEVER_EMULATE:
Considering that it's vcpu_tsc_ratio() that wants this set, I don't
think doing this here (and hence depending on this function being
called early enough / at all) is appropriate. Instead I think this
should be done in SVM's vCPU initialization.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5.1 released
On 23.06.15 at 12:54, net...@crc.id.au wrote: On 23/06/2015 8:45 PM, Ian Jackson wrote: Ian Jackson writes (Re: [Xen-devel] Xen 4.5.1 released): M A Young writes (Re: [Xen-devel] Xen 4.5.1 released): I don't believe this release has the qemu-xen-traditional half of XSA-135. If this wasn't deliberate it might be worth noting it somewhere. You're right. It appears that the patch for XSA-135 was never applied to qemu-traditional, due to an oversight. The XSA-135 fix was missing everywhere. I have now applied it (to all trees 4.1 and onward). Out of interest, is the plan now to re-release a fixed 4.5.1 archive or document the lack of the XSA135 patches and allow people to patch manually? Only documenting the issue is the plan. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 3/4] xen: implement SCHEDOP_soft_reset
On 23.06.15 at 14:10, vkuzn...@redhat.com wrote: Jan Beulich jbeul...@suse.com writes: On 22.06.15 at 18:24, vkuzn...@redhat.com wrote: Jan Beulich jbeul...@suse.com writes: On 22.06.15 at 18:00, vkuzn...@redhat.com wrote: Jan Beulich jbeul...@suse.com writes: On 03.06.15 at 15:35, vkuzn...@redhat.com wrote: @@ -1129,8 +1129,9 @@ void unmap_vcpu_info(struct vcpu *v) mfn = v-vcpu_info_mfn; unmap_domain_page_global((void *) ((unsigned long)v-vcpu_info PAGE_MASK)); - -v-vcpu_info = dummy_vcpu_info; +v-vcpu_info = ((v-vcpu_id XEN_LEGACY_MAX_VCPUS) +? (vcpu_info_t *)shared_info(d, vcpu_info[v-vcpu_id]) Is this cast really needed? Without it my gcc-4.8.3 complains: domain.c: In function ‘unmap_vcpu_info’: domain.c:1158:21: error: pointer type mismatch in conditional expression [-Werror] : dummy_vcpu_info); ^ cc1: all warnings being treated as errors Which is the kind of warning one normally should _not_ work around by adding a cast. In this (and in alloc_vcpu() from where this expression was copied) particular case this is probably OK: in struct shared_info we have 'struct vcpu_info vcpu_info[XEN_LEGACY_MAX_VCPUS]' as its first member. But I may be missing something.. Did you read the comment accompanying the definition of __shared_info()? The cast is presumably safe here, but it doesn't _look_ safe. And for future readers (and future changes) it would be better if it did. Sorry, it seems I don't undestand the suggestion on how to make this look better. I didn't suggest anything in particular; all I care about is for such casts to be avoided. With CONFIG_COMPAT in both struct shared_info and struct compat_shared_info vcpu_info array is of type 'struct vcpu_info[]' but v-vcpu_info is of type 'vcpu_info_t *' which means union of 'struct vcpu_info' and 'struct compat_vcpu_info' in CONFIG_COMPAT case. Both these structures have same size of '64' on x86 so it's really up to its user how to treat this data... Sure, but that doesn't make the cast any more safe or look any better. But then again I see we already have a similar construct in alloc_vcpu(), i.e. - okay, keep it as is. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] [XEN-4.4] tools/libxc: Fix build of 32bit toolstacks on CentOS 5.x following XSA-125
On 23/06/15 14:21, Ian Jackson wrote: Ian Jackson writes (Re: [Xen-devel] [PATCH] [XEN-4.4] tools/libxc: Fix build of 32bit toolstacks on CentOS 5.x following XSA-125): Andrew Cooper writes ([Xen-devel] [PATCH] [XEN-4.4] tools/libxc: Fix build of 32bit toolstacks on CentOS 5.x following XSA-125): gcc 4.1 of CentOS 5.x era does not like the typecheck in min() between uint64_t and unsigned long. Signed-off-by: Andrew Cooper andrew.coop...@citrix.com CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@eu.citrix.com CC: Wei Liu wei.l...@citrix.com --- This needs backporting to 4.2 This doesn't seem to apply to my staging-4.5. Sorry, I meant, to my staging-4.4. You appear to have committed half of it as staging-4.4~2 ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 09/23] arm/xen: Drop duplicate define mfn_to_virt
On Thu, 14 May 2015, Julien Grall wrote: From: Julien Grall julien.gr...@linaro.org Signed-off-by: Julien Grall julien.gr...@citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Reviewed-by: Stefano Stabellini stefano.stabell...@eu.citrix.com arch/arm/include/asm/xen/page.h | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h index 0b579b2..1bee8ca 100644 --- a/arch/arm/include/asm/xen/page.h +++ b/arch/arm/include/asm/xen/page.h @@ -12,7 +12,6 @@ #include xen/interface/grant_table.h #define phys_to_machine_mapping_valid(pfn) (1) -#define mfn_to_virt(m) (__va(mfn_to_pfn(m) PAGE_SHIFT)) #define pte_mfn pte_pfn #define mfn_pte pfn_pte -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt test] 58119: regressions - FAIL
On Tue, Jun 23, 2015 at 01:57:18PM +0100, Ian Campbell wrote: On Tue, 2015-06-23 at 12:15 +0100, Anthony PERARD wrote: On Mon, Jun 08, 2015 at 10:22:28AM +0100, Ian Campbell wrote: 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. 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 Hi, I've tried to debug this device model: startup time out issue that I'm seeing on OpenStack. What I've done is strace every single QEMU. It appear that QEMU take more than 10s to load... FWIW I've started running some adhoc osstest jobs on the Cambridge instance too, first time everything passed. The second attempt I forced onto the *-frog machines which are AMD Opteron(tm) Processor 6168 processors which is as close as I can get to the AMD Opteron(tm) Processor 6376 ones in merlot* and they also passed. That's not enough data to really be going on though. Do you happen to know what h/w the openstack tests run on? It is using nested virt, is that right? For the strace I've sent, they come from a local machine and it is running Xen baremetal. It's an AMD Opteron(tm) Processor 4284. Out of about 4100 domain created, there are only 16 device model startup timeout. I've gathered the data while running Tempest, and asked it to run 4 concurrent tests. Given that merlot* seems to have some sort of barking NUMA configuration SNAFU I wouldn't necessarily rule out it's just really slow. 10s does seem _very_ slow though, on an essentially idle system, no matter how bad it's NUMA-ness is setup... There is probably something specific about those merlot* machines. I think the issue I have with OpenStack and the time out is just a machine that have too much to do. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 6/9] x86/pvh: Properly set HYPERVISOR_COMPAT_VIRT_START for PVH guests
On 20.06.15 at 05:09, boris.ostrov...@oracle.com wrote: --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -584,7 +584,7 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags, mapcache_domain_init(d); HYPERVISOR_COMPAT_VIRT_START(d) = -is_pv_domain(d) ? __HYPERVISOR_COMPAT_VIRT_START : ~0u; +is_hvm_domain(d) ? ~0u : __HYPERVISOR_COMPAT_VIRT_START; Why would a PVH domain be different in this respect from a HVM one? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 7/9] x86/pvh: Handle hypercalls for 32b PVH guests
On 20.06.15 at 05:09, boris.ostrov...@oracle.com wrote: @@ -4959,8 +4979,10 @@ int hvm_do_hypercall(struct cpu_user_regs *regs) return viridian_hypercall(regs); if ( (eax = NR_hypercalls) || - (is_pvh_domain(currd) ? !pvh_hypercall64_table[eax] - : !hvm_hypercall32_table[eax]) ) + (is_pvh_vcpu(curr) ? ((mode == 8) ? Please no switch back to the more expensive is_pvh_vcpu(). + !pvh_hypercall64_table[eax] : + !pvh_hypercall32_table[eax]) +: !hvm_hypercall32_table[eax]) ) This should be done consistently - either all four variants get checked, or pvh_hypercall64_table[] simply get replaced by pvh_hypercall32_table[]. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/2] Revert changes to libxl_set_memory_target, unblock 4.6
A new memory model that allows QEMU to bump memory behind libxl's back was merged a few months ago. We didn't fully understand the repercussions back then. Now it breaks migration and becomes blocker of 4.6 release. It's better to restore to original behaviour at this stage of the release cycle, that would put us in a position no worse than before, so the release is unblocked. The said function is still racy after reverting these two patches. Making domain memory state consistent requires a bit more work. Separate patch(es) will be sent out to deal with that problem. Wei. Wei Liu (2): Revert libxl: fix xl mem-set regression from 0c029c4da2 Revert libxl_set_memory_target: retain the same maxmem offset on top of the current target tools/libxc/include/xenctrl.h | 2 +- tools/libxc/xc_domain.c | 2 +- tools/libxl/libxl.c | 29 - 3 files changed, 18 insertions(+), 15 deletions(-) -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] [XEN-4.4] tools/libxc: Fix build of 32bit toolstacks on CentOS 5.x following XSA-125
Ian Jackson writes (Re: [Xen-devel] [PATCH] [XEN-4.4] tools/libxc: Fix build of 32bit toolstacks on CentOS 5.x following XSA-125): Andrew Cooper writes (Re: [Xen-devel] [PATCH] [XEN-4.4] tools/libxc: Fix build of 32bit toolstacks on CentOS 5.x following XSA-125): On 23/06/15 14:21, Ian Jackson wrote: Sorry, I meant, to my staging-4.4. You appear to have committed half of it as staging-4.4~2 Nnnngg. Sorry. I think I am trying to do too many different things at once. Now fixed. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] Revert libxl_set_memory_target: retain the same maxmem offset on top of the current target
This reverts commit 0c029c4da2169159064568ef4fea862a5d2cd84a.
Signed-off-by: Wei Liu wei.l...@citrix.com
---
tools/libxl/libxl.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 35caf42..e3e63b5 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4741,16 +4741,11 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t
domid,
uint32_t current_max_memkb = 0;
char *memmax, *endptr, *videoram_s = NULL, *target = NULL;
char *dompath = libxl__xs_get_dompath(gc, domid);
+xc_domaininfo_t info;
libxl_dominfo ptr;
char *uuid;
xs_transaction_t t;
-libxl_dominfo_init(ptr);
-if (libxl_domain_info(ctx, ptr, domid) 0)
-goto out_no_transaction;
-
-uuid = libxl__uuid2string(gc, ptr.uuid);
-
retry_transaction:
t = xs_transaction_start(ctx-xsh);
@@ -4826,12 +4821,13 @@ retry_transaction:
}
if (enforce) {
-memorykb = ptr.max_memkb - current_target_memkb + new_target_memkb;
-rc = xc_domain_setmaxmem(ctx-xch, domid, memorykb);
+memorykb = new_target_memkb + videoram;
+rc = xc_domain_setmaxmem(ctx-xch, domid, memorykb +
+LIBXL_MAXMEM_CONSTANT);
if (rc != 0) {
LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
xc_domain_setmaxmem domid=%d memkb=%d failed
-rc=%d\n, domid, memorykb, rc);
+rc=%d\n, domid, memorykb + LIBXL_MAXMEM_CONSTANT, rc);
abort_transaction = 1;
goto out;
}
@@ -4850,9 +4846,18 @@ retry_transaction:
libxl__xs_write(gc, t, libxl__sprintf(gc, %s/memory/target,
dompath), %PRIu32, new_target_memkb);
+rc = xc_domain_getinfolist(ctx-xch, domid, 1, info);
+if (rc != 1 || info.domain != domid) {
+abort_transaction = 1;
+goto out;
+}
+libxl_dominfo_init(ptr);
+xcinfo2xlinfo(ctx, info, ptr);
+uuid = libxl__uuid2string(gc, ptr.uuid);
libxl__xs_write(gc, t, libxl__sprintf(gc, /vm/%s/memory, uuid),
%PRIu32, new_target_memkb / 1024);
+libxl_dominfo_dispose(ptr);
out:
if (!xs_transaction_end(ctx-xsh, t, abort_transaction)
@@ -4861,7 +4866,6 @@ out:
goto retry_transaction;
out_no_transaction:
-libxl_dominfo_dispose(ptr);
GC_FREE;
return rc;
}
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 09/23] arm/xen: Drop duplicate define mfn_to_virt
Hi, On 23/06/15 14:25, Stefano Stabellini wrote: On Thu, 14 May 2015, Julien Grall wrote: From: Julien Grall julien.gr...@linaro.org Signed-off-by: Julien Grall julien.gr...@citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Reviewed-by: Stefano Stabellini stefano.stabell...@eu.citrix.com FYI, David already queued this patch in xentip for Linux 4.2. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Passthrough ARM Design : Draft1
On Tue, Jun 23, 2015 at 09:44:31AM +0100, Ian Campbell wrote:
On Mon, 2015-06-22 at 14:33 -0400, Konrad Rzeszutek Wilk wrote:
On Wed, Jun 17, 2015 at 03:35:02PM +0100, Stefano Stabellini wrote:
On Wed, 17 Jun 2015, Ian Campbell wrote:
On Wed, 2015-06-17 at 07:14 -0700, Manish Jaggi wrote:
On Wednesday 17 June 2015 06:43 AM, Ian Campbell wrote:
On Wed, 2015-06-17 at 13:58 +0100, Stefano Stabellini wrote:
Yes, pciback is already capable of doing that, see
drivers/xen/xen-pciback/conf_space.c
I am not sure if the pci-back driver can query the guest memory
map. Is there an existing hypercall ?
No, that is missing. I think it would be OK for the virtual BAR
to be
initialized to the same value as the physical BAR. But I would
let the
guest change the virtual BAR address and map the MMIO region
wherever it
wants in the guest physical address space with
XENMEM_add_to_physmap_range.
I disagree, given that we've apparently survived for years with x86
PV
guests not being able to right to the BARs I think it would be far
simpler to extend this to ARM and x86 PVH too than to allow guests
to
start writing BARs which has various complex questions around it.
All that's needed is for the toolstack to set everything up and
write
some new xenstore nodes in the per-device directory with the BAR
address/size.
Also most guests apparently don't reassign the PCI bus by default,
so
using a 1:1 by default and allowing it to be changed would require
modifying the guests to reasssign. Easy on Linux, but I don't know
about
others and I imagine some OSes (especially simpler/embedded ones)
are
assuming the firmware sets up something sane by default.
Does the Flow below captures all points
a) When assigning a device to domU, toolstack creates a node in per
device directory with virtual BAR address/size
Option1:
b) toolstack using some hypercall ask xen to create p2m mapping {
virtual BAR : physical BAR } for domU
c) domU will not anytime update the BARs, if it does then it is a
fault,
till we decide how to handle it
As Julien has noted pciback already deals with this correctly, because
sizing a BAR involves a write, it implementes a scheme which allows
either the hardcoded virtual BAR to be written or all 1s (needed for
size detection).
d) when domU queries BAR address from pci-back the virtual BAR
address
is provided.
Option2:
b) domU will not anytime update the BARs, if it does then it is a
fault,
till we decide how to handle it
c) when domU queries BAR address from pci-back the virtual BAR
address
is provided.
d) domU sends a hypercall to map virtual BARs,
e) xen pci code reads the BAR and maps { virtual BAR : physical BAR }
for domU
Which option is better I think Ian is for (2) and Stefano may be (1)
In fact I'm now (after Julien pointed out the current behaviour of
pciback) in favour of (1), although I'm not sure if Stefano is too.
(I was never in favour of (2), FWIW, I previously was in favour of (3)
which is like (2) except pciback makes the hypervcall to map the virtual
bars to the guest, I'd still favour that over (2) but (1) is now my
preference)
OK, let's go with (1).
Right, and as the maintainer of pciback that means I don't have to do
anything right :-)
I _think_ there will need to be some mechanism for the toolstack to
inform pciback what the virtual BARs should contain, so it can correctly
process read requests. But other than review that (hopefully) small bit
of code, I think there is nothing for you to do.
XenBus is the way to go for that.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 23/23] arm/xen: Add support for 64KB page granularity
On Thu, 14 May 2015, Julien Grall wrote:
The hypercall interface is always using 4KB page granularity. This is
requiring to use xen page definition macro when we deal with hypercall.
Note that pfn_to_mfn is working with a Xen pfn (i.e 4KB). We may want to
rename pfn_mfn to make this explicit.
We also allocate a 64KB page for the shared page even though only the
first 4KB is used. I don't think this is really important for now as it
helps to have the pointer 4KB aligned (XENMEM_add_to_physmap is taking a
Xen PFN).
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Russell King li...@arm.linux.org.uk
arch/arm/include/asm/xen/page.h | 12 ++--
arch/arm/xen/enlighten.c| 6 +++---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 1bee8ca..ab6eb9a 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -56,19 +56,19 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
static inline xmaddr_t phys_to_machine(xpaddr_t phys)
{
- unsigned offset = phys.paddr ~PAGE_MASK;
- return XMADDR(PFN_PHYS(pfn_to_mfn(PFN_DOWN(phys.paddr))) | offset);
+ unsigned offset = phys.paddr ~XEN_PAGE_MASK;
+ return XMADDR(XEN_PFN_PHYS(pfn_to_mfn(XEN_PFN_DOWN(phys.paddr))) |
offset);
}
static inline xpaddr_t machine_to_phys(xmaddr_t machine)
{
- unsigned offset = machine.maddr ~PAGE_MASK;
- return XPADDR(PFN_PHYS(mfn_to_pfn(PFN_DOWN(machine.maddr))) | offset);
+ unsigned offset = machine.maddr ~XEN_PAGE_MASK;
+ return XPADDR(XEN_PFN_PHYS(mfn_to_pfn(XEN_PFN_DOWN(machine.maddr))) |
offset);
}
/* VIRT - MACHINE conversion */
#define virt_to_machine(v) (phys_to_machine(XPADDR(__pa(v
-#define virt_to_mfn(v) (pfn_to_mfn(virt_to_pfn(v)))
-#define mfn_to_virt(m) (__va(mfn_to_pfn(m) PAGE_SHIFT))
+#define virt_to_mfn(v) (pfn_to_mfn(virt_to_phys(v)
XEN_PAGE_SHIFT))
+#define mfn_to_virt(m) (__va(mfn_to_pfn(m) XEN_PAGE_SHIFT))
static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
{
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 224081c..dcfe251 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -93,8 +93,8 @@ static void xen_percpu_init(void)
pr_info(Xen: initializing cpu%d\n, cpu);
vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
- info.mfn = __pa(vcpup) PAGE_SHIFT;
- info.offset = offset_in_page(vcpup);
+ info.mfn = __pa(vcpup) XEN_PAGE_SHIFT;
+ info.offset = xen_offset_in_page(vcpup);
err = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_info, cpu, info);
BUG_ON(err);
@@ -204,7 +204,7 @@ static int __init xen_guest_init(void)
xatp.domid = DOMID_SELF;
xatp.idx = 0;
xatp.space = XENMAPSPACE_shared_info;
- xatp.gpfn = __pa(shared_info_page) PAGE_SHIFT;
+ xatp.gpfn = __pa(shared_info_page) XEN_PAGE_SHIFT;
if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, xatp))
BUG();
What about xen_remap_domain_mfn_range? I guess we don't support that use
case on 64K guests? If so, I would appreaciate an assert and/or an error
message.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] Revert changes to libxl_set_memory_target, unblock 4.6
CC Jan, author of one of the patches. On Tue, Jun 23, 2015 at 03:16:22PM +0100, Wei Liu wrote: A new memory model that allows QEMU to bump memory behind libxl's back was merged a few months ago. We didn't fully understand the repercussions back then. Now it breaks migration and becomes blocker of 4.6 release. It's better to restore to original behaviour at this stage of the release cycle, that would put us in a position no worse than before, so the release is unblocked. The said function is still racy after reverting these two patches. Making domain memory state consistent requires a bit more work. Separate patch(es) will be sent out to deal with that problem. Wei. Wei Liu (2): Revert libxl: fix xl mem-set regression from 0c029c4da2 Revert libxl_set_memory_target: retain the same maxmem offset on top of the current target tools/libxc/include/xenctrl.h | 2 +- tools/libxc/xc_domain.c | 2 +- tools/libxl/libxl.c | 29 - 3 files changed, 18 insertions(+), 15 deletions(-) -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/5] Change x86 paging/sharing to 'Orphaned'.
On Tue, Jun 23, 2015 at 6:22 AM, Tim Deegan t...@xen.org wrote: This code now has no active maintainers, as neither Andres nor I can commit the time. Signed-off-by: Tim Deegan t...@xen.org Cc: Andres Lagar-Cavilla and...@lagarcavilla.org Wistfully, Acked-by: Andres Lagar-Cavilla and...@lagarcavilla.org --- MAINTAINERS | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 7f0e96e..d1bec17 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -367,9 +367,7 @@ S: Supported F: xen/arch/x86/mm/ X86 MEMORY SHARING AND PAGING -M: Andres Lagar-Cavilla and...@lagarcavilla.org -M: Tim Deegan t...@xen.org -S: Supported +S: Orphaned F: xen/arch/x86/mm/mem_sharing.c F: xen/arch/x86/mm/mem_paging.c F: tools/memshr -- 2.3.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: libxl: Take the userdata lock around maxmem changes
On Tue, 2015-06-23 at 17:32 +0100, Wei Liu wrote: On Tue, Jun 23, 2015 at 03:58:32PM +0100, Ian Campbell wrote: There is an issue in libxl_set_memory_target whereby the target and the max mem can get out of sync, this is because the call the xc_domain_setmaxmem is not tied in any way to the xenstore transaction which controls updates to the xenstore side of things. Consider a domain with 1M of RAM (==target and maxmem for the sake of argument) and two simultaneous calls to libxl_set_memory_target, both with relative=0 and enforce=1, one with target=3 and the other with target=5. target=5 call target=3 call transaction start transaction start write target=5 to xenstore write target=3 to xenstore setmaxmem(5) setmaxmem(3) transaction commit = success transaction commit = EAGAIN At this point maxmem=3 while target=5. In reality the target=3 case will the retry and eventually (hopefully) succeed with target=maxmem=3, however the bad state will persist for some window which is undesirable. On failure other than EAGAIN all bets are off anyway, but in that case we will likely stick in the bad state until someone else sets the memory). To fix this we slightly abuse the userdata lock which is used to protect updates to the domain's json configuration. Abused because maxmem is not actually stored in there, but is kept by Xen. However the lock protects some semantically similar things and is convenient to use here too. libxl_domain_setmaxmem also takes the lock, since it reads memory/target from xenstore before calling xc_domain_setmaxmem there is a small (but perhaps not very interesting) race there too. There is on more use of xc_domain_setmaxmem in libxl__build_pre. However taking a lock around this would be tricky since the xenstore parts are not done until libxl__build_post. I think this one could be argued to be OK since the domid is not public yet, that is it has not been returned to the application yet (as the result of the create operation). Toolstacks which go round fiddling with random domid's which they find lying on the floor should be taught to do better. Add a doc note that taking the userdata lock requires the CTX_LOCK to be held. Signed-off-by: Ian Campbell ian.campb...@citrix.com --- This applies on top of Wei's revert of libxl_set_memory_target: retain the same maxmem offset on top of the current target I couldn't quite rule out some race (for transaction=EAGAIN, for !EAGAIN there are obvious ones) which resulted in the incorrect state being in place after both entities exit, but couldn't construct an actual case. Not sure I follow. With this patch you lock out other contenders to even start a transaction so the EAGAIN vs !EAGAIN should be moot. You can safely rollback in !EAGAIN case, right? Sorry, I meant a prexisting race which was fixed by this patch, rather than one that continues to exist with this fix. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] xen: Allow xen tools to run in guest using 64K page granularity
Hi, Ping? I don't think this patch series depends on others (such as Linux 64K support) to review it. Regards, On 11/05/15 12:55, Julien Grall wrote: Hi all, This small series are the only changes required in Xen in order to run a guest using 64K page granularity on top of an unmodified Xen. I'd like feedback from maintainers tools to know if it might be worth to introduce a function xc_pagesize() replicating the behavior of getpagesize() for Xen. Sincerely yours, Julien Grall (2): tools/xenstored: Use XC_PAGE_SIZE rather than getpagesize() tools/xenconsoled: Use XC_PAGE_SIZE rather than getpagesize() tools/console/daemon/io.c | 4 ++-- tools/xenstore/xenstored_domain.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 58834: tolerable FAIL - PUSHED
flight 58834 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58834/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 58756
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 58756
version targeted for testing:
ovmf 37baf06b44ba78214aca8806b8516575d3b20db6
baseline version:
ovmf de4db4da318115e9e239c2e3a255889cc8fc5c1b
People who touched revisions under test:
Gabriel Somlo so...@cmu.edu
Laszlo Ersek ler...@redhat.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
Pushing revision :
+ branch=ovmf
+ revision=37baf06b44ba78214aca8806b8516575d3b20db6
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
37baf06b44ba78214aca8806b8516575d3b20db6
+ branch=ovmf
+ revision=37baf06b44ba78214aca8806b8516575d3b20db6
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case $branch in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{OsstestUpstream} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
[Xen-devel] [PATCH OSSTEST 2/2] mg-debian-installer-update: Update current symlink, if appropriate
Where appropriate means if TftpDiVersion is set to current, which is the default in standalone mode. The assumption is that someone wuth that configration runs mg-debian-installer-update then they would expected the update to be immediately effective. There was some existing, but commented, code to do this update, reinstate it with the correct condition and adjusting for the addition of -$suite to the patch many moons ago. There is no impact on any production configuration, since they always set TftpDiVersion. Signed-off-by: Ian Campbell ian.campb...@citrix.com --- mg-debian-installer-update | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/mg-debian-installer-update b/mg-debian-installer-update index 59f05ec..f7a954a 100755 --- a/mg-debian-installer-update +++ b/mg-debian-installer-update @@ -67,6 +67,7 @@ esac pfile=$sbase/non-free/binary-$arch/Packages.gz +tftpdiversion=`getconfig TftpDiVersion` dstroot=`getconfig TftpPath`/`getconfig TftpDiBase`/ date=`date +%Y-%m-%d` dst=$arch/$date-$suite @@ -192,10 +193,12 @@ done rm Packages.gz -#cd $dstroot/$arch -#rm -rf current.new -#ln -s $date current.new -#mv -Tf current.new current +if [ x$tftpdiversion = xcurrent ]; then +cd $dstroot/$arch +rm -rf current-$suite.new +ln -s $date-$suite current-$suite.new +mv -Tf current-$suite.new current-$suite +fi echo New TftpDiVersion: $date echo 2 downloaded $dstroot/$dst -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 10/11] libxc: add XC_DEVICE_MODEL_SAVE_FILE
Use this in libxl_dm instead of hard-coding.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
Acked-by: Ian Campbell ian.campb...@citrix.com
---
tools/libxc/include/xenguest.h | 2 ++
tools/libxl/libxl_dm.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index 7581263..c95e93c 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -147,6 +147,8 @@ int xc_domain_restore2(xc_interface *xch, int io_fd,
uint32_t dom,
* of the new domain is automatically appended to the filename,
* separated by a ..
*/
+
+#define XC_DEVICE_MODEL_SAVE_FILE /var/lib/xen/qemu-save
#define XC_DEVICE_MODEL_RESTORE_FILE /var/lib/xen/qemu-resume
/**
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 33f9ce6..db789ac 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -31,7 +31,7 @@ static const char *libxl_tapif_script(libxl__gc *gc)
const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid)
{
-return libxl__sprintf(gc, /var/lib/xen/qemu-save.%d, domid);
+return libxl__sprintf(gc, XC_DEVICE_MODEL_SAVE_FILE.%d, domid);
}
static const char *qemu_xen_path(libxl__gc *gc)
--
2.4.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 11/11] (lib)xl: soft reset support
Use existing create/restore path to perform 'soft reset' for HVM domains.
Tear everything down, e.g. destroy domain's device model, remove the domain
from xenstore, save toolstack record and start over.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
Changes since 'v7'
- 'Reset everything approach': XEN_DOMCTL_soft_reset doesn't destroy the
original domain any more.
- libxl__domain_soft_reset_state introduced [Ian Campbell]
- Separate do_domain_soft_reset to not intertwine with do_domain_create
[Ian Campbell]
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
docs/man/xl.cfg.pod.5| 10 +++
tools/libxl/libxl.c | 16 +++-
tools/libxl/libxl.h | 12 +++
tools/libxl/libxl_create.c | 181 +--
tools/libxl/libxl_internal.h | 4 +
tools/libxl/libxl_types.idl | 3 +
tools/libxl/xl.h | 1 +
tools/libxl/xl_cmdimpl.c | 33 +++-
8 files changed, 232 insertions(+), 28 deletions(-)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index a3e0e2e..27f4c2a 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -368,6 +368,11 @@ destroy the domain.
write a coredump of the domain to F/var/lib/xen/dump/NAME and then
restart the domain.
+=item Bsoft-reset
+
+cleanup the domain without destroying it, restart the device model. This action
+is supported for HVM guests only.
+
=back
The default for Con_poweroff is Cdestroy.
@@ -386,6 +391,11 @@ Default is Cdestroy.
Action to take if the domain crashes. Default is Cdestroy.
+=item Bon_soft_reset=ACTION
+
+Action to take if the domain performs 'soft reset' (e.g. does kexec).
+Default is Csoft-reset.
+
=back
=head3 Direct Kernel Boot
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index d86ea62..a6743a7 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1492,6 +1492,7 @@ void libxl__domain_destroy(libxl__egc *egc,
libxl__domain_destroy_state *dds)
dds-stubdom.ao = ao;
dds-stubdom.domid = stubdomid;
dds-stubdom.callback = stubdom_destroy_callback;
+dds-stubdom.soft_reset = false;
libxl__destroy_domid(egc, dds-stubdom);
} else {
dds-stubdom_finished = 1;
@@ -1500,6 +1501,7 @@ void libxl__domain_destroy(libxl__egc *egc,
libxl__domain_destroy_state *dds)
dds-domain.ao = ao;
dds-domain.domid = dds-domid;
dds-domain.callback = domain_destroy_callback;
+dds-domain.soft_reset = dds-soft_reset;
libxl__destroy_domid(egc, dds-domain);
}
@@ -1680,10 +1682,13 @@ static void devices_destroy_cb(libxl__egc *egc,
/* Clean up qemu-save and qemu-resume files. They are
* intermediate files created by libxc. Unfortunately they
- * don't fit in existing userdata scheme very well.
+ * don't fit in existing userdata scheme very well. In soft reset
+ * case we need to keep the file.
*/
-rc = libxl__remove_file(gc, libxl__device_model_savefile(gc, domid));
-if (rc 0) goto out;
+if (!dis-soft_reset) {
+rc = libxl__remove_file(gc, libxl__device_model_savefile(gc, domid));
+if (rc 0) goto out;
+}
rc = libxl__remove_file(gc,
GCSPRINTF(XC_DEVICE_MODEL_RESTORE_FILE.%u, domid));
if (rc 0) goto out;
@@ -1694,7 +1699,10 @@ static void devices_destroy_cb(libxl__egc *egc,
ctx-xch = xc_interface_open(ctx-lg,0,0);
if (!ctx-xch) goto badchild;
-rc = xc_domain_destroy(ctx-xch, domid);
+if (!dis-soft_reset)
+rc = xc_domain_destroy(ctx-xch, domid);
+else
+rc = xc_domain_soft_reset(ctx-xch, domid);
if (rc 0) goto badchild;
_exit(0);
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 0a7913b..2006fd6f 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -200,6 +200,13 @@
#define LIBXL_HAVE_DEVICETREE_PASSTHROUGH 1
/*
+ * LIBXL_HAVE_SOFT_RESET indicates that libxl supports performing 'soft reset'
+ * for domains and there is 'soft_reset' shutdown reason in enum
+ * libxl_shutdown_reason.
+ */
+#define LIBXL_HAVE_SOFT_RESET 1
+
+/*
* libxl ABI compatibility
*
* The only guarantee which libxl makes regarding ABI compatibility
@@ -1012,6 +1019,11 @@ int static inline libxl_domain_create_restore_0x040200(
#endif
+int libxl_domain_soft_reset(libxl_ctx *ctx, libxl_domain_config *d_config,
+uint32_t domid, const libxl_asyncop_how *ao_how,
+const libxl_asyncprogress_how *aop_console_how)
+LIBXL_EXTERNAL_CALLERS_ONLY;
+
/* A progress report will be made via ao_console_how, of type
* domain_create_console_available, when the domain's primary
* console is available and can be connected to.
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 86384d2..7b8dcf5 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -536,8 +536,6 @@ int
[Xen-devel] [PATCH v8 02/11] libxl: support SHUTDOWN_soft_reset shutdown reason
Use letter 'S' to indicate a domain in such state.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
Acked-by: Ian Campbell ian.campb...@citrix.com
---
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c | 2 +-
tools/python/xen/lowlevel/xl/xl.c | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 23f27d4..9001f65 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -177,6 +177,7 @@ libxl_shutdown_reason = Enumeration(shutdown_reason, [
(2, suspend),
(3, crash),
(4, watchdog),
+(5, soft_reset),
], init_val = LIBXL_SHUTDOWN_REASON_UNKNOWN)
libxl_vga_interface_type = Enumeration(vga_interface_type, [
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c858068..7247cf1 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3725,7 +3725,7 @@ static void list_domains(bool verbose, bool context, bool
claim, bool numa,
bool cpupool, const libxl_dominfo *info, int
nb_domain)
{
int i;
-static const char shutdown_reason_letters[]= -rscw;
+static const char shutdown_reason_letters[]= -rscwS;
libxl_bitmap nodemap;
libxl_physinfo physinfo;
diff --git a/tools/python/xen/lowlevel/xl/xl.c
b/tools/python/xen/lowlevel/xl/xl.c
index 32f982a..7c61160 100644
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -784,6 +784,7 @@ PyMODINIT_FUNC initxl(void)
_INT_CONST_LIBXL(m, SHUTDOWN_REASON_SUSPEND);
_INT_CONST_LIBXL(m, SHUTDOWN_REASON_CRASH);
_INT_CONST_LIBXL(m, SHUTDOWN_REASON_WATCHDOG);
+_INT_CONST_LIBXL(m, SHUTDOWN_REASON_SOFT_RESET);
genwrap__init(m);
}
--
2.4.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 06/11] xen: Introduce XEN_DOMCTL_soft_reset
New domctl resets state for a domain allowing it to 'start over': register
vcpu_info, switch to FIFO ABI for event channels. Still active grants are
being logged to help debugging misbehaving backends.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
xen/common/domain.c | 29 ++---
xen/common/domctl.c | 9 +
xen/include/public/domctl.h | 1 +
xen/include/xen/sched.h | 2 ++
4 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 3bc52e6..ade80ff 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1010,6 +1010,26 @@ int domain_unpause_by_systemcontroller(struct domain *d)
return 0;
}
+int domain_soft_reset(struct domain *d)
+{
+struct vcpu *v;
+
+for_each_vcpu ( d, v )
+if ( !v-paused_for_shutdown )
+return -EINVAL;
+
+evtchn_reset(d);
+
+grant_table_warn_active_grants(d);
+
+for_each_vcpu ( d, v )
+unmap_vcpu_info(v);
+
+domain_resume(d);
+
+return 0;
+}
+
int vcpu_reset(struct vcpu *v)
{
struct domain *d = v-domain;
@@ -1121,12 +1141,12 @@ int map_vcpu_info(struct vcpu *v, unsigned long gfn,
unsigned offset)
/*
* Unmap the vcpu info page if the guest decided to place it somewhere
- * else. This is only used from arch_domain_destroy, so there's no
- * need to do anything clever.
+ * else. This is used from arch_domain_destroy and domain_soft_reset.
*/
void unmap_vcpu_info(struct vcpu *v)
{
unsigned long mfn;
+struct domain *d = v-domain;
if ( v-vcpu_info_mfn == INVALID_MFN )
return;
@@ -1135,7 +1155,10 @@ void unmap_vcpu_info(struct vcpu *v)
unmap_domain_page_global((void *)
((unsigned long)v-vcpu_info PAGE_MASK));
-v-vcpu_info = dummy_vcpu_info;
+v-vcpu_info = ((v-vcpu_id XEN_LEGACY_MAX_VCPUS)
+? (vcpu_info_t *)shared_info(d, vcpu_info[v-vcpu_id])
+: dummy_vcpu_info);
+
v-vcpu_info_mfn = INVALID_MFN;
put_page_and_type(mfn_to_page(mfn));
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index ce517a7..8cb6a2a 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -703,6 +703,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
u_domctl)
break;
}
+case XEN_DOMCTL_soft_reset:
+if ( d == current-domain )
+{
+ret = -EINVAL;
+break;
+}
+ret = domain_soft_reset(d);
+break;
+
case XEN_DOMCTL_destroydomain:
ret = domain_kill(d);
if ( ret == -ERESTART )
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index bc45ea5..5b4ba6b 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1114,6 +1114,7 @@ struct xen_domctl {
#define XEN_DOMCTL_setvnumainfo 74
#define XEN_DOMCTL_psr_cmt_op75
#define XEN_DOMCTL_monitor_op77
+#define XEN_DOMCTL_soft_reset78
#define XEN_DOMCTL_gdbsx_guestmemio1000
#define XEN_DOMCTL_gdbsx_pausevcpu 1001
#define XEN_DOMCTL_gdbsx_unpausevcpu 1002
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index d810e1c..1120741 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -609,6 +609,8 @@ void domain_shutdown(struct domain *d, u8 reason);
void domain_resume(struct domain *d);
void domain_pause_for_debugger(void);
+int domain_soft_reset(struct domain *d);
+
int vcpu_start_shutdown_deferral(struct vcpu *v);
void vcpu_end_shutdown_deferral(struct vcpu *v);
--
2.4.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 00/11] toolstack-assisted approach to PVHVM guest kexec
This patch series provides x86 PVHVM domains with an ability to perform kexec/kdump-style operations. The list of currently known issues blocking kexec (and why the series is required) is: - Bound event channels. - Registered vcpu_info. - PIRQ/emuirq mappings. - shared_info frame after XENMAPSPACE_shared_info operation. - Active grant mappings. Previously there were several attempts to solve these issues in different ways: - Individual 'shutdown' hypercalls (e.g. VCPUOP_reset_vcpu_info) (we agreed that one 'reset everything' hypercall is better). - Try building new domain reassigning old domain's memory (memory reassignment turned out being too cumbersome). - Toolstack-less 'reset everything' (turned out being impossible because there is not enough knowledge in the hypervisor, e.g. interdomain channels are being set up by the toolstack). This series is a mix of the previously sent 'toolstack-based' and 'reset everything' series. Here are some key points: - No new domain is created. - Domain is asking for soft reset with SCHEDOP_shutdown with SHUTDOWN_soft_reset shutdown reason. - XEN_DOMCTL_soft_reset is being called by the toolstack. - Device model is being restarted. Patches from 'toolstack-based' series: - [PATCH v8 01/11] xen: introduce SHUTDOWN_soft_reset shutdown reason - [PATCH v8 02/11] libxl: support SHUTDOWN_soft_reset shutdown reason (with Ian's ack) - [PATCH v8 03/11] xl: introduce enum domain_restart_type (with Ian's ack) - [PATCH v8 10/11] libxc: add XC_DEVICE_MODEL_SAVE_FILE (with Ian's ack) - [PATCH v8 11/11] (lib)xl: soft reset support (heavily rewritten) Patches from 'reset everything' RFC: - [PATCH v8 04/11] xen: evtchn: make evtchn_reset() ready for soft reset - [PATCH v8 06/11] xen: Introduce XEN_DOMCTL_soft_reset - [PATCH v8 08/11] xen: arch-specific hooks for domain_soft_reset() New patches: - [PATCH v8 05/11] xen: grant_table: implement grant_table_warn_active_grants() - [PATCH v8 07/11] flask: DOMCTL_soft_reset support - [PATCH v8 09/11] libxc: support XEN_DOMCTL_soft_reset operation With regards to active grants. In this series we restart domain's device model, remove it from xenstore and introduce it back. The only 'misbehaving' backend keeping active mapping I currently observe is xenconsoled: currently it has no interface to disconnect from a domain (it just periodically scans all domains to determine if any of them are dead). This is not an issue for us because: - This matches standard domain startup as this grant mapping is being set up by the toolstack. - Guest domain is aware of this special page. grant_table_warn_active_grants() is required to find possible misbehaving backends in future. It can be easily dropped from this series. Some changes are mentioned in individual patches. v7 of the 'toolstack-based approach to pvhvm guest kexec' is available here: http://lists.xenproject.org/archives/html/xen-devel/2015-05/msg03558.html RFC of the 'reset everything approach to PVHVM guest kexec' is available here: http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg00446.html docs/man/xl.cfg.pod.5| 10 ++ tools/flask/policy/policy/modules/xen/xen.if | 2 +- tools/libxc/include/xenctrl.h| 3 + tools/libxc/include/xenguest.h | 2 + tools/libxc/xc_domain.c | 9 ++ tools/libxl/libxl.c | 16 ++- tools/libxl/libxl.h | 12 ++ tools/libxl/libxl_create.c | 181 +++ tools/libxl/libxl_dm.c | 2 +- tools/libxl/libxl_internal.h | 4 + tools/libxl/libxl_types.idl | 4 + tools/libxl/xl.h | 7 ++ tools/libxl/xl_cmdimpl.c | 58 ++--- tools/python/xen/lowlevel/xl/xl.c| 1 + xen/arch/arm/domain.c| 5 + xen/arch/x86/domain.c| 79 xen/arch/x86/hvm/hvm.c | 2 +- xen/common/domain.c | 34 - xen/common/domctl.c | 9 ++ xen/common/event_channel.c | 38 +++--- xen/common/grant_table.c | 31 + xen/common/shutdown.c| 6 + xen/include/asm-x86/hvm/hvm.h| 2 + xen/include/public/domctl.h | 1 + xen/include/public/sched.h | 3 +- xen/include/xen/domain.h | 2 + xen/include/xen/event.h | 3 + xen/include/xen/grant_table.h| 5 + xen/include/xen/sched.h | 2 + xen/xsm/flask/hooks.c| 3 + xen/xsm/flask/policy/access_vectors | 2 + 31 files changed, 470 insertions(+), 68 deletions(-) -- 2.4.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org
[Xen-devel] [PATCH v8 07/11] flask: DOMCTL_soft_reset support
Add new soft_reset vector to domain2 class, add it to create_domain
in the default policy.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
tools/flask/policy/policy/modules/xen/xen.if | 2 +-
xen/xsm/flask/hooks.c| 3 +++
xen/xsm/flask/policy/access_vectors | 2 ++
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/flask/policy/policy/modules/xen/xen.if
b/tools/flask/policy/policy/modules/xen/xen.if
index f4cde11..0dcd620 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -52,7 +52,7 @@ define(`create_domain_common', `
getaffinity setaffinity setvcpuextstate };
allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
- psr_cmt_op };
+ psr_cmt_op soft_reset };
allow $1 $2:security check_context;
allow $1 $2:shadow enable;
allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage
mmuext_op updatemp };
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 6e37d29..0c9a2ed 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -735,6 +735,9 @@ static int flask_domctl(struct domain *d, int cmd)
case XEN_DOMCTL_psr_cmt_op:
return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__PSR_CMT_OP);
+case XEN_DOMCTL_soft_reset:
+return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SOFT_RESET);
+
default:
printk(flask_domctl: Unknown op %d\n, cmd);
return -EPERM;
diff --git a/xen/xsm/flask/policy/access_vectors
b/xen/xsm/flask/policy/access_vectors
index 68284d5..a1bb241 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -224,6 +224,8 @@ class domain2
# XEN_DOMCTL_monitor_op
# XEN_DOMCTL_vm_event_op
vm_event
+# XEN_DOMCTL_soft_reset
+soft_reset
# XENMEM_access_op
mem_access
# XENMEM_paging_op
--
2.4.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 04/11] xen: evtchn: make evtchn_reset() ready for soft reset
We need to close all event channel so the domain performing soft reset
will be able to open them back.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
xen/common/event_channel.c | 38 +++---
xen/include/xen/event.h| 3 +++
2 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 2208de0..894bdf2 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -937,26 +937,19 @@ int evtchn_unmask(unsigned int port)
}
-static long evtchn_reset(evtchn_reset_t *r)
+void evtchn_reset(struct domain *d)
{
-domid_t dom = r-dom;
-struct domain *d;
-int i, rc;
-
-d = rcu_lock_domain_by_any_id(dom);
-if ( d == NULL )
-return -ESRCH;
+unsigned int i;
-rc = xsm_evtchn_reset(XSM_TARGET, current-domain, d);
-if ( rc )
-goto out;
+if ( d != current-domain )
+domain_pause(d);
for ( i = 0; port_is_valid(d, i); i++ )
(void)__evtchn_close(d, i);
spin_lock(d-event_lock);
-if ( (dom == DOMID_SELF) d-evtchn_fifo )
+if ( d-evtchn_fifo )
{
/*
* Guest domain called EVTCHNOP_reset with DOMID_SELF, destroying
@@ -969,12 +962,8 @@ static long evtchn_reset(evtchn_reset_t *r)
spin_unlock(d-event_lock);
-rc = 0;
-
-out:
-rcu_unlock_domain(d);
-
-return rc;
+if ( d != current-domain )
+domain_unpause(d);
}
static long evtchn_set_priority(const struct evtchn_set_priority *set_priority)
@@ -1099,9 +1088,20 @@ long do_event_channel_op(int cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
case EVTCHNOP_reset: {
struct evtchn_reset reset;
+struct domain *d;
+
if ( copy_from_guest(reset, arg, 1) != 0 )
return -EFAULT;
-rc = evtchn_reset(reset);
+
+d = rcu_lock_domain_by_any_id(reset.dom);
+if ( d == NULL )
+return -ESRCH;
+
+rc = xsm_evtchn_reset(XSM_TARGET, current-domain, d);
+if ( !rc )
+evtchn_reset(d);
+
+rcu_unlock_domain(d);
break;
}
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index af923d1..b99e19b 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -126,6 +126,9 @@ void evtchn_check_pollers(struct domain *d, unsigned int
port);
void evtchn_2l_init(struct domain *d);
+/* Close all event channels and reset to 2-level ABI */
+void evtchn_reset(struct domain *d);
+
/*
* Low-level event channel port ops.
*/
--
2.4.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 09/11] libxc: support XEN_DOMCTL_soft_reset operation
Introduce xc_domain_soft_reset() function supporting XEN_DOMCTL_soft_reset.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
tools/libxc/include/xenctrl.h | 3 +++
tools/libxc/xc_domain.c | 9 +
2 files changed, 12 insertions(+)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index d1d2ab3..7aa0e81 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1301,6 +1301,9 @@ int xc_domain_setvnuma(xc_interface *xch,
unsigned int *vcpu_to_vnode,
unsigned int *vnode_to_pnode);
+int xc_domain_soft_reset(xc_interface *xch,
+ uint32_t domid);
+
#if defined(__i386__) || defined(__x86_64__)
/*
* PC BIOS standard E820 types and structure.
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index ce51e69..a59d0b0 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -2452,6 +2452,15 @@ int xc_domain_setvnuma(xc_interface *xch,
return rc;
}
+
+int xc_domain_soft_reset(xc_interface *xch,
+ uint32_t domid)
+{
+DECLARE_DOMCTL;
+domctl.cmd = XEN_DOMCTL_soft_reset;
+domctl.domain = (domid_t)domid;
+return do_domctl(xch, domctl);
+}
/*
* Local variables:
* mode: C
--
2.4.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 05/11] xen: grant_table: implement grant_table_warn_active_grants()
Log first 10 active grants of a domain. This function is going to be used
for soft reset, active grants on this path usually mean misbehaving backends
refusing to release their mappings on shutdown.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
xen/common/grant_table.c | 31 +++
xen/include/xen/grant_table.h | 5 +
2 files changed, 36 insertions(+)
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index db5e5db..c67db28 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -3309,6 +3309,37 @@ gnttab_release_mappings(
}
}
+void grant_table_warn_active_grants(struct domain *d)
+{
+struct grant_table *gt = d-grant_table;
+struct active_grant_entry *act;
+grant_ref_t ref;
+unsigned int nr_active = 0;
+
+read_lock(gt-lock);
+
+for ( ref = 0; ref != nr_grant_entries(gt); ref++ )
+{
+act = active_entry_acquire(gt, ref);
+if ( !act-pin )
+{
+active_entry_release(act);
+continue;
+}
+
+nr_active++;
+if ( nr_active = 10 )
+printk(XENLOG_G_DEBUG Dom%d has an active grant: GFN: %lx
+(MFN: %lx)\n, d-domain_id, act-gfn, act-frame);
+active_entry_release(act);
+}
+
+if ( nr_active 10 )
+printk(XENLOG_G_DEBUG Dom%d has too many (%d) active grants
+to report\n, d-domain_id, nr_active);
+
+read_unlock(gt-lock);
+}
void
grant_table_destroy(
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index 9c7b5a3..54005cc 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -90,6 +90,11 @@ void grant_table_destroy(
struct domain *d);
void grant_table_init_vcpu(struct vcpu *v);
+/*
+ * Check if domain has active grants and log first 10 of them.
+ */
+void grant_table_warn_active_grants(struct domain *d);
+
/* Domain death release of granted mappings of other domains' memory. */
void
gnttab_release_mappings(
--
2.4.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 01/11] xen: introduce SHUTDOWN_soft_reset shutdown reason
This special type of shutdown is supposed to be used by PVHVM guests when they want to perform some sort of kexec/kdump. Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com --- xen/common/shutdown.c | 6 ++ xen/include/public/sched.h | 3 ++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c index 9cfbf7a..03a8641 100644 --- a/xen/common/shutdown.c +++ b/xen/common/shutdown.c @@ -66,6 +66,12 @@ void hwdom_shutdown(u8 reason) machine_restart(0); break; /* not reached */ +case SHUTDOWN_soft_reset: +printk(Hardware domain %d did unsupported soft reset, rebooting.\n, + hardware_domain-domain_id); +machine_restart(0); +break; /* not reached */ + default: printk(Hardware Dom%u shutdown (unknown reason %u): , hardware_domain-domain_id, reason); diff --git a/xen/include/public/sched.h b/xen/include/public/sched.h index 4000ac9..705bc52 100644 --- a/xen/include/public/sched.h +++ b/xen/include/public/sched.h @@ -159,7 +159,8 @@ DEFINE_XEN_GUEST_HANDLE(sched_watchdog_t); #define SHUTDOWN_suspend2 /* Clean up, save suspend info, kill. */ #define SHUTDOWN_crash 3 /* Tell controller we've crashed. */ #define SHUTDOWN_watchdog 4 /* Restart because watchdog time expired. */ -#define SHUTDOWN_MAX4 /* Maximum valid shutdown reason. */ +#define SHUTDOWN_soft_reset 5 /* Domain did soft reset. Clean up and resume.*/ +#define SHUTDOWN_MAX5 /* Maximum valid shutdown reason. */ /* ` } */ #endif /* __XEN_PUBLIC_SCHED_H__ */ -- 2.4.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 08/11] xen: arch-specific hooks for domain_soft_reset()
x86-specific hook cleans up the pirq-emuirq mappings, destroys all ioreq
servers and and replaces the shared_info frame with an empty page to support
subsequent XENMAPSPACE_shared_info call.
ARM-specific hook is a noop for now.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
Changes since 'PATCH RFC' of the 'reset everything' approach to PVHVM guest
kexec:
- Coding style, check get_gfn_query() return value, various minor fixes [Jan
Beulich]
- Do not unpause VCPUs on arch hook failure [Jan Beulich]
---
xen/arch/arm/domain.c | 5 +++
xen/arch/x86/domain.c | 79 +++
xen/arch/x86/hvm/hvm.c| 2 +-
xen/common/domain.c | 5 +++
xen/include/asm-x86/hvm/hvm.h | 2 ++
xen/include/xen/domain.h | 2 ++
6 files changed, 94 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 24b8938..c112afa 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -653,6 +653,11 @@ void arch_domain_unpause(struct domain *d)
{
}
+int arch_domain_soft_reset(struct domain *d)
+{
+return 0;
+}
+
static int is_guest_pv32_psr(uint32_t psr)
{
switch (psr PSR_MODE_MASK)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 0363650..2dd0e0d 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -682,6 +682,85 @@ void arch_domain_unpause(struct domain *d)
viridian_time_ref_count_thaw(d);
}
+int arch_domain_soft_reset(struct domain *d)
+{
+struct page_info *page = virt_to_page(d-shared_info), *new_page;
+int ret = 0;
+struct domain *owner;
+unsigned long mfn, mfn_new, gfn;
+p2m_type_t p2mt;
+unsigned int i;
+
+/* Soft reset is supported for HVM domains only */
+if ( !is_hvm_domain(d) )
+return -EINVAL;
+
+hvm_destroy_all_ioreq_servers(d);
+
+spin_lock(d-event_lock);
+for ( i = 1; i d-nr_pirqs ; i ++ )
+if ( domain_pirq_to_emuirq(d, i) != IRQ_UNBOUND )
+{
+ret = unmap_domain_pirq_emuirq(d, i);
+if ( ret )
+break;
+}
+spin_unlock(d-event_lock);
+
+if ( ret )
+return ret;
+
+/*
+ * shared_info page needs to be replaced with a new page, otherwise we
+ * will get a hole if the domain does XENMAPSPACE_shared_info
+ */
+
+owner = page_get_owner_and_reference(page);
+/* If shared_info page wasn't mounted, we do not need to replace it */
+if ( owner != d )
+goto exit_put_page;
+
+mfn = page_to_mfn(page);
+if ( !mfn_valid(mfn) )
+{
+printk(XENLOG_G_ERR Dom%d's shared_info page points to invalid MFN\n,
+ d-domain_id);
+ret = -EINVAL;
+goto exit_put_page;
+}
+
+gfn = mfn_to_gmfn(d, mfn);
+if ( mfn_x(get_gfn_query(d, gfn, p2mt)) == INVALID_MFN )
+{
+printk(XENLOG_G_ERR Failed to get Dom%d's shared_info GFN (%lx)\n,
+ d-domain_id, gfn);
+ret = -EINVAL;
+goto exit_put_page;
+}
+
+new_page = alloc_domheap_page(d, 0);
+if ( !new_page )
+{
+printk(XENLOG_G_ERR Failed to alloc a page to replace
+Dom%d's shared_info frame %lx\n, d-domain_id, gfn);
+ret = -ENOMEM;
+goto exit_put_gfn;
+}
+mfn_new = page_to_mfn(new_page);
+guest_physmap_remove_page(d, gfn, mfn, 0);
+
+ret = guest_physmap_add_page(d, gfn, mfn_new, 0);
+if ( ret )
+printk(XENLOG_G_ERR Failed to add a page to replace
+Dom%d's shared_info frame %lx\n, d-domain_id, gfn);
+ exit_put_gfn:
+put_gfn(d, gfn);
+ exit_put_page:
+put_page(page);
+
+return ret;
+}
+
unsigned long pv_guest_cr4_fixup(const struct vcpu *v, unsigned long guest_cr4)
{
unsigned long hv_cr4_mask, hv_cr4 = real_cr4_to_pv_guest_cr4(read_cr4());
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index d5e5242..506a7be 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1319,7 +1319,7 @@ static void hvm_all_ioreq_servers_remove_vcpu(struct
domain *d, struct vcpu *v)
spin_unlock(d-arch.hvm_domain.ioreq_server.lock);
}
-static void hvm_destroy_all_ioreq_servers(struct domain *d)
+void hvm_destroy_all_ioreq_servers(struct domain *d)
{
struct hvm_ioreq_server *s, *next;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index ade80ff..cd5ed42 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1013,6 +1013,7 @@ int domain_unpause_by_systemcontroller(struct domain *d)
int domain_soft_reset(struct domain *d)
{
struct vcpu *v;
+int ret;
for_each_vcpu ( d, v )
if ( !v-paused_for_shutdown )
@@ -1025,6 +1026,10 @@ int domain_soft_reset(struct domain *d)
for_each_vcpu ( d, v )
unmap_vcpu_info(v);
+ret = arch_domain_soft_reset(d);
+if (ret)
+return ret;
+
domain_resume(d);
return 0;
diff --git a/xen/include/asm-x86/hvm/hvm.h
Re: [Xen-devel] [PATCH 4/5] Change x86 paging/sharing to 'Orphaned'.
That's indeed sad. I'm actively using the sharing system in my tools and have a couple branches laying around for improving it, like batch memsharing for example to support flash-cloning. Now that it's orphaned, how would I go about merging these into mainline? I'm not yet confident enough in my understanding of the whole sharing system to volunteer as maintainer and my tool-side stuff is also very experimental.. On Tue, Jun 23, 2015 at 12:56 PM, Andres Lagar Cavilla and...@lagarcavilla.org wrote: On Tue, Jun 23, 2015 at 6:22 AM, Tim Deegan t...@xen.org wrote: This code now has no active maintainers, as neither Andres nor I can commit the time. Signed-off-by: Tim Deegan t...@xen.org Cc: Andres Lagar-Cavilla and...@lagarcavilla.org Wistfully, Acked-by: Andres Lagar-Cavilla and...@lagarcavilla.org --- MAINTAINERS | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 7f0e96e..d1bec17 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -367,9 +367,7 @@ S: Supported F: xen/arch/x86/mm/ X86 MEMORY SHARING AND PAGING -M: Andres Lagar-Cavilla and...@lagarcavilla.org -M: Tim Deegan t...@xen.org -S: Supported +S: Orphaned F: xen/arch/x86/mm/mem_sharing.c F: xen/arch/x86/mm/mem_paging.c F: tools/memshr -- 2.3.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel -- [image: www.novetta.com] Tamas K Lengyel Senior Security Researcher 7921 Jones Branch Drive McLean VA 22102 Email tleng...@novetta.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH v3 08/18] xen/arm: vITS: Add virtual ITS driver
Hi Vijay,
On 22/06/15 13:01, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
This patch introduces virtual ITS driver with following
functionality
- Introduces helper functions to manage device table and
ITT table in guest memory
- Helper function to handle virtual ITS devices assigned
to domain
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/Makefile |1 +
xen/arch/arm/vgic-v3-its.c| 266
+
xen/include/asm-arm/domain.h |2 +
xen/include/asm-arm/gic-its.h | 49
4 files changed, 318 insertions(+)
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 1821ed2..8590846 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -33,6 +33,7 @@ obj-y += traps.o
obj-y += vgic.o vgic-v2.o
obj-$(CONFIG_ARM_64) += vgic-v3.o
obj-$(CONFIG_ARM_64) += gic-v3-its.o
+obj-$(CONFIG_ARM_64) += vgic-v3-its.o
I would prefer to the vgic-v3-its code not compiled until you finish to
implement it rather than having every function exported while it should
be static.
obj-y += vtimer.o
obj-y += vuart.o
obj-y += hvm.o
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
new file mode 100644
index 000..ea52a87
--- /dev/null
+++ b/xen/arch/arm/vgic-v3-its.c
[..]
+/* GITS register definitions */
+#define VITS_GITS_TYPER_HCC (0xffU 24)
Where does this value comes from? The number of supported collection
should be the maximum number of VCPUs supported by the domain.
Note that the hardware can only hold 256 collections, all the other
requires provisioning. But it's fine for now, although a BUILD_BUG_ON in
the vGIC code would be nice.
+#define VITS_GITS_TYPER_PTA_SHIFT (19)
+#define VITS_GITS_DEV_BITS(0x14U 13)
+#define VITS_GITS_ID_BITS (0x13U 8)
Where do those values come from? This needs at least to come from the
hardware GIC configuration if we plan to only support DOM0 for now.
+#define VITS_GITS_ITT_SIZE(0x7U 4)
The name is misleading, this is not the size of the ITT but the value to
store in the GITS_TYPER register.
+#define VITS_GITS_DISTRIBUTED (0x1U 3)
Why? This bit is implementation defined in the spec.
+#define VITS_GITS_PLPIS (0x1U 0)
For all these defines, why do you hardcode the shift rather using
GITS_TYPER_* you provide in patch #5? It would make the code more easier
to understand.
+
+/* GITS_PIDRn register values for ARM implementations */
+#define GITS_PIDR0_VAL(0x94)
+#define GITS_PIDR1_VAL(0xb4)
+#define GITS_PIDR2_VAL(0x3b)
+#define GITS_PIDR3_VAL(0x00)
+#define GITS_PIDR4_VAL(0x04)
+
+// #define DEBUG_ITS
+
+#ifdef DEBUG_ITS
+# define DPRINTK(fmt, args...) dprintk(XENLOG_DEBUG, fmt, ##args)
+#else
+# define DPRINTK(fmt, args...) do {} while ( 0 )
+#endif
+
+#ifdef DEBUG_ITS
+static void dump_cmd(its_cmd_block *cmd)
+{
+printk(CMD[0] = 0x%lx CMD[1] = 0x%lx CMD[2] = 0x%lx CMD[3] = 0x%lx\n,
+ cmd-raw_cmd[0], cmd-raw_cmd[1], cmd-raw_cmd[2],
cmd-raw_cmd[3]);
+}
+#endif
+
+/* ITS device table helper functions */
+int vits_vdevice_entry(struct domain *d, uint32_t dev_id,
+ struct vdevice_table *entry, int set)
Any functions not exported should be static. I won't repeat for all the
others within this file.
Also, please use bool_t for set.
+{
+uint64_t offset;
+paddr_t dt_entry;
+struct page_info *page;
+p2m_type_t p2mt;
+void *p;
+
+offset = dev_id * sizeof(struct vdevice_table);
+if ( offset d-arch.vits-dt_size )
If you gonna let the guest to write deci
+{
+dprintk(XENLOG_G_ERR,
+vITS:d%dv%d: Out of range offset 0x%lx id 0x%x size
0x%lx\n,
You can use %pv to print the domain/vcpuid (see an example in vgic-v3.c).
Also, all the value can be printed in decimal because we have to use
them for addition...
+d-domain_id, current-vcpu_id, offset, dev_id,
Please don't mix d and current.
+d-arch.vits-dt_size);
+return -EINVAL;
+}
+
+dt_entry = d-arch.vits-dt_ipa + offset;
+
+page = get_page_from_gfn(d, paddr_to_pfn(dt_entry), p2mt, P2M_ALLOC);
+if ( !page )
+{
+dprintk(XENLOG_G_ERR, vITS:d%dv%d Failed to get VITT device
table\n,
+d-domain_id, current-vcpu_id);
+return -EINVAL;
+}
+
+if ( !p2m_is_ram(p2mt) )
+{
+put_page(page);
+dprintk(XENLOG_G_ERR, vITS:d%dv%d with wrong attributes\n,
+d-domain_id, current-vcpu_id);
+return -EINVAL;
+return -EINVAL;
Duplicate return -EINVAL.
+}
+
+p = __map_domain_page(page);
+/* Offset within the mapped page */
+offset = dt_entry (PAGE_SIZE - 1);
+
+if ( set )
+memcpy(p + offset, entry,
[Xen-devel] [PATCH v2] Revert libxl_set_memory_target: retain the same maxmem offset on top of the current target
This reverts commit 0c029c4da2169159064568ef4fea862a5d2cd84a.
A new memory model that allows QEMU to bump memory behind libxl's back
was merged a few months ago. We didn't fully understand the
repercussions back then. Now it breaks migration and becomes blocker of
4.6 release.
It's better to restore to original behaviour at this stage of the
release cycle, that would put us in a position no worse than before, so
the release is unblocked.
The said function is still racy after reverting these two patches.
Making domain memory state consistent requires a bit more work. Separate
patch(es) will be sent out to deal with that problem.
Fix up conflicts with f5b43e95 (libxl: fix xl mem-set regression from
0c029c4da2).
Signed-off-by: Wei Liu wei.l...@citrix.com
---
tools/libxl/libxl.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index d86ea62..cfc2623 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4742,16 +4742,11 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t
domid,
uint32_t current_max_memkb = 0;
char *memmax, *endptr, *videoram_s = NULL, *target = NULL;
char *dompath = libxl__xs_get_dompath(gc, domid);
+xc_domaininfo_t info;
libxl_dominfo ptr;
char *uuid;
xs_transaction_t t;
-libxl_dominfo_init(ptr);
-if (libxl_domain_info(ctx, ptr, domid) 0)
-goto out_no_transaction;
-
-uuid = libxl__uuid2string(gc, ptr.uuid);
-
retry_transaction:
t = xs_transaction_start(ctx-xsh);
@@ -4827,12 +4822,13 @@ retry_transaction:
}
if (enforce) {
-memorykb = ptr.max_memkb - current_target_memkb + new_target_memkb;
-rc = xc_domain_setmaxmem(ctx-xch, domid, memorykb);
+memorykb = new_target_memkb + videoram;
+rc = xc_domain_setmaxmem(ctx-xch, domid, memorykb +
+LIBXL_MAXMEM_CONSTANT);
if (rc != 0) {
LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
xc_domain_setmaxmem domid=%u memkb=%PRIu64 failed
-rc=%d\n, domid, memorykb, rc);
+rc=%d\n, domid, memorykb + LIBXL_MAXMEM_CONSTANT, rc);
abort_transaction = 1;
goto out;
}
@@ -4851,9 +4847,18 @@ retry_transaction:
libxl__xs_write(gc, t, libxl__sprintf(gc, %s/memory/target,
dompath), %PRIu32, new_target_memkb);
+rc = xc_domain_getinfolist(ctx-xch, domid, 1, info);
+if (rc != 1 || info.domain != domid) {
+abort_transaction = 1;
+goto out;
+}
+libxl_dominfo_init(ptr);
+xcinfo2xlinfo(ctx, info, ptr);
+uuid = libxl__uuid2string(gc, ptr.uuid);
libxl__xs_write(gc, t, libxl__sprintf(gc, /vm/%s/memory, uuid),
%PRIu32, new_target_memkb / 1024);
+libxl_dominfo_dispose(ptr);
out:
if (!xs_transaction_end(ctx-xsh, t, abort_transaction)
@@ -4862,7 +4867,6 @@ out:
goto retry_transaction;
out_no_transaction:
-libxl_dominfo_dispose(ptr);
GC_FREE;
return rc;
}
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 03/11] xl: introduce enum domain_restart_type
As a preparation before adding new restart type (soft reset) put all
restart types into an enum.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
Acked-by: Ian Campbell ian.campb...@citrix.com
---
Changes since v7:
- s,restarter,restarted, [Ian Campbell]
---
tools/libxl/xl.h | 6 ++
tools/libxl/xl_cmdimpl.c | 23 ++-
2 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 5bc138c..374680c 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -186,6 +186,12 @@ enum output_format {
};
extern enum output_format default_output_format;
+typedef enum {
+DOMAIN_RESTART_NONE = 0, /* No domain restart */
+DOMAIN_RESTART_NORMAL, /* Domain should be restarted */
+DOMAIN_RESTART_RENAME, /* Domain should be renamed and restarted */
+} domain_restart_type;
+
extern void printf_info_sexp(int domid, libxl_domain_config *d_config, FILE
*fh);
#define XL_GLOBAL_CONFIG XEN_CONFIG_DIR /xl.conf
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 7247cf1..32217fa 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2283,15 +2283,12 @@ static void reload_domain_config(uint32_t domid,
}
}
-/* Returns 1 if domain should be restarted,
- * 2 if domain should be renamed then restarted, or 0
- * Can update r_domid if domain is destroyed etc */
-static int handle_domain_death(uint32_t *r_domid,
- libxl_event *event,
- libxl_domain_config *d_config)
-
+/* Can update r_domid if domain is destroyed */
+static domain_restart_type handle_domain_death(uint32_t *r_domid,
+ libxl_event *event,
+ libxl_domain_config *d_config)
{
-int restart = 0;
+domain_restart_type restart = DOMAIN_RESTART_NONE;
libxl_action_on_shutdown action;
switch (event-u.domain_shutdown.shutdown_reason) {
@@ -2346,12 +2343,12 @@ static int handle_domain_death(uint32_t *r_domid,
case LIBXL_ACTION_ON_SHUTDOWN_RESTART_RENAME:
reload_domain_config(*r_domid, d_config);
-restart = 2;
+restart = DOMAIN_RESTART_RENAME;
break;
case LIBXL_ACTION_ON_SHUTDOWN_RESTART:
reload_domain_config(*r_domid, d_config);
-restart = 1;
+restart = DOMAIN_RESTART_NORMAL;
/* fall-through */
case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
LOG(Domain %d needs to be cleaned up: destroying the domain,
@@ -2799,7 +2796,7 @@ start:
event-u.domain_shutdown.shutdown_reason,
event-u.domain_shutdown.shutdown_reason);
switch (handle_domain_death(domid, event, d_config)) {
-case 2:
+case DOMAIN_RESTART_RENAME:
if (!preserve_domain(domid, event, d_config)) {
/* If we fail then exit leaving the old domain in place. */
ret = -1;
@@ -2807,7 +2804,7 @@ start:
}
/* Otherwise fall through and restart. */
-case 1:
+case DOMAIN_RESTART_NORMAL:
libxl_event_free(ctx, event);
libxl_evdisable_domain_death(ctx, deathw);
deathw = NULL;
@@ -2843,7 +2840,7 @@ start:
sleep(2);
goto start;
-case 0:
+case DOMAIN_RESTART_NONE:
LOG(Done. Exiting now);
libxl_event_free(ctx, event);
ret = 0;
--
2.4.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/3] x86: drop is_pv_32on64_domain()
On 06/23/2015 04:19 PM, Jan Beulich wrote:
... as being identical to is_pv_32bit_domain() after the x86-32
removal.
In a few cases this includes no longer open-coding is_pv_32bit_vcpu().
Signed-off-by: Jan Beulich jbeul...@suse.com
Reviewed-by: George Dunlap george.dun...@eu.citrix.com
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -367,7 +367,7 @@ int switch_native(struct domain *d)
if ( !may_switch_mode(d) )
return -EACCES;
-if ( !is_pv_32on64_domain(d) )
+if ( !is_pv_32bit_domain(d) )
return 0;
d-arch.is_32bit_pv = d-arch.has_32bit_shinfo = 0;
@@ -392,7 +392,7 @@ int switch_compat(struct domain *d)
if ( !may_switch_mode(d) )
return -EACCES;
-if ( is_pv_32on64_domain(d) )
+if ( is_pv_32bit_domain(d) )
return 0;
d-arch.is_32bit_pv = d-arch.has_32bit_shinfo = 1;
@@ -481,7 +481,7 @@ int vcpu_initialise(struct vcpu *v)
v-arch.pv_vcpu.ctrlreg[4] = real_cr4_to_pv_guest_cr4(mmu_cr4_features);
-rc = is_pv_32on64_domain(d) ? setup_compat_l4(v) : 0;
+rc = is_pv_32bit_domain(d) ? setup_compat_l4(v) : 0;
done:
if ( rc )
{
@@ -689,7 +689,7 @@ unsigned long pv_guest_cr4_fixup(const s
hv_cr4_mask = ~X86_CR4_TSD;
if ( cpu_has_de )
hv_cr4_mask = ~X86_CR4_DE;
-if ( cpu_has_fsgsbase !is_pv_32bit_domain(v-domain) )
+if ( cpu_has_fsgsbase !is_pv_32bit_vcpu(v) )
hv_cr4_mask = ~X86_CR4_FSGSBASE;
if ( cpu_has_xsave )
hv_cr4_mask = ~X86_CR4_OSXSAVE;
@@ -721,7 +721,7 @@ int arch_set_info_guest(
/* The context is a compat-mode one if the target domain is compat-mode;
* we expect the tools to DTRT even in compat-mode callers. */
-compat = is_pv_32on64_domain(d);
+compat = is_pv_32bit_domain(d);
#define c(fld) (compat ? (c.cmp-fld) : (c.nat-fld))
flags = c(flags);
@@ -1195,7 +1195,7 @@ static void load_segments(struct vcpu *n
all_segs_okay = loadsegment(gs, uregs-gs);
}
-if ( !is_pv_32on64_domain(n-domain) )
+if ( !is_pv_32bit_vcpu(n) )
{
/* This can only be non-zero if selector is NULL. */
if ( n-arch.pv_vcpu.fs_base )
@@ -1224,7 +1224,7 @@ static void load_segments(struct vcpu *n
(unsigned long *)pv-kernel_sp;
unsigned long cs_and_mask, rflags;
-if ( is_pv_32on64_domain(n-domain) )
+if ( is_pv_32bit_vcpu(n) )
{
unsigned int *esp = ring_1(regs) ?
(unsigned int *)regs-rsp :
@@ -1340,7 +1340,7 @@ static void save_segments(struct vcpu *v
if ( regs-es )
dirty_segment_mask |= DIRTY_ES;
-if ( regs-fs || is_pv_32on64_domain(v-domain) )
+if ( regs-fs || is_pv_32bit_vcpu(v) )
{
dirty_segment_mask |= DIRTY_FS;
v-arch.pv_vcpu.fs_base = 0; /* != 0 selector kills fs_base */
@@ -1350,7 +1350,7 @@ static void save_segments(struct vcpu *v
dirty_segment_mask |= DIRTY_FS_BASE;
}
-if ( regs-gs || is_pv_32on64_domain(v-domain) )
+if ( regs-gs || is_pv_32bit_vcpu(v) )
{
dirty_segment_mask |= DIRTY_GS;
v-arch.pv_vcpu.gs_base_user = 0; /* != 0 selector kills
gs_base_user */
@@ -1483,8 +1483,8 @@ static void __context_switch(void)
psr_ctxt_switch_to(nd);
-gdt = !is_pv_32on64_domain(nd) ? per_cpu(gdt_table, cpu) :
- per_cpu(compat_gdt_table, cpu);
+gdt = !is_pv_32bit_domain(nd) ? per_cpu(gdt_table, cpu) :
+per_cpu(compat_gdt_table, cpu);
if ( need_full_gdt(nd) )
{
unsigned long mfn = virt_to_mfn(gdt);
@@ -1568,7 +1568,7 @@ void context_switch(struct vcpu *prev, s
if ( is_pv_domain(nextd)
(is_idle_domain(prevd) ||
has_hvm_container_domain(prevd) ||
- is_pv_32on64_domain(prevd) != is_pv_32on64_domain(nextd)) )
+ is_pv_32bit_domain(prevd) != is_pv_32bit_domain(nextd)) )
{
uint64_t efer = read_efer();
if ( !(efer EFER_SCE) )
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -293,7 +293,7 @@ static unsigned long __init compute_dom0
avail -= (d-max_vcpus - 1UL)
get_order_from_bytes(sizeof(struct vcpu));
/* ...and compat_l4's, if needed. */
-if ( is_pv_32on64_domain(d) )
+if ( is_pv_32bit_domain(d) )
avail -= d-max_vcpus - 1;
/* Reserve memory for iommu_dom0_init() (rough estimate). */
@@ -608,7 +608,7 @@ static __init void dom0_update_physmap(s
BUG_ON(rc);
return;
}
-if ( !is_pv_32on64_domain(d) )
+if ( !is_pv_32bit_domain(d) )
((unsigned long *)vphysmap_s)[pfn] = mfn;
else
((unsigned int *)vphysmap_s)[pfn] = mfn;
@@ -718,7 +718,7 @@ static __init void
Re: [Xen-devel] [PATCH] x86/arm/mm: use gfn instead of pfn in p2m_get_mem_access/p2m_set_mem_access
Jan Beulich jbeul...@suse.com writes:
On 26.05.15 at 15:32, vkuzn...@redhat.com wrote:
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1709,9 +1709,9 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla,
const struct npfec npfec)
/*
* Set access type for a region of pfns.
- * If start_pfn == -1ul, sets the default access type.
+ * If start_gfn == -1ul, sets the default access type.
*/
-long p2m_set_mem_access(struct domain *d, unsigned long pfn, uint32_t nr,
+long p2m_set_mem_access(struct domain *d, unsigned long start_gfn, uint32_t
nr,
uint32_t start, uint32_t mask, xenmem_access_t
access)
{
struct p2m_domain *p2m = p2m_get_hostp2m(d);
@@ -1752,14 +1752,15 @@ long p2m_set_mem_access(struct domain *d, unsigned
long pfn, uint32_t nr,
p2m-mem_access_enabled = true;
/* If request to set default access. */
-if ( pfn == ~0ul )
+if ( start_gfn == ~0ul )
{
p2m-default_access = a;
return 0;
}
rc = apply_p2m_changes(d, MEMACCESS,
- pfn_to_paddr(pfn+start), pfn_to_paddr(pfn+nr),
+ pfn_to_paddr(start_gfn + start),
Particularly due to this expression I'm not really happy about the
start_ prefix that you're adding here, but I'll let the maintainers
of the respective pieces of code decide if they're happy with it.
Sorry for the ping but it has been almost one month...
--
Vitaly
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 04/18] x86/hvm: make sure translated MMIO reads or writes fall within a page
-Original Message- From: Jan Beulich [mailto:jbeul...@suse.com] Sent: 23 June 2015 17:22 To: Paul Durrant Cc: Andrew Cooper; xen-de...@lists.xenproject.org; Keir (Xen.org) Subject: RE: [PATCH v3 04/18] x86/hvm: make sure translated MMIO reads or writes fall within a page On 23.06.15 at 18:13, paul.durr...@citrix.com wrote: -Original Message- From: Jan Beulich [mailto:jbeul...@suse.com] Sent: 23 June 2015 16:53 To: Paul Durrant Cc: Andrew Cooper; xen-de...@lists.xenproject.org; Keir (Xen.org) Subject: Re: [PATCH v3 04/18] x86/hvm: make sure translated MMIO reads or writes fall within a page On 23.06.15 at 12:39, paul.durr...@citrix.com wrote: ...otherwise they will simply carry on to the next page using a normal linear-to-phys translation. And what's wrong about this? Is it the right thing to do? It seems wrong. But why? Which way we obtain a linear-to-phys translation doesn't matter. --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -586,7 +586,6 @@ static int __hvmemul_read( p_data); if ( rc != X86EMUL_OKAY || bytes == chunk ) return rc; -addr += chunk; off += chunk; gpa += chunk; p_data += chunk; @@ -594,6 +593,8 @@ static int __hvmemul_read( if ( bytes chunk ) chunk = bytes; } + +return X86EMUL_UNHANDLEABLE; } All the loop above does is leverage that we don't need to do a translation, as we already know the physical address. Continuing if the access crosses a page boundary is not wrong at all afaict. In what circumstances would you expect this to happen. My cscope showed up handle_mmio_with_translation() being called by the shadow code and nested page fault code. The nested code does not look like it expects the I/O to cross a page boundary. Particularly it appears to do checks on the gpa without considering the possibility that the I/O may spill on to a subsequent page. Similarly the shadow code appears to do a va to gpa lookup assuming again that the translation is valid for the whole I/O. Taking specific examples of current callers is not ideal. The code should cope with any (valid) caller, i.e. with any memory operand a valid instruction can have. And indeed I'd expect the calls from hvm_hap_nested_page_fault() to handle_mmio() to also have the potential to reach here (for arbitrary instructions accessing MMIO memory). I'm willing to admit that I only have a very basic knowledge of the code in this area but, on the face of it, just walking onto the next linear address after translation does not seem like it's the right thing to do. That's how instructions work - they simply do another page translation if a memory access crosses a page boundary. Ok. If you believe it's the right thing to do, I'm happy to drop this patch out of the series. I'll send v4 tomorrow. Paul Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PULL 0/5] xen-220615
On 23 June 2015 at 17:19, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: On Tue, 23 Jun 2015, Peter Maydell wrote: I have a bit in my pull-request-creation script that automatically checks that every commit has my signoff, to avoid this kind of mistake: https://git.linaro.org/people/peter.maydell/misc-scripts.git/blob/HEAD:/make-pullreq#l98 Sorry. I noticed that this is the second time that I make this mistake. Part of the problem is that in other communities (Linux, Xen Project), maintainers are not required to add their SOB if they don't modify the patch. Interesting. I thought QEMU's process on this was basically the same as Linux's, which says things like The Signed-off-by: tag indicates that the signer was involved in the development of the patch, or that he/she was in the patch's delivery path. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#n394 which I take to mean that submaintainers add s-o-b lines. Here is my third try: git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-220615-3 Applied this version, thanks. -- PMM ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-4.2-testing test] 58817: FAIL [and 2 more messages]
On Tue, 2015-06-23 at 16:50 +0100, Ian Jackson wrote:
And with that - will it ever clear?
Not unless we get lucky and that guest-stop passes.
The guest-stop is (now) an allowable fail. After discussing this with
Ian f2f it seems that he underlying issue is that the allowable-ness
check is done after the heisenbug detection, i.e. it is never reached
(which is wrong).
Given that we decided we should force push it, which I've just done.
version targeted for testing:
xen 97134c441d6d81ba0d7cdcfdc4d8315115b99dce
baseline version:
xen 21a8344ca38a2797a13b4bf57031b6f49ae12ccb
osstest@osstest:~/branches/for-xen-4.2-testing.git$
OSSTEST_CONFIG=production-config ./ap-push xen-4.2-testing
97134c441d6d81ba0d7cdcfdc4d8315115b99dce
+ branch=xen-4.2-testing
+ revision=97134c441d6d81ba0d7cdcfdc4d8315115b99dce
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-4.2-testing
97134c441d6d81ba0d7cdcfdc4d8315115b99dce
+ branch=xen-4.2-testing
+ revision=97134c441d6d81ba0d7cdcfdc4d8315115b99dce
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case $branch in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-4.2-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{OsstestUpstream} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{GitCacheProxy} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ :
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-4.2-testing
+
Re: [Xen-devel] [PATCH 1/2 linux-next] Revert ufs: fix deadlocks introduced by sb mutex merge
On Sat 20-06-15 00:07:39, Al Viro wrote: On Wed, Jun 17, 2015 at 09:31:16PM +0100, Al Viro wrote: On Wed, Jun 17, 2015 at 10:57:15AM +0200, Jan Kara wrote: Joy... Folks, is anybody actively maintaining fs/ufs these days? Looking into the changelog there wasn't anyone seriously looking into UFS for at least 5-6 years... Fabian did some cleanups recently but they were mostly cosmetic. So I don't think it's really maintained. OTOH clearly there are some users since occasionally someone comes with a bug report. Welcome to the world where we have ~50 on disk / network filesystems :-| FWIW, I've a partial rewrite of that area (completely untested, etc.) in vfs.git#ufs; it's still in progress, but hopefully it'll be done by tomorrow. Basically, it switches the sucker to locking scheme similar to ext2 (modulo seqlock instead of rwlock for protection of block pointers, having to be more careful due to 64bit assignments not being atomic and being unable to fall back to -truncate_mutex in case of race on the read side) and starts cleaning the hell out of the truncate (and eventually create side of get_block as well). As far as I can see, the root of the problems with that sucker is the misplaced handling of tail-packing logics. That had ballooned into a lot of convoluted codepaths ;-/ I'm not blaming Evgeniy - it *is* painful to massage into saner shape and the damn thing kept missing cleanups that were done to similar filesystems due to that... One thing I'm somewhat unhappy about in what Evgeniy had done is dealing with UFS vs. UFS2 differences at such a low level. Sure, the way we did endianness handling in there provoked exactly that, but it might have been better to go the other way round; see e.g. fs/minix/itree*.c for opposite approach. All this stuff is currently completely untested; I'll be using generic parts of xfstests for beating it up, but any assistance would be welcome. Note: all testing I'll be realistically able to do will be for FreeBSD UFS variants - I don't have Solaris left on any boxen, to start with... FWIW, I've got to one bloody unpleasant part of UFS we'd never managed to get right and it seems that I have a potential solution. Problem: UFS has larger-than-page allocation units. And when we allocate a block in a hole, we *must* zero the whole thing out. The trouble being, we notice that inside writepage(), where we are already holding a lock on our page and where we can't lock other pages without risking a deadlock. What's more, as soon as we'd inserted a reference to that block into inode, we are open to readpage on another page backed by the same block coming and seeing a normal mapped area. So UFS block allocator ends up zeroing them out via _buffer_ cache, waiting for writes to finish before returning the block to caller. It doesn't wait for metadata blocks (they are accessed via buffer cache), but for data we end up with zeroes being written to disk, no matter what. That works, but it obviously hurts the performance. Badly. Writes into a hole are relatively rare, but the same thing hurts normal sequential writes to the end of file, which is not rare at all. How about the following approach: * Let allocation of data block at the EOF return the sucker without writing zeroes out. * Let -write_iter() check if it's about to create a hole at the (current) EOF. In such case start with writing zeroes (in normal fashion, via -begin_write()/memset()/-end_write() through the page cache) from the EOF to block boundary (or beginning of the area we were going to write to, whichever's closer). Then proceed in normal fashion. Incidentally, it will deal with tail unpacking for free. * Do the same upon extending truncate. Does anybody see holes in that? readpage() crossing the EOF isn't a problem - it will not even attempt to map past the current -i_size and will zero the page tail out just fine. We get junk past the EOF on disk, but we zero it out (or overwrite with our data) before increasing -i_size. Dealing with sparse files is also possible (taking allocations from -writepage() to -page_mkwrite(), where we are not holding a page lock and thus can grab all affected pages), but it would be bigger, trickier and benefit only a relatively rare case. Comments? Looks good to me. BTW also ext4 (with BIGALLOC feature) and OCFS2 can have block allocation unit (called cluster) larger than page size. However the block size of both filesystems is still = page size. So at least ext4 handles fun with partially initialized clusters by just marking parts of the cluster as uninitialized in the extent tree. But the code is still pretty messy to be honest. Honza -- Jan Kara j...@suse.cz SUSE Labs, CR ___ Xen-devel mailing list
[Xen-devel] [PATCH OSSTEST 1/2] mg-debian-installer-update: Print the correct value for TftpDiVersion
That is, the date without the suite suffix. Signed-off-by: Ian Campbell ian.campb...@citrix.com --- mg-debian-installer-update | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/mg-debian-installer-update b/mg-debian-installer-update index ba2fdc4..59f05ec 100755 --- a/mg-debian-installer-update +++ b/mg-debian-installer-update @@ -68,8 +68,8 @@ esac pfile=$sbase/non-free/binary-$arch/Packages.gz dstroot=`getconfig TftpPath`/`getconfig TftpDiBase`/ -date=`date +%Y-%m-%d`-$suite -dst=$arch/$date +date=`date +%Y-%m-%d` +dst=$arch/$date-$suite cd $dstroot mkdir -p $dst @@ -197,5 +197,5 @@ rm Packages.gz #ln -s $date current.new #mv -Tf current.new current -echo $date -echo 2 downloaded $dstroot/$arch/$date +echo New TftpDiVersion: $date +echo 2 downloaded $dstroot/$dst -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 09/12] x86/altp2m: add remaining support routines.
On 06/23/2015 11:15 AM, Lengyel, Tamas wrote:
On Mon, Jun 22, 2015 at 2:56 PM, Ed White edmund.h.wh...@intel.com wrote:
Add the remaining routines required to support enabling the alternate
p2m functionality.
Signed-off-by: Ed White edmund.h.wh...@intel.com
---
xen/arch/x86/hvm/hvm.c | 60 +-
xen/arch/x86/mm/hap/Makefile| 1 +
xen/arch/x86/mm/hap/altp2m_hap.c| 103 +
xen/arch/x86/mm/p2m-ept.c | 3 +
xen/arch/x86/mm/p2m.c | 405
xen/include/asm-x86/hvm/altp2mhvm.h | 4 +
xen/include/asm-x86/p2m.h | 33 +++
7 files changed, 601 insertions(+), 8 deletions(-)
create mode 100644 xen/arch/x86/mm/hap/altp2m_hap.c
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index d75c12d..b758ee1 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2786,10 +2786,11 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
unsigned long gla,
p2m_access_t p2ma;
mfn_t mfn;
struct vcpu *v = current;
-struct p2m_domain *p2m;
+struct p2m_domain *p2m, *hostp2m;
int rc, fall_through = 0, paged = 0;
int sharing_enomem = 0;
vm_event_request_t *req_ptr = NULL;
+int altp2m_active = 0;
/* On Nested Virtualization, walk the guest page table.
* If this succeeds, all is fine.
@@ -2845,15 +2846,33 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
unsigned long gla,
{
if ( !handle_mmio_with_translation(gla, gpa PAGE_SHIFT, npfec)
)
hvm_inject_hw_exception(TRAP_gp_fault, 0);
-rc = 1;
-goto out;
+return 1;
}
-p2m = p2m_get_hostp2m(v-domain);
-mfn = get_gfn_type_access(p2m, gfn, p2mt, p2ma,
+altp2m_active = altp2mhvm_active(v-domain);
+
+/* Take a lock on the host p2m speculatively, to avoid potential
+ * locking order problems later and to handle unshare etc.
+ */
+hostp2m = p2m_get_hostp2m(v-domain);
+mfn = get_gfn_type_access(hostp2m, gfn, p2mt, p2ma,
P2M_ALLOC | (npfec.write_access ?
P2M_UNSHARE : 0),
NULL);
+if ( altp2m_active )
+{
+if ( altp2mhvm_hap_nested_page_fault(v, gpa, gla, npfec, p2m) ==
1 )
+{
+/* entry was lazily copied from host -- retry */
+__put_gfn(hostp2m, gfn);
+return 1;
+}
+
+mfn = get_gfn_type_access(p2m, gfn, p2mt, p2ma, 0, NULL);
+}
+else
+p2m = hostp2m;
+
/* Check access permissions first, then handle faults */
if ( mfn_x(mfn) != INVALID_MFN )
{
@@ -2893,6 +2912,20 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned
long gla,
if ( violation )
{
+/* Should #VE be emulated for this fault? */
+if ( p2m_is_altp2m(p2m) !cpu_has_vmx_virt_exceptions )
+{
+unsigned int sve;
+
+p2m-get_entry_full(p2m, gfn, p2mt, p2ma, 0, NULL,
sve);
+
+if ( !sve ahvm_vcpu_emulate_ve(v) )
This line generates the following compile-time error: hvm.c:2923:51:
error: ‘v’ undeclared (first use in this function). Did you mean to pass
curr to ahvm_vcpu_emulate_ve instead of v?
I would recommend doing a compile-test on each patch of the series to catch
small things like this. Travis-ci has been working really great for me to
automate that process (https://github.com/tklengyel/xen/compare/travis) ;)
I don't know why you are seeing that error, you can clearly see that v is
defined and initialised at the start of the containing function, and has
been used earlier.
I always compile test every patch individually.
Ed
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt test] 58119: regressions - FAIL
On 06/18/2015 10:02 AM, Ian Campbell wrote:
On Thu, 2015-06-18 at 16:18 +0100, Ian Campbell wrote:
On Mon, 2015-06-15 at 15:30 +0100, Anthony PERARD wrote:
The No response from client ... appear only on armhf as far as I can
tell.
Indeed, and I just noticed while developing osstest for arm64 that the
daemon is segfaulting, and we even managed to collect a core dump, not
this time but in:
http://logs.test-lab.xenproject.org/osstest/logs/58693/test-armhf-armhf-libvirt/info.html
Although the core and the build stuff is all there it was a bit easier
to just install gdb on the arm64 system in my hands, it reports:
Fwiw the arm32 one from 48693 looked a bit different, but was ultimately
some sort of heap corruption I would say:
Which was fixed by your recent change to use libxl_bitmap_{init,dispose}?
https://www.redhat.com/archives/libvir-list/2015-June/msg01024.html
Regards,
Jim
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: libxl: Take the userdata lock around maxmem changes
On Tue, Jun 23, 2015 at 05:38:17PM +0100, Ian Campbell wrote: On Tue, 2015-06-23 at 17:32 +0100, Wei Liu wrote: On Tue, Jun 23, 2015 at 03:58:32PM +0100, Ian Campbell wrote: There is an issue in libxl_set_memory_target whereby the target and the max mem can get out of sync, this is because the call the xc_domain_setmaxmem is not tied in any way to the xenstore transaction which controls updates to the xenstore side of things. Consider a domain with 1M of RAM (==target and maxmem for the sake of argument) and two simultaneous calls to libxl_set_memory_target, both with relative=0 and enforce=1, one with target=3 and the other with target=5. target=5 call target=3 call transaction start transaction start write target=5 to xenstore write target=3 to xenstore setmaxmem(5) setmaxmem(3) transaction commit = success transaction commit = EAGAIN At this point maxmem=3 while target=5. In reality the target=3 case will the retry and eventually (hopefully) succeed with target=maxmem=3, however the bad state will persist for some window which is undesirable. On failure other than EAGAIN all bets are off anyway, but in that case we will likely stick in the bad state until someone else sets the memory). To fix this we slightly abuse the userdata lock which is used to protect updates to the domain's json configuration. Abused because maxmem is not actually stored in there, but is kept by Xen. However the lock protects some semantically similar things and is convenient to use here too. libxl_domain_setmaxmem also takes the lock, since it reads memory/target from xenstore before calling xc_domain_setmaxmem there is a small (but perhaps not very interesting) race there too. There is on more use of xc_domain_setmaxmem in libxl__build_pre. However taking a lock around this would be tricky since the xenstore parts are not done until libxl__build_post. I think this one could be argued to be OK since the domid is not public yet, that is it has not been returned to the application yet (as the result of the create operation). Toolstacks which go round fiddling with random domid's which they find lying on the floor should be taught to do better. Add a doc note that taking the userdata lock requires the CTX_LOCK to be held. Signed-off-by: Ian Campbell ian.campb...@citrix.com --- This applies on top of Wei's revert of libxl_set_memory_target: retain the same maxmem offset on top of the current target I couldn't quite rule out some race (for transaction=EAGAIN, for !EAGAIN there are obvious ones) which resulted in the incorrect state being in place after both entities exit, but couldn't construct an actual case. Not sure I follow. With this patch you lock out other contenders to even start a transaction so the EAGAIN vs !EAGAIN should be moot. You can safely rollback in !EAGAIN case, right? Sorry, I meant a prexisting race which was fixed by this patch, rather than one that continues to exist with this fix. Is there inconsistency after this fix? I think not, because you can roll back maxmem and pod target to previous values -- but the rollback was not implemented here though. Wei. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 09/12] x86/altp2m: add remaining support routines.
On Mon, Jun 22, 2015 at 2:56 PM, Ed White edmund.h.wh...@intel.com wrote:
Add the remaining routines required to support enabling the alternate
p2m functionality.
Signed-off-by: Ed White edmund.h.wh...@intel.com
---
xen/arch/x86/hvm/hvm.c | 60 +-
xen/arch/x86/mm/hap/Makefile| 1 +
xen/arch/x86/mm/hap/altp2m_hap.c| 103 +
xen/arch/x86/mm/p2m-ept.c | 3 +
xen/arch/x86/mm/p2m.c | 405
xen/include/asm-x86/hvm/altp2mhvm.h | 4 +
xen/include/asm-x86/p2m.h | 33 +++
7 files changed, 601 insertions(+), 8 deletions(-)
create mode 100644 xen/arch/x86/mm/hap/altp2m_hap.c
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index d75c12d..b758ee1 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2786,10 +2786,11 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
unsigned long gla,
p2m_access_t p2ma;
mfn_t mfn;
struct vcpu *v = current;
-struct p2m_domain *p2m;
+struct p2m_domain *p2m, *hostp2m;
int rc, fall_through = 0, paged = 0;
int sharing_enomem = 0;
vm_event_request_t *req_ptr = NULL;
+int altp2m_active = 0;
/* On Nested Virtualization, walk the guest page table.
* If this succeeds, all is fine.
@@ -2845,15 +2846,33 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
unsigned long gla,
{
if ( !handle_mmio_with_translation(gla, gpa PAGE_SHIFT, npfec)
)
hvm_inject_hw_exception(TRAP_gp_fault, 0);
-rc = 1;
-goto out;
+return 1;
}
-p2m = p2m_get_hostp2m(v-domain);
-mfn = get_gfn_type_access(p2m, gfn, p2mt, p2ma,
+altp2m_active = altp2mhvm_active(v-domain);
+
+/* Take a lock on the host p2m speculatively, to avoid potential
+ * locking order problems later and to handle unshare etc.
+ */
+hostp2m = p2m_get_hostp2m(v-domain);
+mfn = get_gfn_type_access(hostp2m, gfn, p2mt, p2ma,
P2M_ALLOC | (npfec.write_access ?
P2M_UNSHARE : 0),
NULL);
+if ( altp2m_active )
+{
+if ( altp2mhvm_hap_nested_page_fault(v, gpa, gla, npfec, p2m) ==
1 )
+{
+/* entry was lazily copied from host -- retry */
+__put_gfn(hostp2m, gfn);
+return 1;
+}
+
+mfn = get_gfn_type_access(p2m, gfn, p2mt, p2ma, 0, NULL);
+}
+else
+p2m = hostp2m;
+
/* Check access permissions first, then handle faults */
if ( mfn_x(mfn) != INVALID_MFN )
{
@@ -2893,6 +2912,20 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned
long gla,
if ( violation )
{
+/* Should #VE be emulated for this fault? */
+if ( p2m_is_altp2m(p2m) !cpu_has_vmx_virt_exceptions )
+{
+unsigned int sve;
+
+p2m-get_entry_full(p2m, gfn, p2mt, p2ma, 0, NULL,
sve);
+
+if ( !sve ahvm_vcpu_emulate_ve(v) )
This line generates the following compile-time error: hvm.c:2923:51:
error: ‘v’ undeclared (first use in this function). Did you mean to pass
curr to ahvm_vcpu_emulate_ve instead of v?
I would recommend doing a compile-test on each patch of the series to catch
small things like this. Travis-ci has been working really great for me to
automate that process (https://github.com/tklengyel/xen/compare/travis) ;)
--
[image: www.novetta.com]
Tamas K Lengyel
Senior Security Researcher
7921 Jones Branch Drive
McLean VA 22102
Email tleng...@novetta.com
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/5] Change x86 paging/sharing to 'Orphaned'.
I think it's amazing that you're doing this work and I'll be happy to help if you keep me on cc. It's not serious for me to claim I'm a maintainer when I don't have the time nor the resources to do serious debugging should the need arise. Andres On Tue, Jun 23, 2015 at 10:33 AM, Lengyel, Tamas tleng...@novetta.com wrote: That's indeed sad. I'm actively using the sharing system in my tools and have a couple branches laying around for improving it, like batch memsharing for example to support flash-cloning. Now that it's orphaned, how would I go about merging these into mainline? I'm not yet confident enough in my understanding of the whole sharing system to volunteer as maintainer and my tool-side stuff is also very experimental.. On Tue, Jun 23, 2015 at 12:56 PM, Andres Lagar Cavilla and...@lagarcavilla.org wrote: On Tue, Jun 23, 2015 at 6:22 AM, Tim Deegan t...@xen.org wrote: This code now has no active maintainers, as neither Andres nor I can commit the time. Signed-off-by: Tim Deegan t...@xen.org Cc: Andres Lagar-Cavilla and...@lagarcavilla.org Wistfully, Acked-by: Andres Lagar-Cavilla and...@lagarcavilla.org --- MAINTAINERS | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 7f0e96e..d1bec17 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -367,9 +367,7 @@ S: Supported F: xen/arch/x86/mm/ X86 MEMORY SHARING AND PAGING -M: Andres Lagar-Cavilla and...@lagarcavilla.org -M: Tim Deegan t...@xen.org -S: Supported +S: Orphaned F: xen/arch/x86/mm/mem_sharing.c F: xen/arch/x86/mm/mem_paging.c F: tools/memshr -- 2.3.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel -- [image: www.novetta.com] Tamas K Lengyel Senior Security Researcher 7921 Jones Branch Drive McLean VA 22102 Email tleng...@novetta.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt test] 58119: regressions - FAIL
On 06/18/2015 09:18 AM, Ian Campbell wrote: On Mon, 2015-06-15 at 15:30 +0100, Anthony PERARD wrote: The No response from client ... appear only on armhf as far as I can tell. Indeed, and I just noticed while developing osstest for arm64 that the daemon is segfaulting, and we even managed to collect a core dump, not this time but in: http://logs.test-lab.xenproject.org/osstest/logs/58693/test-armhf-armhf-libvirt/info.html Although the core and the build stuff is all there it was a bit easier to just install gdb on the arm64 system in my hands, it reports: Program terminated with signal SIGSEGV, Segmentation fault. #0 malloc_consolidate (av=av@entry=0x7fa020) at malloc.c:4151 4151malloc.c: No such file or directory. (gdb) bt #0 malloc_consolidate (av=av@entry=0x7fa020) at malloc.c:4151 #1 0x007faf2adc50 in _int_malloc (av=av@entry=0x7fa020, bytes=bytes@entry=1100) at malloc.c:3423 #2 0x007faf2afc20 in __GI___libc_malloc (bytes=bytes@entry=1100) at malloc.c:2891 #3 0x007faf2b0580 in __GI___libc_realloc (oldmem=0x0, bytes=1100) at malloc.c:2972 #4 0x007faf434d98 in virReallocN () from /usr/local/lib/libvirt.so.0 #5 0x007faf438f34 in virBufferGrow () from /usr/local/lib/libvirt.so.0 #6 0x007faf4397b8 in virBufferVasprintf () from /usr/local/lib/libvirt.so.0 #7 0x007faf439700 in virBufferAsprintf () from /usr/local/lib/libvirt.so.0 #8 0x007faf51b7f0 in virDomainObjFormat () from /usr/local/lib/libvirt.so.0 #9 0x007faf51c078 in virDomainSaveStatus () from /usr/local/lib/libvirt.so.0 Did your libvirt fix help here too? libxlDomainSetVcpuAffinities() is called prior to virDomainSaveStatus, and may have freed some of the virDomainObj's memory. Regards, Jim #10 0x007fac510d88 in libxlDomainStart () from /usr/local/lib/libvirt/connection-driver/libvirt_driver_libxl.so #11 0x007fac5136c4 in libxlDomainCreateXML () from /usr/local/lib/libvirt/connection-driver/libvirt_driver_libxl.so #12 0x007faf5977c0 in virDomainCreateXML () from /usr/local/lib/libvirt.so.0 #13 0x0055887730c8 in remoteDispatchDomainCreateXML () #14 0x005588772fb8 in remoteDispatchDomainCreateXMLHelper () #15 0x0055887cb694 in virNetServerProgramDispatchCall () #16 0x0055887cb220 in virNetServerProgramDispatch () #17 0x0055887c2810 in virNetServerProcessMsg () #18 0x0055887c2910 in virNetServerHandleJob () #19 0x007faf4ba738 in virThreadPoolWorker () from /usr/local/lib/libvirt.so.0 #20 0x007faf4b989c in virThreadHelper () from /usr/local/lib/libvirt.so.0 #21 0x007faf388e34 in start_thread (arg=0x7fae6540c0) at pthread_create.c:311 #22 0x007faf2ff7c0 in clone () at ../ports/sysdeps/unix/sysv/linux/aarch64/nptl/../clone.S:96 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
