Re: [Xen-devel] [PATCH] libxlu: avoid linker warnings

On Thu, 2015-10-29 at 04:05 -0600, Jan Beulich wrote: > Recent ld warns about libxenlight.so's dependency libraries not being > available, which can be easily avoided by not just passing the raw > library name on ld's command line. > In the course of checking how things fit together (I originally

Re: [Xen-devel] [PATCH 4/4] x86/PoD: Command line option to prohibit any PoD operations

On Mon, 2015-11-02 at 06:53 -0700, Jan Beulich wrote: > > > > On 30.10.15 at 19:33, wrote: > > --- a/xen/arch/x86/hvm/hvm.c > > +++ b/xen/arch/x86/hvm/hvm.c > > @@ -92,6 +92,9 @@ unsigned long __section(".bss.page_aligned") > > static bool_t __initdata opt_hap_enabled

Re: [Xen-devel] [PATCH v3 2/6] xen: sched: fix locking for insert_vcpu() in credit1 and RTDS

Hi Dario, >> > This is fixed as follows: >> > - take the lock in the hook implementations, in specific >> >schedulers' code; >> > - avoid calling insert_vcpu(), for the idle vCPU, in >> >schedule_cpu_switch(). In fact, idle vCPUs are set to run >> >immediately, and the various

Re: [Xen-devel] [PATCH 1/4] xen/public: arm: Clarify the name of guest handle structures

On Fri, 30 Oct 2015, Julien Grall wrote: > Currently it's hard to know which __guest_handle* is associated to a > guest handle or a guest handle param. > > Rename the types to match the usage. I.e > * __guest_handle is renamed to __guest_handle_param as it's used for > hypercall

Re: [Xen-devel] [PATCH 2/4] xen/public: arm: Rework __guest_handle_param*

Hi Stefano, On 02/11/15 15:19, Stefano Stabellini wrote: > On Fri, 30 Oct 2015, Julien Grall wrote: >> __guest_handle_param is used to represent a guest pointer stored pass as >> an hypercall parameters. They are the same size as the native register >> for the architecture. It will be 32-bit on

Re: [Xen-devel] [PATCH 0/4] xen/public: arm: rework set_xen_guest_handle_raw

>>> On 30.10.15 at 19:13, wrote: > This series is based on the patch sent by Jan Beulich to drop > get_xen_guest_handle [2]. But I wasn't able to apply it cleanly on > unstable, so I've provided a branch with this patch and this series: > >

Re: [Xen-devel] [PATCH] xen: credit1: on vCPU wakeup, kick away current only if makes sense

On Mon, 2015-11-02 at 12:03 +, George Dunlap wrote: > On 29/10/15 10:57, Dario Faggioli wrote: > > In particular, 1) has been reported to cause the following > > issue: > > > > * VM-IO: 1-vCPU pinned to a pCPU, running netperf > > * VM-CPU: 1-vCPU pinned the the same pCPU, running a busy >

Re: [Xen-devel] [PATCH] oxenstored: fix short-write issue

On 02/11/15 13:44, Ian Campbell wrote: > On Tue, 2015-10-27 at 17:10 +, Wei Liu wrote: >> When oxenstored wrote to the ring, it wrote a chunk of contiguous data. >> Originally when it tried to write across ring boundary, it returned a >> short-write when there is still room. That led to

Re: [Xen-devel] [PATCH] libxlu: avoid linker warnings

On Mon, 2015-11-02 at 14:01 +, Ian Campbell wrote: > On Thu, 2015-10-29 at 04:05 -0600, Jan Beulich wrote: > > Recent ld warns about libxenlight.so's dependency libraries not being > > available, which can be easily avoided by not just passing the raw > > library name on ld's command line. >

Re: [Xen-devel] [PATCH] oxenstored: fix short-write issue

On Mon, 2015-11-02 at 14:10 +, Andrew Cooper wrote: > On 02/11/15 13:44, Ian Campbell wrote: > > On Tue, 2015-10-27 at 17:10 +, Wei Liu wrote: > > > When oxenstored wrote to the ring, it wrote a chunk of contiguous > > > data. > > > Originally when it tried to write across ring boundary,

Re: [Xen-devel] [PATCH v2 1/5] symbols: prefix static symbols with their source file names

On Mon, 2015-11-02 at 06:55 -0700, Jan Beulich wrote: > > > > On 02.11.15 at 14:47, wrote: > > On Mon, 2015-10-26 at 05:49 -0600, Jan Beulich wrote: > > > This requires adjustments to the tool generating the symbol table and > > > its as well as nm's invocation. > > > >

