Re: [Xen-devel] [PATCH v2] x86/mm: Suppresses vm_events caused by page-walks

>>> On 23.02.18 at 18:46, wrote: > On Mon, Jan 08, 2018 at 02:49:44PM +0200, Alexandru Isaila wrote: >> --- >> tools/libxc/include/xenctrl.h | 2 ++ >> tools/libxc/xc_monitor.c | 14 ++ > > These changes look sensible to me. > >>

Re: [Xen-devel] [PATCH RFC 00/10] x86 passthrough code cleanup

>>> On 24.02.18 at 04:23, wrote: > I sort of buy-in CONFIG_PV, but not sure whether CONFIG_HVM is > required. I think the shim is where CONFIG_HVM would want to be turned off. Jan ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH 0/9] drm/xen-front: Add support for Xen PV display frontend

** *Hi, all!* * Last *Friday* some concerns on #dri-devel were raised wrt "yet another driver" for Xen and why not virtio-gpu. Let me highlight on why we need a new paravirtualized driver for Xen and why we can't just use virtio. Hope this helps the communities (both Xen and DRI) to have

Re: [Xen-devel] [RFC Patch v4 8/8] x86/hvm: bump the maximum number of vcpus to 512

>>> On 23.02.18 at 19:11, wrote: > On Wed, Dec 06, 2017 at 03:50:14PM +0800, Chao Gao wrote: >> Signed-off-by: Chao Gao >> --- >> xen/include/public/hvm/hvm_info_table.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git

Re: [Xen-devel] [RFC Patch v4 4/8] hvmloader: boot cpu through broadcast

>>> On 24.02.18 at 06:49, wrote: > On Fri, Feb 23, 2018 at 04:42:10PM +, Roger Pau Monné wrote: >>On Wed, Dec 06, 2017 at 03:50:10PM +0800, Chao Gao wrote: >>> Intel SDM Extended XAPIC (X2APIC) -> "Initialization by System Software" >>> has the following description: >>>

[Xen-devel] [xen-4.9-testing test] 120000: tolerable FAIL - PUSHED

flight 12 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/12/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail in 119954 pass in 12

[Xen-devel] [PATCH v2] tools/xenstore: try to get minimum thread stack size for watch thread

When creating a pthread in xs_watch() try to get the minimal needed size of the thread from glibc instead of using a constant. This avoids problems when the library is used in programs with large per-thread memory. Use dlsym() to get the pointer to __pthread_get_minstack() in order to avoid

[Xen-devel] (early) boot output

Boris, Jürgen, I'm now again in a situation where I see a crashed Dom0 with no useful information at all. This time "earlyprintk=xen" produced output, and the crash is after "bootconsole [xenboot0] disabled" (plus the immediately preceding "console [tty0] enabled"). Of course, just like for

[Xen-devel] ACPI / ioremap() crash

Boris, Jürgen, now for the actual crash: ACPI: Core revision 20170831 BUG: unable to handle kernel paging request at 8801d8c09050 IP: xen_set_pmd+0x3a/0x50 PGD 1c0a067 P4D 1c0a067 PUD 1de2067 PMD 1d9b3d067 PTE 8011d8c09065 Oops: 0003 [#1] SMP Modules linked in: Supported: Yes CPU: 0 PID:

Re: [Xen-devel] ACPI / ioremap() crash

On 26/02/18 10:05, Jan Beulich wrote: > Boris, Jürgen, > > now for the actual crash: > > ACPI: Core revision 20170831 > BUG: unable to handle kernel paging request at 8801d8c09050 > IP: xen_set_pmd+0x3a/0x50 > PGD 1c0a067 P4D 1c0a067 PUD 1de2067 PMD 1d9b3d067 PTE 8011d8c09065 > Oops:

Re: [Xen-devel] [PATCH 7/7] x86: add iommu_ops to map and unmap pages, and also to flush the IOTLB

> -Original Message- > From: Tian, Kevin [mailto:kevin.t...@intel.com] > Sent: 24 February 2018 03:02 > To: Paul Durrant ; xen-devel@lists.xenproject.org > Cc: Stefano Stabellini ; Wei Liu > ; George Dunlap

Re: [Xen-devel] [PATCH v5 06/18] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_1

Hi, On 23/02/18 18:57, 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 v5 11/18] xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

