[xen-4.12-testing test] 161522: regressions - FAIL

flight 161522 xen-4.12-testing real [real] flight 161543 xen-4.12-testing real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/161522/ http://logs.test-lab.xenproject.org/osstest/logs/161543/ Regressions :-( Tests which did not succeed and are blocking, including tests which could

[qemu-mainline test] 161514: regressions - FAIL

flight 161514 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/161514/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs. 152631

Re: Xen Virtual Keyboard modalias breaking uevents

Dmitry Torokhov writes: > Userspace may or may not have access to sysfs (it does not have to be > mounted) How would userspace even enumerate the input devices and read their modalias without sysfs?

Re: Xen Virtual Keyboard modalias breaking uevents

On Thu, Apr 29, 2021 at 08:11:03PM -0400, Phillip Susi wrote: > > Dmitry Torokhov writes: > > > Not every keyboard, but all keycodes above KEY_MIN_INTERESTING which is > > KEY_MUTE, so that interested handlers could match on devices they are > > interested in without first opening them or poking

[ovmf test] 161530: all pass - PUSHED

flight 161530 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/161530/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf ab957f036f6711869283217227480b109aedc8ef baseline version: ovmf

Re: Xen Virtual Keyboard modalias breaking uevents

Dmitry Torokhov writes: > Not every keyboard, but all keycodes above KEY_MIN_INTERESTING which is > KEY_MUTE, so that interested handlers could match on devices they are > interested in without first opening them or poking through sysfs. /Shouldn't/ they be reading sysfs attributes to find

[xen-unstable-smoke test] 161533: tolerable all pass - PUSHED

flight 161533 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/161533/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl

Re: Xen Virtual Keyboard modalias breaking uevents

On Thu, Apr 29, 2021 at 04:10:09PM -0400, Phillip Susi wrote: > > It appears that input/input.c is responsible for the insane modalias > length. If I am reading input_print_modalias() correctly, it appends a > "k" plus every key code that the keyboard supports, Not every keyboard, but all

[PATCH] x86: Always have CR4.PKE set in HVM context

The sole user of read_pkru() is the emulated pagewalk, and guarded behind guest_pku_enabled() which restricts the path to HVM (hap, even) context only. The commentary in read_pkru() concerning _PAGE_GNTTAB overlapping with _PAGE_PKEY_BITS is only applicable to PV guests. The context switch path,

Re: [RFC PATCH] iommu: make no-quarantine mean no-quarantine

On 4/28/21, 3:20 AM, Paul Durrant wrote: >> Following the extension to the command line option I'm putting in place >> in "IOMMU: make DMA containment of quarantined devices optional" (which >> I still need to get around to address review feedback for and resubmit), >> I'd be inclined to suggest

[xen-unstable test] 161512: tolerable FAIL

flight 161512 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/161512/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 161492 pass in 161512

Re: Xen Virtual Keyboard modalias breaking uevents

It appears that input/input.c is responsible for the insane modalias length. If I am reading input_print_modalias() correctly, it appends a "k" plus every key code that the keyboard supports, and the Xen Virtual Keyboard supports a lot of keycodes. Why does it do this? Phillip Susi writes: >

[xen-unstable-smoke test] 161525: regressions - FAIL

flight 161525 xen-unstable-smoke real [real] flight 161528 xen-unstable-smoke real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/161525/ http://logs.test-lab.xenproject.org/osstest/logs/161528/ Regressions :-( Tests which did not succeed and are blocking, including tests which

[ovmf test] 161518: all pass - PUSHED

flight 161518 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/161518/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 612edbe6cd71f4392b681b75849b2ab6e48f592d baseline version: ovmf

Re: [PATCH 1/5] tools/debugger: Fix PAGE_SIZE redefinition error

Hi, At 15:05 +0300 on 27 Apr (1619535916), Costin Lupu wrote: > If PAGE_SIZE is already defined in the system (e.g. in > /usr/include/limits.h header) then gcc will trigger a redefinition error > because of -Werror. This commit also protects PAGE_SHIFT definitions for > keeping consistency.