Re: [Xen-devel] [PATCH 3/4] xen/public: Don't expose XEN_GUEST_HANDLE_PARAM outside of the hypervisor

>>> On 30.10.15 at 19:13, wrote: > A XEN_GUEST_HANDLE_PARAM is used to represent a guest pointer passed as > an hypercall register. It will always be the size of a native register. > > This is only used in Xen for type-safety, the guest will directly pass a > pointer in

Re: [Xen-devel] [PATCH 3/4] x86/mm: Return -ESRCH for an invalid foreign domid

On 30/10/15 18:33, Andrew Cooper wrote: > For consistency with all other invalid domid handling. > > Signed-off-by: Andrew Cooper Reviewed-by: George Dunlap ___ Xen-devel mailing list

Re: [Xen-devel] Revisit VT-d asynchronous flush issue

>>> On 02.11.15 at 09:03, wrote: > Based on above information, we propose to continue spin-timeout > model w/ some adjustment, which fixes current timeout concern > and also allows limited ATS support in a light way: > > 1) reduce spin timeout to 1ms, which can be boot-time

Re: [Xen-devel] [PATCH 4/4] x86/PoD: Command line option to prohibit any PoD operations

On 02/11/15 14:32, Ian Campbell wrote: > On Mon, 2015-11-02 at 06:53 -0700, Jan Beulich wrote: > On 30.10.15 at 19:33, wrote: >>> --- a/xen/arch/x86/hvm/hvm.c >>> +++ b/xen/arch/x86/hvm/hvm.c >>> @@ -92,6 +92,9 @@ unsigned long __section(".bss.page_aligned") >>>

Re: [Xen-devel] [PATCH 2/4] xen/public: arm: Rework __guest_handle_param*

On 02/11/15 15:35, Ian Campbell wrote: > On Mon, 2015-11-02 at 15:24 +, Julien Grall wrote: >> Hi Stefano, >> >> On 02/11/15 15:19, Stefano Stabellini wrote: >>> On Fri, 30 Oct 2015, Julien Grall wrote: __guest_handle_param is used to represent a guest pointer stored pass as an

Re: [Xen-devel] [PATCH 0/4] xen/public: arm: rework set_xen_guest_handle_raw

On 02/11/15 13:42, Jan Beulich wrote: On 30.10.15 at 19:13, wrote: >> This series is based on the patch sent by Jan Beulich to drop >> get_xen_guest_handle [2]. But I wasn't able to apply it cleanly on >> unstable, so I've provided a branch with this patch and this

[Xen-devel] [VOTE] Release cycle scheme

Hi committers, There doesn't seem to be consensus on how release cycle should be managed. In the survey [0] about release cycle there were following proposed schemes: #1. 6 months release cycle + current stable release scheme #2. 6 months release cycle + LTS scheme #3. 6 months release cycle +

Re: [Xen-devel] [PATCH v2 1/5] symbols: prefix static symbols with their source file names

On Mon, 2015-10-26 at 05:49 -0600, Jan Beulich wrote: > This requires adjustments to the tool generating the symbol table and > its as well as nm's invocation. > > Note: Not warning about duplicate symbols in the EFI case for now, as > a binutils bug causes misnamed file name entries to appear in

Re: [Xen-devel] [PATCH 2/4] x86/PoD: Identify when a domain has already been killed from PoD exhaustion

On 30/10/15 18:33, Andrew Cooper wrote: > p2m_pod_demand_populate() can be entered repeatedly during a single path > through the hypervisor, e.g. on a toolstack batch map operation. > > The domain might be crashed, but the interface currently lacks a way of > passing an error back through the

Re: [Xen-devel] [PATCH 4/4] x86/PoD: Command line option to prohibit any PoD operations

