[Xen-devel] [linux-3.18 test] 112987: trouble: blocked/broken/fail/pass

flight 112987 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/112987/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 3 capture-logs broken REGR. vs. 112102

Re: [Xen-devel] [RFC PATCH V2 2/4] Tool/ACPI: DSDT extension to support more vcpus

On 2017年08月31日 23:38, Roger Pau Monné wrote: > On Thu, Aug 31, 2017 at 01:01:47AM -0400, Lan Tianyu wrote: >> This patch is to change DSDT table for processor object to support >128 vcpus >> accroding to ACPI spec 8.4 Declaring Processors >> >> Signed-off-by: Lan Tianyu >>

[Xen-devel] [linux-linus test] 112983: tolerable trouble: blocked/broken/fail/pass - PUSHED

flight 112983 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/112983/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-multivcpu 4 host-install(4) broken in 112968 pass in 112983

[Xen-devel] [ovmf baseline-only test] 72047: all pass

This run is configured for baseline tests only. flight 72047 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72047/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf f29ca8e8b96adc2539f44d41ed8521ef6d29c14c baseline

Re: [Xen-devel] [PATCH v5 1/4] VT-d PI: track the number of vcpus on pi blocking list

On Thu, Aug 31, 2017 at 02:33:57AM -0600, Jan Beulich wrote: On 31.08.17 at 09:15, wrote: >> On Thu, Aug 31, 2017 at 01:42:53AM -0600, Jan Beulich wrote: >> On 31.08.17 at 00:57, wrote: On Wed, Aug 30, 2017 at 10:00:49AM -0600, Jan Beulich

[Xen-devel] [xen-unstable test] 112981: tolerable trouble: blocked/broken/fail/pass - PUSHED

flight 112981 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/112981/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1

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

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

[Xen-devel] [seabios baseline-only test] 72046: regressions - FAIL

This run is configured for baseline tests only. flight 72046 seabios real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72046/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 16

[Xen-devel] [PATCH v5] xen: get rid of paravirt op adjust_exception_frame

When running as Xen pv-guest the exception frame on the stack contains %r11 and %rcx additional to the other data pushed by the processor. Instead of having a paravirt op being called for each exception type prepend the Xen specific code to each exception entry. When running as Xen pv-guest just

[Xen-devel] [PATCH 11/13] xen/gntdev: update to new mmu_notifier semantic

From: Jérôme Glisse Call to mmu_notifier_invalidate_page() are replaced by call to mmu_notifier_invalidate_range() and thus call are bracketed by call to mmu_notifier_invalidate_range_start()/end() Remove now useless invalidate_page callback. Signed-off-by: Jérôme Glisse

[Xen-devel] [PATCH 00/13] mmu_notifier kill invalidate_page callback v2

From: Jérôme Glisse (Sorry for so many list cross-posting and big cc) Changes since v1: - remove more dead code in kvm (no testing impact) - more accurate end address computation (patch 2) in page_mkclean_one and try_to_unmap_one - added tested-by/reviewed-by

Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

On 31/08/17 16:01, Boris Ostrovsky wrote: > On 08/31/2017 08:00 AM, Thomas Gleixner wrote: >> On Thu, 31 Aug 2017, Juergen Gross wrote: I've applied it on top of tip:x86/apic and fixed up the merge conflicts mindlessly. Patch below. Juergen, can you please check the result? >>>

[Xen-devel] [qemu-mainline test] 112979: regressions - trouble: blocked/broken/fail/pass

flight 112979 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/112979/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 10 debian-install fail REGR. vs. 112869

Re: [Xen-devel] Mailing List Broken? Unsubscribed?

On 08/29/2017 04:53 PM, Gary R Hook wrote: Hm. For some odd reason I stopped receiving xen-devel mail a while ago. I never unsubscribed, never turned anything off (to the best of my knowledge). Now a co-worker is unable to subscribe. What's up with that? Any ideas? Looks like we may have a

Re: [Xen-devel] [PATCH v4 10/11] public: add XENFEAT_ARM_SMCCC_supported feature

Hi Volodymyr, On 08/31/2017 04:58 PM, Volodymyr Babchuk wrote: > Hi Sergej > > On 31.08.17 16:51, Sergej Proskurin wrote: >> Hi Volodymyr, >> >> >> On 08/31/2017 02:44 PM, Volodymyr Babchuk wrote: >>> Hello Sergej, >>> >>> On 31.08.17 15:20, Sergej Proskurin wrote: Hi Volodymyr, hi Julien,

