flight 150332 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150332/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150320
test-amd64-amd64-xl-qemuu-win7-amd6
flight 150335 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150335/
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 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
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 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
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
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
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
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
> -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
> -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é
>
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
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
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
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
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 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
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
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
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
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
`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: 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/
...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
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
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
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
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
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
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 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 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 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
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 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
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 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
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 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
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 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 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 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
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 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
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 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
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_
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
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
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
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
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 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 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 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
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 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/
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 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 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: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: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 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 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
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 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
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 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 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 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 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 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 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 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 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 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
> -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 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
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 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
> -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
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
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
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/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, 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 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
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 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.
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 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
> -
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 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
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 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.
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 +++
1 - 100 of 102 matches
Mail list logo