Xen Virtual Keyboard modalias breaking uevents

So I have finally drilled down to the modalias for the Xen Virtual Keyboard driver being so long ( over 2KB ) that it causes an -ENOMEM when trying to add it to the environment for uevents. This causes coldplug to fail, which causes the script doing coldplug as part of the debian-installer init

Re: [PATCH v2 06/12] x86/p2m: hardware-log-dirty related hooks are HVM-only

On Mon, Apr 12, 2021 at 04:08:50PM +0200, Jan Beulich wrote: > Exclude functions using them from !HVM builds, thus making it possible > to exclude the hooks as well. > > By moving an #endif in p2m.c (instead of introducing yet another one) > p2m_{get,set}_ioreq_server() get excluded for !HVM

Re: [PATCH v4 04/12] x86/vioapic: switch to use the EOI callback mechanism

On 20.04.2021 16:07, Roger Pau Monne wrote: > Switch the emulated IO-APIC code to use the local APIC EOI callback > mechanism. This allows to remove the last hardcoded callback from > vlapic_handle_EOI. Removing the hardcoded vIO-APIC callback also > allows to getting rid of setting the EOI exit

Re: [PATCH v2 05/12] x86/p2m: change_entry_type_* hooks are HVM-only

On Mon, Apr 12, 2021 at 04:08:29PM +0200, Jan Beulich wrote: > Exclude functions using them from !HVM builds, thus making it possible > to exclude the hooks as well. Also cover the already unused > memory_type_changed hook while inserting the #ifdef in the struct. > > While no respective check

Re: [PATCH v4 02/12] x86/vlapic: introduce an EOI callback mechanism

On 20.04.2021 16:07, Roger Pau Monne wrote: > Add a new vlapic_set_irq_callback helper in order to inject a vector > and set a callback to be executed when the guest performs the end of > interrupt acknowledgment. > > Such functionality will be used to migrate the current ad hoc handling > done

Re: [PATCH v2 04/12] AMD/IOMMU: guest IOMMU support is for HVM only

On Mon, Apr 12, 2021 at 04:07:50PM +0200, Jan Beulich wrote: > Generally all of this is dead code anyway, but there's a caller of > guest_iommu_add_ppr_log(), and the code itself calls > p2m_change_type_one(), which is about to become HVM-only. Hence this > code, short of deleting it altogether,

Re: [PATCH v2 01/12] x86/p2m: set_{foreign,mmio}_p2m_entry() are HVM-only

On Thu, Apr 29, 2021 at 04:09:30PM +0200, Jan Beulich wrote: > On 29.04.2021 15:17, Roger Pau Monné wrote: > > On Mon, Apr 12, 2021 at 04:05:41PM +0200, Jan Beulich wrote: > >> Extend a respective #ifdef from inside set_typed_p2m_entry() to around > >> all three functions. Add ASSERT_UNREACHABLE()

Re: [PATCH v2 02/12] x86/p2m: {,un}map_mmio_regions() are HVM-only

On 29.04.2021 16:48, Roger Pau Monné wrote: > On Mon, Apr 12, 2021 at 04:06:34PM +0200, Jan Beulich wrote: >> Mirror the "translated" check the functions do to do_domctl(), allowing >> the calls to be DCEd by the compiler. Add ASSERT_UNREACHABLE() to the >> original checks. >> >> Also arrange for

Re: [PATCH v4 01/12] x86/rtc: drop code related to strict mode

On 20.04.2021 16:07, Roger Pau Monne wrote: > --- a/xen/arch/x86/hvm/rtc.c > +++ b/xen/arch/x86/hvm/rtc.c > @@ -46,15 +46,6 @@ > #define epoch_year 1900 > #define get_year(x)(x + epoch_year) > > -enum rtc_mode { > - rtc_mode_no_ack, > - rtc_mode_strict > -}; > - > -/* This must be

