On 11.10.21 22:27, Stefano Stabellini wrote:
> On Mon, 11 Oct 2021, Oleksandr Andrushchenko wrote:
>> On 11.10.21 20:15, Bertrand Marquis wrote:
>>> Hi Roger,
>>>
On 11 Oct 2021, at 17:43, Roger Pau Monné wrote:
On Mon, Oct 11, 2021 at 04:20:14PM +, Oleksandr Andrushchenko
flight 165472 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165472/
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
> From: Jan Beulich
> Sent: Monday, October 11, 2021 4:50 PM
>
> BIOSes, when enabling the dedicated DMAR unit for the sound device,
> need to also set a non-zero number of TLB entries in a respective
> system management register (VTISOCHCTRL). At least one BIOS is known
> to fail to do so,
flight 165468 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165468/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 165442
test-amd64-amd64-qemuu-nested-amd
> From: Jan Beulich
> Sent: Monday, October 11, 2021 4:49 PM
>
> Linux'es supposedly equivalent "intel_iommu=igfx_off" deals with any
> graphics devices (not just Intel ones) while at the same time limiting
> the effect to IOMMUs covering only graphics devices. Keying the decision
> to leave
Hi Julien
> -Original Message-
> From: Julien Grall
> Sent: Monday, October 11, 2021 6:49 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Wei Chen
>
> Subject: Re: [PATCH 09/11] xen/arm: if 1:1 direct-map domain use native UART
>
Hi julien
> -Original Message-
> From: Julien Grall
> Sent: Monday, October 11, 2021 7:14 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Wei Chen
>
> Subject: Re: [PATCH 10/11] xen/arm: device assignment on 1:1 direct-map
>
On Mon, 11 Oct 2021, Bertrand Marquis wrote:
> Hi Roger,
>
> > On 11 Oct 2021, at 12:43, Roger Pau Monné wrote:
> >
> > On Wed, Oct 06, 2021 at 06:40:35PM +0100, Rahul Singh wrote:
> >> This patch will be reverted once we add support for VPCI MSI/MSIX
> >> support on ARM.
> >>
> >>
On Mon, 11 Oct 2021, Anthony PERARD wrote:
> On Fri, Oct 08, 2021 at 08:55:32AM +0300, Oleksandr Andrushchenko wrote:
> > From: Oleksandr Andrushchenko
> >
> > Arm's PCI passthrough implementation doesn't support legacy interrupts,
> > but MSI/MSI-X. This can be the case for other platforms too.
On Mon, 11 Oct 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 11/10/2021 22:24, Stefano Stabellini wrote:
> > > diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
> > > index 840728d6c0..076b827bdd 100644
> > > --- a/xen/arch/arm/efi/efi-boot.h
> > > +++
flight 165467 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165467/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 165460
test-armhf-armhf-libvirt 16
Hi Stefano,
On 11/10/2021 22:24, Stefano Stabellini wrote:
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index 840728d6c0..076b827bdd 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -713,10 +713,12 @@ static int __init
On Mon, 11 Oct 2021, Stefano Stabellini wrote:
> On Mon, 11 Oct 2021, Luca Fancellu wrote:
> > > On 11 Oct 2021, at 20:53, Stefano Stabellini
> > > wrote:
> > >
> > > On Mon, 11 Oct 2021, Luca Fancellu wrote:
> > >> Add support to load Dom0 boot modules from
> > >> the device tree using the
On Mon, 11 Oct 2021, Luca Fancellu wrote:
> > On 11 Oct 2021, at 20:53, Stefano Stabellini wrote:
> >
> > On Mon, 11 Oct 2021, Luca Fancellu wrote:
> >> Add support to load Dom0 boot modules from
> >> the device tree using the xen,uefi-binary property.
> >>
> >> Update documentation about that.
> On 11 Oct 2021, at 20:53, Stefano Stabellini wrote:
>
> On Mon, 11 Oct 2021, Luca Fancellu wrote:
>> Add support to load Dom0 boot modules from
>> the device tree using the xen,uefi-binary property.
>>
>> Update documentation about that.
>>
>> Signed-off-by: Luca Fancellu
>
Hi Stefano,
flight 165463 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165463/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 14 guest-start fail REGR. vs. 165206
Tests which are
On Mon, 11 Oct 2021, Michal Orzel wrote:
> Add parameter vpmu to xl domain configuration syntax
> to enable the access to PMU registers by disabling
> the PMU traps(currently only for ARM).
>
> The current status is that the PMU registers are not
> virtualized and the physical registers are
On Mon, 11 Oct 2021, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> We need to pass info about maximum supported guest physical
> address space size to the toolstack on Arm in order to properly
> calculate the base and size of the extended region (safe range)
> for the guest. The
On Mon, 11 Oct 2021, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> The extended region (safe range) is a region of guest physical
> address space which is unused and could be safely used to create
> grant/foreign mappings instead of wasting real RAM pages from
> the domain memory
On Mon, 11 Oct 2021, Luca Fancellu wrote:
> Add support to load Dom0 boot modules from
> the device tree using the xen,uefi-binary property.
>
> Update documentation about that.
>
> Signed-off-by: Luca Fancellu
Unfortunately, due to the change to the previous patch, this patch now
has one
On Mon, 11 Oct 2021, Luca Fancellu wrote:
> This patch introduces the support for dom0less configuration
> when using UEFI boot on ARM, it permits the EFI boot to
> continue if no dom0 kernel is specified but at least one domU
> is found.
>
> Introduce the new property "xen,uefi-binary" for
On Mon, 11 Oct 2021, Oleksandr Andrushchenko wrote:
> On 11.10.21 20:15, Bertrand Marquis wrote:
> > Hi Roger,
> >
> >> On 11 Oct 2021, at 17:43, Roger Pau Monné wrote:
> >>
> >> On Mon, Oct 11, 2021 at 04:20:14PM +, Oleksandr Andrushchenko wrote:
> >>>
> >>> On 11.10.21 19:12, Bertrand
On 11.10.21 20:15, Bertrand Marquis wrote:
> Hi Roger,
>
>> On 11 Oct 2021, at 17:43, Roger Pau Monné wrote:
>>
>> On Mon, Oct 11, 2021 at 04:20:14PM +, Oleksandr Andrushchenko wrote:
>>>
>>> On 11.10.21 19:12, Bertrand Marquis wrote:
Hi Roger,
> On 11 Oct 2021, at 11:51,
On Mon, 11 Oct 2021, Jan Beulich wrote:
> On 11.10.2021 15:34, Bertrand Marquis wrote:
> >> On 11 Oct 2021, at 14:09, Jan Beulich wrote:
> >> On 11.10.2021 14:41, Bertrand Marquis wrote:
> On 7 Oct 2021, at 14:43, Jan Beulich wrote:
> On 06.10.2021 19:40, Rahul Singh wrote:
> > ---
This patch introduces the support for dom0less configuration
when using UEFI boot on ARM, it permits the EFI boot to
continue if no dom0 kernel is specified but at least one domU
is found.
Introduce the new property "xen,uefi-binary" for device tree boot
module nodes that are subnode of
Add support to load Dom0 boot modules from
the device tree using the xen,uefi-binary property.
Update documentation about that.
Signed-off-by: Luca Fancellu
---
Changes in v6:
- given the changes to is_boot_module() in previous patch,
a check to avoid declaration of xsm in DT and cfg file is
This serie introduces a way to start a dom0less setup when Xen is booting as EFI
application.
Using the device tree it's now possible to fetch from the disk and load in
memory all the modules needed to start any domU defined in the DT.
Dom0less for now is supported only by the arm architecture.
flight 165466 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165466/
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
Full perf anlaysis. Time is raw TSC cycles for a xen_version() hypercall,
compared across the change in patch 1, with obvious obvious outliers excluded.
i.e. Idealised best case improvement.
Some general notes. pv64 is `syscall`, while pv32 is `int $0x82` and
therefore has more overhead to
The is_pv_32bit_vcpu() conditionals hide four lfences, with two taken on any
individual path through the function. There is very little code common
between compat and native, and context-dependent conditionals predict very
badly for a period of time after context switch.
Move do_entry_int82()
From: Oleksandr Tyshchenko
The extended region (safe range) is a region of guest physical
address space which is unused and could be safely used to create
grant/foreign mappings instead of wasting real RAM pages from
the domain memory for establishing these mappings.
The extended regions are
From: Oleksandr Tyshchenko
We need to pass info about maximum supported guest physical
address space size to the toolstack on Arm in order to properly
calculate the base and size of the extended region (safe range)
for the guest. The extended region is unused address space which
could be safely
From: Oleksandr Tyshchenko
You can find an initial discussion at [1]-[6].
The extended region (safe range) is a region of guest physical address space
which is unused and could be safely used to create grant/foreign mappings
instead
of wasting real RAM pages from the domain memory for
On Mon, 11 Oct 2021, Bertrand Marquis wrote:
> Hi Luca,
>
> > On 11 Oct 2021, at 08:56, Luca Fancellu wrote:
> >
> > Fix for commit 60649d443dc395243e74d2b3e05594ac0c43cfe3
> > that introduces a null pointer dereference when the
> > fdt_node_offset_by_compatible is called with "fdt"
> >
On Mon, 11 Oct 2021, Bertrand Marquis wrote:
> Hi Jan,
>
> > On 11 Oct 2021, at 09:52, Jan Beulich wrote:
> >
> > On 11.10.2021 10:50, Luca Fancellu wrote:
> >>> On 11 Oct 2021, at 09:11, Jan Beulich wrote:
> >>> On 11.10.2021 10:03, Luca Fancellu wrote:
> This patch introduces the
Hi Roger,
> On 11 Oct 2021, at 17:43, Roger Pau Monné wrote:
>
> On Mon, Oct 11, 2021 at 04:20:14PM +, Oleksandr Andrushchenko wrote:
>>
>>
>> On 11.10.21 19:12, Bertrand Marquis wrote:
>>> Hi Roger,
>>>
On 11 Oct 2021, at 11:51, Roger Pau Monné wrote:
On Wed, Oct 06,
Hi Roger,
> On 11 Oct 2021, at 17:32, Roger Pau Monné wrote:
>
> On Mon, Oct 11, 2021 at 02:16:19PM +, Bertrand Marquis wrote:
>> Hi Roger,
>>
>>> On 11 Oct 2021, at 14:57, Roger Pau Monné wrote:
>>>
>>> On Mon, Oct 11, 2021 at 01:40:30PM +, Bertrand Marquis wrote:
Hi Roger,
On Mon, Oct 11, 2021 at 05:31:08PM +0200, Jan Beulich wrote:
> On 11.10.2021 16:58, Anthony PERARD wrote:
> > On Mon, Oct 11, 2021 at 12:56:54PM +0200, Jan Beulich wrote:
> >> On 24.08.2021 12:50, Anthony PERARD wrote:
> >>> With nearly everything needed to move to "build.mk" moved, there is a
>
On Mon, Oct 11, 2021 at 04:20:14PM +, Oleksandr Andrushchenko wrote:
>
>
> On 11.10.21 19:12, Bertrand Marquis wrote:
> > Hi Roger,
> >
> >> On 11 Oct 2021, at 11:51, Roger Pau Monné wrote:
> >>
> >> On Wed, Oct 06, 2021 at 06:40:34PM +0100, Rahul Singh wrote:
> >>> The existing VPCI
On Fri, Oct 08, 2021 at 08:55:32AM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Arm's PCI passthrough implementation doesn't support legacy interrupts,
> but MSI/MSI-X. This can be the case for other platforms too.
> For that reason introduce a new
On Mon, Oct 11, 2021 at 02:16:19PM +, Bertrand Marquis wrote:
> Hi Roger,
>
> > On 11 Oct 2021, at 14:57, Roger Pau Monné wrote:
> >
> > On Mon, Oct 11, 2021 at 01:40:30PM +, Bertrand Marquis wrote:
> >> Hi Roger,
> >>
> >> + Oleksandr to have a better PCI expert then me.
> >>
> >>>
On 11.10.21 19:12, Bertrand Marquis wrote:
> Hi Roger,
>
>> On 11 Oct 2021, at 11:51, Roger Pau Monné wrote:
>>
>> On Wed, Oct 06, 2021 at 06:40:34PM +0100, Rahul Singh wrote:
>>> The existing VPCI support available for X86 is adapted for Arm.
>>> When the device is added to XEN via the hyper
Hi, Anthony!
On 11.10.21 19:11, Anthony PERARD wrote:
> On Fri, Oct 08, 2021 at 08:55:31AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> The PCI device remove path may now be used by PVH on ARM, so the
>> assert is no longer valid.
> Is there maybe a patch or a
Hi Roger,
> On 11 Oct 2021, at 11:51, Roger Pau Monné wrote:
>
> On Wed, Oct 06, 2021 at 06:40:34PM +0100, Rahul Singh wrote:
>> The existing VPCI support available for X86 is adapted for Arm.
>> When the device is added to XEN via the hyper call
>> “PHYSDEVOP_pci_device_add”, VPCI handler for
On Fri, Oct 08, 2021 at 08:55:31AM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> The PCI device remove path may now be used by PVH on ARM, so the
> assert is no longer valid.
Is there maybe a patch or a commit you could point to which say that
there can be PCI
On 24.08.2021 12:50, Anthony PERARD wrote:
> When assigning a value a target-specific variable, that also affect
> prerequisite of the target. This is mostly fine, but there is one case
> where we will not want the COV_FLAGS added to the CFLAGS.
>
> In arch/x86/boot, we have "head.o" with
On 24.08.2021 12:50, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD
Acked-by: Jan Beulich
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -81,6 +81,10 @@ endif
> extra-y += asm-macros.i
> extra-y += xen.lds
>
> +hostprogs-y += boot/mkelf32
>
> On 11 Oct 2021, at 12:32, Julien Grall wrote:
>
> Hi Luca,
>
> On 11/10/2021 12:23, Luca Fancellu wrote:
>>> On 11 Oct 2021, at 10:39, Julien Grall wrote:
>>>
>>> Hi Luca,
>>>
>> Hi Julien,
>>> On 11/10/2021 09:03, Luca Fancellu wrote:
+static bool __init is_boot_module(int
On 24.08.2021 12:50, Anthony PERARD wrote:
> All those files to be removed are already done in the main Makefile,
> either by the "find" command or directly (for $(TARGET).efi).
>
> Signed-off-by: Anthony PERARD
Acked-by: Jan Beulich
On 24.08.2021 12:50, Anthony PERARD wrote:
> When we will build out-of-tree, make is going to try to generate
> "asm-macros.h" before the directories "arch/x86/include/asm" exist,
> thus we would need to call `mkdir` explicitly. We will use "filechk"
> for that as it does everything that the
On 24.08.2021 12:50, Anthony PERARD wrote:
> This just remove duplication.
>
> Signed-off-by: Anthony PERARD
Ah, here we go.
Reviewed-by: Jan Beulich
On 24.08.2021 12:50, Anthony PERARD wrote:
> This will make out-of-tree build easier.
>
> Signed-off-by: Anthony PERARD
Acked-by: Jan Beulich
On 24.08.2021 12:50, Anthony PERARD wrote:
> This will be used for xen/tools/.
>
> Signed-off-by: Anthony PERARD
Acked-by: Jan Beulich
On 24.08.2021 12:50, Anthony PERARD wrote:
> This will allow $(HOSTCFLAGS) to actually be used when building
> programmes for the build-host.
>
> The other variable don't exist in our build system.
>
> Also remove $(KBUILD_EXTMOD) since it should always be empty.
>
> Signed-off-by: Anthony
On 24.08.2021 12:50, Anthony PERARD wrote:
> Now that xen's build system is very close to Linux's ones, we can hook
> "Makefile.host" into Xen's build system, and we can build Kconfig with
> that.
>
> Signed-off-by: Anthony PERARD
Reviewed-by: Jan Beulich
On Mon, 11 Oct 2021 15:46:25 +0100,
Sean Christopherson wrote:
>
> On Mon, Oct 11, 2021, Marc Zyngier wrote:
> > On Wed, 22 Sep 2021 01:05:29 +0100, Sean Christopherson
> > wrote:
> > > diff --git a/arch/arm64/include/asm/kvm_host.h
> > > b/arch/arm64/include/asm/kvm_host.h
> > > index
On 11.10.2021 16:58, Anthony PERARD wrote:
> On Mon, Oct 11, 2021 at 12:56:54PM +0200, Jan Beulich wrote:
>> On 24.08.2021 12:50, Anthony PERARD wrote:
>>> Currently, the xen/Makefile is re-parsed several times: once to start
>>> the build process, and several more time with Rules.mk including it.
On Mon, Oct 11, 2021 at 12:56:54PM +0200, Jan Beulich wrote:
> On 24.08.2021 12:50, Anthony PERARD wrote:
> > Currently, the xen/Makefile is re-parsed several times: once to start
> > the build process, and several more time with Rules.mk including it.
> > This makes it difficult to reason with a
flight 165460 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165460/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 165452
test-armhf-armhf-libvirt 16
Hi Jan,
> On 11 Oct 2021, at 15:10, Jan Beulich wrote:
>
> On 11.10.2021 15:34, Bertrand Marquis wrote:
>>> On 11 Oct 2021, at 14:09, Jan Beulich wrote:
>>> On 11.10.2021 14:41, Bertrand Marquis wrote:
> On 7 Oct 2021, at 14:43, Jan Beulich wrote:
> On 06.10.2021 19:40, Rahul Singh
On Mon, Oct 11, 2021, Marc Zyngier wrote:
> On Wed, 22 Sep 2021 01:05:29 +0100, Sean Christopherson
> wrote:
> > diff --git a/arch/arm64/include/asm/kvm_host.h
> > b/arch/arm64/include/asm/kvm_host.h
> > index ed940aec89e0..828b6eaa2c56 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++
On 24.08.2021 12:50, Anthony PERARD wrote:
> GNU Make will try to rebuild every Makefile included with the
> "include" directive, so everytime Config.mk is used, make will try to
> build ".config". This would normally not be an issue, unless we happen
> to have a rules which match. This is the
On 24.08.2021 12:50, Anthony PERARD wrote:
> For two reasons: this macro is used to generate a "linker script" and
> is not by the linker, and name starting with an underscore '_' are
> supposed to be reserved, so better avoid them when not needed.
>
> Signed-off-by: Anthony PERARD
Reviewed-by:
On Mon, Oct 11, 2021 at 12:37:55PM +0200, Jan Beulich wrote:
> On 24.08.2021 12:50, Anthony PERARD wrote:
> > There is no need to try to guess a relative path to the "xen.efi" file,
> > we can simply use $@. Also, there's no need to use `notdir`, make
> > already do that work via $(@F).
> >
> >
On Thu, Oct 07, 2021 at 06:14:33PM +0200, Jan Beulich wrote:
> On 24.08.2021 12:50, Anthony PERARD wrote:
> > $(nr-fixups) is renamed to $(efi-check-relocs) as the former might be
> > a bit too generic.
>
> While I don't mind the prefix addition, may I please ask that the rest
> of the name
flight 165465 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165465/
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
On 24.08.2021 12:50, Anthony PERARD wrote:
> This macro does compare command line like if_changed, but it also
> rewrite the dependencies generated by $(CC) in order to depend on a
> CONFIG_* as generated by kconfig instead of depending on autoconf.h.
> This allow to make a change in kconfig
Hi Roger,
> On 11 Oct 2021, at 14:57, Roger Pau Monné wrote:
>
> On Mon, Oct 11, 2021 at 01:40:30PM +, Bertrand Marquis wrote:
>> Hi Roger,
>>
>> + Oleksandr to have a better PCI expert then me.
>>
>>> On 11 Oct 2021, at 14:20, Roger Pau Monné wrote:
>>>
>>> On Mon, Oct 11, 2021 at
Hi, all
On 11.10.21 16:40, Bertrand Marquis wrote:
> Hi Roger,
>
> + Oleksandr to have a better PCI expert then me.
>
>> On 11 Oct 2021, at 14:20, Roger Pau Monné wrote:
>>
>> On Mon, Oct 11, 2021 at 12:11:04PM +, Bertrand Marquis wrote:
>>> Hi Roger,
>>>
On 11 Oct 2021, at 12:47, Roger
On 08/09/2021 12:44, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [XEN PATCH v7 05/51] x86/mm: avoid building
> multiple .o from a single .c file"):
>> On Tue, Sep 07, 2021 at 08:14:14AM +0200, Jan Beulich wrote:
>>> Hmm, when replying to 00/51 I didn't recall I gave an R-b for this one
>>>
On Thu, Oct 07, 2021 at 04:55:01PM +0200, Jan Beulich wrote:
> On 24.08.2021 12:50, Anthony PERARD wrote:
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -332,7 +332,6 @@ xen/include/compat/*
> > xen/include/config/
> > xen/include/generated/
> > xen/include/public/public
> >
Hi Julien,
> On 11 Oct 2021, at 11:21, Julien Grall wrote:
>
> Hi Michal,
>
> On 11/10/2021 10:00, Michal Orzel wrote:
>> Add parameter vpmu to xl domain configuration syntax
>> to enable the access to PMU registers by disabling
>> the PMU traps(currently only for ARM).
>> The current status
On 11.10.2021 15:34, Bertrand Marquis wrote:
>> On 11 Oct 2021, at 14:09, Jan Beulich wrote:
>> On 11.10.2021 14:41, Bertrand Marquis wrote:
On 7 Oct 2021, at 14:43, Jan Beulich wrote:
On 06.10.2021 19:40, Rahul Singh wrote:
> --- /dev/null
> +++ b/xen/arch/arm/vpci.c
> @@
On 11/10/2021 11:06, Roger Pau Monné wrote:
> On Mon, Oct 11, 2021 at 10:20:41AM +0200, Jan Beulich wrote:
>> The conversion of the original code failed to recognize that the 32-bit
>> compat variant of this (sorry, two different meanings of "compat" here)
>> needs to continue to invoke the compat
On 24.08.2021 12:50, Anthony PERARD wrote:
> A subdirectory is now built by setting "$(obj)" instead of changing
> directory. "$(obj)" should always be set when using "Rules.mk" and
> thus a shortcut "$(build)" is introduced and should be used.
>
> A new variable "$(need-builtin)" is introduce.
On Mon, Oct 11, 2021 at 01:40:30PM +, Bertrand Marquis wrote:
> Hi Roger,
>
> + Oleksandr to have a better PCI expert then me.
>
> > On 11 Oct 2021, at 14:20, Roger Pau Monné wrote:
> >
> > On Mon, Oct 11, 2021 at 12:11:04PM +, Bertrand Marquis wrote:
> >> Hi Roger,
> >>
> >>> On 11
On Thu, Oct 07, 2021 at 04:17:28PM +0200, Jan Beulich wrote:
> On 24.08.2021 12:50, Anthony PERARD wrote:
> > --- a/tools/include/Makefile
> > +++ b/tools/include/Makefile
> > @@ -30,7 +30,7 @@ xen-dir:
> > ln -s $(XEN_ROOT)/xen/include/acpi/platform acpi/
> > ln -s
On Thu, Oct 07, 2021 at 05:11:47PM +0100, Ian Jackson wrote:
> Rahul Singh writes ("Re: [PATCH v5 10/11] arm/libxl: Emulated PCI device tree
> node in libxl"):
> > As Stefano suggested in another email that we can remove the vpci
> > option, if we reach to conclusion that we need vpci option I
Hi Roger,
+ Oleksandr to have a better PCI expert then me.
> On 11 Oct 2021, at 14:20, Roger Pau Monné wrote:
>
> On Mon, Oct 11, 2021 at 12:11:04PM +, Bertrand Marquis wrote:
>> Hi Roger,
>>
>>> On 11 Oct 2021, at 12:47, Roger Pau Monné wrote:
>>>
>>> On Wed, Oct 06, 2021 at 06:40:27PM
Hi Jan,
> On 11 Oct 2021, at 14:09, Jan Beulich wrote:
>
> On 11.10.2021 14:41, Bertrand Marquis wrote:
>>> On 7 Oct 2021, at 14:43, Jan Beulich wrote:
>>> On 06.10.2021 19:40, Rahul Singh wrote:
--- /dev/null
+++ b/xen/arch/arm/vpci.c
@@ -0,0 +1,102 @@
+/*
+ *
On 24.08.2021 12:50, Anthony PERARD wrote:
> This rework the livepatch/Makefile to make it less repetitive and make
> use of the facilities. All the targets to be built are now listed in
> $(extra-y) which will allow Rules.mk to build them without the need of
> a local target in a future patch.
>
On Mon, Oct 11, 2021 at 12:11:04PM +, Bertrand Marquis wrote:
> Hi Roger,
>
> > On 11 Oct 2021, at 12:47, Roger Pau Monné wrote:
> >
> > On Wed, Oct 06, 2021 at 06:40:27PM +0100, Rahul Singh wrote:
> >> ARM architecture does not implement I/O ports. Ignore this call on ARM
> >> to avoid the
On Mon, Oct 11, 2021 at 01:35:18PM +0200, Jan Beulich wrote:
> On 11.10.2021 13:29, Michal Orzel wrote:
> > On 08.10.2021 23:46, Stefano Stabellini wrote:
> >> On Fri, 8 Oct 2021, Julien Grall wrote:
> >>> On Fri, 8 Oct 2021, 20:07 Andrew Cooper,
> >>> wrote:
> >>> On 06/10/2021 18:40,
Jan Beulich writes ("Re: [PATCH 0/2] VT-d: correct / extend workaround(s)
leaving an IOMMU disabled [and 1 more messages]"):
> On 11.10.2021 12:56, Ian Jackson wrote:
> > I think 2/ is a new quirk (or, new behaviour for an existing quirk).
> > I think I am happy to treat that as a bugfix,
On 11.10.2021 14:41, Bertrand Marquis wrote:
>> On 7 Oct 2021, at 14:43, Jan Beulich wrote:
>> On 06.10.2021 19:40, Rahul Singh wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/arm/vpci.c
>>> @@ -0,0 +1,102 @@
>>> +/*
>>> + * xen/arch/arm/vpci.c
>>> + *
>>> + * This program is free software; you can
Hi Jan,
As Rahul is on leave, I will answer you and make the changes needed.
> On 7 Oct 2021, at 14:43, Jan Beulich wrote:
>
> On 06.10.2021 19:40, Rahul Singh wrote:
>> --- /dev/null
>> +++ b/xen/arch/arm/vpci.c
>> @@ -0,0 +1,102 @@
>> +/*
>> + * xen/arch/arm/vpci.c
>> + *
>> + * This program
On 24.08.2021 12:50, Anthony PERARD wrote:
> In a future patch, when building a subdirectory, we will set
> "obj=$subdir" rather than change directory.
>
> Before that, we add "$(obj)" and "$(src)" in as many places as
> possible where we will need to know which subdirectory is been built.
>
On 09.10.21 01:14, Stefano Stabellini wrote:
Hi Stefano
On Fri, 8 Oct 2021, Oleksandr wrote:
On 08.10.21 15:36, Jan Beulich wrote:
On 08.10.2021 12:25, Oleksandr wrote:
Just a quick question. What do you think can XEN_DOMCTL_getdomaininfo be
reused to retrieve gpaddr_bits? I don't see why
Hi Roger,
> On 11 Oct 2021, at 12:43, Roger Pau Monné wrote:
>
> On Wed, Oct 06, 2021 at 06:40:35PM +0100, Rahul Singh wrote:
>> This patch will be reverted once we add support for VPCI MSI/MSIX
>> support on ARM.
>>
>> Signed-off-by: Rahul Singh
>> Acked-by: Stefano Stabellini
>>
flight 165462 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165462/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 19ee56c4b33faa33078894a6c8495c81c660b8be
baseline version:
ovmf
Hi Roger,
> On 11 Oct 2021, at 12:47, Roger Pau Monné wrote:
>
> On Wed, Oct 06, 2021 at 06:40:27PM +0100, Rahul Singh wrote:
>> ARM architecture does not implement I/O ports. Ignore this call on ARM
>> to avoid the overhead of making a hypercall just for Xen to return
>> -ENOSYS.
>
> What is
Hi Roger,
On 11.10.2021 11:27, Roger Pau Monné wrote:
> On Wed, Oct 06, 2021 at 06:40:33PM +0100, Rahul Singh wrote:
>> Introduce XEN_DOMCTL_CDF_vpci flag to enable VPCI support in XEN.
>> Reject the use of this new flag for x86 as VPCI is not supported for
>> DOMU guests for x86.
>
> I don't
Hi Julien,
On 11.10.2021 12:17, Julien Grall wrote:
> Hi Michal,
>
> On 11/10/2021 10:00, Michal Orzel wrote:
>> ID_AA64DFR0_EL1/ID_DFR0_EL1 registers provide
>> information about PMU support. Replace structure
>> dbg64/dbg32 with a union and fill in all the
>> register fields according to
On 24.08.2021 12:50, Anthony PERARD wrote:
> $(public-y) contains "public/arch-%" but when used by
> $(PUBLIC_HEADERS) $(public-y) is filtered-out by the pattern
> "public/arch-%". So $(public-y) content is never used.
It has been this way from its very introduction, and iirc $(public-y) was
On Wed, Oct 06, 2021 at 06:40:27PM +0100, Rahul Singh wrote:
> ARM architecture does not implement I/O ports. Ignore this call on ARM
> to avoid the overhead of making a hypercall just for Xen to return
> -ENOSYS.
What is the cal trace of this function actually on Arm?
AFAICT libxl will only
On Wed, Oct 06, 2021 at 06:40:35PM +0100, Rahul Singh wrote:
> This patch will be reverted once we add support for VPCI MSI/MSIX
> support on ARM.
>
> Signed-off-by: Rahul Singh
> Acked-by: Stefano Stabellini
> Reviewed-by: Bertrand Marquis
Reviewed-by: Roger Pau Monné
> ---
> Change in v5:
On 24.08.2021 12:50, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD
Trying to synthesize a description:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -382,6 +382,7 @@ _clean:
> $(MAKE) $(clean) test
> $(MAKE) $(kconfig) clean
> find . \( -name "*.o" -o -name ".*.d" -o
On 11.10.2021 13:29, Michal Orzel wrote:
> On 08.10.2021 23:46, Stefano Stabellini wrote:
>> On Fri, 8 Oct 2021, Julien Grall wrote:
>>> On Fri, 8 Oct 2021, 20:07 Andrew Cooper, wrote:
>>> On 06/10/2021 18:40, Rahul Singh wrote:
>>> > Introduce XEN_DOMCTL_CDF_vpci flag to enable VPCI
Hi Luca,
On 11/10/2021 12:23, Luca Fancellu wrote:
On 11 Oct 2021, at 10:39, Julien Grall wrote:
Hi Luca,
Hi Julien,
On 11/10/2021 09:03, Luca Fancellu wrote:
+static bool __init is_boot_module(int dt_module_offset)
+{
+if ( (fdt_node_check_compatible(fdt, dt_module_offset,
+
On 24.08.2021 12:50, Anthony PERARD wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -271,8 +271,21 @@ CFLAGS += -flto
> LDFLAGS-$(CONFIG_CC_IS_CLANG) += -plugin LLVMgold.so
> endif
>
> +# Note that link order matters!
> +ALL_OBJS-y:= common/built_in.o
> +ALL_OBJS-y
1 - 100 of 150 matches
Mail list logo
