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

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

[Xen-devel] [xen-4.10-testing test] 128108: tolerable FAIL - PUSHED

flight 128108 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/128108/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass

[Xen-devel] [xen-4.9-testing test] 128105: regressions - FAIL

flight 128105 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/128105/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 6 kernel-build fail in 128054 REGR. vs. 127753 Tests which

Re: [Xen-devel] IOREQ server on Arm

>>> On 26.09.18 at 23:32, wrote: > This brings me to the next question. Do you expect set_special_p2m_entry > to take a reference on the page? > > If not, we may run into some troubles because AFAICT you can map twice > the ioreq page in a guest but reference will only be taken on the >

Re: [Xen-devel] [PATCH 00/12] add per-domain and per-cpupool generic parameters

On 26/09/18 17:10, Dario Faggioli wrote: > [Hey, is it me/my mailer, or threading is weird for this series? :-O] > > On Tue, 2018-09-18 at 14:57 +0100, George Dunlap wrote: >> On 09/18/2018 02:36 PM, Juergen Gross wrote: >>> >>> The string variant is much more flexible. >>> >>> It is easy

Re: [Xen-devel] [PATCH] x86: use alternatives for FS/GS base accesses

>>> On 26.09.18 at 20:13, wrote: > On 26/09/18 07:43, Jan Beulich wrote: >> Eliminating conditional branches is always a Good Thing (tm), it seems to > me. > > By this reasoning, we should compile Xen with movfuscator, which really > will get rid of every branch. > > Doing so would be utter

Re: [Xen-devel] [PATCH v3 2/5] x86: use PDEP/PEXT for maddr/direct-map-offset conversion when available

>>> On 25.09.18 at 19:15, wrote: > I seem to recall you saying that the one system it was introduced for > never shipped, at which point, why bother keeping the code around? Well, I've said _I think_ they've never shipped. Irrespective of this, another thought here to come to a middle ground:

[Xen-devel] [PATCH v3] memory_hotplug: Free pages as higher order

When free pages are done with higher order, time spend on coalescing pages by buddy allocator can be reduced. With section size of 256MB, hot add latency of a single section shows improvement from 50-60 ms to less than 1 ms, hence improving the hot add latency by 60%. Modify external providers of

Re: [Xen-devel] [RFC PATCH 1/2] mem_access: Fix npfec.kind propagation

>>> On 26.09.18 at 19:00, wrote: > On 26/09/18 17:47, George Dunlap wrote: >> --- a/xen/arch/x86/mm/mem_access.c >> +++ b/xen/arch/x86/mm/mem_access.c >> @@ -232,12 +232,12 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long >> gla, >> { >> req->u.mem_access.flags |=

[Xen-devel] Xen PPC64

Hello, I would like to fund a port of Xen to the PPC64 architecture, more specially POWER9, in little endian and big endian mode. Anyone with the required competence can provide me with an idea of the delay and funds required for this? I am pushing this forward to enable Qubes OS

Re: [Xen-devel] [PATCH v3] memory_hotplug: Free pages as higher order

On Thu, Sep 27, 2018 at 12:28:50PM +0530, Arun KS wrote: > + __free_pages_boot_core(page, order); I am not sure, but if we are going to use that function from the memory-hotplug code, we might want to rename that function to something more generic? The word "boot" suggests that this is only

Re: [Xen-devel] [PATCH v3] memory_hotplug: Free pages as higher order

On 27/09/18 08:58, Arun KS wrote: > When free pages are done with higher order, time spend on > coalescing pages by buddy allocator can be reduced. With > section size of 256MB, hot add latency of a single section > shows improvement from 50-60 ms to less than 1 ms, hence > improving the hot add

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

On 22/09/18 21:55, Boris Ostrovsky wrote: > Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants") > added support for purging persistent grants when they are not in use. As > part of the purge, the grants were removed from the grant buffer, This > eventually causes the buffer to

Re: [Xen-devel] [PATCH] x86emul: fix test harness build after e8dfbc2962

On Wed, Sep 26, 2018 at 1:43 AM Wei Liu wrote: > > On Wed, Sep 26, 2018 at 02:03:36AM -0600, Jan Beulich wrote: > > There was another stdio.h inclusion left in place. Re-order #include-s > > altogether in test_x86_emulator.c. > > > > Signed-off-by: Jan Beulich > > Reviewed-by: Wei Liu >

Re: [Xen-devel] [PATCH v3] memory_hotplug: Free pages as higher order

On 2018-09-27 12:39, Oscar Salvador wrote: On Thu, Sep 27, 2018 at 12:28:50PM +0530, Arun KS wrote: + __free_pages_boot_core(page, order); Hi, I am not sure, but if we are going to use that function from the memory-hotplug code, we might want to rename that function to something more

Re: [Xen-devel] [PATCH 1/1] x86/boot: Allocate one extra module slot for Xen image placement

On Thu, Sep 27, 2018 at 11:06:24AM +0100, Andrew Cooper wrote: > On 27/09/18 11:05, Daniel Kiper wrote: > > Commit 9589927 (x86/mb2: avoid Xen image when looking for > > module/crashkernel position) fixed relocation issues for > > Multiboot2 protocol. Unfortunately it missed to allocate > > module

[Xen-devel] [PATCH v3 0/6] mm: online/offline_pages called w.o. mem_hotplug_lock

@Andrew, Only patch #5 changed (see change notes below). Thanks! Reading through the code and studying how mem_hotplug_lock is to be used, I noticed that there are two places where we can end up calling device_online()/device_offline() - online_pages()/offline_pages() without the

[Xen-devel] [PATCH v3 5/6] powerpc/powernv: hold device_hotplug_lock when calling memtrace_offline_pages()

Let's perform all checking + offlining + removing under device_hotplug_lock, so nobody can mess with these devices via sysfs concurrently. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Rashmica Gupta Cc: Balbir Singh Cc: Michael Neuling Reviewed-by: Pavel Tatashin

[Xen-devel] [PATCH v3 4/6] powerpc/powernv: hold device_hotplug_lock when calling device_online()

device_online() should be called with device_hotplug_lock() held. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Rashmica Gupta Cc: Balbir Singh Cc: Michael Neuling Reviewed-by: Pavel Tatashin Reviewed-by: Rashmica Gupta Signed-off-by: David Hildenbrand ---

[Xen-devel] [PATCH v3 3/6] mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock

There seem to be some problems as result of 30467e0b3be ("mm, hotplug: fix concurrent memory hot-add deadlock"), which tried to fix a possible lock inversion reported and discussed in [1] due to the two locks a) device_lock() b) mem_hotplug_lock While add_memory() first takes b),