[Xen-devel] [PATCH v5 10/10] public: add and enable XENFEAT_ARM_SMCCC_supported feature

This feature indicates that hypervisor is compatible with ARM SMC calling convention. Previously hypervisor would inject an undefined instruction exception if an invalid SMC function were called or would crash a domain if an invalid HVC function were invoked. XENFEAT_ARM_SMCCC_supported feature

[Xen-devel] [PATCH v5 09/10] arm: vsmc: remove 64 bit mode check in PSCI handler

PSCI handling code had helper routine that checked calling convention. It does not needed anymore, because: - Generic handler checks that 64 bit calls can be made only by 64 bit guests. - SMCCC requires that 64-bit handler should support both 32 and 64 bit calls even if they originate

[Xen-devel] [PATCH v5 06/10] arm: smccc: handle SMCs according to SMCCC

SMCCC (SMC Call Convention) describes how to handle both HVCs and SMCs. SMCCC states that both HVC and SMC are valid conduits to call to different firmware functions. Thus, for example, PSCI calls can be made both by SMC or HVC. Also SMCCC defines function number coding for such calls. Besides

[Xen-devel] [PATCH v5 07/10] arm: traps: handle PSCI calls inside `vsmc.c`

PSCI is part of HVC/SMC interface, so it should be handled in appropriate place: `vsmc.c`. This patch moves PSCI handler calls from `traps.c` to `vsmc.c`. Also it corrects coding style of the PSCI handler functions. Older PSCI 0.1 uses SMC function identifiers in range that is reserved for

[Xen-devel] [PATCH v5 08/10] arm: PSCI: use definitions provided by asm/smccc.h

smccc.h provides definitions to construct SMC call function number according to SMCCC. We don't need multiple definitions for one thing, and definitions in smccc.h are more generic than ones used in psci.h. So psci.h will only provide function codes, while whole SMC function identifier will be

[Xen-devel] [PATCH v5 02/10] arm: traps: check if SMC was conditional before handling it

Trapped SMC instruction can fail condition check on ARMv8 architecture (ARM DDI 0487B.a page D7-2271). So we need to check if condition was meet. Signed-off-by: Volodymyr Babchuk Reviewed-by: Julien Grall --- * added Julien's R-b tag ---

[Xen-devel] [PATCH v5 03/10] public: xen.h: add definitions for UUID handling

Added type xen_uuid_t. This type represents UUID as an array of 16 bytes in big endian format. Added macro XEN_DEFINE_UUID that constructs UUID in the usual way: XEN_DEFINE_UUID(00112233, 4455, 6677, 8899, aabbccddeeff) will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as

[Xen-devel] [PATCH v5 04/10] arm: processor.h: add definition for immediate value mask

This patch define HSR_XXC_IMM_MASK. It can be used to extract immediate value for trapped HVC32, HVC64, SMC64, SVC32, SVC64 instructions, as described in the ARM ARM (ARM DDI 0487B.a pages D7-2270, D7-2272). Signed-off-by: Volodymyr Babchuk --- * spelling fixes ---

[Xen-devel] [PATCH v5 01/10] arm: traps: use generic register accessors in the PSCI code

There are standard functions set_user_reg() and get_user_reg(). We can use them in PSCI_SET_RESULT()/PSCI_ARG() macros instead of relying on CONFIG_ARM_64 definition. Signed-off-by: Volodymyr Babchuk --- * removed 0x mask * coding style left unchanged,

[Xen-devel] [PATCH v5 00/10] Handle SMCs and HVCs in conformance with SMCCC

Hello all, v5: * Patches that add end enable XENFEAT_ARM_SMCCC_supported were squashed together * All other chages are described in corresponding patches This patch series still depend on Julien's patches for traps.c cleanup ([1]). --- v4: * Added patch with public definitiod for

[Xen-devel] [PATCH v5 05/10] arm: add SMCCC protocol definitions

This patch adds generic definitions used in ARM SMC call convention. Those definitions was taken from linux header arm-smccc.h, extended and formatted according to XEN coding style. Some of the macros were converted to inlined functions to ease parsing. They can be used by both SMCCC clients

