Re: [XEN v4 07/11] xen/arm: Introduce choice to enable 64/32 bit physical addressing

On 21.03.2023 19:33, Ayan Kumar Halder wrote: > On 21/03/2023 16:53, Jan Beulich wrote: >> On 21.03.2023 17:15, Ayan Kumar Halder wrote: >>> On 21/03/2023 14:22, Jan Beulich wrote: (Using "unsigned long" for a 32-bit paddr_t is of course suspicious as well - this ought to be uint32_t.) >>

[PATCH] x86/HVM: restrict use of pinned cache attributes as well as associated flushing

We don't permit use of uncachable memory types elsewhere unless a domain meets certain criteria. Enforce this also during registration of pinned cache attribute ranges. Furthermore restrict cache flushing to just uncachable range registration. While there, also - take CPU self-snoop as well as IOM

[xen-4.14-testing test] 179840: tolerable trouble: fail/pass/starved - PUSHED

flight 179840 xen-4.14-testing real [real] flight 179857 xen-4.14-testing real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/179840/ http://logs.test-lab.xenproject.org/osstest/logs/179857/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): t

Re: [PATCH v5] ACPI: processor: Fix evaluating _PDC method when running as Xen dom0

Hi Roger, Thank you for the patch! Yet something to improve: [auto build test ERROR on xen-tip/linux-next] [also build test ERROR on rafael-pm/linux-next linus/master v6.3-rc3 next-20230321] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we

[xen-4.16-testing test] 179842: regressions - trouble: blocked/fail/pass/starved

flight 179842 xen-4.16-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/179842/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 6 kernel-build fail REGR. vs. 179065 Tests which di

RE: [PATCH v2 3/4] xen/arm: Defer GICv2 CPU interface mapping until the first access

Hi Julien, > -Original Message- > From: Julien Grall > Subject: Re: [PATCH v2 3/4] xen/arm: Defer GICv2 CPU interface mapping until > the first access > > > gfn_to_gaddr(gfn) >= d->arch.vgic.cbase || > > gfn_to_gaddr(gfn) < d->arch.vgic.cbase + d->arch.vgic.csize > > ... use the size in

RE: [PATCH v2 4/4] xen/arm: Clean-up in p2m_init() and p2m_final_teardown()

Hi Julien, > -Original Message- > From: Julien Grall > Subject: Re: [PATCH v2 4/4] xen/arm: Clean-up in p2m_init() and > p2m_final_teardown() > > Hi Henry, > > > --- > > I am not entirely sure if I should also drop the "TODO" on top of > > the p2m_set_entry(). Because although we are su

Re: [PATCH v5] ACPI: processor: Fix evaluating _PDC method when running as Xen dom0

Hi Roger, Thank you for the patch! Yet something to improve: [auto build test ERROR on xen-tip/linux-next] [also build test ERROR on rafael-pm/linux-next linus/master v6.3-rc3 next-20230321] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we

Re: [BUG] x2apic broken with current AMD hardware

On Tue, Mar 21, 2023 at 08:13:15AM +0100, Jan Beulich wrote: > On 21.03.2023 05:19, Elliott Mitchell wrote: > > > The above appears about twice for each core, then I start seeing > > "(XEN) CPU#: No irq handler for vector ?? (IRQ -2147483648, LAPIC)" > > > > The core doesn't vary too much with th

[xen-unstable test] 179834: tolerable trouble: fail/pass/starved - PUSHED

flight 179834 xen-unstable real [real] flight 179851 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/179834/ http://logs.test-lab.xenproject.org/osstest/logs/179851/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd6

[linux-linus test] 179830: regressions - trouble: fail/pass/starved

flight 179830 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/179830/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit1 17 guest-saverestorefail REGR. vs. 178042 test-amd64-amd64-fr

Re: [PATCH] xen/arm: irq: Constify the first parameter of platform_get_irq_byname()

On Tue, 20 Mar 2023, Michal Orzel wrote: > Hi Julien, > > On 21/03/2023 18:17, Julien Grall wrote: > > > > > > From: Julien Grall > > > > platform_get_irq_byname() is not meant to modify the parameter 'np'. So > > constify it. > > > > Signed-off-by: Julien Grall > Reviewed-by: Michal Orzel

Re: [RFC PATCH 1/5] x86/xen: disable swiotlb for xen pvh

Am 17.03.23 um 15:45 schrieb Alex Deucher: On Thu, Mar 16, 2023 at 7:09 PM Stefano Stabellini wrote: On Thu, 16 Mar 2023, Juergen Gross wrote: On 16.03.23 14:53, Alex Deucher wrote: On Thu, Mar 16, 2023 at 9:48 AM Juergen Gross wrote: On 16.03.23 14:45, Alex Deucher wrote: On Thu, Mar 16,

Re: [XEN v4 07/11] xen/arm: Introduce choice to enable 64/32 bit physical addressing

Hi Jan, On 21/03/2023 16:53, Jan Beulich wrote: On 21.03.2023 17:15, Ayan Kumar Halder wrote: On 21/03/2023 14:22, Jan Beulich wrote: On 21.03.2023 15:03, Ayan Kumar Halder wrote: --- a/xen/arch/Kconfig +++ b/xen/arch/Kconfig @@ -1,6 +1,12 @@ config 64BIT bool +config PHYS_ADDR