>>> On 02.11.15 at 15:32, wrote: > On Mon, 2015-11-02 at 06:53 -0700, Jan Beulich wrote: >> > > > On 30.10.15 at 19:33, wrote: >> > --- a/xen/common/memory.c >> > +++ b/xen/common/memory.c >> > @@ -818,6 +818,10 @@ long do_memory_op(unsigned

Re: [Xen-devel] [PATCH 2/4] xen/public: arm: Rework __guest_handle_param*

On Fri, 30 Oct 2015, Julien Grall wrote: > __guest_handle_param is used to represent a guest pointer stored pass as > an hypercall parameters. They are the same size as the native register > for the architecture. It will be 32-bit on ARM32 and 64-bit on ARM64. > > As the __guest_handle_param will

Re: [Xen-devel] [PATCH 4/4] x86/PoD: Command line option to prohibit any PoD operations

On 30/10/15 18:33, Andrew Cooper wrote: > PoD is only needed to cover a corner case with memory overcommit > (rebooting a ballooned down VM with insufficient host RAM available). > > Its use comes with a performance hit, and inoperability with other > technologies such as PCI Passthrough. > >

Re: [Xen-devel] [PATCH v2 2/5] compat: enforce distinguishable file names in symbol table

On Mon, 2015-10-26 at 05:50 -0600, Jan Beulich wrote: > To make it possible to tell apart the static symbols in files built a > second for compat guest support, arrange for their source file names to ^ time ? > be prefixed by a suitable path. We can't do this without explicit .file >

Re: [Xen-devel] [PATCH MINI-OS] xenbus: notify the other end when necessary

On Mon, Nov 02, 2015 at 03:08:26PM +, Ian Campbell wrote: > On Mon, 2015-11-02 at 15:00 +, Wei Liu wrote: > > On Mon, Nov 02, 2015 at 12:14:50PM +, Ian Campbell wrote: > > > On Mon, 2015-10-26 at 09:47 +, Wei Liu wrote: > > > > The xenbus thread didn't send notification to other

Re: [Xen-devel] [PATCH] oxenstored: fix short-write issue

On Tue, 2015-10-27 at 17:10 +, Wei Liu wrote: > When oxenstored wrote to the ring, it wrote a chunk of contiguous data. > Originally when it tried to write across ring boundary, it returned a > short-write when there is still room. That led to stalling mini-os's > xenstore thread at times.

Re: [Xen-devel] [PATCH] drop get_xen_guest_handle()

On Tue, 2015-10-27 at 02:04 -0600, Jan Beulich wrote: > Its use in the tools (and its apparent abuse in the hypervisor) are > long gone. > > Signed-off-by: Jan Beulich Acked-by: Ian Campbell ___ Xen-devel

Re: [Xen-devel] [PATCH v2 1/5] symbols: prefix static symbols with their source file names

>>> On 02.11.15 at 14:47, wrote: > On Mon, 2015-10-26 at 05:49 -0600, Jan Beulich wrote: >> This requires adjustments to the tool generating the symbol table and >> its as well as nm's invocation. >> >> Note: Not warning about duplicate symbols in the EFI case for now,

Re: [Xen-devel] [PATCH XEN v4 01/23] tools/Rules.mk: Properly handle libraries with recursive dependencies.

On Thu, 2015-10-29 at 16:27 +, Wei Liu wrote: > On Wed, Oct 21, 2015 at 04:23:08PM +0100, Ian Campbell wrote: > > In tree libraries which link against other in tree libraries in a way > > which is opaque to their callers need special handling, specifically > > correct use of -Wl,-rpath-link

[Xen-devel] [xen-unstable baseline-only test] 38238: tolerable FAIL

This run is configured for baseline tests only. flight 38238 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38238/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-pygrub 20

Re: [Xen-devel] [PATCH] timer-op: demote a debugging message to really be debugging only

On Fri, 2015-10-30 at 18:58 +, Andrew Cooper wrote: > On 30/10/15 17:42, Jan Beulich wrote: > > The issue the message points out may have been of relevance during the > > early days, but shouldn't anymore. > > > > Signed-off-by: Jan Beulich > > Reviewed-by: Andrew Cooper

Re: [Xen-devel] [PATCH 2/4] xen/public: arm: Rework __guest_handle_param*

On Mon, 2015-11-02 at 15:24 +, Julien Grall wrote: > Hi Stefano, > > On 02/11/15 15:19, Stefano Stabellini wrote: > > On Fri, 30 Oct 2015, Julien Grall wrote: > > > __guest_handle_param is used to represent a guest pointer stored pass > > > as > > > an hypercall parameters. They are the same

Re: [Xen-devel] [PATCH 3/4] xen/public: Don't expose XEN_GUEST_HANDLE_PARAM outside of the hypervisor

On Mon, 2 Nov 2015, Jan Beulich wrote: > >>> On 30.10.15 at 19:13, wrote: > > A XEN_GUEST_HANDLE_PARAM is used to represent a guest pointer passed as > > an hypercall register. It will always be the size of a native register. > > > > This is only used in Xen for

Re: [Xen-devel] [PATCH 4/4] x86/PoD: Command line option to prohibit any PoD operations

>>> On 30.10.15 at 19:33, wrote: > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -92,6 +92,9 @@ unsigned long __section(".bss.page_aligned") > static bool_t __initdata opt_hap_enabled = 1; > boolean_param("hap", opt_hap_enabled); > > +bool_t

Re: [Xen-devel] [PATCH] oxenstored: fix short-write issue

On 02/11/15 14:24, Ian Campbell wrote: > On Mon, 2015-11-02 at 14:10 +, Andrew Cooper wrote: >> On 02/11/15 13:44, Ian Campbell wrote: >>> On Tue, 2015-10-27 at 17:10 +, Wei Liu wrote: When oxenstored wrote to the ring, it wrote a chunk of contiguous data. Originally when it

[Xen-devel] [distros-debian-sid test] 38239: tolerable FAIL

flight 38239 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38239/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-amd64-sid-netboot-pygrub 13 guest-saverestore fail blocked in 38212

Re: [Xen-devel] [PATCH v2 1/5] symbols: prefix static symbols with their source file names

>>> On 02.11.15 at 15:54, wrote: > On Mon, 2015-11-02 at 06:55 -0700, Jan Beulich wrote: >> > > > On 02.11.15 at 14:47, wrote: >> > On Mon, 2015-10-26 at 05:49 -0600, Jan Beulich wrote: >> > > This requires adjustments to the tool generating the

Re: [Xen-devel] [PATCH v2 1/5] symbols: prefix static symbols with their source file names

On Mon, 2015-11-02 at 07:58 -0700, Jan Beulich wrote: > So since you're on it - can I get an ack (or otherwise)? Perhaps > also on patch 2? That being "compat: enforce distinguishable file names in symbol table" ? TBH I had considered that to be x86 specific (despite where the code might live).

[Xen-devel] [linux-3.4 test] 63404: regressions - FAIL

flight 63404 linux-3.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/63404/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rumpuserxen-i386 6 xen-boot fail REGR. vs. 62277

Re: [Xen-devel] [PATCH 2/4] xen/public: arm: Rework __guest_handle_param*

On Mon, 2015-11-02 at 15:39 +, Julien Grall wrote: > On 02/11/15 15:35, Ian Campbell wrote: > > On Mon, 2015-11-02 at 15:24 +, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 02/11/15 15:19, Stefano Stabellini wrote: > > > > On Fri, 30 Oct 2015, Julien Grall wrote: > > > > >

Re: [Xen-devel] [PATCH MINI-OS] xenbus: notify the other end when necessary

On Mon, 2015-11-02 at 15:53 +, Wei Liu wrote: > On Mon, Nov 02, 2015 at 03:08:26PM +, Ian Campbell wrote: > > On Mon, 2015-11-02 at 15:00 +, Wei Liu wrote: > > > On Mon, Nov 02, 2015 at 12:14:50PM +, Ian Campbell wrote: > > > > On Mon, 2015-10-26 at 09:47 +, Wei Liu wrote: > >

[Xen-devel] [PATCH RFC] vmalloc/vzalloc: Add memflags parameter.

And use it amongst the callers of this function. Signed-off-by: Konrad Rzeszutek Wilk --- xen/arch/x86/mm/hap/hap.c | 2 +- xen/arch/x86/mm/shadow/common.c | 2 +- xen/common/domain.c | 2 +- xen/common/domctl.c | 2 +-

[Xen-devel] [PATCH RFC] domain: Compile with lock_profile=y enabled.

Our 'struct domain' has when lock profiling is enabled is bigger than one page. We can't use vmap nor vzalloc as both of those stash the physical address in struct page which makes the assumptions in 'arch_init_memory' trip over ASSERTs. Signed-off-by: Konrad Rzeszutek Wilk

Re: [Xen-devel] [PATCH v3 1/6] xen: sched: fix locking of remove_vcpu() in credit1

On 29/10/15 23:04, Dario Faggioli wrote: > In fact, csched_vcpu_remove() (i.e., the credit1 > implementation of remove_vcpu()) manipulates runqueues, > so holding the runqueue lock is necessary. > > Also, while there, *_lock_irq() (for the private lock) is > enough, there is no need to

Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw

>>> On 02.11.15 at 16:55, wrote: > Honestly I would be OK with having a typeof in the public headers to > avoid this code, which is much harder to follow. Why don't we do > something like the following: > > > diff --git a/xen/include/public/arch-arm.h

Re: [Xen-devel] [PATCH] x86/HAP: use %pv printk() format where suitable

On 30/10/15 17:50, Jan Beulich wrote: > Signed-off-by: Jan Beulich Acked-by: George Dunlap ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 6/6] xen: sched: get rid of the per domain vCPU list in Credit2

