flight 128989 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128989/
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
test-amd64-amd64-xl-qemuu
On 16/10/2018 10:38, Stefano Stabellini wrote:
> xen_create_contiguous_region has now only an implementation if
> CONFIG_XEN_PV is defined. However, on ARM we never set CONFIG_XEN_PV but
> we do have an implementation of xen_create_contiguous_region which is
> required for swiotlb-xen to work corre
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
test-amd64-i386-xl
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 veri
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
test-amd64-amd64-xl-qemuu
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
Tests
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 Rzeszute
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 switch
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 feat
> On Oct 25, 2018, at 16:00, Andy Lutomirski wrote:
>
> 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 fsba
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 as
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
test-amd64-amd64-xl-qemuu
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 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 10/24/18 8:52 PM, Tamas K Lengyel wrote:
> >
This run is configured for baseline tests only.
flight 75502 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75502/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
Hi all,
I just discussed this patch with Boris in private, his opinions(Boris,
please correct me if any misunderstood) are:
1. With/without the check, both are incorrect, he thought we need to
prevented unalloc'd free at here.
2. On freeing, if upper layer already checked the memory was DMA-a
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 Geor
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 boundari
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 10/25/2018
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 Lengye
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 c637c60273447736b06be
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 was
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*
___
Xen-dev
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
https://lists
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
https://lists.xenproje
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 upda
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, s
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 different
On Thu, Oct 25, 2018 at 11:23 AM Dario Faggioli wrote:
>
> 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 y
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 ma
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, wr
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 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 different
>>> privilege levels. Getting this working would make it safe t
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.
>
> Signed-off-b
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 pre
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 saveresto
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 +0100
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 ste
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 mean
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, Oct 25, 2018 at 10:01 AM Dario Faggioli wrote:
>
> On Wed, 2018-10-24 at 09:24 -0600, 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.
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 the
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 n
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:
>> Com
On Wed, 2018-10-24 at 09:24 -0600, 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 hy
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 05
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
This is very dangerous from a security point of view, because a missing entry
will cause L2's action to be interpreted as L1's action.
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 | 3 ++-
1 fi
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
--- a/xen
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 Be
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
instru
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 Anis
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 - i
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,
>>> uns
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
>>> space.
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.
https://github.com/Xilinx/xen/tree/xilin
>>> 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 t
> 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 to
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 !iommu_us
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.
Yo
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 byte
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 cert
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 i
>>> 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 LAPIC
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. I'm
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;
>> }
>>
>> +stati
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 b
1 - 100 of 133 matches
Mail list logo