[Xen-devel] [PATCH v3 01/24] x86/shadow: Fix #PFs from emulated writes crossing a page boundary

When translating the second frame of a write crossing a page boundary, mask the linear address down to the page boundary. This causes the correct %cr2 being reported to the guest in the case that the second frame suffers a pagefault during translation. Signed-off-by: Andrew Cooper

[Xen-devel] [PATCH v3 03/24] x86/emul: Simplfy emulation state setup

The current code to set up emulation state is ad-hoc and error prone. * Consistently zero all emulation state structures. * Avoid explicitly initialising some state to 0. * Explicitly identify all input and output state in x86_emulate_ctxt. This involves rearanging some fields. * Have

Re: [Xen-devel] [PATCH v9 07/13] x86: add multiboot2 protocol support for EFI platforms

On Fri, Nov 25, 2016 at 12:50:55AM -0700, Jan Beulich wrote: > >>> On 24.11.16 at 22:44, wrote: > > On Thu, Nov 24, 2016 at 04:08:12AM -0700, Jan Beulich wrote: > >> >>> On 23.11.16 at 19:52, wrote: > >> > On 29/09/16 22:42, Daniel Kiper wrote:

Re: [Xen-devel] [PATCH v3.1 15/15] xen/x86: setup PVHv2 Dom0 ACPI tables

On Mon, Nov 14, 2016 at 09:15:37AM -0700, Jan Beulich wrote: > >>> On 29.10.16 at 11:00, wrote: > > Also, regions marked as E820_ACPI or E820_NVS are identity mapped into Dom0 > > p2m, plus any top-level ACPI tables that should be accessible to Dom0 and > > that don't reside

Re: [Xen-devel] [PATCH v2] xen/arm: Add support for 16 bit VMIDs

Hi Julien, >> >> VMID space is increased to 16-bits from 8-bits in ARMv8 8.1 revision. >> This allows more than 256 VMs to be supported by Xen. >> >> This change adds support for 16-bit VMIDs in Xen based on whether the >> architecture supports it. >> >> Signed-off-by: Bhupinder Thakur

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

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

Re: [Xen-devel] [PATCH 1/3] Don't create default ioreq server

On 30/11/16 09:47, Zhang Chen wrote: > The ioreq server make colo run failed. > > Signed-off-by: Zhang Chen > Signed-off-by: Wen Congyang Nack. You can simply "fix" a COLO issue by breaking a much more common usecase. What actually breaks

[Xen-devel] [PATCH v10 12/13] x86/boot: rename sym_phys() to sym_offs()

This way macro name better describes its function. Currently it is used to calculate symbol offset in relation to the beginning of Xen image mapping. However, value returned by sym_offs() for a given symbol is not always equal its physical address. There is no functional change. Suggested-by:

[Xen-devel] [PATCH v10 03/13] 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 Acked-by: Jan Beulich --- v6 - suggestions/fixes: - move this commit behind "efi: create efi_enabled()" commit

[Xen-devel] [PATCH v10 11/13] 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 v10 08/13] 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 v10 07/13] 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 --- v10 - suggestions/fixes: - replace ljmpl with lretq (suggested by Andrew Cooper), - introduce efi_platform to

[Xen-devel] [PATCH v10 09/13] x86: change default load address from 1 MiB to 2 MiB

Subsequent patches introducing relocatable early boot code play with page tables using 2 MiB huge pages. If load address is not aligned at 2 MiB then code touching such page tables must have special cases for start and end of Xen image memory region. So, let's make life easier and move default

[Xen-devel] [PATCH v10 13/13] 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 v10 10/13] x86/setup: use XEN_IMG_OFFSET instead of...

..calculating its value during runtime. Signed-off-by: Daniel Kiper Acked-by: Jan Beulich --- 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

[Xen-devel] [PATCH v10 06/13] 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 v10 05/13] 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 v10 00/13] x86: multiboot2 protocol support

Hi, I am sending tenth version of multiboot2 protocol support for legacy BIOS and EFI platforms. This patch series release contains fixes for all known issues. The final goal is xen.efi binary file which could be loaded by EFI loader, multiboot (v1) protocol (only on legacy BIOS platforms) and

[Xen-devel] [PATCH v10 01/13] 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 Reviewed-by: Jan Beulich

[Xen-devel] [PATCH v10 04/13] x86: properly calculate xen ELF end of image address

This patch is prereq for "efi: build xen.gz with EFI code" patch which adds, among others, xen/arch/x86/efi/relocs-dummy.S to xen.gz output. Below there is a description why it is needed. Currently xen ELF end of image address is calculated using first line from "nm -nr xen/xen-syms" output.