Re: [PATCH v2 1/3] xen/riscv: introduce setup_initial_pages

Hi, I will try to not repeat the comment already made. On 16/03/2023 16:43, Oleksii Kurochko wrote: Mostly the code for setup_initial_pages was taken from Bobby's repo except for the following changes: * Use only a minimal part of the code enough to enable MMU * rename {_}setup_initial_pagetabl

Re: [PATCH] xen/arm: irq: Constify the first parameter of platform_get_irq_byname()

Hi Julien, On 21/03/2023 18:17, Julien Grall wrote: > > > From: Julien Grall > > platform_get_irq_byname() is not meant to modify the parameter 'np'. So > constify it. > > Signed-off-by: Julien Grall Reviewed-by: Michal Orzel ~Michal

Re: [PATCH v5 5/7] xen/riscv: introduce trap_init()

Hi Oleksii, On 16/03/2023 14:39, Oleksii Kurochko wrote: Signed-off-by: Oleksii Kurochko Reviewed-by: Alistair Francis --- Changes in V5: - Nothing changed --- Changes in V4: - Nothing changed --- Changes in V3: - Nothing changed --- Changes in V2: - Rename setup_trap_handler() to

[PATCH v6 5/5] Automation and CI: Replace git:// and http:// with https://

Obtaining code over an insecure transport is a terrible idea for blatently obvious reasons. Even for non-executable data, insecure transports are considered deprecated. This patch enforces the use of secure transports in automation and CI. All URLs are known to work. Signed-off-by: Demi Marie Ob

[PATCH v6 4/5] Build system: Replace git:// and http:// with https://

Obtaining code over an insecure transport is a terrible idea for blatently obvious reasons. Even for non-executable data, insecure transports are considered deprecated. This patch enforces the use of secure transports in the build system. Some URLs returned 301 or 302 redirects, so I replaced the

[PATCH v6 3/5] Build system: Do not try to use broken links

