[Xen-devel] [linux-4.9 test] 133242: regressions - trouble: blocked/broken/fail/pass

flight 133242 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/133242/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken build-arm64

[Xen-devel] [linux-3.18 test] 133239: regressions - trouble: blocked/broken/fail/pass

flight 133239 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/133239/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvopsbroken build-arm64

[Xen-devel] [linux-4.19 test] 133240: regressions - trouble: blocked/broken/fail/pass

flight 133240 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/133240/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-pvops

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

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

[Xen-devel] [libvirt test] 133238: trouble: blocked/broken/pass

flight 133238 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/133238/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvopsbroken build-arm64-xsm

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

On Fri, 15 Feb 2019, Wei Liu wrote: > On Thu, Feb 14, 2019 at 09:03:24PM +, Lars Kurth wrote: > > > > > > > On 14 Feb 2019, at 18:32, Stefano Stabellini > > > wrote: > > > > > > On Thu, 14 Feb 2019, Jan Beulich wrote: > > > On 13.02.19 at 20:11, wrote: > > >>> On Wed, 13 Feb 2019, Wei

Re: [Xen-devel] MCE/EDAC Status/Updating?

On 15/02/2019 18:20, Elliott Mitchell wrote: > On Fri, Feb 15, 2019 at 03:58:49AM -0700, Jan Beulich wrote: > On 15.02.19 at 05:23, wrote: >>> The MCE/EDAC support code appears to be in rather poor shape. >>> >>> The AMD code mentions Family 10h, which might have been available 10 >>> years ag

[Xen-devel] [PATCH RFC] drm: add func to better detect wether swiotlb is needed

This commit fixes DRM failures on Xen PV systems that were introduced in v4.17 by the following commits: 82626363 drm: add func to get max iomem address v2 fd5fd480 drm/amdgpu: only enable swiotlb alloc when need v2 1bc3d3cc drm/radeon: only enable swiotlb path when need v2 The introduction of ->

Re: [Xen-devel] [Qemu-devel] [PATCH 1/3] dataplane/xen-block: remove dead code

On 2/15/19 5:25 PM, Paul Durrant wrote: > The if() statement is clearly bogus (dead code which should have been > cleaned up when grant mapping was removed). "... was removed in 06454c24ad)." > > Spotted by Coverity: CID 1398635 > > While in the neighbourhood, add a missing 'fall through' annot

Re: [Xen-devel] XEN on R-CAR H3

On 15.02.19 16:17, Amit Tomer wrote: Hi, Hi disk = [ 'phy:/dev/mmcblk1p1,xvda1' ] Thanks , this worked for us and we can now boot Linux guest in domU. Sounds great But now, while booting Android as domU guest , we don't get console login for domU and it stuck here: [ 10.597394]

Re: [Xen-devel] Organising a workshop to solve safety certification related questions (March 25/26, Cambridge, UK, Citrix)

Hi all, apologies this took a while. 5 weeks to go to the event! I created https://wiki.xenproject.org/wiki/Developer_Meeting/March2019_-_Safety_Certification which contains information about the venue, hotel

Re: [Xen-devel] RT Xen on ARM - R-Car series

Sorry for the formatting. On Fri, 15 Feb 2019, 18:30 Andrii Anisov, wrote: > Hello Julien, > > On 15.02.19 18:31, Julien Grall wrote: > > Why? Is it because you want to be cache-aligned? If so, requiring the > > structure to be 64-bytes is not enough. > > I did not mean caches. > What is the r

Re: [Xen-devel] [PATCH V2 0/7] Add FOLL_LONGTERM to GUP fast and use it

> NOTE: This series depends on my clean up patch to remove the write parameter > from gup_fast_permitted()[1] > > HFI1, qib, and mthca, use get_user_pages_fast() due to it performance > advantages. These pages can be held for a significant time. But > get_user_pages_fast() does not protect again

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

On Fri, 15 Feb 2019, George Dunlap wrote: > > On Feb 15, 2019, at 5:36 PM, Stefano Stabellini > > wrote: > > > > On Fri, 15 Feb 2019, George Dunlap wrote: > >>> On Feb 13, 2019, at 7:11 PM, Stefano Stabellini > >>> wrote: > >>> > >>> On Wed, 13 Feb 2019, Wei Liu wrote: > On Tue, Feb 12,

Re: [Xen-devel] MCE/EDAC Status/Updating?

