Finally had time to do a v2. Changes are in each patch.
Brian Woods (2):
arm,smmu: switch to using iommu_fwspec functions
arm,smmu: add support for generic DT bindings
xen/drivers/passthrough/arm/smmu.c| 147 --
xen/drivers/passthrough/device_tree.c |
Modify the smmu driver so that it uses the iommu_fwspec helper
functions. This means both ARM IOMMU drivers will both use the
iommu_fwspec helper functions.
Signed-off-by: Brian Woods
---
Interested in if combining the legacy and generic bindings paths are
worth or if Xen plans to depreicate
Restructure some of the code and add supporting functions for adding
generic device tree (DT) binding support. This will allow for using
current Linux device trees with just modifying the chosen field to
enable Xen.
Signed-off-by: Brian Woods
---
Just realized that I'm fairly sure I need to do
flight 152067 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152067/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 18 guest-localmigrate/x10 fail REGR. vs.
152045
On Tue, 21 Jul 2020, Boris Ostrovsky wrote:
> >> +static int xen_setup_pm_notifier(void)
> >> +{
> >> + if (!xen_hvm_domain())
> >> + return -ENODEV;
> >>
> >> I forgot --- what did we decide about non-x86 (i.e. ARM)?
> > It would be great to support
On Tue, Jul 21, 2020 at 10:30:18AM +0200, Roger Pau Monné wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> Marek: I'm adding you in case you could be
On 7/21/20 12:12 PM, Hayato Ohhashi wrote:
> If the TSC frequency is known from the pvclock page,
> the TSC frequency does not need to be recalibrated.
> We can avoid recalibration by setting X86_FEATURE_TSC_KNOWN_FREQ.
>
> Signed-off-by: Hayato Ohhashi
Reviewed-by: Boris Ostrovsky
flight 152068 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152068/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 02539e900854488343a1efa435d4dded1ddd66a2
baseline version:
ovmf
>> +static int xen_setup_pm_notifier(void)
>> +{
>> + if (!xen_hvm_domain())
>> + return -ENODEV;
>>
>> I forgot --- what did we decide about non-x86 (i.e. ARM)?
> It would be great to support that however, its out of
> scope for this patch set.
Hi Oleksandr,
On 21/07/2020 19:16, Oleksandr wrote:
On 21.07.20 17:27, Julien Grall wrote:
On a similar topic, I am a bit surprised you didn't encounter memory
exhaustion when trying to use virtio. Because on how Linux currently
works (see XSA-300), the backend domain as to have a least as
On Mon, 20 Jul 2020, Rob Herring wrote:
> On Mon, Jul 20, 2020 at 5:24 PM Stefano Stabellini
> wrote:
> >
> > + Rob Herring
> >
> > On Fri, 17 Jul 2020, Bertrand Marquis wrote:
> > > >> Regarding the DT entry, this is not coming from us and this is already
> > > >> defined this way in existing
flight 152077 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152077/
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
This is going to be useful soon.
No functional change.
Signed-off-by: Ian Jackson
---
Osstest/Executive.pm | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
index 8e8b3d33..621153ee 100644
--- a/Osstest/Executive.pm
+++
No functional change.
Signed-off-by: Ian Jackson
---
Osstest/Executive.pm | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
index 3cd37c14..c966a1be 100644
--- a/Osstest/Executive.pm
+++ b/Osstest/Executive.pm
@@ -1146,7
Right now this is pointless since the Perl code doesn't need it. But
this row is going to be part of a WITH clause soon.
No functional change.
Diffs to two example queries (from the Perl DBI trace):
SELECT f.flight AS flight,
+ j.job AS job,
Our spec. says we return nulls for started and status if we don't find
a job matching the host spec.
The way this works right now is that we look up the nonexistent
entries in $refs->[0]. This is not really brilliant and is going to
be troublesome as we continue to refactor.
Provide these
Stuff the two queries together: we use the firsty query as a WITH
clause. This is significantly faster, perhaps because the query
optimiser does a better job but probably just because it saves on
round trips.
No functional change.
Perf: subjectively this seemed to help when the cache was cold.
If we are looking for a particular step then we will ignore jobs
without that step, so any job which was truncated before it will be
ignored.
Otherwise we are looking for the whole job duration and a truncated
job is not a good representative.
This is a bugfix (to duration estimation), not a
After we refactor this query then we can enable the index use.
(Both of these things together in this commit because I haven't perf
tested the version with just the refactoring.)
(We have provided an index that can answer this question really
quickly if a version is specified. But the query
$jcheckq is redundant: we looked this up right at the start.
This is not expected to speed things up very much, but it makes things
somewhat cleaner and clearer.
Signed-off-by: Ian Jackson
---
sg-report-flight | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git
This removes some nondeterminism from the output.
Signed-off-by: Ian Jackson
---
sg-report-flight | 1 +
1 file changed, 1 insertion(+)
diff --git a/sg-report-flight b/sg-report-flight
index 927ea37d..70def778 100755
--- a/sg-report-flight
+++ b/sg-report-flight
@@ -813,6 +813,7 @@ END
Specifically, we narrow the initial query to flights which have at
least some job with the built_revision_foo we are looking for.
This condition is strictly broader than that implemented inside the
flight search loop, so there is no functional change.
Perf: runtime of my test case now
Perf: runtime of my test case now ~11s
Example query before (from the Perl DBI trace):
SELECT * FROM flights JOIN steps USING (flight)
WHERE (branch='xen-unstable')
AND job=? and testid=? and status='pass'
AND ( (TRUE AND flight <= 151903) AND
In afe851ca1771e5da6395b596afa69e509dbbc278
sg-report-flight: When justifying, disregard out-of-flight build jobs
we narrowed sg-report-flight's search algorith.
An extensive justification is in the commit message. I think much of
this information belongs in-tree, so c it (with slight edits)
osstest was taking far too long calculating what test failures were
regressions, and generating the email and web reports. The slow part
was analysing the test history, mostly because it ended up doing a lot
of dumb scans of large tables.
In this series I fix this problem for sg-report-flight: I
While we're here, convert this EXISTS subquery to a JOIN.
Perf: runtime of my test case now ~200-300s.
Example query before (from the Perl DBI trace):
SELECT * FROM (
SELECT DISTINCT flight, blessing
FROM flights
JOIN runvars r1 USING (flight)
These indexes allow very fast lookup of "relevant" flights eg when
trying to justify failures.
In my ad-hoc test case, these indices (along with the subsequent
changes to sg-report-flight and Executive.pm, reduce the runtime of
sg-report-flight from 2-3ks (unacceptably long!) to as little as
5-7s
On 21.07.20 17:27, Julien Grall wrote:
Hi,
Hello
On a similar topic, I am a bit surprised you didn't encounter memory
exhaustion when trying to use virtio. Because on how Linux currently
works (see XSA-300), the backend domain as to have a least as much RAM
as the domain it serves.
On 21.07.20 17:27, Julien Grall wrote:
Hi,
Hello Julien
On 17/07/2020 19:34, Oleksandr wrote:
On 17.07.20 18:00, Roger Pau Monné wrote:
requires
some implementation to forward guest MMIO access to a device model.
And as
it
turned out the Xen on x86 contains most of the pieces to be
... to simplify the default cases.
There are multiple errors with the handling of these three MSRs, but they are
deliberately not addressed this point.
This removes the dance converting -1/0/1 into X86EMUL_*, allowing for the
removal of the 'ret' variable.
While cleaning this up, drop the
On 21/07/2020 17:09, Oleksandr wrote:
>
> On 21.07.20 17:58, André Przywara wrote:
>> On 21/07/2020 15:52, Oleksandr wrote:
>>> On 21.07.20 17:32, André Przywara wrote:
On 21/07/2020 14:43, Julien Grall wrote:
>>> Hello Andre, Julien
>>>
>>>
> (+ Andre)
>
> Hi Oleksandr,
>
flight 152061 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152061/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-amd 16 guest-localmigratefail REGR. vs. 152043
On Tue, 21 Jul 2020, Julien Grall wrote:
> Hi Alex,
>
> Thank you for your feedback!
>
> On 21/07/2020 15:15, Alex Bennée wrote:
> > Julien Grall writes:
> >
> > > (+ Andree for the vGIC).
> > >
> > > Hi Stefano,
> > >
> > > On 20/07/2020 21:38, Stefano Stabellini wrote:
> > > > On Fri, 17
On Tue, 21 Jul 2020, Alex Bennée wrote:
> Julien Grall writes:
>
> > Hi Stefano,
> >
> > On 20/07/2020 21:37, Stefano Stabellini wrote:
> >> On Mon, 20 Jul 2020, Roger Pau Monné wrote:
> >>> On Mon, Jul 20, 2020 at 10:40:40AM +0100, Julien Grall wrote:
>
>
> On 20/07/2020 10:17,
On 21.07.20 17:58, André Przywara wrote:
On 21/07/2020 15:52, Oleksandr wrote:
On 21.07.20 17:32, André Przywara wrote:
On 21/07/2020 14:43, Julien Grall wrote:
Hello Andre, Julien
(+ Andre)
Hi Oleksandr,
On 21/07/2020 13:26, Oleksandr wrote:
On 20.07.20 23:38, Stefano Stabellini
On 21.07.20 12:02, Colin King wrote:
From: Colin Ian King
The pointer bitmap is being initialized with a plain integer 0,
fix this by initializing it with a NULL instead.
Cleans up sparse warning:
arch/x86/xen/enlighten_pv.c:876:27: warning: Using plain integer
as NULL pointer
Signed-off-by:
flight 152074 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152074/
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
On 21/07/2020 15:52, Oleksandr wrote:
>
> On 21.07.20 17:32, André Przywara wrote:
>> On 21/07/2020 14:43, Julien Grall wrote:
>
> Hello Andre, Julien
>
>
>>> (+ Andre)
>>>
>>> Hi Oleksandr,
>>>
>>> On 21/07/2020 13:26, Oleksandr wrote:
On 20.07.20 23:38, Stefano Stabellini wrote:
>
On Tue, Jul 21, 2020 at 07:44:10AM -0700, Elliott Mitchell wrote:
> On Tue, Jul 21, 2020 at 12:26:45PM +, Wei Liu wrote:
> > On Fri, Jul 17, 2020 at 08:31:21PM -0700, Elliott Mitchell wrote:
> > > This partially reverts commit 16504669c5cbb8b195d20412aadc838da5c428f7.
> >
> > Ok, so this
On 21.07.20 17:32, André Przywara wrote:
On 21/07/2020 14:43, Julien Grall wrote:
Hello Andre, Julien
(+ Andre)
Hi Oleksandr,
On 21/07/2020 13:26, Oleksandr wrote:
On 20.07.20 23:38, Stefano Stabellini wrote:
For instance, what's your take on notifications with virtio-mmio? How
are
On Tue, Jul 21, 2020 at 12:26:45PM +, Wei Liu wrote:
> On Fri, Jul 17, 2020 at 08:31:21PM -0700, Elliott Mitchell wrote:
> > This partially reverts commit 16504669c5cbb8b195d20412aadc838da5c428f7.
>
> Ok, so this commit is really old.
Yup. It will still be visible in `git blame
Hi Alex,
Thank you for your feedback!
On 21/07/2020 15:15, Alex Bennée wrote:
Julien Grall writes:
(+ Andree for the vGIC).
Hi Stefano,
On 20/07/2020 21:38, Stefano Stabellini wrote:
On Fri, 17 Jul 2020, Oleksandr wrote:
*A few word about solution:*
As it was mentioned at [1], in order
On 21/07/2020 14:43, Julien Grall wrote:
> (+ Andre)
>
> Hi Oleksandr,
>
> On 21/07/2020 13:26, Oleksandr wrote:
>> On 20.07.20 23:38, Stefano Stabellini wrote:
>>> For instance, what's your take on notifications with virtio-mmio? How
>>> are they modelled today? Are they good enough or do we
Hi,
On 17/07/2020 19:34, Oleksandr wrote:
On 17.07.20 18:00, Roger Pau Monné wrote:
requires
some implementation to forward guest MMIO access to a device model.
And as
it
turned out the Xen on x86 contains most of the pieces to be able to
use that
transport (via existing IOREQ concept).
flight 152058 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152058/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
151065
Julien Grall writes:
> (+ Andree for the vGIC).
>
> Hi Stefano,
>
> On 20/07/2020 21:38, Stefano Stabellini wrote:
>> On Fri, 17 Jul 2020, Oleksandr wrote:
> *A few word about solution:*
> As it was mentioned at [1], in order to implement virtio-mmio Xen on Arm
Any plans for
Julien Grall writes:
> Hi Stefano,
>
> On 20/07/2020 21:37, Stefano Stabellini wrote:
>> On Mon, 20 Jul 2020, Roger Pau Monné wrote:
>>> On Mon, Jul 20, 2020 at 10:40:40AM +0100, Julien Grall wrote:
On 20/07/2020 10:17, Roger Pau Monné wrote:
> On Fri, Jul 17, 2020 at
(+ Andre)
Hi Oleksandr,
On 21/07/2020 13:26, Oleksandr wrote:
On 20.07.20 23:38, Stefano Stabellini wrote:
For instance, what's your take on notifications with virtio-mmio? How
are they modelled today? Are they good enough or do we need MSIs?
Notifications are sent from device (backend) to
On Tue, Jul 21, 2020 at 02:32:38PM +0100, Julien Grall wrote:
> Hi Roger,
>
> On 21/07/2020 14:25, Roger Pau Monné wrote:
> > On Tue, Jul 21, 2020 at 01:31:48PM +0100, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 20/07/2020 21:37, Stefano Stabellini wrote:
> > > > On Mon, 20 Jul 2020,
Hi Roger,
On 21/07/2020 14:25, Roger Pau Monné wrote:
On Tue, Jul 21, 2020 at 01:31:48PM +0100, Julien Grall wrote:
Hi Stefano,
On 20/07/2020 21:37, Stefano Stabellini wrote:
On Mon, 20 Jul 2020, Roger Pau Monné wrote:
On Mon, Jul 20, 2020 at 10:40:40AM +0100, Julien Grall wrote:
On
On Wed, Jul 15, 2020 at 05:25:01PM +0100, Ian Jackson wrote:
> From: Juergen Gross
>
> In order to harmonize names of library related make variables switch
> XEN_LIBXEN* names to XEN_libxen*, as all other related variables (e.g.
> CFLAGS_libxen*, SHDEPS_libxen*, ...) already use this pattern.
>
On Tue, Jul 21, 2020 at 01:31:48PM +0100, Julien Grall wrote:
> Hi Stefano,
>
> On 20/07/2020 21:37, Stefano Stabellini wrote:
> > On Mon, 20 Jul 2020, Roger Pau Monné wrote:
> > > On Mon, Jul 20, 2020 at 10:40:40AM +0100, Julien Grall wrote:
> > > >
> > > >
> > > > On 20/07/2020 10:17, Roger
(+ Andree for the vGIC).
Hi Stefano,
On 20/07/2020 21:38, Stefano Stabellini wrote:
On Fri, 17 Jul 2020, Oleksandr wrote:
*A few word about solution:*
As it was mentioned at [1], in order to implement virtio-mmio Xen on Arm
Any plans for virtio-pci? Arm seems to be moving to the PCI bus, and
> -Original Message-
> From: Roger Pau Monné
> Sent: 21 July 2020 12:53
> To: p...@xen.org
> Cc: 'Andrew Cooper' ; 'Jan Beulich'
> ; xen-
> de...@lists.xenproject.org; 'Wei Liu' ; Igor Druzhinin
>
> Subject: Re: vPT rework (and timer mode)
>
> On Mon, Jul 06, 2020 at 09:58:53AM +0100,
On 20.07.20 23:40, Stefano Stabellini wrote:
Hello Stefano
On Mon, 20 Jul 2020, Roger Pau Monné wrote:
On Mon, Jul 20, 2020 at 01:56:51PM +0300, Oleksandr wrote:
On 20.07.20 12:17, Roger Pau Monné wrote:
On Fri, Jul 17, 2020 at 09:34:14PM +0300, Oleksandr wrote:
On 17.07.20 18:00, Roger
On Tue, Jul 21, 2020 at 12:39:40PM +, Wei Liu wrote:
> On Tue, Jul 21, 2020 at 02:24:51PM +0200, Jürgen Groß wrote:
> > On 21.07.20 14:21, Wei Liu wrote:
> > > On Sat, Jul 18, 2020 at 08:18:27PM +0200, Samuel Thibault wrote:
> > > > Juergen Gross, le lun. 13 juil. 2020 10:42:30 +0200, a ecrit:
On Tue, Jul 21, 2020 at 02:24:51PM +0200, Jürgen Groß wrote:
> On 21.07.20 14:21, Wei Liu wrote:
> > On Sat, Jul 18, 2020 at 08:18:27PM +0200, Samuel Thibault wrote:
> > > Juergen Gross, le lun. 13 juil. 2020 10:42:30 +0200, a ecrit:
> > > > Mini-OS shouldn't use Xen internal paths for building.
Hi Stefano,
On 20/07/2020 21:37, Stefano Stabellini wrote:
On Mon, 20 Jul 2020, Roger Pau Monné wrote:
On Mon, Jul 20, 2020 at 10:40:40AM +0100, Julien Grall wrote:
On 20/07/2020 10:17, Roger Pau Monné wrote:
On Fri, Jul 17, 2020 at 09:34:14PM +0300, Oleksandr wrote:
On 17.07.20 18:00,
On 21/07/2020 13:16, Wei Liu wrote:
> On Tue, Jul 21, 2020 at 02:04:59PM +0200, Jan Beulich wrote:
>> We've grown to a mix of dashes and underscores - switch to consistent
>> naming in the hope that future additions will play by this.
>>
>> Signed-off-by: Jan Beulich
> Acked-by: Wei Liu
On 20.07.20 23:38, Stefano Stabellini wrote:
Hello Stefano
On Fri, 17 Jul 2020, Oleksandr wrote:
*A few word about solution:*
As it was mentioned at [1], in order to implement virtio-mmio Xen on Arm
Any plans for virtio-pci? Arm seems to be moving to the PCI bus, and
it would be very
On Fri, Jul 17, 2020 at 08:31:21PM -0700, Elliott Mitchell wrote:
> This partially reverts commit 16504669c5cbb8b195d20412aadc838da5c428f7.
Ok, so this commit is really old.
>
> Signed-off-by: Elliott Mitchell
> ---
> Doesn't look like much of 16504669c5cbb8b195d20412aadc838da5c428f7
>
On 21.07.20 14:21, Wei Liu wrote:
On Sat, Jul 18, 2020 at 08:18:27PM +0200, Samuel Thibault wrote:
Juergen Gross, le lun. 13 juil. 2020 10:42:30 +0200, a ecrit:
Mini-OS shouldn't use Xen internal paths for building. Import the
needed paths from Xen and fall back to the current values only if
Hi Paul,
On 21/07/2020 08:09, Paul Durrant wrote:
-Original Message-
From: Andrew Cooper
Sent: 20 July 2020 18:49
To: Julien Grall ; xen-devel@lists.xenproject.org
Cc: p...@xen.org; Julien Grall ; George Dunlap
; Ian
Jackson ; Jan Beulich ; Stefano
Stabellini
; Wei Liu
Subject: Re:
On Sat, Jul 18, 2020 at 08:18:27PM +0200, Samuel Thibault wrote:
> Juergen Gross, le lun. 13 juil. 2020 10:42:30 +0200, a ecrit:
> > Mini-OS shouldn't use Xen internal paths for building. Import the
> > needed paths from Xen and fall back to the current values only if
> > the import was not
On Tue, Jul 21, 2020 at 02:04:59PM +0200, Jan Beulich wrote:
> We've grown to a mix of dashes and underscores - switch to consistent
> naming in the hope that future additions will play by this.
>
> Signed-off-by: Jan Beulich
Acked-by: Wei Liu
On 28.05.2020 23:29, Dario Faggioli wrote:
> Dario Faggioli (7):
> xen: credit2: factor cpu to runqueue matching in a function
> xen: credit2: factor runqueue initialization in its own function.
> xen: cpupool: add a back-pointer from a scheduler to its pool
> xen: credit2:
We've grown to a mix of dashes and underscores - switch to consistent
naming in the hope that future additions will play by this.
Signed-off-by: Jan Beulich
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -75,7 +75,7 @@ static const char *const str_e1d[32] =
static const char
On Mon, Jul 06, 2020 at 09:58:53AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monné
> > Sent: 06 July 2020 09:32
> > To: p...@xen.org
> > Cc: 'Andrew Cooper' ; 'Jan Beulich'
> > ; xen-
> > de...@lists.xenproject.org; 'Wei Liu'
> > Subject: Re: vPT rework (and
On Mon, Jul 20, 2020 at 05:20:15PM +0200, Jan Beulich wrote:
> wakeup_32 sets %ds and %es to BOOT_DS, while leaving %fs at what
> wakeup_start did set it to, and %gs at whatever BIOS did load into it.
> All of this may end up confusing the first load_segments() to run on
> the BSP after resume, in
Back in 2013, commits
2e35afaefe64 ("PCI: pciehp: Add reset_slot() method")
608c388122c7 ("PCI: Add slot reset option to pci_dev_reset()")
introduced the callback pciehp_reset_slot() to the PCIe hotplug driver
and amended __pci_dev_reset() (today __pci_reset_function_locked()) to
invoke it
Guest tests shouldn't care about the capabilities or firmware of the
underlying hosts, so drop the request of specific freebsd-
hostflags for FreeBSD guest tests.
While there request the presence of the hvm hostflag since the FreeBSD
guest tests are run in HVM mode.
Signed-off-by: Roger Pau
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-15852 / XSA-329
version 3
Linux ioperm bitmap context switching issues
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
On Thu, Jul 02, 2020 at 04:10:57PM +0100, Andrew Cooper wrote:
[...]
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#define BUF_SIZE (16384 * XC_PAGE_SIZE)
>
> This hardcodes the size of the buffer which is configurable
On Tue, Jun 30, 2020 at 02:33:52PM +0200, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Add functions in libxc that use the new XEN_DOMCTL_vmtrace interface.
>
> Signed-off-by: Michal Leszczynski
Acked-by: Wei Liu
(Subject to acceptance of hypervisor patches)
On 21/07/2020 11:47, Jan Beulich wrote:
> On 21.07.2020 12:32, Andrew Cooper wrote:
>> On 21/07/2020 11:23, Jan Beulich wrote:
>>> --- a/tools/misc/xen-cpuid.c
>>> +++ b/tools/misc/xen-cpuid.c
>>> @@ -160,7 +160,7 @@ static const char *const str_7d0[32] =
>>> [ 2] = "avx512_4vnniw", [ 3] =
On 21.07.2020 12:32, Andrew Cooper wrote:
> On 21/07/2020 11:23, Jan Beulich wrote:
>> --- a/tools/misc/xen-cpuid.c
>> +++ b/tools/misc/xen-cpuid.c
>> @@ -160,7 +160,7 @@ static const char *const str_7d0[32] =
>> [ 2] = "avx512_4vnniw", [ 3] = "avx512_4fmaps",
>> [ 4] = "fsrm",
>>
>> -
On Thu, Jul 02, 2020 at 06:34:48PM +0100, Julien Grall wrote:
> Hi Wei,
>
> On 26/06/2020 12:08, Wei Liu wrote:
> > On Thu, Jun 11, 2020 at 03:57:37PM +0100, Julien Grall wrote:
> > > Hi all,
> > >
> > > kexec-tools has an option to load dynamically libxenctlr.so (not .so.4.x)
> > > (see [1]).
>
On Thu, Jul 16, 2020 at 02:21:33PM +0200, Jan Beulich wrote:
> Requested-by: Roger Pau Monné
> Signed-off-by: Jan Beulich
Acked-by: Wei Liu
This is much appreciated.
>
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -1,3 +1,22 @@
> +# There are a few fundamentally different
On Tue, Jul 21, 2020 at 08:13:28AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Nick Rosbrook
> > Sent: 21 July 2020 00:55
> > To: xen-devel@lists.xenproject.org
> > Cc: p...@xen.org; Nick Rosbrook ; George Dunlap
> > ;
> > Ian Jackson ; Wei Liu
> > Subject: [PATCH
On 21/07/2020 11:23, Jan Beulich wrote:
> --- a/tools/misc/xen-cpuid.c
> +++ b/tools/misc/xen-cpuid.c
> @@ -160,7 +160,7 @@ static const char *const str_7d0[32] =
> [ 2] = "avx512_4vnniw", [ 3] = "avx512_4fmaps",
> [ 4] = "fsrm",
>
> -/* 8 */[ 9] = "srbds-ctrl",
>
flight 152064 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152064/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On Wed, Jul 15, 2020 at 03:21:50PM +, Christian Lindig wrote:
>
>
> From: Edwin Török
> Sent: 15 July 2020 16:10
> To: xen-devel@lists.xenproject.org
> Cc: Edwin Torok; Christian Lindig; David Scott; Ian Jackson; Wei Liu; Igor
> Druzhinin
> Subject:
The standard memory access pattern once again should allow us to go
without a test harness addition beyond the EVEX Disp8-scaling one.
Signed-off-by: Jan Beulich
---
(SDE: -tgl)
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -214,6 +214,7 @@ int
> -Original Message-
> From: George Dunlap
> Sent: 21 July 2020 10:54
> To: p...@xen.org
> Cc: Andrew Cooper ; Nick Rosbrook
> ; xen-
> de...@lists.xenproject.org; Nick Rosbrook ; Ian
> Jackson
> ; Wei Liu
> Subject: Re: [PATCH for-4.14] golang/xenlight: fix code generation for python
From: Colin Ian King
The pointer bitmap is being initialized with a plain integer 0,
fix this by initializing it with a NULL instead.
Cleans up sparse warning:
arch/x86/xen/enlighten_pv.c:876:27: warning: Using plain integer
as NULL pointer
Signed-off-by: Colin Ian King
---
> On 21 Jul 2020, at 12:23 am, Stefano Stabellini
> wrote:
>
> On Fri, 17 Jul 2020, Bertrand Marquis wrote:
>>> On 17 Jul 2020, at 16:06, Jan Beulich wrote:
>>>
>>> On 17.07.2020 15:59, Bertrand Marquis wrote:
> On 17 Jul 2020, at 15:19, Jan Beulich wrote:
>
> On
> On Jul 21, 2020, at 10:23 AM, Paul Durrant wrote:
>
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 21 July 2020 10:21
>> To: p...@xen.org; 'Nick Rosbrook' ;
>> xen-devel@lists.xenproject.org
>> Cc: 'Nick Rosbrook' ; 'Ian Jackson'
>> ; 'George
>> Dunlap' ; 'Wei Liu'
>>
flight 152052 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152052/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
build-armhf-pvops
> -Original Message-
> From: Andrew Cooper
> Sent: 21 July 2020 10:21
> To: p...@xen.org; 'Nick Rosbrook' ;
> xen-devel@lists.xenproject.org
> Cc: 'Nick Rosbrook' ; 'Ian Jackson'
> ; 'George
> Dunlap' ; 'Wei Liu'
> Subject: Re: [PATCH for-4.14] golang/xenlight: fix code generation for
On 21/07/2020 08:13, Paul Durrant wrote:
>> -Original Message-
>> From: Nick Rosbrook
>> Sent: 21 July 2020 00:55
>> To: xen-devel@lists.xenproject.org
>> Cc: p...@xen.org; Nick Rosbrook ; George Dunlap
>> ;
>> Ian Jackson ; Wei Liu
>> Subject: [PATCH for-4.14] golang/xenlight: fix code
Marek: I'm adding you in case you could be able to give this a try and
make sure it doesn't break suspend for dom0.
On Tue, Jul 21, 2020 at 12:17:36AM +, Anchal Agarwal wrote:
> On Mon, Jul 20, 2020 at 11:37:05AM +0200, Roger Pau Monné wrote:
> > CAUTION: This email originated from outside of
On 20.07.2020 18:20, Julien Grall wrote:
> On 15/07/2020 11:40, Jan Beulich wrote:
>> A subsequent change will exclude domctl.c from getting built for a
>> particular configuration, yet the two functions get used from elsewhere.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/common/bitmap.c
>>
> -Original Message-
> From: Nick Rosbrook
> Sent: 21 July 2020 00:55
> To: xen-devel@lists.xenproject.org
> Cc: p...@xen.org; Nick Rosbrook ; George Dunlap
> ;
> Ian Jackson ; Wei Liu
> Subject: [PATCH for-4.14] golang/xenlight: fix code generation for python 2.6
>
> Before python
> -Original Message-
> From: Andrew Cooper
> Sent: 20 July 2020 18:49
> To: Julien Grall ; xen-devel@lists.xenproject.org
> Cc: p...@xen.org; Julien Grall ; George Dunlap
> ; Ian
> Jackson ; Jan Beulich ; Stefano
> Stabellini
> ; Wei Liu
> Subject: Re: [PATCH] SUPPORT.md: Spell
flight 152048 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152048/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cb38ace647231076acfc0c5bdd21d3aff43e4f83
baseline version:
ovmf
flight 152045 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152045/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 152031
On 20.07.2020 18:27, Jan Beulich wrote:
> On 20.07.2020 17:28, Andrew Cooper wrote:
>> On 16/07/2020 11:06, Jan Beulich wrote:
>>> ACCESS_ONCE() guarantees single access, but doesn't guarantee that
>>> the compiler wouldn't split this single access into multiple insns.
>>
>> ACCESS_ONCE() does
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-ovmf-amd64
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
98 matches
Mail list logo