The upstream URLs for zlib, PolarSSL, and the TPM emulator do not work anymore, so do not attempt to use them. Signed-off-by: Demi Marie Obenour --- m4/stubdom.m4| 5 +++-- stubdom/configure| 21 +++-- stubdom/configure.ac | 6 +++--- 3 files changed, 9 insertions(+

[PATCH v6 2/5] Change remaining xenbits.xen.org link to HTTPS

Obtaining code over an insecure transport is a terrible idea for blatently obvious reasons. Even for non-executable data, insecure transports are considered deprecated. This patch enforces the use of secure transports for all xenbits.xen.org URLs. All altered links have been tested and are known

[PATCH v6 1/5] Use HTTPS for all xenbits.xen.org Git repos

Obtaining code over an insecure transport is a terrible idea for blatently obvious reasons. Even for non-executable data, insecure transports are considered deprecated. This patch enforces the use of secure transports for all xenbits.xen.org Git repositories. It was generated with the following

[PATCH v6 0/5] Stop using insecure transports

Obtaining code over an insecure transport is a terrible idea for blatently obvious reasons. Even for non-executable data, insecure transports are considered deprecated. Changes since v5: - Rebase on top of the staging branch. - Do not replace a xenbits.xenproject.org link with a xenbits.xen.org

Re: [PATCH v5 4/7] xen/riscv: introduce decode_cause() stuff

Hi Oleksii, On 16/03/2023 14:39, Oleksii Kurochko wrote: The patch introduces stuff needed to decode a reason of an exception. Signed-off-by: Oleksii Kurochko --- Changes in V5: - Remove from riscv/traps/c as nothing would require inclusion. - decode_reserved_interrupt_cause(), dec

[libvirt test] 179829: tolerable trouble: pass/starved - PUSHED

flight 179829 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/179829/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-s

Re: [PATCH v5 3/7] xen/riscv: introduce dummy

Hi Oleksii, On 16/03/2023 14:39, Oleksii Kurochko wrote: will be used in the patch "xen/riscv: introduce decode_cause() stuff" and requires Signed-off-by: Oleksii Kurochko --- Changes in V5: * the patch was introduced in the current patch series (V5) --- xen/arch/riscv/include/asm/bug.h

Re: [PATCH v3 1/4] tools: rename xen-tools/libs.h file to common-macros.h

On Mon, Mar 06, 2023 at 08:21:37AM +0100, Juergen Gross wrote: > In order to better reflect the contents of the header and to make it > more appropriate to use it for different runtime environments like > programs, libraries, and firmware, rename the libs.h include file to > common-macros.h. Additi

[PATCH] xen/arm: irq: Constify the first parameter of platform_get_irq_byname()

From: Julien Grall platform_get_irq_byname() is not meant to modify the parameter 'np'. So constify it. Signed-off-by: Julien Grall --- xen/arch/arm/include/asm/irq.h | 2 +- xen/arch/arm/irq.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/incl

Re: [PATCH v3 2/2] arch/arm: time: Add support for parsing interrupts by names

Hi, On 13/03/2023 13:08, Andrei Cherechesu (OSS) wrote: From: Andrei Cherechesu Added support for parsing the ARM generic timer interrupts DT node by the "interrupt-names" property, if it is available. If not available, the usual parsing based on the expected IRQ order is performed. Also tre

Re: [PATCH v2 2/3] xen/riscv: setup initial pagetables

On Mon, 2023-03-20 at 18:03 +0100, Jan Beulich wrote: > On 16.03.2023 17:43, Oleksii Kurochko wrote: > > Signed-off-by: Oleksii Kurochko > > --- > > Changes in V2: > >  * Update the commit message > > Odd: It's empty. Since it's not part of the title, you could at least > say that you're also ena

Re: [PATCH v2 1/3] xen/riscv: introduce setup_initial_pages

On Mon, 2023-03-20 at 17:41 +0100, Jan Beulich wrote: > On 16.03.2023 17:43, Oleksii Kurochko wrote: > > --- /dev/null > > +++ b/xen/arch/riscv/include/asm/mm.h > > @@ -0,0 +1,8 @@ > > +#ifndef _ASM_RISCV_MM_H > > +#define _ASM_RISCV_MM_H > > + > > +void setup_initial_pagetables(void); > > + > > +e

Re: [PATCH v2] x86: use POPCNT for hweight() when available

On Tue, Mar 21, 2023 at 05:41:52PM +0100, Jan Beulich wrote: > On 21.03.2023 17:31, Roger Pau Monné wrote: > > On Tue, Mar 21, 2023 at 04:35:54PM +0100, Jan Beulich wrote: > >> On 21.03.2023 15:57, Roger Pau Monné wrote: > >>> On Mon, Mar 20, 2023 at 10:48:45AM +0100, Jan Beulich wrote: > On 1

Re: [PATCH] move {,vcpu_}show_execution_state() declarations to common header

On 21.03.2023 17:44, Julien Grall wrote: > On 16/03/2023 11:55, Jan Beulich wrote: >> These are used from common code, so their signatures should be >> consistent across architectures. This is achieved / guaranteed easiest >> when their declarations are in a common header. >> >> Signed-off-by: Jan

Re: [PATCH v3 1/2] arch/arm: irq: Add platform_get_irq_byname() implementation

Hi Andrei, I realized this has already been merged. But I would like to point out a few things for future series. On 13/03/2023 13:08, Andrei Cherechesu (OSS) wrote: From: Andrei Cherechesu Moved implementation for the function which parses the IRQs of a DT node by the "interrupt-names" pro

Re: [XEN v4 07/11] xen/arm: Introduce choice to enable 64/32 bit physical addressing

On 21.03.2023 17:15, Ayan Kumar Halder wrote: > On 21/03/2023 14:22, Jan Beulich wrote: >> On 21.03.2023 15:03, Ayan Kumar Halder wrote: >>> --- a/xen/arch/Kconfig >>> +++ b/xen/arch/Kconfig >>> @@ -1,6 +1,12 @@ >>> config 64BIT >>> bool >>> >>> +config PHYS_ADDR_T_32 >>> + bool >>> + >>

Re: [PATCH] move {,vcpu_}show_execution_state() declarations to common header

Hi Jan, On 16/03/2023 11:55, Jan Beulich wrote: These are used from common code, so their signatures should be consistent across architectures. This is achieved / guaranteed easiest when their declarations are in a common header. Signed-off-by: Jan Beulich --- There's no really good header to

Re: [PATCH v2] x86: use POPCNT for hweight() when available

On 21.03.2023 17:31, Roger Pau Monné wrote: > On Tue, Mar 21, 2023 at 04:35:54PM +0100, Jan Beulich wrote: >> On 21.03.2023 15:57, Roger Pau Monné wrote: >>> On Mon, Mar 20, 2023 at 10:48:45AM +0100, Jan Beulich wrote: On 17.03.2023 13:26, Andrew Cooper wrote: > On 17/03/2023 11:22 am, Rog

Re: [PATCH v2] x86: use POPCNT for hweight() when available

On Tue, Mar 21, 2023 at 04:35:54PM +0100, Jan Beulich wrote: > On 21.03.2023 15:57, Roger Pau Monné wrote: > > On Mon, Mar 20, 2023 at 10:48:45AM +0100, Jan Beulich wrote: > >> On 17.03.2023 13:26, Andrew Cooper wrote: > >>> On 17/03/2023 11:22 am, Roger Pau Monné wrote: > On Mon, Jul 15, 2019

Re: [PATCH] x86: extend coverage of HLE "bad page" workaround

On 21.03.2023 15:51, Andrew Cooper wrote: > On 20/03/2023 9:24 am, Jan Beulich wrote: >> On 17.03.2023 12:39, Roger Pau Monné wrote: >>> On Tue, May 26, 2020 at 06:40:16PM +0200, Jan Beulich wrote: On 26.05.2020 17:01, Andrew Cooper wrote: > On 26/05/2020 14:35, Jan Beulich wrote: >> O

[xen-unstable-smoke test] 179845: tolerable trouble: pass/starved - PUSHED

flight 179845 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/179845/ 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

Re: [PATCH v1 1/3] xen/riscv: introduce setup_initial_pages

On 05/03/2023 16:25, Oleksii wrote: Hi Julien, Hi, Sorry for the late answer. I was away for the past couple of weeks. On Mon, 2023-02-27 at 17:36 +, Julien Grall wrote: Hi Oleksii, On 27/02/2023 16:52, Oleksii wrote: On Sat, 2023-02-25 at 17:53 +, Julien Grall wrote: +/* + *

Re: [XEN v4 07/11] xen/arm: Introduce choice to enable 64/32 bit physical addressing

Hi Jan, On 21/03/2023 14:22, Jan Beulich wrote: On 21.03.2023 15:03, Ayan Kumar Halder wrote: --- a/xen/arch/Kconfig +++ b/xen/arch/Kconfig @@ -1,6 +1,12 @@ config 64BIT bool +config PHYS_ADDR_T_32 + bool + +config PHYS_ADDR_T_64 + bool Do we really need both? I was

Re: [PATCH] x86: extend coverage of HLE "bad page" workaround

On 21/03/2023 3:59 pm, Roger Pau Monné wrote: > On Tue, Mar 21, 2023 at 02:51:30PM +, Andrew Cooper wrote: >> On 20/03/2023 9:24 am, Jan Beulich wrote: >>> On 17.03.2023 12:39, Roger Pau Monné wrote: On Tue, May 26, 2020 at 06:40:16PM +0200, Jan Beulich wrote: > On 26.05.2020 17:01, An

Re: [PATCH] x86: extend coverage of HLE "bad page" workaround

On 21.03.2023 16:58, Roger Pau Monné wrote: > On Tue, Mar 21, 2023 at 04:51:43PM +0100, Jan Beulich wrote: >> On 21.03.2023 15:42, Roger Pau Monné wrote: >>> On Tue, May 26, 2020 at 08:49:52AM +0200, Jan Beulich wrote: Respective Core Gen10 processor lines are affected, too. Signed-o

Re: [PATCH] x86: extend coverage of HLE "bad page" workaround

On Tue, Mar 21, 2023 at 02:51:30PM +, Andrew Cooper wrote: > On 20/03/2023 9:24 am, Jan Beulich wrote: > > On 17.03.2023 12:39, Roger Pau Monné wrote: > >> On Tue, May 26, 2020 at 06:40:16PM +0200, Jan Beulich wrote: > >>> On 26.05.2020 17:01, Andrew Cooper wrote: > On 26/05/2020 14:35, Ja

Re: [PATCH] x86: extend coverage of HLE "bad page" workaround

On Tue, Mar 21, 2023 at 04:51:43PM +0100, Jan Beulich wrote: > On 21.03.2023 15:42, Roger Pau Monné wrote: > > On Tue, May 26, 2020 at 08:49:52AM +0200, Jan Beulich wrote: > >> Respective Core Gen10 processor lines are affected, too. > >> > >> Signed-off-by: Jan Beulich > >> > >> --- a/xen/arch/x8

Re: [PATCH] x86: extend coverage of HLE "bad page" workaround

On 21.03.2023 15:42, Roger Pau Monné wrote: > On Tue, May 26, 2020 at 08:49:52AM +0200, Jan Beulich wrote: >> Respective Core Gen10 processor lines are affected, too. >> >> Signed-off-by: Jan Beulich >> >> --- a/xen/arch/x86/mm.c >> +++ b/xen/arch/x86/mm.c >> @@ -6045,6 +6045,8 @@ const struct pla

Re: [PATCH v2 4/4] xen/arm: Clean-up in p2m_init() and p2m_final_teardown()

Hi Henry, On 30/01/2023 04:06, Henry Wang wrote: With the change in previous patch, the initial 16 pages in the P2M pool is not necessary anymore. Drop them for code simplification. Also the call to p2m_teardown() from arch_domain_destroy() is not necessary anymore since the movement of the P2M

Re: [PATCH v2] x86: use POPCNT for hweight() when available

On 21.03.23 16:35, Jan Beulich wrote: On 21.03.2023 15:57, Roger Pau Monné wrote: On Mon, Mar 20, 2023 at 10:48:45AM +0100, Jan Beulich wrote: On 17.03.2023 13:26, Andrew Cooper wrote: On 17/03/2023 11:22 am, Roger Pau Monné wrote: On Mon, Jul 15, 2019 at 02:39:04PM +, Jan Beulich wrote:

Re: [PATCH v2] vpci/msix: handle accesses adjacent to the MSI-X table

On 21.03.2023 16:31, Roger Pau Monné wrote: > On Mon, Mar 20, 2023 at 01:08:48PM +0100, Jan Beulich wrote: >> On 16.03.2023 13:07, Roger Pau Monne wrote: >>> { >>> -struct vpci *vpci = msix->pdev->vpci; >>> -unsigned int idx = addr - vmsix_table_addr(vpci, VPCI_MSIX_PBA); >>> -

Re: [PATCH] tools: use libxenlight for writing xenstore-stubdom console nodes

On 21.03.23 16:02, Anthony PERARD wrote: On Wed, Mar 15, 2023 at 04:42:26PM +0100, Juergen Gross wrote: @@ -1982,6 +1987,13 @@ int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num, */ int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm, char **path); +

