[Xen-devel] [distros-debian-sid test] 66612: tolerable trouble: blocked/broken

flight 66612 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66612/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-armhf-pvops 3 host-install(3) broken like 66555 build-armhf

[Xen-devel] [PATCH v2 1/5] xenstore: call each xenstored command function with temporary context

In order to be able to avoid leaving temporary memory allocated after processing of a command in xenstored call all command functions with the temporary "in" context. Each function can then make use of that temporary context for allocating temporary memory instead of either leaving that memory allo

[Xen-devel] [PATCH v2 4/5] xenstore: add explicit memory context parameter to get_node()

Add a parameter to xenstored get_node() function to explicitly specify the memory context to be used for allocations. This will make it easier to avoid memory leaks by using a context which is freed soon. This requires adding the temporary context to errno_from_parents() and ask_parents(), too. W

[Xen-devel] [PATCH v2 3/5] xenstore: add explicit memory context parameter to read_node()

Add a parameter to xenstored read_node() function to explicitly specify the memory context to be used for allocations. This will make it easier to avoid memory leaks by using a context which is freed soon. When calling read_node() select a sensible memory context for the new parameter by preferrin

[Xen-devel] [PATCH v2 2/5] xenstore: add explicit memory context parameter to get_parent()

Add a parameter to xenstored get_parent() function to explicitly specify the memory context to be used for allocations. This will make it easier to avoid memory leaks by using a context which is freed soon. When available use a temporary context when calling get_parent(), otherwise mimic the old b

[Xen-devel] [PATCH v2 0/5] xenstore: fix memory leak of xenstored

xenstored has a memory leak when setting watches: a no longer active watch which fired in the past will still use some memory. This is critical for long running connections to xenstored like the qemu process serving as a qdisk backend for dom0. It will use some few kB in xenstored for each domain c

[Xen-devel] [PATCH v2 5/5] xenstore: use temporary memory context for firing watches

Use a temporary memory context for memory allocations when firing watches. This will avoid leaking memory in case of long living connections and/or xenstore entries. This requires adding a new parameter to fire_watches() and add_event() to specify the memory context to use for allocations. Signed

Re: [Xen-devel] [RFC Design Doc v2] Add vNVDIMM support for Xen

> From: Zhang, Haozhong > Sent: Monday, July 18, 2016 8:29 AM > > Hi, > > Following is version 2 of the design doc for supporting vNVDIMM in > Xen. It's basically the summary of discussion on previous v1 design > (https://lists.xenproject.org/archives/html/xen-devel/2016-02/msg6.html). > Any

Re: [Xen-devel] [RFC Design Doc v2] Add vNVDIMM support for Xen

On 07/18/16 16:36, Tian, Kevin wrote: > > From: Zhang, Haozhong > > Sent: Monday, July 18, 2016 8:29 AM > > > > Hi, > > > > Following is version 2 of the design doc for supporting vNVDIMM in > > Xen. It's basically the summary of discussion on previous v1 design > > (https://lists.xenproject.org/

[Xen-devel] [PATCH] xen/x86: Identify legitimate fallthrough cases

The case in arch_set_info_guest() is a legitimate fallthrough. Mark it as such. The cases in vlapic_accept_irq() are a terminal error path, but Coverity fails to spot this. Reorder the comment to the end. No functional change, but fixes two MISSING_BREAK Coverity defects. Signed-off-by: Andrew

Re: [Xen-devel] [PATCH 2/3] Update to use a .config file

On 07/16/2016 02:55 AM, Konrad Rzeszutek Wilk wrote: OK, I'll split it into two. Feel free to create a stable-47 branch in livepatch-build-tools.git with only the .config patch. Personally, I'd rather not spend much time backporting stuff to support a tech preview feature on an older branch. We

[Xen-devel] [PATCH 8/9] x86/hypercall: Merge the hypercall arg tables

For the same reason as c/s 33a231e3f "x86/HVM: fold hypercall tables" and (TODO - changeset) "x86/pv: Merge the pv hypercall tables", this removes the risk of accidentally updating only one of the tables. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/hvm/hvm.c | 8

[Xen-devel] [PATCH 5/9] x86/hypercall: Move the hypercall tables into C

Editing (and indeed, finding) the hypercall tables can be tricky, especially towards the end where .rept's are used to maintain the correct layout. Move this all into C, and let the compiler do the hard work. To do this, xen/hypercall.h and asm-x86/hypercall.h need to contain prototypes for all t

[Xen-devel] [PATCH 7/9] x86/pv: Merge the pv hypercall tables

For the same reason as c/s 33a231e3f "x86/HVM: fold hypercall tables", this removes the risk of accidentally updating only one of the tables. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/hypercall.c | 75 +--- 1 file changed, 13 i

[Xen-devel] [PATCH 9/9] x86/hypercall: Reduce the size of the hypercall tables

