>>> 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 this change without the description supplying
both a reas
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 backport it
to stable linux with more detailed explanation how the issue is
flight 133589 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133589/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133576
test-armhf-armhf-libvirt 14 sav
flight 133584 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133584/
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
Regressions
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 more robust by reading a negotiation
variable only once and not twic
flight 133607 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133607/
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
flight 133583 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133583/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133573
test-amd64-amd64-xl-qemuu-win7-amd64
Sorry for the formatting.
On Tue, 5 Mar 2019, 21:24 Stefano Stabellini,
wrote:
> On Sun, 3 Mar 2019, Amit Tomer wrote:
> > Hi,
> >
> > > This series introduces a cacheability parameter for the iomem option,
> so
> > > that we can map an iomem region into a guest as cacheable memory.
> > >
> > >
Use DECLARE_BOUNDS and the two static inline functions that come with it
for comparisons and subtractions of:
__note_gnu_build_id_start, __note_gnu_build_id_end,
__lock_profile_start, __lock_profile_end, __initcall_start,
__initcall_end, __presmp_initcall_end, __ctors_start, __ctors_end,
__end_sch
Use DECLARE_BOUNDS and the two static inline functions that come with it
for comparisons and subtractions of:
__init_begin, __init_end, __per_cpu_start, __per_cpu_data_end,
_splatform, _eplatform, _sdevice, _edevice, _asdevice, _aedevice.
M3CM: Rule-18.2: Subtraction between pointers shall only b
Use DECLARE_BOUNDS and the two static inline functions that come with it
for comparisons and subtractions of:
_start, _end, _stext, _etext, _srodata, _erodata, _sinittext,
_einittext
Use explicit casts to uintptr_t when it is not possible to use the
provided static inline functions.
M3CM: Rule-1
Sometimes the static inline functions provided by DECLARE_BOUNDS cannot
be used. This patch uses explicit casts to uintptr_t in those cases.
M3CM: Rule-18.2: Subtraction between pointers shall only be applied to
pointers that address elements of the same array
https://wiki.sei.cmu.edu/confluence/
Hi all,
This version of the series makes use of the macro suggested by Jan with
few modifications. See each patch for a description of the changes.
The following changes since commit 808cff4c2af66afd61973451aeb7e708732abf90:
sched/credit2: remove stale comment (2019-01-09 15:46:05 +0100)
are
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
CC: jbeul...@suse.com
CC: andrew.coop...@citrix.com
CC: julien.gr...@arm.com
CC: george.dun...@eu.citrix.com
CC: ian.jack...@e
Introduce the new type "ptrdiff_t" which is defined as the signed
integer type of the result of subtracting two pointers. Use
__PTRDIFF_TYPE__ to define it.
Signed-off-by: Stefano Stabellini
Reviewed-by: Ian Jackson
CC: jbeul...@suse.com
CC: andrew.coop...@citrix.com
CC: julien.gr...@arm.com
CC:
Introduce a MACRO to be used to declare array variables corresponding to
linker symbols, plus two static inline functions to be used for
comparing and subtracting pointers with the linker symbols.
Note that the start and end symbols are declared of different types to
help avoid errors and misusing
Use DECLARE_BOUNDS and the two static inline functions that come with it
for comparisons and subtractions of:
__alt_instructions, __alt_instructions_end
M3CM: Rule-18.2: Subtraction between pointers shall only be applied to
pointers that address elements of the same array
https://wiki.sei.cmu.ed
Use DECLARE_BOUNDS and the two static inline functions that come with it
for comparisons and subtractions of:
__2M_rwdata_start, __2M_rwdata_end, __end_vpci_array,
__start_vpci_array, _stextentry, _etextentry, __trampoline_rel_start,
__trampoline_rel_stop, __trampoline_seg_start, __trampoline_seg_
On Sun, 3 Mar 2019, Amit Tomer wrote:
> Hi,
>
> > This series introduces a cacheability parameter for the iomem option, so
> > that we can map an iomem region into a guest as cacheable memory.
> >
> > Then, this series fixes the way Xen handles reserved memory regions on
> > ARM: they should be ma
flight 133604 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133604/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 133599
Tests which
flight 133582 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133582/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 133512
test-armhf-armhf-libvirt 14 saveresto
flight 133580 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133580/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat
fail like 133555
test-amd64-amd64-xl-qe
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 source code:
> > >
> > > 1. Use PyUnicode to replace PyString counterparts.
> > > 2
On 05.03.19 20:10, Amit Tomer wrote:
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
No, "CONFIG_EARLY_PRINTK_salvator=scif,0xe6e88000" i
flight 133599 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133599/
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
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
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
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
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 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:
> 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 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 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 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 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 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 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.
>
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: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,
> 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 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
>>> 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 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
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
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
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
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
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 +++
>>> 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
>
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 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
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 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
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
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
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
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_
>>> 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.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/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
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
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
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
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
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
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
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
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,
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 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
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.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: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 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 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
> 在 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 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
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.
__
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.
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
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
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
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
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(),
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
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
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
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
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
>>
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 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
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 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
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 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 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
-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
=
1 - 100 of 125 matches
Mail list logo
