flight 163178 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163178/
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-armhf-libvirt
flight 163175 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163175/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
flight 163171 qemu-mainline real [real]
flight 163177 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/163171/
http://logs.test-lab.xenproject.org/osstest/logs/163177/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 163168 xen-unstable real [real]
flight 163174 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/163168/
http://logs.test-lab.xenproject.org/osstest/logs/163174/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
flight 163172 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163172/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
On Mon, 28 Jun 2021, Julien Grall wrote:
> On 25/06/2021 18:47, Stefano Stabellini wrote:
> > On Fri, 25 Jun 2021, Julien Grall wrote:
> > > Hi,
> > >
> > > On 25/06/2021 02:51, Stefano Stabellini wrote:
> > > > It has become clear that an option to disable trapping SMC calls to Xen
> > > > is ver
flight 163165 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163165/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 02/06/2021 15:37, Jan Beulich wrote:
> The macro expanding to quite a few insns, replace its use by simply
> clearing the status flags when the to be executed insn doesn't depend
> on their initial state, in cases where this is easily possible. (There
> are more cases where the uses are hidden i
flight 163167 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163167/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
Hi Jan,
On 28/06/2021 17:15, Jan Beulich wrote:
On 28.06.2021 17:42, Andrew Cooper wrote:
On 28/06/2021 12:52, Jan Beulich wrote:
Convert the two remaining uses as well as Arm's stub to the properly
named and type-safe mfn_to_gfn(), dropping x86's definition (where we
already have mfn_to_gfn()
On 28.06.2021 17:42, Andrew Cooper wrote:
> On 28/06/2021 12:52, Jan Beulich wrote:
>> Convert the two remaining uses as well as Arm's stub to the properly
>> named and type-safe mfn_to_gfn(), dropping x86's definition (where we
>> already have mfn_to_gfn()).
>>
>> Signed-off-by: Jan Beulich
>
>
Hi Stefano,
On 25/06/2021 18:47, Stefano Stabellini wrote:
On Fri, 25 Jun 2021, Julien Grall wrote:
Hi,
On 25/06/2021 02:51, Stefano Stabellini wrote:
It has become clear that an option to disable trapping SMC calls to Xen
is very useful for debugging user issues.
Instead of having to provid
flight 163163 qemu-mainline real [real]
flight 163170 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/163163/
http://logs.test-lab.xenproject.org/osstest/logs/163170/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 28/06/2021 12:47, Jan Beulich wrote:
> The hypervisor may not have enough memory to satisfy the request.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
> ---
> Especially if the request was mostly fulfilled, guests may have done
> fine despite the failure, so there is a risk of p
On 28/06/2021 12:52, Jan Beulich wrote:
> Convert the two remaining uses as well as Arm's stub to the properly
> named and type-safe mfn_to_gfn(), dropping x86's definition (where we
> already have mfn_to_gfn()).
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper , but ...
> --- a/xen/includ
Just as with x86_cpu_policies_are_compatible(), make a start on this function
with some token handling.
Add levelling support for MSR_ARCH_CAPS, because RSBA has interesting
properties, and introduce test_calculate_compatible_success() to the unit
tests, covering various cases where the arch_caps
Hi Jan,
On 28/06/2021 12:52, Jan Beulich wrote:
Convert the two remaining uses as well as Arm's stub to the properly
named and type-safe mfn_to_gfn(), dropping x86's definition (where we
already have mfn_to_gfn()).
Signed-off-by: Jan Beulich
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
flight 163166 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163166/
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
Anthony PERARD writes ("[XEN PATCH] Config.mk: re-pin OVMF changeset and unpin
qemu-xen"):
> qemu-xen tree have a osstest gate and doesn't need to be pinned.
>
> On the other hand, OVMF's xen repository doesn't have a gate and needs
> to be pinned. The "master" branch correspond now to the tag
>
qemu-xen tree have a osstest gate and doesn't need to be pinned.
On the other hand, OVMF's xen repository doesn't have a gate and needs
to be pinned. The "master" branch correspond now to the tag
"edk2-stable202105", so pin to that commit.
Fixes: a04509d34d72 ("Branching: Update version files etc
On 22.06.2021 20:21, Andrew Cooper wrote:
> v2:
> * Fix CI failures from newly-exposed logic
> * Drop -f's from $(RM)
> * Drop the 'run' rune patch. Its clearly controvertial, but ignoring the
>problems isn't an available option in the longterm.
What is "the problem" here? The presence of
On 22.06.2021 20:21, Andrew Cooper wrote:
> In particular, fill in the install/uninstall rules so this test can be
> packaged to be automated sensibly.
>
> This causes the code to be noticed by CI, which objects as follows:
>
> test-xenstore.c: In function 'main':
> test-xenstore.c:486:5: err
On 22.06.2021 20:21, Andrew Cooper wrote:
> @@ -23,23 +21,32 @@ run: $(TARGET-y)
>
> .PHONY: clean
> clean:
> - $(RM) -f -- *.o .*.d .*.d2 test-cpu-policy
> + $(RM) -- *.o $(TARGETS) $(DEPS_RM)
>
> .PHONY: distclean
> distclean: clean
> - $(RM) -f -- *~
> + $(RM) -- *~
>
>
On 22.06.2021 20:21, Andrew Cooper wrote:
> In particular, fill in the install/uninstall rules so this test can be
> packaged to be automated sensibly.
>
> Make all object files depend on the Makefile, drop redundant -f's for $(RM),
> and use $(TARGET) when appropriate.
>
> Signed-off-by: Andrew
On 17.06.2021 15:05, Ian Jackson wrote:
> On to process:
>
> Jan Beulich writes ("Re: Regressed XSA-286, was [xen-unstable test] 161917:
> regressions - FAIL"):
>> On 16.06.2021 17:43, Andrew Cooper wrote:
>>> I am very irritated that you have *twice* recently introduced security
>>> vulnerabilit
On 02.06.2021 16:38, Jan Beulich wrote:
> We already do so in the native execution case, and a few descriptions (I
> did notice this with SHA ones) are short enough for the output to look
> slightly odd.
>
> Signed-off-by: Jan Beulich
Again - anyone?
Thanks, Jan
> ---
> Many descriptions are l
On 02.06.2021 16:37, Jan Beulich wrote:
> The macro expanding to quite a few insns, replace its use by simply
> clearing the status flags when the to be executed insn doesn't depend
> on their initial state, in cases where this is easily possible. (There
> are more cases where the uses are hidden i
On 20.05.2021 15:34, Jan Beulich wrote:
> The SDM specifically allows for earlier writes to fully overlapping
> ranges to be dropped. If a guest did so, hvmemul_phys_mmio_access()
> would crash it if varying data was written to the same address. Detect
> overlaps early, as doing so in hvmemul_{line
Hi all,
## Minutes from Xen live-update design session, 28th May
- The records are applied in Xen2 as if a hypercall was executed. We execute
the hypercall on behalf of the domain, rather than the domain (i.e. dom0)
calling the hypercall.
- "How extensible is that approach? Things will ch
On 26.06.2021 17:36, Rroach wrote:
> Hi, when I look the source code in Xen-4.15 source code, I found a type
> mismatch.
>
>
> In detailed, in xen/arch/x86/msi.c:find_msi_entry, there is a comparison
> between entry->msi_attrib.type and cap_id. However, according to the
> definition, the type
PFNs are purely a software construct. In particular their association
with MFNs can change at any time. Switch to reporting back GFNs through
the hypercall interface (but stick to PFNs / paddr for the MSR one).
(Note that unmmap_broken_page() validly expects a GFN anyway.)
While doing the adjustme
There's no need for more than an assertion as to the passed in MFN's
validity, as the caller's prior call to offline_page() would not have
succeeded on an invalid one.
There's no use in checking both is_hvm_domain() and paging_mode_hap(),
as the latter implies the former.
Extend the P2M manipulat
While going through uses of get_gpfn_from_mfn(), I've noticed
some anomalies here (but of course there are more left). Patch
2 is specifically RFC, for altering the public interface.
1: adjustments to unmmap_broken_page()
2: change address space for incident reporting
Jan
If anything, a check covering a wider range of invalid M2P entries ought
to be used (e.g. VALID_M2P()). But since everything is fully under Xen's
control at this stage, simply remove the BUG_ON().
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@
Convert the two remaining uses as well as Arm's stub to the properly
named and type-safe mfn_to_gfn(), dropping x86's definition (where we
already have mfn_to_gfn()).
Signed-off-by: Jan Beulich
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -111,7 +111,8 @@ void getdomaininfo(struct doma
At the time of d838ac2539cf ("x86: don't allow Dom0 access to the HT
address range") documentation correctly stated that the range was
completely fixed. For Fam17 and newer, it lives at the top of physical
address space, though.
To correctly determine the top of physical address space, we need to
The hypervisor may not have enough memory to satisfy the request.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
Especially if the request was mostly fulfilled, guests may have done
fine despite the failure, so there is a risk of perceived regressions
here. But not checking the error
Am Mon, 28 Jun 2021 13:20:06 +0200
schrieb Jan Beulich :
> But if a field named dirty_count was intended to convey the P2M size
> (and then only on the first iteration), this very certainly would
> have needed writing down somewhere.
Sure. Right now the only documentation for the precopy_policy c
On 28.06.2021 13:10, Olaf Hering wrote:
> Am Mon, 28 Jun 2021 09:48:26 +0200
> schrieb Jan Beulich :
>
>> On 25.06.2021 18:36, Andrew Cooper wrote:
>>> This is an external interface, and I'm not sure it will tolerate finding
>>> more than p2m_size allegedly dirty.
>> But you do realize that a fe
flight 163160 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163160/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 163136
test-armhf-armhf-libvirt 16 save
Am Mon, 28 Jun 2021 09:48:26 +0200
schrieb Jan Beulich :
> On 25.06.2021 18:36, Andrew Cooper wrote:
> > This is an external interface, and I'm not sure it will tolerate finding
> > more than p2m_size allegedly dirty.
> But you do realize that a few lines down from here there already was
>
flight 163162 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163162/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
Usage of 'scsi-disk' device is deprecated and removed from QEMU,
instead we need to use 'scsi-hd' for hard drives.
See QEMU 879be3af49 (hw/scsi: remove 'scsi-disk' device)
Signed-off-by: Anthony PERARD
---
tools/libs/light/libxl_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
f3f778c81769 forgot one boolean parameter.
Fixes: f3f778c81769 ("libxl: Replace QEMU's command line short-form boolean
option")
Signed-off-by: Anthony PERARD
---
tools/libs/light/libxl_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libs/light/libxl_dm.c b/tools/l
Follow-up of
[XEN PATCH v2 0/8] Fix libxl with QEMU 6.0 + remove some more deprecated
usages
to fix few missing bits.
To be backported to Xen 4.15 as well.
On 25.06.2021 17:49, Andrew Cooper wrote:
> On 25/06/2021 14:17, Jan Beulich wrote:
>> For log-dirty operations a 64-bit field is being truncated to become an
>> "int" return value. Seeing the large number of arguments the present
>> function takes, reduce its set of parameters to that needed for a
On 25.06.2021 21:45, Andrew Cooper wrote:
> On 25/06/2021 14:24, Jan Beulich wrote:
>> Let's try to avoid giving the impression that 32-bit tool stacks are as
>> capable as 64-bit ones.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/SUPPORT.md
>> +++ b/SUPPORT.md
>> @@ -131,6 +131,11 @@ ARM only has
On 25.06.2021 21:00, Andrew Cooper wrote:
> On 25/06/2021 14:20, Jan Beulich wrote:
>> struct xc_sr_record's length field has just 32 bits.
>
> The stream max record length is
>
> /* Somewhat arbitrary - 128MB */
> #define REC_LENGTH_MAX (128U << 20)
>
> and is checked in the low
On 25.06.2021 20:30, Andrew Cooper wrote:
> On 25/06/2021 14:19, Jan Beulich wrote:
>> minfo->p2m_size may have more than 31 significant bits. Change the
>> induction variable to unsigned long, and (largely for signed-ness
>> consistency) a helper variable to unsigned int.
>>
>> Signed-off-by: Jan
On 25.06.2021 20:08, Andrew Cooper wrote:
> On 25/06/2021 14:19, Jan Beulich wrote:
>> Like for the dirty bitmap, it is unnecessary to allocate the deferred-
>> pages bitmap when all that's ever going to happen is a single all-dirty
>> run.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> The clearing o
flight 163164 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163164/
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-armhf-libvirt
On 25.06.2021 19:02, Andrew Cooper wrote:
> On 25/06/2021 14:18, Jan Beulich wrote:
>> For one it is unnecessary to fill a perhaps large chunk of memory with
>> all ones. Add a new parameter to send_dirty_pages() for callers to
>> indicate so.
>>
>> Then it is further unnecessary to allocate the di
On 25.06.2021 18:36, Andrew Cooper wrote:
> On 25/06/2021 14:18, Jan Beulich wrote:
>> In send_memory_live() the precise value the dirty_count struct field
>> gets initialized to doesn't matter much (apart from the triggering of
>> the log message in send_dirty_pages(), see below), but it is import
53 matches
Mail list logo
