On 07/03/2019 06:41, Dan Carpenter wrote:
> The "cpu" variable comes from the sscanf() so Smatch marks it as
> untrusted data. We can't pass a higher value than "nr_cpu_ids" to
> cpu_possible() or it results in an out of bounds access.
>
> Fixes: d68d82afd4c8 ("xen: implement CPU hotplugging")
>
The "cpu" variable comes from the sscanf() so Smatch marks it as
untrusted data. We can't pass a higher value than "nr_cpu_ids" to
cpu_possible() or it results in an out of bounds access.
Fixes: d68d82afd4c8 ("xen: implement CPU hotplugging")
Signed-off-by: Dan Carpenter
---
drivers/xen/cpu_hot
flight 133601 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133601/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 5 host-ping-check-native fail REGR. vs. 133508
test-armhf-armhf-lib
This run is configured for baseline tests only.
flight 83712 xen-4.7-testing real [real]
http://osstest.xensource.com/osstest/logs/83712/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
flight 133600 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133600/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 133491
test-amd64-amd64-xl-qemut-win7-amd64 17
On Fri, Feb 22, 2019 at 11:42:22AM +0100, Roger Pau Monné wrote:
> On Thu, Feb 21, 2019 at 06:40:40PM +0100, Marek Marczykowski-Górecki wrote:
> > On Thu, Feb 21, 2019 at 05:47:51PM +0100, Roger Pau Monné wrote:
> > > On Fri, Feb 08, 2019 at 11:17:05AM +0100, Marek Marczykowski-Górecki
> > > wrote
Hi,
On 06/03/2019 22:42, Stefano Stabellini wrote:
> On Wed, 6 Mar 2019, Amit Tomer wrote:
>> Hi,
>>> Looking at the stack trace, this is very likely due to the issue I pointed
>>> out earlier on. I.e reserved-memory region should be described in the
>>> memory nodes.
>>
>> Do you mean, somethin
On Wed, 6 Mar 2019, Amit Tomer wrote:
> Hi,
> > Looking at the stack trace, this is very likely due to the issue I pointed
> > out earlier on. I.e reserved-memory region should be described in the
> > memory nodes.
>
> Do you mean, something like this(reserved-memory node is under memory node) ?
flight 133598 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133598/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 130965
test-xtf-amd64-
On Wed, 6 Mar 2019, Jan Beulich wrote:
> >>> On 05.03.19 at 23:38, wrote:
> > @@ -193,8 +191,10 @@ void init_or_livepatch apply_alternatives(struct
> > alt_instr *start,
>
> Seeing this relevant part of the function parameters, ...
>
> > *
> > * So be careful if you want to change t
On Wed, 6 Mar 2019, Jan Beulich wrote:
> >>> On 05.03.19 at 23:38, wrote:
> > @@ -600,7 +602,9 @@ static void noinline init_done(void)
> > unregister_init_virtual_region();
> >
> > /* Zero the .init code and data. */
> > -for ( va = __init_begin; va < _p(__init_end); va += PAGE_SIZ
On Wed, 6 Mar 2019, Jan Beulich wrote:
> >>> On 05.03.19 at 23:38, wrote:
> > Use __UINTPTR_TYPE__ to define uintptr_t. A later patch will make use of
> > __PTRDIFF_TYPE__ to define ptrdiff_t.
> >
> > Signed-off-by: Stefano Stabellini
> > Reviewed-by: Ian Jackson
>
> As before - I object to th
This run is configured for baseline tests only.
flight 83711 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/83711/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
On Wed, 6 Mar 2019, Jan Beulich wrote:
> >>> On 05.03.19 at 23:38, wrote:
> > --- a/xen/common/kernel.c
> > +++ b/xen/common/kernel.c
> > @@ -306,20 +306,25 @@ void add_taint(unsigned int flag)
> > tainted |= flag;
> > }
> >
> > -extern const initcall_t __initcall_start[], __presmp_initcal
On Wed, 6 Mar 2019, Jan Beulich wrote:
> >>> On 05.03.19 at 23:38, wrote:
> > --- a/xen/arch/x86/percpu.c
> > +++ b/xen/arch/x86/percpu.c
> > @@ -13,7 +13,8 @@ unsigned long __per_cpu_offset[NR_CPUS];
> > * context of PV guests.
> > */
> > #define INVALID_PERCPU_AREA (0x8000L - (l
On 3/6/19 6:52 PM, Wei Liu wrote:
> Go through the transformations suggested by 2to3 and pick the
> necessary ones.
>
> Use sys.stderr.write to avoid importing from __future__.
>
> Signed-off-by: Wei Liu
> ---
> tools/libxl/gentest.py | 2 +-
> tools/libxl/gentypes.py | 10 +-
> tools
On Wed, 6 Mar 2019, Jan Beulich wrote:
> > +static inline ptrdiff_t name ## _diff(const type s1[],
> >\
> > + const struct abstract_ ## name s2[])
> >\
> > +{
On 06/03/2019 17:52, Wei Liu wrote:
> @@ -128,16 +154,25 @@ fsimage_file_dealloc(fsimage_file_t *file)
> PyObject_DEL(file);
> }
>
> +/* Compatibility for 2.5 and earlier */
> +#ifndef PyVarObject_HEAD_INIT
> +#define PyVarObject_HEAD_INIT(type, size) \
> + PyObject_HEAD_INIT(type) siz
On 06/03/2019 17:52, Wei Liu wrote:
> diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/GrubConf.py
> index dc810d55cb..97913f3993 100644
> --- a/tools/pygrub/src/GrubConf.py
> +++ b/tools/pygrub/src/GrubConf.py
> @@ -100,7 +100,7 @@ class _GrubImage(object):
> " initrd
On 06/03/2019 17:52, Wei Liu wrote:
> @@ -362,11 +362,10 @@ def parse(f):
> globs[n] = t
>
> try:
> -execfile(f, globs, locs)
> -except SyntaxError,e:
> -raise SyntaxError, \
> - "Errors were found at line %d while processing %s:\n\t%s"\
> -
On Wed, Mar 06, 2019 at 05:52:05PM +, Wei Liu wrote:
> This series makes tools work with Python 2 and 3.
>
> No more RFC because I have tested it on my testbox.
Spoke too soon. The testbox wasn't using the files I installed. I will
retest tomorrow.
Wei.
_
This series makes tools work with Python 2 and 3.
No more RFC because I have tested it on my testbox.
You need Andrew's "tools/xen-foreign: Update python scripts to be
Py3 compatible" as well.
Wei.
Wei Liu (5):
Do the following:
1. Change the form of "print".
2. Use AC_CHECK_FUNC to avoid the need to generate library name.
3. Remove unused stuff.
Signed-off-by: Wei Liu
---
I doubt the non-python-config branch works, because the paths generated
seem rather off. It definitely doesn't work on my machine,
Go through the transformations suggested by 2to3 and pick the
necessary ones.
Use sys.stderr.write to avoid importing from __future__.
Signed-off-by: Wei Liu
---
tools/libxl/gentest.py | 2 +-
tools/libxl/gentypes.py | 10 +-
tools/libxl/idl.py | 13 ++---
3 files changed
CentOS 5, which was the reason of the 2.4 restriction, is EOL. CentOS
6 ships 2.6.
Bump the version to 2.6 in README. Now that all scripts are 3
compatible, remove the restriction on python 2 as well.
Update the check in configure.ac.
Signed-off-by: Wei Liu
---
README | 10 ++--
With the help of two porting guides and cpython source code:
1. Use PyBytes to replace PyString counterparts.
2. Use PyVarObject_HEAD_INIT and provide compatibility for 2.5 and
earlier.
3. Remove usage of Py_FindMethod.
4. Use new module initialisation routine.
For #3, Py_FindMethod was remove
Run 2to3 and pick the sensible suggestions.
Signed-off-by: Wei Liu
---
tools/pygrub/src/ExtLinuxConf.py | 15 ---
tools/pygrub/src/GrubConf.py | 36 ++--
tools/pygrub/src/LiloConf.py | 15 ---
3 files changed, 34 insertions(+), 32 d
On 03/06/19 15:26, Igor Druzhinin wrote:
> On 06/03/2019 13:22, Laszlo Ersek wrote:
>> On 03/06/19 13:40, Igor Druzhinin wrote:
>>> On Xen, hvmloader firmware leaves address decoding enabled for
>>> enumerated PCI device before jumping into OVMF. OVMF seems to
>>> expect it to be disabled and tries
flight 133596 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133596/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 130859
Tests which did not succ
On Tue, Mar 05, 2019 at 04:42:06PM +, Wei Liu wrote:
> +
> PyMODINIT_FUNC
> initxenfsimage(void)
So Python 3 requires the initialisation function to be called
PyInit_xenfsimage, otherwise it can't find the entry point of this
module.
I have fixed this in my next version.
Wei.
> {
> +#if
flight 133621 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133621/
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 3/5/19 7:25 PM, Konrad Rzeszutek Wilk wrote:
> Hi Jens,
>
> Apologies for doing it right at the merge window time. This patchset has been
> brewing
> for quite a while.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> stable/for-jens-5.1
>
> This patchset makes the backend
>>> On 05.03.19 at 23:38, wrote:
> @@ -193,8 +191,10 @@ void init_or_livepatch apply_alternatives(struct
> alt_instr *start,
Seeing this relevant part of the function parameters, ...
> *
> * So be careful if you want to change the scan order to any other
> * order.
> + *
>
On Wed, Mar 06, 2019 at 03:35:53PM +, Anthony PERARD wrote:
> On Wed, Mar 06, 2019 at 03:24:43PM +, Wei Liu wrote:
> > On Wed, Mar 06, 2019 at 03:07:16PM +, Anthony PERARD wrote:
> > > > -AC_CHECK_LIB(python$ac_python_version, PyArg_ParseTuple, [],
> > > > -[AC_MSG_ERROR([Unable to
flight 83710 distros-debian-squeeze real [real]
http://osstest.xensource.com/osstest/logs/83710/
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 Tue, Mar 05, 2019 at 05:34:13PM +, Andrew Cooper wrote:
> On 05/03/2019 16:42, Wei Liu wrote:
> > All scripts are transformed by 2to3.
> >
> > The only addition is "from __future__ import print_function" so that
> > print("BLAH", file=sys.stderr) can work.
> >
> > https://python-future.org/c
On 06/03/2019, 16:00, "Ian Jackson" wrote:
Lars Kurth writes ("Re: [Xen-devel] Can someone pls repair patchwork?"):
> Hi all, (+ Florian & +Ian, as NEC runs their own patchwork instance and
may have some insights)
>
> before I approach I wanted to ask whether we are sure this
On 06/03/2019 16:42, Jan Beulich wrote:
On 27.02.19 at 17:13, wrote:
>> This patch series attempts to mitigate the issue that have been raised in the
>> XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
>> execution on Intel hardware, an lfence instruction is requi
Hi Ian,
On 06/03/2019 16:00, Ian Jackson wrote:
Unfortunately I could not find contact details for the site admins
for either of these anywhere on those websites.
You can find the contact on kernel.org (see [1]). Oleksandr already CCed them on
another e-mail.
Cheers,
[1] https://www.kernel
Lars Kurth writes ("Re: [Xen-devel] Can someone pls repair patchwork?"):
> Hi all, (+ Florian & +Ian, as NEC runs their own patchwork instance and may
> have some insights)
>
> before I approach I wanted to ask whether we are sure this has to do with the
> list change. I am assuming that patchwo
>>> On 05.03.19 at 23:38, wrote:
> @@ -600,7 +602,9 @@ static void noinline init_done(void)
> unregister_init_virtual_region();
>
> /* Zero the .init code and data. */
> -for ( va = __init_begin; va < _p(__init_end); va += PAGE_SIZE )
> +for ( va = (char *)__init_begin;
> +
>>> On 27.02.19 at 17:13, wrote:
> This patch series attempts to mitigate the issue that have been raised in the
> XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
> execution on Intel hardware, an lfence instruction is required to make sure
> that selected checks are
>>> On 05.03.19 at 23:38, wrote:
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -306,20 +306,25 @@ void add_taint(unsigned int flag)
> tainted |= flag;
> }
>
> -extern const initcall_t __initcall_start[], __presmp_initcall_end[],
> -__initcall_end[];
> +DECLARE_ARRAY_BOUN
On Wed, Mar 06, 2019 at 03:24:43PM +, Wei Liu wrote:
> On Wed, Mar 06, 2019 at 03:07:16PM +, Anthony PERARD wrote:
> > > -AC_CHECK_LIB(python$ac_python_version, PyArg_ParseTuple, [],
> > > -[AC_MSG_ERROR([Unable to find a suitable python development
> > > library])],
> > > -[$PYTHO
>>> On 05.03.19 at 23:38, wrote:
> --- a/xen/arch/x86/percpu.c
> +++ b/xen/arch/x86/percpu.c
> @@ -13,7 +13,8 @@ unsigned long __per_cpu_offset[NR_CPUS];
> * context of PV guests.
> */
> #define INVALID_PERCPU_AREA (0x8000L - (long)__per_cpu_start)
> -#define PERCPU_ORDER get_orde
On Wed, Mar 06, 2019 at 03:07:16PM +, Anthony PERARD wrote:
> On Tue, Mar 05, 2019 at 04:42:03PM +, Wei Liu wrote:
> > Do the following:
> >
> > 1. Change the form of "print".
> > 2. Check for ABI flags -- this is complicated because it is only
> >introduced in 3.2.
>
> Is this a reco
>>> On 05.03.19 at 23:38, wrote:
> --- a/xen/include/xen/lib.h
> +++ b/xen/include/xen/lib.h
> @@ -173,4 +173,92 @@ void init_constructors(void);
> void *bsearch(const void *key, const void *base, size_t num, size_t size,
>int (*cmp)(const void *key, const void *elt));
>
> + /*
On Tue, Mar 05, 2019 at 04:42:03PM +, Wei Liu wrote:
> Do the following:
>
> 1. Change the form of "print".
> 2. Check for ABI flags -- this is complicated because it is only
>introduced in 3.2.
Is this a recommanded way of doing this? I may have a better way of
fixing this macro, see bel
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 06 March 2019 14:38
> 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 06.03.19 at 14:09, wrote:
>> From: Paul Durrant
>> Sent: 06 March 2019 13:06
>>
>> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> > Sent: 06 March 2019 12:57
>> > Subject: RE: [PATCH v3 8/9] viridian: add implementation of synthetic
>> > timers
>> >
>> > >>> On 06.03.19 at 12:23, wrot
flight 133595 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133595/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 7 xen-boot fail REGR. vs. 132938
Tests which di
On 06/03/2019 13:22, Laszlo Ersek wrote:
> On 03/06/19 13:40, Igor Druzhinin wrote:
>> On Xen, hvmloader firmware leaves address decoding enabled for
>> enumerated PCI device before jumping into OVMF. OVMF seems to
>> expect it to be disabled and tries to size PCI BARs in several places
>> without
On Wed, Mar 06, 2019 at 02:17:31PM +, Anthony PERARD wrote:
> On Wed, Mar 06, 2019 at 01:57:55PM +, Wei Liu wrote:
> > On Wed, Mar 06, 2019 at 01:53:01PM +, George Dunlap wrote:
> > > On 3/6/19 1:49 PM, George Dunlap wrote:
> > > > On 3/5/19 4:42 PM, Wei Liu wrote:
> > > >> This series
On Wed, Mar 06, 2019 at 01:57:55PM +, Wei Liu wrote:
> On Wed, Mar 06, 2019 at 01:53:01PM +, George Dunlap wrote:
> > On 3/6/19 1:49 PM, George Dunlap wrote:
> > > On 3/5/19 4:42 PM, Wei Liu wrote:
> > >> This series makes tools build with Python 3.
> > >>
> > >> Compile test only with 2.7
On 06/03/2019 13:49, George Dunlap wrote:
> On 3/5/19 4:42 PM, Wei Liu wrote:
>> This series makes tools build with Python 3.
>>
>> Compile test only with 2.7 and 3.5 thus far, hence the RFC. This should be
>> able
>> to give people some idea what sort of work is involved.
>>
>> You will also need
On Wed, Mar 06, 2019 at 01:53:01PM +, George Dunlap wrote:
> On 3/6/19 1:49 PM, George Dunlap wrote:
> > On 3/5/19 4:42 PM, Wei Liu wrote:
> >> This series makes tools build with Python 3.
> >>
> >> Compile test only with 2.7 and 3.5 thus far, hence the RFC. This should be
> >> able
> >> to gi
On 3/6/19 1:49 PM, George Dunlap wrote:
> On 3/5/19 4:42 PM, Wei Liu wrote:
>> This series makes tools build with Python 3.
>>
>> Compile test only with 2.7 and 3.5 thus far, hence the RFC. This should be
>> able
>> to give people some idea what sort of work is involved.
>>
>> You will also need A
On Wed, Mar 06, 2019 at 01:49:18PM +, George Dunlap wrote:
> On 3/5/19 4:42 PM, Wei Liu wrote:
> > This series makes tools build with Python 3.
> >
> > Compile test only with 2.7 and 3.5 thus far, hence the RFC. This should be
> > able
> > to give people some idea what sort of work is involve
On 3/5/19 4:42 PM, Wei Liu wrote:
> This series makes tools build with Python 3.
>
> Compile test only with 2.7 and 3.5 thus far, hence the RFC. This should be
> able
> to give people some idea what sort of work is involved.
>
> You will also need Andrew's "tools/xen-foreign: Update python scrip
flight 133594 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133594/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-saverestore.2 fail REGR. vs.
133487
test-armhf
On 03/06/19 13:40, Igor Druzhinin wrote:
> On Xen, hvmloader firmware leaves address decoding enabled for
> enumerated PCI device before jumping into OVMF. OVMF seems to
> expect it to be disabled and tries to size PCI BARs in several places
> without disabling it which causes BAR64, for example, b
> -Original Message-
> From: Paul Durrant
> Sent: 06 March 2019 13:06
> To: 'Jan Beulich'
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Roger Pau
> Monne
> ; Wei Liu ; Stefano Stabellini
> ;
> xen-devel ; Konrad Rzeszutek Wilk
> ; Tim
> (Xen.org)
> Subject: RE
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 06 March 2019 12:57
> 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
>
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 06 March 2019 13:00
> 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 06.03.19 at 12:47, wrote:
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
>> Paul Durrant
>> Sent: 06 March 2019 11:24
>>
>> > -Original Message-
>> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> > Sent: 25 February 2019 14:54
>> >
>> > >>> On 31
Add a sysctl hypercall to support getting hypervisor parameters
at runtime.
Signed-off-by: Vasilis Liaskovitis
---
tools/flask/policy/modules/dom0.te | 2 +-
xen/common/kernel.c | 109
xen/common/sysctl.c | 45
xen/inc
Add a new xl command "get-parameters" to get hypervisor parameters at
runtime.
Signed-off-by: Vasilis Liaskovitis
---
docs/man/xl.1.pod.in | 5 +
tools/xl/xl.h | 1 +
tools/xl/xl_cmdtable.c | 5 +
tools/xl/xl_misc.c | 25 +
4 files changed, 36 in
Currently parameters of the hypervisor cannot be inspected at runtime
through an xl command. Such a command would be a useful diagnostic
tool e.g. used in conjunction with the "xl set-parameters" command.
This patch series implements a new xl command "xl get-parameters"
which takes a string of inp
Add a new libxc function to get hypervisor parameters at runtime.
Signed-off-by: Vasilis Liaskovitis
---
tools/libxc/include/xenctrl.h | 1 +
tools/libxc/xc_misc.c | 26 ++
2 files changed, 27 insertions(+)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libx
Add a new libxl function to get hypervisor parameters at runtime.
Signed-off-by: Vasilis Liaskovitis
---
tools/libxl/libxl.c | 15 +++
tools/libxl/libxl.h | 1 +
2 files changed, 16 insertions(+)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ec71574e99..124033e5a3 10
>>> On 06.03.19 at 12:23, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 25 February 2019 14:54
>>
>> >>> On 31.01.19 at 11:47, wrote:
>> > @@ -118,14 +119,237 @@ static int64_t time_ref_count(struct domain *d)
>> > return raw_trc_val(d) + trc->off;
>> > }
>> >
>> > +stati
On Wed, Mar 06, 2019 at 11:46:24AM +, Andrew Cooper wrote:
> On 06/03/2019 11:31, Wei Liu wrote:
> > On Tue, Mar 05, 2019 at 05:51:04PM +, Andrew Cooper wrote:
> >> On 05/03/2019 16:42, Wei Liu wrote:
> >>> Signed-off-by: Wei Liu
> >>> ---
> >>> Not sure this works with python 2.4, but it
On Tue, Mar 05, 2019 at 07:17:07PM +0100, Marek Marczykowski-Górecki wrote:
> On Tue, Mar 05, 2019 at 05:48:10PM +, Wei Liu wrote:
> > On Tue, Mar 05, 2019 at 05:42:07PM +, Andrew Cooper wrote:
> > > On 05/03/2019 16:42, Wei Liu wrote:
> > > > With the help of two porting guides and cpython
On Xen, hvmloader firmware leaves address decoding enabled for
enumerated PCI device before jumping into OVMF. OVMF seems to
expect it to be disabled and tries to size PCI BARs in several places
without disabling it which causes BAR64, for example, being
incorrectly placed by QEMU.
Fix it by disab
In case BAR64 is placed below 4G choose the correct aperture.
This fixes a failed assertion down the code path.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Igor Druzhinin
---
OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 6 +-
1 file changed, 5 insertions(+), 1 d
This aperture doesn't exist in OVMF and trying to use it causes
failing assertions later in cases there are prefetchable and
non-prefetchable BARs following each other. This configuration is
quite likely with some PCI passthrough devices.
Contributed-under: TianoCore Contribution Agreement 1.1
Sig
Resend to include xen-devel@lists.xenproject.org to CC
Igor Druzhinin (3):
OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge
aperture
OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64
OvmfPkg/XenSupport: turn off address decoding before BAR sizing
Ovmf
+webmas...@kernel.org
Hi, there!
Could you please fix wrong mailing list for Xen project at [2]?
The correct mailing list now lives at "xen-devel@lists.xenproject.org"
Thank you in advance,
Oleksandr
On 3/6/19 1:17 PM, Julien Grall wrote:
(+ Lars)
On 06/03/2019 10:04, Oleksandr Andrushchenko
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Paul Durrant
> Sent: 06 March 2019 11:24
> To: 'Jan Beulich'
> Cc: Stefano Stabellini ; Wei Liu
> ; Konrad Rzeszutek Wilk
> ; Andrew Cooper ; Tim
> (Xen.org) ;
> George Dunlap ; Julien
Hi,
> Looking at the stack trace, this is very likely due to the issue I pointed
> out earlier on. I.e reserved-memory region should be described in the memory
> nodes.
Do you mean, something like this(reserved-memory node is under memory node) ?
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb
On 06/03/2019 11:31, Wei Liu wrote:
> On Tue, Mar 05, 2019 at 05:51:04PM +, Andrew Cooper wrote:
>> On 05/03/2019 16:42, Wei Liu wrote:
>>> Signed-off-by: Wei Liu
>>> ---
>>> Not sure this works with python 2.4, but it should work with 2.7 since
>>> the changes look more or less in the same ve
On Tue, Mar 05, 2019 at 05:51:04PM +, Andrew Cooper wrote:
> On 05/03/2019 16:42, Wei Liu wrote:
> > Signed-off-by: Wei Liu
> > ---
> > Not sure this works with python 2.4, but it should work with 2.7 since
> > the changes look more or less in the same vein as the changes in
> > libxl.
> >
> >
Hi
> Thanks for testing! You might have found a real bug in the series. Could
> you please also attach the full device tree?
Please find the attached DTS and DTB file used for testing.
Thanks
-Amit
r8a7795-h3ulcb.dts
Description: audio/vnd.dts
r8a7795-h3ulcb.dtb
Description: Binary data
_
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 25 February 2019 14:54
> 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>; Kon
Due to personal changes at Intel, I am new TXT maintainer for XEN.
Adding patch that updates maintainers list.
Thanks,
Lukasz
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/debugge
(+ Lars)
On 06/03/2019 10:04, Oleksandr Andrushchenko wrote:
To whom it may concern
Hi Oleksandr,
Since late 2017 the very useful Patchwork resource [1]
stopped working after (as I assume) Xen-devel list has changed
its address from xen-de...@lists.xen.org to the current one.
Patchwork is s
Hello Jinch,
On 05.03.19 15:35, Jinch wrote:
Thank you for your reply,
Now I can set the disk and some basic devices to run Android domu to console,
The main issue is the display GUI of Android.
Here you should distinguish clearly display subsystem and 3D rendering engine.
Yet you need them b
flight 133615 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133615/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3
baseline version:
xen f393
To whom it may concern
Since late 2017 the very useful Patchwork resource [1]
stopped working after (as I assume) Xen-devel list has changed
its address from xen-de...@lists.xen.org to the current one.
Patchwork is still configured to the old one, so recent
patches are not archived.
Could the res
On Mon, Mar 04, 2019 at 04:42:32PM -0700, Jim Fehlig wrote:
> Adding xen-devel to cc in case anyone there wants to comment on my latest
> proposal...
>
> On 2/20/19 5:20 PM, Jim Fehlig wrote:
> > There have been a few requests [1][2] to support Xen's max_grant_frames
> > setting in libvirt domXML,
90 matches
Mail list logo