On 29/10/15 23:04, Dario Faggioli wrote: > As, curently, there is no reason for bothering having > it and keeping it updated. > > In fact, it is only used for dumping and changing > vCPUs parameters, but that can be achieved easily with > for_each_vcpu. > > While there, improve alignment of

Re: [Xen-devel] [PATCH] xen: fix the check of e_pfn in xen_find_pfn_range

On 27/10/15 19:19, Konrad Rzeszutek Wilk wrote: > From: Zhenzhong Duan > > On some NUMA system, after dom0 up, we see below warning even if there are > enough pfn ranges that could be used for remapping: > "Unable to find available pfn range, not remapping identity

Re: [Xen-devel] [PATCH v3 3/6] xen: sched: clarify use cases of schedule_cpu_switch()

On 29/10/15 23:04, Dario Faggioli wrote: > schedule_cpu_switch() is meant to be only used for moving > pCPUs from a cpupool to no cpupool, and from there back > to a cpupool, *not* to move them directly from one cpupool > to another. > > This is something that is reflected in the way it is >

[Xen-devel] [xen-4.5-testing test] 63437: tolerable FAIL - PUSHED

flight 63437 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/63437/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 63358

[Xen-devel] [PATCH 0/3] Futher cpuid handling cleanup

Andrew Cooper (3): xen/x86: Correct {a,m}perf check in generic_identify() xen/x86: Query for paddr_bits in early_cpu_detect() xen/x86: Cleanup of early cpuid handling xen/arch/x86/cpu/common.c | 76 +++ 1 file changed, 38 insertions(+), 38

