On Thu, Jun 18, 2020 at 02:56:17AM +0200, Michał Leszczyński wrote:
> - 18 cze 2020 o 1:29, Kang, Luwei luwei.k...@intel.com napisał(a):
>
> >> > > How does KVM deal with this, do they insert/modify trace packets on
> >> > > trapped and emulated instructions by the VMM?
> >> >
> >> > The KVM i
On 15.06.2020 16:15, Andrew Cooper wrote:
> This is some work in light of IvyBridge not gaining microcode to combat SRBDS
> / XSA-320. It is a mix of some work I'd planned for 4.15, and some patches
> posted already and delayed due to dependence's I'd discovered after-the-fact.
>
> This provides
On Wed, Jun 17, 2020 at 10:20:20PM +0200, Michał Leszczyński wrote:
> - 17 cze 2020 o 18:19, Andrew Cooper andrew.coop...@citrix.com napisał(a):
>
> > On 17/06/2020 04:02, Tamas K Lengyel wrote:
> >> On Tue, Jun 16, 2020 at 2:17 PM Andrew Cooper
> >> wrote:
> >>> On 16/06/2020 19:47, Michał
On Wed, Jun 17, 2020 at 09:13:05PM +0200, Michał Leszczyński wrote:
> - 16 cze 2020 o 19:23, Roger Pau Monné roger@citrix.com napisał(a):
>
> > On Tue, Jun 16, 2020 at 05:22:06PM +0200, Michał Leszczyński wrote:
> >> +buf_order = get_order_from_bytes(a.size);
> >> +
> >> +i
On Wed, Jun 17, 2020 at 08:56:57PM +0200, Michał Leszczyński wrote:
> - 17 cze 2020 o 17:14, Andrew Cooper andrew.coop...@citrix.com napisał(a):
>
> > On 17/06/2020 13:51, Roger Pau Monné wrote:
> >> On Wed, Jun 17, 2020 at 01:54:45PM +0200, Michał Leszczyński wrote:
> >>> - 17 cze 2020 o
On 18/06/2020 08:18, Jan Beulich wrote:
> On 15.06.2020 16:15, Andrew Cooper wrote:
>> This is some work in light of IvyBridge not gaining microcode to combat SRBDS
>> / XSA-320. It is a mix of some work I'd planned for 4.15, and some patches
>> posted already and delayed due to dependence's I'd d
On Thu, Jun 18, 2020 at 08:30:08AM +0200, Jan Beulich wrote:
> On 17.06.2020 18:19, Tamas K Lengyel wrote:
> > While forking VMs running a small RTOS system (Zephyr) a Xen crash has been
> > observed due to a mm-lock order violation while copying the HVM CPU context
> > from the parent. This issue
On 18/06/2020 00:30, Kang, Luwei wrote:
>>> On Wed, Jun 17, 2020 at 01:54:45PM +0200, Michał Leszczyński wrote:
- 17 cze 2020 o 11:09, Roger Pau Monné roger@citrix.com napisał(a):
> 24 Virtual Machine Control Structures -> 24.8 VM-entry Control
> Fields -> 24.8.1 VM-Entry
flight 151175 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151175/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 151065
test-amd64-i386-q
On Thu, Jun 18, 2020 at 08:38:27AM +0200, Jan Beulich wrote:
> * Guests outside of long mode can't have PCID enabled. Drop the
> respective check to make more obvious that there's no security issue
> (from potentially accessing past the mapped page's boundary).
>
> * Only the low 32 bits of CR
On Monday, 15.06.2020 at 17:58, Andrew Cooper wrote:
> On 15/06/2020 15:25, Martin Lucina wrote:
> > Hi,
> >
> > puzzle time: In my continuing explorations of the PVHv2 ABIs for the
> > new MirageOS Xen stack, I've run into some issues with what looks like
> > missed deliveries of events on event c
- 18 cze 2020 o 5:20, Tamas K Lengyel tamas.k.leng...@gmail.com napisał(a):
>> >> +
>> >> +a.mfn = v->arch.hvm.vmx.ipt_state->output_base >> PAGE_SHIFT;
>> >
>> > This will not work for translated domains, ie: a PVH or HVM domain
>> > won't be able to use this interface since it has no
- 18 cze 2020 o 10:52, Roger Pau Monné roger@citrix.com napisał(a):
> On Wed, Jun 17, 2020 at 08:56:57PM +0200, Michał Leszczyński wrote:
>> - 17 cze 2020 o 17:14, Andrew Cooper andrew.coop...@citrix.com
>> napisał(a):
>>
>> > On 17/06/2020 13:51, Roger Pau Monné wrote:
>> >> On Wed,
On Wed, 17 Jun 2020 at 13:33, Gerd Hoffmann wrote:
>
> The following changes since commit 5c24bce3056ff209a1ecc50ff4b7e65b85ad8e74:
>
> Merge remote-tracking branch
> 'remotes/stsquad/tags/pull-testing-and-plugin-160620-2' into staging
> (2020-06-16 14:57:15 +0100)
>
> are available in the Git
On 18.06.2020 11:40, Roger Pau Monné wrote:
> On Thu, Jun 18, 2020 at 08:30:08AM +0200, Jan Beulich wrote:
>> On 17.06.2020 18:19, Tamas K Lengyel wrote:
>>> While forking VMs running a small RTOS system (Zephyr) a Xen crash has been
>>> observed due to a mm-lock order violation while copying the H
On Thu, Jun 18, 2020 at 12:13:30PM +0200, Martin Lucina wrote:
> On Monday, 15.06.2020 at 17:58, Andrew Cooper wrote:
> > On 15/06/2020 15:25, Martin Lucina wrote:
> > > Hi,
> > >
> > > puzzle time: In my continuing explorations of the PVHv2 ABIs for the
> > > new MirageOS Xen stack, I've run into
On Thu, Jun 18, 2020 at 01:07:33PM +0200, Michał Leszczyński wrote:
> - 18 cze 2020 o 10:52, Roger Pau Monné roger@citrix.com napisał(a):
>
> > On Wed, Jun 17, 2020 at 08:56:57PM +0200, Michał Leszczyński wrote:
> >> - 17 cze 2020 o 17:14, Andrew Cooper andrew.coop...@citrix.com
> >>
On 18.06.2020 12:11, Roger Pau Monné wrote:
> On Thu, Jun 18, 2020 at 08:38:27AM +0200, Jan Beulich wrote:
>> * Guests outside of long mode can't have PCID enabled. Drop the
>> respective check to make more obvious that there's no security issue
>> (from potentially accessing past the mapped pa
On Thu, Jun 18, 2020 at 01:01:39PM +0200, Michał Leszczyński wrote:
> - 18 cze 2020 o 5:20, Tamas K Lengyel tamas.k.leng...@gmail.com
> napisał(a):
>
> >> >> +
> >> >> +a.mfn = v->arch.hvm.vmx.ipt_state->output_base >> PAGE_SHIFT;
> >> >
> >> > This will not work for translated domain
On Thu, Jun 18, 2020 at 3:42 AM Roger Pau Monné wrote:
>
> On Thu, Jun 18, 2020 at 08:30:08AM +0200, Jan Beulich wrote:
> > On 17.06.2020 18:19, Tamas K Lengyel wrote:
> > > While forking VMs running a small RTOS system (Zephyr) a Xen crash has
> > > been
> > > observed due to a mm-lock order vio
On Thu, Jun 18, 2020 at 01:49:58PM +0200, Jan Beulich wrote:
> On 18.06.2020 12:11, Roger Pau Monné wrote:
> > On Thu, Jun 18, 2020 at 08:38:27AM +0200, Jan Beulich wrote:
> >> -guest_pdptes = (uint64_t *)(p + (cr3 & ~PAGE_MASK));
> >> +guest_pdptes = __map_domain_page(page) + (cr3 & ~PAGE_
On Thu, Jun 18, 2020 at 12:31 AM Jan Beulich wrote:
>
> On 17.06.2020 18:19, Tamas K Lengyel wrote:
> > While forking VMs running a small RTOS system (Zephyr) a Xen crash has been
> > observed due to a mm-lock order violation while copying the HVM CPU context
> > from the parent. This issue has be
On 18.06.2020 14:39, Tamas K Lengyel wrote:
> On Thu, Jun 18, 2020 at 12:31 AM Jan Beulich wrote:
>>
>> On 17.06.2020 18:19, Tamas K Lengyel wrote:
>>> While forking VMs running a small RTOS system (Zephyr) a Xen crash has been
>>> observed due to a mm-lock order violation while copying the HVM CP
On Thu, Jun 18, 2020 at 06:21:42AM -0600, Tamas K Lengyel wrote:
> On Thu, Jun 18, 2020 at 3:42 AM Roger Pau Monné wrote:
> >
> > On Thu, Jun 18, 2020 at 08:30:08AM +0200, Jan Beulich wrote:
> > > On 17.06.2020 18:19, Tamas K Lengyel wrote:
> > > > While forking VMs running a small RTOS system (Ze
On 18.06.2020 13:55, Roger Pau Monné wrote:
> On Thu, Jun 18, 2020 at 01:01:39PM +0200, Michał Leszczyński wrote:
>> It was previously stated that:
>>
>>> PVH or HVM domain
>>> won't be able to use this interface since it has no way to request the
>>> mapping of a specific mfn into it's physmap.
>>
On Thu, Jun 18, 2020 at 02:46:24PM +0200, Jan Beulich wrote:
> On 18.06.2020 14:39, Tamas K Lengyel wrote:
> > On Thu, Jun 18, 2020 at 12:31 AM Jan Beulich wrote:
> >>
> >> On 17.06.2020 18:19, Tamas K Lengyel wrote:
> >>> While forking VMs running a small RTOS system (Zephyr) a Xen crash has
> >
On Thu, Jun 18, 2020 at 6:52 AM Roger Pau Monné wrote:
>
> On Thu, Jun 18, 2020 at 02:46:24PM +0200, Jan Beulich wrote:
> > On 18.06.2020 14:39, Tamas K Lengyel wrote:
> > > On Thu, Jun 18, 2020 at 12:31 AM Jan Beulich wrote:
> > >>
> > >> On 17.06.2020 18:19, Tamas K Lengyel wrote:
> > >>> While
- 18 cze 2020 o 14:51, Jan Beulich jbeul...@suse.com napisał(a):
> On 18.06.2020 13:55, Roger Pau Monné wrote:
>> On Thu, Jun 18, 2020 at 01:01:39PM +0200, Michał Leszczyński wrote:
>>> It was previously stated that:
>>>
PVH or HVM domain
won't be able to use this interface since it
On 18.06.2020 15:09, Michał Leszczyński wrote:
> - 18 cze 2020 o 14:51, Jan Beulich jbeul...@suse.com napisał(a):
>
>> On 18.06.2020 13:55, Roger Pau Monné wrote:
>>> On Thu, Jun 18, 2020 at 01:01:39PM +0200, Michał Leszczyński wrote:
It was previously stated that:
> PVH or HVM d
On 18.06.2020 15:00, Tamas K Lengyel wrote:
> On Thu, Jun 18, 2020 at 6:52 AM Roger Pau Monné wrote:
>>
>> On Thu, Jun 18, 2020 at 02:46:24PM +0200, Jan Beulich wrote:
>>> On 18.06.2020 14:39, Tamas K Lengyel wrote:
On Thu, Jun 18, 2020 at 12:31 AM Jan Beulich wrote:
>
> On 17.06.202
On 16.06.2020 17:19, Michał Leszczyński wrote:
> --- a/xen/include/asm-x86/msr-index.h
> +++ b/xen/include/asm-x86/msr-index.h
> @@ -621,4 +621,41 @@
> #define MSR_PKGC9_IRTL 0x0634
> #define MSR_PKGC10_IRTL 0x0635
>
> +/* Intel PT MSRs */
> +#
On Thu, Jun 18, 2020 at 7:26 AM Jan Beulich wrote:
>
> On 18.06.2020 15:00, Tamas K Lengyel wrote:
> > On Thu, Jun 18, 2020 at 6:52 AM Roger Pau Monné
> > wrote:
> >>
> >> On Thu, Jun 18, 2020 at 02:46:24PM +0200, Jan Beulich wrote:
> >>> On 18.06.2020 14:39, Tamas K Lengyel wrote:
> On Thu
On Thu, Jun 18, 2020 at 03:09:57PM +0200, Michał Leszczyński wrote:
> - 18 cze 2020 o 14:51, Jan Beulich jbeul...@suse.com napisał(a):
>
> > On 18.06.2020 13:55, Roger Pau Monné wrote:
> >> On Thu, Jun 18, 2020 at 01:01:39PM +0200, Michał Leszczyński wrote:
> >>> It was previously stated that:
On 12.06.2020 17:56, Roger Pau Monne wrote:
> When the IO APIC pin mapped to the ISA IRQ 0 has been configured to
> use fixed delivery mode do not forcefully route interrupts to vCPU 0,
> as the OS might have setup those interrupts to be injected to a
> different vCPU, and injecting to vCPU 0 can c
On Thu, Jun 18, 2020 at 03:43:00PM +0200, Jan Beulich wrote:
> On 12.06.2020 17:56, Roger Pau Monne wrote:
> > When the IO APIC pin mapped to the ISA IRQ 0 has been configured to
> > use fixed delivery mode do not forcefully route interrupts to vCPU 0,
> > as the OS might have setup those interrupt
On 18.06.2020 15:48, Roger Pau Monné wrote:
> On Thu, Jun 18, 2020 at 03:43:00PM +0200, Jan Beulich wrote:
>> On 12.06.2020 17:56, Roger Pau Monne wrote:
>>> When the IO APIC pin mapped to the ISA IRQ 0 has been configured to
>>> use fixed delivery mode do not forcefully route interrupts to vCPU 0,
On Thu, Jun 18, 2020 at 04:08:28PM +0200, Jan Beulich wrote:
> On 18.06.2020 15:48, Roger Pau Monné wrote:
> > On Thu, Jun 18, 2020 at 03:43:00PM +0200, Jan Beulich wrote:
> >> On 12.06.2020 17:56, Roger Pau Monne wrote:
> >>> When the IO APIC pin mapped to the ISA IRQ 0 has been configured to
> >>
On 12.06.2020 17:56, Roger Pau Monne wrote:
> --- a/xen/arch/x86/hvm/vioapic.c
> +++ b/xen/arch/x86/hvm/vioapic.c
> @@ -422,12 +422,13 @@ static void vioapic_deliver(struct hvm_vioapic
> *vioapic, unsigned int pin)
> case dest_LowestPrio:
> {
> #ifdef IRQ0_SPECIAL_ROUTING
> -/*
On 18.06.2020 16:18, Roger Pau Monné wrote:
> On Thu, Jun 18, 2020 at 04:08:28PM +0200, Jan Beulich wrote:
>> On 18.06.2020 15:48, Roger Pau Monné wrote:
>>> On Thu, Jun 18, 2020 at 03:43:00PM +0200, Jan Beulich wrote:
On 12.06.2020 17:56, Roger Pau Monne wrote:
> When the IO APIC pin mapp
On 12.06.2020 17:56, Roger Pau Monne wrote:
> Check whether the emulated device is actually enabled before trying to
> resume the associated timers.
>
> Thankfully all those structures are zeroed at initialization, and
> since the devices are not enabled they are never populated, which
> triggers
While forking VMs running a small RTOS system (Zephyr) a Xen crash has been
observed due to a mm-lock order violation while copying the HVM CPU context
from the parent. This issue has been identified to be due to
hap_update_paging_modes first getting a lock on the gfn using get_gfn. This
call also
On 12.06.2020 17:56, Roger Pau Monne wrote:
> Only call hvm_isa_irq_to_gsi for ISA interrupts, interrupts
> originating from an IO APIC pin already use a GSI and don't need to be
> translated.
>
> I haven't observed any issues from this, but I think it's better to
> use it correctly.
>
> Signed-o
On Thu, Jun 18, 2020 at 04:29:59PM +0200, Jan Beulich wrote:
> On 18.06.2020 16:18, Roger Pau Monné wrote:
> > On Thu, Jun 18, 2020 at 04:08:28PM +0200, Jan Beulich wrote:
> >> On 18.06.2020 15:48, Roger Pau Monné wrote:
> >>> On Thu, Jun 18, 2020 at 03:43:00PM +0200, Jan Beulich wrote:
> On 1
On 18/06/2020 06:22, Oleksandr Andrushchenko wrote:
On 6/4/20 6:31 PM, Stefano Stabellini wrote:
On Thu, 4 Jun 2020, Oleksandr Andrushchenko wrote:
On 6/4/20 4:57 AM, Peng Fan wrote:
Grall ;
Nataliya Korovkina
Subject: UEFI support in ARM DomUs
We have made U-Boot run inside XEN DomU, b
On Thu, Jun 18, 2020 at 04:26:08PM +0200, Jan Beulich wrote:
> On 12.06.2020 17:56, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/vioapic.c
> > +++ b/xen/arch/x86/hvm/vioapic.c
> > @@ -422,12 +422,13 @@ static void vioapic_deliver(struct hvm_vioapic
> > *vioapic, unsigned int pin)
> > cas
On Thu, Jun 18, 2020 at 04:37:57PM +0200, Jan Beulich wrote:
> On 12.06.2020 17:56, Roger Pau Monne wrote:
> > Check whether the emulated device is actually enabled before trying to
> > resume the associated timers.
> >
> > Thankfully all those structures are zeroed at initialization, and
> > sinc
- 17 cze 2020 o 18:19, Andrew Cooper andrew.coop...@citrix.com napisał(a):
> On 17/06/2020 04:02, Tamas K Lengyel wrote:
>> On Tue, Jun 16, 2020 at 2:17 PM Andrew Cooper
>> wrote:
>>> On 16/06/2020 19:47, Michał Leszczyński wrote:
- 16 cze 2020 o 20:17, Andrew Cooper andrew.coop...@
(+ Committers)
On 18/06/2020 02:34, Stefano Stabellini wrote:
On Tue, 16 Jun 2020, Julien Grall wrote:
On Tue, 16 Jun 2020 at 21:57, Stefano Stabellini wrote:
On Tue, 16 Jun 2020, Julien Grall wrote:
On 16/06/2020 02:00, Stefano Stabellini wrote:
On Sat, 13 Jun 2020, Julien Grall wrote:
F
On Thu, Jun 18, 2020 at 04:47:57PM +0200, Jan Beulich wrote:
> On 12.06.2020 17:56, Roger Pau Monne wrote:
> > Only call hvm_isa_irq_to_gsi for ISA interrupts, interrupts
> > originating from an IO APIC pin already use a GSI and don't need to be
> > translated.
> >
> > I haven't observed any issue
On 12.06.2020 17:56, Roger Pau Monne wrote:
> vpt timers are usually added to the per-vCPU list of the vCPU where
> they get setup, but depending on the timer source type that vCPU might
> be different than the one where the interrupt vector gets injected.
>
> For example the PIT timer use a PIC o
On 18.06.2020 16:49, Roger Pau Monné wrote:
> On Thu, Jun 18, 2020 at 04:29:59PM +0200, Jan Beulich wrote:
>> On 18.06.2020 16:18, Roger Pau Monné wrote:
>>> On Thu, Jun 18, 2020 at 04:08:28PM +0200, Jan Beulich wrote:
On 18.06.2020 15:48, Roger Pau Monné wrote:
> On Thu, Jun 18, 2020 at 0
On 18/06/2020 03:58, Volodymyr Babchuk wrote:
Hi Jürgen,
Jürgen Groß writes:
On 13.06.20 00:27, Volodymyr Babchuk wrote:
On Fri, 2020-06-12 at 17:29 +0200, Dario Faggioli wrote:
On Fri, 2020-06-12 at 14:41 +0200, Jürgen Groß wrote:
On 12.06.20 14:29, Julien Grall wrote:
On 12/06/2020 0
On 18.06.2020 16:55, Roger Pau Monné wrote:
> On Thu, Jun 18, 2020 at 04:26:08PM +0200, Jan Beulich wrote:
>> On 12.06.2020 17:56, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/hvm/vioapic.c
>>> +++ b/xen/arch/x86/hvm/vioapic.c
>>> @@ -422,12 +422,13 @@ static void vioapic_deliver(struct hvm_vioapi
On 18.06.2020 17:17, Julien Grall wrote:
>
>
> On 18/06/2020 03:58, Volodymyr Babchuk wrote:
>>
>> Hi Jürgen,
>>
>> Jürgen Groß writes:
>>
>>> On 13.06.20 00:27, Volodymyr Babchuk wrote:
On Fri, 2020-06-12 at 17:29 +0200, Dario Faggioli wrote:
> On Fri, 2020-06-12 at 14:41 +0200, Jürgen
- 16 cze 2020 o 19:23, Roger Pau Monné roger@citrix.com napisał(a):
> On Tue, Jun 16, 2020 at 05:22:06PM +0200, Michał Leszczyński wrote:
>> Provide an interface for privileged domains to manage
>> external IPT monitoring.
>>
>> Signed-off-by: Michal Leszczynski
>
> Thanks for the patch
On 12.06.2020 17:56, Roger Pau Monne wrote:
> The current function has the ISA IRQ 0 hardcoded to GSI 2 for HVM
> domUs. Allow such function to also be used by the hardware domain by
> taking into account the ACPI interrupt overwrites in order to get the
Nit: overrides
> --- a/xen/arch/x86/io_api
On 18.06.2020 17:25, Michał Leszczyński wrote:
> - 16 cze 2020 o 19:23, Roger Pau Monné roger@citrix.com napisał(a):
>> On Tue, Jun 16, 2020 at 05:22:06PM +0200, Michał Leszczyński wrote:
>>> --- a/xen/include/public/hvm/hvm_op.h
>>> +++ b/xen/include/public/hvm/hvm_op.h
>>> @@ -382,6 +382,
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
Jason Andryuk writes ("[PATCH] xl: Allow shutdown wait for domain death"):
> `xl shutdown -w` waits for the first of either domain shutdown or death.
> Shutdown is the halting of the guest operating system, and death is the
> freeing of domain resources.
>
> Allow specifying -w multiple times to w
Paul Durrant writes ("RE: [PATCH for-4.14 v3] tools/xen-ucode: return correct
exit code on failed microcode update"):
> > -Original Message-
> > From: Igor Druzhinin
> > Sent: 17 June 2020 03:19
> > To: xen-devel@lists.xenproject.org
> > Cc: ian.jack...@eu.citrix.com; w...@xen.org; xadimg
On Thu, Jun 18, 2020 at 07:39:04AM -0700, Tamas K Lengyel wrote:
> While forking VMs running a small RTOS system (Zephyr) a Xen crash has been
> observed due to a mm-lock order violation while copying the HVM CPU context
> from the parent. This issue has been identified to be due to
> hap_update_pa
flight 151188 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151188/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 150120
build-amd64-pre
Ian Jackson writes ("[XEN PATCH for-4.14 0/2] tools: Update/reset autogenerated
files"):
> We commit the output of autogen.sh, and the outputs of flex and bison,
> to help people without recent versions of the corresponding tools.
>
> Our usual practice hitherto has been to declare a version of D
On Thu, Jun 18, 2020 at 9:41 AM Jan Beulich wrote:
>
> On 18.06.2020 17:25, Michał Leszczyński wrote:
> > - 16 cze 2020 o 19:23, Roger Pau Monné roger@citrix.com napisał(a):
> >> On Tue, Jun 16, 2020 at 05:22:06PM +0200, Michał Leszczyński wrote:
> >>> --- a/xen/include/public/hvm/hvm_op.h
On Thu, Jun 18, 2020 at 9:47 AM Tamas K Lengyel
wrote:
>
> On Thu, Jun 18, 2020 at 9:41 AM Jan Beulich wrote:
> >
> > On 18.06.2020 17:25, Michał Leszczyński wrote:
> > > - 16 cze 2020 o 19:23, Roger Pau Monné roger@citrix.com
> > > napisał(a):
> > >> On Tue, Jun 16, 2020 at 05:22:06PM +
> -Original Message-
> From: Ian Jackson
> Sent: 18 June 2020 16:48
> To: Wei Liu ; Anthony Perard ;
> Andrew Cooper
> ; Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Samuel Thibault
> ; Nick Rosbrook
>
> Subject: Re: [XEN PATCH for-4.14 0/2] tools: Update/reset autogenerated file
> -Original Message-
> From: Ian Jackson
> Sent: 18 June 2020 16:44
> To: Jason Andryuk ; Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony Perard
>
> Subject: Re: [PATCH for-4.14] xl: Allow shutdown wait for domain death
>
> Jason Andryuk writes ("[PATCH] xl: Allow
> -Original Message-
> From: Roger Pau Monné
> Sent: 18 June 2020 16:46
> To: Tamas K Lengyel
> Cc: xen-devel@lists.xenproject.org; Jun Nakajima ;
> Kevin Tian
> ; Jan Beulich ; Andrew Cooper
> ;
> Wei Liu ; Paul Durrant
> Subject: Re: [PATCH v3 for-4.14] x86/vmx: use P2M_ALLOC in vmx_
Samuel Thibault writes ("Re: [PATCH v1] stubdom/vtpm: add extern to function
declarations"):
> Jason Andryuk, le mer. 17 juin 2020 09:35:52 -0400, a ecrit:
> > On Wed, Jun 17, 2020 at 2:10 AM Olaf Hering wrote:
> > >
> > > Code compiled with gcc10 will not link properly due to multiple
> > > def
flight 151181 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151181/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 151155
Tests which did not succeed
Paul Durrant writes ("RE: [PATCH for-4.14] xl: Allow shutdown wait for domain
death"):
> > -Original Message-
> > From: Ian Jackson
...
> > I have reviewed this patch particularly carefully with a view to
> > understanding what happens if you pass just one `-w' as before.
> > I have convi
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
> -Original Message-
> From: Ian Jackson
> Sent: 18 June 2020 16:56
> To: Paul Durrant
> Cc: Samuel Thibault ; Jason Andryuk
> ; Olaf Hering
> ; xen-devel ; Wei Liu
>
> Subject: Re: [XEN PATCH for-4.14 v1] stubdom/vtpm: add extern to function
> declarations
>
> Samuel Thibault writes
Commit e9aca9470ed86 introduced a regression when avoiding sending
IPIs for certain flush operations. Xen page fault handler
(spurious_page_fault) relies on blocking interrupts in order to
prevent handling TLB flush IPIs and thus preventing other CPUs from
removing page tables pages. Switching to a
On 12.06.2020 17:56, Roger Pau Monne wrote:
> Some video BIOS require a PIT in order to work properly, hence classic
> PV dom0 gets partial access to the physical PIT as long as it's not in
> use by Xen.
>
> Since PVH dom0 is built on top of HVM support, there's already an
> emulated PIT implement
Paul Durrant writes ("RE: [XEN PATCH for-4.14 v1] stubdom/vtpm: add extern to
function declarations"):
> > -Original Message-
> > From: Ian Jackson
...
> > I think this is 4.14 material. Paul ?
>
> Agreed.
>
> Release-acked-by: Paul Durrant
Thanks, pushed.
Ian.
When running under KVM (or presumably other hypervisors) we enable
the CPUID.1.EDX.HTT flag, thus indicating validity of CPUID.1.EBX[23:16]
- maximum number of logical processors which the guest reads as 0.
Although this method of topology detection is considered legacy,
Windows falls back to it w
On Fri, Jun 12, 2020 at 04:19:31PM +0100, Ian Jackson wrote:
> These files are in tree so that people can build (including from git)
> without needing less-than-a-decade-old flex and bison.
>
> We should update them periodically. Debian buster has been Debian
> stable for a while. Our CI is runn
On 18/06/2020 17:22, Hubert Jasudowicz wrote:
> When running under KVM (or presumably other hypervisors) we enable
> the CPUID.1.EDX.HTT flag, thus indicating validity of CPUID.1.EBX[23:16]
> - maximum number of logical processors which the guest reads as 0.
>
> Although this method of topology det
On Thu, Jun 18, 2020 at 05:12:17PM +0200, Jan Beulich wrote:
> On 12.06.2020 17:56, Roger Pau Monne wrote:
> > vpt timers are usually added to the per-vCPU list of the vCPU where
> > they get setup, but depending on the timer source type that vCPU might
> > be different than the one where the inter
On 16/06/2020 16:24, Michał Leszczyński wrote:
> Enable IPT when entering the VM and disable it on vmexit.
> Register state is persisted using vCPU ipt_state structure.
>
> Signed-off-by: Michal Leszczynski
> ---
> xen/arch/x86/hvm/vmx/vmx.c | 26 ++
> 1 file changed, 26 i
On 16/06/2020 18:59, Julien Grall wrote:
From: Julien Grall
SMC call will update some of registers (typically only x0) depending on
the arguments provided.
Some CPUs can speculate past a SMC instruction and potentially perform
speculative access to emrmoy using the pre-call values before ex
flight 151225 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151225/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
+Bertrand and Stefano
On 16/06/2020 02:24, Volodymyr Babchuk wrote:
Hi Peng,
On Mon, 15 Jun 2020 at 05:07, Peng Fan wrote:
Hi All,
While enabling trusty os with xen, I took same approach as OP-TEE,
with OP-TEE running in secure world. But I am also thinking this might
introduce potential is
flight 151184 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151184/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 150176
build-amd64-pr
flight 151187 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151187/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 58ae92a993687d913aa6dd00ef3497a1bc5f6c40
baseline version:
ovmf 8927e286a43cddfaa
Hi Julien,
Julien Grall writes:
> Hi Volodymyr,
>
> On 12/06/2020 12:44, Volodymyr Babchuk wrote:
>>
>> On Fri, 2020-06-12 at 06:57 +0200, Jürgen Groß wrote:
>>> On 12.06.20 02:22, Volodymyr Babchuk wrote:
As scheduler code now collects time spent in IRQ handlers and in
do_softirq(), w
On Thu, 18 Jun 2020 at 21:24, Volodymyr Babchuk
wrote:
>
>
> Hi Julien,
>
> Julien Grall writes:
>
> > Hi Volodymyr,
> >
> > On 12/06/2020 12:44, Volodymyr Babchuk wrote:
> >>
> >> On Fri, 2020-06-12 at 06:57 +0200, Jürgen Groß wrote:
> >>> On 12.06.20 02:22, Volodymyr Babchuk wrote:
> As sch
flight 151226 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151226/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Thu, 18 Jun 2020, Julien Grall wrote:
> On 18/06/2020 06:22, Oleksandr Andrushchenko wrote:
> >
> > On 6/4/20 6:31 PM, Stefano Stabellini wrote:
> > > On Thu, 4 Jun 2020, Oleksandr Andrushchenko wrote:
> > > > On 6/4/20 4:57 AM, Peng Fan wrote:
> > > > > Grall ;
> > > > > > Nataliya Korovkina
On Thu, 18 Jun 2020, Julien Grall wrote:
> +Bertrand and Stefano
Thanks for CC'ing me
> On 16/06/2020 02:24, Volodymyr Babchuk wrote:
> > Hi Peng,
> >
> > On Mon, 15 Jun 2020 at 05:07, Peng Fan wrote:
> > >
> > > Hi All,
> > >
> > > While enabling trusty os with xen, I took same approach as
Hi Paul, Julien,
Volodymyr hasn't come back with an update to this patch, but I think it
is good enough as-is as a bug fix and I would rather have it in its
current form in 4.14 than not having it at all leaving the bug unfixed.
I think Julien agrees.
Paul, are you OK with this?
On Mon, 11 M
Actually adding Paul
On Thu, 18 Jun 2020, Stefano Stabellini wrote:
> Hi Paul, Julien,
>
> Volodymyr hasn't come back with an update to this patch, but I think it
> is good enough as-is as a bug fix and I would rather have it in its
> current form in 4.14 than not having it at all leaving the bu
Hi Paul, Julien, Volodymyr,
This is another bug fix that I would like to get in 4.14. It doesn't
look like we need any changes to this patch, assuming that it is
accurate to the spec.
It would be nice if Volodymyr could provide more info on the spec side,
but honestly I trust his experience on th
On Thu, 18 Jun 2020 at 23:00, Stefano Stabellini wrote:
>
> On Thu, 18 Jun 2020, Julien Grall wrote:
> > On 18/06/2020 06:22, Oleksandr Andrushchenko wrote:
> > >
> > > On 6/4/20 6:31 PM, Stefano Stabellini wrote:
> > > > On Thu, 4 Jun 2020, Oleksandr Andrushchenko wrote:
> > > > > On 6/4/20 4:57
Hi Julien,
Julien Grall writes:
> (+Paul)
>
> Hi,
>
> On 18/05/2020 02:53, Volodymyr Babchuk wrote:
>> Trusted Applications use popular approach to determine required size
>> of buffer: client provides a memory reference with the NULL pointer to
>> a buffer. This is so called "Null memory refer
Hi Stefano,
Stefano Stabellini writes:
> Hi Paul, Julien, Volodymyr,
>
> This is another bug fix that I would like to get in 4.14. It doesn't
> look like we need any changes to this patch, assuming that it is
> accurate to the spec.
>
> It would be nice if Volodymyr could provide more info on t
Intel Processor Trace is an architectural extension available in modern Intel
family CPUs. It allows recording the detailed trace of activity while the
processor executes the code. One might use the recorded trace to reconstruct
the code flow. It means, to find out the executed code paths, deter
Hi Julien,
Julien Grall writes:
> On Thu, 18 Jun 2020 at 21:24, Volodymyr Babchuk
> wrote:
>>
>>
>> Hi Julien,
>>
>> Julien Grall writes:
>>
>> > Hi Volodymyr,
>> >
>> > On 12/06/2020 12:44, Volodymyr Babchuk wrote:
>> >>
>> >> On Fri, 2020-06-12 at 06:57 +0200, Jürgen Groß wrote:
>> >>> On 12.
Replace on-stack array allocation with heap allocation
in order to lift the limit of 32 items in mfn/gfn arrays
when calling acquire_resource.
Signed-off-by: Michal Leszczynski
---
xen/common/memory.c | 39 +--
1 file changed, 17 insertions(+), 22 deletions(-)
1 - 100 of 117 matches
Mail list logo