Hi, On 23/02/18 18:57, Julien Grall wrote: > Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1. > > Signed-off-by: Julien Grall Thanks, that looks good now: Reviewed-by: Andre Przywara Cheers, Andre. > --- > Changes in v5:

[Xen-devel] (partial) Spectre v2 mitigation without on Skylake IBRS

All, if running PV Linux on older Xen (4.5 and earlier) is relevant, it may be necessary to use a mechanism other than IBRS to mitigate Spectre v2 on Skylake. That is because the new MSR value can't be migrated prior to migration v2. Of course one option would be to retrofit some mechanism into

Re: [Xen-devel] [PATCH v5 00/18] xen/arm: PSCI 1.1 and SMCCC-1.1 support and XSA-254 variant 2 update

Hi, On 24/02/18 01:49, Stefano Stabellini wrote: > On Fri, 23 Feb 2018, Julien Grall wrote: >> Hi all, >> >> Arm has recently published a SMC Calling Convention (SMCCC) >> specification update [1] that provides an optimised calling convention >> and optional, discoverable support for mitigating

Re: [Xen-devel] [PATCH v2] tools/xenstore: try to get minimum thread stack size for watch thread

On Mon, Feb 26, 2018 at 09:46:12AM +0100, Juergen Gross wrote: > When creating a pthread in xs_watch() try to get the minimal needed > size of the thread from glibc instead of using a constant. This avoids > problems when the library is used in programs with large per-thread > memory. > > Use

Re: [Xen-devel] [RFC PATCH 38/49] ARM: new VGIC: handle hardware mapped IRQs

Hi, On 26/02/18 16:57, Julien Grall wrote: > > > On 02/26/2018 04:48 PM, Andre Przywara wrote: >> Hi, >> >> On 23/02/18 18:14, Julien Grall wrote: >>> >>> >>> On 23/02/18 18:02, Andre Przywara wrote: Hi, >>> >>> Hi Andre, >>> On 19/02/18 12:19, Julien Grall wrote: > Hi, >

Re: [Xen-devel] [PATCH] common/gnttab: Introduce command line feature controls

On 05/02/18 13:14, George Dunlap wrote: > On 02/05/2018 12:56 PM, Jan Beulich wrote: > On 05.02.18 at 12:55, wrote: >>> On 02/02/18 08:51, Jan Beulich wrote: >>> On 01.02.18 at 15:38, wrote: > ---

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

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 in libvirt, channel devices included. This works well when only one channel device is

Re: [Xen-devel] [PATCH 2/2] xen: events: free irqs in error condition

On Mo, 2018-02-26 at 18:14 +, Roger Pau Monné wrote: > On Mon, Feb 26, 2018 at 05:36:35PM +, Amit Shah wrote: > > > > In case of errors in irq setup for MSI, free up the allocated irqs. > > > > Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups") > > Reported-by: Hooman

Re: [Xen-devel] [RFC PATCH 0/5] x86: Multiple fixes to MSR_TSC_AUX and RDTSCP handling for guests

On 02/26/2018 02:12 PM, Andrew Cooper wrote: > On 20/02/18 11:58, Andrew Cooper wrote: >> This rats nest was discovered when finding that MSR_TSC_AUX leaked into PV >> guests. It is RFC because I haven't done extensive testing on the result, >> and >> because there are some functional changes

Re: [Xen-devel] [PATCH 3/6] x86: Handle the Xen MSRs via the new guest_{rd, wr}msr() infrastructure

On 02/26/2018 12:35 PM, Andrew Cooper wrote: > Dispatch from the guest_{rd,wr}msr() functions, after falling through from the > !is_viridian_domain() case. > > Rename {rd,wr}msr_hypervisor_regs() to guest_{rd,wr}msr_xen() for consistency, > and because the _regs suffix isn't very appropriate. > >

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

flight 120010 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/120010/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 17 guest-localmigrate/x10 fail REGR. vs. 119432

Re: [Xen-devel] [PATCH v8 07/11] vpci/bars: add handlers to map the BARs

On Mon, Feb 26, 2018 at 04:20:17AM -0700, Jan Beulich wrote: > (re-sending with xen-devel re-added; not sure how it got lost) > > >>> On 23.01.18 at 16:07, wrote: > > --- > > tools/tests/vpci/emul.h | 1 + > > xen/arch/x86/hvm/ioreq.c | 4 + > > Again the Cc to Paul

Re: [Xen-devel] [PATCH 2/5] x86/pv: Avoid leaking other guests' MSR_TSC_AUX values into PV context

