On Wed, Nov 27, 2019 at 02:07:16AM +, Tian, Kevin wrote:
> > From: Roger Pau Monné
> > Sent: Monday, November 18, 2019 10:56 PM
> >
> > On Mon, Nov 18, 2019 at 03:19:50PM +0100, Jan Beulich wrote:
> > > On 18.11.2019 15:03, Roger Pau Monné wrote:
> > > > On Mon, Nov 18, 2019 at 01:26:46PM
On 27.11.2019 11:57, Durrant, Paul wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 27 November 2019 09:44
>> To: Durrant, Paul ; Grall, Julien
>> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
>> ; Roger Pau Monné ; Wei
>> Liu
>> Subject: Re: [PATCH] xen/x86: vpmu: Unmap
> -Original Message-
> From: Jan Beulich
> Sent: 27 November 2019 09:44
> To: Durrant, Paul ; Grall, Julien
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Roger Pau Monné ; Wei
> Liu
> Subject: Re: [PATCH] xen/x86: vpmu: Unmap per-vCPU PMU page when the
> domain is destroyed
>
On Wed, Nov 27, 2019 at 4:33 AM Jürgen Groß wrote:
>
> On 26.11.19 18:17, George Dunlap wrote:
> > Xen used to have single, system-wide limits for the number of grant
> > frames and maptrack frames a guest was allowed to create. Increasing
> > or decreasing this single limit on the Xen
Andrew, thanks for the report. Redirecting to xen-devel, as it looks
like a bug in a development version of Xen.
-George
On Wed, Nov 27, 2019 at 4:27 AM Andrew wrote:
>
> Hi Everyone,
>
> We have been trying to get Xen + QEMU 4.x working with Ceph/rbd. A
> like-for-like build process works
On Wed, 27 Nov 2019 at 10:14, Wei Liu wrote:
>
> On Tue, Nov 26, 2019 at 03:49:20PM +, George Dunlap wrote:
> > Changesets 319f9a0ba9 ("passthrough: quarantine PCI devices") and
> > ba2ab00bbb ("IOMMU: default to always quarantining PCI devices")
> > introduced PCI device "quarantine"
On Tue, Nov 26, 2019 at 03:49:20PM +, George Dunlap wrote:
> Changesets 319f9a0ba9 ("passthrough: quarantine PCI devices") and
> ba2ab00bbb ("IOMMU: default to always quarantining PCI devices")
> introduced PCI device "quarantine" behavior, but did not document how
> the pci-assignable-add and
On 27/11/2019 03:10, Chao Gao wrote:
> On Tue, Nov 26, 2019 at 03:41:53PM +, Sergey Dyasli wrote:
>> Currently if a user tries to live-load the same or older ucode revision
>> than CPU already has, he will get a single message in Xen log like:
>>
>>(XEN) 128 cores are to update their
On 27/11/2019 10:04, Sergey Dyasli wrote:
> Currently if a user tries to live-load the same or older ucode revision
> than CPU already has, he will get a single message in Xen log like:
>
> (XEN) 128 cores are to update their microcode
>
> No actual ucode loading will happen and this
flight 144321 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144321/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 5530782cfe70ed22fe44358f6a10c38916443b42
baseline version:
xen
On 27.11.2019 07:24, Yi Sun wrote:
> During test, we found a crash on Xen with below trace.
> (XEN) Xen call trace:
> (XEN)[] R psr.c#l3_cdp_write_msr+0x1e/0x22
> (XEN)[] F psr.c#do_write_psr_msrs+0x6d/0x109
> (XEN)[] F smp_call_function_interrupt+0x5a/0xac
> (XEN)[] F
On 27/11/2019 09:49, Peng Fan wrote:
Subject: Re: [Xen-devel] [PATCH V2] arch: arm: vgic-v3: fix GICD_ISACTIVER
range
On 27.11.19 10:31, Peng Fan wrote:
Subject: Re: [Xen-devel] [PATCH V2] arch: arm: vgic-v3: fix
GICD_ISACTIVER range
On 27.11.19 01:01, Julien Grall wrote:
Hi,
On
Currently if a user tries to live-load the same or older ucode revision
than CPU already has, he will get a single message in Xen log like:
(XEN) 128 cores are to update their microcode
No actual ucode loading will happen and this situation can be quite
confusing. Fix this by starting ucode
On 26.11.2019 19:02, Roger Pau Monné wrote:
> On Tue, Nov 26, 2019 at 05:50:32PM +0100, Jan Beulich wrote:
>> On 26.11.2019 14:26, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/hvm/irq.c
>>> +++ b/xen/arch/x86/hvm/irq.c
>>> @@ -515,7 +515,11 @@ void hvm_set_callback_via(struct domain *d, uint64_t
> Subject: Re: [Xen-devel] [PATCH V2] arch: arm: vgic-v3: fix GICD_ISACTIVER
> range
>
> On 27.11.19 10:31, Peng Fan wrote:
> >> Subject: Re: [Xen-devel] [PATCH V2] arch: arm: vgic-v3: fix
> >> GICD_ISACTIVER range
> >>
> >> On 27.11.19 01:01, Julien Grall wrote:
> >>> Hi,
> >>>
> >>> On
On 26.11.2019 18:17, Paul Durrant wrote:
> From: Julien Grall
>
> A guest will setup a shared page with the hypervisor for each vCPU via
> XENPMU_init. The page will then get mapped in the hypervisor and only
> released when XEMPMU_finish is called.
>
> This means that if the guest is not
On Tue, Nov 26, 2019 at 03:01:12PM +, Andrew Cooper wrote:
> Print the PCI coordinates in its common format and use d%u notation for the
> domain. As well as printing flags, decode them. IO_PAGE_FAULT is used for
> interrupt remapping errors as well as DMA remapping errors.
>
> Before:
>
On 27.11.19 10:25, Jan Beulich wrote:
On 27.11.2019 05:32, Jürgen Groß wrote:
On 26.11.19 18:17, George Dunlap wrote:
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -364,8 +364,8 @@
*/
#define LIBXL_HAVE_BUILDINFO_GRANT_LIMITS 1
-#define LIBXL_MAX_GRANT_FRAMES_DEFAULT 32
On 27.11.19 10:31, Peng Fan wrote:
Subject: Re: [Xen-devel] [PATCH V2] arch: arm: vgic-v3: fix GICD_ISACTIVER
range
On 27.11.19 01:01, Julien Grall wrote:
Hi,
On 26/11/2019 23:17, Stefano Stabellini wrote:
On Tue, 26 Nov 2019, Julien Grall wrote:
Hi,
On 26/11/2019 20:43, Stefano Stabellini
> Subject: Re: [Xen-devel] [PATCH V2] arch: arm: vgic-v3: fix GICD_ISACTIVER
> range
>
> On 27.11.19 01:01, Julien Grall wrote:
> > Hi,
> >
> > On 26/11/2019 23:17, Stefano Stabellini wrote:
> >> On Tue, 26 Nov 2019, Julien Grall wrote:
> >>> Hi,
> >>>
> >>> On 26/11/2019 20:43, Stefano
On 27.11.2019 05:32, Jürgen Groß wrote:
> On 26.11.19 18:17, George Dunlap wrote:
>> --- a/tools/libxl/libxl.h
>> +++ b/tools/libxl/libxl.h
>> @@ -364,8 +364,8 @@
>>*/
>> #define LIBXL_HAVE_BUILDINFO_GRANT_LIMITS 1
>>
>> -#define LIBXL_MAX_GRANT_FRAMES_DEFAULT 32
>> -#define
On Tue, Nov 26, 2019 at 03:01:11PM +, Andrew Cooper wrote:
> Unhandled IOMMU errors (i.e. not IO_PAGE_FAULT) should still be printed, and
> not hidden behind iommu=debug.
>
> While adjusting this, factor out the symbolic name handling to just one
> location exposing its off-by-one nature.
>
On 26.11.2019 22:20, Rich Persaud wrote:
> As an intermediate step, could we have an umbrella opt-in
> Kconfig option (CONFIG_EFI_NONSPEC_COMPATIBILITY?) that
> enables multiple EFI options for maximum hardware compatibility?
> For this thread and Xen 4.13, that would be
>
On Tue, Nov 26, 2019 at 04:36:05PM +0100, SeongJae Park wrote:
> From: SeongJae Park
>
> For each I/O request, blkback first maps the foreign pages for the
> request to its local pages. If an allocation of a local page for the
> mapping fails, it should unmap every mapping already made for the
On 26.11.2019 21:18, Andrew Cooper wrote:
> On 26/11/2019 20:12, Roman Shaposhnik wrote:
>> On Tue, Nov 26, 2019 at 10:32 AM Marek Marczykowski-Górecki
>>> So, to improve Xen's hardware/firmware compatibility, I have two ideas:
>>>
>>> 1. Make efi=attr=uc the default (it's still possible to
On 26.11.2019 19:32, Marek Marczykowski-Górecki wrote:
> Anyway, if I understand correctly, MMIO region should be mapped as UC,
> right?
While MMIO typically would want to be UC, there are clearly cases
where they'd better be WC, and there may even be cases where they
want to be WT, WP, or WB.
On Tue, Nov 26, 2019 at 04:09:08PM +, Andrew Cooper wrote:
> On 26/11/2019 15:34, Roger Pau Monné wrote:
> > On Tue, Nov 26, 2019 at 12:03:56PM +, Andrew Cooper wrote:
> >> ICEBP isn't handled well by SVM.
> >>
> >> The VMexit state for a #DB-vectored TASK_SWITCH has %rip pointing to the
>
> -Original Message-
> From: Xen-devel On Behalf Of Ian
> Jackson
> Sent: 26 November 2019 17:36
> To: George Dunlap
> Cc: Juergen Gross ; Stefano Stabellini
> ; Julien Grall ; Wei Liu
> ; Paul Durrant ; Andrew Cooper
> ; Konrad Rzeszutek Wilk
> ; Marek Marczykowski-Górecki
> ; Hans van
flight 144309 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144309/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
101 - 129 of 129 matches
Mail list logo
