This simply parallels .dtors. Both section types can reference
.text.exit, which requires them to be discarded together with that one.
Compilers, depending on their findings during the configure phase, may
elect to use either model. While .{init,fini}_array look to be
preferred, cross compilers app
On 04.03.2022 08:29, Jan Beulich wrote:
> On 03.03.2022 21:02, Andrew Cooper wrote:
>> On 01/03/2022 08: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
On 03.03.2022 21:02, Andrew Cooper wrote:
> On 01/03/2022 08: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
On 03.03.2022 17:31, Rahul Singh wrote:
>> On 1 Mar 2022, at 1:55 pm, Jan Beulich wrote:
>> 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:
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vms
On 03.03.2022 18:14, Alex Olson wrote:
> I wasn't sure of the distinction between hardware domain and control domain
> for these commands, but they appear to be blocked at the moment when dom0
> executes them, including a lot at boot. Are you suggesting to use
> is_hardware_domain(currd) instea
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2022年3月4日 3:51
> To: Wei Chen ; 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 Wei,
>
> On 0
On 03.03.22 01:40, Andrew Cooper wrote:
When only one scheduler is compiled in, function pointers can be optimised to
direct calls, and the hooks hardened against controlflow hijacking.
RFC for several reasons.
1) There's an almost beautiful way of not introducing MAYBE_SCHED() and hiding
t
flight 168392 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168392/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 168383 linux-linus real [real]
flight 168391 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168383/
http://logs.test-lab.xenproject.org/osstest/logs/168391/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
flight 168389 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168389/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 168376 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168376/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 168343
Tests which did not succee
flight 168386 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168386/
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 Tue, 1 Mar 2022, Ayan Kumar Halder wrote:
> 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
> retur
On Tue, 1 Mar 2022, Ayan Kumar Halder wrote:
> 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
flight 168387 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168387/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 168369 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168369/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail REGR.
vs. 168328
Tests w
flight 168385 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168385/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Tue, 1 Mar 2022, Ayan Kumar Halder wrote:
> 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 pa
On Tue, 1 Mar 2022, Ayan Kumar Halder wrote:
> 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 w
On Thu, 3 Mar 2022, Christoph Hellwig wrote:
> On Wed, Mar 02, 2022 at 05:25:10PM -0800, Stefano Stabellini wrote:
> > Thinking more about it we actually need to drop the xen_initial_domain()
> > check otherwise some cases won't be functional (Dom0 not 1:1 mapped, or
> > DomU 1:1 mapped).
>
> Hmm,
flight 168384 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168384/
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 168381 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168381/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 03/03/2022 16:04, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 28 Feb 2022, at 10:06, Julien Grall wrote:
From: Julien Grall
The boot code expects the regions XEN_VIRT_START, FIXMAP_ADDR(0),
BOOT_FDT_VIRT_START to use the same 0th (arm64 only) and 1st slot.
Add some BUILD_BUG
Hi Bertrand,
On 01/03/2022 13:30, Bertrand Marquis wrote:
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
On 01/03/2022 08: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
branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
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
Hi,
On 02/03/2022 09:59, Michal Orzel wrote:
Introduce macros GIC_PRI_IRQ_ALL and GIC_PRI_IPI_ALL to be used in all
the places where we want to set default priority for all the offsets
in interrupt priority register. This will improve readability and
allow to get rid of introducing variables jus
Hi Wei,
On 03/03/2022 02:06, Wei Chen wrote:
-Original Message-
From: Julien Grall
Sent: 2022年3月2日 20:00
To: Wei Chen ; 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
On 3/3/22 5:57 AM, Christoph Hellwig wrote:
On Wed, Mar 02, 2022 at 08:15:03AM -0500, Boris Ostrovsky wrote:
Not for me, I fail to boot with
[ 52.202000] bnxt_en :31:00.0: swiotlb buffer is full (sz: 256 bytes),
total 0 (slots), used 0 (slots)
(this is iscsi root so I need the NIC).
flight 168374 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168374/
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 Wed, Mar 2, 2022 at 12:57 PM osstest service owner
wrote:
>
> flight 168340 ovmf real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/168340/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64
On Thu, Mar 3, 2022 at 11:34 AM Roger Pau Monné wrote:
>
> On Thu, Mar 03, 2022 at 05:01:23PM +0100, Andrea Stevanato wrote:
> > On 03/03/2022 15:54, Andrea Stevanato wrote:
> > > Hi all,
> > >
> > > according to the conversation that I had with royger, aa67b97ed34 broke
> > > the driver domain
On 03/03/2022 16:48, Jan Beulich wrote:
> While benign (because only the decoder is exercised here, whereas a
> wrong EVEX.W would cause an exception only during actual emulation),
> let's still have correct information in the table entries.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 03/03/2022 16:52, Jan Beulich wrote:
> Truly scalar insns (i.e. not VBROADCASTS{S,D}) only every act on
> %xmm. Adjust comments accordingly.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
I wasn't sure of the distinction between hardware domain and control domain for
these commands, but they appear to be blocked at the moment when dom0 executes
them, including a lot at boot. Are you suggesting to use
is_hardware_domain(currd) instead in my diff?
Or should the hardware domai
On 03.03.2022 17:50, Anthony PERARD wrote:
> On Thu, Mar 03, 2022 at 05:01:07PM +0100, Jan Beulich wrote:
>> On 03.03.2022 16:41, Anthony PERARD wrote:
>>> On Thu, Mar 03, 2022 at 11:37:08AM +0100, Jan Beulich wrote:
On 25.01.2022 12:00, Anthony PERARD wrote:
> +# Part of the command line
Truly scalar insns (i.e. not VBROADCASTS{S,D}) only every act on
%xmm. Adjust comments accordingly.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -7608,8 +7608,8 @@ x86_emulate(
#ifndef X86EMUL_NO_SIMD
case X86EMUL_O
On Thu, Mar 03, 2022 at 05:01:07PM +0100, Jan Beulich wrote:
> On 03.03.2022 16:41, Anthony PERARD wrote:
> > On Thu, Mar 03, 2022 at 11:37:08AM +0100, Jan Beulich wrote:
> >> On 25.01.2022 12:00, Anthony PERARD wrote:
> >>> +# Part of the command line transforms $(obj) in to a relative reverted
>
flight 168377 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168377/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
While benign (because only the decoder is exercised here, whereas a
wrong EVEX.W would cause an exception only during actual emulation),
let's still have correct information in the table entries.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulato
On 03.03.2022 17:45, Alex Olson wrote:
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -84,6 +84,17 @@ static long hvm_physdev_op(int cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
>
> switch ( cmd )
> {
> +
> +case PHYSDEVOP_manage_pci_add:
> +case PHYS
Hi Roger,
Thanks for the patches. In trying them out, I found some other PHYSDEVOP
commands that were being blocked by the "default" case and were being failed
with -ENOSYS...
Would something like the change below make sense? Or is defaulting to failure
incorrect? (I saw denials for the "add
On Tue, Mar 01, 2022 at 12:53:05PM +0200, Christoph Hellwig wrote:
> 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 +-
>
On 03/03/2022 11:37, Jan Beulich wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
>
> On 02.03.2022 16:00, Jane Malalane wrote:
>> Add XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_xapic and
>> XEN_SYSCTL_PHY
On Thu, Mar 03, 2022 at 05:01:23PM +0100, Andrea Stevanato wrote:
> On 03/03/2022 15:54, Andrea Stevanato wrote:
> > Hi all,
> >
> > according to the conversation that I had with royger, aa67b97ed34 broke
> > the driver domain support.
> >
> > What I'm trying to do is to setup networking betwee
Hi Jan,
> On 1 Mar 2022, at 1:55 pm, Jan Beulich wrote:
>
> 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 add
Hi Julien,
> On 28 Feb 2022, at 10:06, Julien Grall wrote:
>
> From: Julien Grall
>
> The boot code expects the regions XEN_VIRT_START, FIXMAP_ADDR(0),
> BOOT_FDT_VIRT_START to use the same 0th (arm64 only) and 1st slot.
>
> Add some BUILD_BUG_ON() to confirm that. This is helpful if one want
On 03/03/2022 15:54, Andrea Stevanato wrote:
Hi all,
according to the conversation that I had with royger, aa67b97ed34 broke the
driver domain support.
What I'm trying to do is to setup networking between guests using driver
domain. Therefore, the guest (driver) has been started with the fol
On 03.03.2022 16:41, Anthony PERARD wrote:
> On Thu, Mar 03, 2022 at 11:37:08AM +0100, Jan Beulich wrote:
>> On 25.01.2022 12:00, Anthony PERARD wrote:
>>> --- a/xen/arch/x86/Makefile
>>> +++ b/xen/arch/x86/Makefile
>>> @@ -77,8 +77,9 @@ obj-$(CONFIG_COMPAT) += x86_64/platform_hypercall.o
>>> obj-
On Thu, Mar 03, 2022 at 09:21:48AM +0100, Juergen Gross wrote:
> On 25.02.22 16:13, Anthony PERARD wrote:
> > diff --git a/tools/include/Makefile b/tools/include/Makefile
> > index d965987f55..3a03a0b0fa 100644
> > --- a/tools/include/Makefile
> > +++ b/tools/include/Makefile
> > @@ -82,6 +82,7 @@
On Thu, Mar 03, 2022 at 11:37:08AM +0100, Jan Beulich wrote:
> On 25.01.2022 12:00, Anthony PERARD wrote:
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -77,8 +77,9 @@ obj-$(CONFIG_COMPAT) += x86_64/platform_hypercall.o
> > obj-y += sysctl.o
> > endif
> >
> > -# Allows "
On 28/02/2022 16:11, Jan Beulich wrote:
> When overriding the tool chain via CROSS_COMPILE, the resulting
> components need to be made available to, in particular (but not limited
> to) the check-endbr.sh script. Note that we don't allow overriding
> ADDR2LINE yet; this would first require addition
Hi Jan,
> On 28 Feb 2022, at 16:11, Jan Beulich wrote:
>
> When overriding the tool chain via CROSS_COMPILE, the resulting
> components need to be made available to, in particular (but not limited
> to) the check-endbr.sh script. Note that we don't allow overriding
> ADDR2LINE yet; this would fi
On Thu, Mar 03, 2022 at 11:29:36AM +0100, Jan Beulich wrote:
> On 25.01.2022 12:00, Anthony PERARD wrote:
> > Rework "arch/x86/boot/Makefile" to allow it to build both file
> > "cmdline.S" and "reloc.S" without "build32.mk".
> >
> > These will now use the main rules for "%.o: %.c", and thus genera
Hi,
> On 1 Mar 2022, at 08:24, Jan Beulich wrote:
>
> 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 reas
On Tue, Jan 25, 2022 at 11:00:59AM +, Anthony PERARD wrote:
> $(srctree) is a better description for the source directory than
> $(BASEDIR) that has been used for both source and build directory
> (which where the same).
>
> This adds $(srctree) to a few path where make's VPATH=$(srctree) won'
On Thu, Mar 03, 2022 at 01:17:03PM +0100, Jan Beulich wrote:
> On 03.03.2022 12:19, Roger Pau Monné wrote:
> > On Wed, Mar 02, 2022 at 03:19:35PM +0100, Jan Beulich wrote:
> >> As was e.g. making necessary 4b7fd8153ddf ("x86: fold sections in final
> >> binaries"), arbitrary sections appearing with
flight 168355 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168355/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168346
test-amd64-amd64-xl-qemuu-ws16-amd64
Hi all,
according to the conversation that I had with royger, aa67b97ed34 broke the
driver domain support.
What I'm trying to do is to setup networking between guests using driver
domain. Therefore, the guest (driver) has been started with the following cfg.
name = "guest0"
kernel = "/m
flight 168372 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168372/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 168366 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168366/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 168349 xen-unstable real [real]
flight 168361 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168349/
http://logs.test-lab.xenproject.org/osstest/logs/168361/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
On 3/3/22 07:24, Jan Beulich wrote:
> On 03.03.2022 13:16, Daniel P. Smith wrote:
>>
>> On 3/3/22 07:03, Jan Beulich wrote:
>>> On 03.03.2022 12:50, Daniel P. Smith wrote:
On 3/3/22 04:49, Jan Beulich wrote:
> We shouldn't include unsupported code by default, with not even a means
> fo
On 03.03.2022 11:30, Roger Pau Monne wrote:
> hvm_domain_use_pirq checking whether the passed domain is an HVM
> guests is pointless, as all calls originate from HVM only paths.
> Instead check whether the domain has PIRQ support in order to avoid
> further checks.
I agree with this, but I wonder
On 03.03.2022 11:30, Roger Pau Monne wrote:
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -556,6 +556,9 @@ static int evtchn_bind_pirq(evtchn_bind_pirq_t *bind)
> intport = 0, rc;
> unsigned int pirq = bind->pirq;
>
> +if ( is_hvm_domain(d)
flight 168364 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168364/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 03.03.2022 13:16, Daniel P. Smith wrote:
>
> On 3/3/22 07:03, Jan Beulich wrote:
>> On 03.03.2022 12:50, Daniel P. Smith wrote:
>>> On 3/3/22 04:49, Jan Beulich wrote:
We shouldn't include unsupported code by default, with not even a means
for its building to be disabled. Convert the
On 3/3/22 07:03, Jan Beulich wrote:
On 03.03.2022 12:50, Daniel P. Smith wrote:
On 3/3/22 04:49, Jan Beulich wrote:
We shouldn't include unsupported code by default, with not even a means
for its building to be disabled. Convert the dependency from merely
affecting the prompt's visibility to
On 03.03.2022 12:19, Roger Pau Monné wrote:
> On Wed, Mar 02, 2022 at 03:19:35PM +0100, Jan Beulich wrote:
>> As was e.g. making necessary 4b7fd8153ddf ("x86: fold sections in final
>> binaries"), arbitrary sections appearing without our linker script
>> placing them explicitly can be a problem. Ha
On 03.03.2022 12:50, Daniel P. Smith wrote:
> On 3/3/22 04:49, Jan Beulich wrote:
>> We shouldn't include unsupported code by default, with not even a means
>> for its building to be disabled. Convert the dependency from merely
>> affecting the prompt's visibility to a real one.
>>
>> Signed-off-by
On 02.03.2022 16:00, Jane Malalane wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -3344,16 +3344,11 @@ static void vmx_install_vlapic_mapping(struct vcpu *v)
>
> void vmx_vlapic_msr_changed(struct vcpu *v)
> {
> -int virtualize_x2apic_mode;
> struct v
Jan,
FYI, I just noticed that Lukasz old intel email was used for this patch.
I assume your tree just hasn't picked up the patch with his new email
address. Copying him now so he can see your patch.
v/r,
dps
On 3/3/22 06:50, Daniel P. Smith wrote:
On 3/3/22 04:49, Jan Beulich wrote:
We sho
On 3/3/22 04:49, Jan Beulich wrote:
We shouldn't include unsupported code by default, with not even a means
for its building to be disabled. Convert the dependency from merely
affecting the prompt's visibility to a real one.
Signed-off-by: Jan Beulich
---
We could of course go further and make
On 03.03.2022 12:40, Roger Pau Monné wrote:
> Or do we just require people with split control/hardware domain model
> to also use a different XSM policy?
I've been under the impression that this is the intended model, yes.
Jan
On 03.03.2022 12:15, Andrew Cooper wrote:
> On 03/03/2022 11:04, Jan Beulich wrote:
>> On 03.03.2022 11:48, Andrew Cooper wrote:
>>> On 03/03/2022 07:44, Jan Beulich wrote:
On 02.03.2022 23:11, Andrew Cooper wrote:
> This makes it behave slightly more like a regular boolean option.
>
>
On Thu, Mar 03, 2022 at 10:45:54AM +, Andrew Cooper wrote:
> On 03/03/2022 10:30, Roger Pau Monne wrote:
> > Control domains (including domains having control over a single other
> > guest) need access to PHYSDEVOP_{un,}map_pirq in order to setup
> > bindings of interrupts from devices assigned
On 02.03.2022 16:00, Jane Malalane wrote:
> Add XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_xapic and
> XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_x2apic to report accelerated xapic
> and x2apic, on x86 hardware.
> No such features are currently implemented on AMD hardware.
>
> For that purpose, also add an arch-speci
On 03/03/2022 10:03, Jan Beulich wrote:
> 1: xz: add fall-through comments to a switch statement
> 2: xz: fix XZ_DYNALLOC to avoid useless memory reallocations
> 3: decompressors: fix spelling mistakes
> 4: xz: avoid overlapping memcpy() with invalid input with in-place
> decompression
> 5: xz: fi
On Wed, Mar 02, 2022 at 03:19:35PM +0100, Jan Beulich wrote:
> As was e.g. making necessary 4b7fd8153ddf ("x86: fold sections in final
> binaries"), arbitrary sections appearing without our linker script
> placing them explicitly can be a problem. Have the linker make us aware
> of such sections, s
flight 168359 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168359/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 03/03/2022 11:04, Jan Beulich wrote:
> On 03.03.2022 11:48, Andrew Cooper wrote:
>> On 03/03/2022 07:44, Jan Beulich wrote:
>>> On 02.03.2022 23:11, Andrew Cooper wrote:
This makes it behave slightly more like a regular boolean option.
Signed-off-by: Andrew Cooper
>>> Reviewed-by
On 25.01.2022 12:01, Anthony PERARD wrote:
> Reorganize a bit the Makefile ahead of patch
> "build: adding out-of-tree support to the xen build"
>
> We are going to want to calculate all the $(*srctree) and $(*objtree)
> once, when we can calculate them. This can happen within the
> "$(root-make-d
On 03.03.2022 11:48, Andrew Cooper wrote:
> On 03/03/2022 07:44, Jan Beulich wrote:
>> On 02.03.2022 23:11, Andrew Cooper wrote:
>>> This makes it behave slightly more like a regular boolean option.
>>>
>>> Signed-off-by: Andrew Cooper
>> Reviewed-by: Jan Beulich
>>
>>> Slightly RFC, because ther
On Wed, Mar 02, 2022 at 05:25:10PM -0800, Stefano Stabellini wrote:
> Thinking more about it we actually need to drop the xen_initial_domain()
> check otherwise some cases won't be functional (Dom0 not 1:1 mapped, or
> DomU 1:1 mapped).
Hmm, but that would be the case even before this series, righ
On 03.03.2022 11:45, Andrew Cooper wrote:
> On 03/03/2022 10:30, Roger Pau Monne wrote:
>> --- a/xen/arch/x86/hvm/hypercall.c
>> +++ b/xen/arch/x86/hvm/hypercall.c
>> @@ -87,6 +87,13 @@ static long hvm_physdev_op(int cmd,
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>> {
>> case PHYSDEVOP_map_pi
On Wed, Mar 02, 2022 at 08:15:03AM -0500, Boris Ostrovsky wrote:
> Not for me, I fail to boot with
>
> [ 52.202000] bnxt_en :31:00.0: swiotlb buffer is full (sz: 256 bytes),
> total 0 (slots), used 0 (slots)
>
> (this is iscsi root so I need the NIC).
>
>
> I bisected it to "x86: remove the
On 25.01.2022 12:01, Anthony PERARD wrote:
> When doing an out-of-tree build, and thus setting VPATH,
> GNU Make 3.81 on Ubuntu Trusty complains about Circular dependency of
> include/Makefile and include/xlat.lst and drop them. The build fails
> later due to headers malformed.
>
> This might be d
On 03/03/2022 07:44, Jan Beulich wrote:
> On 02.03.2022 23:11, Andrew Cooper wrote:
>> This makes it behave slightly more like a regular boolean option.
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
>
>> Slightly RFC, because there is no easy way of making the opposite "normal
>>
On 03/03/2022 10:30, Roger Pau Monne wrote:
> Control domains (including domains having control over a single other
> guest) need access to PHYSDEVOP_{un,}map_pirq in order to setup
> bindings of interrupts from devices assigned to the controlled guest.
>
> As such relax the check for HVM based gue
On 25.01.2022 12:01, Anthony PERARD wrote:
> Listing public headers when out-of-tree build are involved becomes
> more annoying where every path to every headers needs to start with
> "$(srctree)/$(src)", or $(wildcard ) will not work. This means more
> repetition. ( "$(srcdir)" is a shortcut for "
On Wed, Mar 02, 2022 at 05:49:14PM +, Andrew Cooper wrote:
> On 02/03/2022 17:27, Alex Olson wrote:
> > I further attempted to see how far PVH dom0 can get but had a general
> > question regarding what is not yet implemented...
> >
> > With an initial version of Roger's recent "vpci/msix: fix
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2022年3月3日 17:15
> 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
>
> Hi Wei,
>
> O
On 03.03.2022 11:29, Andrew Cooper wrote:
> On 03/03/2022 07:35, Jan Beulich wrote:
>> On 02.03.2022 23:10, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/xen.lds.S
>>> +++ b/xen/arch/x86/xen.lds.S
>>> @@ -210,6 +210,12 @@ SECTIONS
>>>DECL_SECTION(.init.data) {
>>> #endif
>>>
>>> + . = AL
On 25.01.2022 12:00, Anthony PERARD wrote:
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -77,8 +77,9 @@ obj-$(CONFIG_COMPAT) += x86_64/platform_hypercall.o
> obj-y += sysctl.o
> endif
>
> -# Allows "clean" to descend into boot/
> +# Allows "clean" to descend
> subdir- += boo
flight 168356 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168356/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
Control domains (including domains having control over a single other
guest) need access to PHYSDEVOP_{un,}map_pirq in order to setup
bindings of interrupts from devices assigned to the controlled guest.
As such relax the check for HVM based guests and allow the usage of
the hypercalls for any con
hvm_domain_use_pirq checking whether the passed domain is an HVM
guests is pointless, as all calls originate from HVM only paths.
Instead check whether the domain has PIRQ support in order to avoid
further checks.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/hv
HVM (or PVH) domain not having PIRQ support won't be allowed to map PIRQs in
the first place, but would still be allowed usage of
EVTCHNOP_bind_pirq. Such hypercall won't have any practical effect on
the domain, as the event channels would never be bound to PIRQs.
Signed-off-by: Roger Pau Monné
-
Hello,
First two patches are cleanup related to the usage of PIRQs from HVM
guests, and shouldn't result in any functional change.
Patch 3 allows the usage of PHYSDEVOP_{un,}map_pirq for HVM control
domains even when lacking support to route PIRQs over event channels.
This is done in order to all
On 25.01.2022 12:00, Anthony PERARD wrote:
> Rework "arch/x86/boot/Makefile" to allow it to build both file
> "cmdline.S" and "reloc.S" without "build32.mk".
>
> These will now use the main rules for "%.o: %.c", and thus generate a
> dependency file. (We will not need to track the dependency manua
1 - 100 of 120 matches
Mail list logo