On 02/20/2018 06:58 AM, Andrew Cooper wrote: > If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the value in > MSR_TSC_AUX, irrespective of whether the relevant CPUID features are > advertised/hidden. > > At the moment, paravirt_ctxt_switch_to() only writes to MSR_TSC_AUX if >

Re: [Xen-devel] [PATCH 2/2] xen: events: free irqs in error condition

On Mon, Feb 26, 2018 at 05:36:35PM +, Amit Shah wrote: > In case of errors in irq setup for MSI, free up the allocated irqs. > > Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups") > Reported-by: Hooman Mirhadi > CC: > CC: Roger Pau

[Xen-devel] [ping] Re: [PATCH 2/5] x86/pv: Avoid leaking other guests' MSR_TSC_AUX values into PV context

On 26/02/18 11:25, Jan Beulich wrote: On 20.02.18 at 12:58, wrote: >> If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the value >> in >> MSR_TSC_AUX, irrespective of whether the relevant CPUID features are >> advertised/hidden. >> >> At the

Re: [Xen-devel] [PATCH 2/6] x86/hvm: Handle viridian MSRs via the new guest_{rd, wr}msr() infrastructure

On 02/26/2018 12:35 PM, Andrew Cooper wrote: > Dispatch from the guest_{rd,wr}msr() functions, after confirming that the > domain is configured to use viridian. This allows for simplifiction of the > viridian helpers as they don't need to cope with the "not a viridian MSR" > case. It also means

Re: [Xen-devel] [RFC PATCH 0/5] x86: Multiple fixes to MSR_TSC_AUX and RDTSCP handling for guests

On 20/02/18 11:58, Andrew Cooper wrote: > This rats nest was discovered when finding that MSR_TSC_AUX leaked into PV > guests. It is RFC because I haven't done extensive testing on the result, and > because there are some functional changes for the virtualised TSC modes. > > Andrew Cooper (5): >

[Xen-devel] [PATCH 0/6] x86: Switch some bits of MSR handing over to the new infrastructure

Various changes to MSR handling which don't impact the MSR policy objects themselves. See individual patches for details. Andrew Cooper (6): x86/vmx: Simplfy the default cases in vmx_msr_{read,write}_intercept() x86/hvm: Handle viridian MSRs via the new guest_{rd,wr}msr() infrastructure

[Xen-devel] [PATCH 6/6] x86/msr: Blacklist various MSRs which guests definitely shouldn't be using

The main purpose is to blacklist the Intel Resource Director Technology MSRs. We do not yet virtualise support for guests, but Linux has been observed to probe for these MSRs without checking CPUID first. The architecturally inaccessable ranges don't need to fall back into the legacy ranges,

[Xen-devel] [PATCH 2/6] x86/hvm: Handle viridian MSRs via the new guest_{rd, wr}msr() infrastructure

Dispatch from the guest_{rd,wr}msr() functions, after confirming that the domain is configured to use viridian. This allows for simplifiction of the viridian helpers as they don't need to cope with the "not a viridian MSR" case. It also means that viridian MSRs which are unimplemented, or

[Xen-devel] [PATCH 4/6] x86/hvm: Constify the read side of vlapic handling

This is in preparation to make hvm_x2apic_msr_read() take a const vcpu pointer. One modification is to alter vlapic_get_tmcct() to not use current. This in turn needs an alteration to hvm_get_guest_time_fixed(), which is safe because the only mutable action it makes is to take the domain plt

Re: [Xen-devel] [PATCH] x86/link: Don't merge .init.text and .init.data

On 12/01/18 16:05, Jan Beulich wrote: On 12.01.18 at 16:41, wrote: >> On 12/01/18 11:23, Jan Beulich wrote: >>> Even it you make .init.data its own section again, some >>> garbage will remain (mainly due to the trampoline data). >> That is far easier to spot an

[Xen-devel] [PATCH 3/6] x86: Handle the Xen MSRs via the new guest_{rd, wr}msr() infrastructure

Dispatch from the guest_{rd,wr}msr() functions, after falling through from the !is_viridian_domain() case. Rename {rd,wr}msr_hypervisor_regs() to guest_{rd,wr}msr_xen() for consistency, and because the _regs suffix isn't very appropriate. Update them to take a vcpu pointer rather than presuming