[Xen-devel] [PATCH v3 2/6] mm/memory_hotplug: make add_memory() take the device_hotplug_lock

add_memory() currently does not take the device_hotplug_lock, however is aleady called under the lock from arch/powerpc/platforms/pseries/hotplug-memory.c drivers/acpi/acpi_memhotplug.c to synchronize against CPU hot-remove and similar. In general, we should hold the

[Xen-devel] [PATCH v3 1/6] mm/memory_hotplug: make remove_memory() take the device_hotplug_lock

remove_memory() is exported right now but requires the device_hotplug_lock, which is not exported. So let's provide a variant that takes the lock and only export that one. The lock is already held in arch/powerpc/platforms/pseries/hotplug-memory.c drivers/acpi/acpi_memhotplug.c

Re: [Xen-devel] null scheduler bug

On Tue, 2018-09-25 at 19:49 +0200, Dario Faggioli wrote: > [Adding a few people to the Cc-list. See below...] > On Tue, 2018-09-25 at 12:15 +0100, Julien Grall wrote: > > On 09/25/2018 10:02 AM, Dario Faggioli wrote: > > > On Mon, 2018-09-24 at 22:46 +0100, Julien Grall wrote: > > > > > My

Re: [Xen-devel] [PATCH] tools/ocaml: Add OCaml binding of virq bind

> On 27 Sep 2018, at 09:59, Andrew Cooper wrote: > > On 27/09/18 08:53, Yang Qian wrote: >> 1. Add a common bind virq function >> 2. Reduce the stub code of `bind_dom_exc_virq` >> >> Signed-off-by: Yang Qian > > CC'ing the relevant maintainers. > > Reviewed-by: Andrew Cooper (forwarding

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

Hi, On 09/27/2018 11:20 AM, Oleksandr Andrushchenko wrote: On 09/27/2018 01:16 PM, Juergen Gross wrote: On 27/09/2018 12:07, Oleksandr Andrushchenko wrote: Hi, On 09/27/2018 12:39 PM, Lars Kurth wrote: Adding a few people who have recently been working on PV drivers, as well as Julien Lars

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

Hi, Sorry, I forgot, I used code from github chapter [2] from that link, and I just changed name "mydevice" to "vdevb" > Error 13 is EACCESS. I guess the access rights of the Xenstore nodes > are not sufficient to write the needed entries. Where I have to provide access rights, i.e from Kernel

Re: [Xen-devel] [PATCH v3] memory_hotplug: Free pages as higher order

