[ovmf test] 161114: all pass - PUSHED

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

Re: [PATCH v3] tools: create libxensaverestore

On 13.04.21 19:20, Olaf Hering wrote: Move all save/restore related code from libxenguest.so into a separate library libxensaverestore.so. The only consumer is libxl-save-helper. There is no need to have the moved code mapped all the time in binaries where libxenguest.so is used. According to

[qemu-mainline test] 161088: regressions - FAIL

flight 161088 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/161088/ 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

[PATCH v4 2/2] x86/intel: insert Ice Lake-SP and Ice Lake-D model numbers

LBR, C-state MSRs should correspond to Ice Lake desktop according to SDM rev. 74 for both models. Ice Lake-SP is known to expose IF_PSCHANGE_MC_NO in IA32_ARCH_CAPABILITIES MSR (as advisory tells and Whitley SDP confirms) which means the erratum is fixed in hardware for that model and therefore

[PATCH v4 1/2] x86/vtx: add LBR_SELECT to the list of LBR MSRs

This MSR exists since Nehalem and is actively used by Linux, for instance, to improve sampling efficiency. Signed-off-by: Igor Druzhinin --- New patch in v4 as suggested by Andrew. --- xen/arch/x86/hvm/vmx/vmx.c | 7 +-- xen/include/asm-x86/msr-index.h | 6 +- 2 files changed, 10

Re: [PATCH v3 3/4] xen/arm: Reserve domid 0 for Dom0

> On 13 Apr 2021, at 18:00, Julien Grall wrote: > > Hi Luca, > > The title probably wants to be updated as you don't really reserve domid 0. > How about: > > xen/arm: Clarify how the domid is decided in create_domUs() Sure I’ll update in the v4 patch I will send soon Cheers, Luca > >

Re: [PATCH v3 1/4] xen/arm: Move dom0 creation in domain_build.c

> On 13 Apr 2021, at 17:40, Julien Grall wrote: > > Hi Luca, > > On 12/04/2021 11:52, Luca Fancellu wrote: >> Move dom0 creation and start from setup.c to domain_build.c >> on a dedicate function. > > s/dedicate/dedicated/ > > I would also suggest to add "No functional changes intended" to

[xen-unstable test] 161071: regressions - FAIL

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

[xtf test] 161113: all pass - PUSHED

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

[xtf test] 161108: all pass - PUSHED

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

[qemu-mainline bisection] complete test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow

branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow testid guest-saverestore Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree:

[ovmf test] 161099: all pass - PUSHED

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

Re: Support of old Xen versions in the Linux kernel

On Tue, 13 Apr 2021, Boris Ostrovsky wrote: > On 4/13/21 2:14 AM, Juergen Gross wrote: > > In x86 kernel development the question came up whether we need to > > support XENFEAT_gnttab_map_avail_bits not being set when running as a PV > > guest. > > > > This feature is active for PV guests since

Re: [PATCH v3 2/2] xen/arm64: Place a speculation barrier following an ret instruction

On Thu, 1 Apr 2021, Julien Grall wrote: > From: Julien Grall > > Some CPUs can speculate past a RET instruction and potentially perform > speculative accesses to memory before processing the return. > > There is no known gadget available after the RET instruction today. > However some of the

Re: [PATCH] xen/arm: Ensure the vCPU context is seen before clearing the _VPF_down

On Sat, 20 Mar 2021, Julien Grall wrote: > On 20/03/2021 00:01, Stefano Stabellini wrote: > > On Sat, 27 Feb 2021, Julien Grall wrote: > > > (+ Dario and George) > > > > > > Hi Stefano, > > > > > > I have added Dario and George to get some inputs from the scheduling part. > > > > > > On

Re: [PATCH] xen-netback: Check for hotplug-status existence before watching

Hello: This patch was applied to netdev/net.git (refs/heads/master): On Tue, 13 Apr 2021 16:25:12 +0100 you wrote: > The logic in connect() is currently written with the assumption that > xenbus_watch_pathfmt() will return an error for a node that does not > exist. This assumption is incorrect:

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

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