[Xen-devel] [seabios test] 112978: tolerable FAIL - PUSHED

flight 112978 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/112978/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 112966 pass in 112978

[Xen-devel] [xtf test] 112985: all pass - PUSHED

flight 112985 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/112985/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 295eeb7e3cd8c506c5ade03865a0e440a5cd8b22 baseline version: xtf

Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

On Thu, 31 Aug 2017, Boris Ostrovsky wrote: > On 08/31/2017 08:00 AM, Thomas Gleixner wrote: > > On Thu, 31 Aug 2017, Juergen Gross wrote: > >>> I've applied it on top of tip:x86/apic and fixed up the merge conflicts > >>> mindlessly. Patch below. > >>> > >>> Juergen, can you please check the

[Xen-devel] [linux-4.9 test] 112973: regressions - trouble: blocked/broken/fail/pass

flight 112973 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/112973/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 5 host-build-prep fail REGR. vs. 112863

[Xen-devel] [PATCH v5] xen: get rid of paravirt op adjust_exception_frame

From: Juergen Gross When running as Xen pv-guest the exception frame on the stack contains %r11 and %rcx additional to the other data pushed by the processor. Instead of having a paravirt op being called for each exception type prepend the Xen specific code to each exception

[Xen-devel] [xen-unstable-smoke test] 112988: tolerable trouble: broken/pass - PUSHED

flight 112988 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/112988/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2

[Xen-devel] [PATCH] x86/pv: Prohibit attempts to initialise a vcpu with EFLAGS.{NT, VM} set

Luckily, this isn't a security issue, because the fix for XSA-202 (c/s 0e47f92b072) took a proactive aproach and clobbered these flags on the exit-to-guest path. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/domain.c | 6 +-

[Xen-devel] [libvirt test] 112974: tolerable trouble: blocked/broken/pass - PUSHED

flight 112974 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/112974/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1

[Xen-devel] [ovmf baseline-only test] 72045: all pass

This run is configured for baseline tests only. flight 72045 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72045/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf ea8314e4402f6c385b6e41e4f7803853e64e421b baseline

Re: [Xen-devel] [PATCH] x86: mark the entire directmap NX

On 31/08/17 16:55, Jan Beulich wrote: > There's no reason for the first Mb to be excluded here. Enforce the > restriction right in the top level page table entries. > > Suggested-by: Andrew Cooper > Signed-off-by: Jan Beulich Reviewed-by: Andrew

Re: [Xen-devel] [PATCH v5 3/4] VT-d PI: restrict the number of vcpus in a given pcpu's PI blocking list