[Xen-devel] [PATCH 3/3] xen/x86: Cleanup of early cpuid handling

Use register names for variables, rather than their content for leaf 1. Reduce the number of cpuid instructions issued. Also drop some trailing whitespace. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich ---

[Xen-devel] [PATCH 1/3] xen/x86: Correct {a, m}perf check in generic_identify()

Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/cpu/common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c index 653b052..02f2504 100644 ---

[Xen-devel] [PATCH 2/3] xen/x86: Query for paddr_bits in early_cpu_detect()

It is __read_mostly, so repeatedly writing to it is suboptiomal. As the MTRRs have already been set up, nothing good will come from its value changing across CPUs. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/cpu/common.c | 5

[Xen-devel] [V9 1/3] x86/xsaves: enable xsaves/xrstors/xsavec in xen

This patch uses xsaves/xrstors/xsavec instead of xsaveopt/xrstor to perform the xsave_area switching so that xen itself can benefit from them when available. For xsaves/xrstors/xsavec only use compact format. Add format conversion support when perform guest os migration. Also, pv guest will not

[Xen-devel] [V9 2/3] x86/xsaves: enable xsaves/xrstors for hvm guest

This patch enables xsaves for hvm guest, includes: 1.handle xsaves vmcs init and vmexit. 2.add logic to write/read the XSS msr. Add IA32_XSS_MSR save/rstore support. Signed-off-by: Shuai Ruan --- xen/arch/x86/hvm/hvm.c | 27 +++

[Xen-devel] [V9 0/3] add xsaves/xrstors support

From: Shuai Ruan Changes in v9: * Address comments form Jan: * Add msr_ia32_xss save/restor support in patch2. * Change xrstor to alternative asm in patch1. * Use memcpy() copy the save header to avoid one ugly cast in patch1. * Fix coding stype errors. Changes in v8: *

[Xen-devel] [V9 3/3] libxc: expose xsaves/xgetbv1/xsavec to hvm guest

From: Shuai Ruan This patch exposes xsaves/xgetbv1/xsavec to hvm guest. The reserved bits of eax/ebx/ecx/edx must be cleaned up when call cpuid(0dh) with leaf 1 or 2..63. According to the spec the following bits must be reserved: For leaf 1, bits 03-04/08-31 of ecx is

Re: [Xen-devel] [PATCH v7 16/32] xen/x86: allow disabling the pmtimer

>>> On 30.10.15 at 16:36, wrote: > On 30/10/15 13:16, Jan Beulich wrote: > On 30.10.15 at 13:50, wrote: >>> El 14/10/15 a les 16.37, Jan Beulich ha escrit: >>> On 02.10.15 at 17:48, wrote: > Signed-off-by: Roger

[Xen-devel] [xen-4.5-testing baseline-only test] 38241: regressions - FAIL

This run is configured for baseline tests only. flight 38241 xen-4.5-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38241/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-multivcpu 6 xen-boot

[Xen-devel] [xen-4.6-testing test] 63449: tolerable FAIL - PUSHED

flight 63449 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/63449/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-multivcpu 3 host-install(3) broken in 63379 pass in 63449

