>>> 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 Pau Monné
> Cc: Jan Beulich
> Cc: Andrew Cooper
> ---
>>>
> 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
__
> 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 present
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:
* Address comments form Jan
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 s
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/arch/x86/hvm/vmx/vmcs.c
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 reserved. Edx is reserved.
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
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 succe
flight 63466 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63466/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-xsm 6 xen-boot fail in 63384 pass in 63466
test-armhf-armhf-xl-xsm 16 guest-
>>> On 03.11.2015 at 10:27, 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 c
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, November 02, 2015 7:40 PM
>
> >
> > 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:
> >
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 whic
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
04c5efb0a141fa53e8
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:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-
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
test-amd64
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
test-amd64-i386-xl-qemut-stubdo
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 when
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 comme
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
> imple
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 *_lock_irqs
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 deletio
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/arch/x86/cpu/common.c | 69 +++
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
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@
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 +++--
1 file changed, 3 insertions(+), 2 delet
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
test-amd64-i386-xl-qemut-w
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 pages"
>
> Fix it to avoid get
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
---
xen/arch/x86/dom
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/common/grant_table.c| 3 ++-
xen/c
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
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
>>> conditions.
>>>
>>> Signed-off-b
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, alway
>>> 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
>>
>> --- a/xen/arch/x86/mm
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 t
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
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" switc
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
test-amd64-i386-xl-qemut-stubdo
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
> +++ b/xen/arch/x86/mm/p2m-pod.
>>> 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 b/xen/include/public/arch-arm.h
> index 9a96
>>> 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 course.
>> --- a/xen/Rule
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:
> > >
On Fri, 30 Oct 2015, Julien Grall wrote:
> The current implementation of set_xen_guest_handle_raw is using the
> keyword "typeof" which is not part of C spec.
>
> Furthermore, when the guest handle is defined in ARM32 guest, the
> pointer will always be smaller than the handle. Based on the C99 sp
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 end
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:
> > > > > __guest_h
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 h
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
test-amd64-i386-xl-qemu
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 s
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
> dire
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 AR
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
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.
>
> Off
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 parameters
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).
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 end when it
> > > expected
> > > more data or consumed responses, which l
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 end when it expected
> > more data or consumed responses, which led to stalling the ring from
> > time to time.
> >
> > This is
>>> 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 symbol table and
>> > > its as well as nm's invocat
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.
> > >
> > > Note: Not warning abou
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 schedu
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
Acked-by: Ian Camp
>>> 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 long cmd,
>> > XEN_GUEST_HANDLE_PARAM(void) arg)
>> >
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")
>>> static bool_t __initdata opt_h
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
test-amd64-i3
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 wa
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 = 1;
> > boolean_param("hap
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
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.
>
>
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, it
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 for
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 guest-start/debian.repeat
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 to
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 stalli
>>> 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 changed
> up to 10ms.
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
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
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 gene
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
>>> 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, as
>> a binutils bug causes
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 mailing list
Xen-devel@lists.xen.org
http://
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 type-safety, the guest will direct
>>> 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 opt_pod_enabled = 1;
__read_most
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
> > @@ -1959,22 +1959,16
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
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 series:
>>
>> git://xenbits
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 + ex
>>> 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 the hypercall parameter.
>
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.
Wh
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
>
>>> 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:
>
> git://xenbits.xen.org/people/julieng/xen-unstable.git br
On Fri, Oct 30, 2015 at 06:01:36PM +0100, Dario Faggioli wrote:
> On Fri, 2015-10-30 at 22:20 +0530, Harmandeep Kaur wrote:
> > On Fri, Oct 30, 2015 at 10:16 PM, Dario Faggioli <
> > dario.faggi...@citrix.com> wrote:
> > > The list of people you Cc-ed, is not really accurate. In fact, Ian
> > > Cam
Try to use "xen-qemudepriv-domid$domid" first, then
"xen-qemudepriv-shared" and root if everything else fails.
The uids need to be manually created by the user or, more likely, by the
xen package maintainer.
Expose a device_model_user setting in libxl_domain_build_info, so that
opinionated caller
On 30/10/15 18:33, Andrew Cooper wrote:
> This avoids a long running operation when destroying a domain with a
> large PoD cache.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://l
On Mon, 2015-10-26 at 09:47 +, Wei Liu wrote:
> The xenbus thread didn't send notification to other end when it expected
> more data or consumed responses, which led to stalling the ring from
> time to time.
>
> This is the culprit that guest was less responsive when using stubdom
> because th
On 29/10/15 10:57, Dario Faggioli wrote:
> In fact, when waking up a vCPU, __runq_tickle() is called
> to allow the new vCPU to run on a pCPU (which one, depends
> on the relationship between the priority of the new vCPU,
> and the ones of the vCPUs that are already running).
>
> If there is no id
On Fri, 2015-10-30 at 15:28 +0100, Dario Faggioli wrote:
> On Thu, 2015-10-29 at 20:28 +0530, Lasya Venneti wrote:
> >
> >
> > On 29 October 2015 at 15:41, Dario Faggioli <
> > dario.faggi...@citrix.com> wrote:
> > > On Thu, 2015-10-29 at 10:07 +, Wei Liu wrote:
>
> > > > As for xc_dom_alloc
On Mon, 2015-10-26 at 10:40 +, Wei Liu wrote:
> > + return -1;
>
> And, please set rv to a proper error code (presumably ENOMEM)
Please don't, xc_* functions should return -1 or NULL and set errno on
failure. (libxc error reporting is a bit of a mess, but this is the
intention).
S
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 s
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,
[1]
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 writ
>>> 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() providing enough data, and leverage the line number
On 02/11/15 10:54, Jan Beulich wrote:
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
>>>
>>> --- a/docs/misc/xen-command-line.mark
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 flight
1 - 100 of 114 matches
Mail list logo