On 2018-09-27 12:41, Juergen Gross wrote: On 27/09/18 08:58, Arun KS wrote: When free pages are done with higher order, time spend on coalescing pages by buddy allocator can be reduced. With section size of 256MB, hot add latency of a single section shows improvement from 50-60 ms to less than

Re: [Xen-devel] [PATCH] tools/ocaml: Add OCaml binding of virq bind

On 27/09/18 08:53, Yang Qian wrote: > 1. Add a common bind virq function > 2. Reduce the stub code of `bind_dom_exc_virq` > > Signed-off-by: Yang Qian CC'ing the relevant maintainers. Reviewed-by: Andrew Cooper (forwarding my internal review of this patch)

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

On 27/09/2018 12:07, Oleksandr Andrushchenko wrote: > Hi, > On 09/27/2018 12:39 PM, Lars Kurth wrote: >> Adding a few people who have recently been working on PV drivers, as >> well as Julien >> Lars >> >>> On 27 Sep 2018, at 06:44, Omkar Bolla >>> >> >

Re: [Xen-devel] IOREQ server on Arm

> -Original Message- > From: Julien Grall [mailto:julien.gr...@arm.com] > Sent: 27 September 2018 10:42 > To: Paul Durrant ; 'Jan Beulich' > > Cc: Andrew Cooper ; Roger Pau Monne > ; Stefano Stabellini ; xen- > devel > Subject: Re: IOREQ server on Arm > > Hi Paul, > > On 09/27/2018

Re: [Xen-devel] [RFC PATCH 2/2] x86/mm: Add mem access rights to NPT

> -Original Message- > From: George Dunlap [mailto:george.dun...@citrix.com] > Sent: 27 September 2018 11:38 > To: Andrew Cooper ; xen- > de...@lists.xenproject.org > Cc: Isaila Alexandru ; Jan Beulich > ; Tim (Xen.org) ; Tamas K Lengyel > ; Paul Durrant ; > Razvan Cojocaru ; Suravee

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

flight 128094 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/128094/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128049

Re: [Xen-devel] [OSSTEST PATCH v3] ts-xen-build-prep: install libgnutls28-dev for libvirt build

Wei Liu writes ("[OSSTEST PATCH v3] ts-xen-build-prep: install libgnutls28-dev for libvirt build"): > d54ecf31b2 placed the build dependency in a wrong file. This patch > adds the dependency to the right file. Add a runtime dependency in > libvirt.pm. Thanks, acked again and pushed. Let's see

Re: [Xen-devel] IOREQ server on Arm

Hi Paul, On 09/27/2018 11:16 AM, Paul Durrant wrote: -Original Message- From: Julien Grall [mailto:julien.gr...@arm.com] Sent: 27 September 2018 10:42 To: Paul Durrant ; 'Jan Beulich' Cc: Andrew Cooper ; Roger Pau Monne ; Stefano Stabellini ; xen- devel Subject: Re: IOREQ server on

[Xen-devel] [PATCH] tools/ocaml: Add OCaml binding of virq bind

1. Add a common bind virq function 2. Reduce the stub code of `bind_dom_exc_virq` Signed-off-by: Yang Qian --- tools/ocaml/libs/eventchn/xeneventchn.ml | 19 ++- tools/ocaml/libs/eventchn/xeneventchn.mli | 21 +

Re: [Xen-devel] [PATCH] tools/ocaml: Add OCaml binding of virq bind

> On 27 Sep 2018, at 11:15, Andrew Cooper wrote: > > On 27/09/18 11:11, Christian Lindig wrote: >> >>> On 27 Sep 2018, at 09:59, Andrew Cooper wrote: >>> >>> On 27/09/18 08:53, Yang Qian wrote: 1. Add a common bind virq function 2. Reduce the stub code of `bind_dom_exc_virq`

Re: [Xen-devel] [PATCH] tools/ocaml: Add OCaml binding of virq bind

On 27/09/18 11:11, Christian Lindig wrote: > >> On 27 Sep 2018, at 09:59, Andrew Cooper wrote: >> >> On 27/09/18 08:53, Yang Qian wrote: >>> 1. Add a common bind virq function >>> 2. Reduce the stub code of `bind_dom_exc_virq` >>> >>> Signed-off-by: Yang Qian >> CC'ing the relevant maintainers.

Re: [Xen-devel] [PATCH 1/1] x86/boot: Allocate one extra module slot for Xen image placement