[libvirt test] 161516: regressions - FAIL

flight 161516 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/161516/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-amd64-libvirt

Re: [PATCH v2 02/12] x86/p2m: {,un}map_mmio_regions() are HVM-only

On Mon, Apr 12, 2021 at 04:06:34PM +0200, Jan Beulich wrote: > Mirror the "translated" check the functions do to do_domctl(), allowing > the calls to be DCEd by the compiler. Add ASSERT_UNREACHABLE() to the > original checks. > > Also arrange for {set,clear}_mmio_p2m_entry() and >

[PATCH v4 3/3] xen/pci: Refactor MSI code that implements MSI functionality within XEN

MSI code that implements MSI functionality to support MSI within XEN is not usable on ARM. Move the code under CONFIG_HAS_PCI_MSI_INTERCEPT flag to gate the code for ARM. Currently, we have no idea how MSI functionality will be supported for other architecture therefore we have decided to move

[PATCH v4 2/3] xen/pci: Refactor PCI MSI intercept related code

MSI intercept related code is not useful for ARM when MSI interrupts are injected via GICv3 ITS. Therefore introducing the new flag CONFIG_HAS_PCI_MSI_INTERCEPT to gate the MSI code for ARM in common code and also implemented the stub version for the unused code for ARM to avoid compilation error

[PATCH v4 1/3] xen/iommu: Move iommu_update_ire_from_msi(..) to xen/iommu.h

Move iommu_update_ire_from_msi(..) from passthrough/pci.c to xen/iommu.h and wrap it under CONFIG_X86 as it is referenced in x86 code only to avoid compilation error for other architecture when HAS_PCI is enabled. No functional change intended. Signed-off-by: Rahul Singh Acked-by: Jan Beulich

[PATCH v4 0/3] xen/pci: Make PCI passthrough code non-x86 specific

This patch series is preparatory work to implement the PCI passthrough support for the ARM architecture. Rahul Singh (3): xen/iommu: Move iommu_update_ire_from_msi(..) to xen/iommu.h xen/pci: Refactor PCI MSI intercept related code xen/pci: Refactor MSI code that implements MSI

[linux-linus test] 161509: regressions - FAIL

flight 161509 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/161509/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332

Re: [PATCH v2 01/12] x86/p2m: set_{foreign,mmio}_p2m_entry() are HVM-only

On 29.04.2021 15:17, Roger Pau Monné wrote: > On Mon, Apr 12, 2021 at 04:05:41PM +0200, Jan Beulich wrote: >> Extend a respective #ifdef from inside set_typed_p2m_entry() to around >> all three functions. Add ASSERT_UNREACHABLE() to the latter one's safety >> check path. > > Wouldn't it be better

Re: [PATCH] x86/ACPI: Fix build error when tboot is disabled

On 29/04/2021 14:42, Jan Beulich wrote: > On 29.04.2021 15:22, Costin Lupu wrote: >> On 4/29/21 3:40 PM, Jan Beulich wrote: >>> If there is a specific case where the compiler fails to DCE the >>> offending code, then you need to describe this in sufficient >>> detail. >> Yes, indeed. My bad, it is

Re: [PATCH v4 3/3] x86/time: avoid reading the platform timer in rendezvous functions

On 29.04.2021 14:53, Roger Pau Monné wrote: > On Thu, Apr 01, 2021 at 11:55:10AM +0200, Jan Beulich wrote: >> Reading the platform timer isn't cheap, so we'd better avoid it when the >> resulting value is of no interest to anyone. >> >> The consumer of master_stime, obtained by >>

Re: [PATCH] x86/ACPI: Fix build error when tboot is disabled

On 29.04.2021 15:22, Costin Lupu wrote: > On 4/29/21 3:40 PM, Jan Beulich wrote: >> If there is a specific case where the compiler fails to DCE the >> offending code, then you need to describe this in sufficient >> detail. > > Yes, indeed. My bad, it is for a debug build with -O0, so without DCE.

