On 19/12/2018 07:00, David Miller wrote:
> From: Juergen Gross
> Date: Tue, 18 Dec 2018 16:06:19 +0100
>
>> At least old Xen net backends seem to send frags with no real data
>> sometimes. In case such a fragment happens to occur with the frag limit
>> already reached the frontend will BUG curren
From: Juergen Gross
Date: Tue, 18 Dec 2018 16:06:19 +0100
> At least old Xen net backends seem to send frags with no real data
> sometimes. In case such a fragment happens to occur with the frag limit
> already reached the frontend will BUG currently even if this situation
> is easily recoverable
Hello Oleksandr,
Please find the attached log file.
Could please provide some pointers on how test DomU display.
On Tue, Dec 18, 2018 at 12:06 PM Oleksandr Andrushchenko
wrote:
Hello, Vikram!
> * We are using 64 bit arm platform.
> * Linux 4.20 Kernel in DomU with PV DRM front-end drivers.
On Tue, Dec 18, 2018 at 08:53:46AM -0700, Jan Beulich wrote:
On 18.12.18 at 15:43, wrote:
>> I find some pass-thru devices don't work any more across guest
>> reboot. Assigning it to another domain also meets the same issue. And
>> the only way to make it work again is un-binding and binding
On 12/18/18 9:45 PM, Martin K. Petersen wrote:
If you haven't received feedback on a patch you should poke the relevant
driver maintainer.
Got it. Will do so.
Thanks
--
Gustavo
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://li
Hi Gustavo,
> Only 8 out the 41 patches in this series have been applied so far.
I applied the patches that got acked or reviewed by their respective
driver maintainers.
If you haven't received feedback on a patch you should poke the relevant
driver maintainer.
--
Martin K. Petersen Orac
flight 131436 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131436/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 131387 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131387/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs.
131276
test-amd64-amd64
From: "Edgar E. Iglesias"
Introduce platform_smc as a way to handle firmware calls that Xen does
not know about in a platform specific way. This is particularly useful
for implementing the SiP (SoC implementation specific) service calls.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano S
From: "Edgar E. Iglesias"
Stop blacklisting ZynqMP's power management node. It is now possible
since we allow the hardware domain to issue HVC/SMC calls to firmware.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
Reviewed-by: Stefano Stabellini
Acked-by: Julien Grall
---
Hi all,
Only minor changes in this patch, mainly:
- code style
- move PM_GET_TRUSTZONE_VERSION to enum
- remove ZYNQMP_SIP_SVC_*
- add acked-by
Cheers,
Stefano
The following changes since commit 82855aba5bf91e50c81526167c11d4aeaf665e66:
tools/libxc: Fix error handling in get_cpuid_domain_i
ZynqMP IPI mailbox calls are a small set of EEMI sister calls, often
used in conjunction with EEMI related functionalities.
Unfortunately they are not part of the EEMI spec, or any other public
spec, but the implementation is upstream in ATF:
https://github.com/ARM-software/arm-trusted-firmware/b
From: "Edgar E. Iglesias"
Introduce zynqmp_eemi: a function responsible for implementing access
controls over the firmware calls. Only calls that are allowed are
forwarded to the firmware.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes i
From: "Edgar E. Iglesias"
zynqmp_eemi uses the defined functions and structs to decide whether to
make a call to the firmware, or to simply return a predefined value.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
---
Changes in v8:
- remove redundant ZYNQMP_SIP_SVC_* cases
From: "Edgar E. Iglesias"
Introduce zynqmp specific defines for the firmware calls.
See EEMI:
https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
The error codes are described, under XIlPM Error Codes:
https://www.xilinx.com/support/documentation/user_guides/ug1137-zynq-
flight 131399 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131399/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 131358
test-armhf-armhf-libvirt 14 sav
flight 131434 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131434/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Tue, 18 Dec 2018, Stefano Stabellini wrote:
> On Tue, 18 Dec 2018, Julien Grall wrote:
> > At the moment, Xen is relocated towards the end of the memory. While
> > this has the advantage to free space in low memory, the code is not
> > compliant with the break-before-make because it requires to
On Tue, 18 Dec 2018, Julien Grall wrote:
> At the moment, Xen is relocated towards the end of the memory. While
> this has the advantage to free space in low memory, the code is not
> compliant with the break-before-make because it requires to switch
> between two sets of page-table. This is not en
Hello,
I tried updating my NetBSD dom0 to 4.11.1 (from 4.11.0 with security patches),
and on a 32bits PV domU shutdown I get (100% reproductible):
(XEN) Assertion 'preemptible' failed at mm.c:2493
(XEN) [ Xen-4.11.1nb0 x86_64 debug=y Tainted: C ]
On Tue, 18 Dec 2018, Julien Grall wrote:
> Hi,
>
> On 12/17/18 10:10 PM, Stefano Stabellini wrote:
> > +/* These calls are safe and always allowed. */
> > +case EEMI_FID(ZYNQMP_SIP_SVC_CALL_COUNT):
> > +case EEMI_FID(ZYNQMP_SIP_SVC_UID):
> > +case EEMI_FID(ZYNQMP_SIP_SVC_VERSION):
On Tue, 18 Dec 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 12/17/18 10:10 PM, Stefano Stabellini wrote:
> > +/* These calls are safe and always allowed. */
> > +case EEMI_FID(ZYNQMP_SIP_SVC_CALL_COUNT):
> > +case EEMI_FID(ZYNQMP_SIP_SVC_UID):
> > +case EEMI_FID(ZYNQMP_SIP_SVC_V
On Tue, 18 Dec 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 12/17/18 10:10 PM, Stefano Stabellini wrote:
> > From: "Edgar E. Iglesias"
> >
> > From: Edgar E. Iglesias
> >
> > Introduce zynqmp specific defines for the firmware calls.
> > See EEMI:
> > https://www.xilinx.com/support/documentat
I committed the series
On Tue, 18 Dec 2018, Julien Grall wrote:
> Hi all,
>
> This is version 3 of the series to implement set/way. For more details see
> patch #3.
>
> Cheers,
>
> Julien Grall (4):
> xen/arm: vcpreg: Add wrappers to handle co-proc access trapped by
> HCR_EL2.TVM
> xen/
On Tue, 18 Dec 2018, Julien Grall wrote:
> Set/Way operations are used to perform maintenance on a given cache.
> At the moment, Set/Way operations are not trapped and therefore a guest
> OS will directly act on the local cache. However, a vCPU may migrate to
> another pCPU in the middle of the pro
On Tue, Dec 18, 2018 at 12:35:34PM -0500, Boris Ostrovsky wrote:
> On 12/18/18 6:28 AM, Andrew Cooper wrote:
> > On 18/12/2018 10:42, YueHaibing wrote:
> >> On 2018/12/18 16:31, Juergen Gross wrote:
> >>> On 18/12/2018 09:19, YueHaibing wrote:
> Fix smatch warning:
>
> arch/x86/xen/e
From: Volodymyr Babchuk
Shared memory is widely used by NW to communicate with
TAs in OP-TEE. NW can share part of own memory with
TA or OP-TEE core, by registering it OP-TEE, or by providing
a temporal reference. Anyways, information about such memory
buffers are sent to OP-TEE as a list of page
From: Volodymyr Babchuk
Add very basic OP-TEE mediator. It can probe for OP-TEE presence,
tell it about domain creation/destruction and forward all known
calls.
This is all what is needed for Dom0 to work with OP-TEE as long
as Dom0 shares 1:1 mapped pages with OP-TEE. Any attempt to call
OP-TEE
From: Volodymyr Babchuk
Some fast SMCCC calls to OP-TEE should be handled in a special way.
Capabilities exchange should be filtered out, so only caps
known to mediator are used. Also mediator disables static SHM
memory capability, because it can't share OP-TEE memory with a domain.
Only domain c
From: Volodymyr Babchuk
This flag enables TEE support for a domain.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/domain.c | 4
xen/arch/arm/domctl.c | 1 +
xen/include/public/arch-arm.h | 3 +++
3 files changed, 8 insertions(+)
diff --git a/xen/arch/arm/domain.c b/xe
From: Volodymyr Babchuk
OP-TEE usually uses the same idea with command buffers (see
previous commit) to issue RPC requests. Problem is that initially
it has no buffer, where it can write request. So the first RPC
request it makes is special: it requests NW to allocate shared
buffer for other RPC
From: Volodymyr Babchuk
The main way to communicate with OP-TEE is to issue standard SMCCC
call. "Standard" is a SMCCC term and it means that call can be
interrupted and OP-TEE can return control to NW before completing
the call.
In contrast with fast calls, where arguments and return values
are
From: Volodymyr Babchuk
If TEE support is enabled with "tee=1" option in xl.cfg,
then we need to inform guest about available TEE.
Currently only OP-TEE is supported, so we'll create DT
node in a way that is expected by optee driver in linux.
Signed-off-by: Volodymyr Babchuk
---
tools/libxl/l
From: Volodymyr Babchuk
This boolean option controls if TEE access is enabled for the domain.
If access is enabled, xl will set appropriate flag in architecture
configuration to ask hypervisor to enable TEE support.
Signed-off-by: Volodymyr Babchuk
---
Changes from v2:
- Use arch.tee_enabled
From: Volodymyr Babchuk
OP-TEE can issue multiple RPC requests. We are interested mostly in
request that asks NW to allocate/free shared memory for OP-TEE
needs, because mediator need to do address translation in the same
way as it was done for shared buffers registered by NW.
As mediator now ac
From: Volodymyr Babchuk
Hello all,
Sorry for late submussion. I was busy with other projects.
Global changes from v2:
- Use domain flags insted of domctl interface to enable optee for guests
- Remove patch "libxc: add xc_dom_tee_enable(...) function" because
of previous change
- Mediator
This patch adds basic framework for TEE mediators. Guests can't talk
to TEE directly, we need some entity that will intercept request
and decide what to do with them. "TEE mediator" is a such entity.
This is how it works: user can build XEN with multiple TEE mediators
(see the next patches, where
This header files describe protocol between OP-TEE and OP-TEE client
driver in Linux. They are needed for upcoming OP-TEE mediator, which
is added in the next patch.
Reason to add those headers in separate patch is to ease up review.
Those files were taken from linux tree (drivers/tee/optee/) and m
flight 131431 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131431/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
Den 27.11.2018 11.32, skrev Oleksandr Andrushchenko:
From: Oleksandr Andrushchenko
When GEM backing storage is allocated with drm_gem_get_pages
the backing pages may be cached, thus making it possible that
the backend sees only partial content of the buffer which may
lead to screen artifacts.
On 12/18/18 20:31, Boris Ostrovsky wrote:
On 12/18/18 11:15 AM, Noralf Trønnes wrote:
Den 30.11.2018 08.42, skrev Oleksandr Andrushchenko:
From: Oleksandr Andrushchenko
Use page directory based shared buffer implementation
now available as common code for Xen frontend drivers.
Remove flushi
Thomas Huth writes:
> The last user of blk_attach_dev_legacy() is the code in xen_disk.c.
> It passes a pointer to a XenBlkDev as second parameter. XenBlkDev
> is derived from XenDevice which in turn is derived from DeviceState
> since commit 3a6c9172ac5951e ("xen: create qdev for each backend de
On 12/18/18 11:15 AM, Noralf Trønnes wrote:
>
> Den 30.11.2018 08.42, skrev Oleksandr Andrushchenko:
>> From: Oleksandr Andrushchenko
>>
>> Use page directory based shared buffer implementation
>> now available as common code for Xen frontend drivers.
>>
>> Remove flushing of shared buffer on page
flight 131392 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131392/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 131364
test-armhf-armhf-libvirt 14 saveresto
At the moment, the implementation of Set/Way operations will go through
all the entries of the guest P2M and flush them. However, this is very
expensive and may render unusable a guest OS using them.
For instance, Linux 32-bit will use Set/Way operations during secondary
CPU bring-up. As the imple
A follow-up patch will require to emulate some accesses to system
registers trapped by HCR_EL2.TVM. When set, all NS EL1 writes to the
virtual memory control registers will be trapped to the hypervisor.
This patch adds the infrastructure to passthrough the access to the host
registers.
Note that
Set/Way operations are used to perform maintenance on a given cache.
At the moment, Set/Way operations are not trapped and therefore a guest
OS will directly act on the local cache. However, a vCPU may migrate to
another pCPU in the middle of the processor. This will result to have
cache with stale
A follow-up patch will require to emulate some accesses to some
co-processors registers trapped by HCR_EL2.TVM. When set, all NS EL1 writes
to the virtual memory control registers will be trapped to the hypervisor.
This patch adds the infrastructure to passthrough the access to host
registers. For
Hi all,
This is version 3 of the series to implement set/way. For more details see
patch #3.
Cheers,
Julien Grall (4):
xen/arm: vcpreg: Add wrappers to handle co-proc access trapped by
HCR_EL2.TVM
xen/arm: vsysreg: Add wrapper to handle sysreg access trapped by
HCR_EL2.TVM
xen/arm:
Hi Andrew,
On 12/14/18 9:31 PM, Andrew Cooper wrote:
On 14/12/2018 03:58, Julien Grall wrote:
Set/Way operations are used to perform maintenance on a given cache.
At the moment, Set/Way operations are not trapped and therefore a guest
OS will directly act on the local cache. However, a vCPU may
Hi Stefano,
On 12/14/18 9:27 PM, Stefano Stabellini wrote:
On Fri, 14 Dec 2018, Julien Grall wrote:
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 17e2523fc1..5639e4b64c 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1524,13 +1524,17 @@ int relinquish_p2m_mapping(struc
On 12/18/18 6:28 AM, Andrew Cooper wrote:
> On 18/12/2018 10:42, YueHaibing wrote:
>> On 2018/12/18 16:31, Juergen Gross wrote:
>>> On 18/12/2018 09:19, YueHaibing wrote:
Fix smatch warning:
arch/x86/xen/enlighten_pv.c:649 get_trap_addr() error:
buffer overflow 'early_idt_handl
flight 131414 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131414/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
flight 131428 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131428/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 131386 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131386/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail
REGR. vs. 131317
test-
Den 30.11.2018 08.42, skrev Oleksandr Andrushchenko:
From: Oleksandr Andrushchenko
Use page directory based shared buffer implementation
now available as common code for Xen frontend drivers.
Remove flushing of shared buffer on page flip as this
workaround needs a proper fix.
Signed-off-by:
Hi,
On 12/17/18 10:10 PM, Stefano Stabellini wrote:
+/* These calls are safe and always allowed. */
+case EEMI_FID(ZYNQMP_SIP_SVC_CALL_COUNT):
+case EEMI_FID(ZYNQMP_SIP_SVC_UID):
+case EEMI_FID(ZYNQMP_SIP_SVC_VERSION):
+case EEMI_FID(PM_GET_TRUSTZONE_VERSION):
+case EEMI
The last user of blk_attach_dev_legacy() is the code in xen_disk.c.
It passes a pointer to a XenBlkDev as second parameter. XenBlkDev
is derived from XenDevice which in turn is derived from DeviceState
since commit 3a6c9172ac5951e ("xen: create qdev for each backend device").
Thus the code can also
Hello,
The following series attempts to fix a mm lock level issue that prevents
using paging_log_dirty_op from paging callers (like a PVH Dom0). The
discussion that lead to this series can be found at:
https://lists.xenproject.org/archives/html/xen-devel/2018-12/msg01197.html
Thanks, Roger.
Rog
paging_log_dirty_op function takes mm locks from a subject domain and
then attempts to perform copy to operations against the caller
domain in order to copy the result of the hypercall into the caller
provided buffer.
This works fine when the caller is a non-paging domain, but triggers a
lock orde
No functional change.
Signed-off-by: Roger Pau Monné
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xen/arch/x86/mm/mm-locks.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/
And rename to have only one prefix underscore where applicable.
No functional change.
Signed-off-by: Roger Pau Monné
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xen/arch/x86/mm/mm-locks.h | 96 --
1 file changed, 51 insertions(
Hi Stefano,
On 12/17/18 10:10 PM, Stefano Stabellini wrote:
ZynqMP IPI mailbox calls are a small set of EEMI sister calls, often
used in conjunction with EEMI related functionalities.
Unfortunately they are not part of the EEMI spec, or any other public
spec, but the implementation is upstream
Hi Stefano,
On 12/17/18 10:10 PM, Stefano Stabellini wrote:
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Stop blacklisting ZynqMP's power management node. It is now possible
since we allow the hardware domain to issue HVC/SMC calls to firmware.
Signed-off-by: Edgar E. Iglesias
Signed-
Hi Stefano,
On 12/17/18 10:10 PM, Stefano Stabellini wrote:
+/* These calls are safe and always allowed. */
+case EEMI_FID(ZYNQMP_SIP_SVC_CALL_COUNT):
+case EEMI_FID(ZYNQMP_SIP_SVC_UID):
+case EEMI_FID(ZYNQMP_SIP_SVC_VERSION):
I am a bit surprised that you implement those one
>>> On 18.12.18 at 15:43, wrote:
> I find some pass-thru devices don't work any more across guest
> reboot. Assigning it to another domain also meets the same issue. And
> the only way to make it work again is un-binding and binding it to
> pciback. Someone reported this issue one year ago [1].
>
Hi Stefano,
On 12/17/18 10:10 PM, Stefano Stabellini wrote:
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce zynqmp specific defines for the firmware calls.
See EEMI:
https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
The error codes are described, under
Hi Stefano,
On 12/17/18 10:10 PM, Stefano Stabellini wrote:
diff --git a/xen/arch/arm/platforms/xilinx-zynqmp.c
b/xen/arch/arm/platforms/xilinx-zynqmp.c
index d8ceded..8bc7a9f 100644
--- a/xen/arch/arm/platforms/xilinx-zynqmp.c
+++ b/xen/arch/arm/platforms/xilinx-zynqmp.c
@@ -18,6 +18,8 @@
*
On 12/18/2018 11:13 PM, Roger Pau Monné wrote:
> On Tue, Dec 18, 2018 at 07:31:59PM +0800, Dongli Zhang wrote:
>> Hi Roger,
>>
>> On 12/18/2018 05:33 PM, Roger Pau Monné wrote:
>>> On Tue, Dec 18, 2018 at 08:55:38AM +0800, Dongli Zhang wrote:
The xenstore 'ring-page-order' is used globally f
Andrew Cooper writes ("[Xen-devel] [PATCH v2 6/5] tools/docs: Remove PVRDTSCP
remnants"):
> PVRDTSCP is believed-unused, and its implementation has adverse consequences
> on unrelated functionality in the hypervisor. As a result, support has been
> removed.
Acked-by: Ian Jackson
__
Hi Martin,
Friendly ping:
Only 8 out the 41 patches in this series have been applied so far.
I wonder if you could apply the rest of this series, except:
[PATCH 02/41] scsi: NCR5380: Mark expected switch fall-through
(I'll send a v2 of this patch)
Thanks
--
Gustavo
On 11/27/18 10:18 PM, Gu
>>> On 18.12.18 at 15:28, wrote:
> On 10/12/2018 13:56, Jan Beulich wrote:
> On 10.12.18 at 14:20, wrote:
>>> On 10/12/2018 11:32, Jan Beulich wrote:
The avx512_vlen_check() invocation needs to be conditional.
Signed-off-by: Jan Beulich
>>> I'm not sure if I've asked before, b
On Tue, Dec 18, 2018 at 07:31:59PM +0800, Dongli Zhang wrote:
> Hi Roger,
>
> On 12/18/2018 05:33 PM, Roger Pau Monné wrote:
> > On Tue, Dec 18, 2018 at 08:55:38AM +0800, Dongli Zhang wrote:
> >> The xenstore 'ring-page-order' is used globally for each blkback queue and
> >> therefore should be re
Allow altp2m users to disable #VE/VMFUNC alone. Currently it is
only possible to disable this functionality when we disable altp2m
completely; #VE/VMFUNC can only be enabled once per altp2m session.
In addition to making things complete, disabling #VE is also a
workaround for CFW116 ("When Virtual
George Dunlap writes ("Re: [PATCH v2 05/10] libxl: Do root checks once in
libxl__domain_get_device_model_uid"):
> On Dec 12, 2018, at 3:45 PM, Ian Jackson wrote:
> >> +/*
> >> + * If dm_restrict isn't set, and we don't have a specified user, don't
> >> + * bother setting a `-runas` pa
At least old Xen net backends seem to send frags with no real data
sometimes. In case such a fragment happens to occur with the frag limit
already reached the frontend will BUG currently even if this situation
is easily recoverable.
Modify the BUG_ON() condition accordingly.
Cc: sta...@vger.kerne
On 18.12.18 15:07, Julien Grall wrote:
At the moment, Xen is relocated towards the end of the memory. While
this has the advantage to free space in low memory, the code is not
compliant with the break-before-make because it requires to switch
between two sets of page-table. This is not entirely
On 12/18/18 4:54 PM, Razvan Cojocaru wrote:
> Allow altp2m users to disable #VE/VMFUNC alone. Currently it is
> only possible to disable this functionality when we disable altp2m
> completely; #VE/VMFUNC can only be enabled once per altp2m session.
>
> In addition to making things complete, disabl
Allow altp2m users to disable #VE/VMFUNC alone. Currently it is
only possible to disable this functionality when we disable altp2m
completely; #VE/VMFUNC can only be enabled once per altp2m session.
In addition to making things complete, disabling #VE is also a
workaround for CFW116 ("When Virtual
I find some pass-thru devices don't work any more across guest
reboot. Assigning it to another domain also meets the same issue. And
the only way to make it work again is un-binding and binding it to
pciback. Someone reported this issue one year ago [1].
If the device's driver doesn't disable MSI-
When I destroyed a guest with 'xl destroy', I found the warning
in msi_set_mask_bit() in Xen was triggered. After adding "WARN_ON(1)"
to that place, I got the call trace below:
(XEN) Xen call trace:
(XEN)[] msi.c#msi_set_mask_bit+0x1da/0x29b
(XEN)[] guest_mask_msi_irq+0x1c/0x1e
(XEN)[]
On 10/12/2018 13:56, Jan Beulich wrote:
On 10.12.18 at 14:20, wrote:
>> On 10/12/2018 11:32, Jan Beulich wrote:
>>> The avx512_vlen_check() invocation needs to be conditional.
>>>
>>> Signed-off-by: Jan Beulich
>> I'm not sure if I've asked before, but do LIG instructions really #UD
>> for L
On 12/18/18 4:10 PM, Jan Beulich wrote:
On 14.12.18 at 18:17, wrote:
>> Allow altp2m users to disable #VE/VMFUNC alone. Currently it is
>> only possible to disable this functionality when we disable altp2m
>> completely; #VE/VMFUNC can only be enabled once per altp2m session.
>>
>> In additio
>>> On 14.12.18 at 18:17, wrote:
> Allow altp2m users to disable #VE/VMFUNC alone. Currently it is
> only possible to disable this functionality when we disable altp2m
> completely; #VE/VMFUNC can only be enabled once per altp2m session.
>
> In addition to making things complete, disabling #VE is
On 11/12/2018 08:47, Jan Beulich wrote:
> In commit efe9cba66c ("x86emul: VME and PVI modes require a #GP(0) check
> first thing") I neglected the fact that the retire flags get zapped only
> in x86_decode(), which hasn't been invoked yet at the point of the #GP(0)
> check added. Move output state
On 11/12/2018 08:48, Jan Beulich wrote:
> The check needs to happen whenever EVEX.b (SDM nomenclature) is clear,
> not just in the memory operand case.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Clarify naming (to address apparent disconnect between description
> and code change).
Thanks - th
On 11/12/2018 08:50, Jan Beulich wrote:
> There are a number of exception condition related errata on SandyBridge
> CPUs, some of which are unexpected #UD (others, of no interest here, are
> lack of mandated exceptions, or exceptions of unexpected type). Annotate
> the one workaround we already hav
On 12/18/18 12:09 PM, Andrii Anisov wrote:
Hello Julien,
Hi,
On 17.12.18 19:34, Andrii Anisov wrote:
I see something like following as a quick WA (not even build tested):
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d2c63a8..bf72ba9 100644
--- a/xen/arch/ar
At the moment, Xen is relocated towards the end of the memory. While
this has the advantage to free space in low memory, the code is not
compliant with the break-before-make because it requires to switch
between two sets of page-table. This is not entirely trivial to fix as
it would require us to g
Hello Julien,
On 17.12.18 19:34, Andrii Anisov wrote:
I see something like following as a quick WA (not even build tested):
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d2c63a8..bf72ba9 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@
On 18/12/2018 11:29, Jan Beulich wrote:
> While commit 75066cd4ea ("x86emul: fix {,i}mul and {,i}div") indeed did
> as its title says, it broke the 3-operand form by uniformly using AL/AX/
> EAX/RAX as second source operand. Fix this and add tests covering both
> cases.
>
> Reported-by: Andrei Luta
On 12/18/18 1:29 PM, Jan Beulich wrote:
> While commit 75066cd4ea ("x86emul: fix {,i}mul and {,i}div") indeed did
> as its title says, it broke the 3-operand form by uniformly using AL/AX/
> EAX/RAX as second source operand. Fix this and add tests covering both
> cases.
>
> Reported-by: Andrei Lut
flight 131385 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131385/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 17 guest-start.2fail REGR. vs. 131318
Tests which did not
On 18/12/2018 11:37, Jan Beulich wrote:
On 18.12.18 at 10:56, wrote:
>> On 18/12/2018 02:17, Tian, Kevin wrote:
From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
Sent: Monday, December 17, 2018 10:21 PM
On 17/12/2018 13:09, Andrew Cooper wrote:
> On 17/12/2018 02:
>>> On 18.12.18 at 10:56, wrote:
> On 18/12/2018 02:17, Tian, Kevin wrote:
>>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>>> Sent: Monday, December 17, 2018 10:21 PM
>>>
>>> On 17/12/2018 13:09, Andrew Cooper wrote:
On 17/12/2018 02:39, Tian, Kevin wrote:
After some inve
Hi Roger,
On 12/18/2018 05:33 PM, Roger Pau Monné wrote:
> On Tue, Dec 18, 2018 at 08:55:38AM +0800, Dongli Zhang wrote:
>> The xenstore 'ring-page-order' is used globally for each blkback queue and
>> therefore should be read from xenstore only once. However, it is obtained
>> in read_per_ring_re
While commit 75066cd4ea ("x86emul: fix {,i}mul and {,i}div") indeed did
as its title says, it broke the 3-operand form by uniformly using AL/AX/
EAX/RAX as second source operand. Fix this and add tests covering both
cases.
Reported-by: Andrei Lutas
Signed-off-by: Jan Beulich
--- a/tools/tests/x
On 18/12/2018 10:42, YueHaibing wrote:
> On 2018/12/18 16:31, Juergen Gross wrote:
>> On 18/12/2018 09:19, YueHaibing wrote:
>>> Fix smatch warning:
>>>
>>> arch/x86/xen/enlighten_pv.c:649 get_trap_addr() error:
>>> buffer overflow 'early_idt_handler_array' 32 <= 32
>>>
>>> Fixes: 42b3a4cb5609 ("x
George Dunlap writes ("Re: [PATCH v2 08/10] libxl: Kill QEMU by uid when
possible"):
> On 12/12/18 4:17 PM, Ian Jackson wrote:
> > I am tempted to suggest replacing each call
> > PROPAGATE_RC;
> > with
> > ACCUMULATE_RC(ddms);
> > and put the definition in libxl_internal.h for use elsewhere.
>
On 2018/12/18 16:31, Juergen Gross wrote:
> On 18/12/2018 09:19, YueHaibing wrote:
>> Fix smatch warning:
>>
>> arch/x86/xen/enlighten_pv.c:649 get_trap_addr() error:
>> buffer overflow 'early_idt_handler_array' 32 <= 32
>>
>> Fixes: 42b3a4cb5609 ("x86/xen: Support early interrupts in xen pv guest
1 - 100 of 107 matches
Mail list logo
