Re: [Xen-devel] [PATCH v2] x86/cpuid: Add AVX512_4VNNIW and AVX512_4FMAPS support

[Jan Beulich]

>>> 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 Kang 
> Signed-off-by: He Chen 

As before, hypervisor parts
Reviewed-by: Jan Beulich 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Can't always start 32 bit domains after 64 bit domains

[Jan Beulich]

>>> 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:
> 
> xc: error: panic: xc_dom_x86.c:944: arch_setup_meminit: failed to allocate 
> 0x8 pages: Internal error
> xc: error: panic: xc_dom_boot.c:154: xc_dom_boot_mem_init: can't allocate 
> low memory for domain: Out of memory
> libxl: error: libxl_dom.c:719:libxl__build_pv: xc_dom_boot_mem_init failed: 
> Device or resource busy
> libxl: error: libxl_create.c:1144:domcreate_rebuild_done: cannot (re-)build 
> domain: -3
> 
> After shutting down some 64 bit domUs, we could start the remainder
> of the 32 bit domUs. Finally we started the rest of the 64 bit
> domUs such that everything was booted.
> 
> 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 what you base this understanding of yours on; I don't
think this is the case. What exact memory will be allocated for 64-bit
guests isn't very predictable. In particular, the preference of allocating
1Gb pages as long as available may result in allocations eating into the
low 128Gb of memory earlier than you expect. You may want to analyze
system state by looking at debug key output at relevant points in time.

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.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH-for-4.9 v1 8/8] x86/hvm: serialize trap injecting producer and consumer

[Paul Durrant]

> -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 at 18:14,  wrote:
> > Since injection works on a remote vCPU, and since there's no
> > enforcement of the subject vCPU being paused, there's a potential race
> > between the producing and consuming sides. Fix this by leveraging the
> > vector field as synchronization variable.
> >
> > Signed-off-by: Jan Beulich 
> > [re-based]
> > Signed-off-by: Paul Durrant 
> 
> At least this patch of the series should remain "From:" me; I haven't
> looked at the others yet, but I have to admit I'm puzzled that I
> haven't been Cc-ed on other than the one here and patch 1.
> 

I'm puzzled as well because most patches are 'suggested-by' you. I guess it 
means that git-send-email doesn't consider that worthy of a cc... I'll manually 
add you to the cc list for future versions.

  Paul

> Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Wondering about cirris and stdvga

[Paul Durrant]

> -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 about cirris and stdvga
> 
> On Fri, Nov 18, 2016 at 07:04:15PM +0100, Dario Faggioli wrote:
> > Sending again, this time, with Anthony's and xen-devel address spelled
> > right. Sorry!! :-(
> > ---
> > Hello to you, various pseudo-random people,
> >
> > It's not my field of expertise, so bear with me, at least a little bit
> > (and, Konrad, you help me, or there will be consequences! :-D)
> >
> > So, I and Konrad recently discovered --while testing the about to be
> > released Fedora 25 as a Xen guest-- that the Cirrus emulated graphic
> > card that we consume from QEMU for HVM guests is broken on Wayland.
> >
> > We just discovered it because Fedora 25 uses Wayland by default, but it
> > appears not to be something new:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1227770
> >
> > And at least from what we see in that bugreport, not much has happened
> > so far.
> >
> > Using "vga='stdvga'" in the config file, or even "vga='qxl'" make
> > things work again. Disabling Wayland in the guest also works (i.e., if
> > not using Wayland, Cirrus is ok). And that's what made us think that
> > it's probably a Wayland issue.
> >
> > I've tried the same on KVM, and the situation is identical
> > (Cirrus+Wayland=breaks, whatever-else+Wayland=works,
> > Cirrus+Xorg=works).
> >
> > I've also read around that these days, e.g., stdvga is at least as good
> > as cirrus, performance wise, that cirrus is broken and impossible to
> > fix (because it is the hardware that it's emulating that was broken),
> > that stdvga enables better screen resolution in guests, etc.
> >
> > I'm not sure about these claims, in particular the performance one, is
> > probably pretty hard to verify. And as I said, it's not my field.
> >
> > Still I thought it could be worthwhile to at least bring this up:
> > should we start to consider changing the default from cirrus to stdvga
> > (or something else)?
> >
> 
> There's multiple things here..
> 
> 1) Yes, +1, let's change the Xen HVM default to "stdvga".
> 

In general std-vga also gets a +1 from me, but I have recently found that a 
Windows Server 2008 guest does not boot (ar at least the display freezes on 
boot) when using std-vga with QEMU trad but everything is fine with Cirrus... 
so probably worth making the default dependent on which QEMU is being used. 
Never had any issues with std-vga on upstream QEMU.

  Paul

> 2) It'd good to create an upstream Wayland bugreport and investigate more
> about why cirrus is broken with Wayland.
> 
> 3) It'd be good to have Xen HVM with "qxl" tested by OSStest aswell..
> 
> 
> > Thanks for your time and Regards,
> > Dario
> 
> 
> Thanks,
> 
> -- Pasi


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Wondering about cirris and stdvga

[Dario Faggioli]

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 that.

> 3) It'd be good to have Xen HVM with "qxl" tested by OSStest aswell..
> 
I've had a look at that too, and I'm happy to continue trying, although
I don't know much on the subject, so any help is appreciated.

I've found out that, if you install spice dev libraries, (upstream)
QEMU gets built with qxl enabled, and I can specity "vga=qxl" in guest
config, and that works.

I see the boot, I see X / Wayland, etc.

What I haven't understood yet is how to actually connect with a "spice
client" (or whatever the correct terminology is) and get the
acceleration and all the benefits. I've tried just connecting with
spicy or virt-viewer, but couldn't get that to work.

I think I've got to install/enable stuff inside the guest too, but I'm
not sure what yet.

I'll try to fetch docs online, and fish back one of those old thread we
had here about spice support, to see if there is some more info.

Thanks and Regards,
Dario
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [ovmf test] 102470: all pass - PUSHED

[osstest service owner]

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 6a62309459e36d59e4cfe14885fa3ed807841c62

Last test of basis   102464  2016-11-21 01:45:15 Z0 days
Testing same since   102470  2016-11-21 04:36:21 Z0 days1 attempts


People who touched revisions under test:
  Star Zeng 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=ovmf
+ revision=3cabe66b2065980d5084d5823404834e266efe66
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
3cabe66b2065980d5084d5823404834e266efe66
+ branch=ovmf
+ revision=3cabe66b2065980d5084d5823404834e266efe66
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x3cabe66b2065980d5084d5823404834e266efe66 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.gi

[Xen-devel] [XTF PATCH v3] Add a Live Patch privilege check test

[Ross Lagerwall]

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| 211 
 include/xen/xen.h   |   9 ++
 include/xtf/hypercall.h |   6 +
 include/xtf/lib.h   |   6 +
 tests/livepatch-priv-check/Makefile |   9 ++
 tests/livepatch-priv-check/main.c   | 153 ++
 8 files changed, 411 insertions(+)
 create mode 100755 include/xen/sysctl.h
 create mode 100644 tests/livepatch-priv-check/Makefile
 create mode 100644 tests/livepatch-priv-check/main.c

diff --git a/common/lib.c b/common/lib.c
index 9dca3e3..0a2b311 100644
--- a/common/lib.c
+++ b/common/lib.c
@@ -19,6 +19,21 @@ void __noreturn panic(const char *fmt, ...)
 arch_crash_hard();
 }
 
