[Xen-devel] [PATCH 2/2] xen/physmap: Do not permit a guest to populate PoD pages for itself

PoD is supposed to be entirely transparent to guest, but this interface has been left exposed for a long time. The use of PoD requires careful co-ordination by the toolstack with the XENMEM_{get,set}_pod_target hypercalls, and xenstore ballooning target. The best a guest can do without toolstack

[Xen-devel] [PATCH 1/2] xen/memop: Latch current->domain in a local variable

It is more efficient. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: George Dunlap --- xen/common/memory.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/xen/common/memory.c

Re: [Xen-devel] unable start xen in hikey

Hello, On 18/08/16 22:44, Kamenee Arumugam wrote: Please avoid to top-post on the mailing list. Yes, I did try "make dtbs" too, but no difference and it doesn't generate .dtb file. here is the cmd I used: make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- Image dtbs The hikey device tree

Re: [Xen-devel] [PATCH v2 1/2] xen: credit1: fix a race when picking initial pCPU for a vCPU

On Fri, 2016-08-19 at 13:23 +0100, George Dunlap wrote: > On 18/08/16 11:00, Dario Faggioli wrote: > > @@ -248,6 +245,33 @@ __runq_elem(struct list_head *elem) > >  return list_entry(elem, struct csched_vcpu, runq_elem); > >  } > >   > > +/* Is the first element of cpu's runq (if any) cpu's

Re: [Xen-devel] unable start xen in hikey

Hello, On 18/08/16 22:11, Kamenee Arumugam wrote: I am using linux kernel from 96 boards repo: https://github.com/96boards/linux.git and I compile using this command as below: make Image -j24 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts What is your

Re: [Xen-devel] unable start xen in hikey

Hello, On 18/08/16 16:50, Chenxiao Zhao wrote: Please avoid top-posting on the mailing list. It seems that you are using a dtb file that is not compatible with XEN hypervisor on hikey. I strongly suggest you compile the kernel from source in 96boards's repository. When you compile the kernel

[Xen-devel] [PATCH v2] x86/PV: don't wrongly hide/expose CPUID.OSXSAVE from/to user mode

User mode code generally cannot be expected to invoke the PV-enabled CPUID Xen supports, and prior to the CPUID levelling changes for 4.7 (as well as even nowadays on levelling incapable hardware) such CPUID invocations actually saw the host CR4.OSXSAVE value, whereas prior to this patch - on

[Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

>From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001 From: Quan Xu Date: Fri, 19 Aug 2016 20:40:31 +0800 Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue When Xen apicv is enabled, wall clock time is faster on Windows7-32 guest with

Re: [Xen-devel] [PATCH 3/3] x86/EFI: don't accept 64-bit base relocations on page tables

>>> On 19.08.16 at 14:39, wrote: > On 19/08/16 08:52, Jan Beulich wrote: >> Page tables get pre-populated with physical addresses which, due to >> living inside the Xen image, will never exceed 32 bits in width. That >> in turn results in the tool generating the

Re: [Xen-devel] [PATCH v2 2/2] xen: credit1: no need to check for is_idle_vcpu() in csched_vcpu_acct()

On 18/08/16 11:00, Dario Faggioli wrote: > In fact, csched_vcpu_acct() is called by csched_tick() > _only_ on non idle vcpus already. > > There's even an ASSERT() already in place at the top > of it which, by checking that svc->sdom is not NULL, > guarantees that the function is not being called

Re: [Xen-devel] [PATCH 3/3] x86/EFI: don't accept 64-bit base relocations on page tables

On 19/08/16 08:52, Jan Beulich wrote: > Page tables get pre-populated with physical addresses which, due to > living inside the Xen image, will never exceed 32 bits in width. That > in turn results in the tool generating the relocations to produce > 32-bit relocations for them instead of the

Re: [Xen-devel] [PATCH v2 1/2] xen: credit1: fix a race when picking initial pCPU for a vCPU

On 18/08/16 11:00, Dario Faggioli wrote: > In the Credit1 hunk of 9f358ddd69463 ("xen: Have > schedulers revise initial placement") csched_cpu_pick() > is called without taking the runqueue lock of the > (temporary) pCPU that the vCPU has been assigned to > (e.g., in XEN_DOMCTL_max_vcpus). > >

Re: [Xen-devel] [PATCH 2/3] x86/EFI: be cautious about being handed control with CR4.PGE enabled

On 19/08/16 08:51, Jan Beulich wrote: > To effect proper TLB flushing in that case we should clear CR4.PGE > before loading the new page tables. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

Re: [Xen-devel] [PATCH] arm64: head: Fill image size

Hi Julien, On Thu, Aug 18, 2016 at 05:02:01PM +0100, Julien Grall wrote: >Hello Peng, > >On 16/08/16 03:58, Peng Fan wrote: >>When booting xen from U-Boot, U-Boot will use the image size >>info. Because this information is lacked in XEN image,U-Boot >>assume the image size is 16MB to memmove,

Re: [Xen-devel] [PATCH 2/2] hvmloader: cast to 64bit before multiplication in get_module_entry

>>> On 19.08.16 at 12:09, wrote: > On 19/08/16 09:31, Jan Beulich wrote: > On 19.08.16 at 10:06, wrote: >>> --- a/tools/firmware/hvmloader/hvmloader.c >>> +++ b/tools/firmware/hvmloader/hvmloader.c >>> @@ -272,8 +272,8 @@ const struct

Re: [Xen-devel] [PATCH 1/2] hvmloader: correctly copy signature to info structures

>>> On 19.08.16 at 11:42, wrote: > On 19/08/16 09:25, Jan Beulich wrote: > On 19.08.16 at 10:06, wrote: >>> --- a/tools/firmware/hvmloader/ovmf.c >>> +++ b/tools/firmware/hvmloader/ovmf.c >>> @@ -67,10 +67,11 @@ struct ovmf_info { >>> static

Re: [Xen-devel] [PATCH 1/3] x86/EFI: don't apply relocations to l{2, 3}_bootmap

On 19/08/16 08:50, Jan Beulich wrote: > Other than claimed in commit 2ce5963727's ("x86: construct the > {l2,l3}_bootmap at compile time") the initialization of the two page > tables doesn't take care of everything without furher adjustment: The > compile time initialization obviously requires

[Xen-devel] [PATCH v3] xen: support enabling SMEP/SMAP for HVM only

SMEP/SMAP is a security feature to prevent kernel executing/accessing user address involuntarily, any such behavior will lead to a page fault. SMEP/SMAP is open (in CR4) for both Xen and HVM guest in earlier code. A 32-bit PV guest will suffer unknown SMEP/SMAP page fault when guest kernel

Re: [Xen-devel] [PATCH] x86: don't needlessly globalize page table labels

On 19/08/16 08:53, Jan Beulich wrote: > Neither l1_identmap[] nor l3_identmap[] get referenced from outside > their defining source file; the latter didn't even have an extern > declaration for use from C sources. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

Re: [Xen-devel] [PATCH v4 14/19] efi: build xen.gz with EFI code

On Fri, Aug 19, 2016 at 03:24:15AM -0600, Jan Beulich wrote: > >>> On 06.08.16 at 01:04, wrote: > > --- a/xen/common/efi/boot.c > > +++ b/xen/common/efi/boot.c > > @@ -1248,6 +1248,9 @@ void __init efi_init_memory(void) > > } *extra, *extra_head = NULL; > > #endif >

Re: [Xen-devel] [PATCH 2/2] hvmloader: cast to 64bit before multiplication in get_module_entry

On 19/08/16 09:31, Jan Beulich wrote: On 19.08.16 at 10:06, wrote: >> Coverity complains: >> >> overflow_before_widen: Potentially overflowing expression >> info->nr_modules * 32U with type unsigned int (32 bits, unsigned) is >> evaluated using 32-bit arithmetic, and

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

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

Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault

Hi I took another look at Xen and a new crashdump. The last successful __vmwrite should be in static void vmx_vcpu_update_vmfunc_ve(struct vcpu *v) [...] __vmwrite(SECONDARY_VM_EXEC_CONTROL, v->arch.hvm_vmx.secondary_exec_control); [...] After this the altp2m_vcpu_destroy wakes

Re: [Xen-devel] [PATCH 1/2] hvmloader: correctly copy signature to info structures

On 19/08/16 09:25, Jan Beulich wrote: On 19.08.16 at 10:06, wrote: >> --- a/tools/firmware/hvmloader/ovmf.c >> +++ b/tools/firmware/hvmloader/ovmf.c >> @@ -67,10 +67,11 @@ struct ovmf_info { >> static void ovmf_setup_bios_info(void) >> { >> struct ovmf_info *info

Re: [Xen-devel] [PATCH v3 5/9] livepatch: Move code from prepare_payload to own routine

On 08/14/2016 10:52 PM, Konrad Rzeszutek Wilk wrote: Specifically the code that is looking up f->old_addr - which can be in its own routine instead of having it part of prepare_payload. No functional change. Signed-off-by: Konrad Rzeszutek Wilk --- Cc: Ross Lagerwall

Re: [Xen-devel] [PATCH v3 2/9] livepatch: Deal with payloads without any .text

On 08/14/2016 10:52 PM, Konrad Rzeszutek Wilk wrote: It is possible. Especially if the only thing they do is NOP functions - in which case there is only .livepatch.funcs sections. Signed-off-by: Konrad Rzeszutek Wilk --- Cc: Konrad Rzeszutek Wilk

Re: [Xen-devel] [PATCH v3 3/9] version/livepatch: Move xen_build_id_check to version.h

On 08/14/2016 10:52 PM, Konrad Rzeszutek Wilk wrote: It makes more sense for it to be there. However that means the version.h has now a dependency on as the Elf_Note is a macro. The elfstructs.h has a dependency on types.h as well so we need that. We cannot put that #include in elfstructs.h

Re: [Xen-devel] [PATCH v4 14/19] efi: build xen.gz with EFI code

>>> On 06.08.16 at 01:04, wrote: > --- a/xen/common/efi/boot.c > +++ b/xen/common/efi/boot.c > @@ -1248,6 +1248,9 @@ void __init efi_init_memory(void) > } *extra, *extra_head = NULL; > #endif > > +if ( !efi_enabled(EFI_BOOT) ) > +return; > + >

Re: [Xen-devel] [PATCH v3 1/9] livepatch: Clear .bss when payload is reverted

>>> On 19.08.16 at 10:37, wrote: > On 08/15/2016 04:10 PM, Jan Beulich wrote: > On 15.08.16 at 16:29, wrote: >>> On Mon, Aug 15, 2016 at 04:27:38AM -0600, Jan Beulich wrote: >>> On 14.08.16 at 23:52, wrote: >

Re: [Xen-devel] [PATCH v3 1/9] livepatch: Clear .bss when payload is reverted

On 08/15/2016 04:10 PM, Jan Beulich wrote: On 15.08.16 at 16:29, wrote: On Mon, Aug 15, 2016 at 04:27:38AM -0600, Jan Beulich wrote: On 14.08.16 at 23:52, wrote: @@ -1034,6 +1047,9 @@ static int revert_payload(struct payload *data)

Re: [Xen-devel] [PATCH 2/2] hvmloader: cast to 64bit before multiplication in get_module_entry

>>> On 19.08.16 at 10:06, wrote: > Coverity complains: > > overflow_before_widen: Potentially overflowing expression > info->nr_modules * 32U with type unsigned int (32 bits, unsigned) is > evaluated using 32-bit arithmetic, and then used in a context that > expects an

[Xen-devel] [xen-unstable test] 100551: tolerable FAIL - PUSHED

flight 100551 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100551/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-rumpuserxen 6 xen-buildfail like 100544 build-i386-rumpuserxen

Re: [Xen-devel] [PATCH 1/2] hvmloader: correctly copy signature to info structures

>>> On 19.08.16 at 10:06, wrote: > --- a/tools/firmware/hvmloader/ovmf.c > +++ b/tools/firmware/hvmloader/ovmf.c > @@ -67,10 +67,11 @@ struct ovmf_info { > static void ovmf_setup_bios_info(void) > { > struct ovmf_info *info = (void *)OVMF_INFO_PHYSICAL_ADDRESS; > +

[Xen-devel] [PATCH 1/2] hvmloader: correctly copy signature to info structures

The original code used sizeof(info->signature) as the size parameter for memcpy, which was wrong. Fix that by calculating the correct size. Signed-off-by: Wei Liu --- tools/firmware/hvmloader/ovmf.c| 3 ++- tools/firmware/hvmloader/seabios.c | 3 ++- 2 files changed, 4

[Xen-devel] [PATCH 0/2] hvmloader: fix two issues spotted by Coverity

Wei Liu (2): hvmloader: correctly copy signature to info structures hvmloader: cast to 64bit before multiplication in get_module_entry tools/firmware/hvmloader/hvmloader.c | 4 ++-- tools/firmware/hvmloader/ovmf.c | 3 ++- tools/firmware/hvmloader/seabios.c | 3 ++- 3 files changed, 6

[Xen-devel] [PATCH 2/2] hvmloader: cast to 64bit before multiplication in get_module_entry

Coverity complains: overflow_before_widen: Potentially overflowing expression info->nr_modules * 32U with type unsigned int (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type uint64_t (64 bits, unsigned). The overflow is

[Xen-devel] [PATCH] x86: don't needlessly globalize page table labels

Neither l1_identmap[] nor l3_identmap[] get referenced from outside their defining source file; the latter didn't even have an extern declaration for use from C sources. Signed-off-by: Jan Beulich --- a/xen/arch/x86/boot/x86_64.S +++ b/xen/arch/x86/boot/x86_64.S @@ -88,7

[Xen-devel] [PATCH 2/3] x86/EFI: be cautious about being handed control with CR4.PGE enabled

To effect proper TLB flushing in that case we should clear CR4.PGE before loading the new page tables. Signed-off-by: Jan Beulich --- a/xen/arch/x86/efi/efi-boot.h +++ b/xen/arch/x86/efi/efi-boot.h @@ -228,7 +228,7 @@ static void __init efi_arch_pre_exit_boo static void

[Xen-devel] [PATCH 3/3] x86/EFI: don't accept 64-bit base relocations on page tables

Page tables get pre-populated with physical addresses which, due to living inside the Xen image, will never exceed 32 bits in width. That in turn results in the tool generating the relocations to produce 32-bit relocations for them instead of the 64-bit ones needed for relocating virtual

[Xen-devel] [PATCH 1/3] x86/EFI: don't apply relocations to l{2, 3}_bootmap

Other than claimed in commit 2ce5963727's ("x86: construct the {l2,l3}_bootmap at compile time") the initialization of the two page tables doesn't take care of everything without furher adjustment: The compile time initialization obviously requires base relocations, and those get processed after

Re: [Xen-devel] [PATCHv2] x86: Add a tboot Kconfig option

>>> On 19.08.16 at 02:04, wrote: > On 8/18/16 6:44 PM, Derek Straka wrote: >> Allows for the conditional inclusion of tboot related functionality >> via Kconfig >> >> The default configuration for the new CONFIG_TBOOT option is 'y', so the >> behavior out of the box remains

[Xen-devel] [PATCH 0/3] x86/EFI: boot adjustments

1: don't apply relocations to l{2,3}_bootmap 2: be cautious about being handed control with CR4.PGE enabled 3: don't accept 64-bit base relocations on page tables Signed-off-by: Jan Beulich ___ Xen-devel mailing list

[Xen-devel] [libvirt test] 100553: regressions - FAIL

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

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

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

Re: [Xen-devel] [PATCH net-next] xen-netback: create a debugfs node for hash information

From: Paul Durrant Date: Wed, 17 Aug 2016 16:13:29 +0100 > It is useful to be able to see the hash configuration when running tests. > This patch adds a debugfs node for that purpose. > > Signed-off-by: Paul Durrant Applied.

<    1   2