> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Roger Pau Monne
> Sent: 27 July 2018 16:32
> To: xen-devel@lists.xenproject.org
> Cc: Kevin Tian ; Stefano Stabellini
> ; Wei Liu ; George Dunlap
> ; Andrew Cooper
> ; Ian Jackson ; Tim
> (
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Roger Pau Monne
> Sent: 27 July 2018 16:32
> To: xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Roger Pau Monne
>
> Subject: [Xen-devel] [PATCH 1/4] iommu: remove unneeded return from
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Roger Pau Monne
> Sent: 27 July 2018 16:32
> To: xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Roger Pau Monne
>
> Subject: [Xen-devel] [PATCH 3/4] x86/iommu: reorder conditions used
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Roger Pau Monne
> Sent: 27 July 2018 16:32
> To: xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Wei Liu
> ; George Dunlap ;
> Andrew Cooper ; Ian Jackson
> ; Tim (Xen.org) ; Juli
>>> On 31.07.18 at 09:18, wrote:
> To be able to compile Xen with gotocc, the label statement has to be
> followed by a semicolon.
Assuming that gotocc aims to be gcc compatible, this looks like a
shortcoming there. As the workaround is simple enough, I'm fine
with the change, but the description
>>> On 31.07.18 at 04:30, wrote:
Marek,
looks like all of the patches you've sent early this morning local time
here came through twice on xen-devel: Would you please avoid
having xen-devel on both the To and the Cc lists (just with different
domains)?
Thanks, Jan
___
>>> On 30.07.18 at 19:48, wrote:
> Today it is a silent option. This patch adds a one line description and
> makes it optional.
>
> Signed-off-by: Stefano Stabellini
> Acked-by: Julien Grall
> CC: george.dun...@eu.citrix.com
> CC: ian.jack...@eu.citrix.com
> CC: jbeul...@suse.com
> CC: andre
On 31/07/2018 09:01, Jan Beulich wrote:
On 31.07.18 at 04:30, wrote:
> Marek,
>
> looks like all of the patches you've sent early this morning local time
> here came through twice on xen-devel: Would you please avoid
> having xen-devel on both the To and the Cc lists (just with different
> do
On Tue, Jul 31, 2018 at 08:18:36AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> > Of Roger Pau Monne
> > Sent: 27 July 2018 16:32
> > To: xen-devel@lists.xenproject.org
> > Cc: Kevin Tian ; Stefano Stabelli
On Tue, Jul 31, 2018 at 08:29:20AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> > @@ -179,6 +169,13 @@ void __hwdom_init arch_iommu_hwdom_init(struct
> > domain *d)
> > */
> > if ( iommu_
> -Original Message-
> From: Roger Pau Monne
> Sent: 31 July 2018 09:16
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Kevin Tian ;
> Stefano Stabellini ; Wei Liu ;
> George Dunlap ; Andrew Cooper
> ; Ian Jackson ; Tim
> (Xen.org) ; Julien Grall ; Jan Beulich
>
> Subject: Re: [X
On Tue, Jul 31, 2018 at 08:36:02AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> > Of Roger Pau Monne
> > Sent: 27 July 2018 16:32
> > To: xen-devel@lists.xenproject.org
> > Cc: Stefano Stabellini ; Wei Liu
On Tue, Jul 31, 2018 at 09:27:03AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 31 July 2018 09:16
> > To: Paul Durrant
> > Cc: xen-devel@lists.xenproject.org; Kevin Tian ;
> > Stefano Stabellini ; Wei Liu ;
> > George Dunlap ; Andrew Cooper
> > ; I
>>> On 31.07.18 at 10:09, wrote:
> On 31/07/2018 09:01, Jan Beulich wrote:
> On 31.07.18 at 04:30, wrote:
>> Marek,
>>
>> looks like all of the patches you've sent early this morning local time
>> here came through twice on xen-devel: Would you please avoid
>> having xen-devel on both the To
> -Original Message-
> From: Roger Pau Monne
> Sent: 31 July 2018 09:34
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Kevin Tian ;
> Stefano Stabellini ; Wei Liu ;
> George Dunlap ; Andrew Cooper
> ; Ian Jackson ; Tim
> (Xen.org) ; Julien Grall ; Jan Beulich
>
> Subject: Re: [X
>>> On 31.07.18 at 10:32, wrote:
> Sorry for putting you in the To field, I'll use Cc in the future.
>
> I agree that the commit message is a little short, and I will iterate on
> that. Furthermore, I agree that gcc compatibility would allow to parse
> this statement. However, the given sequence
>>> On 31.07.18 at 10:27, wrote:
>> -Original Message-
>> From: Roger Pau Monne
>> Sent: 31 July 2018 09:16
>> To: Paul Durrant
>> Cc: xen-devel@lists.xenproject.org; Kevin Tian ;
>> Stefano Stabellini ; Wei Liu ;
>> George Dunlap ; Andrew Cooper
>> ; Ian Jackson ; Tim
>> (Xen.org) ; Jul
>>> On 31.07.18 at 10:37, wrote:
>> -Original Message-
>> From: Roger Pau Monne
>> Sent: 31 July 2018 09:34
>> To: Paul Durrant
>> Cc: xen-devel@lists.xenproject.org; Kevin Tian ;
>> Stefano Stabellini ; Wei Liu ;
>> George Dunlap ; Andrew Cooper
>> ; Ian Jackson ; Tim
>> (Xen.org) ; Jul
On Tue, Jul 31, 2018 at 04:30:42AM +0200, Marek Marczykowski-Górecki wrote:
> gdb 8.0 fixed bounds checking for 'g' packet (commit
> 9dc193c3be85aafa60ceff57d3b0430af607b4ce "Check for truncated
> registers in process_g_packet"). This revealed that gdbsx did
> not properly formatted 'g' packet - se
On Tue, Jul 31, 2018 at 04:56:53AM +0200, Marek Marczykowski-Górecki wrote:
> Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Wei Liu
Thanks for doing this!
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/ma
On Tue, Jul 31, 2018 at 04:56:54AM +0200, Marek Marczykowski-Górecki wrote:
> From: Simon Gaiser
>
> Parsing/generating the escape sequences used by xenstore-client is non
> trivial. So make scripting (for use in stubdom) easier by adding a raw
> option.
>
> [added man page entries, facor out ex
On Tue, Jul 31, 2018 at 02:49:19AM -0600, Jan Beulich wrote:
> >>> On 31.07.18 at 10:37, wrote:
> >> -Original Message-
> >> From: Roger Pau Monne
> >> Sent: 31 July 2018 09:34
> >> To: Paul Durrant
> >> Cc: xen-devel@lists.xenproject.org; Kevin Tian ;
> >> Stefano Stabellini ; Wei Liu ;
On 31/07/18 10:00, Wei Liu wrote:
> On Tue, Jul 31, 2018 at 04:30:42AM +0200, Marek Marczykowski-Górecki wrote:
>> gdb 8.0 fixed bounds checking for 'g' packet (commit
>> 9dc193c3be85aafa60ceff57d3b0430af607b4ce "Check for truncated
>> registers in process_g_packet"). This revealed that gdbsx did
>
On Tue, Jul 31, 2018 at 05:15:32AM +0200, Marek Marczykowski-Górecki wrote:
> Add --replace-escape option to xenconsoled, which replaces ESC with
> '.' in console output written to log file. This makes it slightly safer
> to do tail -f on a console output of untrusted guest.
> The pty output is una
On Tue, Jul 31, 2018 at 10:08:06AM +0100, Andrew Cooper wrote:
> On 31/07/18 10:00, Wei Liu wrote:
> > On Tue, Jul 31, 2018 at 04:30:42AM +0200, Marek Marczykowski-Górecki wrote:
> >> gdb 8.0 fixed bounds checking for 'g' packet (commit
> >> 9dc193c3be85aafa60ceff57d3b0430af607b4ce "Check for trunc
>>> On 31.07.18 at 11:05, wrote:
> On Tue, Jul 31, 2018 at 02:49:19AM -0600, Jan Beulich wrote:
>> >>> On 31.07.18 at 10:37, wrote:
>> >> -Original Message-
>> >> From: Roger Pau Monne
>> >> Sent: 31 July 2018 09:34
>> >> To: Paul Durrant
>> >> Cc: xen-devel@lists.xenproject.org; Kevin
>>> On 31.07.18 at 10:56, wrote:
> When compiling this file with gcc, the compiler happily accepts the
> sequence of a label followed by an attribute. However, this sequence does
> not follow the gcc documentation. Hence, other compilers might stumble
> upon this statement.
>
> To be able to comp
On Tue, Jul 31, 2018 at 03:18:51AM -0600, Jan Beulich wrote:
> >>> On 31.07.18 at 10:56, wrote:
> > When compiling this file with gcc, the compiler happily accepts the
> > sequence of a label followed by an attribute. However, this sequence does
> > not follow the gcc documentation. Hence, other c
When compiling this file with gcc, the compiler happily accepts the
sequence of a label followed by an attribute. However, this sequence does
not follow the gcc documentation. Hence, other compilers might stumble
upon this statement.
To be able to compile Xen with goto-cc (the compiler of the CPRO
To be able to compile Xen with gotocc, the label statement has to be
followed by a semicolon.
Reported-by: Elizabeth Polgreen
Signed-off-by: Norbert Manthey
---
xen/common/memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/memory.c b/xen/common/memory.c
inde
>>> On 31.07.18 at 11:24, wrote:
> On Tue, Jul 31, 2018 at 03:18:51AM -0600, Jan Beulich wrote:
>> >>> On 31.07.18 at 10:56, wrote:
>> > When compiling this file with gcc, the compiler happily accepts the
>> > sequence of a label followed by an attribute. However, this sequence does
>> > not foll
Sorry for putting you in the To field, I'll use Cc in the future.
I agree that the commit message is a little short, and I will iterate on
that. Furthermore, I agree that gcc compatibility would allow to parse
this statement. However, the given sequence is not unique, and the gcc
documentation sta
On Tue, Jul 31, 2018 at 03:27:03AM -0600, Jan Beulich wrote:
> >>> On 31.07.18 at 11:24, wrote:
> > On Tue, Jul 31, 2018 at 03:18:51AM -0600, Jan Beulich wrote:
> >> >>> On 31.07.18 at 10:56, wrote:
> >> > When compiling this file with gcc, the compiler happily accepts the
> >> > sequence of a la
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
flight 125675 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125675/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
test-armhf-armhf-li
On Tue, Jul 31, 2018 at 03:14:47AM -0600, Jan Beulich wrote:
> >>> On 31.07.18 at 11:05, wrote:
> > On Tue, Jul 31, 2018 at 02:49:19AM -0600, Jan Beulich wrote:
> >> >>> On 31.07.18 at 10:37, wrote:
> >> >> -Original Message-
> >> >> From: Roger Pau Monne
> >> >> Sent: 31 July 2018 09:34
> -Original Message-
> From: Roger Pau Monne
> Sent: 31 July 2018 10:35
> To: Jan Beulich
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Paul
> Durrant ; Wei Liu ; Kevin
> Tian ; Stefano Stabellini ;
> xen-devel ; Tim (Xen.org)
> Subject: Re: [Xen-devel] [PATCH 2/4
>>> On 31.07.18 at 11:34, wrote:
> On Tue, Jul 31, 2018 at 03:14:47AM -0600, Jan Beulich wrote:
>> >>> On 31.07.18 at 11:05, wrote:
>> > On Tue, Jul 31, 2018 at 02:49:19AM -0600, Jan Beulich wrote:
>> >> >>> On 31.07.18 at 10:37, wrote:
>> >> >> -Original Message-
>> >> >> From: Roger P
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 31 July 2018 10:42
> To: Roger Pau Monne
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Paul
> Durrant ; Wei Liu ; Kevin
> Tian ; Stefano Stabellini ;
> xen-devel ; Tim (Xen.org)
> Subject:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2018-14678 / XSA-274
version 2
Linux: Uninitialized state in x86 PV failsafe callback path
UPDATES IN VERSION 2
CVE assigned. Fix the title to refer to
Ian, any objections?
Thanks.On Thu, 2018-06-21 at 08:37 +, Paraschiv, Andra-Irina wrote:
> + Cc: Ian Jackson for review.
>
> Thanks, Roger, for review and feedback.
>
> Andra
>
> From: Roger Pau Monné
> Sent: Monday, June 18, 2018 2:43 PM
> To: Para
Correct a disagreement between text and logged value.
Signed-off-by: Jan Beulich
---
NB: I've already corrected this in the backports.
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -715,7 +715,7 @@ int handle_xsetbv(u32 index, u64 new_bv)
{
gprintk(XENLOG_ERR,
On 31/07/18 11:37, Jan Beulich wrote:
> Correct a disagreement between text and logged value.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinf
>>> On 20.07.18 at 16:57, wrote:
> In preparation for adding switchable SSBD, add some defines and
> variables.
>
> Signed-off-by: Brian Woods
Whether these additions fit the purpose can only be told when
seeing their use. Please fold this into the patch using these.
Jan
___
>>> On 20.07.18 at 16:57, wrote:
> Edit the initialization code for AMD's SSBD via the LS_CFG MSR and
> enable it to pass the status to the initial spec-ctrl print_details at
> boot.
>
> Signed-off-by: Brian Woods
> ---
> xen/arch/x86/cpu/amd.c| 13 ++---
> xen/arch/x86/spec
Hi Jan,
On 31/07/18 09:04, Jan Beulich wrote:
On 30.07.18 at 19:48, wrote:
Today it is a silent option. This patch adds a one line description and
makes it optional.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
CC: george.dun...@eu.citrix.com
CC: ian.jack...@eu.citrix.com
CC: jb
Hi Stefano,
On 30/07/18 18:48, Stefano Stabellini wrote:
Add a "Platform Support" choice with four kconfig options: QEMU, RCAR3,
MPSOC and ALL_PLAT. They enable the required options for their hardware
platform. ALL_PLAT enables all available platforms and it's the default.
It doesn't automatical
flight 125694 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125694/
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
This run is configured for baseline tests only.
flight 75028 xen-unstable real [real]
http://osstest.xensource.com/osstest/logs/75028/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-1 63 xtf/test-hvm64-xsa-204
>>> On 20.07.18 at 16:57, wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -607,16 +607,10 @@ static void init_amd(struct cpuinfo_x86 *c)
> case 0x17: bit = 10; break;
> }
>
> - if (bit >= 0)
> - ssbd_amd_ls_cfg
On 30/07/18 18:48, Stefano Stabellini wrote:
Hi all,
Hi Stefano,
This patch series is the first step toward building a small certifiable
Xen hypervisor for ARM boards.
The series makes a few changes to allow disabling more kconfig options:
most of them already exist but cannot be disabled
flight 125672 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125672/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 125585
test-amd64-i386-qemu
>>> On 25.07.18 at 13:16, wrote:
> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -234,7 +234,7 @@ struct xen_hvm_altp2m_view {
> typedef struct xen_hvm_altp2m_view xen_hvm_altp2m_view_t;
> DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_view_t);
>
> -struct xen_hvm_
>>> On 25.07.18 at 13:18, wrote:
> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -38,7 +38,7 @@ struct xen_hvm_param {
> typedef struct xen_hvm_param xen_hvm_param_t;
> DEFINE_XEN_GUEST_HANDLE(xen_hvm_param_t);
>
> -struct xen_hvm_altp2m_set_suppress_ve {
>
>>> On 25.07.18 at 13:49, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4467,6 +4467,30 @@ static int hvmop_get_param(
> return rc;
> }
>
> +/*
> + * Find the struct vcpu given a dom_id and vcpu_id.
> + * Return NULL if not found.
> + */
> +static struct vcpu *
>>> On 25.07.18 at 14:14, wrote:
> --- a/xen/arch/x86/cpu/mcheck/vmce.c
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c
> @@ -349,6 +349,18 @@ int vmce_wrmsr(uint32_t msr, uint64_t val)
> return ret;
> }
>
> +static int vmce_save_vcpu_ctxt_one(struct vcpu *v, hvm_domain_context_t *h)
Afaict v can
>>> On 25.07.18 at 14:14, wrote:
> This is used to save data from a single instance.
>
> Signed-off-by: Alexandru Isaila
>
> ---
> Changes since V12:
> - Changed memset to {} init.
> ---
> xen/arch/x86/hvm/hvm.c | 214
> +
> 1 file changed
>>> On 25.07.18 at 14:14, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1188,33 +1188,45 @@ HVM_REGISTER_SAVE_RESTORE(CPU, hvm_save_cpu_ctxt,
> hvm_load_cpu_ctxt,
> save_area) + \
>xstate_
>>> On 31.07.18 at 13:56, wrote:
On 25.07.18 at 14:14, wrote:
>> --- a/xen/arch/x86/cpu/mcheck/vmce.c
>> +++ b/xen/arch/x86/cpu/mcheck/vmce.c
>> @@ -349,6 +349,18 @@ int vmce_wrmsr(uint32_t msr, uint64_t val)
>> return ret;
>> }
>>
>> +static int vmce_save_vcpu_ctxt_one(struct vcpu *
>>> On 25.07.18 at 14:14, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1366,69 +1366,80 @@ static const uint32_t msrs_to_send[] = {
> };
> static unsigned int __read_mostly msr_count_max = ARRAY_SIZE(msrs_to_send);
>
> -static int hvm_save_cpu_msrs(struct domain *
>>> On 25.07.18 at 14:14, wrote:
> This is used to save data from a single instance.
>
> Signed-off-by: Alexandru Isaila
>
> ---
> Changes since v11:
> - hvm_save_mtrr_msr() now returns err from hvm_save_mtrr_msr_one().
>
> Note: This patch is based on Roger Pau Monne's series[1]
> ---
>
>>> On 25.07.18 at 14:14, wrote:
> --- a/xen/arch/x86/hvm/viridian.c
> +++ b/xen/arch/x86/hvm/viridian.c
> @@ -1026,24 +1026,32 @@ static int viridian_load_domain_ctxt(struct domain
> *d, hvm_domain_context_t *h)
> HVM_REGISTER_SAVE_RESTORE(VIRIDIAN_DOMAIN, viridian_save_domain_ctxt,
>
>>> On 25.07.18 at 14:14, wrote:
> --- a/xen/arch/x86/hvm/save.c
> +++ b/xen/arch/x86/hvm/save.c
> @@ -85,16 +85,18 @@ int arch_hvm_load(struct domain *d, struct
> hvm_save_header *hdr)
> /* List of handlers for various HVM save and restore types */
> static struct {
> hvm_save_handler sav
flight 125677 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125677/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-shadow 20 guest-start/debian.repeat fail REGR. vs. 124988
Tests which di
On Ma, 2018-07-31 at 06:34 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 25.07.18 at 14:14, wrote:
> > --- a/xen/arch/x86/hvm/save.c
> > +++ b/xen/arch/x86/hvm/save.c
> > @@ -85,16 +85,18 @@ int arch_hvm_load(struct domain *d, struct
> > hvm_save_header *hdr)
> > /* List of handlers f
>>> On 25.07.18 at 14:14, wrote:
> This patch is focused on moving the for loop to the caller so
> now we can save info for a single vcpu instance with the save_one
> handlers.
>
> Signed-off-by: Alexandru Isaila
First of all I'd appreciate if this patch was last in the series, after all
infras
>>> On 25.07.18 at 14:14, wrote:
> --- a/xen/arch/x86/hvm/hpet.c
> +++ b/xen/arch/x86/hvm/hpet.c
> @@ -516,8 +516,9 @@ static const struct hvm_mmio_ops hpet_mmio_ops = {
> };
>
>
> -static int hpet_save(struct domain *d, hvm_domain_context_t *h)
> +static int hpet_save(struct vcpu *vcpu, hvm_
On Ma, 2018-07-31 at 07:24 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 25.07.18 at 14:14, wrote:
> > --- a/xen/arch/x86/hvm/hpet.c
> > +++ b/xen/arch/x86/hvm/hpet.c
> > @@ -516,8 +516,9 @@ static const struct hvm_mmio_ops hpet_mmio_ops
> > = {
> > };
> >
> >
> > -static int hpet
>>> On 31.07.18 at 14:55, wrote:
> On Ma, 2018-07-31 at 06:34 -0600, Jan Beulich wrote:
>> > > > On 25.07.18 at 14:14, wrote:
>> > --- a/xen/arch/x86/hvm/vlapic.c
>> > +++ b/xen/arch/x86/hvm/vlapic.c
>> > @@ -1576,9 +1576,9 @@ static int lapic_load_regs(struct domain *d,
>> > hvm_domain_context_t
On Ma, 2018-07-31 at 07:32 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 31.07.18 at 14:55, wrote:
> > On Ma, 2018-07-31 at 06:34 -0600, Jan Beulich wrote:
> > >
> > > >
> > > > >
> > > > > >
> > > > > > On 25.07.18 at 14:14, wrote:
> > > > --- a/xen/arch/x86/hvm/vlapic.c
> > > >
From: Colin Ian King
Currently when the allocation of gntdev_dmabuf fails, the error exit
path will call dmabuf_imp_free_storage and causes a null pointer
dereference on gntdev_dmabuf. Fix this by adding an error exit path
that won't free gntdev_dmabuf.
Detected by CoverityScan, CID#1472124 ("D
flight 125679 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125679/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 18 guest-localmigrate/x10 fail REGR. vs. 125624
Tests which did
>>> On 31.07.18 at 15:45, wrote:
> On Ma, 2018-07-31 at 07:32 -0600, Jan Beulich wrote:
>> > > > On 31.07.18 at 14:55, wrote:
>> > On Ma, 2018-07-31 at 06:34 -0600, Jan Beulich wrote:
>> > > > > > On 25.07.18 at 14:14, wrote:
>> > > > @@ -114,12 +117,13 @@ void hvm_register_savevm(uint16_t
>> >
flight 125676 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125676/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 125648
test-armhf-armhf-xl
>>> On 31.07.18 at 15:32, wrote:
> On Ma, 2018-07-31 at 07:24 -0600, Jan Beulich wrote:
>> > > > On 25.07.18 at 14:14, wrote:
>> > --- a/xen/arch/x86/hvm/hpet.c
>> > +++ b/xen/arch/x86/hvm/hpet.c
>> > @@ -516,8 +516,9 @@ static const struct hvm_mmio_ops hpet_mmio_ops
>> > = {
>> > };
>> >
>> >
>>> On 27.07.18 at 17:31, wrote:
> Introduce a new iommu=inclusive generic option that supersedes
> iommu_inclusive_mapping. This should be a non-functional change on
> Intel hardware, while AMD hardware will gain the same functionality of
> mapping almost everything below the 4GB boundary.
So fi
>>> On 27.07.18 at 17:31, wrote:
> Several people have reported hardware issues (malfunctioning USB
> controllers) due to iommu page faults. Those faults are caused by
> missing RMRR (VTd) or IRVS (AMD-Vi) entries in the ACPI tables. Those
> can be worked around on VTd hardware by manually adding
The altp2m functionality was originally envisioned to be used in
several different configurations, one of which was a single in-guest
agent that had full operational control of altp2m. This required the
single hypercall to be an HVMOP rather than a DOMCTL, since HVM guests
are not allowed to make
On Tue, Jul 31, 2018 at 04:03:31PM +0100, George Dunlap wrote:
[...]
>
> Reviewed-by: Razvan Cojocaru
> Signed-off-by: George Dunlap
LGTM, FWIW:
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.or
On Tue, Jul 31, 2018 at 04:03:31PM +0100, George Dunlap wrote:
> diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
> index 2ec2e7c80f..daa28a86be 100644
> --- a/xen/include/public/hvm/params.h
> +++ b/xen/include/public/hvm/params.h
> @@ -239,6 +239,11 @@
> * mixed:
On Tue, Jul 31, 2018 at 08:52:14AM -0600, Jan Beulich wrote:
> >>> On 27.07.18 at 17:31, wrote:
> > Several people have reported hardware issues (malfunctioning USB
> > controllers) due to iommu page faults. Those faults are caused by
> > missing RMRR (VTd) or IRVS (AMD-Vi) entries in the ACPI tab
On Tue, Jul 31, 2018 at 05:15:22PM +0200, Roger Pau Monné wrote:
> On Tue, Jul 31, 2018 at 08:52:14AM -0600, Jan Beulich wrote:
> > >>> On 27.07.18 at 17:31, wrote:
> > > --- a/xen/drivers/passthrough/x86/iommu.c
> > > +++ b/xen/drivers/passthrough/x86/iommu.c
> > > @@ -20,6 +20,8 @@
> > > #inclu
On Tue, Jul 31, 2018 at 08:39:22AM -0600, Jan Beulich wrote:
> >>> On 27.07.18 at 17:31, wrote:
> > Introduce a new iommu=inclusive generic option that supersedes
> > iommu_inclusive_mapping. This should be a non-functional change on
> > Intel hardware, while AMD hardware will gain the same functi
>>> On 31.07.18 at 17:15, wrote:
> On Tue, Jul 31, 2018 at 08:52:14AM -0600, Jan Beulich wrote:
>> >>> On 27.07.18 at 17:31, wrote:
>> > +/* ... or the PCIe MCFG regions. */
>> > +for ( i = 0; i < pci_mmcfg_config_num; i++ )
>> > +{
>> > +unsigned long addr = PFN_DOWN(pci_mmcf
>>> On 31.07.18 at 17:27, wrote:
> On Tue, Jul 31, 2018 at 05:15:22PM +0200, Roger Pau Monné wrote:
>> On Tue, Jul 31, 2018 at 08:52:14AM -0600, Jan Beulich wrote:
>> > >>> On 27.07.18 at 17:31, wrote:
>> > > --- a/xen/drivers/passthrough/x86/iommu.c
>> > > +++ b/xen/drivers/passthrough/x86/iommu
On Tue, Jul 31, 2018 at 02:01:39AM -0600, Jan Beulich wrote:
> >>> On 31.07.18 at 04:30, wrote:
>
> Marek,
>
> looks like all of the patches you've sent early this morning local time
> here came through twice on xen-devel: Would you please avoid
> having xen-devel on both the To and the Cc lists
On Tue, Jul 31, 2018 at 10:00:24AM +0100, Wei Liu wrote:
> On Tue, Jul 31, 2018 at 04:30:42AM +0200, Marek Marczykowski-Górecki wrote:
> > --- a/tools/debugger/gdbsx/gx/gx_local.c
> > +++ b/tools/debugger/gdbsx/gx/gx_local.c
> > @@ -45,8 +45,8 @@ prnt_32regs(struct xg_gdb_regs32 *r32p)
> > static
On Tue, 31 Jul 2018, Julien Grall wrote:
> On 30/07/18 18:48, Stefano Stabellini wrote:
> > Hi all,
>
> Hi Stefano,
>
> >
> > This patch series is the first step toward building a small certifiable
> > Xen hypervisor for ARM boards.
> >
> > The series makes a few changes to allow disabling more
On Tue, Jul 31, 2018 at 10:10:10AM +0100, Wei Liu wrote:
> On Tue, Jul 31, 2018 at 05:15:32AM +0200, Marek Marczykowski-Górecki wrote:
> > Add --replace-escape option to xenconsoled, which replaces ESC with
> > '.' in console output written to log file. This makes it slightly safer
> > to do tail -
On Tue, Jul 31, 2018 at 06:10:07PM +0200, Marek Marczykowski-Górecki wrote:
> On Tue, Jul 31, 2018 at 10:00:24AM +0100, Wei Liu wrote:
> > On Tue, Jul 31, 2018 at 04:30:42AM +0200, Marek Marczykowski-Górecki wrote:
> > > --- a/tools/debugger/gdbsx/gx/gx_local.c
> > > +++ b/tools/debugger/gdbsx/gx/g
On 31/07/18 17:10, Marek Marczykowski-Górecki wrote:
> On Tue, Jul 31, 2018 at 10:00:24AM +0100, Wei Liu wrote:
>> On Tue, Jul 31, 2018 at 04:30:42AM +0200, Marek Marczykowski-Górecki wrote:
>>> --- a/tools/debugger/gdbsx/gx/gx_local.c
>>> +++ b/tools/debugger/gdbsx/gx/gx_local.c
>>> @@ -45,8 +45,8
flight 125683 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125683/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 6 xen-install fail REGR. vs. 124881
Regressions whi
On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> This work is in response to my previous attempt to introduce Xen/DRM
> zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
> frontends/backends. There is also an existing hyper_dmabuf approach
On 07/19/2018 05:39 PM, Waiman Long wrote:
> On a VM with only 1 vCPU, the locking fast paths will always be
> successful. In this case, there is no need to use the the PV qspinlock
> code which has higher overhead on the unlock side than the native
> qspinlock code.
>
> The xen_pvspin veriable is
On 07/31/2018 10:02 AM, Colin King wrote:
> From: Colin Ian King
>
> Currently when the allocation of gntdev_dmabuf fails, the error exit
> path will call dmabuf_imp_free_storage and causes a null pointer
> dereference on gntdev_dmabuf. Fix this by adding an error exit path
> that won't free gntd
On Tue, Jul 31, 2018 at 5:53 AM Jan Beulich wrote:
>
> >>> On 25.07.18 at 13:49, wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -4467,6 +4467,30 @@ static int hvmop_get_param(
> > return rc;
> > }
> >
> > +/*
> > + * Find the struct vcpu given a dom_id and v
flight 125704 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125704/
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 07/31/2018 08:19 PM, Tamas K Lengyel wrote:
> On Tue, Jul 31, 2018 at 5:53 AM Jan Beulich wrote:
>> I'd like you to outline in the description how you mean an external
>> agent to coordinate the use of this GFN with the guest (and in
>> particular without in-guest agent).
>
> Using #VE without
flight 125685 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125685/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 125057
test-amd64-i386
1 - 100 of 144 matches
Mail list logo