Re: [PATCH] xen-netback: Check for hotplug-status existence before watching

On 13/04/2021 16:25, Michael Brown wrote: The logic in connect() is currently written with the assumption that xenbus_watch_pathfmt() will return an error for a node that does not exist. This assumption is incorrect: xenstore does allow a watch to be registered for a nonexistent node (and will

[linux-linus test] 161064: regressions - FAIL

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

Re: [PATCH 11/11] Arm/optee: don't open-code xzalloc_flex_struct()

Hi Jan, On 08/04/2021 13:23, Jan Beulich wrote: There is a difference in generated code: xzalloc_bytes() forces SMP_CACHE_BYTES alignment. I think we not only don't need this here, but actually don't want it. So I think moving to xmalloc_flex_struct() is a pretty good move. But I am actually

[PATCH RESEND v3 2/3] arm,smmu: restructure code in preparation to new bindings support

From: Brian Woods Restructure some of the code and add supporting functions for adding generic device tree (DT) binding support. This will allow for using current Linux device trees with just modifying the chosen field to enable Xen. Signed-off-by: Brian Woods Signed-off-by: Stefano

[PATCH RESEND v3 1/3] arm,smmu: switch to using iommu_fwspec functions

From: Brian Woods Modify the smmu driver so that it uses the iommu_fwspec helper functions. This means both ARM IOMMU drivers will both use the iommu_fwspec helper functions, making enabling generic device tree bindings in the SMMU driver much cleaner. Signed-off-by: Brian Woods

[PATCH RESEND v3 3/3] arm,smmu: add support for generic DT bindings. Implement add_device and dt_xlate.

From: Brian Woods Now that all arm iommu drivers support generic bindings we can remove the workaround from iommu_add_dt_device(). Note that if both legacy bindings and generic bindings are present in device tree, the legacy bindings are the ones that are used. Signed-off-by: Brian Woods

[PATCH RESEND v3 0/3] Generic SMMU Bindings

Hi all, This series introduces support for the generic SMMU bindings to xen/drivers/passthrough/arm/smmu.c. This is the same as the previous v3 version forward ported on top of staging, plus Rahul's "xen/arm: smmuv1: Revert associating the group pointer with the S2CR" patch

Re: [PATCH v2] xen/iommu: smmu: Silence clang in arm_smmu_device_dt_probe()

Hi Stefano, On 06/04/2021 23:02, Stefano Stabellini wrote: On Fri, 2 Apr 2021, Julien Grall wrote: From: Julien Grall Clang 11 will throw the following error: smmu.c:2284:18: error: cast to smaller integer type 'enum arm_smmu_arch_version' from 'const void *'

Re: [PATCH] xen: Remove support for PV ACPI cpu/memory hotplug

On Tue, Apr 13, 2021 at 7:53 PM Boris Ostrovsky wrote: > > Commit 76fc253723ad ("xen/acpi-stub: Disable it b/c the acpi_processor_add > is no longer called.") declared as BROKEN support for Xen ACPI stub (which > is required for xen-acpi-{cpu|memory}-hotplug) and suggested that this > is

[PATCH] xen: Remove support for PV ACPI cpu/memory hotplug

Commit 76fc253723ad ("xen/acpi-stub: Disable it b/c the acpi_processor_add is no longer called.") declared as BROKEN support for Xen ACPI stub (which is required for xen-acpi-{cpu|memory}-hotplug) and suggested that this is temporary and will be soon fixed. This was in March 2013. Further, commit

Re: Support of old Xen versions in the Linux kernel

On 4/13/21 2:14 AM, Juergen Gross wrote: > In x86 kernel development the question came up whether we need to > support XENFEAT_gnttab_map_avail_bits not being set when running as a PV > guest. > > This feature is active for PV guests since Xen 3.4. > > So the basic question is: which is the

[ovmf test] 161081: all pass - PUSHED

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

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

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

[PATCH] x86/vPMU: Extend vPMU support to version 5

Version 5 is backwards compatible with version 3. This allows to enable vPMU on Ice Lake CPUs. Signed-off-by: Igor Druzhinin --- xen/arch/x86/cpu/vpmu_intel.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c

[PATCH v3] tools: create libxensaverestore

Move all save/restore related code from libxenguest.so into a separate library libxensaverestore.so. The only consumer is libxl-save-helper. There is no need to have the moved code mapped all the time in binaries where libxenguest.so is used. According to size(1) the change is: textdata

Re: [PATCH v2] xen/pci: Refactor PCI MSI interrupts related code

Hi Roger, On 12/04/2021 11:49, Roger Pau Monné wrote: On Fri, Apr 09, 2021 at 05:00:41PM +0100, Rahul Singh wrote: MSI related code in the "passthrough/pci.c” file is not useful for ARM when MSI interrupts are injected via GICv3 ITS. Therefore introducing the new flag CONFIG_PCI_MSI_INTERCEPT

Re: [PATCH v3 4/4] xen/arm: Prevent Dom0 to be loaded when using dom0less

On 12/04/2021 11:52, Luca Fancellu wrote: This patch prevents the dom0 to be loaded skipping its building and going forward to build domUs when the dom0 kernel is not found and at least one domU is present. Signed-off-by: Luca Fancellu --- v3 changes: - Rephrase documentation ---

Re: [PATCH v3 3/4] xen/arm: Reserve domid 0 for Dom0

Hi Luca, The title probably wants to be updated as you don't really reserve domid 0. How about: xen/arm: Clarify how the domid is decided in create_domUs() On 12/04/2021 11:52, Luca Fancellu wrote: This patch adds a comment in create_domUs() right before domain_create() to explain the

Re: [PATCH v3 1/4] xen/arm: Move dom0 creation in domain_build.c

Hi Luca, On 12/04/2021 11:52, Luca Fancellu wrote: Move dom0 creation and start from setup.c to domain_build.c on a dedicate function. s/dedicate/dedicated/ I would also suggest to add "No functional changes intended" to make clear this is only code movement. Signed-off-by: Luca

Re: [xen-unstable bisection] complete test-armhf-armhf-xl-multivcpu

Hi Jan, On 12/04/2021 09:53, Jan Beulich wrote: On 11.04.2021 04:12, osstest service owner wrote: branch xen-unstable xenbranch xen-unstable job test-armhf-armhf-xl-multivcpu testid guest-start/debian.repeat Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware

Re: [PATCH] libxl: User defined max_maptrack_frames in a stub domain

On Tue, Apr 13, 2021 at 10:23 AM Andrew Cooper wrote: > > On 10/04/2021 16:55, Jason Andryuk wrote: > > On Tue, Sep 22, 2020 at 9:31 AM Wei Liu wrote: > >> On Mon, Sep 14, 2020 at 04:27:45PM +0100, Andrew Cooper wrote: > >>> On 14/09/2020 15:50, Dmitry Fedorov wrote: > Hi, > >

Re: A KernelShark plugin for Xen traces analysis

Hi Giuseppe, On Tue, 13 Apr 2021 16:28:36 +0200 Giuseppe Eletto wrote: > Hello, > I want to share with you a new plugin developed by me, under the > supervision of Dario Faggioli, which allows the new version of KernelShark > (the v2-beta) to open and view the Xen traces created using the

[PATCH] xen-netback: Check for hotplug-status existence before watching

The logic in connect() is currently written with the assumption that xenbus_watch_pathfmt() will return an error for a node that does not exist. This assumption is incorrect: xenstore does allow a watch to be registered for a nonexistent node (and will send notifications should the node be

Re: A KernelShark plugin for Xen traces analysis ​

On 13/04/2021 15:28, Giuseppe Eletto wrote: > Hello, > I want to share with you a new plugin developed by me, under the > supervision of Dario Faggioli, which allows the new version of KernelShark > (the v2-beta) to open and view the Xen traces created using the "xentrace" > tool. > > In fact,

Re: xen-netback hotplug-status regression bug

On 13/04/2021 11:55, Paul Durrant wrote: Ok, so it sound like this was probably my misunderstanding of xenstore semantics in the first place (although I'm sure I remember watch registration failing for non-existent nodes at some point in the past... that may have been with a non-upstream

Re: [PATCH v2 3/6] tools/libs/ctrl: use common p2m mapping code in xc_domain_resume_any()

On 13.04.21 17:00, Christian Lindig wrote: On 12 Apr 2021, at 16:22, Juergen Gross > wrote: Instead of open coding the mapping of the p2m list use the already existing xc_core_arch_map_p2m() call, especially as the current code does not support guests with the linear

Re: [PATCH v2 3/6] tools/libs/ctrl: use common p2m mapping code in xc_domain_resume_any()

On 12 Apr 2021, at 16:22, Juergen Gross mailto:jgr...@suse.com>> wrote: Instead of open coding the mapping of the p2m list use the already existing xc_core_arch_map_p2m() call, especially as the current code does not support guests with the linear p2m map. It should be noted that this code is

A KernelShark plugin for Xen traces analysis ​

Hello, I want to share with you a new plugin developed by me, under the supervision of Dario Faggioli, which allows the new version of KernelShark (the v2-beta) to open and view the Xen traces created using the "xentrace" tool. In fact, KernelShark is a well known tool for graphical visualization

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

flight 161060 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/161060/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow219 guest-localmigrate/x10 fail REGR. vs. 159418 Tests which

Re: [PATCH] libxl: User defined max_maptrack_frames in a stub domain

On 10/04/2021 16:55, Jason Andryuk wrote: > On Tue, Sep 22, 2020 at 9:31 AM Wei Liu wrote: >> On Mon, Sep 14, 2020 at 04:27:45PM +0100, Andrew Cooper wrote: >>> On 14/09/2020 15:50, Dmitry Fedorov wrote: Hi, Implementing qrexec+usbip+qemu in Linux-based stub domain leads me to

[PATCH v2 10/21] tests/cpu-policy: add sorted MSR test

Further changes will rely on MSR entries being sorted, so add a test to assert it. Signed-off-by: Roger Pau Monné --- Changes since v1: - New in this version. --- tools/tests/cpu-policy/test-cpu-policy.c | 17 + 1 file changed, 17 insertions(+) diff --git

[PATCH v2 21/21] libs/guest: (re)move xc_cpu_policy_apply_cpuid

Move the logic from xc_cpu_policy_apply_cpuid into libxl, now that the xc_cpu_policy_* helpers allow modifying a cpu policy. By moving such parsing into libxl directly we can get rid of xc_xend_cpuid, as libxl will now implement it's own private type for storing CPUID information, which currently

[PATCH v2 19/21] libs/guest: apply a featureset into a cpu policy

Pull out the code from xc_cpuid_apply_policy that applies a featureset to a cpu policy and place it on it's own standalone function that's part of the public interface. No functional change intended. Signed-off-by: Roger Pau Monné --- tools/include/xenctrl.h | 5 ++

[PATCH v2 16/21] libs/guest: make a cpu policy compatible with older Xen versions

Older Xen versions used to expose some CPUID bits which are no longer exposed by default. In order to keep a compatible behavior with guests migrated from versions of Xen that don't encode the CPUID data on the migration stream introduce a function that sets the same bits as older Xen versions.

[PATCH v2 20/21] libs/{light,guest}: implement xc_cpuid_apply_policy in libxl

With the addition of the xc_cpu_policy_* now libxl can have better control over the cpu policy, this allows removing the xc_cpuid_apply_policy function and instead coding the required bits by libxl in libxl__cpuid_legacy directly. Remove xc_cpuid_apply_policy. Signed-off-by: Roger Pau Monné ---

[PATCH v2 14/21] libs/guest: introduce helper to check cpu policy compatibility

Such helpers is just a wrapper to the existing x86_cpu_policies_are_compatible function. This requires building policy.c from libx86 on user land also. No user of the interface introduced. Signed-off-by: Roger Pau Monné --- Changes since v1: - Initialize err. - Explicitly name parameters as

[PATCH v2 17/21] libs/guest: introduce helper set cpu topology in cpu policy

This logic is pulled out from xc_cpuid_apply_policy and placed into a separate helper. Note the legacy part of the introduced function, as long term Xen will require a proper topology setter function capable of expressing a more diverse set of topologies. No functional change intended.

[PATCH v2 13/21] libs/guest: allow updating a cpu policy MSR data

Introduce a helper to update the MSR policy using an array of xen_msr_entry_t entries. Note the MSRs present in the input xen_msr_entry_t array will replace any existing entries on the policy. No user of the interface introduced on this patch. Signed-off-by: Roger Pau Monné --- Changes since

[PATCH v2 18/21] libs/guest: rework xc_cpuid_xend_policy

Rename xc_cpuid_xend_policy to xc_cpu_policy_apply_cpuid and make it public. Modify the function internally to use the new xc_cpu_policy_* set of functions. Also don't apply the passed policy to a domain directly, and instead modify the provided xc_cpu_policy_t. The caller will be responsible of

[PATCH v2 15/21] libs/guest: obtain a compatible cpu policy from two input ones

Introduce a helper to obtain a compatible cpu policy based on two input cpu policies. Currently this is done by and'ing all CPUID leaves and MSR entries, except for MSR_ARCH_CAPABILITIES which has the RSBA bit or'ed. The _AC macro is pulled from libxl_internal.h into xen-tools/libs.h since it's

[PATCH v2 04/21] libs/guest: introduce helper to fetch a system cpu policy

Such helper is based on the existing functions to fetch a CPUID and MSR policies, but uses the xc_cpu_policy_t type to return the data to the caller. Note some helper functions are introduced, those are split from xc_cpu_policy_get_system because they will be used by other functions also. No

[PATCH v2 11/21] libs/guest: allow fetching a specific MSR entry from a cpu policy

Introduce an interface that returns a specific MSR entry from a cpu policy in xen_msr_entry_t format. Provide a helper to perform a binary search against an array of MSR entries. This is useful to callers can peek data from the opaque xc_cpu_policy_t type. No caller of the interface introduced

[PATCH v2 08/21] libs/guest: introduce a helper to apply a cpu policy to a domain

Such helper is very similar to the existing xc_set_domain_cpu_policy interface, but takes an opaque xc_cpu_policy_t instead of arrays of CPUID leaves and MSRs. No callers of the interface introduced in this patch. Signed-off-by: Roger Pau Monné --- tools/include/xenctrl.h | 2 ++

[PATCH v2 07/21] tools: switch existing users of xc_get_{system,domain}_cpu_policy

With the introduction of xc_cpu_policy_get_{system,domain} and xc_cpu_policy_serialise the current users of xc_get_{system,domain}_cpu_policy can be switched to the new interface. Note that xc_get_{system,domain}_cpu_policy is removed from the public interface and the functions are made static,

[PATCH v2 12/21] libs/guest: allow updating a cpu policy CPUID data

Introduce a helper to update the CPUID policy using an array of xen_cpuid_leaf_t entries. Note the leaves present in the input xen_cpuid_leaf_t array will replace any existing leaves on the policy. No user of the interface introduced on this patch. Signed-off-by: Roger Pau Monné --- Changes

[PATCH v2 09/21] libs/guest: allow fetching a specific CPUID leaf from a cpu policy

Introduce an interface that returns a specific leaf/subleaf from a cpu policy in xen_cpuid_leaf_t format. This is useful to callers can peek data from the opaque xc_cpu_policy_t type. No caller of the interface introduced on this patch. Note that callers of find_leaf need to be slightly

[PATCH v2 01/21] libxl: don't ignore the return value from xc_cpuid_apply_policy

Also change libxl__cpuid_legacy to propagate the error from xc_cpuid_apply_policy into callers. Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich --- Changes since 1: - Return ERROR_FAIL on error. --- tools/libs/light/libxl_cpuid.c| 15 +++

[PATCH v2 02/21] libs/guest: rename xc_get_cpu_policy_size to xc_cpu_policy_get_size

Preparatory change to introduce a new set of xc_cpu_policy_* functions that will replace the current CPUID/MSR helpers. No functional change intended. Signed-off-by: Roger Pau Monné Acked-by: Andrew Cooper --- tools/include/xenctrl.h | 2 +- tools/libs/guest/xg_cpuid_x86.c | 6

[PATCH v2 03/21] libs/guest: introduce xc_cpu_policy_t

Introduce an opaque type that is used to store the CPUID and MSRs policies of a domain. Such type uses the existing {cpuid,msr}_policy structures to store the data, but doesn't expose the type to the users of the xenguest library. There are also two arrays to allow for easier serialization without

[PATCH v2 06/21] libs/guest: introduce helper to serialize a cpu policy

Such helper allow converting a cpu policy into an array of xen_cpuid_leaf_t and xen_msr_entry_t elements, which matches the current interface of the CPUID/MSR functions. This is required in order for the user to be able to parse the CPUID/MSR data. No user of the interface introduced in this

[PATCH v2 05/21] libs/guest: introduce helper to fetch a domain cpu policy

Such helper is based on the existing functions to fetch a CPUID and MSR policies, but uses the xc_cpu_policy_t type to return the data to the caller. No user of the interface introduced on the patch. Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich --- Changes since v1: - Uniformly

[PATCH v2 00/21] libs/guest: new CPUID/MSR interface

Hello, The following series introduces a new CPUID/MSR interface for the xenguest library. Such interface handles both CPUID and MSRs using the same opaque object, and provides some helpers for the user to peek or modify such data without exposing the backing type. This is useful for future

Re: x86: memset() / clear_page() / page scrubbing

On 08/04/2021 14:58, Jan Beulich wrote: > All, > > since over the years we've been repeatedly talking of changing the > implementation of these fundamental functions, I've taken some time > to do some measurements (just for possible clear_page() alternatives > to keep things manageable). I'm not

Re: [PATCH v4] VMX: use a single, global APIC access page

On Tue, Apr 13, 2021 at 02:03:52PM +0200, Jan Beulich wrote: > On 13.04.2021 12:18, Roger Pau Monné wrote: > > On Tue, Apr 13, 2021 at 11:24:09AM +0200, Jan Beulich wrote: > >> On 12.04.2021 17:31, Roger Pau Monné wrote: > >>> On Mon, Apr 12, 2021 at 12:40:48PM +0200, Jan Beulich wrote: > +

Re: [PATCH 3/3] xen-pciback: simplify vpci's find hook

On 4/13/21 4:09 AM, Jan Beulich wrote: > On 12.04.2021 18:05, Boris Ostrovsky wrote: >> >> Given that next Sunday may be when 5.12 is released I think everything but >> stoppers will have to wait for the merge window. > Oh, I didn't mean it this way. Instead I thought the 3rd patch here could >

Re: [edk2-devel] [PATCH v3 0/7] OvmfXen: Set PcdFSBClock at runtime

On 04/12/21 15:29, Anthony PERARD via groups.io wrote: > Patch series available in this git branch: > git://xenbits.xen.org/people/aperard/ovmf.git br.apic-timer-freq-v3 > > Changes in v3: > - typos and codying style Merged in commit range 16136f218d54..71cdb91f3133, via

Re: [PATCH v4] VMX: use a single, global APIC access page

On 13.04.2021 12:18, Roger Pau Monné wrote: > On Tue, Apr 13, 2021 at 11:24:09AM +0200, Jan Beulich wrote: >> On 12.04.2021 17:31, Roger Pau Monné wrote: >>> On Mon, Apr 12, 2021 at 12:40:48PM +0200, Jan Beulich wrote: +{ +const struct page_info *pg = mfn_to_page(mfn); +

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

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

Re: xen-netback hotplug-status regression bug

On 13/04/2021 11:48, Michael Brown wrote: On 13/04/2021 08:12, Paul Durrant wrote: If the frontend subsequently disconnects and reconnects (e.g. transitions through Closed->Initialising->Connected) then: - Nothing recreates "hotplug-status" - When the frontend re-enters Connected state,

Re: xen-netback hotplug-status regression bug

On 13/04/2021 08:12, Paul Durrant wrote: If the frontend subsequently disconnects and reconnects (e.g. transitions through Closed->Initialising->Connected) then: - Nothing recreates "hotplug-status" - When the frontend re-enters Connected state, connect() sets up a watch on "hotplug-status"

[qemu-mainline test] 161050: regressions - FAIL

flight 161050 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/161050/ 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: [PATCH v4] VMX: use a single, global APIC access page

On Tue, Apr 13, 2021 at 11:24:09AM +0200, Jan Beulich wrote: > On 12.04.2021 17:31, Roger Pau Monné wrote: > > On Mon, Apr 12, 2021 at 12:40:48PM +0200, Jan Beulich wrote: > >> The address of this page is used by the CPU only to recognize when to > >> access the virtual APIC page instead. No

Re: 回复: [edk2-devel] [PATCH v3 2/7] MdePkg: Allow PcdFSBClock to by Dynamic

On 04/13/21 02:59, gaoliming wrote: > Reviewed-by: Liming Gao Thanks, I've updated the email address in your existent R-b on the patch. Laszlo > >> -邮件原件- >> 发件人: de...@edk2.groups.io 代表 Anthony >> PERARD via groups.io >> 发送时间: 2021年4月12日 21:30 >> 收件人: de...@edk2.groups.io >> 抄送:

Re: [PATCH] Remove support for ThumbEE

On 13/04/2021 10:59, Michal Orzel wrote: On 13.04.2021 11:42, Julien Grall wrote: On 13/04/2021 10:32, Michal Orzel wrote: Hi Julien, On 13.04.2021 11:07, Julien Grall wrote: Hi Michal, On 13/04/2021 09:24, Michal Orzel wrote: ThumbEE(T32EE) was introduced in ARMv7 and removed in

Re: [PATCH v3 7/7] OvmfPkg/OvmfXen: Set PcdFSBClock

On 04/12/21 15:30, Anthony PERARD wrote: > Update gEfiMdePkgTokenSpaceGuid.PcdFSBClock so it can have the correct > value when SecPeiDxeTimerLibCpu start to use it for the APIC timer. > > Currently, nothing appear to use the value in PcdFSBClock before > XenPlatformPei had a chance to set it even

Re: [PATCH v3 6/7] OvmfPkg/XenPlatformPei: Calibrate APIC timer frequency

On 04/12/21 15:30, Anthony PERARD wrote: > Calculate the frequency of the APIC timer that Xen provides. > > Even though the frequency is currently hard-coded, it isn't part of > the public ABI that Xen provides and thus may change at any time. OVMF > needs to determine the frequency by an other

Re: [PATCH v3 4/7] OvmfPkg/IndustryStandard: Introduce PageTable.h

On 04/12/21 15:30, Anthony PERARD wrote: > We are going to use the page table structure in yet another place, > collect the types and macro that can be used from another module > rather than making yet another copy. > > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490 > Signed-off-by:

Re: [PATCH] Remove support for ThumbEE

On 13.04.2021 11:42, Julien Grall wrote: > > > On 13/04/2021 10:32, Michal Orzel wrote: >> Hi Julien, >> >> On 13.04.2021 11:07, Julien Grall wrote: >>> Hi Michal, >>> >>> On 13/04/2021 09:24, Michal Orzel wrote: ThumbEE(T32EE) was introduced in ARMv7 and removed in ARMv8. In 2011

Re: [PATCH] Remove support for ThumbEE

On 13/04/2021 10:32, Michal Orzel wrote: Hi Julien, On 13.04.2021 11:07, Julien Grall wrote: Hi Michal, On 13/04/2021 09:24, Michal Orzel wrote: ThumbEE(T32EE) was introduced in ARMv7 and removed in ARMv8. In 2011 ARM deprecated any use of the ThumbEE instruction set. This doesn't mean

Re: [PATCH] Remove support for ThumbEE

Hi Julien, On 13.04.2021 11:07, Julien Grall wrote: > Hi Michal, > > On 13/04/2021 09:24, Michal Orzel wrote: >> ThumbEE(T32EE) was introduced in ARMv7 and removed in ARMv8. >> In 2011 ARM deprecated any use of the ThumbEE instruction set. > > This doesn't mean this is not present in any CPU.

Re: [PATCH v4] VMX: use a single, global APIC access page

On 12.04.2021 17:31, Roger Pau Monné wrote: > On Mon, Apr 12, 2021 at 12:40:48PM +0200, Jan Beulich wrote: >> The address of this page is used by the CPU only to recognize when to >> access the virtual APIC page instead. No accesses would ever go to this >> page. It only needs to be present in the

Re: [PATCH] Remove support for ThumbEE

Hi Michal, On 13/04/2021 09:24, Michal Orzel wrote: ThumbEE(T32EE) was introduced in ARMv7 and removed in ARMv8. In 2011 ARM deprecated any use of the ThumbEE instruction set. This doesn't mean this is not present in any CPU. In fact, in the same section (see A2.10 in ARM DDI 0406C.d):

[PATCH] Remove support for ThumbEE

ThumbEE(T32EE) was introduced in ARMv7 and removed in ARMv8. In 2011 ARM deprecated any use of the ThumbEE instruction set. This feature is untested and as per my understanding there are no reported users for it. Remove all the bits related to it. Signed-off-by: Michal Orzel ---

Re: [PATCH 3/3] xen-pciback: simplify vpci's find hook

On 12.04.2021 18:05, Boris Ostrovsky wrote: > > On 4/12/21 5:50 AM, Jan Beulich wrote: >> On 09.04.2021 23:45, Boris Ostrovsky wrote: >>> On 4/7/21 10:37 AM, Jan Beulich wrote: There's no point in comparing SBDF - we can simply compare the struct pci_dev pointers. If they weren't the

Re: [PATCH 1/2] x86: correct is_pv_domain() when !CONFIG_PV

On 13.04.2021 09:56, Roger Pau Monné wrote: > On Mon, Apr 12, 2021 at 05:51:17PM +0200, Jan Beulich wrote: >> On 12.04.2021 17:40, Roger Pau Monné wrote: >>> On Mon, Apr 12, 2021 at 05:24:41PM +0200, Jan Beulich wrote: On 12.04.2021 16:49, Roger Pau Monné wrote: > On Mon, Apr 12, 2021 at

Re: [PATCH 1/2] x86: correct is_pv_domain() when !CONFIG_PV

On Mon, Apr 12, 2021 at 05:51:17PM +0200, Jan Beulich wrote: > On 12.04.2021 17:40, Roger Pau Monné wrote: > > On Mon, Apr 12, 2021 at 05:24:41PM +0200, Jan Beulich wrote: > >> On 12.04.2021 16:49, Roger Pau Monné wrote: > >>> On Mon, Apr 12, 2021 at 12:07:12PM +0200, Jan Beulich wrote: > On

Re: xen-netback hotplug-status regression bug

On 10/04/2021 19:25, Michael Brown wrote: Commit https://github.com/torvalds/linux/commit/1f25657 ("xen-netback: remove 'hotplug-status' once it has served its purpose") seems to have introduced a regression that prevents a vif frontend from transitioning more than once into Connected state.

[libvirt test] 161078: regressions - FAIL

flight 161078 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/161078/ 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

Support of old Xen versions in the Linux kernel

In x86 kernel development the question came up whether we need to support XENFEAT_gnttab_map_avail_bits not being set when running as a PV guest. This feature is active for PV guests since Xen 3.4. So the basic question is: which is the oldest version of Xen we want to support in the Linux