+int xtf_probe_sysctl_interface_version(void)
+{
+int i;
+xen_sysctl_t op = {0};
+
+for ( i = 0; i < 128; i++ )
+{
+op.interface_version = i;
+if ( hypercall_sysctl(&op) != -EACCES )
+return i;
+}
+
+return -1;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/docs/all-tests.dox b/docs/all-tests.dox
index 4f86182..2909b85 100644
--- a/docs/all-tests.dox
+++ b/docs/all-tests.dox
@@ -22,6 +22,8 @@ and functionality.
 
 @subpage test-invlpg - `invlpg` instruction behaviour.
 
+@subpage test-livepatch-priv-check - Live Patch Privilege Check
+
 @subpage test-pv-iopl - IOPL emulation for PV guests.
 
 @subpage test-swint-emulation - Software interrupt emulation for HVM guests.
diff --git a/include/xen/sysctl.h b/include/xen/sysctl.h
new file mode 100755
index 000..a461b1c
--- /dev/null
+++ b/include/xen/sysctl.h
@@ -0,0 +1,211 @@
+/**
+ * sysctl.h
+ *
+ * System management operations. For use by node control stack.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2002-2006, K Fraser
+ */
+
+#ifndef __XEN_PUBLIC_SYSCTL_H__
+#define __XEN_PUBLIC_SYSCTL_H__
+
+#include "xen.h"
+#include "physdev.h"
+
+/*
+ * XEN_SYSCTL_LIVEPATCH_op
+ *
+ * Refer to the docs/unstable/misc/livepatch.markdown
+ * for the design details of this hypercall.
+ *
+ * There are four sub-ops:
+ *  XEN_SYSCTL_LIVEPATCH_UPLOAD (0)
+ *  XEN_SYSCTL_LIVEPATCH_GET (1)
+ *  XEN_SYSCTL_LIVEPATCH_LIST (2)
+ *  XEN_SYSCTL_LIVEPATCH_ACTION (3)
+ *
+ * The normal sequence of sub-ops is to:
+ *  1) XEN_SYSCTL_LIVEPATCH_UPLOAD to upload the payload. If errors STOP.
+ *  2) XEN_SYSCTL_LIVEPATCH_GET to check the `->rc`. If -XEN_EAGAIN spin.
+ * If zero go to next step.
+ *  3) XEN_SYSCTL_LIVEPATCH_ACTION with LIVEPATCH_ACTION_APPLY to apply the 
patch.
+ *  4) XEN_SYSCTL_LIVEPATCH_GET to check the `->rc`. If in -XEN_EAGAIN spin.
+ * If zero exit with success.
+ */
+
+#define LIVEPATCH_PAYLOAD_VERSION 1
+/*
+ * Structure describing an ELF payload. Uniquely identifies the
+ * payload. Should be human readable.
+ * Recommended length is upto XEN_LIVEPATCH_NAME_SIZE.
+ * Includes the NUL terminator.
+ */
+#define XEN_LIVEPATCH_NAME_SIZE 128
+struct xen_livepatch_name {
+guest_handle_64_t name; /* IN: pointer to name. */
+uint16_t size;  /* IN: size of name. May be upto
+   XEN_LIVEPATCH_NAME_SIZE. */
+uint16_t pad[3];/* IN: MUST be zero. */
+};
+typedef struct xen_livepatch_name xen_livepatch_name_t;
+
+/*
+ * Upload a payload to the hypervisor. The payload is verified
+ * against basic checks and if there are any issues the proper return code
+ * will be returned. The payload is not applied at this time - that is
+ * controlled by XEN_SYSCTL_LIVEPATCH_ACTION.
+ *
+ * The return value is

Re: [Xen-devel] Can't always start 32 bit domains after 64 bit domains

[Sarah Newman]

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 what you base this understanding of yours on; I don't
> think this is the case. What exact memory will be allocated for 64-bit
> guests isn't very predictable. In particular, the preference of allocating
> 1Gb pages as long as available may result in allocations eating into the
> low 128Gb of memory earlier than you expect. You may want to analyze
> system state by looking at debug key output at relevant points in time.

Because whenever I read about the 168GiB limit and 32 bit domains there was no 
mention that the initial 128GiB might not all be available if there
were also 64 bit domains. Given how little visibility there typically is into 
where memory is physically allocated, there is no way to know this
doesn't work as a normal user until it doesn't. Are you saying all Xen users 
have to be developers too?

In my opinion this is a bug until/unless it's very clearly documented that it's 
not supported behavior to mix 32 and 64 bit PV domains when there is
more than 168GiB RAM, or maybe just period if that's too complicated to explain 
to people. I don't know where to find that documentation. It seems
like https://wiki.xenproject.org/wiki/Xen_Project_Release_Features might be the 
right place, I'm not sure. If you know of a better place I'd love to know.

> 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 I wanted to add that, where would it go?

Thanks, Sarah

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [libvirt] Opinions on removing the old, legacy libvirt Xen driver

[Dario Faggioli]

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).  And by that I don't mean that we stopped fixing bugs for
> those,
> but that libvirt now *mandates* version 0.12.0 or newer.  That is
> what
> is available in CentOS 6 and similar (or as Dan stated it "RHEL-6 era
> distros).  For others like me, who don't know when the Xen releases
> were
> made, I found out (for you) that it should be March 2011 for 4.1 and
> September that year for 4.2.  So I'm not even going to ask in which
> version xl/libxl was introduced.
>
FYI, xl was introduced in Xen 4.1:
https://wiki.xen.org/wiki/XL

Xen 4.1 was indeed released on 25th March 2011:
https://wiki.xen.org/wiki/Xen_4.1_Release_Notes

Xen 4.2 was released on 17 Sept _2012_:
https://wiki.xen.org/wiki/Xen_Project_Release_Features

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Can't always start 32 bit domains after 64 bit domains

[Jan Beulich]

>>> 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 are started in.
>> 
>> You don't clarify what you base this understanding of yours on; I don't
>> think this is the case. What exact memory will be allocated for 64-bit
>> guests isn't very predictable. In particular, the preference of allocating
>> 1Gb pages as long as available may result in allocations eating into the
>> low 128Gb of memory earlier than you expect. You may want to analyze
>> system state by looking at debug key output at relevant points in time.
> 
> Because whenever I read about the 168GiB limit and 32 bit domains there was 
> no mention that the initial 128GiB might not all be available if there
> were also 64 bit domains. Given how little visibility there typically is 
> into where memory is physically allocated, there is no way to know this
> doesn't work as a normal user until it doesn't. Are you saying all Xen users 
> have to be developers too?

No, I'm not saying this, but please note that you didn't post the
question on xen-users, but xen-devel.

> In my opinion this is a bug until/unless it's very clearly documented that 
> it's not supported behavior to mix 32 and 64 bit PV domains when there is
> more than 168GiB RAM, or maybe just period if that's too complicated to 
> explain to people. I don't know where to find that documentation. It seems
> like https://wiki.xenproject.org/wiki/Xen_Project_Release_Features might be 
> the right place, I'm not sure. If you know of a better place I'd love to 
> know.

I view this as a bug too, fwiw. Me previously bringing up the topic
didn't result in any activity though, presumably because 32-bit
guests are being considered rare enough these days.

>> 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 I wanted to add that, where would it go?

I don't know, that's a question for xl folks I guess.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] x86/cpuid: Add AVX512_4VNNIW and AVX512_4FMAPS support

[Andrew Cooper]

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 Kang 
> Signed-off-by: He Chen 

Thanks.  Reviewed-by: Andrew Cooper 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.8] x86/svm: Fix svm_nextrip_insn_length() when crossing the virtual boundary to 0

[Andrew Cooper]

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 with the case labels.
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Boris Ostrovsky 
> CC: Suravee Suthikulpanit 
> CC: Wei Liu 

SVM maintainers, ping?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [libvirt test] 102469: regressions - FAIL

[osstest service owner]

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 regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 102443
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 102443
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 102443

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass

version targeted for testing:
 libvirt  8158a19fd78947f0ee9d2e485225bac6eed68af5
baseline version:
 libvirt  112b0959447906a9d9f352b3eb430ec2d5deb9ad

Last test of basis   102443  2016-11-20 04:21:32 Z1 days
Testing same since   102469  2016-11-21 04:22:18 Z0 days1 attempts


People who touched revisions under test:
  Martin Kletzander 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit 8158a19fd78947f0ee9d2e485225bac6eed68af5
Author: Martin Kletzander 
Date:   Sun Nov 20 21:46:21 2016 +0100

util: Print pid_t as long long

After commit f2bf5fbb0449, MinGW strikes again.  Simply print pid as any
other place after commit b7d2d4af2bd5.

Signed-off-by: Martin Kletzander 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V4] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

[Andrii Anisov]

> 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 adjust benchmarking settings to make the comparison fairer.
BTW, what about communication between DomU and the external network
through the hw interface?

Sincerely,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [distros-debian-sid test] 68072: tolerable FAIL

[Platform Team regression test user]

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-amd64-sid-netboot-pygrub  9 debian-di-install  fail like 68032
 test-amd64-i386-i386-sid-netboot-pvgrub  9 debian-di-install   fail like 68032
 test-armhf-armhf-armhf-sid-netboot-pygrub  9 debian-di-install fail like 68032
 test-amd64-amd64-amd64-sid-netboot-pvgrub  9 debian-di-install fail like 68032

baseline version:
 flight   68032

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  fail
 test-amd64-i386-amd64-sid-netboot-pygrub fail
 test-armhf-armhf-armhf-sid-netboot-pygrubfail
 test-amd64-amd64-i386-sid-netboot-pygrub fail



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Error regarding filesystem in Dom0 in lager board

[Andrii Anisov]

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" earlier. But it could be you case.

Sincerely,
Andrii Anisov.


On Sun, Nov 20, 2016 at 5:44 PM, George John  wrote:
> Hi,
>
>
> On Sat, Nov 19, 2016 at 3:06 AM, Julien Grall  wrote:
>>
>>
>>
>> On 16/11/2016 11:23, George John wrote:
>>>
>>> Hi,
>>
>>
>> Hello George,
>>
>>> I just bumped in to some errors related to filesystem . The following is
>>> the log. I am using xen 4.7.1 along with linux kernel 3.19.8 as Dom0
>>
>>
>> [...]
>>
>>> sh_mobile_sdhi sh_mobile_sdhi.0: mmc1 base at 0xee10 clock rate 97
>>> MHz
>>> ata1: link resume succeeded after 1 retries
>>> ata1: SATA link down (SStatus 0 SControl 300)
>>> sh_mobile_sdhi sh_mobile_sdhi.2: mmc2 base at 0xee14 clock rate 48
>>> MHz
>>> asoc-simple-card asoc-simple-card: ak4642-hifi <-> rcar_sound mapping ok
>>> input: gpio-keys as /devices/platform/gpio-keys/input/input0
>>> �H�EXT4-fs (mmcblk0p1): error count since last fsck: 24
>>> EXT4-fs (mmcblk0p1): initial error at time 11: mb_free_blocks:1450:
>>> inode 67523: block 296960
>>> EXT4-fs (mmcblk0p1): last error at time 10: ext4_free_inode:340
>>
>>
>> It looks like the filesystem is corrupted. Have you tried to verify the
>> filesystem with fsck?
>
>
> No, I haven't verified the filesystem. But the filesystem is working with no
> problems for native linux. Also Network file system( working with native
> linux) is not working when linux is running above xen. So I assumed it may
> be the problem with accessibility of hardware by linux when running above
> the hypervisor.
>
>>>
>>>
>>> After this the system hangs
>>
>>
>> Do you mean that even Xen is becoming inaccessible?
>>
>> You can try to switch to the Xen console by type 3-times "CTRL-a". You
>> should see a message from Xen telling you it has switched to Xen. If it
>> works, then only DOM0 is hanging.
>
>
> Yes, I have tried that. Xen is also becoming inaccessible. Nothing works
> after the system hang.
>
>>
>>
>> Regards,
>>
>> --
>> Julien Grall
>
>
>
> Regards,
> George
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
>

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable test] 102465: tolerable FAIL

[osstest service owner]

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-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
pass in 102439

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 102439
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 102439
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 102439
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 102439
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 102439
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 102439
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 102439
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 102439
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 102439

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  58bd0c7985890e0292212f94a56235228a3445c3
baseline version:
 xen  58bd0c7985890e0292212f94a56235228a3445c3

Last test of basis   102465  2016-11-21 01:58:00 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17126 days0 attempts

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvops   

[Xen-devel] [ovmf test] 102474: all pass - PUSHED

[osstest service owner]

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 3cabe66b2065980d5084d5823404834e266efe66

Last test of basis   102470  2016-11-21 04:36:21 Z0 days
Testing same since   102474  2016-11-21 09:44:02 Z0 days1 attempts


People who touched revisions under test:
  Eric Dong 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=ovmf
+ revision=01dd077315c6759c94af9af4232f8318db13cf8d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
01dd077315c6759c94af9af4232f8318db13cf8d
+ branch=ovmf
+ revision=01dd077315c6759c94af9af4232f8318db13cf8d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x01dd077315c6759c94af9af4232f8318db13cf8d = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.gi

Re: [Xen-devel] [XTF PATCH v3] Add a Live Patch privilege check test

[Andrew Cooper]

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
> index 9dca3e3..0a2b311 100644
> --- a/common/lib.c
> +++ b/common/lib.c
> @@ -19,6 +19,21 @@ void __noreturn panic(const char *fmt, ...)
>  arch_crash_hard();
>  }
>  
> +int xtf_probe_sysctl_interface_version(void)
> +{
> +int i;
> +xen_sysctl_t op = {0};

This breaks the build on Clang.  Using { .cmd = 0 } instead is fine.

> +
> +for ( i = 0; i < 128; i++ )
> +{
> +op.interface_version = i;
> +if ( hypercall_sysctl(&op) != -EACCES )
> +return i;
> +}
> +
> +return -1;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tests/livepatch-priv-check/Makefile 
> b/tests/livepatch-priv-check/Makefile
> new file mode 100644
> index 000..e27b9da
> --- /dev/null
> +++ b/tests/livepatch-priv-check/Makefile
> @@ -0,0 +1,9 @@
> +include $(ROOT)/build/common.mk
> +
> +NAME  := livepatch-priv-check
> +CATEGORY  := functional
> +TEST-ENVS := $(ALL_ENVIRONMENTS)

I have dropped this down to pv32pae pv64 hvm32 hvm64

The hvm32pse and hvm32pae environments are an identical ABI to hvm32, so
there is no point testing them all.  The multiple paging options for
32bit HVM guests is only useful for testing pagetable related code.

~Andrew

> +
> +obj-perenv += main.o
> +
> +include $(ROOT)/build/gen.mk


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline test] 102468: regressions - FAIL

[osstest service owner]

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-libvirt-vhd  9 debian-di-installfail REGR. vs. 101909
 test-amd64-amd64-libvirt 11 guest-start  fail REGR. vs. 101909
 test-amd64-amd64-libvirt-xsm 11 guest-start  fail REGR. vs. 101909
 test-amd64-amd64-libvirt-pair 20 guest-start/debian  fail REGR. vs. 101909
 test-armhf-armhf-xl-vhd   9 debian-di-installfail REGR. vs. 101909
 test-amd64-i386-libvirt-pair 20 guest-start/debian   fail REGR. vs. 101909
 test-armhf-armhf-libvirt-xsm 11 guest-start  fail REGR. vs. 101909
 test-amd64-i386-libvirt  11 guest-start  fail REGR. vs. 101909
 test-amd64-i386-libvirt-xsm  11 guest-start  fail REGR. vs. 101909
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install  fail REGR. vs. 101909
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail REGR. vs. 101909
 test-armhf-armhf-libvirt 11 guest-start  fail REGR. vs. 101909

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101909
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101909
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101909

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuud93b1fb009b64333d324a2fe76fe805f2ac2cda4
baseline version:
 qemuu199a5bde46b0eab898ab1ec591f423000302569f

Last test of basis   101909  2016-11-03 23:21:40 Z   17 days
Failing since101943  2016-11-04 22:40:48 Z   16 days   37 attempts
Testing same since   102436  2016-11-19 22:13:58 Z1 days5 attempts


People who touched revisions under test:
  Alberto Garcia 
  Ankit Kumar 
  ann.zhuangyany...@huawei.com
  Ashijeet Acharya 
  Balbir singh 
  Bharata B Rao 
  Brian Candler 
  Christian Borntraeger 
  Cornelia Huck 
  Cédric Le Goater 
  Daniel Oram 
  Daniel P. Berrange 
  David Gibson 
  Doug Evans 
  Eduardo Habkost 
  Eric Blake 
  Fam Zheng 
  Gautham R. Shenoy 
  Gerd Hoffmann 
  Gonglei 
  Greg Kurz 
  Halil Pasic 
  Igor Mammedov 
  Jason Wang 
  Jeff Cody 
  John Snow 
  Jose Ricardo Ziviani 
  Juan Quintela 
  Julian Brown 
  Kevin Wolf 
  Ladi Prosek 
  Laurent Vivier 
  Li Qiang 
  Marc-André Lureau 
  Marcel Apfelbaum 
  Marcin Krzeminski 
  Max Reitz 
  Michael S. Tsirkin 
  Michael Tokarev 
  Nikunj A Dadhania 
  Olaf Hering 
  Paolo Bonzini 
  Peter Korsgaard 
  Peter Maydell 
  Peter Xu 
  Prasad J Pandit 
  Rafael David Tinoco 
  Richard Henderson 
  Samuel Thibault 
  Sander Eikelenboom 
  Stefan Hajnoczi 
  Stefano Stabellini 
  Thomas Huth 
  Tomáš Golembiovský 
  Vladimir Sementsov-Ogievskiy 
  Wei Liu 
  Xiao Guangrong 
  Yuri Benditovich 
  Zhang Chen 
  zhanghailiang 
  Zhuang Yanying 
  ZhuangYanying 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  

[Xen-devel] [xtf test] 102478: all pass - PUSHED

[osstest service owner]

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  bd2a670f858314d28413ca577bb96ee249c4877d

Last test of basis   102385  2016-11-18 13:43:46 Z2 days
Testing same since   102478  2016-11-21 12:13:01 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ross Lagerwall 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xtf
+ revision=1f1aa2c0914818798cdfc1d61014343dad961eed
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xtf 
1f1aa2c0914818798cdfc1d61014343dad961eed
+ branch=xtf
+ revision=1f1aa2c0914818798cdfc1d61014343dad961eed
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xtf
+ xenbranch=xen-unstable
+ '[' xxtf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x1f1aa2c0914818798cdfc1d61014343dad961eed = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/li

Re: [Xen-devel] Xen virtual IOMMU high level design doc V3

[Julien Grall]

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-PCI emulated devices for arm in Qemu which need to be covered by
vIOMMU?


We don't use QEMU on ARM so far, so I guess it should be ok for now. ARM 
guests are very similar to hvmlite/pvh. I got confused and thought this 
design document was targeting pvh too.


BTW, in the design document you mention hvmlite/pvh. Does it mean you 
plan to bring support of vIOMMU for those guests later on?


Regards,


--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Can't always start 32 bit domains after 64 bit domains

[Andrew Cooper]

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
 domUs, regardless of what order the domUs are started in.
>>> You don't clarify what you base this understanding of yours on; I don't
>>> think this is the case. What exact memory will be allocated for 64-bit
>>> guests isn't very predictable. In particular, the preference of allocating
>>> 1Gb pages as long as available may result in allocations eating into the
>>> low 128Gb of memory earlier than you expect. You may want to analyze
>>> system state by looking at debug key output at relevant points in time.
>> Because whenever I read about the 168GiB limit and 32 bit domains there was 
>> no mention that the initial 128GiB might not all be available if there
>> were also 64 bit domains. Given how little visibility there typically is 
>> into where memory is physically allocated, there is no way to know this
>> doesn't work as a normal user until it doesn't. Are you saying all Xen users 
>> have to be developers too?
> No, I'm not saying this, but please note that you didn't post the
> question on xen-users, but xen-devel.
>
>> In my opinion this is a bug until/unless it's very clearly documented that 
>> it's not supported behavior to mix 32 and 64 bit PV domains when there is
>> more than 168GiB RAM, or maybe just period if that's too complicated to 
>> explain to people. I don't know where to find that documentation. It seems
>> like https://wiki.xenproject.org/wiki/Xen_Project_Release_Features might be 
>> the right place, I'm not sure. If you know of a better place I'd love to 
>> know.
> I view this as a bug too, fwiw. Me previously bringing up the topic
> didn't result in any activity though, presumably because 32-bit
> guests are being considered rare enough these days.
>
>>> 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 I wanted to add that, where would it go?
> I don't know, that's a question for xl folks I guess.

IIRC, given no other constraints, the Xen heap allocation allocates from
the top down to help this exact case.

I suspect that libxl's preference towards NUMA allocation of domains
interferes with this, by adding a NUMA constraints to memory allocations
for 64bit PV guests.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.8] x86/svm: Fix svm_nextrip_insn_length() when crossing the virtual boundary to 0

[Boris Ostrovsky]

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 do we need to complain? In the case that you are addressing by this
patch wouldn't that be the expected result (length>15)?

-boris


>>
>> While making changes here, fix two whitespace issues with the case labels.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Boris Ostrovsky 
>> CC: Suravee Suthikulpanit 
>> CC: Wei Liu 
> SVM maintainers, ping?


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen virtual IOMMU high level design doc V3

[Andrew Cooper]

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 has been translated by vIOMMU and return back
> Qemu. Before vIOMMU tells invalidation completed, it's necessary to make
> sure in-fly DMA operation is completed.
>
> When IOMMU driver invalidates IOTLB, it also will wait until the
> invalidation completion. We may use this to drain in-fly DMA operation
> for virtual device.
>
> Guest triggers invalidation operation and trip into vIOMMU in
> hypervisor to flush cache data. After this, it should go to Qemu to
> drain in-fly DMA translation.
>
> To do that, dummy vIOMMU in Qemu registers the same MMIO region as
> vIOMMU's and emulation part of invalidation operation in Xen hypervisor
> returns X86EMUL_UNHANDLEABLE after flush cache. MMIO emulation part is
> supposed to send event to Qemu and dummy vIOMMU get a chance to starts a
> thread to drain in-fly DMA and return emulation done.
>
> Guest polls IVT(invalidate IOTLB) bit in the IOTLB invalidate register
> until it's cleared after triggering invalidation. Dummy vIOMMU in Qemu
> notifies hypervisor drain operation completed via hypercall, vIOMMU
> clears IVT bit and guest finish invalidation operation.

Having the guest poll will be very inefficient.  If the invalidation
does need to reach qemu, it will be a very long time until it
completes.  Is there no interrupt based mechanism which can be used? 
That way the guest can either handle it asynchronous itself, or block
waiting on an interrupt, both of which are better than having it just
spinning.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.8] x86/svm: Fix svm_nextrip_insn_length() when crossing the virtual boundary to 0

[Andrew Cooper]

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
>>> and use x86_decode_insn() as a fallback.
> Why do we need to complain? In the case that you are addressing by this
> patch wouldn't that be the expected result (length>15)?

No.  An instruction crossing the boundary looks like:

e.g. nextrip = 0x3, rip = 0xfffe

As this is all evaluated in unsigned long arithmetic, nextrip - rip
evaluates to 5, which is correct.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.8] x86/svm: Fix svm_nextrip_insn_length() when crossing the virtual boundary to 0

[Boris Ostrovsky]

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, complain if the reported length is greater 
 than 15
 and use x86_decode_insn() as a fallback.
>> Why do we need to complain? In the case that you are addressing by this
>> patch wouldn't that be the expected result (length>15)?
> No.  An instruction crossing the boundary looks like:
>
> e.g. nextrip = 0x3, rip = 0xfffe
>
> As this is all evaluated in unsigned long arithmetic, nextrip - rip
> evaluates to 5, which is correct.

Oh, right.

Reviewed-by: Boris Ostrovsky 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4] xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing

[Boris Ostrovsky]

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_user_pages_locked
__get_user_pages_unlocked
get_user_pages_fast
iov_iter_get_pages
dio_refill_pages
do_direct_IO
do_blockdev_direct_IO
do_blockdev_direct_IO
ext4_direct_IO_read
generic_file_read_iter
aio_run_iocb

(which can happen if guest's vdisk has direct-io-safe option).

To avoid this let's use VM_MIXEDMAP flag instead --- it prevents
NUMA balancing just as VM_IO does and has no effect on
check_vma_flags().

Reported-by: Olaf Hering 
Suggested-by: Hugh Dickins 
Signed-off-by: Boris Ostrovsky 
---
 drivers/xen/gntdev.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index bb95212..2ef2b61 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -1007,7 +1007,7 @@ static int gntdev_mmap(struct file *flip, struct 
vm_area_struct *vma)
 
vma->vm_ops = &gntdev_vmops;
 
-   vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP | VM_IO;
+   vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP | VM_MIXEDMAP;
 
if (use_ptemod)
vma->vm_flags |= VM_DONTCOPY;
-- 
1.7.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 3/3] build system: Also copy ipxe.tar.gz

[Konrad Rzeszutek Wilk]

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,11 @@ if [ -d $xen_root/tools/firmware/ovmf-dir-remote ]; then
 git_archive_into $xen_root/tools/firmware/ovmf-dir-remote 
$tdir/xen-$desc/tools/firmware/ovmf-dir
 cp $xen_root/tools/firmware/ovmf-makefile 
$tdir/xen-$desc/tools/firmware/ovmf-dir/Makefile
 fi
+
+if [ -e $xen_root/tools/firmware/etherboot/ipxe.tar.gz ]; then
+cp $xen_root/tools/firmware/etherboot/ipxe.tar.gz 
$tdir/xen-$desc/tools/firmware/etherboot/
+fi
+
 GZIP=-9v tar cz -f $xen_root/dist/xen-$desc.tar.gz -C $tdir xen-$desc
 
 echo "Source tarball in $xen_root/dist/xen-$desc.tar.gz"
-- 
2.9.3


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Patch "x86/mm/xen: Suppress hugetlbfs in PV guests" (CVE-2016-3961) is missing in 3.4, 3.10 and 3.12 stable tree

[Thomas Deutschmann]

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
> From: Jan Beulich 
> Date: Thu, 21 Apr 2016 00:27:04 -0600
> Subject: x86/mm/xen: Suppress hugetlbfs in PV guests
> 
> Huge pages are not normally available to PV guests. Not suppressing
> hugetlbfs use results in an endless loop of page faults when user mode
> code tries to access a hugetlbfs mapped area (since the hypervisor
> denies such PTEs to be created, but error indications can't be
> propagated out of xen_set_pte_at(), just like for various of its
> siblings), and - once killed in an oops like this:
> 
>   kernel BUG at .../fs/hugetlbfs/inode.c:428!
>   invalid opcode:  [#1] SMP
>   ...
>   RIP: e030:[]  [] 
> remove_inode_hugepages+0x25b/0x320
>   ...
>   Call Trace:
>[] hugetlbfs_evict_inode+0x15/0x40
>[] evict+0xbd/0x1b0
>[] __dentry_kill+0x19a/0x1f0
>[] dput+0x1fe/0x220
>[] __fput+0x155/0x200
>[] task_work_run+0x60/0xa0
>[] do_exit+0x160/0x400
>[] do_group_exit+0x3b/0xa0
>[] get_signal+0x1ed/0x470
>[] do_signal+0x14/0x110
>[] prepare_exit_to_usermode+0xe9/0xf0
>[] retint_user+0x8/0x13
> 
> This is CVE-2016-3961 / XSA-174.
> 
> Reported-by: Vitaly Kuznetsov 
> Signed-off-by: Jan Beulich 
> Cc: Andrew Morton 
> Cc: Andy Lutomirski 
> Cc: Boris Ostrovsky 
> Cc: Borislav Petkov 
> Cc: Brian Gerst 
> Cc: David Vrabel 
> Cc: Denys Vlasenko 
> Cc: H. Peter Anvin 
> Cc: Juergen Gross 
> Cc: Linus Torvalds 
> Cc: Luis R. Rodriguez 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Cc: Toshi Kani 
> Cc: sta...@vger.kernel.org
> Cc: xen-devel 
> Link: 
> http://lkml.kernel.org/r/57188ed80278000e4...@prv-mh.provo.novell.com
> Signed-off-by: Ingo Molnar 

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=103f6112f253017d7062cd74d17f4a514ed4485c


-- 
Regards,
Thomas



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PULL 0/1] tags/xen-20161108-tag

[Stefan Hajnoczi]

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 repository at:
> 
> 
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20161108-tag
> 
> for you to fetch changes up to 804ba7c10bbc66bb8a8aa73ecc60f620da7423d5:
> 
>   xen: Fix xenpv machine initialisation (2016-11-08 11:17:30 -0800)
> 
> 
> Xen 2016/11/08
> 
> 
> Anthony PERARD (1):
>   xen: Fix xenpv machine initialisation
> 
>  xen-common.c | 6 --
>  xen-hvm.c| 4 
>  2 files changed, 4 insertions(+), 6 deletions(-)

Thanks, applied to my staging tree:
https://github.com/stefanha/qemu/commits/staging

Stefan


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] x86/hvm: Fix non-debug build folling c/s 0745f665a5

[Andrew Cooper]

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 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/emulate.c b/xen/arch/x86/hvm/svm/emulate.c
index ca670bf..2b47db9 100644
--- a/xen/arch/x86/hvm/svm/emulate.c
+++ b/xen/arch/x86/hvm/svm/emulate.c
@@ -98,8 +98,8 @@ int __get_instruction_length_from_list(struct vcpu *v,
  */
 #ifdef NDEBUG
 if ( (inst_len = svm_nextrip_insn_length(v)) > MAX_INST_LEN )
-gprintk(XENLOG_WARNING, "NRip reported insn_len %lu\n", insn_len);
-else if ( insn_len != 0 )
+gprintk(XENLOG_WARNING, "NRip reported insn_len %lu\n", inst_len);
+else if ( inst_len != 0 )
 return inst_len;
 
 if ( vmcb->exitcode == VMEXIT_IOIO )
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [libvirt] Opinions on removing the old, legacy libvirt Xen driver

[Neal Gompa]

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 from the libvirt sources?
>
> The Xen community made xl/libxl the primary toolstack in Xen 4.1. In Xen
> 4.2, it was made the default toolstack. In Xen 4.5, xm/xend was completely
> removed from the Xen source tree. According to the Xen release support
> matrix [0], upstream maintenance of Xen 4.1-4.3 has been dropped for some
> time, including "long term" security support. Xen 4.4-4.5 no longer receive
> regular maintenance support, with security support ending in March for 4.4
> and January 2018 for 4.5. In short, the fully maintained upstream Xen
> releases don't even contain xm/xend :-).
>
> As for downstreams, I doubt anyone is interested in running the last several
> libvirt releases on an old Xen installition with xm/xend, let alone
> libvirt.git master. SUSE, which still supports Xen, has no interest in using
> a new libvirt on older (but still supported) SLES that uses the xm/xend
> toolstack. I struggle to find a good reason to keep any of the old cruft
> under src/xen/. I do think we should keep the xm/sexpr config
> parsing/formatting code src/xenconfig/ since it is useful for converting old
> xm and sexpr config to libvirt domXML.
>
> Thanks for opinions and comments!
>
> Regards,
> Jim
>
> [0] https://wiki.xenproject.org/wiki/Xen_Project_Release_Features
>

For what it's worth, I totally agree with this proposal, as it will
make it less confusing to identify what you actually need for
Xen-based virtualization.

As an aside, I recently attempted to set up a Xen based system using
libvirt on Fedora, and I was initially confused by the two drivers,
and completely messed up my setup because of it. I think simply from a
usability point of view, it makes a lot of sense to eliminate the old
code and set up the libxl driver to be the "successor" of the old xen
driver.



-- 
真実はいつも一つ！/ Always, there's only one truth!

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [libvirt] Opinions on removing the old, legacy libvirt Xen driver

[Daniel P. Berrange]

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
> driver from the libvirt sources?
> 
> The Xen community made xl/libxl the primary toolstack in Xen 4.1. In Xen
> 4.2, it was made the default toolstack. In Xen 4.5, xm/xend was completely
> removed from the Xen source tree. According to the Xen release support
> matrix [0], upstream maintenance of Xen 4.1-4.3 has been dropped for some
> time, including "long term" security support. Xen 4.4-4.5 no longer receive
> regular maintenance support, with security support ending in March for 4.4
> and January 2018 for 4.5. In short, the fully maintained upstream Xen
> releases don't even contain xm/xend :-).
> 
> As for downstreams, I doubt anyone is interested in running the last several
> libvirt releases on an old Xen installition with xm/xend, let alone
> libvirt.git master. SUSE, which still supports Xen, has no interest in using
> a new libvirt on older (but still supported) SLES that uses the xm/xend
> toolstack. I struggle to find a good reason to keep any of the old cruft
> under src/xen/. I do think we should keep the xm/sexpr config
> parsing/formatting code src/xenconfig/ since it is useful for converting old
> xm and sexpr config to libvirt domXML.
> 
> Thanks for opinions and comments!

As a point of reference, for the QEMU/KVM driver we took the decision to drop
support for distros whose age is older than RHEL-6 (Nov 2010 release date).
Xen 4.1 came out in early 2011 IIUC, so dropping support for Xen < 4.1 is
a reasonable thing todo and consistent with what we've done for QEMU. So
ACK to that from a project support POV.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Patch "x86/mm/xen: Suppress hugetlbfs in PV guests" (CVE-2016-3961) is missing in 3.4, 3.10 and 3.12 stable tree

[Willy Tarreau]

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 Thomas.

Willy

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH RESEND] OvmfPkg/build.sh: Use GCC49 toolchain with GCC 6.*

[Konrad Rzeszutek Wilk]

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 100755
--- a/OvmfPkg/build.sh
+++ b/OvmfPkg/build.sh
@@ -95,7 +95,7 @@ case `uname` in
   4.8.*)
 TARGET_TOOLS=GCC48
 ;;
-  4.9.*|4.1[0-9].*|5.*.*)
+  4.9.*|4.1[0-9].*|5.*.*|6.*.*)
 TARGET_TOOLS=GCC49
 ;;
   *)
-- 
2.9.3


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH RESEND] Fix TianoCore building under Fedora Core 25

[Konrad Rzeszutek Wilk]

(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) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

And currently there are no runes for it - which means it falls back
to GCC44 and fails to build.

The patch fixes that.

Thanks!


Konrad Rzeszutek Wilk (1):
  OvmfPkg/build.sh: Use GCC49 toolchain with GCC 6.*


 OvmfPkg/build.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/hvm: Fix non-debug build folling c/s 0745f665a5

[Boris Ostrovsky]

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
> in.  My appologies.
> ---
>  xen/arch/x86/hvm/svm/emulate.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/svm/emulate.c b/xen/arch/x86/hvm/svm/emulate.c
> index ca670bf..2b47db9 100644
> --- a/xen/arch/x86/hvm/svm/emulate.c
> +++ b/xen/arch/x86/hvm/svm/emulate.c
> @@ -98,8 +98,8 @@ int __get_instruction_length_from_list(struct vcpu *v,
>   */
>  #ifdef NDEBUG
>  if ( (inst_len = svm_nextrip_insn_length(v)) > MAX_INST_LEN )
> -gprintk(XENLOG_WARNING, "NRip reported insn_len %lu\n", insn_len);
> -else if ( insn_len != 0 )
> +gprintk(XENLOG_WARNING, "NRip reported insn_len %lu\n", inst_len);

Since you are fixing this up anyway, insn_let in format string should
also be updated.

With that,
Reviewed-by: Boris Ostrovsky 


> +else if ( inst_len != 0 )
>  return inst_len;
>  
>  if ( vmcb->exitcode == VMEXIT_IOIO )


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [ovmf baseline-only test] 68074: all pass

[Platform Team regression test user]

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 version:
 ovmf 6a62309459e36d59e4cfe14885fa3ed807841c62

Last test of basis68071  2016-11-21 04:49:31 Z0 days
Testing same since68074  2016-11-21 09:16:17 Z0 days1 attempts


People who touched revisions under test:
  Star Zeng 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


commit 3cabe66b2065980d5084d5823404834e266efe66
Author: Star Zeng 
Date:   Fri Nov 18 10:58:35 2016 +0800

SecurityPkg Tcg2Pei: Add comments into LogHashEvent()

Add comments into LogHashEvent() to describe the usage
of GetDigestListSize (DigestList).

Cc: Jiewen Yao 
Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 

commit a9f1b2e2d708ed98aa47d576a81d947dc7b79fac
Author: Star Zeng 
Date:   Wed Nov 16 17:17:36 2016 +0800

SecurityPkg Tcg2Dxe: Get correct digest list size

Current code uses GetDigestListSize(DigestList) to get
digest list size, that is incorrect.
The code should get digest list size of digests copied
into event2 log, those digests are compacted, so
GetDigestListBinSize() should be used.

Cc: Jiewen Yao 
Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 

commit ab5b1f31c2dae23835b9b49d0fe58e14133ba4e8
Author: Star Zeng 
Date:   Thu Nov 17 16:54:15 2016 +0800

SecurityPkg Tcg2Dxe: Filter inactive digest in event2 log from PEI HOB

Cc: Jiewen Yao 
Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by : Chao Zhang 
Reviewed-by: Jiewen Yao 

commit ae1a4284a03764609de8b2b1b81667b3e50ff145
Author: Star Zeng 
Date:   Fri Nov 18 09:54:21 2016 +0800

SecurityPkg TPM2: Update desc for param Buffer of GetDigestListSize()

To make the description more clear, update the description
for parameter Buffer of GetDigestListSize() to
"Buffer to hold copied TPML_DIGEST_VALUES compact binary.".

Cc: Jiewen Yao 
Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by : Chao Zhang 
Reviewed-by: Jiewen Yao 

commit b8ae1f4de75260f48e1459692bac0d1b84246cc1
Author: Star Zeng 
Date:   Fri Nov 18 13:13:21 2016 +0800

SecurityPkg TPM2: Add GetHashMaskFromAlgo() into Tpm2CommandLib

Add GetHashMaskFromAlgo() into Tpm2CommandLib for coming consumer.

Cc: Jiewen Yao 
Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by : Chao Zhang 
Reviewed-by: Jiewen Yao 

commit 697c30b157c90c9c1a6c6610d73a49e4f5fd56b3
Author: Star Zeng 
Date:   Thu Nov 17 16:41:08 2016 +0800

SecurityPkg TPM2: Make IsHashAlgSupportedInHashAlgorithmMask external

Current IsHashAlgSupportedInHashAlgorithmMask is only an internal
function, this patch makes it external for coming consumer.

Cc: Jiewen Yao 
Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 
Reviewed-by : Chao Zhang 

commit be93a17bbd1e8dd83904653aec17728641d67048
Author: Star Zeng 
Date:   Wed Nov 16 17:17:36 2016 +0800

SecurityPkg TPM2: Assign real copied count in CopyDigestListToBuffer()

In CopyDigestListToBuffer() of Tpm2CommandLib, the count in returned
Buffer should be real copied Digest

Re: [Xen-devel] [edk2] [PATCH RESEND] OvmfPkg/build.sh: Use GCC49 toolchain with GCC 6.*

[Ard Biesheuvel]

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(-)
>
> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
> index eb5eb73..759ade3 100755
> --- a/OvmfPkg/build.sh
> +++ b/OvmfPkg/build.sh
> @@ -95,7 +95,7 @@ case `uname` in
>4.8.*)
>  TARGET_TOOLS=GCC48
>  ;;
> -  4.9.*|4.1[0-9].*|5.*.*)
> +  4.9.*|4.1[0-9].*|5.*.*|6.*.*)
>  TARGET_TOOLS=GCC49
>  ;;
>*)

