flight 118317 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118317/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 118174
test-armhf-armhf-x
Use autoconf to test if ocaml version >= 4.02
If so, use -unsafe-string for ocamlopt and ocamlc
Bytes & safe-string were introduced in ocaml 4.02 (2015-07-27)
With ocaml 4.06, -safe-string is now default
This separates the types bytes (mutable string) and string
ocaml 4.06 throws errors in compi
flight 118351 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118351/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 118326
Tests which
On Fri, 26 Jan 2018, John Thomson wrote:
> Use autoconf to test if ocaml version >= 4.02
> If so, use -unsafe-string for ocamlopt and ocamlc
>
> Bytes & safe-string were introduced in ocaml 4.02 (2015-07-27)
>
> With ocaml 4.06, -safe-string is now default
> This separates the types bytes (mutab
> On 26. Jan 2018, at 09:09, M A Young wrote:
>
> On Fri, 26 Jan 2018, John Thomson wrote:
>
>> Use autoconf to test if ocaml version >= 4.02
>> If so, use -unsafe-string for ocamlopt and ocamlc
>>
>> Bytes & safe-string were introduced in ocaml 4.02 (2015-07-27)
>>
>> With ocaml 4.06, -safe
flight 118328 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118328/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
The emulation layers of Xen lack PCID support, and as we only offer
PCID to HAP guests, all writes to CR3 are handled by hardware,
except when introspection is involved. Consequently, trying to set
CR3 when the noflush bit is set in hvm_set_cr3() leads to domain
crashes. The workaround is to clear
>>> On 26.01.18 at 02:08, wrote:
> On Thu, 2018-01-25 at 19:49 +0100, Dario Faggioli wrote:
>> On Thu, 2018-01-25 at 16:09 +, Andrew Cooper wrote:
>> > On 25/01/18 15:57, Jan Beulich wrote:
>> > >
>> > > For the record, the overwhelming majority of calls to
>> > > __sync_local_execstate() bein
>>> On 26.01.18 at 10:39, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2324,6 +2324,9 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
> }
> }
>
> +if ( hvm_pcid_enabled(v) ) /* Clear the noflush bit. */
> +value &= ((1ull << 63) -
>>> On 25.01.18 at 19:39, wrote:
> Both options are independently choseable in KConfig, but currently a DEBUG
> build without FRAME_POINTER is left to the compilers default choice, not the
> users choice.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of George Dunlap
> Sent: 25 January 2018 18:15
> To: Anthony Perard
> Cc: Kevin Stange ; xen-devel@lists.xenproject.org;
> George Dunlap
> Subject: Re: [Xen-devel] PCI Device Subtree Change
>>> On 25.01.18 at 20:14, wrote:
> When compiling at -O3, GCC 7.2 reports:
>
> irq.c: In function 'map_domain_pirq':
> irq.c:1271:20: error: 'info' may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
>pirq->arch.irq = irq;
>~~~^
> irq.
On 01/26/2018 12:27 PM, Jan Beulich wrote:
On 26.01.18 at 10:39, wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -2324,6 +2324,9 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
>> }
>> }
>>
>> +if ( hvm_pcid_enabled(v) ) /* Clear the
>>> On 26.01.18 at 11:49, wrote:
> On 01/26/2018 12:27 PM, Jan Beulich wrote:
> On 26.01.18 at 10:39, wrote:
>>> --- a/xen/arch/x86/hvm/monitor.c
>>> +++ b/xen/arch/x86/hvm/monitor.c
>>> @@ -36,6 +36,12 @@ bool hvm_monitor_cr(unsigned int index, unsigned long
>>> value, unsigned long old)
>>
flight 118319 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118319/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 6 xen-install fail REGR. vs. 118278
Tests which did not suc
flight 118354 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118354/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 118326
Tests which
>>> On 25.01.18 at 21:04, wrote:
> On 25/01/18 19:43, Stefano Stabellini wrote:
>> On Thu, 25 Jan 2018, Andrew Cooper wrote:
>>> On 25/01/18 18:37, Stefano Stabellini wrote:
The TCG emulator in QEMU is not good enough to pass the the tests in
stub_selftest. Detect if Xen is running on TC
>>> On 25.01.18 at 20:43, wrote:
> I haven't investigated yet the QEMU side of the problem. I can dig
> deeper there, then, once we understand the full extent of the issue,
> we could decide what to do with this patch. However, I performed a few
> tests so far and I haven't seen any other issues.
On Fri, 2018-01-26 at 02:43 -0700, Jan Beulich wrote:
> > > > On 26.01.18 at 02:08, wrote:
> > And in order to go and investigate this a bit further, Jan, what is
> > it
> > that you were doing when you saw what you described above? AFAIUI,
> > that's booting an HVM guest, isn't it?
>
> Yes, plus
>>> On 26.01.18 at 12:13, wrote:
> On Fri, 2018-01-26 at 02:43 -0700, Jan Beulich wrote:
>> > > > On 26.01.18 at 02:08, wrote:
>> > And in order to go and investigate this a bit further, Jan, what is
>> > it
>> > that you were doing when you saw what you described above? AFAIUI,
>> > that's booti
On Fri, Jan 26, 2018 at 09:29:20AM +, Christian Lindig wrote:
>
>
> > On 26. Jan 2018, at 09:09, M A Young wrote:
> >
> > On Fri, 26 Jan 2018, John Thomson wrote:
> >
> >> Use autoconf to test if ocaml version >= 4.02
> >> If so, use -unsafe-string for ocamlopt and ocamlc
> >>
> >> Bytes
On Thu, Jan 25, 2018 at 01:14:24PM +, Wei Liu wrote:
> Commit e8d461497d9 renamed gcov_op to coverage_op but forgot to change
> XSM handles.
>
> Signed-off-by: Wei Liu
Osstest's ARM build is blocked by this now.
I will wait until 5pm UK time for Daniel to express his opinion.
Wei.
___
On 26/01/18 11:43, Wei Liu wrote:
> On Fri, Jan 26, 2018 at 09:29:20AM +, Christian Lindig wrote:
>>
>>> On 26. Jan 2018, at 09:09, M A Young wrote:
>>>
>>> On Fri, 26 Jan 2018, John Thomson wrote:
>>>
Use autoconf to test if ocaml version >= 4.02
If so, use -unsafe-string for ocamlo
> On 26. Jan 2018, at 11:43, Wei Liu wrote:
>
> On Fri, Jan 26, 2018 at 09:29:20AM +, Christian Lindig wrote:
>>
>>
>>> On 26. Jan 2018, at 09:09, M A Young wrote:
>>>
>>> On Fri, 26 Jan 2018, John Thomson wrote:
>>>
Use autoconf to test if ocaml version >= 4.02
If so, use -u
On Fri, Jan 26, 2018 at 11:47:34AM +, Christian Lindig wrote:
>
>
> > On 26. Jan 2018, at 11:43, Wei Liu wrote:
> >
> > On Fri, Jan 26, 2018 at 09:29:20AM +, Christian Lindig wrote:
> >>
> >>
> >>> On 26. Jan 2018, at 09:09, M A Young wrote:
> >>>
> >>> On Fri, 26 Jan 2018, John Tho
In case we can detect single-threaded guest processes (by checking
whether we can account for all root page table uses locally on the vCPU
that's running), there's no point in issuing a sync IPI upon an L4 entry
update, as no other vCPU of the guest will have that page table loaded.
Signed-off-by:
>>> On 26.01.18 at 12:45, wrote:
> On Thu, Jan 25, 2018 at 01:14:24PM +, Wei Liu wrote:
>> Commit e8d461497d9 renamed gcov_op to coverage_op but forgot to change
>> XSM handles.
>>
>> Signed-off-by: Wei Liu
>
> Osstest's ARM build is blocked by this now.
>
> I will wait until 5pm UK time f
>>> On 25.01.18 at 17:54, wrote:
> ret instructions are speculated directly to values recorded in the Return
> Stack Buffer/Return Address Stack, as there is no uncertainty in well-formed
> code. Guests can take advantage of this in two ways:
>
> 1) If they can find a path in Xen which execute
>>> On 25.01.18 at 18:21, wrote:
> This patch is deliberately arranged to be easy to revert if/when alternatives
> patching becomes NMI/#MC safe.
>
> For safety, there must be a dispatch serialising instruction in (what is
> logically) DO_SPEC_CTRL_ENTRY so that, in the case that Xen needs IBRS s
On 26/01/18 12:23, Jan Beulich wrote:
On 25.01.18 at 18:21, wrote:
>> This patch is deliberately arranged to be easy to revert if/when alternatives
>> patching becomes NMI/#MC safe.
>>
>> For safety, there must be a dispatch serialising instruction in (what is
>> logically) DO_SPEC_CTRL_ENTRY
>>> On 23.01.18 at 01:21, wrote:
> @@ -88,6 +88,16 @@ typedef struct _EFI_APPLE_PROPERTIES {
> EFI_APPLE_PROPERTIES_GETALL GetAll;
> } EFI_APPLE_PROPERTIES;
>
> +typedef struct _EFI_LOAD_OPTION {
> +UINT32 Attributes;
> +UINT16 FilePathListLength;
> +CHAR16 Description[];
> +}
The positions of GPRs inside struct cpu_user_regs doesn't follow any
particular order, so as compiled, decode_register() becomes a jump table to 16
blocks which calculate the appropriate offset, at a total of 207 bytes.
Instead, pre-compute the offsets at build time and use pointer arithmetic to
c
Most users of decode_register() can be replaced with decode_gpr() right away.
For the few sites which do care about possibly using the highbyte encoding,
rename decode_register() to decode_high_gpr() and make it prototype match
decode_gpr().
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
* Rename to decode_gpr() to be more specific as to its purpose
* Drop the highbyte encoding handling, as users care, and it unlikely that
future users would care.
* Change to a static inline, returning an unsigned long pointer.
Doing so highlights that the "invalid gpr" paths in hvm_mov_{to,
Andrew Cooper (3):
x86/emul: Optimise decode_register() somewhat
x86/hvm: Improvements to external users of decode_register()
x86/emul: Improvements to internal users of decode_register()
xen/arch/x86/hvm/hvm.c | 17 +---
xen/arch/x86/hvm/vmx/vvmx.c| 16 +---
x
> On 26. Jan 2018, at 12:00, Wei Liu wrote:
>
>>
>> Reviewed-by: Christian Lindig
>>
>
> Taking the above into consideration, does this tag still stand?
Thanks for the clarification. My tag still stands as the code in the patch is
IMHO fine.
Regarding Andrew’s comment: the bytes type wa
On 26/01/18 10:58, Jan Beulich wrote:
On 26.01.18 at 11:49, wrote:
>> On 01/26/2018 12:27 PM, Jan Beulich wrote:
>> On 26.01.18 at 10:39, wrote:
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -36,6 +36,12 @@ bool hvm_monitor_cr(unsigned int index, uns
flight 118359 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118359/
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
Hi,
I am CCing Oleksandr. He knows better than me this platform.
Cheers,
On 26/01/18 00:29, Martin Kelly wrote:
On 01/25/2018 04:17 AM, Julien Grall wrote:
On 24/01/18 22:10, Martin Kelly wrote:
Hi,
Hello,
Does anyone know if GPU passthrough is supported on ARM? (e.g. for a
GPU integra
Jan Beulich writes ("Re: [PATCH] xen: fix xsm build"):
> On 26.01.18 at 12:45, wrote:
> > I will wait until 5pm UK time for Daniel to express his opinion.
>
> I don't think such pure renaming warrants waiting, the more that
> you've got 3 other acks already iirc.
And I committed this this mornin
On 26/01/18 11:06, Jan Beulich wrote:
On 25.01.18 at 21:04, wrote:
>> On 25/01/18 19:43, Stefano Stabellini wrote:
>>> On Thu, 25 Jan 2018, Andrew Cooper wrote:
On 25/01/18 18:37, Stefano Stabellini wrote:
> The TCG emulator in QEMU is not good enough to pass the the tests in
> s
On Fri, Jan 19, 2018 at 07:19:03PM +, Andrew Cooper wrote:
> c/s 4ddf474e2 "tools/xen-mceinj: Pass in GPA when injecting through
> MSR_MCI_ADDR" removed the remaining user of hypercall.
>
> It has been listed as broken, deprecated and wont-fix since XSA-74, so take
> this opportunity to remove
Put the opcode into an array and use memcpy. This allows the compiled code to
be written with two movs, rather than 10 mov $imm8's. Also, drop trailing
whitespace in the file.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/ioport_emulate.c | 34 +
Disable SMAP in the shim before bouncing the hypercall, or else L0
will fail to get the hypercall buffer.
Signed-off-by: Roger Pau Monné
Reported-by: Fatih Acar
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Wei Liu
---
Needs to be backported to the 4.10.0-shim-comet branch.
---
On 26/01/18 15:29, Roger Pau Monne wrote:
> Disable SMAP in the shim before bouncing the hypercall, or else L0
> will fail to get the hypercall buffer.
>
> Signed-off-by: Roger Pau Monné
> Reported-by: Fatih Acar
Reviewed-by: Andrew Cooper
Do we have any other examples of this? I expect it mi
Hi Edgar,
On 25/01/18 14:15, Edgar E. Iglesias wrote:
On Wed, Jan 24, 2018 at 07:04:35PM +0100, Mirela Simonovic wrote:
Hi Oleksandr, Edgar,
Thanks, you're right.
On 01/23/2018 12:58 PM, Edgar E. Iglesias wrote:
On Tue, Jan 23, 2018 at 01:52:50PM +0200, Oleksandr Tyshchenko wrote:
Hi Mire
On Fri, Jan 26, 2018 at 03:29:10PM +, Roger Pau Monne wrote:
> Disable SMAP in the shim before bouncing the hypercall, or else L0
> will fail to get the hypercall buffer.
>
> Signed-off-by: Roger Pau Monné
> Reported-by: Fatih Acar
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Ian Jack
Switch the PV message to match the wording of the PVH side, use the same
number of ***'s, explicitly identify PV vs PVH, and set the log level at INFO.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/hvm/dom0_build.c | 2 +-
xen/arch/x86/pv/do
On Fri, Jan 26, 2018 at 04:00:03PM +, Andrew Cooper wrote:
> Switch the PV message to match the wording of the PVH side, use the same
> number of ***'s, explicitly identify PV vs PVH, and set the log level at INFO.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
_
On 24/01/18 17:55, Mirela Simonovic wrote:
Hi Julien, Stefano,
Hi Mirela,
Thank you very much for the feedback!
On 01/11/2018 03:00 PM, Julien Grall wrote:
Hi Mirela,
Thank you for the sending the design document. The general design
looks good to me. I have some comments below, but th
Razvan -
The proposed changes would only have an impact if CR3 exiting is enabled,
which implies a pair of world switches and other code execution in a
different region of memory and with different page tables anyway.
Under normal operation, CR3 exiting is not turned on, so this will have no
impa
On Fri, Jan 26, 2018 at 04:00:03PM +, Andrew Cooper wrote:
> Switch the PV message to match the wording of the PVH side, use the same
> number of ***'s, explicitly identify PV vs PVH, and set the log level at INFO.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
> ---
> CC: J
Hi Stefano,
On 25/01/18 19:37, Stefano Stabellini wrote:
On Thu, 25 Jan 2018, Julien Grall wrote:
Hi,
On 25/01/18 18:45, Stefano Stabellini wrote:
On Thu, 25 Jan 2018, Julien Grall wrote:
Hi Stefano,
On 24/01/18 23:54, Stefano Stabellini wrote:
On Fri, 19 Jan 2018, Julien Grall wrote:
Ali
On Fri, Jan 26, 2018 at 03:52:38PM +, Wei Liu wrote:
> On Fri, Jan 26, 2018 at 03:29:10PM +, Roger Pau Monne wrote:
> > Disable SMAP in the shim before bouncing the hypercall, or else L0
> > will fail to get the hypercall buffer.
> >
> > Signed-off-by: Roger Pau Monné
> > Reported-by: Fat
On 26/01/18 16:20, Roger Pau Monné wrote:
> On Fri, Jan 26, 2018 at 04:00:03PM +, Andrew Cooper wrote:
>> Switch the PV message to match the wording of the PVH side, use the same
>> number of ***'s, explicitly identify PV vs PVH, and set the log level at
>> INFO.
>>
>> Signed-off-by: Andrew Co
On Fri, Jan 26, 2018 at 04:22:41PM +, Roger Pau Monné wrote:
> On Fri, Jan 26, 2018 at 03:52:38PM +, Wei Liu wrote:
> > On Fri, Jan 26, 2018 at 03:29:10PM +, Roger Pau Monne wrote:
> > > Disable SMAP in the shim before bouncing the hypercall, or else L0
> > > will fail to get the hyperc
flight 118361 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118361/
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
Hi,
On 24/01/18 18:34, Julien Grall wrote:
The PSCI call MIGRATE and MIGRATE_INFO_UP_CPU are optional and
implemented as just returning PSCI_NOT_SUPPORTED (aka UNKNOWN_FUNCTION
for SMCCC).
The new SMCCC framework is able to deal with unimplemented function and
return the proper error code. So r
On Fri, Jan 26, 2018 at 04:28:27PM +, Wei Liu wrote:
> On Fri, Jan 26, 2018 at 04:22:41PM +, Roger Pau Monné wrote:
> > On Fri, Jan 26, 2018 at 03:52:38PM +, Wei Liu wrote:
> > > On Fri, Jan 26, 2018 at 03:29:10PM +, Roger Pau Monne wrote:
> > > > Disable SMAP in the shim before bou
On 26/01/18 16:34, Roger Pau Monné wrote:
> On Fri, Jan 26, 2018 at 04:28:27PM +, Wei Liu wrote:
>> On Fri, Jan 26, 2018 at 04:22:41PM +, Roger Pau Monné wrote:
>>> On Fri, Jan 26, 2018 at 03:52:38PM +, Wei Liu wrote:
On Fri, Jan 26, 2018 at 03:29:10PM +, Roger Pau Monne wrote:
On 01/26/2018 06:17 PM, Bitweasil . wrote:
> The proposed changes would only have an impact if CR3 exiting is
> enabled, which implies a pair of world switches and other code execution
> in a different region of memory and with different page tables anyway.
>
> Under normal operation, CR3 exiting
flight 118324 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118324/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 118250
test-armhf-armhf-libvirt 14 saver
>>> On 26.01.18 at 17:28, wrote:
> On Fri, Jan 26, 2018 at 04:22:41PM +, Roger Pau Monné wrote:
>> On Fri, Jan 26, 2018 at 03:52:38PM +, Wei Liu wrote:
>> > On Fri, Jan 26, 2018 at 03:29:10PM +, Roger Pau Monne wrote:
>> > > --- a/xen/arch/x86/pv/shim.c
>> > > +++ b/xen/arch/x86/pv/shi
>>> On 26.01.18 at 17:20, wrote:
> On Fri, Jan 26, 2018 at 04:00:03PM +, Andrew Cooper wrote:
>> --- a/xen/arch/x86/pv/dom0_build.c
>> +++ b/xen/arch/x86/pv/dom0_build.c
>> @@ -328,7 +328,7 @@ int __init dom0_construct_pv(struct domain *d,
>> /* Machine address of next candidate page-tabl
>>> On 26.01.18 at 17:28, wrote:
> On 26/01/18 16:20, Roger Pau Monné wrote:
>> On Fri, Jan 26, 2018 at 04:00:03PM +, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/pv/dom0_build.c
>>> +++ b/xen/arch/x86/pv/dom0_build.c
>>> @@ -328,7 +328,7 @@ int __init dom0_construct_pv(struct domain *d,
>>>
Hi,
(CC:ing Edgar)
On 25/01/18 15:03, Amit Singh Tomar wrote:
> This seems to be copy/paste error.This patch simply
> replace string xgene_storm with xilink_zymp for xilink
> platform.
>
> Signed-off-by: Amit Singh Tomar
> ---
> xen/arch/arm/platforms/xilinx-zynqmp.c | 2 +-
> 1 file changed,
On Fri, 26 Jan 2018, Andrew Cooper wrote:
> On 26/01/18 11:06, Jan Beulich wrote:
> On 25.01.18 at 21:04, wrote:
> >> On 25/01/18 19:43, Stefano Stabellini wrote:
> >>> On Thu, 25 Jan 2018, Andrew Cooper wrote:
> On 25/01/18 18:37, Stefano Stabellini wrote:
> > The TCG emulator in QE
On selftests failure, print a very visible warning instead of crashing
over an ASSERT.
Signed-off-by: Stefano Stabellini
diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
index 72f30d9..9b834a2 100644
--- a/xen/arch/x86/extable.c
+++ b/xen/arch/x86/extable.c
@@ -9,6 +9,7 @@
#include
On 26/01/18 17:19, Stefano Stabellini wrote:
> On selftests failure, print a very visible warning instead of crashing
> over an ASSERT.
>
> Signed-off-by: Stefano Stabellini
>
> diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
> index 72f30d9..9b834a2 100644
> --- a/xen/arch/x86/extabl
On Fri, Jan 26, 2018 at 5:46 AM, Jan Beulich wrote:
On 23.01.18 at 01:21, wrote:
>> @@ -88,6 +88,16 @@ typedef struct _EFI_APPLE_PROPERTIES {
>> EFI_APPLE_PROPERTIES_GETALL GetAll;
>> } EFI_APPLE_PROPERTIES;
>>
>> +typedef struct _EFI_LOAD_OPTION {
>> +UINT32 Attributes;
>> +UI
This makes the code cleaner because there's no need to declare the
exception_table in assembly, and also fixes the following error when
using clang's integrated assembler:
entry.S:834:15: error: unexpected token in '.rept' directive
.rept 32 - ((. - exception_table) / 8)
^
en
On 26/01/18 17:37, Roger Pau Monne wrote:
> This makes the code cleaner because there's no need to declare the
> exception_table in assembly, and also fixes the following error when
> using clang's integrated assembler:
>
> entry.S:834:15: error: unexpected token in '.rept' directive
> .rep
Hi Julien,
On 24.01.18 20:34, Julien Grall wrote:
The PSCI call MIGRATE and MIGRATE_INFO_UP_CPU are optional and
implemented as just returning PSCI_NOT_SUPPORTED (aka
UNKNOWN_FUNCTION for SMCCC).
The new SMCCC framework is able to deal with unimplemented function
and return the proper error co
On 24.01.18 20:34, Julien Grall wrote:
The current implementation of SMCCC relies on the fact only function
number (bits [15:0]) is enough to identify what to implement.
However, PSCI call are only available in the range 0x8400-0x841F
and 0xC400-0xC41F. Furthermore, not all SMC
On Fri, Jan 26, 2018 at 3:49 PM, Julien Grall wrote:
> Hi,
>
> I am CCing Oleksandr. He knows better than me this platform.
Hi, Julien.
OK, thank you, I will try to provide some pointers.
>
> Cheers,
>
> On 26/01/18 00:29, Martin Kelly wrote:
>>
>> On 01/25/2018 04:17 AM, Julien Grall wrote:
>>
On 26/01/18 18:03, Volodymyr Babchuk wrote:
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index f543dea0bb..303517459f 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -82,9 +82,23 @@ static inline uint32_t smccc_get_owner(register_t
funcid
On Thu, Jan 25, 2018 at 4:36 PM, Juergen Gross wrote:
> Add a function to get the address of the RSDP table. Per default use a
> __weak annotated function being a nop.
The problem with weak functions that we can't have more than one
implementation per kernel while we would like to built several c
On 24.01.18 20:34, Julien Grall wrote:
At the moment PSCI function dispatching is done in vsmc.c and the
function implementation in vpsci.c. Some bits of the implementation is
even done in vsmc.c (see PSCI_SYSTEM_RESET).
This means that it is difficult to follow the implementation and also
req
On 26.01.18 20:07, Julien Grall wrote:
On 26/01/18 18:03, Volodymyr Babchuk wrote:
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index f543dea0bb..303517459f 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -82,9 +82,23 @@ static inline u
Hi, Martin
On Fri, Jan 26, 2018 at 8:05 PM, Oleksandr Tyshchenko
wrote:
> On Fri, Jan 26, 2018 at 3:49 PM, Julien Grall wrote:
>> Hi,
>>
>> I am CCing Oleksandr. He knows better than me this platform.
>
> Hi, Julien.
>
> OK, thank you, I will try to provide some pointers.
>
>>
>> Cheers,
>>
>> O
Hi,
On 26/01/18 18:09, Volodymyr Babchuk wrote:
On 24.01.18 20:34, Julien Grall wrote:
- case PSCI_0_2_FN32(AFFINITY_INFO):
- case PSCI_0_2_FN64(AFFINITY_INFO):
+ switch ( fid )
{
- register_t taff = PSCI_ARG(regs, 1);
- uint32_t laff = PSCI_ARG32(regs, 2);
-
-
Hi,
On 26/01/18 18:12, Volodymyr Babchuk wrote:
On 26.01.18 20:07, Julien Grall wrote:
On 26/01/18 18:03, Volodymyr Babchuk wrote:
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index f543dea0bb..303517459f 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/
Hi,
On 26.01.18 20:15, Julien Grall wrote:
Hi,
On 26/01/18 18:09, Volodymyr Babchuk wrote:
On 24.01.18 20:34, Julien Grall wrote:
- case PSCI_0_2_FN32(AFFINITY_INFO):
- case PSCI_0_2_FN64(AFFINITY_INFO):
+ switch ( fid )
{
- register_t taff = PSCI_ARG(regs, 1);
-
On Fri, Jan 26, 2018 at 05:46:23PM +, Andrew Cooper wrote:
> On 26/01/18 17:37, Roger Pau Monne wrote:
> > diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> > index a3e8f0c9b9..be95baafe1 100644
> > --- a/xen/arch/x86/traps.c
> > +++ b/xen/arch/x86/traps.c
> > @@ -119,6 +119,25 @@ bool
xl: libxl.c:339: libxl_defbool_val: Assertion `!libxl_defbool_is_default(db)'
failed.
This happens because initiate_domain_create() checks for type != HVM, then
pokes at the hvm union. Check for == HVM instead so the union access is
correctly guarded.
Signed-off-by: Andrew Cooper
---
CC: Ian J
On 26/01/18 19:02, Roger Pau Monné wrote:
> On Fri, Jan 26, 2018 at 05:46:23PM +, Andrew Cooper wrote:
>> On 26/01/18 17:37, Roger Pau Monne wrote:
>>> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
>>> index a3e8f0c9b9..be95baafe1 100644
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/a
flight 118363 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118363/
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
Andrew Cooper writes ("[PATCH] tools/libxl: Fix assertion failure when trying
to build a nested-virt PVH domain"):
> xl: libxl.c:339: libxl_defbool_val: Assertion `!libxl_defbool_is_default(db)'
> failed.
>
> This happens because initiate_domain_create() checks for type != HVM, then
> pokes at t
On 26/01/18 19:11, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH] tools/libxl: Fix assertion failure when trying
> to build a nested-virt PVH domain"):
>> xl: libxl.c:339: libxl_defbool_val: Assertion
>> `!libxl_defbool_is_default(db)' failed.
>>
>> This happens because initiate_domain_creat
c/s 94450e36bfbb removed XEN_DOMCTL_getmemlist entirely, but missed adjusting
the XSM side of things. As far as I can tell, 'pagelist' wasn't even offered
to dom0 in default policy.
Also, drop the stale struct xen_domctl_getmemlist which was missed from the
same changeset.
Signed-off-by: Andrew
On Fri, Jan 26, 2018 at 07:23:52PM +, Andrew Cooper wrote:
> On 26/01/18 19:11, Ian Jackson wrote:
> > Andrew Cooper writes ("[PATCH] tools/libxl: Fix assertion failure when
> > trying to build a nested-virt PVH domain"):
> >> xl: libxl.c:339: libxl_defbool_val: Assertion
> >> `!libxl_defbool
Hi,
> I guess you mean: xilinx_zynqmp, ... ?
Sorry, I would fix and repost it.
Thanks for looking.
-Amit
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
flight 118329 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118329/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-3 49 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 118170
test-xtf-amd64-
flight 118366 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118366/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 118363
Tests which
On Fri, 26 Jan 2018, at 23:16, Christian Lindig wrote:
> using the -unsafe-string option (introduced in OCaml 4.02) to keep
> strings mutable to avoid code changes is not going to work in the long
> run.
Okay,
NAK my unsafe-string patch.
On 26. Jan 2018, at 09:09, M A Young wrote:
> The patch
On 01/26/2018 10:13 AM, Oleksandr Tyshchenko wrote:
Hi, Martin
On Fri, Jan 26, 2018 at 8:05 PM, Oleksandr Tyshchenko
wrote:
On Fri, Jan 26, 2018 at 3:49 PM, Julien Grall wrote:
Hi,
I am CCing Oleksandr. He knows better than me this platform.
Hi, Julien.
OK, thank you, I will try to provi
flight 118372 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118372/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 118363
Tests which
> On 25/01/18 16:09, Andrew Cooper wrote:
> > On 25/01/18 15:57, Jan Beulich wrote:
> > > > > >
> > > For the record, the overwhelming majority of calls to
> > > __sync_local_execstate() being responsible for the behavior
> > > come from invalidate_interrupt(), which suggests to me that
> > > ther
flight 118376 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118376/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 118363
Tests which
flight 118337 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118337/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-xtf-amd64-amd64-5 49 xtf/test-hvm64-lbr-tsx-vmentry fail like 118221
test-xtf-amd64-amd64-3 49 xt
1 - 100 of 104 matches
Mail list logo
