Re: [Xen-devel] question about xl migrate

hi Andrew >On 17/05/16 10:01, Zhang, Chunyu wrote: >> hi all >> >> i have two question about xl migrate >> >> write_batch >> 120 for ( i = 0; i < nr_pfns; ++i ) >> 121 { >> 122 types[i] = mfns[i] = ctx->save.ops.pfn_to_gfn(ctx, >> 123

Re: [Xen-devel] [BUG] Linux process vruntime accounting in Xen

On 17/05/16 11:33, George Dunlap wrote: > On Mon, May 16, 2016 at 11:33 PM, Boris Ostrovsky > wrote: >> On 05/16/2016 05:38 PM, Tony S wrote: >>> The issue behind it is that the process execution calculation(e.g., >>> delta_exec) in virtualized environment should not

Re: [Xen-devel] question about xl migrate

On 17/05/16 10:01, Zhang, Chunyu wrote: > hi all > > i have two question about xl migrate > > write_batch > 120 for ( i = 0; i < nr_pfns; ++i ) > 121 { > 122 types[i] = mfns[i] = ctx->save.ops.pfn_to_gfn(ctx, > 123 >

[Xen-devel] [xen-unstable test] 94495: regressions - FAIL

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

Re: [Xen-devel] [BUG] Linux process vruntime accounting in Xen

On Mon, May 16, 2016 at 11:33 PM, Boris Ostrovsky wrote: > On 05/16/2016 05:38 PM, Tony S wrote: >> The issue behind it is that the process execution calculation(e.g., >> delta_exec) in virtualized environment should not be calculated as it >> did in physical

Re: [Xen-devel] [BUG] Bugs existing Xen's credit scheduler cause long tail latency issues

On Sun, May 15, 2016 at 5:11 AM, Tony S wrote: > Hi all, > > When I was running latency-sensitive applications in VMs on Xen, I > found some bugs in the credit scheduler which will cause long tail > latency in I/O-intensive VMs. > > > (1) Problem description > >

Re: [Xen-devel] [xen-unstable test] 94442: regressions - FAIL

>>> On 17.05.16 at 11:01, wrote: > On 17/05/16 09:59, Jan Beulich wrote: > On 16.05.16 at 11:29, wrote: >>> On 16/05/16 10:24, Wei Liu wrote: On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote: > flight 94442

Re: [Xen-devel] [xen-unstable test] 94442: regressions - FAIL

>>> On 17.05.16 at 10:59, wrote: On 16.05.16 at 11:29, wrote: >> On 16/05/16 10:24, Wei Liu wrote: >>> On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote: flight 94442 xen-unstable real [real]

[Xen-devel] question about xl migrate

hi all i have two question about xl migrate write_batch 120 for ( i = 0; i < nr_pfns; ++i ) 121 { 122 types[i] = mfns[i] = ctx->save.ops.pfn_to_gfn(ctx, 123 ctx->save.batch_pfns[i]); 124 125 /* Likely a ballooned

Re: [Xen-devel] [xen-unstable test] 94442: regressions - FAIL

On 17/05/16 09:59, Jan Beulich wrote: On 16.05.16 at 11:29, wrote: >> On 16/05/16 10:24, Wei Liu wrote: >>> On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote: flight 94442 xen-unstable real [real]

Re: [Xen-devel] [PATCH v2 0/1] xen/device-tree: Do not remap IRQs for secondary IRQ controllers

Hi Julien, On 17 May 2016 at 00:30, Julien Grall wrote: > Hi Wei, > > > On 16/05/16 16:47, Wei Liu wrote: >> >> On Mon, May 16, 2016 at 05:03:54PM +0200, Edgar E. Iglesias wrote: >>> >>> From: "Edgar E. Iglesias" >>> >>> I'm sending this as a v2

Re: [Xen-devel] [xen-unstable test] 94442: regressions - FAIL

>>> On 16.05.16 at 11:29, wrote: > On 16/05/16 10:24, Wei Liu wrote: >> On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote: >>> flight 94442 xen-unstable real [real] >>> http://logs.test-lab.xenproject.org/osstest/logs/94442/ >> [...] >>>

Re: [Xen-devel] unable to create domain after enabling XSM

I should add the xsm=policy option to the end of the xen.cfg instead of as an option. Sorry for the fault. However, another problem is that when I modified the policy and reload it using '*xl loadpolicy*', the policy seemed not working. The policy I add is *'allow domU_t security_t:security

Re: [Xen-devel] xen: 82599 passthrough problem

>>> On 16.05.16 at 05:41, wrote: > I also met this problem when passthrough 82599 to domU by SRIOV, and the > call stack as follows: > (XEN) Xen call trace: > (XEN)[] panic+0xc3/0x1a0 > (XEN)[] symbols_lookup+0x22/0x2a0 > (XEN)[] syscall_enter+0x88/0x8d > (XEN)

Re: [Xen-devel] [PATCH] x86/cpuid: Avoid unconditionally clobbering ITSC for guests

>>> On 16.05.16 at 18:59, wrote: > In general, Invariant TSC is not a feature which can be advertised to guests, > because it cannot be guaranteed across migrate. domain_cpuid() goes so far as > to deliberately clobber the feature flag under a number of circumstances.

Re: [Xen-devel] unable to create domain after enabling XSM

>>> On 16.05.16 at 17:00, wrote: > Actually I did that, but the policy is not loaded at all. 'xl list -Z' show > no lable on guests. It seems like that the option 'xsm=xen-policy-4.6.0' is > ingnored during booting. (the policy file is moved to the same directory as >

Re: [Xen-devel] Backport requests to stable for Xen ARM

>>> On 16.05.16 at 17:40, wrote: > On Mon, 16 May 2016, Julien Grall wrote: >> It has been a while without any ARM backport request. Ian Campbell >> used to keep a list of backport fixes for Xen ARM and apply them >> to stable. Now that he left, I am not sure who will do

Re: [Xen-devel] [PATCH for-4.7] x86/compat: Cleanup and further debugging of SMAP/SMEP fixup

>>> On 16.05.16 at 12:49, wrote: > * Abstract (X86_CR4_SMEP | X86_CR4_SMAP) behind XEN_CR4_PV32_BITS to avoid >opencoding the invidial bits which are fixed up behind a 32bit PV guests >back. > * In the debug case, perform the the AND and CMP on 64bit values

[Xen-devel] [ovmf test] 94498: all pass - PUSHED

flight 94498 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/94498/ Perfect :-) All tests in this flight passed version targeted for testing: ovmf 7b13510f2a0a2a118cdafdaa67720ca8e3fe37de baseline version: ovmf

[Xen-devel] [qemu-upstream-4.3-testing test] 94500: trouble: blocked/broken

flight 94500 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94500/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 3 host-install(3) broken

Re: [Xen-devel] [PATCH v3 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

>>> On 13.05.16 at 18:29, wrote: > On Fri, May 13, 2016 at 10:12 AM, Jan Beulich wrote: > On 13.05.16 at 17:31, wrote: >>> On Fri, May 13, 2016 at 9:09 AM, Jan Beulich wrote: >>> On 13.05.16 at 16:50,

Re: [Xen-devel] [PATCH v10 1/3] vt-d: add a timeout parameter for Queued Invalidation

>>> On 17.05.16 at 05:19, wrote: >> From: Xu, Quan >> Sent: Monday, May 16, 2016 11:26 PM >> >> On May 13, 2016 11:28 PM, Jan Beulich wrote: >> > >>> On 22.04.16 at 12:54, wrote: >> > > --- a/docs/misc/xen-command-line.markdown >> >

Re: [Xen-devel] Backport requests to stable for Xen ARM

Hi Jan, On 17/05/2016 08:38, Jan Beulich wrote: xen/arm: Force broadcast of TLB and instruction cache maintenance instructions commit e2faa286faa36da36ee14f6bc973043013001724 up to Xen 4.4 For both of those please note that 4.4 is in security-only maintenance mode, and hence shouldn't be

Re: [Xen-devel] Linux 4.4 boot crash on xen 4.5.3 with dom0_mem == max

On 17/05/16 06:28, Ed Swierk wrote: > I'm trying to figure out a crash when booting a Linux 4.4 dom0 on > a recent stable xen 4.5. I'm capping the dom0 memory by setting > dom0_mem=18432M,max:18432M on the xen command line, and the kernel > config has CONFIG_XEN_BALLOON unset. > > The crash seems

Re: [Xen-devel] Backport requests to stable for Xen ARM

>>> On 16.05.16 at 16:28, wrote: > It has been a while without any ARM backport request. Ian Campbell > used to keep a list of backport fixes for Xen ARM and apply them > to stable. Now that he left, I am not sure who will do it. > > I would be fine to keep the list of

Re: [Xen-devel] [for-4.7 1/2] xen/arm: p2m: apply_p2m_changes: Do not undo more than necessary

On 17/05/2016 07:40, Wei Chen wrote: Hi Julien, Hi Wei, Please avoid top-posting on the mailing list. This code looks good to me. Thank you for the review. Reviewed-by: Wei Chen Regards, -- Julien Grall ___ Xen-devel

[Xen-devel] [distros-debian-snapshot test] 44422: trouble: blocked/broken

flight 44422 distros-debian-snapshot real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44422/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 4 capture-logs

Re: [Xen-devel] [for-4.7 2/2] xen/arm: p2m: Release the p2m lock before undoing the mappings

Hi Julien, I have some concern about this patch. Because we released the spinlock before remove the mapped memory. If somebody acquires the spinlock before we remove the mapped memory, this mapped memory region can be accessed by guest. The apply_p2m_changes is no longer atomic. Is it a

Re: [Xen-devel] [for-4.7 2/2] xen/arm: p2m: Release the p2m lock before undoing the mappings

Hi Julien, This code looks good to me, and I have tested that the deadlock is fixed by this patch. Reviewed-and-Tested-by: Wei Chen Original: (XEN) smmu: /smb/smmu@e080: P2M IPA size not supported (P2M=44 SMMU=40)! (XEN) I/O virtualisation disabled (XEN) Request p2m

Re: [Xen-devel] [for-4.7 1/2] xen/arm: p2m: apply_p2m_changes: Do not undo more than necessary

Hi Julien, This code looks good to me. Reviewed-by: Wei Chen On 2016/5/16 22:08, Julien Grall wrote: Since commit 4b25423a "arch/arm: unmap partially-mapped memory regions", Xen has been undoing the P2M mappings when an error occurred during insertion or memory allocation.

Re: [Xen-devel] [PATCH v2 for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Saturday, May 14, 2016 1:26 AM > > hostmode->p2m_ga_to_gfn() is a plain PT walker, and is not appropriate for a > general L1 p2m walk. It is fine for AMD as NPT share the same format as > normal pagetables. For Intel EPT however,

<    1   2