[Xen-devel] [PATCH 1/6] x86/vmx: Simplfy the default cases in vmx_msr_{read, write}_intercept()

The default case of vmx_msr_write_intercept() in particular is very tangled. First of all, fold long_mode_do_msr_{read,write}() into their callers. These functions were split out in the past because of the 32bit build of Xen, but it is unclear why the cases weren't simply #ifdef'd in place.

Re: [Xen-devel] [PATCH] x86/pv: Rename pv/ro-page-fault.c to pv/emul-ro-page-fault.c

On 05/02/18 13:01, Jan Beulich wrote: On 05.02.18 at 13:22, wrote: >> On 05/02/18 08:57, Jan Beulich wrote: >> On 02.02.18 at 17:58, wrote: To match all our other emulation handling. No functional change.

Re: [Xen-devel] [PATCH 1/2] xen: fix out-of-bounds irq unbind for MSI message groups

On 02/26/2018 12:36 PM, Amit Shah wrote: > When an MSI descriptor was not available, the error path would try to > unbind an irq that was never acquired - potentially unbinding an > unrelated irq. > > Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups") > Reported-by: Hooman Mirhadi

Re: [Xen-devel] [RFC PATCH 38/49] ARM: new VGIC: handle hardware mapped IRQs

Hi, On 02/26/2018 05:19 PM, Andre Przywara wrote: Hi, On 26/02/18 16:57, Julien Grall wrote: On 02/26/2018 04:48 PM, Andre Przywara wrote: Hi, On 23/02/18 18:14, Julien Grall wrote: On 23/02/18 18:02, Andre Przywara wrote: Hi, Hi Andre, On 19/02/18 12:19, Julien Grall wrote: Hi,

Re: [Xen-devel] [RFC PATCH 44/49] ARM: new VGIC: vgic-init: register VGIC

Hi, On 19/02/18 12:39, Julien Grall wrote: > Hi Andre, > > On 09/02/18 14:39, Andre Przywara wrote: >> This patch implements the function which is called by Xen when it wants >> to register the virtual GIC. >> >> Signed-off-by: Andre Przywara >> --- >>  

Re: [Xen-devel] [PATCH] xen: use hvc console for dom0

On 02/26/2018 06:08 AM, Juergen Gross wrote: > Today the hvc console is added as a preferred console for pv domUs > only. As this requires a boot parameter for getting dom0 messages per > default add it for dom0, too. > > Signed-off-by: Juergen Gross > --- >

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

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

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

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

Re: [Xen-devel] [v2 1/1] xen, mm: Allow deferred page initialization for xen pv domains

* Pavel Tatashin wrote: > Juergen Gross noticed that commit > f7f99100d8d ("mm: stop zeroing memory during allocation in vmemmap") > broke XEN PV domains when deferred struct page initialization is enabled. > > This is because the xen's PagePinned() flag is getting

Re: [Xen-devel] [v2 1/1] xen, mm: Allow deferred page initialization for xen pv domains

On 26/02/18 17:01, Pavel Tatashin wrote: > Juergen Gross noticed that commit > f7f99100d8d ("mm: stop zeroing memory during allocation in vmemmap") > broke XEN PV domains when deferred struct page initialization is enabled. > > This is because the xen's PagePinned() flag is getting erased from

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

flight 120025 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/120025/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken in 119952 build-armhf-pvops

[Xen-devel] Error while booting android kernel 4.4 on jacinto j6 evm as DOM0

Hi, I am trying to boot kernel 4.4 on Jacinto-6 EVM board, I am facing error from xen. Please find attached log to find errors. The kernel is stuck at [6.881378] Waiting for root device /dev/mmcblk0p2... Is it due to i2c related errors in boot log as mentioned below? [0.831911] palmas

Re: [Xen-devel] [PATCH 1/2] x86/ACPI: Parse ACPI_FADT_LEGACY_DEVICES

On Tue, Feb 27, 2018 at 11:47:45AM +0530, Anshuman Gupta wrote: > From: "Luis R. Rodriguez" > Anshuman, looks like you sent this by mistake. Please, be careful! Everyone, kindly ignore this patch. > ACPI 5.2.9.3 IA-PC Boot Architecture flag ACPI_FADT_LEGACY_DEVICES > can be

[Xen-devel] [PATCH 1/2] x86/ACPI: Parse ACPI_FADT_LEGACY_DEVICES

