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

flight 122413 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/122413/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 121991 Tests

Re: [Xen-devel] [PATCH RESEND v1 5/7] x86: Implement Intel Processor Trace context switch

> > Load/Store Intel processor trace register in context switch. > > MSR IA32_RTIT_CTL is loaded/stored automatically from VMCS. > > When Intel PT is supported in guest, we need load/restore PT MSRs only > > when PT is enabled in guest. > > > > Signed-off-by: Luwei Kang > >

[Xen-devel] [PATCH v1 0/2] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

To avoid issues with duplicate e-mail sending, I also cleaned up MAINTAINERS Lars Kurth (2): Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl Replace occurances of xen.org with xenproject.org MAINTAINERS| 30

Re: [Xen-devel] [RESEND PULL v9 00/16] xen: xen-domid-restrict improvements

On 26 April 2018 at 19:15, Ian Jackson wrote: > The following changes since commit b8846a4d6352b2a1d2012f8b3b9115640524aeda: > > vl.c: new function serial_max_hds() (2018-04-26 13:58:29 +0100) > > are available in the git repository at: > >

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On 04/25/2018 08:16 PM, Dongwon Kim wrote: On Wed, Apr 25, 2018 at 08:34:55AM +0200, Daniel Vetter wrote: On Wed, Apr 25, 2018 at 09:07:07AM +0300, Oleksandr Andrushchenko wrote: On 04/24/2018 11:35 PM, Dongwon Kim wrote: Had a meeting with Daniel and talked about bringing out generic part of

Re: [Xen-devel] [PATCH RESEND v1 1/7] x86: add a flag to enable Intel processor trace

> > --- a/docs/misc/xen-command-line.markdown > > +++ b/docs/misc/xen-command-line.markdown > > @@ -1009,6 +1009,13 @@ debug hypervisor only). > > ### idle\_latency\_factor > > > `= ` > > > > +### intel\_pt > > +> `= ` > > + > > +> Default: `true` > > + > > +Flag to enable Intel Processor Trace.

Re: [Xen-devel] [PATCH] x86/cpuidle: don't init stats lock more than once

On 26/04/18 15:47, Jan Beulich wrote: > Osstest flight 122363, having hit an NMI watchdog timeout, shows CPU1 at > > Xen call trace: >[] _spin_lock+0x30/0x57 >[] update_last_cx_stat+0x29/0x42 >[] cpu_idle.c#acpi_processor_idle+0x2ff/0x596 >[] domain.c#idle_loop+0xa8/0xc3 > > and

Re: [Xen-devel] [PATCH v1 2/2] Replace occurances of xen.org with xenproject.org

On 27/04/2018, 10:40, "Wei Liu" wrote: On Fri, Apr 27, 2018 at 10:30:51AM +0100, Lars Kurth wrote: > KDD DEBUGGER > -M: Tim Deegan > +M: Tim Deegan I think Tim should choose which domain name he

[Xen-devel] [xen-4.7-testing test] 122405: regressions - trouble: broken/fail/pass

flight 122405 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/122405/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd broken test-arm64-arm64-xl-credit2

[Xen-devel] [PATCH v2] xen/kbdif: Add features to control keyboard and pointer

From: Oleksandr Andrushchenko It is now not fully possible to control if and which virtual devices are created by the frontend, e.g. keyboard and pointer devices are always created and multi-touch device is created if the backend advertises multi-touch support.

Re: [Xen-devel] [PATCH v9 3/9] xen/x86: support per-domain flag for xpti

On Thu, 2018-04-26 at 13:33 +0200, Juergen Gross wrote: > Instead of switching XPTI globally on or off add a per-domain flag for > that purpose. This allows to modify the xpti boot parameter to support > running dom0 without Meltdown mitigations. Using "xpti=no-dom0" as boot "xpti=dom0=0" >

Re: [Xen-devel] [PATCH RESEND v1 1/7] x86: add a flag to enable Intel processor trace