On Fri, Feb 15, 2019 at 03:58:49AM -0700, Jan Beulich wrote: > >>> On 15.02.19 at 05:23, wrote: > > The MCE/EDAC support code appears to be in rather poor shape. > > > > The AMD code mentions Family 10h, which might have been available 10 > > years ago. They've likely been findable used with dif

Re: [Xen-devel] [PATCH v3 7/8] x86/mm: handle foreign mappings in p2m_entry_modify

> On Feb 15, 2019, at 2:18 PM, Roger Pau Monne wrote: > > So that the specific handling can be removed from > atomic_write_ept_entry and be shared with npt and shadow code. > > This commit also removes the check that prevent non-ept PVH dom0 from > mapping foreign pages. > > Signed-off-by: Ro

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

> On Feb 15, 2019, at 5:36 PM, Stefano Stabellini > wrote: > > On Fri, 15 Feb 2019, George Dunlap wrote: >>> On Feb 13, 2019, at 7:11 PM, Stefano Stabellini >>> wrote: >>> >>> On Wed, 13 Feb 2019, Wei Liu wrote: On Tue, Feb 12, 2019 at 09:34:25PM -0500, Daniel P. Smith wrote: > Gre

Re: [Xen-devel] [PATCH v3 6/8] p2m: change write_p2m_entry to return an error code

> On Feb 15, 2019, at 2:18 PM, Roger Pau Monne wrote: > > This is in preparation for also changing p2m_entry_modify to return an > error code. > > No functional change intended. I think you need to explain wheny/why you’re using BUG_ON() rather than ASSERT() or passing the caller up the stack

Re: [Xen-devel] RT Xen on ARM - R-Car series

On 15.02.19 19:13, Julien Grall wrote: Not really... This is an implementation details that does not matter on the OS side. And on hypervisor side? If you want accurate number, then the NOW() macro is not sufficient enough. Read to CNTPCTL_EL0 can occur speculatively and out of order relative

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

On Fri, 15 Feb 2019, George Dunlap wrote: > > On Feb 13, 2019, at 7:11 PM, Stefano Stabellini > > wrote: > > > > On Wed, 13 Feb 2019, Wei Liu wrote: > >> On Tue, Feb 12, 2019 at 09:34:25PM -0500, Daniel P. Smith wrote: > >>> Greetings, > >>> > >>> On the 11/14/18 Xen x86 community call a discus

Re: [Xen-devel] Fwd: xen: credit2: credit2 can’t reach the throughput as expected

[Hey, these email are still in HTML. Please check your mail program] On Fri, 2019-02-15 at 06:15 +, zheng chuan wrote: > Hi, Dario, > Hi, > Here is the xentrace in credit2 with ratelimiting 1 ms and 30ms by > observing 1 seconds both. > Ok, thanks a lot for doing this! I'm doing my own exper

Re: [Xen-devel] RT Xen on ARM - R-Car series

Hello Julien, On 15.02.19 18:31, Julien Grall wrote: Why? Is it because you want to be cache-aligned? If so, requiring the structure to be 64-bytes is not enough. I did not mean caches. You also want the address to be 64-bytes aligned. I would keep it as a hint for static/dynamic allocati

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

On Fri, 15 Feb 2019, Jan Beulich wrote: > >>> On 14.02.19 at 19:32, wrote: > > Do you have any other suggestions about things that could be removed to > > reach down to 100K LOC, in addition to what you have already written > > above (Intel/AMD, shadow)? > > If you mean ones we already have Kconf

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

flight 133264 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/133264/ 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 1

Re: [Xen-devel] RT Xen on ARM - R-Car series

On Fri, Feb 15, 2019 at 12:30 PM Andrii Anisov wrote: > > Hello Julien, Hi, > On 14.02.19 19:29, Julien Grall wrote: > > I am not sure why you are speaking about the current implementation > > when my point was about the new implementation. > > > > I guess your point stick even if we decide to u

[Xen-devel] [linux-4.4 test] 133230: trouble: blocked/broken/fail/pass

flight 133230 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/133230/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-xsm

Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]

Lars Kurth writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]"): > This is fine by me Thanks, pushed now. Ian. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-deve

Re: [Xen-devel] [PATCH] xen/pciback: Don't disable PCI_COMMAND on PCI device reset.

On Wed, Feb 13, 2019 at 06:21:31PM -0500, Prarit Bhargava wrote: > From: Konrad Rzeszutek Wilk > +LKML > This was submitted in 2015 here > > https://marc.info/?l=linux-kernel&m=142807132515973&w=2 > > and has been included in Fedora builds ever since. No issues have been > reported with the p

