Currently, the grant mapping related device tree properties are added if
the backend domain is not Dom0. While Dom0 is privileged and can do
foreign mapping for the entire guest memory, it is still desired for
Dom0 to access guest's memory via grant mappings and hence map only what
is required.
Fields that generic_identify() sets unconditionally don't need pre-
setting. (In fact the compiler removes some of those assignments anyway,
at least in release builds.)
With the setting of ->cpuid_level to -1 gone, also drop the respective
BUG_ON() from default_init().
Signed-off-by: Jan
On Mon, Jun 12, 2023 at 05:10:28PM -0700, Rick Edgecombe wrote:
> The x86 Shadow stack feature includes a new type of memory called shadow
> stack. This shadow stack memory has some unusual properties, which requires
> some core mm changes to function properly.
>
> One of these unusual properties
On 13/06/2023 7:40 am, Jan Beulich wrote:
> On 12.06.2023 20:25, Andrew Cooper wrote:
>> On 12/06/2023 4:46 pm, Jan Beulich wrote:
>>> On 05.06.2023 19:08, Alejandro Vallejo wrote:
@@ -878,5 +887,17 @@ int __init early_microcode_init(unsigned long
*module_map,
if (
On 12.06.2023 22:21, Daniel P. Smith wrote:
>
>
> On 6/12/23 15:44, Daniel P. Smith wrote:
>> On 6/12/23 07:46, Jan Beulich wrote:
>>> The variable needs to be properly set only on the error paths.
>>>
>>> Coverity ID: 1532311
>>> Fixes: ab4440112bec ("xl / libxl: push parsing of SSID and CPU
On Wed, Jun 7, 2023 at 5:55 AM Oleksii Kurochko
wrote:
>
> Signed-off-by: Oleksii Kurochko
Acked-by: Alistair Francis
Alistair
> ---
> xen/arch/riscv/include/asm/page.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/xen/arch/riscv/include/asm/page.h
>
On 05.06.2023 19:08, Alejandro Vallejo wrote:
> --- a/xen/arch/x86/cpu/microcode/core.c
> +++ b/xen/arch/x86/cpu/microcode/core.c
> @@ -749,11 +749,12 @@ __initcall(microcode_init);
> /* Load a cached update to current cpu */
> int microcode_update_one(void)
> {
> +if (
On 13/06/2023 7:12 am, Jan Beulich wrote:
> Fields that generic_identify() sets unconditionally don't need pre-
> setting. (In fact the compiler removes some of those assignments anyway,
> at least in release builds.)
>
> With the setting of ->cpuid_level to -1 gone, also drop the respective
>
On 13.06.2023 09:42, Nicola Vetrini wrote:
> The xen sources contain several violations of Rule 3.1 from MISRA C:2012,
> whose headline states:
> "The character sequences '/*' and '//' shall not be used within a comment".
>
> Most of the violations are due to the presence of links to webpages
flight 181397 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181397/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 4
On 12.06.2023 18:13, Andrew Cooper wrote:
> @@ -593,15 +596,93 @@ static bool __init retpoline_calculations(void)
> return false;
>
> /*
> - * RSBA may be set by a hypervisor to indicate that we may move to a
> - * processor which isn't retpoline-safe.
> + * The meaning
On 13.06.2023 11:21, Daniel P. Smith wrote:
> On 6/13/23 02:33, Jan Beulich wrote:
>> On 12.06.2023 22:21, Daniel P. Smith wrote:
>>> On 6/12/23 15:44, Daniel P. Smith wrote:
On 6/12/23 07:46, Jan Beulich wrote:
> If XSM is disabled, is it really useful to issue the 2nd and 3rd calls
On 12.06.2023 21:28, Andrew Cooper wrote:
> FB_CLEAR is a read-only status bit, not a read-write control. Move it from
> "Hardware features" into "Hardware hints".
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
Hi,
On 13/06/2023 09:27, Jan Beulich wrote:
On 13.06.2023 09:42, Nicola Vetrini wrote:
The xen sources contain several violations of Rule 3.1 from MISRA C:2012,
whose headline states:
"The character sequences '/*' and '//' shall not be used within a comment".
Most of the violations are due to
On 6/13/23 05:40, Jan Beulich wrote:
On 13.06.2023 11:21, Daniel P. Smith wrote:
On 6/13/23 02:33, Jan Beulich wrote:
On 12.06.2023 22:21, Daniel P. Smith wrote:
On 6/12/23 15:44, Daniel P. Smith wrote:
On 6/12/23 07:46, Jan Beulich wrote:
If XSM is disabled, is it really useful to issue
On 12.06.23 22:09, Demi Marie Obenour wrote:
On Mon, Jun 12, 2023 at 08:27:59AM +0200, Juergen Gross wrote:
On 10.06.23 17:32, Demi Marie Obenour wrote:
When a grant entry is still in use by the remote domain, Linux must put
it on a deferred list.
This lacks quite some context.
The main
On 12.06.2023 18:13, Andrew Cooper wrote:
> Reword the comment for 'S' to include an incompatbile set of features on the
> same core.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On Mon, Jun 12, 2023 at 11:05 PM Vishal Moola (Oracle)
wrote:
> As part of the conversions to replace pgtable constructor/destructors with
> ptdesc equivalents, convert various page table functions to use ptdescs.
>
> Some of the functions use the *get*page*() helper functions. Convert
> these to
flight 181400 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181400/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 530f5b0912c1c3837337baeec66eb7b0a90d9969
baseline version:
ovmf
On 12.06.2023 18:10, nicola.vetr...@bugseng.com wrote:
> From: Nicola Vetrini
>
> The xen sources contain several violations of Rule 3.1 from MISRA C:2012,
> whose headline states:
> "The character sequences '/*' and '//' shall not be used within a comment".
>
> Most of the violations are due
On 13.06.2023 05:44, Stefano Stabellini wrote:
> @@ -133,6 +146,13 @@ existing codebase are work-in-progress.
> headers (xen/include/public/) are allowed to retain longer
> identifiers for backward compatibility.
>
> + * - `Rule 6.1
>
On 12.06.2023 20:25, Andrew Cooper wrote:
> On 12/06/2023 4:46 pm, Jan Beulich wrote:
>> On 05.06.2023 19:08, Alejandro Vallejo wrote:
>>> @@ -878,5 +887,17 @@ int __init early_microcode_init(unsigned long
>>> *module_map,
>>> if ( ucode_mod.mod_end || ucode_blob.size )
>>> rc =
On 13/06/23 10:27, Jan Beulich wrote:
On 13.06.2023 09:42, Nicola Vetrini wrote:
--- a/xen/common/xmalloc_tlsf.c
+++ b/xen/common/xmalloc_tlsf.c
@@ -140,9 +140,10 @@ static inline void MAPPING_SEARCH(unsigned long *r, int
*fl, int *sl)
*fl = flsl(*r) - 1;
*sl = (*r >>
flight 181399 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181399/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 4
On 6/13/23 02:33, Jan Beulich wrote:
On 12.06.2023 22:21, Daniel P. Smith wrote:
On 6/12/23 15:44, Daniel P. Smith wrote:
On 6/12/23 07:46, Jan Beulich wrote:
The variable needs to be properly set only on the error paths.
Coverity ID: 1532311
Fixes: ab4440112bec ("xl / libxl: push
flight 181398 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181398/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf
On 6/13/23 06:15, Jan Beulich wrote:
On 13.06.2023 11:57, Daniel P. Smith wrote:
On 6/13/23 05:40, Jan Beulich wrote:
On 13.06.2023 11:21, Daniel P. Smith wrote:
On 6/13/23 02:33, Jan Beulich wrote:
On 12.06.2023 22:21, Daniel P. Smith wrote:
On 6/12/23 15:44, Daniel P. Smith wrote:
On
On Mon, Jun 05, 2023 at 12:36:57PM +0200, Roger Pau Monne wrote:
> The current implementation in libxl_cpuid_parse_config() requires
> keeping a list of cpuid feature bits that should be mostly in sync
> with the contents of cpufeatureset.h.
>
> Avoid such duplication by using the automatically
From: Rasmus Villemoes
> Sent: 12 June 2023 12:08
>
> On 10/06/2023 22.40, Demi Marie Obenour wrote:
> > Passing spaces before e.g. an integer is usually
> > not intended.
>
> Maybe, maybe not. But it's mandated by POSIX/C99.
>
> And of course we are free to ignore that and implement our own
On Tue, Jun 13, 2023 at 12:23:37PM +0200, Jan Beulich wrote:
> On 13.06.2023 12:13, Roger Pau Monne wrote:
> > Do not rely on iommu local variable pointing to a valid amd_iommu
>
> "Do not rely" sounds like we might, but we choose not to. But we may
> not rely on this, as the pointer simply isn't
On 13.06.23 02:10, Rick Edgecombe wrote:
The x86 Shadow stack feature includes a new type of memory called shadow
stack. This shadow stack memory has some unusual properties, which requires
some core mm changes to function properly.
One of these unusual properties is that shadow stack memory is
On 13.06.2023 12:33, Roger Pau Monné wrote:
> On Tue, Jun 13, 2023 at 12:23:37PM +0200, Jan Beulich wrote:
>> On 13.06.2023 12:13, Roger Pau Monne wrote:
>>> Do not rely on iommu local variable pointing to a valid amd_iommu
>>
>> "Do not rely" sounds like we might, but we choose not to. But we may
On Mon, Jun 12, 2023 at 07:54:00PM +0100, Andrew Cooper wrote:
> On 05/06/2023 6:08 pm, Alejandro Vallejo wrote:
> > diff --git a/xen/arch/x86/cpu/microcode/core.c
> > b/xen/arch/x86/cpu/microcode/core.c
> > index 4f60d96d98..a4c123118b 100644
> > --- a/xen/arch/x86/cpu/microcode/core.c
> > +++
flight 181402 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181402/
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
On Mon Jun 12, 2023 at 10:03 AM CDT, Jan Beulich wrote:
> On 12.06.2023 16:51, Shawn Anastasio wrote:
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -460,6 +460,10 @@ X: xen/arch/x86/acpi/lib.c
> > F: xen/drivers/cpufreq/
> > F: xen/include/acpi/cpufreq/
> >
> > +PPC64
> > +M: Shawn
flight 181404 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181404/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 51bb8eb76c4e8c57d5484c647ecf0b5c5fa8fa94
baseline version:
ovmf
On 2023-06-10 04:57, Demi Marie Obenour wrote:
It is not used anywhere but its own unit tests.
Signed-off-by: Demi Marie Obenour
---
Documentation/dev-tools/checkpatch.rst | 9 -
Documentation/process/deprecated.rst | 5 ++---
On Mon, Jun 12, 2023 at 05:46:07PM +0200, Jan Beulich wrote:
> See early_cpu_init().
Ah, I missed that. I didn't expect several leafs to be read at once.
I see now that that function takes care of
> (I have to admit that I was also struggling with
> your use of "read": Aiui you mean the field
On Tue, Jun 13, 2023 at 11:32:16AM +0530, Viresh Kumar wrote:
> Currently, the grant mapping related device tree properties are added if
> the backend domain is not Dom0. While Dom0 is privileged and can do
> foreign mapping for the entire guest memory, it is still desired for
> Dom0 to access
Commit 438c5ffa44e99cceb574c0f9946aacacdedd2952 ("rpmball: Adjust to
new rpm, do not require --force") attempted to handle stricter
directory permissions in newer distributions.
This introduced a few issues:
- /boot used to be a constant prior commit
6475d700055fa952f7671cee982a23de2f5e4a7c
On 12.06.2023 18:13, Andrew Cooper wrote:
> The RSBA bit, "RSB Alternative", means that the RSB may use alternative
> predictors when empty. From a practical point of view, this mean "Retpoline
> not safe".
>
> Enhanced IBRS (officially IBRS_ALL in Intel's docs, previously IBRS_ATT) is a
>
Do not rely on iommu local variable pointing to a valid amd_iommu
element after the call to for_each_amd_iommu(). Instead check whether
any IOMMU on the system doesn't support Invalidate All in order to
perform the per-domain and per-device flushes.
Fixes: 9c46139de889 ('amd iommu: Support
On Mon, Jun 12, 2023 at 06:31:13PM +0100, Andrew Cooper wrote:
> On 12/06/2023 4:16 pm, Jan Beulich wrote:
> > There are many places where we make such connections / assumptions without
> > long comments. I'd be okay with a brief one, but I'm not convinced we need
> > one at all.
>
> I agree. I
On Tue, Jun 13, 2023 at 11:44:51AM +0100, Anthony PERARD wrote:
> On Mon, Jun 05, 2023 at 12:36:57PM +0200, Roger Pau Monne wrote:
> > The current implementation in libxl_cpuid_parse_config() requires
> > keeping a list of cpuid feature bits that should be mostly in sync
> > with the contents of
On Tue, Jun 13, 2023 at 12:55:13PM +0200, Olaf Hering wrote:
> Commit 438c5ffa44e99cceb574c0f9946aacacdedd2952 ("rpmball: Adjust to
> new rpm, do not require --force") attempted to handle stricter
> directory permissions in newer distributions.
>
> This introduced a few issues:
> - /boot used to
From: Oleksandr Andrushchenko
When a PCI device gets assigned/de-assigned some work on vPCI side needs
to be done for that device. Introduce a pair of hooks so vPCI can handle
that.
Signed-off-by: Oleksandr Andrushchenko
---
Since v6:
- do not pass struct domain to
From: Oleksandr Andrushchenko
Introduce a per-domain read/write lock to check whether vpci is present,
so we are sure there are no accesses to the contents of the vpci struct
if not. This lock can be used (and in a few cases is used right away)
so that vpci removal can be performed while holding
From: Oleksandr Andrushchenko
Instead of handling a single range set, that contains all the memory
regions of all the BARs and ROM, have them per BAR.
As the range sets are now created when a PCI device is added and destroyed
when it is removed so make them named and accounted.
Note that
From: Oleksandr Andrushchenko
There are three originators for the PCI configuration space access:
1. The domain that owns physical host bridge: MMIO handlers are
there so we can update vPCI register handlers with the values
written by the hardware domain, e.g. physical view of the registers
vs
From: Oleksandr Andrushchenko
Assign SBDF to the PCI devices being passed through with bus 0.
The resulting topology is where PCIe devices reside on the bus 0 of the
root complex itself (embedded endpoints).
This implementation is limited to 32 devices which are allowed on
a single PCI bus.
From: Oleksandr Andrushchenko
At the moment, we always allocate an extra 16 slots for IO handlers
(see MAX_IO_HANDLER). So while adding IO trap handlers for the emulated
MSI-X registers we need to explicitly tell that we have additional IO
handlers, so those are accounted.
Signed-off-by:
From: Oleksandr Andrushchenko
A guest would be able to read and write those registers which are not
emulated and have no respective vPCI handlers, so it will be possible
for it to access the hardware directly.
In order to prevent a guest from reads and writes from/to the unhandled
registers make
From: Oleksandr Andrushchenko
Add relevant vpci register handlers when assigning PCI device to a domain
and remove those when de-assigning. This allows having different
handlers for different domains, e.g. hwdom and other guests.
Emulate guest BAR register values: this allows creating a guest
From: Oleksandr Andrushchenko
Xen and/or Dom0 may have put values in PCI_COMMAND which they expect
to remain unaltered. PCI_COMMAND_SERR bit is a good example: while the
guest's view of this will want to be zero initially, the host having set
it to 1 may not easily be overwritten with 0, or else
From: Oleksandr Andrushchenko
Take into account guest's BAR view and program its p2m accordingly:
gfn is guest's view of the BAR and mfn is the physical BAR value as set
up by the PCI bus driver in the hardware domain.
This way hardware domain sees physical BAR values and guest sees
emulated
Hello,
This is another another version of vPCI rework (previous one can be
found at [1]). The biggest change is how vPCI locking is done. This
series uses per-domain vPCI rwlock.
Note that this series does not include my work on reference counting
for PCI devices because this counting does not
From: Oleksandr Andrushchenko
There are range sets which should not be printed, so introduce a flag
which allows marking those as such. Implement relevant logic to skip
such entries while printing.
While at it also simplify the definition of the flags by directly
defining those without helpers.
From: Oleksandr Andrushchenko
Reset the command register when assigning a PCI device to a guest:
according to the PCI spec the PCI_COMMAND register is typically all 0's
after reset, but this might not be true for the guest as it needs
to respect host's settings.
For that reason, do not write 0
On Tue, Jun 13, 2023 at 01:01:47PM +0200, Roger Pau Monné wrote:
> On Tue, Jun 13, 2023 at 11:44:51AM +0100, Anthony PERARD wrote:
> > On Mon, Jun 05, 2023 at 12:36:57PM +0200, Roger Pau Monne wrote:
> > > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> > > index
First of all - please don't drop Cc-s when replying, unless you have a
specific reason to.
On 13.06.2023 11:56, nicola wrote:
> On 13/06/23 10:27, Jan Beulich wrote:
>> If you split this to 4 patches, leaving the URL proposal in just
>> the cover letter, then I think this one change (with the
On 13.06.2023 11:57, Daniel P. Smith wrote:
> On 6/13/23 05:40, Jan Beulich wrote:
>> On 13.06.2023 11:21, Daniel P. Smith wrote:
>>> On 6/13/23 02:33, Jan Beulich wrote:
On 12.06.2023 22:21, Daniel P. Smith wrote:
> On 6/12/23 15:44, Daniel P. Smith wrote:
>> On 6/12/23 07:46, Jan
On 13.06.2023 12:13, Roger Pau Monne wrote:
> Do not rely on iommu local variable pointing to a valid amd_iommu
"Do not rely" sounds like we might, but we choose not to. But we may
not rely on this, as the pointer simply isn't valid to deref past
the loop. Hence perhaps better "We cannot rely
On 13/06/23 19:45, Andrew Cooper wrote:
On 13/06/2023 6:39 pm, Julien Grall wrote:
Hi,
On 13/06/2023 17:22, Andrew Cooper wrote:
These are disliked specifically by MISRA, but they also interfere
with code
Please explicitly name the rule.
I can't remember it off the top of my head.
flight 181409 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181409/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 180691
build-arm64
flight 181408 seabios real [real]
flight 181411 seabios real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181408/
http://logs.test-lab.xenproject.org/osstest/logs/181411/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
flight 181406 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181406/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale broken
test-armhf-armhf-xl-vhd
On Mon Jun 12, 2023 at 10:19 AM CDT, George Dunlap wrote:
> Shawn,
>
> Again sorry that you've sort of bumped a hornet's nest here.
>
> Just to clarify, the situation as I understand it is:
Hi George,
No problem, and thank you for the detailed explanation.
> HOWEVER, as Andrew says, there is no
flight 181403 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181403/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 180691
build-arm64-xsm
On 13.06.23 18:19, Edgecombe, Rick P wrote:
On Tue, 2023-06-13 at 10:44 +0300, Mike Rapoport wrote:
Previous patches have done the first step, so next move the callers
that
don't have a VMA to pte_mkwrite_novma(). Also do the same for
I hear x86 maintainers asking to drop "previous patches"
On 13/06/2023 18:32, Julien Grall wrote:
On 13/06/2023 17:52, Andrew Cooper wrote:
This is disliked specifically by MISRA, but it also interferes with code
legibility by hiding control flow. Expand and drop it. >
* Drop redundant "rc = rc" assignment
* Rework gnttab_copy_buf() to be
Add the build system changes required to build for ppc64le (POWER8+).
As of now the resulting image simply boots to an infinite loop.
$ make XEN_TARGET_ARCH=ppc64 -C xen openpower_defconfig
$ make XEN_TARGET_ARCH=ppc64 SUBSYSTEMS=xen -C xen build
This port targets POWER8+ CPUs running in Little
Add a container for cross-compiling xen for ppc64le.
Signed-off-by: Shawn Anastasio
---
.../build/debian/bullseye-ppc64le.dockerfile | 28 +++
automation/scripts/containerize | 1 +
2 files changed, 29 insertions(+)
create mode 100644
Hello all,
This patch series adds support for building a minimal image
(head.o-only) for Power ISA 2.07B+ (POWER8+) systems. The first patch
boots to an infinite loop and the second adds early serial console
support on pseries VMs, with bare metal support planned next.
Since Xen previously had
Signed-off-by: Shawn Anastasio
---
MAINTAINERS | 4
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1bb7a6a839..25139fe4a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -460,6 +460,10 @@ X: xen/arch/x86/acpi/lib.c
F: xen/drivers/cpufreq/
F:
Add build jobs to cross-compile Xen for ppc64le.
Signed-off-by: Shawn Anastasio
---
automation/gitlab-ci/build.yaml | 60 +
1 file changed, 60 insertions(+)
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index
flight 181405 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181405/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 180278
build-arm64-pvops
On Mon, 2023-06-12 at 09:09 +0200, Jan Beulich wrote:
> On 06.06.2023 21:55, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
>
> Such commits without description are worrying. This may be okay for
> entirely trivial and obvious changes, but that's going to be the
> exception.
>
> >
On 13/06/2023 6:39 pm, Julien Grall wrote:
> Hi,
>
> On 13/06/2023 17:22, Andrew Cooper wrote:
>> These are disliked specifically by MISRA, but they also interfere
>> with code
>
> Please explicitly name the rule.
I can't remember it off the top of my head.
Stefano/Bertrand?
>
>> legibility by
On Mon, Jun 12, 2023 at 08:47:41AM -0400, Jason Andryuk wrote:
> On Mon, Jun 12, 2023 at 7:45 AM Jan Beulich wrote:
> >
> > The variable isn't used past the loop, and its value also isn't
> > meaningful across iterations. Reduce its scope to make this more
> > obvious.
> >
> > Coverity ID:
On Mon, Jun 12, 2023 at 01:47:50PM +0200, Jan Beulich wrote:
> "t" is written first thing at the "retry_transaction" label.
>
> Coverity ID: 1532321
> Fixes: 1057300109ea ("libxl: fix error handling (xenstore transaction leak)
> in libxl__domain_make")
> Signed-off-by: Jan Beulich
Acked-by:
On Tue, 2023-06-13 at 14:27 +0200, David Hildenbrand wrote:
> Acked-by: David Hildenbrand
Thanks!
On Tue, 2023-06-13 at 10:44 +0300, Mike Rapoport wrote:
> > Previous patches have done the first step, so next move the callers
> > that
> > don't have a VMA to pte_mkwrite_novma(). Also do the same for
>
> I hear x86 maintainers asking to drop "previous patches" ;-)
>
> Maybe
> This is the
On Tue, Jun 13, 2023 at 06:08:16PM +0200, Jan Beulich wrote:
> On 13.06.2023 18:03, Anthony PERARD wrote:
> > On Mon, Jun 12, 2023 at 01:46:40PM +0200, Jan Beulich wrote:
> >> The function returns immediately after the enclosing if().
> >>
> >> Coverity ID: 1532314
> >> Fixes: bd7a29c3d0b9
flight 181401 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181401/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf
On Tue, Jun 13, 2023 at 08:45:31AM +0200, Juergen Gross wrote:
> On 12.06.23 22:09, Demi Marie Obenour wrote:
> > On Mon, Jun 12, 2023 at 08:27:59AM +0200, Juergen Gross wrote:
> > > On 10.06.23 17:32, Demi Marie Obenour wrote:
> > > > When a grant entry is still in use by the remote domain, Linux
These are disliked specifically by MISRA, but they also interfere with code
legibility by hiding control flow. Expand and drop them.
* Rearrange the order of actions to write into rc, then render rc in the
gdprintk().
* Drop redundant "rc = rc" assignments
* Switch to using %pd for
Hi,
On 13/06/2023 17:22, Andrew Cooper wrote:
These are disliked specifically by MISRA, but they also interfere with code
Please explicitly name the rule.
legibility by hiding control flow. Expand and drop them.
* Rearrange the order of actions to write into rc, then render rc in the
On Mon, 2023-06-12 at 09:15 +0200, Jan Beulich wrote:
> On 06.06.2023 21:55, Oleksii Kurochko wrote:
> > The function was introduced to not calculate and save physical
> > offset before MMU is enabled because access to start() is
> > PC-relative and in case of linker_addr != load_addr it will
On Mon, Jun 12, 2023 at 01:46:19PM +0200, Jan Beulich wrote:
> The variable needs to be properly set only on the error paths.
>
> Coverity ID: 1532311
> Fixes: ab4440112bec ("xl / libxl: push parsing of SSID and CPU pool ID down
> to libxl")
> Signed-off-by: Jan Beulich
Acked-by: Anthony
On 13.06.2023 18:03, Anthony PERARD wrote:
> On Mon, Jun 12, 2023 at 01:46:40PM +0200, Jan Beulich wrote:
>> The function returns immediately after the enclosing if().
>>
>> Coverity ID: 1532314
>> Fixes: bd7a29c3d0b9 ("tools/libs/ctrl: fix xc_core_arch_map_p2m() to support
>> linear p2m table")
On Mon, Jun 12, 2023 at 01:47:13PM +0200, Jan Beulich wrote:
> "rc" is written immediately below the outer if(). Fold the remaining two
> if()s.
>
> Coverity ID: 1532320
> Fixes: 685e922d6f30 ("tools/libxc: Rework xc_cpuid_apply_policy() to use
> {get,set}_cpu_policy()")
> Signed-off-by: Jan
flight 181407 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181407/
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,
On 13/06/2023 17:52, Andrew Cooper wrote:
This is disliked specifically by MISRA, but it also interferes with code
legibility by hiding control flow. Expand and drop it. >
* Drop redundant "rc = rc" assignment
* Rework gnttab_copy_buf() to be simpler by dropping the rc variable
No
On Mon, Jun 12, 2023 at 01:46:40PM +0200, Jan Beulich wrote:
> The function returns immediately after the enclosing if().
>
> Coverity ID: 1532314
> Fixes: bd7a29c3d0b9 ("tools/libs/ctrl: fix xc_core_arch_map_p2m() to support
> linear p2m table")
> Signed-off-by: Jan Beulich
>
> ---
On Tue, Jun 13, 2023 at 08:57:06AM +0200, Jan Beulich wrote:
> On 05.06.2023 19:08, Alejandro Vallejo wrote:
> > --- a/xen/arch/x86/cpu/microcode/core.c
> > +++ b/xen/arch/x86/cpu/microcode/core.c
> > @@ -749,11 +749,12 @@ __initcall(microcode_init);
> > /* Load a cached update to current cpu */
This is disliked specifically by MISRA, but it also interferes with code
legibility by hiding control flow. Expand and drop it.
* Drop redundant "rc = rc" assignment
* Rework gnttab_copy_buf() to be simpler by dropping the rc variable
No functional change.
Signed-off-by: Andrew Cooper
---
On Mon, 2023-06-12 at 09:04 +0200, Jan Beulich wrote:
> On 06.06.2023 21:55, Oleksii Kurochko wrote:
> > Sometimes variables are located in .sbss section but it won't
> > be mapped after MMU will be enabled.
> > To avoid MMU failures .sbss should be mapped
> >
> > Signed-off-by: Oleksii Kurochko
On Mon, 2023-06-12 at 09:12 +0200, Jan Beulich wrote:
> On 06.06.2023 21:55, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
>
> This wants addressing the "Why?" aspect in the description. Is the
> present
> code wrong in some perhaps subtle way? Are you meaning to re-use the
> code?
flight 181410 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181410/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 180278
build-arm64-pvops
flight 181413 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181413/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 180681
test-amd64-i386-xl-qemuu-win7-amd64 19
1 - 100 of 102 matches
Mail list logo