>>> On 16.08.17 at 07:14, wrote: > +static inline bool pi_over_limit(unsigned int cpu) > +{ > +/* Compare w/ constant first to save a division and an add */ > +if ( likely(read_atomic(_cpu(vmx_pi_blocking, cpu).counter) <= > +PI_LIST_FIXED_LIMIT) ) > +

Re: [Xen-devel] [PATCH] x86/pvh: remove stale PVHv1 comment from public headers

On Thu, Aug 31, 2017 at 09:07:59AM -0600, Jan Beulich wrote: > >>> On 31.08.17 at 16:58, wrote: > > --- a/xen/include/public/arch-x86/xen.h > > +++ b/xen/include/public/arch-x86/xen.h > > @@ -162,14 +162,10 @@ typedef uint64_t tsc_timestamp_t; /* RDTSC timestamp > > */ > >

[Xen-devel] [PATCH] x86: mark the entire directmap NX

There's no reason for the first Mb to be excluded here. Enforce the restriction right in the top level page table entries. Suggested-by: Andrew Cooper Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_64/mm.c +++ b/xen/arch/x86/x86_64/mm.c @@

Re: [Xen-devel] [PATCH v2] x86/pvh: remove stale HVM/PVHv1 comment from public headers

On Thu, Aug 31, 2017 at 09:16:35AM -0600, Jan Beulich wrote: > >>> On 31.08.17 at 17:10, wrote: > > Changes since v1: > > - Completely remove the comment, HVM guests also use > >vcpu_hvm_context instead of vcpu_guest_context. > > Are you sure? Specifically for ... > >

Re: [Xen-devel] [xen-unstable-smoke test] 112957: regressions - trouble: broken/fail/pass

On Wed, Aug 30, 2017 at 03:15:09PM +0100, George Dunlap wrote: > On 08/30/2017 02:54 PM, Andrew Cooper wrote: > > On 30/08/17 14:49, osstest service owner wrote: > >> flight 112957 xen-unstable-smoke real [real] > >> http://logs.test-lab.xenproject.org/osstest/logs/112957/ > >> > >> Regressions

Re: [Xen-devel] [RFC PATCH V2 2/4] Tool/ACPI: DSDT extension to support more vcpus

On Thu, Aug 31, 2017 at 01:01:47AM -0400, Lan Tianyu wrote: > This patch is to change DSDT table for processor object to support >128 vcpus > accroding to ACPI spec 8.4 Declaring Processors > > Signed-off-by: Lan Tianyu > --- > tools/libacpi/mk_dsdt.c | 18

Re: [Xen-devel] [PATCH v2] x86/pvh: remove stale HVM/PVHv1 comment from public headers

>>> On 31.08.17 at 17:10, wrote: > Changes since v1: > - Completely remove the comment, HVM guests also use >vcpu_hvm_context instead of vcpu_guest_context. Are you sure? Specifically for ... > --- a/xen/include/public/arch-x86/xen.h > +++

[Xen-devel] [xen-unstable-smoke test] 112984: regressions - trouble: broken/fail/pass

flight 112984 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/112984/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 12 guest-start fail REGR. vs. 112956 Tests which

Re: [Xen-devel] [PATCH v4 03/11] public: xen.h: add definitions for UUID handling

>>> On 31.08.17 at 15:21, wrote: > So, will it be acceptable to use my approach with that union? As per Ian's reply, go with just the containerized uint8_t[]. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org

[Xen-devel] [linux-3.18 test] 112970: regressions - trouble: blocked/broken/fail/pass

flight 112970 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/112970/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 3 capture-logs broken REGR. vs. 112102

[Xen-devel] [PATCH v2] x86/pvh: remove stale HVM/PVHv1 comment from public headers

From the vcpu_guest_context structure. PVHv2/HVM uses a completely different structure (vcpu_hvm_context), that's described in hvm_vpcu.h. Reported-by: Andrew Cooper Signed-off-by: Roger Pau Monné --- Cc: Andrew Cooper

Re: [Xen-devel] [PATCH] x86/pvh: remove stale PVHv1 comment from public headers

>>> On 31.08.17 at 16:58, wrote: > --- a/xen/include/public/arch-x86/xen.h > +++ b/xen/include/public/arch-x86/xen.h > @@ -162,14 +162,10 @@ typedef uint64_t tsc_timestamp_t; /* RDTSC timestamp > */ > * The following is all CPU context. Note that the fpu_ctxt block is

Re: [Xen-devel] [PATCH 2/2] x86/pv: drop gate_op prefix in emul-gate-op.c

On Thu, Aug 31, 2017 at 01:36:13PM +0100, Andrew Cooper wrote: > On 31/08/17 13:03, Jan Beulich wrote: > On 31.08.17 at 13:45, wrote: > >> There is only one function gate_op_read that needs to be modified. > > I'm fine with it just being read() here, but I can see this

Re: [Xen-devel] [PATCH v2 4/4] mm: Don't request scrubbing until dom0 is running

On Thu, Aug 31, 2017 at 09:16:14AM -0400, Boris Ostrovsky wrote: > There is no need to scrub pages freed during dom0 construction since > once dom0 is ready the heap will be scrubbed by scrub_heap_pages() anyway, > setting scrub_debug at the end. > > Signed-off-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH v4 10/11] public: add XENFEAT_ARM_SMCCC_supported feature

Hi Sergej On 31.08.17 16:51, Sergej Proskurin wrote: Hi Volodymyr, On 08/31/2017 02:44 PM, Volodymyr Babchuk wrote: Hello Sergej, On 31.08.17 15:20, Sergej Proskurin wrote: Hi Volodymyr, hi Julien, On 08/24/2017 07:25 PM, Julien Grall wrote: On 21/08/17 21:27, Volodymyr Babchuk wrote:

[Xen-devel] [PATCH] x86/pvh: remove stale PVHv1 comment from public headers

From the vcpu_guest_context structure. PVHv2 uses it in the same exact way as HVM guests, and from the hypervisor point of view PVHv2 is not even a different guest type, so only mention HVM in the public headers. Reported-by: Andrew Cooper Signed-off-by: Roger Pau