Re: [Xen-devel] Upstream Dom0 DRM problems regarding swiotlb

On Fri, Feb 15, 2019 at 11:07:22AM -0500, Michael Labriola wrote: > > > But the latter text seems to agree with that. So what is the actual > > > problem that started this discussion? > > > > > > > See https://lists.xen.org/archives/html/xen-devel/2019-02/threads.html#00818 > > I believe the actu

Re: [Xen-devel] RT Xen on ARM - R-Car series

Hi, On Fri, Feb 15, 2019 at 4:23 PM Andrii Anisov wrote: > On 14.02.19 18:29, Roger Pau Monné wrote: > > In order to simplify stuff the new interface could require runstate > > areas to be page aligned, but I think the check can be relaxed to > > simply require runstate areas to not cross a page

Re: [Xen-devel] [PATCH 1/2] xen/gntdev: Do not destroy context while dma-bufs are in use

On 15/02/2019 16:35, Oleksandr Andrushchenko wrote: > On 2/15/19 5:28 PM, Boris Ostrovsky wrote: >> On 2/15/19 10:07 AM, Oleksandr Andrushchenko wrote: >>> On 2/15/19 5:03 PM, Boris Ostrovsky wrote: On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote: >      /* DMA buffer export support. */

Re: [Xen-devel] Upstream Dom0 DRM problems regarding swiotlb

On Fri, Feb 15, 2019 at 11:07:22AM -0500, Michael Labriola wrote: > On Fri, Feb 15, 2019 at 12:57 AM Juergen Gross wrote: > > > > On 14/02/2019 18:57, Christoph Hellwig wrote: > > > On Thu, Feb 14, 2019 at 07:03:38AM +0100, Juergen Gross wrote: > > >>> The thing which is different between Xen PV g

[Xen-devel] [PATCH 2/3] xen-block: remove redundant assignment

The assignment to 'p' is unnecessary as the code will either goto 'invalid' or p will get overwritten. Spotted by Coverity: CID 1398638 Reported-by: Peter Maydell Signed-off-by: Paul Durrant --- Cc: Stefano Stabellini Cc: Anthony Perard Cc: Kevin Wolf Cc: Max Reitz --- hw/block/xen-block.c

[Xen-devel] [PATCH 0/3] Coverity fixes

Paul Durrant (3): dataplane/xen-block: remove dead code xen-block: remove redundant assignment xen-block: report error condition from vbd_name_to_disk() hw/block/dataplane/xen-block.c | 5 + hw/block/xen-block.c | 24 2 files changed, 17 insertions(+)

[Xen-devel] [PATCH 1/3] dataplane/xen-block: remove dead code

The if() statement is clearly bogus (dead code which should have been cleaned up when grant mapping was removed). Spotted by Coverity: CID 1398635 While in the neighbourhood, add a missing 'fall through' annotation. Reported-by: Peter Maydell Signed-off-by: Paul Durrant --- Cc: Stefan Hajnoczi

[Xen-devel] [PATCH 3/3] xen-block: report error condition from vbd_name_to_disk()

The function needs to make sure it is passed a valid disk name. This is easily done by making sure that the parsing loop results in a non-zero value. Spotted by Coverity: CID 1398640 Reported-by: Peter Maydell Signed-off-by: Paul Durrant --- Cc: Stefano Stabellini Cc: Anthony Perard Cc: Kevin

Re: [Xen-devel] Upstream Dom0 DRM problems regarding swiotlb

On Fri, Feb 15, 2019 at 12:57 AM Juergen Gross wrote: > > On 14/02/2019 18:57, Christoph Hellwig wrote: > > On Thu, Feb 14, 2019 at 07:03:38AM +0100, Juergen Gross wrote: > >>> The thing which is different between Xen PV guests and most others (all > >>> others(?), now that Lguest and UML have bee

Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]

On 15/02/2019, 15:40, "Ian Jackson" wrote: Lars Kurth writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]"): > as mentioned earlier, I think we need a legal/admin item for hardware and donations. See proposed addition below. ... > LEGAL > =

[Xen-devel] [qemu-mainline test] 133228: regressions - trouble: blocked/broken/fail/pass

flight 133228 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/133228/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvopsbroken build-arm64-xsm

Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]

Lars Kurth writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]"): > as mentioned earlier, I think we need a legal/admin item for hardware and > donations. See proposed addition below. ... > LEGAL > = I would prefer not to bake the Linux Foundation address into this

[Xen-devel] [PATCH for-4.12 V5 1/2] altp2m: Prevent deadlocks when a domain performs altp2m operations on itself

