On 28.02.2022 23:51, Andrew Cooper wrote:
> CET-IBT depend on executing indirect branches for protections to apply.
> Extend the clobber for CET-SS to all of CET.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
> I can't decide if this wants a fixes tag or not. If I'd remembered dur
flight 168264 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168264/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
Hello,
when commit d96e5e6c1214 added UNSUPPORTED, it left x86'es TBOOT
default untouched. This means we default-enable an unsupported
setting, which doesn't look to be what's generally wanted. I can
see defaulting to DEBUG as reasonable, and SCHED_NULL's defaulting
to enabled when PV_SHIM can imo
Hi Julien,
On 28.02.2022 11: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
Are these
On 26.02.2022 11:05, Roger Pau Monne wrote:
> --- a/xen/drivers/vpci/msix.c
> +++ b/xen/drivers/vpci/msix.c
> @@ -198,8 +198,13 @@ static int cf_check msix_read(
> if ( !access_allowed(msix->pdev, addr, len) )
> return X86EMUL_OKAY;
>
> +spin_lock(&msix->pdev->vpci->lock);
>
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 haven't been able to derive from observed
behavior under what conditi
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 linker script doesn't
> otherwise place it. (I haven't been able to
Defaults differ for Arm and x86, not the least because of v2 not even
being security supported on Arm.
Also drop a bogus sentence from gnttab_max_maptrack_frames, which was
presumably mistakenly cloned from gnttab_max_frames (albeit even there
what is being said is neither very precise nor very us
On Tue, Mar 01, 2022 at 09:46:13AM +0100, Jan Beulich wrote:
> On 26.02.2022 11:05, Roger Pau Monne wrote:
> > --- a/xen/drivers/vpci/msix.c
> > +++ b/xen/drivers/vpci/msix.c
> > @@ -198,8 +198,13 @@ static int cf_check msix_read(
> > if ( !access_allowed(msix->pdev, addr, len) )
> >
Hi Juergen,
On Fri, Feb 25, 2022 at 03:09:05PM +0100, Juergen Gross wrote:
> On 23.02.22 19:08, James Dingwall wrote:
> > Hi,
> >
> > I have been investigating a very intermittent issue we have with xenstore
> > access hanging. Typically it seems to happen when all domains are stopped
> > prior
Hi,
The set_mtu() function of xen-network-common.sh currently has this code:
if [ ${type_if} = vif ]
then
local dev_=${dev#vif}
local domid=${dev_%.*}
local devid=${dev_#*.}
local FRONTEND_PATH="/local/domain/$domid/device/vif/$devi
On 01/03/2022 08:28, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 28.02.2022 11: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
Hi Julien,
On 01.03.2022 10:57, Julien Grall wrote:
> On 01/03/2022 08:28, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Michal,
>
>> On 28.02.2022 11:06, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> We stopped relocating Xen since commit f60658c6ae "xen/arm: Stop
>>> relocating Xen".
>>>
>>>
flight 168271 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168271/
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 168257 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168257/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168253
test-amd64-amd64-qemuu-nested-amd 20
On 01.03.2022 10:08, Roger Pau Monné wrote:
> On Tue, Mar 01, 2022 at 09:46:13AM +0100, Jan Beulich wrote:
>> On 26.02.2022 11:05, Roger Pau Monne wrote:
>>> --- a/xen/drivers/vpci/msix.c
>>> +++ b/xen/drivers/vpci/msix.c
>>> @@ -198,8 +198,13 @@ static int cf_check msix_read(
>>> if ( !access
Use the more specific is_swiotlb_active check instead of checking the
global swiotlb_force variable.
Signed-off-by: Christoph Hellwig
Reviewed-by: Anshuman Khandual
---
kernel/dma/direct.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/dma/direct.h b/kernel/dma/direc
If force bouncing is enabled we can't release the buffers.
Signed-off-by: Christoph Hellwig
Reviewed-by: Anshuman Khandual
---
kernel/dma/swiotlb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index bfc56cb217059..64b390136f9ef 100644
--- a/
Hi all,
this series tries to clean up the swiotlb initialization, including
that of swiotlb-xen. To get there is also removes the x86 iommu table
infrastructure that massively obsfucates the initialization path.
Git tree:
git://git.infradead.org/users/hch/misc.git swiotlb-init-cleanup
Gitw
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
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 ++--
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-
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
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
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
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
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(-
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
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
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
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
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
1: use fake read_tsc()
2: add CF-clobber annotations
Jan
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
-
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
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
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)
>
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 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
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
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
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
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
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
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
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
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
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
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
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
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: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
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 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
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
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
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
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
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 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: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: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 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 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 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 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 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: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 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: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: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: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
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: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")
>>
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: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
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
>
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
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)
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)
>>
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
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
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 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
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
> -#include
> -
> -/*
> - * History lesson:
> - * The execution chain of IOMMUs in 2.6.36 looks as so:
> - *
> - *[xen-swiotlb]
> - * |
> - * +[swiotlb *]--+
> - */ | \
> - * / | \
> - *[GART] [Calgary]
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 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
1 - 100 of 119 matches
Mail list logo
