On Thu, 2019-07-11 at 14:19 -0700, Adam Williamson wrote:
> Yeah, that's where I was going to go next (there has already been a
> thread about this this morning). If what we care about is that Fedora
> boots on EC2, that's what we should have in the criteria, and what we
> should test.
While
flight 138892 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138892/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 7 xen-boot fail REGR. vs. 138868
Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
selftest") reveals a bug in XEN PV int3 assemble code. There is
a double pop of register R11 and RCX currupting the exception
frame, one in xen_int3 and the other in xen_xenint3.
We see below hang at bootup:
general protection
flight 138896 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138896/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8df52631e53c73cbe5ef037155cc5b6bdc87f757
baseline version:
ovmf
flight 138895 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138895/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
138876
Tests which did
Hi Chaitanya,
> +static inline sector_t bdev_nr_sects(struct block_device *bdev)
> +{
> + return part_nr_sects_read(bdev->bd_part);
> +}
Can bdev end up being NULL in any of the call sites?
Otherwise no objections.
--
Martin K. Petersen Oracle Linux Engineering
On 11.07.2019 19:13, Tamas K Lengyel wrote:
>> @@ -629,6 +697,14 @@ static void *hvmemul_map_linear_addr(
>>
>> ASSERT(p2mt == p2m_ram_logdirty || !p2m_is_readonly(p2mt));
>> }
>> +
>> +if ( curr->arch.vm_event &&
>> +curr->arch.vm_event->send_event &&
>
flight 138890 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138890/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 138799
test-armhf-armhf-libvirt 14
flight 13 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/13/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
flight 138885 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138885/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 138849
On Thu, 2019-07-11 at 21:43 +0100, Peter Robinson wrote:
> > On Mon, 2019-07-08 at 09:11 -0700, Adam Williamson wrote:
> > > It's worth noting that at least part of the justification for the
> > > criterion in the first place was that Amazon was using Xen for EC2, but
> > > that is no longer the
On Mon, 2019-07-08 at 09:11 -0700, Adam Williamson wrote:
> It's worth noting that at least part of the justification for the
> criterion in the first place was that Amazon was using Xen for EC2, but
> that is no longer the case, most if not all EC2 instance types no
> longer use Xen.
I don't
On Thu, Jul 11, 2019 at 10:58:03AM -0700, Adam Williamson wrote:
> On Thu, 2019-07-11 at 09:57 -0500, Doug Goldstein wrote:
> > On 7/8/19 11:11 AM, Adam Williamson wrote:
> > > On Tue, 2019-05-21 at 11:14 -0700, Adam Williamson wrote:
> > > > > > > > "The release must boot successfully as Xen DomU
Hi,
On 7/11/19 7:32 PM, Julien Grall wrote:
>>
>> What do you think?
>
> Have you looked at the series I pointed out earlier on? It extends Xen
> to support other interrupt controller parent.
>
Yes, but you said once that these patch series wasn't accepted because
maintainers didn't like
[This mail incorporates comments raised on IRC. I have made some of this more
verbose to provide context to people that haven't seen the IRC comments.]
This will be a bunch of facts on the am5. Someone else will have relate it
back to Xen.
1 - The WUGen is a hardware block on the MPU block
flight 138907 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138907/
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
On Thu, 2019-07-11 at 09:57 -0500, Doug Goldstein wrote:
> On 7/8/19 11:11 AM, Adam Williamson wrote:
> > On Tue, 2019-05-21 at 11:14 -0700, Adam Williamson wrote:
> > > > > > > "The release must boot successfully as Xen DomU with releases
> > > > > > > providing
> > > > > > > a functional,
On 7/11/19 1:50 PM, Denis Obrezkov wrote:
Hi,
Hi,
I am interested whether we should do something with omap5-wugen-mpu. I
found that crossbar is connected to GIC. And on some schemes in trm it
is connected via omap5-wugen-mpu. So, it is not clear for me whether it
should be handled in xen.
Hi Andrew,
On 7/11/19 3:25 PM, Andrew Cooper wrote:
On 10/07/2019 14:25, Julien Grall wrote:
However, in attempting to review this, I've got some bigger questions.
All ARM and x86 HVM (and PVH) guests return true for
xc_dom_translated(), so should take the fastpath out of xc_dom_p2m() and
> @@ -629,6 +697,14 @@ static void *hvmemul_map_linear_addr(
>
> ASSERT(p2mt == p2m_ram_logdirty || !p2m_is_readonly(p2mt));
> }
> +
> +if ( curr->arch.vm_event &&
> +curr->arch.vm_event->send_event &&
Why not fold these checks into
On 11.07.2019 17:49, Andrew Cooper wrote:
> The GDT and IDT allocations are all order 0, and not going to change.
>
> Use an explicit 0, instead of calling get_order_from_pages(). This
> allows for the removal of the 'order' local parameter in both
> cpu_smpboot_{alloc,free}().
>
> While making
flight 138883 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138883/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 138603
test-amd64-amd64-xl-qemuu-win7-amd64
The GDT and IDT allocations are all order 0, and not going to change.
Use an explicit 0, instead of calling get_order_from_pages(). This
allows for the removal of the 'order' local parameter in both
cpu_smpboot_{alloc,free}().
While making this adjustment, rearrange cpu_smpboot_free() to fold
On 7/8/19 11:11 AM, Adam Williamson wrote:
On Tue, 2019-05-21 at 11:14 -0700, Adam Williamson wrote:
"The release must boot successfully as Xen DomU with releases providing
a functional, supported Xen Dom0 and widely used cloud providers
utilizing Xen."
and change the 'milestone' for the test
On 10/07/2019 14:25, Julien Grall wrote:
>>
>> However, in attempting to review this, I've got some bigger questions.
>>
>> All ARM and x86 HVM (and PVH) guests return true for
>> xc_dom_translated(), so should take the fastpath out of xc_dom_p2m() and
>> never read from dom->p2m_host[].
On Tue, 2019-05-28 at 12:32 +0200, Juergen Gross wrote:
> Add support for core- and socket-scheduling in the Xen hypervisor.
>
> [...]
>
> I have done some very basic performance testing: on a 4 cpu system
> (2 cores with 2 threads each) I did a "make -j 4" for building the
> Xen
> hypervisor.
On 10.07.2019 14:54, Norbert Manthey wrote:
> Guests can issue grant table operations and provide guest controlled
> data to them. This data is used as index for memory loads after bound
> checks have been done. Depending on the grant table version, the
> size of elements in containers differ. As
On 10.07.2019 14:54, Norbert Manthey wrote:
> Guests can issue grant table operations and provide guest controlled
> data to them. This data is used as index for memory loads after bound
> checks have been done. To avoid speculative out-of-bound accesses, we
> use the array_index_nospec macro
Hi,
>>
>> I am interested whether we should do something with omap5-wugen-mpu. I
>> found that crossbar is connected to GIC. And on some schemes in trm it
>> is connected via omap5-wugen-mpu. So, it is not clear for me whether it
>> should be handled in xen.
>
Also, I am interested in how to
flight 138882 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138882/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 138573
Tests which did not
flight 138881 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138881/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass
test-amd64-i386-xl-pvshim12
31 matches
Mail list logo