flight 168300 qemu-mainline real [real]
flight 168325 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168300/
http://logs.test-lab.xenproject.org/osstest/logs/168325/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
Hi julien
> -Original Message-
> From: Wei Chen
> Sent: Tuesday, March 1, 2022 3:52 PM
> To: Julien Grall ; xen-devel@lists.xenproject.org; Stefano
> Stabellini
> Cc: Bertrand Marquis ; Penny Zheng
> ; Henry Wang ; nd
>
> Subject: RE: Proposal for Porting Xen to Armv8-R64 - DraftA
>
>
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Sent: 2022年3月2日 7:39
> To: Wei Chen
> Cc: Stefano Stabellini ; xen-
> de...@lists.xenproject.org; jul...@xen.org; Bertrand Marquis
> ; Penny Zheng ; Henry Wang
> ; nd
> Subject: RE: Proposal for Porting Xen to Armv8-R64 - Dra
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2022年3月1日 21:17
> To: Wei Chen ; Stefano Stabellini
>
> Cc: xen-devel@lists.xenproject.org; Bertrand Marquis
> ; Penny Zheng ; Henry Wang
> ; nd
> Subject: Re: Proposal for Porting Xen to Armv8-R64 - DraftA
>
> On 01/03/2022
flight 168306 linux-linus real [real]
flight 168322 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168306/
http://logs.test-lab.xenproject.org/osstest/logs/168322/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
flight 168313 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168313/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 168316 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168316/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Tue, 1 Mar 2022, Christoph Hellwig wrote:
> Allow to pass a remap argument to the swiotlb initialization functions
> to handle the Xen/x86 remap case. ARM/ARM64 never did any remapping
> from xen_swiotlb_fixup, so we don't even need that quirk.
>
> Signed-off-by: Christoph Hellwig
> ---
> ar
flight 168314 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168314/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 168312 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168312/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 168305 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168305/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 168308 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168308/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Tue, 1 Mar 2022, Wei Chen wrote:
> > On Fri, 25 Feb 2022, Wei Chen wrote:
> > > > Hi Wei,
> > > >
> > > > This is extremely exciting, thanks for the very nice summary!
> > > >
> > > >
> > > > On Thu, 24 Feb 2022, Wei Chen wrote:
> > > > > # Proposal for Porting Xen to Armv8-R64
> > > > >
> > > >
On Tue, 1 Mar 2022, Wei Chen wrote:
> > Hi Julien,
> >
> > > -Original Message-
> > > From: Julien Grall
> > > On 28/02/2022 07:12, Henry Wang wrote:
> > > > Hi Julien,
> > >
> > > Hi Henry,
> > >
> > > >> -Original Message-
> > > >> From: Julien Grall
> > > >> Hi Henry,
> > > >>
flight 168294 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168294/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168257
test-amd64-amd64-qemuu-nested-amd 20
flight 168303 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168303/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
From: Marek Marczykowski-Górecki
[ Upstream commit e8240addd0a3919e0fd7436416afe9aa6429c484 ]
This reverts commit 2afeec08ab5c86ae21952151f726bfe184f6b23d.
The reasoning in the commit was wrong - the code expected to setup the
watch even if 'hotplug-status' didn't exist. In fact, it relied on t
From: Marek Marczykowski-Górecki
[ Upstream commit 0f4558ae91870692ce7f509c31c9d6ee721d8cdc ]
This reverts commit 1f2565780e9b7218cf92c7630130e82dcc0fe9c2.
The 'hotplug-status' node should not be removed as long as the vif
device remains configured. Otherwise the xen-netback would wait for
re-r
From: Marek Marczykowski-Górecki
[ Upstream commit e8240addd0a3919e0fd7436416afe9aa6429c484 ]
This reverts commit 2afeec08ab5c86ae21952151f726bfe184f6b23d.
The reasoning in the commit was wrong - the code expected to setup the
watch even if 'hotplug-status' didn't exist. In fact, it relied on t
From: Marek Marczykowski-Górecki
[ Upstream commit e8240addd0a3919e0fd7436416afe9aa6429c484 ]
This reverts commit 2afeec08ab5c86ae21952151f726bfe184f6b23d.
The reasoning in the commit was wrong - the code expected to setup the
watch even if 'hotplug-status' didn't exist. In fact, it relied on t
From: Marek Marczykowski-Górecki
[ Upstream commit 0f4558ae91870692ce7f509c31c9d6ee721d8cdc ]
This reverts commit 1f2565780e9b7218cf92c7630130e82dcc0fe9c2.
The 'hotplug-status' node should not be removed as long as the vif
device remains configured. Otherwise the xen-netback would wait for
re-r
From: Marek Marczykowski-Górecki
[ Upstream commit e8240addd0a3919e0fd7436416afe9aa6429c484 ]
This reverts commit 2afeec08ab5c86ae21952151f726bfe184f6b23d.
The reasoning in the commit was wrong - the code expected to setup the
watch even if 'hotplug-status' didn't exist. In fact, it relied on t
From: Marek Marczykowski-Górecki
[ Upstream commit 0f4558ae91870692ce7f509c31c9d6ee721d8cdc ]
This reverts commit 1f2565780e9b7218cf92c7630130e82dcc0fe9c2.
The 'hotplug-status' node should not be removed as long as the vif
device remains configured. Otherwise the xen-netback would wait for
re-r
From: Marek Marczykowski-Górecki
[ Upstream commit e8240addd0a3919e0fd7436416afe9aa6429c484 ]
This reverts commit 2afeec08ab5c86ae21952151f726bfe184f6b23d.
The reasoning in the commit was wrong - the code expected to setup the
watch even if 'hotplug-status' didn't exist. In fact, it relied on t
From: Marek Marczykowski-Górecki
[ Upstream commit 0f4558ae91870692ce7f509c31c9d6ee721d8cdc ]
This reverts commit 1f2565780e9b7218cf92c7630130e82dcc0fe9c2.
The 'hotplug-status' node should not be removed as long as the vif
device remains configured. Otherwise the xen-netback would wait for
re-r
From: Marek Marczykowski-Górecki
[ Upstream commit e8240addd0a3919e0fd7436416afe9aa6429c484 ]
This reverts commit 2afeec08ab5c86ae21952151f726bfe184f6b23d.
The reasoning in the commit was wrong - the code expected to setup the
watch even if 'hotplug-status' didn't exist. In fact, it relied on t
From: Marek Marczykowski-Górecki
[ Upstream commit 0f4558ae91870692ce7f509c31c9d6ee721d8cdc ]
This reverts commit 1f2565780e9b7218cf92c7630130e82dcc0fe9c2.
The 'hotplug-status' node should not be removed as long as the vif
device remains configured. Otherwise the xen-netback would wait for
re-r
From: Marek Marczykowski-Górecki
[ Upstream commit e8240addd0a3919e0fd7436416afe9aa6429c484 ]
This reverts commit 2afeec08ab5c86ae21952151f726bfe184f6b23d.
The reasoning in the commit was wrong - the code expected to setup the
watch even if 'hotplug-status' didn't exist. In fact, it relied on t
From: Marek Marczykowski-Górecki
[ Upstream commit 0f4558ae91870692ce7f509c31c9d6ee721d8cdc ]
This reverts commit 1f2565780e9b7218cf92c7630130e82dcc0fe9c2.
The 'hotplug-status' node should not be removed as long as the vif
device remains configured. Otherwise the xen-netback would wait for
re-r
> -#include
> -
> -/*
> - * History lesson:
> - * The execution chain of IOMMUs in 2.6.36 looks as so:
> - *
> - *[xen-swiotlb]
> - * |
> - * +[swiotlb *]--+
> - */ | \
> - * / | \
> - *[GART] [Calgary]
flight 168299 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168299/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 168289 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168289/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 19 guest-start.2fail REGR. vs. 168255
Tests which did not succee
On 2/28/22 11:56 PM, Dongli Zhang wrote:
Hi Boris,
On 2/28/22 5:18 PM, Dongli Zhang wrote:
Hi Boris,
On 2/28/22 12:45 PM, Boris Ostrovsky wrote:
On 2/25/22 8:17 PM, Dongli Zhang wrote:
Hi Boris,
On 2/25/22 2:39 PM, Boris Ostrovsky wrote:
On 2/24/22 4:50 PM, Dongli Zhang wrote:
This is
flight 168296 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168296/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 168295 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168295/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 25/02/2022 08:24, Jan Beulich wrote:
> On 22.02.2022 12:47, Andrew Cooper wrote:
>> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> @@ -628,7 +628,7 @@ static void cf_check amd_dump_page_tables(struct domain
>> *d)
>>
On 01.03.2022 15:51, Andrew Cooper wrote:
> On 01/03/2022 11:59, Jan Beulich wrote:
>> On 14.02.2022 13:56, Andrew Cooper wrote:
>>> @@ -330,6 +333,41 @@ static void init_or_livepatch
>>> _apply_alternatives(struct alt_instr *start,
>>> add_nops(buf + a->repl_len, total_len - a->repl_len)
Hi Julien,
> On 28 Feb 2022, at 10:07, Julien Grall wrote:
>
> From: Julien Grall
>
> Commit 2ac705a59ef5 ("xen/arm32: head: Mark the end of subroutines
> with ENDPROC") intended to mark all the subroutines with ENDPROC.
>
> Unfortunately, I missed fail(), switch_ttbr(), init_uart() and
> __l
Hi Julien,
> On 28 Feb 2022, at 10:08, Julien Grall wrote:
>
> From: Julien Grall
>
> Commit 13c03002c5df ("xen/arm64: head: Mark the end of subroutines
> with ENDPROC") intended to mark all the subroutines with ENDPROC.
>
> Unfortunately, I missed fail(), switch_ttbr() and init_uart(). Add
>
On 01.03.2022 15:23, Andrew Cooper wrote:
> On 01/03/2022 13:34, Jan Beulich wrote:
>> On 01.03.2022 13:48, Andrew Cooper wrote:
>>> On 01/03/2022 11:36, Jan Beulich wrote:
Suitable compiler options are passed only when the actual feature
(XEN_IBT) is enabled, not when merely the compiler
On 01/03/2022 11:59, Jan Beulich wrote:
> On 14.02.2022 13:56, Andrew Cooper wrote:
>> @@ -330,6 +333,41 @@ static void init_or_livepatch
>> _apply_alternatives(struct alt_instr *start,
>> add_nops(buf + a->repl_len, total_len - a->repl_len);
>> text_poke(orig, buf, total_len);
>
On 01.03.2022 15:35, Andrew Cooper wrote:
> On 01/03/2022 14:24, Andrew Cooper wrote:
>> On 01/03/2022 14:18, Jan Beulich wrote:
>>> On 01.03.2022 14:18, Andrew Cooper wrote:
On 01/03/2022 11:06, Jan Beulich wrote:
> With bed9ae54df44 ("x86/time: switch platform timer hooks to altcall")
>>
SeongJae is currently listed as a contact point for some blk{back,front}
features, but he will not work for XEN for a while. This commit
therefore updates the contact point to his colleague, Maximilian, who is
understanding the context and actively working with the features now.
Signed-off-by: Se
On 01.03.2022 15:24, Andrew Cooper wrote:
> On 01/03/2022 14:18, Jan Beulich wrote:
>> On 01.03.2022 14:18, Andrew Cooper wrote:
>>> On 01/03/2022 11:06, Jan Beulich wrote:
With bed9ae54df44 ("x86/time: switch platform timer hooks to altcall")
in place we can further arrange for ENDBR rem
On 01.03.2022 15:39, Andrew Cooper wrote:
> On 01/03/2022 14:14, Jan Beulich wrote:
>> On 01.03.2022 14:07, Andrew Cooper wrote:
>>> On 01/03/2022 11:05, Jan Beulich wrote:
>>> That said... what's wrong a plain NULL? I can't see any need for a
>>> magic constant here.
>> Are you fancying an XSA fo
On 01/03/2022 14:39, Andrew Cooper wrote:
> On 01/03/2022 14:14, Jan Beulich wrote:
>> On 01.03.2022 14:07, Andrew Cooper wrote:
>>> On 01/03/2022 11:05, Jan Beulich wrote:
>>> That said... what's wrong a plain NULL? I can't see any need for a
>>> magic constant here.
>> Are you fancying an XSA fo
On 01.03.2022 15:19, Roger Pau Monné wrote:
> On Tue, Mar 01, 2022 at 08:51:59AM +0100, Jan Beulich wrote:
>> On 28.02.2022 17:31, Roger Pau Monné wrote:
>>> On Mon, Feb 28, 2022 at 05:14:26PM +0100, Jan Beulich wrote:
On 28.02.2022 16:36, Roger Pau Monné wrote:
> On Mon, Feb 28, 2022 at 0
On 01/03/2022 14:14, Jan Beulich wrote:
> On 01.03.2022 14:07, Andrew Cooper wrote:
>> On 01/03/2022 11:05, Jan Beulich wrote:
>> That said... what's wrong a plain NULL? I can't see any need for a
>> magic constant here.
> Are you fancying an XSA for a call through NULL in PV guest context?
Why d
On 01/03/2022 14:24, Andrew Cooper wrote:
> On 01/03/2022 14:18, Jan Beulich wrote:
>> On 01.03.2022 14:18, Andrew Cooper wrote:
>>> On 01/03/2022 11:06, Jan Beulich wrote:
With bed9ae54df44 ("x86/time: switch platform timer hooks to altcall")
in place we can further arrange for ENDBR rem
On 01/03/2022 14:18, Jan Beulich wrote:
> On 01.03.2022 14:18, Andrew Cooper wrote:
>> On 01/03/2022 11:06, Jan Beulich wrote:
>>> With bed9ae54df44 ("x86/time: switch platform timer hooks to altcall")
>>> in place we can further arrange for ENDBR removal from the functions no
>>> longer subject to
On 01/03/2022 13:34, Jan Beulich wrote:
> On 01.03.2022 13:48, Andrew Cooper wrote:
>> On 01/03/2022 11:36, Jan Beulich wrote:
>>> Suitable compiler options are passed only when the actual feature
>>> (XEN_IBT) is enabled, not when merely the compiler capability was found
>>> to be available.
>>>
>
On Tue, Mar 01, 2022 at 03:06:30PM +0100, Jan Beulich wrote:
> On 01.03.2022 14:43, Roger Pau Monné wrote:
> > On Tue, Mar 01, 2022 at 09:55:32AM +0100, Jan Beulich wrote:
> >> Especially when linking a PE binary (xen.efi), standalone output
> >> sections are expensive: Often the linker will align
On Tue, Mar 01, 2022 at 08:51:59AM +0100, Jan Beulich wrote:
> On 28.02.2022 17:31, Roger Pau Monné wrote:
> > On Mon, Feb 28, 2022 at 05:14:26PM +0100, Jan Beulich wrote:
> >> On 28.02.2022 16:36, Roger Pau Monné wrote:
> >>> On Mon, Feb 28, 2022 at 02:11:04PM +0100, Jan Beulich wrote:
> On 2
On 01.03.2022 14:18, Andrew Cooper wrote:
> On 01/03/2022 11:06, Jan Beulich wrote:
>> With bed9ae54df44 ("x86/time: switch platform timer hooks to altcall")
>> in place we can further arrange for ENDBR removal from the functions no
>> longer subject to indirect calls. Note that plt_tsc is left unt
On 01.03.2022 14:07, Andrew Cooper wrote:
> On 01/03/2022 11:05, Jan Beulich wrote:
>> Go a step further than bed9ae54df44 ("x86/time: switch platform timer
>> hooks to altcall") did and eliminate the "real" read_tsc() altogether:
>> It's not used except in pointer comparisons, and hence it looks o
On 01.03.2022 14:43, Roger Pau Monné wrote:
> On Tue, Mar 01, 2022 at 09:55:32AM +0100, Jan Beulich wrote:
>> Especially when linking a PE binary (xen.efi), standalone output
>> sections are expensive: Often the linker will align the subsequent one
>> on the section alignment boundary (2Mb) when th
On 01.03.2022 14:34, Rahul Singh wrote:
>> On 24 Feb 2022, at 2:57 pm, Jan Beulich wrote:
>>
>> On 15.02.2022 16:25, Rahul Singh wrote:
>>> vpci/msix.c file will be used for arm architecture when vpci msix
>>> support will be added to ARM, but there is x86 specific code in this
>>> file.
>>>
>>> M
On Tue, Mar 01, 2022 at 09:55:32AM +0100, Jan Beulich wrote:
> Especially when linking a PE binary (xen.efi), standalone output
> sections are expensive: Often the linker will align the subsequent one
> on the section alignment boundary (2Mb) when the linker script doesn't
> otherwise place it. (I
Hi Julien,
> On 28 Feb 2022, at 13:35, Julien Grall wrote:
>
> From: Julien Grall
>
> Since commit 54c4ae18d158 ("xen/arm32: head: Rework and document
> launch()"), the boot code is setting r12 but not read it.
>
> So remove the two instructions setting r12 and update the documentation
> to s
Hi,
> On 28 Feb 2022, at 18:51, Julien Grall wrote:
>
>
>
> On 28/02/2022 07:12, Henry Wang wrote:
>> Hi Julien,
>
> Hi Henry,
>
>>> -Original Message-
>>> From: Julien Grall
>>> Sent: Saturday, February 26, 2022 4:09 AM
>>> To: Henry Wang ; xen-devel@lists.xenproject.org;
>>> sstab
H Jan,
> On 24 Feb 2022, at 2:57 pm, Jan Beulich wrote:
>
> On 15.02.2022 16:25, Rahul Singh wrote:
>> vpci/msix.c file will be used for arm architecture when vpci msix
>> support will be added to ARM, but there is x86 specific code in this
>> file.
>>
>> Move x86 specific code to the x86/hvm/v
On 01.03.2022 13:48, Andrew Cooper wrote:
> On 01/03/2022 11:36, Jan Beulich wrote:
>> Suitable compiler options are passed only when the actual feature
>> (XEN_IBT) is enabled, not when merely the compiler capability was found
>> to be available.
>>
>> Fixes: 12e3410e071e ("x86/altcall: Check and
Hi Jan,
> On 1 Mar 2022, at 08:58, Jan Beulich wrote:
>
> On 01.03.2022 09:55, Jan Beulich wrote:
>> Especially when linking a PE binary (xen.efi), standalone output
>> sections are expensive: Often the linker will align the subsequent one
>> on the section alignment boundary (2Mb) when the link
On 01/03/2022 11:06, Jan Beulich wrote:
> With bed9ae54df44 ("x86/time: switch platform timer hooks to altcall")
> in place we can further arrange for ENDBR removal from the functions no
> longer subject to indirect calls. Note that plt_tsc is left untouched,
> for not holding any pointer eligible
On 01/03/2022 06:29, Wei Chen wrote:
Hi Julien,
Hi,
-Original Message-
From: Julien Grall
Sent: 2022年2月26日 4:12
To: Wei Chen ; Stefano Stabellini
Cc: xen-devel@lists.xenproject.org; Bertrand Marquis
; Penny Zheng ; Henry Wang
; nd
Subject: Re: Proposal for Porting Xen to Armv8-R64
On 01/03/2022 11:05, Jan Beulich wrote:
> Go a step further than bed9ae54df44 ("x86/time: switch platform timer
> hooks to altcall") did and eliminate the "real" read_tsc() altogether:
> It's not used except in pointer comparisons, and hence it looks overall
> more safe to simply poison plt_tsc's r
flight 168283 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168283/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 168290 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168290/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Sent: 2022年2月26日 7:54
> To: Wei Chen
> Cc: Stefano Stabellini ; xen-
> de...@lists.xenproject.org; jul...@xen.org; Bertrand Marquis
> ; Penny Zheng ; Henry Wang
> ; nd
> Subject: RE: Proposal for Porting Xen to Armv8-R64 - Dr
On 01/03/2022 11:36, Jan Beulich wrote:
> Suitable compiler options are passed only when the actual feature
> (XEN_IBT) is enabled, not when merely the compiler capability was found
> to be available.
>
> Fixes: 12e3410e071e ("x86/altcall: Check and optimise altcall targets")
> Signed-off-by: Jan B
When the data abort is caused due to cache maintenance for an address,
there are two scenarios:-
1. Address belonging to a non emulated region - For this, Xen should
set the corresponding bit in the translation table entry to valid and
return to the guest to retry the instruction. This can happen
When an instruction is trapped in Xen due to translation fault, Xen
checks if the ISS is invalid (for data abort) or it is an instruction
abort. If so, Xen tries to resolve the translation fault using p2m page
tables. In case of data abort, Xen will try to map the mmio region to
the guest (ie tries
At the moment, Xen does not decode any of the arm64 instructions. This
means that when hsr_dabt.isv == 0, Xen cannot handle those instructions.
This will lead to Xen to abort the guests (from which those instructions
originate).
With this patch, Xen is able to decode ldr/str post indexing instruct
Hi All,
The patch series introduces support to decode instructions by Xen when ISS is
invalid. Currently, when the guest executes post indexing ldr/str instructions
on emulated MMIO, these instructions are trapped into Xen as a data abort.
Xen reads hsr_dabt.isv == 0, so ISS is invalid. Therefore,
If the abort was caused due to access to stage1 translation table, Xen
will assume that the stage1 translation table is in the non MMIO region.
It will try to resolve the translation fault. If it succeeds, it will
return to the guest to retry the instruction. If not, then it means
that the table is
On Tue, Mar 01, 2022 at 12:11:30PM +, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
> br.gitlab-ci-build-container-v1
>
> I wanted to automatically check that generated files that we have in our repo
> are
Try to find out whether genereted files that are commited needs to be
regenerated.
Signed-off-by: Anthony PERARD
---
automation/gitlab-ci/test.yaml | 10 +
automation/scripts/check-generated-files | 55
2 files changed, 65 insertions(+)
create mode 100755
Only run this on the staging branch, whenever the dockerfile changes.
Signed-off-by: Anthony PERARD
---
.gitlab-ci.yml | 2 ++
automation/gitlab-ci/containers.yaml | 22 ++
2 files changed, 24 insertions(+)
create mode 100644 automation/gitlab-ci/conta
This container will be used to check that generated source file in the
git repository are up to date.
Signed-off-by: Anthony PERARD
---
automation/build/debian/stable.dockerfile | 53 +++
1 file changed, 53 insertions(+)
create mode 100644 automation/build/debian/stable.dock
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.gitlab-ci-build-container-v1
I wanted to automatically check that generated files that we have in our repo
are up-to-date, those are autoconf and *.gen.go files generataed from
libxl_typ
On 14.02.2022 13:56, Andrew Cooper wrote:
> @@ -330,6 +333,41 @@ static void init_or_livepatch _apply_alternatives(struct
> alt_instr *start,
> add_nops(buf + a->repl_len, total_len - a->repl_len);
> text_poke(orig, buf, total_len);
> }
> +
> +/*
> + * Clobber endbr6
On Tue, Mar 01, 2022 at 11:39:29AM +, Andrew Cooper wrote:
> This isn't really "must". The guest is perfectly capable of sharing
> memory with the hypervisor.
>
> It's just that for now, bounce buffering is allegedly faster, and the
> simple way of getting it working.
Yeah, I guess you щould
On 01/03/2022 10:53, Christoph Hellwig wrote:
> diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
> index 2ac0ef9c2fb76..7ab7002758396 100644
> --- a/arch/x86/kernel/pci-dma.c
> +++ b/arch/x86/kernel/pci-dma.c
> @@ -53,6 +53,13 @@ static void __init pci_swiotlb_detect(void)
>
Suitable compiler options are passed only when the actual feature
(XEN_IBT) is enabled, not when merely the compiler capability was found
to be available.
Fixes: 12e3410e071e ("x86/altcall: Check and optimise altcall targets")
Signed-off-by: Jan Beulich
---
Furthermore, is "Optimised away ..." re
With bed9ae54df44 ("x86/time: switch platform timer hooks to altcall")
in place we can further arrange for ENDBR removal from the functions no
longer subject to indirect calls. Note that plt_tsc is left untouched,
for not holding any pointer eligible for ENDBR removal.
Signed-off-by: Jan Beulich
Go a step further than bed9ae54df44 ("x86/time: switch platform timer
hooks to altcall") did and eliminate the "real" read_tsc() altogether:
It's not used except in pointer comparisons, and hence it looks overall
more safe to simply poison plt_tsc's read_counter hook.
Signed-off-by: Jan Beulich
-
1: use fake read_tsc()
2: add CF-clobber annotations
Jan
branch xen-unstable
xenbranch xen-unstable
job build-amd64
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen gi
flight 168285 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168285/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Pass a bool to pass if swiotlb needs to be enabled based on the
addressing needs and replace the verbose argument with a set of
flags, including one to force enable bounce buffering.
Note that this patch removes the possibility to force xen-swiotlb
use using swiotlb=force on the command line on x8
Power SVM wants to allocate a swiotlb buffer that is not restricted to
low memory for the trusted hypervisor scheme. Consolidate the support
for this into the swiotlb_init interface by adding a new flag.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/svm.h | 4
arch/p
Allow to pass a remap argument to the swiotlb initialization functions
to handle the Xen/x86 remap case. ARM/ARM64 never did any remapping
from xen_swiotlb_fixup, so we don't even need that quirk.
Signed-off-by: Christoph Hellwig
---
arch/arm/xen/mm.c | 23 +++---
arch/x86/includ
gets pulled in by all drivers using the DMA API.
Remove x86 internal variables and unnecessary includes from it.
Signed-off-by: Christoph Hellwig
---
arch/x86/include/asm/dma-mapping.h | 11 ---
arch/x86/include/asm/iommu.h | 2 ++
2 files changed, 2 insertions(+), 11 deletions(-
Move enabling SWIOTLB_FORCE for guest memory encryption into common code.
Signed-off-by: Christoph Hellwig
---
arch/x86/kernel/cpu/mshyperv.c | 8
arch/x86/kernel/pci-dma.c | 7 +++
arch/x86/mm/mem_encrypt_amd.c | 3 ---
3 files changed, 7 insertions(+), 11 deletions(-)
diff
The IOMMU table tries to separate the different IOMMUs into different
backends, but actually requires various cross calls.
Rewrite the code to do the generic swiotlb/swiotlb-xen setup directly
in pci-dma.c and then just call into the IOMMU drivers.
Signed-off-by: Christoph Hellwig
---
arch/ia64
swiotlb_late_init_with_default_size is an overly verbose name that
doesn't even catch what the function is doing, given that the size is
not just a default but the actual requested size.
Rename it to swiotlb_init_late.
Signed-off-by: Christoph Hellwig
Reviewed-by: Anshuman Khandual
---
arch/x8
Hi Julien,
> On 28 Feb 2022, at 10:06, Julien Grall wrote:
>
> From: Julien Grall
>
> We stopped relocating Xen since commit f60658c6ae "xen/arm: Stop
> relocating Xen".
>
> At the same time, update the memory layout description.
>
> Signed-off-by: Julien Grall
> Signed-off-by: Julien Grall
Use the generic swiotlb initialization helper instead of open coding it.
Signed-off-by: Christoph Hellwig
---
arch/mips/cavium-octeon/dma-octeon.c | 15 ++-
arch/mips/pci/pci-octeon.c | 2 +-
2 files changed, 3 insertions(+), 14 deletions(-)
diff --git a/arch/mips/cavium-
Let the caller chose a zone to allocate from. This will be used
later on by the xen-swiotlb initialization on arm.
Signed-off-by: Christoph Hellwig
Reviewed-by: Anshuman Khandual
---
arch/x86/pci/sta2x11-fixup.c | 2 +-
include/linux/swiotlb.h | 2 +-
kernel/dma/swiotlb.c | 4 ++--
Remove the bogus Xen override that was usually larger than the actual
size and just calculate the value on demand. Note that
swiotlb_max_segment still doesn't make sense as an interface and should
eventually be removed.
Signed-off-by: Christoph Hellwig
Reviewed-by: Anshuman Khandual
---
driver
1 - 100 of 119 matches
Mail list logo