The highest populated entry in each hypercall table is currently at index 49. There is no need to extend both to tables to 64 entries. Range check eax against the hypercall table array size, and use a BUILD_BUG_ON() to ensure that the hypercall tables don't grow larger than the args table. Signed

[Xen-devel] [PATCH 4/9] x86/pv: Implement pv_hypercall() in C

In a similar style to hvm_do_hypercall(). The C version is far easier to understand and edit than the assembly versions. There are a few small differences however. The register clobbering values have changed (to match the HVM side), and in particular clobber the upper 32bits of 64bit arguments.

[Xen-devel] [PATCH 6/9] xen/multicall: Rework arch multicall handling

The x86 multicall handling was previously some very hairy inline assembly, and is hard to follow and maintain. Replace the existing do_multicall_call() with arch_do_multicall_call(). The x86 side needs to handle both compat and non-compat calls, so pass the full multicall state, rather than just

Re: [Xen-devel] [PATCH] xen/x86: Identify legitimate fallthrough cases

On 18/07/16 10:30, Andrew Cooper wrote: > The case in arch_set_info_guest() is a legitimate fallthrough. Mark it as > such. > > The cases in vlapic_accept_irq() are a terminal error path, but Coverity fails > to spot this. Reorder the comment to the end. > > No functional change, but fixes two

[Xen-devel] [PATCH 2/9] x86/pv: Support do_set_segment_base() for compat guests

set_segment_base is the only hypercall exists in only one of the two modes guests might run in; all other hypercalls are either implemented, or unimplemented in both modes. Remove this split, by allowing do_set_segment_base() to be called in the compat hypercall path. This change will simplify th

[Xen-devel] [PATCH 0/9] x86: Move the pv hypercall into C

I decided to dust off this series, and found it had been accumulating dust for 18 months. Oops. There is no practical change from the point of view of guests, but: * There is a net reduction in LoC * There is a net reduction in compiled size (according to bloat-o-meter) * Easier to maintain/e

[Xen-devel] [PATCH 1/9] x86/hypercall: Move some of the hvm hypercall infrastructure into hypercall.h

It will be reused for PV hypercalls in subsequent changes. * Rename hvm_hypercall_t to hypercall_fn_t * Introduce hypercall_table_t Finally, rework the #includes for hypercall.h so it may be included in isolation. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/hvm/hvm.c

[Xen-devel] [PATCH 3/9] x86/hypercall: Move the hypercall arg tables into C

Editing (and indeed, finding) the hypercall args tables can be tricky, especially towards the end where .rept's are used to maintain the correct layout. Move this all into C, and let the compiler do the hard work. As 0 is the default value, drop all explicit 0's. No functional change. Signed-of

Re: [Xen-devel] [PATCH 1/3] xen: Some code motion to avoid having to do forward-declaration

On Fri, 2016-07-15 at 19:02 +0100, George Dunlap wrote: > For sched_credit2, move the vcpu insert / remove / free functions > near the domain > insert / remove / alloc / free functions (and after cpu_pick). > > For sched_rt, move rt_cpu_pick() further up. > > This is pure code motion; no function

Re: [Xen-devel] [PATCH 3/3] xen: Remove buggy initial placement algorithm

On 16/07/16 14:55, Dario Faggioli wrote: > On Fri, 2016-07-15 at 19:02 +0100, George Dunlap wrote: >> The initial placement algorithm sometimes picks cpus outside of the >> mask it's given, does a lot of unnecessary bitmasking, does its own >> separate load calculation, and completely ignores vcpu

Re: [Xen-devel] [PATCH 1/3] xen: Some code motion to avoid having to do forward-declaration

On 18/07/16 10:58, Dario Faggioli wrote: > On Fri, 2016-07-15 at 19:02 +0100, George Dunlap wrote: >> For sched_credit2, move the vcpu insert / remove / free functions >> near the domain >> insert / remove / alloc / free functions (and after cpu_pick). >> >> For sched_rt, move rt_cpu_pick() further

[Xen-devel] Xen-unstable 4.8: Host crash when shutting down guest with pci device passed through using MSI-X interrupts.

Hi Jan, It seems that since your patch series starting with commit: 2016-06-22 x86/vMSI-X: defer intercept handler registration 74c6dc2d0ac4dcab0c6243cdf6ed550c1532b798 The shutdown of a guest which has a PCI device passed through which uses MSI-X interrupts causes a host crash, see the splat b

Re: [Xen-devel] [PATCH 2/3] Update to use a .config file

On Mon, Jul 18, 2016 at 10:33:49AM +0100, Ross Lagerwall wrote: > On 07/16/2016 02:55 AM, Konrad Rzeszutek Wilk wrote: > > > > OK, I'll split it into two. Feel free to create a stable-47 branch in > > > > livepatch-build-tools.git with only the .config patch. Personally, I'd > > > > rather not spen

Re: [Xen-devel] [PATCH 2/3] xen: Have schedulers revise initial placement

