On 6/18/20 5:50 PM, 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
>> Subjec
On 2020-06-18 20:12, Souptick Joarder wrote:
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
From: Paul Durrant
Commit babde47a "introduce a 'passthrough' configuration option to xl.cfg..."
added a check to xl_parse.c:parse_config_data() to make sure that an IOMMU
was present and enabled in the system before allowing devices to be passed
through to a guest. This check was then subsequent
On 2020-06-19 01:43, Andrew Cooper wrote:
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 som
> -Original Message-
> From: Stefano Stabellini
> Sent: 18 June 2020 23:21
> To: xadimg...@gmail.com; pdurr...@amazon.co.uk
> Cc: Andrew Cooper ; Julien Grall ;
> Volodymyr Babchuk
> ; xen-devel@lists.xenproject.org;
> tee-...@lists.linaro.org
> Subject: Re: [PATCH] optee: immediately fr
Hi,
> On 18 Jun 2020, at 19:05, Julien Grall wrote:
>
> +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-
> -Original Message-
> From: Stefano Stabellini
> Sent: 18 June 2020 23:27
> To: xadimg...@gmail.com; p...@xen.org; pdurr...@amazon.com
> Cc: Volodymyr Babchuk ; sstabell...@kernel.org;
> xen-
> de...@lists.xenproject.org; p...@xen.org; jul...@xen.org
> Subject: Re: [PATCH] xen/arm: optee
> On 18 Jun 2020, at 23:17, Stefano Stabellini wrote:
>
> 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,
>>
Hi Bertrand,
> Subject: Re: [Tee-dev] TEE with XEN
>
> Hi,
>
> > On 18 Jun 2020, at 19:05, Julien Grall wrote:
> >
> > +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,
> >>>
> >>> Wh
On 18/06/2020 23:20, 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 bug unfixed.
I think Julien a
> On 19 Jun 2020, at 09:52, Peng Fan wrote:
>
> Hi Bertrand,
>
>> Subject: Re: [Tee-dev] TEE with XEN
>>
>> Hi,
>>
>>> On 18 Jun 2020, at 19:05, Julien Grall wrote:
>>>
>>> +Bertrand and Stefano
>>>
>>> On 16/06/2020 02:24, Volodymyr Babchuk wrote:
Hi Peng,
On Mon, 15 Jun 2020 a
Julien, Paul,
Julien Grall writes:
> On 18/06/2020 23:20, 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
> -Original Message-
> From: Boris Ostrovsky
> Sent: 17 June 2020 18:57
> To: Souptick Joarder ; jgr...@suse.com;
> sstabell...@kernel.org
> Cc: xen-devel@lists.xenproject.org; linux-ker...@vger.kernel.org; John
> Hubbard ;
> p...@xen.org
> Subject: Re: [RFC PATCH] xen/privcmd: Convert g
> Subject: Re: [Tee-dev] TEE with XEN
>
>
>
> > On 19 Jun 2020, at 09:52, Peng Fan wrote:
> >
> > Hi Bertrand,
> >
> >> Subject: Re: [Tee-dev] TEE with XEN
> >>
> >> Hi,
> >>
> >>> On 18 Jun 2020, at 19:05, Julien Grall wrote:
> >>>
> >>> +Bertrand and Stefano
> >>>
> >>> On 16/06/2020 02:24,
Hi Peng,
On Fri, 19 Jun 2020 at 12:06, Peng Fan wrote:
>
> > Subject: Re: [Tee-dev] TEE with XEN
> >
> >
> >
> > > On 19 Jun 2020, at 09:52, Peng Fan wrote:
> > >
> > > Hi Bertrand,
> > >
> > >> Subject: Re: [Tee-dev] TEE with XEN
> > >>
> > >> Hi,
> > >>
> > >>> On 18 Jun 2020, at 19:05, Julien
On 19/06/2020 00:29, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
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 poin
On Fri, Jun 12, 2020 at 04:19:30PM +0100, Ian Jackson wrote:
> These files are in tree so that people can build (including from git)
> without needing recent autotools.
>
> We should update them periodically. Debian buster has been Debian
> stable fopr a while. Our CI is running buster.
>
> The
On Fri, Jun 12, 2020 at 04:19:29PM +0100, Ian Jackson wrote:
> We commit the output of autogen.sh, and the outputs of flex and bison,
> to help people without recent versions of the corresponding tools.
> After 4.14 we can perhaps revisit which of these files should be
> committed and how they sho
> Subject: Re: [Tee-dev] TEE with XEN
>
> Hi Peng,
>
> On Fri, 19 Jun 2020 at 12:06, Peng Fan wrote:
> >
> > > Subject: Re: [Tee-dev] TEE with XEN
> > >
> > >
> > >
> > > > On 19 Jun 2020, at 09:52, Peng Fan wrote:
> > > >
> > > > Hi Bertrand,
> > > >
> > > >> Subject: Re: [Tee-dev] TEE with XE
> On 19 Jun 2020, at 10:12, Volodymyr Babchuk wrote:
>
> Hi Peng,
>
> On Fri, 19 Jun 2020 at 12:06, Peng Fan wrote:
>>
>>> Subject: Re: [Tee-dev] TEE with XEN
>>>
>>>
>>>
On 19 Jun 2020, at 09:52, Peng Fan wrote:
Hi Bertrand,
> Subject: Re: [Tee-dev] TEE with XE
Julien Grall writes:
> On 19/06/2020 00:29, Volodymyr Babchuk wrote:
>>
>> Hi Julien,
>
> Hi Volodymyr,
>
>>
>> Julien Grall writes:
>>
>>> (+Paul)
>>>
>>> Hi,
>>>
>>> On 18/05/2020 02:53, Volodymyr Babchuk wrote:
Trusted Applications use popular approach to determine required size
of
On Fri, 19 Jun 2020 at 12:50, Peng Fan wrote:
>
> > Subject: Re: [Tee-dev] TEE with XEN
> >
> > Hi Peng,
> >
> > On Fri, 19 Jun 2020 at 12:06, Peng Fan wrote:
> > >
> > > > Subject: Re: [Tee-dev] TEE with XEN
> > > >
> > > >
> > > >
> > > > > On 19 Jun 2020, at 09:52, Peng Fan wrote:
> > > > >
>
Hi Volodymyr,
On 19/06/2020 10:52, Volodymyr Babchuk wrote:
OP-TEE represents this null memory reference as a TMEM parameter with
buf_ptr == NULL. This is the only case when we should allow TMEM
buffer without the OPTEE_MSG_ATTR_NONCONTIG flag.
IIUC, 0 with OPTEE_MSG_ATTR_NONCONTIG set would m
On 2020-06-18 13:46, Roger Pau Monné wrote:
On Thu, Jun 18, 2020 at 12:13:30PM +0200, Martin Lucina wrote:
At this point I don't really have a clear idea of how to progress,
comparing my implementation side-by-side with the original PV
Mini-OS-based
implementation doesn't show up any differenc
Fix typo.
Fixes: acd0c9416d48 ("xen: fix build without pci passthrough")
Signed-off-by: Anthony PERARD
---
hw/xen/Makefile.objs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
index 3fc715e5954d..502b32d877a0 100644
--- a/hw/xen/Mak
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 6/19/20 12:31 PM, Anthony PERARD wrote:
> Fix typo.
>
> Fixes: acd0c9416d48 ("xen: fix build without pci passthrough")
> Signed-off-by: Anthony PERARD
> ---
> hw/xen/Makefile.objs | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.
> -Original Message-
> From: Anthony PERARD
> Sent: 19 June 2020 11:31
> To: qemu-de...@nongnu.org
> Cc: Paolo Bonzini ; Anthony PERARD
> ; Stefano
> Stabellini ; Paul Durrant ;
> xen-devel@lists.xenproject.org
> Subject: [PATCH] xen: Actually fix build without passthrough
>
> Fix ty
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_
flight 151204 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151204/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 150040
build-i386-pre
On Fri, Jun 19, 2020 at 12:28:50PM +0200, Martin Lucina wrote:
> On 2020-06-18 13:46, Roger Pau Monné wrote:
> > On Thu, Jun 18, 2020 at 12:13:30PM +0200, Martin Lucina wrote:
> > > At this point I don't really have a clear idea of how to progress,
> > > comparing my implementation side-by-side wit
On 19/06/2020 11:28, Martin Lucina wrote:
> On 2020-06-18 13:46, Roger Pau Monné wrote:
>> On Thu, Jun 18, 2020 at 12:13:30PM +0200, Martin Lucina wrote:
>>> At this point I don't really have a clear idea of how to progress,
>>> comparing my implementation side-by-side with the original PV
>>> Mini
On Fri, Jun 19, 2020 at 01:38:00AM +0200, Michał Leszczyński wrote:
> 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.
I'm afraid this is not correct, you cannot allow unbounded amounts of
items to be
Patchew URL:
https://patchew.org/QEMU/20200619103115.254127-1-anthony.per...@citrix.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/b
- 19 cze 2020 o 13:34, Roger Pau Monné roger@citrix.com napisał(a):
> On Fri, Jun 19, 2020 at 01:38:00AM +0200, Michał Leszczyński wrote:
>> 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.
On 19.06.2020 13:36, Michał Leszczyński wrote:
> - 19 cze 2020 o 13:34, Roger Pau Monné roger@citrix.com napisał(a):
>
>> On Fri, Jun 19, 2020 at 01:38:00AM +0200, Michał Leszczyński wrote:
>>> Replace on-stack array allocation with heap allocation
>>> in order to lift the limit of 32 item
- 19 cze 2020 o 13:48, Jan Beulich jbeul...@suse.com napisał(a):
> On 19.06.2020 13:36, Michał Leszczyński wrote:
>> - 19 cze 2020 o 13:34, Roger Pau Monné roger@citrix.com napisał(a):
>>
>>> On Fri, Jun 19, 2020 at 01:38:00AM +0200, Michał Leszczyński wrote:
Replace on-stack arr
We do not expose the feature to guests, so should disallow access to the
respective MSRs.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Paul Durrant
CC: Michał Leszczyński
Paul: For 4.14. This needs backporting to older trees as well.
Michał: CC'ing,
- 19 cze 2020 o 13:58, Andrew Cooper andrew.coop...@citrix.com napisał(a):
> We do not expose the feature to guests, so should disallow access to the
> respective MSRs.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Paul Durrant
> CC: M
On 6/19/20 1:49 AM, Julien Grall wrote:
> 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 Andrushche
- 19 cze 2020 o 13:34, Roger Pau Monné roger@citrix.com napisał(a):
> On Fri, Jun 19, 2020 at 01:38:00AM +0200, Michał Leszczyński wrote:
>> 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.
On 18.06.2020 19:14, Roger Pau Monné wrote:
> On Thu, Jun 18, 2020 at 05:12:17PM +0200, Jan Beulich wrote:
>> On 12.06.2020 17:56, Roger Pau Monne wrote:
>>> case PTSRC_ioapic:
>>> pt_vector = hvm_ioapic_assert(v->domain, irq, level);
>>> -if ( pt_vector < 0 || !vlapic_test_ir
On 19/06/20 12:31, Anthony PERARD wrote:
> Fix typo.
>
> Fixes: acd0c9416d48 ("xen: fix build without pci passthrough")
> Signed-off-by: Anthony PERARD
> ---
> hw/xen/Makefile.objs | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.ob
On 19.06.2020 14:35, Michał Leszczyński wrote:
> - 19 cze 2020 o 13:34, Roger Pau Monné roger@citrix.com napisał(a):
>
>> On Fri, Jun 19, 2020 at 01:38:00AM +0200, Michał Leszczyński wrote:
>>> Replace on-stack array allocation with heap allocation
>>> in order to lift the limit of 32 item
Hi Oleksandr,
On 19/06/2020 13:32, Oleksandr Andrushchenko wrote:
On 6/19/20 1:49 AM, Julien Grall wrote:
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 Stabelli
On 19.06.2020 13:58, Andrew Cooper wrote:
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -168,6 +168,12 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t
> *val)
> case MSR_TSX_FORCE_ABORT:
> case MSR_TSX_CTRL:
> case MSR_MCU_OPT_CTRL:
> +case MSR_RTIT_OUTPUT
On 19.06.2020 14:10, Michał Leszczyński wrote:
> - 19 cze 2020 o 13:58, Andrew Cooper andrew.coop...@citrix.com napisał(a):
>
>> We do not expose the feature to guests, so should disallow access to the
>> respective MSRs.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: We
On 6/19/20 3:47 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 19/06/2020 13:32, Oleksandr Andrushchenko wrote:
>>
>> On 6/19/20 1:49 AM, Julien Grall wrote:
>>> 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, O
- 19 cze 2020 o 14:49, Jan Beulich jbeul...@suse.com napisał(a):
> On 19.06.2020 14:10, Michał Leszczyński wrote:
>> - 19 cze 2020 o 13:58, Andrew Cooper andrew.coop...@citrix.com
>> napisał(a):
>>
>>> We do not expose the feature to guests, so should disallow access to the
>>> respectiv
Hi,
On 19/06/2020 13:51, Oleksandr Andrushchenko wrote:
On 6/19/20 3:47 PM, Julien Grall wrote:
They will not be available from the fdt, but you can retrieve them with an
hypervisor call (see HVM_PARAM_STORE_PFN, HVM_PARAM_CONSOLE_PFN).
Yes, and it used in the relevant pieces of code (hyp cal
On 6/19/20 3:59 PM, Julien Grall wrote:
> Hi,
>
> On 19/06/2020 13:51, Oleksandr Andrushchenko wrote:
>> On 6/19/20 3:47 PM, Julien Grall wrote:
>>> They will not be available from the fdt, but you can retrieve them with an
>>> hypervisor call (see HVM_PARAM_STORE_PFN, HVM_PARAM_CONSOLE_PFN).
>>
> Subject: Re: UEFI support in ARM DomUs
>
>
> On 6/19/20 3:59 PM, Julien Grall wrote:
> > Hi,
> >
> > On 19/06/2020 13:51, Oleksandr Andrushchenko wrote:
> >> On 6/19/20 3:47 PM, Julien Grall wrote:
> >>> They will not be available from the fdt, but you can retrieve them with an
> hypervisor cal
On 19/06/2020 14:06, Oleksandr Andrushchenko wrote:
On 6/19/20 3:59 PM, Julien Grall wrote:
Hi,
On 19/06/2020 13:51, Oleksandr Andrushchenko wrote:
On 6/19/20 3:47 PM, Julien Grall wrote:
They will not be available from the fdt, but you can retrieve them with an
hypervisor call (see HVM_
On 19.06.2020 06:28, Grzegorz Uriasz wrote:
> --- a/xen/arch/x86/acpi/boot.c
> +++ b/xen/arch/x86/acpi/boot.c
> @@ -478,7 +478,9 @@ static int __init acpi_parse_fadt(struct
> acpi_table_header *table)
> if (fadt->header.revision >= FADT2_REVISION_ID) {
> /* FADT rev. 2 */
>
On 19/06/2020 13:57, Michał Leszczyński wrote:
> - 19 cze 2020 o 14:49, Jan Beulich jbeul...@suse.com napisał(a):
>
>> On 19.06.2020 14:10, Michał Leszczyński wrote:
>>> - 19 cze 2020 o 13:58, Andrew Cooper andrew.coop...@citrix.com
>>> napisał(a):
>>>
We do not expose the feature to
On 19/06/2020 13:48, Jan Beulich wrote:
> On 19.06.2020 13:58, Andrew Cooper wrote:
>> --- a/xen/arch/x86/msr.c
>> +++ b/xen/arch/x86/msr.c
>> @@ -168,6 +168,12 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t
>> *val)
>> case MSR_TSX_FORCE_ABORT:
>> case MSR_TSX_CTRL:
>> c
On 6/19/20 4:15 PM, Julien Grall wrote:
On 19/06/2020 14:06, Oleksandr Andrushchenko wrote:
On 6/19/20 3:59 PM, Julien Grall wrote:
Hi,
On 19/06/2020 13:51, Oleksandr Andrushchenko wrote:
On 6/19/20 3:47 PM, Julien Grall wrote:
They will not be available from the fdt, but you can retrieve
On 6/19/20 4:16 PM, Peng Fan wrote:
Subject: Re: UEFI support in ARM DomUs
On 6/19/20 3:59 PM, Julien Grall wrote:
Hi,
On 19/06/2020 13:51, Oleksandr Andrushchenko wrote:
On 6/19/20 3:47 PM, Julien Grall wrote:
They will not be available from the fdt, but you can retrieve them with an
hype
On 19.06.2020 15:28, Andrew Cooper wrote:
> On 19/06/2020 13:48, Jan Beulich wrote:
>> On 19.06.2020 13:58, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/msr.c
>>> +++ b/xen/arch/x86/msr.c
>>> @@ -168,6 +168,12 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t
>>> *val)
>>> case MSR_TSX
On Fri, Jun 19, 2020 at 01:40:21AM +0200, Michał Leszczyński wrote:
> Check if Intel Processor Trace feature is supported by current
> processor. Define hvm_ipt_supported function.
>
> Signed-off-by: Michal Leszczynski
> ---
We usually keep a shirt list of the changes between versions, so it's
e
On 18.06.2020 18:04, Roger Pau Monne wrote:
> 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
On 6/18/20 6:51 PM, Andrew Cooper wrote:
> 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
- 19 cze 2020 o 15:44, Roger Pau Monné roger@citrix.com napisał(a):
> On Fri, Jun 19, 2020 at 01:40:21AM +0200, Michał Leszczyński wrote:
>> Check if Intel Processor Trace feature is supported by current
>> processor. Define hvm_ipt_supported function.
>>
>> Signed-off-by: Michal Leszczyn
Anthony PERARD writes ("Re: [XEN PATCH for-4.14 1/2] tools: Commit autoconf
(2.69) output from Debian buster"):
> FIY, this is the output of autoconf from Debian buster, but it isn't the
> output of autoconf 2.69. Debian is likely to have patches on top of
> the latest autoconf release. 2.69 is ap
Paul Durrant writes ("[PATCH for 4.14] libxl: allow passthrough to PV guests
regardless of whether IOMMU is enabled"):
> From: Paul Durrant
>
> Commit babde47a "introduce a 'passthrough' configuration option to xl.cfg..."
> added a check to xl_parse.c:parse_config_data() to make sure that an IOM
On Fri, Jun 19, 2020 at 01:41:03AM +0200, Michał Leszczyński wrote:
> Provide an interface for privileged domains to manage
> external IPT monitoring. Guest IPT state will be preserved
> across vmentry/vmexit using ipt_state structure.
Thanks! I have some comments below, some of them are cosmetic
On Fri, Jun 19, 2020 at 04:22:28PM +0200, Michał Leszczyński wrote:
> - 19 cze 2020 o 15:44, Roger Pau Monné roger@citrix.com napisał(a):
>
> > On Fri, Jun 19, 2020 at 01:40:21AM +0200, Michał Leszczyński wrote:
> >> Check if Intel Processor Trace feature is supported by current
> >> proce
On 19.06.2020 17:30, Roger Pau Monné wrote:
> On Fri, Jun 19, 2020 at 01:41:03AM +0200, Michał Leszczyński wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -1612,6 +1612,24 @@ int hvm_vcpu_initialise(struct vcpu *v)
>> return rc;
>> }
>>
>> +void hvm_vmtrace_dest
On 2020-06-19 13:21, Roger Pau Monné wrote:
On Fri, Jun 19, 2020 at 12:28:50PM +0200, Martin Lucina wrote:
On 2020-06-18 13:46, Roger Pau Monné wrote:
> On Thu, Jun 18, 2020 at 12:13:30PM +0200, Martin Lucina wrote:
> > At this point I don't really have a clear idea of how to progress,
> > compa
On 2020-06-19 13:21, Andrew Cooper wrote:
On 19/06/2020 11:28, Martin Lucina wrote:
RIP 0x209997 is the 'hlt' instruction in
mirage_xen_evtchn_block_domain() so we are indeed blocking waiting for
events to show up.
I can't find this in the code, but it might be an x86-ism you're
falling
over
On Fri, Jun 19, 2020 at 06:41:21PM +0200, Martin Lucina wrote:
> On 2020-06-19 13:21, Roger Pau Monné wrote:
> > On Fri, Jun 19, 2020 at 12:28:50PM +0200, Martin Lucina wrote:
> > > On 2020-06-18 13:46, Roger Pau Monné wrote:
> > > > On Thu, Jun 18, 2020 at 12:13:30PM +0200, Martin Lucina wrote:
>
On Fri, 19 Jun 2020, Julien Grall wrote:
> Hi Volodymyr,
>
> On 19/06/2020 10:52, Volodymyr Babchuk wrote:
> > > > > > OP-TEE represents this null memory reference as a TMEM parameter
> > > > > > with
> > > > > > buf_ptr == NULL. This is the only case when we should allow TMEM
> > > > > > buffer w
On 19/06/2020 18:15, Stefano Stabellini wrote:
On Fri, 19 Jun 2020, Julien Grall wrote:
Hi Volodymyr,
On 19/06/2020 10:52, Volodymyr Babchuk wrote:
OP-TEE represents this null memory reference as a TMEM parameter
with
buf_ptr == NULL. This is the only case when we should allow TMEM
buffer w
On Fri, Jun 19, 2020 at 06:54:26PM +0200, Roger Pau Monné wrote:
> On Fri, Jun 19, 2020 at 06:41:21PM +0200, Martin Lucina wrote:
> > On 2020-06-19 13:21, Roger Pau Monné wrote:
> > > On Fri, Jun 19, 2020 at 12:28:50PM +0200, Martin Lucina wrote:
> > > > On 2020-06-18 13:46, Roger Pau Monné wrote:
On Fri, 19 Jun 2020, Julien Grall wrote:
> On 19/06/2020 18:15, Stefano Stabellini wrote:
> > On Fri, 19 Jun 2020, Julien Grall wrote:
> > > Hi Volodymyr,
> > >
> > > On 19/06/2020 10:52, Volodymyr Babchuk wrote:
> > > > > > > > OP-TEE represents this null memory reference as a TMEM parameter
> >
On 19/06/2020 15:17, Jan Beulich wrote:
> On 19.06.2020 06:28, Grzegorz Uriasz wrote:
>> --- a/xen/arch/x86/acpi/boot.c
>> +++ b/xen/arch/x86/acpi/boot.c
>> @@ -478,7 +478,9 @@ static int __init acpi_parse_fadt(struct
>> acpi_table_header *table)
>> if (fadt->header.revision >= FADT2_REVISION
flight 151235 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151235/
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
flight 151214 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151214/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 151170
test-amd64-amd64-xl-qemuu-win7-amd64
On Thu, 18 Jun 2020, Julien Grall wrote:
> > Copy/pasting here from my comment on the pull request plus additional
> > thoughts.
> >
> > Uboot is one of those embedded projects that typically assumes that all
> > the information about the platform is available at *build time*. It is
> > meant to be
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 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
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 reference". TA updates the
reference with the required size and returns it back to the
client. Then client allocates b
Normal World can share buffer with OP-TEE for two reasons:
1. Some client application wants to exchange data with TA
2. OP-TEE asks for shared buffer for internal needs
The second case was handle more strictly than necessary:
1. In RPC request OP-TEE asks for buffer
2. NW allocates buffer and pro
There are two patches that previously was mailed separatedly. Both
patches fix issues found during testing the OP-TEE 3.9 release.
Julien and Stefano suggested to include this patches in Xen 4.14
release, because optee support still in the preview state and those
patches provide no new functionali
flight 151237 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151237/
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
flight 151223 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151223/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150068
test-amd64-amd64-xl-qemut-ws16-am
flight 151221 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151221/
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
flight 151224 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151224/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail REGR.
vs. 151181
test-am
88 matches
Mail list logo