I think it may be time to start using GCC5 for 5.x and later

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] [PATCH RESEND] OvmfPkg/build.sh: Use GCC49 toolchain with GCC 6.*

[Konrad Rzeszutek Wilk]

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 
> > ---
> >  OvmfPkg/build.sh | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
> > index eb5eb73..759ade3 100755
> > --- a/OvmfPkg/build.sh
> > +++ b/OvmfPkg/build.sh
> > @@ -95,7 +95,7 @@ case `uname` in
> >4.8.*)
> >  TARGET_TOOLS=GCC48
> >  ;;
> > -  4.9.*|4.1[0-9].*|5.*.*)
> > +  4.9.*|4.1[0-9].*|5.*.*|6.*.*)
> >  TARGET_TOOLS=GCC49
> >  ;;
> >*)
> 
> I think it may be time to start using GCC5 for 5.x and later

This did the trick as well.

I don't have GCC 5.*.* so I could not confirm.

diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
index 759ade3..4d0d0d4 100755
--- a/OvmfPkg/build.sh
+++ b/OvmfPkg/build.sh
@@ -95,9 +95,12 @@ case `uname` in
   4.8.*)
 TARGET_TOOLS=GCC48
 ;;
-  4.9.*|4.1[0-9].*|5.*.*|6.*.*)
+  4.9.*|4.1[0-9].*|5.*.*)
 TARGET_TOOLS=GCC49
 ;;
+  6.*.*)
+TARGET_TOOLS=GCC5
+;;
   *)
 TARGET_TOOLS=GCC44
 ;;


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/hvm: Fix non-debug build folling c/s 0745f665a5

[Wei Liu]

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 Suthikulpanit 
> >
> > I definitely fixed this once duing development, but it clearly slipped back
> > in.  My appologies.
> > ---
> >  xen/arch/x86/hvm/svm/emulate.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/xen/arch/x86/hvm/svm/emulate.c b/xen/arch/x86/hvm/svm/emulate.c
> > index ca670bf..2b47db9 100644
> > --- a/xen/arch/x86/hvm/svm/emulate.c
> > +++ b/xen/arch/x86/hvm/svm/emulate.c
> > @@ -98,8 +98,8 @@ int __get_instruction_length_from_list(struct vcpu *v,
> >   */
> >  #ifdef NDEBUG
> >  if ( (inst_len = svm_nextrip_insn_length(v)) > MAX_INST_LEN )
> > -gprintk(XENLOG_WARNING, "NRip reported insn_len %lu\n", insn_len);
> > -else if ( insn_len != 0 )
> > +gprintk(XENLOG_WARNING, "NRip reported insn_len %lu\n", inst_len);
> 
> Since you are fixing this up anyway, insn_let in format string should
> also be updated.
> 
> With that,
> Reviewed-by: Boris Ostrovsky 
> 

Release-acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

[Iurii Mykhalskyi]

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 Xen 4.8 support in nearly future.

With the best regards,
Iurii Mykhalskyi


On Thu, Nov 10, 2016 at 11:34 AM, Dirk Behme 
wrote:

> On 10.11.2016 10:25, Iurii Mykhalskyi wrote:
>
>> Hello Dirk,
>>
>> On Thu, Nov 10, 2016 at 8:54 AM, Dirk Behme > > wrote:
>>
>> On 09.11.2016 13:14, Julien Grall wrote:
>>
>> Hello,
>>
>> On 09/11/16 07:14, Dirk Behme wrote:
>>
>> On 08.11.2016 16:41, Iurii Mykhalskyi wrote:
>>
>> Hello Dirk,
>>
>> I have made only single change - I recompile ATF to
>> leave CPU in EL2
>> mode and reflash it.
>>
>>
>>
>> Yes, this is what I meant with 'modifying firmware' ;)
>>
>> You are loading Xen with U-Boot running in EL2, then?
>>
>> With this modification, do all other use cases still work?
>> E.g. load and
>> boot U-Boot and native Linux kernel without Xen?
>>
>>
>> Yes, when Linux is booting from EL2, it will drop to EL1 (see
>> el2_setup). As Andre mentioned on the previous thread, U-boot is
>> running
>> at EL2 on various board (e.g pine64, juno).
>>
>> Modifying the firmware was the right way to go as there is no
>> solution
>> go boot at EL2 from EL1.
>>
>>
>>
>> Yes, correct, from general point of view :)
>>
>> My question to Iurii is more focused to this concrete board, if
>> there everything works fine, too. You know, sometimes the
>> implementation on a board might have bugs while it should work well
>> in theory ;)
>>
>> So I'm just interested if everything works fine for him switching
>> ATF to exit in EL2, or if additional fixes/patches are needed for
>> this board.
>>
>>
>> Looks like all basic functions working normally - I have successfully
>> load linux & rootfs without any additional patches for linux kernel.
>>
>
>
> Ok, thanks for this info :)
>
>
> As you ok with this - I will create Salvator-X board related page on Xen
>> wiki.
>> But first of all, I will update yocto layer mentioned by Andrii with
>> minimal setup, based on the latest Renesas & Xen releases.
>> This should be helpful for easier out of box board setup.
>>
>
>
> Ack
>
> Best regards
>
> Dirk
>
>
>


-- 

Iurii Mykhalskyi | Senior Software Engineer
GlobalLogic
P +38.044.492.9695x3664  M +38.096.311.5467  S mad-nemoi
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-smoke test] 102485: tolerable all pass - PUSHED

[osstest service owner]

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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  0745f665a575bdb6724f6ec1ab767cd71ba8c253
baseline version:
 xen  58bd0c7985890e0292212f94a56235228a3445c3

Last test of basis   102390  2016-11-18 16:01:20 Z3 days
Testing same since   102485  2016-11-21 16:00:54 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=0745f665a575bdb6724f6ec1ab767cd71ba8c253
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
0745f665a575bdb6724f6ec1ab767cd71ba8c253
+ branch=xen-unstable-smoke
+ revision=0745f665a575bdb6724f6ec1ab767cd71ba8c253
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x0745f665a575bdb6724f6ec1ab767cd71ba8c253 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmwar

[Xen-devel] [xtf test] 102487: all pass - PUSHED

[osstest service owner]

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  1f1aa2c0914818798cdfc1d61014343dad961eed

Last test of basis   102478  2016-11-21 12:13:01 Z0 days
Testing same since   102487  2016-11-21 16:19:03 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xtf
+ revision=e10e74e48495bfb7e023d0397b625b14364d4422
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xtf 
e10e74e48495bfb7e023d0397b625b14364d4422
+ branch=xtf
+ revision=e10e74e48495bfb7e023d0397b625b14364d4422
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xtf
+ xenbranch=xen-unstable
+ '[' xxtf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xe10e74e48495bfb7e023d0397b625b14364d4422 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x 

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

[Julien Grall]

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-xen

Please review & leave your comments.

I am planning to update this layer with Xen 4.8 support in nearly future.


I am a bit confused here. I like the idea of having yocto building 
everything for you, but at the same time you hide the fact that Xen is 
not an upstream version (you carry more patches [1]). Does it mean this 
patch (early console support) is not sufficient to get Xen working on 
the board?


Also, it is not clear to me why you need a specific device tree and 
hacked DOM0 linux (see [2]) on this board for Xen. This would need some 
documentation on the wiki.


Regards,

[1] 
https://github.com/qbeeukraine/meta-platform-xen/tree/2.12/minimal/meta-rcar-gen3-xen/recipes-extended/xen/xen
[2] 
https://github.com/qbeeukraine/meta-platform-xen/tree/2.12/minimal/meta-rcar-gen3-xen/recipes-kernel/linux/linux-renesas/patches


--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Wondering about cirris and stdvga

[Stefano Stabellini]

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 ; Roger Pau
> > Monne 
> > Subject: Re: [Xen-devel] Wondering about cirris and stdvga
> > 
> > On Fri, Nov 18, 2016 at 07:04:15PM +0100, Dario Faggioli wrote:
> > > Sending again, this time, with Anthony's and xen-devel address spelled
> > > right. Sorry!! :-(
> > > ---
> > > Hello to you, various pseudo-random people,
> > >
> > > It's not my field of expertise, so bear with me, at least a little bit
> > > (and, Konrad, you help me, or there will be consequences! :-D)
> > >
> > > So, I and Konrad recently discovered --while testing the about to be
> > > released Fedora 25 as a Xen guest-- that the Cirrus emulated graphic
> > > card that we consume from QEMU for HVM guests is broken on Wayland.
> > >
> > > We just discovered it because Fedora 25 uses Wayland by default, but it
> > > appears not to be something new:
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1227770
> > >
> > > And at least from what we see in that bugreport, not much has happened
> > > so far.
> > >
> > > Using "vga='stdvga'" in the config file, or even "vga='qxl'" make
> > > things work again. Disabling Wayland in the guest also works (i.e., if
> > > not using Wayland, Cirrus is ok). And that's what made us think that
> > > it's probably a Wayland issue.
> > >
> > > I've tried the same on KVM, and the situation is identical
> > > (Cirrus+Wayland=breaks, whatever-else+Wayland=works,
> > > Cirrus+Xorg=works).
> > >
> > > I've also read around that these days, e.g., stdvga is at least as good
> > > as cirrus, performance wise, that cirrus is broken and impossible to
> > > fix (because it is the hardware that it's emulating that was broken),
> > > that stdvga enables better screen resolution in guests, etc.
> > >
> > > I'm not sure about these claims, in particular the performance one, is
> > > probably pretty hard to verify. And as I said, it's not my field.
> > >
> > > Still I thought it could be worthwhile to at least bring this up:
> > > should we start to consider changing the default from cirrus to stdvga
> > > (or something else)?
> > >
> > 
> > There's multiple things here..
> > 
> > 1) Yes, +1, let's change the Xen HVM default to "stdvga".
> > 
> 
> In general std-vga also gets a +1 from me, but I have recently found that a 
> Windows Server 2008 guest does not boot (ar at least the display freezes on 
> boot) when using std-vga with QEMU trad but everything is fine with Cirrus... 
> so probably worth making the default dependent on which QEMU is being used. 
> Never had any issues with std-vga on upstream QEMU.

In all fairness, I think it's worth mentioning that the original reason
for defaulting to Cirrus was that Windows XP wasn't able to boot on
stdvga either.___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V4] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

[Stefano Stabellini]

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 involving hardware
> interfaces.
> 
> > I am happy to adjust benchmarking settings to make the comparison fairer.
> BTW, what about communication between DomU and the external network
> through the hw interface?

Unfortunately I don't have the HW to do that test at the moment, but I
would be interested in seeing the numbers.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 0/4] xed: add qdevs for each backend, correct pvUSB

[Stefano Stabellini]

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 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
> possible the pvUSB controller has to be a hotpluggable qemu device.
> 
> This is achieved by adding a qdev for each Xen backend all attached to
> a new Xen specific bus.
> 
> Changes in V2:
> - one qdev for each backend instead of pvUSB only
> 
> Juergen Gross (4):
>   xen: add an own bus for xen backend devices
>   qdev: add function qdev_set_id()
>   xen: create qdev for each backend device
>   xen: attach pvusb usb bus to backend qdev
> 
>  hw/usb/xen-usb.c | 23 +++
>  hw/xen/xen_backend.c | 67 
> +---
>  hw/xen/xen_pvdev.c   |  5 +++-
>  include/hw/xen/xen_backend.h |  8 ++
>  include/hw/xen/xen_pvdev.h   |  1 +
>  include/monitor/qdev.h   |  1 +
>  qdev-monitor.c   | 36 +---
>  7 files changed, 107 insertions(+), 34 deletions(-)


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [OSSTEST PATCH v7 2/3] ts-openstack-tempest: Run Tempest to check OpenStack

[Anthony PERARD]

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 4.0 
> > is the
> > +# first Linux to have a fix.
> 
> What fix? Would it make sense to point this out? Also  I am going to
> assume the 'server' and 'client' are guests, and 'server' is not dom0?

It was a patch series, I don't know if I can find it again. I thought
pointing to a release was enough.

I think iSCSI have other terms for 'server' and 'client', maybe 'target'
and something else. But those two sides are running in dom0, in this
test.

> > +push @ignored_tests,
> > +"^\Q${volume_boot_pattern}V2.test_volume_boot_pattern\E";
> > +push @ignored_tests,
> > +
> > "^\Q${volume_boot_pattern}V2.test_create_ebs_image_and_check_boot\E";
> > +
> > +# This regex below select the tests to run and exclude the ones marked 
> > as
> > +# slow as well as the explicit tests listed above.  It is based on the 
> > one
> > +# that can be found in tempest.git/tox.ini in the section 
> > [testenv:full].
> > +my $ignored_tests = join("|", @ignored_tests);
> > +my $regex =
> > +
> > "(?!.*\\[.*\\bslow\\b.*\\]|$ignored_tests)(^tempest\\.(api|scenario|thirdparty))";
> > +
> > +target_cmd($ho, < > +  $builddir/tempest/run_tempest.sh --virtual-env -- --concurrency=2 
> > '$regex'
> 
> 
> How come you are hardcoding 2?

By default, this number is equal to the number of cpus. I think it would
be too much, and increase the failure rate of openstack it self, which I
don't think it would be usefull to test.

For their CI loop, I think this is equal to half the number of cpus. We
could do that but I don't know if it's going to be usefull.

We do use 2 on the XenProject OpenStack CI loop, because I don't think
it can do more than that.

-- 
Anthony PERARD

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 3/7] ts-xen-build: Install livepatch regressions tests. [and 1 more messages]