Re: [PATCH v2] x86: use POPCNT for hweight() when available

On 21.03.2023 15:57, Roger Pau Monné wrote: > On Mon, Mar 20, 2023 at 10:48:45AM +0100, Jan Beulich wrote: >> On 17.03.2023 13:26, Andrew Cooper wrote: >>> On 17/03/2023 11:22 am, Roger Pau Monné wrote: On Mon, Jul 15, 2019 at 02:39:04PM +, Jan Beulich wrote: > This is faster than usin

Re: [PATCH v2 3/4] xen/arm: Defer GICv2 CPU interface mapping until the first access

On 21/03/2023 03:57, Henry Wang wrote: Hi Julien, Hi Henry, -Original Message- From: Julien Grall Subject: Re: [PATCH v2 3/4] xen/arm: Defer GICv2 CPU interface mapping until the first access Hi Henry, On 30/01/2023 04:06, Henry Wang wrote: Since the hardware domain (Dom0) has an

Re: [PATCH v2] vpci/msix: handle accesses adjacent to the MSI-X table

On Mon, Mar 20, 2023 at 01:08:48PM +0100, Jan Beulich wrote: > On 16.03.2023 13:07, Roger Pau Monne wrote: > > --- a/xen/drivers/vpci/msix.c > > +++ b/xen/drivers/vpci/msix.c > > @@ -27,6 +27,11 @@ > > ((addr) >= vmsix_table_addr(vpci, nr) && \ > > (addr) < v

Re: [XEN PATCH v1 1/1] x86/domctl: add gva_to_gfn command

Thanks to all for suggestions and notes. Though as Andrew Cooper noticed current approach is too over simplified. As Tams K Lengyel noticed the effect could be too negligible and some OS specific logic should be present. So as for today we could drop the patch. 20.03.2023 19:32, Ковалёв Сергей

Re: [PATCH] tools: use libxenlight for writing xenstore-stubdom console nodes

On Wed, Mar 15, 2023 at 04:42:26PM +0100, Juergen Gross wrote: > @@ -1982,6 +1987,13 @@ int libxl_console_get_tty(libxl_ctx *ctx, uint32_t > domid, int cons_num, > */ > int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm, char > **path); > > +/* libxl_console_add_xenstore wri

Re: [PATCH v2] x86: use POPCNT for hweight() when available

On Mon, Mar 20, 2023 at 10:48:45AM +0100, Jan Beulich wrote: > On 17.03.2023 13:26, Andrew Cooper wrote: > > On 17/03/2023 11:22 am, Roger Pau Monné wrote: > >> On Mon, Jul 15, 2019 at 02:39:04PM +, Jan Beulich wrote: > >>> This is faster than using the software implementation, and the insn is

Re: [PATCH] x86: extend coverage of HLE "bad page" workaround

On 20/03/2023 9:24 am, Jan Beulich wrote: > On 17.03.2023 12:39, Roger Pau Monné wrote: >> On Tue, May 26, 2020 at 06:40:16PM +0200, Jan Beulich wrote: >>> On 26.05.2020 17:01, Andrew Cooper wrote: On 26/05/2020 14:35, Jan Beulich wrote: > On 26.05.2020 13:17, Andrew Cooper wrote: >> O

[qemu-mainline test] 179824: regressions - trouble: fail/pass/starved

flight 179824 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/179824/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt 14 guest-start fail REGR. vs. 179518 test-amd64-i386-l

Re: [PATCH v8 1/5] xen: introduce CONFIG_GENERIC_BUG_FRAME

On Tue, 2023-03-21 at 14:35 +0100, Jan Beulich wrote: > On 21.03.2023 12:18, Oleksii wrote: > > On Mon, 2023-03-20 at 13:36 +0200, Oleksii wrote: > > > On Fri, 2023-03-17 at 15:59 +0100, Jan Beulich wrote: > > > > On 17.03.2023 10:23, Oleksii wrote: > > > > > On Thu, 2023-03-16 at 12:26 +0100, Jan

Re: [PATCH v5 2/7] xen/riscv: initialize boot_info structure

On Tue, 2023-03-21 at 12:27 +0100, Jan Beulich wrote: > On 16.03.2023 15:39, Oleksii Kurochko wrote: > > --- a/xen/arch/riscv/setup.c > > +++ b/xen/arch/riscv/setup.c > > @@ -1,12 +1,16 @@ > >  #include > >  #include > > +#include > >   > > +#include > >  #include > >   > >  /* Xen stack for b

Re: [PATCH] x86: extend coverage of HLE "bad page" workaround

On Tue, May 26, 2020 at 08:49:52AM +0200, Jan Beulich wrote: > Respective Core Gen10 processor lines are affected, too. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -6045,6 +6045,8 @@ const struct platform_bad_page *__init g > case 0x000506e0: /*

Re: [BUG] x2apic broken with current AMD hardware

> > >> I was taking a look at the BIOS manual for this motherboard and noticed > > >> a mention of a "Local APIC Mode" setting. Four values are listed > > >> "Compatibility", "xAPIC", "x2APIC", and "Auto". > > This does appear to be an improvement. With this the system boots if > the

Re: [PATCH v5 1/7] xen/riscv: introduce boot information structure

On Tue, 2023-03-21 at 12:17 +0100, Jan Beulich wrote: > On 16.03.2023 15:39, Oleksii Kurochko wrote: > > @@ -50,4 +51,6 @@ void asm_offsets(void) > > OFFSET(CPU_USER_REGS_SEPC, struct cpu_user_regs, sepc); > > OFFSET(CPU_USER_REGS_SSTATUS, struct cpu_user_regs, sstatus); > > OFFSET(C

preparations for 4.16.4 and 4.17.1

All, the former release is due in a couple of weeks time, the latter a week or two later. Note that with us following the 4 month cadence pretty strictly this time, 4.16.4 isn't expected to be the last ordinary stable release from the 4.16 branch, yet (unless, of course, we end up slipping signifi

Re: [XEN v4 07/11] xen/arm: Introduce choice to enable 64/32 bit physical addressing

On 21.03.2023 15:03, Ayan Kumar Halder wrote: > --- a/xen/arch/Kconfig > +++ b/xen/arch/Kconfig > @@ -1,6 +1,12 @@ > config 64BIT > bool > > +config PHYS_ADDR_T_32 > + bool > + > +config PHYS_ADDR_T_64 > + bool Do we really need both? If so, what guards against both being selected

[PATCH v5] ACPI: processor: Fix evaluating _PDC method when running as Xen dom0

In ACPI systems, the OS can direct power management, as opposed to the firmware. This OS-directed Power Management is called OSPM. Part of telling the firmware that the OS going to direct power management is making ACPI "_PDC" (Processor Driver Capabilities) calls. These _PDC methods must be eva

Re: [XEN v4 04/11] xen/drivers: ns16550: Use paddr_t for io_base/io_size

On 21.03.2023 15:03, Ayan Kumar Halder wrote: > @@ -1163,10 +1163,16 @@ static const struct ns16550_config __initconst > uart_config[] = > }, > }; > > +#define PARSE_ERR_RET(_f, _a...) \ > +do { \ > +printk( "ERROR: " _f "\n" , ##

[XEN v4 10/11] xen/arm: p2m: Use the pa_range_info table to support Arm_32 and Arm_64

Restructure the code so that one can use pa_range_info[] table for both ARM_32 as well as ARM_64. Signed-off-by: Ayan Kumar Halder --- Changes from - v3 - 1. New patch introduced in v4. 2. Restructure the code such that pa_range_info[] is used both by ARM_32 as well as ARM_64. xen/arch/arm/p2m

[XEN v4 09/11] xen/arm: Restrict zeroeth_table_offset for ARM_64

When 32 bit physical addresses are used (ie ARM_PA_32=y), "va >> ZEROETH_SHIFT" causes an overflow. Also, there is no zeroeth level page table on Arm 32-bit. Also took the opportunity to clean up dump_pt_walk(). One could use DECLARE_OFFSETS() macro instead of declaring the declaring an array of p

Re: [PATCH v4] x86: detect CMOS aliasing on ports other than 0x70/0x71

On Mon, Mar 20, 2023 at 09:32:26AM +0100, Jan Beulich wrote: > ... in order to also intercept Dom0 accesses through the alias ports. I'm trying to get some documentation about this aliasing, but so far I haven't been able to find any. Do you have any references of where I might be able to find it

[XEN v4 11/11] xen/arm: p2m: Enable support for 32bit IPA for ARM_32

The pabits, t0sz, root_order and sl0 values are the same as those for ARM_64. Signed-off-by: Ayan Kumar Halder --- Changes from - v1 - New patch. v2 - 1. Added Ack. v3 - 1. Dropped Ack. 2. Rebased the patch based on the previous change. xen/arch/arm/p2m.c | 5 +++-- 1 file changed, 3 inser

[XEN v4 05/11] xen/arm: Introduce a wrapper for dt_device_get_address() to handle paddr_t

dt_device_get_address() can accept uint64_t only for address and size. However, the address/size denotes physical addresses. Thus, they should be represented by 'paddr_t'. Consequently, we introduce a wrapper for dt_device_get_address() ie dt_device_get_paddr() which accepts address/size as paddr_t

[XEN v4 08/11] xen/arm: guest_walk: LPAE specific bits should be enclosed within "ifndef CONFIG_PHYS_ADDR_T_32"

As the previous patch introduces CONFIG_PHYS_ADDR_T_32 to support 32 bit physical addresses, the code specific to "Large Physical Address Extension" (ie LPAE) should be enclosed within "ifndef CONFIG_PHYS_ADDR_T_32". Refer xen/arch/arm/include/asm/short-desc.h, "short_desc_l1_supersec_t" unsigned

[XEN v4 07/11] xen/arm: Introduce choice to enable 64/32 bit physical addressing

Some Arm based hardware platforms which does not support LPAE (eg Cortex-R52), uses 32 bit physical addresses. Also, users may choose to use 32 bits to represent physical addresses for optimization. To support the above use cases, we have introduced arch independent configs to choose if the physic

[XEN v4 06/11] xen/arm: smmu: Use writeq_relaxed_non_atomic() for writing to SMMU_CBn_TTBR0

Refer ARM IHI 0062D.c ID070116 (SMMU 2.0 spec), 17-360, 17.3.9, SMMU_CBn_TTBR0 is a 64 bit register. Thus, one can use writeq_relaxed_non_atomic() to write to it instead of invoking writel_relaxed() twice for lower half and upper half of the register. This also helps us as p2maddr is 'paddr_t' (wh

Re: [PATCH v4] acpi/processor: fix evaluating _PDC method when running as Xen dom0

On Tue, Mar 21, 2023 at 3:02 PM Roger Pau Monné wrote: > > On Tue, Mar 21, 2023 at 02:47:46PM +0100, Rafael J. Wysocki wrote: > > On Thu, Mar 16, 2023 at 5:43 PM Roger Pau Monne > > wrote: > > > > > > In ACPI systems, the OS can direct power management, as opposed to the > > > firmware. This OS

[XEN v4 04/11] xen/drivers: ns16550: Use paddr_t for io_base/io_size

io_base and io_size represent physical addresses. So they should use paddr_t (instead of u64). However in future, paddr_t may be defined as u32. So when typecasting values from u64 to paddr_t, one should always check for any possible truncation. If any truncation is discovered, Xen needs to return

[XEN v4 03/11] xen/arm: Typecast the DT values into paddr_t

In future, we wish to support 32 bit physical address. However, the current dt and fdt functions can only read u64 values. We wish to make the DT functions read 32bit as well 64bit values (depending on the width of physical address). Also, we wish to detect if any truncation has occurred (ie while

[XEN v4 02/11] xen/arm: domain_build: Track unallocated pages using the frame number

rangeset_{xxx}_range() functions are invoked with 'start' and 'size' as arguments which are either 'uint64_t' or 'paddr_t'. However, the function accepts 'unsigned long' for 'start' and 'size'. 'unsigned long' is 32 bits for ARM_32. Thus, there is an implicit downcasting from 'uint64_t'/'paddr_t' t

[XEN v4 01/11] xen/arm: Use the correct format specifier

1. One should use 'PRIpaddr' to display 'paddr_t' variables. However, while creating nodes in fdt, the address (if present in the node name) should be represented using 'PRIx64'. This is to be in conformance with the following rule present in https://elinux.org/Device_Tree_Linux . node names "unit

[XEN v4 00/11] Add support for 32 bit physical address

Hi All, Please have a look at https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg01465.html for the context. The benefits of using 32 bit physical addresses are as follows :- 1. It helps to use Xen on platforms (for eg R52) which supports 32 bit physical addresses and has no suppor

Re: [PATCH v4] acpi/processor: fix evaluating _PDC method when running as Xen dom0

On Tue, Mar 21, 2023 at 02:47:46PM +0100, Rafael J. Wysocki wrote: > On Thu, Mar 16, 2023 at 5:43 PM Roger Pau Monne wrote: > > > > In ACPI systems, the OS can direct power management, as opposed to the > > firmware. This OS-directed Power Management is called OSPM. Part of > > telling the firmw

[XEN PATCH v5] x86/monitor: Add new monitor event to catch I/O instructions

Adds monitor support for I/O instructions. Signed-off-by: Dmitry Isaykin Signed-off-by: Anton Belousov --- Changes in v5: * Rebase on staging Changes in v4: * Avoid the use of fixed-width types * Document vm_event_io structure fields * Untie vm-event interface from ioreq one Changes in v3:

Re: [PATCH v4] acpi/processor: fix evaluating _PDC method when running as Xen dom0

On Thu, Mar 16, 2023 at 5:43 PM Roger Pau Monne wrote: > > In ACPI systems, the OS can direct power management, as opposed to the > firmware. This OS-directed Power Management is called OSPM. Part of > telling the firmware that the OS going to direct power management is > making ACPI "_PDC" (Pro

Re: [XEN PATCH v1 1/1] x86/domctl: add gva_to_gfn command

On 21/03/2023 7:28 am, Jan Beulich wrote: > On 20.03.2023 20:07, Andrew Cooper wrote: >> On 20/03/2023 4:32 pm, Ковалёв Сергей wrote: >>> gva_to_gfn command used for fast address translation in LibVMI project. >>> With such a command it is possible to perform address translation in >>> single call

Re: [PATCH v3 3/3] tools/xen-ucode: print information about currently loaded ucode

On 21/03/2023 11:47 am, Sergey Dyasli wrote: > Add an option to xen-ucode tool to print the currently loaded ucode > version and also print it during usage info. Print CPU signature and > processor flags as well. The raw data comes from XENPF_get_cpu_version > and XENPF_get_ucode_version platform

Re: [PATCH v8 1/5] xen: introduce CONFIG_GENERIC_BUG_FRAME

On 21.03.2023 12:18, Oleksii wrote: > On Mon, 2023-03-20 at 13:36 +0200, Oleksii wrote: >> On Fri, 2023-03-17 at 15:59 +0100, Jan Beulich wrote: >>> On 17.03.2023 10:23, Oleksii wrote: On Thu, 2023-03-16 at 12:26 +0100, Jan Beulich wrote: > On 15.03.2023 18:21, Oleksii Kurochko wrote:

Re: [PATCH v3 2/3] x86/platform: introduce XENPF_get_ucode_version

On 21.03.2023 12:47, Sergey Dyasli wrote: > --- a/xen/arch/x86/platform_hypercall.c > +++ b/xen/arch/x86/platform_hypercall.c > @@ -640,6 +640,36 @@ ret_t do_platform_op( > } > break; > > +case XENPF_get_ucode_version: > +{ > +struct xenpf_ucode_version *ver = &op->u.uco

[xen-unstable-smoke test] 179838: tolerable trouble: pass/starved - PUSHED

flight 179838 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/179838/ 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

Re: [XEN PATCH v1 1/1] x86/domctl: add gva_to_gfn command

On Tue, Mar 21, 2023 at 3:49 AM Ковалёв Сергей wrote: > > > > 21.03.2023 2:34, Tamas K Lengyel пишет: > > > > > > On Mon, Mar 20, 2023 at 3:23 PM Ковалёв Сергей > > wrote: > > > > > > > > > > > > 21.03.2023 1:51, Tamas K Lengyel wrote: > > > > > > > > > > > > On Mon,

Re: [PATCH v3 2/3] x86/platform: introduce XENPF_get_ucode_version

On 21/03/2023 11:47 am, Sergey Dyasli wrote: > Currently it's impossible to get CPU's microcode revision after late > loading without looking into Xen logs which is not always convenient. It's not impossible (you can do `modprobe msr; rdmsr 0x8b`), but it is inconvenient for library code. > > Add

Re: [RFC XEN PATCH 2/6] vpci: accept BAR writes if dom0 is PVH

On Tue, Mar 21, 2023 at 08:27:21PM +0800, Jan Beulich wrote: > On 21.03.2023 12:49, Huang Rui wrote: > > Thanks, but we found if dom0 is PV domain, the passthrough device will > > access this function to write the real bar. > > Can you please be quite a bit more detailed about this? The specific c

Re: [RFC XEN PATCH 2/6] vpci: accept BAR writes if dom0 is PVH

On Tue, Mar 21, 2023 at 08:20:53PM +0800, Roger Pau Monné wrote: > On Tue, Mar 21, 2023 at 07:49:26PM +0800, Huang Rui wrote: > > On Tue, Mar 21, 2023 at 06:20:03PM +0800, Jan Beulich wrote: > > > On 21.03.2023 11:14, Huang Rui wrote: > > > > On Tue, Mar 21, 2023 at 05:41:57PM +0800, Jan Beulich wr

Re: [PATCH v3 1/3] tools/xenctrl: add xc_get_cpu_version()

On 21/03/2023 11:47 am, Sergey Dyasli wrote: > diff --git a/tools/libs/ctrl/xc_misc.c b/tools/libs/ctrl/xc_misc.c > index 265f15ec2d..f2f6e4348e 100644 > --- a/tools/libs/ctrl/xc_misc.c > +++ b/tools/libs/ctrl/xc_misc.c > @@ -226,6 +226,26 @@ int xc_microcode_update(xc_interface *xch, const void >

Re: [RFC XEN PATCH 4/6] x86/pvh: PVH dom0 also need PHYSDEVOP_setup_gsi call

On Thu, Mar 16, 2023 at 01:01:52AM +0800, Andrew Cooper wrote: > On 14/03/2023 4:30 pm, Jan Beulich wrote: > > On 12.03.2023 08:54, Huang Rui wrote: > >> From: Chen Jiqian > > An empty description won't do here. First of all you need to address the > > Why? > > As already hinted at in the reply t

Re: [RFC XEN PATCH 2/6] vpci: accept BAR writes if dom0 is PVH

On 21.03.2023 12:49, Huang Rui wrote: > Thanks, but we found if dom0 is PV domain, the passthrough device will > access this function to write the real bar. Can you please be quite a bit more detailed about this? The specific code paths taken (in upstream software) to result in such would of of in

Re: [RFC XEN PATCH 2/6] vpci: accept BAR writes if dom0 is PVH

On 21.03.2023 13:20, Roger Pau Monné wrote: > On Tue, Mar 21, 2023 at 07:49:26PM +0800, Huang Rui wrote: >> On Tue, Mar 21, 2023 at 06:20:03PM +0800, Jan Beulich wrote: >>> On 21.03.2023 11:14, Huang Rui wrote: On Tue, Mar 21, 2023 at 05:41:57PM +0800, Jan Beulich wrote: > On 21.03.2023 10

Re: [RFC XEN PATCH 4/6] x86/pvh: PVH dom0 also need PHYSDEVOP_setup_gsi call

On Wed, Mar 15, 2023 at 12:30:21AM +0800, Jan Beulich wrote: > On 12.03.2023 08:54, Huang Rui wrote: > > From: Chen Jiqian > > An empty description won't do here. First of all you need to address the Why? > As already hinted at in the reply to the earlier patch, it looks like you're > breaking th

Re: [RFC XEN PATCH 2/6] vpci: accept BAR writes if dom0 is PVH

On Tue, Mar 21, 2023 at 07:49:26PM +0800, Huang Rui wrote: > On Tue, Mar 21, 2023 at 06:20:03PM +0800, Jan Beulich wrote: > > On 21.03.2023 11:14, Huang Rui wrote: > > > On Tue, Mar 21, 2023 at 05:41:57PM +0800, Jan Beulich wrote: > > >> On 21.03.2023 10:36, Huang Rui wrote: > > >>> On Wed, Mar 15,

  1   2   >