Re: [PATCH v3] gnttab: defer allocation of status frame tracking array

On 29.04.2021 15:15, Julien Grall wrote: > On 15/04/2021 10:41, Jan Beulich wrote: >> This array can be large when many grant frames are permitted; avoid >> allocating it when it's not going to be used anyway, by doing this only >> in gnttab_populate_status_frames(). > > Given the controversy of

Re: [PATCH v4 3/3] unzstd: make helper symbols static

On 29.04.2021 13:27, Julien Grall wrote: > On 21/04/2021 11:22, Jan Beulich wrote: >> While for the original library's purposes these functions of course want >> to be externally exposed, we don't need this, and we also don't want >> this both to prevent unintended use and to keep the name space

Re: [PATCH] x86/ACPI: Fix build error when tboot is disabled

On 4/29/21 3:40 PM, Jan Beulich wrote: > On 29.04.2021 14:11, Costin Lupu wrote: >> When tboot is disabled via menuconfig we get undefined reference error for >> g_tboot_shared. This patch fixes that by disabling the causing source code >> when tboot is disabled. > > There must be more to this:

Re: [PATCH v3 3/3] docs/doxygen: doxygen documentation for grant_table.h

On 29.04.2021 15:15, Luca Fancellu wrote: > That’s great, I’m going to push the v4 for this serie soon, now that the > comment is fixed, > I can include it in the docs too, do you agree? Of course (provided the patch will not get objected to). Jan

Re: [PATCH v2 01/12] x86/p2m: set_{foreign,mmio}_p2m_entry() are HVM-only

On Mon, Apr 12, 2021 at 04:05:41PM +0200, Jan Beulich wrote: > Extend a respective #ifdef from inside set_typed_p2m_entry() to around > all three functions. Add ASSERT_UNREACHABLE() to the latter one's safety > check path. Wouldn't it be better to also move the prototypes in p2m.h into a

Re: [PATCH v3 3/3] docs/doxygen: doxygen documentation for grant_table.h

> On 29 Apr 2021, at 14:11, Jan Beulich wrote: > > On 29.04.2021 11:50, Luca Fancellu wrote: >>> On 29 Apr 2021, at 10:04, Jan Beulich wrote: >>> On 28.04.2021 16:59, Luca Fancellu wrote: > On 27 Apr 2021, at 14:57, Jan Beulich wrote: > On 26.04.2021 17:37, Luca Fancellu wrote:

Re: [PATCH v3] gnttab: defer allocation of status frame tracking array

Hi Jan, On 15/04/2021 10:41, Jan Beulich wrote: This array can be large when many grant frames are permitted; avoid allocating it when it's not going to be used anyway, by doing this only in gnttab_populate_status_frames(). Given the controversy of the change, I would suggest to summarize why

Re: [PATCH v3 3/3] docs/doxygen: doxygen documentation for grant_table.h

On 29.04.2021 11:50, Luca Fancellu wrote: >> On 29 Apr 2021, at 10:04, Jan Beulich wrote: >> On 28.04.2021 16:59, Luca Fancellu wrote: On 27 Apr 2021, at 14:57, Jan Beulich wrote: On 26.04.2021 17:37, Luca Fancellu wrote: > @@ -120,24 +132,26 @@ typedef uint32_t grant_ref_t; >

[PATCH] public/gnttab: relax v2 recommendation