[Konrad Rzeszutek Wilk]

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.
> 
> > +buildcmd_stamped_logged(600, 'xen', 'tests-install', '',< > $dokconfig;
> 
> Can you keep the lines down to 75 characters or less please ?
> 
> > +if test -d xen/test; then
> > +   mkdir -p dist/install/usr/lib/debug
> > +   livepatch_files=`find xen/test/livepatch -name '*.livepatch' 
> > -print`
> > +   cp \$livepatch_files dist/install/usr/lib/debug
> 
> Should this not be in the xen.git Makefiles ?

Jan didn't like it (as part of the normal 'install' stanza).

I could add it in xen/test/Makefile, but I had a hard time executing
anything inside 'xen' sub-directories by themselves, aka:

 make -C xen/test install

As the 'xen/test/livepatch/Makefile' does:
include $(XEN_ROOT)/Config.mk

(and other) and the XEN_ROOT is not available unless you run it from
within 'xen' directory.

Which means I would have to add a new top-level target, such as:

 make -C xen test_install

or such. But then it is not exactly sure where one would install
the "tests"? /usr/lib/debug? /usr/lib/xen/debug/ ?

I figured it would be easier if it was left unimplemented and folks
just copied the files out of there.

 
> 
> Also, the result of this is that the tests end up in the tools output
> because you haven't fixed `divide'.  Background: each osstest
> invocation of ts-xen-build produces two primary deliverables: `' and
> `xen' aka `dist' and `xendist'.
> 
> I think, but I'm not sure, that these patches contain hypervisor code
> and should be in `xendist'.

In the cover letter you mentioned that it may be good to have an
xenlptdist.tar.gz which would only contain the livepatch test-cases.

And then we could use the existence of that file as a check for
the hypervisor having the support?

If I squash this patch in this one:

diff --git a/ts-xen-build b/ts-xen-build
index 1b36b9c..1137947 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -170,11 +170,11 @@ END
 $make_prefix make -C xen tests
 fi
 END
-buildcmd_stamped_logged(600, 'xen', 'tests-install', '',< 
> Thanks,
> Ian.
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen virtual IOMMU high level design doc V3

[Stefano Stabellini]

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 called by Qemu. I am not familiar with ARM. Are there any
> > non-PCI emulated devices for arm in Qemu which need to be covered by
> > vIOMMU?
> 
> We don't use QEMU on ARM so far, so I guess it should be ok for now. ARM
> guests are very similar to hvmlite/pvh. I got confused and thought this design
> document was targeting pvh too.
> 
> BTW, in the design document you mention hvmlite/pvh. Does it mean you plan to
> bring support of vIOMMU for those guests later on?

I quickly went through the document. I don't think we should restrict
the design to only one caller: QEMU. In fact it looks like those
hypercalls, without any modifications, could be called from the
toolstack (xl/libxl) in the case of PVH guests. In other words
PVH guests might work without any addition efforts on the hypervisor
side.

And they might even work on ARM. I have a couple of suggestions to
make the hypercalls a bit more "future proof" and architecture agnostic.

Imagine a future where two vIOMMU versions are supported. We could have
a uint32_t iommu_version field to identify what version of IOMMU we are
creating (create_iommu and query_capabilities commands). This could be
useful even on Intel platforms.

Given that in the future we might support a vIOMMU that take ids other
than sbdf as input, I would change "u32 vsbdf" into the following:

  #define XENVIOMMUSPACE_vsbdf  0
  uint16_t space;
  uint64_t id;

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline test] 102482: regressions - FAIL

[osstest service owner]

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-libvirt-vhd  9 debian-di-installfail REGR. vs. 101909
 test-amd64-amd64-libvirt 11 guest-start  fail REGR. vs. 101909
 test-amd64-amd64-libvirt-xsm 11 guest-start  fail REGR. vs. 101909
 test-amd64-amd64-libvirt-pair 20 guest-start/debian  fail REGR. vs. 101909
 test-armhf-armhf-xl-vhd   9 debian-di-installfail REGR. vs. 101909
 test-amd64-i386-libvirt-pair 20 guest-start/debian   fail REGR. vs. 101909
 test-armhf-armhf-libvirt-xsm 11 guest-start  fail REGR. vs. 101909
 test-amd64-i386-libvirt  11 guest-start  fail REGR. vs. 101909
 test-amd64-i386-libvirt-xsm  11 guest-start  fail REGR. vs. 101909
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install  fail REGR. vs. 101909
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail REGR. vs. 101909
 test-armhf-armhf-libvirt 11 guest-start  fail REGR. vs. 101909

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101909
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101909
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101909

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuud93b1fb009b64333d324a2fe76fe805f2ac2cda4
baseline version:
 qemuu199a5bde46b0eab898ab1ec591f423000302569f

Last test of basis   101909  2016-11-03 23:21:40 Z   17 days
Failing since101943  2016-11-04 22:40:48 Z   16 days   38 attempts
Testing same since   102436  2016-11-19 22:13:58 Z1 days6 attempts


People who touched revisions under test:
  Alberto Garcia 
  Ankit Kumar 
  ann.zhuangyany...@huawei.com
  Ashijeet Acharya 
  Balbir singh 
  Bharata B Rao 
  Brian Candler 
  Christian Borntraeger 
  Cornelia Huck 
  Cédric Le Goater 
  Daniel Oram 
  Daniel P. Berrange 
  David Gibson 
  Doug Evans 
  Eduardo Habkost 
  Eric Blake 
  Fam Zheng 
  Gautham R. Shenoy 
  Gerd Hoffmann 
  Gonglei 
  Greg Kurz 
  Halil Pasic 
  Igor Mammedov 
  Jason Wang 
  Jeff Cody 
  John Snow 
  Jose Ricardo Ziviani 
  Juan Quintela 
  Julian Brown 
  Kevin Wolf 
  Ladi Prosek 
  Laurent Vivier 
  Li Qiang 
  Marc-André Lureau 
  Marcel Apfelbaum 
  Marcin Krzeminski 
  Max Reitz 
  Michael S. Tsirkin 
  Michael Tokarev 
  Nikunj A Dadhania 
  Olaf Hering 
  Paolo Bonzini 
  Peter Korsgaard 
  Peter Maydell 
  Peter Xu 
  Prasad J Pandit 
  Rafael David Tinoco 
  Richard Henderson 
  Samuel Thibault 
  Sander Eikelenboom 
  Stefan Hajnoczi 
  Stefano Stabellini 
  Thomas Huth 
  Tomáš Golembiovský 
  Vladimir Sementsov-Ogievskiy 
  Wei Liu 
  Xiao Guangrong 
  Yuri Benditovich 
  Zhang Chen 
  zhanghailiang 
  Zhuang Yanying 
  ZhuangYanying 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  

[Xen-devel] [ovmf baseline-only test] 68075: all pass

[Platform Team regression test user]

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 version:
 ovmf 3cabe66b2065980d5084d5823404834e266efe66

Last test of basis68074  2016-11-21 09:16:17 Z0 days
Testing same since68075  2016-11-21 16:49:08 Z0 days1 attempts


People who touched revisions under test:
  Eric Dong 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


commit 01dd077315c6759c94af9af4232f8318db13cf8d
Author: Eric Dong 
Date:   Mon Nov 21 14:38:31 2016 +0800

SecurityPkg OpalPasswordDxe: Clean PSID buffer.

Change callback handler type to avoid saving PSID info in
browser temp buffer. Also clean the buffer after using it.

Cc: Feng Tian 
Reviewed-by: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 

commit bee13c00218f3ed3118d8d87683c11b31ca04564
Author: Eric Dong 
Date:   Wed Nov 16 14:15:29 2016 +0800

SecurityPkg OpalPasswordDxe: Clean password buffer.

Cc: Feng Tian 
Reviewed-by: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 

commit bda034c34deea6eb43edcef28018a9ace8f04637
Author: Eric Dong 
Date:   Thu Jun 2 15:20:30 2016 +0800

SecurityPkg Tcg2Config: Remove the empty options.

The BlockSID actions not has code related to
them. Now we implement the BlockSID feature in
OpalPasswordDxe driver. So remove these actions
here.

Reviewed-by: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 

commit 9de81c126c9a75807ee9a89752349af450d0be77
Author: Eric Dong 
Date:   Thu Jun 2 15:20:17 2016 +0800

SecurityPkg OpalPasswordDxe: Use PP actions to enable BlockSID.

Update the implementation, use physical presence defined actions to
update the BlockSid related status.

Reviewed-by: Jiewen Yao 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 

commit 177dca331f8ebf5cde4d0df14988e47b5fb25877
Author: Eric Dong 
Date:   Mon Nov 14 14:47:41 2016 +0800

SecurityPkg TcgSmm: Enable Storage actions.

After enable storage related actions in the
TcgPhysicalPresenceStorageLib, use this library to support
storage related actions in this driver.

Reviewed-by: Jiewen Yao 
Reviewed-by: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 

commit 509b0fe35807d1a51a8c5bee6321a0ea7e2c17b9
Author: Eric Dong 
Date:   Wed Nov 16 13:45:21 2016 +0800

SecurityPkg SmmTcg2PhysicalPresenceLib: Enable Storage actions.

After enable storage related actions in the
TcgPhysicalPresenceStorageLib, use this library to support
storage related actions in this library.

Reviewed-by: Jiewen Yao 
Reviewed-by: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 

commit 182d8208a4b0cf52fad839ba58d6fecae35b467c
Author: Eric Dong 
Date:   Thu Jun 2 15:17:59 2016 +0800

SecurityPkg DxeTcgPhysicalPresenceLib: Enable Storage actions.

After enable storage related actions in the
TcgPhysicalPresenceStorageLib, use this library to support
storage related actions in this library.

Reviewed-by: Jiewen Yao 
Reviewed-by: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 

commit d6b02b79b0fa2b10a0315f9c1de8ea10efdbc23b
Author: Eric Dong 
Date:   Thu Jun 2 15:17:42 2016 +0800

SecurityPkg DxeTcg2PhysicalPres

[Xen-devel] [seabios test] 102484: tolerable FAIL - PUSHED

[osstest service owner]

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-amd64 16 guest-stopfail like 101716

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 seabios  b98c6586c0c3d519359d6e751ecb3e637e82dbcb
baseline version:
 seabios  d7adf6044a4c772b497e97272adf97426b34a249

Last test of basis   101716  2016-10-27 11:03:12 Z   25 days
Testing same since   102484  2016-11-21 15:44:01 Z0 days1 attempts


People who touched revisions under test:
  Igor Mammedov 
  Kevin O'Connor 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=seabios
+ revision=b98c6586c0c3d519359d6e751ecb3e637e82dbcb
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push seabios 
b98c6586c0c3d519359d6e751ecb3e637e82dbcb
+ branch=seabios
+ revision=b98c6586c0c3d519359d6e751ecb3e637e82dbcb
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xb98c6586

[Xen-devel] [xtf test] 102488: all pass - PUSHED

[osstest service owner]

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  e10e74e48495bfb7e023d0397b625b14364d4422

Last test of basis   102487  2016-11-21 16:19:03 Z0 days
Testing same since   102488  2016-11-21 17:48:17 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xtf
+ revision=36431397ac902e791e16a016ade3413bd6b63069
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xtf 
36431397ac902e791e16a016ade3413bd6b63069
+ branch=xtf
+ revision=36431397ac902e791e16a016ade3413bd6b63069
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xtf
+ xenbranch=xen-unstable
+ '[' xxtf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x36431397ac902e791e16a016ade3413bd6b63069 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x 

Re: [Xen-devel] [PATCH v1 5/7] ts-livepatch: Initial test-cases.

[Konrad Rzeszutek Wilk]

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 we go through all of the test-cases.

Thank you!

Let me answer only to some as I am fixing the rest per your comments:
> 
> Is it ever possible to continue with the rest of the livepatch tests
> after one of these command invocations has failed, or does it leave
> the system in an undefined state ?  If it _is_ possible then it would

If the invocations have failed that could mean: 
 - We don't have livepatching enabled (somebody swapped the hypervisor?)
 - The livepatching did not work right and we have code in the
   hypervisor that patched something else. Undefined results.
 - It may be that the test-case failed to load due to dependencies
   issues - and while that means the system can recover - the test
   should fail immediately.

> be possible to provide per-step results to osstest, but that's only
> valuable if this would tell us something meaningfully interesting in
> terms of regressions - eg if we might tolerate a regression of one
> step but still care about the others.

At this stage I believe all of these test-cases should work. If they
don't we got big problems.
..
> > +   {cmd => "xen-livepatch revert xen_hello_world", rc => 256},
> 
> libxl exit statuses are not very good and should not be relied on,
> really.  Instead, you should arrange to:

But this is not libxl. The error values are very much defined
by xen-livepatch.

>   * Run the command with LC_MESSAGES=C

Aye.
>   * Fail the test if the exit status is zero

But some of the test-cases are suppose to return 0 - as the program
executed correctly.

>   * Collect its stderr output (by appending 2>&1)
>   * Match the stderr output against a regexp in the perl program

Right.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Can't always start 32 bit domains after 64 bit domains

[Sarah Newman]

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 I wanted to add that, where would it go?
>> I don't know, that's a question for xl folks I guess.
> 
> IIRC, given no other constraints, the Xen heap allocation allocates from
> the top down to help this exact case.

Yes, that's what I thought it did too, though I can't find my source 
information for that.

> 
> I suspect that libxl's preference towards NUMA allocation of domains
> interferes with this, by adding a NUMA constraints to memory allocations
> for 64bit PV guests.

I ran xl info -n (which I didn't know about before) and that shows the problem 
much more clearly.

If that's the reason not all the higher memory is being used first: is a 
potential workaround to pin 64 bit domains to the second physical core on
boot, and 32 bit domains to the first physical core on boot, and then change 
the allowed cores with 'xl vcpu-pin' after the domain is loaded?

Thanks, Sarah

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

[Edgar E. Iglesias]

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 Fri, 11 Nov 2016, Julien Grall wrote:
> > > > > > On 11/11/2016 02:24, Stefano Stabellini wrote:
> > > > > > > On Thu, 10 Nov 2016, Julien Grall wrote:
> > > > > > > > (CC Stefano and change the title)
> > > > > > > > On 10/11/16 12:13, casionwoo wrote:
> > > > > > > > > I’m pleased about your reply and you have a lot of code to
> > > > > > > > > clean-up.
> > > > > > > > > 
> > > > > > > > > As you mentioned, It’s really huge to digest at once. Thank 
> > > > > > > > > you
> > > > > > > > > for
> > > > > > > > > understanding me.
> > > > > > > > > 
> > > > > > > > > And that’s why i need a small fix up and todo list.
> > > > > > > > > 
> > > > > > > > > I feel familiar with ARM and c language and there’s no 
> > > > > > > > > specific
> > > > > > > > > area
> > > > > > > > > yet.
> > > > > > > > > 
> > > > > > > > > I think that i can find interesting area with following up the
> > > > > > > > > codes.
> > > > > > > > > 
> > > > > > > > > I’m looking forward to being stuck on Xen.
> > > > > > > > > 
> > > > > > > > > Then it would be easier for me to understand about Xen on ARM.
> > > > > > > > > 
> > > > > > > > > Please let me know the TODO and bug-fix lists.
> > > > > > > > 
> > > > > > > > Stefano, before giving a list of code clean-up, do you have any
> > > > > > > > small
> > > > > > > > TODO
> > > > > > > > on
> > > > > > > > ARM in mind?
> > > > > > > 
> > > > > > > A simple task we talked about recently is to enable the vuart
> > > > > > > (xen/arch/arm/vuart.c) for all guests. At the moment it is only
> > > > > > > emulated
> > > > > > > for Dom0, but some guests, in particular BareMetal guests
> > > > > > > (https://en.wikipedia.org/wiki/BareMetal), would benefit from it.
> > > > > > > 
> > > > > > > It would be best to introduce an option in libxl to explicitly
> > > > > > > enable/disable the vuart for DomUs. Something like vuart=1 in the 
> > > > > > > VM
> > > > > > > config file.
> > > > > > 
> > > > > > The vuart has not been enabled for DomU because it the UART region 
> > > > > > may
> > > > > > clash
> > > > > > with the guest memory layout (which is static).
> > > > > > 
> > > > > > I don't think this option should be available until we allow the 
> > > > > > guest
> > > > > > to
> > > > > > use
> > > > > > the same memory layout as the host (see e820_host parameter for 
> > > > > > x86).
> > > > > 
> > > > > Actually there is no reason for the vuart to use the same address as
> > > > > the physical uart on the platform, is there?
> > > > > In fact it doesn't even
> > > > > have to prentend to be the same uart as the one on the board, right?
> > > > > The vuart MMIO address could be completely configurable and 
> > > > > independent
> > > > > from the one of the physical uart.
> > > > 
> > > > There is no reason to use the same information as the physical UART.
> > > > 
> > > > However, the vuart requires quite a few information (e.g base address,
> > > > offset
> > > > of different register... see vuart_info structure in 
> > > > include/xen/serial.h
> > > > for
> > > > more details) in order to fully work.
> > > > 
> > > > IHMO this is a lot of works for the user to configure. I would much 
> > > > prefer
> > > > to
> > > > see a PL011 emulated at a specific base address and let the user select
> > > > whether he wants a UART to debug or not.
> > > 
> > > So you envision the configuration of the MMIO base address to be done as
> > > part of a new dynamic guest memory map?
> > 
> > For guest using dynamic memory map, I would expect to expose an uncompleted
> > emulation of the physical UART (e.g it would only be possible to write) at 
> > the
> > exact same address as on the host.
> 
> Why? Is this a requirement for baremetal guests?
> 
> I would have actually opted for always emulating a PL011 even for guests
> using a dynamic memory map (which of course one way or another need to
> be able to choose the address of the UART, the memory and the rest).

I guess it's not black and white but trying to reduce the gap towards
being able to run unmodified SW for a given platform as a guest would
be nice.

Some times things are quite relaxed and we can recompile the SW for Xen,
add new drivers etc. Other times perhaps SW has been certified and users
may not be able to change anything.

For apps where the UARTs are only used for console data, vuarts at
configurable locations would be nice IMO.

Cheers,
Edgar

> 
> 
> > For guest using static memory map (i.e the current approach), I would 
> > envision
> > to always emulate a PL011 (or at least giving this option) and not the
> > physical UART.
> > 
> > This has a better fit with the support of SBSA/VM Spec compliant guest and
> > still allow a user 

Re: [Xen-devel] [edk2] [PATCH RESEND] OvmfPkg/build.sh: Use GCC49 toolchain with GCC 6.*

[Laszlo Ersek]

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 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
>> index eb5eb73..759ade3 100755
>> --- a/OvmfPkg/build.sh
>> +++ b/OvmfPkg/build.sh
>> @@ -95,7 +95,7 @@ case `uname` in
>>4.8.*)
>>  TARGET_TOOLS=GCC48
>>  ;;
>> -  4.9.*|4.1[0-9].*|5.*.*)
>> +  4.9.*|4.1[0-9].*|5.*.*|6.*.*)
>>  TARGET_TOOLS=GCC49
>>  ;;
>>*)
> 
> I think it may be time to start using GCC5 for 5.x and later

I agree.

We have an open BZ for this:

https://bugzilla.tianocore.org/show_bug.cgi?id=62

Olaf Hering submitted a patch around June, but the formalities on those
patches weren't right, and Olaf decided not to submit further versions
of the patch.

Here's the idea:
- change the catch-all (*) to GCC5, from GCC44
- remove the (5.*.*) pattern from GCC49
- add a branch (with multiple patterns if necessary) for gcc-4.3 and
  earlier to exit with an error message / failure (those compiler
  versions are unsupported)

Konrad, can you please submit a v2 with this? If so, please add the tag

Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=62

as well, just before the "Contributed-under:" tag.

(Side note: we haven't been ignoring BZ#62. It's just that after
reviewing Olaf's original patch, implementing the change -- which is
very simple and cannot really be done in different ways -- in his stead
would have practically consisted of replacing Olaf's signoff with
someone elses, and we couldn't do that.)

Thank you,
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-smoke test] 102490: tolerable all pass - PUSHED

[osstest service owner]

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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  f678e2c78110e73431217306bbd33c736802d700
baseline version:
 xen  0745f665a575bdb6724f6ec1ab767cd71ba8c253

Last test of basis   102485  2016-11-21 16:00:54 Z0 days
Testing same since   102490  2016-11-21 18:01:03 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=f678e2c78110e73431217306bbd33c736802d700
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
f678e2c78110e73431217306bbd33c736802d700
+ branch=xen-unstable-smoke
+ revision=f678e2c78110e73431217306bbd33c736802d700
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' xf678e2c78110e73431217306bbd33c736802d700 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmwar

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

[Stefano Stabellini]

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:
> > > > > On 11/11/2016 13:55, Stefano Stabellini wrote:
> > > > > > On Fri, 11 Nov 2016, Julien Grall wrote:
> > > > > > > On 11/11/2016 02:24, Stefano Stabellini wrote:
> > > > > > > > On Thu, 10 Nov 2016, Julien Grall wrote:
> > > > > > > > > (CC Stefano and change the title)
> > > > > > > > > On 10/11/16 12:13, casionwoo wrote:
> > > > > > > > > > I’m pleased about your reply and you have a lot of code to
> > > > > > > > > > clean-up.
> > > > > > > > > > 
> > > > > > > > > > As you mentioned, It’s really huge to digest at once. Thank 
> > > > > > > > > > you
> > > > > > > > > > for
> > > > > > > > > > understanding me.
> > > > > > > > > > 
> > > > > > > > > > And that’s why i need a small fix up and todo list.
> > > > > > > > > > 
> > > > > > > > > > I feel familiar with ARM and c language and there’s no 
> > > > > > > > > > specific
> > > > > > > > > > area
> > > > > > > > > > yet.
> > > > > > > > > > 
> > > > > > > > > > I think that i can find interesting area with following up 
> > > > > > > > > > the
> > > > > > > > > > codes.
> > > > > > > > > > 
> > > > > > > > > > I’m looking forward to being stuck on Xen.
> > > > > > > > > > 
> > > > > > > > > > Then it would be easier for me to understand about Xen on 
> > > > > > > > > > ARM.
> > > > > > > > > > 
> > > > > > > > > > Please let me know the TODO and bug-fix lists.
> > > > > > > > > 
> > > > > > > > > Stefano, before giving a list of code clean-up, do you have 
> > > > > > > > > any
> > > > > > > > > small
> > > > > > > > > TODO
> > > > > > > > > on
> > > > > > > > > ARM in mind?
> > > > > > > > 
> > > > > > > > A simple task we talked about recently is to enable the vuart
> > > > > > > > (xen/arch/arm/vuart.c) for all guests. At the moment it is only
> > > > > > > > emulated
> > > > > > > > for Dom0, but some guests, in particular BareMetal guests
> > > > > > > > (https://en.wikipedia.org/wiki/BareMetal), would benefit from 
> > > > > > > > it.
> > > > > > > > 
> > > > > > > > It would be best to introduce an option in libxl to explicitly
> > > > > > > > enable/disable the vuart for DomUs. Something like vuart=1 in 
> > > > > > > > the VM
> > > > > > > > config file.
> > > > > > > 
> > > > > > > The vuart has not been enabled for DomU because it the UART 
> > > > > > > region may
> > > > > > > clash
> > > > > > > with the guest memory layout (which is static).
> > > > > > > 
> > > > > > > I don't think this option should be available until we allow the 
> > > > > > > guest
> > > > > > > to
> > > > > > > use
> > > > > > > the same memory layout as the host (see e820_host parameter for 
> > > > > > > x86).
> > > > > > 
> > > > > > Actually there is no reason for the vuart to use the same address as
> > > > > > the physical uart on the platform, is there?
> > > > > > In fact it doesn't even
> > > > > > have to prentend to be the same uart as the one on the board, right?
> > > > > > The vuart MMIO address could be completely configurable and 
> > > > > > independent
> > > > > > from the one of the physical uart.
> > > > > 
> > > > > There is no reason to use the same information as the physical UART.
> > > > > 
> > > > > However, the vuart requires quite a few information (e.g base address,
> > > > > offset
> > > > > of different register... see vuart_info structure in 
> > > > > include/xen/serial.h
> > > > > for
> > > > > more details) in order to fully work.
> > > > > 
> > > > > IHMO this is a lot of works for the user to configure. I would much 
> > > > > prefer
> > > > > to
> > > > > see a PL011 emulated at a specific base address and let the user 
> > > > > select
> > > > > whether he wants a UART to debug or not.
> > > > 
> > > > So you envision the configuration of the MMIO base address to be done as
> > > > part of a new dynamic guest memory map?
> > > 
> > > For guest using dynamic memory map, I would expect to expose an 
> > > uncompleted
> > > emulation of the physical UART (e.g it would only be possible to write) 
> > > at the
> > > exact same address as on the host.
> > 
> > Why? Is this a requirement for baremetal guests?
> > 
> > I would have actually opted for always emulating a PL011 even for guests
> > using a dynamic memory map (which of course one way or another need to
> > be able to choose the address of the UART, the memory and the rest).
> 
> I guess it's not black and white but trying to reduce the gap towards
> being able to run unmodified SW for a given platform as a guest would
> be nice.
> 
> Some times things are quite relaxed and we can recompile the SW for Xen,
> add new drivers etc. Other times perhaps SW has been certified and users
> may not be able to change anything.
> 
> For apps where the UARTs are only used for console data,

[Xen-devel] [PATCH v3 04/11] acpi: Make pmtimer optional in FADT

[Boris Ostrovsky]

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 +
 tools/libacpi/libacpi.h | 1 +
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 6e0cfe7..1d78973 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -948,7 +948,8 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
 if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
 config->table_flags |= ACPI_HAS_SSDT_S4;
 
-config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC | ACPI_HAS_WAET);
+config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC |
+ACPI_HAS_WAET | ACPI_HAS_PMTIMER);
 
 config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
 
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index 47dae01..e1fd381 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -574,6 +574,11 @@ int acpi_build_tables(struct acpi_ctxt *ctxt, struct 
acpi_config *config)
 
 fadt = ctxt->mem_ops.alloc(ctxt, sizeof(struct acpi_20_fadt), 16);
 if (!fadt) goto oom;
+if ( !(config->table_flags & ACPI_HAS_PMTIMER) )
+{
+Fadt.pm_tmr_blk = Fadt.pm_tmr_len = 0;
+memset(&Fadt.x_pm_tmr_blk, 0, sizeof(Fadt.x_pm_tmr_blk));
+}
 memcpy(fadt, &Fadt, sizeof(struct acpi_20_fadt));
 fadt->dsdt   = ctxt->mem_ops.v2p(ctxt, dsdt);
 fadt->x_dsdt = ctxt->mem_ops.v2p(ctxt, dsdt);
diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
index 1d388f9..bda692e 100644
--- a/tools/libacpi/libacpi.h
+++ b/tools/libacpi/libacpi.h
@@ -30,6 +30,7 @@
 #define ACPI_HAS_TCPA(1<<7)
 #define ACPI_HAS_IOAPIC  (1<<8)
 #define ACPI_HAS_WAET(1<<9)
+#define ACPI_HAS_PMTIMER (1<<10)
 
 struct xen_vmemrange;
 struct acpi_numa {
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 03/11] pvh: Set online VCPU map to avail_vcpus

[Boris Ostrovsky]

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 Wilk 
Acked-by: Wei Liu 
---
 tools/libxl/libxl_x86_acpi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_x86_acpi.c b/tools/libxl/libxl_x86_acpi.c
index ff0e2df..949f555 100644
--- a/tools/libxl/libxl_x86_acpi.c
+++ b/tools/libxl/libxl_x86_acpi.c
@@ -98,7 +98,7 @@ static int init_acpi_config(libxl__gc *gc,
 uint32_t domid = dom->guest_domid;
 xc_dominfo_t info;
 struct hvm_info_table *hvminfo;
-int i, rc = 0;
+int rc = 0;
 
 config->dsdt_anycpu = config->dsdt_15cpu = dsdt_pvh;
 config->dsdt_anycpu_len = config->dsdt_15cpu_len = dsdt_pvh_len;
@@ -144,8 +144,8 @@ static int init_acpi_config(libxl__gc *gc,
 hvminfo->nr_vcpus = info.max_vcpu_id + 1;
 }
 
-for (i = 0; i < hvminfo->nr_vcpus; i++)
-hvminfo->vcpu_online[i / 8] |= 1 << (i & 7);
+memcpy(hvminfo->vcpu_online, b_info->avail_vcpus.map,
+   b_info->avail_vcpus.size);
 
 config->hvminfo = hvminfo;
 
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 10/11] pvh: Send an SCI on VCPU hotplug event

[Boris Ostrovsky]

.. 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  |  5 +
 xen/arch/x86/domain.c  | 16 
 xen/common/domctl.c|  1 +
 xen/common/event_channel.c |  7 +--
 xen/include/xen/domain.h   |  1 +
 xen/include/xen/event.h|  8 
 6 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7e43691..19af326 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -549,6 +549,11 @@ void vcpu_destroy(struct vcpu *v)
 free_xenheap_pages(v->arch.stack, STACK_ORDER);
 }
 
+int arch_update_avail_vcpus(struct domain *d)
+{
+return 0;
+}
+
 int arch_domain_create(struct domain *d, unsigned int domcr_flags,
struct xen_arch_domainconfig *config)
 {
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 1bd5eb6..c0c0d4f 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -509,6 +509,22 @@ void vcpu_destroy(struct vcpu *v)
 xfree(v->arch.pv_vcpu.trap_ctxt);
 }
 
+int arch_update_avail_vcpus(struct domain *d)
+{
+/*
+ * For PVH guests we need to send an SCI and set enable/status
+ * bits in GPE block.
+ */
+if ( is_hvm_domain(d) && !has_acpi_ff(d) )
+{
+d->arch.hvm_domain.acpi_io.gpe[2] =
+d->arch.hvm_domain.acpi_io.gpe[0] = 1 << XEN_GPE0_CPUHP_BIT;
+send_guest_global_virq(d, VIRQ_SCI);
+}
+
+return 0;
+}
+
 int arch_domain_create(struct domain *d, unsigned int domcr_flags,
struct xen_arch_domainconfig *config)
 {
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 626f2cb..2ae6a91 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -1179,6 +1179,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
 xfree(d->avail_vcpus);
 d->avail_vcpus = avail_vcpus;
 
+ret = arch_update_avail_vcpus(d);
 break;
 }
 
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 638dc5e..1d77373 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -727,7 +727,7 @@ void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq)
 spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-static void send_guest_global_virq(struct domain *d, uint32_t virq)
+void send_guest_global_virq(struct domain *d, uint32_t virq)
 {
 unsigned long flags;
 int port;
@@ -739,7 +739,10 @@ static void send_guest_global_virq(struct domain *d, 
uint32_t virq)
 if ( unlikely(d == NULL) || unlikely(d->vcpu == NULL) )
 return;
 
-v = d->vcpu[0];
+/* Send to first available VCPU */
+for_each_vcpu(d, v)
+if ( is_vcpu_online(v) )
+break;
 if ( unlikely(v == NULL) )
 return;
 
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index bce0ea1..b386038 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -52,6 +52,7 @@ void vcpu_destroy(struct vcpu *v);
 int map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset);
 void unmap_vcpu_info(struct vcpu *v);
 
+int arch_update_avail_vcpus(struct domain *d);
 int arch_domain_create(struct domain *d, unsigned int domcr_flags,
struct xen_arch_domainconfig *config);
 
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 5008c80..74bd605 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -23,6 +23,14 @@
 void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq);
 
 /*
+ * send_guest_global_virq: Notify guest via a global VIRQ.
+ *  @d:domain to which virtual IRQ should be sent. First
+ * online VCPU will be selected.
+ *  @virq: Virtual IRQ number (VIRQ_*)
+ */
+void send_guest_global_virq(struct domain *d, uint32_t virq);
+
+/*
  * send_global_virq: Notify the domain handling a global VIRQ.
  *  @virq: Virtual IRQ number (VIRQ_*)
  */
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 07/11] pvh/ioreq: Install handlers for ACPI-related PVH IO accesses

[Boris Ostrovsky]

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 
---
CC: Paul Durrant 
---
Changes in v3:
* acpi_ioaccess() returns X86EMUL_UNHANDLEABLE
* Renamed XEN_X86_EMU_IOREQ_CPUHP to XEN_X86_EMU_ACPI_FF (together
  with corresponding has_*())

 xen/arch/x86/hvm/ioreq.c  | 18 ++
 xen/include/asm-x86/domain.h  |  1 +
 xen/include/public/arch-x86/xen.h |  4 +++-
 3 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index d2245e2..51bb399 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -1380,6 +1380,12 @@ static int hvm_access_cf8(
 return X86EMUL_UNHANDLEABLE;
 }
 
