On 23.05.2023 18:37, Anthony PERARD wrote:
> Change of directory to xen/lib/x86 isn't needed to be shown. If
> something gets updated, make will print the command line.
>
> Signed-off-by: Anthony PERARD
Acked-by: Jan Beulich
On 23.05.2023 18:38, Anthony PERARD wrote:
> --- a/xen/xsm/flask/Makefile
> +++ b/xen/xsm/flask/Makefile
> @@ -48,10 +48,15 @@ targets += flask-policy.S
> FLASK_BUILD_DIR := $(abs_objtree)/$(obj)
> POLICY_SRC := $(FLASK_BUILD_DIR)/xenpolicy-$(XEN_FULLVERSION)
>
> +policy_chk = \
> +$(Q)if !
On 23.05.2023 18:38, Anthony PERARD wrote:
> Make the gzip command generic and use -9 which wasn't use for
> config.gz. (xen.gz does use -9)
You mention xen.gz here, but you don't make its rule use this new
construct. Is that intentional (and if so, why)? (There we also go
through $@.new, and bein
On 23.05.2023 18:38, Anthony PERARD wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -339,7 +339,7 @@ filechk_kconfig_allconfig = \
> :
>
> .allconfig.tmp: FORCE
> - set -e; { $(call filechk_kconfig_allconfig); } > $@
> + $(Q)set -e; { $(call filechk_kconfig_allconfig); } > $@
> On 23 May 2023, at 17:37, Anthony PERARD wrote:
>
> Use $(if_changed_dep, ) macro to generate "asm-offsets.s" and remove
> the use of $(move-if-changes,). That mean that "asm-offset.s" will be
> changed even when the output doesn't change.
>
> But "asm-offsets.s" is only used to generated "a
Hi Stewart,
On 18/05/2023 23:06, Stewart Hildebrand wrote:
>
>
> From: Oleksandr Tyshchenko
>
> The main purpose of this patch is to add a way to register PCI device
> (which is behind the IOMMU) using the generic PCI-IOMMU DT bindings [1]
> before assigning that device to a domain.
>
> This
On 24.05.2023 09:39, Luca Fancellu wrote:
>> On 23 May 2023, at 17:37, Anthony PERARD wrote:
>> Instead of having a special $(cmd_asm-offsets.s) command, we could
>> probably reuse $(cmd_cc_s_c) from Rules.mk, but that would mean that
>> an hypothetical additional flags "-flto" in CFLAGS would not
On Tue, May 23, 2023 at 11:47:08AM -0400, Stefan Hajnoczi wrote:
On Fri, May 19, 2023 at 10:45:57AM +0200, Stefano Garzarella wrote:
On Wed, May 17, 2023 at 06:10:17PM -0400, Stefan Hajnoczi wrote:
> Introduce a new API for thread-local blk_io_plug() that does not
> traverse the block graph. The
> On 23 May 2023, at 17:38, Anthony PERARD wrote:
>
> Whether or not the linker can do build id is only used by the
> hypervisor build, so move that there.
>
> Rename $(build_id_linker) to $(XEN_LDFLAGS_BUILD_ID) as this is a
> better name to be exported as to use the "XEN_*" namespace.
>
>
On Tue, May 23, 2023 at 01:12:55PM -0400, Stefan Hajnoczi wrote:
Introduce a new API for thread-local blk_io_plug() that does not
traverse the block graph. The goal is to make blk_io_plug() multi-queue
friendly.
Instead of having block drivers track whether or not we're in a plugged
section, pro
On Tue, May 23, 2023 at 01:12:56PM -0400, Stefan Hajnoczi wrote:
Stop using the .bdrv_co_io_plug() API because it is not multi-queue
block layer friendly. Use the new blk_io_plug_call() API to batch I/O
submission instead.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
---
v2
- Remove
On Tue, May 23, 2023 at 01:12:57PM -0400, Stefan Hajnoczi wrote:
Stop using the .bdrv_co_io_plug() API because it is not multi-queue
block layer friendly. Use the new blk_io_plug_call() API to batch I/O
submission instead.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
---
v2
- Add mis
> On 23 May 2023, at 17:38, Anthony PERARD wrote:
>
> Make use of filechk mean that we don't have to use
> $(move-if-changed,). It also mean that will have sometime "UPD .." in
> the build output when the target changed, rather than having "GEN ..."
> all the time when "xlat.lst" happen to hav
> On 24 May 2023, at 09:01, Jan Beulich wrote:
>
> On 24.05.2023 09:39, Luca Fancellu wrote:
>>> On 23 May 2023, at 17:37, Anthony PERARD wrote:
>>> Instead of having a special $(cmd_asm-offsets.s) command, we could
>>> probably reuse $(cmd_cc_s_c) from Rules.mk, but that would mean that
>>> a
On Wed, May 24, 2023, at 01:09, Boris Ostrovsky wrote:
> On 5/23/23 4:37 PM, Arnd Bergmann wrote:
>> On Sat, May 20, 2023, at 00:24, Boris Ostrovsky wrote:
>>> On 5/19/23 5:28 AM, Arnd Bergmann wrote:
>>
>> Not sure if there is much point for the second one, since
>> it's only called from assembler
> On 23 May 2023, at 17:38, Anthony PERARD wrote:
>
> but still show a log entry for syncconfig. We have to use kecho
> instead of $(cmd,) to avoid issue with prompt from kconfig.
>
> linux commits for reference:
>23cd88c91343 ("kbuild: hide commands to run Kconfig, and show short log
>
flight 180919 xen-4.17-testing real [real]
flight 180926 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180919/
http://logs.test-lab.xenproject.org/osstest/logs/180926/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
flight 180921 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180921/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 180691
build-amd64-xsm
> On 23 May 2023, at 17:38, Anthony PERARD wrote:
>
> We don't want the AFLAGS from the environment, they are usually meant
> to build user space application and not for the hypervisor.
>
> Config.mk doesn't provied any $(AFLAGS) so we can start a fresh
> $(XEN_AFLAGS).
>
> Signed-off-by: An
> On 23 May 2023, at 17:38, Anthony PERARD wrote:
>
> This is a preparatory patch. A future patch will not even use
> $(CFLAGS) to seed $(XEN_CFLAGS).
>
> Signed-off-by: Anthony PERARD
Reviewed-by: Luca Fancellu
Tested-by: Luca Fancellu
> On 24 May 2023, at 09:29, Luca Fancellu wrote:
>
>
>
>> On 23 May 2023, at 17:38, Anthony PERARD wrote:
>>
>> We don't want the AFLAGS from the environment, they are usually meant
>> to build user space application and not for the hypervisor.
>>
>> Config.mk doesn't provied any $(AFLAGS
On Tue, May 23, 2023 at 01:12:58PM -0400, Stefan Hajnoczi wrote:
Stop using the .bdrv_co_io_plug() API because it is not multi-queue
block layer friendly. Use the new blk_io_plug_call() API to batch I/O
submission instead.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
---
v2
- Removed
On Tue, May 23, 2023 at 01:13:00PM -0400, Stefan Hajnoczi wrote:
No block driver implements .bdrv_co_io_plug() anymore. Get rid of the
function pointers.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
---
include/block/block-io.h | 3 ---
include/block/block_int-common.h | 11 -
On Tue, May 23, 2023 at 01:12:59PM -0400, Stefan Hajnoczi wrote:
Stop using the .bdrv_co_io_plug() API because it is not multi-queue
block layer friendly. Use the new blk_io_plug_call() API to batch I/O
submission instead.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
---
include/bloc
Hi Luca,
> On 23 May 2023, at 09:43, Luca Fancellu wrote:
>
> Enable Xen to handle the SVE extension, add code in cpufeature module
> to handle ZCR SVE register, disable trapping SVE feature on system
> boot only when SVE resources are accessed.
> While there, correct coding style for the commen
Hi Luca,
> On 23 May 2023, at 09:43, Luca Fancellu wrote:
>
> Add sve_vl field to arch_domain and xen_arch_domainconfig struct,
> to allow the domain to have an information about the SVE feature
> and the number of SVE register bits that are allowed for this
> domain.
>
> sve_vl field is the ve
Hi Luca,
> On 23 May 2023, at 09:43, Luca Fancellu wrote:
>
> When a guest is allowed to use SVE, expose the SVE features through
> the identification registers.
>
> Signed-off-by: Luca Fancellu
> Acked-by: Julien Grall
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
> ---
> Changes from v6
On 23/05/2023 5:37 pm, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
> br.build-system-xen-removing-config.mk-v1
>
> Hi,
>
> This series of patch cleanup the remaining rules still displaying their
> command
>
On 23/05/2023 5:37 pm, Anthony PERARD wrote:
> diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
> index 03d8ce3a9e..2693b938bd 100644
> --- a/xen/arch/x86/boot/Makefile
> +++ b/xen/arch/x86/boot/Makefile
> @@ -26,10 +28,16 @@ $(head-bin-objs): XEN_CFLAGS := $(CFLAGS_x86_32) -fpi
> On 23 May 2023, at 17:38, Anthony PERARD wrote:
>
> The variable $(CFLAGS) is too often set in the environment,
> especially when building a package for a distribution. Often, those
> CFLAGS are intended to be use to build user spaces binaries, not a
NIT: s/use/used/
But I’m not a native sp
> On 23 May 2023, at 17:38, Anthony PERARD wrote:
>
> CFLAGS is just from Config.mk, instead use the flags used to build
> Xen.
>
> Signed-off-by: Anthony PERARD
> ---
>
> Notes:
>I don't know if CFLAGS is even useful there, just --version without the
>flags might produce the same re
Hi Luca,
> On 23 May 2023, at 09:43, Luca Fancellu wrote:
>
> Save/restore context switch for SVE, allocate memory to contain
> the Z0-31 registers whose length is maximum 2048 bits each and
> FFR who can be maximum 256 bits, the allocated memory depends on
> how many bits is the vector length f
> On 24 May 2023, at 10:47, Bertrand Marquis wrote:
>
> Hi Luca,
>
>> On 23 May 2023, at 09:43, Luca Fancellu wrote:
>>
>> Save/restore context switch for SVE, allocate memory to contain
>> the Z0-31 registers whose length is maximum 2048 bits each and
>> FFR who can be maximum 256 bits, the
Hi,
On 24/05/2023 10:01, Bertrand Marquis wrote:
diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
index c4ec38bb2554..83b84368f6d5 100644
--- a/xen/arch/arm/cpufeature.c
+++ b/xen/arch/arm/cpufeature.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
DECLARE_
Hi Luca,
> On 23 May 2023, at 09:43, Luca Fancellu wrote:
>
> Add a command line parameter to allow Dom0 the use of SVE resources,
> the command line parameter sve=, sub argument of dom0=,
> controls the feature on this domain and sets the maximum SVE vector
> length for Dom0.
>
> Add a new fun
> On 23 May 2023, at 17:38, Anthony PERARD wrote:
>
> In xen/, it isn't necessary to include Config.mk in every Makefile in
> subdirectories as nearly all necessary variables should be calculated
> in xen/Makefile. But some Makefile make use of the macro $(cc-option,)
> that is only available
> On 23 May 2023, at 17:38, Anthony PERARD wrote:
>
> Everything needed to build the hypervisor should already be configured
> by "xen/Makefile", thus Config.mk shouldn't be needed.
>
> Then, Config.mk keeps on testing support of some CFLAGS with CC, the
> result of this testing is not used a
We are about to move MSR_ARCH_CAPS into featureset, but the order of
operations (copy raw policy, then copy x86_capabilitiles[] in) will end up
clobbering the ARCH_CAPS value.
Some toolstacks use this information to handle TSX compatibility across the
CPUs and microcode versions where support was
Bits through 24 are already defined, meaning that we're not far off needing
the second word. Put both in right away.
As both halves are present now, the arch_caps field is full width. Adjust the
unit test, which notices.
The bool bitfield names in the arch_caps union are unused, and somewhat ou
Also combined with "x86: Feature check cleanup" for simplicity.
See individual patches for v2 deltas.
Andrew Cooper (10):
x86/boot: Rework dom0 feature configuration
x86/boot: Adjust MSR_ARCH_CAPS handling for the Host policy
x86/cpu-policy: Infrastructure for MSR_ARCH_CAPS
x86/cpu-policy
The current cpu_has_tsx_ctrl tristate is serving double pupose; to signal the
first pass through tsx_init(), and the availability of MSR_TSX_CTRL.
Drop the variable, replacing it with a once boolean, and altering
cpu_has_tsx_ctrl to come out of the feature information.
No functional change.
Sign
Right now, dom0's feature configuration is split between between the common
path and a dom0-specific one. This mostly is by accident, and causes some
very subtle bugs.
First, start by clearly defining init_dom0_cpuid_policy() to be the domain
that Xen builds automatically. The late hwdom case is
One area where Xen deviates from Linux is that test_bit() forces a volatile
read. This leads to poor code generation, because the optimiser cannot merge
bit operations on the same word.
Drop the use of test_bit(), and write the expressions in regular C. This
removes the include of bitops.h (whic
Seed the default visibility from the dom0 special case, which for the most
part just exposes the *_NO bits. EIBRS is the one non-*_NO bit, which is
"just" a status bit to the guest indicating a change in implemention of IBRS
which is already fully supported.
Insert a block dependency from the ARC
We already have common and default feature adjustment helpers. Introduce one
for max featuresets too.
Offer MSR_ARCH_CAPS unconditionally in the max policy, and stop clobbering the
data inherited from the Host policy. This will be necessary to level a VM
safely for migration. Annotate the ARCH_
Extend x86_cpu_policy_fill_native() with a read of ARCH_CAPS based on the
CPUID information just read, removing the specially handling in
calculate_raw_cpu_policy().
Right now, the only use of x86_cpu_policy_fill_native() outside of Xen is the
unit tests. Getting MSR data in this context is left
MSR_ARCH_CAPS data is now included in featureset information.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/hvm/vmx/vmx.c| 8 ++--
xen/arch/x86/include/asm/cpufeatur
MSR_ARCH_CAPS data is now included in featureset information. Replace
opencoded checks with regular feature ones.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/include/asm/cpufeature.h | 7
xen/arch/x86/spec_ctr
On 24.05.2023 08:14, Jan Beulich wrote:
> On 24.05.2023 03:13, Stefano Stabellini wrote:
>> For sure I can test your patch. BTW it is also really easy for you to do
>> it your simply by pushing a branch to a repo on gitlab-ci and watch for
>> the results. If you are interested let me know I can giv
flight 180922 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180922/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-install fail in 180913 pass in
180922
test-amd64-i386-libvirt-r
On 23.05.23 22:56, Arnd Bergmann wrote:
From: Arnd Bergmann
These function are all called from assembler files, or from inline assembler,
so there is no immediate need for a prototype in a header, but if
-Wmissing-prototypes
is enabled, the compiler warns about them:
arch/x86/xen/efi.c:130:13
Hidden devices (e.g. an add-in PCI serial card used for Xen's serial
console) are associated with DomXEN, not Dom0. This means that while
looking for overlapping BARs such devices cannot be found on Dom0's list
of devices; DomXEN's list also needs to be scanned.
Suppress vPCI init altogether for r
On 24.05.2023 03:13, Stefano Stabellini wrote:
> On Tue, 23 May 2023, Jan Beulich wrote:
>> On 23.05.2023 00:20, Stefano Stabellini wrote:
>>> On Sat, 20 May 2023, Roger Pau Monné wrote:
diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index ec2e978a4e6b..0ff8e940fa8d 10
On 24/05/2023 12:25 pm, Andrew Cooper wrote:
> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
> index 9bbb385db42d..f1084bb1ed36 100644
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -477,6 +477,11 @@ static void generic_identify(struct cpuinfo_x86 *c)
On 23.05.2023 18:37, Anthony PERARD wrote:
> Use $(if_changed_dep, ) macro to generate "asm-offsets.s" and remove
> the use of $(move-if-changes,). That mean that "asm-offset.s" will be
> changed even when the output doesn't change.
>
> But "asm-offsets.s" is only used to generated "asm-offsets.h"
On 23.05.2023 18:37, Anthony PERARD wrote:
> We are adding %.lnk to .PRECIOUS or make treat them as intermediate
> targets and remove them.
What's wrong with them getting removed? Note also that's no different from
today, so it's an orthogonal change in any event (unless I'm overlooking
something)
On 19/05/2023 09:54, Michal Orzel wrote:
Hi Ayan,
Hi Michal,
On 18/05/2023 16:39, Ayan Kumar Halder wrote:
Restructure the code so that one can use pa_range_info[] table for both
ARM_32 as well as ARM_64.
Also, removed the hardcoding for P2M_ROOT_ORDER and P2M_ROOT_LEVEL as
p2m_root_order
On Wed, May 24, 2023 at 03:45:58PM +0200, Jan Beulich wrote:
> Hidden devices (e.g. an add-in PCI serial card used for Xen's serial
> console) are associated with DomXEN, not Dom0. This means that while
> looking for overlapping BARs such devices cannot be found on Dom0's list
> of devices; DomXEN'
Hi Julien,
> On 24 May 2023, at 11:58, Julien Grall wrote:
>
> Hi,
>
> On 24/05/2023 10:01, Bertrand Marquis wrote:
>>> diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
>>> index c4ec38bb2554..83b84368f6d5 100644
>>> --- a/xen/arch/arm/cpufeature.c
>>> +++ b/xen/arch/arm/cpufe
The 'i' iterator index stores a PDX, not a PFN, and hence the initial
assignation of start (which stores a PFN) needs a conversion from PFN
to PDX.
This is harmless currently, as the PDX compression skips the bottom
MAX_ORDER bits which cover the low 1MB, but still do the conversion
from PDX to PF
flight 180928 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180928/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ba91d0292e593df8528b66f99c1b0b14fadc8e16
baseline version:
ovmf 5ce29ae84db340244c3c3
On 24.05.2023 16:22, Roger Pau Monné wrote:
> On Wed, May 24, 2023 at 03:45:58PM +0200, Jan Beulich wrote:
>> Hidden devices (e.g. an add-in PCI serial card used for Xen's serial
>> console) are associated with DomXEN, not Dom0. This means that while
>> looking for overlapping BARs such devices can
On 24.05.2023 16:30, Roger Pau Monne wrote:
> The 'i' iterator index stores a PDX, not a PFN, and hence the initial
> assignation of start (which stores a PFN) needs a conversion from PFN
> to PDX.
>
> This is harmless currently, as the PDX compression skips the bottom
> MAX_ORDER bits which cover
On 24.05.2023 13:25, Andrew Cooper wrote:
> Bits through 24 are already defined, meaning that we're not far off needing
> the second word. Put both in right away.
>
> As both halves are present now, the arch_caps field is full width. Adjust the
> unit test, which notices.
>
> The bool bitfield
On 24.05.2023 13:25, Andrew Cooper wrote:
> Seed the default visibility from the dom0 special case, which for the most
> part just exposes the *_NO bits. EIBRS is the one non-*_NO bit, which is
> "just" a status bit to the guest indicating a change in implemention of IBRS
> which is already fully
On 24.05.2023 13:25, Andrew Cooper wrote:
> We already have common and default feature adjustment helpers. Introduce one
> for max featuresets too.
>
> Offer MSR_ARCH_CAPS unconditionally in the max policy, and stop clobbering the
> data inherited from the Host policy. This will be necessary to
On 24.05.2023 13:25, Andrew Cooper wrote:
> MSR_ARCH_CAPS data is now included in featureset information. Replace
> opencoded checks with regular feature ones.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
flight 180924 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180924/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 180910
test-armhf-armhf-libvirt-raw 15 saveresto
Hi Luca,
> On 23 May 2023, at 09:43, Luca Fancellu wrote:
>
> Add a device tree property in the dom0less domU configuration
> to enable the guest to use SVE.
>
> Update documentation.
>
> Signed-off-by: Luca Fancellu
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
> ---
> Changes from v6:
>
Hi Luca,
> On 23 May 2023, at 09:43, Luca Fancellu wrote:
>
> Arm now can use the "dom0=" Xen command line option and the support
> for guests running SVE instructions is added, put entries in the
> changelog.
>
> Mention the "Tech Preview" status and add an entry in SUPPORT.md
>
> Signed-off-
When translating an address that falls inside of a superpage in the
IOMMU page tables the fetching of the PTE value wasn't masking of the
contiguous related data, which caused the returned data to be
corrupt as it would contain bits that the caller would interpret as
part of the address.
Fix this
Hi Andrew,
> On 4 May 2023, at 15:14, Bertrand Marquis wrote:
>
> Hi Andrew,
>
>> On 14 Apr 2023, at 10:58, Jens Wiklander wrote:
>>
>> Hi,
>>
>> On Thu, Apr 13, 2023 at 3:27 PM Andrew Cooper
>> wrote:
>>>
>>> On 13/04/2023 1:26 pm, Julien Grall wrote:
> +static int ffa_domain_init(st
On Wed, May 24, 2023 at 04:44:49PM +0200, Jan Beulich wrote:
> On 24.05.2023 16:22, Roger Pau Monné wrote:
> > On Wed, May 24, 2023 at 03:45:58PM +0200, Jan Beulich wrote:
> >> Hidden devices (e.g. an add-in PCI serial card used for Xen's serial
> >> console) are associated with DomXEN, not Dom0. T
On Wed, May 03, 2023 at 01:16:53PM +, Maximilian Heyne wrote:
> Commit bf5e758f02fc ("genirq/msi: Simplify sysfs handling") reworked the
> creation of sysfs entries for MSI IRQs. The creation used to be in
> msi_domain_alloc_irqs_descs_locked after calling ops->domain_alloc_irqs.
> Then it move
On 24.05.23 17:43, Maximilian Heyne wrote:
On Wed, May 03, 2023 at 01:16:53PM +, Maximilian Heyne wrote:
Commit bf5e758f02fc ("genirq/msi: Simplify sysfs handling") reworked the
creation of sysfs entries for MSI IRQs. The creation used to be in
msi_domain_alloc_irqs_descs_locked after callin
On Wed, May 24, 2023 at 03:45:58PM +0200, Jan Beulich wrote:
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -218,6 +218,7 @@ static int modify_bars(const struct pci_
> struct vpci_header *header = &pdev->vpci->header;
> struct rangeset *mem = rangeset_new(NULL, N
On 5/24/23 08:47, Juergen Gross wrote:
>> Any other feedback on this one? This is definitely a bug but I
>> understand that
>> there might be different ways to fix it.
>
> I'd be happy to take the patch via the Xen tree, but I think x86
> maintainers should at least ack that.
Ack.
Works for me.
Since firmware doesn't indicate the iBFT in the E820, add a reserved
region so that it gets identity mapped when running as Dom 0 so that it
is possible to search for it. Move the call to reserve_ibft_region()
later so that it is called after the Xen identity mapping adjustments
are applied.
Final
On 24.05.2023 17:22, Roger Pau Monne wrote:
> When translating an address that falls inside of a superpage in the
> IOMMU page tables the fetching of the PTE value wasn't masking of the
> contiguous related data, which caused the returned data to be
> corrupt as it would contain bits that the calle
flight 180929 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180929/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 24/05/2023 3:53 pm, Jan Beulich wrote:
> On 24.05.2023 13:25, Andrew Cooper wrote:
>> Bits through 24 are already defined, meaning that we're not far off needing
>> the second word. Put both in right away.
>>
>> As both halves are present now, the arch_caps field is full width. Adjust
>> the
flight 180927 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180927/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 180691
build-amd64-xsm
Signed-off-by: Olaf Hering
---
xen/include/public/hvm/dm_op.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/public/hvm/dm_op.h b/xen/include/public/hvm/dm_op.h
index acdf91693d..fa98551914 100644
--- a/xen/include/public/hvm/dm_op.h
+++ b/xen/include/public/hvm/d
On Mon, May 08, 2023 at 09:44:17PM +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> Make the primary thread tracking CPU mask based in preparation for simpler
> handling of parallel bootup.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Michael Kelley
>
>
> ---
> arch/x86/include/
On 5/5/23 12:31, Sean Christopherson wrote:
> On Fri, May 05, 2023, Micka�l Sala�n wrote:
>>
>> On 05/05/2023 18:28, Sean Christopherson wrote:
>>> I have no doubt that we'll need to solve performance and scaling issues
>>> with the
>>> memory attributes implementation, e.g. to utilize xarr
On 5/5/2023 8:20 AM, Mickaël Salaün wrote:
Hi,
This patch series is a proof-of-concept that implements new KVM features
(extended page tracking, MBEC support, CR pinning) and defines a new API to
protect guest VMs. No VMM (e.g., Qemu) modification is required.
The main idea being that kernel se
On Wed, 24 May 2023, Olaf Hering wrote:
> Signed-off-by: Olaf Hering
Acked-by: Stefano Stabellini
> ---
> xen/include/public/hvm/dm_op.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/include/public/hvm/dm_op.h b/xen/include/public/hvm/dm_op.h
> index acdf91693d
On Fri, 2023-05-05 at 17:20 +0200, Mickaël Salaün wrote:
> # How does it work?
>
> This implementation mainly leverages KVM capabilities to control the
> Second
> Layer Address Translation (or the Two Dimensional Paging e.g.,
> Intel's EPT or
> AMD's RVI/NPT) and Mode Based Execution Control (Inte
flight 180925 linux-linus real [real]
flight 180932 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180925/
http://logs.test-lab.xenproject.org/osstest/logs/180932/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
flight 180931 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180931/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Wed, 24 May 2023, Jan Beulich wrote:
> >> RFC: _setup_hwdom_pci_devices()' loop may want splitting: For
> >> modify_bars() to consistently respect BARs of hidden devices while
> >> setting up "normal" ones (i.e. to avoid as much as possible the
> >> "continue" path introduced here
On Wed, 24 May 2023, Jan Beulich wrote:
> Hidden devices (e.g. an add-in PCI serial card used for Xen's serial
> console) are associated with DomXEN, not Dom0. This means that while
> looking for overlapping BARs such devices cannot be found on Dom0's list
> of devices; DomXEN's list also needs to
On Tue, 23 May 2023, Roger Pau Monné wrote:
> On Tue, May 23, 2023 at 03:54:36PM +0200, Roger Pau Monné wrote:
> > On Thu, May 18, 2023 at 04:44:53PM -0700, Stefano Stabellini wrote:
> > > Hi all,
> > >
> > > After many PVH Dom0 suspend/resume cycles we are seeing the following
> > > Xen crash (it
On Fri, 19 May 2023, Luca Fancellu wrote:
> Use tuple comparison to check the cppcheck version.
>
> Take the occasion to harden the regex, escaping the dots so that we
> check for them instead of generic characters.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Luca Fancellu
Acked-by: Stefa
On 5/24/2023 3:20 PM, Edgecombe, Rick P wrote:
On Fri, 2023-05-05 at 17:20 +0200, Mickaël Salaün wrote:
# How does it work?
This implementation mainly leverages KVM capabilities to control the
Second
Layer Address Translation (or the Two Dimensional Paging e.g.,
Intel's EPT or
AMD's RVI/NPT) an
On Fri, 19 May 2023, Luca Fancellu wrote:
> Fix the generation of the relative path from the repo, for cppcheck
> reports, when the script is launching make with in-tree build.
>
> Fixes: b046f7e37489 ("xen/misra: xen-analysis.py: use the relative path from
> the ...")
> Reported-by: Michal Orzel
On Fri, 19 May 2023, Luca Fancellu wrote:
> Add a new tool, diff-report.py that can be used to make diff between
> reports generated by xen-analysis.py tool.
> Currently this tool supports the Xen cppcheck text report format in
> its operations.
>
> The tool prints every finding that is in the rep
On Fri, 19 May 2023, Luca Fancellu wrote:
> > On 19 May 2023, at 10:46, Luca Fancellu wrote:
> >
> > Add a feature to the diff-report.py script that improves the comparison
> > between two analysis report, one from a baseline codebase and the other
> > from the changes applied to the baseline.
>
flight 180933 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180933/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 180691
build-amd64-xsm
flight 180930 xen-unstable real [real]
flight 180935 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180930/
http://logs.test-lab.xenproject.org/osstest/logs/180935/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
1 - 100 of 103 matches
Mail list logo
