flight 179869 xen-4.17-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179869/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 179843
test-amd64-i386-xl-qemut-win7-am
flight 179853 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179853/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 179834
test-amd64-i386-xl-qemuu-win7-amd64
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt-pair
testid guest-start/debian
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git:
flight 179852 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179852/
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
test-amd64-amd64-fr
From: Jan Beulich
[ Upstream commit 934ef33ee75c3846f605f18b65048acd147e3918 ]
A new platform-op was added to Xen to allow obtaining the same VGA
console information PV Dom0 is handed. Invoke the new function and have
the output data processed by xen_init_vga().
Signed-off-by: Jan Beulich
Revi
From: Jan Beulich
[ Upstream commit 934ef33ee75c3846f605f18b65048acd147e3918 ]
A new platform-op was added to Xen to allow obtaining the same VGA
console information PV Dom0 is handed. Invoke the new function and have
the output data processed by xen_init_vga().
Signed-off-by: Jan Beulich
Revi
From: Jan Beulich
[ Upstream commit 934ef33ee75c3846f605f18b65048acd147e3918 ]
A new platform-op was added to Xen to allow obtaining the same VGA
console information PV Dom0 is handed. Invoke the new function and have
the output data processed by xen_init_vga().
Signed-off-by: Jan Beulich
Revi
On Mon, Mar 20, 2023 at 03:16:31PM +0200, Andy Shevchenko wrote:
> ...
> -#define pci_bus_for_each_resource(bus, res, i)
> \
> - for (i = 0; \
> - (res = pci_bus_resource_n(bus, i)) || i < PCI_BRIDGE_RES
Hi Andy and Mika,
I really like the improvements here. They make the code read much
better.
On Mon, Mar 20, 2023 at 03:16:30PM +0200, Andy Shevchenko wrote:
> From: Mika Westerberg
> ...
> static void fixup_winbond_82c105(struct pci_dev* dev)
> {
> - int i;
> + struct resource *r;
>
On Wed, Mar 22, 2023 at 12:13 PM 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" (Pr
flight 179847 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179847/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 14 guest-start fail REGR. vs. 179518
test-amd64-amd64-
On Wed, Mar 22, 2023 at 08:32:48AM -0400, Jason Andryuk wrote:
> On Wed, Mar 22, 2023 at 3:35 AM Juergen Gross wrote:
> >
> > Rework the config parsing of a p9 device to use the
> > split_string_into_pair() function instead of open coding it.
> >
> > Signed-off-by: Juergen Gross
>
> Reviewed-by:
On Wed, Mar 22, 2023 at 08:29:51AM -0400, Jason Andryuk wrote:
> On Wed, Mar 22, 2023 at 3:35 AM Juergen Gross wrote:
> >
> > Today split_string_into_pair() will not really do what its name is
> > suggesting: instead of splitting a string into a pair of strings using
> > a delimiter, it will retur
On Wed, Mar 22, 2023 at 08:29:39AM +0100, Juergen Gross wrote:
> Instead of duplicating libxl__device_console_add() work in
> init-xenstore-domain.c, just use libxenlight.
>
> This requires to add a small wrapper function to libxenlight, as
> libxl__device_console_add() is an internal function.
>
On Wed, Mar 22, 2023 at 06:05:55PM +0100, Roger Pau Monné wrote:
> On Wed, Mar 22, 2023 at 04:14:54PM +0100, Jan Beulich wrote:
> > On 22.03.2023 15:30, Roger Pau Monne wrote:
> > > Changes since v2:
> > > - Slightly adjust VMSIX_ADDR_SAME_PAGE().
> > > - Use IS_ALIGNED and unlikely for the non-a
On Wed, Mar 22, 2023 at 04:14:54PM +0100, Jan Beulich wrote:
> On 22.03.2023 15:30, Roger Pau Monne wrote:
> > Changes since v2:
> > - Slightly adjust VMSIX_ADDR_SAME_PAGE().
> > - Use IS_ALIGNED and unlikely for the non-aligned access checking.
> > - Move the check for the page mapped before th
Hi Michal,
On 22/03/2023 10:29, 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 xfree(). This should be done instead on an error path
Hi,
On 22/03/2023 10:29, Michal Orzel wrote:
We are assigning return code of domain_vpl011_init() to a variable
without checking it for an error. Fix it.
Fixes: 3580c8b2dfc3 ("xen/arm: if direct-map domain use native UART address and IRQ
number for vPL011")
Signed-off-by: Michal Orzel
Acked
flight 179860 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179860/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4f441d024bee7e1a6438737b58e4b0b6856b3eab
baseline version:
ovmf 494127613b36e87025064
> On 22 Mar 2023, at 10:29, 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 xfree(). This should be done instead on an
> On 22 Mar 2023, at 10:29, Michal Orzel wrote:
>
> We are assigning return code of domain_vpl011_init() to a variable
> without checking it for an error. Fix it.
>
> Fixes: 3580c8b2dfc3 ("xen/arm: if direct-map domain use native UART address
> and IRQ number for vPL011")
> Signed-off-by: Mi
On 22.03.2023 15:59, Oleksii wrote:
> Then it looks like enabling of MMU should go first but in that case
> this not clear what to do with BUG(), WARN() etc as for them it is
> needed excpetion handling functionality and MMU related code uses the
> macros.
It's still possible to reconsider and do
On 22.03.2023 15:30, Roger Pau Monne wrote:
> Changes since v2:
> - Slightly adjust VMSIX_ADDR_SAME_PAGE().
> - Use IS_ALIGNED and unlikely for the non-aligned access checking.
> - Move the check for the page mapped before the aligned one.
> - Remove cast of data to uint8_t and instead use a ma
On 21.03.23 09:03, Jan Beulich wrote:
In the commit referenced below I failed to pay attention to this code
also being buildable as 32-bit. Adjust the type of "ret" - there's no
real need for it to be wider than 32 bits.
Fixes: 934ef33ee75c ("x86/PVH: obtain VGA console info in Dom0")
Reported-b
Hi Julien,
On 21/03/2023 18:56, Julien Grall wrote:
> Hi Andrei,
>
> I realized this has already been merged. But I would like to point out a
> few things for future series.
>
> On 13/03/2023 13:08, Andrei Cherechesu (OSS) wrote:
>> From: Andrei Cherechesu
>>
>> Moved implementation for the fun
On Wed, 2023-03-22 at 14:46 +0100, Jan Beulich wrote:
> On 22.03.2023 14:32, Oleksii wrote:
> > On Wed, 2023-03-22 at 13:26 +0100, Jan Beulich wrote:
> > > But as said before - I'm unconvinced this approach will scale,
> > > because
> > > you'll need to apply the wrapper to anything which can be re
On Wed, 2023-03-22 at 13:51 +, Julien Grall wrote:
> Hi Oleksii,
>
> On 22/03/2023 13:40, Oleksii wrote:
> > On Wed, 2023-03-22 at 12:14 +, Julien Grall wrote:
> > >
> > >
> > > On 22/03/2023 11:33, Oleksii wrote:
> > > > Hi Julien,
> > >
> > > Hi Oleksii,
> > >
> > > >
> > > > On Tue
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 tables is not currently
accessible, as the accesses are ju
On 22/03/2023 09:55, Oleksii wrote:
Hi Jullien,
Hi,
On Tue, 2023-03-21 at 17:58 +, Julien Grall wrote:
Hi,
I will try to not repeat the comment already made.
On 16/03/2023 16:43, Oleksii Kurochko wrote:
Mostly the code for setup_initial_pages was taken from Bobby's
repo except for
On 20.03.2023 16:28, Anthony PERARD wrote:
> This simple comment allows to detect when $(CC) changes version.
> Kconfig will be rerun in this case. (Rerun is forced by
> include/config/auto.conf.cmd which detects changes of CC_VERSION_TEXT
> value).
>
> Signed-off-by: Anthony PERARD
> ---
>
> Te
On 22.03.2023 14:51, Julien Grall wrote:
> I am a bit puzzled with what you wrote. From my understanding, with
> -noPIE, the compiler would be free to use absolute address rather than
> pc-relative one. Do you have any pointer to documentation that would
> back your reasoning?
It might for RV32
From: Peter Hoyes
Saving, restoring and migrating domains are not currently supported on
arm and arm64 platforms, so xendomains prints the warning:
An error occurred while saving domain:
command not implemented
when attempting to run `xendomains stop`. It otherwise continues to shut
down th
The size argument to ->sendmsg() ought to be redundant as the same
information should be conveyed by msg->msg_iter.count as returned by
msg_data_left().
Signed-off-by: David Howells
cc: Eric Dumazet
cc: "David S. Miller"
cc: Jakub Kicinski
cc: Paolo Abeni
cc: net...@vger.kernel.org
cc: appar.
Hi,
On 22/03/2023 08:19, Jan Beulich wrote:
On 21.03.2023 18:58, Julien Grall wrote:
Also, where do you guarantee that Xen will be loaded at a 2MB aligned
address? (For a fact I know that UEFI is only guarantee 4KB alignment).
I don't think this is true. We rely on UEFI honoring larger alignm
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, Jan Beulich wrote:
>> (Using "unsigned lo
Hi Oleksii,
On 22/03/2023 13:40, Oleksii wrote:
On Wed, 2023-03-22 at 12:14 +, Julien Grall wrote:
On 22/03/2023 11:33, Oleksii wrote:
Hi Julien,
Hi Oleksii,
On Tue, 2023-03-21 at 17:42 +, Julien Grall wrote:
Hi Oleksii,
On 16/03/2023 14:39, Oleksii Kurochko wrote:
Signed-off
On 22.03.2023 14:32, Oleksii wrote:
> On Wed, 2023-03-22 at 13:26 +0100, Jan Beulich wrote:
>> But as said before - I'm unconvinced this approach will scale,
>> because
>> you'll need to apply the wrapper to anything which can be reached
>> prior
>> to you enabling the MMU. Whether you can contain
On Wed, 2023-03-22 at 12:14 +, Julien Grall wrote:
>
>
> On 22/03/2023 11:33, Oleksii wrote:
> > Hi Julien,
>
> Hi Oleksii,
>
> >
> > On Tue, 2023-03-21 at 17:42 +, Julien Grall wrote:
> > > Hi Oleksii,
> > >
> > > On 16/03/2023 14:39, Oleksii Kurochko wrote:
> > > > Signed-off-by: Ol
On Wed, 2023-03-22 at 13:26 +0100, Jan Beulich wrote:
> On 22.03.2023 11:20, Oleksii wrote:
> > On Tue, 2023-03-21 at 17:33 +, Julien Grall wrote:
> > > On 16/03/2023 14:39, Oleksii Kurochko wrote:
> > > > --- a/xen/arch/riscv/traps.c
> > > > +++ b/xen/arch/riscv/traps.c
> > > > @@ -4,10 +4,95
Hi Jan,
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, Jan Beulich wrote:
(Using "unsigned long" for a 32-bit paddr_t is of
course suspicious as w
On Wed, 2023-03-22 at 11:27 +0100, Jan Beulich wrote:
> On 22.03.2023 11:09, Oleksii wrote:
> > On Tue, 2023-03-21 at 17:21 +, Julien Grall wrote:
> > > On 16/03/2023 14:39, Oleksii Kurochko wrote:
> > > > will be used in the patch "xen/riscv: introduce
> > > > decode_cause() stuff" and requir
On Tue, 2023-03-21 at 11:56 +, Andrew Cooper wrote:
> On 16/03/2023 2:39 pm, Oleksii Kurochko wrote:
> > The structure holds information about:
> > 1. linker start/end address
> > 2. load start/end address
> >
> > Also the patch introduces offsets for boot information structure
> > members to
On 22.03.23 13:38, Jan Beulich wrote:
On 22.03.2023 13:08, Juergen Gross wrote:
--- a/tools/tests/vpci/emul.h
+++ b/tools/tests/vpci/emul.h
@@ -106,22 +106,6 @@ typedef union {
#define BUG() assert(0)
#define ASSERT_UNREACHABLE() assert(0)
-#define min(x, y) ({\
-
On 22.03.2023 13:33, Huang Rui wrote:
> I traced that while we do pci-assignable-add, we will follow below trace to
> bind the passthrough device.
>
> pciassignable_add()->libxl_device_pci_assignable_add()->libxl__device_pci_assignable_add()->pciback_dev_assign()
>
> Then kernel xen-pciback drive
On 22.03.23 13:42, Jan Beulich wrote:
On 22.03.2023 13:08, Juergen Gross wrote:
util.h contains a definition of offsetof(), which isn't needed.
While true, this is also ambiguous in the context of this series: It isn't
"not needed" because common-macros.h has another definition, but it is
actu
On 22.03.23 13:34, Jan Beulich wrote:
On 22.03.2023 13:08, Juergen Gross wrote:
--- a/tools/include/xen-tools/common-macros.h
+++ b/tools/include/xen-tools/common-macros.h
@@ -76,4 +76,8 @@
#define __must_check __attribute__((__warn_unused_result__))
#endif
+#define container_of(ptr, type
On 22.03.2023 13:08, Juergen Gross wrote:
> util.h contains a definition of offsetof(), which isn't needed.
While true, this is also ambiguous in the context of this series: It isn't
"not needed" because common-macros.h has another definition, but it is
actually unused in hvmloader code. So perhap
On 22.03.2023 13:08, Juergen Gross wrote:
> --- a/tools/tests/vpci/emul.h
> +++ b/tools/tests/vpci/emul.h
> @@ -106,22 +106,6 @@ typedef union {
> #define BUG() assert(0)
> #define ASSERT_UNREACHABLE() assert(0)
>
> -#define min(x, y) ({\
> -const typeof(x) tx = (x);
On 22.03.2023 13:08, Juergen Gross wrote:
> --- a/tools/include/xen-tools/common-macros.h
> +++ b/tools/include/xen-tools/common-macros.h
> @@ -76,4 +76,8 @@
> #define __must_check __attribute__((__warn_unused_result__))
> #endif
>
> +#define container_of(ptr, type, member) ({\
On Wed, Mar 22, 2023 at 05:34:41PM +0800, Roger Pau Monné wrote:
> On Wed, Mar 22, 2023 at 03:28:58PM +0800, Huang Rui wrote:
> > On Tue, Mar 21, 2023 at 09:03:58PM +0800, Huang Rui wrote:
> > > On Tue, Mar 21, 2023 at 08:27:21PM +0800, Jan Beulich wrote:
> > > > On 21.03.2023 12:49, Huang Rui wrot
On Wed, Mar 22, 2023 at 3:35 AM Juergen Gross wrote:
>
> Rework the config parsing of a p9 device to use the
> split_string_into_pair() function instead of open coding it.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
On Wed, Mar 22, 2023 at 3:35 AM Juergen Gross wrote:
>
> Today split_string_into_pair() will not really do what its name is
> suggesting: instead of splitting a string into a pair of strings using
> a delimiter, it will return the first two strings of the initial string
> by using the delimiter.
>
On 22.03.2023 11:20, Oleksii wrote:
> On Tue, 2023-03-21 at 17:33 +, Julien Grall wrote:
>> On 16/03/2023 14:39, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/traps.c
>>> +++ b/xen/arch/riscv/traps.c
>>> @@ -4,10 +4,95 @@
>>> *
>>> * RISC-V Trap handlers
>>> */
>>> +
>>> +#include
flight 179867 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179867/
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 22/03/2023 11:33, Oleksii wrote:
Hi Julien,
Hi Oleksii,
On Tue, 2023-03-21 at 17:42 +, Julien Grall wrote:
Hi Oleksii,
On 16/03/2023 14:39, Oleksii Kurochko wrote:
Signed-off-by: Oleksii Kurochko
Reviewed-by: Alistair Francis
---
Changes in V5:
- Nothing changed
---
Change
xfs/fsys_xfs.c is defining offsetof privately. Remove that definition
and just use stddef.h instead.
Signed-off-by: Juergen Gross
---
V4:
- new patch
---
tools/libfsimage/xfs/fsys_xfs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/tools/libfsimage/xfs/fsys_xfs.c b/tools
vchan/init.c is defining offsetof privately. Remove that definition
and just use stddef.h instead.
Signed-off-by: Juergen Gross
---
V4:
- new patch
---
tools/libs/vchan/init.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/tools/libs/vchan/init.c b/tools/libs/vchan/init.
util.h contains a definition of offsetof(), which isn't needed.
Remove it.
Signed-off-by: Juergen Gross
---
V4:
- new patch
---
tools/firmware/hvmloader/util.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index e04990ee9
Defining min(), min_t(), max() and max_t() at other places than
xen-tools/common-macros.h isn't needed, as the definitions in said
header can be used instead.
Same applies to BUILD_BUG_ON() in hvmloader.
Signed-off-by: Juergen Gross
---
tools/firmware/hvmloader/util.h | 8 ++--
tools/libs/
Instead of having 4 identical copies of the definition of a
container_of() macro in different tools header files, add that macro
to xen-tools/common-macros.h and use that instead.
Delete the other copies of that macro.
Signed-off-by: Juergen Gross
---
There is a similar macro CONTAINER_OF() defi
There are some macros defined multiple times in tools. Use only
a single header file for defining those macros and drop the copies,
or use stddef.h for offsetof().
V2:
- add patch 1 (Andrew Cooper)
V3:
- address comments
V4:
- patch 1 of V3 already applied
- new patches 3-5
Juergen Gross (5):
Hi Julien,
On Tue, 2023-03-21 at 17:42 +, Julien Grall wrote:
> Hi Oleksii,
>
> On 16/03/2023 14:39, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
> > Reviewed-by: Alistair Francis
> > ---
> > Changes in V5:
> > - Nothing changed
> > ---
> > Changes in V4:
> > - Nothing
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 Capabilities) calls. These _PDC
methods must be eva
flight 179843 xen-4.17-testing real [real]
flight 179866 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/179843/
http://logs.test-lab.xenproject.org/osstest/logs/179866/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
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 headers-n anywhere, so zap them (by using $(sort ...)) right
where the fi
We are assigning return code of domain_vpl011_init() to a variable
without checking it for an error. Fix it.
Fixes: 3580c8b2dfc3 ("xen/arm: if direct-map domain use native UART address and
IRQ number for vPL011")
Signed-off-by: Michal Orzel
---
xen/arch/arm/domain_build.c | 4
1 file chang
This series contains two trivial fixes around domain_vpl011_init().
Michal Orzel (2):
xen/arm: domain_build: Check return code of domain_vpl011_init
xen/arm: vpl011: Fix domain_vpl011_init error path
xen/arch/arm/domain_build.c | 4
xen/arch/arm/vpl011.c | 11 +++
2 files
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 xfree(). This should be done instead on an error path
from vgic_reserve_virq(). Also, take the opportunity t
On 22.03.2023 11:09, Oleksii wrote:
> On Tue, 2023-03-21 at 17:21 +, Julien Grall wrote:
>> On 16/03/2023 14:39, Oleksii Kurochko wrote:
>>> will be used in the patch "xen/riscv: introduce
>>> decode_cause() stuff" and requires
>>>
>>> Signed-off-by: Oleksii Kurochko
>>> ---
>>> Changes in V
Hi Julien,
On Tue, 2023-03-21 at 17:33 +, Julien Grall wrote:
> Hi Oleksii,
>
> On 16/03/2023 14:39, Oleksii Kurochko wrote:
> > The patch introduces stuff needed to decode a reason of an
> > exception.
> >
> > Signed-off-by: Oleksii Kurochko
> > ---
> > Changes in V5:
> > - Remove from
On Wed, Mar 22, 2023 at 09:32:53AM +0100, Jan Beulich wrote:
> On 21.03.2023 18:33, Demi Marie Obenour wrote:
> > Obtaining code over an insecure transport is a terrible idea for
> > blatently obvious reasons. Even for non-executable data, insecure
> > transports are considered deprecated.
> >
>
On Tue, 2023-03-21 at 17:21 +, Julien Grall wrote:
> Hi Oleksii,
>
> On 16/03/2023 14:39, Oleksii Kurochko wrote:
> > will be used in the patch "xen/riscv: introduce
> > decode_cause() stuff" and requires
> >
> > Signed-off-by: Oleksii Kurochko
> > ---
> > Changes in V5:
> > * the patch
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 ha
Hi Jullien,
On Tue, 2023-03-21 at 17:58 +, Julien Grall wrote:
> Hi,
>
> I will try to not repeat the comment already made.
>
> On 16/03/2023 16:43, Oleksii Kurochko wrote:
> > Mostly the code for setup_initial_pages was taken from Bobby's
> > repo except for the following changes:
> > * Use
sh_update_paging_modes() as its last action already invokes
sh_update_cr3(). Therefore there is no reason to invoke update_cr3()
another time immediately after calling paging_update_paging_modes(),
the more that sh_update_cr3() does not short-circuit the "nothing
changed" case.
Signed-off-by: Jan
While 670d6b908ff2 ('x86 shadow: Move the shadow linear mapping for
n-on-3-on-4 shadows so') bumped the amount by one too little for the
32-on-64 case (which luckily was dead code, and hence a bump wasn't
necessary in the first place), 0b841314dace ('x86/shadow:
sh_{make,destroy}_monitor_table() ar
It looks like in the combination of aff8bf94ce65 ('x86/shadow: only
4-level guest code needs building when !HVM') and 0b841314dace
('x86/shadow: sh_{make,destroy}_monitor_table() are "even more" HVM-
only') I didn't go quite far enough: SH_type_monitor_table is also
effectively unused when !HVM.
T
With an initial mode installed by shadow_vcpu_init(), there's no need
for sh_update_paging_modes() to deal with the "mode is still unset"
case. Leave an assertion, though.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1864,6 +1864,8 @@
While benign at present, it is still a little fragile to operate on a
wrong "old_mode" value in sh_update_paging_modes(). This can happen when
no monitor table was present initially - we'd create one for the new
mode without updating old_mode. Correct this two ways, each of which
would be sufficien
Emulation related functions are involved in HVM handling only, and in
some cases they even invoke such checks after having already done things
which are valid for HVM domains only. OOS active also implies HVM. In
sh_remove_all_mappings() one of the two checks is redundant with an
earlier paging_mod
The code has been identified as HVM-only, and its main functions are
pretty well isolated. Move them to their own file. While moving, besides
making two functions non-static, do a few style adjustments, mainly
comment formatting, but leave the code otherwise untouched.
Signed-off-by: Jan Beulich
On Wed, Mar 22, 2023 at 03:28:58PM +0800, Huang Rui wrote:
> On Tue, Mar 21, 2023 at 09:03:58PM +0800, Huang Rui wrote:
> > On Tue, Mar 21, 2023 at 08:27:21PM +0800, Jan Beulich wrote:
> > > On 21.03.2023 12:49, Huang Rui wrote:
> > > > Thanks, but we found if dom0 is PV domain, the passthrough dev
XEN_DOMCTL_CDF_oos_off is forced set for PV domains, so the logic can't
ever be engaged for them. Conditionalize respective fields and remove
the respective bit from SHADOW_OPTIMIZATIONS when !HVM. As a result the
SH_type_oos_snapshot constant can disappear altogether in that case, and
a couple of
shadow_mode_...(), with the exception of shadow_mode_enabled(), are
shorthands for shadow_mode_enabled() && paging_mode_...(). While
potentially useful outside of shadow-internal functions, when we already
know that we're dealing with a domain in shadow mode, the "paging"
checks are sufficient and
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 Beulich
---
I find this and the respective Win7 related comment suspicious: If
These aren't mode dependent (see 06f04f54ba97 ["x86/shadow:
sh_{write,cmpxchg}_guest_entry() are PV-only"], where they were moved
out of multi.c) and hence there's no need to have pointers to the
functions in struct shadow_paging_mode. Due to include dependencies,
however, the "paging" wrappers nee
validate_guest_pt_write(), by calling sh_validate_guest_entry(), already
guarantees the needed update of log-dirty information. Move the
operation into the sole code path needing it (when SHOPT_SKIP_VERIFY is
enabled), making clear that only one such call is needed.
Signed-off-by: Jan Beulich
--
Ordinary scalar operations are used in a multitude of other places, so
do so here as well. In fact take the opportunity and drop a local
variable then as well, first and foremost to get rid of a bogus cast.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/sha
SHADOW_FOREACH_LE() already invokes the "body" only when the present
bit is set; no need to re-do the check.
While there also
- stop open-coding mfn_to_maddr() in code being touched (re-indented)
anyway,
- stop open-coding mfn_eq() in code being touched or adjacent code,
- drop local variables w
The "32b" and "pae" functions are identical at the source level (they
differ in what they get compiled to, due to differences in
SHADOW_FOREACH_L2E()), leaving aside a comment the PAE variant has and
the non-PAE one doesn't. Replace these infixes by the more usual l
ones (and then also for the "64b
While no caller currently invokes the function without first making sure
there is at least one shadow [1], we'd better eliminate UB here:
find_first_set_bit() requires input to be non-zero to return a well-
defined result.
Further, using find_first_set_bit() isn't very efficient in the first
place
This is kind of fallout from XSA-427 investigations, partly related to
there having been a more intrusive first approach. This is also the
reason why one of the patch has R-b already - that was a prereq for
the original approach.
Most patches aren't really dependent upon one another, so can probab
On Wed, 2023-03-22 at 09:12 +0100, Jan Beulich wrote:
> On 21.03.2023 18:08, Oleksii wrote:
> > On Mon, 2023-03-20 at 17:41 +0100, Jan Beulich wrote:
> > > On 16.03.2023 17:43, Oleksii Kurochko wrote:
> > > > +#define LEVEL_ORDER(lvl) (lvl * PAGETABLE_ORDER)
> > > > +#define LEVEL_SHIFT(
Hi Julien,
On Tue, 2023-03-21 at 16:25 +, Julien Grall wrote:
>
>
> On 05/03/2023 16:25, Oleksii wrote:
> > Hi Julien,
>
> Hi,
>
> Sorry for the late answer. I was away for the past couple of weeks.
>
> > On Mon, 2023-02-27 at 17:36 +, Julien Grall wrote:
> > > Hi Oleksii,
> > >
> >
On 21/03/2023 5:33 pm, Demi Marie Obenour wrote:
> Obtaining code over an insecure transport is a terrible idea for
> blatently obvious reasons. Even for non-executable data, insecure
> transports are considered deprecated.
>
> This patch enforces the use of secure transports in the build system.
> On 22 Mar 2023, at 07:02, Luca Fancellu wrote:
>
> I don’t understand, what entry is being overwritten? If I understood it
> correctly, I’m writing the position 10 of physinfo
> which is not written before.
>
> Cheers,
Sorry, I read this wrong. We are in #elif which I read as #ifdef in my
On 21/03/2023 5:33 pm, Demi Marie Obenour wrote:
> diff --git a/Config.mk b/Config.mk
> index
> 10eb443b17d85381b2d1e2282f8965c3e99767e0..75f1975e5e78af44d36c2372cba6e89b425267a5
> 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -215,19 +215,11 @@ ifneq (,$(QEMU_TAG))
> QEMU_TRADITIONAL_REVISION
On 21/03/2023 5:33 pm, Demi Marie Obenour wrote:
> Demi Marie Obenour (5):
> Use HTTPS for all xenbits.xen.org Git repos
> Change remaining xenbits.xen.org link to HTTPS
> Build system: Do not try to use broken links
> Build system: Replace git:// and http:// with https://
> Automation an
On 21.03.2023 18:33, Demi Marie Obenour wrote:
> Obtaining code over an insecure transport is a terrible idea for
> blatently obvious reasons. Even for non-executable data, insecure
> transports are considered deprecated.
>
> This patch enforces the use of secure transports for all xenbits.xen.or
On 21.03.2023 18:33, Demi Marie Obenour wrote:
> Obtaining code over an insecure transport is a terrible idea for
> blatently obvious reasons. Even for non-executable data, insecure
> transports are considered deprecated.
>
> This patch enforces the use of secure transports for all xenbits.xen.or
1 - 100 of 116 matches
Mail list logo