+static int acpi_ioaccess(
+int dir, unsigned int port, unsigned int bytes, uint32_t *val)
+{
+return X86EMUL_UNHANDLEABLE;
+}
+
 void hvm_ioreq_init(struct domain *d)
 {
 spin_lock_init(&d->arch.hvm_domain.ioreq_server.lock);
@@ -1387,6 +1393,18 @@ void hvm_ioreq_init(struct domain *d)
 
 if ( !is_pvh_domain(d) )
 register_portio_handler(d, 0xcf8, 4, hvm_access_cf8);
+
+if ( !has_acpi_ff(d) )
+{
+/* Online CPU map, see DSDT's PRST region. */
+register_portio_handler(d, XEN_ACPI_CPU_MAP,
+XEN_ACPI_CPU_MAP_LEN, acpi_ioaccess);
+
+register_portio_handler(d, ACPI_GPE0_BLK_ADDRESS_V1,
+ACPI_GPE0_BLK_LEN_V1, acpi_ioaccess);
+register_portio_handler(d, ACPI_PM1A_EVT_BLK_ADDRESS_V1,
+ACPI_PM1A_EVT_BLK_LEN, acpi_ioaccess);
+}
 }
 
 /*
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index f6a40eb..33f862f 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -425,6 +425,7 @@ struct arch_domain
 #define has_vvga(d)(!!((d)->arch.emulation_flags & XEN_X86_EMU_VGA))
 #define has_viommu(d)  (!!((d)->arch.emulation_flags & XEN_X86_EMU_IOMMU))
 #define has_vpit(d)(!!((d)->arch.emulation_flags & XEN_X86_EMU_PIT))
+#define has_acpi_ff(d) (!!((d)->arch.emulation_flags & 
XEN_X86_EMU_ACPI_FF))
 
 #define has_arch_pdevs(d)(!list_empty(&(d)->arch.pdev_list))
 
diff --git a/xen/include/public/arch-x86/xen.h 
b/xen/include/public/arch-x86/xen.h
index cdd93c1..04c78ec 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -283,12 +283,14 @@ struct xen_arch_domainconfig {
 #define XEN_X86_EMU_IOMMU   (1U<<_XEN_X86_EMU_IOMMU)
 #define _XEN_X86_EMU_PIT8
 #define XEN_X86_EMU_PIT (1U<<_XEN_X86_EMU_PIT)
+#define _XEN_X86_EMU_ACPI_FF9
+#define XEN_X86_EMU_ACPI_FF (1U<<_XEN_X86_EMU_ACPI_FF)
 
 #define XEN_X86_EMU_ALL (XEN_X86_EMU_LAPIC | XEN_X86_EMU_HPET |  \
  XEN_X86_EMU_PM | XEN_X86_EMU_RTC |  \
  XEN_X86_EMU_IOAPIC | XEN_X86_EMU_PIC |  \
  XEN_X86_EMU_VGA | XEN_X86_EMU_IOMMU |   \
- XEN_X86_EMU_PIT)
+ XEN_X86_EMU_PIT | XEN_X86_EMU_ACPI_FF)
 uint32_t emulation_flags;
 };
 #endif
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 05/11] acpi: Power and Sleep ACPI buttons are not emulated for PVH guests

[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/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 1d78973..a3f12fe 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -949,7 +949,8 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
 config->table_flags |= ACPI_HAS_SSDT_S4;
 
 config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC |
-ACPI_HAS_WAET | ACPI_HAS_PMTIMER);
+ACPI_HAS_WAET | ACPI_HAS_PMTIMER |
+ACPI_HAS_BUTTONS);
 
 config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
 
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index e1fd381..4a2e2a9 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -579,6 +579,8 @@ int acpi_build_tables(struct acpi_ctxt *ctxt, struct 
acpi_config *config)
 Fadt.pm_tmr_blk = Fadt.pm_tmr_len = 0;
 memset(&Fadt.x_pm_tmr_blk, 0, sizeof(Fadt.x_pm_tmr_blk));
 }
+if ( !(config->table_flags & ACPI_HAS_BUTTONS) )
+Fadt.flags |= (ACPI_PWR_BUTTON | ACPI_SLP_BUTTON);
 memcpy(fadt, &Fadt, sizeof(struct acpi_20_fadt));
 fadt->dsdt   = ctxt->mem_ops.v2p(ctxt, dsdt);
 fadt->x_dsdt = ctxt->mem_ops.v2p(ctxt, dsdt);
diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
index bda692e..dd6ef8b 100644
--- a/tools/libacpi/libacpi.h
+++ b/tools/libacpi/libacpi.h
@@ -31,6 +31,7 @@
 #define ACPI_HAS_IOAPIC  (1<<8)
 #define ACPI_HAS_WAET(1<<9)
 #define ACPI_HAS_PMTIMER (1<<10)
+#define ACPI_HAS_BUTTONS (1<<11)
 
 struct xen_vmemrange;
 struct acpi_numa {
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 00/11] PVH VCPU hotplug support

[Boris Ostrovsky]

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 (newly added) VIRQ_SCI.

I decided not to implement enforcement of avail_vcpus in this series
after I realized that HVM guests (just like PV) also start all
max_vcpus initially and then offline them
(firmware/hvmloader/smp.c:smp_initialise()). Together with the fact
that HVM hotplug only works in one direction (i.e. adding VCPUs but
not removing them) I think it's pretty clear that hotplug needs to be
fixed in general, and adding avail_vcpus enforcement should be part of that
fix.

I also didn't include changes to getdomaininfo to expanded with getting
number of available vcpus, mostly because I haven't needed it so
far. For live migration (where Andrew thought it might be needed) we
rely on xenstore's "cpu/available" value to keep hypervisor up-to-date
(see libxl__update_avail_vcpus_xenstore()) (I should say that I
haven't tested live migration, only save/restore but I think it's the
same codepath)

Boris Ostrovsky (11):
  x86/domctl: Add XEN_DOMCTL_set_avail_vcpus
  acpi: Define ACPI IO registers for PVH guests
  pvh: Set online VCPU map to avail_vcpus
  acpi: Make pmtimer optional in FADT
  acpi: Power and Sleep ACPI buttons are not emulated for PVH guests
  acpi: PVH guests need _E02 method
  pvh/ioreq: Install handlers for ACPI-related PVH IO accesses
  pvh/acpi: Handle ACPI accesses for PVH guests
  events/x86: Define SCI virtual interrupt
  pvh: Send an SCI on VCPU hotplug event
  docs: Describe PVHv2's VCPU hotplug procedure

 docs/misc/hvmlite.markdown|  12 
 tools/firmware/hvmloader/util.c   |   4 +-
 tools/flask/policy/modules/dom0.te|   2 +-
 tools/flask/policy/modules/xen.if |   4 +-
 tools/libacpi/build.c |   7 +++
 tools/libacpi/libacpi.h   |   2 +
 tools/libacpi/mk_dsdt.c   |  17 +++---
 tools/libacpi/static_tables.c |  20 ++-
 tools/libxc/include/xenctrl.h |   5 ++
 tools/libxc/xc_domain.c   |  12 
 tools/libxl/libxl.c   |   7 +++
 tools/libxl/libxl_dom.c   |   7 +++
 tools/libxl/libxl_x86_acpi.c  |   6 +-
 xen/arch/arm/domain.c |   5 ++
 xen/arch/x86/domain.c |  16 ++
 xen/arch/x86/hvm/ioreq.c  | 103 ++
 xen/common/domctl.c   |  26 +
 xen/common/event_channel.c|   7 ++-
 xen/include/asm-x86/domain.h  |   1 +
 xen/include/asm-x86/hvm/domain.h  |   6 ++
 xen/include/public/arch-x86/xen-mca.h |   2 -
 xen/include/public/arch-x86/xen.h |   7 ++-
 xen/include/public/domctl.h   |   9 +++
 xen/include/public/hvm/ioreq.h|  25 +
 xen/include/xen/domain.h  |   1 +
 xen/include/xen/event.h   |   8 +++
 xen/include/xen/sched.h   |   6 ++
 xen/xsm/flask/hooks.c |   3 +
 xen/xsm/flask/policy/access_vectors   |   2 +
 29 files changed, 299 insertions(+), 33 deletions(-)

-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 08/11] pvh/acpi: Handle ACPI accesses for PVH guests

[Boris Ostrovsky]

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 |  6 +++
 2 files changed, 92 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 51bb399..4ab0d0a 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -16,6 +16,7 @@
  * this program; If not, see .
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -1383,7 +1384,91 @@ static int hvm_access_cf8(
 static int acpi_ioaccess(
 int dir, unsigned int port, unsigned int bytes, uint32_t *val)
 {
-return X86EMUL_UNHANDLEABLE;
+uint8_t *reg = NULL;
+const uint8_t *mask = NULL;
+bool is_cpu_map = false;
+struct domain *currd = current->domain;
+const static uint8_t pm1a_mask[4] = {ACPI_BITMASK_GLOBAL_LOCK_STATUS, 0,
+ ACPI_BITMASK_GLOBAL_LOCK_ENABLE, 0};
+const static uint8_t gpe0_mask[4] = {1U << XEN_GPE0_CPUHP_BIT, 0,
+ 1U << XEN_GPE0_CPUHP_BIT, 0};
+
+BUILD_BUG_ON((ACPI_PM1A_EVT_BLK_LEN != 4) ||
+ (ACPI_GPE0_BLK_LEN_V1 != 4));
+
+ASSERT(!has_acpi_ff(currd));
+
+switch ( port )
+{
+case ACPI_PM1A_EVT_BLK_ADDRESS_V1 ...
+ ACPI_PM1A_EVT_BLK_ADDRESS_V1 + ACPI_PM1A_EVT_BLK_LEN - 1:
+reg = currd->arch.hvm_domain.acpi_io.pm1a;
+mask = pm1a_mask;
+break;
+
+case ACPI_GPE0_BLK_ADDRESS_V1 ...
+ ACPI_GPE0_BLK_ADDRESS_V1 + ACPI_GPE0_BLK_LEN_V1 - 1:
+reg = currd->arch.hvm_domain.acpi_io.gpe;
+mask = gpe0_mask;
+break;
+
+case XEN_ACPI_CPU_MAP ...
+ XEN_ACPI_CPU_MAP + XEN_ACPI_CPU_MAP_LEN - 1:
+is_cpu_map = true;
+break;
+
+default:
+return X86EMUL_UNHANDLEABLE;
+}
+
+if ( bytes == 0 )
+return X86EMUL_OKAY;
+
+if ( dir == IOREQ_READ )
+{
+if ( is_cpu_map )
+{
+unsigned int first_byte = port - XEN_ACPI_CPU_MAP;
+
+/*
+ * Clear bits that we are about to read to in case we
+ * copy fewer than @bytes.
+ */
+*val &= (~((1ULL << (bytes * 8)) - 1)) & 0x;
+
+if ( ((currd->max_vcpus + 7) / 8) > first_byte )
+{
+memcpy(val, (uint8_t *)currd->avail_vcpus + first_byte,
+   min(bytes, ((currd->max_vcpus + 7) / 8) - first_byte));
+}
+}
+else
+memcpy(val, ®[port & 3], bytes);
+}
+else
+{
+unsigned int idx = port & 3;
+unsigned int i;
+uint8_t *ptr;
+
+if ( is_cpu_map )
+/*
+ * CPU map is only read by DSDT's PRSC method and should never
+ * be written by a guest.
+ */
+return X86EMUL_UNHANDLEABLE;
+
+ptr = (uint8_t *)val;
+for ( i = 0; i < bytes; i++, idx++ )
+{
+if ( idx < 2 ) /* status, write 1 to clear. */
+reg[idx] &= ~(mask[i] & ptr[i]);
+else   /* enable */
+reg[idx] |= (mask[i] & ptr[i]);
+}
+}
+
+return X86EMUL_OKAY;
 }
 
 void hvm_ioreq_init(struct domain *d)
diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
index f34d784..f492a2b 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -87,6 +87,12 @@ struct hvm_domain {
 } ioreq_server;
 struct hvm_ioreq_server *default_ioreq_server;
 
+/* PVH guests */
+struct {
+uint8_t pm1a[ACPI_PM1A_EVT_BLK_LEN];
+uint8_t gpe[ACPI_GPE0_BLK_LEN_V1];
+} acpi_io;
+
 /* Cached CF8 for guest PCI config cycles */
 uint32_tpci_cf8;
 
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 02/11] acpi: Define ACPI IO registers for PVH guests

[Boris Ostrovsky]

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_CPU_ACPI_MAP[_LEN] block that lists online VCPUs.

Define XEN_GPE0_CPUHP_BIT which is set in GPE0 on CPU hotplug
event.

Signed-off-by: Boris Ostrovsky 
---
CC: Paul Durrant 
---
Changes in v3:
* Dropped ARM changes (ARM is not using PRST)
* Restored bit offset macros
* Added XEN_ prefix to CPU_ACPI_MAP
* Moved struct hvm_domain.acpi_io definition to later patch
* Made XEN_CPU_ACPI_MAP* definitions conditional
* Added XEN_GPE0_CPUHP_BIT definition
* Simplfied XEN_ACPI_CPU_MAP_LEN definition

 tools/libacpi/mk_dsdt.c|  7 +--
 tools/libacpi/static_tables.c  | 20 ++--
 xen/include/public/hvm/ioreq.h | 25 +
 3 files changed, 36 insertions(+), 16 deletions(-)

diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index 16320a9..6da24fa 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -19,6 +19,7 @@
 #include 
 #if defined(__i386__) || defined(__x86_64__)
 #include 
+#include 
 #elif defined(__aarch64__)
 #include 
 #endif
@@ -244,7 +245,8 @@ int main(int argc, char **argv)
 #endif
 
 /* Operation Region 'PRST': bitmask of online CPUs. */
-stmt("OperationRegion", "PRST, SystemIO, 0xaf00, 32");
+stmt("OperationRegion", "PRST, SystemIO, %#x, %d",
+XEN_ACPI_CPU_MAP, XEN_ACPI_CPU_MAP_LEN);
 push_block("Field", "PRST, ByteAcc, NoLock, Preserve");
 indent(); printf("PRS, %u\n", max_cpus);
 pop_block();
@@ -288,7 +290,8 @@ int main(int argc, char **argv)
 /* Define GPE control method. */
 push_block("Scope", "\\_GPE");
 push_block("Method",
-   dm_version == QEMU_XEN_TRADITIONAL ? "_L02" : "_E02");
+   dm_version == QEMU_XEN_TRADITIONAL ? "_L%02d" : "_E%02d",
+   XEN_GPE0_CPUHP_BIT);
 stmt("\\_SB.PRSC ()", NULL);
 pop_block();
 pop_block();