Re: [Xen-devel] [PATCH v4 03/11] public: xen.h: add definitions for UUID handling

Volodymyr Babchuk writes ("Re: [PATCH v4 03/11] public: xen.h: add definitions for UUID handling"): > Do you have any ideas how to indicate endianess of the fields, then? I > can just write it in the comments. But I fear of misuse. I definitely prefer your approach of providing only an array.

Re: [Xen-devel] [PATCH v4 11/39] altp2m: Move (MAX|INVALID)_ALTP2M to xen/p2m-common.h

Hi Jan, On 08/31/2017 12:19 PM, Jan Beulich wrote: On 31.08.17 at 11:49, wrote: >> On 08/31/2017 10:04 AM, Jan Beulich wrote: >> On 30.08.17 at 20:32, wrote: We move the macros (MAX|INVALID)_ALTP2M out of x86-related code to

Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

On 08/31/2017 08:00 AM, Thomas Gleixner wrote: > On Thu, 31 Aug 2017, Juergen Gross wrote: >>> I've applied it on top of tip:x86/apic and fixed up the merge conflicts >>> mindlessly. Patch below. >>> >>> Juergen, can you please check the result? >> You missed the updates to

Re: [Xen-devel] [RFC PATCH V2 4/4] xl/libacpi: extend lapic_id() to uint32_t

On 31/08/17 06:01, Lan Tianyu wrote: > From: Chao Gao > > This patch is to extend lapic_id() to support more vcpus. > > Signed-off-by: Chao Gao > Signed-off-by: Lan Tianyu Reviewed-by: Andrew Cooper

Re: [Xen-devel] [RFC PATCH V2 1/4] xen/hap: Increase hap page pool size for more vcpus support

On 31/08/17 06:01, Lan Tianyu wrote: > This patch is to increase hap page pool size to support more vcpus in single > VM. > > Signed-off-by: Lan Tianyu > --- > xen/arch/x86/mm/hap/hap.c | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git

Re: [Xen-devel] [PATCH v4 10/11] public: add XENFEAT_ARM_SMCCC_supported feature

Hi Volodymyr, On 08/31/2017 02:44 PM, Volodymyr Babchuk wrote: > Hello Sergej, > > On 31.08.17 15:20, Sergej Proskurin wrote: >> Hi Volodymyr, hi Julien, >> >> >> On 08/24/2017 07:25 PM, Julien Grall wrote: >>> >>> >>> On 21/08/17 21:27, Volodymyr Babchuk wrote: This feature indicates that

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

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

Re: [Xen-devel] [PATCH v4 03/11] public: xen.h: add definitions for UUID handling

On 31.08.17 15:53, Jan Beulich wrote: On 31.08.17 at 14:24, wrote: Hi Jan, On 31.08.17 10:34, Jan Beulich wrote: On 30.08.17 at 18:20, wrote: My first intention was to declare union with all possible representations, so it would be

[Xen-devel] [PATCH v2 2/4] mm: Change boot_scrub_done definition

Rename it to the more appropriate scrub_debug and define as a macro for !CONFIG_SCRUB_DEBUG. This will allow us to get rid of some ifdefs (here and in the subsequent patch). Signed-off-by: Boris Ostrovsky Suggested-by: Jan Beulich Reviewed-by: Wei

[Xen-devel] [PATCH v2 0/4] Scrubbing updates

First patch fixes a long-standing bug where a low memory monitor is not initialized if boottime scrubbing is turned off. The other threee patches are performace and readability optimizations. I will send the last patch from previous posting (the one that broke the tree) later. I have a couple of

[Xen-devel] [PATCH v2 1/4] mm: Initialize lowmem virq when boot-time scrubbing is disabled

scrub_heap_pages() does early return if boot-time scrubbing is disabled, neglecting to initialize lowmem VIRQ. Because setup_low_mem_virq() doesn't logically belong in scrub_heap_pages() we put them both into the newly added heap_init_late(). Signed-off-by: Boris Ostrovsky

[Xen-devel] [PATCH v2 3/4] mm: Don't poison a page if scrub_debug is off

If scrub_debug is off we don't check pages in check_one_page(). Thus there is no reason to ever poison them. Signed-off-by: Boris Ostrovsky Reviewed-by: Wei Liu --- xen/common/page_alloc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[Xen-devel] [PATCH v2 4/4] mm: Don't request scrubbing until dom0 is running

