>>> "Wang, Wei W" 10/26/15 7:27 AM >>>
>On 08/10/2015 12:11, Jan Beulich wrote:
>> >>> On 14.09.15 at 04:32, wrote:
>> > --- a/tools/libxc/xc_pm.c
>> > +++ b/tools/libxc/xc_pm.c
>> > @@ -260,13 +260,14 @@ int xc_get_cpufreq_para(xc_interface *xch, int
>> cpuid,
>> > }
>> > else
>> >
> -Original Message-
> From: Hu, Robert
> Sent: Sunday, October 25, 2015 10:46 AM
> To: Ian Campbell ; 'Ian Jackson'
> ; 'xen-de...@lists.xenproject.org'
>
> Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp' to `ensurebridge'
>
> > -Original Message-
flight 63303 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63303/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 5 xen-build fail REGR. vs. 63099
build-armhf
On 26/10/2015 15:03, Jan Beulich wrote:
> >>> "Wang, Wei W" 10/26/15 7:27 AM >>>
> >On 08/10/2015 12:11, Jan Beulich wrote:
> >> >>> On 14.09.15 at 04:32, wrote:
> >> > -new_policy.governor = __find_governor(op-
> >u.set_gov.scaling_governor);
> >> > -if (new_policy.governor == NULL)
>
From: Jiri Kosina
xen_blkif_schedule() kthread calls try_to_freeze() at the beginning of
every attempt to purge the LRU. This operation can't ever succeed though,
as the kthread hasn't marked itself as freezable.
Before (hopefully eventually) kthread freezing gets converted to fileystem
freez
Hi everybody
I need to understand when these pending and mask bits are set and cleared.
It seems pending bits are set by evtchn_set_pending method in
event_channel.c but I don't understand where pending bit is cleared by the
guest and where mask bit is set and reset?
Can anybody help me with unders
On 10/23/2015 05:23 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Oct 23, 2015 at 04:28:25PM +0100, Ross Lagerwall wrote:
Limitations
===
The above is enough to fully implement an update system where multiple
source patches are combined (using combinediff) and built into a single
binary which
On Sun, 2015-10-25 at 15:32 +0530, Lasya Venneti wrote:
> *This is part of my 'bite sized contribution' to Xen for the
> OutreachY program.
>
> *The change handles the return value of the function xc_dom_allocate,
> if the function returns NULL the function returns -1. It would not be
> useful to
Hello,
I just wanted to submit this as one of the bugs, the one which George
assigned to me is still pending(it's a patch series), I will submit that
ASAP. As for this bug, if I have incorrectly handled it, can you please
point out my mistake, I will correct it and re-submit.
Thanks
Lasya V
On
Thank you for pointing out the changelog errors to me, I will definitely
keep those in mind and be careful next time.
Thanks
Lasya V
On 26 October 2015 at 14:48, Lasya Venneti wrote:
> Hello,
>
> I just wanted to submit this as one of the bugs, the one which George
> assigned to me is still pen
>>> On 26.10.15 at 08:07, wrote:
> flight 63303 xen-4.5-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/63303/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-armhf 5 xen-build
On Sat, 2015-10-24 at 11:01 +0530, Harmandeep Kaur wrote:
> turning main function xl exit codes towards using the
> EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary
> numbers
> or libxl return codes.
>
I'd say "turning xl main() function exit codes..."
Also in the subject "xl: conve
>>> On 26.10.15 at 08:59, wrote:
> On 26/10/2015 15:03, Jan Beulich wrote:
>> >>> "Wang, Wei W" 10/26/15 7:27 AM >>>
>> >On 08/10/2015 12:11, Jan Beulich wrote:
>> >> >>> On 14.09.15 at 04:32, wrote:
>> >> > -new_policy.governor = __find_governor(op-
>> >u.set_gov.scaling_governor);
>> >>
For me ovmf fails to build in staging-4.6:
...
[ 541s] + ./configure --host=x86_64-suse-linux-gnu
--build=x86_64-suse-linux-gnu --program-prefix= --disable-dependency-tracking
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--sysconfdir=/etc --datadir=/usr/share --includ
>>> On 25.10.15 at 09:59, wrote:
> I modified Xen kernel to turn off the core number 1 from 80th second to
> 100th.
> In 80th second I use cpu_down which is implemented in /xen/common/cpu.c to
> turn off the 1st core. But, as you can see in below, the core does not be
> in C4 idle state shile have
> -Original Message-
> From: Hu, Robert
> Sent: Monday, October 26, 2015 3:05 PM
> To: 'Ian Campbell' ; 'Ian Jackson'
> ; 'xen-de...@lists.xenproject.org'
>
> Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp' to `ensurebridge'
>
> > -Original Message
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 the device model was stalled.
Fix this by sending notification
flight 63304 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63304/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-libvirt 3 host-install(3) broken in 63275 pass in 63304
test-amd64-amd64-libvirt-qemuu-de
On 26/10/2015 17:42, Jan Beulich wrote:
> >>> On 26.10.15 at 08:59, wrote:
> > On 26/10/2015 15:03, Jan Beulich wrote:
> >> >>> "Wang, Wei W" 10/26/15 7:27 AM >>>
> >> >On 08/10/2015 12:11, Jan Beulich wrote:
> >> >> >>> On 14.09.15 at 04:32, wrote:
> >> >> > @@ -309,23 +326,13 @@ struct xen_
>>> On 26.10.15 at 10:48, wrote:
> On 26/10/2015 17:42, Jan Beulich wrote:
>> >>> On 26.10.15 at 08:59, wrote:
>> > On 26/10/2015 15:03, Jan Beulich wrote:
>> >> >>> "Wang, Wei W" 10/26/15 7:27 AM >>>
>> >> >On 08/10/2015 12:11, Jan Beulich wrote:
>> >> >> >>> On 14.09.15 at 04:32, wrote:
>>
On Sat, 2015-10-24 at 11:01 +0530, Harmandeep Kaur wrote:
> turning scheduling related functions xl exit codes towards using the
> EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary
> numbers
> or libxl return codes.
>
"turning scheduling related xl functions exit codes..."
However, i
On Sat, 2015-10-24 at 11:01 +0530, Harmandeep Kaur wrote:
> turning vcpu manipulation functions xl exit codes toward using the
> EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary
> numbers
> or libxl return codes.
>
Again, distch "xl" from the sentence above.
Again, just one small co
On Mon, Oct 26, 2015 at 10:43:15AM +0100, Olaf Hering wrote:
> For me ovmf fails to build in staging-4.6:
>
> ...
> [ 541s] + ./configure --host=x86_64-suse-linux-gnu
> --build=x86_64-suse-linux-gnu --program-prefix= --disable-dependency-tracking
> --prefix=/usr --exec-prefix=/usr --bindir=/usr
On Sat, 2015-10-24 at 11:01 +0530, Harmandeep Kaur wrote:
> turning cpupools related functions xl exit codes towards using the
> EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary
> numbers
> or libxl return codes.
>
Ditch "xl" :-)
With that:
> Signed-off-by: Harmandeep Kaur
>
Revi
On Mon, Oct 26, Wei Liu wrote:
> On Mon, Oct 26, 2015 at 10:43:15AM +0100, Olaf Hering wrote:
> > Does it compile for anyone?
> It compiles for me -- but I'm using gcc 4.9.
I noticed that just now, fails only in Tumbleweed which used gcc-5.1.1.
Sorry for the noise.
Olaf
___
On Mon, Oct 26, 2015 at 11:11:16AM +0100, Olaf Hering wrote:
> On Mon, Oct 26, Wei Liu wrote:
>
> > On Mon, Oct 26, 2015 at 10:43:15AM +0100, Olaf Hering wrote:
>
> > > Does it compile for anyone?
> > It compiles for me -- but I'm using gcc 4.9.
>
> I noticed that just now, fails only in Tumblew
On 26/10/2015 17:54, Jan Beulich wrote:
> >>> On 26.10.15 at 10:48, wrote:
> > On 26/10/2015 17:42, Jan Beulich wrote:
> >> >>> On 26.10.15 at 08:59, wrote:
> >> > On 26/10/2015 15:03, Jan Beulich wrote:
> >> >> >>> "Wang, Wei W" 10/26/15 7:27 AM >>>
> >> >> >On 08/10/2015 12:11, Jan Beulich
On 23/10/15 11:33, Julien Grall wrote:
> The last parameter of alloc_domheap_page{s,} contain the memory flags and
> not the order of the allocation.
>
> Use 0 for the call in p2m_pod_set_cache_target as it was before
> 1069d63c5ef2510d08b83b2171af660e5bb18c63 "x86/mm/p2m: use defines for
> page s
On Sat, 2015-10-24 at 11:01 +0530, Harmandeep Kaur wrote:
> turning parsing related functions xl exit codes towards using the
> EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary
> numbers
> or libxl return codes.
>
I think the changelog, in this case, can be restructured and improved
>>> On 26.10.15 at 11:19, wrote:
> On 26/10/2015 17:54, Jan Beulich wrote:
>> That wasn't the question; I rather inquired what "meaning at the same time"
>> both fields have.
>
> turbo_enable: indicates if turbo is enabled or not.
> turbo_pct: shows the capability of turbo in percentage. For exa
On 24/10/15 12:55, David Miller wrote:
> From: Paul Durrant
> Date: Wed, 21 Oct 2015 11:36:17 +0100
>
>> This series adds xen-netback support for hash negotiation with a frontend
>> driver, and an implementation of toeplitz hashing as the initial negotiable
>> algorithm.
>
> Ping, I want to see
>>> On 26.10.15 at 11:29, wrote:
> On 23/10/15 11:33, Julien Grall wrote:
>> Note that the patch has only been build tested.
>
> It would be nice if we could properly test the codepath in question
> before checking it in, but we have lots of time before the release for
> people to find this sort
Aside from what Dario said.
On Sun, Oct 25, 2015 at 03:32:24PM +0530, Lasya Venneti wrote:
> ---
> tools/xenstore/init-xenstore-domain.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/tools/xenstore/init-xenstore-domain.c
> b/tools/xenstore/init-xenstore-domain.c
> index 0d12169..d1
On Sat, 2015-10-24 at 11:01 +0530, Harmandeep Kaur wrote:
> turning parsing related functions xl exit codes towards using the
> EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary
> numbers
> or libxl return codes.
>
> it doesn't include parse_config_data() which is big enough to deser
On Mon, Oct 26, 2015 at 1:14 PM, Jan Beulich wrote:
> ing maintained by (and hence re
I only turned off the cpu which has ID = 1 from 80th second to 100th
second. As you can see in the result of "xenpm get-cpuidle-state" in time
100.7, the residency in C0 of cpu1 is equal to C0 of cpu0! How it
On 26/10/2015 18:37, Jan Beulich wrote:
> >>> On 26.10.15 at 11:19, wrote:
> > On 26/10/2015 17:54, Jan Beulich wrote:
> >> That wasn't the question; I rather inquired what "meaning at the same time"
> >> both fields have.
> >
> > turbo_enable: indicates if turbo is enabled or not.
> > turbo_pct
Triggered by Konrad's needs for xSplice, but having been on my todo
list for a very long time to help interpretation of stack traces, here's a
revised remainder of changes allowing to tell apart identically named
static symbols. The main and general thing is to prefix them by file
name. Some remain
On 25/10/15 09:25, amin.fall...@gmail.com wrote:
> Hi everybody
> I need to understand when these pending and mask bits are set and
> cleared. It seems pending bits are set by evtchn_set_pending method in
> event_channel.c but I don't understand where pending bit is cleared by
> the guest and where
>>> On 26.10.15 at 11:40, wrote:
> On Mon, Oct 26, 2015 at 1:14 PM, Jan Beulich wrote:
>> ing maintained by (and hence re
This is rather too little context you left in place.
> I only turned off the cpu which has ID = 1 from 80th second to 100th
> second. As you can see in the result of "xenpm
>>> On 26.10.15 at 11:45, wrote:
> On 26/10/2015 18:37, Jan Beulich wrote:
>> >>> On 26.10.15 at 11:19, wrote:
>> > On 26/10/2015 17:54, Jan Beulich wrote:
>> >> That wasn't the question; I rather inquired what "meaning at the same
>> >> time"
>> >> both fields have.
>> >
>> > turbo_enable: in
On Fri, Oct 23, 2015 at 04:44:11PM +0100, Ian Jackson wrote:
> def_getopt would print a message to stderr, but blunder on anyway.
>
> Sadly this is probably not a backport candidate.
>
> Signed-off-by: Ian Jackson
Acked-by: Wei Liu
> ---
> tools/libxl/xl_cmdimpl.c |1 +
> 1 file changed,
On 26/10/15 10:40, Jan Beulich wrote:
On 26.10.15 at 11:29, wrote:
>> On 23/10/15 11:33, Julien Grall wrote:
>>> Note that the patch has only been build tested.
>>
>> It would be nice if we could properly test the codepath in question
>> before checking it in, but we have lots of time before
On 26/10/2015 18:52, Jan Beulich wrote:
> >>> On 26.10.15 at 11:45, wrote:
> > On 26/10/2015 18:37, Jan Beulich wrote:
> >> >>> On 26.10.15 at 11:19, wrote:
> >> > On 26/10/2015 17:54, Jan Beulich wrote:
> >> >> That wasn't the question; I rather inquired what "meaning at the same
> time"
> >>
>
>
> Did you look at the code generating the stats?
No.
> C0 gets accounted
> to everything not explicitly accounted to any other C state (i.e. only
> C1...Cn get explicit stats maintained).
>
> Jan
>
> I dont think so. C0 only accounted when all parts of cpu being on. I was
wondering if cpu_dow
On Mon, Oct 26, Wei Liu wrote:
> Wait, so you're using gcc-5.1.1 but OVMF is reporting gcc-4.4 (see in
> the path of output string), there might be another problem with
> toolchain detection then.
As Linus said: detect old and known to be problematic, everything else has to
be handled as "current
Hi Jan,
On 26/10/15 09:29, Jan Beulich wrote:
On 26.10.15 at 08:07, wrote:
>> flight 63303 xen-4.5-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/63303/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be r
Ping?
On 10/13/2015 03:11 PM, Juergen Gross wrote:
The Xen hypervisor supports starting a dom0 with large memory (up to
the TB range) by not including the initrd and p2m list in the initial
kernel mapping. Especially the p2m list can grow larger than the
available virtual space in the initial ma
flight 63306 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63306/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops3 host-install(3) broken in 63280 REGR. vs. 62642
build-armhf-pvops
Future work will rearange it, invalidating these assumptions.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/cpu/amd.c | 2 +-
xen/arch/x86/cpu/centaur.c | 6 ++
xen/arch/x86/cpu/common.c| 18 ++
xen/arch/x8
More patches as a result of my cpuid levelling improvement work.
These changes are all purely mechanical and neither of these two patches have
any functional change; the compiled binaries are identical other than their
timestamps.
Andrew Cooper (2):
xen/x86: Helpers for cpu feature manipuation
Expose them to assembly code, and replace open-coded versions.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/boot/head.S | 2 +-
xen/arch/x86/boot/trampoline.S | 2 +-
xen/arch/x86/cpu/common.c| 4 +-
xen/arch/x86/efi/efi-boot.h
This reverts commit 9befcd335c21818caaf5c5ab764d31a4006d2800.
This commit breaks the build:
libxl_arm.c: In function 'libxl__arch_domain_init_hw_description':
libxl_arm.c:591:76: error: 'state' undeclared (first use in this function)
libxl_arm.c:591:76: note: each undeclared identifier is repor
On 25/10/15 15:35, Meng Xu wrote:
> Hi,
Hi Meng,
> Does anyone know if Xen 4.5+ can run on Freescale IMX6 QuadCore SABRE board
> [1]?
> I found a video back to 2013 which shows an automotive demo [2] of
> Mentor Graphics' Embedded ARM Hypervisor on Freescale i.MX6 Board.
>
> I'm curious if any
>>> On 26.10.15 at 12:13, wrote:
>>>
>>>
>>> Did you look at the code generating the stats?
>>
>> No.
Then may I suggest you do so, since ...
>> C0 gets accounted
>> to everything not explicitly accounted to any other C state (i.e. only
>> C1...Cn get explicit stats maintained).
>>
>> I dont t
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 EFI
binaries' symbol tables when the file name is longer than 18
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
be prefixed by a suitable path. We can't do this without explicit .file
directives, since gcc has always been stripping paths from file names
handed to the i
To make it possible to tell apart the static symbols therein, use their
object file names instead of their source ones.
Signed-off-by: Jan Beulich
---
v2: Introduce __OBJECT_FILE__.
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -42,10 +42,10 @@ ALL_OBJS-y += $(BASEDIR)/x
ALL_OBJS-y
flight 38212 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38212/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-i386-sid-netboot-pygrub 9 debian-di-install fail like 38180
test-amd64-i386-amd
From: David Vrabel
Date: Mon, 26 Oct 2015 10:38:50 +
> On 24/10/15 12:55, David Miller wrote:
>> From: Paul Durrant
>> Date: Wed, 21 Oct 2015 11:36:17 +0100
>>
>>> This series adds xen-netback support for hash negotiation with a frontend
>>> driver, and an implementation of toeplitz hashing
It doesn't depend on GUEST_PAGING_LEVELS. Moving the function to p2m.c
at once allows a bogus #define/#include pair to be removed from
hap/nested_ept.c.
Signed-off-by: Jan Beulich
---
v2: To ensure no dependency on GUEST_PAGING_LEVELS, move the function
to p2m.c.
--- a/xen/arch/x86/mm/guest_
None of its elements depends on GUEST_PAGING_LEVELS.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
v2: Re-base on top of earlier changes.
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -32,30 +32,32 @@ asm(".file \"" __OBJECT_FILE__ "\"");
#include
#incl
On 16.09.2015 23:01, Konrad Rzeszutek Wilk wrote:
[...]
> +### xsplice_patch
> +
> +This structure has the binary code (or data) to be patched. Depending on the
> +type it can either an inline patch (data or text) or require an relocation
> +change (which requires a trampoline). Naturally it also
Hello,
Indeed, notification seems to have been missing since basically 2006...
Wei Liu, le Mon 26 Oct 2015 09:47:48 +, a écrit :
> diff --git a/xenbus/xenbus.c b/xenbus/xenbus.c
> index 4613ed6..7451161 100644
> --- a/xenbus/xenbus.c
> +++ b/xenbus/xenbus.c
> @@ -205,8 +205,10 @@ static void
Hi, i'm getting this problem with linux 4.3.0-rcX branch.
Full log is attached. My hardware is based on intel skylake i7-6700k on
z170 chipset and it is working properly. It does boot correctly with
older kernels (3.12).
With mce=off on xen parameters it does boot unti during pci detection
where it
On Mon, Oct 26, 2015 at 12:13:40PM +0100, Olaf Hering wrote:
> On Mon, Oct 26, Wei Liu wrote:
>
> > Wait, so you're using gcc-5.1.1 but OVMF is reporting gcc-4.4 (see in
> > the path of output string), there might be another problem with
> > toolchain detection then.
>
> As Linus said: detect old
>>> On 26.10.15 at 12:17, wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -202,7 +202,7 @@ static void __init early_cpu_detect(void)
> c->x86_mask = tfms & 15;
> cap0 &= ~cleared_caps[0];
> cap4 &= ~cleared_caps[4];
> - if (cap0 & (1<<19))
> +
>>> On 26.10.15 at 13:01, wrote:
> On 16.09.2015 23:01, Konrad Rzeszutek Wilk wrote:
>> +The convention for file-type symbols (that would allow to map many
>> +symbols to their compilation unit) says that only the basename (i.e.,
>> +without directories) is embedded. This creates another layer of
On Mon, Oct 26, 2015 at 01:02:45PM +0100, Samuel Thibault wrote:
> Hello,
>
> Indeed, notification seems to have been missing since basically 2006...
>
> Wei Liu, le Mon 26 Oct 2015 09:47:48 +, a écrit :
> > diff --git a/xenbus/xenbus.c b/xenbus/xenbus.c
> > index 4613ed6..7451161 100644
> >
Wei Liu, le Mon 26 Oct 2015 12:14:43 +, a écrit :
> In my patch, mini-os notifies remote whenever it consumes a message,
> which I think it's slightly better because backend can start putting
> things in the ring as mini-os processes them.
That makes more notifications, but that can lead to mo
On Mon, Oct 26, 2015 at 01:21:51PM +0100, Samuel Thibault wrote:
> Wei Liu, le Mon 26 Oct 2015 12:14:43 +, a écrit :
> > In my patch, mini-os notifies remote whenever it consumes a message,
> > which I think it's slightly better because backend can start putting
> > things in the ring as mini-o
Wei Liu, le Mon 26 Oct 2015 12:30:28 +, a écrit :
> On Mon, Oct 26, 2015 at 01:21:51PM +0100, Samuel Thibault wrote:
> > Wei Liu, le Mon 26 Oct 2015 12:14:43 +, a écrit :
> > > In my patch, mini-os notifies remote whenever it consumes a message,
> > > which I think it's slightly better beca
On Mon, Oct 26, 2015 at 01:33:12PM +0100, Samuel Thibault wrote:
> Wei Liu, le Mon 26 Oct 2015 12:30:28 +, a écrit :
> > On Mon, Oct 26, 2015 at 01:21:51PM +0100, Samuel Thibault wrote:
> > > Wei Liu, le Mon 26 Oct 2015 12:14:43 +, a écrit :
> > > > In my patch, mini-os notifies remote when
On 26/10/15 12:06, Jan Beulich wrote:
On 26.10.15 at 12:17, wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -202,7 +202,7 @@ static void __init early_cpu_detect(void)
>> c->x86_mask = tfms & 15;
>> cap0 &= ~cleared_caps[0];
>> cap4 &= ~cleared
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 the device model was stalled.
Fix this by sending notification
On 26/10/15 11:51, Jan Beulich wrote:
> To make it possible to tell apart the static symbols therein, use their
> object file names instead of their source ones.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-
Wei Liu, le Mon 26 Oct 2015 12:47:56 +, a écrit :
> -if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons <
> sizeof(msg))
> +if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons <
> sizeof(msg)) {
> +notify_remote_via_evtchn(start_info.store_evtchn);
>
On 26/10/15 11:52, Jan Beulich wrote:
> It doesn't depend on GUEST_PAGING_LEVELS. Moving the function to p2m.c
> at once allows a bogus #define/#include pair to be removed from
> hap/nested_ept.c.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
>>> 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 @@ __initcall(pagealloc_keyhandler_init);
>
> void scrub_one_page(struct
>>> On 19.10.15 at 16:53, wrote:
> --- a/tools/libxc/xc_sr_save.c
> +++ b/tools/libxc/xc_sr_save.c
> @@ -537,7 +537,8 @@ static int suspend_and_send_dirty(struct
> if ( xc_shadow_control(
> xch, ctx->domid, XEN_DOMCTL_SHADOW_OP_CLEAN,
> HYPERCALL_BUFFER(dirty_bitma
>>> On 22.10.15 at 19:13, wrote:
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -583,6 +583,68 @@ out:
> return ret;
> }
>
> +static int register_one_rmrr(struct acpi_rmrr_unit *rmrru)
> +{
> +bool_t ignore = 0;
> +unsigned int i = 0;
> +
On 10/26/2015 12:01 PM, Martin Pohlack wrote:
On 16.09.2015 23:01, Konrad Rzeszutek Wilk wrote:
[...]
+### xsplice_patch
+
+This structure has the binary code (or data) to be patched. Depending on the
+type it can either an inline patch (data or text) or require an relocation
+change (which re
>>> On 22.10.15 at 19:13, wrote:
> From: Elena Ufimtseva
>
> On some platforms RMRR regions may be not specified in ACPI and thus will not
> be mapped 1:1 in dom0.
I think this may be misleading to readers: It sounds as if there was
the option for RMRRs to not be specified in ACPI tables, while
OUR THEME OF THE MONTH: "Ready for 4.6"
This month, we continue with the effort to make the Wiki reflect the
realities of the 4.6 release. Many pages need reviewing and may need
updating. Main tasks include:
- Add new documentation for new features
- Modify existing documentation for anything w
On Mon, Oct 26, 2015 at 01:52:47PM +0100, Samuel Thibault wrote:
> Wei Liu, le Mon 26 Oct 2015 12:47:56 +, a écrit :
> > -if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons <
> > sizeof(msg))
> > +if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons <
> > sizeof(msg))
On Mon, Oct 26, 2015 at 01:21:46PM +, Ross Lagerwall wrote:
> On 10/26/2015 12:01 PM, Martin Pohlack wrote:
> >On 16.09.2015 23:01, Konrad Rzeszutek Wilk wrote:
> >
> >[...]
> >
> >>+### xsplice_patch
> >>+
> >>+This structure has the binary code (or data) to be patched. Depending on
> >>the
>
>>> On 23.10.15 at 11:48, wrote:
> 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
>>> On 23.10.15 at 11:48, wrote:
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -23,8 +23,8 @@ static u32 __read_mostly xsave_cntxt_size;
>
> /* A 64-bit bitmask of the XSAVE/XRSTOR features supported by processor. */
> u64 __read_mostly xfeature_mask;
> -static unsigned int
> On 22 Oct 2015, at 16:04, George Dunlap wrote:
>
> On Wed, Oct 21, 2015 at 4:02 PM, Stefano Stabellini
> wrote:
>>> ! = Summary =
>>> !
>>> ! There seems to be a clear consensus against the current veto model. From
>>> ! the comments there was no clear case for a simple majority, but for a
>
On 26.10.2015 12:51, Jan Beulich wrote:
> To make it possible to tell apart the static symbols therein, use their
> object file names instead of their source ones.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Introduce __OBJECT_FILE__.
>
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -42,10 +42,10
Hey,
Here I am reviewing this patch, sorry for the delay.
Ok, we have discussed a lot about all this, and in fact I had to go
back in my mail archive and re-read the rather long sub-thread for this
patch in v7. :-)
Also, in that thread, I found (as I was recalling there being) a couple of open
On Wed, Oct 21, 2015 at 04:24:14PM +0100, Ian Campbell wrote:
> We intend to stabilise some parts of the libxenctrl interface by
> splitting out some functionality into separate stable libraries.
>
> This is the mini-os part of the first phase of that change.
>
> This mail is (or is intended to b
On 23/09/15 16:34, Jan Beulich wrote:
> Us extending the GDT limit past the Xen descriptors so far meant that
> guests (including user mode programs) accessing any descriptor table
> slot above the original OS'es limit but below the first Xen descriptor
> caused a #PF, converted to a #GP in our #PF
On Fri, Oct 23, 2015 at 05:44:44PM +0800, Joe Jin wrote:
> Should not allocate xen vif queues number more than online cpus.
I think it's absolutely fine for administrators to override the value
should they choose to.
Wei.
___
Xen-devel mailing list
Xen
On 26/10/15 14:34, Martin Pohlack wrote:
> On 26.10.2015 12:51, Jan Beulich wrote:
>> To make it possible to tell apart the static symbols therein, use their
>> object file names instead of their source ones.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> v2: Introduce __OBJECT_FILE__.
>>
>> --- a/xen
On 26/10/15 14:55, Andrew Cooper wrote:
> On 26/10/15 14:43, David Vrabel wrote:
>> On 23/09/15 16:34, Jan Beulich wrote:
>>> Us extending the GDT limit past the Xen descriptors so far meant that
>>> guests (including user mode programs) accessing any descriptor table
>>> slot above the original OS
On 26/10/15 11:52, Jan Beulich wrote:
> It doesn't depend on GUEST_PAGING_LEVELS. Moving the function to p2m.c
> at once allows a bogus #define/#include pair to be removed from
> hap/nested_ept.c.
>
> Signed-off-by: Jan Beulich
> ---
> v2: To ensure no dependency on GUEST_PAGING_LEVELS, move the
On 26/10/15 11:53, Jan Beulich wrote:
> None of its elements depends on GUEST_PAGING_LEVELS.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Andrew Cooper
> ---
> v2: Re-base on top of earlier changes.
Acked-by: George Dunlap
>
> --- a/xen/arch/x86/mm/guest_walk.c
> +++ b/xen/arch/x86/mm/guest
On 26/10/15 14:43, David Vrabel wrote:
> On 23/09/15 16:34, Jan Beulich wrote:
>> Us extending the GDT limit past the Xen descriptors so far meant that
>> guests (including user mode programs) accessing any descriptor table
>> slot above the original OS'es limit but below the first Xen descriptor
>
On Mon, Oct 26, 2015 at 08:35:30AM +, Ross Lagerwall wrote:
> On 10/23/2015 05:23 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Oct 23, 2015 at 04:28:25PM +0100, Ross Lagerwall wrote:
> >>Limitations
> >>===
> >>The above is enough to fully implement an update system where multiple
> >>so
>>> On 26.10.15 at 15:58, wrote:
> On 26/10/15 14:55, Andrew Cooper wrote:
>> On 26/10/15 14:43, David Vrabel wrote:
>>> On 23/09/15 16:34, Jan Beulich wrote:
Us extending the GDT limit past the Xen descriptors so far meant that
guests (including user mode programs) accessing any descrip
1 - 100 of 184 matches
Mail list logo