On Thu, Sep 27, 2018 at 11:19:24AM +0100, Andrew Cooper wrote: > On 27/09/18 11:10, Daniel Kiper wrote: > > On Thu, Sep 27, 2018 at 11:06:24AM +0100, Andrew Cooper wrote: > >> On 27/09/18 11:05, Daniel Kiper wrote: > >>> Commit 9589927 (x86/mb2: avoid Xen image when looking for > >>>

Re: [Xen-devel] IOREQ server on Arm

> -Original Message- > From: Julien Grall [mailto:julien.gr...@arm.com] > Sent: 27 September 2018 11:31 > To: Paul Durrant ; 'Jan Beulich' > > Cc: Andrew Cooper ; Roger Pau Monne > ; Stefano Stabellini ; xen- > devel > Subject: Re: IOREQ server on Arm > > Hi Paul, > > On 09/27/2018

[Xen-devel] [PATCH v3 6/6] memory-hotplug.txt: Add some details about locking internals

Let's document the magic a bit, especially why device_hotplug_lock is required when adding/removing memory and how it all play together with requests to online/offline memory from user space. Cc: Jonathan Corbet Cc: Michal Hocko Cc: Andrew Morton Reviewed-by: Pavel Tatashin Reviewed-by:

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

Adding a few people who have recently been working on PV drivers, as well as Julien Lars > On 27 Sep 2018, at 06:44, Omkar Bolla wrote: > > Hi, > > I am using Debian as Domain-0 and Debian as Domain-U on Hikey960 > platform(ARMv8) and using Xen-4.8 stable release. Here I want to create a PV

Re: [Xen-devel] [RFC PATCH 2/2] x86/mm: Add mem access rights to NPT

On Wed, 2018-09-26 at 17:47 +0100, George Dunlap wrote: > From: Isaila Alexandru > > This patch adds access control for NPT mode. > > There aren’t enough extra bits to store the access rights in the NPT > p2m > table, so we add a radix tree to store extra information. > > For efficiency: > -

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

Hi, On 09/27/2018 12:39 PM, Lars Kurth wrote: Adding a few people who have recently been working on PV drivers, as well as Julien Lars On 27 Sep 2018, at 06:44, Omkar Bolla > wrote: Hi, I am using Debian as Domain-0 and Debian as Domain-U on Hikey960

Re: [Xen-devel] [PATCH 1/1] x86/boot: Allocate one extra module slot for Xen image placement

On 27/09/18 11:05, Daniel Kiper wrote: > Commit 9589927 (x86/mb2: avoid Xen image when looking for > module/crashkernel position) fixed relocation issues for > Multiboot2 protocol. Unfortunately it missed to allocate > module slot for Xen image placement in early boot path. > So, let's fix it

Re: [Xen-devel] [RFC PATCH 2/2] x86/mm: Add mem access rights to NPT

On 09/26/2018 06:22 PM, Andrew Cooper wrote: > On 26/09/18 17:47, George Dunlap wrote: >> From: Isaila Alexandru >> >> This patch adds access control for NPT mode. >> >> There aren’t enough extra bits to store the access rights in the NPT p2m >> table, so we add a radix tree to store extra

Re: [Xen-devel] IOREQ server on Arm

Hi Paul, Thank you for your help understanding the resource code. On 09/27/2018 11:46 AM, Paul Durrant wrote: If the DM domain is not PV then currently it must be the hardware domain to be able to map resources. Hence we trust it not to descrease_reservation IOREQ pages. Can you point me

[Xen-devel] [PATCH] x86/mwait-idle: Tweak reporting when MONITOR is not available

Currently, booting Xen as a PVH guest yields: (d10) (XEN) mwait-idle: does not run on family 6 model 60 which is inaccurate. The problem is the lack of monitor, rather than the family/model. Combine the two CPUID checks and skip the list search in the case that is is going to fail for

[Xen-devel] [PATCH] mem_access: Fix npfec.kind propagation

The name of the "with_gla" flag is confusing; it has nothing to do with the existence or lack thereof of a faulting GLA, but rather where the fault originated. The npfec.kind value is always valid, and should thus be propagated, regardless of whether gla_valid is set or not. In particular,

Re: [Xen-devel] [PATCH] mem_access: Fix npfec.kind propagation

On 27/09/18 12:25, George Dunlap wrote: > The name of the "with_gla" flag is confusing; it has nothing to do > with the existence or lack thereof of a faulting GLA, but rather where > the fault originated. The npfec.kind value is always valid, and > should thus be propagated, regardless of

Re: [Xen-devel] [PATCH] mem_access: Fix npfec.kind propagation

On Thu, 2018-09-27 at 12:25 +0100, George Dunlap wrote: > The name of the "with_gla" flag is confusing; it has nothing to do > with the existence or lack thereof of a faulting GLA, but rather > where > the fault originated. The npfec.kind value is always valid, and > should thus be propagated,

Re: [Xen-devel] [PATCH] x86/mwait-idle: Tweak reporting when MONITOR is not available

>>> On 27.09.18 at 13:12, wrote: > Currently, booting Xen as a PVH guest yields: > > (d10) (XEN) mwait-idle: does not run on family 6 model 60 > > which is inaccurate. > > The problem is the lack of monitor, rather than the family/model. Combine the > two CPUID checks and skip the list

[Xen-devel] [PATCH] amd-iommu: get rid of pointless IOMMU_PAGING_MODE_LEVEL_X definitions

The levels are absolute numbers such that IOMMU_PAGING_MODE_LEVEL_X evaluates to X (for the valid range of 0 - 7) so simply use numbers in the code. No functional change. NOTE: This patch also adds emacs boilerplate to amd-iommu-defs.h Signed-off-by: Paul Durrant --- Cc: Suravee Suthikulpanit

Re: [Xen-devel] [PATCH v11 9/9] mm / iommu: split need_iommu() into has_iommu_pt() and need_iommu_pt_sync()

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 25 September 2018 11:37 > To: Paul Durrant > Cc: Brian Woods ; Suravee Suthikulpanit > ; Julien Grall ; > Andrew Cooper ; Wei Liu ; > George Dunlap ; Ian Jackson > ; Jun Nakajima ; Kevin > Tian ; Stefano

Re: [Xen-devel] null scheduler bug

Hi, I applied patch and vwfi=native and everything works fine, I can create and destroy guest domain as many times as I want. I have to ask, will this patch have any impact on performance (I will test it later, but I just need your opinions)? And what this patch exactly do? I need to fully

[Xen-devel] [linux-4.9 test] 128095: tolerable FAIL - PUSHED

flight 128095 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/128095/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 127931 test-amd64-i386-xl-qemuu-win7-amd64 17

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

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

Re: [Xen-devel] null scheduler bug

On Thu, 2018-09-27 at 15:15 +0200, Milan Boberic wrote: > Hi, > I applied patch and vwfi=native and everything works fine, I can > create and destroy guest domain as many times as I want. > > I have to ask, will this patch have any impact on performance (I will > test it later, but I just need

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

On 9/27/18 1:12 AM, Juergen Gross wrote: > On 22/09/18 21:55, Boris Ostrovsky wrote: >> Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants") >> added support for purging persistent grants when they are not in use. As >> part of the purge, the grants were removed from the grant

[Xen-devel] [qemu-mainline baseline-only test] 75302: trouble: blocked/broken

This run is configured for baseline tests only. flight 75302 qemu-mainline real [real] http://osstest.xensource.com/osstest/logs/75302/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64

Re: [Xen-devel] null scheduler bug

On Thu, 2018-09-27 at 15:15 +0200, Milan Boberic wrote: > Hi, > I applied patch and vwfi=native and everything works fine, I can > create and destroy guest domain as many times as I want. > Ok, now that we know it works, what do you guys prefer? Stefano? Julien? I know it's not strictly an

[Xen-devel] [PATCH v12 8/9] mm / iommu: include need_iommu() test in iommu_use_hap_pt()

The name 'iommu_use_hap_pt' suggests that that P2M table is in use as the domain's IOMMU pagetable which, prior to this patch, is not strictly true since the macro did not test whether the domain actually has IOMMU mappings. Signed-off-by: Paul Durrant Reviewed-by: Kevin Tian --- Cc: Jun

[Xen-devel] [PATCH v12 0/9] paravirtual IOMMU pre-requisites and clean-up

This series contains pre-requisites and clean-up needed for paravirtual IOMMU support. I have separated these patches to avoid further delaying their application whilst I re-work the implementation of paravirtual IOMMU after review of v6 of the series. Several of them already have all necessary

[Xen-devel] [PATCH v12 7/9] vtd: add lookup_page method to iommu_ops

This patch adds a new method to the VT-d IOMMU implementation to find the MFN currently mapped by the specified DFN along with a wrapper function in generic IOMMU code to call the implementation if it exists. NOTE: This patch only adds a Xen-internal interface. This will be used by a

[Xen-devel] [PATCH v12 3/9] iommu: push use of type-safe DFN and MFN into iommu_ops

This patch modifies the methods in struct iommu_ops to use type-safe DFN and MFN. This follows on from the prior patch that modified the functions exported in xen/iommu.h. Signed-off-by: Paul Durrant Reviewed-by: Wei Liu Reviewed-by: Kevin Tian Reviewed-by: Roger Pau Monne Acked-by: Jan

[Xen-devel] [PATCH v12 4/9] iommu: don't domain_crash() inside iommu_map/unmap_page()

This patch removes the implicit domain_crash() from iommu_map(), unmap_page() and iommu_iotlb_flush() and turns them into straightforward wrappers that check the existence of the relevant iommu_op and call through to it. This makes them usable by PV IOMMU code to be delivered in future patches.

[Xen-devel] [PATCH v12 1/9] iommu: introduce the concept of DFN...

...meaning 'device DMA frame number' i.e. a frame number mapped in the IOMMU (rather than the MMU) and hence used for DMA address translation. This patch is a largely cosmetic change that substitutes the terms 'gfn' and 'gaddr' for 'dfn' and 'daddr' in all the places where the frame number or

[Xen-devel] [PATCH v12 9/9] mm / iommu: split need_iommu() into has_iommu_pt() and need_iommu_pt_sync()

The name 'need_iommu()' is a little confusing as it suggests a domain needs to use the IOMMU but something might not be set up yet, when in fact it represents a tri-state value (not a boolean as might be expected) where -1 means 'IOMMU mappings being set up' and 1 means 'IOMMU mappings have been

[Xen-devel] [PATCH v12 5/9] memory: add check_get_page_from_gfn() as a wrapper...

...for some uses of get_page_from_gfn(). There are many occurrences of the following pattern in the code: q = ? P2M_ALLOC : P2M_UNSHARE; page = get_page_from_gfn(d, gfn, , q); if ( p2m_is_paging(p2mt) ) { if ( page ) put_page(page);

[Xen-devel] [PATCH v12 6/9] vtd: add missing check for shared EPT...

...in intel_iommu_unmap_page(). This patch also includes some non-functional modifications in intel_iommu_map_page(). Signed-off-by: Paul Durrant Acked-by: Kevin Tian --- Cc: Wei Liu Cc: Jan Beulich Cc: George Dunlap v8: - New in v8. (Split from the next patch in the series as requested

[Xen-devel] [PATCH v12 2/9] iommu: make use of type-safe DFN and MFN in exported functions

This patch modifies the declaration of the entry points to the IOMMU sub-system to use dfn_t and mfn_t in place of unsigned long. A subsequent patch will similarly modify the methods in the iommu_ops structure. Signed-off-by: Paul Durrant Reviewed-by: Wei Liu Reviewed-by: Kevin Tian

[Xen-devel] Backports to stable trees

Hello, Please can the following patches be considered for stable. 18cd4997d26b - x86/efi: move the logic to detect PE build support 93249f7fc17c - x86/efi: split compiler vs linker support CentOS and RHEL 7.x GCC's are capable of compiling xen.gz with EFI support, but LD doesn't have i386pep

Re: [Xen-devel] null scheduler bug

Hi Dario, On 09/27/2018 03:32 PM, Dario Faggioli wrote: On Thu, 2018-09-27 at 15:15 +0200, Milan Boberic wrote: Hi, I applied patch and vwfi=native and everything works fine, I can create and destroy guest domain as many times as I want. Ok, now that we know it works, what do you guys

[Xen-devel] [PATCH] x86: hap_enabled() is HVM-only

There at least two cases where the field so far got accessed for PV guests as well: One is in iommu_construct(), via iommu_use_hap_pt(), and the other is arch_domain_create() -> paging_domain_init() -> p2m_init() -> p2m_init_hostp2m() -> p2m_init_one() ->

Re: [Xen-devel] [PATCH] x86: hap_enabled() is HVM-only

On 27/09/18 16:30, Jan Beulich wrote: > There at least two cases where the field so far got accessed for PV > guests as well: One is in iommu_construct(), via iommu_use_hap_pt(), > and the other is > arch_domain_create() > -> paging_domain_init() >-> p2m_init() > -> p2m_init_hostp2m() >

Re: [Xen-devel] [PATCH v12 9/9] mm / iommu: split need_iommu() into has_iommu_pt() and need_iommu_pt_sync()

>>> On 27.09.18 at 16:33, wrote: > v12: > - Fix two mis-uses of iommu_hap_pt_share(). I had hoped that with my reply to v11 you would have gone through all uses, not just the ones your series adds or modifies. At the very least the one in iommu_construct() is bogus too, as PV domains also make

Re: [Xen-devel] [PATCH] x86: assert MBI is large enough in pvh-boot.c

On Wed, Sep 26, 2018 at 06:07:30AM -0600, Jan Beulich wrote: > >>> On 26.09.18 at 13:00, wrote: > > --- a/xen/arch/x86/guest/pvh-boot.c > > +++ b/xen/arch/x86/guest/pvh-boot.c > > @@ -44,6 +44,13 @@ static void __init convert_pvh_info(void) > > > > ASSERT(pvh_info->magic ==

Re: [Xen-devel] [PATCH] x86: assert MBI is large enough in pvh-boot.c

On Wed, Sep 26, 2018 at 12:05:05PM +0100, Andrew Cooper wrote: > On 26/09/18 12:00, Wei Liu wrote: > > The relocation code in __start_xen requires one extra element in the > > MBI structure. By the looks of it the temporary MBI array is already > > large enough. Add an assertion to catch any issue

[Xen-devel] [linux-4.14 test] 128097: regressions - FAIL

flight 128097 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/128097/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 127877 Tests which

Re: [Xen-devel] null scheduler bug

On Thu, 2018-09-27 at 16:09 +0100, Julien Grall wrote: > Hi Dario, > Hi, > On 09/27/2018 03:32 PM, Dario Faggioli wrote: > > On Thu, 2018-09-27 at 15:15 +0200, Milan Boberic wrote: > > > > In one of your e-mail, you wrote: > > "Well, our implementation of RCU requires that, from time to time,

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

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

Re: [Xen-devel] Backports to stable trees

On 27/09/18 15:36, Andrew Cooper wrote: > Hello, > > Please can the following patches be considered for stable. > > 18cd4997d26b - x86/efi: move the logic to detect PE build support > 93249f7fc17c - x86/efi: split compiler vs linker support > > CentOS and RHEL 7.x GCC's are capable of compiling

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

On 27/09/18 16:26, Jens Axboe wrote: > On 9/27/18 1:12 AM, Juergen Gross wrote: >> On 22/09/18 21:55, Boris Ostrovsky wrote: >>> Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants") >>> added support for purging persistent grants when they are not in use. As >>> part of the purge,

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

On 9/27/18 12:52 PM, Sander Eikelenboom wrote: > On 27/09/18 16:26, Jens Axboe wrote: >> On 9/27/18 1:12 AM, Juergen Gross wrote: >>> On 22/09/18 21:55, Boris Ostrovsky wrote: Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants") added support for purging persistent

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

On 9/27/18 2:56 PM, Jens Axboe wrote: > On 9/27/18 12:52 PM, Sander Eikelenboom wrote: >> On 27/09/18 16:26, Jens Axboe wrote: >>> On 9/27/18 1:12 AM, Juergen Gross wrote: On 22/09/18 21:55, Boris Ostrovsky wrote: > Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

On 9/27/18 1:06 PM, Boris Ostrovsky wrote: > On 9/27/18 2:56 PM, Jens Axboe wrote: >> On 9/27/18 12:52 PM, Sander Eikelenboom wrote: >>> On 27/09/18 16:26, Jens Axboe wrote: On 9/27/18 1:12 AM, Juergen Gross wrote: > On 22/09/18 21:55, Boris Ostrovsky wrote: >> Commit a46b53672b2c

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

On 27/09/18 21:06, Boris Ostrovsky wrote: > On 9/27/18 2:56 PM, Jens Axboe wrote: >> On 9/27/18 12:52 PM, Sander Eikelenboom wrote: >>> On 27/09/18 16:26, Jens Axboe wrote: On 9/27/18 1:12 AM, Juergen Gross wrote: > On 22/09/18 21:55, Boris Ostrovsky wrote: >> Commit a46b53672b2c

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

On 9/27/18 2:33 PM, Sander Eikelenboom wrote: > On 27/09/18 21:06, Boris Ostrovsky wrote: >> On 9/27/18 2:56 PM, Jens Axboe wrote: >>> On 9/27/18 12:52 PM, Sander Eikelenboom wrote: On 27/09/18 16:26, Jens Axboe wrote: > On 9/27/18 1:12 AM, Juergen Gross wrote: >> On 22/09/18 21:55,

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

On 9/27/18 5:37 PM, Jens Axboe wrote: > On 9/27/18 2:33 PM, Sander Eikelenboom wrote: >> On 27/09/18 21:06, Boris Ostrovsky wrote: >>> On 9/27/18 2:56 PM, Jens Axboe wrote: On 9/27/18 12:52 PM, Sander Eikelenboom wrote: > On 27/09/18 16:26, Jens Axboe wrote: >> On 9/27/18 1:12 AM,

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

On 27/09/18 23:48, Boris Ostrovsky wrote: > On 9/27/18 5:37 PM, Jens Axboe wrote: >> On 9/27/18 2:33 PM, Sander Eikelenboom wrote: >>> On 27/09/18 21:06, Boris Ostrovsky wrote: On 9/27/18 2:56 PM, Jens Axboe wrote: > On 9/27/18 12:52 PM, Sander Eikelenboom wrote: >> On 27/09/18 16:26,

Re: [Xen-devel] [PATCH v2 4/6] xen/arm: cpufeature: Add helper to check constant caps

On Wed, 26 Sep 2018, Julien Grall wrote: > Hi Stefano, > > On 09/26/2018 05:53 PM, Stefano Stabellini wrote: > > On Tue, 25 Sep 2018, Julien Grall wrote: > > > Some capababilities are set right during boot and will never change > > > afterwards. At the moment, the function cpu_have_caps will

Re: [Xen-devel] [PATCH v2 6/6] xen/arm: Replace call_smc with arm_smccc_smc

On Wed, 26 Sep 2018, Julien Grall wrote: > Hi Stefano, > > On 09/26/2018 12:57 AM, Stefano Stabellini wrote: > > On Tue, 25 Sep 2018, Julien Grall wrote: > > > diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c > > > index 941eec921b..02737e6caa 100644 > > > --- a/xen/arch/arm/psci.c > > >

[Xen-devel] [ovmf baseline-only test] 75305: trouble: blocked/broken

This run is configured for baseline tests only. flight 75305 ovmf real [real] http://osstest.xensource.com/osstest/logs/75305/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm

Re: [Xen-devel] [PATCH v2 3/6] xen/arm: add SMC wrapper that is compatible with SMCCC v1.0

On Wed, 26 Sep 2018, Julien Grall wrote: > Hi Stefano, > > On 09/26/2018 12:50 AM, Stefano Stabellini wrote: > > On Tue, 25 Sep 2018, Julien Grall wrote: > > > From: Volodymyr Babchuk > > > > > > Existing SMC wrapper call_smc() allows only 4 parameters and > > > returns only one value. This is

Re: [Xen-devel] [PATCH 1/3] [not-for-unstable] xen/arm: vgic-v3: Delay the initialization of the domain information

On Wed, 26 Sep 2018, Julien Grall wrote: > Hi Stefano, > > On 09/25/2018 09:45 PM, Stefano Stabellini wrote: > > On Tue, 4 Sep 2018, Andrew Cooper wrote: > > > On 04/09/18 20:35, Julien Grall wrote: > > > > Hi, > > > > > > > > On 09/04/2018 08:21 PM, Julien Grall wrote: > > > > > A follow-up

Re: [Xen-devel] [PATCH 2/3] xen/arm: vgic-v3: Don't create empty re-distributor regions

On Wed, 26 Sep 2018, Julien Grall wrote: > Hi Stefano, > > On 09/25/2018 09:38 PM, Stefano Stabellini wrote: > > On Tue, 4 Sep 2018, Julien Grall wrote: > > > At the moment, Xen is assuming the hardware domain will have the same > > > number of re-distributor regions as the host. However, as the

Re: [Xen-devel] [PATCH v2] arm/traps: coding style fixes

On Tue, 11 Sep 2018, Andrii Anisov wrote: > From: Andrii Anisov > > Signed-off-by: Andrii Anisov Reviewed-by: Stefano Stabellini > --- > xen/arch/arm/traps.c | 21 + > 1 file changed, 13 insertions(+), 8 deletions(-) > > diff --git a/xen/arch/arm/traps.c

[Xen-devel] [linux-next test] 128101: regressions - FAIL

flight 128101 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/128101/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 128022

Re: [Xen-devel] [Xen-users] XSM/Flask iomem

[Moving to xen-devel] Daniel, Any comments on this one? -George On Wed, Sep 26, 2018 at 12:41 PM wrote: > > Hi, > > I just noticed from a bad behaviour of my installation and the > security_iterate_iomem_sids > function that the iomem ranges have to be sorted in the device_contexts file. >

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

On 09/27/2018 01:16 PM, Juergen Gross wrote: On 27/09/2018 12:07, Oleksandr Andrushchenko wrote: Hi, On 09/27/2018 12:39 PM, Lars Kurth wrote: Adding a few people who have recently been working on PV drivers, as well as Julien Lars On 27 Sep 2018, at 06:44, Omkar Bolla

Re: [Xen-devel] [PATCH 1/1] x86/boot: Allocate one extra module slot for Xen image placement

On 27/09/18 11:10, Daniel Kiper wrote: > On Thu, Sep 27, 2018 at 11:06:24AM +0100, Andrew Cooper wrote: >> On 27/09/18 11:05, Daniel Kiper wrote: >>> Commit 9589927 (x86/mb2: avoid Xen image when looking for >>> module/crashkernel position) fixed relocation issues for >>> Multiboot2 protocol.

  1   2   >