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
Hello, Hans!
This is the version of the protocol with minor comments addressed
(that you had on v4). Hope this now looks OK.
Thank you,
Oleksandr
On 3/12/19 10:19 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hello!
At the moment Xen [1] already supports some virtual mult
On 12/03/2019 09:20, Oleksandr Andrushchenko wrote:
> 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 def
On 12/03/2019 09:19, Oleksandr Andrushchenko wrote:
> 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 i
Hello xen-devel,
I'm reading the code of xen arm smmu in drivers/passthrough/arm, and I have
some questions that confused me.
I think if the board use SMMU, xen will take charge of it before dom0 boot, and
will not pass the node of SMMU to dom0 in device tree,
so my question is how dom0 use SMMU
Hi Oleksandr,
Just one comment:
On 3/12/19 9:20 AM, Oleksandr Andrushchenko wrote:
> 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
>>> On 12.03.19 at 09:48, wrote:
> On 12/03/2019 09:19, Oleksandr Andrushchenko wrote:
>> 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-
On 3/12/19 10:58 AM, Hans Verkuil wrote:
Hi Oleksandr,
Just one comment:
On 3/12/19 9:20 AM, Oleksandr Andrushchenko wrote:
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 enab
On 3/12/19 11:07 AM, Jan Beulich wrote:
On 12.03.19 at 09:48, wrote:
On 12/03/2019 09:19, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hello!
At the moment Xen [1] already supports some virtual multimedia
features [2] such as virtual display, sound. It supports keyboards,
po
On 12/03/2019 10:07, Jan Beulich wrote:
On 12.03.19 at 09:48, wrote:
>> On 12/03/2019 09:19, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> Hello!
>>>
>>> At the moment Xen [1] already supports some virtual multimedia
>>> features [2] such as virtual display, sound.
>>> On 11.03.19 at 19:18, wrote:
> On 11/03/2019 16:38, Jan Beulich wrote:
>> Add model 0x86 to relevant switch() statements, as per SDM 069 Vol 4.
>> Take the liberty and also change Gemini Lake comments to say Goldmont
>> Plus. to match the SDM.
>
> Goldmont+ (Goldmont Refresh in some places) i
>>> On 12.03.19 at 10:13, wrote:
> On 3/12/19 11:07 AM, Jan Beulich wrote:
> On 12.03.19 at 09:48, wrote:
>>> On 12/03/2019 09:19, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hello!
At the moment Xen [1] already supports some virtual multimedia
>>> On 12.03.19 at 10:15, wrote:
> On 12/03/2019 10:07, Jan Beulich wrote:
>> Without the specific MAINTAINERS entry, as in the old days, THE
>> REST would assume responsibility again, which personally I'd prefer
>> over adding a second individual to the section. Unless someone else
>> (like you)
>>> On 11.03.19 at 18:53, wrote:
> Hi,
>
> On 11/03/2019 16:50, Andrew Cooper wrote:
>> On 11/03/2019 16:48, Jan Beulich wrote:
>>> There's no need to set the evtchn_pending_sel bits one by one. Simply
>>> write full words with all ones.
>>>
>>> For Arm this requires extending write_atomic() to a
On 3/12/19 10:08 AM, Oleksandr Andrushchenko wrote:
> On 3/12/19 10:58 AM, Hans Verkuil wrote:
>> Hi Oleksandr,
>>
>> Just one comment:
>>
>> On 3/12/19 9:20 AM, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> This is the ABI for the two halves of a para-virtualized
>>> ca
On 3/12/19 11:30 AM, Hans Verkuil wrote:
On 3/12/19 10:08 AM, Oleksandr Andrushchenko wrote:
On 3/12/19 10:58 AM, Hans Verkuil wrote:
Hi Oleksandr,
Just one comment:
On 3/12/19 9:20 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a par
>>> On 11.03.19 at 19:19, wrote:
> On 11/03/2019 16:52, Jan Beulich wrote:
>> Correct coding style of asm() invocations.
> Coding style from where? Most of the Arm code does not contain space before (
> and after ) for asm invocations. I also can't find anywhere in CODING_STYLE
> imposing this s
flight 133693 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133693/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 128858
test-amd64-i386-xl
Due to personal changes at Intel, I am new TXT maintainer for XEN.
Adding patch that updates maintainers list.
Lukasz Hawrylko (1):
Update TXT maintainter
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.20.1
Signed-off-by: Lukasz Hawrylko
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a0cda4f7a1..4c47294706 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -237,7 +237,7 @@ F: xen/arch/x86/debug.c
F: tools/debugger/gdbsx/
INTEL(
flight 133698 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133698/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 690d60c0ada5ff137c84982220b3fdd112697aa3
baseline version:
ovmf a24a37dba42c4f7dad879
Am Mon, 11 Mar 2019 04:16:07 -0600
schrieb "Jan Beulich" :
> >>> On 08.03.19 at 20:20, wrote:
> > To reiterate the second paragraph: if a domU uses TSC as primary clock
> > source, it is expected that it runs NTP to cover for the resulting
> > drift. Therefore this change does no need a knob to
On 3/12/19 10:35 AM, Oleksandr Andrushchenko wrote:
> On 3/12/19 11:30 AM, Hans Verkuil wrote:
>> On 3/12/19 10:08 AM, Oleksandr Andrushchenko wrote:
>>> On 3/12/19 10:58 AM, Hans Verkuil wrote:
Hi Oleksandr,
Just one comment:
On 3/12/19 9:20 AM, Oleksandr Andrushchenko wro
On 3/12/19 12:09 PM, Hans Verkuil wrote:
On 3/12/19 10:35 AM, Oleksandr Andrushchenko wrote:
On 3/12/19 11:30 AM, Hans Verkuil wrote:
On 3/12/19 10:08 AM, Oleksandr Andrushchenko wrote:
On 3/12/19 10:58 AM, Hans Verkuil wrote:
Hi Oleksandr,
Just one comment:
On 3/12/19 9:20 AM, Oleksandr An
Hi Jan,
On 3/12/19 9:30 AM, Jan Beulich wrote:
On 11.03.19 at 18:53, wrote:
Hi,
On 11/03/2019 16:50, Andrew Cooper wrote:
On 11/03/2019 16:48, Jan Beulich wrote:
There's no need to set the evtchn_pending_sel bits one by one. Simply
write full words with all ones.
For Arm this requires exte
Hi Jan,
On 3/12/19 9:35 AM, Jan Beulich wrote:
On 11.03.19 at 19:19, wrote:
On 11/03/2019 16:52, Jan Beulich wrote:
Correct coding style of asm() invocations.
Coding style from where? Most of the Arm code does not contain space before (
and after ) for asm invocations. I also can't find anyw
On 3/5/19 17:38, Jan Beulich wrote:
On 27.02.19 at 17:13, wrote:
>> Speculative execution is not blocked in case one of the following
>> properties is true:
>> - path cannot be triggered by the guest
>> - path does not return to the guest
>> - path does not result in an out-of-bound access
On 3/12/19 9:07 AM, Jan Beulich wrote:
On 12.03.19 at 09:48, wrote:
>> On 12/03/2019 09:19, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> Hello!
>>>
>>> At the moment Xen [1] already supports some virtual multimedia
>>> features [2] such as virtual display, sound.
flight 133695 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133695/
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-li
The update to README and SUPPORT.md where correct, but XEN_EXTRAVERSION had an
additional .0 slip in.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
---
xen/Ma
>>> On 12.03.19 at 11:43, wrote:
> On 3/12/19 9:07 AM, Jan Beulich wrote:
> On 12.03.19 at 09:48, wrote:
>>> On 12/03/2019 09:19, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hello!
At the moment Xen [1] already supports some virtual multimedia
f
On 3/12/19 8:58 AM, jinchen wrote:
Hello xen-devel,
Hello,
I'm reading the code of xen arm smmu in drivers/passthrough/arm, and I
have some questions that confused me.
I think if the board use SMMU, xen will take charge of it before dom0
boot, and will not pass the node of SMMU to dom0 in
Thanks. The format looks correct now.
Shane, can you ack this patch?
On Tue, Mar 12, 2019 at 09:39:26AM +, Hawrylko, Lukasz wrote:
> Signed-off-by: Lukasz Hawrylko
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index
On Mon, Mar 11, 2019 at 07:18:40PM +, Andrew Cooper wrote:
> The issues are:
> * dict.has_key() was completely removed in Py3
> * dict.keys() is an iterable rather than list in Py3, so .sort() doesn't
> work.
> * list.sort(cmp=) was deprecated in Py2.4 and removed in Py3.
>
> The has_key()
On Mon, Mar 11, 2019 at 02:02:15PM -0400, Jason Andryuk wrote:
> MSI-X is not supported in Xen stubdoms, so it must be disabled. Use the
> existing xen_pt_hide_dev_cap to hide when running under -xen-stubdom.
I'm afraid this requires some more context. What's the actual issue
that prevents MSI-X
On Tue, Mar 12, 2019 at 10:15:08AM +0100, Juergen Gross wrote:
> On 12/03/2019 10:07, Jan Beulich wrote:
> On 12.03.19 at 09:48, wrote:
> >> On 12/03/2019 09:19, Oleksandr Andrushchenko wrote:
> >>> From: Oleksandr Andrushchenko
> >>>
> >>> Hello!
> >>>
> >>> At the moment Xen [1] already su
On Tue, Mar 12, 2019 at 11:38:03AM +, Andrew Cooper wrote:
> The update to README and SUPPORT.md where correct, but XEN_EXTRAVERSION had an
> additional .0 slip in.
>
> Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen
On Wed, Nov 28, 2018 at 01:58:03PM +, Wei Liu wrote:
> It is agreed that tmem can be removed from xen.git. See the thread starting
>
>
> from .
>
> In this version:
>
> 1. Remove some residuals from previous
On Tue, Mar 12, 2019 at 01:04:19PM +0100, Roger Pau Monné wrote:
> On Mon, Mar 11, 2019 at 02:02:15PM -0400, Jason Andryuk wrote:
> > MSI-X is not supported in Xen stubdoms, so it must be disabled. Use the
> > existing xen_pt_hide_dev_cap to hide when running under -xen-stubdom.
>
> I'm afraid th
On Mon, Mar 11, 2019 at 10:37:44AM -0600, Jan Beulich wrote:
> The flag is really only meant for those, both HVM and 32-bit PV tell
> kernel from user mode based on CPL/RPL. Remove the all-question-marks
> comment and let's be on the safe side here and also suppress clearing
> for 32-bit PV (this i
>>> On 12.03.19 at 11:23, wrote:
> On 3/12/19 9:35 AM, Jan Beulich wrote:
> On 11.03.19 at 19:19, wrote:
>>> On 11/03/2019 16:52, Jan Beulich wrote:
Correct coding style of asm() invocations.
>>> Coding style from where? Most of the Arm code does not contain space before
>>> and after )
On Wed, Mar 06, 2019 at 03:35:40PM +0800, Dongli Zhang wrote:
> Thanks to Joe Jin's reminding, this patch is applicable to mainline linux
> kernel, although there is no issue due to this kind of bug in mainline kernel.
>
> Therefore, can I first submit this patch to mainline kernel and then backpo
>>> On 12.03.19 at 11:36, wrote:
> On 3/5/19 17:38, Jan Beulich wrote:
> On 27.02.19 at 17:13, wrote:
>>> Speculative execution is not blocked in case one of the following
>>> properties is true:
>>> - path cannot be triggered by the guest
>>> - path does not return to the guest
>>> - path
>>> On 12.03.19 at 13:21, wrote:
> On Wed, Nov 28, 2018 at 01:58:03PM +, Wei Liu wrote:
>> It is agreed that tmem can be removed from xen.git. See the thread starting
>
>
>> from .
>>
>> In this version:
>>
Hi Jan,
On 12/03/2019 12:53, Jan Beulich wrote:
On 12.03.19 at 11:23, wrote:
>> On 3/12/19 9:35 AM, Jan Beulich wrote:
>> On 11.03.19 at 19:19, wrote:
On 11/03/2019 16:52, Jan Beulich wrote:
> Correct coding style of asm() invocations.
Coding style from where? Most of the
flight 133696 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133696/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-examine4 memdisk-try-append fail in 133675 pass in 133696
test-armhf-armhf-xl-vhd 15
The "PUBLIC I/O INTERFACES AND PV DRIVERS DESIGNS" section of the
MAINTAINERS file lists Konrad as the only maintainer. Add myself for
helping him to review patches.
Signed-off-by: Juergen Gross
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index a
>>> On 07.01.19 at 10:30, wrote:
> Found while reviewing Andrew's str{,n}cmp() fix.
>
> 1: avoid undefined behavior in strrchr()
> 2: remove memscan()
I've taken care of the formatting issue pointed out by Jürgen here,
but it didn't seem worthwhile to send v2 just for this.
Jan
> 3: fix type u
Thank you for your reply,
I’m just researching the implementation of the SMMU driver in Xen and dom0
kernel.
If my board has SMMU of arm,mmu-500, do you mean that the Xen use the stage 2
of it and the dom0 kernel use stage1?
And if I want to passthrough some device that use SMMU to domu, how the
On Tue, Mar 12, 2019 at 02:24:14PM +0100, Juergen Gross wrote:
> The "PUBLIC I/O INTERFACES AND PV DRIVERS DESIGNS" section of the
> MAINTAINERS file lists Konrad as the only maintainer. Add myself for
> helping him to review patches.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
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 Tue, Mar 12, 2019 at 8:38 AM Marek Marczykowski-Górecki
wrote:
>
> On Tue, Mar 12, 2019 at 01:04:19PM +0100, Roger Pau Monné wrote:
> > On Mon, Mar 11, 2019 at 02:02:15PM -0400, Jason Andryuk wrote:
> > > MSI-X is not supported in Xen stubdoms, so it must be disabled. Use the
> > > existing xe
We don't need bigger alignment except when calling EFI boot or runtime
services functions (and we don't guarantee that either, as explained
close to the top of xen/common/efi/runtime.c in the struct efi_rs_state
declaration). Hence if the compiler supports reducing stack alignment
from the ABI comp
While we don't mean to run their objtool over our generated code, it
still seems desirable to avoid calls to further functions before a
function's frame pointer is set up.
Suggested-by: Andrew Cooper
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
---
v6: Fix build issue with old gcc.
v5: New.
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 (explicitly)
initialized function pointer.
Signed-off-by: Jan Beulich
Acked-by: Kevin Tian
Review
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Reviewed-by: Andrew Cooper
---
v2: Drop open-coded number from macro invocation.
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -185,7 +185,7 @@ void ctxt_switch_levelling(const struct
}
if (ctxt_switch_maskin
For (I hope) obvious reasons only the ones used at runtime get
converted.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Acked-by: Andrew Cooper
---
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(
This looks to be the only frequently executed hook; don't bother
patching any other ones.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Acked-by: Andrew Cooper
---
v2: New.
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -364,7 +364,8 @@ int __cpufreq_driver_target
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
This is intentionally not touching hooks used rarely (or not at all)
during the lifetime of a VM, unless perhaps sitting on an error path
next to a call which gets changed (in which case I think the error
path better remains consistent with the respective main path).
Signed-off-by: Jan Beulich
Re
flight 133699 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133699/
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
test-armhf-a
On Tue, Mar 12, 2019 at 09:58:56AM -0400, Jason Andryuk wrote:
> On Tue, Mar 12, 2019 at 8:38 AM Marek Marczykowski-Górecki
> wrote:
> >
> > On Tue, Mar 12, 2019 at 01:04:19PM +0100, Roger Pau Monné wrote:
> > > On Mon, Mar 11, 2019 at 02:02:15PM -0400, Jason Andryuk wrote:
> > > > MSI-X is not su
On Tue, Mar 12, 2019 at 09:58:56AM -0400, Jason Andryuk wrote:
> On Tue, Mar 12, 2019 at 8:38 AM Marek Marczykowski-Górecki
> wrote:
> >
> > On Tue, Mar 12, 2019 at 01:04:19PM +0100, Roger Pau Monné wrote:
> > > On Mon, Mar 11, 2019 at 02:02:15PM -0400, Jason Andryuk wrote:
> > > > MSI-X is not su
On Tue, Mar 12, 2019 at 10:13 AM Roger Pau Monné wrote:
>
> On Tue, Mar 12, 2019 at 09:58:56AM -0400, Jason Andryuk wrote:
> > On Tue, Mar 12, 2019 at 8:38 AM Marek Marczykowski-Górecki
> > wrote:
> > >
> > > On Tue, Mar 12, 2019 at 01:04:19PM +0100, Roger Pau Monné wrote:
> > > > On Mon, Mar 11,
Some compiler versions don't recognize that "mfn" can't really be used
uninitialized in svm_do_nested_pgfault(). To be on the safe side, add an
initializer for p2mt as well.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@
flight 133707 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133707/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 4545fe820a83b675845f9045f06c856129b9c17c
baseline version:
freebsd 6f4627c0db4
flight 133741 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133741/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Tue, Mar 12, 2019 at 09:24:45AM -0600, Jan Beulich wrote:
> Some compiler versions don't recognize that "mfn" can't really be used
> uninitialized in svm_do_nested_pgfault(). To be on the safe side, add an
> initializer for p2mt as well.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Jan Beul
On 3/12/19 11:43 AM, Wei Liu wrote:
> On Tue, Mar 12, 2019 at 09:24:45AM -0600, Jan Beulich wrote:
>> Some compiler versions don't recognize that "mfn" can't really be used
>> uninitialized in svm_do_nested_pgfault(). To be on the safe side, add an
>> initializer for p2mt as well.
>>
>> Reported-by
On Mon, Mar 11, 2019 at 03:57:25PM +0800, Chao Gao wrote:
> This patch provides a tool for late microcode update.
>
> Signed-off-by: Konrad Rzeszutek Wilk
> Signed-off-by: Chao Gao
> ---
> tools/libxc/include/xenctrl.h | 1 +
> tools/libxc/xc_misc.c | 20 ++
> tools/misc/Makefi
On Mon, Mar 11, 2019 at 03:57:26PM +0800, Chao Gao wrote:
Please add "No functional change" to the commit description.
Reviewed-by: Roger Pau Monné
This can likely go in ahead of the rest of the series.
Thanks, Roger.
___
Xen-devel mailing list
Xen-
Hi all,
It looks like all the arm test for linus [1] and next [2] tree
are now failing. x86 seems to be mostly ok.
The bisector fingered the following commit:
commit 0ee930e6cafa048c1925893d0ca89918b2814f2c
Author: Matthew Wilcox
Date: Tue Mar 5 15:46:06 2019 -0800
mm/memory.c: prevent m
On 12/03/2019 13:32, Jan Beulich wrote:
On 07.01.19 at 10:30, wrote:
>> Found while reviewing Andrew's str{,n}cmp() fix.
>>
>> 1: avoid undefined behavior in strrchr()
>> 2: remove memscan()
> I've taken care of the formatting issue pointed out by Jürgen here,
> but it didn't seem worthwhile
Since the introduction of linear_{read,write}() helpers in 3bdec530a5
(x86/HVM: split page straddling emulated accesses in more cases) the
completion path for IOREQs has been broken: if there is an IOREQ in
progress but hvm_copy_{to,from}_guest_linear() returns HVMTRANS_okay
(e.g. when P2M type of
>>> On 12.03.19 at 16:33, wrote:
> On Mon, Mar 11, 2019 at 03:57:26PM +0800, Chao Gao wrote:
>
> Please add "No functional change" to the commit description.
>
> Reviewed-by: Roger Pau Monné
Acked-by: Jan Beulich
> This can likely go in ahead of the rest of the series.
Indeed.
Jan
__
The CPUID bit and MSR are deliberately not exposed to guests, because they
won't exist on newer processors. As vPMU isn't security supported, the
misbehaviour of PCR3 isn't expected to impact production deployments.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
docs/misc/xen-comman
(Adding more people in the thread)
Hi,
On 3/12/19 3:59 PM, Julien Grall wrote:
Hi all,
It looks like all the arm test for linus [1] and next [2] tree
are now failing. x86 seems to be mostly ok.
The bisector fingered the following commit:
commit 0ee930e6cafa048c1925893d0ca89918b2814f2c
Author
On Mon, Mar 11, 2019 at 03:57:28PM +0800, Chao Gao wrote:
> to replace the current per-cpu cache 'uci->mc'.
>
> Compared to the current per-cpu cache, the benefits of the global
> microcode cache are:
> 1. It reduces the work that need to be done on each CPU. Parsing ucode
> file is done once on o
On 2/22/19 4:59 PM, Paolo Bonzini wrote:
> On 21/02/19 12:45, Joao Martins wrote:
>> On 2/20/19 9:09 PM, Paolo Bonzini wrote:
>>> On 20/02/19 21:15, Joao Martins wrote:
2. PV Driver support (patches 17 - 39)
We start by redirecting hypercalls from the backend to routines
whic
On Tue, Mar 12, 2019 at 05:05:39PM +, Julien Grall wrote:
> On 3/12/19 3:59 PM, Julien Grall wrote:
> > It looks like all the arm test for linus [1] and next [2] tree
> > are now failing. x86 seems to be mostly ok.
> >
> > The bisector fingered the following commit:
> >
> > commit 0ee930e6caf
On 12.03.19 18:14, Matthew Wilcox wrote:
> On Tue, Mar 12, 2019 at 05:05:39PM +, Julien Grall wrote:
>> On 3/12/19 3:59 PM, Julien Grall wrote:
>>> It looks like all the arm test for linus [1] and next [2] tree
>>> are now failing. x86 seems to be mostly ok.
>>>
>>> The bisector fingered the fo
On Mon, Mar 11, 2019 at 03:57:29PM +0800, Chao Gao wrote:
> Intel CPU only allows mixing in stepping or 'pf'. If an ucode patch is
> for other CPU families or models, it won't be compatible to all CPUs on
> current system and even hot-plugged CPUs. Don't save such patch to
> reduce the size of uco
On 12.03.19 18:14, Matthew Wilcox wrote:
> On Tue, Mar 12, 2019 at 05:05:39PM +, Julien Grall wrote:
>> On 3/12/19 3:59 PM, Julien Grall wrote:
>>> It looks like all the arm test for linus [1] and next [2] tree
>>> are now failing. x86 seems to be mostly ok.
>>>
>>> The bisector fingered the fo
> On Mar 12, 2019, at 10:23 AM, David Hildenbrand wrote:
>
> On 12.03.19 18:14, Matthew Wilcox wrote:
>> On Tue, Mar 12, 2019 at 05:05:39PM +, Julien Grall wrote:
>>> On 3/12/19 3:59 PM, Julien Grall wrote:
It looks like all the arm test for linus [1] and next [2] tree
are now faili
Hi David,
On 3/12/19 5:18 PM, David Hildenbrand wrote:
On 12.03.19 18:14, Matthew Wilcox wrote:
On Tue, Mar 12, 2019 at 05:05:39PM +, Julien Grall wrote:
On 3/12/19 3:59 PM, Julien Grall wrote:
It looks like all the arm test for linus [1] and next [2] tree
are now failing. x86 seems to be
On 12/03/2019 17:18, David Hildenbrand wrote:
> On 12.03.19 18:14, Matthew Wilcox wrote:
>> On Tue, Mar 12, 2019 at 05:05:39PM +, Julien Grall wrote:
>>> On 3/12/19 3:59 PM, Julien Grall wrote:
It looks like all the arm test for linus [1] and next [2] tree
are now failing. x86 seems t
On Tue, Mar 12, 2019 at 03:59:04PM +, Julien Grall wrote:
> Hi all,
>
> It looks like all the arm test for linus [1] and next [2] tree
> are now failing. x86 seems to be mostly ok.
I'm quite sure x86 PVH dom0 is also broken after this change.
> The bisector fingered the following commit:
>
On 12.03.19 18:39, Julien Grall wrote:
> Hi David,
>
> On 3/12/19 5:18 PM, David Hildenbrand wrote:
>> On 12.03.19 18:14, Matthew Wilcox wrote:
>>> On Tue, Mar 12, 2019 at 05:05:39PM +, Julien Grall wrote:
On 3/12/19 3:59 PM, Julien Grall wrote:
> It looks like all the arm test for li
On Tue, Mar 12, 2019 at 06:27:03PM +0100, Roger Pau Monné wrote:
> On Tue, Mar 12, 2019 at 03:59:04PM +, Julien Grall wrote:
> > Hi all,
> >
> > It looks like all the arm test for linus [1] and next [2] tree
> > are now failing. x86 seems to be mostly ok.
>
> I'm quite sure x86 PVH dom0 is al
On 3/12/19 1:24 PM, Andrew Cooper wrote:
> On 12/03/2019 17:18, David Hildenbrand wrote:
>> On 12.03.19 18:14, Matthew Wilcox wrote:
>>> On Tue, Mar 12, 2019 at 05:05:39PM +, Julien Grall wrote:
On 3/12/19 3:59 PM, Julien Grall wrote:
> It looks like all the arm test for linus [1] and
On 12/03/2019 18:02, Boris Ostrovsky wrote:
> On 3/12/19 1:24 PM, Andrew Cooper wrote:
>> On 12/03/2019 17:18, David Hildenbrand wrote:
>>> On 12.03.19 18:14, Matthew Wilcox wrote:
On Tue, Mar 12, 2019 at 05:05:39PM +, Julien Grall wrote:
> On 3/12/19 3:59 PM, Julien Grall wrote:
>
On 12.03.19 19:02, Boris Ostrovsky wrote:
> On 3/12/19 1:24 PM, Andrew Cooper wrote:
>> On 12/03/2019 17:18, David Hildenbrand wrote:
>>> On 12.03.19 18:14, Matthew Wilcox wrote:
On Tue, Mar 12, 2019 at 05:05:39PM +, Julien Grall wrote:
> On 3/12/19 3:59 PM, Julien Grall wrote:
>>
On Tue, Mar 12, 2019 at 10:43:23AM -0600, Jan Beulich wrote:
> >>> On 12.03.19 at 16:33, wrote:
> > On Mon, Mar 11, 2019 at 03:57:26PM +0800, Chao Gao wrote:
> >
> > Please add "No functional change" to the commit description.
> >
> > Reviewed-by: Roger Pau Monné
>
> Acked-by: Jan Beulich
>
On Tue, Mar 12, 2019 at 02:24:14PM +0100, Juergen Gross wrote:
> The "PUBLIC I/O INTERFACES AND PV DRIVERS DESIGNS" section of the
> MAINTAINERS file lists Konrad as the only maintainer. Add myself for
> helping him to review patches.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Konrad Rzeszutek
flight 133703 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133703/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133677
test-armhf-armhf-libvirt 14 sav
flight 133747 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133747/
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 Jinch,
Replies inline below.
On Tue, 12 Mar 2019, Jinch wrote:
> Thank you for your reply,
> I’m just researching the implementation of the SMMU driver in Xen and dom0
> kernel.
> If my board has SMMU of arm,mmu-500, do you mean that the Xen use the stage 2
> of it and the dom0 kernel use s
1 - 100 of 112 matches
Mail list logo
