[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 test-amd64

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. > >> xen/arch/x86/mm/mem_access.c | 27

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 Xen-devel@lists.xenproject.org https://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 be

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 a/xen/include/public/hvm/hvm_info_table.h > b/xen/

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: >>> >>> "The ACPI interfa

[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 linkag

[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 nativ

[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: 0003

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 ; > Andrew Cooper ; Ian Jackson > ; Tim (Xen.org) ; Jan Beulich > > Subject: RE: [X

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: > - Fold the fixup! patch which re-orde

[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 ne

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 CV

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 dlsy

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 1c0a067 PUD 1de2067 PMD

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 ; > Andrew Cooper ; Ian Jackson > ; Tim (Xen.org) ; Jan Beulich > ; Daniel De Graaf

[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 reports

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: > > > > Reall

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] 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: > > > > On Tue, Feb 6, 2018 at 2:36 PM, Wei Liu w

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

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

[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 test-armhf-armh

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 o

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 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 o

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(&attr) != 0) { > > mutex_unlock(&h->request_mutex); > > return false; > > } > > - if (pthread_attr_setstacksize(&attr, READ_THRE

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 dlsy

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] 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] (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 migrated >> prior t

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 to read > as: > > (port + bytes) <= v->arch.pv_vcpu.iobmp_limit

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 guest

[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 deletion(-) diff --git

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 invert the check, my brain finds it easier to read >> as: >> >> (p

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] [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 map_range(unsigned long s, unsi

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, &val, len * 8 ) +    { +    struct vgic_irq *irq; + +    irq = vgic_get_irq(vcpu->domain, vcpu, intid + i); + +   

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 clang 3.5, clang 6, gcc 6.

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/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 Beulich --- xen/arch/x86/x86_64/compat/entry.S | 2 +- xen/arch/x86/x8

[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é Reviewed-by: Jan Beulich --- v2: * Retain ASM_OUTPUT2() --- xen/inclu

[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 decl

[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é Reviewed-by: Jan Beulich Reviewed-by: Konrad Rzeszutek Wilk ---

[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 usa

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 MSR_TSC_AUX if > TSC_MODE_PVRDT

[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 is

[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 CC: Roger Pau Monné CC: Wei Liu RFC until support is actually committe

[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 hardoc

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, >>> uint64_t *val) >>> _MSR_MISC_FEAT

[Xen-devel] [PATCH v2 1/7] 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é Reviewed-by: Jan Beulich --- v2: * Retain ASM_OUTPUT2() --- xen/inclu

[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 hardoc

[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é Reviewed-by: Jan Beulich Reviewed-by: Konrad Rzeszutek Wilk ---

[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 decl

[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 Beulich --- xen/arch/x86/x86_64/compat/entry.S | 2 +- xen/arch/x86/x8

[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 CC: Roger Pau Monné CC: Wei Liu RFC until support is actually committe

[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 is

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 o

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 > > Cc: Stefano Stabellini

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 CR

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

Marek Marczykowski-Górecki writes ("Re: [Xen-devel] libxl - avoid calling block script"): > On Fri, Feb 09, 2018 at 11:03:55AM +, Roger Pau Monné wrote: > > Really adding Ian and Wei. > > > > On Fri, Feb 09, 2018 at 10:55:24AM +, Roger Pau Monné wrote: > > > So the problem is creation tim

Re: [Xen-devel] RTDS with extra time issue

Hello Dario, On 22.02.18 19:53, Dario Faggioli wrote: As I said already, improving the accounting would be more than welcome. If you're planning on doing something like this already, I'll be happy to look at the patches. :-) First I have to document my findings and make some conclusions about a

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

Wei Liu writes ("Re: [Xen-devel] [PATCH v2] tools/xenstore: try to get minimum thread stack size for watch thread"): > I don't think FreeBSD needs this particular workaround for glibc FWIW. Indeed. Err, I guess we should have a configure test of some kind then ? The patch looks good. Ian. ___

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

On Mon, Feb 26, 2018 at 12:03:29PM +, Ian Jackson wrote: > Wei Liu writes ("Re: [Xen-devel] [PATCH v2] tools/xenstore: try to get > minimum thread stack size for watch thread"): > > I don't think FreeBSD needs this particular workaround for glibc FWIW. > > Indeed. > > Err, I guess we should

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

Hello Juergen, On 26.02.18 13:08, 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 --- arch/x86/xen/enlighten_pv.c | 4 +++-

Re: [Xen-devel] [PATCH v4 5/7] libxl: support unmapping static shared memory areas during domain destruction

Wei Liu writes ("Re: [Xen-devel] [PATCH v4 5/7] libxl: support unmapping static shared memory areas during domain destruction"): > On Mon, Feb 12, 2018 at 03:24:26PM +, Julien Grall wrote: > > In any case, the worst that could happen is the unmap is called twice on the > > same region. So you

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

Wei Liu writes ("Re: [Xen-devel] [PATCH v2] tools/xenstore: try to get minimum thread stack size for watch thread"): > It is already enclosed in CONFIG_Linux. I think that should be enough. Oh, I see. I had read USE_DLSYM as CONFIG_DLSYM, ie "dlsym is available". A better name might be USE_DLSY

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

On Mon, Feb 26, 2018 at 11:24:55AM +, Andrew Cooper wrote: > 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

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

On Mon, Feb 26, 2018 at 11:35:04AM +, Andrew Cooper wrote: > 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 Wi

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

On 26/02/18 13:06, Andrii Anisov wrote: > Hello Juergen, > > > On 26.02.18 13:08, 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-b

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

On 26/02/18 11:49, Jan Beulich wrote: 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

Re: [Xen-devel] [PATCH RFC 1/3] x86/vpt: execute callbacks for masked interrupts

On Fri, Feb 23, 2018 at 01:27:41PM +, Roger Pau Monne wrote: > Execute periodic_time callbacks even if the interrupt is not actually > injected because the IRQ is masked. > > Current callbacks from emulated timer devices only update emulated > registers, which from my reading of the specs shou

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

On Sat, Feb 24, 2018 at 03:23:48AM +, Tian, Kevin wrote: > > From: Wei Liu [mailto:wei.l...@citrix.com] > > Sent: Saturday, February 24, 2018 12:08 AM > > > > On Fri, Feb 23, 2018 at 05:12:05AM +, Tian, Kevin wrote: > > > > From: Wei Liu > > > > Sent: Thursday, February 22, 2018 5:47 AM >

Re: [Xen-devel] [PATCH RFC 1/3] x86/vpt: execute callbacks for masked interrupts

On Mon, Feb 26, 2018 at 12:35:54PM +, Wei Liu wrote: > On Fri, Feb 23, 2018 at 01:27:41PM +, Roger Pau Monne wrote: > > Execute periodic_time callbacks even if the interrupt is not actually > > injected because the IRQ is masked. > > > > Current callbacks from emulated timer devices only u

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

On Mon, Feb 26, 2018 at 01:47:38AM +0100, Marek Marczykowski-Górecki wrote: > On Fri, Feb 23, 2018 at 10:39:20PM -0600, Doug Goldstein wrote: > > On 2/22/18 11:12 PM, Tian, Kevin wrote: > > >> From: Wei Liu > > >> Sent: Thursday, February 22, 2018 5:47 AM > > >> > > >> Hi all > > >> > > >> At some

Re: [Xen-devel] [PATCH RFC 1/3] x86/vpt: execute callbacks for masked interrupts

>>> On 26.02.18 at 13:48, wrote: > On Mon, Feb 26, 2018 at 12:35:54PM +, Wei Liu wrote: >> On Fri, Feb 23, 2018 at 01:27:41PM +, Roger Pau Monne wrote: >> > int pt_update_irq(struct vcpu *v) >> > { >> > struct list_head *head = &v->arch.hvm_vcpu.tm_list; >> > +LIST_HEAD(purged);

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

On 26/02/18 12:31, Roger Pau Monné wrote: > On Mon, Feb 26, 2018 at 11:35:04AM +, Andrew Cooper wrote: >> 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

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

On Mon, Feb 26, 2018 at 3:51 PM, Julien Grall wrote: > 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. > Ok. Got it. > On 26/02/18 07:31, bharat

[Xen-devel] [xen-unstable test] 120001: tolerable FAIL - PUSHED

flight 120001 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/120001/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 119713 test-amd64-amd64-xl-qemut-win7-amd64

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

>>> On 26.02.18 at 13:36, wrote: > On 26/02/18 11:49, Jan Beulich wrote: > On 26.02.18 at 11:18, wrote: >>> If this is the case I believe the easiest solution would be to let the >>> kernel set the MSR again after leaving suspended state. suspend/resume >>> require hooks in pv kernels after a

Re: [Xen-devel] [PATCH v2] x86/HVM: don't give the wrong impression of WRMSR succeeding

On 23/02/18 08:36, Jan Beulich wrote: > ... for non-existent MSRs: wrmsr_hypervisor_regs()'s comment clearly > says that the function returns 0 for unrecognized MSRs, so > {svm,vmx}_msr_write_intercept() should not convert this into success. We > don't want to unconditionally fail the access though

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

On Mon, Feb 26, 2018 at 01:28:07AM -0700, Jan Beulich wrote: 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 Softwa

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

Hi Juergen, Thank you for taking a look at this patch, I will address your comments, and send out an updated patch. >> extern void default_banner(void); >> >> +static inline void paravirt_after_bootmem(void) >> +{ >> + pv_init_ops.after_bootmem(); >> +} >> + > > Putting this in the paravirt

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

On 26/02/18 14:11, Jan Beulich wrote: On 26.02.18 at 13:36, wrote: >> On 26/02/18 11:49, Jan Beulich wrote: >> On 26.02.18 at 11:18, wrote: If this is the case I believe the easiest solution would be to let the kernel set the MSR again after leaving suspended state. suspend/res

[Xen-devel] [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

Older Xen versions (4.5 and before) might have problems migrating pv guests with MSR_IA32_SPEC_CTRL having a non-zero value. So before suspending zero that MSR and restore it after being resumed. Cc: sta...@vger.kernel.org Signed-off-by: Juergen Gross --- arch/x86/xen/suspend.c | 16

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

On Mon, Feb 26, 2018 at 11:35:00AM +, Andrew Cooper wrote: > * 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, facto

Re: [Xen-devel] [PATCH RFC 1/3] x86/vpt: execute callbacks for masked interrupts

On Mon, Feb 26, 2018 at 06:04:51AM -0700, Jan Beulich wrote: > >>> On 26.02.18 at 13:48, wrote: > > On Mon, Feb 26, 2018 at 12:35:54PM +, Wei Liu wrote: > >> On Fri, Feb 23, 2018 at 01:27:41PM +, Roger Pau Monne wrote: > >> > int pt_update_irq(struct vcpu *v) > >> > { > >> > struct

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

On Mon, Feb 26, 2018 at 01:26:42AM -0700, Jan Beulich wrote: 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(-) >>

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

On Mon, Feb 26, 2018 at 08:33:23PM +0800, Chao Gao wrote: > On Mon, Feb 26, 2018 at 01:28:07AM -0700, Jan Beulich wrote: > 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: > I

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

On Mon, Feb 26, 2018 at 01:08:05PM +, Andrew Cooper wrote: > On 26/02/18 12:31, Roger Pau Monné wrote: > > On Mon, Feb 26, 2018 at 11:35:04AM +, Andrew Cooper wrote: > >> Newer versions of binutils are capable of emitting an exact number bytes > >> worth > >> of optimised nops. Use this i

[Xen-devel] [seabios test] 120002: regressions - FAIL

flight 120002 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/120002/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539 Tests which did not suc

Re: [Xen-devel] [RFC PATCH 25/49] ARM: new VGIC: Add GICv2 world switch backend

Hi, On 13/02/18 14:31, Julien Grall wrote: > Hi, > > On 09/02/18 14:39, Andre Przywara wrote: >> Processing maintenance interrupts and accessing the list registers >> are dependent on the host's GIC version. >> Introduce vgic-v2.c to contain GICv2 specific functions. >> Implement the GICv2 specif

Re: [Xen-devel] [RFC PATCH 25/49] ARM: new VGIC: Add GICv2 world switch backend

Hi, forgot to mention: On 13/02/18 14:31, Julien Grall wrote: > Hi, > > On 09/02/18 14:39, Andre Przywara wrote: >> Processing maintenance interrupts and accessing the list registers >> are dependent on the host's GIC version. >> Introduce vgic-v2.c to contain GICv2 specific functions. >> Implem

Re: [Xen-devel] [RFC PATCH 26/49] ARM: new VGIC: Implement vgic_vcpu_pending_irq

Hi, On 13/02/18 16:35, Julien Grall wrote: > Hi, > > On 09/02/18 14:39, Andre Przywara wrote: >> Tell Xen whether a particular VCPU has an IRQ that needs handling >> in the guest. This is used to decide whether a VCPU is runnable. >> >> This is based on Linux commit 90eee56c5f90, written by Eric

Re: [Xen-devel] [RFC PATCH 26/49] ARM: new VGIC: Implement vgic_vcpu_pending_irq

Hi, On 02/26/2018 03:29 PM, Andre Przywara wrote: On 13/02/18 16:35, Julien Grall wrote: diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c index f4f2a04a60..9e7fb1edcb 100644 --- a/xen/arch/arm/vgic/vgic.c +++ b/xen/arch/arm/vgic/vgic.c @@ -646,6 +646,38 @@ void gic_inject(void)

Re: [Xen-devel] [RFC PATCH 25/49] ARM: new VGIC: Add GICv2 world switch backend

On 02/26/2018 03:16 PM, Andre Przywara wrote: Hi, Hi, forgot to mention: On 13/02/18 14:31, Julien Grall wrote: Hi, On 09/02/18 14:39, Andre Przywara wrote: Processing maintenance interrupts and accessing the list registers are dependent on the host's GIC version. Introduce vgic-v2.c to

Re: [Xen-devel] [RFC PATCH 25/49] ARM: new VGIC: Add GICv2 world switch backend

Hi Andre, On 02/26/2018 03:13 PM, Andre Przywara wrote: Hi, On 13/02/18 14:31, Julien Grall wrote: Hi, On 09/02/18 14:39, Andre Przywara wrote: Processing maintenance interrupts and accessing the list registers are dependent on the host's GIC version. Introduce vgic-v2.c to contain GICv2 spe

  1   2   >