On Fri, 2016-07-15 at 19:02 +0100, George Dunlap wrote: > The generic domain creation logic in > xen/common/domctl.c:default_vcpu0_location() attempts to try to do > initial placement load-balancing by placing vcpu 0 on the least-busy > non-primary hyperthread available.  Unfortunately, the logic c

[Xen-devel] [linux-3.18 test] 97533: regressions - FAIL

flight 97533 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/97533/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 96188 test-amd64-amd64-

Re: [Xen-devel] [PATCH v4] altp2m: Allow the hostp2m entries to be of type p2m_ram_shared

On Fri, Jul 15, 2016 at 3:59 PM, Tamas K Lengyel wrote: >> I could go on in the analysis, but the point is that there's a morass >> of interactions here all of which need to be correct, which this patch >> does not address. You have a long way to go before sharing and altp2m >> can be safely used

[Xen-devel] Linux 3.18 and Linux 4.1 reproducible OOM crashes under Xen

The Xen Project CI system (`osstest') reports that the current tip of the Linux 3.18 and Linux 4.1 stable branches have serious problems booting Xen. Our automatic bisector has completed its work and fingered (in 3.18) a2d8c5147532 "mm/swap.c: flush lru pvecs on compound page arrival" (and a backp

Re: [Xen-devel] Linux 3.18 and Linux 4.1 reproducible OOM crashes under Xen

On Mon 18-07-16 12:17:58, Ian Jackson wrote: > The Xen Project CI system (`osstest') reports that the current tip of > the Linux 3.18 and Linux 4.1 stable branches have serious problems > booting Xen. > > Our automatic bisector has completed its work and fingered (in 3.18) > a2d8c5147532 "mm/swap.

Re: [Xen-devel] Linux 3.18 and Linux 4.1 reproducible OOM crashes under Xen

On Mon 18-07-2016 1:26 PM, Michal Hocko wrote: > Yes, this patch has been misbackported to the stable tree (at least 4.1 > and maybe others which took it over from there). See > http://lkml.kernel.org/r/20160714175521.3675e...@gandalf.local.home Symptoms looks similar to this one: http://marc.info

Re: [Xen-devel] [PATCH] credi2-ratelimit: Implement rate limit for credit2 scheduler

On 13/07/16 09:53, Dario Faggioli wrote: On Tue, 2016-07-12 at 17:16 +0100, George Dunlap wrote: On Wed, Jul 6, 2016 at 6:33 PM, Makkar anshul.mak...@citrix.com wrote: --- a/xen/common/sched_credit2.c +++ b/xen/common/sched_credit2.c +#define MAX_TSLICE(t1, t2) \ + ({ typeo

[Xen-devel] [PATCH v2 1/1] ratelimit: Implement rate limit for credit2 scheduler Rate limit assures that a vcpu will execute for a minimum amount of time before being put at the back of a queue or bei

It introduces a minimum amount of latency to enable a VM to batch its work and it also ensures that system is not spending most of its time in VMEXIT/VMENTRY because of VM that is waking/sleeping at high rate. ratelimit can be disabled by setting it to 0. Signed-off-by: Anshul Makkar --- Changes

[Xen-devel] [linux-4.1 bisection] complete test-amd64-i386-qemut-rhel6hvm-amd

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-qemut-rhel6hvm-amd testid redhat-install Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-

Re: [Xen-devel] [PATCH v2 1/2] xen: fix a (latent) cpupool-related race during domain destroy

On Fri, 2016-07-15 at 16:23 +0200, Dario Faggioli wrote: > On Fri, 2016-07-15 at 14:52 +0200, Juergen Gross wrote: > > On 15/07/16 13:52, Dario Faggioli wrote: > > > Therefore, I still think this patch is correct, but I'm up for > > > investigating further and finding a way to solve the "zombie in

[Xen-devel] [OSSTEST PATCH 5/5] sg-execute-flight: Fix an error message

When pid is undefined, meaning we didn't find gotpid, print gotpid, not pid. Signed-off-by: Ian Jackson --- sg-execute-flight | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sg-execute-flight b/sg-execute-flight index 4e3fcf2..fd98291 100755 --- a/sg-execute-flight +++ b/sg-e

[Xen-devel] [OSSTEST PATCH 2/5] ms-flights-summary: Do gather_stats without GROUP BY

We are going to want to look at each job's Reso separately. Signed-off-by: Ian Jackson --- ms-flights-summary | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/ms-flights-summary b/ms-flights-summary index 413b703..98cca90 100755 --- a/ms-flights-summary +++ b/ms-fligh

[Xen-devel] [OSSTEST PATCH 4/5] ms-flights-summary: Treat preparing jobs outside the plan as `queued'

These jobs are still to run but we have no time estimate for them. So do not add them to UnqueuedJobs; they then contribute to making the `End of phase/flight' indication *not* bold when there are such jobs. And bolden their figure in the table. Signed-off-by: Ian Jackson --- ms-flights-summar

[Xen-devel] [OSSTEST PATCH 3/5] ms-flights-summary: Invent a `prep.alloc.' pseudo job state

This allows us to separate out `preparing' jobs into ones which are in our data plan and ones which are not. The ones which are not may not have quite started to run ts-hosts-allocate, or may still be in the planning queue and not made it into the projection. In either case we don't have an estim

[Xen-devel] [OSSTEST PATCH 1/5] ms-flights-summary: Do gather_stats on jobs a bit later

We are going to want to invent a fake status for `preparing' jobs which have no allocation, separate from ones which do have an allocation. Signed-off-by: Ian Jackson --- ms-flights-summary | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/ms-flights-summary b/ms-flights-su

Re: [Xen-devel] [PATCH v2 1/2] xen: fix a (latent) cpupool-related race during domain destroy

On 18/07/16 16:03, Dario Faggioli wrote: > On Fri, 2016-07-15 at 16:23 +0200, Dario Faggioli wrote: >> On Fri, 2016-07-15 at 14:52 +0200, Juergen Gross wrote: >>> On 15/07/16 13:52, Dario Faggioli wrote: Therefore, I still think this patch is correct, but I'm up for investigating further

[Xen-devel] [PATCH] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

ACPI builder is currently distributed under GPLv2 license. We plan to make the builder available to components other than the hvmloader (which is also GPLv2). Some of these components (such as libxl) may be distributed under LGPL-2.1 so that they can be used by non-GPLv2 callers. But this will no

[Xen-devel] [PATCH v2 3/3] x86/emulate: added tests for {, v}movd mm, m32

Signed-off-by: Mihai Donțu --- tools/tests/x86_emulator/test_x86_emulator.c | 42 1 file changed, 42 insertions(+) diff --git a/tools/tests/x86_emulator/test_x86_emulator.c b/tools/tests/x86_emulator/test_x86_emulator.c index 8994149..e2bd7ce 100644 --- a/tools/test

Re: [Xen-devel] [PATCH v2 01/11] xen: sched: leave CPUs doing tasklet work alone.

On 15/07/16 15:49, Dario Faggioli wrote: > In both Credit1 and Credit2, stop considering a pCPU idle, > if the reason why the idle vCPU is being selected, is to > do tasklet work. > > Not doing so means that the tickling and load balancing > logic, seeing the pCPU as idle, considers it a candidate

Re: [Xen-devel] [PATCH v2 1/3] x86/emulate: add support for {, v}movq xmm, xmm/m64

On 18/07/16 15:30, Mihai Donțu wrote: > Signed-off-by: Mihai Donțu > --- > Changed since v1: > * added a test for vmovq > * made the tests depend on SSE and AVX, respectively > * added emulator support for vmovq (0xd6 forces the operand size to >64bit) > --- > tools/tests/x86_emulator/test

[Xen-devel] [PATCH v2 2/3] x86/emulate: add support of emulating SSE2 instruction {, v}movd mm, m32

Found that Windows driver was using a SSE2 instruction MOVD. Signed-off-by: Zhi Wang Signed-off-by: Mihai Donțu --- Picked from the XenServer 7 patch queue, as suggested by Andrew Cooper --- xen/arch/x86/x86_emulate/x86_emulate.c | 30 +++--- 1 file changed, 27 insertion

[Xen-devel] [PATCH v2 1/3] x86/emulate: add support for {, v}movq xmm, xmm/m64

Signed-off-by: Mihai Donțu --- Changed since v1: * added a test for vmovq * made the tests depend on SSE and AVX, respectively * added emulator support for vmovq (0xd6 forces the operand size to 64bit) --- tools/tests/x86_emulator/test_x86_emulator.c | 44 xen/a

Re: [Xen-devel] [PATCH v2 03/11] xen: credit2: rework load tracking logic

On 15/07/16 15:49, Dario Faggioli wrote: > The existing load tracking code was hard to understad and > maintain, and not entirely consistent. This is due to a > number of reasons: > - code and comments were not in perfect sync, making it >difficult to figure out what the intent of a particular

Re: [Xen-devel] [PATCH 01/19] xen: Create a new file xen_pvdev.c

On Sun, Jul 17, 2016 at 03:41:26PM +0800, Quan Xu wrote: > > [Quan:]: comment starts with [Quan:] > > > The purpose of the new file is to store generic functions shared by  > frontendand backends such as xenstore operations, xendevs. > > Signed-off-by: Quan Xu  > Signed-off-by: Emil Condrea  >

Re: [Xen-devel] [PATCH v2 03/11] xen: credit2: rework load tracking logic

On Mon, 2016-07-18 at 15:46 +0100, George Dunlap wrote: > On 15/07/16 15:49, Dario Faggioli wrote: > >  > > This may look handy, but it introduced a (not especially well > > documented) dependency between the lenght of the window and > > the precision of the calculations, which really should be > >

Re: [Xen-devel] [PATCH v2 3/3] x86/emulate: added tests for {, v}movd mm, m32

On 18/07/16 15:30, Mihai Donțu wrote: > Signed-off-by: Mihai Donțu Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 2/3] x86/emulate: add support of emulating SSE2 instruction {, v}movd mm, m32

On 18/07/16 15:30, Mihai Donțu wrote: > @@ -4409,6 +4409,10 @@ x86_emulate( > case 0x6f: /* movq mm/m64,mm */ > /* {,v}movdq{a,u} xmm/m128,xmm */ > /* vmovdq{a,u} ymm/m256,ymm */ > +case 0x7e: /* movd mm,r/m32 */ > + /* movq mm,r/m64 */ > +

Re: [Xen-devel] [PATCH 01/19] xen: Create a new file xen_pvdev.c

On 07/17/2016 01:41 AM, Quan Xu wrote: > > [Quan:]: comment starts with [Quan:] > This line doesn't belong in a commit message; it's fine to put it after the --- separator though, if it aids mailing list reviewers. > > The purpose of the new file is to store generic functions shared by > fron

Re: [Xen-devel] [PATCH v2 06/11] xen: credit2: make the code less experimental

On 15/07/16 15:49, Dario Faggioli wrote: > Mainly, almost all of the BUG_ON-s can be converted into > ASSERTS, and almost all the debug printk can either be > removed or turned into tracing. > > The 'TODO' list, in a comment at the beginning of the file, > was also stale, so remove items that were

Re: [Xen-devel] OVMF very slow on AMD

On Fri, Jul 15, 2016 at 09:48:31AM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Jul 14, 2016 at 04:53:07PM +0100, Anthony PERARD wrote: > > So, this loop takes about 1 minute on my AMD machine (AMD Opteron(tm) > > Processor 4284), and less that 1 second on an Intel machine. > > If I compile OVMF a

Re: [Xen-devel] [PATCH v2 08/11] xen: credit2: only marshall trace point arguments if tracing enabled

On 15/07/16 15:50, Dario Faggioli wrote: > Signed-off-by: Dario Faggioli It seems a bit strange not to have anything in the "body" of the changeset here, but I can't think of anything in particular to say here, so: Reviewed-by: George Dunlap Thanks > --- > Cc: George Dunlap > Cc: Anshul Makk

Re: [Xen-devel] [PATCH v4] altp2m: Allow the hostp2m entries to be of type p2m_ram_shared

On Mon, Jul 18, 2016 at 5:04 AM, George Dunlap wrote: > On Fri, Jul 15, 2016 at 3:59 PM, Tamas K Lengyel wrote: >>> I could go on in the analysis, but the point is that there's a morass >>> of interactions here all of which need to be correct, which this patch >>> does not address. You have a lo

Re: [Xen-devel] xenbits "official" repo for XTF (was Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)

On 18/07/2016 15:36, "Ian Jackson" wrote: >Lars Kurth writes ("Re: [Xen-devel] xenbits "official" repo for XTF (was >Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)"): >> On 15/07/2016 11:21, "Ian Jackson" wrote: >> >Lars, you haven't specified the pathname for this. I assume that it >> >would

Re: [Xen-devel] xenbits "official" repo for XTF (was Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)

Lars Kurth writes ("Re: [Xen-devel] xenbits "official" repo for XTF (was Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)"): > On 15/07/2016 11:21, "Ian Jackson" wrote: > >Lars, you haven't specified the pathname for this. I assume that it > >would be `xtf', to correspond to the toplevel fit repo.

Re: [Xen-devel] [PATCH] xen/domctl: Add DOMINFO_hap to xen_domctl_getdomaininfo

On Fri, Jul 15, 2016 at 05:57:45PM +0100, Andrew Cooper wrote: > This allows a toolstack to identify whether a running domain is using hardware > assisted paging or not. > > The appropriate tests differ by architecture, so introduce > arch_get_domain_info(). ARM unconditionally sets the new flag,

Re: [Xen-devel] [PATCH v4] altp2m: Allow the hostp2m entries to be of type p2m_ram_shared

On 18/07/16 16:18, Tamas K Lengyel wrote: > On Mon, Jul 18, 2016 at 5:04 AM, George Dunlap > wrote: >> On Fri, Jul 15, 2016 at 3:59 PM, Tamas K Lengyel wrote: I could go on in the analysis, but the point is that there's a morass of interactions here all of which need to be correct, whi

Re: [Xen-devel] xenbits "official" repo for XTF (was Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)

Lars Kurth writes ("Re: [Xen-devel] xenbits "official" repo for XTF (was Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)"): > I don't object to a new xtf directory in the docs root per se. I mainly > object to how the documents are presented in > http://xenbits.xen.org/docs/unstable The documents u

[Xen-devel] Is: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-ad...@xenproject.org: [linux-4.1 bisection] complet

Hey Lukasz, We found that your patch in the automated Xen test-case ends up OOMing the box when trying to install guests. This worked prior to your patch. See serial log: http://logs.test-lab.xenproject.org/osstest/logs/97597/test-amd64-i386-qemut-rhel6hvm-amd/serial-pinot0.log Would it be OK to

Re: [Xen-devel] xenbits "official" repo for XTF (was Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)

Lars Kurth writes ("Re: [Xen-devel] xenbits "official" repo for XTF (was Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)"): > If there is a link between directory structure and web index, my preferred > alternative to creating the two separate directories would be to group all > the test related doc

Re: [Xen-devel] [PATCH v3] libxl: trigger attach events for devices attached before xl devd startup

On Sat, Jul 16, 2016 at 01:47:56AM +0200, Marek Marczykowski-Górecki wrote: > When this daemon is started after creating backend device, that device > will not be configured. > > Racy situation: > 1. driver domain is started > 2. frontend domain is started (just after kicking driver domain off) >

Re: [Xen-devel] xenbits "official" repo for XTF (was Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)

On 18/07/2016 16:30, "Ian Jackson" wrote: >Lars Kurth writes ("Re: [Xen-devel] xenbits "official" repo for XTF (was >Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)"): >> I don't object to a new xtf directory in the docs root per se. I mainly >> object to how the documents are presented in >> htt

Re: [Xen-devel] [PATCH v2 09/11] tools: tracing: deal with new Credit2 events

On Fri, Jul 15, 2016 at 04:50:11PM +0200, Dario Faggioli wrote: > more specifically, with: TICKLE_NEW, RUNQ_MAX_WEIGHT, > MIGRATE, LOAD_CHECK, LOAD_BALANCE and PICKED_CPU, and > in both both xenalyze and formats (for xentrace_format). > > Signed-off-by: Dario Faggioli > Acked-by: George Dunlap

Re: [Xen-devel] [PATCH v2 04/11] xen/tools: improve tracing of Credit2 load tracking events

On Fri, Jul 15, 2016 at 04:49:33PM +0200, Dario Faggioli wrote: > Add the shift used for the precision of the integer > arithmetic to the trace records, and update both xenalyze > and xentrace_format to make use of/print it. > > In particular, in xenalyze, we are can now show the > load as a (easi

Re: [Xen-devel] Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-ad...@xenproject.org: [linux-4.1 bisection] complet

On Monday, July 18, 2016 5:31 PM, Konrad Rzeszutek Wilk wrote: > We found that your patch in the automated Xen test-case ends up > OOMing the box when trying to install guests. This worked prior > to your patch. > > See serial log: > http://logs.test-lab.xenproject.org/osstest/logs/97597/test-amd64

Re: [Xen-devel] xenbits "official" repo for XTF (was Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)

Lars Kurth writes ("Re: [Xen-devel] xenbits "official" repo for XTF (was Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)"): > In that case, forget my objection and go ahead and create the directories. > I clearly don't understand how the docs toolchain works and was assuming > that the docs director

Re: [Xen-devel] xenbits "official" repo for XTF (was Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)

On 18/07/2016 16:58, "Ian Jackson" wrote: >Lars Kurth writes ("Re: [Xen-devel] xenbits "official" repo for XTF (was >Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)"): >> In that case, forget my objection and go ahead and create the >>directories. >> I clearly don't understand how the docs toolch

Re: [Xen-devel] [PATCH v4] altp2m: Allow the hostp2m entries to be of type p2m_ram_shared

On 18/07/16 16:18, Tamas K Lengyel wrote: > On Mon, Jul 18, 2016 at 5:04 AM, George Dunlap > wrote: >> On Fri, Jul 15, 2016 at 3:59 PM, Tamas K Lengyel wrote: I could go on in the analysis, but the point is that there's a morass of interactions here all of which need to be correct, whi

[Xen-devel] [PATCH] docs/misc/hvmlite: Sync up hvm_start_info data structure

It as been modified by: 3c8d890 x86/PVHv2: update the start info structure layout 247d38c xen: change the sizes of memory fields in the HVM start info to be 64bits Signed-off-by: Anthony PERARD --- docs/misc/hvmlite.markdown | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-)

Re: [Xen-devel] [PATCH v4] altp2m: Allow the hostp2m entries to be of type p2m_ram_shared

On 18/07/16 16:27, Andrew Cooper wrote: > On 18/07/16 16:18, Tamas K Lengyel wrote: >> On Mon, Jul 18, 2016 at 5:04 AM, George Dunlap >> wrote: >>> On Fri, Jul 15, 2016 at 3:59 PM, Tamas K Lengyel >>> wrote: > I could go on in the analysis, but the point is that there's a morass > of in

Re: [Xen-devel] Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-ad...@xenproject.org: [linux-4.1 bisection] complet

On Mon, Jul 18, 2016 at 03:48:03PM +, Odzioba, Lukasz wrote: > On Monday, July 18, 2016 5:31 PM, Konrad Rzeszutek Wilk wrote: > > We found that your patch in the automated Xen test-case ends up > > OOMing the box when trying to install guests. This worked prior > > to your patch. > > > > See se

Re: [Xen-devel] [PATCH v4] altp2m: Allow the hostp2m entries to be of type p2m_ram_shared

On Mon, Jul 18, 2016 at 10:15 AM, George Dunlap wrote: > On 18/07/16 16:27, Andrew Cooper wrote: >> On 18/07/16 16:18, Tamas K Lengyel wrote: >>> On Mon, Jul 18, 2016 at 5:04 AM, George Dunlap >>> wrote: On Fri, Jul 15, 2016 at 3:59 PM, Tamas K Lengyel wrote: >> I could go on in

Re: [Xen-devel] Kernel panic on Xen virtualisation in Debian

Hi everyone, did the information that Ingo provided (i cited his message to the list below) maybe help in narrowing down the possible issue? If you need additional information we can try getting it for you, as Ingo might be able to reproduce the kernel panic, although not reliably. by the way, I

Re: [Xen-devel] [PATCH v2 11/11] xen: credit2: implement true SMT support

On 15/07/16 15:50, Dario Faggioli wrote: > In fact, right now, we recommend keepeing runqueues > arranged per-core, so that it is the inter-runqueue load > balancing code that automatically spreads the work in an > SMT friendly way. This means that any other runq > arrangement one may want to use f

Re: [Xen-devel] [PATCH 01/19] xen: Create a new file xen_pvdev.c

Eric, this is the link to the original patch which is well formatted: http://marc.info/?l=xen-devel&m=146815138831762&w=2 I think that the formatting and s-o-b was broken in the reply from Quan. On Jul 18, 2016 17:57, "Eric Blake" wrote: > On 07/17/2016 01:41 AM, Quan Xu wrote: > > > > [Quan:]:

Re: [Xen-devel] [PATCH v4] altp2m: Allow the hostp2m entries to be of type p2m_ram_shared

On Mon, Jul 18, 2016 at 10:10 AM, George Dunlap wrote: > On 18/07/16 16:18, Tamas K Lengyel wrote: >> On Mon, Jul 18, 2016 at 5:04 AM, George Dunlap >> wrote: >>> On Fri, Jul 15, 2016 at 3:59 PM, Tamas K Lengyel >>> wrote: > I could go on in the analysis, but the point is that there's a mo

Re: [Xen-devel] [PATCH v2 00/11] xen: sched: assorted fixes and improvements to Credit2

On Fri, Jul 15, 2016 at 3:49 PM, Dario Faggioli wrote: > Hi, > > Version 2 of the patch series. Not much to say apart from the fact that (I > think) I've addressed all the review comments v1 received (thanks everyone!). > Details are in the individual changelogs. > > It's smaller because George co

Re: [Xen-devel] [PATCH v2 11/11] xen: credit2: implement true SMT support

On Mon, 2016-07-18 at 17:48 +0100, George Dunlap wrote: > On 15/07/16 15:50, Dario Faggioli wrote: > >  > > +/* > > + * If all the siblings of cpu (including cpu itself) are in > > idlers, > > + * set all their bits in mask. > > + * > > + * In order to properly take into account tickling, idlers ne

Re: [Xen-devel] Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-ad...@xenproject.org: [linux-4.1 bisection] complet

i have the same issue without xen. for me network traffic causes oom within seconds to 3 minutes on embedded systems. but i dont know if this is the cause. i just can say that it was introduced with 3.18.37 Am 18.07.2016 um 18:18 schrieb Konrad Rzeszutek Wilk: On Mon, Jul 18, 2016 at 03:48:0

Re: [Xen-devel] Xen-unstable 4.8: Host crash when shutting down guest with pci device passed through using MSI-X interrupts.

On 18/07/16 11:21, li...@eikelenboom.it wrote: > Hi Jan, > > It seems that since your patch series starting with commit: > 2016-06-22 x86/vMSI-X: defer intercept handler registration > 74c6dc2d0ac4dcab0c6243cdf6ed550c1532b798 > > The shutdown of a guest which has a PCI device passed through which >

Re: [Xen-devel] [PATCH] docs/misc/hvmlite: Sync up hvm_start_info data structure

On 18/07/16 17:15, Anthony PERARD wrote: > It as been modified by: > 3c8d890 x86/PVHv2: update the start info structure layout > 247d38c xen: change the sizes of memory fields in the HVM start info to be > 64bits > > Signed-off-by: Anthony PERARD Now that we have (or are just about to get) the s

Re: [Xen-devel] [PATCH 03/16] x86/monitor: mechanical renames

On 15/07/16 08:18, Corneliu ZUZU wrote: > On 7/12/2016 9:10 AM, Corneliu ZUZU wrote: >> On 7/11/2016 7:43 PM, Tamas K Lengyel wrote: >>> On Sat, Jul 9, 2016 at 12:46 PM, Corneliu ZUZU >>> wrote: On 7/9/2016 9:10 PM, Tamas K Lengyel wrote: > On Fri, Jul 8, 2016 at 10:13 PM, Corneliu ZUZU >

Re: [Xen-devel] [PATCH 2/3] xen: Have schedulers revise initial placement

On 16/07/16 15:12, Dario Faggioli wrote: > On Fri, 2016-07-15 at 19:07 +0100, Andrew Cooper wrote: > >> None of the scheduler-accounting functions should be disabling >> interrupts. >> > They don't. But you can't keep irq disabled for some operations and > enabled for others, on the same lock (beca

Re: [Xen-devel] Atheros WiFi - memory paging failure on driver load

On 18/07/16 04:29, Andrey Grodzovsky wrote: > > > On Fri, Jul 15, 2016 at 11:45 PM, Andrey Grodzovsky > mailto:andrey2...@gmail.com>> wrote: > > > > On Fri, Jul 15, 2016 at 6:04 AM, Andrew Cooper > mailto:andrew.coop...@citrix.com>> wrote: > > On 12/07/16 04:59, Andrey Grodzovsky wr

[Xen-devel] unable to compile android-hikey-linaro-4.1

Hi All, I am referring to this wiki page (http://wiki.xen.org/wiki/HiKey) to setup xen in hikey. I am currently facing problem in building linux ( android-hikey-linaro-4.1 ),but I am getting compile error as below: kamenee@kamenee

[Xen-devel] [xen-unstable test] 97562: tolerable FAIL

flight 97562 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/97562/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 9 debian-install fail blocked in 97477 build-amd64-rumpuserxen

[Xen-devel] [PATCH] symbols: Generate an xen-sym.map file similar to Linux's

You could construct _most_ of the names of the functions by doing 'nm --defined' but unfortunatly you do not get the prefix that is added on. For example: $ cat xen-syms.symbols |grep do_domain_pause 0x82d080104920 t domain.c#do_domain_pause $ nm --defined xen-syms|grep do_domain_pause 82

Re: [Xen-devel] [PATCH v4] x86/cpuid: AVX-512 Feature Detection

On 07/07/16 03:42, Kang, Luwei wrote: > >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: Tuesday, July 5, 2016 3:03 PM >> To: Kang, Luwei >> Cc: andrew.coop...@citrix.com; chao.p.p...@linux.intel.com; xen- >> de...@lists.xen.org >> Subject: RE: [PATCH v4] x86/

Re: [Xen-devel] [PATCH 2/3] xen: Have schedulers revise initial placement

On Mon, 2016-07-18 at 19:10 +0100, Andrew Cooper wrote: > On 16/07/16 15:12, Dario Faggioli wrote: > > On Fri, 2016-07-15 at 19:07 +0100, Andrew Cooper wrote: > > So you have to always keep IRQ enabled, for all scheduling > > operations, > > which is ok for _almost_ all of them, with the only excep

Re: [Xen-devel] Atheros WiFi - memory paging failure on driver load

Thank you for your comments ! As a question , will disabling MSI enable bit in the card and switching back to legacy interrupt method might resolve the issue ? On Mon, Jul 18, 2016 at 2:22 PM, Andrew Cooper wrote: > On 18/07/16 04:29, Andrey Grodzovsky wrote: > > > > On Fri, Jul 15, 2016 at 11:

Re: [Xen-devel] Atheros WiFi - memory paging failure on driver load

On 18/07/2016 19:56, Andrey Grodzovsky wrote: > Thank you for your comments ! > As a question , will disabling MSI enable bit in the card and > switching back to legacy interrupt method might resolve the issue ? I don't know. That will be down to the driver itself. However, the use of legacy li

Re: [Xen-devel] Xen-unstable 4.8: Host crash when shutting down guest with pci device passed through using MSI-X interrupts.

Monday, July 18, 2016, 7:48:20 PM, you wrote: > On 18/07/16 11:21, li...@eikelenboom.it wrote: >> Hi Jan, >> >> It seems that since your patch series starting with commit: >> 2016-06-22 x86/vMSI-X: defer intercept handler registration >> 74c6dc2d0ac4dcab0c6243cdf6ed550c1532b798 >> >> The shutdown

Re: [Xen-devel] [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

On Fri, 15 Jul 2016, Shannon Zhao wrote: > On 2016/7/15 16:00, Shannon Zhao wrote: > > > > > > On 2016/7/13 18:03, Julien Grall wrote: > >> > >> > >> On 13/07/2016 10:48, Shannon Zhao wrote: > >>> > >>> > >>> On 2016/7/13 17:20, Julien Grall wrote: > On 13/07/2016 08:54, Shannon Zhao wrote:

[Xen-devel] [ovmf test] 97565: regressions - FAIL

flight 97565 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/97565/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 94748 test-amd64-amd64-

  1   2   >