With there being a way to disable v2 support, telling new guests to use v2 exclusively is not a good suggestion. Signed-off-by: Jan Beulich --- a/xen/include/public/grant_table.h +++ b/xen/include/public/grant_table.h @@ -121,8 +121,10 @@ typedef uint32_t grant_ref_t; */ /* - * Version 1

Re: Serial Console : SOL vs Physical Port

Thanks @Jan Beulich On Thu, Apr 29, 2021 at 10:35 AM Jan Beulich wrote: > On 28.04.2021 20:49, Charles Gonçalves wrote: > > Is there any difference between both? > > I'm trying to debug an issue using a SOL but the host crashes before any > > meaningful message. > > > > The SOL is working

Re: Ping: [PATCH v3] gnttab: defer allocation of status frame tracking array

Hi Jan, On 29/04/2021 10:31, Jan Beulich wrote: On 15.04.2021 11:41, Jan Beulich wrote: This array can be large when many grant frames are permitted; avoid allocating it when it's not going to be used anyway, by doing this only in gnttab_populate_status_frames(). Signed-off-by: Jan Beulich

Re: [PATCH v4 3/3] x86/time: avoid reading the platform timer in rendezvous functions

On Thu, Apr 01, 2021 at 11:55:10AM +0200, Jan Beulich wrote: > Reading the platform timer isn't cheap, so we'd better avoid it when the > resulting value is of no interest to anyone. > > The consumer of master_stime, obtained by > time_calibration_{std,tsc}_rendezvous() and propagated through >

Re: [PATCH v4 3/3] x86/time: avoid reading the platform timer in rendezvous functions

On Wed, Apr 21, 2021 at 12:06:34PM +0200, Jan Beulich wrote: > On 20.04.2021 18:12, Roger Pau Monné wrote: > > On Thu, Apr 01, 2021 at 11:55:10AM +0200, Jan Beulich wrote: > >> Reading the platform timer isn't cheap, so we'd better avoid it when the > >> resulting value is of no interest to

Re: [PATCH] x86/ACPI: Fix build error when tboot is disabled

On 29.04.2021 14:11, Costin Lupu wrote: > When tboot is disabled via menuconfig we get undefined reference error for > g_tboot_shared. This patch fixes that by disabling the causing source code > when tboot is disabled. There must be more to this: Our shim config also builds with tboot disabled,

[PATCH] x86/ACPI: Fix build error when tboot is disabled

When tboot is disabled via menuconfig we get undefined reference error for g_tboot_shared. This patch fixes that by disabling the causing source code when tboot is disabled. Signed-off-by: Costin Lupu --- xen/arch/x86/acpi/power.c | 4 1 file changed, 4 insertions(+) diff --git

[PATCH v4] hotplug/Linux: fix starting of xenstored with restarting systemd

A hard to trigger race with another unrelated systemd service and xenstored.service unveiled a bug in the way how xenstored is launched with systemd. launch-xenstore may start either a daemon or a domain. In case a domain is used, systemd-notify was called. If another service triggered a restart

Re: [PATCH v3 3/3] xen/pci: Refactor MSI code that implements MSI functionality within XEN

Hi Roger, > On 28 Apr 2021, at 12:06 pm, Roger Pau Monné wrote: > > On Mon, Apr 26, 2021 at 05:21:27PM +0100, Rahul Singh wrote: >> MSI code that implements MSI functionality to support MSI within XEN is >> not usable on ARM. Move the code under CONFIG_PCI_MSI_INTERCEPT flag to >> gate the code

Re: [PATCH v3] evtchn/fifo: don't enforce higher than necessary alignment

Hi Jan, On 22/04/2021 10:19, Jan Beulich wrote: On 21.04.2021 21:52, Julien Grall wrote: Hi, On 21/04/2021 15:36, Jan Beulich wrote: Neither the code nor the original commit provide any justification for the need to 8-byte align the struct in all cases. Enforce just as much alignment as the

Re: [PATCH v3 2/3] xen/pci: Refactor PCI MSI intercept related code

On 29.04.2021 13:31, Rahul Singh wrote: >> On 28 Apr 2021, at 3:06 pm, Jan Beulich wrote: >> On 26.04.2021 18:21, Rahul Singh wrote: >>> --- a/xen/xsm/flask/hooks.c >>> +++ b/xen/xsm/flask/hooks.c >>> @@ -21,7 +21,7 @@ >>> #include >>> #include >>> #include >>> -#ifdef CONFIG_HAS_PCI >>>

[xen-4.12-testing test] 161508: regressions - FAIL

flight 161508 xen-4.12-testing real [real] flight 161521 xen-4.12-testing real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/161508/ http://logs.test-lab.xenproject.org/osstest/logs/161521/ Regressions :-( Tests which did not succeed and are blocking, including tests which could

Re: [PATCH 2/5] tools/libfsimage: Fix PATH_MAX redefinition error

Hi Costin, On 28/04/2021 19:35, Costin Lupu wrote: On 4/28/21 12:04 PM, Julien Grall wrote: On 27/04/2021 13:05, Costin Lupu wrote: If PATH_MAX is already defined in the system (e.g. in /usr/include/limits.h header) then gcc will trigger a redefinition error because of -Werror.

Re: [PATCH v3 2/3] xen/pci: Refactor PCI MSI intercept related code

Hi Jan, > On 28 Apr 2021, at 3:06 pm, Jan Beulich wrote: > > On 26.04.2021 18:21, Rahul Singh wrote: >> --- a/xen/xsm/flask/hooks.c >> +++ b/xen/xsm/flask/hooks.c >> @@ -21,7 +21,7 @@ >> #include >> #include >> #include >> -#ifdef CONFIG_HAS_PCI >> +#ifdef CONFIG_PCI_MSI_INTERCEPT >>

Re: [PATCH 3/5] tools/libs/foreignmemory: Fix PAGE_SIZE redefinition error

On 28/04/2021 19:27, Costin Lupu wrote: Hi Julien, Hi Costin, On 4/28/21 12:03 PM, Julien Grall wrote: Hi Costin, On 27/04/2021 13:05, Costin Lupu wrote:   tools/libs/foreignmemory/private.h | 6 --   1 file changed, 4 insertions(+), 2 deletions(-) diff --git

Re: [PATCH v4 3/3] unzstd: make helper symbols static

Hi Jan, On 21/04/2021 11:22, Jan Beulich wrote: While for the original library's purposes these functions of course want to be externally exposed, we don't need this, and we also don't want this both to prevent unintended use and to keep the name space tidy. (When functions have no callers at

[PATCH v5 02/10] numa: Teach ram block notifiers about resizeable ram blocks

Ram block notifiers are currently not aware of resizes. To properly handle resizes during migration, we want to teach ram block notifiers about resizeable ram. Introduce the basic infrastructure but keep using max_size in the existing notifiers. Supply the max_size when adding and removing ram

Re: [PATCH v4 1/3] unzstd: replace INIT and STATIC

Hi Jan, On 21/04/2021 11:21, Jan Beulich wrote: With xen/common/decompress.h now agreeing in both build modes about what STATIC expands to, there's no need for these abstractions anymore. Requested-by: Andrew Cooper Signed-off-by: Jan Beulich Reviewed-by: Julien Grall Cheers, --- v4:

Re: [PATCH v2 10/10] arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t

On 29/04/2021 11:31, Tamas K Lengyel wrote: On Thu, Apr 29, 2021, 4:53 AM Michal Orzel > wrote: Hi Julien, On 27.04.2021 13:09, Julien Grall wrote: > Hi Michal, > > On 27/04/2021 10:35, Michal Orzel wrote: >> AArch64 registers are

Re: [PATCH v2 10/10] arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t

On Thu, Apr 29, 2021, 4:53 AM Michal Orzel wrote: > Hi Julien, > > On 27.04.2021 13:09, Julien Grall wrote: > > Hi Michal, > > > > On 27/04/2021 10:35, Michal Orzel wrote: > >> AArch64 registers are 64bit whereas AArch32 registers > >> are 32bit or 64bit. MSR/MRS are expecting 64bit values thus

Re: [PATCH v3 3/3] docs/doxygen: doxygen documentation for grant_table.h

> On 29 Apr 2021, at 10:04, Jan Beulich wrote: > > On 28.04.2021 16:59, Luca Fancellu wrote: >>> On 27 Apr 2021, at 14:57, Jan Beulich wrote: >>> On 26.04.2021 17:37, Luca Fancellu wrote: @@ -66,6 +67,7 @@ * compiler barrier will still be required. * * Introducing a

Re: [PATCH v3 19/22] x86emul: support TILELOADD{,T1} and TILESTORE

On 26.04.2021 09:12, Paul Durrant wrote: > On 22/04/2021 16:11, Jan Beulich wrote: >> On 22.04.2021 17:06, Jan Beulich wrote: >>> On 22.04.2021 16:55, Jan Beulich wrote: +do { +/* Limit rows to just as many to cover the next one to access. */ +

