[Xen-devel] [libvirt test] 140784: regressions - FAIL

flight 140784 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/140784/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 140598

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf

Re: [Xen-devel] [PATCH v9 13/15] x86/microcode: Synchronize late microcode loading

On Thu, Aug 29, 2019 at 02:06:39PM +0200, Jan Beulich wrote: >On 19.08.2019 03:25, Chao Gao wrote: >> + >> +static int master_thread_fn(const struct microcode_patch *patch) >> +{ >> +unsigned int cpu = smp_processor_id(); >> +int ret = 0; >> + >> +while ( loading_state !=

Re: [Xen-devel] [PATCH v9 10/15] microcode: split out apply_microcode() from cpu_request_microcode()

On Thu, Aug 29, 2019 at 12:06:28PM +0200, Jan Beulich wrote: >On 22.08.2019 15:59, Roger Pau Monné wrote: >> Seeing how this works I'm not sure what's the best option here. As >> updating will be attempted on other CPUs, I'm not sure if it's OK to >> return an error if the update succeed on some

[Xen-devel] [linux-linus test] 140778: regressions - FAIL

flight 140778 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/140778/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-examine 8 reboot fail REGR. vs. 133580

[Xen-devel] [PATCH V2] arm: xen: mm: use __GPF_DMA32 for arm64

From: Peng Fan arm64 shares some code under arch/arm/xen, including mm.c. However ZONE_DMA is removed by commit ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32"). So introduce xen_set_gfp_dma for arm32/arm64 and using __GFP_DMA for the former and __GFP_DMA32 for the latter. Signed-off-by:

Re: [Xen-devel] [PATCH v3 00/39] put_user_pages(): miscellaneous call sites

On 8/29/2019 6:29 PM, Mike Marshall wrote: Hi John... I added this patch series on top of Linux 5.3rc6 and ran xfstests with no regressions... Acked-by: Mike Marshall Hi Mike (and I hope Ira and others are reading as well, because I'm making a bunch of claims further down), That's great

Re: [Xen-devel] [Xen-unstable] boot crash while loading AMD microcode due to commit "microcode/amd: fix memory leak"

On Fri, Aug 30, 2019 at 01:04:54AM +0200, Sander Eikelenboom wrote: >L.S., > >While testing xen-unstable, my AMD system crashes during early boot while >loading microcode with an "Early fatal page fault". >Reverting commit de45e3ff37bb1602796054afabfa626ea5661c45 "microcode/amd: fix >memory

Re: [Xen-devel] [PATCH v3 00/39] put_user_pages(): miscellaneous call sites

Hi John... I added this patch series on top of Linux 5.3rc6 and ran xfstests with no regressions... Acked-by: Mike Marshall -Mike On Tue, Aug 6, 2019 at 9:50 PM John Hubbard wrote: > > On 8/6/19 6:32 PM, john.hubb...@gmail.com wrote: > > From: John Hubbard > > ... > > > > John Hubbard (38):

[Xen-devel] [Xen-unstable] boot crash while loading AMD microcode due to commit "microcode/amd: fix memory leak"

L.S., While testing xen-unstable, my AMD system crashes during early boot while loading microcode with an "Early fatal page fault". Reverting commit de45e3ff37bb1602796054afabfa626ea5661c45 "microcode/amd: fix memory leak" fixes the boot issue. At present I don't have my serial console stuff

Re: [Xen-devel] swiotlb-xen cleanups v2

On Mon, 26 Aug 2019, Christoph Hellwig wrote: > Hi Xen maintainers and friends, > > please take a look at this series that cleans up the parts of swiotlb-xen > that deal with non-coherent caches. > > Changes since v1: > - rewrite dma_cache_maint to be much simpler > - improve various comments

Re: [Xen-devel] [PATCH 03/11] xen/arm: simplify dma_cache_maint

On Tue, 27 Aug 2019, Christoph Hellwig wrote: > And this was still buggy I think, it really needs some real Xen/Arm > testing which I can't do. Hopefully better version below: > > -- > >From 5ad4b6e291dbb49f65480c9b769414931cbd485a Mon Sep 17 00:00:00 2001 > From: Christoph Hellwig > Date: Wed,

Re: [Xen-devel] [PATCH 11/11] arm64: use asm-generic/dma-mapping.h

On Mon, 26 Aug 2019, Christoph Hellwig wrote: > Now that the Xen special cases are gone nothing worth mentioning is > left in the arm64 file, so switch to use the > asm-generic version instead. > > Signed-off-by: Christoph Hellwig > Acked-by: Will Deacon Reviewed-by: Stefano Stabellini >

Re: [Xen-devel] [PATCH 09/11] swiotlb-xen: remove page-coherent.h

On Mon, 26 Aug 2019, Christoph Hellwig wrote: > The only thing left of page-coherent.h is two functions implemented by > the architecture for non-coherent DMA support that are never called for > fully coherent architectures. Just move the prototypes for those to > swiotlb-xen.h instead. > >

Re: [Xen-devel] [PATCH 08/11] swiotlb-xen: simplify cache maintainance

On Mon, 26 Aug 2019, Christoph Hellwig wrote: > Now that we know we always have the dma-noncoherent.h helpers available > if we are on an architecture with support for non-coherent devices, > we can just call them directly, and remove the calls to the dma-direct > routines, including the fact that

Re: [Xen-devel] [PATCH 10/11] swiotlb-xen: merge xen_unmap_single into xen_swiotlb_unmap_page

On Mon, 26 Aug 2019, Christoph Hellwig wrote: > No need for a no-op wrapper. > > Signed-off-by: Christoph Hellwig Reviewed-by: Stefano Stabellini > --- > drivers/xen/swiotlb-xen.c | 15 --- > 1 file changed, 4 insertions(+), 11 deletions(-) > > diff --git

Re: [Xen-devel] [PATCH 07/11] swiotlb-xen: use the same foreign page check everywhere

On Mon, 26 Aug 2019, Christoph Hellwig wrote: > xen_dma_map_page uses a different and more complicated check for foreign > pages than the other three cache maintainance helpers. Switch it to the > simpler pfn_valid method a well, and document the scheme with a single > improved comment in

Re: [Xen-devel] [PATCH 06/11] swiotlb-xen: always use dma-direct helpers to alloc coherent pages

+ Boris, Juergen On Mon, 26 Aug 2019, Christoph Hellwig wrote: > x86 currently calls alloc_pages, but using dma-direct works as well > there, with the added benefit of using the CMA pool if available. > The biggest advantage is of course to remove a pointless bit of > architecture specific code.

Re: [Xen-devel] [PATCH 04/11] xen/arm: remove xen_dma_ops

On Mon, 26 Aug 2019, Christoph Hellwig wrote: > arm and arm64 can just use xen_swiotlb_dma_ops directly like x86, no > need for a pointer indirection. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Julien Grall Reviewed-by: Stefano Stabellini > --- > arch/arm/mm/dma-mapping.c| 3

Re: [Xen-devel] [PATCH 05/11] xen: remove the exports for xen_{create, destroy}_contiguous_region

On Mon, 26 Aug 2019, Christoph Hellwig wrote: > These routines are only used by swiotlb-xen, which cannot be modular. > > Signed-off-by: Christoph Hellwig Reviewed-by: Stefano Stabellini > --- > arch/arm/xen/mm.c | 2 -- > arch/x86/xen/mmu_pv.c | 2 -- > 2 files changed, 4 deletions(-)

Re: [Xen-devel] [PATCH 03/11] xen/arm: simplify dma_cache_maint

On Mon, 26 Aug 2019, Christoph Hellwig wrote: > Calculate the required operation in the caller, and pass it directly > instead of recalculating it for each page, and use simple arithmetics > to get from the physical address to Xen page size aligned chunks. > > Signed-off-by: Christoph Hellwig >

Re: [Xen-devel] [PATCH 02/11] xen/arm: use dev_is_dma_coherent

On Mon, 26 Aug 2019, Christoph Hellwig wrote: > Use the dma-noncoherent dev_is_dma_coherent helper instead of the home > grown variant. Note that both are always initialized to the same > value in arch_setup_dma_ops. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Julien Grall

Re: [Xen-devel] [PATCH 01/11] xen/arm: use dma-noncoherent.h calls for xen-swiotlb cache maintainance

On Mon, 26 Aug 2019, Christoph Hellwig wrote: > Reuse the arm64 code that uses the dma-direct/swiotlb helpers for DMA > non-coherent devices. This patch does a bunch of things not listed in the commit message, such as moving the static inline functions to include/xen/arm/page-coherent.h and

Re: [Xen-devel] [PATCH v2 11/12] livepatch: Add metadata runtime retrieval mechanism

On Tue, Aug 27, 2019 at 08:46:23AM +, Pawel Wieczorkiewicz wrote: > Extend the livepatch list operation to fetch also payloads' metadata. > This is achieved by extending the sysctl list interface with 2 extra > guest handles: > * metadata - an array of arbitrary size strings > *

[Xen-devel] [ovmf test] 140769: regressions - FAIL

flight 140769 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/140769/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail REGR. vs. 140559 version

Re: [Xen-devel] [PATCH v2 08/12] livepatch: Add support for inline asm hotpatching expectations

> Ah, I forgot about endianness of course... > I am sending an improved patch. I hope it works this time as expected. Works nicely! (Tested only on ARM64, hadn't tried ARM32 yet). ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

[Xen-devel] [qemu-upstream-unstable test] 140767: tolerable FAIL - PUSHED

flight 140767 qemu-upstream-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/140767/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 140235 test-armhf-armhf-libvirt

Re: [Xen-devel] [PATCH] x86/mmcfg: add "force" option for MCFG

On 29/08/2019 09:00, Roger Pau Monné wrote: >> >> I think we need to have this option to at least have a way to workaround >> problem (1). Problem (2) could be solved in Dom0 kernel by invoking >> xen_mcfg_late() earlier but before the first PCI bus enumertaion which >> currently happens somwhere

Re: [Xen-devel] [PATCH v2 00/12] livepatch: new features and fixes

> Pawel Wieczorkiewicz (12): > [1] livepatch: Always check hypervisor build ID upon hotpatch upload > [2] livepatch: Allow to override inter-modules buildid dependency > [3] livepatch: Export payload structure via livepatch_payload.h > [4] livepatch: Implement pre-|post- apply|revert hooks

Re: [Xen-devel] [PATCH v2 08/12] livepatch: Add support for inline asm hotpatching expectations

On 29. Aug 2019, at 19:49, Konrad Rzeszutek Wilk mailto:konrad.w...@oracle.com>> wrote: On Thu, Aug 29, 2019 at 04:16:13PM +, Wieczorkiewicz, Pawel wrote: On 29. Aug 2019, at 17:58, Konrad Rzeszutek Wilk mailto:konrad.w...@oracle.com>> wrote: …snip..

Re: [Xen-devel] [PATCH V3 4/8] xen/common: Introduce xrealloc_flex_struct() helper macros

On 29.08.19 10:21, Jan Beulich wrote: Hi Jan On 28.08.2019 20:23, Oleksandr wrote: --- a/xen/include/xen/xmalloc.h +++ b/xen/include/xen/xmalloc.h @@ -35,6 +35,18 @@  #define xzalloc_array(_type, _num) \ ((_type *)_xzalloc_array(sizeof(_type), __alignof__(_type), _num)) +/*

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

flight 140763 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/140763/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 17 guest-saverestore.2 fail in 140670 REGR. vs. 139910 Tests which are

Re: [Xen-devel] [PATCH v2 08/12] livepatch: Add support for inline asm hotpatching expectations

On Thu, Aug 29, 2019 at 04:16:13PM +, Wieczorkiewicz, Pawel wrote: > > > On 29. Aug 2019, at 17:58, Konrad Rzeszutek Wilk > mailto:konrad.w...@oracle.com>> wrote: > > +CODE_GET_EXPECT=$(shell objdump -d --insn-width=1 $(1) | grep -A6 -E > '<'$(2)'>:' | tail -n +2 | awk 'BEGIN {printf "{"}

[Xen-devel] [PATCH v3 01/11] checkpatch: check for nested (un)?likely() calls

IS_ERR(), IS_ERR_OR_NULL(), IS_ERR_VALUE() and WARN*() already contain unlikely() optimization internally. Thus, there is no point in calling these functions and defines under likely()/unlikely(). This check is based on the coccinelle rule developed by Enrico Weigelt

[Xen-devel] [PATCH v3 04/11] xen/events: Remove unlikely() from WARN() condition

"unlikely(WARN(x))" is excessive. WARN() already uses unlikely() internally. Signed-off-by: Denis Efremov Cc: Boris Ostrovsky Cc: Juergen Gross Cc: Joe Perches Cc: Andrew Morton Cc: xen-devel@lists.xenproject.org --- drivers/xen/events/events_base.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [Xen-devel] [PATCH v4 1/2] xen: Switch parameter in get_page_from_gfn to use typesafe gfn

Hi, On 29/08/2019 17:41, Jan Beulich wrote: > On 19.08.2019 16:26, Julien Grall wrote: >> No functional change intended. >> >> Only reasonable clean-ups are done in this patch. The rest will use _gfn >> for the time being. >> >> The code in get_page_from_gfn is slightly reworked to also handle a

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

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

Re: [Xen-devel] [PATCH v2 08/12] livepatch: Add support for inline asm hotpatching expectations

On 29. Aug 2019, at 17:58, Konrad Rzeszutek Wilk mailto:konrad.w...@oracle.com>> wrote: +CODE_GET_EXPECT=$(shell objdump -d --insn-width=1 $(1) | grep -A6 -E '<'$(2)'>:' | tail -n +2 | awk 'BEGIN {printf "{"} {printf "0x%s,", $$2}' | sed 's/,$$/}/g') Ony my Hikey 960 when I compile using an

Re: [Xen-devel] [PATCH v2 08/12] livepatch: Add support for inline asm hotpatching expectations

> +CODE_GET_EXPECT=$(shell objdump -d --insn-width=1 $(1) | grep -A6 -E > '<'$(2)'>:' | tail -n +2 | awk 'BEGIN {printf "{"} {printf "0x%s,", $$2}' | > sed 's/,$$/}/g') Ony my Hikey 960 when I compile using an native compiler I get: gcc -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall

[Xen-devel] [linux-4.19 test] 140757: regressions - FAIL

flight 140757 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/140757/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129313 build-armhf-pvops

Re: [Xen-devel] [PATCH v4 2/2] xen/domain: Use typesafe gfn in map_vcpu_info

On 23.08.2019 16:16, Andrew Cooper wrote: > On 19/08/2019 15:26, Julien Grall wrote: >> diff --git a/xen/include/public/vcpu.h b/xen/include/public/vcpu.h >> index 3623af932f..dc4c6a72a0 100644 >> --- a/xen/include/public/vcpu.h >> +++ b/xen/include/public/vcpu.h >> @@ -182,7 +182,7 @@

Re: [Xen-devel] [PATCH v4 1/2] xen: Switch parameter in get_page_from_gfn to use typesafe gfn

On 19.08.2019 16:26, Julien Grall wrote: > No functional change intended. > > Only reasonable clean-ups are done in this patch. The rest will use _gfn > for the time being. > > The code in get_page_from_gfn is slightly reworked to also handle a bad > behavior because it is not safe to use

Re: [Xen-devel] [PATCH v2 08/12] livepatch: Add support for inline asm hotpatching expectations

On 29. Aug 2019, at 16:34, Konrad Rzeszutek Wilk mailto:kon...@darnok.org>> wrote: …snip... + +struct livepatch_func __section(".livepatch.funcs") livepatch_exceptions = { +.version = LIVEPATCH_PAYLOAD_VERSION, +.name = livepatch_exceptions_str, +.new_addr = xen_hello_world, +

Re: [Xen-devel] [PATCH v6 10/10] introduce a 'passthrough' configuration option to xl.cfg...

> -Original Message- > From: Jan Beulich > Sent: 29 August 2019 15:07 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; Julien Grall ; > Andrew Cooper > ; Anthony Perard ; > Roger Pau Monne > ; Volodymyr Babchuk ; > George Dunlap > ; Ian Jackson ; Stefano > Stabellini > ;

Re: [Xen-devel] [PATCH v6 10/10] introduce a 'passthrough' configuration option to xl.cfg...

> -Original Message- > From: Roger Pau Monne > Sent: 23 August 2019 15:17 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; Ian Jackson ; Wei > Liu ; Andrew > Cooper ; George Dunlap ; > Jan Beulich > ; Julien Grall ; Konrad Rzeszutek > Wilk > ; Stefano Stabellini ; Tim >

Re: [Xen-devel] [PATCH RFC 2/3] x86/ACPI: restore VESA mode upon resume from S3

On 29.08.2019 16:45, Andrew Cooper wrote: > On 14/06/2019 12:37, Jan Beulich wrote: >> --- >> I'm wondering actually whether the user having to explicitly request the >> mode restoration is a good model: Why would we _not_ want to restore the >> mode we've set during boot? In the worst case Dom0

Re: [Xen-devel] [RFC Patch] xen/pt: Emulate FLR capability

On Thu, Aug 29, 2019 at 12:03:44PM +0200, Jan Beulich wrote: >On 29.08.2019 11:02, Chao Gao wrote: >> Currently, for a HVM on Xen, no reset method is virtualized. So in a VM's >> perspective, assigned devices cannot be reset. But some devices rely on PCI >> reset to recover from hardware hangs.

Re: [Xen-devel] [PATCH 3/3] x86: a little bit of 16-bit video mode setting code cleanup

On 29.08.2019 16:38, Andrew Cooper wrote: > On 29/08/2019 15:23, Jan Beulich wrote: >> On 29.08.2019 16:08, Andrew Cooper wrote: >>> On 14/06/2019 12:38, Jan Beulich wrote: @@ -38,9 +38,9 @@ ENTRY(wakeup_start) movw%ax, %ss# Need this? How to ret if clobbered?

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

On 22.08.2019 16:02, Alexandru Stefan ISAILA wrote: > This patch adds access control for NPT mode. > > The access rights are stored in the NPT p2m table 56:53. Why starting from bit 53? I can't seem to find any use of bit 52. > The bits are free after clearing the IOMMU flags [1]. > > Modify

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

flight 140745 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/140745/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 140676 Tests which did not

Re: [Xen-devel] [PATCH RFC 2/3] x86/ACPI: restore VESA mode upon resume from S3

On 14/06/2019 12:37, Jan Beulich wrote: > In order for "acpi_sleep=s3_mode" to have any effect, we should record > the video mode we switched to during boot. Since right now there's mode > setting code for VESA modes only in the resume case, record the mode > just in that one case. > >

Re: [Xen-devel] [PATCH 3/3] x86: a little bit of 16-bit video mode setting code cleanup

On 29/08/2019 15:23, Jan Beulich wrote: > On 29.08.2019 16:08, Andrew Cooper wrote: >> On 14/06/2019 12:38, Jan Beulich wrote: >>> To "compensate" for the code size growth by an earlier change: >>> - drop "trampoline" labels (in almost all cases the target label is >>> reachable with an

Re: [Xen-devel] [PATCH v2 08/12] livepatch: Add support for inline asm hotpatching expectations

> diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile > index 23113d3418..067861903f 100644 > --- a/xen/test/livepatch/Makefile > +++ b/xen/test/livepatch/Makefile > @@ -27,6 +27,8 @@ LIVEPATCH_ACTION_HOOKS_NOFUNC := > xen_action_hooks_nofunc.livepatch >

Re: [Xen-devel] [PATCH 3/3] x86: a little bit of 16-bit video mode setting code cleanup

On 29.08.2019 16:08, Andrew Cooper wrote: > On 14/06/2019 12:38, Jan Beulich wrote: >> To "compensate" for the code size growth by an earlier change: >> - drop "trampoline" labels (in almost all cases the target label is >> reachable with an 8-bit-displacement branch anyway, and a single 16- >>

Re: [Xen-devel] [PATCH 3/3] x86: a little bit of 16-bit video mode setting code cleanup

On 14/06/2019 12:38, Jan Beulich wrote: > To "compensate" for the code size growth by an earlier change: > - drop "trampoline" labels (in almost all cases the target label is > reachable with an 8-bit-displacement branch anyway, and a single 16- > bit-displacement branch is still better than a

Re: [Xen-devel] [PATCH v6 10/10] introduce a 'passthrough' configuration option to xl.cfg...

On 16.08.2019 19:20, Paul Durrant wrote: > ...and hence the ability to disable IOMMU mappings, and control EPT > sharing. > > This patch introduces a new 'libxl_passthrough' enumeration into > libxl_domain_create_info. The value will be set by xl either when it parses > a new 'passthrough' option

Re: [Xen-devel] [PATCH v6 09/10] iommu: tidy up iommu_use_hap_pt() and need_iommu_pt_sync() macros

On 16.08.2019 19:20, Paul Durrant wrote: > --- a/xen/drivers/passthrough/iommu.c > +++ b/xen/drivers/passthrough/iommu.c > @@ -102,8 +102,10 @@ static int __init parse_iommu_param(const char *s) > iommu_hwdom_passthrough = val; > else if ( (val = parse_boolean("dom0-strict",

Re: [Xen-devel] [PATCH v6 08/10] remove late (on-demand) construction of IOMMU page tables

> -Original Message- > From: Jan Beulich > Sent: 29 August 2019 14:39 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; Julien Grall ; > Alexandru Isaila > ; Petre Pircalabu ; > Razvan Cojocaru > ; Andrew Cooper ; Roger > Pau Monne > ; Volodymyr Babchuk ; > George Dunlap > ;

Re: [Xen-devel] [PATCH] x86: properly gate clearing of PKU feature

On 29.08.2019 15:21, Andrew Cooper wrote: > On 29/08/2019 14:13, Jan Beulich wrote: >> On 29.08.2019 12:46, Andrew Cooper wrote: >>> On 29/08/2019 10:27, Jan Beulich wrote: setup_clear_cpu_cap() is __init and hence may not be called post-boot. Note that opt_pku nevertheless is not

Re: [Xen-devel] [PATCH v6 08/10] remove late (on-demand) construction of IOMMU page tables

On 16.08.2019 19:19, Paul Durrant wrote: > --- a/xen/drivers/passthrough/iommu.c > +++ b/xen/drivers/passthrough/iommu.c > @@ -146,6 +146,17 @@ static int __init parse_dom0_iommu_param(const char *s) > } > custom_param("dom0-iommu", parse_dom0_iommu_param); > > +static void __hwdom_init

Re: [Xen-devel] [PATCH 1/3] x86/ACPI: re-park previously parked CPUs upon resume from S3

On 14/06/2019 12:37, Jan Beulich wrote: > Aiui when resuming from S3, CPUs come back out of RESET/INIT. From a programmers point of view, all APs are in Wait-for-SIPI after resume, and this is confirmed by several of the BWG flowcharts.  This is a logical consequence of the CPU losing all power,

Re: [Xen-devel] [PATCH v6 07/10] use is_iommu_enabled() where appropriate...

On 16.08.2019 19:19, Paul Durrant wrote: > ...rather than testing the global iommu_enabled flag and ops pointer. > > Now that there is a per-domain flag indicating whether the domain is > permitted to use the IOMMU (which determines whether the ops pointer will > be set), many tests of the global

Re: [Xen-devel] [PATCH] x86: properly gate clearing of PKU feature

On 29/08/2019 14:13, Jan Beulich wrote: > On 29.08.2019 12:46, Andrew Cooper wrote: >> On 29/08/2019 10:27, Jan Beulich wrote: >>> setup_clear_cpu_cap() is __init and hence may not be called post-boot. >>> Note that opt_pku nevertheless is not getting __initdata added - see >>> e.g. commit

Re: [Xen-devel] [PATCH] x86: properly gate clearing of PKU feature

On 29.08.2019 12:46, Andrew Cooper wrote: > On 29/08/2019 10:27, Jan Beulich wrote: >> setup_clear_cpu_cap() is __init and hence may not be called post-boot. >> Note that opt_pku nevertheless is not getting __initdata added - see >> e.g. commit 43fa95ae6a ("mm: make opt_bootscrub non-init"). >> >>

Re: [Xen-devel] [PATCH 2/2] x86/AMD: Fix handling of x87 exception pointers on Fam17h hardware

On 19.08.2019 20:26, Andrew Cooper wrote: > AMD Pre-Fam17h CPUs "optimise" {F,}X{SAVE,RSTOR} by not saving/restoring > FOP/FIP/FDP if an x87 exception isn't pending. This causes an information > leak, CVE-2006-1056, and worked around by several OSes, including Xen. AMD > Fam17h CPUs no longer

Re: [Xen-devel] [PATCH] x86: clear RDRAND CPUID bit on AMD family 15h/16h

On 29/08/2019 13:39, Juergen Gross wrote: > On 29.08.19 14:27, Jan Beulich wrote: >> On 29.08.2019 14:01, Juergen Gross wrote: >>> On 29.08.19 13:42, Andrew Cooper wrote: On 29/08/2019 10:28, Jan Beulich wrote: > Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24: >

[Xen-devel] [OSSTEST PATCH] make-hosts-flight: Prefer stretch to jessie

The list of suites in ALL_SUITES is in decreasing order of preference: it gets passed to cs-hosts-list, where the order is significant. Without this patch, we try to commission hosts by running jessie if the host flags seem to say jessie would be supported. That's not really sensible. CC:

Re: [Xen-devel] [PATCH] x86: clear RDRAND CPUID bit on AMD family 15h/16h

On 29.08.19 14:27, Jan Beulich wrote: On 29.08.2019 14:01, Juergen Gross wrote: On 29.08.19 13:42, Andrew Cooper wrote: On 29/08/2019 10:28, Jan Beulich wrote: Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24: There have been reports of RDRAND issues after resuming

Re: [Xen-devel] [PATCH] x86: clear RDRAND CPUID bit on AMD family 15h/16h

On 29.08.2019 14:01, Juergen Gross wrote: > On 29.08.19 13:42, Andrew Cooper wrote: >> On 29/08/2019 10:28, Jan Beulich wrote: >>> Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24: >>> >>> There have been reports of RDRAND issues after resuming from suspend on >>> some

Re: [Xen-devel] [PATCH v9 15/15] microcode: block #NMI handling when loading an ucode

On 19.08.2019 03:25, Chao Gao wrote: > @@ -481,12 +478,28 @@ static int do_microcode_update(void *patch) > return ret; > } > > +static int microcode_nmi_callback(const struct cpu_user_regs *regs, int cpu) > +{ > +/* The first thread of a core is to load an update. Don't block it. */ >

Re: [Xen-devel] [PATCH v9 15/15] microcode: block #NMI handling when loading an ucode

On 27.08.2019 06:52, Chao Gao wrote: > On Mon, Aug 26, 2019 at 04:07:59PM +0800, Chao Gao wrote: >> On Fri, Aug 23, 2019 at 09:46:37AM +0100, Sergey Dyasli wrote: >>> On 19/08/2019 02:25, Chao Gao wrote: register an nmi callback. And this callback does busy-loop on threads which are

Re: [Xen-devel] [PATCH v9 13/15] x86/microcode: Synchronize late microcode loading

On 19.08.2019 03:25, Chao Gao wrote: > @@ -232,6 +276,34 @@ bool microcode_update_cache(struct microcode_patch > *patch) > return true; > } > > +/* Wait for a condition to be met with a timeout (us). */ > +static int wait_for_condition(int (*func)(void *data), void *data, > +

Re: [Xen-devel] [PATCH] x86: clear RDRAND CPUID bit on AMD family 15h/16h

On 29.08.19 13:42, Andrew Cooper wrote: On 29/08/2019 10:28, Jan Beulich wrote: Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24: There have been reports of RDRAND issues after resuming from suspend on some AMD family 15h and family 16h systems. This issue stems from

Re: [Xen-devel] [PATCH] x86: clear RDRAND CPUID bit on AMD family 15h/16h

On 29/08/2019 10:28, Jan Beulich wrote: > Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24: > > There have been reports of RDRAND issues after resuming from suspend on > some AMD family 15h and family 16h systems. This issue stems from a BIOS > not performing the

Re: [Xen-devel] [PATCH V3 8/8] iommu/arm: Add Renesas IPMMU-VMSA support

Hi, all + +static __init int ipmmu_init(struct dt_device_node *node, const void *data) +{ +int ret; + +/* + * Even if the device can't be initialized, we don't want to give + * the IPMMU device to dom0. + */ +dt_device_set_used_by(node, DOMID_XEN); + +if (

Re: [Xen-devel] [PATCH V3 8/8] iommu/arm: Add Renesas IPMMU-VMSA support

On 29.08.19 11:37, Yoshihiro Shimoda wrote: Hi Oleksandr-san, Hi Shimoda-san. From: Oleksandr Tyshchenko, Sent: Wednesday, August 21, 2019 3:10 AM From: Oleksandr Tyshchenko The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU) which provides address translation and

Re: [Xen-devel] [PATCH v2] Partially revert "x86/mm: Clean IOMMU flags from p2m-pt code"

On 8/29/19 9:49 AM, Roger Pau Monne wrote: > This partially reverts commit > 854a49a7486a02edae5b3e53617bace526e9c1b1 by re-adding the logic that > propagates changes to the domain physmap done by p2m_pt_set_entry into > the iommu page tables. Without this logic changes to the guest physmap > are

Re: [Xen-devel] [PATCH v8 01/28] linkage: new macros for assembler symbols

On 12. 08. 19, 19:06, Borislav Petkov wrote: >> + Again, every ``SYM_CODE_START*`` **shall** be coupled by ``SYM_CODE_END``. > > Btw, this coupling: I haven't gone through the whole patchset but do we > have automatic checking which makes sure a starting macro is coupled > with the correct

Re: [Xen-devel] [PATCH v9 12/15] microcode: reduce memory allocation and copy when creating a patch

On 19.08.2019 03:25, Chao Gao wrote: > @@ -542,29 +505,21 @@ static struct microcode_patch > *cpu_request_microcode(const void *buf, > while ( (error = get_ucode_from_buffer_amd(mc_amd, buf, bufsize, > )) == 0 ) > { > -struct

Re: [Xen-devel] [PATCH] x86: properly gate clearing of PKU feature

On 29/08/2019 10:27, Jan Beulich wrote: > setup_clear_cpu_cap() is __init and hence may not be called post-boot. > Note that opt_pku nevertheless is not getting __initdata added - see > e.g. commit 43fa95ae6a ("mm: make opt_bootscrub non-init"). > > Signed-off-by: Jan Beulich Acked-by: Andrew

Re: [Xen-devel] [PATCH] p2m/ept: pass correct level to atomic_write_ept_entry in ept_invalidate_emt

On 29.08.2019 12:26, Roger Pau Monné wrote: > On Tue, Aug 27, 2019 at 05:23:33PM +0200, Jan Beulich wrote: >> On 23.08.2019 07:58, Tian, Kevin wrote: From: Roger Pau Monne [mailto:roger@citrix.com] Sent: Tuesday, August 20, 2019 11:38 PM The level passed to

Re: [Xen-devel] [PATCH 3/6] remove late (on-demand) construction of IOMMU page tables

On 29.08.2019 12:20, Paul Durrant wrote: >> -Original Message- >> From: Jan Beulich >> Sent: 29 August 2019 10:52 >> To: Paul Durrant >> Cc: 'JulienGrall' ; 'Alexandru Isaila' >> ; 'Petre >> Pircalabu' ; 'Razvan Cojocaru' >> ; Andrew Cooper >> ; George Dunlap ; Ian >> Jackson >> ;

Re: [Xen-devel] [PATCH 2/3] build: allow picking the env values for compiler variables

On Tue, Aug 27, 2019 at 11:59:33AM +0100, Ian Jackson wrote: > Jan Beulich writes ("Re: [PATCH 2/3] build: allow picking the env values for > compiler variables"): > > On 20.08.2019 09:58, Roger Pau Monné wrote: > > > I don't have things 'left' in the environment, neither have most build > > >

Re: [Xen-devel] [PATCH v9 11/15] microcode: unify loading update during CPU resuming and AP wakeup

On 19.08.2019 03:25, Chao Gao wrote: > Both are loading the cached patch. Since APs call the unified function, > microcode_update_one(), during wakeup, the 'start_update' parameter > which originally used to distinguish BSP and APs is redundant. So remove > this parameter. > > Signed-off-by: Chao

Re: [Xen-devel] [PATCH v9 11/15] microcode: unify loading update during CPU resuming and AP wakeup

On 29.08.2019 09:37, Chao Gao wrote: > On Fri, Aug 23, 2019 at 11:09:07AM +0200, Roger Pau Monné wrote: >> On Fri, Aug 23, 2019 at 12:44:34AM +0800, Chao Gao wrote: >>> On Thu, Aug 22, 2019 at 04:10:46PM +0200, Roger Pau Monné wrote: On Mon, Aug 19, 2019 at 09:25:24AM +0800, Chao Gao wrote:

Re: [Xen-devel] [PATCH] p2m/ept: pass correct level to atomic_write_ept_entry in ept_invalidate_emt

On Tue, Aug 27, 2019 at 05:23:33PM +0200, Jan Beulich wrote: > On 23.08.2019 07:58, Tian, Kevin wrote: > > > From: Roger Pau Monne [mailto:roger@citrix.com] > > > Sent: Tuesday, August 20, 2019 11:38 PM > > > > > > The level passed to ept_invalidate_emt corresponds to the EPT entry > > >

Re: [Xen-devel] [RFC Patch] xen/pt: Emulate FLR capability

On Thu, Aug 29, 2019 at 05:02:27PM +0800, Chao Gao wrote: > Currently, for a HVM on Xen, no reset method is virtualized. So in a VM's > perspective, assigned devices cannot be reset. But some devices rely on PCI > reset to recover from hardware hangs. When being assigned to a VM, those > devices

Re: [Xen-devel] [PATCH 3/6] remove late (on-demand) construction of IOMMU page tables

> -Original Message- > From: Jan Beulich > Sent: 29 August 2019 10:52 > To: Paul Durrant > Cc: 'JulienGrall' ; 'Alexandru Isaila' > ; 'Petre > Pircalabu' ; 'Razvan Cojocaru' > ; Andrew Cooper > ; George Dunlap ; Ian > Jackson > ; Roger Pau Monne ; > 'VolodymyrBabchuk' > ; 'Stefano

Re: [Xen-devel] [PATCH v9 10/15] microcode: split out apply_microcode() from cpu_request_microcode()

On 19.08.2019 03:25, Chao Gao wrote: > @@ -300,32 +322,44 @@ int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) > buf, unsigned long len) > if ( microcode_ops == NULL ) > return -EINVAL; > > -info = xmalloc_bytes(sizeof(*info) + len); > -if ( info == NULL ) > +

Re: [Xen-devel] [PATCH v9 04/15] microcode: introduce a global cache of ucode patch

On 19.08.2019 03:25, Chao Gao wrote: > +static enum microcode_match_result compare_patch( > +const struct microcode_patch *new, const struct microcode_patch *old) > +{ > +return (new->mc_intel->hdr.rev > old->mc_intel->hdr.rev) ? NEW_UCODE : > +

[Xen-devel] [PATCH v3 2/5] xen: add new CONFIG_DEBUG_LOCKS option

Instead of enabling debugging for debug builds only add a dedicated Kconfig option for that purpose which defaults to DEBUG. Signed-off-by: Juergen Gross --- V2: - rename to CONFIG_DEBUG_LOCKS (Jan Beulich) --- xen/Kconfig.debug | 7 +++ xen/common/spinlock.c | 4 ++--

[Xen-devel] [PATCH v3 3/5] xen: print lock profile info in panic()

Print the lock profile data when the system crashes and add some more information for each lock data (lock address, cpu holding the lock). While at it use the PRI_stime format specifier for printing time data. This is especially beneficial for watchdog triggered crashes in case of deadlocks. In

[Xen-devel] [PATCH v3 1/5] xen/spinlocks: in debug builds store cpu holding the lock

Add the cpu currently holding the lock to struct lock_debug. This makes analysis of locking errors easier and it can be tested whether the correct cpu is releasing a lock again. Signed-off-by: Juergen Gross --- V2: adjust types (Jan Beulich) --- xen/common/spinlock.c | 33

Re: [Xen-devel] [PATCH v9 10/15] microcode: split out apply_microcode() from cpu_request_microcode()

On 22.08.2019 15:59, Roger Pau Monné wrote: > Seeing how this works I'm not sure what's the best option here. As > updating will be attempted on other CPUs, I'm not sure if it's OK to > return an error if the update succeed on some CPUs but failed on > others. The overall result of a partially

Re: [Xen-devel] [RFC Patch] xen/pt: Emulate FLR capability

On 29.08.2019 11:02, Chao Gao wrote: > Currently, for a HVM on Xen, no reset method is virtualized. So in a VM's > perspective, assigned devices cannot be reset. But some devices rely on PCI > reset to recover from hardware hangs. When being assigned to a VM, those > devices cannot be reset and

Re: [Xen-devel] [PATCH 3/6] remove late (on-demand) construction of IOMMU page tables

On 29.08.2019 11:33, Paul Durrant wrote: > TBH I've seen sufficient numbers of domain create failures when using > auto-ballooning that I stopped using it some time ago (besides the fact > that it's slow). If you're happy with the simplistic > double-the-page-table-reservation calculation then I

Re: [Xen-devel] [PATCH] x86/mmcfg: add "force" option for MCFG

On 28.08.2019 17:24, Igor Druzhinin wrote: > If MCFG area is not reserved in E820 Xen by default will defer its usage > until Dom0 registers it explicitly after ACPI parser recognizes it as > a reserved resource in DSDT. Having it reserved in E820 is not > mandatory according to "PCI Firmware

Re: [Xen-devel] [PATCH v2] Partially revert "x86/mm: Clean IOMMU flags from p2m-pt code"

On Thu, Aug 29, 2019 at 11:33:11AM +0200, Jan Beulich wrote: > On 29.08.2019 10:49, Roger Pau Monne wrote: > > @@ -640,9 +670,17 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, > > mfn_t mfn, > > && (gfn + (1UL << page_order) - 1 > p2m->max_mapped_pfn) ) > >

Re: [Xen-devel] [PATCH v2] Partially revert "x86/mm: Clean IOMMU flags from p2m-pt code"

On 29.08.2019 11:49, Roger Pau Monne wrote: > This partially reverts commit > 854a49a7486a02edae5b3e53617bace526e9c1b1 by re-adding the logic that > propagates changes to the domain physmap done by p2m_pt_set_entry into > the iommu page tables. Without this logic changes to the guest physmap >

Re: [Xen-devel] [PATCH v2] Partially revert "x86/mm: Clean IOMMU flags from p2m-pt code"

On 29.08.2019 10:49, Roger Pau Monne wrote: > @@ -640,9 +670,17 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, > mfn_t mfn, > && (gfn + (1UL << page_order) - 1 > p2m->max_mapped_pfn) ) > p2m->max_mapped_pfn = gfn + (1UL << page_order) - 1; > > +if (

  1   2   >