Hi Stefano,
On 28/11/2019 01:12, Stefano Stabellini wrote:
On Wed, 27 Nov 2019, Jürgen Groß wrote:
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 Stab
On 19-11-27 11:06:49, Jan Beulich wrote:
> 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_funct
On 28.11.19 09:14, Julien Grall wrote:
Hi Stefano,
On 28/11/2019 01:12, Stefano Stabellini wrote:
On Wed, 27 Nov 2019, Jürgen Groß wrote:
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
> Subject: Re: [Xen-devel] [PATCH V2] arch: arm: vgic-v3: fix GICD_ISACTIVER
> range
>
> Hi Stefano,
>
> On 28/11/2019 01:12, Stefano Stabellini wrote:
> > On Wed, 27 Nov 2019, Jürgen Groß wrote:
> >> On 27.11.19 10:31, Peng Fan wrote:
> Subject: Re: [Xen-devel] [PATCH V2] arch: arm: vgic-v3
__xen_evtchn_do_upcall() contains guards against being called
recursively. This mechanism was introduced in the early pvops times
(kernel 2.6.26) when there were all the Xen backend drivers missing
from the upstream kernel, and some of those out-of-tree drivers were
enabling interrupts in their eve
On 07.11.19 12:15, Juergen Gross wrote:
The Xen gntdev driver's checking of the number of allowed mapped pages
is in need of some sanitizing work.
Changes in V2:
- enhanced commit message of patch 1 (Andrew Cooper)
Juergen Gross (2):
xen/gntdev: replace global limit of mapped pages by limit
Hi,
On 28/11/2019 08:32, Jürgen Groß wrote:
On 28.11.19 09:14, Julien Grall wrote:
In short, I think the patch should go in now and there are no downsides
to it. That's it, I rest my case. Julien, I hope you'll reconsider.
I don't really see the point to try to allow Linux 5.4 booting on Xen
4
Please accept my sincere apologies for taking so long to reply. A few
thoughts before I dig deeper.
Vladimir Sementsov-Ogievskiy writes:
> Hi all!
>
> At the request of Markus: full version of errp propagation. Let's look
> at it. Cover as much as possible, except inserting macro invocation
> w
On 28.11.19 09:48, Julien Grall wrote:
Hi,
On 28/11/2019 08:32, Jürgen Groß wrote:
On 28.11.19 09:14, Julien Grall wrote:
In short, I think the patch should go in now and there are no downsides
to it. That's it, I rest my case. Julien, I hope you'll reconsider.
I don't really see the point to
> -Original Message-
> From: Julien Grall
> Sent: 27 November 2019 19:42
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
> ; Jun Nakajima ; Kevin Tian
>
> Subject: Re: [PATCH v2] xen/x86: vpmu: Unmap per-vCPU PMU page wh
28.11.2019 11:54, Markus Armbruster wrote:
> Please accept my sincere apologies for taking so long to reply. A few
> thoughts before I dig deeper.
>
> Vladimir Sementsov-Ogievskiy writes:
>
>> Hi all!
>>
>> At the request of Markus: full version of errp propagation. Let's look
>> at it. Cover a
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 XENPMU_finish is called.
This means that if the guest fails to invoke XENPMU_finish, e.g if it is
destroyed rather than cl
On 28/11/2019 09:00, Jürgen Groß wrote:
On 28.11.19 09:48, Julien Grall wrote:
Hi,
On 28/11/2019 08:32, Jürgen Groß wrote:
On 28.11.19 09:14, Julien Grall wrote:
In short, I think the patch should go in now and there are no
downsides
to it. That's it, I rest my case. Julien, I hope you'll
On 28/11/2019 01:07, Stefano Stabellini wrote:
On Wed, 27 Nov 2019, Julien Grall wrote:
On Tue, 26 Nov 2019, 23:18 Stefano Stabellini, wrote:
On Fri, 15 Nov 2019, Stewart Hildebrand wrote:
> Allow vgic_get_hw_irq_desc to be called with a vcpu argument.
>
> Use vcpu
On 27.11.2019 19:17, Andrew Cooper wrote:
> On 21/11/2019 08:34, Jan Beulich wrote:
>> On 20.11.2019 18:13, Andrew Cooper wrote:
>>> On 20/11/2019 16:40, Jürgen Groß wrote:
On 20.11.19 17:30, Jan Beulich wrote:
> On 08.11.2019 12:18, Jan Beulich wrote:
>> The .file assembler directives
On 28.11.2019 09:17, Yi Sun wrote:
> On 19-11-27 11:06:49, Jan Beulich wrote:
>> On 27.11.2019 07:24, Yi Sun wrote:
>>> --- a/xen/arch/x86/psr.c
>>> +++ b/xen/arch/x86/psr.c
>>> @@ -316,6 +316,7 @@ static bool cat_init_feature(const struct cpuid_leaf
>>> *regs,
>>> [FEAT_TYPE_L3_CDP] = "L
On 28.11.2019 00:51, Lars Kurth wrote:
> On 29/10/2019, 12:41, "Stefano Stabellini" wrote:
> On Tue, 29 Oct 2019, Julien Grall wrote:
> > On 28/10/2019 21:43, Stefano Stabellini wrote:
> > > On Mon, 28 Oct 2019, Julien Grall wrote:
> > >> Hi,
> > >>
> > >> On 25/10/2019 11
On 28.11.2019 01:54, Stefano Stabellini wrote:
> On Thu, 26 Sep 2019, Lars Kurth wrote:
>> From: Lars Kurth
>>
>> This document highlights what reviewers such as maintainers and committers
>> look
>> for when reviewing code. It sets expectations for code authors and provides
>> a framework for co
On Wed, Nov 27, 2019 at 06:24:58PM -0800, Stefano Stabellini wrote:
> libxl_arm_acpi.c is using BUILD_BUG_ON but it is not including
> xen-tools/libs.h that defines it.
>
> Signed-off-by: Stefano Stabellini
Acked-by: Wei Liu
Juergen, this is a trivial patch. I think it can go in 4.13.
Wei.
>
> On Nov 28, 2019, at 9:55 AM, Jan Beulich wrote:
Has anyone actually tried building a livepatch with this change in place?
>>> Actually - what is your concern here? The exact spelling of symbols
>>> names should be of no interest to the tool. After all the compiler is
>>> free to invent all
flight 144339 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144339/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 144319
test-amd64-i386-xl-pvshim12
On 28.11.2019 01:56, Stefano Stabellini wrote:
> On Thu, 26 Sep 2019, Lars Kurth wrote:
>> +This could take for example the form of
>> +> Do you think it would be useful for the code to do XXX?
>> +> I can imagine a user wanting to do YYY (and XXX would enable this)
>> +
>> +That potentially adds
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 call_function_interrupt+0x20/0x34
(XEN)[] F do_IRQ+0x175
On 28.11.2019 10:38, 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 XENPMU_finish is called.
>
> This means that if the guest fails to invo
On 28.11.19 11:17, George Dunlap wrote:
On Nov 28, 2019, at 9:55 AM, Jan Beulich wrote:
Has anyone actually tried building a livepatch with this change in place?
Actually - what is your concern here? The exact spelling of symbols
names should be of no interest to the tool. After all the comp
> -Original Message-
> From: George Dunlap
> Sent: 27 November 2019 16:52
> To: Durrant, Paul ; Jan Beulich
> Cc: AndrewCooper ; Anthony PERARD
> ; Roger Pau Monné ;
> Volodymyr Babchuk ; George Dunlap
> ; Ian Jackson ;
> Marek Marczykowski-Górecki ; Stefano
> Stabellini ; xen-devel@lists
> -Original Message-
> From: Jan Beulich
> Sent: 28 November 2019 10:23
> To: Durrant, Paul ; Boris Ostrovsky
>
> Cc: xen-devel@lists.xenproject.org; Grall, Julien ;
> Andrew Cooper ; Roger Pau Monné
> ; Jun Nakajima ; Kevin Tian
> ; Wei Liu
> Subject: Re: [PATCH v3] xen/x86: vpmu: Unmap
On 28.11.19 11:15, Wei Liu wrote:
On Wed, Nov 27, 2019 at 06:24:58PM -0800, Stefano Stabellini wrote:
libxl_arm_acpi.c is using BUILD_BUG_ON but it is not including
xen-tools/libs.h that defines it.
Signed-off-by: Stefano Stabellini
Acked-by: Wei Liu
Juergen, this is a trivial patch. I thi
On 28.11.2019 11:26, Durrant, Paul wrote:
>> From: George Dunlap
>> Sent: 27 November 2019 16:52
>>
>> On 11/27/19 4:43 PM, Durrant, Paul wrote:
From: George Dunlap
Sent: 27 November 2019 16:34
TBH I'd be tempted to define XENSOMETHING_MAX_DEFAULT as (unsigned
long)(-1)
On Thu, Nov 28, 2019 at 11:30:34AM +0100, Jürgen Groß wrote:
> On 28.11.19 11:15, Wei Liu wrote:
> > On Wed, Nov 27, 2019 at 06:24:58PM -0800, Stefano Stabellini wrote:
> > > libxl_arm_acpi.c is using BUILD_BUG_ON but it is not including
> > > xen-tools/libs.h that defines it.
> > >
> > > Signed-o
On Wed, Nov 27, 2019 at 10:54:42PM +1000, Andrew wrote:
> I have the system setup for testing, so happy to test any patches that may
> come out.
Thanks Andrew for the report, I think I understand the issue. I'll work
on a fix.
Cheers,
--
Anthony PERARD
_
At the time the pending EOI stack was introduced there were no
internally used IRQs which would have the LAPIC EOI issued from the
->end() hook. This had then changed with the introduction of IOMMUs,
but the interaction issue was presumably masked by
irq_guest_eoi_timer_fn() frequently EOI-ing inte
On 27.11.2019 18:11, Paul Durrant wrote:
> This patch introduces a new iommu_op to facilitate a per-implementation
> quarantine set up, and then further code for x86 implementations
> (amd and vtd) to set up a read-only scratch page to serve as the source
> for DMA reads whilst a device is assigned
On 28.11.2019 12:03, Jan Beulich wrote:
> At the time the pending EOI stack was introduced there were no
> internally used IRQs which would have the LAPIC EOI issued from the
> ->end() hook. This had then changed with the introduction of IOMMUs,
> but the interaction issue was presumably masked by
On 28.11.2019 11:18, Yi Sun wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -1271,7 +1271,8 @@ static void do_write_psr_msrs(void *data)
>
> for ( j = 0; j < cos_num; j++, index++ )
> {
> -if ( feat->cos_reg_val[cos * cos_num + j] != info->val[index
On 28.11.19 12:17, Jan Beulich wrote:
On 27.11.2019 18:11, Paul Durrant wrote:
This patch introduces a new iommu_op to facilitate a per-implementation
quarantine set up, and then further code for x86 implementations
(amd and vtd) to set up a read-only scratch page to serve as the source
for DMA
On 28.11.19 12:19, Jan Beulich wrote:
On 28.11.2019 12:03, Jan Beulich wrote:
At the time the pending EOI stack was introduced there were no
internally used IRQs which would have the LAPIC EOI issued from the
->end() hook. This had then changed with the introduction of IOMMUs,
but the interactio
c/s d0a699a389f1 "x86/monitor: add support for descriptor access events"
introduced logic looking for what appeared to be exitinfo (not that this
exists in SVM - exitinfo1 or 2 do), but actually passed the exit IDT vectoring
information. There is never any IDT vectoring involved in these intercept
On Thu, Nov 28, 2019 at 12:03:47PM +0100, Jan Beulich wrote:
> At the time the pending EOI stack was introduced there were no
> internally used IRQs which would have the LAPIC EOI issued from the
> ->end() hook. This had then changed with the introduction of IOMMUs,
> but the interaction issue was
On 28/11/2019 11:03, Jan Beulich wrote:
> Notes:
>
> - In principle we could get away without the check_eoi_deferral flag.
> I've introduced it just to make sure there's as little change as
> possible to unaffected paths.
> - Similarly the cpu_has_pending_apic_eoi() check in do_IRQ() isn't
>
On 27/11/2019 18:17, Andrew Cooper wrote:
> On 21/11/2019 08:34, Jan Beulich wrote:
>> On 20.11.2019 18:13, Andrew Cooper wrote:
>>> On 20/11/2019 16:40, Jürgen Groß wrote:
On 20.11.19 17:30, Jan Beulich wrote:
> On 08.11.2019 12:18, Jan Beulich wrote:
>> The .file assembler directives
Vladimir Sementsov-Ogievskiy writes:
> 28.11.2019 11:54, Markus Armbruster wrote:
>> Please accept my sincere apologies for taking so long to reply. A few
>> thoughts before I dig deeper.
>>
>> Vladimir Sementsov-Ogievskiy writes:
>>
>>> Hi all!
>>>
>>> At the request of Markus: full version
flight 144345 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144345/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
144304
Tests which did not
From: George Dunlap
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 command-line would change
the limit for all guests on the system.
Later, per-domain limits for t
On 28/11/2019, 04:09, "Jan Beulich" wrote:
On 28.11.2019 01:54, Stefano Stabellini wrote:
> On Thu, 26 Sep 2019, Lars Kurth wrote:
>> From: Lars Kurth
>>
>> This document highlights what reviewers such as maintainers and
committers look
>> for when reviewing code. It
On 28/11/2019 10:17, George Dunlap wrote:
>> On Nov 28, 2019, at 9:55 AM, Jan Beulich wrote:
> Has anyone actually tried building a livepatch with this change in place?
Actually - what is your concern here? The exact spelling of symbols
names should be of no interest to the tool. Aft
On 28.11.2019 12:39, Roger Pau Monné wrote:
> On Thu, Nov 28, 2019 at 12:03:47PM +0100, Jan Beulich wrote:
>> At the time the pending EOI stack was introduced there were no
>> internally used IRQs which would have the LAPIC EOI issued from the
>> ->end() hook. This had then changed with the introdu
On 28.11.2019 14:06, Lars Kurth wrote:
> I can certainly add something on the timing , along the lines of
> * For complex series, consider the time it takes to do reviews (maybe with a
> guide of LOC per hour) and give reviewers enough time to
> * For series with design issues or large questions,
On 28.11.2019 14:10, Andrew Cooper wrote:
> On 28/11/2019 10:17, George Dunlap wrote:
>>> On Nov 28, 2019, at 9:55 AM, Jan Beulich wrote:
>> Has anyone actually tried building a livepatch with this change in place?
> Actually - what is your concern here? The exact spelling of symbols
>
On 28.11.2019 13:15, Sergey Dyasli wrote:
> Applying the patch didn't end up well for my test LP (from another thread):
>
> Perform full initial build with 8 CPU(s)...
> Reading special section data
> Apply patch and build with 8 CPU(s)...
> Unapply patch and build with 8 CPU(s)...
> Extracting ne
On Thu, Nov 28, 2019 at 4:44 AM Andrew Cooper wrote:
>
> c/s d0a699a389f1 "x86/monitor: add support for descriptor access events"
> introduced logic looking for what appeared to be exitinfo (not that this
> exists in SVM - exitinfo1 or 2 do), but actually passed the exit IDT vectoring
> informatio
> -Original Message-
> From: Paul Durrant
> Sent: 28 November 2019 12:51
> To: xen-devel@lists.xenproject.org
> Cc: George Dunlap ; Durrant, Paul
> ; Ian Jackson ; Wei Liu
> ; Andrew Cooper ; George Dunlap
> ; Jan Beulich ; Julien
> Grall ; Konrad Rzeszutek Wilk ;
> Stefano Stabellini ; An
On 28/11/2019 12:10, Andrew Cooper wrote:
> On 28/11/2019 11:03, Jan Beulich wrote:
>> Notes:
>>
>> - In principle we could get away without the check_eoi_deferral flag.
>> I've introduced it just to make sure there's as little change as
>> possible to unaffected paths.
>> - Similarly the cpu_h
On 11/28/19 1:49 PM, Jan Beulich wrote:
> On 28.11.2019 13:15, Sergey Dyasli wrote:
>> Applying the patch didn't end up well for my test LP (from another thread):
>>
>> Perform full initial build with 8 CPU(s)...
>> Reading special section data
>> Apply patch and build with 8 CPU(s)...
>> Unapply p
flight 144346 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144346/
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 1
On 28.11.2019 14:54, Ross Lagerwall wrote:
> On 11/28/19 1:49 PM, Jan Beulich wrote:
>> On 28.11.2019 13:15, Sergey Dyasli wrote:
>>> Applying the patch didn't end up well for my test LP (from another thread):
>>>
>>> Perform full initial build with 8 CPU(s)...
>>> Reading special section data
>>>
From: George Dunlap
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 command-line would change
the limit for all guests on the system.
Later, per-domain limits for t
On 28.11.2019 14:53, Andrew Cooper wrote:
> On 28/11/2019 12:10, Andrew Cooper wrote:
>> On 28/11/2019 11:03, Jan Beulich wrote:
>>> Notes:
>>>
>>> - In principle we could get away without the check_eoi_deferral flag.
>>> I've introduced it just to make sure there's as little change as
>>> poss
On 28/11/2019, 07:37, "Jan Beulich" wrote:
On 28.11.2019 14:06, Lars Kurth wrote:
> I can certainly add something on the timing , along the lines of
> * For complex series, consider the time it takes to do reviews (maybe
with a guide of LOC per hour) and give reviewers enough time
On 11/28/19 1:44 PM, Andrew Cooper wrote:
> c/s d0a699a389f1 "x86/monitor: add support for descriptor access events"
> introduced logic looking for what appeared to be exitinfo (not that this
> exists in SVM - exitinfo1 or 2 do), but actually passed the exit IDT vectoring
> information. There is n
On Thu, Nov 28, 2019 at 02:33:08PM +0100, Jan Beulich wrote:
> On 28.11.2019 12:39, Roger Pau Monné wrote:
> > On Thu, Nov 28, 2019 at 12:03:47PM +0100, Jan Beulich wrote:
> >> At the time the pending EOI stack was introduced there were no
> >> internally used IRQs which would have the LAPIC EOI is
On 28.11.2019 15:13, Roger Pau Monné wrote:
> On Thu, Nov 28, 2019 at 02:33:08PM +0100, Jan Beulich wrote:
>> On 28.11.2019 12:39, Roger Pau Monné wrote:
>>> On Thu, Nov 28, 2019 at 12:03:47PM +0100, Jan Beulich wrote:
At the time the pending EOI stack was introduced there were no
intern
On 28.11.2019 10:55, Jan Beulich wrote:
> On 27.11.2019 19:17, Andrew Cooper wrote:
>> On 21/11/2019 08:34, Jan Beulich wrote:
>>> On 20.11.2019 18:13, Andrew Cooper wrote:
On 20/11/2019 16:40, Jürgen Groß wrote:
> On 20.11.19 17:30, Jan Beulich wrote:
>> On 08.11.2019 12:18, Jan Beuli
On 11/28/19 1:10 PM, Andrew Cooper wrote:
> On 28/11/2019 10:17, George Dunlap wrote:
>>> On Nov 28, 2019, at 9:55 AM, Jan Beulich wrote:
>> Has anyone actually tried building a livepatch with this change in place?
> Actually - what is your concern here? The exact spelling of symbols
>
flight 144344 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144344/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail REGR. vs. 144323
Tests which did not succeed
On Thu, Nov 28, 2019 at 03:19:50PM +0100, Jan Beulich wrote:
> On 28.11.2019 15:13, Roger Pau Monné wrote:
> > On Thu, Nov 28, 2019 at 02:33:08PM +0100, Jan Beulich wrote:
> >> On 28.11.2019 12:39, Roger Pau Monné wrote:
> >>> On Thu, Nov 28, 2019 at 12:03:47PM +0100, Jan Beulich wrote:
> At
On 28.11.2019 13:44, Andrew Cooper wrote:
> c/s d0a699a389f1 "x86/monitor: add support for descriptor access events"
> introduced logic looking for what appeared to be exitinfo (not that this
> exists in SVM - exitinfo1 or 2 do), but actually passed the exit IDT vectoring
> information. There is
On Wed, Nov 27, 2019 at 01:44:52PM -0500, Pavel Tatashin wrote:
> We currently duplicate the logic to enable/disable uaccess via TTBR0,
> with C functions and assembly macros. This is a maintenenace burden
> and is liable to lead to subtle bugs, so let's get rid of the assembly
> macros, and always
The patch "build: provide option to disambiguate symbol names" changes
ENFORCE_UNIQUE_SYMBOLS so that gcc generates output to a temporary file
and then objcopy is used to create the final object file. This breaks
livepatch-build's interposition of GCC to capture the changed object
files so intercep
On 11/28/19 1:57 PM, Jan Beulich wrote:
> On 28.11.2019 14:54, Ross Lagerwall wrote:
>> On 11/28/19 1:49 PM, Jan Beulich wrote:
>>> On 28.11.2019 13:15, Sergey Dyasli wrote:
Applying the patch didn't end up well for my test LP (from another thread):
Perform full initial build with 8
On 11/27/19 10:32 PM, Hans van Kranenburg wrote:
> Hi all,
>
> On 11/27/19 12:13 PM, Durrant, Paul wrote:
>>> -Original Message-
>>> From: Ian Jackson
>>> Sent: 27 November 2019 11:10
>>> [...]
>>> Subject: RE: [Xen-devel] [PATCH for-4.13 2/2] Rationalize max_grant_frames
>>> and max_mapt
On Thu, Nov 28, 2019 at 01:10:05PM +, Andrew Cooper wrote:
> On 28/11/2019 10:17, George Dunlap wrote:
> >> On Nov 28, 2019, at 9:55 AM, Jan Beulich wrote:
> > Has anyone actually tried building a livepatch with this change in
> > place?
> Actually - what is your concern here? Th
Hello,
Andrew Cooper writes:
> c/s d0a699a389f1 "x86/monitor: add support for descriptor access events"
> introduced logic looking for what appeared to be exitinfo (not that this
> exists in SVM - exitinfo1 or 2 do), but actually passed the exit IDT vectoring
> information. There is never any
On 28/11/2019 14:51, Ross Lagerwall wrote:
> The patch "build: provide option to disambiguate symbol names" changes
> ENFORCE_UNIQUE_SYMBOLS so that gcc generates output to a temporary file
> and then objcopy is used to create the final object file. This breaks
> livepatch-build's interposition of
On 28/11/2019 14:00, Jan Beulich wrote:
> On 28.11.2019 14:53, Andrew Cooper wrote:
>> On 28/11/2019 12:10, Andrew Cooper wrote:
>>> On 28/11/2019 11:03, Jan Beulich wrote:
Notes:
- In principle we could get away without the check_eoi_deferral flag.
I've introduced it just to
On 11/28/19 3:54 PM, George Dunlap wrote:
> On 11/27/19 10:32 PM, Hans van Kranenburg wrote:
>> Hi all,
>>
>> On 11/27/19 12:13 PM, Durrant, Paul wrote:
-Original Message-
From: Ian Jackson
Sent: 27 November 2019 11:10
[...]
Subject: RE: [Xen-devel] [PATCH for-4.13
On 28.11.19 16:33, Hans van Kranenburg wrote:
On 11/28/19 3:54 PM, George Dunlap wrote:
On 11/27/19 10:32 PM, Hans van Kranenburg wrote:
Hi all,
On 11/27/19 12:13 PM, Durrant, Paul wrote:
-Original Message-
From: Ian Jackson
Sent: 27 November 2019 11:10
[...]
Subject: RE: [Xen-devel]
On 26.11.19 13:03, Andrew Cooper wrote:
These patches want backporting due to the severity of patch 2. They should
therefore be considered for 4.13 at this point.
Andrew Cooper (3):
x86/vtx: Fix fault semantics for early task switch failures
x86/svm: Always intercept ICEBP
x86/svm: Wri
On 28.11.2019 15:30, Roger Pau Monné wrote:
> On Thu, Nov 28, 2019 at 03:19:50PM +0100, Jan Beulich wrote:
>> On 28.11.2019 15:13, Roger Pau Monné wrote:
>>> On Thu, Nov 28, 2019 at 02:33:08PM +0100, Jan Beulich wrote:
On 28.11.2019 12:39, Roger Pau Monné wrote:
> On Thu, Nov 28, 2019 at
On 28.11.2019 14:58, Paul Durrant wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -84,11 +84,43 @@ struct grant_table {
> struct grant_table_arch arch;
> };
>
> +static int __init parse_gnttab_limit(const char *param, const char *arg,
No __init please here and
On 28.11.2019 12:44, Andrew Cooper wrote:
> c/s d0a699a389f1 "x86/monitor: add support for descriptor access events"
> introduced logic looking for what appeared to be exitinfo (not that this
> exists in SVM - exitinfo1 or 2 do), but actually passed the exit IDT vectoring
> information. There is n
Jan Beulich writes ("Re: [PATCH-for-4.13 v4] Rationalize max_grant_frames and
max_maptrack_frames handling"):
> On 28.11.2019 14:58, Paul Durrant wrote:
> > uint32_t max_vcpus;
> > uint32_t max_evtchn_port;
> > -uint32_t max_grant_frames;
> > -uint32_t max_maptrack_frames;
> > +
> -Original Message-
> From: Jan Beulich
> Sent: 28 November 2019 16:37
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Anthony PERARD ;
> George Dunlap ; Roger Pau Monné
> ; Volodymyr Babchuk ;
> George Dunlap ; Ian Jackson
> ; Marek Marczykowski-Górecki
> ; S
On 28.11.19 17:36, Jan Beulich wrote:
On 28.11.2019 14:58, Paul Durrant wrote:
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -84,11 +84,43 @@ struct grant_table {
struct grant_table_arch arch;
};
+static int __init parse_gnttab_limit(const char *param, const char *a
On 28.11.2019 17:42, Durrant, Paul wrote:
>> From: Jan Beulich
>> Sent: 28 November 2019 16:37
>>
>> On 28.11.2019 14:58, Paul Durrant wrote:
>>> +val = simple_strtoul(arg, &e, 0);
>>> +if ( *e )
>>> +return -EINVAL;
>>> +
>>> +if ( val <= INT_MAX )
>>> +*valp = val;
On 28.11.2019 17:47, Jürgen Groß wrote:
> On 28.11.19 17:36, Jan Beulich wrote:
>> On 28.11.2019 14:58, Paul Durrant wrote:
>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -84,11 +84,43 @@ struct grant_table {
>>> struct grant_table_arch arch;
>>> };
>>>
>>>
From: George Dunlap
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 command-line would change
the limit for all guests on the system.
Later, per-domain limits for t
On 28.11.2019 17:42, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH-for-4.13 v4] Rationalize max_grant_frames and
> max_maptrack_frames handling"):
>> On 28.11.2019 14:58, Paul Durrant wrote:
>>> uint32_t max_vcpus;
>>> uint32_t max_evtchn_port;
>>> -uint32_t max_grant_frames;
flight 144350 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144350/
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 1
On Thu, 28 Nov 2019, Julien Grall wrote:
> > In both cases I see no reason to keep wrong code.
> >
> > Either the patch will let run Linux 5.4 fine - then the patch should
> > definitely be taken.
> That's up to Stefano and Peng to provide me information why this is fine.
> FAOD, the current justi
On Nov 28, 2019, at 05:12, Jan Beulich wrote:
>
> On 28.11.2019 01:54, Stefano Stabellini wrote:
>>> On Thu, 26 Sep 2019, Lars Kurth wrote:
>>> From: Lars Kurth
>>>
>>> This document highlights what reviewers such as maintainers and committers
>>> look
>>> for when reviewing code. It sets exp
On Thu, 28 Nov 2019, Jan Beulich wrote:
> On 28.11.2019 01:54, Stefano Stabellini wrote:
> > On Thu, 26 Sep 2019, Lars Kurth wrote:
> >> From: Lars Kurth
> >>
> >> This document highlights what reviewers such as maintainers and committers
> >> look
> >> for when reviewing code. It sets expectatio
On Nov 28, 2019, at 09:05, Lars Kurth wrote:
>
> On 28/11/2019, 07:37, "Jan Beulich" wrote:
>
>>On 28.11.2019 14:06, Lars Kurth wrote:
>> I can certainly add something on the timing , along the lines of
>> * For complex series, consider the time it takes to do reviews (maybe with a
>> gui
On Thu, 28 Nov 2019, Jan Beulich wrote:
> On 28.11.2019 01:56, Stefano Stabellini wrote:
> > On Thu, 26 Sep 2019, Lars Kurth wrote:
> >> +This could take for example the form of
> >> +> Do you think it would be useful for the code to do XXX?
> >> +> I can imagine a user wanting to do YYY (and XXX
On Thu, 28 Nov 2019, Wei Liu wrote:
> On Thu, Nov 28, 2019 at 11:30:34AM +0100, Jürgen Groß wrote:
> > On 28.11.19 11:15, Wei Liu wrote:
> > > On Wed, Nov 27, 2019 at 06:24:58PM -0800, Stefano Stabellini wrote:
> > > > libxl_arm_acpi.c is using BUILD_BUG_ON but it is not including
> > > > xen-tools
On Thu, 28 Nov 2019, 18:09 Stefano Stabellini,
wrote:
> On Thu, 28 Nov 2019, Julien Grall wrote:
> > > In both cases I see no reason to keep wrong code.
> > >
> > > Either the patch will let run Linux 5.4 fine - then the patch should
> > > definitely be taken.
> > That's up to Stefano and Peng to
flight 144352 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144352/
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 1
On 11/28/19 3:45 AM, Juergen Gross wrote:
> -
> static void __xen_evtchn_do_upcall(void)
> {
> struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
> - int cpu = get_cpu();
> - unsigned count;
> + int cpu = smp_processor_id();
>
> do {
> vcpu_info->evtc
On 11/28/19 3:48 AM, Jürgen Groß wrote:
> On 07.11.19 12:15, Juergen Gross wrote:
>> The Xen gntdev driver's checking of the number of allowed mapped pages
>> is in need of some sanitizing work.
>>
>> Changes in V2:
>> - enhanced commit message of patch 1 (Andrew Cooper)
>>
>> Juergen Gross (2):
>>
On 11/28/19 5:23 AM, Jan Beulich wrote:
> On 28.11.2019 10:38, Paul Durrant wrote:
>
>> --- a/xen/arch/x86/cpu/vpmu.c
>> +++ b/xen/arch/x86/cpu/vpmu.c
>> @@ -576,11 +576,36 @@ static void vpmu_arch_destroy(struct vcpu *v)
>>
>> vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
>> }
>> +
>
1 - 100 of 110 matches
Mail list logo