There is no need to scrub pages freed during dom0 construction since once dom0 is ready the heap will be scrubbed by scrub_heap_pages() anyway, setting scrub_debug at the end. Signed-off-by: Boris Ostrovsky --- Changes in v2: * Use '||' instead of '|'. Drop '!!' *

Re: [Xen-devel] [PATCH v4 03/11] public: xen.h: add definitions for UUID handling

>>> On 31.08.17 at 14:24, wrote: > Hi Jan, > > On 31.08.17 10:34, Jan Beulich wrote: > On 30.08.17 at 18:20, wrote: >>> My first intention was to declare union with all possible >>> representations, so it would be possible to access

[Xen-devel] [xen-unstable-smoke test] 112982: regressions - trouble: broken/fail/pass

flight 112982 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/112982/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 12 guest-start fail REGR. vs. 112956 Tests which

[Xen-devel] [linux-linus test] 112968: regressions - trouble: blocked/broken/fail/pass

flight 112968 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/112968/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 4 host-install(4) broken REGR. vs. 112948

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

>>> On 31.08.17 at 12:27, wrote: > vMCE: Is MCE an x86-only thing, or could this conceivably by extended > to ARM? I think this can't be reasonably extended beyond x86 (and, considering their similar origin, ia64). > +## Tooling > + > +### gdbsx > + > +Status, x86:

Re: [Xen-devel] [PATCH v4 10/11] public: add XENFEAT_ARM_SMCCC_supported feature

Hello Sergej, On 31.08.17 15:20, Sergej Proskurin wrote: Hi Volodymyr, hi Julien, On 08/24/2017 07:25 PM, Julien Grall wrote: On 21/08/17 21:27, Volodymyr Babchuk wrote: This feature indicates that hypervisor is compatible with ARM SMC calling convention. Hypervisor will not inject an

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

>>> On 31.08.17 at 13:25, wrote: > On Thu, Aug 31, 2017 at 11:27:19AM +0100, George Dunlap wrote: >> +## Limits/Guest >> + >> +### Virtual CPUs >> + >> +Limit, x86 PV: 512 >> +Limit, x86 HVM: 128 > > There has already been some discussion about the HVM vCPU limit

Re: [Xen-devel] [PATCH v2 1/2] x86/mm: don't wrap x86_emulate_ctxt in ptwr_emulate_ctxt

On 31/08/17 12:22, Wei Liu wrote: > Rewrite the code so that it has the same structure as > mmio_ro_emualte_ctxt. x86_emulate_ctxt now points to ptwr_emulate_ctxt > via its data pointer. > > This patch will help unify mmio_ro and ptwr code paths later. > > Signed-off-by: Wei Liu

Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

