Yes, sorry this was aimed at Andrew and Jan(when he will be in).
Alex
On 24.10.2018 19:48, Tamas K Lengyel wrote:
> On Tue, Oct 23, 2018 at 2:37 AM Alexandru Stefan ISAILA
> wrote:
>>
>> Any thoughts on this are appreciated.
>
> FYI I already acked this.
>
> Tamas
>
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 feature is enabled.
>>>
>>> Accessing user GSBASE
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"
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 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
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)
> 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 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 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;
>> }
>>
>>
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
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 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 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 -
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 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/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 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
>>> 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
>>> 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 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:
>
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 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 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 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;
>>> +
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 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 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 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 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 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
>>> 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 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 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.
>>> 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,
>>>
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
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
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 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
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 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 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 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 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/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:
> 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 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 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 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
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
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
---
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 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 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 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
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 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 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
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*
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
> -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 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 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: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 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 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 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 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.
>
>
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 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
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 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
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 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
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
flight 128971 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128971/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c637c60273447736b06be971d647cd5e5d2035b8
baseline version:
ovmf
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 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 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
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 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 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 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
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 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
This run is configured for baseline tests only.
flight 75499 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/75499/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
>>> On 12.10.18 at 19:18, wrote:
>> -Original Message-
>> From: Woods, Brian [mailto:brian.wo...@amd.com]
>> Sent: 12 October 2018 18:14
>> To: Paul Durrant
>> Cc: xen-devel@lists.xenproject.org; Suthikulpanit, Suravee
>> ; Woods, Brian
>> Subject: Re: [PATCH] amd-iommu: get rid of
>>> On 15.10.18 at 11:56, wrote:
> Introduce a macro, __symbol,
Irrespective of all other remarks already made, and irrespective
of me not being convinced that we really need to wrap _text,
_stext, and alike - no new name space violations please. I.e.
no leading underscores in header files, and
>>> On 15.10.18 at 11:56, wrote:
> Use __symbol everywhere _stext, _etext, etc. are used. Technically, it
> is only required when comparing pointers, but use it everywhere to avoid
> confusion.
While the description slightly limits the scope, I'm not sure that's what
you mean. What about e.g.
>>> On 22.10.18 at 14:57, wrote:
> This removes all use of keyhandler_scratch as a bounce-buffer for the rendered
> string. In some cases, collapse combine adjacent printk()'s which are writing
> parts of the same line.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> Reviewed-by:
1 - 100 of 122 matches
Mail list logo
