flight 180051 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180051/
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
180046 pass in 180051
flight 180060 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180060/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e3e88d90e8d777e38120c32c7b3bbfb9bcf99b79
baseline version:
ovmf
On 2023-03-16 02:14:18 +, Andrew Cooper wrote:
> Ok, so there is a lot here. Apologies in advance for the overly long
> answer.
>
> First, while altp2m was developed in parallel with EPTP-switching, we
> took care to split the vendor neutral parts from the vendor specific
> bits. So while we
flight 180049 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180049/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pair25 guest-start/debian fail REGR. vs. 178042
flight 180058 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180058/
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
Hi,
Sorry for the late reply.
On 17/03/2023 11:01, Matias Ezequiel Vara Larsen wrote:
On Thu, Feb 23, 2023 at 08:31:29PM +, Julien Grall wrote:
+#define rmb() asm volatile("lfence":::"memory")
This is rmb(), but rmb() isn't what you want.
You want smp_rmb(), which is
#define
Hi,
On 24/03/2023 09:35, Luca Fancellu wrote:
On 23 Mar 2023, at 13:56, Michal Orzel wrote:
When vgic_reserve_virq() fails and backend is in domain, we should also
free the allocated event channel.
When backend is in Xen and call to xzalloc() returns NULL, there is no
need to call
Hi Juergen,
On 28/03/2023 15:43, Juergen Gross wrote:
Today when finalizing a transaction the number of node quota is checked
to not being exceeded after the transaction. This check is always done,
even if the transaction is being performed by a privileged connection,
or if there were no nodes
Looking at this diff, I'm wondering whether keeping
union {
struct cpu_policy *cpuid;
struct cpu_policy *cpu_policy;
};
permentantly might be a good idea, because d->arch.cpuid->$X reads rather
better than d->arch.cpu_policy->$X
Thoughts?
Signed-off-by: Andrew Cooper
tl;dr to add MSR_ARCH_CAPS features sensibly, cpu_{featureset<->policy}() need
to not operate on objects of differing lifetimes, so structs
{cpuid,msr}_policy need merging and cpu_policy is the obvious name.
But this does mean that we now have
cpu_policy->basic.$X
cpu_policy->feat.$Y
With all the complicated callers of x86_cpu_policies_are_compatible() updated
to use a single cpu_policy object, we can drop the final user of struct
old_cpu_policy.
Update x86_cpu_policies_are_compatible() to take (new) cpu_policy pointers,
reducing the amount of internal pointer chasing, and
Also merge lib/x86/cpuid.h entirely into lib/x86/cpu-policy.h
Use a temporary define to make struct cpuid_policy still work.
There's one forward declaration of struct cpuid_policy in
tools/tests/x86_emulator/x86-emulate.h that isn't covered by the define, and
it's easier to rename that now than
Right now, they're the same underlying type, containing disjoint information.
Use a single object instead. Also take the opportunity to rename 'entries' to
'msrs' which is more descriptive, and more in line with nr_msrs being the
count of MSR entries in the API.
test-tsx uses xg_private.h to
As with the cpuid side, use a temporary define to make struct msr_policy still
work.
Note, this means that domains now have two separate struct cpu_policy
allocations with disjoint information, and system policies are in a similar
position. Both will be deduplicated in the following patches.
These weren't great names to begin with, and using {leaves,msrs} matches up
better with the existing nr_{leaves,msr} parameters anyway.
Furthermore,by renaming these fields we can get away with using some #define
trickary to avoid the struct {cpuid,msr}_policy merge needing to happen in a
single
Right now, they're the same underlying type, containing disjoint information.
Drop the d->arch.msr pointer, and union d->arch.cpuid to give it a second name
of cpu_policy in the interim.
Merge init_domain_{cpuid,msr}_policy() into a single init_domain_cpu_policy(),
moving the implementation into
Right now, they're the same underlying type, containing disjoint information.
Introduce a new cpu-policy.{h,c} to be the new location for all policy
handling logic. Place the combined objects in __ro_after_init, which has
appeared since the original logic was written.
As we're trying to phase
We want to merge struct cpuid_policy and struct msr_policy together, and the
result wants to be called struct cpu_policy.
The current struct cpu_policy, being a pair of pointers, isn't terribly
useful. Rename the type to struct old_cpu_policy, but it will disappear
entirely once the merge is
flight 180047 qemu-mainline real [real]
flight 180056 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180047/
http://logs.test-lab.xenproject.org/osstest/logs/180056/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 180055 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180055/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f92a9dce10281c103b04d6b38283e0ff1d677b91
baseline version:
ovmf
flight 180048 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180048/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass
test-amd64-i386-libvirt 15
flight 180054 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180054/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6f415f8af48d0ba3e5d4719062a62cbfc3577227
baseline version:
ovmf
On Mon, Dec 05, 2022 at 04:10:28PM +0100, Jan Beulich wrote:
> On 23.11.2022 16:45, Roger Pau Monne wrote:
> > @@ -265,6 +266,15 @@ __efi64_mb2_start:
> > cmpl$MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%rcx)
> > je .Lrun_bs
> >
> > +/*
> > + * Get command
flight 180052 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180052/
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
flight 180053 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180053/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b697a31a8db5f23ed1030f0fea1b56c107ca85a3
baseline version:
ovmf
On Mon, Feb 27, 2023 at 12:48:03PM +0100, Simon Gaiser wrote:
> Hi,
>
> I have been looking into using S0ix with Xen. On systems with with 11th
> gen (Tiger Lake) Intel mobile CPUs or newer this is often the only
> supported suspend method, thus we want to support it in Qubes OS.
>
> Below a
Hi Jan,
On 21/03/2023 14:16, Jan Beulich wrote:
On 21.03.2023 15:03, Ayan Kumar Halder wrote:
@@ -1163,10 +1163,16 @@ static const struct ns16550_config __initconst
uart_config[] =
},
};
+#define PARSE_ERR_RET(_f, _a...) \
+do {
> On 29 Mar 2023, at 13:24, Jan Beulich wrote:
>
> On 29.03.2023 14:06, Luca Fancellu wrote:
@@ -61,7 +62,12 @@ custom_param("dom0_mem", parse_dom0_mem);
int __init parse_arch_dom0_param(const char *str_begin, const char
*str_end)
{
-return -1;
+int
On 29.03.2023 16:20, Roger Pau Monné wrote:
> On Wed, Mar 29, 2023 at 03:22:34PM +0200, Jan Beulich wrote:
>> On 29.03.2023 12:18, Roger Pau Monne wrote:
>>> @@ -419,9 +424,8 @@ static int adjacent_write(const struct domain *d, const
>>> struct vpci_msix *msix,
>>> * assumed to be equal or
On Wed, Mar 29, 2023 at 03:22:34PM +0200, Jan Beulich wrote:
> On 29.03.2023 12:18, Roger Pau Monne wrote:
> > @@ -419,9 +424,8 @@ static int adjacent_write(const struct domain *d, const
> > struct vpci_msix *msix,
> > * assumed to be equal or bigger (8 bytes) than the length of any
> >
On Tue, Mar 28, 2023 at 04:48:10PM +0200, Jan Beulich wrote:
> On 28.03.2023 16:19, Roger Pau Monné wrote:
> > On Wed, Jun 15, 2022 at 11:57:54AM +0200, Jan Beulich wrote:
> >> ... of the huge monolithic source file. The series is largely code
> >> movement and hence has the intention of not
On 29.03.2023 15:27, Marek Marczykowski-Górecki wrote:
> On Wed, Mar 29, 2023 at 02:39:22PM +0200, Jan Beulich wrote:
>> On 29.03.2023 12:51, Marek Marczykowski-Górecki wrote:
>>> On Wed, Mar 29, 2023 at 10:50:20AM +0200, Jan Beulich wrote:
Taking both remarks together, limiting granularity
On Wed, Mar 29, 2023 at 02:39:22PM +0200, Jan Beulich wrote:
> On 29.03.2023 12:51, Marek Marczykowski-Górecki wrote:
> > On Wed, Mar 29, 2023 at 10:50:20AM +0200, Jan Beulich wrote:
> >> On 27.03.2023 12:09, Marek Marczykowski-Górecki wrote:
> >>> In some cases, only few registers on a page needs
On 29.03.2023 12:18, Roger Pau Monne wrote:
> @@ -419,9 +424,8 @@ static int adjacent_write(const struct domain *d, const
> struct vpci_msix *msix,
> * assumed to be equal or bigger (8 bytes) than the length of any access
> * handled here.
> */
> -if (
On 29.03.2023 12:18, Roger Pau Monne wrote:
> Accesses to the PBA array have the same length and alignment
> limitations as accesses to the MSI-X table:
>
> "For all accesses to MSI-X Table and MSI-X PBA fields, software must
> use aligned full DWORD or aligned full QWORD transactions; otherwise,
On 29.03.2023 12:51, Marek Marczykowski-Górecki wrote:
> On Wed, Mar 29, 2023 at 10:50:20AM +0200, Jan Beulich wrote:
>> On 27.03.2023 12:09, Marek Marczykowski-Górecki wrote:
>>> In some cases, only few registers on a page needs to be write-protected.
>>> Examples include USB3 console (64 bytes
On 29.03.2023 14:06, Luca Fancellu wrote:
>>> @@ -61,7 +62,12 @@ custom_param("dom0_mem", parse_dom0_mem);
>>>
>>> int __init parse_arch_dom0_param(const char *str_begin, const char *str_end)
>>> {
>>> -return -1;
>>> +int rc = 0;
>>> +
>>> +if ( sve_parse_dom0_param(str_begin,
On 29.03.2023 13:47, Oleksii wrote:
> On Tue, 2023-03-28 at 16:44 +0100, Julien Grall wrote:
>> On 28/03/2023 16:34, Jan Beulich wrote:
>>> On 27.03.2023 19:17, Oleksii Kurochko wrote:
--- a/xen/arch/riscv/include/asm/config.h
+++ b/xen/arch/riscv/include/asm/config.h
@@ -39,12
flight 180046 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180046/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 180040
test-amd64-i386-xl-qemuu-win7-amd64
>
>> @@ -61,7 +62,12 @@ custom_param("dom0_mem", parse_dom0_mem);
>>
>> int __init parse_arch_dom0_param(const char *str_begin, const char *str_end)
>> {
>> -return -1;
>> +int rc = 0;
>> +
>> +if ( sve_parse_dom0_param(str_begin, str_end) < 0 )
>> +rc = -EINVAL;
>
> ...
On 29.03.2023 13:43, Oleksii wrote:
> On Tue, 2023-03-28 at 17:34 +0200, Jan Beulich wrote:
>> On 27.03.2023 19:17, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/mm.c
>>> @@ -0,0 +1,277 @@
>>> +#include
>>> +#include
>>> +
>>> +#include
>>> +#include
>>> +#include
>>>
On 29.03.2023 12:48, Roger Pau Monné wrote:
> On Wed, Mar 29, 2023 at 11:55:26AM +0200, Jan Beulich wrote:
>> On 16.03.2023 17:16, Roger Pau Monné wrote:
>>> On Tue, Mar 14, 2023 at 08:56:29PM +, Volodymyr Babchuk wrote:
Prior to this change, lifetime of pci_dev objects was protected by
On 29.03.2023 13:48, Luca Fancellu wrote:
>> On 28 Mar 2023, at 11:08, Jan Beulich wrote:
>> On 27.03.2023 12:59, Luca Fancellu wrote:
>>> @@ -838,6 +838,18 @@ Controls for how dom0 is constructed on x86 systems.
>>>
>>> If using this option is necessary to fix an issue, please report a bug.
> On 28 Mar 2023, at 11:08, Jan Beulich wrote:
>
> On 27.03.2023 12:59, Luca Fancellu wrote:
>> @@ -838,6 +838,18 @@ Controls for how dom0 is constructed on x86 systems.
>>
>> If using this option is necessary to fix an issue, please report a bug.
>>
>> +Enables features on dom0 on Arm
Hi Julien,
On Tue, 2023-03-28 at 16:44 +0100, Julien Grall wrote:
> Hi,
>
> On 28/03/2023 16:34, Jan Beulich wrote:
> > On 27.03.2023 19:17, Oleksii Kurochko wrote:
> > > --- a/xen/arch/riscv/include/asm/config.h
> > > +++ b/xen/arch/riscv/include/asm/config.h
> > > @@ -39,12 +39,25 @@
> > >
flight 180050 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180050/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e3aba976f6d588abd88027fef46999a1d3724576
baseline version:
ovmf
On Tue, 2023-03-28 at 17:34 +0200, Jan Beulich wrote:
> On 27.03.2023 19:17, Oleksii Kurochko wrote:
> > --- a/xen/arch/riscv/include/asm/config.h
> > +++ b/xen/arch/riscv/include/asm/config.h
> > @@ -39,12 +39,25 @@
> > name:
> > #endif
> >
> > -#define XEN_VIRT_START _AT(UL, 0x8020)
>
On 29.03.2023 12:50, Oleksii Kurochko wrote:
> A large part of the content of the bug.h is repeated among all
> architectures, so it was decided to create a new config
> CONFIG_GENERIC_BUG_FRAME.
>
> The version of from x86 was taken as the base version.
>
> The patch introduces the following
On Wed, Mar 29, 2023 at 10:50:20AM +0200, Jan Beulich wrote:
> On 27.03.2023 12:09, Marek Marczykowski-Górecki wrote:
> > 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
A large part of the content of the bug.h is repeated among all
architectures, so it was decided to create a new config
CONFIG_GENERIC_BUG_FRAME.
The version of from x86 was taken as the base version.
The patch introduces the following stuff:
* common bug.h header
* generic implementation of
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 do_bug_frame()
* Define BUG_DEBUGGER_TRAP_FATAL to debugger_trap_fatal(X86_EXC_GP,regs)
* type of eip variable was changed to 'const
The idea of the patch is to change all to and
keep Xen compilable with adding only minimal amount of changes:
1. It was added "#include " to ARM's "" as it
uses uint_{16,32}t in 'struct bug_frame'.
2. It was added '#define BUG_FRAME_STRUCT' which means that ARM hasn't
been switched to
The following changes were made:
* make GENERIC_BUG_FRAME mandatory for ARM
* As do_bug_frame() returns -EINVAL in case something goes wrong
otherwise id of bug frame. Thereby 'if' cases where do_bug_frame() was
updated to check if the returned value is less than 0
* Switch ARM's
The following defines BUG_DISP_WIDTH, BUG_LINE_LO_WIDTH,
BUG_LINE_HI_WIDTH aren't used in ARM so could be purged
as unused.
Requested-by: Jan Beulich
Signed-off-by: Oleksii Kurochko
Reviewed-by: Jan Beulich
---
Changes in V9:
* Nothing changed
---
Changes in V8:
* Update the commit message
A large part of the content of the bug.h is repeated among all
architectures (especially x86 and RISCV have the same implementation), so it
was created a new config CONFIG_GENERIC_BUG_FRAME which is used to
introduce generic implementation of do_bug_frame() and move x86's
to with the following
On Wed, Mar 29, 2023 at 11:55:26AM +0200, Jan Beulich wrote:
> On 16.03.2023 17:16, Roger Pau Monné wrote:
> > On Tue, Mar 14, 2023 at 08:56:29PM +, Volodymyr Babchuk wrote:
> >> Prior to this change, lifetime of pci_dev objects was protected by global
> >> pcidevs_lock(). Long-term plan is to
> On 29 Mar 2023, at 11:32, Jan Beulich wrote:
>
> On 29.03.2023 12:01, Luca Fancellu wrote:
>>> On 28 Mar 2023, at 10:36, Jan Beulich wrote:
>>> Yet another question is whether both range checks (against
>>> SVE_VL_MAX_BITS and zcr_max_bits) are actually necessary / useful.
>>> Iirc 2048 is
On 29.03.2023 12:01, Luca Fancellu wrote:
>> On 28 Mar 2023, at 10:36, Jan Beulich wrote:
>> Yet another question is whether both range checks (against
>> SVE_VL_MAX_BITS and zcr_max_bits) are actually necessary / useful.
>> Iirc 2048 is a hard upper bound, so zcr_max_bits being higher than
>>
On 29.03.2023 12:21, Marek Marczykowski-Górecki wrote:
> Making subpage_mmio_ro_add() to call mmio_ro_ranges() on its own,
> together with Roger's suggestion of using ioremap() internally instead
> of using fixmap would make it a bit nicer (if mapping the same page with
> ioremap() in addition to
This symlink is getting in the way of using e.g. "find" on the xen/
subtree, and it isn't really needed when not building out-of-tree:
The one use that there was can easily be avoided.
Signed-off-by: Jan Beulich
--- a/.gitignore
+++ b/.gitignore
@@ -295,7 +295,6 @@ xen/include/xen/acm_policy.h
I don't view a variable of this name as suitable for exporting, the more
that it carries entirely redundant information. The reasons for its
introduction in Linux commit 051f278e9d81 ("kbuild: replace
KBUILD_SRCTREE with boolean building_out_of_srctree") also don't apply
to us. Ditch exporting of
Accesses to the PBA array have the same length and alignment
limitations as accesses to the MSI-X table:
"For all accesses to MSI-X Table and MSI-X PBA fields, software must
use aligned full DWORD or aligned full QWORD transactions; otherwise,
the result is undefined."
Introduce such length and
On Wed, Mar 29, 2023 at 11:14:52AM +0200, Jan Beulich wrote:
> On 27.03.2023 12:09, Marek Marczykowski-Górecki wrote:
> > ... 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.
The 1st patch is new, addressing comments on the previously standalone
(and unchanged) 2nd patch in a way different from what was discussed.
1: don't export building_out_of_srctree
2: omit "source" symlink when building hypervisor in-tree
Jan
On 14.03.2023 21:56, Volodymyr Babchuk wrote:
> @@ -422,33 +423,6 @@ static struct pci_dev *alloc_pdev(struct pci_seg *pseg,
> u8 bus, u8 devfn)
> return pdev;
> }
>
> -static void free_pdev(struct pci_seg *pseg, struct pci_dev *pdev)
> -{
> -/* update bus2bridge */
> -switch (
Hi Jan,
Thank you for your review, very appreciated,
> On 28 Mar 2023, at 10:36, Jan Beulich wrote:
>
> On 27.03.2023 12:59, Luca Fancellu wrote:
>> @@ -43,8 +44,16 @@ register_t compute_max_zcr(void)
>> }
>>
>> /* Takes a vector length in bits and returns the ZCR_ELx encoding */
>>
On 16.03.2023 17:16, Roger Pau Monné wrote:
> On Tue, Mar 14, 2023 at 08:56:29PM +, Volodymyr Babchuk wrote:
>> Prior to this change, lifetime of pci_dev objects was protected by global
>> pcidevs_lock(). Long-term plan is to remove this log, so we need some
>
On 17.03.2023 09:43, Roger Pau Monné wrote:
> On Tue, Mar 14, 2023 at 08:56:30PM +, Volodymyr Babchuk wrote:
>> vPCI MMIO handlers are accessing pdevs without protecting this
>> access with pcidevs_{lock|unlock}. This is not a problem as of now
>> as these are only used by Dom0. But, towards
On 29.03.2023 11:13, George Dunlap wrote:
> On Tue, Mar 28, 2023 at 4:58 PM Jan Beulich wrote:
>
>> On 28.03.2023 17:07, Andrew Cooper wrote:
>>> On 28/03/2023 2:51 pm, Jan Beulich wrote:
On 27.03.2023 21:41, Andrew Cooper wrote:
> It is not valid to retain a bootstrap_map() across
On 27.03.2023 12:09, Marek Marczykowski-Górecki wrote:
> ... 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,
On Tue, Mar 28, 2023 at 4:58 PM Jan Beulich wrote:
> On 28.03.2023 17:07, Andrew Cooper wrote:
> > On 28/03/2023 2:51 pm, Jan Beulich wrote:
> >> On 27.03.2023 21:41, Andrew Cooper wrote:
> >>> It is not valid to retain a bootstrap_map() across returning back to
> >>> __start_xen(), but various
On 29.03.2023 10:02, Juergen Gross wrote:
> Issue the same error message in case an illegal page boundary crossing
> has been detected in both cases where this is tested.
>
> Suggested-by: Jan Beulich
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
On 29.03.2023 10:14, Roger Pau Monné wrote:
> On Wed, Mar 29, 2023 at 09:55:27AM +0200, Jan Beulich wrote:
>> On 24.03.2023 13:17, Roger Pau Monne wrote:
>>> The handling of the MSI-X table accesses by Xen requires that any
>>> pages part of the MSI-X related tables are not mapped into the domain
On 27.03.2023 12:09, Marek Marczykowski-Górecki wrote:
> 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).
Yet like the MSI-X table the
> On 24 Mar 2023, at 20:25, Andrew Cooper wrote:
>
> Strings in Ocaml carry their own length. Absolutely nothing good can come
> from having caml_string_length(data) be different to len.
>
> Use the appropriate accessor, String_val(), but retain the workaround for the
> Ocaml -safe-string
flight 180045 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180045/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pair25 guest-start/debian fail REGR. vs. 178042
On Wed, Mar 29, 2023 at 09:55:27AM +0200, Jan Beulich wrote:
> On 24.03.2023 13:17, Roger Pau Monne wrote:
> > The handling of the MSI-X table accesses by Xen requires that any
> > pages part of the MSI-X related tables are not mapped into the domain
> > physmap. As a result, any device registers
Issue the same error message in case an illegal page boundary crossing
has been detected in both cases where this is tested.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
---
V2:
- new patch
V3:
- modify message text (Jan Beulich)
---
drivers/net/xen-netback/netback.c | 6 ++
1
On 24.03.2023 13:17, Roger Pau Monne wrote:
> The handling of the MSI-X table accesses by Xen requires that any
> pages part of the MSI-X related tables are not mapped into the domain
> physmap. As a result, any device registers in the same pages as the
> start or the end of the MSIX or PBA
On 28.03.2023 17:07, Andrew Cooper wrote:
> On 28/03/2023 2:51 pm, Jan Beulich wrote:
>> On 27.03.2023 21:41, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpu/microcode/core.c
>>> +++ b/xen/arch/x86/cpu/microcode/core.c
>>> @@ -755,47 +755,51 @@ int microcode_update_one(void)
>>> return
On 29.03.2023 09:19, Andrew Cooper wrote:
> On 29/03/2023 7:50 am, Jan Beulich wrote:
>> First of all these were inverted: "bridge=" caused the port coordinates
>> to be established, while "port=" controlled the bridge coordinates. And
>> then the error messages being identical also wasn't
On 28.03.2023 18:07, Andrew Cooper wrote:
> On 28/03/2023 5:01 pm, Jan Beulich wrote:
>> On 28.03.2023 17:12, Andrew Cooper wrote:
>>> On 28/03/2023 3:19 pm, Jan Beulich wrote:
On 27.03.2023 21:41, Andrew Cooper wrote:
> Right now, the boot flow depends on the second pass over
>
On 29/03/2023 7:50 am, Jan Beulich wrote:
> First of all these were inverted: "bridge=" caused the port coordinates
> to be established, while "port=" controlled the bridge coordinates. And
> then the error messages being identical also wasn't helpful. While
> correcting this also move both case
On 28.03.2023 18:55, Oleksii wrote:
> On Tue, 2023-03-28 at 19:38 +0300, Oleksii wrote:
>> On Tue, 2023-03-28 at 18:38 +0300, Oleksii wrote:
>>> offsets.s arch/x86/x86_64/asm-offsets.c
>>> In file included from ./include/public/domctl.h:21,
>>> from ./include/public/sysctl.h:18,
On 29.03.23 09:20, Juergen Gross wrote:
Hello Juergen
> On 28.03.23 17:47, Oleksandr Tyshchenko wrote:
>>
>>
>> On 28.03.23 11:46, Juergen Gross wrote:
>>
>> Hello Juergen
>>
>>> scsiback_free_translation_entry() shouldn't be called under spinlock,
>>> as it can sleep.
>>>
>>> This requires
First of all these were inverted: "bridge=" caused the port coordinates
to be established, while "port=" controlled the bridge coordinates. And
then the error messages being identical also wasn't helpful. While
correcting this also move both case blocks close together.
Fixes: 97fd49a7e074
At 12:37 +0200 on 28 Mar (1680007032), Jan Beulich wrote:
> On 27.03.2023 17:39, Tim Deegan wrote:
> > 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
On 28.03.23 15:32, Jan Beulich wrote:
On 28.03.2023 15:12, Juergen Gross wrote:
Issue the same error message in case an illegal page boundary crossing
has been detected in both cases where this is tested.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
On 28.03.23 17:47, Oleksandr Tyshchenko wrote:
On 28.03.23 11:46, Juergen Gross wrote:
Hello Juergen
scsiback_free_translation_entry() shouldn't be called under spinlock,
as it can sleep.
This requires to split removing a translation entry from the v2p list
from actually calling kref_put()
89 matches
Mail list logo
