branch xen-unstable
xenbranch xen-unstable
job build-amd64-xen-freebsd
testid host-install(5)
Tree: freebsd git://github.com/freebsd/freebsd.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree:
Hi,
Trying to run XEN on imx8mq which is different from imx8qm in term of
UART controller IP(attached is the debug code).
DTS used for host is :
https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_4.9.x_2.0.0_ga/arch/arm64/boot/dts/freescale/fsl-imx8mq.dtsi
But , I see following issu
flight 133864 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133864/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133696
test-amd64-amd64-xl-qemuu-win7-amd64
>>> On 16.03.19 at 10:57, wrote:
> On 2019/3/15 19:18, Jan Beulich wrote:
> On 15.03.19 at 11:17, wrote:
>>> On 2019/3/15 1:11, Jan Beulich wrote:
>>> On 21.02.19 at 10:48, wrote:
> +static void __init noinline probe_masking_msrs(void)
> +{
> + const struct cpuinfo_x86 *c = &
>>> On 16.03.19 at 11:06, wrote:
> On 2019/3/15 20:40, Jan Beulich wrote:
> On 21.02.19 at 10:48, wrote:
>>> The Hygon Dhyana CPU supports the MSR way to get TOP_MEM2. So add Hygon
>>> Dhyana support to print the value of TOP_MEM2.
>>>
>>> Signed-off-by: Pu Wen
>>
>> Acked-by: Jan Beulich
>>> On 16.03.19 at 11:11, wrote:
> On 2019/3/15 20:41, Jan Beulich wrote:
> On 21.02.19 at 10:50, wrote:
>>> --- a/xen/arch/x86/cpu/vpmu_amd.c
>>> +++ b/xen/arch/x86/cpu/vpmu_amd.c
>>> @@ -545,6 +545,8 @@ int __init amd_vpmu_init(void)
>>> switch ( current_cpu_data.x86 )
>>> {
>>>
This was added to try to ensure a consistent intack from repeated calls to
hvm_vcpu_has_pending_irq(). However there are other ways in which a new
IRR bit could be set between such calls. Hence the poll blocking does not
actually serve any useful purpose, so it may as well be removed to simplify
th
Further testing and code inspection revealed some problems with my recent
series [1]. This series fixes those issues.
[1] https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg01078.html
Paul Durrant (2):
viridian: remove synic poll blocking
viridian: fix mistakes in timer expiratio
This patch fixes a few issues:
- The specification says that a one-shot timers should be marked as
disabled at the point of expiry, so the enabled bit should be cleared by
stimer_expire() rather than poll_stimer(). For simplicity, call
stimer_expire() from start_stimer() for timers that expi
flight 133868 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133868/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
129313
Tests which
>>> On 15.03.19 at 17:39, wrote:
> On 14/03/2019 17:15, Jan Beulich wrote:
> On 14.03.19 at 17:38, wrote:
>>> On 19/12/2018 14:38, Jan Beulich wrote:
@@ -8444,6 +8465,45 @@ x86_emulate(
generate_exception_if(ea.type != OP_MEM || !vex.l || vex.w,
EXC_UD);
>>> On 15.03.19 at 19:21, wrote:
> On 15/03/2019 10:41, Jan Beulich wrote:
>> @@ -6681,6 +6681,12 @@ x86_emulate(
>> case X86EMUL_OPC_EVEX_66(0x0f, 0xf6): /* vpsadbw
>> [xyz]mm/mem,[xyz]mm,[xyz]mm */
>> generate_exception_if(evex.opmsk, EXC_UD);
>> /* fall through */
>> +
>>> On 15.03.19 at 17:07, wrote:
> On 07/03/2019 10:31, Jan Beulich wrote:
>> e820.c: In function ‘clip_to_limit’:
>> .../xen/include/asm/string.h:10:26: error: ‘__builtin_memmove’ offset [-16,
> -36] is out of the bounds [0, 20484] of
>> object ‘e820’ with type ‘struct e820map’ [-Werror=array-bo
+Amazon
pls see inline
On 3/14/19 9:00 PM, Julien Grall wrote:
Hi,
On 3/14/19 3:40 PM, Boris Ostrovsky wrote:
On 3/14/19 11:10 AM, Oleksandr Andrushchenko wrote:
On 3/14/19 5:02 PM, Boris Ostrovsky wrote:
On 3/14/19 10:52 AM, Oleksandr Andrushchenko wrote:
On 3/14/19 4:47 PM, Boris Ostrovsk
>>> On 15.03.19 at 17:21, wrote:
> On 07/03/2019 10:32, Jan Beulich wrote:
>> generic.c: In function ‘print_mtrr_state’:
>> generic.c:210:11: error: ‘%0*lx’ directive output between 1 and 1073741823
> bytes may cause result to exceed
>> ‘INT_MAX’ [-Werror=format-overflow=]
>> 210 |printk("%
>>> On 18.03.19 at 10:06, wrote:
> Further testing and code inspection revealed some problems with my recent
> series [1]. This series fixes those issues.
>
> [1]
> https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg01078.html
>
> Paul Durrant (2):
> viridian: remove synic poll
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 18 March 2019 10:21
> To: Paul Durrant
> Cc: xen-devel
> Subject: Re: [Xen-devel] [PATCH 0/2] Follow-up viridian fixes
>
> >>> On 18.03.19 at 10:06, wrote:
> > Further testing and code inspection revealed some p
On 18/03/2019 10:11, Jan Beulich wrote:
On 15.03.19 at 17:21, wrote:
>> On 07/03/2019 10:32, Jan Beulich wrote:
>>> generic.c: In function ‘print_mtrr_state’:
>>> generic.c:210:11: error: ‘%0*lx’ directive output between 1 and 1073741823
>> bytes may cause result to exceed
>>> ‘INT_MAX’ [-We
On 18/03/2019 07:39, Amit Tomer wrote:
Hi,
Hello,
(XEN) Checking for initrd in /chosen
(XEN) RAM: 4000 - bfff
(XEN)
(XEN) MODULE[0]: be51 - be51d000 Device Tree
(XEN) MODULE[1]: 4048 - 41c8 Kernel
(XEN) RESVD[0]: 430
>>> On 18.03.19 at 11:22, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 18 March 2019 10:21
>> To: Paul Durrant
>> Cc: xen-devel
>> Subject: Re: [Xen-devel] [PATCH 0/2] Follow-up viridian fixes
>>
>> >>> On 18.03.19 at 10:06, wrote:
>> > Further
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 18 March 2019 10:35
> To: Paul Durrant
> Cc: xen-devel
> Subject: Re: [Xen-devel] [PATCH 0/2] Follow-up viridian fixes
>
> >>> On 18.03.19 at 11:22, wrote:
> >> -Original Message-
> >> From: Jan Beulich
Hello,
> The tree you are using is dirty. What did you change?
Just added the imx8mq specific debug so that we can see early prints from XEN,
>
> [..]
>
> > (XEN) GICv3: CPU3: Found redistributor in region 0 @4007a000
> > (XEN) Adding cpu 3 to runqueue 0
> > (XEN) CPU 3 booted.
> > (XEN)
>>> On 18.03.19 at 11:30, wrote:
> On 18/03/2019 10:11, Jan Beulich wrote:
> On 15.03.19 at 17:21, wrote:
>>> @@ -203,14 +202,13 @@ static void __init print_mtrr_state(const char *level)
>>> }
>>> printk("%sMTRR variable ranges %sabled:\n", level,
>>>mtrr_state
Hello,
On 15/03/2019 23:57, Feng Kan OS wrote:
On 3/15/19 4:21 AM, Julien Grall wrote:
On 15/03/2019 08:34, Vishnu Pajjuri OS wrote:
Current pa_range_info table's configuration prevents 42 bit PA systems
from booting DOM0. This patch modifies t0sz=22 and root_order=3
to expose 42-bit IPA (Inte
Hello,
On 18/03/2019 10:41, Amit Tomer wrote:
Hello,
The tree you are using is dirty. What did you change?
Just added the imx8mq specific debug so that we can see early prints from XEN,
[..]
(XEN) GICv3: CPU3: Found redistributor in region 0 @4007a000
(XEN) Adding cpu 3 to runque
Currently the time module lacks vcpu context save helpers and the synic
module lacks domain context save helpers. These helpers are not yet
required but subsequent patches will require at least some of them so this
patch completes the set to avoid introducing them in an ad-hoc way.
Signed-off-by:
This patch introduces an implementation of the SCONTROL, SVERSION, SIEFP,
SIMP, EOM and SINT0-15 SynIC MSRs. No message source is added and, as such,
nothing will yet generate a synthetic interrupt. A subsequent patch will
add an implementation of synthetic timers which will need the infrastructure
Currently the viridian_domain and viridian_vcpu structures are inline in
the hvm_domain and hvm_vcpu structures respectively. Subsequent patches
will need to add sizable extra fields to the viridian structures which
will cause the PAGE_SIZE limit of the overall vcpu structure to be
exceeded. This p
...inside viridian_page_msr and viridian_guest_os_id_msr unions.
There's no need to name it and the code is shortened by not doing so.
No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v4:
- New in v4
---
xen
This patch adds domain and vcpu init hooks for viridian features. The init
hooks do not yet do anything; the functionality will be added to by
subsequent patches.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: "Roger Pau Monné"
v5:
- Put the
Whilst the reference tsc page does not currently need to be kept mapped
after it is initially set up (or updated after migrate), the code can
be simplified by using the common guest page map/unmap and dump functions.
New functionality added by a subsequent patch will also require the page to
kept m
This patch simply adds domain and vcpu init/deinit hooks into the synic
and time modules and wires them into viridian_[domain|vcpu]_[init|deinit]().
Only one of the hooks is currently needed (to unmap the 'VP Assist' page)
but subsequent patches will make use of the others.
NOTE: To perform the un
This series adds three new enlightenments:
- Synthetic timers, which depends on the...
- Synthetic interrupt controller (or SynIC)
- Synthetic cluster IPI
All these enlightenments are implemented in current versions of QEMU/KVM
so this series closes the gap.
Paul Durrant (11):
viridian: add in
...where there is more than one dereference inside a function.
This shortens the code and makes it more readable. No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v4:
- New in v4
---
xen/arch/x86/hvm/viridia
...from arch_domain_shutdown/pause/unpause().
A subsequent patch will introduce an implementaion of synthetic timers
which will also need freeze/thaw hooks, so make the exported hooks more
generic and call through to (re-named and static) time_ref_count_freeze/thaw
functions.
NOTE: This patch als
This patch adds an implementation of the hypercall as documented in the
specification [1], section 10.5.2. This enlightenment, as with others, is
advertised by CPUID leaf 0x4004 and is under control of a new
'hcall_ipi' option in libxl.
If used, this enlightenment should mean the guest only ta
* Some of the single-byte versions specify "=q" as the output. This is a
remnent of the 32bit build and can be relaxed to "=r" in 64bit builds.
* Constraints in the form "=r" (x) : "0" (x) can be folded to just "+r" (x)
* Switch to using named parameters (mostly for legibility) which in
p
All currently-released Atom processors are in practice retpoline-safe, because
they don't fall back to a BTB prediction on RSB underflow.
However, an additional meaning of Enhanced IRBS is that the processor may not
be retpoline-safe. The Gemini Lake platform, based on the Goldmont+
microarchitec
This patch introduces an implementation of the STIMER0-15_CONFIG/COUNT MSRs
and hence a the first SynIC message source.
The new (and documented) 'stimer' viridian enlightenment group may be
specified to enable this feature.
While in the neighbourhood, this patch adds a missing check for an
attemp
Hello Julien, Guys,
Sorry for a delayed answer. I caught a pretty nasty flu after last long
weekend, it made me completely unavailable last week :(
On 07.03.19 17:17, Julien Grall wrote:
Why? Arm32 is as equally supported as Arm64.
Yep, I believe that.
But I do not expect one would build arm3
flight 83744 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/83744/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
They are unnecesserily verbose, and ARCH_CAPS_* is already the more common
version.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/spec_ctrl.c| 10 +-
xen/include/asm-x86/msr-index.h | 4 ++--
2 files changed, 7 insertions(+)
>>> On 18.03.19 at 12:27, wrote:
> However, an additional meaning of Enhanced IRBS is that the processor may not
> be retpoline-safe. The Gemini Lake platform, based on the Goldmont+
> microarchitecture is the first Atom processor to support eIBRS, even though it
> is in practice safe.
But afaic
On 18/03/2019 11:31, Andrii Anisov wrote:
Hello Julien, Guys,
Hi,
Sorry for a delayed answer. I caught a pretty nasty flu after last long weekend,
it made me completely unavailable last week :(
Sorry to hear that.
On 07.03.19 17:17, Julien Grall wrote:
Why? Arm32 is as equally supported
>>> On 18.03.19 at 12:45, wrote:
> They are unnecesserily verbose, and ARCH_CAPS_* is already the more common
> version.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists
> It will be difficult to help without any log. You probably want to try with
> Stefano series instead. However ...
Yeah, tried Stefano series as well but show same message:
Starting kernel ...
- UART enabled -
- CPU booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Zero BSS
flight 133900 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133900/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 18/03/2019 11:58, Jan Beulich wrote:
On 18.03.19 at 12:27, wrote:
>> However, an additional meaning of Enhanced IRBS is that the processor may not
>> be retpoline-safe. The Gemini Lake platform, based on the Goldmont+
>> microarchitecture is the first Atom processor to support eIBRS, even
Add a new cpu notifier action CPU_RESUME_FAILED which is called for all
cpus which failed to come up at resume. The calls will be done after
all other cpus are already up.
Signed-off-by: Juergen Gross
---
xen/common/cpu.c | 5 +
xen/include/xen/cpu.h | 20 +++-
2 files
Instead of removing cpus temporarily from cpupools during
suspend/resume only remove cpus finally which didn't come up when
resuming.
Signed-off-by: Juergen Gross
---
xen/common/cpupool.c | 130 ++---
xen/include/xen/sched-if.h | 1 -
2 files chang
Today there is special handling in cpu_disable_scheduler() for suspend
by forcing all vcpus to the boot cpu. In fact there is no need for that
as during resume the vcpus are put on the correct cpus again.
So we can just omit the call of cpu_disable_scheduler() when offlining
a cpu due to suspend a
cpu_disable_scheduler() is being called from __cpu_disable() today.
There is no need to call it on the cpu just being disabled, so use
the CPU_DEAD case of the cpu notifier chain.
Signed-off-by: Juergen Gross
---
xen/arch/x86/smpboot.c | 3 ---
xen/common/schedule.c | 12 +---
2 files
Add a helper cpu_notifier_call_chain() to call notifier_call_chain()
for a cpu with a specified action, returning an errno value.
This avoids coding the same pattern multiple times.
Signed-off-by: Juergen Gross
---
xen/common/cpu.c | 50 +-
1 file
Especially in the scheduler area (schedule.c, cpupool.c) there is a
rather complex handling involved when doing suspend and resume.
This can be simplified a lot by not performing a complete cpu down and
up cycle for the non-boot cpus, but keeping the pure software related
state and freeing it only
Instead of freeing percpu areas during suspend and allocating them
again when resuming keep them. Only free an area in case a cpu didn't
come up again when resuming.
Signed-off-by: Juergen Gross
---
xen/arch/x86/percpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/a
On 18/03/2019 06:50, rambl...@sina.com wrote:
Hello,
Hello,
I'm researching xen for automotive use case and I see a presentation called:
"Design and Implementation of Automotive Virtualization Based on Xen - Sung-Min
Lee, Samsung Electronics"
on Xen Developer and Design Summit 2018.
I'm in
>>> On 18.03.19 at 12:27, wrote:
> * Some of the single-byte versions specify "=q" as the output. This is a
>remnent of the 32bit build and can be relaxed to "=r" in 64bit builds.
I have to admit that I don't understand the "relaxed" part of this:
"q" and "r" represent the exact same set of
>>> On 18.03.19 at 14:04, wrote:
> On 18/03/2019 11:58, Jan Beulich wrote:
> On 18.03.19 at 12:27, wrote:
>>> However, an additional meaning of Enhanced IRBS is that the processor may
>>> not
>>> be retpoline-safe. The Gemini Lake platform, based on the Goldmont+
>>> microarchitecture is th
thanks for the review.
On Wed, 2019-03-13 at 17:35 +0100, Jan Beulich wrote:
> > > > On 06.03.19 at 13:58, wrote:
> > +static int get_params(const char *cmdline, char *values,
> > + const struct kernel_param *start,
> > + const struct kernel_param *end)
>
On 18.03.19 14:25, Julien Grall wrote:
As I already said multiple times before, please try to explain everything in
your first e-mail...
I know. I'm trying to provide enough info in the cover letter. But it seems I
do not succeed.
Putting all the thoughts might lead into overburdened text. B
Hi Volodymyr,
Only few NITs in this patch. See below:
On 07/03/2019 21:04, Volodymyr Babchuk wrote:
+/*
+ * Default maximal number concurrent threads that OP-TEE supports.
+ * This limits number of standard calls that guest can have.
+ */
+#define DEF_MAX_OPTEE_THREADS 16
+
#define OPTEE_KNOW
Hi,
I closely followed
https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/CrossCompiling
to cross compile xen tool, but "saucy" is a wrong option now.
Which discts/folder would you recommend now?
sbuild-createchroot --components=main,universe saucy
/srv/chroots/saucy-armhf-cross
>>> On 18.03.19 at 14:34, wrote:
> On Wed, 2019-03-13 at 17:35 +0100, Jan Beulich wrote:
>> > > > On 06.03.19 at 13:58, wrote:
>> > +found = false;
>>
>> I don't think you need this variable here, or if so, it shouldn't
>> be boolean: Either you mean to support returning data for
>> mult
On 18/03/2019 13:20, Jan Beulich wrote:
> >>> On 18.03.19 at 12:27, wrote:
>> * Some of the single-byte versions specify "=q" as the output. This is a
>>remnent of the 32bit build and can be relaxed to "=r" in 64bit builds.
> I have to admit that I don't understand the "relaxed" part of this
Hi Volodymyr,
On 07/03/2019 21:04, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
OP-TEE usually uses the same idea with command buffers (see
previous commit) to issue RPC requests. Problem is that initially
it has no buffer, where it can write request. So the first RPC
request it makes is s
>>> On 18.03.19 at 12:20, wrote:
> @@ -72,11 +77,14 @@ static void update_reference_tsc(struct domain *d, bool
> initialize)
> * ticks per 100ns shifted left by 64.
> */
> p->TscScale = ((1ul << 32) / d->arch.tsc_khz) << 32;
> +smp_wmb();
> +
> +seq = p->TscSequence +
flight 133863 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133863/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 12 guest-start fail REGR. vs. 133580
test-arm64-arm64-xl
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 18 March 2019 14:24
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; Roger Pau Monne
> ; Wei Liu ; George Dunlap
> ; Ian
> Jackson ; Stefano Stabellini
> ; xen-devel de...@lists.xenproject.org>; Konrad
> On 18/03/2019 06:50, rambl...@sina.com wrote:
> > Hello,
> Hello,
> > I'm researching xen for automotive use case and I see a presentation called:
> > "Design and Implementation of Automotive Virtualization Based on Xen -
> > Sung-Min
> > Lee, Samsung Electronics"
> > on Xen Developer and Design
On 18/03/2019 14:11, Andrew Cooper wrote:
>
>>> @@ -63,36 +65,38 @@ static always_inline __uint128_t cmpxchg16b_local_(
>>> * If no fault occurs then _o is updated to the value we saw at _p. If this
>>> * is the same as the initial value of _o then _n is written to location
>>> _p.
>>> */
>>
The pvshim is loaded directly by toolstack. Use 2M alignment for
potential better performance.
Signed-off-by: Wei Liu
---
xen/arch/x86/configs/pvshim_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/configs/pvshim_defconfig
b/xen/arch/x86/configs/pvshim_defconfig
index
Introduce a new Kconfig option to pick the alignment for xen binary.
To retain original behaviour, the default pick for EFI build is 2M and
non-EFI build 4K.
Signed-off-by: Wei Liu
---
xen/arch/x86/Kconfig | 26 ++
xen/arch/x86/xen.lds.S | 16 ++--
2 files c
Wei Liu (2):
x86: decouple xen alignment setting from EFI/non-EFI build
x86/pvshim: use 2M alignment
xen/arch/x86/Kconfig | 26 ++
xen/arch/x86/configs/pvshim_defconfig | 1 +
xen/arch/x86/xen.lds.S| 16 ++--
3 files change
>>> On 18.03.19 at 15:11, wrote:
> On 18/03/2019 13:20, Jan Beulich wrote:
>> >>> On 18.03.19 at 12:27, wrote:
>>> * Some of the single-byte versions specify "=q" as the output. This is a
>>>remnent of the 32bit build and can be relaxed to "=r" in 64bit builds.
>> I have to admit that I don
Hi all,
Xen 4.12 rc6 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.12.0-rc6
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.12.0-rc6/xen-4.12.0-rc6.tar.gz
And the signature is at:
https://downloads.xenproject.org/
>>> On 18.03.19 at 15:49, wrote:
> On 18/03/2019 14:11, Andrew Cooper wrote:
>>
@@ -63,36 +65,38 @@ static always_inline __uint128_t cmpxchg16b_local_(
* If no fault occurs then _o is updated to the value we saw at _p. If
this
* is the same as the initial value of _o then
Hello,
> It will be difficult to help without any log. You probably want to try with
> Stefano series instead. However ...
If we comment out GPU node(gpu@3800) , we don't see this issue and
Dom0 kernel is
loaded into memory but we following crash:
Starting kernel ...
- UART enabled -
- CPU
>>> On 18.03.19 at 15:37, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 18 March 2019 14:24
>>
>> >>> On 18.03.19 at 12:20, wrote:
>> > @@ -72,11 +77,14 @@ static void update_reference_tsc(struct domain *d,
>> > bool initialize)
>> > * ticks per 100ns shifted left by 64.
On 07/03/2019 21:04, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
Some of the patches are using your EPAM e-mail addresss. Other are using your
gmail address. Could you confirm this is expected?
Shared memory is widely used by NW (Normal World) to communicate with
TAs (Trusted Appli
flight 133876 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133876/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 133846
test-amd64-amd64-libvir
Hi Volodymyr,
On 07/03/2019 21:04, Volodymyr Babchuk wrote:
@@ -376,8 +391,11 @@ static struct shm_rpc *allocate_and_pin_shm_rpc(struct
optee_domain *ctx,
return shm_rpc;
err:
+free_domheap_page(shm_rpc->xen_arg_pg);
+
if ( shm_rpc->guest_page )
put_page(shm_rpc-
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Jan Beulich
> Sent: 18 March 2019 15:21
> To: Paul Durrant
> Cc: Stefano Stabellini ; Wei Liu
> ; Konrad Rzeszutek Wilk
> ; Andrew Cooper ; Tim
> (Xen.org) ;
> George Dunlap ; Julien Gr
On Mon, 2019-03-18 at 15:02 +0100, Jan Beulich wrote:
> > > > From the return value of strcmp()? I don't think so, because
> > > > you
> may have run past all table entries. Instead it's that property
> that you can use, i.e. checking whether ...
>
> > > > +for ( param = start; param < end
Or if it's not possible to honor the hinted address an error is returned
instead. This makes it easier to spot the actual failure, instead of
failing later on when the caller of xen_remap_bucket realizes the
mapping has not been created at the requested address.
Also note that at least on FreeBSD
(+ Achin)
On 07/03/2019 21:04, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
This enumeration controls TEE type for a domain. Currently there is
two possible options: either 'none' or 'native'.
'none' is the default value and it basically disables TEE support at
all.
'native' enables acce
On 18/03/2019 15:45, Roger Pau Monne wrote:
> Or if it's not possible to honor the hinted address an error is returned
> instead. This makes it easier to spot the actual failure, instead of
> failing later on when the caller of xen_remap_bucket realizes the
> mapping has not been created at the req
> -Original Message-
[snip]
> > > +{
> > > +expiration = vs->count;
> > > +if ( expiration - now <= 0 )
> > > +{
> > > +vs->expiration = expiration;
> > > +stimer_expire(vs);
> >
> > Aren't you introducing a risk for races by calling the t
> -Original Message-
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: 18 March 2019 15:46
> To: qemu-de...@nongnu.org
> Cc: Roger Pau Monne ; Stefano Stabellini
> ; Anthony
> Perard ; Paul Durrant ;
> Igor Druzhinin
> ; Paolo Bonzini ; Richard
> Henderson ;
> Eduardo Habkost
Hi,
On 07/03/2019 21:04, Volodymyr Babchuk wrote:
static int make_memory_nodes(libxl__gc *gc, void *fdt,
const struct xc_dom_image *dom)
{
@@ -933,6 +959,9 @@ next_resize:
if (info->arch_arm.vuart == LIBXL_VUART_TYPE_SBSA_UART)
FDT( make
On 2019/3/18 16:57, Jan Beulich wrote:
On 16.03.19 at 11:06, wrote:
>> On 2019/3/15 20:40, Jan Beulich wrote:
>> On 21.02.19 at 10:48, wrote:
The Hygon Dhyana CPU supports the MSR way to get TOP_MEM2. So add Hygon
Dhyana support to print the value of TOP_MEM2.
Signed-
On Mon, Mar 18, 2019 at 03:48:59PM +, Igor Druzhinin wrote:
> On 18/03/2019 15:45, Roger Pau Monne wrote:
> > Or if it's not possible to honor the hinted address an error is returned
> > instead. This makes it easier to spot the actual failure, instead of
> > failing later on when the caller of
All,
the release is due by the end of the month, but will likely don't make
it before early April. Please point out backports you find missing from
the respective staging branch, but which you consider relevant. The
one commit I've queued already on top of what was just pushed is
22e2f8dddf
>>> On 18.03.19 at 16:36, wrote:
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
>> Jan Beulich
>> Sent: 18 March 2019 15:21
>>
>> >>> On 18.03.19 at 15:37, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: 18 March 2019 14:24
>> >>
>> >> >>>
>>> On 18.03.19 at 16:46, wrote:
>> > > +{
>> > > +expiration = vs->count;
>> > > +if ( expiration - now <= 0 )
>> > > +{
>> > > +vs->expiration = expiration;
>> > > +stimer_expire(vs);
>> >
>> > Aren't you introducing a risk for races by calling
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 18 March 2019 16:23
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Roger Pau
> Monne
> ; Wei Liu ; Stefano Stabellini
> ;
> xen-devel ; Konrad Rzeszutek Wilk
> ; Tim
>
On Mon, Mar 18, 2019 at 03:48:59PM +, Igor Druzhinin wrote:
> On 18/03/2019 15:45, Roger Pau Monne wrote:
> > diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
> > index 349f72d00c..23de5517db 100644
> > --- a/hw/i386/xen/xen-mapcache.c
> > +++ b/hw/i386/xen/xen-mapcache.c
>
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 18 March 2019 16:35
> To: Igor Druzhinin
> Cc: Roger Pau Monne ; qemu-de...@nongnu.org; Stefano
> Stabellini
> ; Paul Durrant ; Paolo
> Bonzini ;
> Richard Henderson ; Eduardo Habkost ;
> Michael S. T
>>> On 18.03.19 at 16:51, wrote:
> On 2019/3/18 16:57, Jan Beulich wrote:
> On 16.03.19 at 11:06, wrote:
>>> On 2019/3/15 20:40, Jan Beulich wrote:
>>> On 21.02.19 at 10:48, wrote:
> The Hygon Dhyana CPU supports the MSR way to get TOP_MEM2. So add Hygon
> Dhyana support to print
>>> On 18.03.19 at 17:26, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 18 March 2019 16:23
>>
>> >>> On 18.03.19 at 16:46, wrote:
>> >> > > +{
>> >> > > +expiration = vs->count;
>> >> > > +if ( expiration - now <= 0 )
>> >> > > +{
>> >> > > +
>>> On 18.03.19 at 16:44, wrote:
> On Mon, 2019-03-18 at 15:02 +0100, Jan Beulich wrote:
>> > > I'm also
>> > > unconvinced this is appropriate if the value is actually
>> > > a signed quantity.
>> >
>> > isn't OPT_UINT only for unsigned integers?
>>
>> You'll notice that there's no OPT_INT or O
1 - 100 of 136 matches
Mail list logo
