flight 151200 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151200/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 151022
test-amd64-amd64-xl-
On some computers the bit width of the PM Timer as reported
by ACPI is 32 bits when in fact the FADT flags report correctly
that the timer is 24 bits wide. On affected machines such as the
ASUS FX504GM and never gaming laptops this results in the inability
to resume the machine from suspend. Withou
Hi,
The included patch is a small subset of a bigger patch set spanning few
projects aiming to isolate the GPU in Qubes OS to a dedicated security domain.
I'm doing this together with 3 colleagues as part of our Bachelors thesis.
While working on the project we came across 2 machines - newer gamin
On Wed, Jun 17, 2020 at 11:29 PM Boris Ostrovsky
wrote:
>
> On 6/16/20 11:14 PM, Souptick Joarder wrote:
> > In 2019, we introduced pin_user_pages*() and now we are converting
> > get_user_pages*() to the new API as appropriate. [1] & [2] could
> > be referred for more information.
> >
> > [1] Doc
flight 151196 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151196/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 150039
test-amd64-amd
> From: Lengyel, Tamas
> Sent: Thursday, June 18, 2020 10:39 PM
>
> 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_up
> From: Jan Beulich
> Sent: Thursday, June 18, 2020 2:38 PM
>
> * 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
flight 151197 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151197/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151165
test-armhf-armhf-libvirt-raw 13 saveresto
- 19 cze 2020 o 1:41, Michał Leszczyński michal.leszczyn...@cert.pl
napisał(a):
> Provide an interface for privileged domains to manage
> external IPT monitoring. Guest IPT state will be preserved
> across vmentry/vmexit using ipt_state structure.
>
> Signed-off-by: Michal Leszczynski
> ---
- 19 cze 2020 o 1:34, Michał Leszczyński michal.leszczyn...@cert.pl
napisał(a):
> 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
On 18/06/2020 11:13, 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 some issues with what looks li
Add an demonstration tool that uses xc_vmtrace_* calls in order
to manage external IPT monitoring for DomU.
Signed-off-by: Michal Leszczynski
---
tools/proctrace/COPYING | 339
tools/proctrace/Makefile| 50 ++
tools/proctrace/proctrace.c | 153 ++
Add functions in libxc that use the new HVMOP_vmtrace interface.
Signed-off-by: Michal Leszczynski
---
tools/libxc/Makefile | 1 +
tools/libxc/include/xenctrl.h | 39 ++
tools/libxc/xc_vmtrace.c | 97 +++
3 files changed, 137 insertions(
Allow to specify the size of per-vCPU trace buffer upon
domain creation. This is zero by default (meaning: not enabled).
Signed-off-by: Michal Leszczynski
---
tools/golang/xenlight/helpers.gen.go | 2 ++
tools/golang/xenlight/types.gen.go | 1 +
tools/libxl/libxl_types.idl | 2 ++
too
Provide an interface for privileged domains to manage
external IPT monitoring. Guest IPT state will be preserved
across vmentry/vmexit using ipt_state structure.
Signed-off-by: Michal Leszczynski
---
xen/arch/x86/hvm/hvm.c | 167 +
xen/arch/x86/hvm/vmx/vmx
Check if Intel Processor Trace feature is supported by current
processor. Define hvm_ipt_supported function.
Signed-off-by: Michal Leszczynski
---
xen/arch/x86/hvm/vmx/vmcs.c | 4
xen/include/asm-x86/cpufeature.h| 1 +
xen/include/asm-x86/hvm/hvm.h
Define constants related to Intel Processor Trace features.
Signed-off-by: Michal Leszczynski
---
xen/include/asm-x86/msr-index.h | 37 +
1 file changed, 37 insertions(+)
diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
index b328a47
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(-)
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.
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 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
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
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 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
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 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
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
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
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 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
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
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
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
+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 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
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
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 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 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 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
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
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.
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
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
> -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
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_
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
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
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
> -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_
> -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: 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
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 +
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
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
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
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
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
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_
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,
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
- 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 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
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 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: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 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 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
(+ 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
- 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...@
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
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 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: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 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
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:
> 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
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:
> --- 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 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 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 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 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: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 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 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 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 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
- 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 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
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 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 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 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 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 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 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: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 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
> >>
1 - 100 of 117 matches
Mail list logo