[Xen-devel] [PATCH v10 02/13] 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

Re: [Xen-devel] xen-4.8-rc7 in Stretch with linux-image 4.8 fails to boot domU with pv-grub

On 30/11/16 10:41, Jan Beulich wrote: On 30.11.16 at 01:29, wrote: >> Built & packaged xen 4.8-rc7 in Stretch (deb9) today. >> xen-4.8-rc7 in Stretch with linux-image 4.8, fails to boot domU kernel with >> pv-grub: https://paste.debian.net/plain/899726 >> from

Re: [Xen-devel] [COVERITY ACCESS] for Embedded/Automotive team

Done On 29.11.16 20:19, Stefano Stabellini wrote: > On Tue, 29 Nov 2016, Artem Mygaiev wrote: >> Hi Julien >> >> On 29.11.16 16:27, Julien Grall wrote: >>> Hi Artem, >>> >>> On 29/11/16 14:21, Artem Mygaiev wrote: Lars, the project is approved by Coverity. Scan has found some issues in

Re: [Xen-devel] [COVERITY ACCESS] for Embedded/Automotive team

Hi Lars On 29.11.16 17:04, Lars Kurth wrote: > Please don't post them to xen-devel@ though: as a one-off, you may want to > send to Julien and maybe Stefano > Longer term, we ought to find a way to send the output to a safe place, as > for x86 > Lars I have added Julien, Stefano and you as

Re: [Xen-devel] [DOC v1] Xen transport for 9pfs

On 29/11/16 23:34, Stefano Stabellini wrote: > > The producer (the backend for **in**, the frontend for **out**) writes to the > array in the following way: > - read memory barrier > - read *cons*, *prod* from shared memory > - write to array at position *prod* up to *cons*, wrapping around the

Re: [Xen-devel] [PATCH] arm/acpi: hide watchdog timer in GTDT table for dom0

Hi Shanker, On 29/11/2016 02:59, Shanker Donthineni wrote: Either we have to hide the watchdog timer section in GTDT or emulate watchdog timer block for dom0. Otherwise, system gets panic when dom0 accesses its MMIO registers. The current XEN doesn't support virtualization of watchdog timer, so

Re: [Xen-devel] [PATCH v3 04/15] x86: refactor psr: Encapsulate 'cbm_len' and 'cbm_max'

On 16-11-30 02:42:20, Jan Beulich wrote: > >>> On 30.11.16 at 10:08, wrote: > > On 16-11-29 02:43:24, Jan Beulich wrote: > >> >>> On 29.11.16 at 05:38, wrote: > >> > To make codes be better reviewable, I propose below three suggestions: > >> >

Re: [Xen-devel] [PATCH] arm/acpi: hide watchdog timer in GTDT table for dom0

On Wed, Nov 30, 2016 at 01:54:00AM -0700, Jan Beulich wrote: > >>> On 29.11.16 at 21:19, wrote: > > On 29/11/16 12:09, Roger Pau Monne wrote: > >> On Tue, Nov 29, 2016 at 04:44:18AM -0700, Jan Beulich wrote: > >> On 29.11.16 at 12:38, wrote: >

[Xen-devel] [xen-unstable-coverity test] 102731: all pass - PUSHED

flight 102731 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/102731/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen a7a578ce6b8634eec30cb8445ea98e18d9b4e9b8 baseline version: xen

[Xen-devel] [PATCH 2/3] Add Xen colo support for qemu-upstream colo codes

Because of qemu codes update, we update Xen colo block codes Signed-off-by: Zhang Chen --- tools/libxl/libxl_colo_qdisk.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_colo_qdisk.c b/tools/libxl/libxl_colo_qdisk.c index

[Xen-devel] [PATCH 3/3] Add COLO replication top-id support

Because of qemu colo add the top-id, so we update it. Signed-off-by: Zhang Chen --- tools/libxl/libxl_dm.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index ad366a8..815938e 100644 ---

[Xen-devel] [PATCH 0/3] Support the latest version of qemu COLO

Because of new version COLO has been merged by QEMU, Some codes has changed by community comments. So, we must update Xen COLO codes to support latest qemu. Zhang Chen (3): Don't create default ioreq server Add Xen colo support for qemu-upstream colo codes Add COLO replication top-id

Re: [Xen-devel] [PATCH] arm/acpi: hide watchdog timer in GTDT table for dom0

