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 s
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 opera
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]: **
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 in
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,
> > i
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 en
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...)
>>> 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.markdown
>> +++ b/docs/misc/xen-command-line.markd
>>> 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
>
> The messages are not c
>>> 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
>
> The messages are not c
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 39
[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 the change and also turn the B
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 it prints.
>>>
>>> Signed-off
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 it prints.
>>>
>>> Signed-off
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
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
>>> 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
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
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]
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
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 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 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 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 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
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 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
>>> 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 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 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 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 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 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 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, 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 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 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 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 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 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 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 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 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
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: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
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 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 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 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
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: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
>>> 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 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
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 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
>>> 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, 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 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, 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 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 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
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 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
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
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 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
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 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 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, 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 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 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 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 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: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 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 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
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 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
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
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
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
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
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
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
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
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:
> 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:
> 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
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
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
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-
1 - 100 of 114 matches
Mail list logo
