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 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 a notion, that the segment base is
>> -* overwritten, which will b
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:
[0.00] Xen Platform PCI: unrecognised magic value
On Wed, Oct 24, 2018 at 03:45:22PM +0200, Bernhard M. Wiedemann wrote:
> in order to make builds reproducible.
> See https://reproducible-builds.org/ for why this is good.
>
> We only add the option, if ld understands it.
>
> Signed-off-by: Bernhard M. Wiedemann
Reviewed-by: Wei Liu
_
On Wed, Oct 24, 2018 at 11:32:01AM +0100, Ian Jackson wrote:
> Something is wrong with the freebsd repositories. This causes freebsd
> host installation to fail. This problem has persisted for a while now
> and is blocking other work.
>
> For now, drop these. The jobs being dropped are
>
>>> On 12.10.18 at 18:37, wrote:
> On 12/10/18 16:58, Jan Beulich wrote:
>> First of all, hvm_intsrc_mce was not considered here at all, yet nothing
>> blocks #MC (other than an already in-progress #MC, but dealing with this
>> is not the purpose of this patch).
>
> I don't believe we've got suff
>>> On 15.10.18 at 13:19, wrote:
> On Fri, Oct 12, 2018 at 08:14:36AM -0600, Jan Beulich wrote:
>> >>> On 04.10.18 at 17:43, wrote:
>> > It is used by PV code only.
>>
>> And wrongly so - the same is needed for a PVH Dom0 afaict.
>
> Yes, looking at the models affected by this issue according t
>>> On 20.10.18 at 01:10, wrote:
> On Mon, 8 Oct 2018, Jan Beulich wrote:
>> >>> On 05.10.18 at 20:47, wrote:
>> > @@ -391,31 +394,73 @@ static void dump_console_ring_key(unsigned char key)
>> > free_xenheap_pages(buf, order);
>> > }
>> >
>> > -/* CTRL- switches input direction between Xe
>>> On 17.10.18 at 15:30, wrote:
> On 17/10/18 14:26, Razvan Cojocaru wrote:
>> On 10/4/18 6:20 PM, Jan Beulich wrote:
>>> Roger recently has posted a patch adding rangeset_merge(), which I think
>>> is more general than your rangeset_copy(). That said, I'm in no way
>>> convinced copying (and the
>>> On 19.10.18 at 16:30, wrote:
> On Fri, Oct 12, 2018 at 03:32:59AM -0600, Jan Beulich wrote:
>>In commit 303066fdb1e ("VMX: fix interaction of APIC-V and Viridian
>>emulation") I screwed up quite heavily: Instead of clearing SVI, RVI was
>>cleared. Furthermore, unconditional clearing of SVI is
Hello,
Is it possible to specify vendor and product strings for disk through xl.cfg or
xenstore or something else?
Something like
https://www.redhat.com/archives/libvir-list/2012-November/msg00205.html.
___
Xen-devel mailing list
Xen-devel@lists.xenpr
>>> On 19.10.18 at 18:57, wrote:
> Hello,
>
> I noticed this most recently in the AVIC series from Janakarajan. The
> global svm_avic boolean was left off-by-default because it doesn't work
> with nested virt yet. The code in question was actually inherited from
> the VT-x side, and the general
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 measurable difference.
Yes, when I did:
grep ctxt
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 poin
>>> 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 n
>>> 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:
>>> On 22.10.18 at 14:58, wrote:
> This removes all use of keyhandler_scratch as a bounce-buffer for the
> rendered
> string.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> Reviewed-by: Wei Liu
> Reviewed-by: Jan Beulich
> ---
> v2:
> * Fix %pd typo
> * Use ->bits for cpumask
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 not
too high).
Is it number you measured on Xen 4.11 fla
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 a8b5750901faa63ff5570
>>> 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 equall
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 meas
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" only
>>> 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 x86_segmen
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:
>
> [
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:
qemu-2.9-20170907T112512.4cd42653f5/include/hw/xen/xen_
>>> 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 her
>>> 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 image
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 sur
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:
>> xenbus_va_dev
>>> 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 interru
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
test-amd64-i
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
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
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 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. I'm
>>> 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
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 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
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 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 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
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 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
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/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 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 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 to
>>> 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
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 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/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 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 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 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 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 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 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:
> 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 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
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
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
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
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
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 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 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 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 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 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, 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 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 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 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 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 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 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 saveresto
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
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 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:
> 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/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 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
> -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 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 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, 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 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 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 upda
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 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
1 - 100 of 133 matches
Mail list logo