diff --git a/tools/libacpi/static_tables.c b/tools/libacpi/static_tables.c
index 617bf68..a966333 100644
--- a/tools/libacpi/static_tables.c
+++ b/tools/libacpi/static_tables.c
@@ -30,14 +30,6 @@ struct acpi_20_facs Facs = {
 /*
  * Fixed ACPI Description Table (FADT).
  */
-
-#define ACPI_PM1A_EVT_BLK_BIT_WIDTH 0x20
-#define ACPI_PM1A_EVT_BLK_BIT_OFFSET0x00
-#define ACPI_PM1A_CNT_BLK_BIT_WIDTH 0x10
-#define ACPI_PM1A_CNT_BLK_BIT_OFFSET0x00
-#define ACPI_PM_TMR_BLK_BIT_WIDTH   0x20
-#define ACPI_PM_TMR_BLK_BIT_OFFSET  0x00
-
 struct acpi_20_fadt Fadt = {
 .header = {
 .signature= ACPI_2_0_FADT_SIGNATURE,
@@ -56,9 +48,9 @@ struct acpi_20_fadt Fadt = {
 .pm1a_cnt_blk = ACPI_PM1A_CNT_BLK_ADDRESS_V1,
 .pm_tmr_blk = ACPI_PM_TMR_BLK_ADDRESS_V1,
 .gpe0_blk = ACPI_GPE0_BLK_ADDRESS_V1,
-.pm1_evt_len = ACPI_PM1A_EVT_BLK_BIT_WIDTH / 8,
-.pm1_cnt_len = ACPI_PM1A_CNT_BLK_BIT_WIDTH / 8,
-.pm_tmr_len = ACPI_PM_TMR_BLK_BIT_WIDTH / 8,
+.pm1_evt_len = ACPI_PM1A_EVT_BLK_LEN,
+.pm1_cnt_len = ACPI_PM1A_CNT_BLK_LEN,
+.pm_tmr_len = ACPI_PM_TMR_BLK_LEN,
 .gpe0_blk_len = ACPI_GPE0_BLK_LEN_V1,
 
 .p_lvl2_lat = 0x0fff, /* >100,  means we do not support C2 state */
@@ -79,21 +71,21 @@ struct acpi_20_fadt Fadt = {
 
 .x_pm1a_evt_blk = {
 .address_space_id= ACPI_SYSTEM_IO,
-.register_bit_width  = ACPI_PM1A_EVT_BLK_BIT_WIDTH,
+.register_bit_width  = ACPI_PM1A_EVT_BLK_LEN * 8,
 .register_bit_offset = ACPI_PM1A_EVT_BLK_BIT_OFFSET,
 .address = ACPI_PM1A_EVT_BLK_ADDRESS_V1,
 },
 
 .x_pm1a_cnt_blk = {
 .address_space_id= ACPI_SYSTEM_IO,
-.register_bit_width  = ACPI_PM1A_CNT_BLK_BIT_WIDTH,
+.register_bit_width  = ACPI_PM1A_CNT_BLK_LEN * 8,
 .register_bit_offset = ACPI_PM1A_CNT_BLK_BIT_OFFSET,
 .address = ACPI_PM1A_CNT_BLK_ADDRESS_V1,
 },
 
 .x_pm_tmr_blk = {
 .address_space_id= ACPI_SYSTEM_IO,
-.register_bit_width  = ACPI_PM_TMR_BLK_BIT_WIDTH,
+.register_bit_width  = ACPI_PM_TMR_BLK_LEN * 8,
 .register_bit_offset = ACPI_PM_TMR_BLK_BIT_OFFSET,
 .address = ACPI_PM_TMR_BLK_ADDRESS_V1,
 }
diff --git a/xen/include/public/hvm/ioreq.h b/xen/include/public/hvm/ioreq.h
index 2e5809b..c04b5e6 100644
--- a/xen/include/public/hvm/ioreq.h
+++ b/xen/include/public/hvm/ioreq.h
@@ -24,6 +24,9 @@
 #ifndef _IOREQ_H_
 #define _IOREQ_H_
 
+#include "../xen-compat.h"
+#include "hvm_info_table.h" /* HVM_MAX_VCPUS */
+
 #define IOREQ_READ  1
 #define IOREQ_WRITE 0
 
@@ -119,11 +122,33 @@ typedef struct buffered_iopage buffered_iopage_t;
 
 /* Compatibility definitions for the default location (version 0). */
 #define ACPI_PM1A_EVT_BLK_ADDRESSACPI_PM1A_EVT_BLK_ADDRESS_V0
+

[Xen-devel] [PATCH v3 11/11] docs: Describe PVHv2's VCPU hotplug procedure

[Boris Ostrovsky]

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 100644
--- a/docs/misc/hvmlite.markdown
+++ b/docs/misc/hvmlite.markdown
@@ -75,3 +75,15 @@ info structure that's passed at boot time (field rsdp_paddr).
 
 Description of paravirtualized devices will come from XenStore, just as it's
 done for HVM guests.
+
+## VCPU hotplug ##
+
+VCPU hotplug (e.g. 'xl vcpu-set  ') for PVHv2 guests
+follows ACPI model where change in domain's number of VCPUS (stored in
+arch_domain.avail_vcpus) results in an SCI being sent to the guest. The
+guest then executes DSDT's PRSC method, updating MADT enable status for
+the affected VCPU.
+
+This is achieved by having the toolstack call XEN_DOMCTL_set_avail_vcpus
+which sets appropriate bits in ACPI GPE0 enable and status registers followed
+by sending VIRQ_SCI to the guest.
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 09/11] events/x86: Define SCI virtual interrupt

[Boris Ostrovsky]

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 Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
---
Changes in v3:
* VIRQ_SCI is global

 xen/include/public/arch-x86/xen-mca.h | 2 --
 xen/include/public/arch-x86/xen.h | 3 +++
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/include/public/arch-x86/xen-mca.h 
b/xen/include/public/arch-x86/xen-mca.h
index a97e821..b76c53c 100644
--- a/xen/include/public/arch-x86/xen-mca.h
+++ b/xen/include/public/arch-x86/xen-mca.h
@@ -91,8 +91,6 @@
 
 #ifndef __ASSEMBLY__
 
-#define VIRQ_MCA VIRQ_ARCH_0 /* G. (DOM0) Machine Check Architecture */
-
 /*
  * Machine Check Architecure:
  * structs are read-only and used to report all kinds of
diff --git a/xen/include/public/arch-x86/xen.h 
b/xen/include/public/arch-x86/xen.h
index 04c78ec..fcc1bf8 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -295,6 +295,9 @@ struct xen_arch_domainconfig {
 };
 #endif
 
+#define VIRQ_MCA VIRQ_ARCH_0 /* G. (DOM0) Machine Check Architecture */
+#define VIRQ_SCI VIRQ_ARCH_1 /* G. (PVH) ACPI interrupt */
+
 #endif /* !__ASSEMBLY__ */
 
 /*
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 06/11] acpi: PVH guests need _E02 method

[Boris Ostrovsky]

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
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -282,11 +282,6 @@ int main(int argc, char **argv)
 
 pop_block();
 
-if (dm_version == QEMU_NONE) {
-pop_block();
-return 0;
-}
-
 /* Define GPE control method. */
 push_block("Scope", "\\_GPE");
 push_block("Method",
@@ -295,6 +290,11 @@ int main(int argc, char **argv)
 stmt("\\_SB.PRSC ()", NULL);
 pop_block();
 pop_block();
+
+if (dm_version == QEMU_NONE) {
+pop_block();
+return 0;
+}
 / Processor end /
 
 
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

[Boris Ostrovsky]

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 Ostrovsky 
Acked-by: Daniel De Graaf 
---
CC: Daniel De Graaf 
---
Changes in v3:
* Clarified commit message to include reason for having the domctl
* Moved domctl to common code
* Made avail_vcpus a bitmap

 tools/flask/policy/modules/dom0.te  |  2 +-
 tools/flask/policy/modules/xen.if   |  4 ++--
 tools/libxc/include/xenctrl.h   |  5 +
 tools/libxc/xc_domain.c | 12 
 tools/libxl/libxl.c |  7 +++
 tools/libxl/libxl_dom.c |  7 +++
 xen/common/domctl.c | 25 +
 xen/include/public/domctl.h |  9 +
 xen/include/xen/sched.h |  6 ++
 xen/xsm/flask/hooks.c   |  3 +++
 xen/xsm/flask/policy/access_vectors |  2 ++
 11 files changed, 79 insertions(+), 3 deletions(-)

diff --git a/tools/flask/policy/modules/dom0.te 
b/tools/flask/policy/modules/dom0.te
index 2d982d9..fd60c39 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -38,7 +38,7 @@ allow dom0_t dom0_t:domain {
 };
 allow dom0_t dom0_t:domain2 {
set_cpuid gettsc settsc setscheduler set_max_evtchn set_vnumainfo
-   get_vnumainfo psr_cmt_op psr_cat_op
+   get_vnumainfo psr_cmt_op psr_cat_op set_avail_vcpus
 };
 allow dom0_t dom0_t:resource { add remove };
 
diff --git a/tools/flask/policy/modules/xen.if 
b/tools/flask/policy/modules/xen.if
index eb646f5..afbedc2 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -52,7 +52,7 @@ define(`create_domain_common', `
settime setdomainhandle getvcpucontext };
allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
-   psr_cmt_op psr_cat_op soft_reset };
+   psr_cmt_op psr_cat_op soft_reset set_avail_vcpus};
allow $1 $2:security check_context;
allow $1 $2:shadow enable;
allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage 
mmuext_op updatemp };
@@ -85,7 +85,7 @@ define(`manage_domain', `
getaddrsize pause unpause trigger shutdown destroy
setaffinity setdomainmaxmem getscheduler resume
setpodtarget getpodtarget };
-allow $1 $2:domain2 set_vnumainfo;
+allow $1 $2:domain2 { set_vnumainfo set_avail_vcpus };
 ')
 
 # migrate_domain_out(priv, target)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 2c83544..49e9b9f 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1256,6 +1256,11 @@ int xc_domain_getvnuma(xc_interface *xch,
 int xc_domain_soft_reset(xc_interface *xch,
  uint32_t domid);
 
+int xc_domain_set_avail_vcpus(xc_interface *xch,
+  uint32_t domid,
+  unsigned int num_vcpus);
+
+
 #if defined(__i386__) || defined(__x86_64__)
 /*
  * PC BIOS standard E820 types and structure.
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 296b852..161a80e 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -2520,6 +2520,18 @@ int xc_domain_soft_reset(xc_interface *xch,
 domctl.domain = (domid_t)domid;
 return do_domctl(xch, &domctl);
 }
+
+int xc_domain_set_avail_vcpus(xc_interface *xch,
+  uint32_t domid,
+  unsigned int num_vcpus)
+{
+DECLARE_DOMCTL;
+domctl.cmd = XEN_DOMCTL_set_avail_vcpus;
+domctl.domain = (domid_t)domid;
+domctl.u.avail_vcpus.num = num_vcpus;
+return do_domctl(xch, &domctl);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 33c5e4c..e936f38 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5164,6 +5164,13 @@ int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, 
libxl_bitmap *cpumap)
 default:
 rc = ERROR_INVAL;
 }
+
+if (!rc) {
+rc = xc_domain_set_avail_vcpus(ctx->xch, domid, maxcpus);
+if (rc)
+LOG(ERROR, "Couldn't set available vcpu count");
+}
+
 out:
 libxl_dominfo_dispose(&info);
 GC_FREE;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index d519c8d..9037166 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -309,6 +309,13 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 return ERROR_FAIL;
 }
 
+rc = xc_domain_set_avail_vcpus(ctx->xch, domid,
+   libxl_bitmap_count_set(&info->avail_vcpus));
+if (rc) {
+LOG(ERROR, "C

Re: [Xen-devel] Can't always start 32 bit domains after 64 bit domains

[Sarah Newman]

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 situation in xl has ever seen any interest.
 If I wanted to add that, where would it go?
>>> I don't know, that's a question for xl folks I guess.
>>
>> IIRC, given no other constraints, the Xen heap allocation allocates from
>> the top down to help this exact case.
> 
> Yes, that's what I thought it did too, though I can't find my source 
> information for that.
> 
>>
>> I suspect that libxl's preference towards NUMA allocation of domains
>> interferes with this, by adding a NUMA constraints to memory allocations
>> for 64bit PV guests.
> 
> I ran xl info -n (which I didn't know about before) and that shows the 
> problem much more clearly.
> 
> If that's the reason not all the higher memory is being used first: is a 
> potential workaround to pin 64 bit domains to the second physical core on
> boot, and 32 bit domains to the first physical core on boot, and then change 
> the allowed cores with 'xl vcpu-pin' after the domain is loaded?

Free memory on a test server with no domains:
node:memsizememfreedistances
   0:148480 142983  10,21
   1:147456 144645  21,10

Free memory booting 116 256M 64-bit domains, limited to cpus='all,^0-1' on boot:
node:memsizememfreedistances
   0:148480 128416  10,21
   1:147456 129669  21,10

Free memory booting 116 256M 64-bit domains, limited to cpus='12-23' on boot:
node:memsizememfreedistances
   0:148480 143397  10,21
   1:147456 114693  21,10

This looks like a viable workaround. Where should I document it?

--Sarah

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

[Edgar E. Iglesias]

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, Stefano Stabellini wrote:
> > > > > On Mon, 14 Nov 2016, Julien Grall wrote:
> > > > > > On 11/11/2016 13:55, Stefano Stabellini wrote:
> > > > > > > On Fri, 11 Nov 2016, Julien Grall wrote:
> > > > > > > > On 11/11/2016 02:24, Stefano Stabellini wrote:
> > > > > > > > > On Thu, 10 Nov 2016, Julien Grall wrote:
> > > > > > > > > > (CC Stefano and change the title)
> > > > > > > > > > On 10/11/16 12:13, casionwoo wrote:
> > > > > > > > > > > I’m pleased about your reply and you have a lot of code to
> > > > > > > > > > > clean-up.
> > > > > > > > > > > 
> > > > > > > > > > > As you mentioned, It’s really huge to digest at once. 
> > > > > > > > > > > Thank you
> > > > > > > > > > > for
> > > > > > > > > > > understanding me.
> > > > > > > > > > > 
> > > > > > > > > > > And that’s why i need a small fix up and todo list.
> > > > > > > > > > > 
> > > > > > > > > > > I feel familiar with ARM and c language and there’s no 
> > > > > > > > > > > specific
> > > > > > > > > > > area
> > > > > > > > > > > yet.
> > > > > > > > > > > 
> > > > > > > > > > > I think that i can find interesting area with following 
> > > > > > > > > > > up the
> > > > > > > > > > > codes.
> > > > > > > > > > > 
> > > > > > > > > > > I’m looking forward to being stuck on Xen.
> > > > > > > > > > > 
> > > > > > > > > > > Then it would be easier for me to understand about Xen on 
> > > > > > > > > > > ARM.
> > > > > > > > > > > 
> > > > > > > > > > > Please let me know the TODO and bug-fix lists.
> > > > > > > > > > 
> > > > > > > > > > Stefano, before giving a list of code clean-up, do you have 
> > > > > > > > > > any
> > > > > > > > > > small
> > > > > > > > > > TODO
> > > > > > > > > > on
> > > > > > > > > > ARM in mind?
> > > > > > > > > 
> > > > > > > > > A simple task we talked about recently is to enable the vuart
> > > > > > > > > (xen/arch/arm/vuart.c) for all guests. At the moment it is 
> > > > > > > > > only
> > > > > > > > > emulated
> > > > > > > > > for Dom0, but some guests, in particular BareMetal guests
> > > > > > > > > (https://en.wikipedia.org/wiki/BareMetal), would benefit from 
> > > > > > > > > it.
> > > > > > > > > 
> > > > > > > > > It would be best to introduce an option in libxl to explicitly
> > > > > > > > > enable/disable the vuart for DomUs. Something like vuart=1 in 
> > > > > > > > > the VM
> > > > > > > > > config file.
> > > > > > > > 
> > > > > > > > The vuart has not been enabled for DomU because it the UART 
> > > > > > > > region may
> > > > > > > > clash
> > > > > > > > with the guest memory layout (which is static).
> > > > > > > > 
> > > > > > > > I don't think this option should be available until we allow 
> > > > > > > > the guest
> > > > > > > > to
> > > > > > > > use
> > > > > > > > the same memory layout as the host (see e820_host parameter for 
> > > > > > > > x86).
> > > > > > > 
> > > > > > > Actually there is no reason for the vuart to use the same address 
> > > > > > > as
> > > > > > > the physical uart on the platform, is there?
> > > > > > > In fact it doesn't even
> > > > > > > have to prentend to be the same uart as the one on the board, 
> > > > > > > right?
> > > > > > > The vuart MMIO address could be completely configurable and 
> > > > > > > independent
> > > > > > > from the one of the physical uart.
> > > > > > 
> > > > > > There is no reason to use the same information as the physical UART.
> > > > > > 
> > > > > > However, the vuart requires quite a few information (e.g base 
> > > > > > address,
> > > > > > offset
> > > > > > of different register... see vuart_info structure in 
> > > > > > include/xen/serial.h
> > > > > > for
> > > > > > more details) in order to fully work.
> > > > > > 
> > > > > > IHMO this is a lot of works for the user to configure. I would much 
> > > > > > prefer
> > > > > > to
> > > > > > see a PL011 emulated at a specific base address and let the user 
> > > > > > select
> > > > > > whether he wants a UART to debug or not.
> > > > > 
> > > > > So you envision the configuration of the MMIO base address to be done 
> > > > > as
> > > > > part of a new dynamic guest memory map?
> > > > 
> > > > For guest using dynamic memory map, I would expect to expose an 
> > > > uncompleted
> > > > emulation of the physical UART (e.g it would only be possible to write) 
> > > > at the
> > > > exact same address as on the host.
> > > 
> > > Why? Is this a requirement for baremetal guests?
> > > 
> > > I would have actually opted for always emulating a PL011 even for guests
> > > using a dynamic memory map (which of course one way or another need to
> > > be able to choose the address of the UART, the memory and the rest).
> > 
> > I guess it's not black and white but trying 

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

[Julien Grall]

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/2016 11:26, Stefano Stabellini wrote:

On Mon, 14 Nov 2016, Julien Grall wrote:

On 11/11/2016 13:55, Stefano Stabellini wrote:

On Fri, 11 Nov 2016, Julien Grall wrote:

On 11/11/2016 02:24, Stefano Stabellini wrote:

On Thu, 10 Nov 2016, Julien Grall wrote:

(CC Stefano and change the title)
On 10/11/16 12:13, casionwoo wrote:

I’m pleased about your reply and you have a lot of code to
clean-up.

As you mentioned, It’s really huge to digest at once. Thank you
for
understanding me.

And that’s why i need a small fix up and todo list.

I feel familiar with ARM and c language and there’s no specific
area
yet.

I think that i can find interesting area with following up the
codes.

I’m looking forward to being stuck on Xen.

Then it would be easier for me to understand about Xen on ARM.

Please let me know the TODO and bug-fix lists.


Stefano, before giving a list of code clean-up, do you have any
small
TODO
on
ARM in mind?


A simple task we talked about recently is to enable the vuart
(xen/arch/arm/vuart.c) for all guests. At the moment it is only
emulated
for Dom0, but some guests, in particular BareMetal guests
(https://en.wikipedia.org/wiki/BareMetal), would benefit from it.

It would be best to introduce an option in libxl to explicitly
enable/disable the vuart for DomUs. Something like vuart=1 in the VM
config file.


The vuart has not been enabled for DomU because it the UART region may
clash
with the guest memory layout (which is static).

I don't think this option should be available until we allow the guest
to
use
the same memory layout as the host (see e820_host parameter for x86).


Actually there is no reason for the vuart to use the same address as
the physical uart on the platform, is there?
In fact it doesn't even
have to prentend to be the same uart as the one on the board, right?
The vuart MMIO address could be completely configurable and independent
from the one of the physical uart.


There is no reason to use the same information as the physical UART.

However, the vuart requires quite a few information (e.g base address,
offset
of different register... see vuart_info structure in include/xen/serial.h
for
more details) in order to fully work.

IHMO this is a lot of works for the user to configure. I would much prefer
to
see a PL011 emulated at a specific base address and let the user select
whether he wants a UART to debug or not.


So you envision the configuration of the MMIO base address to be done as
part of a new dynamic guest memory map?


For guest using dynamic memory map, I would expect to expose an uncompleted
emulation of the physical UART (e.g it would only be possible to write) at the
exact same address as on the host.


Why? Is this a requirement for baremetal guests?

I would have actually opted for always emulating a PL011 even for guests
using a dynamic memory map (which of course one way or another need to
be able to choose the address of the UART, the memory and the rest).


I guess it's not black and white but trying to reduce the gap towards
being able to run unmodified SW for a given platform as a guest would
be nice.

Some times things are quite relaxed and we can recompile the SW for Xen,
add new drivers etc. Other times perhaps SW has been certified and users
may not be able to change anything.

For apps where the UARTs are only used for console data, vuarts at
configurable locations would be nice IMO.


All right, so I take that same UART as baremetal is easier than always
PL011?


I think so, yes.

To comply with the SBSA, depending on the guest, we'll probably need to allow 
for optional emulation of pl011 though...

Having a flexible setup so that vm.cfgs can instantiate vuarts or emulated 
pl011 at specific addresses, that sounds good to me.


I am more in favor to have a different approach depending on the memory 
layout (static vs dynamic) of the guest.


Exposing the vuart to a guest with static memory layout is overly 
complex (you have a bunch information to configure) and it is much 
easier to require a guest using pl011 (implementing a small driver for 
it is very easy). Note that the emulation could just use the vuart for 
now. But the user would just have to say pl011 = true in the vm.cfg.


For the emulated pl011, I would not support user configuration (e.g 
address) when using the static memory layout for similar reason as 
above. Only dynamic layout could support an extend configuration. Even 
though, I am not convince of the usefulness of a pl011 for baremetal app 
(we are supposed to only emulate the hardware).


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen

[Xen-devel] [PATCH 0/4] 9pfs: clean-up for multiple transports

[Stefano Stabellini]

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_pack
  9pfs: add a size parameter to init_iov_from_pdu

 hw/9pfs/9p.c   | 71 +++---
 hw/9pfs/9p.h   | 19 +
 hw/9pfs/virtio-9p-device.c | 20 +
 hw/9pfs/virtio-9p.h| 10 ---
 4 files changed, 69 insertions(+), 51 deletions(-)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 2/4] 9pfs: introduce transport specific callbacks

[Stefano Stabellini]

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|  9 -
 4 files changed, 36 insertions(+), 17 deletions(-)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 05e950f..5a20a13 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -47,7 +47,7 @@ ssize_t pdu_marshal(V9fsPDU *pdu, size_t offset, const char 
*fmt, ...)
 va_list ap;
 
 va_start(ap, fmt);
-ret = virtio_pdu_vmarshal(pdu, offset, fmt, ap);
+ret = pdu->s->transport->pdu_vmarshal(pdu, offset, fmt, ap);
 va_end(ap);
 
 return ret;
@@ -59,7 +59,7 @@ ssize_t pdu_unmarshal(V9fsPDU *pdu, size_t offset, const char 
*fmt, ...)
 va_list ap;
 
 va_start(ap, fmt);
-ret = virtio_pdu_vunmarshal(pdu, offset, fmt, ap);
+ret = pdu->s->transport->pdu_vunmarshal(pdu, offset, fmt, ap);
 va_end(ap);
 
 return ret;
@@ -67,7 +67,7 @@ ssize_t pdu_unmarshal(V9fsPDU *pdu, size_t offset, const char 
*fmt, ...)
 
 static void pdu_push_and_notify(V9fsPDU *pdu)
 {
-virtio_9p_push_and_notify(pdu);
+pdu->s->transport->push_and_notify(pdu);
 }
 
 static int omode_to_uflags(int8_t mode)
@@ -1751,7 +1751,7 @@ static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, 
V9fsPDU *pdu,
 struct iovec *iov;
 unsigned int niov;
 
-virtio_init_iov_from_pdu(pdu, &iov, &niov, is_write);
+pdu->s->transport->init_iov_from_pdu(pdu, &iov, &niov, is_write);
 
 qemu_iovec_init_external(&elem, iov, niov);
 qemu_iovec_init(qiov, niov);
diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
index 07cee01..ab398d0 100644
--- a/hw/9pfs/9p.h
+++ b/hw/9pfs/9p.h
@@ -230,6 +230,7 @@ typedef struct V9fsState
 enum p9_proto_version proto_version;
 int32_t msize;
 V9fsPDU pdus[MAX_REQ];
+struct V9fsTransport *transport;
 /*
  * lock ensuring atomic path update
  * on rename.
@@ -343,4 +344,21 @@ void pdu_free(V9fsPDU *pdu);
 void pdu_submit(V9fsPDU *pdu);
 void v9fs_reset(V9fsState *s);
 
+struct V9fsTransport {
+ssize_t (*pdu_vmarshal)(V9fsPDU *pdu, size_t offset, const char *fmt, 
va_list ap);
+ssize_t (*pdu_vunmarshal)(V9fsPDU *pdu, size_t offset, const char 
*fmt, va_list ap);
+void(*init_iov_from_pdu)(V9fsPDU *pdu, struct iovec **piov,
+  unsigned int *pniov, bool is_write);
+void(*push_and_notify)(V9fsPDU *pdu);
+};
+
+static inline int v9fs_register_transport(V9fsState *s, struct V9fsTransport 
*t)
+{
+if (s->transport) {
+return -EINVAL;
+}
+s->transport = t;
+return 0;
+}
+
 #endif
diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index 1782e4a..e1a37a4 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -20,7 +20,9 @@
 #include "hw/virtio/virtio-access.h"
 #include "qemu/iov.h"
 
-void virtio_9p_push_and_notify(V9fsPDU *pdu)
+static struct V9fsTransport virtio_9p_transport;
+
+static void virtio_9p_push_and_notify(V9fsPDU *pdu)
 {
 V9fsState *s = pdu->s;
 V9fsVirtioState *v = container_of(s, V9fsVirtioState, state);
@@ -126,6 +128,7 @@ static void virtio_9p_device_realize(DeviceState *dev, 
Error **errp)
 v->config_size = sizeof(struct virtio_9p_config) + strlen(s->fsconf.tag);
 virtio_init(vdev, "virtio-9p", VIRTIO_ID_9P, v->config_size);
 v->vq = virtio_add_queue(vdev, MAX_REQ, handle_9p_output);
+v9fs_register_transport(s, &virtio_9p_transport);
 
 out:
 return;
@@ -148,7 +151,7 @@ static void virtio_9p_reset(VirtIODevice *vdev)
 v9fs_reset(&v->state);
 }
 
-ssize_t virtio_pdu_vmarshal(V9fsPDU *pdu, size_t offset,
+static ssize_t virtio_pdu_vmarshal(V9fsPDU *pdu, size_t offset,
 const char *fmt, va_list ap)
 {
 V9fsState *s = pdu->s;
@@ -158,7 +161,7 @@ ssize_t virtio_pdu_vmarshal(V9fsPDU *pdu, size_t offset,
 return v9fs_iov_vmarshal(elem->in_sg, elem->in_num, offset, 1, fmt, ap);
 }
 
-ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, size_t offset,
+static ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, size_t offset,
   const char *fmt, va_list ap)
 {
 V9fsState *s = pdu->s;
@@ -168,7 +171,7 @@ ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, size_t offset,
 return v9fs_iov_vunmarshal(elem->out_sg, elem->out_num, offset, 1, fmt, 
ap);
 }
 
-void virtio_init_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov,
+static void virtio_init_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov,
   unsigned int *pniov, bool is_write)
 {
 V9fsState *s = pdu->s;
@@ -184,6 +187,13 @@ void virtio_init_iov_from_pdu(V9fsPDU *pdu, struct iovec 
**piov,
 }
 }
 
+static struct V9fsTransport virtio_9p_transport = {
+.pdu_vmarshal = virtio_pdu_vmarshal,
+.pdu_vunmarshal = virtio_pdu_vunmarshal,
+.init_iov_from_pdu =

[Xen-devel] [PATCH 4/4] 9pfs: add a size parameter to init_iov_from_pdu

[Stefano Stabellini]

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 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index b6ec042..b82212b 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -1652,7 +1652,7 @@ static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, 
V9fsPDU *pdu,
 struct iovec *iov;
 unsigned int niov;
 
-pdu->s->transport->init_iov_from_pdu(pdu, &iov, &niov, is_write);
+pdu->s->transport->init_iov_from_pdu(pdu, &iov, &niov, is_write, skip + 
size);
 
 qemu_iovec_init_external(&elem, iov, niov);
 qemu_iovec_init(qiov, niov);
diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
index ab398d0..c830188 100644
--- a/hw/9pfs/9p.h
+++ b/hw/9pfs/9p.h
@@ -348,7 +348,7 @@ struct V9fsTransport {
 ssize_t (*pdu_vmarshal)(V9fsPDU *pdu, size_t offset, const char *fmt, 
va_list ap);
 ssize_t (*pdu_vunmarshal)(V9fsPDU *pdu, size_t offset, const char 
*fmt, va_list ap);
 void(*init_iov_from_pdu)(V9fsPDU *pdu, struct iovec **piov,
-  unsigned int *pniov, bool is_write);
+  unsigned int *pniov, bool is_write, size_t size);
 void(*push_and_notify)(V9fsPDU *pdu);
 };
 
diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index e1a37a4..e2b27e8 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -172,7 +172,7 @@ static ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, size_t 
offset,
 }
 
 static void virtio_init_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov,
-  unsigned int *pniov, bool is_write)
+  unsigned int *pniov, bool is_write, size_t size)
 {
 V9fsState *s = pdu->s;
 V9fsVirtioState *v = container_of(s, V9fsVirtioState, state);
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 3/4] 9pfs: use v9fs_init_qiov_from_pdu instead of v9fs_pack

[Stefano Stabellini]

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, 29 insertions(+), 29 deletions(-)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 5a20a13..b6ec042 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -1633,14 +1633,39 @@ out_nofid:
 pdu_complete(pdu, err);
 }
 
+/*
+ * Create a QEMUIOVector for a sub-region of PDU iovecs
+ *
+ * @qiov:   uninitialized QEMUIOVector
+ * @skip:   number of bytes to skip from beginning of PDU
+ * @size:   number of bytes to include
+ * @is_write:   true - write, false - read
+ *
+ * The resulting QEMUIOVector has heap-allocated iovecs and must be cleaned up
+ * with qemu_iovec_destroy().
+ */
+static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, V9fsPDU *pdu,
+size_t skip, size_t size,
+bool is_write)
+{
+QEMUIOVector elem;
+struct iovec *iov;
+unsigned int niov;
+
+pdu->s->transport->init_iov_from_pdu(pdu, &iov, &niov, is_write);
+
+qemu_iovec_init_external(&elem, iov, niov);
+qemu_iovec_init(qiov, niov);
+qemu_iovec_concat(qiov, &elem, skip, size);
+}
+
 static int v9fs_xattr_read(V9fsState *s, V9fsPDU *pdu, V9fsFidState *fidp,
uint64_t off, uint32_t max_count)
 {
 ssize_t err;
 size_t offset = 7;
 uint64_t read_count;
-V9fsVirtioState *v = container_of(s, V9fsVirtioState, state);
-VirtQueueElement *elem = v->elems[pdu->idx];
+QEMUIOVector qiov_full;
 
 if (fidp->fs.xattr.len < off) {
 read_count = 0;
@@ -1656,7 +1681,8 @@ static int v9fs_xattr_read(V9fsState *s, V9fsPDU *pdu, 
V9fsFidState *fidp,
 }
 offset += err;
 
-err = v9fs_pack(elem->in_sg, elem->in_num, offset,
+v9fs_init_qiov_from_pdu(&qiov_full, pdu, 0, read_count, false);
+err = v9fs_pack(qiov_full.iov, qiov_full.niov, offset,
 ((char *)fidp->fs.xattr.value) + off,
 read_count);
 if (err < 0) {
@@ -1732,32 +1758,6 @@ static int coroutine_fn 
v9fs_do_readdir_with_stat(V9fsPDU *pdu,
 return count;
 }
 
-/*
- * Create a QEMUIOVector for a sub-region of PDU iovecs
- *
- * @qiov:   uninitialized QEMUIOVector
- * @skip:   number of bytes to skip from beginning of PDU
- * @size:   number of bytes to include
- * @is_write:   true - write, false - read
- *
- * The resulting QEMUIOVector has heap-allocated iovecs and must be cleaned up
- * with qemu_iovec_destroy().
- */
-static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, V9fsPDU *pdu,
-size_t skip, size_t size,
-bool is_write)
-{
-QEMUIOVector elem;
-struct iovec *iov;
-unsigned int niov;
-
-pdu->s->transport->init_iov_from_pdu(pdu, &iov, &niov, is_write);
-
-qemu_iovec_init_external(&elem, iov, niov);
-qemu_iovec_init(qiov, niov);
-qemu_iovec_concat(qiov, &elem, skip, size);
-}
-
 static void coroutine_fn v9fs_read(void *opaque)
 {
 int32_t fid;
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 1/4] 9pfs: move pdus to V9fsState

[Stefano Stabellini]

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/9p.c b/hw/9pfs/9p.c
index aea7e9d..05e950f 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -3440,7 +3440,6 @@ void pdu_submit(V9fsPDU *pdu)
 /* Returns 0 on success, 1 on failure. */
 int v9fs_device_realize_common(V9fsState *s, Error **errp)
 {
-V9fsVirtioState *v = container_of(s, V9fsVirtioState, state);
 int i, len;
 struct stat stat;
 FsDriverEntry *fse;
@@ -3451,9 +3450,9 @@ int v9fs_device_realize_common(V9fsState *s, Error **errp)
 QLIST_INIT(&s->free_list);
 QLIST_INIT(&s->active_list);
 for (i = 0; i < (MAX_REQ - 1); i++) {
-QLIST_INSERT_HEAD(&s->free_list, &v->pdus[i], next);
-v->pdus[i].s = s;
-v->pdus[i].idx = i;
+QLIST_INSERT_HEAD(&s->free_list, &s->pdus[i], next);
+s->pdus[i].s = s;
+s->pdus[i].idx = i;
 }
 
 v9fs_path_init(&path);
diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
index 3976b7f..07cee01 100644
--- a/hw/9pfs/9p.h
+++ b/hw/9pfs/9p.h
@@ -229,6 +229,7 @@ typedef struct V9fsState
 char *tag;
 enum p9_proto_version proto_version;
 int32_t msize;
+V9fsPDU pdus[MAX_REQ];
 /*
  * lock ensuring atomic path update
  * on rename.
diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h
index 25c47c7..52c4b9d 100644
--- a/hw/9pfs/virtio-9p.h
+++ b/hw/9pfs/virtio-9p.h
@@ -10,7 +10,6 @@ typedef struct V9fsVirtioState
 VirtIODevice parent_obj;
 VirtQueue *vq;
 size_t config_size;
-V9fsPDU pdus[MAX_REQ];
 VirtQueueElement *elems[MAX_REQ];
 V9fsState state;
 } V9fsVirtioState;
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

[Edgar E. Iglesias]

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 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 Fri, 11 Nov 2016, Julien Grall wrote:
> >On 11/11/2016 02:24, Stefano Stabellini wrote:
> >>On Thu, 10 Nov 2016, Julien Grall wrote:
> >>>(CC Stefano and change the title)
> >>>On 10/11/16 12:13, casionwoo wrote:
> I’m pleased about your reply and you have a lot of code to
> clean-up.
> 
> As you mentioned, It’s really huge to digest at once. Thank you
> for
> understanding me.
> 
> And that’s why i need a small fix up and todo list.
> 
> I feel familiar with ARM and c language and there’s no specific
> area
> yet.
> 
> I think that i can find interesting area with following up the
> codes.
> 
> I’m looking forward to being stuck on Xen.
> 
> Then it would be easier for me to understand about Xen on ARM.
> 
> Please let me know the TODO and bug-fix lists.
> >>>
> >>>Stefano, before giving a list of code clean-up, do you have any
> >>>small
> >>>TODO
> >>>on
> >>>ARM in mind?
> >>
> >>A simple task we talked about recently is to enable the vuart
> >>(xen/arch/arm/vuart.c) for all guests. At the moment it is only
> >>emulated
> >>for Dom0, but some guests, in particular BareMetal guests
> >>(https://en.wikipedia.org/wiki/BareMetal), would benefit from it.
> >>
> >>It would be best to introduce an option in libxl to explicitly
> >>enable/disable the vuart for DomUs. Something like vuart=1 in the VM
> >>config file.
> >
> >The vuart has not been enabled for DomU because it the UART region 
> >may
> >clash
> >with the guest memory layout (which is static).
> >
> >I don't think this option should be available until we allow the 
> >guest
> >to
> >use
> >the same memory layout as the host (see e820_host parameter for x86).
> 
> Actually there is no reason for the vuart to use the same address as
> the physical uart on the platform, is there?
> In fact it doesn't even
> have to prentend to be the same uart as the one on the board, right?
> The vuart MMIO address could be completely configurable and 
> independent
> from the one of the physical uart.
> >>>
> >>>There is no reason to use the same information as the physical UART.
> >>>
> >>>However, the vuart requires quite a few information (e.g base address,
> >>>offset
> >>>of different register... see vuart_info structure in 
> >>>include/xen/serial.h
> >>>for
> >>>more details) in order to fully work.
> >>>
> >>>IHMO this is a lot of works for the user to configure. I would much 
> >>>prefer
> >>>to
> >>>see a PL011 emulated at a specific base address and let the user select
> >>>whether he wants a UART to debug or not.
> >>
> >>So you envision the configuration of the MMIO base address to be done as
> >>part of a new dynamic guest memory map?
> >
> >For guest using dynamic memory map, I would expect to expose an 
> >uncompleted
> >emulation of the physical UART (e.g it would only be possible to write) 
> >at the
> >exact same address as on the host.
> 
> Why? Is this a requirement for baremetal guests?
> 
> I would have actually opted for always emulating a PL011 even for guests
> using a dynamic memory map (which of course one way or another need to
> be able to choose the address of the UART, the memory and the rest).
> >>>
> >>>I guess it's not black and white but trying to reduce the gap towards
> >>>being able to run unmodified SW for a given platform as a guest would
> >>>be nice.
> >>>
> >>>Some times things are quite relaxed and we can recompile the SW for Xen,
> >>>add new drivers etc. Other times perhaps SW has been certified and users
> >>>may not be able to change anything.
> >>>
> >>>For apps where the UARTs are only used for console data, vuarts at
> >>>configurable locations would be nice IMO.
> >>
> >>All right, so I take that same UART as baremetal is easier than always
> >>PL011?
> >
> >I think so, yes.
> >
> >To comply with t

[Xen-devel] [seabios baseline-only test] 68076: tolerable FAIL

[Platform Team regression test user]

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 fail like 67953
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67953
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67953
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 67953

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 seabios  b98c6586c0c3d519359d6e751ecb3e637e82dbcb
baseline version:
 seabios  d7adf6044a4c772b497e97272adf97426b34a249

Last test of basis67953  2016-10-28 05:18:42 Z   24 days
Testing same since68076  2016-11-21 19:16:35 Z0 days1 attempts


People who touched revisions under test:
  Igor Mammedov 
  Kevin O'Connor 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-qemuu-nested-intel  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


commit b98c6586c0c3d519359d6e751ecb3e637e82dbcb
Author: Igor Mammedov 
Date:   Fri Nov 11 16:35:15 2016 +0100

drop "etc/boot-cpus" fw_cfg file and reuse legacy QEMU_CFG_NB_CPUS

since QEMU_CFG_NB_CPUS not going away anytime soon
and serves the same purpose as just added "etc/boot-cpus" fw_cfg
drop support for "etc/boot-cpus" while this code is not
in use yet (i.e. QEMU with "etc/boot-cpus" hasn't been released)
and reuse QEMU_CFG_NB_CPUS instead of it.

Signed-off-by: Igor Mammedov 

commit c5e56b2ffe439b919d5e622374c1aa70af4e1911
Author: Kevin O'Connor 
Date:   Wed Oct 26 12:43:12 2016 -0400

usb: Make usb_time_sigatt variable static

Signed-off-by: Kevin O'Connor 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC] Shared coprocessor framework

[Stefano Stabellini]

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 situation is not as bad as having full-scope driver (which is
> AM> implemented in some proprietary hypervisors), we only need to:
> AM> 1. stop
> AM> 2. flush registers
> AM> 3. switch memory context <--- implemented by SMMU in ARM
> AM> 4. restore registers
> AM> 5. start
> 
> Well, we also need to take care about following:
> 
> AA> Due to the fact that some domain assigned a vcoproc could access coproc 
> when
> AA> it is running another domain context, framework will implement iomem 
> access
> AA> emulation for domains which are not provided coproc at the moment of 
> access.

This is certainly going to be the hardest part. I take the framework is
just going to provide a generic API for implementing a coprocessor
emulator and it is going to be up to each coprocessor implementation to
provide the code.

Is the emulator going to live in the Xen hypervisor?

It would be nice to provide a simple coprocessor example, if you have one.


> On Sat, Nov 12, 2016 at 2:04 PM, Artem Mygaiev  wrote:
> > On Fri, Nov 11, 2016 at 10:43 PM, Konrad Rzeszutek Wilk
> >  wrote:
> >> Does this also mean that the hypervisor has to know the co-processors?
> >> As in how to start/stop them? And how to tell them to save/restore
> >> guest context? Or is there some generic specification for doing this?
> >
> > Unfortunately there is be no single way to switch context on
> > co-processors, so yes, hypervisor has to know the co-processors.
> > The situation is not as bad as having full-scope driver (which is
> > implemented in some proprietary hypervisors), we only need to:
> > 1. stop
> > 2. flush registers
> > 3. switch memory context <--- implemented by SMMU in ARM
> > 4. restore registers
> > 5. start
> >
> > Best regards,
> > Artem Mygaiev
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable test] 102489: regressions - FAIL

[osstest service owner]

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-armhf-xl-vhd   9 debian-di-installfail REGR. vs. 102465

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 102465
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 102465
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 102465
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 102465
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 102465
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 102465
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 102465
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 102465
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 102465

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  0745f665a575bdb6724f6ec1ab767cd71ba8c253
baseline version:
 xen  58bd0c7985890e0292212f94a56235228a3445c3

Last test of basis   102465  2016-11-21 01:58:00 Z1 days
Testing same since   102489  2016-11-21 17:49:05 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvops  

Re: [Xen-devel] [PATCH v4] xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing

[Hugh Dickins]

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 fail with -EFAULT.
> 
> check_vma_flags
> __get_user_pages
> __get_user_pages_locked
> __get_user_pages_unlocked
> get_user_pages_fast
> iov_iter_get_pages
> dio_refill_pages
> do_direct_IO
> do_blockdev_direct_IO
> do_blockdev_direct_IO
> ext4_direct_IO_read
> generic_file_read_iter
> aio_run_iocb
> 
> (which can happen if guest's vdisk has direct-io-safe option).
> 
> To avoid this let's use VM_MIXEDMAP flag instead --- it prevents
> NUMA balancing just as VM_IO does and has no effect on
> check_vma_flags().
> 
> Reported-by: Olaf Hering 
> Suggested-by: Hugh Dickins 
> Signed-off-by: Boris Ostrovsky 

Acked-by: Hugh Dickins 

But nicer with the addition of a code comment saying
/* VM_MIXEDMAP to forbid NUMA balancing but permit get_user_pages() */

> ---
>  drivers/xen/gntdev.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index bb95212..2ef2b61 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -1007,7 +1007,7 @@ static int gntdev_mmap(struct file *flip, struct 
> vm_area_struct *vma)
>  
>   vma->vm_ops = &gntdev_vmops;
>  
> - vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP | VM_IO;
> + vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP | VM_MIXEDMAP;
>  
>   if (use_ptemod)
>   vma->vm_flags |= VM_DONTCOPY;
> -- 
> 1.7.1

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v8 4/7] VT-d: Use one function to update both remapped and posted IRTE

[Wu, Feng]

> -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 update both remapped
> and posted IRTE
> 
> > From: Wu, Feng
> > Sent: Friday, November 18, 2016 9:57 AM
> >
> > Use one function to update both remapped IRTE and posted IRET.
> >
> > Signed-off-by: Feng Wu 
> > ---
> > v8:
> > - Newly added
> >
> >  xen/drivers/passthrough/vtd/intremap.c | 162 
> > ++-
> --
> >  1 file changed, 66 insertions(+), 96 deletions(-)
> >
> > diff --git a/xen/drivers/passthrough/vtd/intremap.c
> > b/xen/drivers/passthrough/vtd/intremap.c
> > index bfd468b..fd2a49a 100644
> > --- a/xen/drivers/passthrough/vtd/intremap.c
> > +++ b/xen/drivers/passthrough/vtd/intremap.c
> > @@ -420,7 +420,7 @@ void io_apic_write_remap_rte(
> >  __ioapic_write_entry(apic, ioapic_pin, 1, old_rte);
> >  }
> >
> > -static void set_msi_source_id(struct pci_dev *pdev, struct iremap_entry 
> > *ire)
> > +static void set_msi_source_id(const struct pci_dev *pdev, struct
> iremap_entry *ire)
> >  {
> >  u16 seg;
> >  u8 bus, devfn, secbus;
> > @@ -548,11 +548,12 @@ static int remap_entry_to_msi_msg(
> >  }
> >
> >  static int msi_msg_to_remap_entry(
> > -struct iommu *iommu, struct pci_dev *pdev,
> > -struct msi_desc *msi_desc, struct msi_msg *msg)
> > +struct iommu *iommu, const struct pci_dev *pdev,
> > +struct msi_desc *msi_desc, struct msi_msg *msg,
> > +const struct pi_desc *pi_desc, const uint8_t gvec)
> >  {
> >  struct iremap_entry *iremap_entry = NULL, *iremap_entries;
> > -struct iremap_entry new_ire;
> > +struct iremap_entry new_ire, old_ire;
> 
> old_ire is used only in later 'else' branch. move definition there.
> 
> >  struct msi_msg_remap_entry *remap_rte;
> >  unsigned int index, i, nr = 1;
> >  unsigned long flags;
> > @@ -597,31 +598,50 @@ static int msi_msg_to_remap_entry(
> >
> >  memcpy(&new_ire, iremap_entry, sizeof(struct iremap_entry));
> >
> > -/* Set interrupt remapping table entry */
> > -new_ire.remap.fpd = 0;
> > -new_ire.remap.dm = (msg->address_lo >> MSI_ADDR_DESTMODE_SHIFT)
> & 0x1;
> > -new_ire.remap.tm = (msg->data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
> > -new_ire.remap.dlm = (msg->data >> MSI_DATA_DELIVERY_MODE_SHIFT) &
> 0x1;
> > -/* Hardware require RH = 1 for LPR delivery mode */
> > -new_ire.remap.rh = (new_ire.remap.dlm == dest_LowestPrio);
> > -new_ire.remap.avail = 0;
> > -new_ire.remap.res_1 = 0;
> > -new_ire.remap.vector = (msg->data >> MSI_DATA_VECTOR_SHIFT) &
> > -MSI_DATA_VECTOR_MASK;
> > -new_ire.remap.res_2 = 0;
> > -if ( x2apic_enabled )
> > -new_ire.remap.dst = msg->dest32;
> > +if ( !pi_desc )
> > +{
> > +/* Set interrupt remapping table entry */
> > +new_ire.remap.fpd = 0;
> > +new_ire.remap.dm = (msg->address_lo >> MSI_ADDR_DESTMODE_SHIFT)
> &
> > 0x1;
> > +new_ire.remap.tm = (msg->data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
> > +new_ire.remap.dlm = (msg->data >> MSI_DATA_DELIVERY_MODE_SHIFT)
> &
> > 0x1;
> > +/* Hardware require RH = 1 for LPR delivery mode */
> > +new_ire.remap.rh = (new_ire.remap.dlm == dest_LowestPrio);
> > +new_ire.remap.avail = 0;
> > +new_ire.remap.res_1 = 0;
> > +new_ire.remap.vector = (msg->data >> MSI_DATA_VECTOR_SHIFT) &
> > +MSI_DATA_VECTOR_MASK;
> > +new_ire.remap.res_2 = 0;
> > +if ( x2apic_enabled )
> > +new_ire.remap.dst = msg->dest32;
> > +else
> > +new_ire.remap.dst = ((msg->address_lo >> 
> > MSI_ADDR_DEST_ID_SHIFT)
> > + & 0xff) << 8;
> > +
> > +new_ire.remap.res_3 = 0;
> > +new_ire.remap.res_4 = 0;
> > +new_ire.remap.p = 1;/* finally, set present bit */
> > +}
> >  else
> > -new_ire.remap.dst = ((msg->address_lo >> MSI_ADDR_DEST_ID_SHIFT)
> > - & 0xff) << 8;
> > +{
> > +new_ire.post.fpd = 0;
> > +new_ire.post.res_1 = 0;
> > +new_ire.post.res_2 = 0;
> > +new_ire.post.urg = 0;
> > +new_ire.post.im = 1;
> > +new_ire.post.vector = gvec;
> > +new_ire.post.res_3 = 0;
> > +new_ire.post.res_4 = 0;
> > +new_ire.post.res_5 = 0;
> > +new_ire.post.pda_l = virt_to_maddr(pi_desc) >> (32 - PDA_LOW_BIT);
> > +new_ire.post.pda_h = virt_to_maddr(pi_desc) >> 32;
> > +new_ire.post.p = 1;/* finally, set present bit */
> > +}
> 
> It's a little confusing here:
> 
> - you first copy current remapping entry to new_ire and then do some
> initialization.
> Is it necessary? If there are some fields we'd like to i

Re: [Xen-devel] [PATCH v8 5/7] VT-d: No need to set irq affinity for posted format IRTE

[Wu, Feng]

> -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 affinity for posted 
> format
> IRTE
> 
> > From: Wu, Feng
> > Sent: Friday, November 18, 2016 9:59 AM
> >
> > We don't set the affinity for posted format IRTE, since the
> > destination of these interrupts is vCPU and the vCPU affinity
> > is set during vCPU scheduling.
> >
> > Signed-off-by: Feng Wu 
> > ---
> > v8:
> > - Changes based on [6/7]
> 
> [5/7]?

Sorry, should be [4/7]

> 
> >
> > v7:
> > - Compare all the field in IRTE to justify whether we can suppress the 
> > update
> >
> > v6:
> > - Make pi_can_suppress_irte_update() a check-only function
> > - Introduce another function pi_get_new_irte() to update the 'new_ire' if
> needed
> >
> > v5:
> > - Only suppress affinity related IRTE updates for PI
> >
> > v4:
> > - Keep the construction of new_ire and only modify the hardware
> > IRTE when it is not in posted mode.
> >
> >  xen/drivers/passthrough/vtd/intremap.c | 87
> > --
> >  1 file changed, 52 insertions(+), 35 deletions(-)
> >
> > diff --git a/xen/drivers/passthrough/vtd/intremap.c
> > b/xen/drivers/passthrough/vtd/intremap.c
> > index fd2a49a..0cb8c37 100644
> > --- a/xen/drivers/passthrough/vtd/intremap.c
> > +++ b/xen/drivers/passthrough/vtd/intremap.c
> > @@ -600,27 +600,41 @@ static int msi_msg_to_remap_entry(
> >
> >  if ( !pi_desc )
> >  {
> > -/* Set interrupt remapping table entry */
> > -new_ire.remap.fpd = 0;
> > -new_ire.remap.dm = (msg->address_lo >> MSI_ADDR_DESTMODE_SHIFT)
> &
> > 0x1;
> > -new_ire.remap.tm = (msg->data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
> > -new_ire.remap.dlm = (msg->data >> MSI_DATA_DELIVERY_MODE_SHIFT)
> &
> > 0x1;
> > -/* Hardware require RH = 1 for LPR delivery mode */
> > -new_ire.remap.rh = (new_ire.remap.dlm == dest_LowestPrio);
> > -new_ire.remap.avail = 0;
> > -new_ire.remap.res_1 = 0;
> > -new_ire.remap.vector = (msg->data >> MSI_DATA_VECTOR_SHIFT) &
> > -MSI_DATA_VECTOR_MASK;
> > -new_ire.remap.res_2 = 0;
> > -if ( x2apic_enabled )
> > -new_ire.remap.dst = msg->dest32;
> > -else
> > -new_ire.remap.dst = ((msg->address_lo >> 
> > MSI_ADDR_DEST_ID_SHIFT)
> > - & 0xff) << 8;
> > +/*
> > + * We are here because we are trying to update the IRTE to remapped
> mode,
> > + * we only need to update the remapped specific fields for the 
> > following
> > + * two cases:
> 
> you said "we only need to update the remapped specific fields", while later...
> 
> > + * 1. When we create a new IRTE. A new IRTE is created when we 
> > create
> a
> > + *new irq, so a new IRTE is always initialized with remapped 
> > format.
> > + * 2. When the old IRTE is present and in remapped mode. Since if 
> > the old
> > + *IRTE is in posted mode, we cannot update it to remapped mode 
> > and
> > + *this is what we need to suppress. So we don't update the 
> > remapped
> > + *specific fields here, we only update the commom field.
> 
> you said "we don't update remapped specific fields"...

Sorry for the confusion. When I said "So we don't update the remapped specific
fields here, we only update the common field" above, I actually would like to
mean for the case "when we are updating remapped IRTE -> posted IRTE".
I will reword this to make it clear.

> 
> It's also unclear to me why we cannot change irte from posted mode back to
> remapped mode. Is it defined as a VT-d arch limitation? What about the other
> direction from remapped mode to posted mode?

It is not a VT-d arch limitation. We don't need that and currently don't have 
that
path to trigger the transition from posted IRTE to remapped one. And in fact 
that
is the main purpose of this patch to suppress affinity update to a posted mode
IRTE. And the other direction from remapped mode to posted mode is
straightforward, when IRTE is created with remapped mode, sometime later,
our code will update it to posted mode if the device is assigned to guest and
the guest updates the affinity.

> 
> > + */
> > +if ( !iremap_entry->remap.p || !iremap_entry->remap.im )
> > +{
> > +/* Set interrupt remapping table entry */
> > +new_ire.remap.fpd = 0;
> > +new_ire.remap.dm = (msg->address_lo >>
> MSI_ADDR_DESTMODE_SHIFT)
> > & 0x1;
> > +new_ire.remap.tm = (msg->data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
> > +new_ire.remap.dlm = (msg->data >>
> MSI_DATA_DELIVERY_MODE_SHIFT)
> > & 0x1;
> > +/* Hardware require RH = 1 for LPR delive

Re: [Xen-devel] [PATCH] xen-scsifront: Add a missing call to kfree

[Martin K. Petersen]

> "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: Quentin Lambert 

Juergen> Nice catch. I think this will need some more work, I'll do a
Juergen> follow-on patch.

Juergen> Reviewed-by: Juergen Gross 

Are you taking this patch through the Xen tree or should I queue it up?

-- 
Martin K. Petersen  Oracle Linux Engineering

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline test] 102492: regressions - FAIL

[osstest service owner]

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-libvirt-vhd  9 debian-di-installfail REGR. vs. 101909
 test-amd64-amd64-libvirt 11 guest-start  fail REGR. vs. 101909
 test-amd64-amd64-libvirt-xsm 11 guest-start  fail REGR. vs. 101909
 test-amd64-amd64-libvirt-pair 20 guest-start/debian  fail REGR. vs. 101909
 test-armhf-armhf-xl-vhd   9 debian-di-installfail REGR. vs. 101909
 test-amd64-i386-libvirt-pair 20 guest-start/debian   fail REGR. vs. 101909
 test-armhf-armhf-libvirt-xsm 11 guest-start  fail REGR. vs. 101909
 test-amd64-i386-libvirt  11 guest-start  fail REGR. vs. 101909
 test-amd64-i386-libvirt-xsm  11 guest-start  fail REGR. vs. 101909
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install  fail REGR. vs. 101909
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail REGR. vs. 101909
 test-armhf-armhf-libvirt 11 guest-start  fail REGR. vs. 101909

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101909
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101909
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101909

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuuc36ed06e9159fa484b711dfdd27ec64d7ac3d17a
baseline version:
 qemuu199a5bde46b0eab898ab1ec591f423000302569f

Last test of basis   101909  2016-11-03 23:21:40 Z   18 days
Failing since101943  2016-11-04 22:40:48 Z   17 days   39 attempts
Testing same since   102492  2016-11-21 19:22:23 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Williamson 
  Alexey Kardashevskiy 
  Ankit Kumar 
  ann.zhuangyany...@huawei.com
  Ashijeet Acharya 
  Balbir singh 
  Bharata B Rao 
  Brian Candler 
  Christian Borntraeger 
  Cornelia Huck 
  Cédric Le Goater 
  Daniel Oram 
  Daniel P. Berrange 
  David Gibson 
  Doug Evans 
  Eduardo Habkost 
  Eric Blake 
  Fam Zheng 
  Farhan Ali 
  Gautham R. Shenoy 
  Gerd Hoffmann 
  Gonglei 
  Greg Kurz 
  Halil Pasic 
  Igor Mammedov 
  Jason Wang 
  Jeff Cody 
  John Snow 
  Jose Ricardo Ziviani 
  Juan Quintela 
  Julian Brown 
  Kevin Wolf 
  Ladi Prosek 
  Laurent Vivier 
  Li Qiang 
  Marc-André Lureau 
  Marcel Apfelbaum 
  Marcin Krzeminski 
  Max Reitz 
  Michael S. Tsirkin 
  Michael Tokarev 
  Nikunj A Dadhania 
  Olaf Hering 
  Paolo Bonzini 
  Peter Korsgaard 
  Peter Maydell 
  Peter Xu 
  Prasad J Pandit 
  Rafael David Tinoco 
  Richard Henderson 
  Samuel Thibault 
  Sander Eikelenboom 
  Stefan Hajnoczi 
  Stefano Stabellini 
  Thomas Huth 
  Tomáš Golembiovský 
  Vladimir Sementsov-Ogievskiy 
  Wei Liu 
  Xiao Guangrong 
  Yuri Benditovich 
  Zhang Chen 
  zhanghailiang 
  Zhuang Yanying 
  ZhuangYanying 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm 

Re: [Xen-devel] [PATCH] xen-scsifront: Add a missing call to kfree

[Juergen Gross]

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.
>>>
>>> This issue was found with Hector.
>>>
>>> Signed-off-by: Quentin Lambert 
> 
> Juergen> Nice catch. I think this will need some more work, I'll do a
> Juergen> follow-on patch.
> 
> Juergen> Reviewed-by: Juergen Gross 
> 
> Are you taking this patch through the Xen tree or should I queue it up?

I'm taking it through the xen tree, thanks.


Juergen


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4] xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing

[Juergen Gross]

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 this flag causes get_user_pages() to
>> always fail with -EFAULT.
>>
>> check_vma_flags
>> __get_user_pages
>> __get_user_pages_locked
>> __get_user_pages_unlocked
>> get_user_pages_fast
>> iov_iter_get_pages
>> dio_refill_pages
>> do_direct_IO
>> do_blockdev_direct_IO
>> do_blockdev_direct_IO
>> ext4_direct_IO_read
>> generic_file_read_iter
>> aio_run_iocb
>>
>> (which can happen if guest's vdisk has direct-io-safe option).
>>
>> To avoid this let's use VM_MIXEDMAP flag instead --- it prevents
>> NUMA balancing just as VM_IO does and has no effect on
>> check_vma_flags().
>>
>> Reported-by: Olaf Hering 
>> Suggested-by: Hugh Dickins 
>> Signed-off-by: Boris Ostrovsky 
> 
> Acked-by: Hugh Dickins 
> 
> But nicer with the addition of a code comment saying
>   /* VM_MIXEDMAP to forbid NUMA balancing but permit get_user_pages() */

I can fix that up when committing.


Juergen

> 
>> ---
>>  drivers/xen/gntdev.c |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
>> index bb95212..2ef2b61 100644
>> --- a/drivers/xen/gntdev.c
>> +++ b/drivers/xen/gntdev.c
>> @@ -1007,7 +1007,7 @@ static int gntdev_mmap(struct file *flip, struct 
>> vm_area_struct *vma)
>>  
>>  vma->vm_ops = &gntdev_vmops;
>>  
>> -vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP | VM_IO;
>> +vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP | VM_MIXEDMAP;
>>  
>>  if (use_ptemod)
>>  vma->vm_flags |= VM_DONTCOPY;
>> -- 
>> 1.7.1
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen virtual IOMMU high level design doc V3

[Tian, Kevin]

> 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 happens.
> >
> > When guest triggers a invalidation operation, there maybe in-fly DMA
> > request for virtual device has been translated by vIOMMU and return back
> > Qemu. Before vIOMMU tells invalidation completed, it's necessary to make
> > sure in-fly DMA operation is completed.
> >
> > When IOMMU driver invalidates IOTLB, it also will wait until the
> > invalidation completion. We may use this to drain in-fly DMA operation
> > for virtual device.
> >
> > Guest triggers invalidation operation and trip into vIOMMU in
> > hypervisor to flush cache data. After this, it should go to Qemu to
> > drain in-fly DMA translation.
> >
> > To do that, dummy vIOMMU in Qemu registers the same MMIO region as
> > vIOMMU's and emulation part of invalidation operation in Xen hypervisor
> > returns X86EMUL_UNHANDLEABLE after flush cache. MMIO emulation part is
> > supposed to send event to Qemu and dummy vIOMMU get a chance to starts a
> > thread to drain in-fly DMA and return emulation done.
> >
> > Guest polls IVT(invalidate IOTLB) bit in the IOTLB invalidate register
> > until it's cleared after triggering invalidation. Dummy vIOMMU in Qemu
> > notifies hypervisor drain operation completed via hypercall, vIOMMU
> > clears IVT bit and guest finish invalidation operation.
> 
> Having the guest poll will be very inefficient.  If the invalidation
> does need to reach qemu, it will be a very long time until it
> completes.  Is there no interrupt based mechanism which can be used?
> That way the guest can either handle it asynchronous itself, or block
> waiting on an interrupt, both of which are better than having it just
> spinning.
> 

VT-d spec supports both poll and interrupt modes, and it's decided
by guest IOMMU driver. Not say that this design requires guest to
use poll mode. I guess Tianyu uses as an example flow.

Thanks
Kevin
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 0/4] xen: add qdevs for each backend, correct pvUSB

[Juergen Gross]

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
possible the pvUSB controller has to be a hotpluggable qemu device.

This is achieved by adding a qdev for each Xen backend all attached to
a new Xen specific bus.

Changes in V3:
- removed two spurious changes in patch 3 as requested by Stefano

Changes in V2:
- one qdev for each backend instead of pvUSB only

Juergen Gross (4):
  xen: add an own bus for xen backend devices
  qdev: add function qdev_set_id()
  xen: create qdev for each backend device
  xen: attach pvusb usb bus to backend qdev

 hw/usb/xen-usb.c | 23 +++
 hw/xen/xen_backend.c | 66 ++--
 hw/xen/xen_pvdev.c   |  4 ++-
 include/hw/xen/xen_backend.h |  8 ++
 include/hw/xen/xen_pvdev.h   |  1 +
 include/monitor/qdev.h   |  1 +
 qdev-monitor.c   | 36 +---
 7 files changed, 106 insertions(+), 33 deletions(-)

-- 
2.10.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 2/4] qdev: add function qdev_set_id()

[Juergen Gross]

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 
 2 files changed, 21 insertions(+), 16 deletions(-)

diff --git a/include/monitor/qdev.h b/include/monitor/qdev.h
index 8e504bc..0ff3331 100644
--- a/include/monitor/qdev.h
+++ b/include/monitor/qdev.h
@@ -12,5 +12,6 @@ void qmp_device_add(QDict *qdict, QObject **ret_data, Error 
**errp);
 
 int qdev_device_help(QemuOpts *opts);
 DeviceState *qdev_device_add(QemuOpts *opts, Error **errp);
+void qdev_set_id(DeviceState *dev, const char *id);
 
 #endif
diff --git a/qdev-monitor.c b/qdev-monitor.c
index 4f78ecb..c73410c 100644
--- a/qdev-monitor.c
+++ b/qdev-monitor.c
@@ -539,10 +539,28 @@ static BusState *qbus_find(const char *path, Error **errp)
 return bus;
 }
 
+void qdev_set_id(DeviceState *dev, const char *id)
+{
+if (id) {
+dev->id = id;
+}
+
+if (dev->id) {
+object_property_add_child(qdev_get_peripheral(), dev->id,
+  OBJECT(dev), NULL);
+} else {
+static int anon_count;
+gchar *name = g_strdup_printf("device[%d]", anon_count++);
+object_property_add_child(qdev_get_peripheral_anon(), name,
+  OBJECT(dev), NULL);
+g_free(name);
+}
+}
+
 DeviceState *qdev_device_add(QemuOpts *opts, Error **errp)
 {
 DeviceClass *dc;
-const char *driver, *path, *id;
+const char *driver, *path;
 DeviceState *dev;
 BusState *bus = NULL;
 Error *err = NULL;
@@ -591,21 +609,7 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error **errp)
 qdev_set_parent_bus(dev, bus);
 }
 
-id = qemu_opts_id(opts);
-if (id) {
-dev->id = id;
-}
-
-if (dev->id) {
-object_property_add_child(qdev_get_peripheral(), dev->id,
-  OBJECT(dev), NULL);
-} else {
-static int anon_count;
-gchar *name = g_strdup_printf("device[%d]", anon_count++);
-object_property_add_child(qdev_get_peripheral_anon(), name,
-  OBJECT(dev), NULL);
-g_free(name);
-}
+qdev_set_id(dev, qemu_opts_id(opts));
 
 /* set properties */
 if (qemu_opt_foreach(opts, set_property, dev, &err)) {
-- 
2.10.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 1/4] xen: add an own bus for xen backend devices

[Juergen Gross]

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 insertions(+), 3 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 41ba5c5..5ad3caa 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -29,14 +29,14 @@
 #include "hw/sysbus.h"
 #include "sysemu/char.h"
 #include "qemu/log.h"
+#include "qapi/error.h"
 #include "hw/xen/xen_backend.h"
 #include "hw/xen/xen_pvdev.h"
 
 #include 
 
-#define TYPE_XENSYSDEV "xensysdev"
-
 DeviceState *xen_sysdev;
+BusState *xen_sysbus;
 
 /* - */
 
@@ -528,6 +528,8 @@ int xen_be_init(void)
 
 xen_sysdev = qdev_create(NULL, TYPE_XENSYSDEV);
 qdev_init_nofail(xen_sysdev);
+xen_sysbus = qbus_create(TYPE_XENSYSBUS, DEVICE(xen_sysdev), "xen-sysbus");
+qbus_set_bus_hotplug_handler(xen_sysbus, &error_abort);
 
 return 0;
 
@@ -586,6 +588,15 @@ int xen_be_bind_evtchn(struct XenDevice *xendev)
 }
 
 
+static const TypeInfo xensysbus_info = {
+.name   = TYPE_XENSYSBUS,
+.parent = TYPE_BUS,
+.interfaces = (InterfaceInfo[]) {
+{ TYPE_HOTPLUG_HANDLER },
+{ }
+}
+};
+
 static int xen_sysdev_init(SysBusDevice *dev)
 {
 return 0;
@@ -602,6 +613,7 @@ static void xen_sysdev_class_init(ObjectClass *klass, void 
*data)
 
 k->init = xen_sysdev_init;
 dc->props = xen_sysdev_properties;
+dc->bus_type = TYPE_XENSYSBUS;
 }
 
 static const TypeInfo xensysdev_info = {
@@ -613,7 +625,8 @@ static const TypeInfo xensysdev_info = {
 
 static void xenbe_register_types(void)
 {
+type_register_static(&xensysbus_info);
 type_register_static(&xensysdev_info);
 }
 
-type_init(xenbe_register_types);
+type_init(xenbe_register_types)
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index cbda40e..38f730e 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -6,12 +6,16 @@
 #include "sysemu/sysemu.h"
 #include "net/net.h"
 
+#define TYPE_XENSYSDEV "xen-sysdev"
+#define TYPE_XENSYSBUS "xen-sysbus"
+
 /* variables */
 extern xc_interface *xen_xc;
 extern xenforeignmemory_handle *xen_fmem;
 extern struct xs_handle *xenstore;
 extern const char *xen_protocol;
 extern DeviceState *xen_sysdev;
+extern BusState *xen_sysbus;
 
 int xenstore_mkdir(char *path, int p);
 int xenstore_write_be_str(struct XenDevice *xendev, const char *node, const 
char *val);
-- 
2.10.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 4/4] xen: attach pvusb usb bus to backend qdev

[Juergen Gross]

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 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
index 1b3c2fb..8e676e6 100644
--- a/hw/usb/xen-usb.c
+++ b/hw/usb/xen-usb.c
@@ -712,15 +712,10 @@ static void usbback_portid_detach(struct usbback_info 
*usbif, unsigned port)
 
 static void usbback_portid_remove(struct usbback_info *usbif, unsigned port)
 {
-USBPort *p;
-
 if (!usbif->ports[port - 1].dev) {
 return;
 }
 
-p = &(usbif->ports[port - 1].port);
-snprintf(p->path, sizeof(p->path), "%d", 99);
-
 object_unparent(OBJECT(usbif->ports[port - 1].dev));
 usbif->ports[port - 1].dev = NULL;
 usbback_portid_detach(usbif, port);
@@ -733,10 +728,10 @@ static void usbback_portid_add(struct usbback_info 
*usbif, unsigned port,
 {
 unsigned speed;
 char *portname;
-USBPort *p;
 Error *local_err = NULL;
 QDict *qdict;
 QemuOpts *opts;
+char *tmp;
 
 if (usbif->ports[port - 1].dev) {
 return;
@@ -749,11 +744,16 @@ static void usbback_portid_add(struct usbback_info 
*usbif, unsigned port,
 return;
 }
 portname++;
-p = &(usbif->ports[port - 1].port);
-snprintf(p->path, sizeof(p->path), "%s", portname);
 
 qdict = qdict_new();
 qdict_put(qdict, "driver", qstring_from_str("usb-host"));
+tmp = g_strdup_printf("%s.0", usbif->xendev.qdev.id);
+qdict_put(qdict, "bus", qstring_from_str(tmp));
+g_free(tmp);
+tmp = g_strdup_printf("%s-%u", usbif->xendev.qdev.id, port);
+qdict_put(qdict, "id", qstring_from_str(tmp));
+g_free(tmp);
+qdict_put(qdict, "port", qint_from_int(port));
 qdict_put(qdict, "hostbus", qint_from_int(atoi(busid)));
 qdict_put(qdict, "hostport", qstring_from_str(portname));
 opts = qemu_opts_from_qdict(qemu_find_opts("device"), qdict, &local_err);
@@ -765,7 +765,6 @@ static void usbback_portid_add(struct usbback_info *usbif, 
unsigned port,
 goto err;
 }
 QDECREF(qdict);
-snprintf(p->path, sizeof(p->path), "%d", port);
 speed = usbif->ports[port - 1].dev->speed;
 switch (speed) {
 case USB_SPEED_LOW:
@@ -799,7 +798,6 @@ static void usbback_portid_add(struct usbback_info *usbif, 
unsigned port,
 
 err:
 QDECREF(qdict);
-snprintf(p->path, sizeof(p->path), "%d", 99);
 xen_pv_printf(&usbif->xendev, 0, "device %s could not be opened\n", busid);
 }
 
@@ -1012,13 +1010,13 @@ static void usbback_alloc(struct XenDevice *xendev)
 
 usbif = container_of(xendev, struct usbback_info, xendev);
 
-usb_bus_new(&usbif->bus, sizeof(usbif->bus), &xen_usb_bus_ops, xen_sysdev);
+usb_bus_new(&usbif->bus, sizeof(usbif->bus), &xen_usb_bus_ops,
+DEVICE(&xendev->qdev));
 for (i = 0; i < USBBACK_MAXPORTS; i++) {
 p = &(usbif->ports[i].port);
 usb_register_port(&usbif->bus, p, usbif, i, &xen_usb_port_ops,
   USB_SPEED_MASK_LOW | USB_SPEED_MASK_FULL |
   USB_SPEED_MASK_HIGH);
-snprintf(p->path, sizeof(p->path), "%d", 99);
 }
 
 QTAILQ_INIT(&usbif->req_free_q);
@@ -1066,7 +1064,6 @@ static int usbback_free(struct XenDevice *xendev)
 }
 
 usb_bus_release(&usbif->bus);
-object_unparent(OBJECT(&usbif->bus));
 
 TR_BUS(xendev, "finished\n");
 
-- 
2.10.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 3/4] xen: create qdev for each backend device

[Juergen Gross]

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 found in xenstore.

Signed-off-by: Juergen Gross 
Reviewed-by: Stefano Stabellini 
---
 hw/xen/xen_backend.c | 47 
 hw/xen/xen_pvdev.c   |  4 +++-
 include/hw/xen/xen_backend.h |  4 
 include/hw/xen/xen_pvdev.h   |  1 +
 4 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 5ad3caa..d119004 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -27,11 +27,13 @@
 
 #include "hw/hw.h"
 #include "hw/sysbus.h"
+#include "hw/boards.h"
 #include "sysemu/char.h"
 #include "qemu/log.h"
 #include "qapi/error.h"
 #include "hw/xen/xen_backend.h"
 #include "hw/xen/xen_pvdev.h"
+#include "monitor/qdev.h"
 
 #include 
 
@@ -121,6 +123,12 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
 
 /* init new xendev */
 xendev = g_malloc0(ops->size);
+object_initialize(&xendev->qdev, ops->size, TYPE_XENBACKEND);
+qdev_set_parent_bus(&xendev->qdev, xen_sysbus);
+qdev_set_id(&xendev->qdev, g_strdup_printf("xen-%s-%d", type, dev));
+qdev_init_nofail(&xendev->qdev);
+object_unref(OBJECT(&xendev->qdev));
+
 xendev->type  = type;
 xendev->dom   = dom;
 xendev->dev   = dev;
@@ -541,6 +549,15 @@ err:
 return -1;
 }
 
+static void xen_set_dynamic_sysbus(void)
+{
+Object *machine = qdev_get_machine();
+ObjectClass *oc = object_get_class(machine);
+MachineClass *mc = MACHINE_CLASS(oc);
+
+mc->has_dynamic_sysbus = true;
+}
+
 int xen_be_register(const char *type, struct XenDevOps *ops)
 {
 char path[50];
@@ -562,6 +579,8 @@ int xen_be_register(const char *type, struct XenDevOps *ops)
 
 void xen_be_register_common(void)
 {
+xen_set_dynamic_sysbus();
+
 xen_be_register("console", &xen_console_ops);
 xen_be_register("vkbd", &xen_kbdmouse_ops);
 xen_be_register("qdisk", &xen_blkdev_ops);
@@ -588,9 +607,36 @@ int xen_be_bind_evtchn(struct XenDevice *xendev)
 }
 
 
+static Property xendev_properties[] = {
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void xendev_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+dc->props = xendev_properties;
+set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+}
+
+static const TypeInfo xendev_type_info = {
+.name  = TYPE_XENBACKEND,
+.parent= TYPE_XENSYSDEV,
+.class_init= xendev_class_init,
+.instance_size = sizeof(struct XenDevice),
+};
+
+static void xen_sysbus_class_init(ObjectClass *klass, void *data)
+{
+HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(klass);
+
+hc->unplug = qdev_simple_device_unplug_cb;
+}
+
 static const TypeInfo xensysbus_info = {
 .name   = TYPE_XENSYSBUS,
 .parent = TYPE_BUS,
+.class_init = xen_sysbus_class_init,
 .interfaces = (InterfaceInfo[]) {
 { TYPE_HOTPLUG_HANDLER },
 { }
@@ -627,6 +673,7 @@ static void xenbe_register_types(void)
 {
 type_register_static(&xensysbus_info);
 type_register_static(&xensysdev_info);
+type_register_static(&xendev_type_info);
 }
 
 type_init(xenbe_register_types)
diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index 5212bc6..aed783e 100644
--- a/hw/xen/xen_pvdev.c
+++ b/hw/xen/xen_pvdev.c
@@ -19,6 +19,7 @@
 
 #include "qemu/osdep.h"
 #include "qemu/log.h"
+#include "hw/qdev-core.h"
 #include "hw/xen/xen_backend.h"
 #include "hw/xen/xen_pvdev.h"
 
@@ -307,7 +308,8 @@ void xen_pv_del_xendev(struct XenDevice *xendev)
 }
 
 QTAILQ_REMOVE(&xendevs, xendev, next);
-g_free(xendev);
+
+qdev_unplug(&xendev->qdev, NULL);
 }
 
 void xen_pv_insert_xendev(struct XenDevice *xendev)
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 38f730e..4f4799a 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -8,6 +8,10 @@
 
 #define TYPE_XENSYSDEV "xen-sysdev"
 #define TYPE_XENSYSBUS "xen-sysbus"
+#define TYPE_XENBACKEND "xen-backend"
+
+#define XENBACKEND_DEVICE(obj) \
+OBJECT_CHECK(XenDevice, (obj), TYPE_XENBACKEND)
 
 /* variables */
 extern xc_interface *xen_xc;
diff --git a/include/hw/xen/xen_pvdev.h b/include/hw/xen/xen_pvdev.h
index 083f0a9..d473e9b 100644
--- a/include/hw/xen/xen_pvdev.h
+++ b/include/hw/xen/xen_pvdev.h
@@ -29,6 +29,7 @@ struct XenDevOps {
 };
 
 struct XenDevice {
+DeviceStateqdev;
 const char *type;
 intdom;
 intdev;
-- 
2.10.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel