On 09/11/2018 08:52 AM, Oleksandr Andrushchenko wrote:
> Hi, Hans!
>
> On 09/10/2018 03:26 PM, Hans Verkuil wrote:
>> On 09/10/2018 01:49 PM, Oleksandr Andrushchenko wrote:
>>> On 09/10/2018 02:09 PM, Hans Verkuil wrote:
On 09/10/2018 11:52 AM, Oleksandr Andrushchenko wrote:
> On 09/10/20
Commit 57f230ab04d291 ("xen/netfront: raise max number of slots in
xennet_get_responses()") raised the max number of allowed slots by one.
This seems to be problematic in some configurations with netback using
a larger MAX_SKB_FRAGS value (e.g. old Linux kernel with MAX_SKB_FRAGS
defined as 18 inst
On 09/11/2018 10:04 AM, Hans Verkuil wrote:
On 09/11/2018 08:52 AM, Oleksandr Andrushchenko wrote:
Hi, Hans!
On 09/10/2018 03:26 PM, Hans Verkuil wrote:
On 09/10/2018 01:49 PM, Oleksandr Andrushchenko wrote:
On 09/10/2018 02:09 PM, Hans Verkuil wrote:
On 09/10/2018 11:52 AM, Oleksandr Andrus
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
xen/arch/arm/traps.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 9ae64ae..45fb3d5 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -244,7 +2
On 09/05/2018 11:27 PM, Jim Fehlig wrote:
> Patch 5 fixes a long standing problem found by some very slow hosts in
> xen's osstest
>
> https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg01945.html
>
> While working on the fix, I discovered other problems in libxl's V3
> migration pro
This run is configured for baseline tests only.
flight 75195 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75195/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
> -Original Message-
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: 07 September 2018 10:08
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Jan
> Beulich ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Stefano Stabelli
On 09/11/18 09:14, Oleksandr Andrushchenko wrote:
> On 09/11/2018 10:04 AM, Hans Verkuil wrote:
>> On 09/11/2018 08:52 AM, Oleksandr Andrushchenko wrote:
>>> Hi, Hans!
>>>
>>> On 09/10/2018 03:26 PM, Hans Verkuil wrote:
On 09/10/2018 01:49 PM, Oleksandr Andrushchenko wrote:
> On 09/10/2018
Am Fri, 7 Sep 2018 12:56:37 -0400
schrieb Boris Ostrovsky :
> I was hoping you'd respond to my question about warning.
It looks like CONFIG_BOOTPARAM_HOTPLUG_CPU0=y is the reason for the warning.
As Jürgen suggested in another mail, Xen should probably disable hotplugging
for cpu#0 in the generic
On 11/09/18 09:52, Olaf Hering wrote:
> Am Fri, 7 Sep 2018 12:56:37 -0400
> schrieb Boris Ostrovsky :
>
>> I was hoping you'd respond to my question about warning.
>
> It looks like CONFIG_BOOTPARAM_HOTPLUG_CPU0=y is the reason for the warning.
> As Jürgen suggested in another mail, Xen should pr
>>> On 10.09.18 at 23:56, wrote:
> On 09/10/2018 10:03 AM, Jan Beulich wrote:
>> Having noticed that VMLOAD alone is about as fast as a single of the
>> involved WRMSRs, I thought it might be a reasonable idea to also use it
>> for PV. Measurements, however, have shown that an actual improvement c
>>> On 10.09.18 at 19:51, wrote:
> On 10/09/18 14:29, Jan Beulich wrote:
> On 10.09.18 at 15:21, wrote:
>> On 31.08.18 at 10:43, wrote:
>>> On 31.08.18 at 10:29, wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -11,6 +11,13 @@ config DEBUG
>
>
> -Original Message-
> From: zhong jiang [mailto:zhongji...@huawei.com]
> Sent: 08 September 2018 14:54
> To: da...@davemloft.net; Paul Durrant ; Wei Liu
>
> Cc: xen-devel@lists.xenproject.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] xen-netback: remove u
> -Original Message-
> From: zhong jiang [mailto:zhongji...@huawei.com]
> Sent: 08 September 2018 14:35
> To: da...@davemloft.net; Paul Durrant ; Wei Liu
>
> Cc: xen-devel@lists.xenproject.org; net...@vger.kernel.org
> Subject: [PATCH] net: xenbus: remove redundant condition check before
>
>>> On 10.09.18 at 18:40, wrote:
> On Mon, Jul 16, 2018 at 5:39 AM Jan Beulich wrote:
>
>> >>> On 13.07.18 at 20:54, wrote:
>> > Hello,
>> >
>> > I'm currently testing last Xen 4.8.4 build for CentOS
>> > (http://cbs.centos.org/koji/buildinfo?buildID=23169) and disabling
>> > XPTI for dom0 does
On 09/11/2018 10:52 AM, Hans Verkuil wrote:
On 09/11/18 09:14, Oleksandr Andrushchenko wrote:
On 09/11/2018 10:04 AM, Hans Verkuil wrote:
On 09/11/2018 08:52 AM, Oleksandr Andrushchenko wrote:
Hi, Hans!
On 09/10/2018 03:26 PM, Hans Verkuil wrote:
On 09/10/2018 01:49 PM, Oleksandr Andrushchen
From: Andrii Anisov
The structure member last_run_time is used by a credit scheduler only.
So move it from a generic vcpu sctructure to the credit scheduler private
vcpu definition.
Signed-off-by: Andrii Anisov
---
xen/common/sched_credit.c | 12 +---
xen/common/schedule.c | 1 -
>>> On 28.08.18 at 16:54, wrote:
> First and foremost the fix for XSA-270. On top of that further changes
> which looked desirable to me while investigating that XSA.
>
> 1: fix input validation in xenvif_set_hash_mapping()
> 2: validate queue numbers in xenvif_set_hash_mapping()
> 3: handle page
>>> On 29.08.18 at 14:36, wrote:
> On 21/08/18 11:44, Jan Beulich wrote:
>> While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
>> parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that
>> this then became equivalent to "xpti=no".
>
> That was accidental, but the end r
>>> On 11.09.18 at 09:18, wrote:
> From: Andrii Anisov
>
> Signed-off-by: Andrii Anisov
> ---
> xen/arch/arm/traps.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
Two things: Could you please make your subject make clear this is
about ARM, so that people know whether to
>>> On 11.09.18 at 08:53, wrote:
> --- a/xen/common/perfc.c
> +++ b/xen/common/perfc.c
> @@ -33,8 +33,7 @@ void perfc_printall(unsigned char key)
> unsigned int i, j;
> s_time_t now = NOW();
>
> -printk("Xen performance counters SHOW (now = 0x%08X:%08X)\n",
> - (u32)(now
From: Oleksandr Andrushchenko
Hello!
At the moment Xen [1] already supports some virtual multimedia
features [2] such as virtual display, sound. It supports keyboards,
pointers and multi-touch devices all allowing Xen to be used in
automotive appliances, In-Vehicle Infotainment (IVI) systems
and
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
camera driver which extends Xen's reach multimedia capabilities even
farther enabling it for video conferencing, In-Vehicle Infotainment,
high definition maps etc.
The initial goal is to support most needed fu
>>> On 11.09.18 at 10:10, wrote:
> From: Andrii Anisov
>
> The structure member last_run_time is used by a credit scheduler only.
> So move it from a generic vcpu sctructure to the credit scheduler private
> vcpu definition.
>
> Signed-off-by: Andrii Anisov
> ---
> xen/common/sched_credit.c |
flight 127479 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127479/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs. 125898
Hello Jan,
On 11.09.18 11:27, Jan Beulich wrote:
NAK, for two reasons: I'm not of the opinion that reading a 15 or more
digit decimal number without any separators is any easier than the
current format.
It's quite subjective. IMHO timestamps measured in ns easier to
understand in decimals rath
Hello Jan,
On 11.09.18 11:23, Jan Beulich wrote:
Two things: Could you please make your subject make clear this is
about ARM, so that people know whether to look at the patch?
Got it.
And - since this pattern repeats - could you please refrain from
spamming the list by sending all of your pa
>>> On 11.09.18 at 10:50, wrote:
> On 11.09.18 11:27, Jan Beulich wrote:
>> NAK, for two reasons: I'm not of the opinion that reading a 15 or more
>> digit decimal number without any separators is any easier than the
>> current format.
> It's quite subjective. IMHO timestamps measured in ns easier
On 11/09/18 10:10, Jan Beulich wrote:
On 11.09.18 at 10:50, wrote:
>> On 11.09.18 11:27, Jan Beulich wrote:
>>> NAK, for two reasons: I'm not of the opinion that reading a 15 or more
>>> digit decimal number without any separators is any easier than the
>>> current format.
>> It's quite subje
>>> On 11.09.18 at 11:15, wrote:
> On 11/09/18 10:10, Jan Beulich wrote:
> On 11.09.18 at 10:50, wrote:
>>> On 11.09.18 11:27, Jan Beulich wrote:
NAK, for two reasons: I'm not of the opinion that reading a 15 or more
digit decimal number without any separators is any easier than the
On 11.09.18 12:10, Jan Beulich wrote:
It is subjective, yes, but in such a case you even more so need to
demonstrate a change is an overall improvement.
I would phrase it as "printing timestapms in timestamp format".
--
*Andrii Anisov*
___
Xen-dev
On 11/09/18 10:18, Jan Beulich wrote:
On 11.09.18 at 11:15, wrote:
>> On 11/09/18 10:10, Jan Beulich wrote:
>> On 11.09.18 at 10:50, wrote:
On 11.09.18 11:27, Jan Beulich wrote:
> NAK, for two reasons: I'm not of the opinion that reading a 15 or more
> digit decimal number w
On 11.09.18 12:18, Jan Beulich wrote:
What other separator do you suggest? I consider it quite helpful
to have one when there are more than about 10 digits. (I'd also
be fine, btw, to have the time printed in decimal, but then
perhaps with ms granularity and 6 digits for the fractional part.)
S
flight 127492 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127492/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
build-amd64-libvirt
On 09/11/2018 09:50 AM, Andrii Anisov wrote:
> Hello Jan,
>
>
> On 11.09.18 11:27, Jan Beulich wrote:
>> NAK, for two reasons: I'm not of the opinion that reading a 15 or more
>> digit decimal number without any separators is any easier than the
>> current format.
> It's quite subjective. IMHO ti
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 September 2018 11:40
> To: Paul Durrant
> Cc: Kevin Tian ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [PATCH v6 06/14] iommu: track reserved ranges using a rangeset
>
> >>> On 23.08.18 at 11:47, wro
On 09/11/2018 10:18 AM, Jan Beulich wrote:
On 11.09.18 at 11:15, wrote:
>> On 11/09/18 10:10, Jan Beulich wrote:
>> On 11.09.18 at 10:50, wrote:
On 11.09.18 11:27, Jan Beulich wrote:
> NAK, for two reasons: I'm not of the opinion that reading a 15 or more
> digit decimal num
>>> On 11.09.18 at 11:20, wrote:
> On 11/09/18 10:18, Jan Beulich wrote:
> On 11.09.18 at 11:15, wrote:
>>> On 11/09/18 10:10, Jan Beulich wrote:
>>> On 11.09.18 at 10:50, wrote:
> On 11.09.18 11:27, Jan Beulich wrote:
>> NAK, for two reasons: I'm not of the opinion that reading
>>> On 11.09.18 at 11:21, wrote:
> On 11.09.18 12:18, Jan Beulich wrote:
>> What other separator do you suggest? I consider it quite helpful
>> to have one when there are more than about 10 digits. (I'd also
>> be fine, btw, to have the time printed in decimal, but then
>> perhaps with ms granula
flight 127486 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127486/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-examine 1 build-check(1) blocked n/a
test-arm64-arm64-xl-credit2 1 build-check
>>> On 11.09.18 at 11:24, wrote:
> On 09/11/2018 09:50 AM, Andrii Anisov wrote:
>> Hello Jan,
>>
>>
>> On 11.09.18 11:27, Jan Beulich wrote:
>>> NAK, for two reasons: I'm not of the opinion that reading a 15 or more
>>> digit decimal number without any separators is any easier than the
>>> curre
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 September 2018 12:01
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; Stefano Stabellini
> ; xen-devel ;
> Konrad Rzeszutek Wilk ; Tim (Xen.org)
>
> Subject: Re: [PATCH v6 07
>>> On 11.09.18 at 11:28, wrote:
> On 09/11/2018 10:18 AM, Jan Beulich wrote:
> On 11.09.18 at 11:15, wrote:
>>> On 11/09/18 10:10, Jan Beulich wrote:
>>> On 11.09.18 at 10:50, wrote:
> On 11.09.18 11:27, Jan Beulich wrote:
>> NAK, for two reasons: I'm not of the opinion that rea
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 September 2018 12:20
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap
> ; Jun Nakajima ;
> Stefano Stabellini ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [PATCH v6 09/14] mm /
>>> On 11.09.18 at 11:34, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 07 September 2018 12:01
>>
>> >>> On 23.08.18 at 11:47, wrote:
>> > This patch adds an iommu_op to allow the domain IOMMU reserved
>> ranges to be
>> > queried by the guest.
>> >
>> > NOTE: The number of re
>>> On 11.09.18 at 11:39, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 07 September 2018 12:20
>> To: Paul Durrant
>> Cc: Julien Grall ; Andrew Cooper
>> ; George Dunlap
>> ; Jun Nakajima ;
>> Stefano Stabellini ; xen-devel > de...@lists.xenprojec
On 11.09.18 12:30, Jan Beulich wrote:
Should we think about replacing PRI_stime?
Why not, but that would require adding another %p suffix or
introducing a construct splitting s_time_t values into two pieces
(to be used to hide the two printk() arguments required).
I don't think that splitting
On 11.09.18 12:33, Jan Beulich wrote:
Well, what should I say - I disagree. I would agree if it would be a
whole lot of work, but there's not that many key handlers to begin
with, and far not all of them print a time stamp in their headlines.
I'm quite ok with that.
--
*Andrii Anisov*
On 09/11/2018 10:33 AM, Jan Beulich wrote:
On 11.09.18 at 11:24, wrote:
>> On 09/11/2018 09:50 AM, Andrii Anisov wrote:
>>> Hello Jan,
>>>
>>>
>>> On 11.09.18 11:27, Jan Beulich wrote:
NAK, for two reasons: I'm not of the opinion that reading a 15 or more
digit decimal number withou
On 10/09/18 15:00, Jan Beulich wrote:
> Real hardware wraps silently in most cases, so we should behave the
> same. Also split real and VM86 mode handling, as the latter really
> ought to have limit checks applied.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
__
On 09/10/2018 05:41 PM, Andrii Anisov wrote:
> From: Andrii Anisov
The title here makes it seem like you're introducing new functionality,
when in fact you're just documenting and tweaking existing functionality.
The description should be something like:
---
xentrace_format: Document -c option
On Tue, Sep 11, 2018 at 02:12:07AM -0600, Jan Beulich wrote:
> >>> On 28.08.18 at 16:54, wrote:
> > First and foremost the fix for XSA-270. On top of that further changes
> > which looked desirable to me while investigating that XSA.
> >
> > 1: fix input validation in xenvif_set_hash_mapping()
>
On 09/10/2018 05:41 PM, Andrii Anisov wrote:
> From: Andrii Anisov
>
> In some systems fraction of the MHz might be a meaningful part
> of the cycles frequency value. So accept MHz value as float.
>
> Signed-off-by: Andrii Anisov
Acked-by: George Dunlap
__
flight 127496 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127496/
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 09/10/2018 05:41 PM, Andrii Anisov wrote:
> From: Andrii Anisov
>
> For convinience, print RTDS budget and deadline values as decimals.
>
> Signed-off-by: Andrii Anisov
Acked-by: George Dunlap
> ---
> tools/xentrace/formats | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
Hello George,
On 11.09.18 13:15, George Dunlap wrote:
if mhz:
-tsc = tsc / (mhz*100.0)
+tsc = tsc * 1000.0 / mhz
Why do you prefer this?
I'm playing with scheduling from one hand, so time stamps in seconds
does not give understanding about what's going on
flight 75197 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/75197/
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
On 11/09/18 10:04, Andrii Anisov wrote:
Hello Jan,
On 11.09.18 11:23, Jan Beulich wrote:
Two things: Could you please make your subject make clear this is
about ARM, so that people know whether to look at the patch?
Got it.
And - since this pattern repeats - could you please refrain from
On 11/09/18 08:18, Andrii Anisov wrote:
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
xen/arch/arm/traps.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 9ae64ae..45fb3d5 100644
--- a/xen/arch/arm/t
Jim Fehlig writes ("[PATCH OSSTEST] Install GnuTLS for libvirt builds"):
> Since libvirt commit 60d9ad6f GnuTLS is required to build libvirt. The
> various libvirt build tests in osstest began failing after the commit
> hit libvirt.git master. Adding libgnutls28-dev to the list of packages
> needed
On 09/11/2018 11:32 AM, Andrii Anisov wrote:
> Hello George,
>
>
> On 11.09.18 13:15, George Dunlap wrote:
>>> if mhz:
>>> - tsc = tsc / (mhz*100.0)
>>> + tsc = tsc * 1000.0 / mhz
>> Why do you prefer this?
> I'm playing with scheduling from one hand, so time s
On 09/11/2018 11:44 AM, George Dunlap wrote:
> On 09/11/2018 11:32 AM, Andrii Anisov wrote:
>> Hello George,
>>
>>
>> On 11.09.18 13:15, George Dunlap wrote:
if mhz:
- tsc = tsc / (mhz*100.0)
+ tsc = tsc * 1000.0 / mhz
>>> Why do you prefer this?
>
Am Tue, 11 Sep 2018 09:52:58 +0200
schrieb Olaf Hering :
> As Jürgen suggested in another mail, Xen should probably disable hotplugging
> for cpu#0 in the generic setup code. Then cpu_is_hotpluggable(cpu) would
> do the right thing.
The relevant code is all private to arch/x86/kernel/topology.c.
On 09/10/2018 05:41 PM, Andrii Anisov wrote:
> From: Andrii Anisov
>
> In order to be able to print possible 64bit LE values from
> trace records, precombine possible variants.
I like the idea; but what does 'LE' mean in this context?
-George
___
Xe
I'll let Dario review this one; one comment:
On 09/10/2018 05:41 PM, Andrii Anisov wrote:
> From: Andrii Anisov
>
> Allign rtds:repl_budget trace record format to the current code.
s/allign/align/g;
Otherwise:
Reviewed-by: George Dunlap
-G
___
X
On 11/09/18 12:48, Olaf Hering wrote:
> Am Tue, 11 Sep 2018 09:52:58 +0200
> schrieb Olaf Hering :
>
>> As Jürgen suggested in another mail, Xen should probably disable hotplugging
>> for cpu#0 in the generic setup code. Then cpu_is_hotpluggable(cpu) would
>> do the right thing.
>
> The relevant
On 10/09/18 18:37, Volodymyr Babchuk wrote:
Hi Julien,
Hi,
On 05.09.18 18:17, Julien Grall wrote:
Hi,
On 09/03/2018 05:54 PM, Volodymyr Babchuk wrote:
Main way to communicate with OP-TEE is to issue standard SMCCC
NIT: The main way
call. "Standard" is a SMCCC term and it means that c
Hello Julien,
Hello Julien,
On 11.09.18 13:40, Julien Grall wrote:
What's your full command?
For this particular patch it was:
git format-patch -1 --to "xen-de...@lists.xen.org"
git send-email --cc-cmd=scripts/get_maintainer.pl
0001-traps-coding-style-fixes.patch
All occurrence of x
On 07/09/18 08:30, Olaf Hering wrote:
> The command 'xl vcpu-set 0 0', issued in dom0, will crash dom0:
>
> BUG: unable to handle kernel NULL pointer dereference at 02d8
> PGD 0 P4D 0
> Oops: [#1] PREEMPT SMP NOPTI
> CPU: 7 PID: 65 Comm: xenwatch Not tainted 4.19.0-rc2-1.ga9462db-
On 11.09.18 13:42, Julien Grall wrote:
@@ -1429,7 +1430,8 @@ static void do_debug_trap(struct cpu_user_regs
*regs, unsigned int code)
{
uint32_t reg;
uint32_t domid = current->domain->domain_id;
While you are at fixing coding style: newline here.
- switch ( code ) {
+ sw
On 11/09/18 12:22, Andrii Anisov wrote:
Hello Julien,
Hello Julien,
On 11.09.18 13:40, Julien Grall wrote:
What's your full command?
For this particular patch it was:
git format-patch -1 --to "xen-de...@lists.xen.org"
That's your problem. You are using a deprecated e-mail address her
On 11.09.18 14:19, Julien Grall wrote:
On 10/09/18 18:37, Volodymyr Babchuk wrote:
Hi Julien,
Hi,
On 05.09.18 18:17, Julien Grall wrote:
Hi,
On 09/03/2018 05:54 PM, Volodymyr Babchuk wrote:
Main way to communicate with OP-TEE is to issue standard SMCCC
NIT: The main way
call. "Sta
Hello Julien,
On 11.09.18 14:31, Julien Grall wrote:
That's your problem. You are using a deprecated e-mail address here.
This should be replaced by xen-devel@lists.xenproject.org.
I've got the point.
Thank you for taking care to help me sort it out.
But the --to here should not be necessary.
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
xen/common/domain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 78c450e..aec10a7 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -155,7 +155,7 @@ struct vcp
Hi,
A more meaningful title would be:
"xen/domain: Remove trailing whitespace"
This would help to understand...
On 11/09/18 12:38, Andrii Anisov wrote:
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
xen/common/domain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
On 10/09/18 18:44, Volodymyr Babchuk wrote:
Hi Julien,
On 10.09.18 16:01, Julien Grall wrote:
Hi Volodymyr,
On 03/09/18 17:54, Volodymyr Babchuk wrote:
OP-TEE usually uses the same idea with command buffers (see
previous commit) to issue RPC requests. Problem is that initially
it has no buf
Hello George,
On 11.09.18 13:48, George Dunlap wrote:
I like the idea; but what does 'LE' mean in this context?
Little endian. Most significant 32bit word is at a higher index in the
array.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel
flight 127499 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127499/
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
Emulation requiring device model assistance uses a form of instruction
re-execution, assuming that the second (and any further) pass takes
exactly the same path. This is a valid assumption as far as use of CPU
registers goes (as those can't change without any other instruction
executing in between)
The caching isn't actually implemented here, this is just setting the
stage.
Touching these anyway also
- make their return values gfn_t
- gva -> gla in their names
- name their input arguments gla
At the use sites do the conversion to gfn_t as suitable.
Signed-off-by: Jan Beulich
Reviewed-by:
The caching isn't actually implemented here, this is just setting the
stage.
Signed-off-by: Jan Beulich
---
v2: Don't wrongly use top_gfn for non-root gpa calculation. Re-write
cache entries after setting A/D bits (an alternative would be to
suppress their setting upon cache hits).
--- a
Emulation requiring device model assistance uses a form of instruction
re-execution, assuming that the second (and any further) pass takes
exactly the same path. This is a valid assumption as far use of CPU
registers goes (as those can't change without any other instruction
executing in between), b
Since strictly speaking it is incorrect for guest_walk_tables() to read
L3 entries during PAE page walks, try to overcome this where possible by
pre-loading the values from hardware into the cache. Sadly the
information is available in the EPT case only. On the positive side for
NPT the spec spells
While indirect calls have always been more expensive than direct ones,
their cost has further increased with the Spectre v2 mitigations. In a
number of cases we simply pointlessly use them in the first place. In
many other cases the indirection solely exists to abstract from e.g.
vendor specific ha
On 11/09/18 12:31, Volodymyr Babchuk wrote:
On 11.09.18 14:19, Julien Grall wrote:
On 10/09/18 18:37, Volodymyr Babchuk wrote:
Hi Julien,
Hi,
On 05.09.18 18:17, Julien Grall wrote:
Hi,
On 09/03/2018 05:54 PM, Volodymyr Babchuk wrote:
Main way to communicate with OP-TEE is to issue
In a number of cases the targets of indirect calls get determined once
at boot time. In such cases we can replace those calls with direct ones
via our alternative instruction patching mechanism.
Some of the targets (in particular the hvm_funcs ones) get established
only in pre-SMP initcalls, makin
This is intentionally not touching hooks used rarely (or not at all)
during the lifetime of a VM, like {domain,vcpu}_initialise or cpu_up,
as well as nested, VM event, and altp2m ones (they can all be done
later, if so desired). Virtual Interrupt delivery ones will be dealt
with in a subsequent pat
While not strictly necessary, change the VMX initialization logic to
update the function table in start_vmx() from NULL rather than to NULL,
to make more obvious that we won't ever change an already (explictly)
initialized function pointer.
Signed-off-by: Jan Beulich
Acked-by: Kevin Tian
---
v2:
Signed-off-by: Jan Beulich
---
v2: Drop open-coded number from macro invocation.
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -184,7 +184,7 @@ void ctxt_switch_levelling(const struct
}
if (ctxt_switch_masking)
- ctxt_switch_masking(next);
+
Instead of loading a pointer at each use site, have a single runtime
instance of struct genapic, copying into it from the individual
instances. The individual instances can this way also be moved to .init
(also adjust apic_probe[] at this occasion).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/
For (I hope) obvious reasons only the ones used at runtime get
converted.
Signed-off-by: Jan Beulich
---
v2: Drop open-coded numbers from macro invocations.
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -29,12 +29,12 @@
void send_IPI_mask(const cpumask_t *mask, int vector)
{
-gena
For now only the ones used during entering/exiting of idle states are
converted. Additionally pm_idle{,_save} and lapic_timer_{on,off} can't
be converted, as they may get established rather late (when Dom0 is
already active).
Note that for patching to be deferred until after the pre-SMP initcalls
Hi Volodymyr,
On 10/09/18 19:04, Volodymyr Babchuk wrote:
On 10.09.18 17:02, Julien Grall wrote:
On 03/09/18 17:54, Volodymyr Babchuk wrote:
+ struct {
+ uint64_t pages_list[PAGELIST_ENTRIES_PER_PAGE];
+ uint64_t next_page_data;
+ } *pages_data_guest, *pages_data_xen, *page
This reduces the post-init memory footprint, eliminates a pointless
level of indirection at the use sites, and allows for subsequent
alternatives call patching.
Take the opportunity and also add a name to the PowerNow! instance.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/acpi/cp
9pfs support has been a documented feature since Xen 4.9, but QEMU will
not be built with backend support unless VirtFS is enabled, which is
predicated on the libcap and libattr dev packages being installed. This is
not obvious to anyone intending to use 9pfs.
This patch adds an 'enable-9pfs' opti
This looks to be the only frequently executed hook; don't bother
patching any other ones.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -364,7 +364,8 @@ int __cpufreq_driver_target(struct cpufr
{
unsigned int prev
>>> On 30.08.18 at 10:13, wrote:
> On Wed, Aug 29, 2018 at 10:03:01AM -0600, Jan Beulich wrote:
>> Eliminates a couple of branches in particular from the context switch
>> path.
>>
>> Signed-off-by: Jan Beulich
>
> Reviewed-by: Wei Liu
Andrew?
Jan
_
On 9/11/18 4:13 PM, Jan Beulich wrote:
> The caching isn't actually implemented here, this is just setting the
> stage.
>
> Touching these anyway also
> - make their return values gfn_t
> - gva -> gla in their names
> - name their input arguments gla
>
> At the use sites do the conversion to gfn_
>>> On 11.09.18 at 15:37, wrote:
> 9pfs support has been a documented feature since Xen 4.9, but QEMU will
> not be built with backend support unless VirtFS is enabled, which is
> predicated on the libcap and libattr dev packages being installed. This is
> not obvious to anyone intending to use 9p
On 10/09/18 19:14, Volodymyr Babchuk wrote:
On 10.09.18 18:34, Julien Grall wrote:
On 03/09/18 17:54, Volodymyr Babchuk wrote:
static struct shm_buf *allocate_shm_buf(struct domain_ctx *ctx,
uint64_t cookie,
1 - 100 of 173 matches
Mail list logo
