Re: [Xen-devel] [PATCH v4 12/28] x86/vvtd: decode interrupt attribute from IRTE

On Mon, Feb 12, 2018 at 11:55:42AM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:19PM +0800, Chao Gao wrote: >> Without interrupt remapping, interrupt attributes can be extracted from >> msi message or IOAPIC RTE. However, with interrupt remapping enabled, >> the attributes are

Re: [Xen-devel] [PATCH v4 10/28] x86/vvtd: Enable Interrupt Remapping through GCMD

On Mon, Feb 12, 2018 at 11:30:18AM +, Roger Pau Monné wrote: >On Sun, Feb 11, 2018 at 01:05:01PM +0800, Chao Gao wrote: >> On Fri, Feb 09, 2018 at 05:15:17PM +, Roger Pau Monné wrote: >> >On Fri, Nov 17, 2017 at 02:22:17PM +0800, Chao Gao wrote: >> >> +static void write_gcmd_ire(struct

Re: [Xen-devel] [PATCH v4 08/28] x86/vvtd: Add MMIO handler for VVTD

On Fri, Feb 09, 2018 at 05:51:29PM +, Roger Pau Monné wrote: >On Sat, Feb 10, 2018 at 01:21:09AM +0800, Chao Gao wrote: >> On Fri, Feb 09, 2018 at 04:39:15PM +, Roger Pau Monné wrote: >> >On Fri, Nov 17, 2017 at 02:22:15PM +0800, Chao Gao wrote: >> >> This patch adds VVTD MMIO handler to

[Xen-devel] [xen-4.7-testing test] 119780: tolerable FAIL - PUSHED

flight 119780 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/119780/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 119489 test-xtf-amd64-amd64-1 50

[Xen-devel] [PATCH] xen/tools: support Python 2 and Python 3

These changes should make it possible to support modern Pythons as well as the oldest Python 2 still supported. Signed-off-by: Doug Goldstein --- CC: Andrew Cooper CC: George Dunlap CC: Ian Jackson

[Xen-devel] [PATCH v2] xen: append EXTRA_CFLAGS_XEN_CORE to CFLAGS

Allow a user to supply extra CFLAGS via the EXTRA_CFLAGS_XEN_CORE environment variable for hypervisor builds. This is not a configuration that is supported but is only aimed to help support testing and troubleshooting when you need to make changes. Signed-off-by: Doug Goldstein

Re: [Xen-devel] pvh+vcpus startup issue

On 22/02/18 05:37, x...@randomwebstuff.com wrote: > Hi.  I have a domU.  Its params file has: vcpus = 8.  It will start with > pv, but not type="pvh".  It will not start (on pvh) with vcpus = 7 or 6 > or 5.  It does start with vcpus = 4. > > I diffed the xl -v create logs, no difference there on

Re: [Xen-devel] [PATCH] xenstore: increase default thread stack size to 32k

On 21/02/18 23:13, Jim Fehlig wrote: > On several Skylake machines I've observed xl segfaults when running > create or destroy subcommands. Other subcommands may segfault too, > but I've only looked at create and destroy which share a similar > backtrace > > Thread 2 (Thread 0x77ff3700 (LWP

[Xen-devel] pvh+vcpus startup issue

Hi.  I have a domU.  Its params file has: vcpus = 8.  It will start with pv, but not type="pvh".  It will not start (on pvh) with vcpus = 7 or 6 or 5.  It does start with vcpus = 4. I diffed the xl -v create logs, no difference there on either startup. I grabbed the domU console output for a

[Xen-devel] [xen-4.10-testing test] 119777: regressions - FAIL

flight 119777 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/119777/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 118771 Tests which

[Xen-devel] [xen-4.8-testing test] 119771: tolerable FAIL - PUSHED

flight 119771 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/119771/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 119273 test-armhf-armhf-xl-rtds 16

Re: [Xen-devel] [PATCH 0/2] x86/svm: add pause filtering threshold for SVM

On 02/20/2018 07:12 PM, Brian Woods wrote: > This patch series adds support and enablement of the pause filtering > threshold. Once there's pause filtering threshold amount of cycles > between pauses, the pause filtering counter resets to what was in the > VMCB. This allows the pause filtering

Re: [Xen-devel] [PATCH v4 16/16] xen: Convert page_to_mfn and mfn_to_page to use typesafe MFN

On 02/21/2018 09:02 AM, Julien Grall wrote: > Most of the users of page_to_mfn and mfn_to_page are either overriding > the macros to make them work with mfn_t or use mfn_x/_mfn because the > rest of the function use mfn_t. > > So make page_to_mfn and mfn_to_page return mfn_t by default. The __* >

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-qemut-rhel6hvm-amd

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-qemut-rhel6hvm-amd 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: qemu

Re: [Xen-devel] [PATCH] libxl: set channel devid when not provided by application

Any comments on this patch? Thanks! Regards, Jim On 02/07/2018 08:04 PM, Jim Fehlig wrote: Applications like libvirt may not populate a device devid field, delegating that to libxl. If needed, the application can later retrieve the libxl-produced devid. Indeed most devices are handled this way

[Xen-devel] [PATCH] xenstore: increase default thread stack size to 32k

On several Skylake machines I've observed xl segfaults when running create or destroy subcommands. Other subcommands may segfault too, but I've only looked at create and destroy which share a similar backtrace Thread 2 (Thread 0x77ff3700 (LWP 2941)): at /usr/include/bits/unistd.h:44

[Xen-devel] [PATCH RFC 10/10] x86: check hvm domain before calling pt_irq_destroy_bind

... just like its counter part because that function is HVM only. There is no risk of corruption because pt_irq_destroy_bind already has proper check in place, but it would be nice to be more explicit before calling the said function. Signed-off-by: Wei Liu ---

[Xen-devel] [PATCH RFC 07/10] passthrough/amd: split out hvm code from iommu_map.c

Move and rename update_paging_mode. Create a local header file for this and other functions that need exporting. Signed-off-by: Wei Liu --- Cc: Suravee Suthikulpanit --- xen/drivers/passthrough/x86/amd/Makefile| 1 +

[Xen-devel] [PATCH RFC 05/10] x86/passthrough: move hvm_dpci_isairq_eoi

This function is not Intel specific. Move it to io.c along side its sole user. Remove declaration in iommu.h. Signed-off-by: Wei Liu --- Cc: Kevin Tian --- xen/drivers/passthrough/x86/io.c | 45 +++

[Xen-devel] [PATCH RFC 01/10] passthrough: rearrange x86 code

Clean up the hierarchy of the directory: put vtd, amd and io.c under x86. Adjust makefile and MAINTAINERS. Signed-off-by: Wei Liu --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Suravee Suthikulpanit

[Xen-devel] [PATCH RFC 06/10] passthrough/amd: remove guest iommu support

It is never used and it is getting in the way of cleaning up. The only callsite of guest_iommu_add_ppr_log has no effect because guest iommu is not initialised. Signed-off-by: Wei Liu --- Cc: Suravee Suthikulpanit ---

[Xen-devel] [PATCH RFC 04/10] x86/passthrough: arch_pci_clean_irqs is HVM only

Provide a !CONFIG_HVM stub in preparation for future usage. Signed-off-by: Wei Liu --- xen/drivers/passthrough/x86/pci.c | 12 1 file changed, 12 insertions(+) diff --git a/xen/drivers/passthrough/x86/pci.c b/xen/drivers/passthrough/x86/pci.c index

[Xen-devel] [PATCH RFC 09/10] passthrough/intel: put some code under CONFIG_HVM

The code which references code under arch/x86/hvm/ is surrounded by CONFIG_HVM now. The basic idea is that in !CONFIG_HVM && CONFIG_PV case we still want to retain the host side IOMMU code so that PV guests can use it if necessary. Signed-off-by: Wei Liu --- Cc: Kevin Tian

[Xen-devel] [PATCH RFC 08/10] passthrough/amd: make clear_iommu_pte_present static

There is only one user in the same file. Signed-off-by: Wei Liu --- Cc: Suravee Suthikulpanit --- xen/drivers/passthrough/x86/amd/iommu_map.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Xen-devel] [PATCH RFC 02/10] passthrough: split out x86 PCI code to x86/pci.c

Move the functions that reference x86 hvm data structures to its own file. Rename pci_clean_dpci_irqs to arch_pci_clean_irqs. There is still one location in that file which references arch.hvm_domain, but it is fine because ARM guest is HVM. Signed-off-by: Wei Liu --- Cc:

Re: [Xen-devel] [PATCH 2/7] x86/alt: Clean up struct alt_instr and its users

On Mon, Feb 12, 2018 at 11:23:02AM +, Andrew Cooper wrote: > * Rename some fields for consistency and clarity, and use standard types. > * Don't opencode the use of ALT_{ORIG,REPL}_PTR(). > > No functional change. > > Signed-off-by: Andrew Cooper > --- > CC: Jan

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

flight 119776 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/119776/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 7 xen-boot fail REGR. vs. 118784 Regressions

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

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

Re: [Xen-devel] [PATCH RFC v2] x86/domctl: Don't pause the whole domain if only getting vcpu state

On Fri, Oct 6, 2017 at 11:02 AM, Alexandru Isaila wrote: > This patch adds the hvm_save_one_cpu_ctxt() function. > It optimizes by only pausing the vcpu on all HVMSR_PER_VCPU save > callbacks where only data for one VCPU is required. Sorry it's taken so long to get back

Re: [Xen-devel] [RFC PATCH v2 0/9] hyper_dmabuf: Hyper_DMABUF driver

On Mon, Feb 19, 2018 at 06:01:29PM +0100, Daniel Vetter wrote: > On Tue, Feb 13, 2018 at 05:49:59PM -0800, Dongwon Kim wrote: > > This patch series contains the implementation of a new device driver, > > hyper_DMABUF driver, which provides a way to expand the boundary of > > Linux DMA-BUF sharing

Re: [Xen-devel] [PATCH] domctl: revert double increment of domctl version

Am Wed, 21 Feb 2018 17:53:54 + schrieb Andrew Cooper : > I continue to think that this is a mistake (which is backed up by > everyone else being confused about what is going on), and demonstrates > the ineffectiveness of the *_INTERFACE_VERSIONS in general. Well,

Re: [Xen-devel] [PATCH] domctl: revert double increment of domctl version

On 21/02/18 17:38, Wei Liu wrote: > On Wed, Feb 21, 2018 at 06:34:22PM +0100, Olaf Hering wrote: >> Xen 4.10 has XEN_DOMCTL_INTERFACE_VERSION 0xe, staging should be fine >> with 0xf until the next release is prepared. >> >> Signed-off-by: Olaf Hering >> --- >>

Re: [Xen-devel] [PATCH] domctl: revert double increment of domctl version

Am Wed, 21 Feb 2018 17:38:03 + schrieb Wei Liu : > The reason we bumped the number twice is because we want a dedicated > number to denote the recent security fix. Thanks, that was no clear from the commit messages. Olaf pgptLjyZ2XhXq.pgp Description: Digitale

Re: [Xen-devel] [PATCH 1/2] x86/svm: add support for pause filtering threshold

Looks good. Reviewed-by: Babu Moger > -Original Message- > From: Woods, Brian > Sent: Tuesday, February 20, 2018 6:13 PM > To: xen-de...@lists.xen.org > Cc: Boris Ostrovsky ; Suthikulpanit, Suravee > ; Jan

Re: [Xen-devel] [PATCH 2/2] x86/svm: enable pause filtering threshold

Looks good. Reviewed-by: Babu Moger > -Original Message- > From: Woods, Brian > Sent: Tuesday, February 20, 2018 6:13 PM > To: xen-de...@lists.xen.org > Cc: Boris Ostrovsky ; Suthikulpanit, Suravee > ; Jan

Re: [Xen-devel] [PATCH] domctl: revert double increment of domctl version

On Wed, Feb 21, 2018 at 06:34:22PM +0100, Olaf Hering wrote: > Xen 4.10 has XEN_DOMCTL_INTERFACE_VERSION 0xe, staging should be fine > with 0xf until the next release is prepared. > > Signed-off-by: Olaf Hering > --- > xen/include/public/domctl.h | 2 +- > 1 file changed, 1

Re: [Xen-devel] [PATCH v3 10/17] xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

On Wed, 21 Feb 2018, Julien Grall wrote: > Hi Stefano, > > On 21/02/2018 00:35, Stefano Stabellini wrote: > > On Thu, 15 Feb 2018, Julien Grall wrote: > > > Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1. > > > > > > Signed-off-by: Julien Grall > > > >

[Xen-devel] [PATCH] domctl: revert double increment of domctl version

Xen 4.10 has XEN_DOMCTL_INTERFACE_VERSION 0xe, staging should be fine with 0xf until the next release is prepared. Signed-off-by: Olaf Hering --- xen/include/public/domctl.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/include/public/domctl.h

Re: [Xen-devel] [PATCH RFC] CODING_STYLE: document intended usage of types

On 02/21/2018 03:55 PM, Andrew Cooper wrote: > On 19/02/18 13:30, Jan Beulich wrote: > On 19.02.18 at 14:12, wrote: >>> On 19/02/18 08:44, Jan Beulich wrote: --- a/CODING_STYLE +++ b/CODING_STYLE @@ -88,6 +88,26 @@ Braces should be omitted for blocks

Re: [Xen-devel] [PATCH v5 3/5] x86/clang: restore integrated assembler usage with indirect thunks

On 20/02/18 14:10, Roger Pau Monne wrote: > If the required features are met by the integrated clang assembler > (support for .includes and propagation of .macro-s between asm()-s) > do not disable it. > > Only disable the integrated assembler for assembly files, like it was > done prior to "x86:

Re: [Xen-devel] [PATCH v3 03/17] xen/arm: vsmc: Implement SMCCC_ARCH_WORKAROUND_1 BP hardening support

Hi, On 21/02/18 16:41, Julien Grall wrote: > > > On 21/02/18 16:34, Andre Przywara wrote: >> Hi, > > Hi, > >> On 15/02/18 15:02, Julien Grall wrote: >>> SMCCC 1.1 offers firmware-based CPU workarounds. In particular, >>> SMCCC_ARCH_WORKAROUND_1 provides BP hardening for variant 2 of XSA-254

Re: [Xen-devel] [PATCH v3 03/17] xen/arm: vsmc: Implement SMCCC_ARCH_WORKAROUND_1 BP hardening support

On 21/02/18 16:34, Andre Przywara wrote: Hi, Hi, On 15/02/18 15:02, Julien Grall wrote: SMCCC 1.1 offers firmware-based CPU workarounds. In particular, SMCCC_ARCH_WORKAROUND_1 provides BP hardening for variant 2 of XSA-254 (CVE-2017-5715). If the hypervisor has some mitigation for this

Re: [Xen-devel] [PATCH v3 12/17] xen/arm: vpsci: Remove parameter 'ver' from do_common_cpu

On 21/02/18 16:27, Andre Przywara wrote: Hi, Hi, On 15/02/18 15:02, Julien Grall wrote: Currently, the behavior of do_common_cpu will slightly change depending on the PSCI version passed in parameter. Looking at the code, more the specific 0.2 behavior could move out of the function or

Re: [Xen-devel] [PATCH v3 03/17] xen/arm: vsmc: Implement SMCCC_ARCH_WORKAROUND_1 BP hardening support

Hi, On 15/02/18 15:02, Julien Grall wrote: > SMCCC 1.1 offers firmware-based CPU workarounds. In particular, > SMCCC_ARCH_WORKAROUND_1 provides BP hardening for variant 2 of XSA-254 > (CVE-2017-5715). > > If the hypervisor has some mitigation for this issue, report that we > deal with it using

Re: [Xen-devel] [PATCH v5 2/5] build: filter out command line assembler arguments

On 20/02/18 14:10, Roger Pau Monne wrote: > If the assembler is not used. This happens when using cc -E or cc -S > for example. GCC will just ignore the -Wa,... when the assembler is > not called, but clang will complain loudly and fail. > > Also enable passing -Wa,-I$(BASEDIR)/include to clang

Re: [Xen-devel] [PATCH v3 12/17] xen/arm: vpsci: Remove parameter 'ver' from do_common_cpu

Hi, On 15/02/18 15:02, Julien Grall wrote: > Currently, the behavior of do_common_cpu will slightly change depending > on the PSCI version passed in parameter. Looking at the code, more the > specific 0.2 behavior could move out of the function or adapted for 0.1: > > - x0/r0 can be updated

Re: [Xen-devel] [PATCH] sysctl: correct comment in xen_sysctl_pcitopoinfo

On Wed, 21 Feb 2018, Olaf Hering wrote: > Refer to correct member of struct xen_sysctl_pcitopoinfo in comment. > > Fixes: commit 61319fbfd9 ("sysctl: add sysctl interface for querying PCI > topology") > > Signed-off-by: Olaf Hering Reviewed-by: Stefano Stabellini

Re: [Xen-devel] [PATCH v5 1/5] build: do not hardcode AFLAGS for as-insn tests

On 20/02/18 14:10, Roger Pau Monne wrote: > Hardcoding as-insn to use AFLAGS is not correct. For once the test is > performed using a C file with inline assembly, and secondly the flags > used can be passed by the caller together with the CC. > > Fix as-insn-check to pass the flags given as

Re: [Xen-devel] [PATCH v3 10/17] xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

Hi, On 15/02/18 15:02, Julien Grall wrote: > Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1. > > Signed-off-by: Julien Grall > > --- > Changes in v3: > - Add the missing call to smc #0. > > Changes in v2: > - Patch added > ---

Re: [Xen-devel] [PATCH v3 17/17] xen/arm: vpsci: Rework the logic to start AArch32 vCPU in Thumb mode

Hi, On 15/02/18 15:02, Julien Grall wrote: > 32-bit domain is able to select the instruction (ARM vs Thumb) to use > when boot a new vCPU via CPU_ON. This is indicated via bit[0] of the > entry point address (see "T32 support" in PSCI v1.1 DEN0022D). bit[0] > must be cleared when setting the PC.

Re: [Xen-devel] [RFC PATCH 01/10] Add CONFIG_VGIC_ERRATA

On 21/02/18 15:17, Manish Jaggi wrote: Hi Julien, On 01/25/2018 07:18 PM, Julien Grall wrote: Hi Manish, On 16/01/18 15:42, mja...@caviumnetworks.com wrote: From: Manish Jaggi Add a config option to enable VGIC Errata Code in Xen. Platforms which do not have

Re: [Xen-devel] [PATCH RFC] CODING_STYLE: document intended usage of types

On 19/02/18 13:30, Jan Beulich wrote: On 19.02.18 at 14:12, wrote: >> On 19/02/18 08:44, Jan Beulich wrote: >>> --- a/CODING_STYLE >>> +++ b/CODING_STYLE >>> @@ -88,6 +88,26 @@ Braces should be omitted for blocks with >>> if ( condition ) >>>

Re: [Xen-devel] Excited for Xen Project in Outreachy

Hi Lars, I'm already on #unikraft with the registered username - kanik. My timezone is UTC+5:30h and I can be available for a chat at any time of the day post noon usually. I have subscribed to the mailing lists and gone through the documentation at

Re: [Xen-devel] [PATCH RFC] CODING_STYLE: document intended usage of types

On Mon, Feb 19, 2018 at 8:44 AM, Jan Beulich wrote: > Signed-off-by: Jan Beulich > > --- a/CODING_STYLE > +++ b/CODING_STYLE > @@ -88,6 +88,26 @@ Braces should be omitted for blocks with > if ( condition ) > single_statement(); > > +Types > +- > +

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

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

Re: [Xen-devel] [RFC PATCH 01/10] Add CONFIG_VGIC_ERRATA

Hi Julien, On 01/25/2018 07:18 PM, Julien Grall wrote: Hi Manish, On 16/01/18 15:42, mja...@caviumnetworks.com wrote: From: Manish Jaggi Add a config option to enable VGIC Errata Code in Xen. Platforms which do not have this errta can compile out this feature.

Re: [Xen-devel] [PATCH v4 16/16] xen: Convert page_to_mfn and mfn_to_page to use typesafe MFN

> -Original Message- > From: Julien Grall [mailto:julien.gr...@arm.com] > Sent: 21 February 2018 14:03 > To: xen-de...@lists.xen.org > Cc: Julien Grall ; Stefano Stabellini > ; Andrew Cooper ; > George Dunlap

Re: [Xen-devel] Ability to crash a HVM guest by accessing /dev/hpet

On 21.02.2018 15:40, Roger Pau Monné wrote: > On Wed, Feb 21, 2018 at 03:12:15PM +0100, Stefan Bader wrote: >> This seems to have been found by us[1] and Citrix[2] recently. To trigger >> this >> one needs to be root in the guest, so it is not super critical but still it >> seems to be a bit

Re: [Xen-devel] [PATCH v3 08/17] xen/arm: psci: Detect SMCCC version

Hi, On 15/02/18 15:02, Julien Grall wrote: > PSCI 1.0 and later allows the SMCCC version to be (indirectly) probed > via PSCI_FEATURES. If the PSCI_FEATURES does not exist (PSCI 0.2 or > earlier) and the function return an error, then we considered SMCCC 1.0 returns

Re: [Xen-devel] Ability to crash a HVM guest by accessing /dev/hpet

On Wed, Feb 21, 2018 at 03:12:15PM +0100, Stefan Bader wrote: > This seems to have been found by us[1] and Citrix[2] recently. To trigger this > one needs to be root in the guest, so it is not super critical but still it > seems to be a bit harsh that purely opening /dev/hpet read-only is leading

Re: [Xen-devel] [PATCH v3 05/17] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_1

Hi, On 15/02/18 15:02, Julien Grall wrote: > The function SMCCC_ARCH_WORKAROUND_1 will be called by the guest for > hardening the branch predictor. So we want the handling to be as fast as > possible. > > As the mitigation is applied on every guest exit, we can check for the > call before saving

Re: [Xen-devel] [PATCH v4 16/16] xen: Convert page_to_mfn and mfn_to_page to use typesafe MFN

On 02/21/2018 04:02 PM, Julien Grall wrote: > Most of the users of page_to_mfn and mfn_to_page are either overriding > the macros to make them work with mfn_t or use mfn_x/_mfn because the > rest of the function use mfn_t. > > So make page_to_mfn and mfn_to_page return mfn_t by default. The __* >

Re: [Xen-devel] [PATCH v3 1/2] x86/hvm: introduce cr{0, 4}_host_mask to store trapped bits of CR accesses

On Wed, Feb 21, 2018 at 08:48:20AM -0500, Boris Ostrovsky wrote: > On 02/21/2018 03:27 AM, Roger Pau Monné wrote: > > On Tue, Feb 20, 2018 at 07:23:44PM -0500, Boris Ostrovsky wrote: > >> On 02/20/2018 03:56 AM, Roger Pau Monne wrote: > >>> At the moment this is currently set at VMC{S/B} creation

[Xen-devel] Ability to crash a HVM guest by accessing /dev/hpet

This seems to have been found by us[1] and Citrix[2] recently. To trigger this one needs to be root in the guest, so it is not super critical but still it seems to be a bit harsh that purely opening /dev/hpet read-only is leading to a domain crash via xen/arch/x86/hvm/hpet.c@375(hpet_write):

[Xen-devel] Modifying domain creation interface

Creating a new domain currently is a sequence of hypercalls with many of those being mandatory and needed in a specific sequence. Its has been discussed before to build a new interface for domain creation with _all_ the mandatory information passed to the hypervisor in one hypercall. I'd like to

[Xen-devel] [PATCH v4 04/16] xen/arm: mm: Remove unused M2P code

Arm does not have an M2P and very unlikely to get one in the future, therefore don't keep defines that are not necessary in the common code. At the same time move the remaining M2P define just above just above set_gpfn_from_mfn to keep all the dummy helpers for M2P together. Signed-off-by:

[Xen-devel] [PATCH v4 09/16] xen/pdx: Introduce helper to convert MFN <-> PDX

This will avoid use of pfn_to_pdx(mfn_x(mfn)) over the code base. Signed-off-by: Julien Grall --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich

[Xen-devel] [PATCH v4 05/16] xen/arm: mm: Remove unused relinquish_shared_pages

relinquish_shared_pages is never called on Arm. Signed-off-by: Julien Grall --- Cc: Stefano Stabellini Changes in v4: - Patch added --- xen/include/asm-arm/mm.h | 4 1 file changed, 4 deletions(-) diff --git

[Xen-devel] [PATCH v4 15/16] xen/x86: Switch mfn_to_page in x86_64/mm.c to use typesafe MFN

No functional change intendend. Signed-off-by: Julien Grall --- Cc: Jan Beulich Cc: Andrew Cooper Changes in v4: - Patch added --- xen/arch/x86/x86_64/mm.c | 46 ++ 1

[Xen-devel] [PATCH v4 13/16] xen/grant: Switch {create, replace}_grant_p2m_mapping to typesafe MFN

The current prototype is slightly confusing because it takes a guest physical address and a machine physical frame (not address!). Switching to MFN will improve safety and reduce the chance to mistakenly invert the 2 parameters. Signed-off-by: Julien grall --- Cc: Stefano

[Xen-devel] [PATCH v4 06/16] xen/x86: Remove unused override of page_to_mfn/mfn_to_page

A few files override page_to_mfn/mfn_to_page but actually never use those macros. So drop them. Signed-off-by: Julien Grall --- Cc: George Dunlap Cc: Jan Beulich Cc: Andrew Cooper Changes in

[Xen-devel] [PATCH v4 01/16] xen/tmem: Convert the file common/tmem_xen.c to use typesafe MFN

The file common/tmem_xen.c is now converted to use typesafe. This is requiring to override the macro page_to_mfn to make it work with mfn_t. Note that all variables converted to mfn_t havem there initial value, when set, switch from 0 to INVALID_MFN. This is fine because the initial values was

[Xen-devel] [PATCH v4 16/16] xen: Convert page_to_mfn and mfn_to_page to use typesafe MFN

Most of the users of page_to_mfn and mfn_to_page are either overriding the macros to make them work with mfn_t or use mfn_x/_mfn because the rest of the function use mfn_t. So make page_to_mfn and mfn_to_page return mfn_t by default. The __* version are now dropped as this patch will convert all

[Xen-devel] [PATCH v4 11/16] xen/mm: Switch page_alloc.c to typesafe MFN

No functional change intended. Signed-off-by: Julien Grall --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk

[Xen-devel] [PATCH v4 00/16] xen: Convert page_to_mfn and mfn_to_page to use typesafe MFN

Hi all, This series is a rework of "xen: Convert __page_to_mfn and __mfn_to_page to use typesafe MFN" sent a couple of months ago (see [1]). In this new approach, the macros __page_to_mfn and __mfn_to_page are completely dropped. To avoid the last patch (#16) to be a huge patch some files are

[Xen-devel] [PATCH v4 12/16] xen/mm: Switch common/memory.c to use typesafe MFN

A new helper copy_mfn_to_guest is introduced to easily to copy a MFN to the guest memory. Not functional change intended Signed-off-by: Julien Grall --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson

[Xen-devel] [PATCH v4 14/16] xen/grant: Switch common/grant_table.c to use typesafe MFN

No functional change intended. Signed-off-by: Julien Grall --- Cc: Stefano Stabellini Cc: Julien Grall Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson

[Xen-devel] [PATCH v4 07/16] xen/x86: mm: Switch x86/mm.c to use typesafe for virt_to_mfn

No functional change intended. Signed-off Julien Grall --- Cc: Jan Beulich Cc: Andrew Cooper Changes in v4: - Patch added --- xen/arch/x86/mm.c | 17 + 1 file changed, 9 insertions(+), 8

[Xen-devel] [PATCH v4 10/16] xen/mm: Switch map_pages_to_xen to use MFN typesafe

The current prototype is slightly confusing because it takes a virtual address and a physical frame (not address!). Switching to MFN will improve safety and reduce the chance to mistakenly invert the 2 parameters. Signed-off-by: Julien Grall --- Cc: Stefano Stabellini

[Xen-devel] [PATCH v4 03/16] xen/arm: mm: Use gaddr_to_gfn rather than _gfn(paddr_to_pfn(...))

The construction _gfn(paddr_to_pfn(...)) can be simplified by using gaddr_to_gfn. Signed-off-by: Julien Grall --- Cc: Stefano Stabellini Changes in v4: - Patch added --- xen/arch/arm/mm.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[Xen-devel] [PATCH v4 08/16] xen/mm: Drop the parameter mfn from populate_pt_range

The function populate_pt_range is used to populate in advance the page-table but it will not do the actual mapping. So passing the MFN in parameter is pointless. Note that the only caller pass 0... At the same time replace 0 by INVALID_MFN to make clear the MFN is invalid. Signed-off-by: Julien

[Xen-devel] [PATCH v4 02/16] xen/arm: setup: use maddr_to_mfn rather than _mfn(paddr_to_pfn(...))

The construction _mfn(paddr_to_pfn(...)) can be simplified by using maddr_to_mfn. Signed-off-by: Julien Grall --- Cc: Stefano Stabellini Changes in v4: - Patch added --- xen/arch/arm/setup.c | 4 ++-- 1 file changed, 2 insertions(+),

Re: [Xen-devel] [PATCH v3 1/2] x86/hvm: introduce cr{0, 4}_host_mask to store trapped bits of CR accesses

On 02/21/2018 03:27 AM, Roger Pau Monné wrote: > On Tue, Feb 20, 2018 at 07:23:44PM -0500, Boris Ostrovsky wrote: >> On 02/20/2018 03:56 AM, Roger Pau Monne wrote: >>> At the moment this is currently set at VMC{S/B} creation and not changed, >>> but further patches are going to change the CR4 mask

[Xen-devel] [PATCH] sysctl: correct comment in xen_sysctl_pcitopoinfo

Refer to correct member of struct xen_sysctl_pcitopoinfo in comment. Fixes: commit 61319fbfd9 ("sysctl: add sysctl interface for querying PCI topology") Signed-off-by: Olaf Hering --- xen/include/public/sysctl.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

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

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

Re: [Xen-devel] [PATCH v2 5/5] x86: Rework MSR_TSC_AUX handling from scratch.

On Wed, Feb 21, 2018 at 11:36:15AM +, Andrew Cooper wrote: > There are many problems with MSR_TSC_AUX handling. > > To begin with, the RDPID instruction reads MSR_TSC_AUX, but it is only the > RDTSCP feature which enumerates the MSR. Therefore, RDPID functionally > depends on RDTSCP. > >

Re: [Xen-devel] [PATCH v3] build: remove shim related targets

>>> On 21.02.18 at 13:22, wrote: > --- a/tools/firmware/xen-dir/Makefile > +++ b/tools/firmware/xen-dir/Makefile > @@ -48,13 +48,14 @@ shim-%config: $(D) FORCE > KCONFIG_CONFIG=$(CURDIR)/shim.config > > xen-shim: $(D) shim-olddefconfig > - $(MAKE) -C

Re: [Xen-devel] [PATCH v3] build: remove shim related targets

On 21/02/18 12:22, Roger Pau Monne wrote: > There's no need to have shim specific targets, so just use the regular > xen makefile targets in order to build the shim binary. > > When the shim is build as part of the firmware directory install the > stripped Xen binary to the firmware directory and

Re: [Xen-devel] [PATCH v3] build: remove shim related targets

On Wed, Feb 21, 2018 at 12:22:18PM +, Roger Pau Monne wrote: > There's no need to have shim specific targets, so just use the regular > xen makefile targets in order to build the shim binary. > > When the shim is build as part of the firmware directory install the > stripped Xen binary to the

[Xen-devel] [PATCH v3] build: remove shim related targets

There's no need to have shim specific targets, so just use the regular xen makefile targets in order to build the shim binary. When the shim is build as part of the firmware directory install the stripped Xen binary to the firmware directory and place a binary with symbols in the debug directory.

Re: [Xen-devel] [PATCH v2 1/4] asm-x86/monitor: Enable svm monitor events

On Fri, Feb 9, 2018 at 4:21 PM, Tamas K Lengyel wrote: > On Fri, Feb 9, 2018 at 3:28 AM, George Dunlap wrote: >> On Thu, Feb 8, 2018 at 3:25 PM, Alexandru Isaila >> wrote: >>> This commit separates the svm caps from the vmx caps.

[Xen-devel] [PATCH v2 5/5] x86: Rework MSR_TSC_AUX handling from scratch.

There are many problems with MSR_TSC_AUX handling. To begin with, the RDPID instruction reads MSR_TSC_AUX, but it is only the RDTSCP feature which enumerates the MSR. Therefore, RDPID functionally depends on RDTSCP. For PV guests, we hide RDTSCP but advertise RDPID. We also silently drop

[Xen-devel] [PATCH RFC] x86: slightly reduce RSB overwrite overhead

Avoiding the PAUSE/LFENCE pair on the first of the two unrolled iterations not only reduces code size, but also improves performance according to my (limited) measurements (by 15-20 cycles on my Westmere; granted I can't really explain why that is). Now that the two iterations are sufficiently

Re: [Xen-devel] [PATCH 5/5] x86: Rework MSR_TSC_AUX handling from scratch.

On Tue, Feb 20, 2018 at 05:42:06PM +, Andrew Cooper wrote: > On 20/02/18 17:03, Wei Liu wrote: > > On Tue, Feb 20, 2018 at 11:58:43AM +, Andrew Cooper wrote: > >> There are many problems with MSR_TSC_AUX handling. > >> > >> To being with, the RDPID instruction reads MSR_TSC_AUX, but it is

[Xen-devel] [xen-unstable-coverity test] 119806: regressions - ALL FAIL

flight 119806 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/119806/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: coverity-amd647 coverity-upload fail REGR. vs. 119558 version

Re: [Xen-devel] [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver

On 02/21/2018 12:19 PM, Roger Pau Monné wrote: On Wed, Feb 21, 2018 at 11:42:23AM +0200, Oleksandr Andrushchenko wrote: On 02/21/2018 11:17 AM, Roger Pau Monné wrote: On Wed, Feb 21, 2018 at 10:03:34AM +0200, Oleksandr Andrushchenko wrote: --- /dev/null +++

Re: [Xen-devel] [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver

On Wed, Feb 21, 2018 at 11:42:23AM +0200, Oleksandr Andrushchenko wrote: > On 02/21/2018 11:17 AM, Roger Pau Monné wrote: > > On Wed, Feb 21, 2018 at 10:03:34AM +0200, Oleksandr Andrushchenko wrote: > > > --- /dev/null > > > +++ b/drivers/gpu/drm/xen/xen_drm_front.c > > > @@ -0,0 +1,83 @@ > > >

[Xen-devel] [PATCH v2] hvm/svm: Implement CPUID events

At this moment the CPUID events for the AMD architecture are not forwarded to the monitor layer. This patch adds the CPUID event to the common capabilities and then forwards the event to the monitor layer. --- Changes since V1: - Made function svm_vmexit_do_cpuid return int to handle

Re: [Xen-devel] [PATCH 5/5] x86: Rework MSR_TSC_AUX handling from scratch.

On Tue, Feb 20, 2018 at 06:28:15PM +, Andrew Cooper wrote: > On 20/02/18 17:35, Roger Pau Monné wrote: > > On Tue, Feb 20, 2018 at 11:58:43AM +, Andrew Cooper wrote: > >> There are many problems with MSR_TSC_AUX handling. > >> > >> To being with, the RDPID instruction reads MSR_TSC_AUX,

Re: [Xen-devel] [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver

On 02/21/2018 11:17 AM, Roger Pau Monné wrote: On Wed, Feb 21, 2018 at 10:03:34AM +0200, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Introduce skeleton of the para-virtualized Xen display frontend driver. This patch only adds required

  1   2   >