domain_pause_except_self() was introduced to allow a domain to pause itself while doing altp2m operations. However, as written, it has a risk fo deadlock if two vcpus enter the loop at the same time. Luckily, there's already a solution for this: Attempt to call domain's hypercall_deadlock_mutex,

[Xen-devel] [PATCH for-4.12 V5 2/2] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

HVMOP_altp2m_set_domain_state does not domain_pause(), presumably on purpose (as it was originally supposed to cater to a in-guest agent, and a domain pausing itself is not a good idea). This can lead to domain crashes in the vmx_vmexit_handler() code that checks if the guest has the ability to sw

Re: [Xen-devel] [PATCH 1/2] xen/gntdev: Do not destroy context while dma-bufs are in use

On 2/15/19 5:28 PM, Boris Ostrovsky wrote: On 2/15/19 10:07 AM, Oleksandr Andrushchenko wrote: On 2/15/19 5:03 PM, Boris Ostrovsky wrote: On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote:     /* DMA buffer export support. */ @@ -311,6 +317,7 @@ static void dmabuf_exp_release(struct kref *kre

Re: [Xen-devel] [PATCH 1/2] xen/gntdev: Do not destroy context while dma-bufs are in use

On 2/15/19 10:07 AM, Oleksandr Andrushchenko wrote: > On 2/15/19 5:03 PM, Boris Ostrovsky wrote: >> On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote: >>>     /* DMA buffer export support. */ >>> @@ -311,6 +317,7 @@ static void dmabuf_exp_release(struct kref *kref) >>>     dmabuf_exp_wait_obj_s

Re: [Xen-devel] [PATCH for-4.12 v3 3/8] amd/npt/shadow: replace assert that prevents creating 2M/1G MMIO entries

On 15/02/2019 15:18, Roger Pau Monne wrote: > The assert was originally added to make sure that higher order > regions (> PAGE_ORDER_4K) could not be used to bypass the > mmio_ro_ranges check performed by p2m_type_to_flags. > > This however is already checked in set_mmio_p2m_entry, which makes > s

Re: [Xen-devel] [PATCH for-4.12 v3 3/8] amd/npt/shadow: replace assert that prevents creating 2M/1G MMIO entries

> On Feb 15, 2019, at 2:18 PM, Roger Pau Monne wrote: > > The assert was originally added to make sure that higher order > regions (> PAGE_ORDER_4K) could not be used to bypass the > mmio_ro_ranges check performed by p2m_type_to_flags. > > This however is already checked in set_mmio_p2m_entry,

Re: [Xen-devel] [PATCH 1/2] xen/gntdev: Do not destroy context while dma-bufs are in use

On 2/15/19 5:03 PM, Boris Ostrovsky wrote: On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote: /* DMA buffer export support. */ @@ -311,6 +317,7 @@ static void dmabuf_exp_release(struct kref *kref) dmabuf_exp_wait_obj_signal(gntdev_dmabuf->priv, gntdev_dmabuf); list_del(&gntde

Re: [Xen-devel] RT Xen on ARM - R-Car series

Hello Roger, On 14.02.19 18:29, Roger Pau Monné wrote: I meant that with the current interface a user could change the backing memory behind the virtual address passed in the runstate register hypercall and expect Xen to write to the new physical memory area without having to do anything else.

Re: [Xen-devel] [PATCH 2/2] xen/gntdev: Check and release imported dma-bufs on close

On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Check if there are any imported dma-bufs left not released by > user-space when grant device's release callback is called and > free those if this is the case. This can happen if user-space > leaks the buffers b

Re: [Xen-devel] [PATCH 1/2] xen/gntdev: Do not destroy context while dma-bufs are in use

On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote: > > /* DMA buffer export support. */ > @@ -311,6 +317,7 @@ static void dmabuf_exp_release(struct kref *kref) > > dmabuf_exp_wait_obj_signal(gntdev_dmabuf->priv, gntdev_dmabuf); > list_del(&gntdev_dmabuf->next); > + fput(gntdev_

[Xen-devel] [PATCH for-4.12 v3 1/8] dom0/pvh: align allocation and mapping order to start address

The p2m and iommu mapping code always had the requirement that addresses and orders must be aligned when populating the p2m or the iommu page tables. PVH dom0 builder didn't take this requirement into account, and can call into the p2m/iommu mapping helpers with addresses and orders that are not a

[Xen-devel] [PATCH for-4.12 v3 2/8] x86/pvh: reorder PVH dom0 iommu initialization

So that the iommu is initialized before populating the p2m, and entries added get the corresponding iommu page table entries if required. This requires splitting the current pvh_setup_p2m into two different functions. One that crafts dom0 physmap and sets the paging allocation, and another one that

Re: [Xen-devel] [PATCH for-4.12 v3 3/8] amd/npt/shadow: replace assert that prevents creating 2M/1G MMIO entries

>>> On 15.02.19 at 15:18, wrote: > The assert was originally added to make sure that higher order > regions (> PAGE_ORDER_4K) could not be used to bypass the > mmio_ro_ranges check performed by p2m_type_to_flags. > > This however is already checked in set_mmio_p2m_entry, which makes > sure that h

Re: [Xen-devel] [PATCH for-4.12 v3 2/8] x86/pvh: reorder PVH dom0 iommu initialization

On 15/02/2019 15:18, Roger Pau Monne wrote: > So that the iommu is initialized before populating the p2m, and > entries added get the corresponding iommu page table entries if > required. This requires splitting the current pvh_setup_p2m into two > different functions. One that crafts dom0 physmap

Re: [Xen-devel] [PATCH for-4.12 v3 1/8] dom0/pvh: align allocation and mapping order to start address

On 15/02/2019 15:18, Roger Pau Monne wrote: > The p2m and iommu mapping code always had the requirement that > addresses and orders must be aligned when populating the p2m or the > iommu page tables. > > PVH dom0 builder didn't take this requirement into account, and can > call into the p2m/iommu

[Xen-devel] [PATCH v3 7/8] x86/mm: handle foreign mappings in p2m_entry_modify

So that the specific handling can be removed from atomic_write_ept_entry and be shared with npt and shadow code. This commit also removes the check that prevent non-ept PVH dom0 from mapping foreign pages. Signed-off-by: Roger Pau Monné --- Cc: George Dunlap Cc: Jan Beulich Cc: Andrew Cooper

[Xen-devel] [PATCH for-4.12 v3 4/8] pvh/dom0: warn when dom0_mem is not set

There have been several reports of the dom0 builder running out of memory when building a PVH dom0 without having specified a dom0_mem value. Print a warning message if dom0_mem is not set when booting in PVH mode. This is a temporary workaround until accounting for internal memory required by Xen

[Xen-devel] [PATCH for-4.12 v3 0/8] pvh/dom0/shadow/amd fixes

Hello, The following series contains fixes that should be considered for 4.12. I'm not sure whether patches 5, 6, 7 and 8 should be aimed at 4.12, they contain changes to the p2m code that could affect HVM guests. Note that without those changes a PVH dom0 running on AMD hardware will be unable t

Re: [Xen-devel] [PATCH for-4.12 v3 4/8] pvh/dom0: warn when dom0_mem is not set

>>> On 15.02.19 at 15:18, wrote: > There have been several reports of the dom0 builder running out of > memory when building a PVH dom0 without having specified a dom0_mem > value. Print a warning message if dom0_mem is not set when booting in > PVH mode. > > This is a temporary workaround until

Re: [Xen-devel] XEN on R-CAR H3

Hi, > disk = [ 'phy:/dev/mmcblk1p1,xvda1' ] Thanks , this worked for us and we can now boot Linux guest in domU. But now, while booting Android as domU guest , we don't get console login for domU and it stuck here: [ 10.597394] usbcore: registered new interface driver cdc_acm [ 10.597436] c

[Xen-devel] [PATCH for-4.12 v3 3/8] amd/npt/shadow: replace assert that prevents creating 2M/1G MMIO entries

The assert was originally added to make sure that higher order regions (> PAGE_ORDER_4K) could not be used to bypass the mmio_ro_ranges check performed by p2m_type_to_flags. This however is already checked in set_mmio_p2m_entry, which makes sure that higher order mappings don't overlap with mmio_r

[Xen-devel] [PATCH v3 8/8] npt/shadow: allow getting foreign page table entries

Current npt and shadow code to get an entry will always return INVALID_MFN for foreign entries. Allow to return the entry mfn for foreign entries, like it's done for grant table entries. Signed-off-by: Roger Pau Monné --- Cc: George Dunlap Cc: Jan Beulich Cc: Andrew Cooper Cc: Wei Liu --- Cha

[Xen-devel] [PATCH v3 5/8] x86/mm: split p2m ioreq server pages special handling into helper

So that it can be shared by both ept, npt and shadow code, instead of duplicating it. No change in functionality intended. Signed-off-by: Roger Pau Monné Reviewed-by: Paul Durrant --- Cc: George Dunlap Cc: Jan Beulich Cc: Andrew Cooper Cc: Wei Liu Cc: Jun Nakajima Cc: Kevin Tian Cc: Paul

[Xen-devel] [PATCH v3 6/8] p2m: change write_p2m_entry to return an error code

This is in preparation for also changing p2m_entry_modify to return an error code. No functional change intended. Signed-off-by: Roger Pau Monné --- Cc: George Dunlap Cc: Jan Beulich Cc: Andrew Cooper Cc: Wei Liu Cc: Tim Deegan --- Changes since v2: - New in this version. --- xen/arch/x86

[Xen-devel] [linux-next test] 133224: regressions - trouble: blocked/broken/fail/pass

flight 133224 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/133224/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvopsbroken build-arm64-xsm

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

> On Feb 15, 2019, at 2:02 PM, Jan Beulich wrote: > On 15.02.19 at 14:51, wrote: > >> >>> On Feb 15, 2019, at 1:47 PM, Andrew Cooper >>> wrote: >>> >>> On 15/02/2019 13:37, George Dunlap wrote: >> The one issue is that domain_pause_except_self() currently is actually a >>>

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

>>> On 15.02.19 at 14:51, wrote: > >> On Feb 15, 2019, at 1:47 PM, Andrew Cooper wrote: >> >> On 15/02/2019 13:37, George Dunlap wrote: >>> > The one issue is that domain_pause_except_self() currently is actually a > deadlock risk if two different vcpus start it at the same time. I

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

On 2/15/19 3:37 PM, George Dunlap wrote: On Feb 15, 2019, at 1:24 PM, Jan Beulich wrote: On 15.02.19 at 13:52, wrote: On Feb 12, 2019, at 11:42 AM, Razvan Cojocaru wrote: HVMOP_altp2m_set_domain_state does not domain_pause(), presumably on purpose (as it was originally supposed to cater

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

> On Feb 15, 2019, at 1:47 PM, Andrew Cooper wrote: > > On 15/02/2019 13:37, George Dunlap wrote: >> The one issue is that domain_pause_except_self() currently is actually a deadlock risk if two different vcpus start it at the same time. I think the attached patch (comp

Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]

Ian, as mentioned earlier, I think we need a legal/admin item for hardware and donations. See proposed addition below. On 15/02/2019, 11:57, "Ian Jackson" wrote: Ian Jackson writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]"): > So overall, for the reason

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

On 15/02/2019 13:37, George Dunlap wrote: > >>> The one issue is that domain_pause_except_self() currently is actually a >>> deadlock risk if two different vcpus start it at the same time. I think >>> the >>> attached patch (compile-tested only) should fix this issue; after this >>> patch >>>

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

>>> On 15.02.19 at 14:37, wrote: >> On Feb 15, 2019, at 1:24 PM, Jan Beulich wrote: >> And two cosmetic remarks - there's no need to re-specify >> __must_check on the function definition, as the function >> declaration ought to be in scope anyway. And there's a stray >> blank inside the likely()

Re: [Xen-devel] [PATCH V2 0/3] Renesas Stout board support (R-Car Gen2)

On 15.02.19 15:30, Julien Grall wrote: Hi, Julien On Fri, 15 Feb 2019, 14:25 Oleksandr, > wrote: On 01.02.19 14:37, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko mailto:oleksandr_tyshche...@epam.com>> > > Hi, all. Hi, all g

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

> On Feb 15, 2019, at 1:24 PM, Jan Beulich wrote: > On 15.02.19 at 13:52, wrote: >>> On Feb 12, 2019, at 11:42 AM, Razvan Cojocaru >>> wrote: >>> >>> HVMOP_altp2m_set_domain_state does not domain_pause(), presumably >>> on purpose (as it was originally supposed to cater to a in-guest >

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

On Feb 12, 2019, at 11:42 AM, Razvan Cojocaru wrote: HVMOP_altp2m_set_domain_state does not domain_pause(), presumably on purpose (as it was originally supposed to cater to a in-guest agent, and a domain pausing itself is not a good idea). Sorry to come in here on v4 and suggest changing every

Re: [Xen-devel] [PATCH V2 0/3] Renesas Stout board support (R-Car Gen2)

On Fri, 15 Feb 2019, 14:25 Oleksandr, wrote: > > On 01.02.19 14:37, Oleksandr Tyshchenko wrote: > > From: Oleksandr Tyshchenko > > > > Hi, all. > > > Hi, all > > gentle reminder... > This is in my queue of patches to review. Also, as we are in freeze, I tend to prioritize patches for 4.12. I w

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

>>> On 15.02.19 at 13:52, wrote: >> On Feb 12, 2019, at 11:42 AM, Razvan Cojocaru >> wrote: >> >> HVMOP_altp2m_set_domain_state does not domain_pause(), presumably >> on purpose (as it was originally supposed to cater to a in-guest >> agent, and a domain pausing itself is not a good idea). > >

Re: [Xen-devel] [PATCH V2 0/3] Renesas Stout board support (R-Car Gen2)

On 01.02.19 14:37, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko Hi, all. Hi, all gentle reminder... The purpose of this patch series is to add required support to be able to run Xen on Renesas Stout board [1] which uses SCIFA compatible UART as a console interface. Actually

Re: [Xen-devel] [PATCH for-4.12 V4] x86/altp2m: fix HVMOP_altp2m_set_domain_state race

> On Feb 12, 2019, at 11:42 AM, Razvan Cojocaru > wrote: > > HVMOP_altp2m_set_domain_state does not domain_pause(), presumably > on purpose (as it was originally supposed to cater to a in-guest > agent, and a domain pausing itself is not a good idea). Sorry to come in here on v4 and suggest c

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

flight 133263 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/133263/ 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 1

Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]

On 15/02/2019 12:56, Ian Jackson wrote: > Ian Jackson writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 > more messages]"): >> So overall, for the reasons I explain, I'm going to commit this >> document (subject to the other comments etc.) *with* the requirement >> that hardware must

Re: [Xen-devel] [PATCH] tools/libxendevicemodel: add xendevicemodel_modified_memory_bulk to map

On 15/02/2019 11:31, Paul Durrant wrote: > Cc-ing Juergen, in case this can make 4.12... > >> -Original Message- >> From: Paul Durrant [mailto:paul.durr...@citrix.com] >> Sent: 15 February 2019 10:02 >> To: xen-devel@lists.xenproject.org >> Cc: Paul Durrant ; Ian Jackson >> ; Wei Liu >> S

Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]

Ian Jackson writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]"): > So overall, for the reasons I explain, I'm going to commit this > document (subject to the other comments etc.) *with* the requirement > that hardware must be supported by Debian (at least, in -backport