Re: [Xen-devel] [PATCH v3 5/6] xen: sched: get rid of the per domain vCPU list in RTDS

On 29/10/15 23:04, Dario Faggioli wrote: > As, curently, there is no reason for bothering having > it and keeping it updated. > > In fact, it is only used for dumping and changing > vCPUs parameters, but that can be achieved easily with > for_each_vcpu. > > While there, take care of the case

Re: [Xen-devel] [PATCH 4/6] x86/vmx: Replace unqualified ud2 instructions with BUG frames

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Saturday, October 31, 2015 3:59 AM > > Using new _ASM_BUGFRAME* internals. > > A side effect of complicating the ASM statements is that GCC now chooses to > out-of-line the stub functions, resulting in identical copies being

Re: [Xen-devel] [PATCH v2 2/6] xen/x86: Replace unqualified ud2 instructions with BUG frames

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Saturday, October 31, 2015 3:59 AM > > No functional change, other than the failure cases, which now produce a > far more clear error message. > > Signed-off-by: Andrew Cooper Acked-by: Kevin Tian

[Xen-devel] [libvirt test] 63469: regressions - FAIL

flight 63469 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/63469/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 5 libvirt-build fail REGR. vs. 63340 Tests which did not

Re: [Xen-devel] [PATCH v3 2/6] xen: sched: fix locking for insert_vcpu() in credit1 and RTDS

On Fri, 2015-10-30 at 19:00 -0400, Meng Xu wrote: > Hi Dario, > Hi, > > This is fixed as follows: > > - take the lock in the hook implementations, in specific > >schedulers' code; > > - avoid calling insert_vcpu(), for the idle vCPU, in > >schedule_cpu_switch(). In fact, idle vCPUs are

[Xen-devel] Revisit VT-d asynchronous flush issue

Let's start a new thread with a summary of previous discussion, and then our latest experiment data and updated proposal. >From previous discussions, it's suggested that a spin model is accepted, only when spin timeout doesn't exceed the order of a scheduling time slice, or other blocking

Re: [Xen-devel] [PATCH] xenconsoled: Remove unexpected daemonize behavior

On Mon, Nov 02, 2015 at 11:17:38AM +, Ross Lagerwall wrote: > Previously, xenconsoled's daemonize function would do nothing if its > parent process is init (as it is under systemd but not sysv init). > This is confusing. Instead, always daemonize when asked to, but use the > "interactive"

[Xen-devel] [linux-3.16 test] 63429: tolerable FAIL - PUSHED

flight 63429 linux-3.16 real [real] http://logs.test-lab.xenproject.org/osstest/logs/63429/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-credit2 18 guest-localmigrate/x10 fail like 62695

Re: [Xen-devel] [PATCH] x86/PoD: tighten conditions for checking super page

On 02/11/15 16:50, Jan Beulich wrote: On 02.11.15 at 17:29, wrote: >> On 30/10/15 17:39, Jan Beulich wrote: >>> Since calling the function isn't cheap, try to avoid the call when we >>> know up front it won't help; see the code comment for details on those >>>

Re: [Xen-devel] [PATCH] xenconsoled: Remove unexpected daemonize behavior

Ross Lagerwall writes ("[PATCH] xenconsoled: Remove unexpected daemonize behavior"): > Previously, xenconsoled's daemonize function would do nothing if its > parent process is init (as it is under systemd but not sysv init). > > This is confusing. It's quite bogglesome, indeed. > Instead,

[Xen-devel] [xen-unstable-smoke test] 63484: tolerable all pass - PUSHED

flight 63484 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/63484/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13

Re: [Xen-devel] [PATCH] x86/PoD: tighten conditions for checking super page

On 30/10/15 17:39, Jan Beulich wrote: > Since calling the function isn't cheap, try to avoid the call when we > know up front it won't help; see the code comment for details on those > conditions. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/mm/p2m-pod.c > +++

Re: [Xen-devel] [PATCH] x86/PoD: tighten conditions for checking super page

>>> On 02.11.15 at 17:29, wrote: > On 30/10/15 17:39, Jan Beulich wrote: >> Since calling the function isn't cheap, try to avoid the call when we >> know up front it won't help; see the code comment for details on those >> conditions. >> >> Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH v2 2/5] compat: enforce distinguishable file names in symbol table

>>> On 02.11.15 at 16:20, wrote: > On Mon, 2015-10-26 at 05:50 -0600, Jan Beulich wrote: >> To make it possible to tell apart the static symbols in files built a >> second for compat guest support, arrange for their source file names to > > ^ time ? Oh, yes, of

