flight 128968 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128968/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
I did not realized range_straddles_page_boundary() only available
on xen-swiotlb, please ignore this patch.
Sorry for the bother.
Thanks,
Joe
On 10/25/18 5:16 PM, Joe Jin wrote:
> xen_destroy_contiguous_region() used to exchange physically
> contiguous memory with hypervisor, but it does not
flight 128979 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128979/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 128974
This run is configured for baseline tests only.
flight 75505 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75505/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
flight 128967 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128967/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-saverestore.2 fail REGR.
vs. 128855
xen_destroy_contiguous_region() used to exchange physically
contiguous memory with hypervisor, but it does not verify
that the memory is physically contiguous or no, passing
non-contiguous memory to xen_destroy_contiguous_region()
will lead kernel panic.
Signed-off-by: Joe Jin
Cc: Konrad
On Wed, Oct 24, 2018 at 12:16 PM Andy Lutomirski wrote:
>
> On Tue, Oct 23, 2018 at 11:43 AM Chang S. Bae
> wrote:
> > +/*
> > + * Interrupts are disabled here. Out of line to be protected from kprobes.
> > + */
> > +static noinline __kprobes unsigned long rd_inactive_gsbase(void)
> > +{
> > +
On 26/10/2018 00:11, Andy Lutomirski wrote:
> On Thu, Oct 25, 2018 at 4:09 PM Andrew Cooper
> wrote:
>> On 25/10/2018 07:09, Juergen Gross wrote:
>>> On 24/10/2018 21:41, Andrew Cooper wrote:
On 24/10/18 20:16, Andy Lutomirski wrote:
> On Tue, Oct 23, 2018 at 11:43 AM Chang S. Bae
On Thu, Oct 25, 2018 at 4:09 PM Andrew Cooper wrote:
>
> On 25/10/2018 07:09, Juergen Gross wrote:
> > On 24/10/2018 21:41, Andrew Cooper wrote:
> >> On 24/10/18 20:16, Andy Lutomirski wrote:
> >>> On Tue, Oct 23, 2018 at 11:43 AM Chang S. Bae
> >>> wrote:
> The helper functions will
On 25/10/2018 07:09, Juergen Gross wrote:
> On 24/10/2018 21:41, Andrew Cooper wrote:
>> On 24/10/18 20:16, Andy Lutomirski wrote:
>>> On Tue, Oct 23, 2018 at 11:43 AM Chang S. Bae
>>> wrote:
The helper functions will switch on faster accesses to FSBASE and GSBASE
when the FSGSBASE
On Thu, Oct 25, 2018 at 12:32 AM Bae, Chang Seok
wrote:
>
>
> > On Oct 24, 2018, at 12:16, Andy Lutomirski wrote:
> >
> > On Tue, Oct 23, 2018 at 11:43 AM Chang S. Bae
> > wrote:
> >> void x86_fsbase_write_cpu(unsigned long fsbase)
> >> {
> >> - /*
> >> -* Set the selector to 0
flight 128976 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128976/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 128974
flight 128966 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128966/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore.2 fail
REGR. vs. 128900
flight 75503 examine real [real]
http://osstest.xensource.com/osstest/logs/75503/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
On 10/25/18 11:11 PM, Tamas K Lengyel wrote:
> On Thu, Oct 25, 2018 at 9:08 AM Tamas K Lengyel
> wrote:
>>
>> On Thu, Oct 25, 2018 at 9:02 AM Razvan Cojocaru
>> wrote:
>>>
>>> On 10/25/18 5:55 PM, Tamas K Lengyel wrote:
On Thu, Oct 25, 2018 at 8:24 AM Razvan Cojocaru
wrote:
>
On 25/10/18 19:35, Tamas K Lengyel wrote:
> On Thu, Oct 25, 2018 at 12:13 PM Andrew Cooper
> wrote:
>> On 25/10/18 18:58, Tamas K Lengyel wrote:
>>> On Thu, Oct 25, 2018 at 11:43 AM Andrew Cooper
>>> wrote:
On 25/10/18 18:35, Tamas K Lengyel wrote:
> On Thu, Oct 25, 2018 at 11:02 AM
On 18/09/18 12:53, Jan Beulich wrote:
> This is needed before enabling any AVX512 insns in the emulator. Change
> the way alignment is enforced at the same time.
>
> Add a check that the buffer won't actually overflow, and while at it
> also convert the check for accesses to not cross page
On Thu, Oct 25, 2018 at 12:13 PM Andrew Cooper
wrote:
>
> On 25/10/18 18:58, Tamas K Lengyel wrote:
> > On Thu, Oct 25, 2018 at 11:43 AM Andrew Cooper
> > wrote:
> >> On 25/10/18 18:35, Tamas K Lengyel wrote:
> >>> On Thu, Oct 25, 2018 at 11:02 AM George Dunlap
> >>> wrote:
> On
On 18/09/18 12:53, Jan Beulich wrote:
> @@ -1187,6 +1188,11 @@ static int _get_fpu(
> return X86EMUL_UNHANDLEABLE;
> break;
>
> +case X86EMUL_FPU_opmask:
> +if ( !(xcr0 & X86_XCR0_SSE) || !(xcr0 & X86_XCR0_OPMASK) )
> +return X86EMUL_UNHANDLEABLE;
>
On 25/10/18 18:58, Tamas K Lengyel wrote:
> On Thu, Oct 25, 2018 at 11:43 AM Andrew Cooper
> wrote:
>> On 25/10/18 18:35, Tamas K Lengyel wrote:
>>> On Thu, Oct 25, 2018 at 11:02 AM George Dunlap
>>> wrote:
On 10/25/2018 05:55 PM, Andrew Cooper wrote:
> On 24/10/18 16:24, Tamas K
flight 128974 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128974/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0019375fbc89e4d7cfebe29e288b74731bd9f456
baseline version:
ovmf
On Thu, Oct 25, 2018 at 11:43 AM Andrew Cooper
wrote:
>
> On 25/10/18 18:35, Tamas K Lengyel wrote:
> > On Thu, Oct 25, 2018 at 11:02 AM George Dunlap
> > wrote:
> >> On 10/25/2018 05:55 PM, Andrew Cooper wrote:
> >>> On 24/10/18 16:24, Tamas K Lengyel wrote:
> > A solution to this issue
On 18.10.18 16:20, Julien Grall wrote:
> do_unexpected_traps() is moved to traps.h while init_traps() and
> hyp_traps_vectors() are moved to setup.h.
>
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
On 18.10.18 16:21, Julien Grall wrote:
> None of the platforms are using the p2m helpers.
>
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 18.10.18 16:21, Julien Grall wrote:
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 18.10.18 16:21, Julien Grall wrote:
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 18.10.18 16:21, Julien Grall wrote:
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 18.10.18 16:21, Julien Grall wrote:
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 18.10.18 16:21, Julien Grall wrote:
> Also, include smccc.h instead of psci.h.
>
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 18.10.18 16:21, Julien Grall wrote:
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 23.10.18 21:17, Julien Grall wrote:
> Devices that expose their interrupt status registers via system
> registers (e.g. Statistical profiling, CPU PMU, DynamIQ PMU, arch timer,
> vgic (although unused by Linux), ...) rely on a context synchronising
> operation on the CPU to ensure that the
On 25.10.18 17:22, Julien Grall wrote:
> You misread what I wrote. They are not needed to cover the vGIC for
> GICv2 platform. However they are still necessary, for instance, for
> the timer as it is accessible via system registers.
Ah, OK.
> Here the isb() sits between ack() and do_IRQ().
>
On 25/10/18 18:35, Tamas K Lengyel wrote:
> On Thu, Oct 25, 2018 at 11:02 AM George Dunlap
> wrote:
>> On 10/25/2018 05:55 PM, Andrew Cooper wrote:
>>> On 24/10/18 16:24, Tamas K Lengyel wrote:
> A solution to this issue was proposed, whereby Xen synchronises siblings
> on vmexit/entry,
On Thu, Oct 25, 2018 at 11:02 AM George Dunlap wrote:
>
> On 10/25/2018 05:55 PM, Andrew Cooper wrote:
> > On 24/10/18 16:24, Tamas K Lengyel wrote:
> >>> A solution to this issue was proposed, whereby Xen synchronises siblings
> >>> on vmexit/entry, so we are never executing code in two
On Thu, 2018-10-25 at 10:25 -0600, Tamas K Lengyel wrote:
> On Thu, Oct 25, 2018 at 10:01 AM Dario Faggioli
> wrote:
> >
> > Which is indeed very interesting. But, as we're discussing in the
> > other
> > thread, I would, in your case, do some more measurements, varying
> > the
> > configuration
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 25 October 2018 15:28
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; xen-devel
> Subject: Re: [Xen-devel] [PATCH v2] x86/mm/p2m: don't needlessly limit
> MMIO
On 10/25/2018 05:50 PM, Andrew Cooper wrote:
> On 25/10/18 17:43, George Dunlap wrote:
>> On 10/25/2018 05:29 PM, Andrew Cooper wrote:
>>> On 25/10/18 16:02, Jan Beulich wrote:
>>> On 25.10.18 at 16:56, wrote:
> On 10/25/2018 03:50 PM, Jan Beulich wrote:
> On 22.10.18 at 16:55,
On 18.10.18 16:21, Julien Grall wrote:
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 18.10.18 16:21, Julien Grall wrote:
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 18.10.18 16:20, Julien Grall wrote:
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 18.10.18 16:20, Julien Grall wrote:
> System registers accessors are self-contained and should not be included
> everywhere in Xen. Move the accessors in sysregs.h and include the file
> when necessary.
>
> With that change, it is not necessary to include processor.h in time.h.
>
>
On 18.10.18 16:20, Julien Grall wrote:
> The HSR defines are pretty much self-contained and not necessary to be
> included everywhere in Xen. So move them in a new header hsr.h.
>
> Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
On 24/10/18 16:24, Tamas K Lengyel wrote:
>> A solution to this issue was proposed, whereby Xen synchronises siblings
>> on vmexit/entry, so we are never executing code in two different
>> privilege levels. Getting this working would make it safe to continue
>> using hyperthreading even in the
flight 128963 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128963/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128942
test-armhf-armhf-libvirt-raw 13
On 18.10.18 16:21, Julien Grall wrote:
> Keep vgic_* helpers in a single place. At the same time remove gic.h
> from event.h since the helpers has now been moved to vgic.h (included by
> domain.h).
>
> Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
On 25/10/18 17:43, George Dunlap wrote:
> On 10/25/2018 05:29 PM, Andrew Cooper wrote:
>> On 25/10/18 16:02, Jan Beulich wrote:
>> On 25.10.18 at 16:56, wrote:
On 10/25/2018 03:50 PM, Jan Beulich wrote:
On 22.10.18 at 16:55, wrote:
>> On Thu, Oct 18, 2018 at 06:46:22PM
On 10/25/2018 05:29 PM, Andrew Cooper wrote:
> On 25/10/18 16:02, Jan Beulich wrote:
> On 25.10.18 at 16:56, wrote:
>>> On 10/25/2018 03:50 PM, Jan Beulich wrote:
>>> On 22.10.18 at 16:55, wrote:
> On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
>> An easy first
On 18.10.18 16:20, Julien Grall wrote:
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 25/10/18 16:02, Jan Beulich wrote:
On 25.10.18 at 16:56, wrote:
>> On 10/25/2018 03:50 PM, Jan Beulich wrote:
>> On 22.10.18 at 16:55, wrote:
On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
> An easy first step here is to remove Xen's directmap, which will
On 10/25/18 9:10 AM, Boris Ostrovsky wrote:
> On 10/25/18 10:23 AM, Joe Jin wrote:
>> On 10/25/18 4:45 AM, Boris Ostrovsky wrote:
>>> On 10/24/18 10:43 AM, Joe Jin wrote:
On 10/24/18 6:57 AM, Boris Ostrovsky wrote:
> On 10/24/18 9:02 AM, Konrad Rzeszutek Wilk wrote:
>> On Tue, Oct 23,
On Thu, 25 Oct 2018, Julien Grall wrote:
> On 10/25/18 3:47 PM, Milan Boberic wrote:
> > > I was asking the Xen configuration (xen/.config) to know what you have
> > > enabled in Xen.
> >
> > Oh, sorry, because I'm building xen from git repository here is the
> > link to it where you can check
On Thu, 25 Oct 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 10/24/18 1:24 AM, Stefano Stabellini wrote:
> > On Tue, 23 Oct 2018, Milan Boberic wrote:
> > I don't have any other things to suggest right now. You should be able
> > to measure an overall 2.5us IRQ latency (if the interrupt rate is
On 10/25/18 10:23 AM, Joe Jin wrote:
> On 10/25/18 4:45 AM, Boris Ostrovsky wrote:
>> On 10/24/18 10:43 AM, Joe Jin wrote:
>>> On 10/24/18 6:57 AM, Boris Ostrovsky wrote:
On 10/24/18 9:02 AM, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 23, 2018 at 08:09:04PM -0700, Joe Jin wrote:
>>
On 10/25/18 8:36 AM, Juergen Gross wrote:
> On 11/10/2018 13:03, Joao Martins wrote:
>> On 10/11/2018 06:05 AM, Juergen Gross wrote:
>>> On 10/10/2018 18:57, Boris Ostrovsky wrote:
On 10/10/18 11:53 AM, Juergen Gross wrote:
> On 10/10/2018 17:09, Joao Martins wrote:
>> On 10/09/2018
Signed-off-by: Andrew Cooper
---
CC: Sergey Dyasli
CC: Jan Beulich
CC: Wei Liu
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/hvm/vmx/vvmx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 9390705..d1c8a41 100644
---
Now that nvmx_handle_vmx_insn() performs all VT-x instruction checks, there is
no need for redundant checking in vmx_inst_check_privilege(). Remove it, and
take out the vmxon_check boolean which was plumbed through decode_vmx_inst().
Signed-off-by: Andrew Cooper
---
CC: Sergey Dyasli
CC: Jan
Here are some of the easier fixes following on from the XSA-278 investigation.
This series removes the duplicated checks left over from the security fix. I
did have some further plans, but the embargo breaking early means I haven't
had time to get them ready for posting.
A longer term plan is to
This is a stopgap solution until the toolstack side of initialisation can be
sorted out, but it does result in the nvmx_vcpu_in_vmx() predicate working
correctly even when nested virt hasn't been enabled for the domain.
Update nvmx_handle_vmx_insn() to include the in-vmx mode check (for all
On 18.10.18 16:20, Julien Grall wrote:
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 18.10.18 16:20, Julien Grall wrote:
> The macro VABORT_GEN_BY_GUEST is only used by the trap code. So move it
> to trap.h.
>
> While moving the code, convert is to a static inline to allow typecheck.
>
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
On 18.10.18 16:20, Julien Grall wrote:
> At the moment, CPU Identification is spread accross cpu.c, cpufeature.c,
> processor.h, cpufeature.h. It would be better to keep everything
> together in a single place.
>
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii
On Thu, Oct 25, 2018 at 9:02 AM Razvan Cojocaru
wrote:
>
> On 10/25/18 5:55 PM, Tamas K Lengyel wrote:
> > On Thu, Oct 25, 2018 at 8:24 AM Razvan Cojocaru
> > wrote:
> >>
> >> On 10/24/18 8:52 PM, Tamas K Lengyel wrote:
> >>> On Wed, Oct 24, 2018 at 11:31 AM Tamas K Lengyel
> >>> wrote:
>
>>> On 12.10.18 at 18:29, wrote:
> On Mon, Oct 01, 2018 at 07:42:12AM -0600, Jan Beulich wrote:
>> The system Intel have handed me for AVX512 emulator work ("Gigabyte
>> Technology Co., Ltd. X299 AORUS Gaming 3 Pro/X299 AORUS Gaming 3
>> Pro-CF, BIOS F3 12/28/2017") would not come up under Xen -
On 10/25/18 5:55 PM, Tamas K Lengyel wrote:
> On Thu, Oct 25, 2018 at 8:24 AM Razvan Cojocaru
> wrote:
>>
>> On 10/24/18 8:52 PM, Tamas K Lengyel wrote:
>>> On Wed, Oct 24, 2018 at 11:31 AM Tamas K Lengyel
>>> wrote:
On Wed, Oct 24, 2018 at 11:20 AM Razvan Cojocaru
wrote:
>
>>> On 25.10.18 at 16:56, wrote:
> On 10/25/2018 03:50 PM, Jan Beulich wrote:
> On 22.10.18 at 16:55, wrote:
>>> On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
An easy first step here is to remove Xen's directmap, which will mean
that guests general RAM isn't mapped
>>> On 25.10.18 at 16:36, wrote:
> On 25/10/18 15:28, Jan Beulich wrote:
> On 17.10.18 at 16:24, wrote:
>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -2081,14 +2081,11 @@ static unsigned int mmio_order(const struct domain
> *d,
>>>
On 10/25/2018 03:50 PM, Jan Beulich wrote:
On 22.10.18 at 16:55, wrote:
>> On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
>>> An easy first step here is to remove Xen's directmap, which will mean
>>> that guests general RAM isn't mapped by default into Xen's address
>>>
On Thu, Oct 25, 2018 at 8:24 AM Razvan Cojocaru
wrote:
>
> On 10/24/18 8:52 PM, Tamas K Lengyel wrote:
> > On Wed, Oct 24, 2018 at 11:31 AM Tamas K Lengyel
> > wrote:
> >>
> >> On Wed, Oct 24, 2018 at 11:20 AM Razvan Cojocaru
> >> wrote:
> >>>
> >>> On 10/24/18 8:09 PM, Tamas K Lengyel wrote:
>
On 10/25/18 3:47 PM, Milan Boberic wrote:
I was asking the Xen configuration (xen/.config) to know what you have
enabled in Xen.
Oh, sorry, because I'm building xen from git repository here is the
link to it where you can check the file you mentioned.
>>> On 22.10.18 at 16:55, wrote:
> On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
>> An easy first step here is to remove Xen's directmap, which will mean
>> that guests general RAM isn't mapped by default into Xen's address
>> space. This will come with some performance hit, as
> I was asking the Xen configuration (xen/.config) to know what you have
> enabled in Xen.
Oh, sorry, because I'm building xen from git repository here is the
link to it where you can check the file you mentioned.
https://github.com/Xilinx/xen/tree/xilinx/versal/xen
> It might, OTOH, be wise
On 25/10/18 15:28, Jan Beulich wrote:
On 17.10.18 at 16:24, wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -2081,14 +2081,11 @@ static unsigned int mmio_order(const struct domain
>> *d,
>> unsigned long start_fn, unsigned long nr)
>>> On 17.10.18 at 16:24, wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -2081,14 +2081,11 @@ static unsigned int mmio_order(const struct domain *d,
> unsigned long start_fn, unsigned long nr)
> {
> /*
> - * Note that the
On 10/24/18 8:52 PM, Tamas K Lengyel wrote:
> On Wed, Oct 24, 2018 at 11:31 AM Tamas K Lengyel
> wrote:
>>
>> On Wed, Oct 24, 2018 at 11:20 AM Razvan Cojocaru
>> wrote:
>>>
>>> On 10/24/18 8:09 PM, Tamas K Lengyel wrote:
On Tue, Oct 23, 2018 at 6:37 AM Razvan Cojocaru
wrote:
>
On 10/25/18 4:45 AM, Boris Ostrovsky wrote:
> On 10/24/18 10:43 AM, Joe Jin wrote:
>> On 10/24/18 6:57 AM, Boris Ostrovsky wrote:
>>> On 10/24/18 9:02 AM, Konrad Rzeszutek Wilk wrote:
On Tue, Oct 23, 2018 at 08:09:04PM -0700, Joe Jin wrote:
> Commit 4855c92dbb7 "xen-swiotlb: fix the check
On 10/25/18 3:11 PM, Andrii Anisov wrote:
Hello Julien,
Hi,
On 24.10.18 17:41, Julien Grall wrote:
vGIC is not only about GICv2. It also covers GICv3 that is accessible
via system registers.
Yes, I know. But, as you state below, for GICv2 based systems those
barriers are not needed.
Hello Julien,
On 24.10.18 17:41, Julien Grall wrote:
> vGIC is not only about GICv2. It also covers GICv3 that is accessible
> via system registers.
Yes, I know. But, as you state below, for GICv2 based systems those
barriers are not needed.
>>>rely on a context synchronising
>>> operation
>>> On 25.10.18 at 16:00, wrote:
> On 25/10/18 13:35, Jan Beulich wrote:
> On 24.10.18 at 15:45, wrote:
>>> in order to make builds reproducible.
>>> See https://reproducible-builds.org/ for why this is good.
>> But is this something everyone wants, unconditionally? I'm
>> generally happy to
>>> On 25.10.18 at 15:10, wrote:
> On 25.10.2018 14:55, Jan Beulich wrote:
> On 18.10.18 at 11:02, wrote:
>>> @@ -157,6 +157,19 @@
>>> #define VM_EVENT_X86_CR42
>>> #define VM_EVENT_X86_XCR0 3
>>>
>>> +struct x86_selector_reg {
>>> +union
>>> +{
>>> +uint64_t
On 10/25/18 1:36 PM, Milan Boberic wrote:
On Thu, Oct 25, 2018 at 1:30 PM Julien Grall wrote:
Hi Milan,
Hi Julien,
Sorry if it was already asked. Can you provide your .config for your
test?
Yes of course, bare-metal's .cfg file is in it's in attachment (if
that is what you asked :) ).
On 25/10/18 13:35, Jan Beulich wrote:
On 24.10.18 at 15:45, wrote:
>> in order to make builds reproducible.
>> See https://reproducible-builds.org/ for why this is good.
> But is this something everyone wants, unconditionally? I'm
> generally happy to have this basic indication of when a
Hi Dario,
On 10/25/18 2:44 PM, Dario Faggioli wrote:
On Thu, 2018-10-25 at 14:36 +0200, Milan Boberic wrote:
On Thu, Oct 25, 2018 at 1:30 PM Julien Grall
wrote:
Do you have DEBUG enabled?
I'm not sure where exactly should I disable it. If you check line 18
in xl dmesg file in attachment
>>> On 25.10.18 at 15:02, wrote:
> On 25/10/18 13:51, Jan Beulich wrote:
> On 15.10.18 at 14:06, wrote:
>>> From the debugging, we see that PPR/IRR/ISR appear to retain their state
>>> across the mwait, and there is nothing in the manual which I can see
>>> discussing the interaction of
On Thu, 2018-10-25 at 14:36 +0200, Milan Boberic wrote:
> On Thu, Oct 25, 2018 at 1:30 PM Julien Grall
> wrote:
> > Do you have DEBUG enabled?
>
> I'm not sure where exactly should I disable it. If you check line 18
> in xl dmesg file in attachment it says debug=n, it's output of xl
> dmesg.
On 10/25/18 4:10 PM, Alexandru Stefan ISAILA wrote:
> On 25.10.2018 14:55, Jan Beulich wrote:
> On 18.10.18 at 11:02, wrote:
>>> +struct x86_selector_reg {
>>> +union
>>> +{
>>> +uint64_t bytes;
>>> +struct
>>> +{
>>> +uint32_t base;
>>> +
flight 75500 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/75500/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
On 25.10.2018 14:55, Jan Beulich wrote:
On 18.10.18 at 11:02, wrote:
>> --- a/xen/arch/x86/vm_event.c
>> +++ b/xen/arch/x86/vm_event.c
>> @@ -122,11 +122,60 @@ void vm_event_monitor_next_interrupt(struct vcpu *v)
>> v->arch.monitor.next_interrupt_enabled = true;
>> }
>>
>>
On 25/10/18 13:51, Jan Beulich wrote:
On 15.10.18 at 14:06, wrote:
>> From the debugging, we see that PPR/IRR/ISR appear to retain their state
>> across the mwait, and there is nothing in the manual which I can see
>> discussing the interaction of LAPIC state and C states.
> Is it perhaps a
flight 128957 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128957/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
128861
>>> On 15.10.18 at 14:06, wrote:
> From the debugging, we see that PPR/IRR/ISR appear to retain their state
> across the mwait, and there is nothing in the manual which I can see
> discussing the interaction of LAPIC state and C states.
Is it perhaps a bad idea to go idle with an un-acked
On 11/10/2018 13:03, Joao Martins wrote:
> On 10/11/2018 06:05 AM, Juergen Gross wrote:
>> On 10/10/2018 18:57, Boris Ostrovsky wrote:
>>> On 10/10/18 11:53 AM, Juergen Gross wrote:
On 10/10/2018 17:09, Joao Martins wrote:
> On 10/09/2018 05:09 PM, Juergen Gross wrote:
>>
On Thu, Oct 25, 2018 at 1:30 PM Julien Grall wrote:
>
> Hi Milan,
Hi Julien,
> Sorry if it was already asked. Can you provide your .config for your
> test?
Yes of course, bare-metal's .cfg file is in it's in attachment (if
that is what you asked :) ).
> Do you have DEBUG enabled?
I'm not
>>> On 24.10.18 at 15:45, wrote:
> in order to make builds reproducible.
> See https://reproducible-builds.org/ for why this is good.
But is this something everyone wants, unconditionally? I'm
generally happy to have this basic indication of when a certain
image was built; I regret that ELF
>>> On 23.10.18 at 16:33, wrote:
> On the subject of having NMIs disabled, it is definitely a more robust
> way of handing off between components. Until Xen has transitioned the
> BSP and APs into 64bit mode and fully set the IDT up, NMIs are fatal to
> the system.
I don't follow the AP part
I have a matrix of various qemu.git#stable-x.y that build against
xen.git#staging*. Since some months qemu.git#stable-2.x fails to build against
xen.git#staging. qemu-2.10+ works with staging. To me it is not clear how to
fix this failure:
On 10/25/18 3:54 AM, Juergen Gross wrote:
> A Xen PVH guest has no associated qemu device model, so trying to
> unplug any emulated devices is making no sense at all.
>
> Bail out early from xen_unplug_emulated_devices() when running as PVH
> guest. This will avoid issuing the boot message:
>
> [
>>> On 18.10.18 at 11:02, wrote:
> --- a/xen/arch/x86/vm_event.c
> +++ b/xen/arch/x86/vm_event.c
> @@ -122,11 +122,60 @@ void vm_event_monitor_next_interrupt(struct vcpu *v)
> v->arch.monitor.next_interrupt_enabled = true;
> }
>
> +static void vm_event_pack_segment_register(enum
On 10/24/18 10:43 AM, Joe Jin wrote:
> On 10/24/18 6:57 AM, Boris Ostrovsky wrote:
>> On 10/24/18 9:02 AM, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Oct 23, 2018 at 08:09:04PM -0700, Joe Jin wrote:
Commit 4855c92dbb7 "xen-swiotlb: fix the check condition for
xen_swiotlb_free_coherent"
Hi Milan,
On 10/25/18 11:09 AM, Milan Boberic wrote:
Hi,
On Wed, Oct 24, 2018 at 2:24 AM Stefano Stabellini
wrote:
It is good that there are no physical interrupts interrupting the cpu.
serrors=panic makes the context switch faster. I guess there are not
enough context switches to make a
>>> On 12.10.18 at 18:37, wrote:
> Furthermore, I believe even #MC is blocked by the MOVSS shadow, because
> the purpose of the shadow is to indicate "my stack is not safe to take
> an exception".
Having thought about this some more over lunch, I'm afraid I
now think that both variants are
1 - 100 of 122 matches
Mail list logo