flight 152517 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152517/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9565ab67c2095a5ea893e63561a49aedf3387b8f
baseline version:
ovmf 8834e10b30125daa47da9
flight 152514 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152514/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 152501
Tests which did not succeed, b
flight 152511 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152511/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 152418
test-amd64-amd64-xl-qemuu-ws16-amd64
On 08.08.20 00:50, Stefano Stabellini wrote:
Hi
On Fri, 7 Aug 2020, Oleksandr wrote:
On 06.08.20 03:37, Stefano Stabellini wrote:
Hi Stefano
Trying to simulate IO_RETRY handling mechanism (according to model below) I
continuously get IO_RETRY from try_fwd_ioserv() ...
OK, thanks for the
On 08.08.20 00:50, Stefano Stabellini wrote:
Hi Stefano
On Fri, 7 Aug 2020, Oleksandr wrote:
On 06.08.20 03:37, Stefano Stabellini wrote:
Hi Stefano
Trying to simulate IO_RETRY handling mechanism (according to model below) I
continuously get IO_RETRY from try_fwd_ioserv() ...
OK, thanks
On Fri, 7 Aug 2020, Jan Beulich wrote:
> On 07.08.2020 01:49, Stefano Stabellini wrote:
> > @@ -108,56 +107,66 @@
> > * Use SMP-safe bit-setting instruction.
> > */
> >
> > -/*
> > +/**
> > + * typedef
> > * Reference to a grant entry in a specified domain's grant table.
> > */
> > type
On Fri, 7 Aug 2020, Jan Beulich wrote:
> On 07.08.2020 01:49, Stefano Stabellini wrote:
> > @@ -41,19 +41,25 @@
> > * XENFEAT_dom0 MUST be set if the guest is to be booted as dom0,
> > */
> >
> > -/*
> > - * If set, the guest does not need to write-protect its pagetables, and can
> > - * upda
On Fri, 7 Aug 2020, Jan Beulich wrote:
> On 07.08.2020 01:49, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > Convert in-code comments to kernel-doc format wherever possible.
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> > xen/include/public/memory.h | 232
On Fri, 7 Aug 2020, Jan Beulich wrote:
> On 07.08.2020 01:49, Stefano Stabellini wrote:
> > --- a/xen/include/public/version.h
> > +++ b/xen/include/public/version.h
> > @@ -30,19 +30,33 @@
> >
> > #include "xen.h"
> >
> > -/* NB. All ops return zero on success, except XENVER_{version,pagesize
On Fri, 7 Aug 2020, Oleksandr wrote:
> On 06.08.20 03:37, Stefano Stabellini wrote:
>
> Hi Stefano
>
> Trying to simulate IO_RETRY handling mechanism (according to model below) I
> continuously get IO_RETRY from try_fwd_ioserv() ...
>
> > OK, thanks for the details. My interpretation seems to be
On Fri, 7 Aug 2020, Jan Beulich wrote:
> On 07.08.2020 01:49, Stefano Stabellini wrote:
> > On Thu, 6 Aug 2020, Julien Grall wrote:
> >> On 06/08/2020 01:37, Stefano Stabellini wrote:
> >>> On Wed, 5 Aug 2020, Julien Grall wrote:
> On 05/08/2020 00:22, Stefano Stabellini wrote:
> > On Mon,
On Fri, 7 Aug 2020, Jan Beulich wrote:
> On 07.08.2020 01:49, Stefano Stabellini wrote:
> > @@ -137,65 +147,78 @@ typedef struct evtchn_bind_interdomain
> > evtchn_bind_interdomain_t;
> > * binding cannot be changed.
> > */
> > struct evtchn_bind_virq {
> > -/* IN parameters. */
> > -
On Fri, 7 Aug 2020, Jan Beulich wrote:
> On 07.08.2020 01:49, Stefano Stabellini wrote:
> > # THE KERNEL-DOC KEYWORDS USED
> >
> > I used the "struct" keyword for structures, i.e.:
> >
> > /**
> > * struct foobar
> > */
> >
> > "struct" makes kernel-doc go and look at the following struct in t
flight 152532 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152532/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Thursday, August 6, 2020 8:14 PM, Andrew Cooper
wrote:
> For SecureBoot, it is important that nothing which is signed can be
> tricked into running unsigned code.
>
> That includes configuration such as xen.cfg or the command line.
> Consuming these from unsigned sources is ok, so long as we c
flight 152505 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152505/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 152332
test-amd64-i386-qem
The pull request you sent on Fri, 7 Aug 2020 07:04:50 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.9-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e51418191f5a741b5f94764798c81bf69dec4806
Thank you!
--
Deet-doot-dot, I
On 07/08/2020 12:34, Jan Beulich wrote:
> This is in preparation of making the building of sysctl.c conditional.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 07/08/2020 12:34, Jan Beulich wrote:
> This is in preparation of making the building of domctl.c conditional.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 07/08/2020 12:33, Jan Beulich wrote:
> --- a/xen/common/bitmap.c
> +++ b/xen/common/bitmap.c
> @@ -384,3 +386,87 @@ void bitmap_byte_to_long(unsigned long *
> }
>
> #endif
> +
> +int bitmap_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_bitmap,
> +const unsigned lo
On 07/08/2020 12:33, Jan Beulich wrote:
> While this won't affect overall memory overhead (struct vcpu as well as
> struct domain get allocated as single pages) nor code size (the offsets
> into the base structures are too large to be representable as signed 8-
> bit displacements), it'll allow the
I am replying to this email as I have been told that the original was
filtered as spam due to the tarball attachment. The tarball contains
some example html output document files from sphinx.
I have uploaded the tarball here for your convenience:
http://xenbits.xenproject.org/people/sstabellini/h
On 06.08.20 03:37, Stefano Stabellini wrote:
Hi Stefano
Trying to simulate IO_RETRY handling mechanism (according to model
below) I continuously get IO_RETRY from try_fwd_ioserv() ...
OK, thanks for the details. My interpretation seems to be correct.
In which case, it looks like xen/arch/
On 07/08/2020 12:32, Jan Beulich wrote:
> With changes done over time and as far as linking goes, the only special
> thing about building with EFI support enabled is the need for the dummy
> relocations object for xen.gz uniformly in all build stages. All other
> efi/*.o can be consumed from the bu
On 07.08.2020 17:12, Andrew Cooper wrote:
> On 07/08/2020 11:56, Jan Beulich wrote:
>> On 06.08.2020 18:16, Andrew Cooper wrote:
>>> On 06/08/2020 10:05, Jan Beulich wrote:
>>> Can't we remove all of this by having CONFIG_XEN_PE expressed/selectable
>>> properly in Kconfig, and gathering all the ob
flight 152524 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152524/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 07/08/2020 11:56, Jan Beulich wrote:
> On 06.08.2020 18:16, Andrew Cooper wrote:
>> On 06/08/2020 10:05, Jan Beulich wrote:
>> Can't we remove all of this by having CONFIG_XEN_PE expressed/selectable
>> properly in Kconfig, and gathering all the objects normally, rather than
>> bodging all of co
On 07.07.2020 21:39, Michał Leszczyński wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -428,6 +428,56 @@ static void vmx_domain_relinquish_resources(struct
> domain *d)
> vmx_free_vlapic_mapping(d);
> }
>
> +static int vmx_init_pt(struct vcpu *v)
> +{
> +
On 07.07.2020 21:39, Michał Leszczyński wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -2205,6 +2205,27 @@ int domain_relinquish_resources(struct domain *d)
> altp2m_vcpu_disable_ve(v);
> }
>
> +for_each_vcpu ( d, v )
> +{
> +
On 07.07.2020 21:39, Michał Leszczyński wrote:
> @@ -443,6 +449,9 @@ struct domain *domain_create(domid_t domid,
> d->nr_pirqs = min(d->nr_pirqs, nr_irqs);
>
> radix_tree_init(&d->pirq_tree);
> +
> +if ( config->processor_trace_buf_kb )
> +d->processor_trace_
On 07.07.2020 21:39, Michał Leszczyński wrote:
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -291,6 +291,20 @@ static int vmx_init_vmcs_config(void)
> _vmx_cpu_based_exec_control &=
> ~(CPU_BASED_CR8_LOAD_EXITING | CPU_BASED_CR8_STORE_EXITING);
>
On 27.07.2020 16:21, Hongyan Xia wrote:
> From: Wei Liu
>
> Signed-off-by: Wei Liu
> Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
On 27.07.2020 16:21, Hongyan Xia wrote:
> From: Wei Liu
>
> Map and unmap pages instead of relying on the direct map.
>
> Signed-off-by: Wei Liu
> Signed-off-by: Hongyan Xia
> Reviewed-by: Jan Beulich
>
> ---
> Changed in v8:
> - replace l3/2_ro_mpt_mfn with just mfn since their lifetimes do
On 27.07.2020 16:21, Hongyan Xia wrote:
> From: Wei Liu
>
> Rewrite those functions to use the new APIs. Modify its callers to unmap
> the pointer returned. Since alloc_xen_pagetable_new() is almost never
> useful unless accompanied by page clearing and a mapping, introduce a
> helper alloc_map_c
flight 152512 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152512/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On 06.08.20 23:32, Stefano Stabellini wrote:
Hi Stefano
On Thu, 6 Aug 2020, Jan Beulich wrote:
On 06.08.2020 02:37, Stefano Stabellini wrote:
What should do_trap_stage2_abort_guest do on IO_RETRY? Simply return
early and let the scheduler do its job? Something like:
enum io_st
On 07.08.2020 01:49, Stefano Stabellini wrote:
> --- a/xen/include/public/version.h
> +++ b/xen/include/public/version.h
> @@ -30,19 +30,33 @@
>
> #include "xen.h"
>
> -/* NB. All ops return zero on success, except XENVER_{version,pagesize}
> - * XENVER_{version,pagesize,build_id} */
> +/**
>
On 07.08.2020 01:49, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> Convert in-code comments to kernel-doc format wherever possible.
>
> Signed-off-by: Stefano Stabellini
> ---
> xen/include/public/memory.h | 232
> 1 file changed, 155 insertions(
On 07.08.2020 01:49, Stefano Stabellini wrote:
> @@ -137,65 +147,78 @@ typedef struct evtchn_bind_interdomain
> evtchn_bind_interdomain_t;
> * binding cannot be changed.
> */
> struct evtchn_bind_virq {
> -/* IN parameters. */
> -uint32_t virq; /* enum virq */
> +/** @virq: IN
On 07.08.2020 01:49, Stefano Stabellini wrote:
> @@ -108,56 +107,66 @@
> * Use SMP-safe bit-setting instruction.
> */
>
> -/*
> +/**
> + * typedef
> * Reference to a grant entry in a specified domain's grant table.
> */
> typedef uint32_t grant_ref_t;
In the comment, did you mean grant
On 07.08.2020 01:49, Stefano Stabellini wrote:
> @@ -41,19 +41,25 @@
> * XENFEAT_dom0 MUST be set if the guest is to be booted as dom0,
> */
>
> -/*
> - * If set, the guest does not need to write-protect its pagetables, and can
> - * update them via direct writes.
> +/**
> + * DOC: XENFEAT_wr
On 06.08.2020 16:15, Trammell Hudson wrote:
> Updated patch:
I'm afraid the number of style issues has further increased. First
and foremost please read ./CODING_STYLE and look at surrounding code.
> --- /dev/null
> +++ b/xen/arch/x86/efi/pe.c
> @@ -0,0 +1 @@
> +../../../common/efi/pe.c
> \ No ne
Hello,
Is Spectre and Meltdown solved in Xen hypervisor completely?How many versions
of it existed?
Tnx.
There is no need for platform-wide, system-wide, or per-domain control
in this case. Hence avoid including this dead code in the build.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -23,7 +23,6 @@ obj-$(CONFIG_GDBSX) += debug.o
obj-y += delay.o
obj-y +=
This is in preparation of making the building of sysctl.c conditional.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -396,3 +397,36 @@ void call_function_interrupt(struct cpu_
A subsequent change will exclude domctl.c from getting built for a
particular configuration, yet the two functions get used from elsewhere.
Signed-off-by: Jan Beulich
---
v2: Move function decls to xen/bitmap.h.
--- a/xen/common/bitmap.c
+++ b/xen/common/bitmap.c
@@ -9,6 +9,8 @@
#include
#inc
This is in preparation of making the building of domctl.c conditional.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -294,6 +294,173 @@ void update_guest_memory_policy(struct v
}
}
+void domain_cpu_policy_changed(struct domain *d)
+{
+const str
While this won't affect overall memory overhead (struct vcpu as well as
struct domain get allocated as single pages) nor code size (the offsets
into the base structures are too large to be representable as signed 8-
bit displacements), it'll allow the tail of struct pv_{domain,vcpu} to
share a cach
With changes done over time and as far as linking goes, the only special
thing about building with EFI support enabled is the need for the dummy
relocations object for xen.gz uniformly in all build stages. All other
efi/*.o can be consumed from the built_in*.o files.
In efi/Makefile, besides movin
There's no need for xen.efi at all, and there's also no need for EFI
support in xen.gz since the shim runs in PVH mode, i.e. without any
firmware (and hence by implication also without EFI one).
The slightly odd looking use of $(space) is to ensure the new ifneq()
evaluates consistently between "b
This is a in part just loosely connected set of changes in particular
aiming at further shim size binary reduction.
One patch of v1 did go in. Besides the dropping of that one, there
was a small adjustment to what is now patch 4 (based on feedback) and
I did notice an omission in patch 1.
1: x86/
submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Juergen-Gross/Remove-32-bit-Xen-PV-guest-support/20200807-164058
base: https://git.kernel.org/pub/scm/linux/kernel/git/t
On 06.08.2020 18:16, Andrew Cooper wrote:
> On 06/08/2020 10:05, Jan Beulich wrote:
>> We're gaining such sections, and like .text.* and .data.* they shouldn't
>> be present in objects subject to automatic to-init conversion. Oddly
>> enough for quite some time we did have an instance breaking this
On 07.08.2020 12:12, Jan Beulich wrote:
> On 06.08.2020 21:16, Andrew Cooper wrote:
>> On 06/08/2020 10:28, Jan Beulich wrote:
>>> An alternative place for opt_pv32.h would seem to be asm-x86/config.h.
>>
>> Oh - yes please. I think that would be better overall.
>
> Done.
Now that I'm trying to
On Fri, Aug 07, 2020 at 12:02:59PM +0200, Jürgen Groß wrote:
> On 07.08.20 11:39, [email protected] wrote:
> > On Fri, Aug 07, 2020 at 10:38:23AM +0200, Juergen Gross wrote:
> >
> > > -# else
> > > - const unsigned char cpu_iret[1];
> > > -# endif
> > > };
> > > static const struct patc
On 06.08.2020 21:16, Andrew Cooper wrote:
> On 06/08/2020 10:28, Jan Beulich wrote:
>> Note that opt_pv32's declaration / #define need to be moved due to other
>> header dependencies; in particular can asm-x86/mm.h not include
>> asm-x86/pv/domain.h.
>>
>> While touching their definitions anyway,
On 07.08.20 11:39, [email protected] wrote:
On Fri, Aug 07, 2020 at 10:38:23AM +0200, Juergen Gross wrote:
-# else
- const unsigned char cpu_iret[1];
-# endif
};
static const struct patch_xxl patch_data_xxl = {
@@ -42,7 +38,6 @@ static const struct patch_xxl patch_data_xxl
On Fri, Aug 07, 2020 at 10:38:23AM +0200, Juergen Gross wrote:
> -# else
> - const unsigned char cpu_iret[1];
> -# endif
> };
>
> static const struct patch_xxl patch_data_xxl = {
> @@ -42,7 +38,6 @@ static const struct patch_xxl patch_data_xxl = {
> .irq_save_fl= { 0x
Den 31.07.2020 14.51, skrev Oleksandr Andrushchenko:
> From: Oleksandr Andrushchenko
>
> Add YUYV to supported formats, so the frontend can work with the
> formats used by cameras and other HW.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
Acked-by: Noralf Trønnes
Den 31.07.2020 14.51, skrev Oleksandr Andrushchenko:
> From: Oleksandr Andrushchenko
>
> While importing a dmabuf it is possible that the data of the buffer
> is put with offset which is indicated by the SGT offset.
> Respect the offset value and forward it to the backend.
>
> Signed-off-by:
On 06.08.2020 16:04, Andrew Cooper wrote:
> On 06/08/2020 10:28, Jan Beulich wrote:
>> Add #ifdef-s (the 2nd one will be needed in particular, to guard the
>> uses of m2p_compat_vstart and HYPERVISOR_COMPAT_VIRT_START()) and fold
>> duplicate uses of elf_32bit().
>>
>> Also adjust what gets logged:
flight 152504 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152504/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8834e10b30125daa47da9f6c5c1a41b4eafbae7f
baseline version:
ovmf e188ecc8b4aed8fdd26b7
On 07.08.2020 01:49, Stefano Stabellini wrote:
> # THE KERNEL-DOC KEYWORDS USED
>
> I used the "struct" keyword for structures, i.e.:
>
> /**
> * struct foobar
> */
>
> "struct" makes kernel-doc go and look at the following struct in the
> code, parses struct members comments, and generate a d
On 07.08.2020 01:49, Stefano Stabellini wrote:
> On Thu, 6 Aug 2020, Julien Grall wrote:
>> On 06/08/2020 01:37, Stefano Stabellini wrote:
>>> On Wed, 5 Aug 2020, Julien Grall wrote:
On 05/08/2020 00:22, Stefano Stabellini wrote:
> On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
>> Fro
With 32-bit Xen PV support gone commit a4c0e91d1d65bc58
("x86/entry/32: Fix XEN_PV build dependency") can be reverted again.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/idtentry.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/idtentry.h b/
There are some code parts using CONFIG_PARAVIRT for Xen pvops related
issues instead of the more stringent CONFIG_PARAVIRT_XXL.
Signed-off-by: Juergen Gross
---
arch/x86/entry/entry_64.S| 4 ++--
arch/x86/include/asm/fixmap.h| 2 +-
arch/x86/include/asm/required-featu
Xen is requiring 64-bit machines today and since Xen 4.14 it can be
built without 32-bit PV guest support. There is no need to carry the
burden of 32-bit PV guest support in the kernel any longer, as new
guests can be either HVM or PVH, or they can use a 64 bit kernel.
Remove the 32-bit Xen PV sup
The long term plan has been to replace Xen PV guests by PVH. The first
victim of that plan are now 32-bit PV guests, as those are used only
rather seldom these days. Xen on x86 requires 64-bit support and with
Grub2 now supporting PVH officially since version 2.04 there is no
need to keep 32-bit PV
Some paravirt macros are no longer used, delete them.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index dedc89a07826..99da08852df0 100644
---
With 32-bit pv-guest support removed xen-asm_64.S can be merged with
xen-asm.S
Signed-off-by: Juergen Gross
---
arch/x86/xen/Makefile | 3 +-
arch/x86/xen/xen-asm.S| 179 +++
arch/x86/xen/xen-asm_64.S | 192 --
3 files
The last 32-bit user of stuff under CONFIG_PARAVIRT_XXL is gone.
Remove 32-bit specific parts.
Signed-off-by: Juergen Gross
---
arch/x86/entry/vdso/vdso32/vclock_gettime.c | 1 +
arch/x86/include/asm/paravirt.h | 92 +++--
arch/x86/include/asm/paravirt_types.h
With support for 32-bit pv guests gone pure pv-code no longer needs to
test for highmem. Dropping those tests removes the need for flushing
in some places.
Signed-off-by: Juergen Gross
---
arch/x86/xen/enlighten_pv.c | 11 ++-
arch/x86/xen/mmu_pv.c | 138 ++
On 06.08.2020 16:15, Trammell Hudson wrote:
> Updated patch:
Before I get to look at this new version, one more general remark
(just to not forget making it later): There's a scalability issue
here: Right now xen.efi requires to be loaded below the 4Gb
boundary. I've seen systems with as little as
On 06.08.2020 20:10, Trammell Hudson wrote:
> On Thursday, August 6, 2020 6:40 PM, Jan Beulich wrote:
>
>> On 05.08.2020 20:19, Trammell Hudson wrote:
>> [...]
>>> ~/build/xen-clean/xen$ objcopy xen.efi test.efi
>>> objcopy: test.efi: Data Directory size (1c) exceeds space left in section
>>> (1
74 matches
Mail list logo