Re: [Xen-devel] [PATCH] xenconsoled: Remove unexpected daemonize behavior

On 11/02/2015 04:37 PM, Wei Liu wrote: On Mon, Nov 02, 2015 at 11:17:38AM +, Ross Lagerwall wrote: Previously, xenconsoled's daemonize function would do nothing if its parent process is init (as it is under systemd but not sysv init). This is confusing. Instead, always daemonize when asked

Re: [Xen-devel] ovmf fail to compile

On Mon, Nov 02, 2015 at 07:27:32AM +, Hao, Xudong wrote: > Hi, > > Does anyone meet build OVMF failure? The ovmf is xen default repo: > http://xenbits.xen.org/git-http/ovmf.git, with latest commit > af9785a9ed61daea52b47f0bf448f1f228beee1e, and OS is X86_64 RHEL6.6. > > > ... > make[1]:

Re: [Xen-devel] Contributing to Outreachy (Dec '15 - March '16)

Hi Aastha On Fri, Oct 30, 2015 at 11:40:51PM +0530, Aastha Yadav wrote: > Hi, > > I am an Outreachy (Dec '15 - March '16) applicant. I have a background in > C, C++, Python, bash and Unix like systems. I also have knowledge of > operating systems and networking. > > I know it's late, but I am

Re: [Xen-devel] [linux-3.14 test] 63336: regressions - FAIL

On Wed, 2015-10-28 at 18:12 +, Julien Grall wrote: > Hi, > > On 28/10/15 17:31, osstest service owner wrote: > > flight 63336 linux-3.14 real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/63336/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > >

[Xen-devel] [X-POST from xen-users] DomU Sync I/O

Good morning everyone, while trying out xenserver there was a thing that caught my attention: apparently every I/O done in the guest magically ends being async toward the storage (amongst other things I tried dd with oflags=sync). The storage BOX exports the LUNs via FC, with writeback cache

Re: [Xen-devel] ovmf fail to compile

Wei, I checked the latest OVMF changeset on Xen staging tree and master tree, both are af9785a9ed61daea52b47f0bf448f1f228beee1e. This commit is what I used. OVMF_UPSTREAM_REVISION ?= af9785a9ed61daea52b47f0bf448f1f228beee1e Yes, I found the Config.mk updated with Xen commit

[Xen-devel] [linux-3.16 baseline-only test] 38240: regressions - trouble: broken/fail/pass

This run is configured for baseline tests only. flight 38240 linux-3.16 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38240/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run:

[Xen-devel] [linux-mingo-tip-master test] 63462: regressions - FAIL

flight 63462 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/63462/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail REGR. vs. 60684

Re: [Xen-devel] [OSSTEST PATCH 0/3] cs-bisection-step: Linky linky revision graph

On Fri, 2015-10-23 at 17:55 +0100, Ian Jackson wrote: > Andrew Cooper writes ("Re: [Xen-devel] [OSSTEST PATCH 0/3] cs-bisection > -step: Linky linky revision graph"): > > On 23/10/15 17:46, Ian Jackson wrote: > > > Yes, indeed. It appears that your browser is rather poor :-). (Most > > > are...)

Re: [Xen-devel] [PATCH] x86: make compat_iret() domain crash cases distinguishable

On 02/11/15 10:56, Jan Beulich wrote: On 30.10.15 at 20:05, wrote: >> On 30/10/15 17:46, Jan Beulich wrote: >>> Rather than issuing a (mostly) useless separate message, rely on >>> domain_crash() providing enough data, and leverage the line number >>> information

Re: [Xen-devel] [PATCH] x86: make compat_iret() domain crash cases distinguishable

>>> On 02.11.15 at 12:10, wrote: > On 02/11/15 10:57, Jan Beulich wrote: > On 30.10.15 at 20:05, wrote: >>> On 30/10/15 17:46, Jan Beulich wrote: Rather than issuing a (mostly) useless separate message, rely on domain_crash()

Re: [Xen-devel] Revisit VT-d asynchronous flush issue

On 02/11/15 08:03, Tian, Kevin wrote: > Let's start a new thread with a summary of previous discussion, and > then our latest experiment data and updated proposal. > > From previous discussions, it's suggested that a spin model is accepted, > only when spin timeout doesn't exceed the order of a

Re: [Xen-devel] [PATCH] cpufreq: allow ordinary boolean options to be passed on the command line

>>> On 30.10.15 at 20:22, wrote: > On 30/10/15 17:49, Jan Beulich wrote: >> I was quite surprised to find "cpufreq=off" not doing what one would >> expect it to do. Fix this. >> >> Signed-off-by: Jan Beulich >> >> ---

