Add a new function to query whether hypercall buffers are always safe
to access by the hypervisor or might result in EFAULT.
Signed-off-by: Juergen Gross
Acked-by: Ian Jackson
---
tools/libs/call/Makefile | 2 +-
tools/libs/call/freebsd.c | 5 +
tools/libs/call/include/xenc
On Linux systems hypercall buffers in user memory are allocated with
MAP_LOCKED attribute. Unfortunately that doesn't mean that the buffer
will always be accessible by the hypervisor, as the kernel might set
the PTE for the buffer to invalid or read only for short periods of
time, e.g. due to page
Instead of using anonymous memory for hypercall buffers which is then
locked into memory, use the hypercall buffer device of the Linux
privcmd driver if available.
This has the advantage of needing just a single mmap() for allocating
the buffer and page migration or compaction can't make the buffe
A hypercall issued via the privcmd driver can very rarely return
-EFAULT even if the hypercall buffers are locked in memory. This
happens for hypercall buffers in user memory when the Linux kernel
is doing memory scans e.g. for page migration or compaction.
Retry the getpageframeinfo3 hypercall up
For passing arbitrary data from user land to the Xen hypervisor the
Xen tools today are using mlock()ed buffers. Unfortunately the kernel
might change access rights of such buffers for brief periods of time
e.g. for page migration or compaction, leading to access faults in the
hypervisor, as the hy
On 18/06/18 15:36, Juergen Gross wrote:
> +static int privcmd_buf_mmap(struct file *file, struct vm_area_struct *vma)
> +{
> + struct privcmd_buf_private *file_priv = file->private_data;
> + struct privcmd_buf_vma_private *vma_priv;
> + unsigned long count = vma_pages(vma);
> + unsi
4.16-stable review patch. If anyone has any objections, please let me know.
--
From: "van der Linden, Frank"
[ Upstream commit d1ecfa9d1f402366b1776fbf84e635678a51414f ]
This patch fixes crashes during boot for HVM guests on older (pre HVM
vector callback) Xen versions. Withou
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: "van der Linden, Frank"
[ Upstream commit d1ecfa9d1f402366b1776fbf84e635678a51414f ]
This patch fixes crashes during boot for HVM guests on older (pre HVM
vector callback) Xen versions. Withou
On 17/06/18 16:56, Jan Beulich wrote:
> Just like in the HVM emulation and EFI runtime call cases we must not
> set CR0.TS here in fully eager mode. Note that idle vCPU-s never have
> ->arch.fully_eager_fpu set (for their initialization not going through
> vcpu_init_fpu()), so we won't hit the resp
flight 74884 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74884/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-i386-sid-netboot-pvgrub 11 guest-start fail blocked in 74842
test-amd64-amd64-amd64-sid-n
When a MSI interrupt is bound to a guest using
xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt is
left masked by default.
This causes problems with guests that first configure interrupts and
clean the per-entry MSIX table mask bit and afterwards enable MSIX
globally. In such scenar
Hi,
On 25/05/18 06:32, Oleksandr Andrushchenko wrote:
> On 05/23/2018 02:46 PM, Juergen Gross wrote:
>> On 23/05/18 13:36, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> Building for a 32-bit target results in warnings from casting
>>> between a 32-bit pointer and a 64-b
On 06/18/2018 01:06 PM, Andre Przywara wrote:
Hi,
On 25/05/18 06:32, Oleksandr Andrushchenko wrote:
On 05/23/2018 02:46 PM, Juergen Gross wrote:
On 23/05/18 13:36, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Building for a 32-bit target results in warnings from casting
betw
On Wed, 2018-05-23 at 10:01 +0200, David Woodhouse wrote:
>
>On Mon, 2018-05-21 at 14:10 +0200, Roger Pau Monné wrote:
>>
>> Hm, I think I might have fixed this issue, see:
>>
>> https://git.qemu.org/?p=qemu.git;a=commit;h=a8036336609d2e184fc3543a4c439c0ba7d7f3a2
>
>Hm, thanks. We'll look at portin
Juergen Gross writes ("[PATCH v2 1/3] tools/libxencall: use hypercall buffer
device if available"):
> Instead of using anonymous memory for hypercall buffers which is then
> locked into memory, use the hypercall buffer device of the Linux
> privcmd driver if available.
>
> This has the advantage
Juergen Gross writes ("[PATCH v2 3/3] tools/libxc: retry hypercall in case of
EFAULT"):
> A hypercall issued via the privcmd driver can very rarely return
> -EFAULT even if the hypercall buffers are locked in memory. This
> happens for hypercall buffers in user memory when the Linux kernel
> is do
flight 124283 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124283/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt broken in 124221
build-
Committers,
Please don't push any new patch to staging because osstest should
catch up to do a push. As soon as this has happened I'm planning to
initiate branching off Xen 4.11.
Another email will be sent once the moratorium is lifted.
Juergen Gross
___
On Mon, Jun 18, 2018 at 09:35:20AM +, Andra Paraschiv wrote:
> When a MSI interrupt is bound to a guest using
> xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt is
> left masked by default.
>
> This causes problems with guests that first configure interrupts and
> clean the per-
On Mon, Jun 18, 2018 at 09:07:09AM +0300, Oleksandr Andrushchenko wrote:
> drivers/gpu/drm/drm_gem_cma_helper.c| 2 +-
> drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/dr
On 06/18/2018 03:29 PM, Dan Carpenter wrote:
On Mon, Jun 18, 2018 at 09:07:09AM +0300, Oleksandr Andrushchenko wrote:
drivers/gpu/drm/drm_gem_cma_helper.c| 2 +-
drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm
gcc8 spotted this error:
error: 'memcmp' reading 20 bytes from a region of size 8
[-Werror=stringop-overflow=]
Signed-off-by: Olaf Hering
---
stubdom/Makefile| 1 +
stubdom/vtpm_TPM_ChangeAuthAsymFinish.patch | 12
2 files changed, 13 insertions(+)
cre
Olaf Hering, le lun. 18 juin 2018 14:55:36 +0200, a ecrit:
> gcc8 spotted this error:
> error: 'memcmp' reading 20 bytes from a region of size 8
> [-Werror=stringop-overflow=]
>
> Signed-off-by: Olaf Hering
Indeed!
Reviewed-by: Samuel Thibault
> ---
> stubdom/Makefile
On Thu, Jun 14, 2018 at 05:44:31PM +0100, Stefan Hajnoczi wrote:
> Determining the size of a field is useful when you don't have a struct
> variable handy. Open-coding this is ugly.
>
> This patch adds the sizeof_field() macro, which is similar to
> typeof_field(). Existing instances are updated
flight 124353 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124353/
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
From: Isaila Alexandru
This patch adds access rights for the NPT pages. The access rights are
saved in a radix tree with the root saved in p2m_domain. The rights are
manipulated through p2m_set_access()
and p2m_get_access() functions.
The patch follows the ept logic.
Note: It was tested with xe
On 06/18/2018 03:36 AM, Juergen Gross wrote:
> For passing arbitrary data from user land to the Xen hypervisor the
> Xen tools today are using mlock()ed buffers. Unfortunately the kernel
> might change access rights of such buffers for brief periods of time
> e.g. for page migration or compaction,
On Mon, Jun 18, 2018 at 9:19 AM Alexandru Isaila
wrote:
>
> From: Isaila Alexandru
>
> This patch adds access rights for the NPT pages. The access rights are
> saved in a radix tree with the root saved in p2m_domain. The rights are
> manipulated through p2m_set_access()
> and p2m_get_access() fu
flight 124295 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124295/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu broken
test-armhf-armhf-xl-multivcpu 4 host-insta
flight 124312 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124312/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 123814
build-i386-libvirt
flight 124299 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124299/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 7 xen-boot fail REGR. vs. 124090
build-i386-libvirt
flight 124227 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124227/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumprun-amd64 broken
test-armhf-armhf-xl-vhd
branch xen-unstable
xenbranch xen-unstable
job test-armhf-armhf-libvirt-raw
testid xen-boot
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://
flight 124258 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124258/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
test-armhf-armhf-libvirt 7 xen-boot
flight 124321 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124321/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl broken
build-amd64-libvirt 6 libvirt-bui
flight 124292 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124292/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 broken
Tests which are f
36 matches
Mail list logo