On Thu, 2017-08-31 at 11:16 +0200, Ingo Molnar wrote: > * Thomas Gleixner wrote: > Low prio nitpicking, could we please write such table based initializers in a > vertically organized, tabular fashion: > > > + { debug,xen_xendebug,

Re: [Xen-devel] [PATCH 2/2] x86/pv: drop gate_op prefix in emul-gate-op.c

On 31/08/17 13:03, Jan Beulich wrote: On 31.08.17 at 13:45, wrote: >> There is only one function gate_op_read that needs to be modified. > I'm fine with it just being read() here, but I can see this being possibly > controversial. Please double check that Andrew isn't

Re: [Xen-devel] [PATCH v4 03/11] public: xen.h: add definitions for UUID handling

Hi Jan, On 31.08.17 10:34, Jan Beulich wrote: On 30.08.17 at 18:20, wrote: My first intention was to declare union with all possible representations, so it would be possible to access the same UUID as an array of bytes or, for example, as Microsoft GUID. Like this:

Re: [Xen-devel] [PATCH v4 10/11] public: add XENFEAT_ARM_SMCCC_supported feature

Hi Volodymyr, hi Julien, On 08/24/2017 07:25 PM, Julien Grall wrote: > > > On 21/08/17 21:27, Volodymyr Babchuk wrote: >> This feature indicates that hypervisor is compatible with ARM >> SMC calling convention. Hypervisor will not inject an undefined >> instruction exception if an invalid SMC

Re: [Xen-devel] [PATCH 2/2] x86/pv: drop gate_op prefix in emul-gate-op.c

>>> On 31.08.17 at 13:45, wrote: > There is only one function gate_op_read that needs to be modified. I'm fine with it just being read() here, but I can see this being possibly controversial. Please double check that Andrew isn't entirely opposed to it. An alternative

Re: [Xen-devel] [PATCH 1/2] x86/pv: drop priv_op prefix in emul-priv-op.c

>>> On 31.08.17 at 13:45, wrote: > Drop the prefix because they live in their own file now. One exception > is wbinvd handler because drpooing the prefix will clash with the > actual wbinvd function. How about _wbinvd() (single underscores as prefix are okay for static

Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

On Thu, 31 Aug 2017, Juergen Gross wrote: > > I've applied it on top of tip:x86/apic and fixed up the merge conflicts > > mindlessly. Patch below. > > > > Juergen, can you please check the result? > > You missed the updates to arch/x86/xen/xen-asm_64.S and the declarations > of the xen specific

Re: [Xen-devel] ARM64:Porting xen to new hardware

On Thu, Aug 31, 2017 at 2:13 PM, bharat gohil wrote: > Hello Oleksandr, Hi Bharat > > I had removed A72 cluster and tried to boot only two A35 but I got same > error. > > Is anything added or missing in A35 compare to A53? Unfortunately, I don't know. BTW, did you check your

[Xen-devel] [PATCH 2/2] x86/pv: drop gate_op prefix in emul-gate-op.c

There is only one function gate_op_read that needs to be modified. Signed-off-by: Wei Liu --- xen/arch/x86/pv/emul-gate-op.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/xen/arch/x86/pv/emul-gate-op.c b/xen/arch/x86/pv/emul-gate-op.c

[Xen-devel] [PATCH 0/2] x86/pv: drop unnecessary prefixes

Wei Liu (2): x86/pv: drop priv_op prefix in emul-priv-op.c x86/pv: drop gate_op prefix in emul-gate-op.c xen/arch/x86/pv/emul-gate-op.c | 15 +++ xen/arch/x86/pv/emul-priv-op.c | 99 +- 2 files changed, 55 insertions(+), 59 deletions(-) -- 2.11.0

[Xen-devel] [PATCH 1/2] x86/pv: drop priv_op prefix in emul-priv-op.c

Drop the prefix because they live in their own file now. One exception is wbinvd handler because drpooing the prefix will clash with the actual wbinvd function. Signed-off-by: Wei Liu --- xen/arch/x86/pv/emul-priv-op.c | 99 +- 1 file

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

On Thu, Aug 31, 2017 at 11:27:19AM +0100, George Dunlap wrote: > Add a machine-readable file to describe what features are in what > state of being 'supported', as well as information about how long this > release will be supported, and so on. > > The document should be formatted using "semantic

[Xen-devel] [PATCH v2 0/2] x86/mm: merge ptwr and mmio_ro page fault handlers

Address Andrew's comments and rebased on top of staging. Wei Liu (2): x86/mm: don't wrap x86_emulate_ctxt in ptwr_emulate_ctxt x86/mm: merge ptwr and mmio_ro page fault handlers xen/arch/x86/mm.c| 302 +-- xen/arch/x86/traps.c | 20

Re: [Xen-devel] Memory Issue HVM guest after Upgrade from 4.4 to 4.8

> -Original Message- > From: Michael Schinzel [mailto:schin...@ip-projects.de] > Sent: 31 August 2017 12:12 > To: Paul Durrant ; xen-devel@lists.xen.org > Cc: Thomas Toka > Subject: AW: Memory Issue HVM guest after Upgrade from 4.4 to 4.8 > >

[Xen-devel] [PATCH v2 1/2] x86/mm: don't wrap x86_emulate_ctxt in ptwr_emulate_ctxt

Rewrite the code so that it has the same structure as mmio_ro_emualte_ctxt. x86_emulate_ctxt now points to ptwr_emulate_ctxt via its data pointer. This patch will help unify mmio_ro and ptwr code paths later. Signed-off-by: Wei Liu --- v2: do away with pointer in

[Xen-devel] [PATCH v2 2/2] x86/mm: merge ptwr and mmio_ro page fault handlers

Provide a unified entry to avoid going through pte look-up, decode and emulation cycle more than necessary. The path taken is determined by the faulting address. Note that the order of checks is changed in the new function, but the order of the checks is performed shouldn't matter. The sole

Re: [Xen-devel] ARM64:Porting xen to new hardware

Hello Oleksandr, I had removed A72 cluster and tried to boot only two A35 but I got same error. Is anything added or missing in A35 compare to A53? Regards, Bharat On Wed, Aug 30, 2017 at 8:00 PM, bharat gohil wrote: > Hello Oleksandr, > Thank you very much for your

Re: [Xen-devel] Memory Issue HVM guest after Upgrade from 4.4 to 4.8

Hello, with traditional i get the information root@v34:/etc/xen# xl create vmanager1866.cfg Parsing config from vmanager1866.cfg libxl: error: libxl_dm.c:2024:libxl__spawn_local_dm: device model /usr/lib/xen-4.8/bin/qemu-dm is not executable: No such file or directory libxl: error:

[Xen-devel] [RFC PATCH V2 4/4] xl/libacpi: extend lapic_id() to uint32_t

From: Chao Gao This patch is to extend lapic_id() to support more vcpus. Signed-off-by: Chao Gao Signed-off-by: Lan Tianyu --- tools/firmware/hvmloader/util.c | 2 +- tools/libacpi/libacpi.h | 2 +-

[Xen-devel] [RFC PATCH V2 0/4] Extend resources to support more vcpus in single VM

Change since v1: 1) Increase hap page pool according vcpu number 2) Use "Processor" syntax to define vcpus with APIC id < 255 in dsdt and use "Device" syntax for other vcpus in ACPI DSDT table. 3) Use XAPIC structure for vcpus with APIC id < 255 in dsdt and use x2APIC

