flight 180034 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180034/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
> From: Dmitry Isaykin
> Sent: Tuesday, March 21, 2023 9:59 PM
>
> Adds monitor support for I/O instructions.
>
> Signed-off-by: Dmitry Isaykin
> Signed-off-by: Anton Belousov
Reviewed-by: Kevin Tian
On Mon, 27 Mar 2023, Julien Grall wrote:
> From: Julien Grall
>
> It is easier to understand the license of a file when using SPDX.
>
> This is replacing the below pattern with the SPDX tag GPL-2.0-or-later
> in xen/arch/x86/*.h:
>
> * This program is free software; you can redistribute it
On Mon, 27 Mar 2023, Julien Grall wrote:
> From: Julien Grall
>
> It is easier to understand the license of a file when using SPDX.
>
> This is replacing the below pattern with the SPDX tag GPL-2.0-or-later
> in xen/arch/x86/*.c:
>
> * This program is free software; you can redistribute it
On Mon, 27 Mar 2023, Julien Grall wrote:
> From: Julien Grall
>
> It is easier to understand the license of a file when using SPDX.
>
> This is replacing the below pattern with the SPDX tag GPL-2.0-only
> in xen/arch/x86/*.h:
>
> * This program is free software; you can redistribute it and/or
On Mon, 27 Mar 2023, Julien Grall wrote:
> From: Julien Grall
>
> It is easier to understand the license of a file when using SPDX.
>
> This is replacing the below pattern with the SPDX tag GPL-2.0-only
> in xen/arch/x86/*.h:
>
> * This program is free software; you can redistribute it and/or
On Mon, 27 Mar 2023, Julien Grall wrote:
> From: Julien Grall
>
> It is easier to understand the license of a file when using SPDX.
>
> This is replacing the below pattern with the SPDX tag GPL-2.0-only
> in xen/arch/x86/*.c:
>
> * This program is free software; you can redistribute it and/or
On Mon, 27 Mar 2023, Julien Grall wrote:
> From: Julien Grall
>
> It is easier to understand the license of a file when using SPDX.
>
> This is replacing the below pattern with the SPDX tag GPL-2.0-only
> in xen/arch/x86/*.c:
>
> * This program is free software; you can redistribute it and/or
On Sat, 25 Mar 2023, Marek Marczykowski-Górecki wrote:
> This is a first test using Qubes OS CI infra. The gitlab-runner has
> access to ssh-based control interface (control@thor.testnet, ssh key
> exposed to the test via ssh-agent) and pre-configured HTTP dir for boot
> files (mapped under
On Sat, 25 Mar 2023, Marek Marczykowski-Górecki wrote:
> It will be used in tests added in subsequent patches.
> Enable config options needed for those tests.
> While at it, migrate all the x86 tests to the newer kernel, and
> introduce x86-64-test-needs to allow deduplication later (for now it's
On Mon, 27 Mar 2023, Julien Grall wrote:
> From: Julien Grall
>
> >From https://spdx.org/licenses/GPL-2.0.html, the SPDX tag GPL-2.0
> is deprecated. Instead, GPL-2.0-only should be used.
>
> Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
> ---
> Changes in v2:
> -
flight 180030 qemu-upstream-unstable real [real]
flight 180033 qemu-upstream-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180030/
http://logs.test-lab.xenproject.org/osstest/logs/180033/
Failures :-/ but no regressions.
Tests which are failing intermittently (not
These both incorrectly cache bootstrap_map()'d pointers across returns back to
__start_xen(). This is never valid, and such pointers may fault, or point to
something unrelated.
With the refactoring work in the previous patches, they're clearly now just
non-standard function return parameters.
It is not valid to retain a bootstrap_map() across returning back to
__start_xen(), but various pointers get stashed across calls.
Begin to address this by folding early_update_cache() into it's single caller,
rearranging the exit path to always invalidate the mapping.
No practical change.
When microcode_scan_module() is used, it's used twice.
The caching of the bootstrap_map() pointer in ucode_blob.data is buggy for
multiple reasons and is going to be removed.
Right now, the boot flow depends on the second pass over
bootstrap_map()/find_cpio_data() altering ucode_blob.data to use
This is imported from Linux, but the parameter being signed is dubious in the
first place and we're not plausibly going to gain a use for the functionality.
Linux has subsequently made it an optional parameter to avoid forcing callers
to pass a stack variable they don't care about using.
In the
Stumbled on to while trying to fix bugs elsewhere with bootstrap_map(). I
don't know if I'd conciously reaslised how bogus microcode_init() was
previously, but it absolutely can't stay...
Andrew Cooper (5):
xen/earlycpio: Drop nextoff parameter
x86/ucode: Fold early_update_cache() into
It is not valid to retain a bootstrap_map() across returning back to
__start_xen(), but various pointers get stashed across calls.
Begin to address this by folding early_update_cache() into it's single caller,
rearranging the exit path to always invalidate the mapping.
No practical change.
flight 180029 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180029/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit1 14 guest-start fail REGR. vs. 178042
flight 180031 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180031/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 144028626e0072c2c4fdfcc0fe1b72de319bdd2f
baseline version:
ovmf
From: Julien Grall
It is easier to understand the license of a file when using SPDX.
This is replacing the below pattern with the SPDX tag GPL-2.0-only
in xen/arch/x86/*.h:
* This program is free software; you can redistribute it and/or
* modify it under the terms and conditions of the GNU
From: Julien Grall
It is easier to understand the license of a file when using SPDX.
This is replacing the below pattern with the SPDX tag GPL-2.0-or-later
in xen/arch/x86/*.h:
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General
From: Julien Grall
>From https://spdx.org/licenses/GPL-2.0.html, the SPDX tag GPL-2.0
is deprecated. Instead, GPL-2.0-only should be used.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
LICENSES/GPL-2.0 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Julien Grall
It is easier to understand the license of a file when using SPDX.
This is replacing the below pattern with the SPDX tag GPL-2.0-or-later
in xen/arch/x86/*.c:
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General
From: Julien Grall
Hi all,
This is a first attempt to replace all the full license text with
SPX tag in xen/arch/x86/. This is covering most of the x86 files.
I have used the script below to remove the full license and add
an SPDX tag. The script is based on the work from Anthony [1].
#!
From: Julien Grall
It is easier to understand the license of a file when using SPDX.
This is replacing the below pattern with the SPDX tag GPL-2.0-only
in xen/arch/x86/*.c:
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU
From: Julien Grall
It is easier to understand the license of a file when using SPDX.
This is replacing the below pattern with the SPDX tag GPL-2.0-only
in xen/arch/x86/*.h:
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU
From: Julien Grall
It is easier to understand the license of a file when using SPDX.
This is replacing the below pattern with the SPDX tag GPL-2.0-only
in xen/arch/x86/*.c:
* This program is free software; you can redistribute it and/or
* modify it under the terms and conditions of the GNU
The idea was taken from xvisor but the following changes
were done:
* Use only a minimal part of the code enough to enable MMU
* rename {_}setup_initial_pagetables functions
* add an argument for setup_initial_mapping to have
an opportunity to make set PTE flags.
* update
The patch does two thing:
1. Setup initial pagetables.
2. Enable MMU which end up with code in
cont_after_mmu_is_enabled()
Signed-off-by: Oleksii Kurochko
---
Changes in V3:
- update the commit message that MMU is also enabled here
- remove early_printk("All set up\n") as it was moved to
The patch series is based on top patches [1] and [2]
The patch series introduces the following things:
1. Functionality to build the page tables for Xen that map
link-time to physical-time location.
2. Check that Xen is less then page size.
3. Check that load addresses don't overlap with
After introduction of initial pagetables there is no any sense
in dummy_bss variable as bss section will not be empty anymore.
Signed-off-by: Oleksii Kurochko
---
Changes in V3:
* patch was introduced in the current one patch series (v3).
---
Changes in V2:
* patch was introduced in the
On 27.03.23 17:38, Jan Beulich wrote:
On 27.03.2023 12:07, Juergen Gross wrote:
On 27.03.23 11:49, Jan Beulich wrote:
On 27.03.2023 10:36, Juergen Gross wrote:
@@ -413,6 +418,13 @@ static void xenvif_get_requests(struct xenvif_queue *queue,
cop->dest.u.gmfn =
A recent xentrace highlighted an unhandled corner case in the vcpu
"start-of-day" logic, if the trace starts after the last running ->
non-running transition, but before the first non-running -> running
transition. Because start-of-day wasn't handled, vcpu_next_update()
was expecting p->current
For now, mainly just do volume analysis and get rid of the warnings.
Signed-off-by: George Dunlap
---
CC: Wei Liu
CC: Anthony PERARD
---
tools/xentrace/xenalyze.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/tools/xentrace/xenalyze.c
Hello Jan,
On Thu, 2023-03-16 at 10:52 +0100, Jan Beulich wrote:
> On 15.03.2023 18:21, Oleksii Kurochko wrote:
> > The following changes were made:
> > * Make GENERIC_BUG_FRAME mandatory for X86
> > * Update asm/bug.h using generic implementation in
> > * Update do_invalid_op using generic
On 27.03.2023 12:55, Andrew Cooper wrote:
> On 21/03/2023 2:30 pm, Jan Beulich wrote:
>> 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
On 27.03.23 17:49, Roger Pau Monné wrote:
On Mon, Mar 27, 2023 at 03:58:26PM +0200, Juergen Gross wrote:
On 21.03.23 15:19, 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
On Mon, Mar 27, 2023 at 03:58:26PM +0200, Juergen Gross wrote:
> On 21.03.23 15:19, 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
On 23.03.2023 17:40, Roger Pau Monné wrote:
> On Thu, Mar 23, 2023 at 05:08:43PM +0100, Jan Beulich wrote:
>> On 23.03.2023 15:49, Roger Pau Monné wrote:
>>> On Mon, Mar 20, 2023 at 09:32:26AM +0100, Jan Beulich wrote:
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@
On 23.03.2023 15:49, Roger Pau Monné wrote:
> On Mon, Mar 20, 2023 at 09:32:26AM +0100, Jan Beulich wrote:
>> @@ -1249,6 +1252,80 @@ static unsigned long get_cmos_time(void)
>> return mktime(rtc.year, rtc.mon, rtc.day, rtc.hour, rtc.min, rtc.sec);
>> }
>>
>> +static unsigned int
On 21.03.2023 15:12, Roger Pau Monné wrote:
> 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
On 24.03.2023 23:08, Andrew Cooper wrote:
> While we've been diligent to ensure that the main text/data/rodata mappings
> have suitable restrictions, their aliases via the directmap were left fully
> read/write. Worse, we even had pieces of code making use of this as a
> feature.
>
> Restrict
On Mon, Mar 27, 2023 at 05:32:01PM +0200, Jan Beulich wrote:
> On 27.03.2023 12:12, Roger Pau Monné wrote:
> > On Sat, Mar 25, 2023 at 03:49:22AM +0100, Marek Marczykowski-Górecki wrote:
> >> QEMU needs to know whether clearing maskbit of a vector is really
> >> clearing, or was already cleared
On 24.03.2023 22:44, Andrew Cooper wrote:
> These two early exits skipped re-enabling the watchdog, and restoring the NMI
> callback. Always execute the tail of the function on the way out.
>
> Fixes: 8dd4dfa92d62 ("x86/microcode: Synchronize late microcode loading")
> Signed-off-by: Andrew
Hi,
At 10:33 +0100 on 22 Mar (1679481226), Jan Beulich wrote:
> There's no need for an indirect call here, as the mode is invariant
> throughout the entire paging-locked region. All it takes to avoid it is
> to have a forward declaration of sh_update_cr3() in place.
>
> Signed-off-by: Jan
On 27.03.2023 12:07, Juergen Gross wrote:
> On 27.03.23 11:49, Jan Beulich wrote:
>> On 27.03.2023 10:36, Juergen Gross wrote:
>>> @@ -413,6 +418,13 @@ static void xenvif_get_requests(struct xenvif_queue
>>> *queue,
>>> cop->dest.u.gmfn = virt_to_gfn(skb->data + skb_headlen(skb)
>>>
On 27.03.2023 12:12, Roger Pau Monné wrote:
> On Sat, Mar 25, 2023 at 03:49:22AM +0100, Marek Marczykowski-Górecki wrote:
>> QEMU needs to know whether clearing maskbit of a vector is really
>> clearing, or was already cleared before. Currently Xen sends only
>> clearing that bit to the device
On Mon, Mar 27, 2023 at 04:20:45PM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Mar 27, 2023 at 03:29:55PM +0200, Roger Pau Monné wrote:
> > On Mon, Mar 27, 2023 at 01:34:23PM +0200, Marek Marczykowski-Górecki wrote:
> > > On Mon, Mar 27, 2023 at 12:51:09PM +0200, Roger Pau Monné wrote:
> >
On Mon, Mar 27, 2023 at 03:29:55PM +0200, Roger Pau Monné wrote:
> On Mon, Mar 27, 2023 at 01:34:23PM +0200, Marek Marczykowski-Górecki wrote:
> > On Mon, Mar 27, 2023 at 12:51:09PM +0200, Roger Pau Monné wrote:
> > > On Mon, Mar 27, 2023 at 12:26:05PM +0200, Marek Marczykowski-Górecki
> > >
On Wed, Mar 22, 2023 at 11:59:40AM +0100, Jan Beulich wrote:
> When !GRANT_TABLE and !PV_SHIM headers-n contains grant_table.h twice,
> causing make to complain "target '...' given more than once in the same
> rule" for the rule generating the stub headers. We don't need duplicate
> entries in
On Fri, Mar 24, 2023 at 08:14:04PM +, Andrew Cooper wrote:
> Following Demi's work to use HTTPS everywhere, all users of GIT_HTTP have
> been removed from the build system. Drop the configure knob.
>
> Signed-off-by: Andrew Cooper
Do we need a changelog entry about these changes? (That git
On 21.03.23 15:19, 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" (Processor Driver
Hi,
Just to let you know that we've added both machines "rimava0" and
"rimava1" in back in production. I did run a whole "xen-unstable" flight on
just those two machines and it looked fine.
Cheers,
--
Anthony PERARD
Hi,
On 27/03/2023 12:46, Ayan Kumar Halder wrote:
On 22/03/2023 13:53, Jan Beulich wrote:
On 22.03.2023 14:29, Julien Grall wrote:
On 22/03/2023 06:59, Jan Beulich wrote:
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
On Mon, Mar 27, 2023 at 01:34:23PM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Mar 27, 2023 at 12:51:09PM +0200, Roger Pau Monné wrote:
> > On Mon, Mar 27, 2023 at 12:26:05PM +0200, Marek Marczykowski-Górecki wrote:
> > > On Mon, Mar 27, 2023 at 12:12:29PM +0200, Roger Pau Monné wrote:
> >
On Fri, Mar 24, 2023 at 9:44 PM Andrew Cooper wrote:
>
> These two early exits skipped re-enabling the watchdog, and restoring the NMI
> callback. Always execute the tail of the function on the way out.
>
> Fixes: 8dd4dfa92d62 ("x86/microcode: Synchronize late microcode loading")
>
flight 180028 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180028/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2bc854588309b6a9b348655297f3f82165de23a7
baseline version:
ovmf
Hi Jan, Julien,
On 22/03/2023 13:53, Jan Beulich wrote:
On 22.03.2023 14:29, Julien Grall wrote:
On 22/03/2023 06:59, Jan Beulich wrote:
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,
flight 180025 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180025/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit1 14 guest-start fail REGR. vs. 178042
On Mon, Mar 27, 2023 at 12:51:09PM +0200, Roger Pau Monné wrote:
> On Mon, Mar 27, 2023 at 12:26:05PM +0200, Marek Marczykowski-Górecki wrote:
> > On Mon, Mar 27, 2023 at 12:12:29PM +0200, Roger Pau Monné wrote:
> > > On Sat, Mar 25, 2023 at 03:49:22AM +0100, Marek Marczykowski-Górecki
> > >
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.
Signed-off-by: Luca Fancellu
---
Change from v3:
- new patch
---
CHANGELOG.md | 5 +
1 file changed, 5 insertions(+)
diff --git a/CHANGELOG.md
Add sve parameter in XL configuration to allow guests to use
SVE feature.
Signed-off-by: Luca Fancellu
Acked-by: George Dunlap
---
Changes from v3:
- no changes
Changes from v2:
- domain configuration field name has changed to sve_vl,
also its value now is VL/128.
- Add Ack-by George for
On Arm, the SVE vector length is encoded in arch_capabilities field
of struct xen_sysctl_physinfo, make use of this field in the tools
when building for arm.
Create header arm-arch-capabilities.h to handle the arch_capabilities
field of physinfo for Arm.
Removed include for
Add a device tree property in the dom0less domU configuration
to enable the guest to use SVE.
Update documentation.
Signed-off-by: Luca Fancellu
---
Changes from v3:
- Now domainconfig_encode_vl is named sve_encode_vl
Changes from v2:
- xen_domctl_createdomain field name has changed into
Currently x86 defines a Xen command line argument dom0= where
there can be specified dom0 controlling sub-options, to use it also
on Arm, move the code that loops through the list of arguments from
x86 to the common code and from there, call architecture specific
functions to handle the comma
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 function, parse_integer(), to parse an integer command
line argument.
SVE has a new exception class with code 0x19, introduce the new code
and handle the exception.
Signed-off-by: Luca Fancellu
---
Changes from v3:
- No changes
Changes from v2:
- No changes
Changes from v1:
- No changes
Changes from RFC:
- No changes
---
xen/arch/arm/include/asm/processor.h |
When the arm platform supports SVE, advertise the feature in the
field arch_capabilities in struct xen_sysctl_physinfo by encoding
the SVE vector length in it.
Signed-off-by: Luca Fancellu
---
Changes from v3:
- domainconfig_encode_vl is now named sve_encode_vl
Changes from v2:
- Remove
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 for the domain and how many bits
are supported by the platform.
Save
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 comment on coprocessor
trapping.
Now cptr_el2 is part of the domain context
When a guest is allowed to use SVE, expose the SVE features through
the identification registers.
Signed-off-by: Luca Fancellu
---
Changes from v3:
- no changes
Changes from v2:
- no changes
Changes from v1:
- No changes
Changes from RFC:
- No changes
---
xen/arch/arm/arm64/vsysreg.c | 39
This serie is introducing the possibility for Dom0 and DomU guests to use
sve/sve2 instructions.
SVE feature introduces new instruction and registers to improve performances on
floating point operations.
The SVE feature is advertised using the ID_AA64PFR0_EL1 register, SVE field, and
when
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 vector length in bits divided by 128, this
allows to use less space in the
On 21/03/2023 2:30 pm, Jan Beulich wrote:
> 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
On 27/03/2023 11:50, Oleksii wrote:
Hello Julien,
Hi,
On Tue, 2023-03-21 at 17:58 +, Julien Grall wrote:
+ /* Setup level0 table */
+ if ( !pte_is_valid([index0]) )
On the previous version, you said it should be checked for each
level.
But here you still only check
On Mon, Mar 27, 2023 at 12:26:05PM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Mar 27, 2023 at 12:12:29PM +0200, Roger Pau Monné wrote:
> > On Sat, Mar 25, 2023 at 03:49:22AM +0100, Marek Marczykowski-Górecki wrote:
> > > QEMU needs to know whether clearing maskbit of a vector is really
> >
Hello Julien,
On Tue, 2023-03-21 at 17:58 +, Julien Grall wrote:
> > + /* Setup level0 table */
> > + if ( !pte_is_valid([index0]) )
>
> On the previous version, you said it should be checked for each
> level.
> But here you still only check for a single level.
>
>
On 25/03/2023 2:49 am, Marek Marczykowski-Górecki wrote:
> diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
> index 9c82bf9b4ec2..9293009a4075 100644
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -438,6 +438,152 @@ static const struct hvm_io_ops
On Mon, Mar 27, 2023 at 12:12:29PM +0200, Roger Pau Monné wrote:
> On Sat, Mar 25, 2023 at 03:49:22AM +0100, Marek Marczykowski-Górecki wrote:
> > QEMU needs to know whether clearing maskbit of a vector is really
> > clearing, or was already cleared before. Currently Xen sends only
> > clearing
On Sat, Mar 25, 2023 at 03:49:22AM +0100, Marek Marczykowski-Górecki wrote:
> QEMU needs to know whether clearing maskbit of a vector is really
> clearing, or was already cleared before. Currently Xen sends only
> clearing that bit to the device model, but not setting it, so QEMU
> cannot detect
On older systems, XHCI xcap had a layout that no other (interesting) registers
were placed on the same page as the debug capability, so Linux was fine with
making the whole page R/O. But at least on Tiger Lake and Alder Lake, Linux
needs to write to some other registers on the same page too.
Add
... not the whole page, which may contain other registers too. In fact
on Tiger Lake and newer (at least), this page do contain other registers
that Linux tries to use. And with share=yes, a domU would use them too.
Without this patch, PV dom0 would fail to initialize the controller,
while HVM
In some cases, only few registers on a page needs to be write-protected.
Examples include USB3 console (64 bytes worth of registers) or MSI-X's
PBA table (which doesn't need to span the whole table either).
Current API allows only marking whole pages pages read-only, which
sometimes may cover
On 27.03.23 11:49, Jan Beulich wrote:
On 27.03.2023 10:36, Juergen Gross wrote:
Fix xenvif_get_requests() not to do grant copy operations across local
page boundaries. This requires to double the maximum number of copy
operations per queue, as each copy could now be split into 2.
Make sure
On 27.03.2023 10:36, Juergen Gross wrote:
> Fix xenvif_get_requests() not to do grant copy operations across local
> page boundaries. This requires to double the maximum number of copy
> operations per queue, as each copy could now be split into 2.
>
> Make sure that struct xenvif_tx_cb doesn't
flight 180027 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180027/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d55d73152ebf5c793b645d6ec5bc517d219881cd
baseline version:
ovmf
flight 180024 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180024/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsmbroken
Tests
On 27/03/2023 09:36, Juergen Gross wrote:
The tests for the number of grant mapping or copy operations reaching
the array size of the operations buffer at the end of the main loop in
xenvif_tx_build_gops() isn't needed.
The loop can handle at maximum MAX_PENDING_REQS transfer requests, as
On 27/03/2023 09:36, Juergen Gross wrote:
Fix xenvif_get_requests() not to do grant copy operations across local
page boundaries. This requires to double the maximum number of copy
operations per queue, as each copy could now be split into 2.
Make sure that struct xenvif_tx_cb doesn't grow too
Hi Andrew,
Reviewed-by: Oleksii Kurochko
~ Oleksii
The tests for the number of grant mapping or copy operations reaching
the array size of the operations buffer at the end of the main loop in
xenvif_tx_build_gops() isn't needed.
The loop can handle at maximum MAX_PENDING_REQS transfer requests, as
XEN_RING_NR_UNCONSUMED_REQUESTS() is taking
Fix xenvif_get_requests() not to do grant copy operations across local
page boundaries. This requires to double the maximum number of copy
operations per queue, as each copy could now be split into 2.
Make sure that struct xenvif_tx_cb doesn't grow too large.
Cc: sta...@vger.kernel.org
Fixes:
The fix for XSA-423 introduced a bug which resulted in loss of network
connection in some configurations.
The first patch is fixing the issue, while the second one is removing
a test which isn't needed.
Juergen Gross (2):
xen/netback: don't do grant copy across page boundary
xen/netback:
flight 180026 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180026/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1bfc89414dbc2b4e620e06231ae98d714914fc46
baseline version:
ovmf
95 matches
Mail list logo
