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

flight 100898 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/100898/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100665

[Xen-devel] [xen-4.5-testing test] 100897: regressions - FAIL

flight 100897 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/100897/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 100828

[Xen-devel] [xen-4.6-testing test] 100895: tolerable FAIL - PUSHED

flight 100895 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/100895/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail blocked in 100835

[Xen-devel] [xen-4.7-testing test] 100896: regressions - FAIL

flight 100896 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/100896/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 9 debian-install fail REGR. vs. 100830 build-amd64

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

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

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

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

Re: [Xen-devel] Xen 4.8 Development Update

On Wed, Aug 31, 2016 at 09:30:46AM +0100, Wei Liu wrote: [...] > * Boot Xen on EFI platforms using GRUB2 (multiboot2 protocol) > - Daniel Kiper I have just sent v6. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org

[Xen-devel] [PATCH v6 14/15] x86/boot: rename sym_phys() to sym_offs()

This way macro name better describes its function. There is no functional change. Suggested-by: Jan Beulich Signed-off-by: Daniel Kiper --- xen/arch/x86/boot/head.S | 40

[Xen-devel] [PATCH v6 08/15] x86/efi: create new early memory allocator

There is a problem with place_string() which is used as early memory allocator. It gets memory chunks starting from start symbol and goes down. Sadly this does not work when Xen is loaded using multiboot2 protocol because then the start lives on 1 MiB address and we should not allocate a memory

[Xen-devel] [PATCH v6 12/15] x86/setup: use XEN_IMG_OFFSET instead of...

..calculating its value during runtime. Signed-off-by: Daniel Kiper --- xen/arch/x86/setup.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index f19af6e..ca1a97a 100644 --- a/xen/arch/x86/setup.c

[Xen-devel] [PATCH v6 13/15] x86: make Xen early boot code relocatable