[Xen-devel] [RFC PATCH V2 1/4] xen/hap: Increase hap page pool size for more vcpus support

This patch is to increase hap page pool size to support more vcpus in single VM. Signed-off-by: Lan Tianyu --- xen/arch/x86/mm/hap/hap.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c

[Xen-devel] [RFC PATCH V2 3/4] hvmload: Add x2apic entry support in the MADT build

This patch is to add x2apic entry support for ACPI MADT table according to ACPI spec 5.2.12.12 Processor Local x2APIC Structure Signed-off-by: Chao Gao Signed-off-by: Lan Tianyu --- tools/libacpi/acpi2_0.h | 10 + tools/libacpi/build.c | 59

[Xen-devel] [RFC PATCH V2 2/4] Tool/ACPI: DSDT extension to support more vcpus

This patch is to change DSDT table for processor object to support >128 vcpus accroding to ACPI spec 8.4 Declaring Processors Signed-off-by: Lan Tianyu --- tools/libacpi/mk_dsdt.c | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

On 08/31/2017 12:03 PM, Paul Durrant wrote: >> -Original Message- >> From: George Dunlap [mailto:george.dun...@citrix.com] >> Sent: 31 August 2017 11:56 >> To: Paul Durrant ; xen-de...@lists.xenproject.org >> Cc: Ian Jackson ; Wei Liu

Re: [Xen-devel] Memory Issue HVM guest after Upgrade from 4.4 to 4.8

> -Original Message- > From: Michael Schinzel [mailto:schin...@ip-projects.de] > Sent: 31 August 2017 12:02 > To: Paul Durrant ; xen-devel@lists.xen.org > Cc: Thomas Toka > Subject: AW: Memory Issue HVM guest after Upgrade from 4.4 to 4.8 > >

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

> -Original Message- > From: George Dunlap [mailto:george.dun...@citrix.com] > Sent: 31 August 2017 11:56 > To: Paul Durrant ; xen-de...@lists.xenproject.org > Cc: Ian Jackson ; Wei Liu ; > Andrew Cooper

Re: [Xen-devel] Memory Issue HVM guest after Upgrade from 4.4 to 4.8

Hello, sry for HTML Mail, it is auto configuration of Outlook. We have testet adding device_model_version="qemu-xen" to the config and rebooting the VMs. With this configuration, no change at memory usage. Mit freundlichen Grüßen Michael Schinzel - Geschäftsführer - IP-Projects GmbH &

[Xen-devel] [xen-unstable-smoke test] 112980: regressions - trouble: broken/fail/pass

flight 112980 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/112980/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 12 guest-start fail REGR. vs. 112956 Tests which

  1   2   >