Re: Serial Console : SOL vs Physical Port

On 28.04.2021 20:49, Charles Gonçalves wrote: > Is there any difference between both? > I'm trying to debug an issue using a SOL but the host crashes before any > meaningful message. > > The SOL is working properly when I can debug some crashes perfectly. But > for a specific case I'm wondering

Re: [PATCH v4 3/3] x86/time: avoid reading the platform timer in rendezvous functions

On 21.04.2021 12:06, Jan Beulich wrote: > On 20.04.2021 18:12, Roger Pau Monné wrote: >> On Thu, Apr 01, 2021 at 11:55:10AM +0200, Jan Beulich wrote: >>> Reading the platform timer isn't cheap, so we'd better avoid it when the >>> resulting value is of no interest to anyone. >>> >>> The consumer

Ping: [PATCH v3] gnttab: defer allocation of status frame tracking array

On 15.04.2021 11:41, Jan Beulich wrote: > This array can be large when many grant frames are permitted; avoid > allocating it when it's not going to be used anyway, by doing this only > in gnttab_populate_status_frames(). > > Signed-off-by: Jan Beulich I know there has been controversy here.

Ping: [PATCH v2 00/12] x86/p2m: restrict more code to build just for HVM

On 12.04.2021 16:03, Jan Beulich wrote: > Since it was brought up in the discussion of v1: I think the end > goal is to be for mm/p2m.c to become a HVM-only file. Any "wrappers" > also trying to take care of !paging_mode_translate() guests ought to > be moved elsewhere. To see what actually still