Every multiboot protocol (regardless of version) compatible image must specify its load address (in ELF or multiboot header). Multiboot protocol compatible loader have to load image at specified address. However, there is no guarantee that the requested memory region (in case of Xen it starts at 2

[Xen-devel] [PATCH v6 15/15] x86: add multiboot2 protocol support for relocatable images

Add multiboot2 protocol support for relocatable images. Only GRUB2 with "multiboot2: Add support for relocatable images" patch understands that feature. Older multiboot protocol (regardless of version) compatible loaders ignore it and everything works as usual. Signed-off-by: Daniel Kiper

[Xen-devel] [PATCH v6 09/15] x86: add multiboot2 protocol support for EFI platforms

This way Xen can be loaded on EFI platforms using GRUB2 and other boot loaders which support multiboot2 protocol. Signed-off-by: Daniel Kiper --- v6 - suggestions/fixes: - improve label names in assembly error printing code (suggested by Jan Beulich), -

[Xen-devel] [PATCH v6 10/15] x86/boot: implement early command line parser in C

Current early command line parser implementation in assembler is very difficult to change to relocatable stuff using segment registers. This requires a lot of changes in very weird and fragile code. So, reimplement this functionality in C. This way code will be relocatable out of the box (without

[Xen-devel] [PATCH v6 06/15] x86: allow EFI reboot method neither on EFI platforms...

..nor EFI platforms with runtime services enabled. Suggested-by: Jan Beulich Signed-off-by: Daniel Kiper --- v6 - suggestions/fixes: - move this commit behind "efi: create efi_enabled()" commit (suggested by Jan Beulich). v5 -

[Xen-devel] [PATCH v6 04/15] x86: add multiboot2 protocol support

Add multiboot2 protocol support. Alter min memory limit handling as we now may not find it from either multiboot (v1) or multiboot2. This way we are laying the foundation for EFI + GRUB2 + Xen development. Signed-off-by: Daniel Kiper --- v6 - suggestions/fixes: -

[Xen-devel] [PATCH v6 07/15] efi: build xen.gz with EFI code

Build xen.gz with EFI code. We need this to support multiboot2 protocol on EFI platforms. If we wish to load non-ELF file using multiboot (v1) or multiboot2 then it must contain "linear" (or "flat") representation of code and data. This is requirement of both boot protocols. Currently, PE file

[Xen-devel] [PATCH v6 03/15] x86/boot/reloc: rename some variables and rearrange code a bit

Replace mbi with mbi_out and mbi_old with mbi_in and rearrange code a bit to make it more readable. Additionally, this way multiboot (v1) protocol implementation and future multiboot2 protocol implementation will use the same variable naming convention. Signed-off-by: Daniel Kiper

[Xen-devel] [PATCH v6 02/15] x86/boot/reloc: create generic alloc and copy functions

Create generic alloc and copy functions. We need separate tools for memory allocation and copy to provide multiboot2 protocol support. Signed-off-by: Daniel Kiper --- v6 - suggestions/fixes: - reduce number of casts (suggested by Andrew Cooper and Jan Beulich).

[Xen-devel] [PATCH v6 01/15] x86: properly calculate ELF end of image address

Currently ELF end of image address is calculated using first line from "nm -nr xen/xen-syms" output. However, today usually it contains random symbol address not related to end of image in any way. So, it looks that for years that stuff have been working just by lucky coincidence. Hence, it have

[Xen-devel] [PATCH v6 00/15] x86: multiboot2 protocol support

Hi, I am sending sixth version of multiboot2 protocol support for legacy BIOS and EFI platforms. This patch series release contains fixes for all known issues except one. During last review Jan pointed out that there is no memory size check for trampoline region returned by efi_multiboot2(). I

[Xen-devel] [PATCH v6 05/15] efi: create efi_enabled()

First of all we need to differentiate between legacy BIOS and EFI platforms during runtime, not during build, because one image will have legacy and EFI code and can be executed on both platforms. Additionally, we need more fine grained knowledge about EFI environment and check for EFI platform

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

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

Re: [Xen-devel] Getting started with Xen Project

Okay. I have a basic knowledge of x86 assembly language. I will need to get familiar with coding in OVMF. I feel that with some assignments and resources (like a minor bug in some OVMF code, or tutorial links) and guidance, a prospective mentee might reach the level required by the project. I

[Xen-devel] [qemu-mainline test] 100892: regressions - FAIL

flight 100892 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/100892/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-qcow2 6 xen-boot fail REGR. vs. 100877 Regressions

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

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

Re: [Xen-devel] PC8 Residency on Broadwell hardware

On Sep 12, 2016, at 2:00 AM, Jan Beulich > wrote: On 12.09.16 at 10:47, > wrote: c/s 350bc1a9d4 "x86: support newer Intel CPU models" changed the set of MSRs read by Xeon Broadwell hardware

Re: [Xen-devel] [PATCH 04/24] xen: credit2: properly schedule migration of a running vcpu.

On 17/08/16 18:18, Dario Faggioli wrote: > If wanting to migrate a vcpu that is actually running, > we need to ask the scheduler to chime in as soon as > possible, to have the vcpu itself stopped and actually > moved. > > Make sure this happens by, after setting all the relevant > flags, raising

Re: [Xen-devel] [RFC] x86/vm_event: Allow returning i-cache for emulation

On Mon, Sep 12, 2016 at 10:02 AM, Jan Beulich wrote: On 12.09.16 at 17:48, wrote: >> On Mon, Sep 12, 2016 at 8:56 AM, Jan Beulich wrote: >>> >>> On 09.09.16 at 17:41, wrote: >>> > @@ -1783,7

[Xen-devel] [PATCH v2 2/6] x86/domctl: Fix TOCTOU race with the use of XEN_DOMCTL_getvcpuextstate

A toolstack must call XEN_DOMCTL_getvcpuextstate twice; first to find the size of the buffer to use, and a second time to get the actual content. The reported size was based on v->arch.xcr0_accum, but a guest which extends its xcr0_accum between the two hypercalls will cause the toolstack to fail

[Xen-devel] [PATCH v2 6/6] x86/xstate: Fix latent bugs in compress_xsave_states()

compress_xsave_states() mustn't read xstate_bv or xcomp_bv before first confirming that the input buffer is large enough. It also doesn't cope with compressed input. Make all of these problems the callers responsbility to ensure. Simplify the decompression logic by inlining get_xsave_addr().

[Xen-devel] [PATCH v2 3/6] x86/domctl: Simplfy XEN_DOMCTL_getvcpuextstate when xsave is not in use

Older guests will not use xsave even if it is available. As such, their xcr0_accum will be 0 at the point of migrate. If it is empty, forgo the memory allocation and serialisation into a zero-length buffer. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich

[Xen-devel] [PATCH v2 5/6] x86/domctl: Fix migration of guests which are not using xsave

c/s da62246e "x86/xsaves: enable xsaves/xrstors/xsavec in xen" broke migration of PV guests which were not using xsave. In such a case, compress_xsave_states() gets passed a zero length buffer. The first thing it tries to do is ASSERT() on user-provided data, if it hadn't already wandered off

[Xen-devel] [PATCH v2 1/6] x86/domctl: Introduce PV_XSAVE_HDR_SIZE and remove its opencoding

Also remove opencoding of PV_XSAVE_SIZE(). Undefine both when they are done with. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- xen/arch/x86/domctl.c | 21 - 1 file changed, 12 insertions(+),

[Xen-devel] [PATCH v2 0/6] Fix multiple issues with xsave state handling on migrate

Patch 5 is the primary bugfix of this series, which is broken in Xen 4.7 as well as master. There are multiple latent security issues which would be exposed at the point support for the first compressed xsave state was added, but are in currently-dead code. Changes from v1: * Inline and remove

[Xen-devel] [PATCH v2 4/6] x86/xstate: Fix latent bugs in expand_xsave_states()

Without checking the size input, the memcpy() for the uncompressed path might read off the end of the vcpu's xsave_area. Both callers pass the approprite size, so hold them to it with a BUG_ON(). The compressed path is currently dead code, but its attempt to avoid leaking uninitalised data was

[Xen-devel] [PATCH v2 0/3] Significant changes to Xen Project Governance (governance.html)

I made some significant proposed changes to governance.html based on a number of issues that were raised in a number of surveys last year, and via other means, as well as in the recent discussions related to governance.html changes (the issue of too many committers in XAPI and XAPI being able

[Xen-devel] [PATCH v2 2/3] Added comment sections to highight problem areas

These are marked by - ... - blocks that will be removed in the published version Signed-off-by: Lars Kurth --- governance.pandoc

[Xen-devel] [PATCH v2 3/3] Significant changes to decision making; some new roles and minor changes

Added RTC Policy Added +2 ... -2 scheme for votes Clarified lazy consensus (tallying and lazy voting) Added Informal Votes/Surveys Added Project Team Leadership role and Decision making Added Community Decisions with Funding and Legal Implications Changed Project Wide Decision making: per project

[Xen-devel] [PATCH v2 1/3] Code motion changes to make real patches easier to read

Added TOC Re-arranged sections compared to previous version of document Added new anchors where needed Split Roles section into two sections The actual content was not changed (with the exception of minor typos that I spotted) Signed-off-by: Lars Kurth ---

Re: [Xen-devel] [PATCH 6/6] x86/xstate: Fix latent bugs in compress_xsave_states()

>>> On 12.09.16 at 17:28, wrote: > On 12/09/16 14:47, Jan Beulich wrote: > On 12.09.16 at 14:59, wrote: >>> On 12/09/16 13:27, Jan Beulich wrote: >>> On 12.09.16 at 11:51, wrote: > +xstate_bv =

Re: [Xen-devel] [PATCH v6 2/2] qdisk - hw/block/xen_disk: grant copy implementation

On Wed, Sep 07, 2016 at 12:41:00PM +0200, Paulina Szubarczyk wrote: > Copy data operated on during request from/to local buffers to/from > the grant references. > > Before grant copy operation local buffers must be allocated what is > done by calling ioreq_init_copy_buffers. For the 'read'

Re: [Xen-devel] [RFC] x86/vm_event: Allow returning i-cache for emulation

>>> On 12.09.16 at 17:48, wrote: > On Mon, Sep 12, 2016 at 8:56 AM, Jan Beulich wrote: >> >>> On 09.09.16 at 17:41, wrote: >> > @@ -1783,7 +1786,14 @@ static int _hvm_emulate_one(struct >> hvm_emulate_ctxt *hvmemul_ctxt,

Re: [Xen-devel] [PATCH v3 09/18] livepatch/arm/x86: Check payload for for unwelcomed symbols.

>>> On 11.09.16 at 22:35, wrote: > --- a/xen/arch/arm/livepatch.c > +++ b/xen/arch/arm/livepatch.c > @@ -117,6 +117,20 @@ bool_t arch_livepatch_symbol_ok(const struct > livepatch_elf *elf, > return true; > } > > +int arch_livepatch_symbol_check(const struct

Re: [Xen-devel] [PATCH v3 08/18] livepatch: ARM 32|64: Ignore mapping symbols: $[d, a, x]

>>> On 11.09.16 at 22:35, wrote: > Those symbols are used to help final linkers to replace insn. > The ARM ELF specification mandates that they are present > to denote the start of certain CPU features. There are two > variants of it - short and long format. > > Either

Re: [Xen-devel] [RFC] x86/vm_event: Allow returning i-cache for emulation

On Mon, Sep 12, 2016 at 8:56 AM, Jan Beulich wrote: > >>> On 09.09.16 at 17:41, wrote: > > When emulating instructions the emulator maintains a small i-cache > fetched > > from the guest memory. Under certain scenarios this memory region may >

Re: [Xen-devel] [PATCH v3 07/18] livepatch: ARM/x86: Check displacement of old_addr and new_addr

>>> On 11.09.16 at 22:35, wrote: > If the distance is too great we are in trouble - as our relocation I think you mean "large" or big" here. > distance can surely be clipped, or still have a valid width - but > cause an overflow of distance. > > On various architectures

Re: [Xen-devel] [PATCH v3 01/18] arm/x86: Add HAS_[ALTERNATIVE|EX_TABLE]

Hi, On 12/09/16 16:28, Jan Beulich wrote: On 11.09.16 at 22:35, wrote: x86 implements all of them by default - and we just add two extra HAS_ variables to be declared in autoconf.h. ARM 64 only has alternative while ARM 32 has none of them. The ARM64 is going to be a

Re: [Xen-devel] [PATCH 6/6] x86/xstate: Fix latent bugs in compress_xsave_states()

On 12/09/16 14:47, Jan Beulich wrote: On 12.09.16 at 14:59, wrote: >> On 12/09/16 13:27, Jan Beulich wrote: >> On 12.09.16 at 11:51, wrote: void compress_xsave_states(struct vcpu *v, const void *src, unsigned int size)

Re: [Xen-devel] [PATCH v3 01/18] arm/x86: Add HAS_[ALTERNATIVE|EX_TABLE]

>>> On 11.09.16 at 22:35, wrote: > x86 implements all of them by default - and we just > add two extra HAS_ variables to be declared in autoconf.h. > > ARM 64 only has alternative while ARM 32 has none of them. > The ARM64 is going to be a bit funny as there is an >

[Xen-devel] BUG_ON() vs ASSERT()

All, in https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01201.html and https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01210.html Andrew basically suggests that we should switch away from using ASSERT() and over to BUG_ON() in perhaps quite broad a set of cases.

Re: [Xen-devel] [PATCH v5 00/16] Xen ARM DomU ACPI support

Hi Shannon, On 02/09/16 03:55, Shannon Zhao wrote: From: Shannon Zhao The design of this feature is described as below. Firstly, the toolstack (libxl) generates the ACPI tables according the number of vcpus and gic controller. Then, it copies these ACPI tables to

Re: [Xen-devel] [PATCH v5 16/16] libxl/arm: Add the size of ACPI tables to maxmem

Hi Shannon, On 02/09/16 03:55, Shannon Zhao wrote: From: Shannon Zhao Here it adds the ACPI tables size to set the target maxmem to avoid providing less available memory for guest. Signed-off-by: Shannon Zhao --- tools/libxl/libxl_arch.h

Re: [Xen-devel] [PATCH 03/24] xen: credit1: return the 'time remaining to the limit' as next timeslice.

On 17/08/16 18:17, Dario Faggioli wrote: > If vcpu x has run for 200us, and sched_ratelimit_us is > 1000us, continue running x _but_ return 1000us-200us as > the next time slice. This way, next scheduling point will > happen in 800us, i.e., exactly at the point when x crosses > the threshold, and

Re: [Xen-devel] [PATCH v5 15/16] libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ

Hi Shannon, On 02/09/16 03:55, Shannon Zhao wrote: From: Shannon Zhao The guest kernel will get the event channel interrupt information via domain param HVM_PARAM_CALLBACK_IRQ. Initialize it here. Signed-off-by: Shannon Zhao Acked-by:

Re: [Xen-devel] [PATCH v5 11/16] libxl/arm: Construct ACPI DSDT table

Hi Shannon, On 02/09/16 03:55, Shannon Zhao wrote: From: Shannon Zhao Copy the static DSDT table into ACPI blob. Signed-off-by: Shannon Zhao Acked-by: Julien Grall Regards, --- tools/libxl/libxl_arm_acpi.c | 10

Re: [Xen-devel] [PATCH v5 10/16] libxl/arm: Construct ACPI FADT table

Hi Shannon, On 02/09/16 03:55, Shannon Zhao wrote: From: Shannon Zhao Signed-off-by: Shannon Zhao Acked-by: Julien Grall Regards, -- Julien Grall ___ Xen-devel mailing

Re: [Xen-devel] [PATCH v5 09/16] libxl/arm: Construct ACPI MADT table

Hi Shannon, On 02/09/16 03:55, Shannon Zhao wrote: From: Shannon Zhao According to the GIC version, construct the MADT table. Signed-off-by: Shannon Zhao Acked-by: Julien Grall Regards, -- Julien Grall

Re: [Xen-devel] [PATCH v5 07/16] libxl/arm: Construct ACPI GTDT table

Hi Shannon, On 02/09/16 03:55, Shannon Zhao wrote: From: Shannon Zhao Construct GTDT table with the interrupt information of timers. Signed-off-by: Shannon Zhao --- tools/libxl/libxl_arm_acpi.c | 38 ++ 1

Re: [Xen-devel] [PATCH 01/24] xen: credit1: small optimization in Credit1's tickling logic.

On 17/08/16 18:17, Dario Faggioli wrote: > If, when vcpu x wakes up, there are no idle pcpus in x's > soft-affinity, we just go ahead and look at its hard > affinity. This basically means that, if, in __runq_tickle(), > new_idlers_empty is true, balance_step is equal to >

Re: [Xen-devel] [PATCH v5 06/16] libxl/arm: Construct ACPI XSDT table

Hi Shannon, On 02/09/16 03:55, Shannon Zhao wrote: From: Shannon Zhao Signed-off-by: Shannon Zhao Acked-by: Julien Grall Regards, --- tools/libxl/libxl_arm_acpi.c | 30 ++ 1 file

Re: [Xen-devel] [RFC] x86/vm_event: Allow returning i-cache for emulation

On Sep 12, 2016 08:59, "George Dunlap" wrote: > > On 12/09/16 15:56, Jan Beulich wrote: > On 09.09.16 at 17:41, wrote: > >> When emulating instructions the emulator maintains a small i-cache fetched > >> from the guest memory. Under

Re: [Xen-devel] [PATCH 02/24] xen: credit1: fix mask to be used for tickling in Credit1

On Thu, Aug 18, 2016 at 12:42 AM, Dario Faggioli wrote: > On Wed, 2016-08-17 at 19:17 +0200, Dario Faggioli wrote: >> If there are idle pcpus inside the waking vcpu's >> soft-affinity mask, we should really tickle one >> of them (this is one of the purposes of the >>

Re: [Xen-devel] [RFC] x86/vm_event: Allow returning i-cache for emulation

On 12/09/16 15:56, Jan Beulich wrote: On 09.09.16 at 17:41, wrote: >> When emulating instructions the emulator maintains a small i-cache fetched >> from the guest memory. Under certain scenarios this memory region may contain >> instructions that a monitor

Re: [Xen-devel] [PATCH v5 05/16] libxl/arm: Construct ACPI RSDP table

Hi Shannon, On 02/09/16 03:55, Shannon Zhao wrote: From: Shannon Zhao Construct ACPI RSDP table and add a helper to calculate the ACPI table checksum. Signed-off-by: Shannon Zhao Acked-by: Julien Grall Regards,

Re: [Xen-devel] [RFC] x86/vm_event: Allow returning i-cache for emulation

>>> On 09.09.16 at 17:41, wrote: > When emulating instructions the emulator maintains a small i-cache fetched > from the guest memory. Under certain scenarios this memory region may contain > instructions that a monitor subscriber would prefer to hide, namely INT3, and

Re: [Xen-devel] [PATCH v5 03/16] libxl/arm: Generate static ACPI DSDT table

Hi Shannon, On 02/09/16 03:55, Shannon Zhao wrote: From: Shannon Zhao It uses static DSDT table like the way x86 uses. Currently the DSDT table only contains processor device objects and it generates the maximal objects which so far is 128. While the GUEST_MAX_VCPUS

Re: [Xen-devel] [PATCH v5 02/16] libxl/arm: prepare for constructing ACPI tables

Hi Shannon, On 02/09/16 03:55, Shannon Zhao wrote: From: Shannon Zhao It only constructs the ACPI tables for 64-bit ARM DomU when user enables acpi because 32-bit DomU doesn't support ACPI. And the generation codes are only built for 64-bit toolstack. Signed-off-by:

Re: [Xen-devel] [RFC] x86/vm_event: Allow returning i-cache for emulation

On 12/09/16 15:31, Tamas Lengyel wrote: > On Sep 12, 2016 08:17, "George Dunlap" wrote: >> >> On 09/09/16 16:41, Tamas K Lengyel wrote: >>> When emulating instructions the emulator maintains a small i-cache > fetched >>> from the guest memory. Under certain scenarios

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

>>> On 09.09.16 at 17:16, wrote: > The following code illustrates this idea: > > typedef struct dm_op_buffer { > XEN_GUEST_HANDLE(void) h; > size_t len; > } dm_op_buffer_t; This implies that we'll lose all type safety on the handles passed, as is also

Re: [Xen-devel] [RFC] x86/vm_event: Allow returning i-cache for emulation

On Sep 12, 2016 08:17, "George Dunlap" wrote: > > On 09/09/16 16:41, Tamas K Lengyel wrote: > > When emulating instructions the emulator maintains a small i-cache fetched > > from the guest memory. Under certain scenarios this memory region may contain > > instructions

Re: [Xen-devel] [PATCH v3 35/38] arm/p2m: Adjust debug information to altp2m

Hello Sergej, On 16/08/16 23:17, Sergej Proskurin wrote: Signed-off-by: Sergej Proskurin --- Cc: Stefano Stabellini Cc: Julien Grall --- v2: Dump p2m information of the hostp2m and all altp2m views. ---

Re: [Xen-devel] [PATCH v3 34/38] arm/p2m: Add HVMOP_altp2m_change_gfn

Hello Sergej, On 16/08/16 23:17, Sergej Proskurin wrote: This commit adds the functionality to change mfn mappings for specified gfn's in altp2m views. This mechanism can be used within the context of VMI, e.g., to establish stealthy debugging. Signed-off-by: Sergej Proskurin

Re: [Xen-devel] [PATCH v3 33/38] arm/p2m: Add altp2m paging mechanism

Hello Sergej, On 16/08/16 23:17, Sergej Proskurin wrote: This commit adds the function "altp2m_lazy_copy" implementing the altp2m paging mechanism. The function "altp2m_lazy_copy" lazily copies the hostp2m's mapping into the currently active altp2m view on 2nd stage translation faults on

Re: [Xen-devel] [RFC] x86/vm_event: Allow returning i-cache for emulation

On 09/09/16 16:41, Tamas K Lengyel wrote: > When emulating instructions the emulator maintains a small i-cache fetched > from the guest memory. Under certain scenarios this memory region may contain > instructions that a monitor subscriber would prefer to hide, namely INT3, and > instead would

Re: [Xen-devel] [PATCH 4/6] x86/xstate: Fix latent bugs in expand_xsave_states()

>>> On 12.09.16 at 15:57, wrote: > On 12/09/16 13:43, Jan Beulich wrote: > On 12.09.16 at 14:29, wrote: >>> On 12/09/16 12:41, Jan Beulich wrote: >>> On 12.09.16 at 11:51, wrote: > @@ -205,11 +222,9 @@

Re: [Xen-devel] [PATCH 4/6] x86/xstate: Fix latent bugs in expand_xsave_states()

On 12/09/16 13:43, Jan Beulich wrote: On 12.09.16 at 14:29, wrote: >> On 12/09/16 12:41, Jan Beulich wrote: >> On 12.09.16 at 11:51, wrote: @@ -205,11 +222,9 @@ void expand_xsave_states(struct vcpu *v, void *dest, unsigned

Re: [Xen-devel] [PATCH v3 32/38] arm/p2m: Code movement in instr/data abort handlers

Hi Sergej, On 16/08/16 23:17, Sergej Proskurin wrote: This commit moves code in the functions "do_trap_data_(instr|abort)_guest" without changing the original functionality. The code movement is limited to moving the struct npfec out of the switch statements in both functions. This commit acts

Re: [Xen-devel] [PATCH 6/6] x86/xstate: Fix latent bugs in compress_xsave_states()

>>> On 12.09.16 at 14:59, wrote: > On 12/09/16 13:27, Jan Beulich wrote: > On 12.09.16 at 11:51, wrote: >>> void compress_xsave_states(struct vcpu *v, const void *src, unsigned int >>> size) >>> { >>> struct xsave_struct *xsave =

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

On 09/09/16 16:16, Jennifer Herbert wrote: > The following code illustrates this idea: > > typedef struct dm_op_buffer { > XEN_GUEST_HANDLE(void) h; > size_t len; > } dm_op_buffer_t; > > int > HYPERVISOR_device_model_op( > domid_t domid, > unsigned int nr_buffers, >

Re: [Xen-devel] [PATCH 5/6] x86/domctl: Fix migration of guests which are not using xsave

>>> On 12.09.16 at 14:46, wrote: > On 12/09/16 13:14, Jan Beulich wrote: > On 12.09.16 at 11:51, wrote: >>> --- a/xen/arch/x86/domctl.c >>> +++ b/xen/arch/x86/domctl.c >>> @@ -1158,7 +1158,15 @@ long arch_do_domctl( >>>

Re: [Xen-devel] [PATCH 2/6] x86/domctl: Fix TOCTOU race with the use of XEN_DOMCTL_getvcpuextstate

>>> On 12.09.16 at 11:51, wrote: > A toolstack must call XEN_DOMCTL_getvcpuextstate twice; first to find the size > of the buffer to use, and a second time to get the actual content. > > The reported size was based on v->arch.xcr0_accum, but a guest which extends > its

Re: [Xen-devel] [PATCH 2/6] x86/domctl: Fix TOCTOU race with the use of XEN_DOMCTL_getvcpuextstate

>>> On 12.09.16 at 15:09, wrote: > On 12/09/16 13:33, Jan Beulich wrote: > On 12.09.16 at 14:02, wrote: >>> On 12/09/16 12:17, Jan Beulich wrote: >>> On 12.09.16 at 11:51, wrote: > A toolstack must call

Re: [Xen-devel] [PATCH 2/6] x86/domctl: Fix TOCTOU race with the use of XEN_DOMCTL_getvcpuextstate

On 12/09/16 13:33, Jan Beulich wrote: On 12.09.16 at 14:02, wrote: >> On 12/09/16 12:17, Jan Beulich wrote: >> On 12.09.16 at 11:51, wrote: A toolstack must call XEN_DOMCTL_getvcpuextstate twice; first to find the >> size

Re: [Xen-devel] [PATCH 6/6] x86/xstate: Fix latent bugs in compress_xsave_states()

On 12/09/16 13:27, Jan Beulich wrote: On 12.09.16 at 11:51, wrote: >> void compress_xsave_states(struct vcpu *v, const void *src, unsigned int >> size) >> { >> struct xsave_struct *xsave = v->arch.xsave_area; >> uint16_t

Re: [Xen-devel] [PATCH 6/6] x86/xstate: Fix latent bugs in compress_xsave_states()

>>> On 12.09.16 at 11:51, wrote: > void compress_xsave_states(struct vcpu *v, const void *src, unsigned int > size) > { > struct xsave_struct *xsave = v->arch.xsave_area; > uint16_t comp_offsets[sizeof(xfeature_mask)*8]; > -u64 xstate_bv = ((const

Re: [Xen-devel] [PATCH 5/6] x86/domctl: Fix migration of guests which are not using xsave

On 12/09/16 13:14, Jan Beulich wrote: On 12.09.16 at 11:51, wrote: >> --- a/xen/arch/x86/domctl.c >> +++ b/xen/arch/x86/domctl.c >> @@ -1158,7 +1158,15 @@ long arch_do_domctl( >> goto vcpuextstate_out; >> } >> >> -if (

Re: [Xen-devel] [PATCH 4/6] x86/xstate: Fix latent bugs in expand_xsave_states()

>>> On 12.09.16 at 14:29, wrote: > On 12/09/16 12:41, Jan Beulich wrote: > On 12.09.16 at 11:51, wrote: >>> @@ -205,11 +222,9 @@ void expand_xsave_states(struct vcpu *v, void *dest, >>> unsigned int size) >>> >>> if ( src )

Re: [Xen-devel] [PATCH 4/6] x86/xstate: Fix latent bugs in expand_xsave_states()

>>> On 12.09.16 at 14:29, wrote: > On 12/09/16 12:41, Jan Beulich wrote: > On 12.09.16 at 11:51, wrote: >>> @@ -205,11 +222,9 @@ void expand_xsave_states(struct vcpu *v, void *dest, >>> unsigned int size) >>> >>> if ( src )

[Xen-devel] [xen-unstable-smoke test] 100891: tolerable all pass - PUSHED

flight 100891 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100891/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

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

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

Re: [Xen-devel] [PATCH 2/6] x86/domctl: Fix TOCTOU race with the use of XEN_DOMCTL_getvcpuextstate

>>> On 12.09.16 at 14:02, wrote: > On 12/09/16 12:17, Jan Beulich wrote: > On 12.09.16 at 11:51, wrote: >>> A toolstack must call XEN_DOMCTL_getvcpuextstate twice; first to find the > size >>> of the buffer to use, and a second time to

Re: [Xen-devel] Getting started with Xen Project

On Sat, Sep 10, 2016 at 03:51:33PM +0530, Aashaka Shah wrote: > Hello! I am Aashaka. I like computer architecture and have a good knowledge > of C. While browsing Outreachy projects, I came across the project about > adding PVH support to OVMF binaries. Since it looked interesting, I started >

Re: [Xen-devel] [PATCH 4/6] x86/xstate: Fix latent bugs in expand_xsave_states()

On 12/09/16 12:41, Jan Beulich wrote: On 12.09.16 at 11:51, wrote: >> @@ -176,6 +187,11 @@ void expand_xsave_states(struct vcpu *v, void *dest, >> unsigned int size) >> u64 xstate_bv = xsave->xsave_hdr.xstate_bv; >> u64 valid; >> >> +/* Check there

[Xen-devel] [distros-debian-sid test] 67696: tolerable FAIL

flight 67696 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67696/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-i386-sid-netboot-pvgrub 9 debian-di-install fail like 67637

Re: [Xen-devel] [PATCH 5/6] x86/domctl: Fix migration of guests which are not using xsave

>>> On 12.09.16 at 11:51, wrote: > --- a/xen/arch/x86/domctl.c > +++ b/xen/arch/x86/domctl.c > @@ -1158,7 +1158,15 @@ long arch_do_domctl( > goto vcpuextstate_out; > } > > -if ( evc->size <= PV_XSAVE_SIZE(_xcr0_accum) ) > +

Re: [Xen-devel] [PATCH v3 29/38] arm/p2m: Add HVMOP_altp2m_set_mem_access

Hi Sergej, On 16/08/16 23:17, Sergej Proskurin wrote: The HVMOP_altp2m_set_mem_access allows to set gfn permissions of (currently one page at a time) of a specific altp2m view. In case the view does not hold the requested gfn entry, it will be first copied from the host's p2m table and then

Re: [Xen-devel] [PATCH 2/6] x86/domctl: Fix TOCTOU race with the use of XEN_DOMCTL_getvcpuextstate

On 12/09/16 12:17, Jan Beulich wrote: On 12.09.16 at 11:51, wrote: >> A toolstack must call XEN_DOMCTL_getvcpuextstate twice; first to find the >> size >> of the buffer to use, and a second time to get the actual content. >> >> The reported size was based on

Re: [Xen-devel] [PATCH net-next] xen-netfront: avoid packet loss when ethernet header crosses page boundary

David Vrabel writes: > On 22/08/16 16:42, Vitaly Kuznetsov wrote: >> Small packet loss is reported on complex multi host network configurations >> including tunnels, NAT, ... My investigation led me to the following check >> in netback which drops packets: >> >>

Re: [Xen-devel] [PATCH 4/6] x86/xstate: Fix latent bugs in expand_xsave_states()

>>> On 12.09.16 at 11:51, wrote: > @@ -176,6 +187,11 @@ void expand_xsave_states(struct vcpu *v, void *dest, > unsigned int size) > u64 xstate_bv = xsave->xsave_hdr.xstate_bv; > u64 valid; > > +/* Check there is state to serialise (i.e. at least an

  1   2   >