From: "Luis R. Rodriguez" ACPI 5.2.9.3 IA-PC Boot Architecture flag ACPI_FADT_LEGACY_DEVICES can be used to determine if a system has legacy devices LPC or ISA devices. The x86 platform already has a struct which lists known associated legacy devices, we start off careful only

Re: [Xen-devel] [PATCH 8/9] drm/xen-front: Implement GEM operations

On 02/27/2018 01:47 AM, Boris Ostrovsky wrote: On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote: On 02/23/2018 05:26 PM, Boris Ostrovsky wrote: On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote: +static struct xen_gem_object *gem_create(struct drm_device *dev, size_t size) +{ +

Re: [Xen-devel] [PATCH 3/6] x86: Handle the Xen MSRs via the new guest_{rd, wr}msr() infrastructure

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Tuesday, February 27, 2018 1:35 AM > > Dispatch from the guest_{rd,wr}msr() functions, after falling through from > the > !is_viridian_domain() case. > > Rename {rd,wr}msr_hypervisor_regs() to guest_{rd,wr}msr_xen() for >

Re: [Xen-devel] [PATCH 2/6] x86/hvm: Handle viridian MSRs via the new guest_{rd, wr}msr() infrastructure

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Tuesday, February 27, 2018 1:35 AM > > Dispatch from the guest_{rd,wr}msr() functions, after confirming that the > domain is configured to use viridian. This allows for simplifiction of the > viridian helpers as they don't need to

Re: [Xen-devel] [PATCH 8/9] drm/xen-front: Implement GEM operations

On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote: > On 02/23/2018 05:26 PM, Boris Ostrovsky wrote: >> On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote: >>> +static struct xen_gem_object *gem_create(struct drm_device *dev, >>> size_t size) >>> +{ >>> +struct xen_drm_front_drm_info

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

flight 120051 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120051/ 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 5/7] public / x86: introduce __HYPERCALL_iommu_op

> -Original Message- > From: Tian, Kevin [mailto:kevin.t...@intel.com] > Sent: 24 February 2018 02:57 > To: Paul Durrant ; xen-devel@lists.xenproject.org > Cc: Stefano Stabellini ; Wei Liu > ; George Dunlap

Re: [Xen-devel] libxl - avoid calling block script

On Fri, Feb 23, 2018 at 09:14:03PM +0100, Marek Marczykowski-Górecki wrote: > On Fri, Feb 23, 2018 at 06:28:56PM +, Wei Liu wrote: > > On Fri, Feb 09, 2018 at 12:35:13PM +0100, Marek Marczykowski-Górecki wrote: > > > On Fri, Feb 09, 2018 at 11:03:55AM +, Roger Pau Monné wrote: > > > >

Re: [Xen-devel] [PATCH v3 2/2] vmx/hap: optimize CR4 trapping

On Sat, Feb 24, 2018 at 01:47:37AM +, Tian, Kevin wrote: > > From: Roger Pau Monné [mailto:roger@citrix.com] > > Sent: Friday, February 23, 2018 6:18 PM > > > > On Fri, Feb 23, 2018 at 04:56:38AM +, Tian, Kevin wrote: > > > > From: Roger Pau Monne [mailto:roger@citrix.com] > > > >

Re: [Xen-devel] [PATCH v2] tools/xenstore: try to get minimum thread stack size for watch thread

On Mon, Feb 26, 2018 at 09:46:12AM +0100, Juergen Gross wrote: > When creating a pthread in xs_watch() try to get the minimal needed > size of the thread from glibc instead of using a constant. This avoids > problems when the library is used in programs with large per-thread > memory. > > Use

Re: [Xen-devel] [RFC PATCH 02/10] arm64: Add hook to handle guest GICv3 sysreg accesses

Hi Manish, On 26/02/18 06:42, Manish Jaggi wrote: On 02/01/2018 04:24 PM, Julien Grall wrote: Hi Manish, On 01/02/18 08:51, Manish Jaggi wrote: On 01/25/2018 11:37 PM, Julien Grall wrote: Hi, I forgot to mention one thing about the placement of do_fixup_vgic_errata. On 16/01/18 15:42,

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

Hi, On 21/02/18 21:46, Wei Liu wrote: Move the functions that reference x86 hvm data structures to its own file. Rename pci_clean_dpci_irqs to arch_pci_clean_irqs. NIT: Double space. There is still one location in that file which references arch.hvm_domain, but it is fine because ARM

Re: [Xen-devel] [PATCH v6] x86/clang: allow integrated assembler usage

On 23/02/18 14:11, Roger Pau Monne wrote: > If the required features are present. > > Modify as-option-add to add an option in case the test fails, and use > it to detect whether the required clang integrated assembler features > are present. > > This patch has been tested with clang 3.5, clang 6,

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

On 22/02/18 21:38, x...@randomwebstuff.com wrote: > > On 22/02/18 6:35 PM, Juergen Gross wrote: >> 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

Re: [Xen-devel] [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op

> From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: Monday, February 26, 2018 5:57 PM > > > -Original Message- > > From: Tian, Kevin [mailto:kevin.t...@intel.com] > > Sent: 24 February 2018 02:57 > > To: Paul Durrant ; xen- > de...@lists.xenproject.org >

[Xen-devel] [PATCH v4] vmx/hap: optimize CR4 trapping

There a bunch of bits in CR4 that should be allowed to be set directly by the guest without requiring Xen intervention, currently this is already done by passing through guest writes into the CR4 used when running in non-root mode, but taking an expensive vmexit in order to do so. xenalyze

Re: [Xen-devel] [PATCH v2] tools/xenstore: try to get minimum thread stack size for watch thread

On Mon, Feb 26, 2018 at 09:46:01AM +, Roger Pau Monné wrote: > > > > if (pthread_attr_init() != 0) { > > mutex_unlock(>request_mutex); > > return false; > > } > > - if (pthread_attr_setstacksize(,

Re: [Xen-devel] [PATCH] x86/PV: fix off-by-one in I/O bitmap limit check

>>> On 26.02.18 at 11:44, wrote: > On Mon, Feb 26, 2018 at 12:38:11AM -0700, Jan Beulich wrote: >> Signed-off-by: Jan Beulich > > Reviewed-by: Roger Pau Monné Thanks. > I would however invert the check, my brain finds it easier

Re: [Xen-devel] (partial) Spectre v2 mitigation without on Skylake IBRS

>>> On 26.02.18 at 11:18, wrote: > On 26/02/18 10:44, Jan Beulich wrote: >> if running PV Linux on older Xen (4.5 and earlier) is relevant, it may be >> necessary to use a mechanism other than IBRS to mitigate Spectre v2 >> on Skylake. That is because the new MSR value can't be

[Xen-devel] [PATCH] xen: use hvc console for dom0

Today the hvc console is added as a preferred console for pv domUs only. As this requires a boot parameter for getting dom0 messages per default add it for dom0, too. Signed-off-by: Juergen Gross --- arch/x86/xen/enlighten_pv.c | 4 +++- 1 file changed, 3 insertions(+), 1

Re: [Xen-devel] [PATCH v4] vmx/hap: optimize CR4 trapping

> From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: Monday, February 26, 2018 6:05 PM > > There a bunch of bits in CR4 that should be allowed to be set directly > by the guest without requiring Xen intervention, currently this is > already done by passing through guest writes into the

Re: [Xen-devel] (partial) Spectre v2 mitigation without on Skylake IBRS

On 26/02/18 10:44, Jan Beulich wrote: > All, > > if running PV Linux on older Xen (4.5 and earlier) is relevant, it may be > necessary to use a mechanism other than IBRS to mitigate Spectre v2 > on Skylake. That is because the new MSR value can't be migrated > prior to migration v2. Of course one

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

flight 120009 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/120009/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 119227

Re: [Xen-devel] [PATCH v2] libxl: do not fail device removal if backend domain is gone

On Fri, Feb 23, 2018 at 09:00:41PM +0100, Marek Marczykowski-Górecki wrote: > Backend domain may be independently destroyed - there is no > synchronization of libxl structures (including /libxl tree) elsewhere. > Backend might also remove the device info from its backend xenstore > subtree on its

Re: [Xen-devel] [RFC PATCH 30/49] ARM: new VGIC: Add ENABLE registers handlers

Hi Andre, On 23/02/18 15:18, Andre Przywara wrote: +    irq_desc_t *desc; +    int i; +    unsigned long flags; +    enum vgic_irq_config config; + +    for_each_set_bit( i, , len * 8 ) +    { +    struct vgic_irq *irq; + +    irq = vgic_get_irq(vcpu->domain, vcpu, intid + i); + +   

Re: [Xen-devel] [PATCH v8 07/11] vpci/bars: add handlers to map the BARs

(re-sending with xen-devel re-added; not sure how it got lost) >>> On 23.01.18 at 16:07, wrote: > --- > tools/tests/vpci/emul.h | 1 + > xen/arch/x86/hvm/ioreq.c | 4 + Again the Cc to Paul is missing (no matter that it's just a tiny change). > +static int

Re: [Xen-devel] ACPI / ioremap() crash

>>> On 26.02.18 at 10:32, wrote: > On 26/02/18 10:05, Jan Beulich wrote: >> Boris, Jürgen, >> >> now for the actual crash: >> >> ACPI: Core revision 20170831 >> BUG: unable to handle kernel paging request at 8801d8c09050 >> IP: xen_set_pmd+0x3a/0x50 >> PGD 1c0a067 P4D

Re: [Xen-devel] [PATCH] libxl: add libxl__is_driver_domain function

On Fri, Feb 23, 2018 at 7:44 PM, Wei Liu wrote: > On Tue, Feb 13, 2018 at 03:32:04PM +0200, Oleksandr Grytsov wrote: > > On Tue, Feb 13, 2018 at 2:06 PM, Wei Liu wrote: > > > > > On Tue, Feb 06, 2018 at 03:08:45PM +0200, Oleksandr Grytsov wrote: > > > >

Re: [Xen-devel] ARM64:Porting xen to new hardware

Hi, What I meant by using '>' for quoting is all my reply should be prefixed with '>'. You write your reply normally. You can do that in gmail by switching the e-mail from HTML to plain text. On 26/02/18 07:31, bharat gohil wrote: On Thu, Feb 22, 2018 at 4:57 PM, Julien Grall

Re: [Xen-devel] [PATCH v2] fuzz/x86_emulate: fix bounds for input size

On Fri, Feb 23, 2018 at 11:48:57PM +0100, Paul Semel wrote: > The maximum size for the input size was set to INPUT_SIZE, which is actually > the size of the data array inside the fuzz_corpus structure and so was not > abling user (or AFL) to fill in the whole structure. Changing to > sizeof(struct

Re: [Xen-devel] [PATCH v6] x86/clang: allow integrated assembler usage

>>> On 23.02.18 at 15:11, wrote: > If the required features are present. > > Modify as-option-add to add an option in case the test fails, and use > it to detect whether the required clang integrated assembler features > are present. > > This patch has been tested with

Re: [Xen-devel] [PATCH v6] x86/clang: allow integrated assembler usage

On Fri, Feb 23, 2018 at 02:11:00PM +, Roger Pau Monne wrote: > If the required features are present. > > Modify as-option-add to add an option in case the test fails, and use > it to detect whether the required clang integrated assembler features > are present. > > This patch has been tested

[Xen-devel] [PATCH v2] x86/build: Use new .nop directive when available

Newer versions of binutils are capable of emitting an exact number bytes worth of optimised nops. Use this in preference to .skip when available. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Konrad Rzeszutek Wilk

[Xen-devel] [PATCH v2] x86/asm: Remove opencoded uses of altinstruction_entry

With future changes, altinstruction_entry is going to become more complicated to use. Furthermore, there are already ALTERNATIVE* macros which can be used to avoid opencoding the creation of replacement information. For ASM_STAC, ASM_CLAC and CR4_PV32_RESTORE, this means the removal of all

[Xen-devel] [PATCH v2] x86/alternatives: Support for automatic padding calculations

This is the end result of a lot of work I started during the Spectre/Meltdown embargo window, and deferred because it was taking too long. It finally resolves the explict padding calculations for the SPEC_CTRL alternatives. This series depends on Roger's "x86/clang: allow integrated assembler

Re: [Xen-devel] [PATCH 2/5] x86/pv: Avoid leaking other guests' MSR_TSC_AUX values into PV context

>>> On 20.02.18 at 12:58, wrote: > If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the value in > MSR_TSC_AUX, irrespective of whether the relevant CPUID features are > advertised/hidden. > > At the moment, paravirt_ctxt_switch_to() only writes to

[Xen-devel] [PATCH v2] x86/alt: Support for automatic padding calculations

The correct amount of padding in an origin patch site can be calculated automatically, based on the relative lengths of the replacements. This requires a bit of trickery to calculate correctly, especially in the ALTENRATIVE_2 case where a branchless max() calculation in needed. The calculation

[Xen-devel] [PATCH v2 3/7] x86/alt: Clean up the assembly used to generate alternatives

* On the C side, switch to using local lables rather than hardcoded numbers. * Rename parameters and lables to be consistent with alt_instr names, and consistent between the the C and asm versions. * On the asm side, factor some expressions out into macros to aid clarity. * Consistently

[Xen-devel] [PATCH v2 7/7] x86/build: Use new .nop directive when available

Newer versions of binutils are capable of emitting an exact number bytes worth of optimised nops. Use this in preference to .skip when available. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Konrad Rzeszutek Wilk

[Xen-devel] [PATCH v2 5/7] x86/alt: Support for automatic padding calculations

The correct amount of padding in an origin patch site can be calculated automatically, based on the relative lengths of the replacements. This requires a bit of trickery to calculate correctly, especially in the ALTENRATIVE_2 case where a branchless max() calculation in needed. The calculation

[Xen-devel] [PATCH v2 6/7] x86/alt: Drop explicit padding of origin sites

Now that the alternatives infrastructure can calculate the required padding automatically, there is no need to hard code it. Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu Reviewed-by: Roger Pau Monné Reviewed-by: Jan

Re: [Xen-devel] [PATCH v2] libxl: do not fail device removal if backend domain is gone

On Fri, Feb 23, 2018 at 09:00:41PM +0100, Marek Marczykowski-Górecki wrote: > Backend domain may be independently destroyed - there is no > synchronization of libxl structures (including /libxl tree) elsewhere. > Backend might also remove the device info from its backend xenstore > subtree on its

Re: [Xen-devel] [PATCH] x86/PV: fix off-by-one in I/O bitmap limit check

On Mon, Feb 26, 2018 at 12:38:11AM -0700, Jan Beulich wrote: > Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné I would however invert the check, my brain finds it easier to read as: (port + bytes) <= v->arch.pv_vcpu.iobmp_limit Thanks, Roger.

Re: [Xen-devel] [PATCH] x86/PV: fix off-by-one in I/O bitmap limit check

On 26/02/18 10:50, Jan Beulich wrote: On 26.02.18 at 11:44, wrote: >> On Mon, Feb 26, 2018 at 12:38:11AM -0700, Jan Beulich wrote: >>> Signed-off-by: Jan Beulich >> Reviewed-by: Roger Pau Monné > Thanks. > >> I would however

[Xen-devel] [PATCH v2] x86/alt: Clean up the assembly used to generate alternatives

* On the C side, switch to using local lables rather than hardcoded numbers. * Rename parameters and lables to be consistent with alt_instr names, and consistent between the the C and asm versions. * On the asm side, factor some expressions out into macros to aid clarity. * Consistently

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

* 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 Reviewed-by: Wei Liu Reviewed-by: Roger Pau Monné

[Xen-devel] [PATCH v2] x86/alt: Drop explicit padding of origin sites

Now that the alternatives infrastructure can calculate the required padding automatically, there is no need to hard code it. Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu Reviewed-by: Roger Pau Monné Reviewed-by: Jan

[Xen-devel] [PATCH v2] x86/alt: Drop unused alternative infrastructure

ALTERNATIVE_3 is more complicated than ALTERNATIVE_2 when it comes to calculating extra padding length, and we have no need for the complexity. Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu Reviewed-by: Roger Pau Monné

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

>>> On 23.02.18 at 16:51, wrote: > On 23/02/18 15:05, Jan Beulich wrote: > On 21.02.18 at 12:36, wrote: >>> --- a/xen/arch/x86/msr.c >>> +++ b/xen/arch/x86/msr.c >>> @@ -175,6 +175,13 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr,

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

* 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 Reviewed-by: Wei Liu Reviewed-by: Roger Pau Monné

[Xen-devel] [PATCH RESEND v2 0/7] x86/alternatives: Support for automatic padding calculations

[ Resend properly numbered this time. ] This is the end result of a lot of work I started during the Spectre/Meltdown embargo window, and deferred because it was taking too long. It finally resolves the explict padding calculations for the SPEC_CTRL alternatives. This series depends on Roger's

[Xen-devel] [PATCH v2 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

With future changes, altinstruction_entry is going to become more complicated to use. Furthermore, there are already ALTERNATIVE* macros which can be used to avoid opencoding the creation of replacement information. For ASM_STAC, ASM_CLAC and CR4_PV32_RESTORE, this means the removal of all

  1   2   >