Ping: [PATCH] x86emul: fix test harness build for gas 2.36

On 19.04.2021 17:51, Jan Beulich wrote: > On 19.04.2021 17:41, Andrew Cooper wrote: >> On 19/04/2021 16:30, Jan Beulich wrote: >>> All of the sudden, besides .text and .rodata and alike, an always >>> present .note.gnu.property section has appeared. This section, when >>> converting to binary

Re: [PATCH] x86/AMD: also determine L3 cache size

On 16.04.2021 16:21, Andrew Cooper wrote: > On 16/04/2021 14:20, Jan Beulich wrote: >> For Intel CPUs we record L3 cache size, hence we should also do so for >> AMD and alike. >> >> While making these additions, also make sure (throughout the function) >> that we don't needlessly overwrite prior

Ping: [PATCH v4 0/3] zstd decompression fallout / consolidation

On 21.04.2021 12:20, Jan Beulich wrote: > 1: unzstd: replace INIT{,DATA} and STATIC > 2: xen/decompress: drop STATIC and INIT > 3: unzstd: make helper symbols static Anyone? Thanks, Jan

Ping: [PATCH] build: centralize / unify asm-offsets generation

On 27.04.2021 16:13, Roger Pau Monné wrote: > Acked-by: Roger Pau Monné Thanks Roger. Julien, Stefano, may I ask for an Arm side ack (or otherwise) here as well? Thanks, Jan

Re: [PATCH 1/3] x86/hvm: Introduce experimental guest CET support

On 28.04.2021 19:54, Andrew Cooper wrote: > I know we're making up our "how to do complicated experimental features" > process as we go here, but nothing *in Xen* will malfunction if a user > opts into CET_SS/IBT.  Therefore I think they're fine to go in and stay. Well, okay then. I hope possibls

