On 08.02.2023 20:19, Demi Marie Obenour wrote:
> On Wed, Feb 08, 2023 at 08:26:37AM +, Julien Grall wrote:
>> On 08/02/2023 07:40, Jan Beulich wrote:
>>> On 08.02.2023 05:51, Demi Marie Obenour wrote:
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -11,
On 08.02.2023 18:07, Ayan Kumar Halder wrote:
> Hi Jan,
>
> On 08/02/2023 13:52, Jan Beulich wrote:
>> On 08.02.2023 13:05, Ayan Kumar Halder wrote:
>>> @@ -1166,8 +1166,9 @@ static const struct ns16550_config __initconst
>>> uart_config[] =
>>> static int __init
>>> pci_uart_config(struct ns
On 08.02.2023 16:51, Ayan Kumar Halder wrote:
> On 08/02/2023 13:33, Jan Beulich wrote:
>> On 08.02.2023 13:05, Ayan Kumar Halder wrote:
>>> In future, we wish to support 32 bit physical address.
>>> However, the current dt and fdt functions can only read u64 values.
>>> We wish to make the DT func
When running as Xen PV initial domain (aka dom0), MTRRs are disabled
by the hypervisor, but the system should nevertheless use correct
cache memory types. This has always kind of worked, as disabled MTRRs
resulted in disabled PAT, too, so that the kernel avoided code paths
resulting in inconsistenc
This series tries to fix the rather special case of PAT being available
without having MTRRs (either due to CONFIG_MTRR being not set, or
because the feature has been disabled e.g. by a hypervisor).
The main use cases are Xen PV guests and SEV-SNP guests running under
Hyper-V.
Instead of trying t
On 08-02-23, 17:36, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Update stub IOMMU driver (which main purpose is to reuse generic
> IOMMU device-tree bindings by Xen grant DMA-mapping layer on Arm)
> according to the recent changes done in the following
> commit 57365a04c921 ("iom
flight 176694 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176694/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f6ce1a5cd8932844ec24701d158254ccf75b6159
baseline version:
ovmf b59e6fdae2545b45c36c8
flight 176598 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176598/
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-amd64-libvirt 15 migrate-s
flight 176591 xen-unstable real [real]
flight 176689 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/176591/
http://logs.test-lab.xenproject.org/osstest/logs/176689/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Tue, Feb 7, 2023 at 10:49 PM Oleksii Kurochko
wrote:
>
> Because printk() relies on a serial driver (like the ns16550 driver)
> and drivers require working virtual memory (ioremap()) there is not
> print functionality early in Xen boot.
>
> The patch introduces the basic stuff of early_printk f
On Wed, Feb 8, 2023 at 12:47 AM Oleksii Kurochko
wrote:
>
> The patch introduces a set of registers which should be saved to and
> restored from a stack after an exception occurs and a set of defines
> which will be used during exception context saving/restoring.
>
> Originally header was introdu
On Wed, Feb 8, 2023 at 12:47 AM Oleksii Kurochko
wrote:
>
> Signed-off-by: Oleksii Kurochko
Acked-by: Alistair Francis
Alistair
> ---
> Changes in V3:
> - Nothing changed
> ---
> Changes in V2:
> - Nothing changed
> ---
> xen/arch/riscv/setup.c | 16
> 1 file changed, 16
On Wed, Feb 8, 2023 at 12:47 AM Oleksii Kurochko
wrote:
>
> The patch modifies the grep pattern to reflect the usage of WARN.
>
> Signed-off-by: Oleksii Kurochko
Reviewed-by: Alistair Francis
Alistair
> ---
> Changes in V3:
> - Update commit message
> ---
> Changes in V2:
> - Leave only the
On Wed, Feb 8, 2023 at 12:47 AM Oleksii Kurochko
wrote:
>
> The following changes were made in comparison with from
> Linux:
> * remove all defines as they are defined in riscv_encoding.h
> * leave only csr_* macros
>
> Origin: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.gi
On Wed, Feb 8, 2023 at 12:47 AM Oleksii Kurochko
wrote:
>
> Signed-off-by: Oleksii Kurochko
Reviewed-by: Alistair Francis
Alistair
> ---
> Changes in V3:
> - Nothing changed
> ---
> Changes in V2:
> - Nothing changed
> ---
> xen/arch/riscv/include/asm/asm.h | 54 +
flight 176670 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176670/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b59e6fdae2545b45c36c8c5373f4b858fb83c8cd
baseline version:
ovmf 5db84c85c3544b92fa236
On Wed, Feb 08, 2023 at 02:58:38PM -0800, Stefano Stabellini wrote:
> On Wed, 8 Feb 2023, 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, 7 Feb 2023, Oleksii Kurochko wrote:
> The patch modifies the grep pattern to reflect the usage of WARN.
>
> Signed-off-by: Oleksii Kurochko
Acked-by: Stefano Stabellini
> ---
> Changes in V3:
> - Update commit message
> ---
> Changes in V2:
> - Leave only the latest "grep ..."
> ---
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 changes miscellaneous links that are not used by any
automated tool. Some of these links are dead anyway.
Signed-of
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 automation and CI.
Signed-off-by: Demi Marie Obenour
---
README
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.
Signed-off-by: Demi Marie Obenour
---
Config.mk
Obtaining code over an insecure transport is a terrible idea for
blatently obvious reasons. Even for non-executable data, insecure
transports are considered deprecated.
Demi Marie Obenour (4):
Build system: Replace git:// and http:// with https://
Automation and CI: Replace git:// and http://
flight 176498 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176498/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 176434
test-amd64-amd64-xl-qemuu-win7-amd64
On Wed, Feb 08, 2023 at 08:26:37AM +, Julien Grall wrote:
> Hi,
>
> On 08/02/2023 07:40, Jan Beulich wrote:
> > On 08.02.2023 05:51, Demi Marie Obenour wrote:
> > > --- a/xen/drivers/passthrough/pci.c
> > > +++ b/xen/drivers/passthrough/pci.c
> > > @@ -11,7 +11,7 @@
> > >* more details.
>
On Wed, Feb 08, 2023 at 09:02:35AM +0100, Jan Beulich wrote:
> On 07.02.2023 19:02, Anthony PERARD wrote:
> >
> > I think the issue that Andrew saw in the CI with "libxlu_cfg_y.o"
> > failing to build while "libxlu_cfg_l.[ch]" are been regenerated is
> > probably because make doesn't consider "lib
Certain debug sections like ".debug_aranges" when built with GCC 11.2.1
are missing section symbols (presumably because they're not needed).
Instead, of segfaulting, simply don't include them if they're missing.
Signed-off-by: Ross Lagerwall
---
create-diff-object.c | 2 +-
1 file changed, 1 ins
> From: Xen-devel on behalf of Mihails
> Strasuns
> Sent: Thursday, January 19, 2023 10:13 AM
> To: xen-devel@lists.xenproject.org
> Cc: mstra...@amazon.com ; Michael Kurth
> Subject: [PATCH v1 1/4] common.h: Flush stdout before writing to stderr
>
> Flush existing debug messages before wri
The FILE symbols in out-of-tree builds may be either a relative path to
the object dir or an absolute path depending on how the build is
invoked. Fix the paths for C files so that they are consistent with
in-tree builds - the path is relative to the "xen" directory (e.g.
common/irq.c).
This fixes
Hi Jan,
On 08/02/2023 13:52, Jan Beulich wrote:
On 08.02.2023 13:05, Ayan Kumar Halder wrote:
@@ -1166,8 +1166,9 @@ static const struct ns16550_config __initconst
uart_config[] =
static int __init
pci_uart_config(struct ns16550 *uart, bool_t skip_amt, unsigned int idx)
{
-u64 orig_ba
flight 176460 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176460/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pairbroken
build-arm64-pvops 6 kernel-build
LDLIBS is usually only the library flags (that is the `-l` flags), as
proposed in GNU make manual, while LDFLAGS would be extra flags such
as `-L`.
Rework the make macro $(xenlibs-ldlibs, ) to only provide the library
flags. $(xenlibs-ldflags, ) already only provide the extra flags like
the -rpath
Hi Jan,
On 08/02/2023 13:33, Jan Beulich wrote:
On 08.02.2023 13:05, Ayan Kumar Halder wrote:
In future, we wish to support 32 bit physical address.
However, the current dt and fdt functions can only read u64 values.
We wish to make the DT functions read u64 as well u32 values (depending
on the
flight 176640 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176640/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
From: Oleksandr Tyshchenko
Update stub IOMMU driver (which main purpose is to reuse generic
IOMMU device-tree bindings by Xen grant DMA-mapping layer on Arm)
according to the recent changes done in the following
commit 57365a04c921 ("iommu: Move bus setup to IOMMU device registration").
With pro
On 08.02.23 16:10, Anthony PERARD wrote:
On Wed, Feb 08, 2023 at 08:48:33AM +0100, Juergen Gross wrote:
On 20.01.23 20:44, Anthony PERARD wrote:
LDLIBS is usually only the library flags (that is the `-l` flags), as
proposed in GNU make manual, while LDFLAGS would be extra flags such
as `-L`.
R
On Wed, Feb 08, 2023 at 08:48:33AM +0100, Juergen Gross wrote:
> On 20.01.23 20:44, Anthony PERARD wrote:
> > LDLIBS is usually only the library flags (that is the `-l` flags), as
> > proposed in GNU make manual, while LDFLAGS would be extra flags such
> > as `-L`.
> >
> > Rework the make macro $(
First of all move the almost loop-invariant condition out of the loop;
transform it into an altered loop boundary, noting that the updating of
_gl2p is relevant only at one use site, and then also only inside the
_code blob it provides. Then drop the shadow_mode_external() part of the
condition as
Just ahead of the logic in question we've translated the subject MFN to
a valid original GFN, in order to then translate that GFN back to an
MFN. Restricting the call to p2m_remove_page() to the case where these
two MFNs match is too weak. Instead refuse the operation altogether when
there's a mism
The "domain" in there has become meaningless; drop it.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1680,15 +1680,15 @@ bool shadow_hash_delete(struct domain *d
return true;
}
-typedef int (*hash_domai
The domain based variant is easily usable by shadow_audit_tables(); all
that's needed is conversion of the callback functions.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v3: Re-base.
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1680,59 +1680,11 @@
Rather than doing a separate hash walk (and then even using the vCPU
variant, which is to go away), do the up-pointer-clearing right in
sh_unpin(), as an alternative to the (now further limited) enlisting on
a "free floating" list fragment. This utilizes the fact that such list
fragments are traver
... or so I hope. The main observation was that we still have both
hash_vcpu_for_each() and hash_domain_for_each(), where the latter was
introduced in 2014/15 to replace the former. Only some eight years
later we can now complete this conversion. Everything else addresses
other things noticed along
>Hello together,
>im trying to write C code to monitor the CPU usage in and memory allocation in
>a very short time (in microsecond / if possible also nano second). For this I
>need to use the functions provided by the following libraries, libxl.h /
>xenstore.h or the libraries provided by xen
On 08.02.2023 13:00, Oleksii wrote:
> On Tue, 2023-02-07 at 16:07 +0100, Jan Beulich wrote:
>> On 07.02.2023 15:46, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/include/asm/bug.h
>>> @@ -0,0 +1,38 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * Copyright (C) 201
On 02/02/2023 11:36, Michal Orzel wrote:
Hi Julien,
Hi,
On 02/02/2023 12:23, Julien Grall wrote:
On 02/02/2023 11:12, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 02/02/2023 12:01, Julien Grall wrote:
Hi Michal,
On 02/02/2023 08:49, Michal Orzel wrote:
@@ -265,11 +284,14 @@ s
On 08.02.2023 13:05, Ayan Kumar Halder wrote:
> @@ -1166,8 +1166,9 @@ static const struct ns16550_config __initconst
> uart_config[] =
> static int __init
> pci_uart_config(struct ns16550 *uart, bool_t skip_amt, unsigned int idx)
> {
> -u64 orig_base = uart->io_base;
> +paddr_t orig_bas
Hi,
On 08/02/2023 12:00, Oleksii wrote:
On Tue, 2023-02-07 at 16:07 +0100, Jan Beulich wrote:
On 07.02.2023 15:46, Oleksii Kurochko wrote:
--- /dev/null
+++ b/xen/arch/riscv/include/asm/bug.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2012 Regents of the Uni
On 08.02.2023 13:05, Ayan Kumar Halder wrote:
> In future, we wish to support 32 bit physical address.
> However, the current dt and fdt functions can only read u64 values.
> We wish to make the DT functions read u64 as well u32 values (depending
> on the width of physical address). Also, we wish t
In the subsequent patch, we introduce "CONFIG_ARM_PA_32" to support
32 bit physical addresses. Thus, the code specific to
"Large Physical Address Extension" (ie LPAE) should be enclosed within
"ifndef CONFIG_ARM_PA_32".
Refer xen/arch/arm/include/asm/short-desc.h, "short_desc_l1_supersec_t"
unsign
Some Arm based hardware platforms which does not support LPAE
(eg Cortex-R52), uses 32 bit physical addresses.
Also, users may choose to use 32 bits to represent physical addresses
for optimization.
To support the above use cases, we have introduced arch independent
configs to choose if the physic
VTCR.T0SZ should be set as 0x20 to support 32bit IPA.
Refer ARM DDI 0487I.a ID081822, G8-9824, G8.2.171, VTCR,
"Virtualization Translation Control Register" for the bit descriptions.
Signed-off-by: Ayan Kumar Halder
Acked-by: Stefano Stabellini
---
Changes from -
v1 - New patch.
v2 - 1. Added
When 32 bit physical addresses are used (ie ARM_PA_32=y),
"va >> ZEROETH_SHIFT" causes an overflow.
Also, there is no zeroeth level page table on Arm 32-bit.
Also took the opportunity to clean up dump_pt_walk(). One could use
DECLARE_OFFSETS() macro instead of declaring the declaring an array
of p
Refer ARM IHI 0062D.c ID070116 (SMMU 2.0 spec), 17-360, 17.3.9,
SMMU_CBn_TTBR0 is a 64 bit register. Thus, one can use
writeq_relaxed_non_atomic() to write to it instead of invoking
writel_relaxed() twice for lower half and upper half of the register.
This also helps us as p2maddr is 'paddr_t' (wh
In an earlier commit (7c1de0038895), "ns16550.io_size" was u32 and
"io_size" was u64. Thus, the ASSERT() was needed to check if the values
are the same.
However, in a later commit (c9f8e0aee507), "ns16550.io_size" was changed
to u64. Thus, the ASSERT() became redundant.
So, now as "io_size" and "u
io_base and io_size represent physical addresses. So they should use
paddr_t (instead of u64).
However in future, paddr_t may be defined as u32. So when typecasting
values from u64 to paddr_t, one should always check for any possible
truncation. If any truncation is discovered, Xen needs to raise
dt_device_get_address() can accept u64 only for address and size.
However, the address/size denotes physical addresses. Thus, they should
be represented by 'paddr_t'.
Consequently, we introduce a wrapper for dt_device_get_address() ie
dt_device_get_paddr() which accepts address/size as paddr_t and
In future, we wish to support 32 bit physical address.
However, the current dt and fdt functions can only read u64 values.
We wish to make the DT functions read u64 as well u32 values (depending
on the width of physical address). Also, we wish to detect if any
truncation has occurred (ie while read
Hi All,
Please have a look at
https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg01465.html
for the context.
The benefits of using 32 bit physical addresses are as follows :-
1. It helps to use Xen on platforms (for eg R52) which supports 32 bit
physical addresses and has no suppor
Hello Jan,
Thanks for the comments!
On Tue, 2023-02-07 at 16:07 +0100, Jan Beulich wrote:
> On 07.02.2023 15:46, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/bug.h
> > @@ -0,0 +1,38 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (C) 2012
flight 176458 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176458/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 175454
test-amd64-amd64-xl-qemut-win7-a
flight 176618 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176618/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 176459 xen-4.17-testing real [real]
flight 176621 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/176459/
http://logs.test-lab.xenproject.org/osstest/logs/176621/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
On 2/8/23 10:38, Julien Grall wrote:
On 07/02/2023 13:59, Xenia Ragiadakou wrote:
Hi Julien,
Hi Xenia,
On 2/7/23 15:01, Julien Grall wrote:
Hi,
On 07/02/2023 12:46, Xenia Ragiadakou wrote:
On 2/7/23 14:25, Julien Grall wrote:
On 07/02/2023 10:46, Xenia Ragiadakou wrote:
On 2/7/2
> On 8 Feb 2023, at 04:51, 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.
>
> Demi Marie Obenour (4):
> Build system: Replace git://
On 07/02/2023 13:59, Xenia Ragiadakou wrote:
Hi Julien,
Hi Xenia,
On 2/7/23 15:01, Julien Grall wrote:
Hi,
On 07/02/2023 12:46, Xenia Ragiadakou wrote:
On 2/7/23 14:25, Julien Grall wrote:
On 07/02/2023 10:46, Xenia Ragiadakou wrote:
On 2/7/23 12:39, Julien Grall wrote:
Hi,
On 0
Hi,
On 08/02/2023 07:40, Jan Beulich wrote:
On 08.02.2023 05:51, Demi Marie Obenour wrote:
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -11,7 +11,7 @@
* more details.
*
* You should have received a copy of the GNU General Public License along
with
- * thi
On 07.02.2023 19:02, Anthony PERARD wrote:
> On Tue, Feb 07, 2023 at 06:03:12PM +0100, Jan Beulich wrote:
>> On 07.02.2023 17:09, Anthony PERARD wrote:
>>> Both are already mandatory to build the hypervisor.
>>
>> I'm not sure this is sufficient as a justification. From all we can
>> tell even pret
67 matches
Mail list logo
