On Tue, Mar 5, 2019 at 12:56 AM Robin Murphy wrote:
> On 2019-03-04 7:59 pm, Arnd Bergmann wrote:
> > This reverts commit b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR"),
> > which
> > introduced an overflow warning in configurations that have a larger
> > dma_addr_t than phys_addr_t:
> >
> >
On Tue, Mar 5, 2019 at 7:39 AM Juergen Gross wrote:
>
> Can we avoid that ifdef in the Makefile?
>
> I'd rather have an architecture independant builtin driver added which
> is always included for CONFIG_XEN. This would allow to move redundant
> stuff from arch/*/xen/ into it (e.g. xen_vcpu_id).
> -Original Message-
> From: Tian, Kevin [mailto:kevin.t...@intel.com]
> Sent: 05 March 2019 02:45
> To: Paul Durrant ; xen-devel
> (xen-devel@lists.xenproject.org) de...@lists.xenproject.org>
> Subject: RE: standalone PCI passthrough emulator
>
> > From: Paul Durrant [mailto:paul.durr..
flight 133576 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133576/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133552
test-armhf-armhf-libvirt 14 sav
On 05/03/2019 09:34, Arnd Bergmann wrote:
> On Tue, Mar 5, 2019 at 7:39 AM Juergen Gross wrote:
>
>>
>> Can we avoid that ifdef in the Makefile?
>>
>> I'd rather have an architecture independant builtin driver added which
>> is always included for CONFIG_XEN. This would allow to move redundant
>>
Hi,
On 3/5/19 1:55 AM, jinchen wrote:
> Hi,
Hello,
> I’m using the NXP i.mx8qxp men board and want to create an
Android domu on Xen,
> but this board doesn’t have IOMMU. Does anyone knows that can I
passthrough GPU without IOMMU on it?
Device DMA-capable passthroug
On Tue, Mar 5, 2019 at 10:05 AM Juergen Gross wrote:
>
> On 05/03/2019 09:34, Arnd Bergmann wrote:
> > On Tue, Mar 5, 2019 at 7:39 AM Juergen Gross wrote:
> >
> >>
> >> Can we avoid that ifdef in the Makefile?
> >>
> >> I'd rather have an architecture independant builtin driver added which
> >> i
Hi Robin,
On 3/4/19 11:56 PM, Robin Murphy wrote:
On 2019-03-04 7:59 pm, Arnd Bergmann wrote:
This reverts commit b907e20508d0 ("swiotlb: remove
SWIOTLB_MAP_ERROR"), which
introduced an overflow warning in configurations that have a larger
dma_addr_t than phys_addr_t:
In file included from in
Hi Arnd,
On 3/5/19 8:16 AM, Arnd Bergmann wrote:
On Tue, Mar 5, 2019 at 12:56 AM Robin Murphy wrote:
On 2019-03-04 7:59 pm, Arnd Bergmann wrote:
This reverts commit b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR"), which
introduced an overflow warning in configurations that have a larger
dm
On Mon, Mar 04, 2019 at 06:31:48PM +, 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. Replace it
>w
On Mon, Mar 04, 2019 at 07:00:11PM +, George Dunlap wrote:
> checking for PyArg_ParseTuple in -lpython... no
> configure: error: Unable to find a suitable python development library
> configure: error: ./configure failed for tools
>
> Note the error with the VERSION above; that results in look
On 04/03/2019 10:31, Andy Shevchenko wrote:
> Switch to bitmap_zalloc() to show clearly what we are allocating.
> Besides that it returns pointer of bitmap type instead of opaque void *.
>
> Signed-off-by: Andy Shevchenko
Pushed to xen/tip.git for-linus-5.1a
Juergen
__
On 04/03/2019 21:52, Arnd Bergmann wrote:
> The legacy hypercall handlers were originally added with
> a comment explaining that "copying the argument structures in
> HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local
> variable is sufficiently safe" and only made sure to not
On 04/03/2019 20:00, George Dunlap wrote:
> On 3/4/19 6:31 PM, 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
flight 83704 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/83704/
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 12:41:53PM +0100, Juergen Gross wrote:
> On 04/03/2019 20:00, George Dunlap wrote:
> > On 3/4/19 6:31 PM, 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() doe
On 3/5/19 12:04 PM, Wei Liu wrote:
> On Tue, Mar 05, 2019 at 12:41:53PM +0100, Juergen Gross wrote:
>> On 04/03/2019 20:00, George Dunlap wrote:
>>> On 3/4/19 6:31 PM, Andrew Cooper wrote:
The issues are:
* dict.has_key() was completely removed in Py3
* dict.keys() is an iterable r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-291
version 2
x86/PV: page type reference counting issue with failed IOMMU update
UPDATES IN VERSION 2
Metadata updated to remove dependency on XSA-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-285
version 2
race with pass-through device hotplug
UPDATES IN VERSION 2
Metadata updated to remove dependency on XSA-283.
Public re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-292
version 2
x86: insufficient TLB flushing when using PCID
UPDATES IN VERSION 2
Metadata updated to remove dependency on XSA-283.
Publi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-287
version 2
x86: steal_page violates page_struct access discipline
UPDATES IN VERSION 2
Metadata updated to remove dependency on XSA-283.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-288
version 2
x86: Inconsistent PV IOMMU discipline
UPDATES IN VERSION 2
Metadata updated to remove dependency on XSA-283.
4.7 backp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-290
version 2
missing preemption in x86 PV page table unvalidation
UPDATES IN VERSION 2
Metadata updated to remove dependency on XSA-283.
Pu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-284
version 2
grant table transfer issues on large hosts
UPDATES IN VERSION 2
Metadata updated to remove dependency on XSA-283.
Public
>>> On 04.03.19 at 09:15, wrote:
> On 2/28/19 11:00, Jan Beulich wrote:
> On 27.02.19 at 14:01, wrote:
>>> On 2/25/19 17:46, Jan Beulich wrote:
I would really like to ask that I (or someone else) don't need to
go through and list remaining version checks again - after all I
had
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-294
version 2
x86 shadow: Insufficient TLB flushing when using PCID
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
On 05/03/2019 13:19, George Dunlap wrote:
> On 3/5/19 12:04 PM, Wei Liu wrote:
>> On Tue, Mar 05, 2019 at 12:41:53PM +0100, Juergen Gross wrote:
>>> On 04/03/2019 20:00, George Dunlap wrote:
On 3/4/19 6:31 PM, Andrew Cooper wrote:
> The issues are:
> * dict.has_key() was completely re
On 3/5/19 12:30 PM, Juergen Gross wrote:
> On 05/03/2019 13:19, George Dunlap wrote:
>> On 3/5/19 12:04 PM, Wei Liu wrote:
>>> On Tue, Mar 05, 2019 at 12:41:53PM +0100, Juergen Gross wrote:
On 04/03/2019 20:00, George Dunlap wrote:
> On 3/4/19 6:31 PM, Andrew Cooper wrote:
>> The issue
On 3/5/19 12:31 PM, George Dunlap wrote:
> On 3/5/19 12:30 PM, Juergen Gross wrote:
>> On 05/03/2019 13:19, George Dunlap wrote:
>>> On 3/5/19 12:04 PM, Wei Liu wrote:
On Tue, Mar 05, 2019 at 12:41:53PM +0100, Juergen Gross wrote:
> On 04/03/2019 20:00, George Dunlap wrote:
>> On 3/4/1
On 05/03/2019 13:33, George Dunlap wrote:
> On 3/5/19 12:31 PM, George Dunlap wrote:
>> On 3/5/19 12:30 PM, Juergen Gross wrote:
>>> On 05/03/2019 13:19, George Dunlap wrote:
On 3/5/19 12:04 PM, Wei Liu wrote:
> On Tue, Mar 05, 2019 at 12:41:53PM +0100, Juergen Gross wrote:
>> On 04/03
Much of the tools and configure makefile actually have a python2
dependency; specify this. It also assumes that `python` points to `python2`;
document how to work around this on systems where this is false.
Also update second version requirement listed to match the first.
Signed-off-by: George D
On Tue, Mar 05, 2019 at 12:48:52PM +, George Dunlap wrote:
> Much of the tools and configure makefile actually have a python2
> dependency; specify this. It also assumes that `python` points to `python2`;
> document how to work around this on systems where this is false.
>
> Also update secon
On 05/03/2019 13:48, George Dunlap wrote:
> Much of the tools and configure makefile actually have a python2
> dependency; specify this. It also assumes that `python` points to `python2`;
> document how to work around this on systems where this is false.
>
> Also update second version requirement
On 27/02/2019 11:45, Julien Grall wrote:
> (+ Juergen Gross as RM)
>
> I forgot to CC Juergen for this.
>
> On 2/26/19 11:03 PM, Julien Grall wrote:
>> After upgrading Debian to Buster, I started noticing console mangling
>> when using zsh. This is happenning because output sent by zsh to the
>>
From: Andrii Anisov
The hypercall employs the same vcpu_register_runstate_memory_area
structure for the interface, but requires registered area to not
cross a page boundary.
Signed-off-by: Andrii Anisov
---
xen/arch/arm/domain.c | 39 ++---
xen/arch/x86/domain.c
From: Andrii Anisov
VCPUOP_register_runstate_phys_memory_area is implemented via runstate
area mapping.
Signed-off-by: Andrii Anisov
---
xen/arch/arm/domain.c| 22 ++-
xen/arch/x86/domain.c| 34 ++--
xen/common/domain.c | 92
From: Andrii Anisov
Following discussion [1] it is introduced and implemented a runstate
registration interface which uses guest's phys address instead of a virtual one.
The new hypercall employes the same data structures as a predecessor, but
expects the vcpu_runstate_info structure to not cross
On 05/03/2019 14:14, Andrii Anisov wrote:
> From: Andrii Anisov
>
> Following discussion [1] it is introduced and implemented a runstate
> registration interface which uses guest's phys address instead of a virtual
> one.
> The new hypercall employes the same data structures as a predecessor, bu
At least patch 1 is a clear candidate for 4.12; the others are less clear,
but I wanted to put them on the table nevertheless. The patches are
grouped together just because of the XSA relationship; they don't
depend on one another.
1: x86/mm: fix #GP(0) in switch_cr3_cr4()
2: IOMMU/x86: make page
With "pcid=no-xpti" and opposite XPTI settings in two 64-bit PV domains
(achievable with one of "xpti=no-dom0" or "xpti=no-domu"), switching
from a PCID-disabled to a PCID-enabled 64-bit PV domain fails to set
CR4.PCIDE in time, as CR4.PGE would not be set in either (see
pv_guest_cr4_to_real_cr4(),
There are currently three more or less different checks:
- _get_page_type() adjusts the IOMMU mappings according to the new type
alone,
- arch_iommu_populate_page_table() wants just the type to be
PGT_writable_page,
- iommu_hwdom_init() additionally permits all other types with a type
refcoun
Hello,
On 05.03.19 11:15, Julien Grall wrote:
I am not familiar with Android running in guest. CCing some people that may
know.
Running Android in DomU is a pretty long story. And the initial thread topic is
GPU passthrough without IOMMU.
So, Jinchen, could you please describe in details the
On 05/03/2019 14:25, Jan Beulich wrote:
> With "pcid=no-xpti" and opposite XPTI settings in two 64-bit PV domains
> (achievable with one of "xpti=no-dom0" or "xpti=no-domu"), switching
> from a PCID-disabled to a PCID-enabled 64-bit PV domain fails to set
> CR4.PCIDE in time, as CR4.PGE would not b
The commit re-introducing it (14eb3b41d0 ["xen: reinstate previously
unused XENMEM_remove_from_physmap hypercall"]) as well as the one having
originally introduced it (d818f3cb7c ["hvm: Use main memory for video
memory"]) and the one then purging it again (78c3097e4f ["Remove unused
XENMEM_remove_f
Building the privcmd code as a loadable module on ARM, we get
a link error due to the private cache management functions:
ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined!
Move the code into a new file that is always built in when Xen
is enabled, as suggested by Juergen Gross.
Hello Juergen,
On 05.03.19 15:20, Juergen Gross wrote:
No new features for 4.12. This series will have to wait until 4.13.
This is rather a complex fix for [1].
[1] https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg02379.html
--
Sincerely,
Andrii Anisov.
__
On 05/03/2019 14:30, Arnd Bergmann wrote:
> Building the privcmd code as a loadable module on ARM, we get
> a link error due to the private cache management functions:
>
> ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined!
>
> Move the code into a new file that is always built
> 在 2019年3月5日，下午9:26，Andrii Anisov 写道：
>
> Hello,
>
> On 05.03.19 11:15, Julien Grall wrote:
>> I am not familiar with Android running in guest. CCing some people that may
>> know.
> Running Android in DomU is a pretty long story. And the initial thread topic
> is GPU passthrough without IOM
On 3/5/19 1:32 PM, Andrii Anisov wrote:
Hello Juergen,
Hi,
On 05.03.19 15:20, Juergen Gross wrote:
No new features for 4.12. This series will have to wait until 4.13.
This is rather a complex fix for [1].
I will back Juergen here. As I said in that thread, I don't consider it
as a criti
On 3/5/19 8:30 AM, Arnd Bergmann wrote:
>
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index b24ddac1604b..290b6aca7e1d 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -723,26 +723,6 @@ static long privcmd_ioctl_restrict(struct file *file,
> void __user
On 05/03/2019 14:32, Andrii Anisov wrote:
> Hello Juergen,
>
> On 05.03.19 15:20, Juergen Gross wrote:
>> No new features for 4.12. This series will have to wait until 4.13.
>
> This is rather a complex fix for [1].
>
> [1]
> https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg02379.
On 05.03.19 15:44, Juergen Gross wrote:
On 05/03/2019 14:32, Andrii Anisov wrote:
Hello Juergen,
On 05.03.19 15:20, Juergen Gross wrote:
No new features for 4.12. This series will have to wait until 4.13.
This is rather a complex fix for [1].
[1]
https://lists.xenproject.org/archives/html
On 05/03/2019 14:26, Jan Beulich wrote:
> There are currently three more or less different checks:
> - _get_page_type() adjusts the IOMMU mappings according to the new type
> alone,
> - arch_iommu_populate_page_table() wants just the type to be
> PGT_writable_page,
> - iommu_hwdom_init() additi
On 05/03/2019 14:28, Jan Beulich wrote:
> The commit re-introducing it (14eb3b41d0 ["xen: reinstate previously
> unused XENMEM_remove_from_physmap hypercall"]) as well as the one having
> originally introduced it (d818f3cb7c ["hvm: Use main memory for video
> memory"]) and the one then purging it a
Hi,
On 3/5/19 1:14 PM, Andrii Anisov wrote:
The interface is implemented in a way vcpu_runstate_info structure is mapped to
the hypervisor on the hypercall processing and is directly accessed during its
updates.
I had some concern about this solution in [1] that have not been
addressed nor ev
On 05/03/2019 13:25, Jan Beulich wrote:
> With "pcid=no-xpti" and opposite XPTI settings in two 64-bit PV domains
> (achievable with one of "xpti=no-dom0" or "xpti=no-domu"), switching
> from a PCID-disabled to a PCID-enabled 64-bit PV domain fails to set
> CR4.PCIDE in time, as CR4.PGE would not b
Hi Juergen,
On 3/5/19 12:57 PM, Juergen Gross wrote:
On 27/02/2019 11:45, Julien Grall wrote:
(+ Juergen Gross as RM)
I forgot to CC Juergen for this.
On 2/26/19 11:03 PM, Julien Grall wrote:
After upgrading Debian to Buster, I started noticing console mangling
when using zsh. This is happen
Hello Julien,
On 05.03.19 15:39, Julien Grall wrote:
This is just an annoyance in debug build because of the number of message
printed.
It is not an annoyance, but inaccurate runstate info passed (actually not
passed) to KPTI enabled guests.
Debug build only makes the problem visible.
--
Si
On 05/03/2019 15:08, Julien Grall wrote:
> Hi Juergen,
>
> On 3/5/19 12:57 PM, Juergen Gross wrote:
>> On 27/02/2019 11:45, Julien Grall wrote:
>>> (+ Juergen Gross as RM)
>>>
>>> I forgot to CC Juergen for this.
>>>
>>> On 2/26/19 11:03 PM, Julien Grall wrote:
After upgrading Debian to Buste
Hi,
I just try to enable xen 4.12 on my one platform, but got this error. And if I
choose 4.8 version Xen.
It works, doesn't have this. If there is someone can give me some deep
debugging tip, that will be very appreciative.
Thanks
(XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
(XEN) P2M
Hi,
On 3/5/19 2:11 PM, Andrii Anisov wrote:
Hello Julien,
On 05.03.19 15:39, Julien Grall wrote:
This is just an annoyance in debug build because of the number of
message printed.
It is not an annoyance, but inaccurate runstate info passed (actually
not passed) to KPTI enabled guests.
The run
flight 133592 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133592/
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
OVMF does not build itself with -fPIC, as a result it fails to compile with
recent toolchains.
Luckily ovmf.git#master has changes for
BaseTools/Source/C/Makefiles/header.makefile to recognize EXTRA_OPTFLAGS, which
can be used as vehicle to pass the required CFLAGS.
What are the options to upgra
On 05/03/2019 14:43, Boris Ostrovsky wrote:
> On 3/5/19 8:30 AM, Arnd Bergmann wrote:
>>
>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>> index b24ddac1604b..290b6aca7e1d 100644
>> --- a/drivers/xen/privcmd.c
>> +++ b/drivers/xen/privcmd.c
>> @@ -723,26 +723,6 @@ static long privc
>>> On 05.03.19 at 14:50, wrote:
> On 05/03/2019 14:26, Jan Beulich wrote:
>> There are currently three more or less different checks:
>> - _get_page_type() adjusts the IOMMU mappings according to the new type
>> alone,
>> - arch_iommu_populate_page_table() wants just the type to be
>> PGT_wri
>>> On 05.03.19 at 14:53, wrote:
> On 05/03/2019 14:28, Jan Beulich wrote:
>> The commit re-introducing it (14eb3b41d0 ["xen: reinstate previously
>> unused XENMEM_remove_from_physmap hypercall"]) as well as the one having
>> originally introduced it (d818f3cb7c ["hvm: Use main memory for video
>>
On 05/03/2019 16:21, Jan Beulich wrote:
On 05.03.19 at 14:50, wrote:
>> On 05/03/2019 14:26, Jan Beulich wrote:
>>> There are currently three more or less different checks:
>>> - _get_page_type() adjusts the IOMMU mappings according to the new type
>>> alone,
>>> - arch_iommu_populate_page_
Hi Juergen,
On 3/5/19 2:12 PM, Juergen Gross wrote:
On 05/03/2019 15:08, Julien Grall wrote:
Hi Juergen,
On 3/5/19 12:57 PM, Juergen Gross wrote:
On 27/02/2019 11:45, Julien Grall wrote:
(+ Juergen Gross as RM)
I forgot to CC Juergen for this.
On 2/26/19 11:03 PM, Julien Grall wrote:
Afte
This library, which is private to Xen and was properly namespaced in
1a814711881beb17f073f5f57e27e5bd4da1b956
tools/libfsimage: Add `xen' to .h names and principal .so name
honours an environment variable to override the directory where
shared objects (ie filesystem plugins) are to be loaded fr
Ian Jackson writes ("[PATCH] tools/libfsimage: Add `XEN' to environment
variable name"):
> This library, which is private to Xen and was properly namespaced in
> 1a814711881beb17f073f5f57e27e5bd4da1b956
> tools/libfsimage: Add `xen' to .h names and principal .so name
> honours an environment v
On Tue, Mar 05, 2019 at 03:37:30PM +, Ian Jackson wrote:
> This library, which is private to Xen and was properly namespaced in
> 1a814711881beb17f073f5f57e27e5bd4da1b956
> tools/libfsimage: Add `xen' to .h names and principal .so name
> honours an environment variable to override the direc
On Tue, Mar 05, 2019 at 03:37:30PM +, Ian Jackson wrote:
> This library, which is private to Xen and was properly namespaced in
> 1a814711881beb17f073f5f57e27e5bd4da1b956
> tools/libfsimage: Add `xen' to .h names and principal .so name
> honours an environment variable to override the direc
This run is configured for baseline tests only.
flight 83705 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/83705/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
On 05/03/2019 16:37, Ian Jackson wrote:
> This library, which is private to Xen and was properly namespaced in
> 1a814711881beb17f073f5f57e27e5bd4da1b956
> tools/libfsimage: Add `xen' to .h names and principal .so name
> honours an environment variable to override the directory where
> shared o
Juergen Gross writes ("Re: [PATCH] tools/libfsimage: Add `XEN' to environment
variable name"):
> Release-acked-by: Juergen Gross
Thanks all, pushed.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/l
>>> 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
> - path cannot be executed repeatedly
>
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.
The conversion of the import is interesting. This definitely needs
some testing.
---
tools/pygrub/src/ExtLinuxConf.py | 16 +++
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.
3. Fix library name in AC_CHECK_LIB.
4. Remove other-libs in AC_CHECK_LIB.
Signed-off-by: Wei Liu
---
I doubt the non python-pkg branch works, because the paths
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 scripts to be
Py3 compatible".
Wei.
Wei Liu (4):
b
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/compatible_idioms.html
Tested with 2.7 and 3.5.
Signed-off-by: Wei Liu
---
I don't have environment to test 2.4 -- it is
With the help of two porting guides and cpython source code:
1. Use PyUnicode 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 remo
On 05/03/2019 16:28, Julien Grall wrote:
> Hi Juergen,
>
> On 3/5/19 2:12 PM, Juergen Gross wrote:
>> On 05/03/2019 15:08, Julien Grall wrote:
>>> Hi Juergen,
>>>
>>> On 3/5/19 12:57 PM, Juergen Gross wrote:
On 27/02/2019 11:45, Julien Grall wrote:
> (+ Juergen Gross as RM)
>
> I
>>> On 22.02.19 at 17:10, wrote:
> Since we can't seem to be able to settle our discussion for the wider
> adjustment previously posted, let's at least add the missing dependency
> for 4.12. I'm not convinced though that attaching it to SSE is correct.
>
> Signed-off-by: Jan Beulich
Andrew gave
On Tue, Mar 5, 2019 at 3:57 PM Juergen Gross wrote:
> On 05/03/2019 14:43, Boris Ostrovsky wrote:
> > On 3/5/19 8:30 AM, Arnd Bergmann wrote:
> >> @@ -809,15 +789,7 @@ static long privcmd_ioctl_mmap_resource(struct file
> >> *file, void __user *udata)
> >> goto out;
> >>
> >> i
Hi,
> The proper command is:
>
> mkimage -A arm64 -C none -T kernel -a 0x7808 -e 0x7808 -n "XEN"
> -d xen/xen xen-uImage
Yeah but it didn't boot it up :(
[ 16.991035] => setenv ipaddr 10.105.2.28;setenv serverip
10.105.2.27;ping 10.105.2.27
[ 18.791456] ravb Waiting for PHY auto nego
On 05/03/2019 17:49, Arnd Bergmann wrote:
> On Tue, Mar 5, 2019 at 3:57 PM Juergen Gross wrote:
>> On 05/03/2019 14:43, Boris Ostrovsky wrote:
>>> On 3/5/19 8:30 AM, Arnd Bergmann wrote:
>
@@ -809,15 +789,7 @@ static long privcmd_ioctl_mmap_resource(struct file
*file, void __user *udat
Hi Juergen,
On 3/5/19 4:44 PM, Juergen Gross wrote:
On 05/03/2019 16:28, Julien Grall wrote:
Hi Juergen,
On 3/5/19 2:12 PM, Juergen Gross wrote:
On 05/03/2019 15:08, Julien Grall wrote:
Hi Juergen,
On 3/5/19 12:57 PM, Juergen Gross wrote:
On 27/02/2019 11:45, Julien Grall wrote:
(+ Juerge
On 05/03/2019 17:46, Jan Beulich wrote:
On 22.02.19 at 17:10, wrote:
>> Since we can't seem to be able to settle our discussion for the wider
>> adjustment previously posted, let's at least add the missing dependency
>> for 4.12. I'm not convinced though that attaching it to SSE is correct.
>
On Mon, Mar 04, 2019 at 04:59:42PM +, David Woodhouse wrote:
> On Mon, 2019-03-04 at 15:46 +, Wei Liu wrote:
[...]
> > Also you mentioned "a node disappears", I thought that was the case you
> > cared about, hence my suggestion.
>
> That's my primary use case, yes. Obviously we should make
On 05/03/2019 18:02, Wei Liu wrote:
> On Mon, Mar 04, 2019 at 04:59:42PM +, David Woodhouse wrote:
>> On Mon, 2019-03-04 at 15:46 +, Wei Liu wrote:
> [...]
>>> Also you mentioned "a node disappears", I thought that was the case you
>>> cared about, hence my suggestion.
>>
>> That's my prima
On Wed, Feb 27, 2019 at 06:23:35PM +, Woods, Brian wrote:
> On 2/27/19 7:47 AM, Wei Liu wrote:
> > On Mon, Feb 25, 2019 at 08:23:58PM +, Woods, Brian wrote:
> >> Some AMD processors can use a mixture of mwait and halt for accessing
> >> various c-states. In preparation for adding support f
On Tue, Mar 05, 2019 at 06:09:27PM +0100, Juergen Gross wrote:
> On 05/03/2019 18:02, Wei Liu wrote:
> > On Mon, Mar 04, 2019 at 04:59:42PM +, David Woodhouse wrote:
> >> On Mon, 2019-03-04 at 15:46 +, Wei Liu wrote:
> > [...]
> >>> Also you mentioned "a node disappears", I thought that was
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/compatible_idioms.html
>
> Tested with 2.7 and 3.5.
>
> Signed-off-by: Wei Liu
On 05/03/2019 16:42, Wei Liu wrote:
> With the help of two porting guides and cpython source code:
>
> 1. Use PyUnicode 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 initia
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 source code:
> >
> > 1. Use PyUnicode to replace PyString counterparts.
> > 2. Use PyVarObject_HEAD_INIT and provide compatibility for 2.5 and
> >
flight 133577 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133577/
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-amd64-xl-
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.
>
> The conversion of the import is interesting. This definitely needs
> some test
On 05.03.19 18:50, Amit Tomer wrote:
Hi,
Hi, Amit
The proper command is:
mkimage -A arm64 -C none -T kernel -a 0x7808 -e 0x7808 -n "XEN"
-d xen/xen xen-uImage
Yeah but it didn't boot it up :(
Have you tried to enable early_prink?
AFAIR, I tested that branch (ipmmu_v2) before
Hi,
> Have you tried to enable early_prink?
Yes, this is how we compiled it.
make dist-xen XEN_TARGET_ARCH=arm64 debug=y
CROSS_COMPILE=aarch64-linux-gnu-
CONFIG_EARLY_PRINTK_salvator=scif,0xe6e88000 -j16
> AFAIR, I tested that branch (ipmmu_v2) before submitting RFC patch
> series [1] and it was
flight 133578 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133578/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs.
132889
test-am
1 - 100 of 125 matches
Mail list logo