On Fri, Apr 27, 2018 at 08:22:00AM +, Kang, Luwei wrote: > > > diff --git a/docs/misc/xen-command-line.markdown > > > b/docs/misc/xen-command-line.markdown > > > index 781110d..95411cf 100644 > > > --- a/docs/misc/xen-command-line.markdown > > > +++ b/docs/misc/xen-command-line.markdown > > >

[Xen-devel] [BUG] Xen failed to emulate lfence instruction

Hi ! While working on a VMI app that is supposed to intercepted a specific process, and set a breakpoint on NtResumeThread in Windows, i got a BSOD. Analyzing this BSOD with windbg reveals that I was in this location: FAULTING_IP: nt!PsLookupThreadByThreadId+82 f800`02bcc642

Re: [Xen-devel] [PATCH v9 3/9] xen/x86: support per-domain flag for xpti

>>> On 27.04.18 at 09:59, wrote: > On 27/04/18 09:55, Sergey Dyasli wrote: >> On Thu, 2018-04-26 at 13:33 +0200, Juergen Gross wrote: >>> index b353352adf..220d1ba020 100644 >>> --- a/docs/misc/xen-command-line.markdown >>> +++ b/docs/misc/xen-command-line.markdown >>> @@

[Xen-devel] [distros-debian-jessie test] 74644: tolerable FAIL

flight 74644 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74644/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like 74634 baseline version:

Re: [Xen-devel] [PATCH v1 2/2] Replace occurances of xen.org with xenproject.org

On Fri, Apr 27, 2018 at 10:30:51AM +0100, Lars Kurth wrote: > KDD DEBUGGER > -M: Tim Deegan > +M: Tim Deegan I think Tim should choose which domain name he prefers. Those URL changes are fine. Wei. ___

Re: [Xen-devel] [PATCH] x86/cpuidle: don't init stats lock more than once

On 26/04/18 16:47, Jan Beulich wrote: > Osstest flight 122363, having hit an NMI watchdog timeout, shows CPU1 at > > Xen call trace: >[] _spin_lock+0x30/0x57 >[] update_last_cx_stat+0x29/0x42 >[] cpu_idle.c#acpi_processor_idle+0x2ff/0x596 >[] domain.c#idle_loop+0xa8/0xc3 > > and

Re: [Xen-devel] [PATCH v9 3/9] xen/x86: support per-domain flag for xpti

On 27/04/18 09:55, Sergey Dyasli wrote: > On Thu, 2018-04-26 at 13:33 +0200, Juergen Gross wrote: >> Instead of switching XPTI globally on or off add a per-domain flag for >> that purpose. This allows to modify the xpti boot parameter to support >> running dom0 without Meltdown mitigations. Using

Re: [Xen-devel] [PATCH RESEND v1 1/7] x86: add a flag to enable Intel processor trace

> > diff --git a/docs/misc/xen-command-line.markdown > > b/docs/misc/xen-command-line.markdown > > index 781110d..95411cf 100644 > > --- a/docs/misc/xen-command-line.markdown > > +++ b/docs/misc/xen-command-line.markdown > > @@ -1009,6 +1009,13 @@ debug hypervisor only). > > ###

[Xen-devel] [PATCH v1 1/2] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

The tool covers step 2 of the following workflow Without --overwrite Step 1: git format-patch ... -o ... Step 2: ./scripts/add_maintainers.pl -d This creates *.patchm files in Step 3: git send-email -to xen-devel@lists.xenproject.org /*.patchm With --overwrite Step 1:

[Xen-devel] [PATCH v1 2/2] Replace occurances of xen.org with xenproject.org

This is a general clean-up activity. It also avoids mails being sent to xen-devel@lists.xenproject.org and xen-de...@lists.xen.org when used with add_maintainers.pl/git send-email Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson

Re: [Xen-devel] [PATCH for-4.11] x86/traps: Improve code generation for set_ist()

On 27/04/18 15:07, Andrew Cooper wrote: > The IST field in an IDT entry is a 3 bit field, with 5 adjacent reserved bits > which we always write as zero. By expressing this as a byte field in a union, > we turn an invocation of enable_each_ist() from > > 4b 8b 14 d3 mov

Re: [Xen-devel] [PATCH for-4.11] x86/traps: Improve code generation for set_ist()

>>> On 27.04.18 at 15:07, wrote: > The IST field in an IDT entry is a 3 bit field, with 5 adjacent reserved bits > which we always write as zero. By expressing this as a byte field in a union, > we turn an invocation of enable_each_ist() from > > 4b 8b 14 d3

Re: [Xen-devel] [PATCH] x86emul: VMOVNTDQA should raise #GP(0) on mis-alignment

On 27/04/18 14:10, Jan Beulich wrote: > Commit 50b73118d5 introduced emulation of the insn without extending the > set of opcodes requiring special alignment related #GP behavior. > > Signed-off-by: Jan Beulich Release-acked-by: Juergen Gross Juergen

Re: [Xen-devel] [PATCH RESEND v1 1/7] x86: add a flag to enable Intel processor trace

>>> On 27.04.18 at 10:22, wrote: >> > diff --git a/docs/misc/xen-command-line.markdown >> > b/docs/misc/xen-command-line.markdown >> > index 781110d..95411cf 100644 >> > --- a/docs/misc/xen-command-line.markdown >> > +++ b/docs/misc/xen-command-line.markdown >> > @@ -1009,6

Re: [Xen-devel] [PATCH v2 09/10] xen/arm: Free memory allocated for sibling/core maps on CPU hot-unplug

Thanks Julien, I fixed this On Mon, Apr 23, 2018 at 1:38 PM, Julien Grall wrote: > Hi, > > > On 20/04/18 13:25, Mirela Simonovic wrote: >> >> The memory allocated in setup_cpu_sibling_map() when a CPU is hotplugged >> has to be freed when the CPU is hot-unplugged. This is

[Xen-devel] [xen-4.8-testing test] 122414: regressions - trouble: broken/fail/pass

flight 122414 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/122414/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-xsm broken test-armhf-armhf-xl-xsm 4

Re: [Xen-devel] [PATCH RESEND v1 6/7] x86: Implement Intel Processor Trace MSRs read/write

>>> On 15.01.18 at 19:12, wrote: > +int pt_do_wrmsr(unsigned int msr, uint64_t msr_content) > +{ > +struct pt_desc *pt_desc = >arch.hvm_vmx.pt_desc; > + > +if ( !opt_intel_pt ) > +return 1; > + > +switch ( msr ) { > +case MSR_IA32_RTIT_CTL: > +

Re: [Xen-devel] [PATCH] x86emul: VMOVNTDQA should raise #GP(0) on mis-alignment

On 27/04/18 13:10, Jan Beulich wrote: > Commit 50b73118d5 introduced emulation of the insn without extending the > set of opcodes requiring special alignment related #GP behavior. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper

Re: [Xen-devel] [PATCH v2 07/10] xen/arm: Release maintenance interrupt when CPU is hot-unplugged

Hi, At 10:28 +0100 on 27 Apr (1524824906), Julien Grall wrote: > On 26/04/18 15:23, Tim Deegan wrote: > > At 11:08 +0100 on 26 Apr (1524740921), Julien Grall wrote: > >> On 20/04/18 13:25, Mirela Simonovic wrote: > This looks a bit weird. AFAIU, if you disable the CPU interface, then you

Re: [Xen-devel] [PATCH v1 1/2] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

Added Anthony as he highlighted the issue which led to the creation of the tool Otherwise I played a little bit more on various series I worked on in the past and there are minor niggles in its usage On 27/04/2018, 10:31, "Lars Kurth" wrote: +OPTIONS:

Re: [Xen-devel] [PATCH RESEND v1 1/7] x86: add a flag to enable Intel processor trace

>>> On 27.04.18 at 11:01, wrote: >Thanks for you review. "ptrace" make me associate "strace", "ftrace". > Although they are complete different things but I think "ptrace" is not good > enough to present "Intel Processor Trace". Then how about ipt instead of just pt?

[Xen-devel] [PATCH for-4.11] x86/traps: Improve code generation for set_ist()

The IST field in an IDT entry is a 3 bit field, with 5 adjacent reserved bits which we always write as zero. By expressing this as a byte field in a union, we turn an invocation of enable_each_ist() from 4b 8b 14 d3 mov(%r11,%r10,8),%rdx 48 b8 ff ff ff ff f8 ff ff ff

[Xen-devel] [PATCH v3 01/10] xen/arm64: Added handling of the trapped access to OSLSR register

Linux/dom0 accesses OSLSR register when saving CPU context during the suspend procedure. Xen traps access to this register, but has no handling for it. Consequently, Xen injects undef exception to linux, causing it to crash. This patch adds handling of the trapped access to OSLSR as ro/raz.

[Xen-devel] [PATCH v3 02/10] xen/arm: Ignore write to GICD_ISACTIVERn registers (vgic-v2)

Guests attempt to write into these registers on resume (for example Linux). Without this patch a data abort exception will be raised to the guest. This patch handles the write access by ignoring it, but only if the value to be written is zero. This should be fine because reading these registers is

[Xen-devel] [PATCH v3 00/10] xen/arm64: Suspend preconditions and CPU hotplug fixes

This patch set contains fixes that are required as precondition for suspend to RAM support, including the CPU hotplug which is required to suspend non-boot CPUs. The first two patches in this series: 1) xen/arm64: Added handling of the trapped access to OSLSR register 2) xen/arm: Ignore write to

[Xen-devel] [PATCH v3 09/10] xen/arm: Free memory allocated for sibling/core maps on CPU hot-unplug

The memory allocated in setup_cpu_sibling_map() when a CPU is hotplugged has to be freed when the CPU is hot-unplugged. This is done in remove_cpu_sibling_map() and called when the CPU dies. The call to remove_cpu_sibling_map() is made from a notifier callback when CPU_DEAD event is received.

[Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

On boot, enabling errata workarounds will be triggered by the boot CPU from start_xen(). On CPU hotplug (non-boot scenario) this would not be done. This patch adds the code required to enable errata workarounds for a CPU being hotplugged after the system boots. This is triggered using a notifier.

[Xen-devel] [PATCH v3 05/10] xen/arm: Setup virtual paging for non-boot CPUs on hotplug/resume

In existing code the virtual paging for non-boot CPUs is setup only on boot. The setup is triggered from start_xen() after all CPUs are brought online. In other words, the initialization of VTCR_EL2 register is done out of the cpu_up/start_secondary() control flow. However, the cpu_up flow is also

[Xen-devel] [PATCH v3 04/10] xen/arm: Remove __initdata and __init to enable CPU hotplug

CPU up flow is currently used during the initial boot to start secondary CPUs. However, the same flow should be used for CPU hotplug, e.g. when hotplugging secondary CPUs within the resume procedure (resume from the suspend to RAM). Therefore, prefixes __initdata and __init had to be removed from

[Xen-devel] [PATCH v3 08/10] xen/arm: Release timer interrupts when CPU is hot-unplugged

When a CPU is hot-unplugged timer interrupts have to be released in order to free the memory that was allocated when the interrupts were requested (using request_irq()). The request_irq is called for each timer interrupt when the CPU gets hotplugged

[Xen-devel] [PATCH v3 03/10] xen/arm: Implement CPU_OFF PSCI call (physical interface)

During the system suspend to RAM non-boot CPUs will be hotplugged. This will be triggered via disable_nonboot_cpus() call. When hotplugged the CPU will end up in an infinite wfi loop in stop_cpu(). This patch adds PSCI CPU_OFF call to the EL3 with the aim to get powered down the calling CPU during

[Xen-devel] [PATCH v3 06/10] xen/common: Restore IRQ affinity when hotplugging a pCPU

Non-boot pCPUs are being hot-unplugged during the system suspend to RAM and hotplugged during the resume. When non-boot pCPUs are hot-unplugged the interrupts that were targeted to them are migrated to the boot pCPU. On suspend, each guest could have its own wake-up devices/interrupts

[Xen-devel] [PATCH v3 07/10] xen/arm: Release maintenance interrupt when CPU is hot-unplugged

When a CPU is hot-unplugged the maintenance interrupt has to be released in order to free the memory that was allocated when the CPU was hotplugged and interrupt requested. The interrupt was requested using request_irq() which is called from start_secondary-> init_maintenance_interrupt. With this

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

flight 122471 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122471/ 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 v2] xen/kbdif: Add features to control keyboard and pointer

On Fri, Apr 27, 2018 at 06:19:35PM +0300, Oleksandr Andrushchenko wrote: > On 04/27/2018 06:11 PM, Konrad Rzeszutek Wilk wrote: > > On Fri, Apr 27, 2018 at 09:58:11AM +0300, Oleksandr Andrushchenko wrote: > > > From: Oleksandr Andrushchenko > > > > > > It is now

Re: [Xen-devel] [PATCH] SVM: re-work VMCB sync-ing

On 04/27/2018 11:52 AM, Jan Beulich wrote: On 26.04.18 at 19:27, wrote: >> On 04/26/2018 11:55 AM, Jan Beulich wrote: >> On 26.04.18 at 17:20, wrote: On 04/26/2018 09:33 AM, Jan Beulich wrote: >>> -static void

[Xen-devel] [PATCH] [v3] x86: Convert x86_platform_ops to timespec64

The x86 platform operations are fairly isolated, so we can change them from using timespec to timespec64. I checked that All the users and callers are safe, and there is only one critical function that is broken beyond 2106: pvclock_read_wallclock() uses a 32-bit number of seconds since the epoch

[Xen-devel] [PATCH for-4.11 v2 2/2] Add Designated Reviewer (R:) to MAINTAINERS file and add support for it in get_maintainer.pl

The syntax has been copied from the Linux Maintainers file. I moved the following Linux get_maintainer.pl patches to Xen, fixing up some merge issues (and a bug). The get_maintainer.pl changes were based on the following git commits *

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

flight 122427 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/122427/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 122286

Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?

Hi Wei Liu, On Fri, Apr 27, 2018 at 05:58:17PM +0100, Wei Liu wrote: > On Fri, Apr 27, 2018 at 04:14:16PM +, Jason Cooper wrote: > > On Fri, Apr 27, 2018 at 04:52:57PM +0100, Andrew Cooper wrote: ... > > > xc_domain_create() takes a domid value by pointer.  Passing a value > > > other than

Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?

On Fri, Apr 27, 2018 at 06:02:46PM +0100, Andrew Cooper wrote: > On 27/04/18 17:14, Jason Cooper wrote: > > On Fri, Apr 27, 2018 at 04:52:57PM +0100, Andrew Cooper wrote: > >> On 27/04/18 16:35, Jason Cooper wrote: > >>> On Fri, Apr 27, 2018 at 04:11:39PM +0100, Andrew Cooper wrote: > On

[Xen-devel] [PATCH for-4.11 v2 0/2] Add Designated Reviewer (R:) to MAINTAINERS (plus a test case)

This follows up from a conversation after the April x86 community call, in which I had the following action: Lars to propose fixing CC issue in xen.git:MAINTAINERS copying the R section entries from Linux.git:MAINTAINERS (will need changes to get_maintainers.pl also) On 27/4/18 Juergen gave a

[Xen-devel] [PATCH for-4.11 v2 1/2] Add Brian Woods as Designated reviewer to AMD IOMMU and AMD SVM

This was discussed in an IRC discussion post the April x86 meeting. On 27/4/18 Juergen gave a RAB via IRC Cc: Lars Kurth Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan

Re: [Xen-devel] [PATCH v1 2/2] Replace occurances of xen.org with xenproject.org

At 10:40 +0100 on 27 Apr (1524825602), Wei Liu wrote: > On Fri, Apr 27, 2018 at 10:30:51AM +0100, Lars Kurth wrote: > > KDD DEBUGGER > > -M: Tim Deegan > > +M: Tim Deegan > > I think Tim should choose which domain name he prefers. I would prefer to keep

[Xen-devel] [xen-4.9-testing test] 122417: regressions - trouble: blocked/broken/fail/pass

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

Re: [Xen-devel] [PATCH] SVM: re-work VMCB sync-ing

>>> On 26.04.18 at 19:27, wrote: > On 04/26/2018 11:55 AM, Jan Beulich wrote: > On 26.04.18 at 17:20, wrote: >>> On 04/26/2018 09:33 AM, Jan Beulich wrote: >> -static void svm_sync_vmcb(struct vcpu *v) >> +static void

Re: [Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn

On 27/04/2018, 16:29, "Julien Grall" wrote: On 27/04/18 15:32, Ian Jackson wrote: > George Dunlap writes ("Re: [Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn"): >> How would you apply this directive to the particular

Re: [Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn

Hi Ian, On 27/04/18 16:34, Ian Jackson wrote: Julien Grall writes ("Re: [Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn"): I guess I'm being quite selfish here. I'm usually the release technician. Doing release preparation at the last minute and in strange ways

Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?

On Fri, Apr 27, 2018 at 04:14:16PM +, Jason Cooper wrote: > On Fri, Apr 27, 2018 at 04:52:57PM +0100, Andrew Cooper wrote: > > On 27/04/18 16:35, Jason Cooper wrote: > > > On Fri, Apr 27, 2018 at 04:11:39PM +0100, Andrew Cooper wrote: > > >> On 27/04/18 16:03, Jason Cooper wrote: > > >>> The

[Xen-devel] [xen-unstable-smoke test] 122468: regressions - FAIL

flight 122468 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122468/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-i386 16 guest-localmigrate/x10 fail REGR. vs. 122457

Re: [Xen-devel] [PATCH v2 07/10] xen/arm: Release maintenance interrupt when CPU is hot-unplugged

On 27/04/18 15:38, Mirela Simonovic wrote: Hi, On Fri, Apr 27, 2018 at 4:15 PM, Tim Deegan wrote: Hi, At 10:28 +0100 on 27 Apr (1524824906), Julien Grall wrote: On 26/04/18 15:23, Tim Deegan wrote: At 11:08 +0100 on 26 Apr (1524740921), Julien Grall wrote: On 20/04/18

Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?

On Fri, Apr 27, 2018 at 04:52:57PM +0100, Andrew Cooper wrote: > On 27/04/18 16:35, Jason Cooper wrote: > > On Fri, Apr 27, 2018 at 04:11:39PM +0100, Andrew Cooper wrote: > >> On 27/04/18 16:03, Jason Cooper wrote: > >>> The problem occurs when I reboot a driver domain. Regardless of the > >>>

Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?

On Fri, Apr 27, 2018 at 04:52:57PM +0100, Andrew Cooper wrote: > On 27/04/18 16:35, Jason Cooper wrote: > > Hi Andrew, > > > > On Fri, Apr 27, 2018 at 04:11:39PM +0100, Andrew Cooper wrote: > >> On 27/04/18 16:03, Jason Cooper wrote: > >>> The problem occurs when I reboot a driver domain.

Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?

On 27/04/18 16:03, Jason Cooper wrote: > All, > > On Gentoo Xen 4.9.1, I've been creating minimal Linux DomU's to create a > virtual, segregated network infrastructure. This has been going really > well, and I'm slowly progressing toward a self-updating system. > > My main snag has to do with

Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?

Hi Andrew, On Fri, Apr 27, 2018 at 04:11:39PM +0100, Andrew Cooper wrote: > On 27/04/18 16:03, Jason Cooper wrote: > > The problem occurs when I reboot a driver domain. Regardless of the > > type of guest attached to it, I'm unable to re-establish connectivity > > between the driver domain and

[Xen-devel] [OSSTEST PATCH] sg-report-flight: Provide correct links to test history pages

The files are actually called `ALL.html' and `.html'. See the assignments to $html_file in sg-report-job-history near l.251. I think this may have previously worked in Massachusetts (prior to the recent upgrades) due to content negotiation, but this should not be relied on. Reported-by: Julien

