[Xen-devel] [linux-3.18 test] 102732: regressions - FAIL

flight 102732 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/102732/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-bootfail REGR. vs. 101675

[Xen-devel] [xen-4.4-testing test] 102730: regressions - trouble: blocked/broken/fail/pass

flight 102730 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/102730/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 3 host-install(3)broken REGR. vs. 102521

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

On Fri, 25 Nov 2016, Julien Grall wrote: > Hi Stefano, > > On 23/11/16 19:55, Stefano Stabellini wrote: > > Actually I am thinking that the default values should be in the > > emulators themselves. After all they are the part of the code that knows > > more about vuarts. > > Can you expand what

Re: [Xen-devel] [PATCH] xen/arm: Fix misplaced parentheses for PSCI version check

On Wed, Nov 30, 2016 at 11:16:49AM -0800, Stefano Stabellini wrote: > On Wed, 30 Nov 2016, Julien Grall wrote: > > Hi Artem, > > > > On 30/11/16 13:53, Artem Mygaiev wrote: > > > Fix misplaced parentheses for PSCI version check > > > > > > Signed-off-by: Artem Mygaiev >

[Xen-devel] [xen-4.5-testing baseline-only test] 68129: regressions - FAIL

This run is configured for baseline tests only. flight 68129 xen-4.5-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68129/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-520

[Xen-devel] tap device name for emulated NIC too long

Hi All, During the last Wg-openstack meetup we briefly discussed a long-standing bug when using Xen+libvirt+OpenStack with Neutron networking https://bugs.launchpad.net/nova/+bug/1450465 The bug was also discussed on this list with no resolution

Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

On Fri, 25 Nov 2016, Julien Grall wrote: > Hi, > > On 18/11/16 18:39, Stefano Stabellini wrote: > > On Fri, 11 Nov 2016, Stefano Stabellini wrote: > > > On Fri, 11 Nov 2016, Julien Grall wrote: > > > > On 10/11/16 20:42, Stefano Stabellini wrote: > > > > That's why in the approach we had on the

Re: [Xen-devel] [PATCH v4 06/14] x86/vtd: refuse to enable IOMMU if the PCI scan fails

> From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: Thursday, December 01, 2016 12:50 AM > > This provides uniform behavior between Intel and AMD IOMMU initialization, and > is a requirement for PVHv2 Dom0, that depends on a working IOMMU plus the PCI > bus being scanned for devices. >

Re: [Xen-devel] [ARM] Handling CMA pool device nodes in Dom0

On Tue, 29 Nov 2016, Julien Grall wrote: > (CC Stefano) > > On 25/11/16 12:19, Iurii Mykhalskyi wrote: > > Hello! > > Hi Iurii, > > > > > I'm working under Renesas Gen3 H3 board with 4GB RAM (Salvator-X) > > support in Xen mainline. > > > > Salvator-X has several CMA pool nodes, for example:

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

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

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

On Wed, 23 Nov 2016, Lars Kurth wrote: > List of changes > - Added Goal: Local Decision Making > - Split roles into project wide and sub-project specific roles > - Added new roles: Community Manager, Security Response Team, Leadership Team > - Added RTC Policy > - Added +2 ... -2 scheme for

[Xen-devel] [libvirt test] 102726: tolerable all pass - PUSHED

flight 102726 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/102726/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 102706 test-armhf-armhf-libvirt 13

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

flight 102725 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/102725/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-raw 10 guest-start fail REGR. vs. 102536

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

On Wed, 30 Nov 2016, Julien Grall wrote: > Hi all, > > Few months ago, Linaro has published the version 2 of the VM specification > [1]. > > For those who don't know, the specification provides guidelines to guarantee a > compliant OS images could run on various hypervisor (e.g Xen, KVM). > >

Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

On Mon, 28 Nov 2016, Julien Grall wrote: > > > If not, then it might be worth to consider a 3rd solution where the TEE > > > SMC > > > calls are forwarded to a specific domain handling the SMC on behalf of the > > > guests. This would allow to upgrade the TEE layer without having to > > > upgrade

Re: [Xen-devel] How to Build Xen for UEFI native boot