Re: [Xen-devel] [PATCH SpectreV1+L1TF v6 3/9] x86/hvm: block speculative out-of-bound accesses

>>> On 15.02.19 at 11:50, wrote: > On 2/15/19 09:55, Jan Beulich wrote: > On 15.02.19 at 09:05, wrote: >>> On 2/12/19 15:14, Jan Beulich wrote: >>> On 12.02.19 at 15:05, wrote: > On 2/12/19 14:25, Jan Beulich wrote: > On 08.02.19 at 14:44, wrote: >>> @@ -4104,6 +4108,12

Re: [Xen-devel] [PATCH] tools/libxendevicemodel: add xendevicemodel_modified_memory_bulk to map

Paul Durrant writes ("RE: [PATCH] tools/libxendevicemodel: add xendevicemodel_modified_memory_bulk to map"): > Perhaps it would be possible to build some sort of cross-check that all > functions listed in the public header of a library are actually *somewhere* > in the map file, so this doesn't

Re: [Xen-devel] RT Xen on ARM - R-Car series

Hello Julien, On 14.02.19 19:29, Julien Grall wrote: I am not sure why you are speaking about the current implementation when my point was about the new implementation. I guess your point stick even if we decide to use guest physical address. For sure. The type of guest address used by hypervi

Re: [Xen-devel] [PATCH] tools/libxendevicemodel: add xendevicemodel_modified_memory_bulk to map

