On 01.07.2021 16:09, Anthony PERARD wrote:
> This avoid the need to create the symbolic link "include/asm".
>
> Signed-off-by: Anthony PERARD
> ---
>
> Other possible locations that I could think of:
> include/arch/*/asm
> arch/*/include/asm
I thought it was always the plan to follow Linux (and
On 01.07.2021 16:09, Anthony PERARD wrote:
> Avoid depending on Makefile but still allow to rebuild the banner when
> $(XEN_FULLVERSION) changes.
>
> Also add a dependency on tools/xen.flf, even if not expected to
> change.
>
> Signed-off-by: Anthony PERARD
Reviewed-by: Jan Beulich
This looks
flight 164108 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164108/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 01.07.2021 16:10, Anthony PERARD wrote:
> This will always try regenerate the content of compile.h, but if it
> didn't change the file isn't updated.
>
> Also, as it's currently the case, the file isn't regenerated during
> `sudo make install` if it exist and does belong to a different user.
>
On 01.07.2021 16:10, Anthony PERARD wrote:
> We are going to need the variable XEN_BUILD_EFI earlier.
>
> This early check is using "try-run" to allow to have a temporary
> output file in case it is needed for $(CC) to build the *.c file.
>
> The "efi/check.o" file is still needed in "arch/x86/Ma
On Thu, 2021-08-05 at 08:31 +0200, Jan Beulich wrote:
> On 04.08.2021 19:55, Dario Faggioli wrote:
> >
> > Suggested-by: George Dunlap
> > Signed-off-by: Dario Faggioli
>
> In part based on your explanation in response to my v1 comments:
> Reviewed-by: Jan Beulich
>
Cool! Thank you very much a
flight 164110 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164110/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 63552872061130e236ab30f81cfe5a6714cd0012
baseline version:
ovmf 55266a9b8ac71dace1109
flight 164106 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164106/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 164097
test-armhf-armhf-libvirt 16 save
Hi Dave:
Thanks for review.
On 8/5/2021 3:27 AM, Dave Hansen wrote:
On 8/4/21 11:44 AM, Tianyu Lan wrote:
+static int default_set_memory_enc(unsigned long addr, int numpages, bool enc);
+DEFINE_STATIC_CALL(x86_set_memory_enc, default_set_memory_enc);
+
#define CPA_FLUSHTLB 1
#define
Based on feedback from 2021 Xen Developers Summit the xsm-roles RFC patch set
is being split into two separate patch sets. This is the first patch set and is
focused purely on the clean up and refactoring of the XSM hooks.
This patch set refactors the xsm_ops wrapper hooks to use the alternative_c
From: Andrew Cooper
The alternative call infrastructure is x86-only for now, but the common iommu
code has a variant and more common code wants to use the infrastructure.
Introduce CONFIG_ALTERNATIVE_CALL and a conditional implemetnation so common
code can use the optimisation when available, wi
On Linux when SELinux is put into permissive mode the descretionary access
controls are still in place. Whereas for Xen when the enforcing state of flask
is set to permissive, all operations for all domains would succeed, i.e. it
does not fall back to the default access controls. To provide a means
This renames the `struct xsm_operations` to the shorter `struct xsm_ops` and
converts the global xsm_ops from being a pointer to an explicit instance. As
part of this conversion, it reworks the XSM modules init function to return
their xsm_ops struct which is copied in to the global xsm_ops instanc
To reduce retpolines convert all the pointer function calls of the
xsm_ops hooks over to the alternative_call infrastructure.
Signed-off-by: Daniel P. Smith
Acked-by: Andrew Cooper
---
xen/include/xsm/xsm.h | 193 +-
1 file changed, 97 insertions(+), 96 d
Multiple preprocessor defines were used as a mechanism to selective include
parts of the xsm.h header file. This makes it difficult to know which portion
is being included at any one time. This commit works to simplify this by
separating the core structures and functions of XSM into xsm-core.h away
The internal define flag is not used by any XSM module, removing the #ifdef
leaving the generic event channel labeling as always present.
Signed-off-by: Daniel P. Smith
---
xen/include/xen/sched.h | 4
1 file changed, 4 deletions(-)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sc
The XSM facilities are always in use by Xen with the facade of being able to
turn XSM on and off. This option is in fact about allowing the selection of
which policies are available and which are used at runtime. To provide this
facade a complicated serious of #ifdef's are used to selective includ
On Thu, Aug 05, 2021 at 10:05:17PM +0800, Tianyu Lan wrote:
> +static int default_set_memory_enc(unsigned long addr, int numpages, bool
> enc)
> +{
> + return 0;
> +}
> +
> +DEFINE_STATIC_CALL(x86_set_memory_enc, default_set_memory_enc);
That's spelled:
DEFINE_STATIC_CALL_RET0(x86_set_memory_
On Thu, Aug 05, 2021 at 10:05:17PM +0800, Tianyu Lan wrote:
> static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc)
> {
> + return static_call(x86_set_memory_enc)(addr, numpages, enc);
> }
Hurpmh... So with a bit of 'luck' you get code-gen like:
__set_memory_enc_dec:
On 8/5/21 7:23 AM, Peter Zijlstra wrote:
> This is assuming any of this is actually performance critical, based off
> of this using static_call() to begin with.
This code is not performance critical.
I think I sent folks off on a wild goose chase when I asked that we make
an effort to optimize co
flight 164109 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164109/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 05.08.21 01:00, Julien Grall wrote:
On 04/08/2021 21:56, Oleksandr wrote:
Hi Julien, Stefano.
Hi Oleksandr,
Hi, Julien
Thank you for the prompt reply and explanations.
On 02.08.21 22:12, Oleksandr wrote:
I have done some experiments with Xen and toolstack according to the
d
On Thu, Aug 5, 2021 at 2:20 AM Jan Beulich wrote:
>
> On 05.08.2021 00:17, Jason Andryuk wrote:
> > commit 0fdb48ffe7a1 "libxl: Make sure devices added by pci-attach are
> > reflected in the config"
>
> This should be in a Fixes: tag; whether you fully spell out the
> reference here or instead ref
On 7/28/21 12:18 PM, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
...
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index e07bd9a..3f9b816 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -1811,6 +1811,62 @@ long do_memory_op(unsigned long cmd,
> XEN_
On 05.08.21 08:58, Jan Beulich wrote:
Hi Jan.
On 04.08.2021 21:18, Oleksandr wrote:
On 03.08.21 15:53, Jan Beulich wrote:
On 30.07.2021 18:13, Oleksandr wrote:
- Where that range should be located in guest address space, should that
range be the same for all domains (how GUEST_GNTTAB_BASE(
On 05.08.2021 16:06, Daniel P. Smith wrote:
> --- /dev/null
> +++ b/xen/include/xen/alternative-call.h
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef XEN_ALTERNATIVE_CALL
> +#define XEN_ALTERNATIVE_CALL
> +
> +/*
> + * Some subsystems in Xen may have multiple implementions,
flight 164111 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164111/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9abc60f9f722d891b3cedb0205fd6c9c0e2af54b
baseline version:
ovmf 63552872061130e236ab3
On 05.08.2021 16:57, Jason Andryuk wrote:
> On Thu, Aug 5, 2021 at 2:20 AM Jan Beulich wrote:
>>
>> On 05.08.2021 00:17, Jason Andryuk wrote:
>>> commit 0fdb48ffe7a1 "libxl: Make sure devices added by pci-attach are
>>> reflected in the config"
>>
>> This should be in a Fixes: tag; whether you ful
On 8/5/2021 10:29 PM, Dave Hansen wrote:
On 8/5/21 7:23 AM, Peter Zijlstra wrote:
This is assuming any of this is actually performance critical, based off
of this using static_call() to begin with.
This code is not performance critical.
I think I sent folks off on a wild goose chase when I as
Hi Christoph:
Could you have a look at this patch? It adds new API
dma_map_decrypted() to do memory decrypted and remap. It will
be used in the swiotlb code.
Thanks.
On 8/5/2021 2:45 AM, Tianyu Lan wrote:
From: Tianyu Lan
In Hyper-V Isolation VM with AMD SEV, swiotlb boucne buffer
need
Messages printed with PERROR() do not need explicit newlines (\n)
because they are added implicitly.
Signed-off-by: Costin Lupu
---
tools/libs/ctrl/xc_vm_event.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/libs/ctrl/xc_vm_event.c b/tools/libs/ctrl/xc_vm_e
On 05.08.21 18:03, Daniel P. Smith wrote:
Hi Daniel.
On 7/28/21 12:18 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
...
diff --git a/xen/common/memory.c b/xen/common/memory.c
index e07bd9a..3f9b816 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1811,6 +1811,6
Hi Konrad:
Could you have a look at this new version? The change since v1 is
make swiotlb_init_io_tlb_mem() return error code when
dma_map_decrypted() fails according your previous comment. If this
change is ok, could you give your ack and this series needs to be merged
via Hyper-V next t
Hey Oleksandr!
On 8/5/21 11:59 AM, Oleksandr wrote:
>
> On 05.08.21 18:03, Daniel P. Smith wrote:
>
> Hi Daniel.
>
>> On 7/28/21 12:18 PM, Oleksandr Tyshchenko wrote:
>>> From: Oleksandr Tyshchenko
>> ...
>>
>>> diff --git a/xen/common/memory.c b/xen/common/memory.c
>>> index e07bd9a..3f9b816
Hi Oleksandr,
On 05/08/2021 15:52, Oleksandr wrote:
On 05.08.21 01:00, Julien Grall wrote:
On 04/08/2021 21:56, Oleksandr wrote:
Hi Julien, Stefano.
Hi Oleksandr,
Hi, Julien
Thank you for the prompt reply and explanations.
On 02.08.21 22:12, Oleksandr wrote:
I have done some e
flight 164112 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164112/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 05.08.21 20:25, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 05/08/2021 15:52, Oleksandr wrote:
On 05.08.21 01:00, Julien Grall wrote:
On 04/08/2021 21:56, Oleksandr wrote:
Hi Julien, Stefano.
Hi Oleksandr,
Hi, Julien
Thank you for the prompt reply and explanations.
On 05.08.21 19:37, Daniel P. Smith wrote:
Hey Oleksandr!
Hi Daniel.
On 8/5/21 11:59 AM, Oleksandr wrote:
On 05.08.21 18:03, Daniel P. Smith wrote:
Hi Daniel.
On 7/28/21 12:18 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
...
diff --git a/xen/common/memory.c b/xen/com
On Tue, Aug 03, 2021 at 12:01:44PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> changes since v1
> (https://lore.kernel.org/linux-pci/20210729203740.1377045-1-u.kleine-koe...@pengutronix.de):
>
> - New patch to simplify drivers/pci/xen-pcifront.c, spotted and
> suggested by Boris Ostrovsky
> -
On Thu, 5 Aug 2021, Julien Grall wrote:
> Hi Oleksandr,
>
> On 05/08/2021 15:52, Oleksandr wrote:
> >
> > On 05.08.21 01:00, Julien Grall wrote:
> > >
> > >
> > > On 04/08/2021 21:56, Oleksandr wrote:
> > > >
> > > > Hi Julien, Stefano.
> > >
> > > Hi Oleksandr,
> >
> >
> > Hi, Julien
> >
On Wed, 4 Aug 2021, Julien Grall wrote:
> > +#define GUEST_SAFE_RANGE_BASE xen_mk_ullong(0xDE) /* 128GB */
> > +#define GUEST_SAFE_RANGE_SIZE xen_mk_ullong(0x02)
> >
> > While the possible new DT bindings has not been agreed yet, I re-used
> > existing "reg" property under the
flight 164114 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164114/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 97fdcbda4e69d6f085ec3f2bd9d29a04af2b50a4
baseline version:
ovmf 9abc60f9f722d891b3ced
flight 164115 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164115/
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
flight 164113 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164113/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 05.08.2021 18:37, Daniel P. Smith wrote:
> On 8/5/21 11:59 AM, Oleksandr wrote:
>> On 05.08.21 18:03, Daniel P. Smith wrote:
>>> On 7/28/21 12:18 PM, Oleksandr Tyshchenko wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1811,6 +1811,62 @@ long do_memory_op(unsigned l
Hello Bjorn,
On Thu, Aug 05, 2021 at 06:42:34PM -0500, Bjorn Helgaas wrote:
> On Tue, Aug 03, 2021 at 12:01:44PM +0200, Uwe Kleine-König wrote:
> > Hello,
> >
> > changes since v1
> > (https://lore.kernel.org/linux-pci/20210729203740.1377045-1-u.kleine-koe...@pengutronix.de):
> >
> > - New patc
46 matches
Mail list logo