On Wed, Nov 30, 2016 at 06:31:15PM +, Bill Jacobs (billjac) wrote: > Hi All > > Relative newb to Xen. > > Would like to build Xen for UEFI Native boot behind GRUB2 (EFI), and see many > resources 'out there', many of which are dated. Where's the best current > place to start down this

[Xen-devel] [xen-4.6-testing test] 102723: regressions - FAIL

flight 102723 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/102723/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 10 guest-start fail REGR. vs. 102712 Regressions

[Xen-devel] How to Build Xen for UEFI native boot

Hi All Relative newb to Xen. Would like to build Xen for UEFI Native boot behind GRUB2 (EFI), and see many resources 'out there', many of which are dated. Where's the best current place to start down this path? Thanks -Bill ___ Xen-devel mailing

[Xen-devel] [PATCH 02/36] qdict: Add convenience helpers for wrapped puts

Quite a few users of qdict_put() were manually wrapping a non-QObject. We can make such call-sites shorter, by providing common macros to do the tedious work. Also shorten nearby qdict_put_obj(,,QOBJECT()) sequences. Signed-off-by: Eric Blake --- I'm okay if you want me to

[Xen-devel] [distros-debian-squeeze test] 68128: tolerable FAIL

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

Re: [Xen-devel] DomU application crashes while mmap'ing device memory on x86_64

Thank you for explanation, now it is clear. BTW, is PAGE_SHARED the right choice in my case or should I use something else instead? Thank you, Oleksandr On 11/30/2016 09:10 PM, Andrew Cooper wrote: On 30/11/16 19:00, Oleksandr Andrushchenko wrote: I traced the problem down to

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

On 29/11/16 15:09, 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 >>> xen/arch/arm on master, part of them are false positives. >>

Re: [Xen-devel] [PATCH] xen/arm: Fix misplaced parentheses for PSCI version check

On Wed, 30 Nov 2016, Julien Grall wrote: > Hi Artem, > > On 30/11/16 13:53, Artem Mygaiev wrote: > > Fix misplaced parentheses for PSCI version check > > > > Signed-off-by: Artem Mygaiev > > Can you please include the coverity ID: > > Coverity-ID: 1381830 > > With

Re: [Xen-devel] DomU application crashes while mmap'ing device memory on x86_64

On 30/11/16 19:00, Oleksandr Andrushchenko wrote: > I traced the problem down to vma->vm_page_prot which > > in my case is set as: > > vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > > This sets additional flags _PAGE_BIT_PSE/_PAGE_BIT_PAT +_PAGE_BIT_PCD > > so after that

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

Thank you! On Wed, 30 Nov 2016, Artem Mygaiev wrote: > 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: >

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

On Wed, 30 Nov 2016, Shanker Donthineni wrote: > Hi Julien, > > We are using Fu's [v5] patch series > https://patchwork.codeaurora.org/patch/20325/ in our testing. We thought > system crash in xen was related to watchdog timer driver, so removed the > watchdog timer sections including GT blocks

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

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

Re: [Xen-devel] DomU application crashes while mmap'ing device memory on x86_64