Re: [PATCH v3 3/3] docs/doxygen: doxygen documentation for grant_table.h

On 28.04.2021 16:59, Luca Fancellu wrote: >> On 27 Apr 2021, at 14:57, Jan Beulich wrote: >> On 26.04.2021 17:37, Luca Fancellu wrote: >>> @@ -66,6 +67,7 @@ >>> * compiler barrier will still be required. >>> * >>> * Introducing a valid entry into the grant table: >>> + * @code >>> * 1.

Re: [PATCH v2 10/10] arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t

Hi Julien, On 27.04.2021 13:09, Julien Grall wrote: > Hi Michal, > > On 27/04/2021 10:35, Michal Orzel wrote: >> AArch64 registers are 64bit whereas AArch32 registers >> are 32bit or 64bit. MSR/MRS are expecting 64bit values thus >> we should get rid of helpers READ/WRITE_SYSREG32 >> in favour

Re: [PATCH v3 2/3] xen/pci: Refactor PCI MSI intercept related code

Hi Jan, > On 28 Apr 2021, at 2:57 pm, Jan Beulich wrote: > > On 28.04.2021 12:42, Roger Pau Monné wrote: >> On Mon, Apr 26, 2021 at 05:21:26PM +0100, Rahul Singh wrote: >>> --- a/xen/arch/x86/Kconfig >>> +++ b/xen/arch/x86/Kconfig >>> @@ -20,6 +20,7 @@ config X86 >>> select HAS_NS16550 >>>

Re: [PATCH v3 2/3] xen/pci: Refactor PCI MSI intercept related code

Hi Roger, > On 28 Apr 2021, at 11:42 am, Roger Pau Monné wrote: > > On Mon, Apr 26, 2021 at 05:21:26PM +0100, Rahul Singh wrote: >> MSI intercept related code is not useful for ARM when MSI interrupts are >> injected via GICv3 ITS. >> >> Therefore introducing the new flag

Re: [PATCH v2 07/10] arm/mm: Get rid of READ/WRITE_SYSREG32

Hi Julien, On 27.04.2021 11:59, Julien Grall wrote: > > > On 27/04/2021 10:35, Michal Orzel wrote: >> AArch64 registers are 64bit whereas AArch32 registers >> are 32bit or 64bit. MSR/MRS are expecting 64bit values thus >> we should get rid of helpers READ/WRITE_SYSREG32 >> in favour of using

Re: [PATCH v2 05/10] arm/gic: Get rid of READ/WRITE_SYSREG32

Hi Julien, On 27.04.2021 12:02, Julien Grall wrote: > > > On 27/04/2021 10:35, Michal Orzel wrote: >> AArch64 registers are 64bit whereas AArch32 registers >> are 32bit or 64bit. MSR/MRS are expecting 64bit values thus >> we should get rid of helpers READ/WRITE_SYSREG32 >> in favour of using

Re: [PATCH v2 03/10] arm: Modify type of actlr to register_t

Hi Julien, On 27.04.2021 11:47, Julien Grall wrote: > Hi Michal, > > On 27/04/2021 10:35, Michal Orzel wrote: >> AArch64 registers are 64bit whereas AArch32 registers >> are 32bit or 64bit. MSR/MRS are expecting 64bit values thus >> we should get rid of helpers READ/WRITE_SYSREG32 >> in favour

Re: [PATCH v2 02/10] arm/domain: Get rid of READ/WRITE_SYSREG32

Hi Julien, On 27.04.2021 11:45, Julien Grall wrote: > Hi Michal, > > On 27/04/2021 10:35, Michal Orzel wrote: >> AArch64 registers are 64bit whereas AArch32 registers >> are 32bit or 64bit. MSR/MRS are expecting 64bit values thus >> we should get rid of helpers READ/WRITE_SYSREG32 >> in favour

[ovmf test] 161504: all pass - PUSHED

flight 161504 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/161504/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 01c0ab90beb3d2a80f913d4a0866b4e92656a42a baseline version: ovmf