Re: [Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn

On 27/04/18 15:32, Ian Jackson wrote: George Dunlap writes ("Re: [Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn"): How would you apply this directive to the particular situation we found ourselves in this time? As a reminder: * Around 3 December, we didn't think

Re: [Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn

Julien Grall writes ("Re: [Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn"): > While I understand this was not ideal, I still think it was the best > solution we had at that time. I would be interested to know what you > would have chosen with the situation we had. >

Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?

On 27/04/18 17:14, Jason Cooper wrote: > On Fri, Apr 27, 2018 at 04:52:57PM +0100, Andrew Cooper wrote: >> On 27/04/18 16:35, Jason Cooper wrote: >>> On Fri, Apr 27, 2018 at 04:11:39PM +0100, Andrew Cooper wrote: On 27/04/18 16:03, Jason Cooper wrote: > The problem occurs when I reboot a

Re: [Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn

George Dunlap writes ("Re: [Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn"): > How would you apply this directive to the particular situation we > found ourselves in this time? > > As a reminder: > > * Around 3 December, we didn't think we'd be ready to release until

[Xen-devel] Xen 4.11 RC2

Hi all, Xen 4.11 rc2 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.11.0-rc2 For your convenience there is also a tarball at: https://downloads.xenproject.org/release/xen/4.11.0-rc2/xen-4.11.0-rc2.tar.gz And the signature is at:

Re: [Xen-devel] [PATCH v1 2/2] Replace occurances of xen.org with xenproject.org

On 27/04/2018, 15:22, "Tim Deegan" wrote: At 10:40 +0100 on 27 Apr (1524825602), Wei Liu wrote: > On Fri, Apr 27, 2018 at 10:30:51AM +0100, Lars Kurth wrote: > > KDD DEBUGGER > > -M: Tim Deegan > > +M: Tim Deegan

Re: [Xen-devel] [PATCH v2 07/10] xen/arm: Release maintenance interrupt when CPU is hot-unplugged

Hi, On Fri, Apr 27, 2018 at 4:15 PM, Tim Deegan wrote: > Hi, > > At 10:28 +0100 on 27 Apr (1524824906), Julien Grall wrote: >> On 26/04/18 15:23, Tim Deegan wrote: >> > At 11:08 +0100 on 26 Apr (1524740921), Julien Grall wrote: >> >> On 20/04/18 13:25, Mirela Simonovic wrote:

Re: [Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn

On 27/04/18 16:32, Ian Jackson wrote: > George Dunlap writes ("Re: [Xen-devel] [PATCH] > docs/process/xen-release-management: Lesson to learn"): >> How would you apply this directive to the particular situation we >> found ourselves in this time? >> >> As a reminder: >> >> * Around 3 December, we

[Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?

All, On Gentoo Xen 4.9.1, I've been creating minimal Linux DomU's to create a virtual, segregated network infrastructure. This has been going really well, and I'm slowly progressing toward a self-updating system. My main snag has to do with re-attaching VMs to a driver domain after rebooting

Re: [Xen-devel] [PATCH v2] xen/kbdif: Add features to control keyboard and pointer

On Fri, Apr 27, 2018 at 09:58:11AM +0300, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > It is now not fully possible to control if and which virtual devices > are created by the frontend, e.g. keyboard and pointer devices > are always

Re: [Xen-devel] [PATCH RESEND v1 1/7] x86: add a flag to enable Intel processor trace

> >>> On 27.04.18 at 11:01, wrote: > >Thanks for you review. "ptrace" make me associate "strace", "ftrace". > > Although they are complete different things but I think "ptrace" is > > not good enough to present "Intel Processor Trace". > > Then how about ipt instead of

Re: [Xen-devel] [PATCH] [v3] x86: Convert x86_platform_ops to timespec64

2018-04-27 22:13+0200, Arnd Bergmann: > The x86 platform operations are fairly isolated, so we can > change them from using timespec to timespec64. I checked that > All the users and callers are safe, and there is only one > critical function that is broken beyond 2106: > >

[Xen-devel] [qemu-mainline test] 122437: FAIL

flight 122437 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/122437/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu broken in 122394 Tests

Re: [Xen-devel] [PATCH RESEND v1 1/7] x86: add a flag to enable Intel processor trace

> >>> On 27.04.18 at 10:22, wrote: > >> > diff --git a/docs/misc/xen-command-line.markdown > >> > b/docs/misc/xen-command-line.markdown > >> > index 781110d..95411cf 100644 > >> > --- a/docs/misc/xen-command-line.markdown > >> > +++ b/docs/misc/xen-command-line.markdown > >>

[Xen-devel] [ovmf baseline-only test] 74645: all pass

This run is configured for baseline tests only. flight 74645 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74645/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf c8dca871df2a6b6d9a3b46cca7ee65ee66a33355 baseline

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

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

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

On Mon, Apr 23, 2018 at 2:00 AM, Alexandru Isaila wrote: > This patch is adding a way to enable/disable inguest pagefault > events. It introduces the xc_monitor_inguest_pagefault function > and adds the inguest_pagefault_disabled in the monitor structure. > This is needed

Re: [Xen-devel] [PATCH] [v3] x86: Convert x86_platform_ops to timespec64

On 04/27/2018 09:13 PM, Arnd Bergmann wrote: > diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c > index 761f6af6efa5..637982efecd8 100644 > --- a/arch/x86/kernel/pvclock.c > +++ b/arch/x86/kernel/pvclock.c > @@ -123,28 +123,35 @@ u64 pvclock_clocksource_read(struct >

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

flight 122442 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/122442/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 11 debian-fixup fail REGR. vs. 118324

Re: [Xen-devel] [PATCH RESEND v1 2/7] x86: configure vmcs for Intel processor trace virtualization

> > This patch configure VMCS to make Intel PT output address can be treat > > as guest physical address and translated by EPT when intel_pt option > > is true. > > There have some constraint condition on VMCS configuration, otherwise > > will cause VM entry failed. > > > > 1. If the “Guest PT

Re: [Xen-devel] [PATCH RESEND v1 4/7] x86: add intel processor trace context

> > --- a/xen/include/asm-x86/hvm/vmx/vmcs.h > > +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h > > @@ -20,6 +20,7 @@ > > > > #include > > #include > > +#include > > > > extern void vmcs_dump_vcpu(struct vcpu *v); extern void > > setup_vmcs_dump(void); @@ -171,6 +172,8 @@ struct arch_vmx_struct {

Re: [Xen-devel] [PATCH RESEND v1 5/7] x86: Implement Intel Processor Trace context switch

> > --- a/xen/arch/x86/cpu/intel_pt.c > > +++ b/xen/arch/x86/cpu/intel_pt.c > > @@ -21,7 +21,76 @@ > > #include > > #include > > #include > > +#include > > +#include > > > > /* intel_pt: Flag to enable Intel Processor Trace (default on). */ > > bool_t __read_mostly opt_intel_pt = 1;

Re: [Xen-devel] [PATCH] xen/kbdif: Add frontend's virtual device options

On 04/27/2018 12:14 AM, Dmitry Torokhov wrote: Hi Oleksandr, On Tue, Apr 24, 2018 at 10:31:38AM +0300, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko It is now not possible to control if and which virtual devices are created by the frontend,

Re: [Xen-devel] [PATCH] tools: prepend to PKG_CONFIG_PATH when configuring qemu

On 26/04/18 19:41, Stewart Hildebrand wrote: > A user may choose to set his/her own PKG_CONFIG_PATH, which is useful in the > case of cross-compiling. We don't want to completely override the > PKG_CONFIG_PATH, just add to it. > > Signed-off-by: Stewart Hildebrand