flight 150317 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150317/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
flight 150312 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150312/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 150271
test-amd64-amd64-xl-qemuu-win7-amd6
Apply a workaround for errata BA80, AAK120, AAM108, AAO67, BD59,
AAY54: Rapid Core C3/C6 Transition May Cause Unpredictable System
Behavior.
Limit maximum C state to C2 when SMT is enabled on the affected CPUs.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/cpu/intel.c | 37 +++
On 21.05.20 23:57, Boris Ostrovsky wrote:
On 5/21/20 2:46 PM, Marek Marczykowski-Górecki wrote:
On Thu, May 21, 2020 at 01:22:03PM -0400, Boris Ostrovsky wrote:
On 3/19/20 3:14 AM, Juergen Gross wrote:
There have been reports of races in evtchn_from_irq() where the info
pointer has been NULL.
On Thu, May 21, 2020 at 03:53:22PM -0700, Tamas K Lengyel wrote:
> When running shallow forks without device models it may be undesirable for Xen
> to inject interrupts. With Windows forks we have observed the kernel going
> into
> infinite loops when trying to process such interrupts. By disablin
On Thu, May 21, 2020 at 03:53:23PM -0700, Tamas K Lengyel wrote:
> Toolstack side for creating forks with interrupt injection disabled.
>
> Signed-off-by: Tamas K Lengyel
Reviewed-by: Roger Pau Monné
I have the same suggestion to use block instead of prohibit, so if you
agree to change it on p
Hi,
As a consequence of this fix, the following has been committed (I guess as a
consequence of regenerating the configure scripts):
diff --git a/tools/configure b/tools/configure
index 375430df3f..36596389b8 100755
--- a/tools/configure
+++ b/tools/configure
@@ -4678,6 +4678,10 @@ for ldflag in
On Fri, May 22, 2020 at 08:41:17AM +, Bertrand Marquis wrote:
> Hi,
>
> As a consequence of this fix, the following has been committed (I guess as a
> consequence of regenerating the configure scripts):
> diff --git a/tools/configure b/tools/configure
> index 375430df3f..36596389b8 100755
> -
On 5/18/20 6:04 PM, Denis Kirjanov wrote:
> The patch adds a new extra type to be able to diffirentiate
> between RX responses on xen-netfront side with the adjusted offset
> required for XDP processing.
>
> The offset value from a guest is passed via xenstore.
>
> Signed-off-by: Denis Kirjanov
>
> On May 19, 2020, at 2:54 AM, Jason Andryuk wrote:
>
> General idea is to allow freely set device_model_version and
> device_model_stubdomain_override and choose the right options based on this
> choice. Also, allow to specific path to stubdomain kernel/ramdisk, for
> greater
> flexibility.
CC’ing the release manager, since we’re past the last posting date
> On May 21, 2020, at 3:55 PM, Nick Rosbrook wrote:
>
> When generating documentation, pkg.go.dev and godoc.org assume a comment
> that immediately precedes the package declaration is a "package
> comment", and should be shown in
On 22/05/2020 09:09, Roger Pau Monne wrote:
> Apply a workaround for errata BA80, AAK120, AAM108, AAO67, BD59,
> AAY54: Rapid Core C3/C6 Transition May Cause Unpredictable System
> Behavior.
>
> Limit maximum C state to C2 when SMT is enabled on the affected CPUs.
C1
> Signed-off-by: Roger Pau Mo
On 5/22/20, Oleksandr Andrushchenko wrote:
> On 5/18/20 6:04 PM, Denis Kirjanov wrote:
>> The patch adds a new extra type to be able to diffirentiate
>> between RX responses on xen-netfront side with the adjusted offset
>> required for XDP processing.
>>
>> The offset value from a guest is passed
On 5/18/20, Denis Kirjanov wrote:
> The patch adds a new extra type to be able to diffirentiate
> between RX responses on xen-netfront side with the adjusted offset
> required for XDP processing.
>
> The offset value from a guest is passed via xenstore.
I'm going to send a new version for Linux w
On 5/22/20 12:17 PM, Denis Kirjanov wrote:
> On 5/22/20, Oleksandr Andrushchenko wrote:
>> On 5/18/20 6:04 PM, Denis Kirjanov wrote:
>>> The patch adds a new extra type to be able to diffirentiate
>>> between RX responses on xen-netfront side with the adjusted offset
>>> required for XDP processin
On 5/22/20, Oleksandr Andrushchenko wrote:
> On 5/22/20 12:17 PM, Denis Kirjanov wrote:
>> On 5/22/20, Oleksandr Andrushchenko
>> wrote:
>>> On 5/18/20 6:04 PM, Denis Kirjanov wrote:
The patch adds a new extra type to be able to diffirentiate
between RX responses on xen-netfront side wi
Hi,
> On 22 May 2020, at 10:05, Wei Liu wrote:
>
> On Fri, May 22, 2020 at 08:41:17AM +, Bertrand Marquis wrote:
>> Hi,
>>
>> As a consequence of this fix, the following has been committed (I guess as a
>> consequence of regenerating the configure scripts):
>> diff --git a/tools/configure
> -Original Message-
> From: George Dunlap
> Sent: 22 May 2020 10:14
> To: Nick Rosbrook
> Cc: xen-devel ; Nick Rosbrook
> ; Ian Jackson
> ; Wei Liu ; Paul Durrant
> Subject: Re: [PATCH] golang/xenlight: add an empty line after DO NOT EDIT
> comment
>
> CC’ing the release manager, sin
On 21/05/2020 22:43, Igor Druzhinin wrote:
> If a recalculation NPT fault hasn't been handled explicitly in
> hvm_hap_nested_page_fault() then it's potentially safe to retry -
> US bit has been re-instated in PTE and any real fault would be correctly
> re-raised next time.
>
> This covers a specifi
c/s 7efd9f3d45 ("libxl: Handle Linux stubdomain specific QEMU
options.") modified libl_types.idl. Run gengotypes.py again to update
the geneated golang bindings.
Signed-off-by: George Dunlap
---
CC: Nick Rosbrook
CC: Ian Jackson
CC: Wei Liu
---
tools/golang/xenlight/helpers.gen.go | 10 +
On 20.05.2020 17:13, Roger Pau Monné wrote:
> On Wed, May 20, 2020 at 10:56:26AM +0200, Jan Beulich wrote:
>> On 18.05.2020 16:51, Roger Pau Monné wrote:
>>> On Tue, Apr 28, 2020 at 08:30:12AM +0200, Jan Beulich wrote:
On 27.04.2020 22:11, Andrew Cooper wrote:
> On 27/04/2020 16:15, Jan Be
> -Original Message-
> From: Xen-devel On Behalf Of George
> Dunlap
> Sent: 22 May 2020 10:11
> To: Jason Andryuk
> Cc: Stefano Stabellini ; Julien Grall
> ; Samuel Thibault
> ; Wei Liu ; Andrew Cooper
> ; Jan
> Beulich ; Ian Jackson ; Anthony
> Perard
> ; xen-devel ;
> Daniel De Gra
On 20.05.2020 19:18, Roger Pau Monné wrote:
> I also assume that using no_caller_saved_registers when available or
> else keeping the current behavior is not an acceptable solution? FWIW,
> from a FreeBSD PoV I would be OK with that, as I don't think there are
> any supported targets with clang < 5
On Fri, May 22, 2020 at 09:37:51AM +, Bertrand Marquis wrote:
> Hi,
>
> > On 22 May 2020, at 10:05, Wei Liu wrote:
> >
> > On Fri, May 22, 2020 at 08:41:17AM +, Bertrand Marquis wrote:
> >> Hi,
> >>
> >> As a consequence of this fix, the following has been committed (I guess as
> >> a
On Fri, May 22, 2020 at 10:49:56AM +0100, George Dunlap wrote:
> c/s 7efd9f3d45 ("libxl: Handle Linux stubdomain specific QEMU
> options.") modified libl_types.idl. Run gengotypes.py again to update
libxl_types.idl.
> the geneated golang bindings.
>
Can we perhaps add a dependency on golang's
On 22/05/2020 10:45, Andrew Cooper wrote:
> On 21/05/2020 22:43, Igor Druzhinin wrote:
>> If a recalculation NPT fault hasn't been handled explicitly in
>> hvm_hap_nested_page_fault() then it's potentially safe to retry -
>> US bit has been re-instated in PTE and any real fault would be correctly
>
On 21.05.2020 18:46, Andrew Cooper wrote:
> On 05/05/2020 07:16, Jan Beulich wrote:
>> While the mere updating of ->pv_cr3 and ->root_pgt_changed aren't overly
>> expensive (but still needed only for the toggle_guest_mode() path), the
>> effect of the latter on the exit-to-guest path is not insigni
On Thu, May 21, 2020 at 10:43:58PM +0100, Igor Druzhinin wrote:
> If a recalculation NPT fault hasn't been handled explicitly in
> hvm_hap_nested_page_fault() then it's potentially safe to retry -
> US bit has been re-instated in PTE and any real fault would be correctly
> re-raised next time.
>
>
On 5/22/20 12:33 PM, Denis Kirjanov wrote:
> On 5/22/20, Oleksandr Andrushchenko wrote:
>> On 5/22/20 12:17 PM, Denis Kirjanov wrote:
>>> On 5/22/20, Oleksandr Andrushchenko
>>> wrote:
On 5/18/20 6:04 PM, Denis Kirjanov wrote:
> The patch adds a new extra type to be able to diffirentiat
On 22/05/2020 11:08, Roger Pau Monné wrote:
> On Thu, May 21, 2020 at 10:43:58PM +0100, Igor Druzhinin wrote:
>> If a recalculation NPT fault hasn't been handled explicitly in
>> hvm_hap_nested_page_fault() then it's potentially safe to retry -
>> US bit has been re-instated in PTE and any real fau
On 22/05/2020 11:05, Igor Druzhinin wrote:
> On 22/05/2020 10:45, Andrew Cooper wrote:
>> On 21/05/2020 22:43, Igor Druzhinin wrote:
>>> If a recalculation NPT fault hasn't been handled explicitly in
>>> hvm_hap_nested_page_fault() then it's potentially safe to retry -
>>> US bit has been re-instat
On Fri, May 22, 2020 at 11:58:40AM +0200, Jan Beulich wrote:
> On 20.05.2020 19:18, Roger Pau Monné wrote:
> > I also assume that using no_caller_saved_registers when available or
> > else keeping the current behavior is not an acceptable solution? FWIW,
> > from a FreeBSD PoV I would be OK with th
On Fri, May 22, 2020 at 11:14:24AM +0100, Igor Druzhinin wrote:
> On 22/05/2020 11:08, Roger Pau Monné wrote:
> > On Thu, May 21, 2020 at 10:43:58PM +0100, Igor Druzhinin wrote:
> >> If a recalculation NPT fault hasn't been handled explicitly in
> >> hvm_hap_nested_page_fault() then it's potentiall
The logic is completely undocumented and almost impossible to follow. It
actually uses return oriented programming. Rewrite it to conform to more
normal call mechanics, and leave a big comment explaining thing. As well as
the code being easier to follow, it will execute faster as it isn't fighti
On 22/05/2020 11:19, Andrew Cooper wrote:
> On 22/05/2020 11:05, Igor Druzhinin wrote:
>> On 22/05/2020 10:45, Andrew Cooper wrote:
>>> On 21/05/2020 22:43, Igor Druzhinin wrote:
If a recalculation NPT fault hasn't been handled explicitly in
hvm_hap_nested_page_fault() then it's potential
On 22/05/2020 11:23, Roger Pau Monné wrote:
> On Fri, May 22, 2020 at 11:14:24AM +0100, Igor Druzhinin wrote:
>> On 22/05/2020 11:08, Roger Pau Monné wrote:
>>> On Thu, May 21, 2020 at 10:43:58PM +0100, Igor Druzhinin wrote:
If a recalculation NPT fault hasn't been handled explicitly in
h
> On May 22, 2020, at 11:01 AM, Wei Liu wrote:
>
> On Fri, May 22, 2020 at 10:49:56AM +0100, George Dunlap wrote:
>> c/s 7efd9f3d45 ("libxl: Handle Linux stubdomain specific QEMU
>> options.") modified libl_types.idl. Run gengotypes.py again to update
>
> libxl_types.idl.
>
>> the geneated g
On 25/09/2019 16:25, Jan Beulich wrote:
> The bit is meaningful only for MOV-to-CR3 insns, not anywhere else, in
> particular not when loading nested guest state.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Paul Durrant
Acked-by: Andrew Cooper
On Fri, May 22, 2020 at 11:52:42AM +0200, Jan Beulich wrote:
> On 20.05.2020 17:13, Roger Pau Monné wrote:
> > OK, so I think I'm starting to understand this all. Sorry it's taken
> > me so long. So it's my understanding that diff != 0 can only happen in
> > Xen context, or when in an IST that has
On 25/09/2019 16:23, Jan Beulich wrote:
> When there's no XPTI-enabled PV domain at all, there's no need to issue
> respective TLB flushes. Hardwire opt_xpti_* to false when !PV, and
> record the creation of PV domains by bumping opt_xpti_* accordingly.
>
> As to the sticky opt_xpti_domu vs increme
On Fri, May 22, 2020 at 11:27:38AM +0100, Igor Druzhinin wrote:
> On 22/05/2020 11:23, Roger Pau Monné wrote:
> > On Fri, May 22, 2020 at 11:14:24AM +0100, Igor Druzhinin wrote:
> >> On 22/05/2020 11:08, Roger Pau Monné wrote:
> >>> On Thu, May 21, 2020 at 10:43:58PM +0100, Igor Druzhinin wrote:
>
On Fri, May 22, 2020 at 12:00:14PM +0100, Andrew Cooper wrote:
> On 25/09/2019 16:23, Jan Beulich wrote:
> > When there's no XPTI-enabled PV domain at all, there's no need to issue
> > respective TLB flushes. Hardwire opt_xpti_* to false when !PV, and
> > record the creation of PV domains by bumpin
On Fri, May 22, 2020 at 10:05:53AM +0100, Wei Liu wrote:
> On Fri, May 22, 2020 at 08:41:17AM +, Bertrand Marquis wrote:
> > Hi,
> >
> > As a consequence of this fix, the following has been committed (I guess as
> > a consequence of regenerating the configure scripts):
> > diff --git a/tools/
It is reported that [] was removed by autoconf, which caused the
following error:
./configure: line 4681: -z: command not found
Switch to test. That's what is used throughout our configure scripts.
Reported-by: Bertrand Marquis
Fixes: 8a6b1665d987 ("configure: also add EXTRA_PREFIX to {CPP/LD
On 25/09/2019 16:23, Jan Beulich wrote:
> I can't see any technical or performance reason why we should treat
> 32-bit PV different from 64-bit PV in this regard.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Roger Pau Monné
There are technical reasons, and a very good perf reason not to...
The
> On 22 May 2020, at 12:19, Roger Pau Monné wrote:
>
> On Fri, May 22, 2020 at 10:05:53AM +0100, Wei Liu wrote:
>> On Fri, May 22, 2020 at 08:41:17AM +, Bertrand Marquis wrote:
>>> Hi,
>>>
>>> As a consequence of this fix, the following has been committed (I guess as
>>> a consequence of
On Fri, May 22, 2020 at 11:40:06AM +, Bertrand Marquis wrote:
>
>
> > On 22 May 2020, at 12:19, Roger Pau Monné wrote:
> >
> > On Fri, May 22, 2020 at 10:05:53AM +0100, Wei Liu wrote:
> >> On Fri, May 22, 2020 at 08:41:17AM +, Bertrand Marquis wrote:
> >>> Hi,
> >>>
> >>> As a conseque
On 22.05.2020 13:00, Andrew Cooper wrote:
> On 25/09/2019 16:23, Jan Beulich wrote:
>> When there's no XPTI-enabled PV domain at all, there's no need to issue
>> respective TLB flushes. Hardwire opt_xpti_* to false when !PV, and
>> record the creation of PV domains by bumping opt_xpti_* accordingly
On 22/05/2020 12:13, Roger Pau Monné wrote:
> On Fri, May 22, 2020 at 12:00:14PM +0100, Andrew Cooper wrote:
>> On 25/09/2019 16:23, Jan Beulich wrote:
>>> When there's no XPTI-enabled PV domain at all, there's no need to issue
>>> respective TLB flushes. Hardwire opt_xpti_* to false when !PV, and
On 22.05.2020 12:48, Roger Pau Monné wrote:
> On Fri, May 22, 2020 at 11:52:42AM +0200, Jan Beulich wrote:
>> On 20.05.2020 17:13, Roger Pau Monné wrote:
>>> OK, so I think I'm starting to understand this all. Sorry it's taken
>>> me so long. So it's my understanding that diff != 0 can only happen
All,
I am pleased to announce the release of Xen 4.12.3. This is available
immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.12
(tag RELEASE-4.12.3) or from the XenProject download page
https://xenproject.org/downloads/xen-project-archive
All,
I am pleased to announce the release of Xen 4.13.1. This is available
immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.13
(tag RELEASE-4.13.1) or from the XenProject download page
https://xenproject.org/downloads/xen-project-archive
flight 150315 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150315/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150285
test-armhf-armhf-libvirt 14 save
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
On 21.05.2020 10:44, Andrew Cooper wrote:
> The 'T' debugkey reliably wedges on one of my systems, which has a sparse
> APIC_ID layout due to a non power-of-2 number of cores per socket. The
> per_cpu(dt_cpu_data, cpu) calcution falls over the deliberately non-canonical
> poison value.
>
> Signed
Tamas K Lengyel writes ("[PATCH for-4.14 2/2] tools/libxc: xc_memshr_fork with
interrupts disabled"):
> Toolstack side for creating forks with interrupt injection disabled.
Acked-by: Ian Jackson
Subject to the hypervisor folks being happy with the underlying
feature.
Ian.
On 22.05.2020 13:11, Roger Pau Monné wrote:
> That being said, I also don't like the fact that logdity is handled
> differently between EPT and NPT, as on EPT it's handled as a
> misconfig while on NPT it's handled as a violation.
Because, well, there is no concept of misconfig in NPT.
Jan
Wei Liu writes ("[PATCH] m4: use test instead of []"):
> It is reported that [] was removed by autoconf, which caused the
> following error:
>
> ./configure: line 4681: -z: command not found
>
> Switch to test. That's what is used throughout our configure scripts.
The reason for [ ] being remo
On 22/05/2020 14:04, Jan Beulich wrote:
> On 22.05.2020 13:11, Roger Pau Monné wrote:
>> That being said, I also don't like the fact that logdity is handled
>> differently between EPT and NPT, as on EPT it's handled as a
>> misconfig while on NPT it's handled as a violation.
> Because, well, there
On 20/05/2020 08:53, Jan Beulich wrote:
> It is wrong for us to check frames beyond the guest specified limit
> (in the compat case another loop bound is already correct).
>
> Signed-off-by: Jan Beulich
I'm still not overly convinced this is a good idea, because all it will
allow people to do is
On Fri, May 22, 2020 at 5:54 AM Paul Durrant wrote:
>
> > -Original Message-
> > From: Xen-devel On Behalf Of
> > George Dunlap
> > Sent: 22 May 2020 10:11
> > To: Jason Andryuk
> > Cc: Stefano Stabellini ; Julien Grall
> > ; Samuel Thibault
> > ; Wei Liu ; Andrew Cooper
> > ; Jan
> >
On Fri, May 22, 2020 at 02:11:15PM +0100, Andrew Cooper wrote:
> On 22/05/2020 14:04, Jan Beulich wrote:
> > On 22.05.2020 13:11, Roger Pau Monné wrote:
> >> That being said, I also don't like the fact that logdity is handled
> >> differently between EPT and NPT, as on EPT it's handled as a
> >> mi
On 22.05.2020 12:19, Andrew Cooper wrote:
> On 22/05/2020 11:05, Igor Druzhinin wrote:
>> On 22/05/2020 10:45, Andrew Cooper wrote:
>>> On 21/05/2020 22:43, Igor Druzhinin wrote:
If a recalculation NPT fault hasn't been handled explicitly in
hvm_hap_nested_page_fault() then it's potential
Jason Andryuk writes ("Re: [PATCH v7 00/19] Add support for qemu-xen runnning
in a Linux-based stubdomain"):
> I can do this. What is the SUPPORT status for this?
I think that given we aren't testing it upstream, the answer
probably has to be "Tech Preview".
In general, I would love to see this
On 21.05.2020 11:22, Roger Pau Monne wrote:
> Apply a workaround for Intel errata BDX99, CLX30, SKX100, CFW125,
> BDF104, BDH85, BDM135, KWB131: "A Pending Fixed Interrupt May Be
> Dispatched Before an Interrupt of The Same Priority Completes".
While the change looks good to me as far as Broadwell
On 21.05.2020 17:43, Andrew Cooper wrote:
> @@ -1439,6 +1418,21 @@ void do_page_fault(struct cpu_user_regs *regs)
> if ( unlikely(fixup_page_fault(addr, regs) != 0) )
> return;
>
> +/*
> + * Xen doesn't have reserved bits set in its pagetables, nor do we permit
> + * PV
On Fri, May 22, 2020 at 03:42:10PM +0200, Jan Beulich wrote:
> On 21.05.2020 11:22, Roger Pau Monne wrote:
> > Apply a workaround for Intel errata BDX99, CLX30, SKX100, CFW125,
> > BDF104, BDH85, BDM135, KWB131: "A Pending Fixed Interrupt May Be
> > Dispatched Before an Interrupt of The Same Priori
flight 150319 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150319/
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 22.05.2020 12:24, Andrew Cooper wrote:
> --- a/xen/arch/x86/ioport_emulate.c
> +++ b/xen/arch/x86/ioport_emulate.c
> @@ -8,7 +8,10 @@
> #include
> #include
>
> -static bool ioemul_handle_proliant_quirk(
> +unsigned int __read_mostly (*ioemul_handle_quirk)(
I guess the more correct (and lo
On 22.05.2020 15:54, Roger Pau Monné wrote:
> On Fri, May 22, 2020 at 03:42:10PM +0200, Jan Beulich wrote:
>> On 21.05.2020 11:22, Roger Pau Monne wrote:
>>> Apply a workaround for Intel errata BDX99, CLX30, SKX100, CFW125,
>>> BDF104, BDH85, BDM135, KWB131: "A Pending Fixed Interrupt May Be
>>> Di
On 22.05.2020 15:27, Andrew Cooper wrote:
> On 20/05/2020 08:53, Jan Beulich wrote:
>> It is wrong for us to check frames beyond the guest specified limit
>> (in the compat case another loop bound is already correct).
>>
>> Signed-off-by: Jan Beulich
>
> I'm still not overly convinced this is a g
On 21.05.2020 18:19, Paul Durrant wrote:
> To allow enlightened HVM guests (i.e. those that have PV drivers) to be
> migrated without their co-operation it will be necessary to transfer 'PV'
> state such as event channel state, grant entry state, etc.
>
> Currently there is a framework (entered vi
On 21.05.2020 18:19, Paul Durrant wrote:
> @@ -1649,6 +1650,70 @@ int continue_hypercall_on_cpu(
> return 0;
> }
>
> +static int save_shared_info(const struct domain *d, struct domain_context *c,
> +bool dry_run)
> +{
> +struct domain_shared_info_context ctxt
flight 150318 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150318/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1c877c716038a862e876cac8f0929bab4a96e849
baseline version:
ovmf 1a2ad3ba9efdd0db4bf1b
This bug was first discovered against Haswell. It is definitely affected.
(The XenServer ticket for this bug was opened on 2013-05-30 which is coming up
on 7 years old, and predates Broadwell).
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
We've followed u
On 22/05/2020 14:32, Roger Pau Monné wrote:
> On Fri, May 22, 2020 at 02:11:15PM +0100, Andrew Cooper wrote:
>> On 22/05/2020 14:04, Jan Beulich wrote:
>>> On 22.05.2020 13:11, Roger Pau Monné wrote:
That being said, I also don't like the fact that logdity is handled
differently between E
On 22.05.2020 17:07, Andrew Cooper wrote:
> This bug was first discovered against Haswell. It is definitely affected.
>
> (The XenServer ticket for this bug was opened on 2013-05-30 which is coming up
> on 7 years old, and predates Broadwell).
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beu
...rather than duplicating the path in several places.
Signed-off-by: George Dunlap
---
CC: Ian Jackson
CC: Wei Liu
CC: Nick Rosbrook
---
tools/golang/xenlight/Makefile | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenl
Signed-off-by: George Dunlap
---
CC: Ian Jackson
CC: Wei Liu
CC: Nick Rosbrook
---
tools/golang/xenlight/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
index 751f916276..6ab36c0aa9 100644
--- a/tools/
`go build` wants to add the current go version to go.mod as the
minimum every time we run `make` in the directory. Add 1.11 (the
earliest Go version that supports modules) there to make it happy.
Signed-off-by: George Dunlap
---
CC: Nick Rosbrook
---
tools/golang/xenlight/go.mod | 2 ++
1 file
Signed-off-by: George Dunlap
---
CC: Ian Jackson
CC: Wei Liu
CC: Andrew Cooper
CC: Jan Beulich
CC: Konrad Wilk
CC: Stefano Stabellini
CC: Julien Grall
CC: Nick Rosbrook
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 7418ce9829..c15b49
This is a series of patches that improve build for the golang xenlight
bindings. The most important patch is #3, which will update the
generated golang bindings from the tools/libxl directory when
libxl_types.idl is updated, even if the person building doesn't have
the golang packages enabled.
Ge
The generated golang bindings (types.gen.go and helpers.gen.go) are
left checked in so that they can be fetched from xenbits using the
golang tooling. This means that they must be updated whenever
libxl_types.idl (or other dependencies) are updated. However, the
golang bindings are only built opt
When running shallow forks without device models it may be undesirable for Xen
to inject interrupts. With Windows forks we have observed the kernel going into
infinite loops when trying to process such interrupts, likely because it
attempts
to interact with devices that are not responding without
Toolstack side for creating forks with interrupt injection blocked.
Signed-off-by: Tamas K Lengyel
Reviewed-by: Roger Pau Monné
Acked-by: Ian Jackson
---
tools/libxc/include/xenctrl.h | 3 ++-
tools/libxc/xc_memshr.c | 4 +++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git
flight 150324 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150324/
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, 21 May 2020, Boris Ostrovsky wrote:
> On 5/20/20 7:45 PM, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > Call dma_to_phys in is_xen_swiotlb_buffer.
> > Call phys_to_dma in xen_phys_to_bus.
> > Call dma_to_phys in xen_bus_to_phys.
> >
> > Everything is taken care of by these
flight 150316 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150316/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 7 xen-boot fail REGR. vs. 150281
test-amd64-amd64-ex
Hi Stefano,
On 22/05/2020 04:54, Stefano Stabellini wrote:
On Thu, 21 May 2020, Julien Grall wrote:
Hi,
On 21/05/2020 00:45, Stefano Stabellini wrote:
From: Boris Ostrovsky
Don't just assume that virt_to_page works on all virtual addresses.
Instead add a is_vmalloc_addr check and use vmallo
Hi,
On 22/05/2020 04:55, Stefano Stabellini wrote:
On Thu, 21 May 2020, Julien Grall wrote:
Hi,
On 21/05/2020 00:45, Stefano Stabellini wrote:
From: Stefano Stabellini
It is not strictly needed. Call virt_to_phys on xen_io_tlb_start
instead. It will be useful not to have a start_dma_addr ar
On 5/22/20 1:34 PM, Stefano Stabellini wrote:
> On Thu, 21 May 2020, Boris Ostrovsky wrote:
>> On 5/20/20 7:45 PM, Stefano Stabellini wrote:
>>> From: Stefano Stabellini
>>>
>>> Call dma_to_phys in is_xen_swiotlb_buffer.
>>> Call phys_to_dma in xen_phys_to_bus.
>>> Call dma_to_phys in xen_bus_to_p
> -Original Message-
> From: Jan Beulich
> Sent: 22 May 2020 15:25
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Julien Grall
> ; Andrew Cooper ; George Dunlap
> ;
> Ian Jackson ; Stefano Stabellini
> ; Wei Liu
> ; Volodymyr Babchuk ; Roger Pau
> Monné
>
> -Original Message-
> From: Jan Beulich
> Sent: 22 May 2020 15:34
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Ian Jackson
> ; Wei Liu ; Andrew Cooper
> ; George
> Dunlap ; Julien Grall ; Stefano
> Stabellini
>
> Subject: RE: [EXTERNAL] [PATCH v5 4/5] co
flight 150320 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150320/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150312
test-amd64-amd64-xl-qemuu-win7-amd6
flight 150330 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150330/
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 Fri, 22 May 2020, Julien Grall wrote:
> Hi Stefano,
>
> On 22/05/2020 04:54, Stefano Stabellini wrote:
> > On Thu, 21 May 2020, Julien Grall wrote:
> > > Hi,
> > >
> > > On 21/05/2020 00:45, Stefano Stabellini wrote:
> > > > From: Boris Ostrovsky
> > > >
> > > > Don't just assume that virt_t
On Fri, 22 May 2020, Julien Grall wrote:
> On 22/05/2020 04:55, Stefano Stabellini wrote:
> > On Thu, 21 May 2020, Julien Grall wrote:
> > > Hi,
> > >
> > > On 21/05/2020 00:45, Stefano Stabellini wrote:
> > > > From: Stefano Stabellini
> > > >
> > > > It is not strictly needed. Call virt_to_phy
flight 150333 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150333/
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
flight 150326 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150326/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-seattle 7 xen-boot fail REGR. vs. 150315
Regressions which
flight 150331 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150331/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx 7 xen-boot fail REGR. vs. 150281
build-i386-pvops
1 - 100 of 102 matches
Mail list logo