Re: [Xen-devel] [PATCH] x86: make compat_iret() domain crash cases distinguishable

>>> On 30.10.15 at 20:05, wrote: > On 30/10/15 17:46, Jan Beulich wrote: >> Rather than issuing a (mostly) useless separate message, rely on >> domain_crash() providing enough data, and leverage the line number >> information it prints. >> >> Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH] sched_credit: Remove cpu argument to __runq_insert()

[Trimming the Cc list, and adding George, which I did not realize he was not there!] On Fri, 2015-10-30 at 11:00 -0600, Jan Beulich wrote: > > > > On 30.10.15 at 17:33, wrote: > > Are you saying that we shouldn't make the change at all? Or that we > > should make

Re: [Xen-devel] Question about XEN Hypervisor MSR capability exposion to VMs

On 31/10/15 02:53, Liuyingdong wrote: > Hi All > > We encountered a blue screen problem when live migrate > Win8.1/Win2012R2 64bit VM from V3 processor to non-V3 > processor sandbox, KVM does not has this problem. > > After looking into the MSR capabilities, we found XEN > hypervisor exposed bit

Re: [Xen-devel] [PATCH] x86: make compat_iret() domain crash cases distinguishable

On 02/11/15 10:57, Jan Beulich wrote: On 30.10.15 at 20:05, wrote: >> On 30/10/15 17:46, Jan Beulich wrote: >>> Rather than issuing a (mostly) useless separate message, rely on >>> domain_crash() providing enough data, and leverage the line number >>> information

[Xen-devel] [PATCH] xenconsoled: Remove unexpected daemonize behavior

Previously, xenconsoled's daemonize function would do nothing if its parent process is init (as it is under systemd but not sysv init). This is confusing. Instead, always daemonize when asked to, but use the "interactive" switch when running from the systemd service. Because a pidfile is only

Re: [Xen-devel] [PATCH] x86: make compat_iret() domain crash cases distinguishable

>>> On 30.10.15 at 20:05, wrote: > On 30/10/15 17:46, Jan Beulich wrote: >> Rather than issuing a (mostly) useless separate message, rely on >> domain_crash() providing enough data, and leverage the line number >> information it prints. >> >> Signed-off-by: Jan Beulich

Re: [Xen-devel] [linux-3.14 test] 63336: regressions - FAIL

Hi Ian, On 02/11/15 10:17, Ian Campbell wrote: >> So shall we disable 3.14 job for ARM for once and all? > > Given the above failure I don't think the ability to test the 3.14 kernels > on the Cambridge instance is all that valuable. So yes, I think we should > drop ARM from the linux-3.14

Re: [Xen-devel] [PATCH v4 00/10] xen-block: multi hardware-queues/rings support

Hi Bob, On 02/11/15 04:21, Bob Liu wrote: > --- > v4: > * Rebase to v4.3-rc7 xentip/for-linus-4.4 [1] contains a lot of change in xen-blkfront, mainly to add support of 64KB page granularity. I would advise you to rebase your series know as some part of the code may have changed. Regards,

[Xen-devel] [xen-4.3-testing test] 63464: regressions - FAIL

flight 63464 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/63464/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-migrupgrade 21 guest-migrate/src_host/dst_host fail REGR. vs. 63212 Tests

Re: [Xen-devel] Ping: [PATCH] use clear_domain_page() instead of open coding it

On Mon, 2015-10-26 at 07:06 -0600, Jan Beulich wrote: > > > > On 19.10.15 at 16:51, wrote: > > "REST" maintainers, could I please get an ack or otherwise on this > common code change? > > Thanks, Jan > > > --- a/xen/common/page_alloc.c > > +++ b/xen/common/page_alloc.c > >

Re: [Xen-devel] [OSSTEST PATCH] build_clone: git clean newly cloned trees

On Thu, 2015-10-29 at 16:01 +, Andrew Cooper wrote: > On 29/10/15 15:57, Ian Jackson wrote: > > This may seem redundant, however: > > > > git does not track empty directories. So it can happen that a > > directory is created as part of `git clone', but is empty in the > > revision switched

Re: [Xen-devel] [PATCH 2/4] x86/PoD: Identify when a domain has already been killed from PoD exhaustion

On 02/11/15 14:07, George Dunlap wrote: > On 30/10/15 18:33, Andrew Cooper wrote: >> p2m_pod_demand_populate() can be entered repeatedly during a single path >> through the hypervisor, e.g. on a toolstack batch map operation. >> >> The domain might be crashed, but the interface currently lacks a

  1   2   >