I traced the problem down to vma->vm_page_prot which in my case is set as: vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); This sets additional flags _PAGE_BIT_PSE/_PAGE_BIT_PAT +_PAGE_BIT_PCD so after that remap_pfn_range makes Xen complain. (pgprot_noncached(vma->vm_page_prot) ==

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

On Wed, 30 Nov 2016, Julien Grall wrote: > 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

[Xen-devel] [xen-4.6-testing baseline-only test] 68126: regressions - FAIL

This run is configured for baseline tests only. flight 68126 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68126/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-120

[Xen-devel] [qemu-mainline test] 102722: tolerable FAIL - PUSHED

flight 102722 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/102722/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 102621

Re: [Xen-devel] [PATCH v3 10/24] x86/emul: Always use fault semantics for software events

On 11/30/2016 08:50 AM, Andrew Cooper wrote: > The common case is already using fault semantics out of x86_emulate(), as that > is how VT-x/SVM expects to inject the event (given suitable hardware support). > > However, x86_emulate() returning X86EMUL_EXCEPTION and also completing a > register

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

On Wed, Nov 30, 2016 at 06:59:57AM -0700, Jan Beulich wrote: > >>> On 30.11.16 at 14:45, wrote: > > 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

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

Hello Julien, On 30 November 2016 at 17:29, Julien Grall wrote: [...] > I think we can distinct two places where the PL011 could be emulated: > in the hypervisor, or outside the hypervisor. > > Emulating the UART in the hypervisor means that we take the risk to increase >

[Xen-devel] [PATCH v4 11/14] xen/x86: parse Dom0 kernel for PVHv2

Introduce a helper to parse the Dom0 kernel. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper --- Changes since v3: - Change one error message. - Indent "out" label by one space. - Introduce

[Xen-devel] [PATCH v4 09/14] xen/x86: split Dom0 build into PV and PVHv2

Split the Dom0 builder into two different functions, one for PV (and classic PVH), and another one for PVHv2. Introduce a new command line parameter called 'dom0' that can be used to request the creation of a PVHv2 Dom0 by setting the 'hvm' sub-option. A panic has also been added if a user tries

[Xen-devel] [PATCH v4 05/14] xen/x86: split the setup of Dom0 permissions to a function

So that it can also be used by the PVH-specific domain builder. This is just code motion, it should not introduce any functional change. Signed-off-by: Roger Pau Monné Acked-by: Jan Beulich --- Cc: Andrew Cooper Cc: Jan

[Xen-devel] [PATCH v4 13/14] xen/x86: hack to setup PVHv2 Dom0 CPUs

Initialize Dom0 BSP/APs and setup the memory and IO permissions. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper --- DO NOT APPLY. The logic used to setup the CPUID leaves is clearly lacking. This patch

[Xen-devel] [PATCH v4 00/14] Initial PVHv2 Dom0 support

Hello, This is the first batch of the PVHv2 Dom0 support series, that includes everything up to the point where ACPI tables for Dom0 are crafted. I've decided to left the last part of the series (the one that contains the PCI config space handlers, and other emulation/trapping related code)

[Xen-devel] [PATCH v4 01/14] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests

PVHv2 guests, unlike HVM guests, won't have the option to route interrupts from physical or emulated devices over event channels using PIRQs. This applies to both DomU and Dom0 PVHv2 guests. Introduce a new XEN_X86_EMU_USE_PIRQ to notify Xen whether a HVM guest can route physical interrupts (even

[Xen-devel] [PATCH v4 03/14] xen/x86: allow calling {shadow/hap}_set_allocation with the idle domain

... and using the "preempted" parameter. Introduce a new helper that can be used from both hypercall or idle vcpu context (ie: during Dom0 creation) in order to check if preemption is needed. If such preemption happens, the caller should then call process_pending_softirqs in order to drain the

[Xen-devel] [PATCH v4 07/14] x86/iommu: add IOMMU entries for p2m_mmio_direct pages

There's nothing wrong with allowing the domain to perform DMA transfers to MMIO areas that it already can access from the CPU, and this allows us to remove the hack in set_identity_p2m_entry for PVH Dom0. Signed-off-by: Roger Pau Monné --- xen/arch/x86/mm/p2m.c | 9

[Xen-devel] [PATCH v4 12/14] x86/PVHv2: fix dom0_max_vcpus so it's capped to 128 for PVHv2 Dom0

PVHv2 Dom0 is limited to 128 vCPUs, as are all HVM guests at the moment. Fix dom0_max_vcpus so it takes this limitation into account by poking at the dom0_hvm variable. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper

[Xen-devel] [PATCH v4 10/14] xen/x86: populate PVHv2 Dom0 physical memory map

Craft the Dom0 e820 memory map and populate it. Introduce a helper to remove memory pages that are shared between Xen and a domain, and use it in order to remove low 1MB RAM regions from dom_io in order to assign them to a PVHv2 Dom0. Signed-off-by: Roger Pau Monné --- Cc:

[Xen-devel] [PATCH v4 04/14] x86/paging: introduce paging_set_allocation

... and remove hap_set_alloc_for_pvh_dom0. While there also change the last parameter of the {hap/shadow}_set_allocation functions to be a boolean. Signed-off-by: Roger Pau Monné Acked-by: Tim Deegan Acked-by: George Dunlap

[Xen-devel] [PATCH v4 08/14] xen/x86: allow the emulated APICs to be enabled for the hardware domain

Allow the use of both the emulated local APIC and IO APIC for the hardware domain. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper --- Changes since v3: - Don't enable the emulated PIT for PVHv2 Dom0.

[Xen-devel] [PATCH v4 02/14] xen/x86: fix return value of *_set_allocation functions

Return should be an int. Signed-off-by: Roger Pau Monné Acked-by: George Dunlap Acked-by: Tim Deegan --- Cc: George Dunlap Cc: Jan Beulich Cc: Andrew Cooper

[Xen-devel] [PATCH v4 06/14] x86/vtd: refuse to enable IOMMU if the PCI scan fails

This provides uniform behavior between Intel and AMD IOMMU initialization, and is a requirement for PVHv2 Dom0, that depends on a working IOMMU plus the PCI bus being scanned for devices. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew

[Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables

Create a new MADT table that contains the topology exposed to the guest. A new XSDT table is also created, in order to filter the tables that we want to expose to the guest, plus the Xen crafted MADT. This in turn requires Xen to also create a new RSDP in order to make it point to the custom XSDT.

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 17:42, wrote: > On Wed, Nov 30, 2016 at 02:30:41AM -0700, Jan Beulich wrote: >> >>> On 30.11.16 at 05:39, wrote: >> > This is to support the requirement that exists in PV dom0 >> > when doing DMA requests: >> > >> >

Re: [Xen-devel] [PATCH v3 07/24] x86/emul: Clean up the naming of the retire union

>>> On 30.11.16 at 15:05, wrote: >> From: Andrew Cooper >> Sent: 30 November 2016 14:02 >> On 30/11/16 13:58, Paul Durrant wrote: >> > Also, anonymous unions are not part of C99 AFAIK... are we now stipulating >> something more recent? >> >> We used gnu99 for as long as

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

On Wed, Nov 30, 2016 at 02:30:41AM -0700, Jan Beulich wrote: > >>> 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

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

>>> On 30.11.16 at 15:23, wrote: > On Wed, Nov 30, 2016 at 07:09:47AM -0700, Jan Beulich wrote: >> >>> On 30.11.16 at 13:40, wrote: >> > On Mon, Nov 14, 2016 at 09:15:37AM -0700, Jan Beulich wrote: >> >> >>> On 29.10.16 at 11:00,

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

On Wed, Nov 30, 2016 at 03:29:32PM +, Julien Grall wrote: > Hi all, > > Few months ago, Linaro has published the version 2 of the VM > specification [1]. > > For those who don't know, the specification provides guidelines to > guarantee a compliant OS images could run on various hypervisor

Re: [Xen-devel] [PATCH] xen/arm: Fix misplaced parentheses for PSCI version check

Hi Artem, On 30/11/16 13:53, Artem Mygaiev wrote: Fix misplaced parentheses for PSCI version check Signed-off-by: Artem Mygaiev Can you please include the coverity ID: Coverity-ID: 1381830 With that: Reviewed-by: Julien Grall This has been

Re: [Xen-devel] [PATCH v3 13/24] x86/emul: Rework emulator event injection

> -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: 30 November 2016 13:51 > To: Xen-devel > Cc: Andrew Cooper ; Jan Beulich > ; Paul Durrant ; Tim > (Xen.org)

Re: [Xen-devel] [PATCH v3 22/24] x86/hvm: Avoid __hvm_copy() raising #PF behind the emulators back

> -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: 30 November 2016 13:51 > To: Xen-devel > Cc: Andrew Cooper ; Paul Durrant > > Subject: [PATCH v3 22/24] x86/hvm: Avoid

Re: [Xen-devel] [PATCH v3 11/24] x86/emul: Implement singlestep as a retire flag

> -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: 30 November 2016 13:50 > To: Xen-devel > Cc: Andrew Cooper ; Jan Beulich > ; Tim (Xen.org) ; Paul Durrant >

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

Hi Julien, We are using Fu's [v5] patch series https://patchwork.codeaurora.org/patch/20325/ in our testing. We thought system crash in xen was related to watchdog timer driver, so removed the watchdog timer sections including GT blocks in GTDT to fix the crash. Let me root cause the issue

[Xen-devel] [xen-4.5-testing test] 102721: tolerable FAIL - PUSHED

flight 102721 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/102721/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate fail like 102543

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

On Wed, Nov 30, 2016 at 07:09:47AM -0700, Jan Beulich wrote: > >>> On 30.11.16 at 13:40, wrote: > > 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

[Xen-devel] Xen ARM - Exposing a PL011 to the guest

Hi all, Few months ago, Linaro has published the version 2 of the VM specification [1]. For those who don't know, the specification provides guidelines to guarantee a compliant OS images could run on various hypervisor (e.g Xen, KVM). Looking at the specification, it will require Xen to

Re: [Xen-devel] [PATCH v3 07/24] x86/emul: Clean up the naming of the retire union

> -Original Message- > From: Andrew Cooper > Sent: 30 November 2016 14:02 > To: Paul Durrant ; Xen-devel de...@lists.xen.org> > Cc: Jan Beulich > Subject: Re: [PATCH v3 07/24] x86/emul: Clean up the naming of the retire > union > > On 30/11/16

Re: [Xen-devel] [PATCH v3 07/24] x86/emul: Clean up the naming of the retire union

On 30/11/16 13:58, Paul Durrant wrote: >> -Original Message- >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] >> Sent: 30 November 2016 13:50 >> To: Xen-devel >> Cc: Andrew Cooper ; Jan Beulich >> ; Paul

Re: [Xen-devel] [PATCH v3 07/24] x86/emul: Clean up the naming of the retire union

> -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: 30 November 2016 13:50 > To: Xen-devel > Cc: Andrew Cooper ; Jan Beulich > ; Paul Durrant > Subject:

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

On 30/11/16 14:43, Shanker Donthineni wrote: Hi Julien, Hi Shanker, On 11/30/2016 08:31 AM, Shanker Donthineni wrote: On 11/30/2016 04:29 AM, Julien Grall wrote: Hi Shanker, On 29/11/2016 02:59, Shanker Donthineni wrote: Either we have to hide the watchdog timer section in GTDT or

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

Hi Julien, On 11/30/2016 08:31 AM, Shanker Donthineni wrote: Hi Julien, On 11/30/2016 04:29 AM, Julien Grall wrote: 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,

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

On 30/11/16 14:31, Shanker Donthineni wrote: Hi Julien, Hi Shanker, On 11/30/2016 04:29 AM, Julien Grall wrote: 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

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

On 30/11/16 08:41, Jan Beulich wrote: if ( unlikely(null_trap_bounce(v, tb)) ) -gprintk(XENLOG_WARNING, -"Unhandled %s fault/trap [#%d, ec=%04x]\n", -trapstr(trapnr), trapnr, regs->error_code); +{ +if ( vector

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

Hi Julien, On 11/30/2016 04:29 AM, Julien Grall wrote: 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

[Xen-devel] [OSSTEST PATCH 1/2] Executive database: set isolation level in Perl

The Perl was lacking SET TRANSACTION ISOLATION LEVEL SERIALIZABLE, which is sadly not the default. Currently that does not matter because of all the table locking, but we are about to abolish that. Signed-off-by: Ian Jackson --- Osstest/JobDB/Executive.pm | 3 +++ 1

[Xen-devel] [OSSTEST PATCH 2/2] Executive database: stub out use of LOCK TABLES

We want to improve database performance, and one of the problems is excessive locking. Postgresql now has predictate locking, and we have, we think, eliminated all the places that do not handle a database transaction failure. So we can rely on optimistic concurrency. So, eliminate all uses of

[Xen-devel] [PATCH v3 19/24] x86/hvm: Extend the hvm_copy_*() API with a pagefault_info pointer

which is filled with pagefault information should one occur. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Tim Deegan Reviewed-by: Paul Durrant Reviewed-by: Kevin Tian

[Xen-devel] [PATCH v3 14/24] x86/vmx: Use hvm_{get, set}_segment_register() rather than vmx_{get, set}_segment_register()

No functional change at this point, but this is a prerequisite for forthcoming functional changes. Make vmx_get_segment_register() private to vmx.c like all the other Vendor get/set functions. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich

[Xen-devel] [PATCH v3 16/24] x86/emul: Avoid raising faults behind the emulators back

Introduce a new x86_emul_pagefault() similar to x86_emul_hw_exception(), and use this instead of hvm_inject_page_fault() from emulation codepaths. Signed-off-by: Andrew Cooper Reviewed-by: Paul Durrant Reviewed-by: Jan Beulich

[Xen-devel] [PATCH v3 10/24] x86/emul: Always use fault semantics for software events

The common case is already using fault semantics out of x86_emulate(), as that is how VT-x/SVM expects to inject the event (given suitable hardware support). However, x86_emulate() returning X86EMUL_EXCEPTION and also completing a register writeback is problematic for callers. Switch the logic

[Xen-devel] [PATCH v3 21/24] x86/hvm: Rename hvm_copy_*_guest_virt() to hvm_copy_*_guest_linear()

The functions use linear addresses, not virtual addresses, as no segmentation is used. (Lots of other code in Xen makes this mistake.) Signed-off-by: Andrew Cooper Acked-by: Tim Deegan Reviewed-by: Kevin Tian Reviewed-by: Jan

[Xen-devel] [PATCH v3 15/24] x86/hvm: Reposition the modification of raw segment data from the VMCB/VMCS

Intel VT-x and AMD SVM provide access to the full segment descriptor cache via fields in the VMCB/VMCS. However, the bits which are actually checked by hardware and preserved across vmentry/exit are inconsistent, and the vendor accessor functions perform inconsistent modification to the raw

[Xen-devel] [PATCH v3 20/24] x86/hvm: Reimplement hvm_copy_*_nofault() in terms of no pagefault_info

No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Tim Deegan Reviewed-by: Paul Durrant --- xen/arch/x86/hvm/emulate.c| 6 ++--- xen/arch/x86/hvm/hvm.c

[Xen-devel] [PATCH v3 22/24] x86/hvm: Avoid __hvm_copy() raising #PF behind the emulators back

Drop the call to hvm_inject_page_fault() in __hvm_copy(), and require callers to inject the pagefault themselves. Signed-off-by: Andrew Cooper Acked-by: Tim Deegan Acked-by: Kevin Tian Reviewed-by: Jan Beulich

[Xen-devel] [PATCH v3 13/24] x86/emul: Rework emulator event injection

The emulator needs to gain an understanding of interrupts and exceptions generated by its actions. Move hvm_emulate_ctxt.{exn_pending,trap} into struct x86_emulate_ctxt so they are visible to the emulator. This removes the need for the inject_{hw_exception,sw_interrupt}() hooks, which are

[Xen-devel] [PATCH v3 18/24] x86/shadow: Avoid raising faults behind the emulators back

Use x86_emul_{hw_exception,pagefault}() rather than {pv,hvm}_inject_page_fault() and hvm_inject_hw_exception() to cause raised faults to be known to the emulator. This requires altering the callers of x86_emulate() to properly re-inject the event. While fixing this, fix the singlestep behaviour.

[Xen-devel] [PATCH v3 11/24] x86/emul: Implement singlestep as a retire flag

The behaviour of singlestep is to raise #DB after the instruction has been completed, but implementing it with inject_hw_exception() causes x86_emulate() to return X86EMUL_EXCEPTION, despite succesfully completing execution of the instruction, including register writeback. Instead, use a retire

[Xen-devel] [PATCH v3 24/24] x86/emul: Use system-segment relative memory accesses

With hvm_virtual_to_linear_addr() capable of doing proper system-segment relative memory accesses, avoid open-coding the address and limit calculations locally. When a table spans the 4GB boundary (32bit) or non-canonical boundary (64bit), segmentation errors are now raised. Previously, the use

[Xen-devel] [PATCH v3 12/24] x86/emul: Remove opencoded exception generation

Introduce generate_exception() for unconditional exception generation, and replace existing uses. Both generate_exception() and generate_exception_if() are updated to make their error code parameters optional, which removes the use of the -1 sentinal. The ioport_access_check() check loses the

[Xen-devel] [PATCH v3 23/24] x86/emul: Prepare to allow use of system segments for memory references

All system segments (GDT/IDT/LDT and TR) describe a linear address and limit, and act similarly to user segments. However all current uses of these tables in the emulator opencode the address calculations and limit checks. In particular, no care is taken for access which wrap around the 4GB or

[Xen-devel] [PATCH v3 17/24] x86/pv: Avoid raising faults behind the emulators back

Use x86_emul_pagefault() rather than pv_inject_page_fault() to cause raised pagefaults to be known to the emulator. This requires altering the callers of x86_emulate() to properly re-inject the event. Signed-off-by: Andrew Cooper --- CC: Jan Beulich

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

>>> On 30.11.16 at 13:40, wrote: > 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

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

On 30/11/16 14:51, Juergen Gross wrote: > On 30/11/16 14:04, Daniel Kiper wrote: >> 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

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

>>> On 30.11.16 at 14:45, wrote: > 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,

[Xen-devel] [PATCH] xen/arm: Fix misplaced parentheses for PSCI version check

Fix misplaced parentheses for PSCI version check Signed-off-by: Artem Mygaiev --- xen/arch/arm/psci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c index 7966b5e..34ee97e 100644 --- a/xen/arch/arm/psci.c +++

[Xen-devel] [PATCH v3 02/24] x86/emul: Drop X86EMUL_CMPXCHG_FAILED

X86EMUL_CMPXCHG_FAILED was introduced in c/s d430aae25 in 2005. Even at the time it alised what is now X86EMUL_RETRY (as well as what is now X86EMUL_EXCEPTION). I am not sure why the distinction was considered useful at the time. It is only used twice; there is no need to call it out

[Xen-devel] [PATCH for-4.9 v3 00/24] XSA-191 followup

This is the quantity of changes required to fix some edgecases in XSA-191 which were ultimately chosen not to go out in the security fix. The main purpose of this series is to fix emulation sufficiently to allow the final patch to avoid opencoding all of the segmenation logic. Changes from v2:

[Xen-devel] [PATCH v3 09/24] x86/emul: Provide a wrapper to x86_emulate() to ASSERT() certain behaviour

In debug builds, confirm that some properties of x86_emulate()'s behaviour actually hold. The first property, fixed in a previous change, is that retire flags are only ever set in the X86EMUL_OKAY case. While adjusting the userspace test harness to cope with ASSERT() in x86_emulate.h, fix a

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

To help with event injection improvements for the PV uses of x86_emulate(), implement a event injection API which matches its hvm counterpart. This is started with taking do_guest_trap() and modifying its calling API to pv_inject_event(), subsequentally implementing the former in terms of the

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

On 30/11/16 14:04, Daniel Kiper wrote: > 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.

[Xen-devel] [PATCH v3 07/24] x86/emul: Clean up the naming of the retire union

Rename byte to raw, as the field being a single byte long is an implementation detail. Make the bitfields part of an anonymous struct to remove the .flags qualifier. Change the types of the flags to being booleans, to match their use. No functional change. Signed-off-by: Andrew Cooper

[Xen-devel] [PATCH v3 05/24] x86/emul: Rename HVM_DELIVER_NO_ERROR_CODE to X86_EVENT_NO_EC

and move it to live with the other x86_event infrastructure in x86_emulate.h. Switch it and x86_event.error_code to being signed, matching the rest of the code. Signed-off-by: Andrew Cooper Reviewed-by: Paul Durrant Reviewed-by: Boris

[Xen-devel] [PATCH v3 04/24] x86/emul: Rename hvm_trap to x86_event and move it into the emulation infrastructure

The x86 emulator needs to gain an understanding of interrupts and exceptions generated by its actions. The naming choice is to match both the Intel and AMD terms, and to avoid 'trap' specifically as it has an architectural meaning different to its current usage. While making this change, make

[Xen-devel] [PATCH v3 08/24] x86/emul: Correct the behaviour of pop %ss and interrupt shadowing

The mov_ss retire flag should only be set once load_seg() has returned success. In particular, it should not be set if an exception occured when trying to load %ss. _hvm_emulate_one(), currently the sole user of mov_ss, only consideres it in the case that x86_emulate() returns X86EMUL_OKAY, so

  1   2   >