Hi Stefano, On 29/11/2016 19:08, Stefano Stabellini wrote: On Mon, 28 Nov 2016, Shanker Donthineni wrote: Either we have to hide the watchdog timer section in GTDT or emulate watchdog timer block for dom0. Otherwise, system gets panic when dom0 accesses its MMIO registers. The current XEN

[Xen-devel] [PATCH 1/3] Don't create default ioreq server

The ioreq server make colo run failed. Signed-off-by: Zhang Chen Signed-off-by: Wen Congyang --- xen/arch/x86/hvm/hvm.c | 11 --- 1 file changed, 11 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index

Re: [Xen-devel] [PATCH v3 04/15] x86: refactor psr: Encapsulate 'cbm_len' and 'cbm_max'

>>> On 30.11.16 at 10:08, wrote: > On 16-11-29 02:43:24, Jan Beulich wrote: >> >>> On 29.11.16 at 05:38, wrote: >> > To make codes be better reviewable, I propose below three suggestions: >> > 1) I write a design document about refactor to make

Re: [Xen-devel] xen-4.8-rc7 in Stretch with linux-image 4.8 fails to boot domU with pv-grub

>>> On 30.11.16 at 01:29, wrote: > Built & packaged xen 4.8-rc7 in Stretch (deb9) today. > xen-4.8-rc7 in Stretch with linux-image 4.8, fails to boot domU kernel with > pv-grub: https://paste.debian.net/plain/899726 > from config/Tools.mk: ZLIB := -DHAVE_BZLIB -lbz2

Re: [Xen-devel] [PATCH RFC 1/2] xen/page_alloc: Add size_align parameter to provide MFNs which are size aligned.

>>> On 30.11.16 at 05:39, wrote: > This is to support the requirement that exists in PV dom0 > when doing DMA requests: > > "dma_alloc_coherent() > [...] > The CPU virtual address and the DMA address are both guaranteed to be > aligned to the smallest PAGE_SIZE order which is

Re: [Xen-devel] [PATCH v3 04/15] x86: refactor psr: Encapsulate 'cbm_len' and 'cbm_max'

On 16-11-29 02:43:24, Jan Beulich wrote: > >>> On 29.11.16 at 05:38, wrote: > > To make codes be better reviewable, I propose below three suggestions: > > 1) I write a design document about refactor to make you more easily > > understand the ideas. > > This is

Re: [Xen-devel] [PATCH v14] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

On 11/30/2016 10:45 AM, Jan Beulich wrote: On 29.11.16 at 19:44, wrote: On 11/29/2016 08:30 PM, Dario Faggioli wrote: On Tue, 2016-11-29 at 19:27 +0200, Oleksandr Andrushchenko wrote: On 11/29/2016 07:05 PM, Jan Beulich wrote: If you document it as padding, you can't

Re: [Xen-devel] [PATCH v3.1 07/15] xen/x86: do the PCI scan unconditionally

>>> On 30.11.16 at 06:53, wrote: > I'm OK with this policy change. Although there is no strict dependency > between VT-d and PCI scan, the purpose of VT-d is for PCI-based > device assignment. How is there not, considering the bus to bridge mapping? Within IOMMU code, VT-d

Re: [Xen-devel] [PATCH] arm/acpi: hide watchdog timer in GTDT table for dom0

>>> On 29.11.16 at 21:19, wrote: > On 29/11/16 12:09, Roger Pau Monne wrote: >> On Tue, Nov 29, 2016 at 04:44:18AM -0700, Jan Beulich wrote: >> On 29.11.16 at 12:38, wrote: On Tue, Nov 29, 2016 at 03:40:37AM -0700, Jan Beulich wrote:

Re: [Xen-devel] [PATCH v14] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

>>> On 29.11.16 at 19:44, wrote: > On 11/29/2016 08:30 PM, Dario Faggioli wrote: >> On Tue, 2016-11-29 at 19:27 +0200, Oleksandr Andrushchenko wrote: >>> On 11/29/2016 07:05 PM, Jan Beulich wrote: If you document it as padding, you can't easily use it later on for

Re: [Xen-devel] [PATCH v2 06/19] x86/pv: Implement pv_inject_{event, page_fault, hw_exception}()

>>> On 29.11.16 at 17:50, wrote: > On 29/11/16 16:00, Jan Beulich wrote: > On 28.11.16 at 12:13, wrote: >>> The existing propagate_page_fault() is fairly similar to >>> pv_inject_page_fault(), although it has a return value. Only a

[Xen-devel] [qemu-upstream-4.6-testing baseline-only test] 68124: tolerable FAIL

This run is configured for baseline tests only. flight 68124 qemu-upstream-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68124/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16

<    1   2