>>> On 21.11.16 at 07:01, wrote:
> Add two new AVX512 subfeatures support for guest.
>
> AVX512_4VNNIW:
> Vector instructions for deep learning enhanced word variable precision.
>
> AVX512_4FMAPS:
> Vector instructions for deep learning floating-point single precision.
>
> Signed-off-by: Luwei
>>> On 19.11.16 at 22:22, wrote:
> Last night on a 288GiB server with less than 64GiB of 32 bit
> domUs, we used the standard xendomains script which starts VMs
> in alphabetical order.
>
> Some 32 bit domUs at the very end were unable to start. The
> error message we received is the following:
>
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 21 November 2016 07:54
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH-for-4.9 v1 8/8] x86/hvm: serialize trap injecting producer
> and consumer
>
> >>> On 18.11.16
> -Original Message-
> From: Pasi Kärkkäinen [mailto:pa...@iki.fi]
> Sent: 19 November 2016 10:57
> To: Dario Faggioli
> Cc: Konrad Rzeszutek Wilk ; Paul Durrant
> ; Anthony Perard ;
> xen-devel ; Stefano Stabellini
> ; Ian Jackson ; Roger Pau
> Monne
> Subject: Re: [Xen-devel] Wondering
On Sat, 2016-11-19 at 12:56 +0200, Pasi Kärkkäinen wrote:
> There's multiple things here..
>
> 1) Yes, +1, let's change the Xen HVM default to "stdvga".
>
:-)
> 2) It'd good to create an upstream Wayland bugreport and investigate
> more about why cirrus is broken with Wayland.
>
Sure, I can do
flight 102470 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102470/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3cabe66b2065980d5084d5823404834e266efe66
baseline version:
ovmf 6a62309459e36d59e4cfe
Add a test to check that Live Patch operations cannot be called from an
unprivileged domain.
Signed-off-by: Ross Lagerwall
---
Changed in v3:
* Addressed review comments.
common/lib.c| 15 +++
docs/all-tests.dox | 2 +
include/xen/sysctl.h
On 11/21/2016 12:20 AM, Jan Beulich wrote:
On 19.11.16 at 22:22, wrote:
>> My current understanding is that on a server with more than 168GiB
>> of memory, I should still be able to around 128GiB of 32-bit PV
>> domUs, regardless of what order the domUs are started in.
>
> You don't clarify
On Sun, 2016-11-20 at 23:37 +0100, Martin Kletzander wrote:
>
> I'm not familiar with Xen to such detail, particularly with its
> history,
> but allow me to (hopefully) help you with the decision by saying that
> we
> dropped support for any QEmu older than 0.12.0 (released on December
> 2009). A
>>> On 21.11.16 at 10:45, wrote:
> On 11/21/2016 12:20 AM, Jan Beulich wrote:
> On 19.11.16 at 22:22, wrote:
>>> My current understanding is that on a server with more than 168GiB
>>> of memory, I should still be able to around 128GiB of 32-bit PV
>>> domUs, regardless of what order the domUs
On 21/11/16 06:01, He Chen wrote:
> Add two new AVX512 subfeatures support for guest.
>
> AVX512_4VNNIW:
> Vector instructions for deep learning enhanced word variable precision.
>
> AVX512_4FMAPS:
> Vector instructions for deep learning floating-point single precision.
>
> Signed-off-by: Luwei Kan
On 16/11/16 10:51, Andrew Cooper wrote:
> vmcb->nextrip can legitimately be less than vmcb->rip when execution wraps
> back around to 0. Instead, complain if the reported length is greater than 15
> and use x86_decode_insn() as a fallback.
>
> While making changes here, fix two whitespace issues w
flight 102469 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102469/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 9 debian-di-installfail REGR. vs. 102443
Regressions which are r
> Why it is not a fair comparison? Because the design is different or
> because of the settings?
Because the design difference.
It's not about memcpy vs mapping within the same stack (design). And
you measured interdomain communication only, not involving hardware
interfaces.
> I am happy to adjus
flight 68072 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68072/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-i386-sid-netboot-pygrub 9 debian-di-install fail like 68032
test-amd64-i386-amd
John,
I guess you should remove descriptions of clocks and pins of a serial
port owned by XEN from the DTSI.
Normally kernel decides that they are not used, so disables them and
you think your system hangs.
I'm not really sure why you are reached this far (rootfs mounting), it
should be "hanged" e
flight 102465 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102465/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail in 102439
pass in 102465
test-amd64-amd64-xl-
flight 102474 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102474/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 01dd077315c6759c94af9af4232f8318db13cf8d
baseline version:
ovmf 3cabe66b2065980d5084d
On 21/11/16 09:24, Ross Lagerwall wrote:
> Add a test to check that Live Patch operations cannot be called from an
> unprivileged domain.
>
> Signed-off-by: Ross Lagerwall
Reviewed-by: Andrew Cooper and applied.
I made two very small adjustments.
> diff --git a/common/lib.c b/common/lib.c
> in
flight 102468 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102468/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 9 debian-di-installfail REGR. vs. 101909
test-amd64-amd64-
flight 102478 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102478/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 1f1aa2c0914818798cdfc1d61014343dad961eed
baseline version:
xtf bd2a670f858314d28413ca
On 21/11/2016 02:21, Lan, Tianyu wrote:
On 11/19/2016 3:43 AM, Julien Grall wrote:
On 17/11/2016 09:36, Lan Tianyu wrote:
Hi Julien:
Hello Lan,
Thanks for your input. This interface is just for virtual PCI device
which is called by Qemu. I am not familiar with ARM. Are there any
non-P
On 21/11/16 10:05, Jan Beulich wrote:
On 21.11.16 at 10:45, wrote:
>> On 11/21/2016 12:20 AM, Jan Beulich wrote:
>> On 19.11.16 at 22:22, wrote:
My current understanding is that on a server with more than 168GiB
of memory, I should still be able to around 128GiB of 32-bit PV
>>
On 11/21/2016 05:40 AM, Andrew Cooper wrote:
> On 16/11/16 10:51, Andrew Cooper wrote:
>> vmcb->nextrip can legitimately be less than vmcb->rip when execution wraps
>> back around to 0. Instead, complain if the reported length is greater than
>> 15
>> and use x86_decode_insn() as a fallback.
Why
On 17/11/16 15:36, Lan Tianyu wrote:
> 3.2 l2 translation
> 1) For virtual PCI device
> Xen dummy xen-vIOMMU in Qemu translates IOVA to target GPA via new
> hypercall when DMA operation happens.
>
> When guest triggers a invalidation operation, there maybe in-fly DMA
> request for virtual device ha
On 21/11/16 13:38, Boris Ostrovsky wrote:
> On 11/21/2016 05:40 AM, Andrew Cooper wrote:
>> On 16/11/16 10:51, Andrew Cooper wrote:
>>> vmcb->nextrip can legitimately be less than vmcb->rip when execution wraps
>>> back around to 0. Instead, complain if the reported length is greater than
>>> 15
On 11/21/2016 08:53 AM, Andrew Cooper wrote:
> On 21/11/16 13:38, Boris Ostrovsky wrote:
>> On 11/21/2016 05:40 AM, Andrew Cooper wrote:
>>> On 16/11/16 10:51, Andrew Cooper wrote:
vmcb->nextrip can legitimately be less than vmcb->rip when execution wraps
back around to 0. Instead, compl
Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
NUMA balancing") set VM_IO flag to prevent grant maps from being
subjected to NUMA balancing.
It was discovered recently that this flag causes get_user_pages() to
always fail with -EFAULT.
check_vma_flags
__get_user_pages
__get
As that is also part of the release.
Signed-off-by: Konrad Rzeszutek Wilk
---
tools/misc/mktarball | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/misc/mktarball b/tools/misc/mktarball
index 356def3..72cae34 100755
--- a/tools/misc/mktarball
+++ b/tools/misc/mktarball
@@ -41,6 +41
Hi,
the following patch is present in the following LTS kernels
>=linux-3.2.81
>=linux-3.16.36
>=linux-3.18.33
>=linux-4.1.24
>=linux-4.4.9
however it is missing from LTS kernels
- linux-3.4
- linux-3.10
- linux-3.12
> From 103f6112f253017d7062cd74d17f4a514ed4485c Mon Sep 17 00:00:00 2001
>
On Tue, Nov 08, 2016 at 11:59:46AM -0800, Stefano Stabellini wrote:
> The following changes since commit 207faf24c58859f5240f66bf6decc33b87a1776e:
>
> Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into
> staging (2016-11-07 14:02:15 +)
>
> are available in the git repo
The variable is named inst_len, not insn_len.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
I definitely fixed this once duing development, but it clearly slipped back
in. My appologies.
---
xen/arch/x86/hvm/svm/emulate.c | 4 ++-
On Fri, Nov 18, 2016 at 4:25 PM, Jim Fehlig wrote:
> Hi All,
>
> I briefly mentioned this at an evening event during the KVM Forum / Xen Dev
> Summit, but the list is certainly a better place to discuss such a topic.
> What do folks think about finally removing the old, legacy, xend-based
> driver
On Fri, Nov 18, 2016 at 02:25:18PM -0700, Jim Fehlig wrote:
> Hi All,
>
> I briefly mentioned this at an evening event during the KVM Forum / Xen Dev
> Summit, but the list is certainly a better place to discuss such a topic.
> What do folks think about finally removing the old, legacy, xend-based
On Mon, Nov 21, 2016 at 04:22:10PM +0100, Thomas Deutschmann wrote:
> > From 103f6112f253017d7062cd74d17f4a514ed4485c Mon Sep 17 00:00:00 2001
> > From: Jan Beulich
> > Date: Thu, 21 Apr 2016 00:27:04 -0600
> > Subject: x86/mm/xen: Suppress hugetlbfs in PV guests
Queued for next 3.10, thanks Thom
Without this I cannot build it under Fedora Core 25.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Konrad Rzeszutek Wilk
---
OvmfPkg/build.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
index eb5eb73..759ade3 10
(Resending as I was not subscribed to edk2-de...@lists.01.org when
I sent out the patch, now I am)
Please accept and review the following patch which enables me to
build TianoCore under Fedora Core 25.
The GCC version that is installed is:
gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2)
Copyright (C)
On 11/21/2016 10:32 AM, Andrew Cooper wrote:
> The variable is named inst_len, not insn_len.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Boris Ostrovsky
> CC: Suravee Suthikulpanit
>
> I definitely fixed this once duing development, but it clearly slipped back
This run is configured for baseline tests only.
flight 68074 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68074/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3cabe66b2065980d5084d5823404834e266efe66
baseline v
On 21 November 2016 at 15:56, Konrad Rzeszutek Wilk wrote:
> Without this I cannot build it under Fedora Core 25.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> OvmfPkg/build.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On Mon, Nov 21, 2016 at 04:20:04PM +, Ard Biesheuvel wrote:
> On 21 November 2016 at 15:56, Konrad Rzeszutek Wilk wrote:
> > Without this I cannot build it under Fedora Core 25.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Konrad Rzeszutek Wilk
> > ---
>
On Mon, Nov 21, 2016 at 11:06:23AM -0500, Boris Ostrovsky wrote:
> On 11/21/2016 10:32 AM, Andrew Cooper wrote:
> > The variable is named inst_len, not insn_len.
> >
> > Signed-off-by: Andrew Cooper
> > ---
> > CC: Jan Beulich
> > CC: Wei Liu
> > CC: Boris Ostrovsky
> > CC: Suravee Suthikulpani
Hello guys,
I have created wiki page for Salvator-X board:
https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X
And update related yocto layer:
https://github.com/qbeeukraine/meta-platform-xen
Please review & leave your comments.
I am planning to update this layer with Xe
flight 102485 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102485/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 102487 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102487/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf e10e74e48495bfb7e023d0397b625b14364d4422
baseline version:
xtf 1f1aa2c0914818798cdfc1
Hello Iurii,
On 21/11/2016 17:12, Iurii Mykhalskyi wrote:
Hello guys,
I have created wiki page for Salvator-X board:
https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X
Thank you for that.
And update related yocto layer:
https://github.com/qbeeukraine/meta-platform-
On Mon, 21 Nov 2016, Paul Durrant wrote:
> > -Original Message-
> > From: Pasi Kärkkäinen [mailto:pa...@iki.fi]
> > Sent: 19 November 2016 10:57
> > To: Dario Faggioli
> > Cc: Konrad Rzeszutek Wilk ; Paul Durrant
> > ; Anthony Perard ;
> > xen-devel ; Stefano Stabellini
> > ; Ian Jackson ;
On Mon, 21 Nov 2016, Andrii Anisov wrote:
> > Why it is not a fair comparison? Because the design is different or
> > because of the settings?
> Because the design difference.
> It's not about memcpy vs mapping within the same stack (design). And
> you measured interdomain communication only, not i
Hi Juergen,
it would be helpful if you could resend this series with the small
changes I requested. But if it is a problem for you, I can do that
myself while committing.
Cheers,
Stefano
On Wed, 2 Nov 2016, Juergen Gross wrote:
> Trying to use pvUSB in a Xen guest with a qemu emulated USB contr
On Tue, Nov 15, 2016 at 04:42:50PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 14, 2016 at 12:33:33PM +, Anthony PERARD wrote:
> > +# Those tests access a volume through iSCSI. This does not work when
> > both
> > +# the server and client of iSCSI are on the same Xen host, Linux
On Thu, Nov 17, 2016 at 11:49:19AM +, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("[PATCH v1 3/7] ts-xen-build: Install livepatch
> regressions tests."):
> > That come with the Xen git tree (see xen/test/).
>
> I think this and the "build them" patch should be combined.
>
> > +bui
On Mon, 21 Nov 2016, Julien Grall wrote:
> On 21/11/2016 02:21, Lan, Tianyu wrote:
> > On 11/19/2016 3:43 AM, Julien Grall wrote:
> > > On 17/11/2016 09:36, Lan Tianyu wrote:
> > Hi Julien:
>
> Hello Lan,
>
> > Thanks for your input. This interface is just for virtual PCI device
> > which is
flight 102482 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102482/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 9 debian-di-installfail REGR. vs. 101909
test-amd64-amd64-
This run is configured for baseline tests only.
flight 68075 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68075/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 01dd077315c6759c94af9af4232f8318db13cf8d
baseline v
flight 102484 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102484/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101716
test-amd64-amd64-xl-qemuu-win7-a
flight 102488 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102488/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 36431397ac902e791e16a016ade3413bd6b63069
baseline version:
xtf e10e74e48495bfb7e023d0
On Thu, Nov 17, 2016 at 12:21:58PM +, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("[PATCH v1 5/7] ts-livepatch: Initial
> test-cases."):
> > There are 32 test-cases in there. Before we run
> > any of them we verify that the payload files are present
> > in /usr/lib/debug.
> >
> > If so
On 11/21/2016 05:21 AM, Andrew Cooper wrote:
> On 21/11/16 10:05, Jan Beulich wrote:
Back in the xend days someone here had invented a (crude) mechanism
to set aside memory for 32-bit PV domains, but I don't think dealing with
this situation in xl has ever seen any interest.
>>> If
On Fri, Nov 18, 2016 at 10:58:42AM -0800, Stefano Stabellini wrote:
> On Thu, 17 Nov 2016, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 17/11/2016 11:26, Stefano Stabellini wrote:
> > > On Mon, 14 Nov 2016, Julien Grall wrote:
> > > > On 11/11/2016 13:55, Stefano Stabellini wrote:
> > > > > On F
On 11/21/16 17:20, Ard Biesheuvel wrote:
> On 21 November 2016 at 15:56, Konrad Rzeszutek Wilk wrote:
>> Without this I cannot build it under Fedora Core 25.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Konrad Rzeszutek Wilk
>> ---
>> OvmfPkg/build.sh | 2 +-
>>
flight 102490 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102490/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Mon, 21 Nov 2016, Edgar E. Iglesias wrote:
> On Fri, Nov 18, 2016 at 10:58:42AM -0800, Stefano Stabellini wrote:
> > On Thu, 17 Nov 2016, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 17/11/2016 11:26, Stefano Stabellini wrote:
> > > > On Mon, 14 Nov 2016, Julien Grall wrote:
> > > > > O
PM timer is not supported by PVH guests.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Konrad Rzeszutek Wilk
Acked-by: Jan Beulich
---
Changes in v3:
* Fadt.pm_tmr_len needs to be zero too. (I kept the acks)
tools/firmware/hvmloader/util.c | 3 ++-
tools/libacpi/build.c | 5 +
too
ACPI builder marks VCPUS set in vcpu_online map as enabled in MADT.
With ACPI-based CPU hotplug we only want VCPUs that are started by
the guest to be marked as such. Remaining VCPUs will be set to
"enable" by AML code during hotplug.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Konrad Rzeszutek W
.. and update GPE0 registers.
Signed-off-by: Boris Ostrovsky
---
CC: Stefano Stabellini
CC: Julien Grall
---
Changes in v3:
* Add per-arch arch_update_avail_vcpus() (nop for ARM)
* send_guest_global_virq() is updated to deal with
offlined VCPU0, made non-static.
xen/arch/arm/domain.c |
PVH guests will have ACPI accesses emulated by the hypervisor
as opposed to QEMU (as is the case for HVM guests)
Support for IOREQ server emulation of CPU hotplug is indicated
by XEN_X86_EMU_IOREQ_CPUHP flag.
Logic for the handler will be provided by a later patch.
Signed-off-by: Boris Ostrovsky
Signed-off-by: Boris Ostrovsky
Reviewed-by: Konrad Rzeszutek Wilk
Acked-by: Jan Beulich
---
tools/firmware/hvmloader/util.c | 3 ++-
tools/libacpi/build.c | 2 ++
tools/libacpi/libacpi.h | 1 +
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/firmware/hvmloa
This series adds support for ACPI-based VCPU hotplug for unprivileged
PVH guests.
New XEN_DOMCTL_set_avail_vcpus is introduced and is called during
guest creation and in response to 'xl vcpu-set' command. This domctl
updates GPE0's status and enable registers and sends an SCI to the
guest using (n
Signed-off-by: Boris Ostrovsky
---
CC: Paul Durrant
---
Changes in v3:
* Introduce a mask for pm1a and gpe0 that lists bits that a
guest can operate on.
* Lots of small changes.
xen/arch/x86/hvm/ioreq.c | 87 +++-
xen/include/asm-x86/hvm/domain.h |
ACPI hotplug-related IO accesses (to GPE0 block) are handled
by qemu for HVM guests. Since PVH guests don't have qemu these
accesses will need to be procesed by the hypervisor.
Because ACPI event model expects pm1a block to be present we
need to have the hypervisor emulate it as well.
Define XEN_
Signed-off-by: Boris Ostrovsky
---
CC: George Dunlap
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
---
docs/misc/hvmlite.markdown | 12
1 file changed, 12 insertions(+)
diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
index 898b8ee..0045d22
PVH guests do not have IOAPIC which typically generates an SCI. For
those guests SCI will be provided as a virtual interrupt.
We also move VIRQ_MCA definition out of xen-mca.h to
keep all x86-specific VIRQ_ARCH_* in one place.
Signed-off-by: Boris Ostrovsky
---
CC: George Dunlap
CC: Konrad Rzes
This is the method that will get invoked on an SCI.
Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
---
tools/libacpi/mk_dsdt.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index 6da24fa..6197692 100644
---
This domctl is called when a VCPU is hot-(un)plugged to a guest (via
'xl vcpu-set').
The primary reason for adding this call is because for PVH guests
the hypervisor needs to send an SCI and set GPE registers. This is
unlike HVM guests that have qemu to perform these tasks.
Signed-off-by: Boris O
On 11/21/2016 11:37 AM, Sarah Newman wrote:
> On 11/21/2016 05:21 AM, Andrew Cooper wrote:
>> On 21/11/16 10:05, Jan Beulich wrote:
>
> Back in the xend days someone here had invented a (crude) mechanism
> to set aside memory for 32-bit PV domains, but I don't think dealing with
> this
On Mon, Nov 21, 2016 at 01:01:15PM -0800, Stefano Stabellini wrote:
> On Mon, 21 Nov 2016, Edgar E. Iglesias wrote:
> > On Fri, Nov 18, 2016 at 10:58:42AM -0800, Stefano Stabellini wrote:
> > > On Thu, 17 Nov 2016, Julien Grall wrote:
> > > > Hi Stefano,
> > > >
> > > > On 17/11/2016 11:26, Stefan
On 21/11/2016 21:13, Edgar E. Iglesias wrote:
On Mon, Nov 21, 2016 at 01:01:15PM -0800, Stefano Stabellini wrote:
On Mon, 21 Nov 2016, Edgar E. Iglesias wrote:
On Fri, Nov 18, 2016 at 10:58:42AM -0800, Stefano Stabellini wrote:
On Thu, 17 Nov 2016, Julien Grall wrote:
Hi Stefano,
On 17/11/
Hi all,
this small patch series provides a few fixes and clean-ups in
preparation for the introduction of a 9pfs Xen transport.
Stefano Stabellini (4):
9pfs: move pdus to V9fsState
9pfs: introduce transport specific callbacks
9pfs: use v9fs_init_qiov_from_pdu instead of v9fs_pa
Don't call virtio functions from 9pfs generic code, use generic function
callbacks instead.
Signed-off-by: Stefano Stabellini
---
hw/9pfs/9p.c | 8
hw/9pfs/9p.h | 18 ++
hw/9pfs/virtio-9p-device.c | 18 ++
hw/9pfs/virtio-9p.h
Not all 9pfs transports share memory between request and response. For
those who don't, it is necessary to know how much memory is required in
the response.
Signed-off-by: Stefano Stabellini
---
hw/9pfs/9p.c | 2 +-
hw/9pfs/9p.h | 2 +-
hw/9pfs/virtio-9p-device.c | 2
v9fs_xattr_read should not access VirtQueueElement elems directly.
Move v9fs_init_qiov_from_pdu up in the file and call
v9fs_init_qiov_from_pdu instead of v9fs_pack.
Signed-off-by: Stefano Stabellini
---
hw/9pfs/9p.c | 58 +-
1 file changed
pdus are initialized and used in 9pfs common code. Move the array from
V9fsVirtioState to V9fsState.
Signed-off-by: Stefano Stabellini
---
hw/9pfs/9p.c| 7 +++
hw/9pfs/9p.h| 1 +
hw/9pfs/virtio-9p.h | 1 -
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/hw/9pfs
On Mon, Nov 21, 2016 at 09:24:27PM +, Julien Grall wrote:
>
>
> On 21/11/2016 21:13, Edgar E. Iglesias wrote:
> >On Mon, Nov 21, 2016 at 01:01:15PM -0800, Stefano Stabellini wrote:
> >>On Mon, 21 Nov 2016, Edgar E. Iglesias wrote:
> >>>On Fri, Nov 18, 2016 at 10:58:42AM -0800, Stefano Stabell
This run is configured for baseline tests only.
flight 68076 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68076/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop
Hi Andrii,
Thank you for the document, I think is a very good start. I also see the
need for this framework. Please add more details about the proposed
interface (Xen API, hypercalls, etc) in the next version; I am looking
forward to it.
On Wed, 16 Nov 2016, Andrii Anisov wrote:
> AM> The situat
flight 102489 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102489/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail REGR. vs.
102465
test-armhf-
On Mon, 21 Nov 2016, Boris Ostrovsky wrote:
> Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
> NUMA balancing") set VM_IO flag to prevent grant maps from being
> subjected to NUMA balancing.
>
> It was discovered recently that this flag causes get_user_pages() to
> always f
> -Original Message-
> From: Tian, Kevin
> Sent: Friday, November 18, 2016 12:31 PM
> To: Wu, Feng ; xen-devel@lists.xen.org
> Cc: jbeul...@suse.com; andrew.coop...@citrix.com;
> george.dun...@eu.citrix.com; dario.faggi...@citrix.com
> Subject: RE: [PATCH v8 4/7] VT-d: Use one function to
> -Original Message-
> From: Tian, Kevin
> Sent: Friday, November 18, 2016 12:44 PM
> To: Wu, Feng ; xen-devel@lists.xen.org
> Cc: jbeul...@suse.com; andrew.coop...@citrix.com;
> george.dun...@eu.citrix.com; dario.faggi...@citrix.com
> Subject: RE: [PATCH v8 5/7] VT-d: No need to set irq
> "Juergen" == Juergen Gross writes:
Juergen,
Juergen> On 19/11/16 19:22, Quentin Lambert wrote:
>> Most error branches following the call to kmalloc contain a call to
>> kfree. This patch add these calls where they are missing.
>>
>> This issue was found with Hector.
>>
>> Signed-off-by:
flight 102492 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102492/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 9 debian-di-installfail REGR. vs. 101909
test-amd64-amd64-
On 22/11/16 04:40, Martin K. Petersen wrote:
>> "Juergen" == Juergen Gross writes:
>
> Juergen,
>
> Juergen> On 19/11/16 19:22, Quentin Lambert wrote:
>>> Most error branches following the call to kmalloc contain a call to
>>> kfree. This patch add these calls where they are missing.
>>>
>>>
On 22/11/16 04:59, Hugh Dickins wrote:
> On Mon, 21 Nov 2016, Boris Ostrovsky wrote:
>
>> Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
>> NUMA balancing") set VM_IO flag to prevent grant maps from being
>> subjected to NUMA balancing.
>>
>> It was discovered recently that
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, November 21, 2016 9:41 PM
>
> On 17/11/16 15:36, Lan Tianyu wrote:
> > 3.2 l2 translation
> > 1) For virtual PCI device
> > Xen dummy xen-vIOMMU in Qemu translates IOVA to target GPA via new
> > hypercall when DMA operation h
Trying to use pvUSB in a Xen guest with a qemu emulated USB controller
will crash qemu as it tries to attach a pvUSB device to the emulated
controller.
This can be avoided by adding a unique id to each pvUSB controller which
can be used when attaching the pvUSB device. In order to make this
possib
In order to have an easy way to add a new qdev with a specific id
carve out the needed functionality from qdev_device_add() into a new
function qdev_set_id().
Signed-off-by: Juergen Gross
Reviewed-by: Stefano Stabellini
---
include/monitor/qdev.h | 1 +
qdev-monitor.c | 36
Add a bus for Xen backend devices in order to be able to establish a
dedicated device path for pluggable devices.
Signed-off-by: Juergen Gross
Reviewed-by: Stefano Stabellini
---
hw/xen/xen_backend.c | 19 ---
include/hw/xen/xen_backend.h | 4
2 files changed, 20 i
Attach the usb bus of a new pvusb controller to the qdev associated
with the Xen backend. Any device connected to that controller can now
specify the bus and port directly via its properties.
Signed-off-by: Juergen Gross
Reviewed-by: Stefano Stabellini
---
hw/usb/xen-usb.c | 23 ++--
Create a qdev plugged to the xen-sysbus for each new backend device.
This device can be used as a parent for all needed devices of that
backend. The id of the new device will be "xen--" with
being the xen backend type (e.g. "qdisk") and the xen
backend number of the type under which it is to be f
99 matches
Mail list logo