> -Original Message- > From: Ian Jackson [mailto:ian.jack...@citrix.com] > Sent: 15 February 2019 11:27 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; Wei Liu ; > jgr...@suse.com > Subject: RE: [PATCH] tools/libxendevicemodel: add > xendevicemodel_modified_memory_bulk to map > >

Re: [Xen-devel] [PATCH] tools/libxendevicemodel: add xendevicemodel_modified_memory_bulk to map

Paul Durrant writes ("RE: [PATCH] tools/libxendevicemodel: add xendevicemodel_modified_memory_bulk to map"): > Cc-ing Juergen, in case this can make 4.12... I think this should go into 4.12. It is very low risk. In another case there would possibly be questions about whether we wanted to add an

Re: [Xen-devel] [OSSTEST PATCH 5/4] backports snapshot: Disable apt timestamp checking in right place

Juergen Gross writes ("Re: [Xen-devel] [OSSTEST PATCH 5/4] backports snapshot: Disable apt timestamp checking in right place"): > Release-acked-by: Juergen Gross > > in case my implicit ack from yesterday expired as well ;-) Thanks :-). I pushed it without waiting. It is now in production (as

Re: [Xen-devel] [PATCH] tools/libxendevicemodel: add xendevicemodel_modified_memory_bulk to map

On Fri, Feb 15, 2019 at 10:02:00AM +, Paul Durrant wrote: > Commit e3b93b3c595 "dmop: add xendevicemodel_modified_memory_bulk()" added > the implementation to the library almost 2 years ago, but the function > was not included in the map file, essentially making it useless. This > patch rectifi

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

> On 15 Feb 2019, at 09:35, George Dunlap wrote: > >>> >>> As use case goes, it would be a good start if you just submit something >>> you care about. >> >> I mentioned on the call that a good first start could be a kconfig that >> allows to build an hypervisor binary with only support for PV

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

On Thu, Feb 14, 2019 at 09:03:24PM +, Lars Kurth wrote: > > > > On 14 Feb 2019, at 18:32, Stefano Stabellini wrote: > > > > On Thu, 14 Feb 2019, Jan Beulich wrote: > > On 13.02.19 at 20:11, wrote: > >>> On Wed, 13 Feb 2019, Wei Liu wrote: > On Tue, Feb 12, 2019 at 09:34:25PM -0500

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

On Thu, Feb 14, 2019 at 10:32:31AM -0800, Stefano Stabellini wrote: > > Do you have any other suggestions about things that could be removed to > reach down to 100K LOC, in addition to what you have already written > above (Intel/AMD, shadow)? Turning off some of the decompression algorithms can

Re: [Xen-devel] MCE/EDAC Status/Updating?

>>> On 15.02.19 at 05:23, wrote: > The MCE/EDAC support code appears to be in rather poor shape. > > The AMD code mentions Family 10h, which might have been available 10 > years ago. They've likely been findable used with difficulty more > recently, but no hardware made in the past 5 years match

Re: [Xen-devel] [PATCH SpectreV1+L1TF v6 3/9] x86/hvm: block speculative out-of-bound accesses

On 2/15/19 09:55, Jan Beulich wrote: On 15.02.19 at 09:05, wrote: >> On 2/12/19 15:14, Jan Beulich wrote: >> On 12.02.19 at 15:05, wrote: On 2/12/19 14:25, Jan Beulich wrote: On 08.02.19 at 14:44, wrote: >> @@ -4104,6 +4108,12 @@ static int hvmop_set_param( >>

Re: [Xen-devel] [PATCH] tools/libxendevicemodel: add xendevicemodel_modified_memory_bulk to map

Cc-ing Juergen, in case this can make 4.12... > -Original Message- > From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: 15 February 2019 10:02 > To: xen-devel@lists.xenproject.org > Cc: Paul Durrant ; Ian Jackson > ; Wei Liu > Subject: [PATCH] tools/libxendevicemodel: add > xende

Re: [Xen-devel] [PATCH SpectreV1+L1TF v6 8/9] common/grant_table: block speculative out-of-bound accesses

>>> On 15.02.19 at 10:55, wrote: > On 2/13/19 12:50, Jan Beulich wrote: > On 08.02.19 at 14:44, wrote: >>> Guests can issue grant table operations and provide guest controlled >>> data to them. This data is also used for memory loads. To avoid >>> speculative out-of-bound accesses, we use the

[Xen-devel] [PATCH] tools/libxendevicemodel: add xendevicemodel_modified_memory_bulk to map

Commit e3b93b3c595 "dmop: add xendevicemodel_modified_memory_bulk()" added the implementation to the library almost 2 years ago, but the function was not included in the map file, essentially making it useless. This patch rectifies the situation. Signed-off-by: Paul Durrant --- Cc: Ian Jackson C

Re: [Xen-devel] [PATCH SpectreV1+L1TF v6 8/9] common/grant_table: block speculative out-of-bound accesses

On 2/13/19 12:50, Jan Beulich wrote: On 08.02.19 at 14:44, wrote: >> Guests can issue grant table operations and provide guest controlled >> data to them. This data is also used for memory loads. To avoid >> speculative out-of-bound accesses, we use the array_index_nospec macro >> where appli

[Xen-devel] [xen-unstable-smoke test] 133260: trouble: blocked/broken/pass

flight 133260 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/133260/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken build-arm64-xs

  1   2   >