Re: [Xen-devel] HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2

[Konrad Rzeszutek Wilk]

> >>Your analysis was absolutely spot on. After re-thinking this for a
> >>moment, I thought going down that route first would make a lot of sense
> >>as PV guests still do work and one of the differences to HVM domUs is
> >>that the former do _not_ require SeaBIOS. Looking at my log files of
> >>installed packages confirmed an upgrade from SeaBIOS 1.7.5 to 1.8.2 in
> >>the relevant timeframe which obviously had not made it to the hvmloader
> >>of xen-4.5.1 as I did not re-compile xen after the upgrade of SeaBIOS.
> >>
> >>So I re-compiled xen-4.5.1 (obviously now using the installed SeaBIOS
> >>1.8.2) and the same error as with xen-4.5.2 popped up - and that seemed
> >>to strongly indicate that there indeed might be an issue with SeaBIOS as
> >>this probably was the only variable that had changed from the original
> >>install of xen-4.5.1.

I recall seeing this way back in Fedora 20 days. I narrowed it down the 
SeaBIOS version that was a standalone package to not have CONFIG_XEN.

Having that fixed in the SeaBIOS package fixed it.

> >>
> >>My next step was to downgrade SeaBIOS to 1.7.5 and to re-compile
> >>xen-4.5.1. Voila, the system was again up and running. While still
> >>having SeaBIOS 1.7.5 installed, I also re-compiled xen-4.5.2 and ... you
> >>probably guessed it ... the problem was gone: The system boots up with
> >>no issues and everything is fine again.
> >>
> >>So in a nutshell: There seems to be a problem with SeaBIOS 1.8.2
> >>preventing HVM doamins from successfully starting up. I don't know what
> >>this is triggered from, if this is specific to my hardware or whether
> >>something else in my environment is to blame.
> >>
> >>In any case, I am again more than happy to provide data / run a few
> >>tests should you wish to get to the grounds of this.
> >>
> >>I do owe you a beer (or any other drink) should you ever be at my
> >>location (i.e. Vienna, Austria).
> >>
> >>Many thanks again for your analysis and your first class support. Xen
> >>and their people absolutely rock!
> >>
> >>Atom2
> >I'm a little late to the thread but can you send me (you can do it
> >off-list if you'd like) the USE flags you used for xen, xen-tools and
> >seabios? Also emerge --info. You can kill two birds with one stone by
> >using emerge --info xen.
> Hi Doug,
> here you go:
> USE flags:
> app-emulation/xen-4.5.2-r1::gentoo  USE="-custom-cflags -debug -efi -flask
> -xsm"
> app-emulation/xen-tools-4.5.2::gentoo  USE="hvm pam pygrub python qemu
> screen system-seabios -api -custom-cflags -debug -doc -flask (-ocaml) -ovmf
> -static-libs -system-qemu" PYTHON_TARGETS="python2_7"
> sys-firmware/seabios-1.7.5::gentoo  USE="binary"
> emerge --info: Please see the attached file
> >I'm not too familiar with the xen ebuilds but I was pretty sure that
> >xen-tools is what builds hvmloader and it downloads a copy of SeaBIOS
> >and builds it so that it remains consistent. But obviously your
> >experience shows otherwise.
> You are right, it's xen-tools that builds hvmloader. If I remember
> correctly, the "system-seabios" USE flag (for xen-tools) specifies whether
> sys-firmware/seabios is used and the latter downloads SeaBIOS in it's binary
> form provided its "binary" USE flag is set. At least that's my
> understanding.
> >I'm looking at some ideas to improve SeaBIOS packaging on Gentoo and
> >your info would be helpful.
> Great. Whatever makes gentoo and xen stronger will be awesome. What
> immediately springs to mind is to create a separate hvmloader package and
> slot that (that's just an idea and probably not fully thought through, but
> ss far as I understood Andrew, it would then be possible to specify the
> specific firmware version [i.e. hvmloader] to use on xl's command line by
> using firmware_override="full/path/to/firmware").
> 
> I also found out that an upgrade to sys-firmware/seabios obviously does not
> trigger an automatic re-emerge of xen-tools and thus hvmloader. Shouldn't
> this also happen automatically as xen-tools depends on seabios?

No and yes. You can use 'seabios' also with a standalone QEMU (so not
hardware virtualization).

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

Re: [Xen-devel] [OSSTEST PATCH 1/2] Nested hosts: Provide hostnamepath and hostnamepath_list

[Ian Campbell]

On Mon, 2015-11-16 at 15:20 +, Ian Jackson wrote:
> This can (and often should) be used to replace $ho->{Name}.
> 
> For an L0 host it returns "$ho->{Name}", ie HOST.
> 
> For a plain guest or L1 guest it returns
> "$ho->{Host}{Name}_$ho->{Name}", ie HOST_GUEST or HOST_L1.
> 
> For an L2 guest it recurses further, giving HOST_L1_L2.
> 
> Signed-off-by: Ian Jackson 

I'm not 100% convinced it makes sense to have "path" in the name of the
_list variant, but:

Acked-by: Ian Campbell 



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

Re: [Xen-devel] [OSSTEST PATCH 2/2] Nested hosts: Use hostnamepath() in create_webfile

[Ian Campbell]

On Mon, 2015-11-16 at 15:20 +, Ian Jackson wrote:
> create_webfile needs a pathname in the shared public-html directory.
> These paths need to be (a) stable (b) unique across all running jobs.
> We achieve this by basing the filenames on the hostname and (for a
> guest) the guest name.
> 
> But for an L2 guest we need to include the physical host name too,
> because the L1 `host' is not unique.
> 
> Fix this by using hostnamepath(), replacing the open-coded single
> iteration.
> 
> Reported-by: Ian Campbell 
> CC: Robert Ho 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


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

[Xen-devel] [PATCH v6 2/3] public/io/netif.h: add definition of gso_prefix flag

[Paul Durrant]

This flag is defined here only for compatibility with the Linux variant of
this header. The feature has never been documented and should be
considered deprecated.

Signed-off-by: Paul Durrant 
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
---
 xen/include/public/io/netif.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
index 04d8026..f62a0c8 100644
--- a/xen/include/public/io/netif.h
+++ b/xen/include/public/io/netif.h
@@ -409,6 +409,10 @@ typedef struct netif_rx_request netif_rx_request_t;
 #define _NETRXF_extra_info (3)
 #define  NETRXF_extra_info (1U<<_NETRXF_extra_info)
 
+/* Packet has GSO prefix. Deprecated but included for compatibility */
+#define _NETRXF_gso_prefix (4)
+#define  NETRXF_gso_prefix (1U<<_NETRXF_gso_prefix)
+
 struct netif_rx_response {
 uint16_t id;
 uint16_t offset;   /* Offset in page of start of received packet  */
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] xen/x86: Adjust stack pointer in xen_sysexit

[Boris Ostrovsky]

On 11/15/2015 01:02 PM, Andy Lutomirski wrote:

On Nov 13, 2015 5:23 PM, "Boris Ostrovsky"  wrote:



On 11/13/2015 06:26 PM, Andy Lutomirski wrote:

On Fri, Nov 13, 2015 at 3:18 PM, Boris Ostrovsky
 wrote:

After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c
("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack
frame that is passed to xen_sysexit is no longer a "standard" one (i.e.
it's not pt_regs).

We need to adjust it so that subsequent xen_iret can use it.

I'm wondering if this should be more straightforward:

  movq%rsp, %rdi
  calldo_fast_syscall_32
  testl   %eax, %eax
  jz  .Lsyscall_32_done

  /* Opportunistic SYSRET */
sysret32_from_system_call:
  XEN_DO_SYSRET32

where XEN_DO_SYSRET32 is a simple pv op that, on Xen, jumps to a
variant of Xen's iret path that knows that the fast path is okay.



This patch is for 32-bit kernel. I actually haven't looked at compat code 
(probably because our tests don't try that), I need to do that too.

In 4.4, it's almost identical (which was part of the point of this
whole series).  We use sysret32 instead of sysexit, but the underlying
structure is the same: munge the stack frame and register state
appropriately to use the fast return instruction in question and then
execute it.  In both cases, the only real difference from the IRET
path is that we're willing to lose the values of some subset of cx,
dx, and (on 64-bit kernels) r11.



So it turned out that for compat mode we don't need to do anything since 
xen_sysret32 doesn't assume any stack format (or, rather, it assumes 
that it can't be used) and builds the IRET frame itself.






As for XEN_DO_SYSRET32 --- we'd presumably need to have a nop for baremetal 
otherwise current paravirt op will use native_usergs_sysret32 (for compat 
code). Which means a new pv_op, I think.

Agreed, unless...

Does Xen have a cpufeature?  Using ALTERNATIVE instead of a pvop could
be easier to follow and be less code at the same time.  Frankly,
following the control flow from asm through the pre-paravirt-patching
and post-paravirt-patching variants and into the final targets is
getting a little bit old, and ALTERNATIVE is crystal clear in
comparison (and has all the interesting info inline with the rest of
the asm).  Of course, it doesn't work early in boot, but that's fine
for anything involving user/kernel switches.



We don't currently have a Xen-specific CPU feature. We could, in 
principle, add it but we can't replace all of current paravirt patching 
with a single feature since PVH guests use a subset of existing pv ops 
(and in the future it may become even more fine-grained).


And I don't think we should go ALTERNATIVE route for one set of features 
and keep pv ops for the rest --- it should be either one or the other.



-boris


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

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

[osstest service owner]

flight 64466 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64466/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  d07f63fa6e70350b23e7acbde06129247c4e655d
baseline version:
 xen  ddebece6d540ac8d9211e9b3ff8f9c49cfccc428

Last test of basis64453  2015-11-16 13:00:56 Z0 days
Testing same since64466  2015-11-16 15:00:52 Z0 days1 attempts


People who touched revisions under test:
  Ian Campbell 
  Jan Beulich 
  Juergen Gross 
  Wei Liu 

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=d07f63fa6e70350b23e7acbde06129247c4e655d
+ . ./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 
d07f63fa6e70350b23e7acbde06129247c4e655d
+ branch=xen-unstable-smoke
+ revision=d07f63fa6e70350b23e7acbde06129247c4e655d
+ . ./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-unstable
+ '[' xd07f63fa6e70350b23e7acbde06129247c4e655d = 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/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
  

Re: [Xen-devel] [xen-4.3-testing test] 63948: regressions - FAIL [and 1 more messages] [and 1 more messages]

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] [xen-4.3-testing test] 63948: regressions 
- FAIL [and 1 more messages] [and 1 more messages]"):
> On 16.11.15 at 17:00,  wrote:
> > Based on this, which is the only regression in 64287, we could force
> > push this:
...
> Well, yes, but wouldn't it re-occur once it managed to run on an
> Intel box again?

Yes, but that's not very likely to happen soon.

This will allow us to think about the medium-term fix without the
short-term breakage causing pain.

Ian.

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

Re: [Xen-devel] [PATCH 10/10] x86/hvm: pkeys, add xstate support for pkeys

[Andrew Cooper]

On 16/11/15 10:31, Huaitong Han wrote:
> This patch adds xstate support for pkeys.
>
> Signed-off-by: Huaitong Han 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2 1/2] xen/serial: Move any OMAP specific things to OMAP UART driver

[Ian Campbell]

On Fri, 2015-11-06 at 04:26 -0700, Jan Beulich wrote:
> > > > On 05.11.15 at 18:53,  wrote:
> > The 8250-uart.h contains extra serial register definitions
> > for the internal UARTs in TI OMAP SoCs which are used in
> > OMAP UART driver only.
> > In order to clean up code move these definitions to omap-uart.c.
> > Also rename some definitions to follow to the UART_OMAP* prefix.
> > 
> > Signed-off-by: Oleksandr Tyshchenko  > om>
> > CC: Ian Campbell 
> > CC: Julien Grall 
> > CC: Stefano Stabellini 
> > Cc: Jan Beulich 
> 
> The Cc list of the mail disagrees with the list above, but nevertheless
> Acked-by: Jan Beulich 

Acked + applied both patches.


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

Re: [Xen-devel] [PATCH] tools: migration: Use PRIpfn when printing frame numbers.

[Ian Campbell]

On Wed, 2015-11-11 at 13:44 +, Wei Liu wrote:
> On Wed, Nov 11, 2015 at 01:33:46PM +, Ian Campbell wrote:
> > This avoids various printf formatting warnings when building on arm32.
> > 
> > While touching the affected lines make them consistently use %#.
> > 
> > Signed-off-by: Ian Campbell 
> > Cc: Andrew Cooper 
> 
> Acked-by: Wei Liu 

Applied, thanks.

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

Re: [Xen-devel] [PATCH v10] run QEMU as non-root

[Ian Campbell]

On Thu, 2015-11-05 at 12:47 +, Stefano Stabellini wrote:
> Try to use "xen-qemuuser-domid$domid" first, then
> "xen-qemuuser-shared" and root if everything else fails.
> 
> The uids need to be manually created by the user or, more likely, by the
> xen package maintainer.
> 
> Expose a device_model_user setting in libxl_domain_build_info, so that
> opinionated callers, such as libvirt, can set any user they like. Do not
> fall back to root if device_model_user is set. Users can also set
> device_model_user by hand in the xl domain config file.
> 
> QEMU is going to setuid and setgid to the user ID and the group ID of
> the specified user, soon after initialization, before starting to deal
> with any guest IO.
> 
> To actually secure QEMU when running in Dom0, we need at least to
> deprivilege the privcmd and xenstore interfaces, this is just the first
> step in that direction.
> 
> Signed-off-by: Stefano Stabellini 

acked + applied.


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

Re: [Xen-devel] [xen-4.6-testing test] 64270: regressions - FAIL

[Jan Beulich]

>>> On 16.11.15 at 13:01,  wrote:
> I think if the 4.6 release cycle is at a suitable point we should backport
> the Cofnig.mk change to switch to the combined trees. If that would be
> inappropriate right now then pushing the tags by hand to the old tree would
> be ok.

Backporting would seem fine - we're still quite far away from 4.6.1.

Jan


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

Re: [Xen-devel] [PATCH XEN v5 07/23] tools: Refactor /dev/xen/gnt{dev, shr} wrappers into libxengnttab.

[Ian Campbell]

On Fri, 2015-11-13 at 15:38 -0500, Daniel De Graaf wrote:
> On 13/11/15 10:02, Ian Campbell wrote:
> > On Wed, 2015-11-11 at 15:03 +, Ian Jackson wrote:
> > > Ian Campbell writes ("[PATCH XEN v5 07/23] tools: Refactor
> > > /dev/xen/gnt{dev,shr} wrappers into libxengnttab."):
> > > > libxengnttab will provide a stable API and ABI for accessing the
> > > > grant table devices.
> > > > 
> > > > The functions are moved into the xengnt{tab,shr} namespace to make
> > > > a
> > > > clean break from libxc and avoid ambiguity regarding which
> > > > interfaces
> > > > are stable.
> > > 
> > > I have reviewed the API.  Mostly this produced questions...
> > 
> > Yes, thanks this is the sort of feedback I was looking for before we
> > call
> > this a stable interface.
> > 
> > Some of my answers are of the "yes, we should decide that" variety.
> > 
> > Daniel, I've added you because some of the questions below relate to
> > the
> > notification mechanism and to gntshr which I don't really understand
> > (not
> > that I really understand gnttab either).
> 
> Responses below.

Thanks.

>   I also agree that unifying the interfaces would be
> better.
> 
> [...]
> > > > +/**
> > > > + * Memory maps a grant reference from one domain to a local
> > > > address
> > > > range.
> > > > + * Mappings should be unmapped with xengnttab_munmap. If
> > > > notify_offset
> > > > or
> > > > + * notify_port are not -1, this version will attempt to set up an
> > > > unmap
> > > > + * notification at the given offset and event channel. When the
> > > > page
> > > > is
> > > > + * unmapped, the byte at the given offset will be zeroed and a
> > > > wakeup
> > > > will be
> > > > + * sent to the given event channel.  Logs errors.
> > > 
> > > What happens if the unmap notification cannot be set up ?
> > > 
> > > Also "when the page is unmapped" makes it sound like you mean
> > > xengnttab_munmap but actually I think this is when the grant is
> > > withdrawn by the grantor ?
> > > 
> > > If the grant is withdrawn by the grantor, does the page become
> > > unuseable immediately ?  If so, how can anyone ever use this safely ?
> > 
> > Daniel, could you answer these ones please.
> 
> This is intended to allow the kernel to send a close-request notification
> when the application that allocated the grant page exits without calling
> a proper shutdown (i.e. it crashes, calls _exit, calls execve, etc).

That is the kernel of the grantor or grantee process? It sounds like
grantor tells grantee (who would then be expected to unmap?)

Who actually does the unmap, the grantee process or their kernel? I suppose
the process, which is expected to be watching for the notification and is
required to do the unmap itself. IOW the "munmap notification" is a request
to please munmap, not a notification that something has been unmapped out
from beneath the calling process.

What happens if the unmap notification cannot be set up? Does the call fail
(and unmap what it has done) or does it succeed?

I think the answer to the other two questions depend on the clarifications
above, but I think it is the case that nothing is unmapped automatically,
all that this does is give you a result from evtchn_poll etc with the
expectation that the caller will call xengnttab_munmap in a controlled way
by themselves.

> Without this signal, the kernel has no way to request that the mapper of
> the page release it, and since Xen has no grant revocation mechanism, the
> page will likely be tied up until the process on the other side is told to
> release the page through some other method.



> 
> > > > +/*
> > > > + * Creates and shares pages with another domain.
> > > > + *
> > > ...
> > > > +void *xengntshr_share_pages(xengntshr_handle *xgs, uint32_t domid,
> > > > +int count, uint32_t *refs, int
> > > > writable);
> > > 
> > > Can this fail ?  Can it partially succeed ?
> > 
> > Daniel?
> 
> It can fail if you are out of pages to grant (there is a module parameter
> that can be adjusted via sysfs for the maximum), or in the unlikely case
> that the kernel itself is out of room in its grant mapping table (or if
> the syscall itself encounters -ENOMEM).

Does it either completely succeed or undo partial work, or does it return
partial success somehow?

> 
> > > > +/*
> > > > + * Creates and shares a page with another domain, with unmap
> > > > notification.
> > > > + *
> > > > + * @parm xgs a handle to an open grant sharing instance
> > > > + * @parm domid the domain to share memory with
> > > > + * @parm refs the grant reference of the pages (output)
> > > > + * @parm writable true if the other domain can write to the page
> > > > + * @parm notify_offset The byte offset in the page to use for
> > > > unmap
> > > > + * notification; -1 for none.
> > > > + * @parm notify_port The event channel port to use for unmap
> > > > notify,
> > > > or -1
> > > > + * @return local mapping of the page
> > > > + */
> > > > +void 

Re: [Xen-devel] [PATCH 00/13] tools: do cleanups related to libxc python bindings

[Juergen Gross]

On 16/11/15 13:09, Ian Campbell wrote:
> On Thu, 2015-11-12 at 13:01 +, Wei Liu wrote:
>> On Mon, Nov 09, 2015 at 04:19:24PM +0100, Juergen Gross wrote:
>>> On 10/23/2015 03:04 PM, Juergen Gross wrote:
 This series is a combination of my previous patches:

 "libxc: remove most of tools/libxc/xc_dom_compat_linux.c"
 "tools: remove unused wrappers for python"

 I have split it up as requested by Ian Campbell, thus it consists of
 13 patches instead just of 2, but the functionality is roughly the
 same. I have just kept more python bindings compared to the first
 version, as there have been reports of some out of tree uses. Asking
 for more such use case on xen-devel and xen-user didn't result in
 requests for more interfaces to be kept, so I delete them.
>>>
>>> There have been acks and critical responses regarding this series.
> 
> Have there? I don't have the stashed alongside the series as I would
> normally, so maybe I've missed them?

At least on #xendevel there was a rather clear statement towards not
removing code without any need, even if unused. This statement has not
been rejected by others.

I still think the python wrappers used by nobody are something we
should get rid of, OTOH I don't want to fight really hard for it. :-)

> 
>>> What should we do?
>>>
>>> - drop them all
>>> - apply the first two patches only to get rid of the extra interfaces
>>>   to the domain builder as requested by Ian Campbell
>>
>> I would go for this.
> 
> I've done this one.

Thanks.


Juergen


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

Re: [Xen-devel] [PATCH RFC 3/3] Revert "libxc: create an initial FPU state for HVM guests"

[Ian Campbell]

On Wed, 2015-10-14 at 17:30 +0100, Wei Liu wrote:
> On Wed, Oct 14, 2015 at 06:24:40PM +0200, Roger Pau Monne wrote:
> > This reverts commit d64dbbcc7c9934a46126c59d78536235908377ad.
> > 
> > Xen always set the FPU as initialized when loading a HVM context, so
> > libxc
> > has to provide a valid FPU context when setting the CPU registers.
> > 
> > This is a stop-gap measure in order to unblock OSSTest Windows 7
> > failures
> > while a proper fix for the HVM CPU save/restore is being worked on.
> 
> I think it is better to say in the commit message that a proper fix is
> in place so we can revert the stop-gap patch instead of copying the
> commit message from the patch this is being reverted.
> 
> Assuming I'm right about a proper fix will be committed before this
> patch and the commit message fixed:

Roger, Is the "proper fix" in tree now? If so then please can we get an
updated commit message which references that as Wei suggests.

I can update the message upon commit if you just want to provide the words,
or feel free to resend of course.

Ian.


> 
> Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 1/9] xen/arm: vgic-v3: Use the correct offset GICR_IGRPMODR0

[Ian Campbell]

On Fri, 2015-11-13 at 11:54 +, Julien Grall wrote:
> The offset is 0x0D00 and not 0x0F80.
> 
> Also re-order the definition to keep all the definitions ordered.
> 
> Signed-off-by: Julien Grall 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [PATCH 8/9] xen/arm: vgic-v3: Don't implement write-only register read as zero

[Ian Campbell]

On Fri, 2015-11-13 at 11:54 +, Julien Grall wrote:
> A read to a write only register is unknown. Use a memorable value to
> differentiate from an actual RAZ register.

Shame it's the same memorable value as every other memorable value in the
world ;-)

> Signed-off-by: Julien Grall 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] Unable to create Stubdomains with NIC(s) - Xen 4.5.2

[Peter Schmid]

Thank you for your quick responses.

Gesendet: Montag, 16. November 2015 um 13:41 Uhr
Von: "Wei Liu" 
An: "Ian Campbell" 
Cc: "Peter Schmid" , xen-devel@lists.xen.org, "Wei Liu" 

Betreff: Re: [Xen-devel] Unable to create Stubdomains with NIC(s) - Xen 4.5.2
On Mon, Nov 16, 2015 at 12:11:14PM +, Ian Campbell wrote:
> > On Mon, 2015-11-16 at 11:45 +0100, Peter Schmid wrote:
> > > Dear all
> > > I have been trying to setup stubdomains for added security on a test
> > > machine so I could then suggest to use xen at work with some added
> > > "backbone" and practical experience.
> > >
> > > Unfortunately I am unable to launch domains with a stubdomain when
> > > there's a NIC configured in the VM config file.
> > > The Domain launches without problems when I comment the vif= entry.
> > >  
> > > The Error I am getting is the following:
> > > libxl: error: libxl_dm.c:1284:stubdom_pvqemu_cb: error connecting nics
> > > devices: No such file or directory
> > > I have tried different types as well (ioemu, etc.).
> > >  
> > > More logs/configs can be found further below.
> > >  
> > > Thank you very much in advance,
> > >  Peter
> > >
> > >
> > > #
> > > $ xl create win7_install_test.cfg
> > > 
> > > Parsing config from win7_install_test.cfg
> > > libxl: error: libxl_dm.c:1284:stubdom_pvqemu_cb: error connecting nics
> > > devices: No such file or directory
> > > libxl: error: libxl_device.c:797:libxl__initiate_device_remove: unable to 
> > > get my domid
> >
> > These often suggests that your xencommons initscript is not up to date and
> > isn't populating some of the required nodes for dom0. I'm not sure if this
> > would have the knock on effect of the breakage you describe, but it is
> > worth fixing in any case.
> >
> > Given "No such file or directory" I'd also be inclined to check that
> > /etc/xen/scripts exists and has stuff in it, especially vif-* and that they
> > are executable, there #! refers to a shell which exists etc.

The scripts are all executable, here's an ls -l:
-rwxr-xr-x 1 root root 7726 Nov  3 10:11 block
-rwxr-xr-x 1 root root 3164 Nov  3 10:11 block-common.sh
-rwxr-xr-x 1 root root 2063 Nov  3 10:11 block-drbd-probe
-rwxr-xr-x 1 root root  498 Nov  3 10:11 block-enbd
-rwxr-xr-x 1 root root 3982 Nov  3 10:11 block-iscsi
-rwxr-xr-x 1 root root  498 Nov  3 10:11 block-nbd
-rwxr-xr-x 1 root root 2896 Nov  3 10:11 external-device-migrate
-rwxr-xr-x 1 root root  319 Nov 10 16:18 hotplugpath.sh
-rwxr-xr-x 1 root root 4960 Nov  3 10:11 locking.sh
-rwxr-xr-x 1 root root  804 Nov  3 10:11 logging.sh
-rwxr-xr-x 1 root root  840 Sep 11 12:20 qemu-ifup
-rwxr-xr-x 1 root root 7632 Nov  3 10:11 remus-netbuf-setup
-rwxr-xr-x 1 root root  850 Nov  3 10:11 vif2
-rwxr-xr-x 1 root root 2597 Nov  3 10:11 vif-bridge
-rwxr-xr-x 1 root root 5629 Nov  3 10:11 vif-common.sh
-rwxr-xr-x 1 root root 4624 Nov  3 10:11 vif-nat
-rwxr-xr-x 1 root root 3018 Nov  3 10:11 vif-openvswitch
-rwxr-xr-x 1 root root 1353 Nov  3 10:11 vif-route
-rwxr-xr-x 1 root root  105 Nov 10 16:17 vif-setup
-rwxr-xr-x 1 root root  243 Nov  3 10:11 vscsi
-rwxr-xr-x 1 root root 1442 Nov  3 10:11 xen-hotplug-cleanup
-rwxr-xr-x 1 root root 2887 Nov 10 16:17 xen-hotplug-common.sh
-rwxr-xr-x 1 root root 3162 Nov  3 10:11 xen-network-common.sh
-rwxr-xr-x 1 root root  993 Nov  3 10:11 xen-script-common.sh

> >
> > Weirdly our automated test test doesn't seem to include the stubdom jobs
> > for 4.5 (they appear to being at 4.6), but I can't see at all where such a
> > test is deliberately suppressed by the test code. Perhaps Wei (CC'd) knows.
> >
> 
> 4.5 has a bug that completely stops stubdom from working. Paul provided
> a workaround which was backported to 4.5.1. I considered 4.5 branch
> stubdom broken so I skipped that branch.
> 
> > FWIW the flights testing stbudom in xen-unstable use a cfg file which looks
> > like:
> >  
> > http://logs.test-lab.xenproject.org/osstest/logs/64035/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/merlot1---etc-xen-debianhvm.guest.osstest.>
> >  cfg
> >
> > It doesn't look to me to be materially very different to what you have.
> >
> > Ian.
> >
> > > libxl: error: libxl_device.c:797:libxl__initiate_device_remove: unable to
> > > get my domid
> 
> Can you try a config with vif then
> 
> xl create -p guest.cfg
> 
> And then use xl list to see if stubdom is alive?
> 
> You should see something similar to:
> 
> Name ID Mem VCPUs State Time(s)
> Domain-0 0 2863 4 r- 7041.7
> wheezy-hvm 699 511 1 --p--- 0.0
> wheezy-hvm-dm 700 32 1 r- 19.9
> 
> Wei.

xl create -p guest.cfg doesn't create any domains

so xl list has only dom0 in the output:

xl list
NameID   Mem VCPUs  State   Time(s)
(null)   0  1024 8 r- 230.7

Can you point me to the Patch which was backported to 

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

[osstest service owner]

flight 64453 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64453/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  ddebece6d540ac8d9211e9b3ff8f9c49cfccc428
baseline version:
 xen  cc967461e7f3b392990ca8c5ca02a435960ab0c7

Last test of basis64221  2015-11-13 15:00:58 Z2 days
Testing same since64453  2015-11-16 13:00:56 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  David Scott 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jim Fehlig 
  Jonathan Davies 
  Juergen Gross 
  Oleksandr Tyshchenko 
  Simon Rowe 
  Stefano Stabellini 
  Wei Liu 

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=ddebece6d540ac8d9211e9b3ff8f9c49cfccc428
+ . ./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 
ddebece6d540ac8d9211e9b3ff8f9c49cfccc428
+ branch=xen-unstable-smoke
+ revision=ddebece6d540ac8d9211e9b3ff8f9c49cfccc428
+ . ./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-unstable
+ '[' xddebece6d540ac8d9211e9b3ff8f9c49cfccc428 = 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/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 

[Xen-devel] [PATCH v6 1/3] public/io/netif.h: document the reality of netif_rx_request/reponse

[Paul Durrant]

Because GSO metadata is passed from backend to frontend using
netif_extra_info segments, which do not carry information stating which
netif_rx_request_t was consumed to free up their slot, frontends must
assume some form of identity relation between ring slot and request.
Hence, so that it is able to use GSO metadata, Linux netfront simply
assumes rx responses appear in the same ring slot as their corresponding
request.

This patch documents the assumption made by Linux netfront and the
necessity of the assumption (to support GSO) so that backends are coded
to be compatible.

Signed-off-by: Paul Durrant 
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
---

v4:
 - Add slightly more explanation in a comment

v5:
 - Re-word the comments since the restriction is not actually on
   the rx request/response id field, but the slots used by requests
   and responses.
---
 xen/include/public/io/netif.h | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
index 5c31ae3..04d8026 100644
--- a/xen/include/public/io/netif.h
+++ b/xen/include/public/io/netif.h
@@ -226,15 +226,29 @@
  * flags: NETRXF_*
  * status: -ve: NETIF_RSP_*; +ve: Rx'ed pkt size.
  *
+ * NOTE: Historically, to support GSO on the frontend receive side, Linux
+ *   netfront does not make use of the rx response id (because, as
+ *   described below, extra info structures overlay the id field).
+ *   Instead it assumes that responses always appear in the same ring
+ *   slot as their corresponding request. Thus, to maintain
+ *   compatibilty, backends must make sure this is the case.
+ *
  * Extra Info
  * ==
  *
- * Can be present if initial request has NET{T,R}XF_extra_info, or
- * previous extra request has XEN_NETIF_EXTRA_MORE.
+ * Can be present if initial request or response has NET{T,R}XF_extra_info,
+ * or previous extra request has XEN_NETIF_EXTRA_MORE.
  *
  * The struct therefore needs to fit into either a tx or rx slot and
  * is therefore limited to 8 octets.
  *
+ * NOTE: Because extra info data overlays the usual request/response
+ *   structures, there is no id information in the opposite direction.
+ *   So, if an extra info overlays an rx response the frontend can
+ *   assume that it is in the same ring slot as the request that was
+ *   consumed to make the slot available, and the backend must ensure
+ *   this assumption is true.
+ *
  * extra info (netif_extra_info_t)
  * ---
  *
-- 
2.1.4


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

Re: [Xen-devel] [xen-4.3-testing test] 63948: regressions - FAIL [and 1 more messages] [and 1 more messages]

[Jan Beulich]

>>> On 16.11.15 at 17:14,  wrote:
> Jan Beulich writes ("Re: [Xen-devel] [xen-4.3-testing test] 63948: 
> regressions - 
> FAIL [and 1 more messages] [and 1 more messages]"):
>> On 16.11.15 at 17:00,  wrote:
>> > Based on this, which is the only regression in 64287, we could force
>> > push this:
> ...
>> Well, yes, but wouldn't it re-occur once it managed to run on an
>> Intel box again?
> 
> Yes, but that's not very likely to happen soon.
> 
> This will allow us to think about the medium-term fix without the
> short-term breakage causing pain.

Okay. Why don't you go ahead then?

Jan


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

Re: [Xen-devel] [PATCH 07/10] x86/hvm: pkeys, add functions to support PKRU access/write

[Andrew Cooper]

On 16/11/15 10:31, Huaitong Han wrote:
> This patch adds functions to support PKRU access/write
>
> Signed-off-by: Huaitong Han 
>
> diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
> index f507f5e..427eb84 100644
> --- a/xen/include/asm-x86/processor.h
> +++ b/xen/include/asm-x86/processor.h
> @@ -336,6 +336,44 @@ static inline void write_cr4(unsigned long val)
>  asm volatile ( "mov %0,%%cr4" : : "r" (val) );
>  }
>  
> +static inline unsigned int read_pkru(void)
> +{
> +unsigned int eax, edx;
> +unsigned int ecx = 0;
> +unsigned int pkru;
> +
> +asm volatile(".byte 0x0f,0x01,0xee\n\t"
> + : "=a" (eax), "=d" (edx)
> + : "c" (ecx));
> +pkru = eax;
> +return pkru;

This can be far more simple.

{
unsigned int pkru;

asm volatile (".byte 0x0f,0x01,0xee"
: "=a" (pkru) : "c" (0) : "dx");

return pkru;
}

> +}
> +
> +static inline void write_pkru(unsigned int pkru)
> +{
> +unsigned int eax = pkru;
> +unsigned int ecx = 0;
> +unsigned int edx = 0;
> +
> +asm volatile(".byte 0x0f,0x01,0xef\n\t"
> + : : "a" (eax), "c" (ecx), "d" (edx));
> +}

I don't see any need for Xen to use WRPKRU, and this helper isn't used
anywhere in your series.  Please drop it (unless I have overlooked
something).

> +
> +/* macros for pkru */
> +#define PKRU_READ  0
> +#define PKRU_WRITE 1
> +#define PKRU_ATTRS 2
> +
> +/*
> +* PKRU defines 32 bits, there are 16 domains and 2 attribute bits per
> +* domain in pkru, pkeys is index to a defined domain, so the value of
> +* pte_pkeys * PKRU_ATTRS + R/W is offset of a defined domain attribute.
> +*/
> +#define READ_PKRU_AD(x) ((read_pkru() >> (x * PKRU_ATTRS + PKRU_READ)) & 1)
> +#define READ_PKRU_WD(x) ((read_pkru() >> (x * PKRU_ATTRS + PKRU_WRITE)) & 1)

Sorry, but no.  This hides expensive rdpkru instructions in innocuous code.

Instead, a function manipulating the keys should cache rdpkru once, and
use the following helpers:

static inline bool_t pkru_ad(unsigned int pkru, unsigned int key);
static inline bool_t pkru_wd(unsigned int pkru, unsigned int key);

~Andrew

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

Re: [Xen-devel] 9p file system for xen

[Wei Liu]

On Mon, Nov 16, 2015 at 09:36:24AM -0700, Linda wrote:
> Hi Wei,
> 
> On 11/16/2015 8:16 AM, Wei Liu wrote:
> >Hi Linda
> >
> >On Fri, Nov 13, 2015 at 10:23:22AM -0700, Linda wrote:
> >>Hello,
> >>  I worked this summer as an intern under Julien Grall and Wei Liu.  My
> >>project was to develop a prototype/proof of concept xen front/back end for
> >>the 9p file system.  I mostly hacked the virtio 9p system.
> >> This project was not complete, at the end of the summer.  Julien said
> >>that you all wanted to include this in the next release of xen in January,
> >>and offered to take it over.  I told Julien I wanted to continue working on
> >>it, which I have been doing, very much in the background.
> >> I came upon a bug in my code recently that made me aware that I am not
> >>clear what the expectation for what I deliver should be: i.e., whether it's
> >>still a prototype, or whether this should be production software.
> >> Right now, I do not modify the toolstack (I never learned how), but
> >>rather start and pause my guest, and then modify xenstore, manually.   I can
> >>fix my bug in the same manner, but this will limit the usefulness of what I
> >>deliver.  To do more will hit up against the limitations of my time and
> >>knowledge.
> >> So please let me know what you're expecting, especially wrt the user
> >>interface, and when I would need to complete everything for this release.
> >>
> >If I interpret this correctly, you have a prototype that's working? Do
> >you have your code somewhere?
> No.  I hit a bug that I would fix differently, depending on my goal.
> >I think we would still like to include it in next release if possible --
> >that would require a properly implemented solution, not just a
> >prototype.  Let's assess the current situation and then decide what to
> The situation is, given my current knowledge and what my availability has
> been (it may improve), I can either:
> a.  Get a decent prototype working by the end of the year.  This would
> have certain values pre-written in xenstore, that I'm currently doing
> manually.  There are potentially some issues with mounting that I suspect
> need to be different for xen than they are for virtio - so either way, I
> need a clarification of how xen people want this to work.
> b.  Make sure what I've written is working, and pass it on to someone
> else to update the toolstack, and resolve the issues, described above.  In
> this scenario, I would need to know how much time that someone would need
> and just devote a week to getting this to them.
> 

Your description is too vague. I don't have clear idea what kind of bug
you encountered and what suggestion I can give.

The code freeze for next release is going to be end of March next year.
As software engineer often overestimates the progress he or she can
make, I would say we shall aim for getting something working as soon as
possible. Get the design straight and something clean by the end of this
year would be good.

> Either way, my next step is to sync up my qemu with the current qemu, and
> merge everything, and then my github will be correct, at which point you'll
> be able to access my most recent code.
> 

That would be a good first step. You don't actually need to fix the bug
for that if you don't know how to proceed yet.

Wei.

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

Re: [Xen-devel] [PATCH] ns16550: reset bar_64 on each iteration

[Ian Campbell]

On Thu, 2015-11-12 at 16:58 +, Andrew Cooper wrote:
> On 12/11/15 15:52, Jan Beulich wrote:
> > Re-using the possibly non-zero value from a previous iteration can't
> > do any good.
> > 
> > Take the opportunity and
> > - limit a few other variables' scopes at once,
> > - adjust a few types.
> > 
> > Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Andrew Cooper 

On that basis, Acked-by: Ian Campbell 


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

Re: [Xen-devel] [PATCH 09/10] x86/hvm: pkeys, add pkeys support for guest_walk_tables

[Andrew Cooper]

On 16/11/15 10:31, Huaitong Han wrote:
> This patch adds pkeys support for guest_walk_tables.
>
> Signed-off-by: Huaitong Han 
>
> diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
> index 773454d..7a7ae96 100644
> --- a/xen/arch/x86/mm/guest_walk.c
> +++ b/xen/arch/x86/mm/guest_walk.c
> @@ -124,6 +124,46 @@ void *map_domain_gfn(struct p2m_domain *p2m, gfn_t gfn, 
> mfn_t *mfn,
>  return map;
>  }
>  
> +#if GUEST_PAGING_LEVELS >= 4
> +uint32_t leaf_pte_pkeys_check(struct vcpu *vcpu, uint32_t pfec,
> +uint32_t pte_access, uint32_t pte_pkeys)
> +{
> +unsigned int pkru_ad, pkru_wd;
> +unsigned int ff, wf, uf, rsvdf, pkuf;
> +
> +uf = pfec & PFEC_user_mode;
> +wf = pfec & PFEC_write_access;
> +rsvdf = pfec & PFEC_reserved_bit;
> +ff = pfec & PFEC_insn_fetch;
> +pkuf = pfec & PFEC_protection_key;
> +
> +if (!pkuf)
> +return 0;
> +
> +/*
> + * PKU:  additional mechanism by which the paging controls
> +* access to user-mode addresses based on the value in the
> +* PKRU register. A fault is considered as a PKU violation if all
> +* of the following conditions are ture:
> +* 1.CR4_PKE=1.
> +* 2.EFER_LMA=1.
> +* 3.page is present with no reserved bit violations.
> +* 4.the access is not an instruction fetch.
> +* 5.the access is to a user page.
> +* 6.PKRU.AD=1
> +*   or The access is a data write and PKRU.WD=1
> +*and either CR0.WP=1 or it is a user access.
> +*/

Please fix the alignment of the comment.

> +pkru_ad = READ_PKRU_AD(pte_pkeys);
> +pkru_wd = READ_PKRU_AD(pte_pkeys);
> +if ( hvm_pku_enabled(vcpu) && hvm_long_mode_enabled(vcpu) &&
> +!rsvdf && !ff && (pkru_ad ||
> +(pkru_wd && wf && (hvm_wp_enabled(vcpu) || uf
> +return 1;

Same comments as patch 8 for the PV case.

> +
> +return 0;
> +}
> +#endif
>  
>  /* Walk the guest pagetables, after the manner of a hardware walker. */
>  /* Because the walk is essentially random, it can cause a deadlock 
> @@ -141,6 +181,7 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
>  #if GUEST_PAGING_LEVELS >= 4 /* 64-bit only... */
>  guest_l3e_t *l3p = NULL;
>  guest_l4e_t *l4p;
> +uint32_t pkeys;
>  #endif
>  uint32_t gflags, mflags, iflags, rc = 0;
>  bool_t smep = 0, smap = 0;
> @@ -225,6 +266,7 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
>  goto out;
>  /* Get the l3e and check its flags*/
>  gw->l3e = l3p[guest_l3_table_offset(va)];
> +pkeys = guest_l3e_get_pkeys(gw->l3e);
>  gflags = guest_l3e_get_flags(gw->l3e) ^ iflags;
>  if ( !(gflags & _PAGE_PRESENT) ) {
>  rc |= _PAGE_PRESENT;
> @@ -234,6 +276,9 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
>  
>  pse1G = (gflags & _PAGE_PSE) && guest_supports_1G_superpages(v); 
>  
> +if (pse1G && leaf_pte_pkeys_check(v, pfec, gflags, pkeys))
> +rc |= _PAGE_PK_BIT;
> +
>  if ( pse1G )
>  {
>  /* Generate a fake l1 table entry so callers don't all 
> @@ -295,7 +340,6 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
>  gw->l2e = l2p[guest_l2_table_offset(va)];
>  
>  #endif /* All levels... */
> -

Spurious deletion.

>  gflags = guest_l2e_get_flags(gw->l2e) ^ iflags;
>  if ( !(gflags & _PAGE_PRESENT) ) {
>  rc |= _PAGE_PRESENT;
> @@ -305,6 +349,12 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
>  
>  pse2M = (gflags & _PAGE_PSE) && guest_supports_superpages(v); 
>  
> +#if GUEST_PAGING_LEVELS >= 4
> +pkeys = guest_l2e_get_pkeys(gw->l2e);
> +if (pse2M && leaf_pte_pkeys_check(v, pfec, gflags, pkeys))
> +rc |= _PAGE_PK_BIT;
> +#endif
> +
>  if ( pse2M )
>  {
>  /* Special case: this guest VA is in a PSE superpage, so there's
> @@ -365,6 +415,11 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
>  goto out;
>  }
>  rc |= ((gflags & mflags) ^ mflags);
> +#if GUEST_PAGING_LEVELS >= 4
> +pkeys = guest_l1e_get_pkeys(gw->l1e);
> +if (leaf_pte_pkeys_check(v, pfec, gflags, pkeys))
> +rc |= _PAGE_PK_BIT;
> +#endif

Without modifying the caller's logic, setting _PAGE_PK_BIT in the return
value isn't going to get propagated to the guest correctly.

~Andrew

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

Re: [Xen-devel] [xen-4.3-testing test] 63948: regressions - FAIL [and 1 more messages] [and 1 more messages]

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] [xen-4.3-testing test] 63948: regressions 
- FAIL [and 1 more messages] [and 1 more messages]"):
> On 16.11.15 at 17:14,  wrote:
> > This will allow us to think about the medium-term fix without the
> > short-term breakage causing pain.
> 
> Okay. Why don't you go ahead then?

Done.

Maybe we should bring AMD in and ask them if they want to fix this
migration ?

Ian.

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

[Xen-devel] [PATCH v6 3/3] public/io/netif.h: tidy up and remove duplicate comments

[Paul Durrant]

Now that requests and response types and extra info segments are
documented in block comments, we can get rid of the inline comments
in the structures. This has the happy side-effect of making the Linux
checkpatch.pl script make fewer complaints after import.

This patch also fixes a small whitespace issue in the initial boiler-
plate comment, and a typo in one of the ascii-art diagrams.

Signed-off-by: Paul Durrant 
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
---
 xen/include/public/io/netif.h | 81 +--
 1 file changed, 32 insertions(+), 49 deletions(-)

diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
index f62a0c8..e103cf3 100644
--- a/xen/include/public/io/netif.h
+++ b/xen/include/public/io/netif.h
@@ -1,8 +1,8 @@
 /**
  * netif.h
- * 
+ *
  * Unified network-device I/O interface for Xen guest OSes.
- * 
+ *
  * 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
@@ -153,8 +153,10 @@
 /*
  * This is the 'wire' format for packets:
  *  Request 1: netif_tx_request_t -- NETTXF_* (any flags)
- * [Request 2: netif_extra_info_t] (only if request 1 has NETTXF_extra_info)
- * [Request 3: netif_extra_info_t] (only if request 2 has XEN_NETIF_EXTRA_MORE)
+ * [Request 2: netif_extra_info_t] (only if request 1 has
+ *  NETTXF_extra_info)
+ * [Request 3: netif_extra_info_t] (only if request 2 has
+ *  XEN_NETIF_EXTRA_MORE)
  *  Request 4: netif_tx_request_t -- NETTXF_more_data
  *  Request 5: netif_tx_request_t -- NETTXF_more_data
  *  ...
@@ -256,7 +258,7 @@
  *
  *0 1 2 3 4 5 6 7  octet
  * +-+-+-+-+-+-+-+-+
- * |type |flags| type specfic data |
+ * |type |flags| type specific data|
  * +-+-+-+-+-+-+-+-+
  * | padding for tx|
  * +-+-+-+-+
@@ -264,7 +266,8 @@
  * type: XEN_NETIF_EXTRA_TYPE_*
  * flags: XEN_NETIF_EXTRA_FLAG_*
  * padding for tx: present only in the tx case due to 8 octet limit
- * from rx case. Not shown in type specific entries below.
+ * from rx case. Not shown in type specific entries
+ * below.
  *
  * XEN_NETIF_EXTRA_TYPE_GSO:
  *
@@ -275,9 +278,14 @@
  *
  * type: Must be XEN_NETIF_EXTRA_TYPE_GSO
  * flags: XEN_NETIF_EXTRA_FLAG_*
- * size: Maximum payload size of each segment.
- * type: XEN_NETIF_GSO_TYPE_*
- * features: EN_NETIF_GSO_FEAT_*
+ * size: Maximum payload size of each segment. For example,
+ *   for TCP this is just the path MSS.
+ * type: XEN_NETIF_GSO_TYPE_*: This determines the protocol of
+ *   the packet and any extra features required to segment the
+ *   packet properly.
+ * features: EN_NETIF_GSO_FEAT_*: This specifies any extra GSO
+ *   features required to process this packet, such as ECN
+ *   support for TCPv4.
  *
  * XEN_NETIF_EXTRA_TYPE_MCAST_{ADD,DEL}:
  *
@@ -309,11 +317,11 @@
 
 #define XEN_NETIF_MAX_TX_SIZE 0x
 struct netif_tx_request {
-grant_ref_t gref;  /* Reference to buffer page */
-uint16_t offset;   /* Offset within buffer page */
-uint16_t flags;/* NETTXF_* */
-uint16_t id;   /* Echoed in response message. */
-uint16_t size; /* Packet size in bytes.   */
+grant_ref_t gref;
+uint16_t offset;
+uint16_t flags;
+uint16_t id;
+uint16_t size;
 };
 typedef struct netif_tx_request netif_tx_request_t;
 
@@ -338,43 +346,18 @@ typedef struct netif_tx_request netif_tx_request_t;
  * netif_rx_response_t for compatibility.
  */
 struct netif_extra_info {
-uint8_t type;  /* XEN_NETIF_EXTRA_TYPE_* */
-uint8_t flags; /* XEN_NETIF_EXTRA_FLAG_* */
-
+uint8_t type;
+uint8_t flags;
 union {
-/*
- * XEN_NETIF_EXTRA_TYPE_GSO:
- */
 struct {
-/*
- * Maximum payload size of each segment. For example, for TCP this
- * is just the path MSS.
- */
 uint16_t size;
-
-/*
- * GSO type. This determines the protocol of the packet and any
- * extra features required to segment the packet properly.
- */
-uint8_t type; /* XEN_NETIF_GSO_TYPE_* */
-
-/* Future expansion. */
+uint8_t type;
 uint8_t pad;
-
-/*
- * GSO features. This specifies any extra GSO features required
- * to process this packet, such as ECN support 

[Xen-devel] [PATCH v6 0/3] updates to public/io/netif.h

[Paul Durrant]

v5 of this series included updates to support NDIS RSS for Windows
frontends. Since review concluded that some more fundamental changes
were needed in the protocol, v6 is just the surrounding cleanup patches
which are still relevant.
Another series will be posted for RSS related infrastructure.

Patch #1 documents the (sad) reality of the netif_rx_request/response
protocol, which has been long overdue.

Patch #2 adds a definition of the NETRXF_gso_prefix flag which has been
present in the Linux variant of the header for several years

Patch #3 reduces comment duplication and fixes formatting.

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

Re: [Xen-devel] [xen-4.3-testing test] 63948: regressions - FAIL [and 1 more messages] [and 1 more messages]

[Ian Jackson]

Ian Jackson writes ("Re: [Xen-devel] [xen-4.3-testing test] 63948: regressions 
- FAIL [and 1 more messages]"):
> I wonder how easy it would be to filter out the wrong advertisement,
> during outgoing migration, in the toolstack in 4.2.  I appreciate that
> 4.2 is long-dead.  So maybe we should just leave it.  Users can shut
> down and restart their guests.

For now I think the easiest fix is:

osstest service owner writes ("[xen-4.3-testing test] 64287: regressions - 
FAIL"):
> flight 64287 xen-4.3-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/64287/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-migrupgrade 21 guest-migrate/src_host/dst_host fail REGR. 
> vs. 63212

Based on this, which is the only regression in 64287, we could force
push this:

> version targeted for testing:
>  xen  fd1e4cc4d1d100337931b6f6dc50ed0b9766968a
> baseline version:
>  xen  85ca813ec23c5a60680e4a13777dad530065902b
> 
> Last test of basis63212  2015-10-22 10:03:01 Z   24 days
> Failing since 63360  2015-10-29 13:39:04 Z   17 days   12 attempts
> Testing same since64090  2015-11-10 18:01:42 Z5 days3 attempts

Ian.

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

Re: [Xen-devel] [xen-4.3-testing test] 63948: regressions - FAIL [and 1 more messages] [and 1 more messages]

[Jan Beulich]

>>> On 16.11.15 at 17:00,  wrote:
> Ian Jackson writes ("Re: [Xen-devel] [xen-4.3-testing test] 63948: 
> regressions - 
> FAIL [and 1 more messages]"):
>> I wonder how easy it would be to filter out the wrong advertisement,
>> during outgoing migration, in the toolstack in 4.2.  I appreciate that
>> 4.2 is long-dead.  So maybe we should just leave it.  Users can shut
>> down and restart their guests.
> 
> For now I think the easiest fix is:
> 
> osstest service owner writes ("[xen-4.3-testing test] 64287: regressions - 
> FAIL"):
>> flight 64287 xen-4.3-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/64287/ 
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-amd64-amd64-migrupgrade 21 guest-migrate/src_host/dst_host fail REGR. 
>> vs. 63212
> 
> Based on this, which is the only regression in 64287, we could force
> push this:
> 
>> version targeted for testing:
>>  xen  fd1e4cc4d1d100337931b6f6dc50ed0b9766968a
>> baseline version:
>>  xen  85ca813ec23c5a60680e4a13777dad530065902b
>> 
>> Last test of basis63212  2015-10-22 10:03:01 Z   24 days
>> Failing since 63360  2015-10-29 13:39:04 Z   17 days   12 attempts
>> Testing same since64090  2015-11-10 18:01:42 Z5 days3 attempts

Well, yes, but wouldn't it re-occur once it managed to run on an
Intel box again?

Jan


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

Re: [Xen-devel] [PATCHv2 2/3] mm: don't free pages until mm locks are released

[Jan Beulich]

>>> On 16.11.15 at 13:02,  wrote:
> On 16/11/15 11:52, Jan Beulich wrote:
> On 13.11.15 at 19:49,  wrote:
>>> @@ -2805,6 +2806,9 @@ int p2m_add_foreign(struct domain *tdom, unsigned 
>>> long 
> fgfn,
>>>  prev_mfn = mfn_x(get_gfn(tdom, gpfn, _prev));
>>>  if ( mfn_valid(_mfn(prev_mfn)) )
>>>  {
>>> +prev_page = mfn_to_page(_mfn(prev_mfn));
>>> +get_page(prev_page, tdom);
>> 
>> If you're absolutely sure that this can never fail, then still at the very
>> least this imo should be documented by a respective ASSERT() (or
>> ASSERT_UNREACHABLE()).
> 
> What are you suggesting may fail?

get_page()

Jan


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

Re: [Xen-devel] [PATCHv2 2/3] mm: don't free pages until mm locks are released

[David Vrabel]

On 16/11/15 11:52, Jan Beulich wrote:
 On 13.11.15 at 19:49,  wrote:
>> @@ -2805,6 +2806,9 @@ int p2m_add_foreign(struct domain *tdom, unsigned long 
>> fgfn,
>>  prev_mfn = mfn_x(get_gfn(tdom, gpfn, _prev));
>>  if ( mfn_valid(_mfn(prev_mfn)) )
>>  {
>> +prev_page = mfn_to_page(_mfn(prev_mfn));
>> +get_page(prev_page, tdom);
> 
> If you're absolutely sure that this can never fail, then still at the very
> least this imo should be documented by a respective ASSERT() (or
> ASSERT_UNREACHABLE()).

What are you suggesting may fail?

David

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

Re: [Xen-devel] [PATCH v8 01/21] xen/x86: add bitmap of enabled emulated devices

[Jan Beulich]

>>> On 06.11.15 at 17:05,  wrote:
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -265,7 +265,31 @@ typedef struct arch_shared_info arch_shared_info_t;
>   * XEN_DOMCTL_INTERFACE_VERSION.
>   */
>  struct xen_arch_domainconfig {
> -char dummy;
> +#define _XEN_X86_EMU_LAPIC  0
> +#define XEN_X86_EMU_LAPIC   (1U<<_XEN_X86_EMU_LAPIC)
> +#define _XEN_X86_EMU_HPET   1
> +#define XEN_X86_EMU_HPET(1U<<_XEN_X86_EMU_HPET)
> +#define _XEN_X86_EMU_PM 2
> +#define XEN_X86_EMU_PM  (1U<<_XEN_X86_EMU_PM)
> +#define _XEN_X86_EMU_RTC3
> +#define XEN_X86_EMU_RTC (1U<<_XEN_X86_EMU_RTC)
> +#define _XEN_X86_EMU_IOAPIC 4
> +#define XEN_X86_EMU_IOAPIC  (1U<<_XEN_X86_EMU_IOAPIC)
> +#define _XEN_X86_EMU_PIC5
> +#define XEN_X86_EMU_PIC (1U<<_XEN_X86_EMU_PIC)
> +#define _XEN_X86_EMU_VGA6
> +#define XEN_X86_EMU_VGA (1U<<_XEN_X86_EMU_VGA)
> +#define _XEN_X86_EMU_IOMMU  7
> +#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)

While only used for a domctl (so far), I still think we should aim at
making this a complete set (i.e. preempt future additions to the
set if at all possible). I say this because - having looked again - I'm
missing things like MTRR, PAT, and 8254 here.

Jan


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

[Xen-devel] [linux-3.10 test] 64300: regressions - FAIL

[osstest service owner]

flight 64300 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64300/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 5 kernel-build  fail REGR. vs. 62642

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail in 64136 pass 
in 64300
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail pass in 64136

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail in 64136 like 62642
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62642
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 62642

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 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-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-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-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 linuxbdf8cfb859e9cd265ec1696d9e007fac66e7aea7
baseline version:
 linuxf5552cd830e58c46dffae3617b3ce0c839771981

Last test of basis62642  2015-10-03 17:59:45 Z   43 days
Failing since 63224  2015-10-22 22:20:05 Z   24 days   18 attempts
Testing same since64001  2015-11-10 00:11:01 Z6 days4 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Aaron Conole 
  Adam Radford 
  Al Viro 
  Alexander Couzens 
  Alexey Klimov 
  Andi Kleen 
  Andreas Schwab 
  Andrew Morton 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  Ben Hutchings 
  Ben Skeggs 
  Cathy Avery 
  Charles Keepax 
  Christoph Biedl 
  Christoph Hellwig 
  cov...@ccs.covici.com 
  Daniel Vetter 
  Daniel Vetter 
  Dave Kleikamp 
  David S. Miller 
  David Vrabel 
  David Woodhouse 
  David Woodhouse 
  Ding Tianhong 
  dingtianhong 
  Dirk Mueller 
  Dirk Müller 
  Doron Tsur 
  Doug Ledford 
  Dāvis Mosāns 
  Eric Dumazet 
  Eric W. Biederman 
  Felix Fietkau 
  G. Richard Bellamy 
  Geert Uytterhoeven 
  Greg Kroah-Hartman 
  Guenter Roeck 
  Guillaume Nault 
  H. Peter Anvin 
  Herbert Xu 
  Ian Abbott 
  Ilia Mirkin 
  Ilya Dryomov 
  Ingo Molnar 
  James Bottomley 
  James Chapman 
  James Hogan 
  Jan Kara 
  Jan Kara 
  Jann Horn 
  Jarkko Nikula 
  Jeff Mahoney 
  Jes Sorensen 
  Jiri Slaby 
  Joe Perches 
  Joe Stringer 
  Joe Thornber 
  Joe Thornber 
  Joerg Roedel 
  Johan Hovold 
  Johannes Berg 
  John Covici 
  Julian Anastasov 
  Kalle Valo 
  Kees Cook 
  Konrad Rzeszutek Wilk 
  Linus Torvalds 
  

Re: [Xen-devel] [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown

[Ian Campbell]

On Mon, 2015-11-16 at 13:16 +, Paul Durrant wrote:
> > 
> > > +ret = vasprintf(, fmt, ap);
> > >  if (ret == -1) {
> > >  return -1;
> > >  }
> > >  xs_write(ctx->xsh, t, path, s, ret);
> > > +if (perms)
> > > +xs_set_permissions(ctx->xsh, t, path, perms, num_perms);
> > 
> > This can fail, can't it? (OTOH so can xs_write, so maybe there is some
> > reason we apparently don't care for such things here?)
> > 
> 
> That's a good point. I would have thought wiring an xs_write() failure
> back through to the caller would be a good idea (and same goes for
> xs_set_permissions, I guess).

git tells me it has been this way since libxl was first committed to the
repo. I can't think of a good reason to squash these errors.

Ian.


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

Re: [Xen-devel] Unable to create Stubdomains with NIC(s) - Xen 4.5.2

[Wei Liu]

On Mon, Nov 16, 2015 at 02:36:51PM +0100, Peter Schmid wrote:
[...]
> xl create -p guest.cfg doesn't create any domains
> 

That's probably stubdom already crashed and it triggered domain
destruction.

> so xl list has only dom0 in the output:
> 
> xl list
> NameID   Mem VCPUs  State   
> Time(s)
> (null)   0  1024 8 r- 
> 230.7
> 

Hmm... This is not right. Can you do xenstore-ls -f and paste in output?

Have you run xen-init-dom0?

Also xl dmesg can give some insight on whether stubdom crashes. (I see
you already have guest_loglvl=all in xen command line)

> Can you point me to the Patch which was backported to 4.5?
> 

dd748d128d86996592afafea02e578cc7d4e6d42 in master branch. It should be
in 4.5.1 already, which means your 4.5.2 is OK.

Wei.



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

Re: [Xen-devel] [PATCH 05/10] x86/hvm: pkeys, disable pkeys for guests in non-paging mode

[Andrew Cooper]

On 16/11/15 10:31, Huaitong Han wrote:
> This patch disables pkeys for guest in non-paging mode, However XEN always 
> uses
> paging mode to emulate guest non-paging mode, To emulate this behavior, pkeys
> needs to be manually disabled when guest switches to non-paging mode.
>
> Signed-off-by: Huaitong Han 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 00/13] tools: do cleanups related to libxc python bindings

[Ian Campbell]

On Mon, 2015-11-16 at 13:30 +0100, Juergen Gross wrote:
> On 16/11/15 13:09, Ian Campbell wrote:
> > On Thu, 2015-11-12 at 13:01 +, Wei Liu wrote:
> > > On Mon, Nov 09, 2015 at 04:19:24PM +0100, Juergen Gross wrote:
> > > > On 10/23/2015 03:04 PM, Juergen Gross wrote:
> > > > > This series is a combination of my previous patches:
> > > > > 
> > > > > "libxc: remove most of tools/libxc/xc_dom_compat_linux.c"
> > > > > "tools: remove unused wrappers for python"
> > > > > 
> > > > > I have split it up as requested by Ian Campbell, thus it consists
> > > > > of
> > > > > 13 patches instead just of 2, but the functionality is roughly
> > > > > the
> > > > > same. I have just kept more python bindings compared to the first
> > > > > version, as there have been reports of some out of tree uses.
> > > > > Asking
> > > > > for more such use case on xen-devel and xen-user didn't result in
> > > > > requests for more interfaces to be kept, so I delete them.
> > > > 
> > > > There have been acks and critical responses regarding this series.
> > 
> > Have there? I don't have the stashed alongside the series as I would
> > normally, so maybe I've missed them?
> 
> At least on #xendevel there was a rather clear statement towards not
> removing code without any need, even if unused. This statement has not
> been rejected by others.

Part of me thinks that such statements made on #xendevel may as well not
have been made as far as the formal review process goes.

But...

> I still think the python wrappers used by nobody are something we
> should get rid of, OTOH I don't want to fight really hard for it. :-)

... I think this is the right approach when dealing with such removals,
i.e. to try and abort upon valid complaints.

Ian.

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

Re: [Xen-devel] [PATCH v4 1/3] xen: move wallclock functions from x86 to common

[Ian Campbell]

On Thu, 2015-11-12 at 17:46 +, Stefano Stabellini wrote:
> Remove dummy arm implementation of wallclock_time.
> Use shared_info() in common code rather than x86-ism to access it, when
> possible.
> 
> Define the static variable wc_sec, and the local variale sec in

                                                   variable

> update_domain_wallclock_time, as uint64_t instead of unsigned long, to
> avoid size issue on arm.

             issues

> Take a uint64_t sec paramter in do_settime for the same reason.

                      parameter

> 
> Signed-off-by: Stefano Stabellini 
> Acked-by: Jan Beulich 

Apart from the typos:

Acked-by: Ian Campbell 

> CC: jbeul...@suse.com
> CC: andrew.coop...@citrix.com
> 
> ---
> 
> Changes in v3:
> - remove stray blank lines
> 
> Changes in v2:
> - remove stray blank lines
> - remove include 
> - move version_update_* to include/xen/time.h
> - introduce ifdef to fix build issue in common/time.c
> - define wc_sec and sec as uint64_t
> - pass u64 to do_settime
> ---
>  xen/arch/arm/time.c|5 ---
>  xen/arch/x86/time.c|   96 +-
> --
>  xen/common/time.c  |   95
> ++-
>  xen/include/xen/time.h |5 ++-
>  4 files changed, 99 insertions(+), 102 deletions(-)
> 
> diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> index 5ded30c..6207615 100644
> --- a/xen/arch/arm/time.c
> +++ b/xen/arch/arm/time.c
> @@ -280,11 +280,6 @@ void domain_set_time_offset(struct domain *d,
> int64_t time_offset_seconds)
>  /* XXX update guest visible wallclock time */
>  }
>  
> -struct tm wallclock_time(uint64_t *ns)
> -{
> -return (struct tm) { 0 };
> -}
> -
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
> index bbb7e6c..0f16db5 100644
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -47,9 +47,6 @@ string_param("clocksource", opt_clocksource);
>  unsigned long __read_mostly cpu_khz;  /* CPU clock frequency in kHz. */
>  DEFINE_SPINLOCK(rtc_lock);
>  unsigned long pit0_ticks;
> -static unsigned long wc_sec; /* UTC time at last 'time update'. */
> -static unsigned int wc_nsec;
> -static DEFINE_SPINLOCK(wc_lock);
>  
>  struct cpu_time {
>  u64 local_tsc_stamp;
> @@ -783,10 +780,6 @@ uint64_t tsc_ticks2ns(uint64_t ticks)
>  return scale_delta(ticks, >tsc_scale);
>  }
>  
> -/* Explicitly OR with 1 just in case version number gets out of sync. */
> -#define version_update_begin(v) (((v)+1)|1)
> -#define version_update_end(v)   ((v)+1)
> -
>  static void __update_vcpu_system_time(struct vcpu *v, int force)
>  {
>  struct cpu_time   *t;
> @@ -900,37 +893,6 @@ void force_update_vcpu_system_time(struct vcpu *v)
>  __update_vcpu_system_time(v, 1);
>  }
>  
> -void update_domain_wallclock_time(struct domain *d)
> -{
> -uint32_t *wc_version;
> -unsigned long sec;
> -
> -spin_lock(_lock);
> -
> -wc_version = _info(d, wc_version);
> -*wc_version = version_update_begin(*wc_version);
> -wmb();
> -
> -sec = wc_sec + d->time_offset_seconds;
> -if ( likely(!has_32bit_shinfo(d)) )
> -{
> -d->shared_info->native.wc_sec= sec;
> -d->shared_info->native.wc_nsec   = wc_nsec;
> -d->shared_info->native.wc_sec_hi = sec >> 32;
> -}
> -else
> -{
> -d->shared_info->compat.wc_sec = sec;
> -d->shared_info->compat.wc_nsec= wc_nsec;
> -d->shared_info->compat.arch.wc_sec_hi = sec >> 32;
> -}
> -
> -wmb();
> -*wc_version = version_update_end(*wc_version);
> -
> -spin_unlock(_lock);
> -}
> -
>  static void update_domain_rtc(void)
>  {
>  struct domain *d;
> @@ -988,27 +950,6 @@ int cpu_frequency_change(u64 freq)
>  return 0;
>  }
>  
> -/* Set clock to  after 00:00:00 UTC, 1 January, 1970. */
> -void do_settime(unsigned long secs, unsigned int nsecs, u64
> system_time_base)
> -{
> -u64 x;
> -u32 y;
> -struct domain *d;
> -
> -x = SECONDS(secs) + nsecs - system_time_base;
> -y = do_div(x, 10);
> -
> -spin_lock(_lock);
> -wc_sec  = x;
> -wc_nsec = y;
> -spin_unlock(_lock);
> -
> -rcu_read_lock(_read_lock);
> -for_each_domain ( d )
> -update_domain_wallclock_time(d);
> -rcu_read_unlock(_read_lock);
> -}
> -
>  /* Per-CPU communication between rendezvous IRQ and softirq handler. */
>  struct cpu_calibration {
>  u64 local_tsc_stamp;
> @@ -1608,25 +1549,6 @@ void send_timer_event(struct vcpu *v)
>  send_guest_vcpu_virq(v, VIRQ_TIMER);
>  }
>  
> -/* Return secs after 00:00:00 localtime, 1 January, 1970. */
> -unsigned long get_localtime(struct domain *d)
> -{
> -return wc_sec + (wc_nsec + NOW()) / 10ULL 
> -+ d->time_offset_seconds;
> -}
> -
> -/* Return microsecs after 00:00:00 localtime, 1 January, 1970. */
> 

Re: [Xen-devel] [PATCH v4 2/3] arm: export platform_op XENPF_settime64

[Ian Campbell]

On Thu, 2015-11-12 at 17:46 +, Stefano Stabellini wrote:
> Call update_domain_wallclock_time at domain initialization.
> Set time_offset_seconds to the number of seconds between physical boot
> and domain initialization: it is going to be used to get/set the
> wallclock time.
> Add time_offset_seconds to system_time when before calling do_settime,
> so that system_time actually accounts for all the time in nsec between
> machine boot and when the wallclock was set.
> 
> Expose xsm_platform_op to ARM.
> 
> Signed-off-by: Stefano Stabellini 

Acked-by: Ian Campbell 

An aside:[...]
@@ -1332,6 +1332,75 @@ static int flask_deassign_dtdevice(struct domain
> *d, const char *dtpath)
>  }
>  #endif /* HAS_PASSTHROUGH && HAS_DEVICE_TREE */
>  
> +static int flask_platform_op(uint32_t op)
> +{
> +switch ( op )
> +{
> +#ifdef CONFIG_X86
> +/* These operations have their own XSM hooks */
> +case XENPF_cpu_online:
> +case XENPF_cpu_offline:
> +case XENPF_cpu_hotadd:
> +case XENPF_mem_hotadd:
> +return 0;

Should this not then be an error (e.g. fail closed)?

Also, although only implemented today for x86 they don't seem inherently
any more x86 specific than many of the other things below, so maybe the
ifdef could be ditched?


> +#endif
> +
> +case XENPF_settime32:
> +case XENPF_settime64:
> +return domain_has_xen(current->domain, XEN__SETTIME);
> +
> +case XENPF_add_memtype:
> +return domain_has_xen(current->domain, XEN__MTRR_ADD);
> +
> +case XENPF_del_memtype:
> +return domain_has_xen(current->domain, XEN__MTRR_DEL);
> +
> +case XENPF_read_memtype:
> +return domain_has_xen(current->domain, XEN__MTRR_READ);
> +
> +case XENPF_microcode_update:
> +return domain_has_xen(current->domain, XEN__MICROCODE);
> +
> +case XENPF_platform_quirk:
> +return domain_has_xen(current->domain, XEN__QUIRK);
> +
> +case XENPF_firmware_info:
> +return domain_has_xen(current->domain, XEN__FIRMWARE);
> +
> +case XENPF_efi_runtime_call:
> +return domain_has_xen(current->domain, XEN__FIRMWARE);
> +
> +case XENPF_enter_acpi_sleep:
> +return domain_has_xen(current->domain, XEN__SLEEP);
> +
> +case XENPF_change_freq:
> +return domain_has_xen(current->domain, XEN__FREQUENCY);
> +
> +case XENPF_getidletime:
> +return domain_has_xen(current->domain, XEN__GETIDLE);
> +
> +case XENPF_set_processor_pminfo:
> +case XENPF_core_parking:
> +return domain_has_xen(current->domain, XEN__PM_OP);
> +
> +case XENPF_get_cpu_version:
> +case XENPF_get_cpuinfo:
> +return domain_has_xen(current->domain, XEN__GETCPUINFO);
> +
> +case XENPF_resource_op:
> +return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
> +XEN2__RESOURCE_OP, NULL);
> +
> +case XENPF_get_symbol:
> +return avc_has_perm(domain_sid(current->domain), SECINITSID_XEN,
> +SECCLASS_XEN2, XEN2__GET_SYMBOL, NULL);
> +
> +default:
> +printk("flask_platform_op: Unknown op %d\n", op);
> +return -EPERM;
> +}
> +}
> +
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 3/3] xen/arm: move ticks conversions function declarations to the header file

[Ian Campbell]

On Thu, 2015-11-12 at 17:46 +, Stefano Stabellini wrote:
> This is just a cleanup, not required at the moment.
> 
> Signed-off-by: Stefano Stabellini 

Acked-by: Ian Campbell 



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

Re: [Xen-devel] [PATCH v4 0/3] wallclock time on arm

[Ian Campbell]

On Thu, 2015-11-12 at 17:45 +, Stefano Stabellini wrote:
> Hi all,
> 
> this small series enables the wallclock time on arm and it consists
> mostly in code movement from x86 to common.

AFAICT this is all now suitably acked, but I wanted to coordinate with you
on the guest side changes before applying.

Ian.

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

Re: [Xen-devel] [PATCH v2 1/2] xen/serial: Move any OMAP specific things to OMAP UART driver

[Oleksandr Tyshchenko]

Thanks!

On Mon, Nov 16, 2015 at 2:07 PM, Ian Campbell  wrote:
> On Fri, 2015-11-06 at 04:26 -0700, Jan Beulich wrote:
>> > > > On 05.11.15 at 18:53,  wrote:
>> > The 8250-uart.h contains extra serial register definitions
>> > for the internal UARTs in TI OMAP SoCs which are used in
>> > OMAP UART driver only.
>> > In order to clean up code move these definitions to omap-uart.c.
>> > Also rename some definitions to follow to the UART_OMAP* prefix.
>> >
>> > Signed-off-by: Oleksandr Tyshchenko > > om>
>> > CC: Ian Campbell 
>> > CC: Julien Grall 
>> > CC: Stefano Stabellini 
>> > Cc: Jan Beulich 
>>
>> The Cc list of the mail disagrees with the list above, but nevertheless
>> Acked-by: Jan Beulich 
>
> Acked + applied both patches.
>



-- 

Oleksandr Tyshchenko | Embedded Dev
GlobalLogic
www.globallogic.com

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

Re: [Xen-devel] [PATCH 9/9] xen/arm: vgic-v3: Make clear that GICD_*SPI_* registers are reserved

[Ian Campbell]

On Fri, 2015-11-13 at 11:54 +, Julien Grall wrote:
> Our vGIC emulation have GICD_TYPER.MBIS set to 0 which means that
> GICD_*SPI_* registers are reserved. Implement them using the *_reserved
> labels.
> 
> Also, implement thoses registers for the read part.

"those" ("these" might be better though)

> 
> Signed-off-by: Julien Grall 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] Unable to create Stubdomains with NIC(s) - Xen 4.5.2

[Ian Campbell]

On Mon, 2015-11-16 at 11:45 +0100, Peter Schmid wrote:
> Dear all
> I have been trying to setup stubdomains for added security on a test
> machine so I could then suggest to use xen at work with some added
> "backbone" and practical experience.
> 
> Unfortunately I am unable to launch domains with a stubdomain when
> there's a NIC configured in the VM config file.
> The Domain launches without problems when I comment the vif= entry.
>  
> The Error I am getting is the following:
> libxl: error: libxl_dm.c:1284:stubdom_pvqemu_cb: error connecting nics
> devices: No such file or directory
> I have tried different types as well (ioemu, etc.).
>  
> More logs/configs can be found further below.
>  
> Thank you very much in advance,
>  Peter
> 
> 
> #
> $ xl create win7_install_test.cfg                                        
>         
> Parsing config from win7_install_test.cfg
> libxl: error: libxl_dm.c:1284:stubdom_pvqemu_cb: error connecting nics
> devices: No such file or directory
> libxl: error: libxl_device.c:797:libxl__initiate_device_remove: unable to get 
> my domid

These often suggests that your xencommons initscript is not up to date and
isn't populating some of the required nodes for dom0. I'm not sure if this
would have the knock on effect of the breakage you describe, but it is
worth fixing in any case.

Given "No such file or directory" I'd also be inclined to check that
/etc/xen/scripts exists and has stuff in it, especially vif-* and that they
are executable, there #! refers to a shell which exists etc.

Weirdly our automated test test doesn't seem to include the stubdom jobs
for 4.5 (they appear to being at 4.6), but I can't see at all where such a
test is deliberately suppressed by the test code. Perhaps Wei (CC'd) knows.

FWIW the flights testing stbudom in xen-unstable use a cfg file which looks
like:
 
http://logs.test-lab.xenproject.org/osstest/logs/64035/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/merlot1---etc-xen-debianhvm.guest.osstest.cfg

It doesn't look to me to be materially very different to what you have.

Ian.

> libxl: error: libxl_device.c:797:libxl__initiate_device_remove: unable to
> get my domid
> libxl: error: libxl_device.c:797:libxl__initiate_device_remove: unable to
> get my domid
> libxl: error: libxl_device.c:797:libxl__initiate_device_remove: unable to
> get my domid
> libxl: error: libxl.c:1652:devices_destroy_cb: libxl__devices_destroy
> failed for 2
> libxl: info: libxl.c:1698:devices_destroy_cb: forked pid 582 for destroy
> of domain 2
> libxl: error: libxl_create.c:1362:domcreate_attach_vtpms: unable to add
> nic devices
> libxl: error: libxl.c:1578:libxl__destroy_domid: non-existant domain 2
> libxl: error: libxl.c:1510:stubdom_destroy_callback: unable to destroy
> stubdom with domid 2
> libxl: error: libxl_device.c:797:libxl__initiate_device_remove: unable to
> get my domid
> libxl: error: libxl_device.c:797:libxl__initiate_device_remove: unable to
> get my domid
> libxl: error: libxl_device.c:797:libxl__initiate_device_remove: unable to
> get my domid
> libxl: error: libxl.c:1652:devices_destroy_cb: libxl__devices_destroy
> failed for 1
> libxl: info: libxl.c:1698:devices_destroy_cb: forked pid 596 for destroy
> of domain 1
> libxl: error: libxl_create.c:1482:domcreate_destruction_cb: unable to
> destroy domain 1 following failed creation
> #
> Here is my config file:
> #
> builder='hvm'
> memory = 8192
> name = "win7_test"
> ## vif = [ 'mac=00:fe:fe:ca:be:dd,bridge=xenbr0,model=e1000' ]
> vif = [ 'type=ioemu, bridge=xenbr0' ]
> uuid = "ffacbdff-abcd-abcd-cafe-deadbeefbabe"
> acpi = 1
> apic = 1
> disk = [ 'file:/home/user/win7_test_2015_11_02.img,hda,w', ]
> #--
> ---
> # boot on floppy (a), hard disk (c) or CD-ROM (d)
> # default: hard disk, cd-rom, floppy
> boot="c"
> # stubdomain:
> device_model_stubdomain_override = 1
> xen_platform_pci=0
> sdl=0
> vnc=1
> vncdisplay=0
> vncconsole=0
> vnclisten='0.0.0.0'
> vfb = [ 'type=vnc,vnclisten=0.0.0.0,vncunused=1' ]
> serial='pty'
> usbdevice='tablet'
> #
> running xl create with more verbose output:
> #
> Parsing config from win7_test_install_test_filedisk.cfg
> libxl: debug: libxl_create.c:1504:do_domain_create: ao 0xa190e0: create:
> how=(nil) callback=(nil) poller=0xa189c0
> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk
> vdev=hda spec.backend=unknown
> libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=hda, backend
> phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk
> vdev=hda, using backend qdisk
> libxl: debug: libxl_create.c:907:initiate_domain_create: running
> bootloader
> libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a PV
> domain, skipping bootloader
> libxl: debug: libxl_event.c:633:libxl__ev_xswatch_deregister: watch
> w=0xa198b0: deregister unregistered

Re: [Xen-devel] what's the equivalent function to "schedule_timeout" in xen kernel?

[Olaf Hering]

On Mon, Nov 16, Andrew Cooper wrote:

> On 16/11/15 06:36, Zhangbo (Oscar) wrote:
> > Hi all:
> > 　　I'd like to SLEEP a while in xen kernel during VMEXIT,  the easiest way 
> > is to call "udelay" or "mdelay" there. However, these 2 functions use busy 
> > wait to sleep, which is a waste.
> > 　　In linux kernel, there's a function named  'schedule_timeout', allowing 
> > the CPU to run other tasks during SLEEPING. 
> > 　　So, is there any equivalent function to "schedule_timeout" in xen kernel 
> > ? 
> > 　　Thanks in advance.
> > 　　
> 
> There is not any equivalent.  Paths through Xen are synchronous
> (scheduling vCPUS has different requirements/constraints than scheduling
> userspace tasks), and there are no concepts of tasks like the Linux
> kernel has.

For xenpaging xen/common/wait.c was invented, which gives some sort of
async. The thread of execution goes to sleep, until another thread wakes
it up again.

Olaf

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

Re: [Xen-devel] [PATCH v10] run QEMU as non-root

[Ian Campbell]

On Thu, 2015-11-05 at 12:47 +, Stefano Stabellini wrote:
> diff --git a/docs/misc/qemu-deprivilege.txt b/docs/misc/qemu-
> deprivilege.txt
> new file mode 100644
> index 000..dde74ab
> --- /dev/null
> +++ b/docs/misc/qemu-deprivilege.txt
> @@ -0,0 +1,31 @@
> +For security reasons, libxl tries to pass a non-root username to QEMU as
> +argument. During initialization QEMU calls setuid and setgid with the
> +user ID and the group ID of the user passed as argument.
> +Libxl looks for the following users in this order:
> +
> +1) a user named "xen-qemuuser-domid$domid",
> +Where $domid is the domid of the domain being created.
> +This requires the reservation of 65535 uids from xen-qemuuser-domid1
> +to xen-qemuuser-domid65535. To use this mechanism, you might want to
> +create a large number of users at installation time. For example:
> +
> +for ((i=1; i<65536; i++))
> +do
> +adduser --no-create-home --system xen-qemuuser-domid$i
> +done

I suppose we should integrate either this or suggestion #2 into osstest.
Will you send a patch?

I suppose ts-xen-install is the obvious place to do this, only quirk might
be making it idempotent (for convenience when running in standalone mode).
The adduser manpage suggests it already is:
       0  The  user exists as specified. This can have 2 causes:
  The user was  created  by  adduser  or  the  user  was
  already  present  on  the  system  before  adduser was
  invoked. If adduser was returning 0 , invoking adduser
  a  second time with the same parameters as before also
  returns 0.

So hopefully that is trivial.

> 
> +You might want to consider passing --group to adduser to create a new
> +group for each new user.
> +
> +
> +2) a user named "xen-qemuuser-shared"
> +As a fall back if both 1) fails, libxl will use a single user for
> +all QEMU instances. The user is named xen-qemuuser-shared. This is
> +less secure but still better than running QEMU as root. Using this is as
> +simple as creating just one more user on your host:
> +
> +adduser --no-create-home --system xen-qemuuser-shared
> +
> +
> +3) root
> +As a last resort, libxl will start QEMU as root.
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 168fedd..5edeb30 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -199,6 +199,11 @@
>   */
>  #define LIBXL_HAVE_DEVICETREE_PASSTHROUGH 1
>  
> +/* libxl_domain_build_info has device_model_user to specify the user to
> + * run the device model with. See docs/misc/qemu-deprivilege.txt.
> + */
> +#define LIBXL_HAVE_DEVICE_MODEL_USER 1
> +
>  /*
>   * libxl_domain_build_info has the arm.gic_version field.
>   */
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 9c9eaa3..151b6ed 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -21,6 +21,8 @@
>  
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  static const char *libxl_tapif_script(libxl__gc *gc)
>  {
> @@ -722,6 +724,36 @@ libxl__detect_gfx_passthru_kind(libxl__gc *gc,
>  return LIBXL_GFX_PASSTHRU_KIND_DEFAULT;
>  }
>  
> +/* return 1 if the user was found, 0 if it was not, -1 on error */
> +static int libxl__dm_runas_helper(libxl__gc *gc, const char *username)
> +{
> +struct passwd pwd, *user = NULL;
> +char *buf = NULL;
> +long buf_size;
> +int ret;
> +
> +buf_size = sysconf(_SC_GETPW_R_SIZE_MAX);
> +if (buf_size < 0) {
> +LOGE(ERROR, "sysconf(_SC_GETPW_R_SIZE_MAX) returned error %ld",
> +buf_size);
> +return ERROR_FAIL;
> +}
> +
> +while (1) {
> +buf = libxl__realloc(gc, buf, buf_size);
> +ret = getpwnam_r(username, , buf, buf_size, );
> +if (ret == ERANGE) {
> +buf_size += 128;
> +continue;
> +}
> +if (ret != 0)
> +return ERROR_FAIL;
> +if (user != NULL)
> +return 1;
> +return 0;
> +}
> +}
> +
>  static int libxl__build_device_model_args_new(libxl__gc *gc,
>  const char *dm, int guest_domid,
>  const libxl_domain_config
> *guest_config,
> @@ -740,9 +772,10 @@ static int
> libxl__build_device_model_args_new(libxl__gc *gc,
>  const char *keymap = dm_keymap(guest_config);
>  char *machinearg;
>  flexarray_t *dm_args, *dm_envs;
> -int i, connection, devid;
> +int i, connection, devid, ret;
>  uint64_t ram_size;
>  const char *path, *chardev;
> +char *user = NULL;
>  
>  dm_args = flexarray_make(gc, 16, 1);
>  dm_envs = flexarray_make(gc, 16, 1);
> @@ -1222,6 +1255,38 @@ static int
> libxl__build_device_model_args_new(libxl__gc *gc,
>  default:
>  break;
>  }
> +
> +if (b_info->device_model_user) {
> +user = b_info->device_model_user;
> +goto end_search;
> +}
> +
> +user = libxl__sprintf(gc, 

[Xen-devel] [PATCH] cxenstored: correct calculation of data/space in the ring

[Wei Liu]

The cxenstored implementation can't handle cross ring boundary read and
write. It gets aways with buggy behaviour because upper layer won't
sleep when short-write or short-read occurs.

It would be nice, however, to make the low level routine correct
regardless of what upper layer is doing. This should at least avoid
latent bug should upper layer logic changes.

This patch ports 8a2c11f8 ("tools/ocaml/xb: Correct calculations of
data/space the ring") for oxenstored to cxenstored.

Two functions -- get_{input,output}_chunks -- become unused. Nuke them.
Preserve the behaviour of always sending notification to the other end
when exiting.

Signed-off-by: Wei Liu 
---
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Andrew Cooper 
---
 tools/xenstore/xenstored_domain.c | 76 +--
 1 file changed, 42 insertions(+), 34 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c 
b/tools/xenstore/xenstored_domain.c
index dcd6581..4c0b87e 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -82,33 +82,12 @@ static bool check_indexes(XENSTORE_RING_IDX cons, 
XENSTORE_RING_IDX prod)
return ((prod - cons) <= XENSTORE_RING_SIZE);
 }
 
-static void *get_output_chunk(XENSTORE_RING_IDX cons,
- XENSTORE_RING_IDX prod,
- char *buf, uint32_t *len)
-{
-   *len = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(prod);
-   if ((XENSTORE_RING_SIZE - (prod - cons)) < *len)
-   *len = XENSTORE_RING_SIZE - (prod - cons);
-   return buf + MASK_XENSTORE_IDX(prod);
-}
-
-static const void *get_input_chunk(XENSTORE_RING_IDX cons,
-  XENSTORE_RING_IDX prod,
-  const char *buf, uint32_t *len)
-{
-   *len = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(cons);
-   if ((prod - cons) < *len)
-   *len = prod - cons;
-   return buf + MASK_XENSTORE_IDX(cons);
-}
-
 static int writechn(struct connection *conn,
-   const void *data, unsigned int len)
+   const void *buffer, unsigned int len)
 {
-   uint32_t avail;
-   void *dest;
struct xenstore_domain_interface *intf = conn->domain->interface;
XENSTORE_RING_IDX cons, prod;
+   int total_space, space;
 
/* Must read indexes once, and before anything else, and verified. */
cons = intf->rsp_cons;
@@ -120,25 +99,39 @@ static int writechn(struct connection *conn,
return -1;
}
 
-   dest = get_output_chunk(cons, prod, intf->rsp, );
-   if (avail < len)
-   len = avail;
+   total_space = XENSTORE_RING_SIZE - (prod - cons);
+   if (total_space == 0) {
+   /* No space at all - exit having done nothing. */
+   len = 0;
+   goto exit;
+   } else if (total_space < len)
+   /* Some space - make a partial write */
+   len = total_space;
+
+   space = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(prod);
+   if (len < space)
+   /* Message fits inside the remaining part of the ring */
+   memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), buffer, len);
+   else {
+   /* Message wraps around the end of ring. Write both halves. */
+   memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), buffer, space);
+   memcpy(intf->rsp, buffer + space, len - space);
+   }
 
-   memcpy(dest, data, len);
xen_mb();
intf->rsp_prod += len;
 
+exit:
xc_evtchn_notify(xce_handle, conn->domain->port);
 
return len;
 }
 
-static int readchn(struct connection *conn, void *data, unsigned int len)
+static int readchn(struct connection *conn, void *buffer, unsigned int len)
 {
-   uint32_t avail;
-   const void *src;
struct xenstore_domain_interface *intf = conn->domain->interface;
XENSTORE_RING_IDX cons, prod;
+   int total_data, data;
 
/* Must read indexes once, and before anything else, and verified. */
cons = intf->req_cons;
@@ -150,14 +143,29 @@ static int readchn(struct connection *conn, void *data, 
unsigned int len)
return -1;
}
 
-   src = get_input_chunk(cons, prod, intf->req, );
-   if (avail < len)
-   len = avail;
+   total_data = prod - cons;
+   if (total_data == 0) {
+   /* No pending data at all. */
+   len = 0;
+   goto exit;
+   } else if (total_data < len)
+   /* Some data - make a partial read. */
+   len = total_data;
+
+   data = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(cons);
+   if (len < data)
+   /* Data within the remaining part of the ring. */
+   memcpy(buffer, intf->req + MASK_XENSTORE_IDX(cons), len);
+   else {
+ 

Re: [Xen-devel] [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown

[Paul Durrant]

> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: 16 November 2015 12:55
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Cc: Ian Jackson; Stefano Stabellini; Wei Liu
> Subject: Re: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for
> ~/control/shutdown
> 
> On Wed, 2015-11-11 at 16:18 +, Paul Durrant wrote:
> > As documented in docs/misc/xenstore, the XS_MKDIR operation merely
> makes
> > sure a path exists whereas ~/control/shutdown needs to start empty. Also
> > using XS_MKDIR for a node which is never supposed to have children is
> > somewhat counterintuitive.
> >
> > This patch introduces a new libxl__xs_printf_perms() function analogous
> > to libxl__xs_printf() but taking explicit permissions arguments, and then
> > uses this to create an empty ~/control/shutdown node.
> >
> > Signed-off-by: Paul Durrant 
> > Cc: Ian Jackson 
> > Cc: Stefano Stabellini 
> > Cc: Ian Campbell 
> > Cc: Wei Liu 
> > ---
> >  tools/libxl/libxl_create.c   | 16 ++--
> >  tools/libxl/libxl_internal.h | 10 ++
> >  tools/libxl/libxl_xshelp.c   | 44
> > ++--
> >  3 files changed, 58 insertions(+), 12 deletions(-)
> >
> > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > index 921d155..279deda 100644
> > --- a/tools/libxl/libxl_create.c
> > +++ b/tools/libxl/libxl_create.c
> > @@ -484,7 +484,7 @@ int libxl__domain_make(libxl__gc *gc,
> > libxl_domain_config *d_config,
> >  libxl_ctx *ctx = libxl__gc_owner(gc);
> >  int flags, ret, rc, nb_vm;
> >  char *uuid_string;
> > -char *dom_path, *vm_path, *libxl_path;
> > +char *dom_path, *vm_path, *libxl_path, *control_path;
> >  struct xs_permissions roperm[2];
> >  struct xs_permissions rwperm[1];
> >  struct xs_permissions noperm[1];
> > @@ -605,17 +605,21 @@ retry_transaction:
> >  libxl__xs_mkdir(gc, t,
> >  libxl__sprintf(gc, "%s/device", dom_path),
> >  roperm, ARRAY_SIZE(roperm));
> > -libxl__xs_mkdir(gc, t,
> > -libxl__sprintf(gc, "%s/control", dom_path),
> > +
> > +control_path = libxl__sprintf(gc, "%s/control", dom_path);
> > +
> > +libxl__xs_mkdir(gc, t, control_path,
> >  roperm, ARRAY_SIZE(roperm));
> >  if (info->type == LIBXL_DOMAIN_TYPE_HVM)
> >  libxl__xs_mkdir(gc, t,
> >  libxl__sprintf(gc, "%s/hvmloader", dom_path),
> >  roperm, ARRAY_SIZE(roperm));
> >
> > -libxl__xs_mkdir(gc, t,
> > -libxl__sprintf(gc, "%s/control/shutdown", dom_path),
> > -rwperm, ARRAY_SIZE(rwperm));
> > +libxl__xs_printf_perms(gc, t,
> > +   libxl__sprintf(gc, "%s/shutdown",
> > control_path),
> > +   rwperm, ARRAY_SIZE(rwperm),
> > +   "");
> > +
> >  libxl__xs_mkdir(gc, t,
> >  libxl__sprintf(gc, "%s/device/suspend/event-
> > channel", dom_path),
> >  rwperm, ARRAY_SIZE(rwperm));
> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > index 4710804..04d8a29 100644
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -666,6 +666,16 @@ _hidden int libxl__xs_writev_perms(libxl__gc *gc,
> > xs_transaction_t t,
> >  _hidden int libxl__xs_writev_atonce(libxl__gc *gc,
> >   const char *dir, char **kvs);
> >
> > +_hidden int libxl__xs_vprintf_perms(libxl__gc *gc, xs_transaction_t t,
> > +const char *path,
> > +struct xs_permissions *perms,
> > +unsigned int num_perms,
> > +const char *fmt, va_list ap);
> > +_hidden int libxl__xs_printf_perms(libxl__gc *gc, xs_transaction_t t,
> > +   const char *path,
> > +   struct xs_permissions *perms,
> > +   unsigned int num_perms,
> > +   const char *fmt, ...)
> > PRINTF_ATTRIBUTE(6, 7);
> >  _hidden int libxl__xs_printf(libxl__gc *gc, xs_transaction_t t,
> >   const char *path, const char *fmt, ...)
> > PRINTF_ATTRIBUTE(4, 5);
> > /* Each fn returns 0 on success.
> > diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
> > index 3cac4f2..0b56f8b 100644
> > --- a/tools/libxl/libxl_xshelp.c
> > +++ b/tools/libxl/libxl_xshelp.c
> > @@ -96,25 +96,57 @@ out:
> >
> >  }
> >
> > -int libxl__xs_printf(libxl__gc *gc, xs_transaction_t t,
> > - const char *path, const char *fmt, ...)
> > +int libxl__xs_vprintf_perms(libxl__gc *gc, 

Re: [Xen-devel] [PATCH V8 2/7] libxl_read_file_contents: add new entry to read sysfs file

[Ian Campbell]

On Wed, 2015-10-21 at 17:08 +0800, Chunyan Liu wrote:
> Sysfs file has size=4096 but actual file content is less than that.
> Current libxl_read_file_contents will treat it as error when file size
> and actual file content differs, so reading sysfs file content with
> this function always fails.

You changes to the existing code seem to do more than just cope with this
possibility.


[...]
@@ -359,20 +360,35 @@ int libxl_read_file_contents(libxl_ctx *ctx, const
> char *filename,
>  datalen = stab.st_size;
>  
>  if (stab.st_size && data_r) {
> -data = malloc(datalen);
> +data = malloc(datalen + 1);

This (and the related change) seem to be fixing an off by one bug in the
existing code? At a minimum this should be mentioned in the commit message
but ideally it would be split out into a precursor code, so as to allow it
to be backported (assuming it is a bug fix and not some other consequence
of reading from sysfs).

>  if (!data) goto xe;
>  
> -rs = fread(data, 1, datalen, f);
> -if (rs != datalen) {
> -if (ferror(f))
> +rs = fread(data, 1, datalen + 1, f);
> +if (rs > datalen) {
> +LOG(ERROR, "%s increased size while we were reading it",
> +filename);
> +goto xe;
> +}
> +
> +if (rs < datalen) {
> +if (ferror(f)) {
>  LOGE(ERROR, "failed to read %s", filename);
> -else if (feof(f))
> -LOG(ERROR, "%s changed size while we were reading it",
> - filename);
> -else
> +goto xe;
> +} else if (feof(f)) {
> +if (tolerate_shrinking_file) {
> +datalen = rs;
> +} else {
> +LOG(ERROR, "%s shrunk size while we were reading
> it",
> +filename);
> +goto xe;
> +}
> +} else {
>  abort();
> -goto xe;
> +}
>  }
> +
> +data = realloc(data, datalen);
> +if (!data) goto xe;

and this change I don't follow at all. Is it shrinking the buffer? I'm not
sure that is needed, it should be a smallish waste of memory.

If you feel strongly that the realloc is needed then you should call
libxl__realloc(NOGC, ...) to get the correct behaviour on error.

That NOGC brings me onto my last point:
> +int libxl__read_sysfs_file_contents(libxl__gc *gc, const char *filename,
> +   void **data_r, int *datalen_r)
> +{
> +return read_file_contents_core(gc, filename, data_r, datalen_r, 1);

Since this is now an internal function it would normally be expected that
the returned buffer would be garbage collected.

Since you want to share the core code with an external function which
should return un-gc'd memory it seems like the easiest change would be to
call libxl__ptr_add here.

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

[Xen-devel] [PATCH v2 2/3] libxl: check for underlying xenstore operation failure...

[Paul Durrant]

...in libxl__xs_writev_perms() and libxl__xs_printf()

ERROR_FAIL is returned when any underlying operation fails. This is a
semantic change in the case of a vasprintf() failure in libxl__xs_printf(),
but appears to be better than returning a hardcoded -1.

Signed-off-by: Paul Durrant 
---
 tools/libxl/libxl_xshelp.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index 3cac4f2..a178039 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -57,9 +57,11 @@ int libxl__xs_writev_perms(libxl__gc *gc, xs_transaction_t t,
 path = libxl__sprintf(gc, "%s/%s", dir, kvs[i]);
 if (path && kvs[i + 1]) {
 int length = strlen(kvs[i + 1]);
-xs_write(ctx->xsh, t, path, kvs[i + 1], length);
-if (perms)
-xs_set_permissions(ctx->xsh, t, path, perms, num_perms);
+if (!xs_write(ctx->xsh, t, path, kvs[i + 1], length))
+return ERROR_FAIL;
+if (perms &&
+!xs_set_permissions(ctx->xsh, t, path, perms, num_perms))
+return ERROR_FAIL;
 }
 }
 return 0;
@@ -108,11 +110,10 @@ int libxl__xs_printf(libxl__gc *gc, xs_transaction_t t,
 va_end(ap);
 
 if (ret == -1) {
-return -1;
+return ERROR_FAIL;
 }
-xs_write(ctx->xsh, t, path, s, ret);
-free(s);
-return 0;
+libxl__ptr_add(gc, s);
+return xs_write(ctx->xsh, t, path, s, ret) ? 0 : ERROR_FAIL;
 }
 
 char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, const char *path)
-- 
2.1.4


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

Re: [Xen-devel] [PATCH MINI-OS v3 1/2] xenbus: notify the other end when necessary

[Ian Campbell]

On Tue, 2015-10-27 at 16:46 +0100, Samuel Thibault wrote:
> Wei Liu, le Tue 27 Oct 2015 15:43:28 +, a écrit :
> > The xenbus thread didn't send notification to other end when it
> > expected
> > more data or consumed responses, which led to stalling the ring from
> > time to time.
> > 
> > This is the culprit that guest was less responsive when using stubdom
> > because the device model was stalled.
> > 
> > Fix this by sending notification to the other end when it consumes a
> > message. A bunch of memory barriers are also added to ensure
> > correctness.
> > 
> > Signed-off-by: Wei Liu 
> 
> Acked-by: Samuel Thibault 

Applied.

> And it should clearly be backported to stable branches.

I don't think we have a mini-os branch for stable, but I'll let Ian J
figure out the right way to achieve this.

Ian


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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Wei Liu]

On Mon, Nov 16, 2015 at 12:08:45PM +, Ian Campbell wrote:
> On Thu, 2015-11-12 at 10:06 +, Wei Liu wrote:
> > The new osstest tested head contains a fix for gcc-4.4 toolchain.
> > 
> > Signed-off-by: Wei Liu 
> > ---
> > Cc: "Hao, Xudong" 
> > Cc: Ian Campbell 
> > 
> > Please pull from
> >   git://xenbits.xen.org/osstest/ovmf.git xen-tested-master
> 
> For future such updates please could you use the specific commit here, so
> we avoid issues with osstest pushing something newer and I can just cut the
> line onto the end of a "git fetch".

NP. I will do that in the future.

> 
> I have done:
> 
> ianc@cosworth:edk2.git$ git fetch git://xenbits.xen.org/osstest/ovmf.git  
> 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d
> From git://xenbits.xen.org/osstest/ovmf
>  * branch52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d -> FETCH_HEAD
> ianc@cosworth:edk2.git$ git push maint --dry-run 
> 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d:master
> To ssh://xenbits.xen.org/home/xen/git/ovmf.git
>    af9785a..52a9949  52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d -> master
> ianc@cosworth:edk2.git$ git push maint  
> 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d:master
> Counting objects: 1642, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (640/640), done.
> Writing objects: 100% (1642/1642), 2.43 MiB | 4.09 MiB/s, done.
> Total 1642 (delta 1080), reused 1544 (delta 992)
> To ssh://xenbits.xen.org/home/xen/git/ovmf.git
>    af9785a..52a9949  52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d -> master
> 
> and acked + applied this patch.
> 

Thanks.

> > and push the said commit to
> >   git://xenbits.xen.org/ovmf.git master
> > 
> > It should be a fast-forward push.
> > ---
> >  Config.mk | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Config.mk b/Config.mk
> > index 5db7ca5..1392575 100644
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -253,7 +253,7 @@ QEMU_TRADITIONAL_URL ?= git://xenbits.xen.org/qemu-xe
> > n-traditional.git
> >  SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
> >  MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
> >  endif
> > -OVMF_UPSTREAM_REVISION ?= af9785a9ed61daea52b47f0bf448f1f228beee1e
> > +OVMF_UPSTREAM_REVISION ?= 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d
> >  QEMU_UPSTREAM_REVISION ?= master
> >  MINIOS_UPSTREAM_REVISION ?= 256035e01a1aa5739e34f245f3b1e9e8ee204210
> >  # Thu Jul 23 11:08:38 2015 +0100

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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Ian Campbell]

On Thu, 2015-11-12 at 10:06 +, Wei Liu wrote:
> The new osstest tested head contains a fix for gcc-4.4 toolchain.
> 
> Signed-off-by: Wei Liu 
> ---
> Cc: "Hao, Xudong" 
> Cc: Ian Campbell 
> 
> Please pull from
>   git://xenbits.xen.org/osstest/ovmf.git xen-tested-master

For future such updates please could you use the specific commit here, so
we avoid issues with osstest pushing something newer and I can just cut the
line onto the end of a "git fetch".

I have done:

ianc@cosworth:edk2.git$ git fetch git://xenbits.xen.org/osstest/ovmf.git  
52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d
From git://xenbits.xen.org/osstest/ovmf
 * branch52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d -> FETCH_HEAD
ianc@cosworth:edk2.git$ git push maint --dry-run 
52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d:master
To ssh://xenbits.xen.org/home/xen/git/ovmf.git
   af9785a..52a9949  52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d -> master
ianc@cosworth:edk2.git$ git push maint  
52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d:master
Counting objects: 1642, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (640/640), done.
Writing objects: 100% (1642/1642), 2.43 MiB | 4.09 MiB/s, done.
Total 1642 (delta 1080), reused 1544 (delta 992)
To ssh://xenbits.xen.org/home/xen/git/ovmf.git
   af9785a..52a9949  52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d -> master

and acked + applied this patch.

> and push the said commit to
>   git://xenbits.xen.org/ovmf.git master
> 
> It should be a fast-forward push.
> ---
>  Config.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Config.mk b/Config.mk
> index 5db7ca5..1392575 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -253,7 +253,7 @@ QEMU_TRADITIONAL_URL ?= git://xenbits.xen.org/qemu-xe
> n-traditional.git
>  SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
>  MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
>  endif
> -OVMF_UPSTREAM_REVISION ?= af9785a9ed61daea52b47f0bf448f1f228beee1e
> +OVMF_UPSTREAM_REVISION ?= 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d
>  QEMU_UPSTREAM_REVISION ?= master
>  MINIOS_UPSTREAM_REVISION ?= 256035e01a1aa5739e34f245f3b1e9e8ee204210
>  # Thu Jul 23 11:08:38 2015 +0100

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

Re: [Xen-devel] [PATCH V2] libxl: relax readonly check introduced by XSA-142 fix

[Ian Campbell]

On Fri, 2015-11-13 at 09:56 -0700, Jim Fehlig wrote:
> On 11/12/2015 07:40 PM, Jim Fehlig wrote:
> > The fix for XSA-142 is quite a big hammer, rejecting readonly
> > disk configuration even when the requested backend is known to
> > support readonly. While it is true that qemu doesn't support
> > readonly for emulated IDE or AHCI disks
> > 
> > $ /usr/lib/xen/bin/qemu-system-i386 \
> >  -drive file=/tmp/disk.raw,if=ide,media=disk,format=raw,readonly=on
> > qemu-system-i386: Can't use a read-only drive
> > 
> > $ /usr/lib/xen/bin/qemu-system-i386 -device ahci,id=ahci0 \
> >  -drive file=/tmp/disk.raw,if=none,id=ahcidisk-0,format=raw,readonly=on 
> > \
> >  -device ide-hd,bus=ahci0.0,unit=0,drive=ahcidisk-0
> > qemu-system-i386: -device ide-hd,bus=ahci0.0,unit=0,drive=ahcidisk-0:
> > Can't use a read-only drive
> > 
> > It does support readonly SCSI disks
> > 
> > $ /usr/lib/xen/bin/qemu-system-i386 \
> >  -drive file=/tmp/disk.raw,if=scsi,media=disk,format=raw,readonly=on
> > [ok]
> > 
> > Inside a guest using such a disk, the SCSI kernel driver sees write
> > protect on
> > 
> > [   7.339232] sd 2:0:1:0: [sdb] Write Protect is on
> > 
> > Also, PV drivers support readonly, but the patch rejects such
> > configuration even when PV drivers (vdev=xvd*) have been explicitly
> > specified and creation of an emulated twin is skiped.
> > 
> > This follow-up patch loosens the restriction to reject readonly when
> > creating and emulated IDE or AHCI disk, but allows it when the backend
> 
> s/and/an/. I can fix this typo if a V3 is needed.

I fixed it upon commit.

Thanks,
Ian.


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

Re: [Xen-devel] [PATCH v5 5/6] xen/arm: vgic: Introduce helpers to extract/update/clear/set vGIC register ...

[Ian Campbell]

On Wed, 2015-11-11 at 16:09 +, Julien Grall wrote:
> 
> I will either resend this whole series or only this patch depending on
> the reviews.

I don't think I've got anything to add to my existing acks or Stefano's
comments. Best resend I think.

Ian.


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

Re: [Xen-devel] [PATCH 4/9] xen/arm: vgic-v3: Remove GICR_MOVALLR and GICR_MOVLPIR

[Ian Campbell]

On Fri, 2015-11-13 at 11:54 +, Julien Grall wrote:
> The 2 registers are not described in the software spec (ARM IHI 0069A)
> and their offsets are marked "implementation defined".

They do exist in "PRD03-GENC-010745 24.0", in that they are mentioned as
having corresponding completion bits in GICR_SYNCR in that version, but
seem to never be defined themselves. I suppose they were a remnant of an
older spec. No need to discuss that in the commit message though.

> 
> Signed-off-by: Julien Grall 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [PATCH 06/10] x86/hvm: pkeys, add functions to get pkeys value from PTE

[Andrew Cooper]

On 16/11/15 10:31, Huaitong Han wrote:
> This patch adds functions to get pkeys value from PTE.
>
> Signed-off-by: Huaitong Han 
>
> diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h
> index 87b3341..1cdbfc8 100644
> --- a/xen/include/asm-x86/page.h
> +++ b/xen/include/asm-x86/page.h
> @@ -93,6 +93,13 @@
>  #define l3e_get_flags(x)   (get_pte_flags((x).l3))
>  #define l4e_get_flags(x)   (get_pte_flags((x).l4))
>  
> +/* Get pte pkeys (unsigned int). */
> +#define l1e_get_pkeys(x)   (get_pte_pkeys((x).l1))
> +#define l2e_get_pkeys(x)   (get_pte_pkeys((x).l2))
> +#define l3e_get_pkeys(x)   (get_pte_pkeys((x).l3))
> +#define l4e_get_pkeys(x)   (get_pte_pkeys((x).l4))
> +
> +

Please only insert a single line here.

>  /* Construct an empty pte. */
>  #define l1e_empty()((l1_pgentry_t) { 0 })
>  #define l2e_empty()((l2_pgentry_t) { 0 })
> diff --git a/xen/include/asm-x86/x86_64/page.h 
> b/xen/include/asm-x86/x86_64/page.h
> index 19ab4d0..03418ba 100644
> --- a/xen/include/asm-x86/x86_64/page.h
> +++ b/xen/include/asm-x86/x86_64/page.h
> @@ -134,6 +134,18 @@ typedef l4_pgentry_t root_pgentry_t;
>  #define get_pte_flags(x) (((int)((x) >> 40) & ~0xFFF) | ((int)(x) & 0xFFF))
>  #define put_pte_flags(x) (((intpte_t)((x) & ~0xFFF) << 40) | ((x) & 0xFFF))
>  
> +/*
> +* Protection keys define a new 4-bit protection key field
> +* (PKEY) in bits 62:59 of leaf entries of the page tables.
> +* This corresponds to bit 22:19 of a 24-bit flags.
> +*/

Please align all the *'s of the comment vertically (i.e. with a space on
the very left hand side)

> +#define _PAGE_PKEY_BIT0 19   /* Protection Keys, bit 1/4 */
> +#define _PAGE_PKEY_BIT1 20   /* Protection Keys, bit 2/4 */
> +#define _PAGE_PKEY_BIT2 21   /* Protection Keys, bit 3/4 */
> +#define _PAGE_PKEY_BIT3 22   /* Protection Keys, bit 4/4 */
> +
> +#define get_pte_pkeys(x) ((int)(get_pte_flags(x) >> _PAGE_PKEY_BIT0) & 0xF)

Please implemented these as masks, for consistency with the other
_PAGE_* entries.  I would recommend also having a _SHIFT and _MASK define.

> +
>  /* Bit 23 of a 24-bit flag mask. This corresponds to bit 63 of a pte.*/
>  #define _PAGE_NX_BIT (1U<<23)
>  

There is however another issue. Xen currently uses bit 62 for software
purposes, which is incompatible with enabling PKE.  _PAGE_GNTTAB needs
moving to a different, software-available bit.  I would recommend bit 13
of flags, adjacent to _PAGE_GUEST_KERNEL which is our other
software-used flag.

Also, the changes to _PAGE_GNTTAB must be ahead of patch 4 which enables
CR4.PKE for Xen.

~Andrew

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

Re: [Xen-devel] [PATCH v5 8/9] libxc: rework of domain builder's page table handler

[Juergen Gross]

On 16/11/15 14:40, Ian Campbell wrote:
> On Thu, 2015-11-12 at 14:48 +0100, Juergen Gross wrote:
>> On 12/11/15 14:47, Wei Liu wrote:
>>> On Thu, Nov 12, 2015 at 02:43:35PM +0100, Juergen Gross wrote:
 In order to prepare a p2m list outside of the initial kernel mapping
 do a rework of the domain builder's page table handler. The goal is
 to be able to use common helpers for page table allocation and setup
 for initial kernel page tables and page tables mapping the p2m list.
 This is achieved by supporting multiple mapping areas. The mapped
 virtual addresses of the single areas must not overlap, while the
 page tables of a new area added might already be partially present.
 Especially the top level page table is existing only once, of course.

 Currently restrict the number of mappings to 1 because the only
 mapping
 now is the initial mapping created by toolstack. There should not be
 behaviour change and guest visible change introduced.

 Signed-off-by: Juergen Gross 
 Reviewed-by: Wei Liu >>
>>> Missing closing ">". :-)
>>
>> Uuh, mouse buffer underrun, I guess ;-)
>>
>>>
>>> I don't think you need to resend though.
>>
>> Thanks,
> 
> I fixed while I was applying the whole series.

Thanks,


Juergen


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

[Xen-devel] [linux-3.4 test] 64297: regressions - FAIL

[osstest service owner]

flight 64297 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64297/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-rumpuserxen-i386  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 62277
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 62277
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail REGR. vs. 62277
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail REGR. vs. 62277
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail REGR. vs. 62277
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot  fail REGR. vs. 62277
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot fail REGR. vs. 62277
 test-amd64-amd64-xl-xsm   6 xen-boot  fail REGR. vs. 62277
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-bootfail REGR. vs. 62277
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 62277

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-amd64-pvgrub  3 host-install(3) broken in 63294 pass in 64297
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken 
in 63294 pass in 64297
 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken in 63294 pass in 
64297
 test-amd64-amd64-xl-qemuu-winxpsp3 3 host-install(3) broken in 63294 pass in 
64297
 test-amd64-amd64-xl-qcow2 3 host-install(3)  broken in 63310 pass in 64297
 test-amd64-i386-xl-xsm3 host-install(3)  broken in 63310 pass in 64297
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken in 
63310 pass in 64297
 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 63310 pass in 
64297
 test-amd64-i386-xl-raw3 host-install(3)  broken in 63324 pass in 64297
 test-amd64-amd64-xl-credit2   3 host-install(3)  broken in 63324 pass in 64297
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken in 63324 
pass in 64297
 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 63324 pass in 
64297
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail in 63310 pass in 64297
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail in 63324 pass in 64297
 test-amd64-amd64-xl-rtds  6 xen-bootfail pass in 63228
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
63228
 test-amd64-amd64-i386-pvgrub  6 xen-bootfail pass in 63294
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 
guest-localmigrate/x10 fail pass in 63294
 test-amd64-i386-pair 10 xen-boot/dst_host   fail pass in 63310
 test-amd64-i386-pair  9 xen-boot/src_host   fail pass in 63310
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host  fail pass in 63310
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host  fail pass in 63310
 test-amd64-amd64-amd64-pvgrub  6 xen-boot   fail pass in 63324
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot   fail pass in 63324
 test-amd64-amd64-xl-qcow2 6 xen-bootfail pass in 63338
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host   fail pass in 63374
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host   fail pass in 63374
 test-amd64-amd64-pair10 xen-boot/dst_host   fail pass in 63404
 test-amd64-amd64-pair 9 xen-boot/src_host   fail pass in 63404

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 62277
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 
fail blocked in 62277
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail in 63228 blocked in 62277
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 62277
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 62277
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 62277
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62277

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 63228 never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start 

Re: [Xen-devel] [PATCH 00/13] tools: do cleanups related to libxc python bindings

[Ian Campbell]

On Thu, 2015-11-12 at 13:01 +, Wei Liu wrote:
> On Mon, Nov 09, 2015 at 04:19:24PM +0100, Juergen Gross wrote:
> > On 10/23/2015 03:04 PM, Juergen Gross wrote:
> > > This series is a combination of my previous patches:
> > > 
> > > "libxc: remove most of tools/libxc/xc_dom_compat_linux.c"
> > > "tools: remove unused wrappers for python"
> > > 
> > > I have split it up as requested by Ian Campbell, thus it consists of
> > > 13 patches instead just of 2, but the functionality is roughly the
> > > same. I have just kept more python bindings compared to the first
> > > version, as there have been reports of some out of tree uses. Asking
> > > for more such use case on xen-devel and xen-user didn't result in
> > > requests for more interfaces to be kept, so I delete them.
> > 
> > There have been acks and critical responses regarding this series.

Have there? I don't have the stashed alongside the series as I would
normally, so maybe I've missed them?

> > What should we do?
> > 
> > - drop them all
> > - apply the first two patches only to get rid of the extra interfaces
> >   to the domain builder as requested by Ian Campbell
> 
> I would go for this.

I've done this one.

Ian.

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

Re: [Xen-devel] [PATCH] oxenstored: Quota.merge: don't assume domain already exists

[Ian Campbell]

On Wed, 2015-11-11 at 15:24 +, Ian Jackson wrote:
> Jonathan Davies writes ("[PATCH] oxenstored: Quota.merge: don't assume
> domain already exists"):
> > In Quota.merge, we merge two quota hashtables, orig_quota and
> > mod_quota, putting
> > the results into dest_quota. These hashtables map domids to the number
> > of
> > entries currently owned by that domain.
> > 
> > When mod_quota contains an entry for a domid that was not present in
> > orig_quota
> > (or dest_quota), the call to get_entry caused Quota.merge to raise a
> > Not_found
> > exception. This propagates back to the client as an ENOENT error, which
> > is not
> > an appropriate return value from some operations, such as
> > transaction_end.
> > 
> > This situation can arise when a transaction that introduces a domain
> > (hence
> > calling Quota.add_entry) needs to be coalesced due to concurrent
> > xenstore
> > activity.
> > 
> > This patch handles the merge in the case where mod_quota contains an
> > entry not
> > present in orig_quota (or in dest_quota) by treating that hashtable as
> > having
> > existing value 0.
> > 
> > Signed-off-by: Jonathan Davies 
> 
> The ocaml looks vaguely plausible.  I speak enough ocaml to see that
> this looks (out of context and with my half-remembered knowledge of
> oxenstored innards) like it does what you say.
> 
> Acked-by: Ian Jackson 

Applied.


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

Re: [Xen-devel] [PATCH] ocaml/xc: correct shutdown_reason enumeration

[Ian Campbell]

On Thu, 2015-11-05 at 11:56 +, David Scott wrote:
> > On 5 Nov 2015, at 11:39, Simon Rowe  wrote:
> > 
> > As defined by the Xen public header the fifth value of
> > shutdown_reason is watchdog.
> 
> I’ve always been a bit suspicious about having both “Poweroff” and “Halt”
> there. Perhaps there was some confusion between what could be written to
> ‘control/shutdown’ in xenstore and legal arguments to
> `xc_domain_shutdown` and `SCHEDOP_shutdown`?
> 
> Anyway you’re clearly right, `Watchdog` is the 5th value. So I think this
> is fine.
> 
> Acked-by: David Scott 

Applied.

> 
> I happen to notice there’s a type with the same name in “xenopsd”[1], so
> I’ve cc:d xen-api@lists as a heads-up.
> 
> Thanks,
> Dave
> 
> [1] https://github.com/xapi-project/xenopsd/blob/7818ab896d9969c5f5462a2f
> 0d0ae62703b104b6/xc/domain.ml#L268
> 
> > 
> > Signed-off-by: Simon Rowe 
> > ---
> > tools/ocaml/libs/xc/xenctrl.ml  |2 +-
> > tools/ocaml/libs/xc/xenctrl.mli |2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/ocaml/libs/xc/xenctrl.ml
> > b/tools/ocaml/libs/xc/xenctrl.ml
> > index b7ba8b7..beb95b8 100644
> > --- a/tools/ocaml/libs/xc/xenctrl.ml
> > +++ b/tools/ocaml/libs/xc/xenctrl.ml
> > @@ -89,7 +89,7 @@ type compile_info =
> > compile_date : string;
> > }
> > 
> > -type shutdown_reason = Poweroff | Reboot | Suspend | Crash | Halt
> > +type shutdown_reason = Poweroff | Reboot | Suspend | Crash | Watchdog
> > 
> > type domain_create_flag = CDF_HVM | CDF_HAP
> > 
> > diff --git a/tools/ocaml/libs/xc/xenctrl.mli
> > b/tools/ocaml/libs/xc/xenctrl.mli
> > index bc4af56..8928a2e 100644
> > --- a/tools/ocaml/libs/xc/xenctrl.mli
> > +++ b/tools/ocaml/libs/xc/xenctrl.mli
> > @@ -61,7 +61,7 @@ type compile_info = {
> >   compile_domain : string;
> >   compile_date : string;
> > }
> > -type shutdown_reason = Poweroff | Reboot | Suspend | Crash | Halt
> > +type shutdown_reason = Poweroff | Reboot | Suspend | Crash | Watchdog
> > 
> > type domain_create_flag = CDF_HVM | CDF_HAP
> > 

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

Re: [Xen-devel] [PATCH v5 8/9] libxc: rework of domain builder's page table handler

[Ian Campbell]

On Thu, 2015-11-12 at 14:48 +0100, Juergen Gross wrote:
> On 12/11/15 14:47, Wei Liu wrote:
> > On Thu, Nov 12, 2015 at 02:43:35PM +0100, Juergen Gross wrote:
> > > In order to prepare a p2m list outside of the initial kernel mapping
> > > do a rework of the domain builder's page table handler. The goal is
> > > to be able to use common helpers for page table allocation and setup
> > > for initial kernel page tables and page tables mapping the p2m list.
> > > This is achieved by supporting multiple mapping areas. The mapped
> > > virtual addresses of the single areas must not overlap, while the
> > > page tables of a new area added might already be partially present.
> > > Especially the top level page table is existing only once, of course.
> > > 
> > > Currently restrict the number of mappings to 1 because the only
> > > mapping
> > > now is the initial mapping created by toolstack. There should not be
> > > behaviour change and guest visible change introduced.
> > > 
> > > Signed-off-by: Juergen Gross 
> > > Reviewed-by: Wei Liu  > 
> > Missing closing ">". :-)
> 
> Uuh, mouse buffer underrun, I guess ;-)
> 
> > 
> > I don't think you need to resend though.
> 
> Thanks,

I fixed while I was applying the whole series.

Ian.


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

Re: [Xen-devel] Unable to create Stubdomains with NIC(s) - Xen 4.5.2

[Ian Campbell]

On Mon, 2015-11-16 at 14:36 +0100, Peter Schmid wrote:
> 
> so xl list has only dom0 in the output:
> 
> xl list
> NameID   Mem VCPUs  State   
> Time(s)
> (null)   0  1024 8 r- 
> 230.7

The "(null)" here instead of "Domain 0" is another indicator that your
initscripts are not correctly up to date. In particular it appears that
"xen-init-dom0" has not been called.

How are you installing Xen? From source or from distro packages?

> Can you point me to the Patch which was backported to 4.5?
> 

If I understood Wei correctly it was backported to 4.5.1 and therefore is
already in the 4.5.2 release which you are using.

Ian.

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

Re: [Xen-devel] [PATCH 03/10] x86/hvm: pkeys, add the flag to enable Memory Protection Keys

[Andrew Cooper]

On 16/11/15 10:31, Huaitong Han wrote:
> This patch adds the flag to enable Memory Protection Keys.
>
> Signed-off-by: Huaitong Han 
>
> diff --git a/docs/misc/xen-command-line.markdown 
> b/docs/misc/xen-command-line.markdown
> index a565c1b..0ded4bf 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1303,6 +1303,13 @@ Flag to enable Supervisor Mode Execution Protection
>  
>  Flag to enable Supervisor Mode Access Prevention
>  
> +### pku

Options should be in alphabetical order please.

> +> `= >`

Extra closing arrow.

> +
> +> Default: `true`
> +
> +Flag to enable Memory Protection Keys

I know there are a number of bad examples in this file, but please avoid
adding to the problem.

It would be useful to have a very brief description of what PKU is, and
which hardware it is available on.  See the 'psr' option as an example.

> +
>  ### snb\_igd\_quirk
>  > `=  | cap | `
>  
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 3946e4c..c1f924e 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -67,6 +67,10 @@ invbool_param("smep", disable_smep);
>  static bool_t __initdata disable_smap;
>  invbool_param("smap", disable_smap);
>  
> +/* pku: Enable/disable Memory Protection Keys (default on). */
> +static bool_t __initdata disable_pku;
> +invbool_param("pku", disable_pku);

I am going to submit a patch removing invbool_param(), as it is barely
used and adds unnecessary cognitive overhead

Please us:

static bool_t __initdata opt_pku = 1;
boolean_param("pku", opt_pku);

instead.

~Andrew

> +
>  /* Boot dom0 in pvh mode */
>  static bool_t __initdata opt_dom0pvh;
>  boolean_param("dom0pvh", opt_dom0pvh);
> @@ -1304,6 +1308,9 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  if ( cpu_has_smap )
>  set_in_cr4(X86_CR4_SMAP);
>  
> +if ( disable_pku )
> +setup_clear_cpu_cap(X86_FEATURE_PKU);
> +
>  if ( cpu_has_fsgsbase )
>  set_in_cr4(X86_CR4_FSGSBASE);
>  


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

[Xen-devel] [PATCH v2 0/3] libxl: xenstore related cleanup

[Paul Durrant]

This series is v2 since patches #1 and #3 were part of my previous
RFC posting.

Patch #1 is a cosmetic change to re-name a function so that the name of
a function introduced in a subsequent patch makes more sense

Patch #2 passes back errors from libx__xs_printf() and
libxl__xs_writev_perms() if the underlying xenstore operations fail

Patch #3 stops mis-use of XS_MKDIR

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

[Xen-devel] [PATCH v2 3/3] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown

[Paul Durrant]

As documented in docs/misc/xenstore, the XS_MKDIR operation merely makes
sure a path exists whereas ~/control/shutdown needs to start empty. Also
using XS_MKDIR for a node which is never supposed to have children is
somewhat counterintuitive.

This patch introduces a new libxl__xs_printf_perms() function analogous
to libxl__xs_printf() but taking explicit permissions arguments, and then
uses this to create an empty ~/control/shutdown node.

Signed-off-by: Paul Durrant 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/libxl/libxl_create.c   | 16 +-
 tools/libxl/libxl_internal.h | 10 +
 tools/libxl/libxl_xshelp.c   | 52 +---
 3 files changed, 64 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 921d155..279deda 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -484,7 +484,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config 
*d_config,
 libxl_ctx *ctx = libxl__gc_owner(gc);
 int flags, ret, rc, nb_vm;
 char *uuid_string;
-char *dom_path, *vm_path, *libxl_path;
+char *dom_path, *vm_path, *libxl_path, *control_path;
 struct xs_permissions roperm[2];
 struct xs_permissions rwperm[1];
 struct xs_permissions noperm[1];
@@ -605,17 +605,21 @@ retry_transaction:
 libxl__xs_mkdir(gc, t,
 libxl__sprintf(gc, "%s/device", dom_path),
 roperm, ARRAY_SIZE(roperm));
-libxl__xs_mkdir(gc, t,
-libxl__sprintf(gc, "%s/control", dom_path),
+
+control_path = libxl__sprintf(gc, "%s/control", dom_path);
+
+libxl__xs_mkdir(gc, t, control_path,
 roperm, ARRAY_SIZE(roperm));
 if (info->type == LIBXL_DOMAIN_TYPE_HVM)
 libxl__xs_mkdir(gc, t,
 libxl__sprintf(gc, "%s/hvmloader", dom_path),
 roperm, ARRAY_SIZE(roperm));
 
-libxl__xs_mkdir(gc, t,
-libxl__sprintf(gc, "%s/control/shutdown", dom_path),
-rwperm, ARRAY_SIZE(rwperm));
+libxl__xs_printf_perms(gc, t,
+   libxl__sprintf(gc, "%s/shutdown", control_path),
+   rwperm, ARRAY_SIZE(rwperm),
+   "");
+
 libxl__xs_mkdir(gc, t,
 libxl__sprintf(gc, "%s/device/suspend/event-channel", 
dom_path),
 rwperm, ARRAY_SIZE(rwperm));
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e51d57f..94f05cd 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -667,6 +667,16 @@ _hidden int libxl__xs_writev_perms(libxl__gc *gc, 
xs_transaction_t t,
 _hidden int libxl__xs_writev_atonce(libxl__gc *gc,
  const char *dir, char **kvs);
 
+_hidden int libxl__xs_vprintf_perms(libxl__gc *gc, xs_transaction_t t,
+const char *path,
+struct xs_permissions *perms,
+unsigned int num_perms,
+const char *fmt, va_list ap);
+_hidden int libxl__xs_printf_perms(libxl__gc *gc, xs_transaction_t t,
+   const char *path,
+   struct xs_permissions *perms,
+   unsigned int num_perms,
+   const char *fmt, ...) PRINTF_ATTRIBUTE(6, 
7);
 _hidden int libxl__xs_printf(libxl__gc *gc, xs_transaction_t t,
  const char *path, const char *fmt, ...) 
PRINTF_ATTRIBUTE(4, 5);
/* Each fn returns 0 on success.
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index a178039..6d4f33d 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -98,22 +98,58 @@ out:
 
 }
 
-int libxl__xs_printf(libxl__gc *gc, xs_transaction_t t,
- const char *path, const char *fmt, ...)
+int libxl__xs_vprintf_perms(libxl__gc *gc, xs_transaction_t t,
+const char *path,
+struct xs_permissions *perms,
+unsigned int num_perms,
+const char *fmt,
+va_list ap)
 {
 libxl_ctx *ctx = libxl__gc_owner(gc);
 char *s;
+int ret;
+
+ret = vasprintf(, fmt, ap);
+if (ret == -1)
+return ERROR_FAIL;
+
+libxl__ptr_add(gc, s);
+
+if (!xs_write(ctx->xsh, t, path, s, ret))
+return ERROR_FAIL;
+if (perms && !xs_set_permissions(ctx->xsh, t, path, perms, num_perms))
+return ERROR_FAIL;
+
+return 0;
+}
+
+int libxl__xs_printf_perms(libxl__gc *gc, xs_transaction_t t,
+   const char *path,

Re: [Xen-devel] [PATCH 04/10] x86/hvm: pkeys, add pkeys support when setting CR4

[Andrew Cooper]

On 16/11/15 10:31, Huaitong Han wrote:
> This patch adds pkeys support when setting CR4
>
> Signed-off-by: Huaitong Han 

Again, this patch is in need of a rebase (although it should be entirely
mechanical).

~Andrew

>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 66917ff..953047f 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1911,6 +1911,7 @@ static unsigned long hvm_cr4_guest_reserved_bits(const 
> struct vcpu *v,
>  leaf1_edx = boot_cpu_data.x86_capability[X86_FEATURE_VME / 32];
>  leaf1_ecx = boot_cpu_data.x86_capability[X86_FEATURE_PCID / 32];
>  leaf7_0_ebx = boot_cpu_data.x86_capability[X86_FEATURE_FSGSBASE / 
> 32];
> +leaf7_0_ecx = boot_cpu_data.x86_capability[X86_FEATURE_PKU / 32];
>  }
>  
>  return ~(unsigned long)
> @@ -1946,7 +1947,9 @@ static unsigned long hvm_cr4_guest_reserved_bits(const 
> struct vcpu *v,
>   (leaf7_0_ebx & cpufeat_mask(X86_FEATURE_SMEP) ?
>X86_CR4_SMEP : 0) |
>   (leaf7_0_ebx & cpufeat_mask(X86_FEATURE_SMAP) ?
> -  X86_CR4_SMAP : 0));
> +  X86_CR4_SMAP : 0) |
> + (leaf7_0_ecx & cpufeat_mask(X86_FEATURE_PKU) ?
> +  X86_CR4_PKE : 0));
>  }
>  
>  static int hvm_load_cpu_ctxt(struct domain *d, hvm_domain_context_t *h)
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index c1f924e..8101a1b 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1310,6 +1310,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  
>  if ( disable_pku )
>  setup_clear_cpu_cap(X86_FEATURE_PKU);
> +if ( cpu_has_pku )
> +set_in_cr4(X86_CR4_PKE);
>  
>  if ( cpu_has_fsgsbase )
>  set_in_cr4(X86_CR4_FSGSBASE);


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

Re: [Xen-devel] [libvirt] [PATCH RFC] libxl: use libxl_event_wait to process libxl events

[max ustermann]

Am Fri, 13 Nov 2015 14:36:54 -0700
schrieb Jim Fehlig :


Hi,
i have tested the patches provide by Jim Fehlig.

The setup consist of xen 4.6.0 with libvirt 1.2.19 and the patches.
As i describe in my posting in the libvirt-user list
(https://www.redhat.com/archives/libvir-list/2015-November/msg00130.html),
the system resume 20 VM´s in parallel, attach a block-device and then
attach a network-device, run 60 seconds, destroy each vm and starts
again.

until now the test-system has done 1820 cycles 

i observe , until now, no errors, no crashes and also the system
doesn´t freeze. Everything looks good.


so thank´s a lot for your time, work and help.

all the best
max


> Prior to this patch, libxl events were delivered to libvirt via
> the libxlDomainEventHandler callback registered with libxl.
> Documenation in $xensrc/tools/libxl/libxl_event.h states that the
> callback "may occur on any thread in which the application calls
> libxl". This can result in deadlock since many of the libvirt
> callees of libxl hold a lock on the virDomainObj they are working
> on. When the callback is invoked, it attempts to find a virDomainObj
> corresponding to the domain ID provided by libxl. Searching the
> domain obj list results in locking each obj before checking if it is
> active, and its ID equals the requested ID. Deadlock is possible
> when attempting to lock an obj that is already locked further up
> the call stack. Indeed, Max Ustermann recently reported an instance
> of this deadlock
> 
> https://www.redhat.com/archives/libvir-list/2015-November/msg00130.html
> 
> This patch moves processing of libxl events to a thread, where
> libxl_event_wait() is used to collect events. This allows processing
> libxl events asynchronously in libvirt, avoiding the deadlock.
> 
> Reported-by: max ustermann 
> Signed-off-by: Jim Fehlig 
> ---
> 
> The only reservations I have about this patch come from comments
> about libxl_event_wait in libxl_event.h
> 
>   Like libxl_event_check but blocks if no suitable events are
>   available, until some are.  Uses libxl_osevent_beforepoll/
>   _afterpoll so may be inefficient if very many domains are being
>   handled by a single program.
> 
> libvirt does handle "very many domains" :-). But thus far, I haven't
> noticed any problems in my testing. The reporter expressed interest
> in testing the patch. Positive results from that testing would improve
> my confidence, as would an ACK from Ian Jackson.
> 
>  src/libxl/libxl_domain.c | 130
> ++-
> src/libxl/libxl_domain.h |  16 +- src/libxl/libxl_driver.c |  13
> ++--- 3 files changed, 66 insertions(+), 93 deletions(-)
> 
> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> index 40dcea1..0b8c292 100644
> --- a/src/libxl/libxl_domain.c
> +++ b/src/libxl/libxl_domain.c
> @@ -380,27 +380,14 @@ virDomainDefParserConfig
> libxlDomainDefParserConfig = { .domainPostParseCallback =
> libxlDomainDefPostParse, };
>  
> -
> -struct libxlShutdownThreadInfo
> -{
> -libxlDriverPrivatePtr driver;
> -virDomainObjPtr vm;
> -libxl_event *event;
> -};
> -
> -
>  static void
> -libxlDomainShutdownThread(void *opaque)
> +libxlDomainShutdownEventHandler(libxlDriverPrivatePtr driver,
> +virDomainObjPtr vm,
> +libxl_event *ev)
>  {
> -struct libxlShutdownThreadInfo *shutdown_info = opaque;
> -virDomainObjPtr vm = shutdown_info->vm;
> -libxl_event *ev = shutdown_info->event;
> -libxlDriverPrivatePtr driver = shutdown_info->driver;
>  virObjectEventPtr dom_event = NULL;
>  libxl_shutdown_reason xl_reason =
> ev->u.domain_shutdown.shutdown_reason;
> -libxlDriverConfigPtr cfg;
> -
> -cfg = libxlDriverConfigGet(driver);
> +libxlDriverConfigPtr cfg = libxlDriverConfigGet(driver);
>  
>  if (libxlDomainObjBeginJob(driver, vm, LIBXL_JOB_MODIFY) < 0)
>  goto cleanup;
> @@ -501,74 +488,77 @@ libxlDomainShutdownThread(void *opaque)
>  virObjectUnlock(vm);
>  if (dom_event)
>  libxlDomainEventQueue(driver, dom_event);
> -libxl_event_free(cfg->ctx, ev);
> -VIR_FREE(shutdown_info);
>  virObjectUnref(cfg);
>  }
>  
> +static int
> +libxlDomainXEventsPredicate(const libxl_event *event,
> +   ATTRIBUTE_UNUSED void *data)
> +{
> +/*
> + * Currently we only handle shutdown event
> + */
> +if (event->type == LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN)
> +return 1;
> +
> +return 0;
> +}
> +
>  /*
> - * Handle previously registered domain event notification from
> libxenlight.
> + * Process events from libxl using libxl_event_wait.
>   */
> -void
> -libxlDomainEventHandler(void *data, VIR_LIBXL_EVENT_CONST
> libxl_event *event) +static void
> +libxlDomainXEventsProcess(void *opaque)
>  {
> -libxlDriverPrivatePtr driver = data;
> +libxlDriverPrivatePtr driver = 

Re: [Xen-devel] [PATCH 2/9] xen/arm: vgic-v3: Only emulate identification registers requested by the spec

[Ian Campbell]

On Fri, 2015-11-13 at 11:54 +, Julien Grall wrote:
> Most of the identification registers space contains implementation
> defined registers (see 8.1.13 in ARM IHI 0069A) and only GIC{D,R}_PIDR2
> is required to be implemented.

I think you mean s/requested/required/ in the subject too?

> 
> Currently the emulation of those registers mimic the ARM implementation,
> but it's untrue to say that we properly emulate a such implementation.
> 
> Keep only GIC{D,R}_PIDR2 implemented with the "implementationd defined

"implementation"

> bits" to zero and the ArchRev field (bits[7:4]) to 0x3 as we emulate a
> GICv3.
> 
> Note that the emulation of the range wasn't valid anyway because the
> registers are split in 2 sets (PIDR4-PIDR7 and PIDR0-PIDR2).
> 
> Signed-off-by: Julien Grall 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [PATCH 7/9] xen/arm: vgic-v3: Remove spurious return in GICR_INVALLR

[Ian Campbell]

On Fri, 2015-11-13 at 11:54 +, Julien Grall wrote:
> Signed-off-by: Julien Grall 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [PATCH 6/9] xen/arm: vgic-v3: Emulate read to GICD_ICACTIVER

[Ian Campbell]

On Fri, 2015-11-13 at 11:54 +, Julien Grall wrote:
> The GICD_ICACTIVER registers are missing in the read emulation of the
> distributor.
> 
> Call the common emulation for the whole range.
> 
> Signed-off-by: Julien Grall 

Acked-by: Ian Campbell 

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

[Xen-devel] [PATCH] ocaml/xc: add softreset shutdown reason

[Wei Liu]

According to public/sched.h, there is a new shutdown_reason called
soft_reset. Propagate that value to ocaml.

Signed-off-by: Wei Liu 
---
Cc: David Scott 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
---
 tools/ocaml/libs/xc/xenctrl.ml  | 2 +-
 tools/ocaml/libs/xc/xenctrl.mli | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
index beb95b8..41d228d 100644
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -89,7 +89,7 @@ type compile_info =
compile_date : string;
 }
 
-type shutdown_reason = Poweroff | Reboot | Suspend | Crash | Watchdog
+type shutdown_reason = Poweroff | Reboot | Suspend | Crash | Watchdog | 
Soft_reset
 
 type domain_create_flag = CDF_HVM | CDF_HAP
 
diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
index 8928a2e..b4a175b 100644
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -61,7 +61,7 @@ type compile_info = {
   compile_domain : string;
   compile_date : string;
 }
-type shutdown_reason = Poweroff | Reboot | Suspend | Crash | Watchdog
+type shutdown_reason = Poweroff | Reboot | Suspend | Crash | Watchdog | 
Soft_reset
 
 type domain_create_flag = CDF_HVM | CDF_HAP
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2] xen: sched: fix (ACPI S3) resume with cpupools with different schedulers.

[Juergen Gross]

On 13/11/15 18:10, Dario Faggioli wrote:
> In fact, with 2 cpupools, one (the default) Credit and
> one Credit2 (with at least 1 pCPU in the latter), trying
> a (e.g., ACPI S3) suspend/resume crashes like this:
> 
> (XEN) [  150.587779] [ Xen-4.7-unstable  x86_64  debug=y  Not tainted 
> ]
> (XEN) [  150.587783] CPU:6
> (XEN) [  150.587786] RIP:e008:[] 
> sched_credit.c#csched_schedule+0xf2/0xc3d
> (XEN) [  150.587796] RFLAGS: 00010086   CONTEXT: hypervisor
> (XEN) [  150.587801] rax: 83031fa3c020   rbx: 830322c1b4b0   rcx: 
> 
> (XEN) [  150.587806] rdx: 83031fa78000   rsi: 000a   rdi: 
> 82d0802a9788
> (XEN) [  150.587811] rbp: 83031fa7fe20   rsp: 83031fa7fd30   r8:  
> 83031fa8
> (XEN) [  150.587815] r9:  0006   r10: 0008f7f2   r11: 
> 0006
> (XEN) [  150.587819] r12: 8300dbdf3000   r13: 830322c1b4b0   r14: 
> 0006
> (XEN) [  150.587823] r15:    cr0: 8005003b   cr4: 
> 26e0
> (XEN) [  150.587827] cr3: dbaa8000   cr2: 
> (XEN) [  150.587830] ds:    es:    fs:    gs:    ss:    
> cs: e008
> (XEN) [  150.587835] Xen stack trace from rsp=83031fa7fd30:
> ... ... ...
> (XEN) [  150.587962] Xen call trace:
> (XEN) [  150.587966][] 
> sched_credit.c#csched_schedule+0xf2/0xc3d
> (XEN) [  150.587974][] schedule.c#schedule+0x128/0x635
> (XEN) [  150.587979][] softirq.c#__do_softirq+0x82/0x8d
> (XEN) [  150.587983][] do_softirq+0x13/0x15
> (XEN) [  150.587988][] domain.c#idle_loop+0x5b/0x6b
> (XEN) [  151.272182]
> (XEN) [  151.274174] 
> (XEN) [  151.279624] Panic on CPU 6:
> (XEN) [  151.282915] Xen BUG at sched_credit.c:655
> (XEN) [  151.287415] 
> 
> During suspend, the pCPUs are not removed from their
> pools with the standard procedure (which would involve
> schedule_cpu_switch(). During resume, they:
>  1) are assigned to the default cpupool (CPU_UP_PREPARE
> phase);
>  2) are moved to the pool they were in before suspend,
> via schedule_cpu_switch() (CPU_ONLINE phase)
> 
> During resume, scheduling (even if just the idle loop)
> can happen right after the CPU_STARTING phase(before
> CPU_ONLINE), i.e., before the pCPU is put back in its
> pool. In this case, it is the default pool'sscheduler
> that is invoked (Credit1, in the example above). But,
> during suspend, the Credit2 specific vCPU data is not
> being freed, and Credit1 specific vCPU data is not
> allocated, during resume.
> 
> Therefore, Credit1 schedules on pCPUs whose idle vCPU's
> sched_priv points to Credit2 vCPU data, and we crash.
> 
> Fix things by properly deallocating scheduler specific
> data of the pCPU's pool scheduler during pCPU teardown,
> and re-allocating them --always for  during pCPU
> bringup.
> 
> This also fixes another (latent) bug. In fact, it avoids,
> still in schedule_cpu_switch(), that Credit1's free_vdata()
> is used to deallocate data allocated with Credit2's
> alloc_vdata(). This is not easy to trigger, but only
> because the other bug shown above manifests first and
> crashes the host.
> 
> The downside of this patch, is that it adds one more
> allocation on the resume path, which is not ideal. Still,
> there is no better way of fixing the described bugs at
> the moment. Removing (all ideally) allocations happening
> during resume should continue being chased, in the long
> run.
> 
> Signed-off-by: Dario Faggioli 

Reviewed-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH 3/9] xen/arm: vgic: Properly emulate the full register

[Ian Campbell]

On Fri, 2015-11-13 at 11:54 +, Julien Grall wrote:
> The offset in the emulation is based on byte. As most of the registers
> are 64/32 bits, they will span over multiple bytes.
> 
> However, the current emulation only care about the first offset. This

"cares"

> will result to not emulate properly any access on the register with

"This results in not properly emulating ... with any other offset"

> other offset.
> 
> Introduce new macros to help implementing access on multiple byte and
> use them over the vGIC emulation.
> 
> Note that I didn't convert the reserved/implementation defined
> registers. It will be done in a follow-up.
> 
> Signed-off-by: Julien Grall 

Acked-by: Ian Campbell 

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

Re: [Xen-devel] [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown

[Paul Durrant]

> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: 16 November 2015 13:43
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Cc: Ian Jackson; Stefano Stabellini; Wei Liu
> Subject: Re: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for
> ~/control/shutdown
> 
> On Mon, 2015-11-16 at 13:16 +, Paul Durrant wrote:
> > >
> > > > +ret = vasprintf(, fmt, ap);
> > > >  if (ret == -1) {
> > > >  return -1;
> > > >  }
> > > >  xs_write(ctx->xsh, t, path, s, ret);
> > > > +if (perms)
> > > > +xs_set_permissions(ctx->xsh, t, path, perms, num_perms);
> > >
> > > This can fail, can't it? (OTOH so can xs_write, so maybe there is some
> > > reason we apparently don't care for such things here?)
> > >
> >
> > That's a good point. I would have thought wiring an xs_write() failure
> > back through to the caller would be a good idea (and same goes for
> > xs_set_permissions, I guess).
> 
> git tells me it has been this way since libxl was first committed to the
> repo. I can't think of a good reason to squash these errors.
> 

I'll split out this patch and the name change one and send a small cleanup 
series. I'll wait for Ian's docs review before sending the rest.

  Paul

> Ian.

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

Re: [Xen-devel] Unable to create Stubdomains with NIC(s) - Xen 4.5.2

[Wei Liu]

On Mon, Nov 16, 2015 at 12:11:14PM +, Ian Campbell wrote:
> On Mon, 2015-11-16 at 11:45 +0100, Peter Schmid wrote:
> > Dear all
> > I have been trying to setup stubdomains for added security on a test
> > machine so I could then suggest to use xen at work with some added
> > "backbone" and practical experience.
> > 
> > Unfortunately I am unable to launch domains with a stubdomain when
> > there's a NIC configured in the VM config file.
> > The Domain launches without problems when I comment the vif= entry.
> >  
> > The Error I am getting is the following:
> > libxl: error: libxl_dm.c:1284:stubdom_pvqemu_cb: error connecting nics
> > devices: No such file or directory
> > I have tried different types as well (ioemu, etc.).
> >  
> > More logs/configs can be found further below.
> >  
> > Thank you very much in advance,
> >  Peter
> > 
> > 
> > #
> > $ xl create win7_install_test.cfg                                        
> >         
> > Parsing config from win7_install_test.cfg
> > libxl: error: libxl_dm.c:1284:stubdom_pvqemu_cb: error connecting nics
> > devices: No such file or directory
> > libxl: error: libxl_device.c:797:libxl__initiate_device_remove: unable to 
> > get my domid
> 
> These often suggests that your xencommons initscript is not up to date and
> isn't populating some of the required nodes for dom0. I'm not sure if this
> would have the knock on effect of the breakage you describe, but it is
> worth fixing in any case.
> 
> Given "No such file or directory" I'd also be inclined to check that
> /etc/xen/scripts exists and has stuff in it, especially vif-* and that they
> are executable, there #! refers to a shell which exists etc.
> 
> Weirdly our automated test test doesn't seem to include the stubdom jobs
> for 4.5 (they appear to being at 4.6), but I can't see at all where such a
> test is deliberately suppressed by the test code. Perhaps Wei (CC'd) knows.
> 

4.5 has a bug that completely stops stubdom from working. Paul provided
a workaround which was backported to 4.5.1.  I considered 4.5 branch
stubdom broken so I skipped that branch.

> FWIW the flights testing stbudom in xen-unstable use a cfg file which looks
> like:
>  
> http://logs.test-lab.xenproject.org/osstest/logs/64035/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/merlot1---etc-xen-debianhvm.guest.osstest.cfg
> 
> It doesn't look to me to be materially very different to what you have.
> 
> Ian.
> 
> > libxl: error: libxl_device.c:797:libxl__initiate_device_remove: unable to
> > get my domid

Can you try a config with vif then

  xl create -p guest.cfg

And then use xl list to see if stubdom is alive?

You should see something similar to:

NameID   Mem VCPUs  State   Time(s)
Domain-0 0  2863 4 r-7041.7
wheezy-hvm 699   511 1 --p---   0.0
wheezy-hvm-dm  70032 1 r-  19.9

Wei.

> > libxl: error: libxl_device.c:797:libxl__initiate_device_remove: unable to
> > get my domid
> > libxl: error: libxl_device.c:797:libxl__initiate_device_remove: unable to
> > get my domid
> > libxl: error: libxl.c:1652:devices_destroy_cb: libxl__devices_destroy
> > failed for 2
> > libxl: info: libxl.c:1698:devices_destroy_cb: forked pid 582 for destroy
> > of domain 2
> > libxl: error: libxl_create.c:1362:domcreate_attach_vtpms: unable to add
> > nic devices
> > libxl: error: libxl.c:1578:libxl__destroy_domid: non-existant domain 2
> > libxl: error: libxl.c:1510:stubdom_destroy_callback: unable to destroy
> > stubdom with domid 2
> > libxl: error: libxl_device.c:797:libxl__initiate_device_remove: unable to
> > get my domid
> > libxl: error: libxl_device.c:797:libxl__initiate_device_remove: unable to
> > get my domid
> > libxl: error: libxl_device.c:797:libxl__initiate_device_remove: unable to
> > get my domid
> > libxl: error: libxl.c:1652:devices_destroy_cb: libxl__devices_destroy
> > failed for 1
> > libxl: info: libxl.c:1698:devices_destroy_cb: forked pid 596 for destroy
> > of domain 1
> > libxl: error: libxl_create.c:1482:domcreate_destruction_cb: unable to
> > destroy domain 1 following failed creation
> > #
> > Here is my config file:
> > #
> > builder='hvm'
> > memory = 8192
> > name = "win7_test"
> > ## vif = [ 'mac=00:fe:fe:ca:be:dd,bridge=xenbr0,model=e1000' ]
> > vif = [ 'type=ioemu, bridge=xenbr0' ]
> > uuid = "ffacbdff-abcd-abcd-cafe-deadbeefbabe"
> > acpi = 1
> > apic = 1
> > disk = [ 'file:/home/user/win7_test_2015_11_02.img,hda,w', ]
> > #--
> > ---
> > # boot on floppy (a), hard disk (c) or CD-ROM (d)
> > # default: hard disk, cd-rom, floppy
> > boot="c"
> > # stubdomain:
> > device_model_stubdomain_override = 1
> > xen_platform_pci=0
> > sdl=0
> > vnc=1
> > vncdisplay=0
> > vncconsole=0
> > vnclisten='0.0.0.0'
> > vfb = [ 

Re: [Xen-devel] [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown

[Ian Campbell]

On Wed, 2015-11-11 at 16:18 +, Paul Durrant wrote:
> As documented in docs/misc/xenstore, the XS_MKDIR operation merely makes
> sure a path exists whereas ~/control/shutdown needs to start empty. Also
> using XS_MKDIR for a node which is never supposed to have children is
> somewhat counterintuitive.
> 
> This patch introduces a new libxl__xs_printf_perms() function analogous
> to libxl__xs_printf() but taking explicit permissions arguments, and then
> uses this to create an empty ~/control/shutdown node.
> 
> Signed-off-by: Paul Durrant 
> Cc: Ian Jackson 
> Cc: Stefano Stabellini 
> Cc: Ian Campbell 
> Cc: Wei Liu 
> ---
>  tools/libxl/libxl_create.c   | 16 ++--
>  tools/libxl/libxl_internal.h | 10 ++
>  tools/libxl/libxl_xshelp.c   | 44
> ++--
>  3 files changed, 58 insertions(+), 12 deletions(-)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 921d155..279deda 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -484,7 +484,7 @@ int libxl__domain_make(libxl__gc *gc,
> libxl_domain_config *d_config,
>  libxl_ctx *ctx = libxl__gc_owner(gc);
>  int flags, ret, rc, nb_vm;
>  char *uuid_string;
> -char *dom_path, *vm_path, *libxl_path;
> +char *dom_path, *vm_path, *libxl_path, *control_path;
>  struct xs_permissions roperm[2];
>  struct xs_permissions rwperm[1];
>  struct xs_permissions noperm[1];
> @@ -605,17 +605,21 @@ retry_transaction:
>  libxl__xs_mkdir(gc, t,
>  libxl__sprintf(gc, "%s/device", dom_path),
>  roperm, ARRAY_SIZE(roperm));
> -libxl__xs_mkdir(gc, t,
> -libxl__sprintf(gc, "%s/control", dom_path),
> +
> +control_path = libxl__sprintf(gc, "%s/control", dom_path);
> +
> +libxl__xs_mkdir(gc, t, control_path,
>  roperm, ARRAY_SIZE(roperm));
>  if (info->type == LIBXL_DOMAIN_TYPE_HVM)
>  libxl__xs_mkdir(gc, t,
>  libxl__sprintf(gc, "%s/hvmloader", dom_path),
>  roperm, ARRAY_SIZE(roperm));
>  
> -libxl__xs_mkdir(gc, t,
> -libxl__sprintf(gc, "%s/control/shutdown", dom_path),
> -rwperm, ARRAY_SIZE(rwperm));
> +libxl__xs_printf_perms(gc, t,
> +   libxl__sprintf(gc, "%s/shutdown",
> control_path),
> +   rwperm, ARRAY_SIZE(rwperm),
> +   "");
> +
>  libxl__xs_mkdir(gc, t,
>  libxl__sprintf(gc, "%s/device/suspend/event-
> channel", dom_path),
>  rwperm, ARRAY_SIZE(rwperm));
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 4710804..04d8a29 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -666,6 +666,16 @@ _hidden int libxl__xs_writev_perms(libxl__gc *gc,
> xs_transaction_t t,
>  _hidden int libxl__xs_writev_atonce(libxl__gc *gc,
>   const char *dir, char **kvs);
>  
> +_hidden int libxl__xs_vprintf_perms(libxl__gc *gc, xs_transaction_t t,
> +const char *path,
> +struct xs_permissions *perms,
> +unsigned int num_perms,
> +const char *fmt, va_list ap);
> +_hidden int libxl__xs_printf_perms(libxl__gc *gc, xs_transaction_t t,
> +   const char *path,
> +   struct xs_permissions *perms,
> +   unsigned int num_perms,
> +   const char *fmt, ...)
> PRINTF_ATTRIBUTE(6, 7);
>  _hidden int libxl__xs_printf(libxl__gc *gc, xs_transaction_t t,
>   const char *path, const char *fmt, ...)
> PRINTF_ATTRIBUTE(4, 5);
> /* Each fn returns 0 on success.
> diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
> index 3cac4f2..0b56f8b 100644
> --- a/tools/libxl/libxl_xshelp.c
> +++ b/tools/libxl/libxl_xshelp.c
> @@ -96,25 +96,57 @@ out:
>  
>  }
>  
> -int libxl__xs_printf(libxl__gc *gc, xs_transaction_t t,
> - const char *path, const char *fmt, ...)
> +int libxl__xs_vprintf_perms(libxl__gc *gc, xs_transaction_t t,
> +const char *path,
> +struct xs_permissions *perms,
> +unsigned int num_perms,
> +const char *fmt,
> +va_list ap)
>  {
>  libxl_ctx *ctx = libxl__gc_owner(gc);
>  char *s;
> -va_list ap;
>  int ret;
> -va_start(ap, fmt);
> -ret = vasprintf(, fmt, ap);
> -va_end(ap);
>  
> +ret = vasprintf(, fmt, ap);
>  if (ret 

Re: [Xen-devel] [PATCH v5 1/6] xen/arm: vgic-v2: Implement correctly ITARGETSR0 - ITARGETSR7 read-only

[Ian Campbell]

On Mon, 2015-11-09 at 15:49 +, Julien Grall wrote:
>  #define GICD_ITARGETSR  (0x800)
> +#define GICD_ITARGETSR7 (0x81C)
> +#define GICD_ITARGETSR8 (0x820)

As a future change, I wonder if making these take a parameter (N) and do
the necessary arithmetic would be less error prone?

>  #define GICD_ITARGETSRN (0xBF8)



>  #define GICD_ICFGR  (0xC00)
>  #define GICD_ICFGRN (0xCFC)

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

Re: [Xen-devel] [PATCH 5/9] xen/arm: vgic: Re-order the register emulations to match the memory map

[Ian Campbell]

On Fri, 2015-11-13 at 11:54 +, Julien Grall wrote:
> It helps to find quickly whether we forgot to emulate a register or not.
> 
> At the same time add the missing reserved/implementation defined
> registers. All other missing registers will be added in a follow-up if
> necessary.
> 
> Note that only the distributor register map explicitely say the
> size of a register (see 8.8 in ARM IHI 0069A). When the size is not
> known, the implementation defined/reserved may not be emulated
> correctly.
> 
> Signed-off-by: Julien Grall 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [PATCH 02/10] x86/hvm: pkeys, add pku support for x86_capability

[Andrew Cooper]

On 16/11/15 10:31, Huaitong Han wrote:
> This patch adds pku support for x86_capability.
>
> Signed-off-by: Huaitong Han 

Please rebase your series (preferably on staging).  There are some
recent changes in this area.

As rebasing (and correcting patch 1) will drop this patch to a single
hunk, I would just fold it into patch 1.

~Andrew

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

Re: [Xen-devel] [PATCH 06/10] x86/hvm: pkeys, add functions to get pkeys value from PTE

[Jan Beulich]

>>> On 16.11.15 at 15:16,  wrote:
> On 16/11/15 10:31, Huaitong Han wrote:
>> +#define _PAGE_PKEY_BIT0 19   /* Protection Keys, bit 1/4 */
>> +#define _PAGE_PKEY_BIT1 20   /* Protection Keys, bit 2/4 */
>> +#define _PAGE_PKEY_BIT2 21   /* Protection Keys, bit 3/4 */
>> +#define _PAGE_PKEY_BIT3 22   /* Protection Keys, bit 4/4 */
>> +
>> +#define get_pte_pkeys(x) ((int)(get_pte_flags(x) >> _PAGE_PKEY_BIT0) & 0xF)
> 
> Please implemented these as masks, for consistency with the other
> _PAGE_* entries.  I would recommend also having a _SHIFT and _MASK define.

Since _SHIFT can always be calculated from _MASK, and since
we have MASK_{INSR,EXTR}(), I'd prefer just _MASK ones to
be added, unless this results in significantly less readable code.

>> +
>>  /* Bit 23 of a 24-bit flag mask. This corresponds to bit 63 of a pte.*/
>>  #define _PAGE_NX_BIT (1U<<23)
>>  
> 
> There is however another issue. Xen currently uses bit 62 for software
> purposes, which is incompatible with enabling PKE.  _PAGE_GNTTAB needs
> moving to a different, software-available bit.  I would recommend bit 13
> of flags, adjacent to _PAGE_GUEST_KERNEL which is our other
> software-used flag.

Can we in fact do that? _PAGE_GNTTAB is visible to PV guests, and
those guests need to avoid using that flag for their own purposes.

Jan


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

Re: [Xen-devel] [RFC PATCH 6/6] libxl: create path for advertisement of network attributes...

[Ian Jackson]

Paul Durrant writes ("[RFC PATCH 6/6] libxl: create path for advertisement of 
network attributes..."):
> -frontend_perms[0].id = device->domid;
> -frontend_perms[0].perms = XS_PERM_NONE;
> -frontend_perms[1].id = device->backend_domid;
> -frontend_perms[1].perms = XS_PERM_READ;
> +attr_perms[0].id = frontend_perms[0].id = device->domid;
> +attr_perms[0].perms = frontend_perms[0].perms = XS_PERM_NONE;
> +attr_perms[1].id = frontend_perms[1].id = device->backend_domid;
> +attr_perms[1].perms = frontend_perms[1].perms = XS_PERM_READ;

Why not just use frontend_perms throughout rather than creating a new
identical structure ?

If you do want another structure, please line up the assignemnts
horizontally so that it is easy to read !

Also there is a lot of wrap damage in this patch.  Can you please
rewrap the lines you touch, at least ?  At the moment it is hard for
me to read.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH] cxenstored: correct calculation of data/space in the ring

[Wei Liu]

On Mon, Nov 16, 2015 at 06:09:54PM +, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH] cxenstored: correct calculation of 
> data/space in the ring"):
> > On 16/11/15 18:01, Ian Jackson wrote:
> > > Wei Liu writes ("[PATCH] cxenstored: correct calculation of data/space in 
> > > the ring"):
> > >> The cxenstored implementation can't handle cross ring boundary read and
> > >> write. It gets aways with buggy behaviour because upper layer won't
> > >> sleep when short-write or short-read occurs.
> > > I don't understand why you think this is a bug.
> > 
> > It is exactly the same bug as I fixed in c/s 8a2c11f8
> > 
> > The short reads/writes themselves aren't inherently a problem.  They are
> > genuine signals that the server should wait for the client to
> > produce/consume more data.
> > 
> > However, the low level functions erroneously return a short read/write
> > when hitting the ring boundary when there is actually more space/data. 
> > This causes a protocol stall as the server incorrectly believes that the
> > client has the next action to perform.
> 
> If I understand Wei correctly you are contradicting him.  The `upper
> layer' in question is inside the C xenstored so there is no protocol
> stall.
> 

There is no protocol stall for now. But the code that controls whether
to sleep or not can change (however unlikely). And it would be hard to
debug such bug as the effort for debugging stubdom / oxenstored already
demonstrated.

IMO short-writing and short-reading when there is still space / data is
a bug in its own right. We might as well just fix it before we get hit
again.

Wei.

> (I haven't peered at the code...)
> 
> Ian.

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

Re: [Xen-devel] [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown

[Paul Durrant]

> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 16 November 2015 17:20
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Stefano Stabellini; Ian Campbell; Wei Liu
> Subject: Re: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for
> ~/control/shutdown
> 
> Paul Durrant writes ("[RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for
> ~/control/shutdown"):
> > As documented in docs/misc/xenstore, the XS_MKDIR operation merely
> makes
> > sure a path exists whereas ~/control/shutdown needs to start empty. Also
> > using XS_MKDIR for a node which is never supposed to have children is
> > somewhat counterintuitive.
> 
> The way xenstore doesn't distinguish between leaves and directories is
> unusual but it is part of the xenstore API.  I think users inside
> libxl will have to cope with it anyway.
> 
> > This patch introduces a new libxl__xs_printf_perms() function analogous
> > to libxl__xs_printf() but taking explicit permissions arguments, and then
> > uses this to create an empty ~/control/shutdown node.
> 
> This is a lot of extra boilerplate to clean up one slightly odd call.
> 
> Maybe it would be easier to rename libxl__xs_mkdir to
> libxl__xs_mknode ?  (It's probably too late to rename XS_MKDIR.)
> 

There is still the need to set the path to an empty value though, which is not 
implicitly done by the XS_MKDIR.

  Paul

> Ian.

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

Re: [Xen-devel] [PATCH] cxenstored: correct calculation of data/space in the ring

[Ian Jackson]

Wei Liu writes ("[PATCH] cxenstored: correct calculation of data/space in the 
ring"):
> The cxenstored implementation can't handle cross ring boundary read and
> write. It gets aways with buggy behaviour because upper layer won't
> sleep when short-write or short-read occurs.

I don't understand why you think this is a bug.

> It would be nice, however, to make the low level routine correct
> regardless of what upper layer is doing. This should at least avoid
> latent bug should upper layer logic changes.

I don't think this is as hard a layer boundary as you suggest.

Ian.

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

Re: [Xen-devel] [RFC PATCH 4/6] libxl: add guest writable xenstore area for driver versions

[Ian Jackson]

Ian Jackson writes ("Re: [RFC PATCH 4/6] libxl: add guest writable xenstore 
area for driver versions"):
> > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > index cc82311..389427f 100644
> > --- a/tools/libxl/libxl_create.c
> > +++ b/tools/libxl/libxl_create.c
> > @@ -648,6 +648,9 @@ retry_transaction:
> >  libxl__xs_mkdir(gc, t,
> >  libxl__sprintf(gc, "%s/data", dom_path),
> >  rwperm, ARRAY_SIZE(rwperm));
> > +libxl__xs_mkdir(gc, t,
> > +libxl__sprintf(gc, "%s/drivers", dom_path),
> > +rwperm, ARRAY_SIZE(rwperm));
> 
> I see there are already many of these open-coded calls to
> libxl__xs_mkdir with libxl__sprintf (rather than GCSPRINTF).  Oh well.

Which means, I should say:

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [RFC PATCH 4/6] libxl: add guest writable xenstore area for driver versions

[Ian Jackson]

Paul Durrant writes ("[RFC PATCH 4/6] libxl: add guest writable xenstore area 
for driver versions"):
> docs/misc/xenstore-paths documents a path format that can be used by
> guests to supply version information for PV drivers.
> 
> This patch creates a guest writable ~/drivers area for these paths.
> 
> Signed-off-by: Paul Durrant 
> Cc: Ian Jackson 
> Cc: Stefano Stabellini 
> Cc: Ian Campbell 
> Cc: Wei Liu 
> ---
>  tools/libxl/libxl_create.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index cc82311..389427f 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -648,6 +648,9 @@ retry_transaction:
>  libxl__xs_mkdir(gc, t,
>  libxl__sprintf(gc, "%s/data", dom_path),
>  rwperm, ARRAY_SIZE(rwperm));
> +libxl__xs_mkdir(gc, t,
> +libxl__sprintf(gc, "%s/drivers", dom_path),
> +rwperm, ARRAY_SIZE(rwperm));

I see there are already many of these open-coded calls to
libxl__xs_mkdir with libxl__sprintf (rather than GCSPRINTF).  Oh well.

Ian.

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

Re: [Xen-devel] 9p file system for xen

[Wei Liu]

On Mon, Nov 16, 2015 at 10:22:41AM -0700, Linda wrote:
> 
> 
> On 11/16/2015 9:51 AM, Wei Liu wrote:
> >On Mon, Nov 16, 2015 at 09:36:24AM -0700, Linda wrote:
> >>Hi Wei,
> >>
> >>On 11/16/2015 8:16 AM, Wei Liu wrote:
> >>>Hi Linda
> >>>
> >>>On Fri, Nov 13, 2015 at 10:23:22AM -0700, Linda wrote:
> Hello,
>   I worked this summer as an intern under Julien Grall and Wei Liu.  
>  My
> project was to develop a prototype/proof of concept xen front/back end for
> the 9p file system.  I mostly hacked the virtio 9p system.
>  This project was not complete, at the end of the summer.  Julien said
> that you all wanted to include this in the next release of xen in January,
> and offered to take it over.  I told Julien I wanted to continue working 
> on
> it, which I have been doing, very much in the background.
>  I came upon a bug in my code recently that made me aware that I am 
>  not
> clear what the expectation for what I deliver should be: i.e., whether 
> it's
> still a prototype, or whether this should be production software.
>  Right now, I do not modify the toolstack (I never learned how), but
> rather start and pause my guest, and then modify xenstore, manually.   I 
> can
> fix my bug in the same manner, but this will limit the usefulness of what 
> I
> deliver.  To do more will hit up against the limitations of my time and
> knowledge.
>  So please let me know what you're expecting, especially wrt the user
> interface, and when I would need to complete everything for this release.
> 
> >>>If I interpret this correctly, you have a prototype that's working? Do
> >>>you have your code somewhere?
> >>No.  I hit a bug that I would fix differently, depending on my goal.
> >>>I think we would still like to include it in next release if possible --
> >>>that would require a properly implemented solution, not just a
> >>>prototype.  Let's assess the current situation and then decide what to
> >>The situation is, given my current knowledge and what my availability has
> >>been (it may improve), I can either:
> >> a.  Get a decent prototype working by the end of the year.  This would
> >>have certain values pre-written in xenstore, that I'm currently doing
> >>manually.  There are potentially some issues with mounting that I suspect
> >>need to be different for xen than they are for virtio - so either way, I
> >>need a clarification of how xen people want this to work.
> >> b.  Make sure what I've written is working, and pass it on to someone
> >>else to update the toolstack, and resolve the issues, described above.  In
> >>this scenario, I would need to know how much time that someone would need
> >>and just devote a week to getting this to them.
> >>
> >Your description is too vague. I don't have clear idea what kind of bug
> >you encountered and what suggestion I can give.
> The bug is a timing issue:  During virtio's probe step, on the front end, it
> initialized the mount path.  Since at that time, the front end doesn't have
> access to the back end's entries in xenstore (AFIACT), I either need to put
> it in xenstore prior to starting, or move the access to this information to
> later in the initialization.
> 
> Note, I used the past tense on what virtio did, as of last summer: when I
> looked at it last week, it appears to have changed since I first used it as
> a template.I need to investigate this further.
> 

OK.

> Finally, I've made no provision for how to mount more than one file system
> for the same guest.  This is a feature that virtio provides for in the
> front-end code (as do I), but I am unclear about how this works in the
> back-end or at the user level.  This is what I suspect will be different in
> xen, and I'd like some input on what it should look like.

I think this comes down to how your design the xenstore protocol to
represent different mount points.

> >The code freeze for next release is going to be end of March next year.
> >As software engineer often overestimates the progress he or she can
> >make, I would say we shall aim for getting something working as soon as
> >possible. Get the design straight and something clean by the end of this
> >year would be good.
> Sounds good to me.  I'm happy to keep working on this.  I just didn't want
> to find myself in a position where I needed to pass this on to someone else,
> but I didn't give that person enough time to finish what I'd done.

Depending on the situation, I can take over the code. You've done enough
for this project and we don't really want you to work on it for free --
we don't have provision for more funding at the moment.

If we end up taking over the project, we will still attribute the
initial implementation to you.

Wei.

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

Re: [Xen-devel] [PATCH v4 2/4] docs: Introduce xenstore paths for PV driver information

[Ian Jackson]

Paul Durrant writes ("[PATCH v4 2/4] docs: Introduce xenstore paths for PV 
driver information"):
> For domain management purposes it is convenient to be able to see
> information about PV drivers in xenstore. The XAPI toolstack in
> XenServer has always created a ~/drivers path for this purpose.
> 
> This patch documents that path and also adds a specification of how
> it should be used.
...
> +* DISTRIBUTION -- information about a software distribution, comprised
> +  of 3 or 4 space separated fields as follows:

I think you should also specify an allowable character set, and
expected matching rules (if any).

> +  VENDOR -- Commonly used vendor short name,
> +e.g "Citrix" rather than "Citrix Systems
> +Inc."
> +
> +  PRODUCT -- Commonly used product (e.g. driver) name
> + without version information.

"If a toolstack needs to match on these values it should support Unix
glob style matching" ?

> +  ATTRIBUTES -- Optional human readable text enclosed in
> +parentheses to denote attributes of the
> +software, e.g. "(debug)"

What are the parentheses for ?  How might a toolstack provide
facilities to match this ?

Ian.

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

Re: [Xen-devel] [PATCH V8 2/7] libxl_read_file_contents: add new entry to read sysfs file

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH V8 2/7] libxl_read_file_contents: add new 
entry to read sysfs file"):
> @@ -359,20 +360,35 @@ int libxl_read_file_contents(libxl_ctx *ctx, const
> > char *filename,
> >  datalen = stab.st_size;
> >  
> >  if (stab.st_size && data_r) {
> > -data = malloc(datalen);
> > +data = malloc(datalen + 1);
> 
> This (and the related change) seem to be fixing an off by one bug in the
> existing code? At a minimum this should be mentioned in the commit message
> but ideally it would be split out into a precursor code, so as to allow it
> to be backported (assuming it is a bug fix and not some other consequence
> of reading from sysfs).

There is no off-by-one error in the existing code.  I think this +1
arises because Chunyan wants libxl__read_sysfs_file_contents to
produce a nul-terminated string, even though libxl_read_file_contents
doesn't.

In June I wrote:

  If you want to make an API which is useable for [code which wants a
  trailing nul], and not intended for byte blocks, that's fine, but
  you must then always nul-terminate (not only if the data was less
  than 4k) and your new function probably doesn't want to return a
  length at all.

I am coming to the thought that it might be better for this to be two
functions with entirely separate implementations.  The resulting
unified function is already full of tangled conditional logic, and our
complaint here will involve yet another conditional.

Ian.

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

Re: [Xen-devel] [PATCH v8 01/21] xen/x86: add bitmap of enabled emulated devices

[Andrew Cooper]

On 16/11/15 12:18, Jan Beulich wrote:
 On 06.11.15 at 17:05,  wrote:
>> --- a/xen/include/public/arch-x86/xen.h
>> +++ b/xen/include/public/arch-x86/xen.h
>> @@ -265,7 +265,31 @@ typedef struct arch_shared_info arch_shared_info_t;
>>   * XEN_DOMCTL_INTERFACE_VERSION.
>>   */
>>  struct xen_arch_domainconfig {
>> -char dummy;
>> +#define _XEN_X86_EMU_LAPIC  0
>> +#define XEN_X86_EMU_LAPIC   (1U<<_XEN_X86_EMU_LAPIC)
>> +#define _XEN_X86_EMU_HPET   1
>> +#define XEN_X86_EMU_HPET(1U<<_XEN_X86_EMU_HPET)
>> +#define _XEN_X86_EMU_PM 2
>> +#define XEN_X86_EMU_PM  (1U<<_XEN_X86_EMU_PM)
>> +#define _XEN_X86_EMU_RTC3
>> +#define XEN_X86_EMU_RTC (1U<<_XEN_X86_EMU_RTC)
>> +#define _XEN_X86_EMU_IOAPIC 4
>> +#define XEN_X86_EMU_IOAPIC  (1U<<_XEN_X86_EMU_IOAPIC)
>> +#define _XEN_X86_EMU_PIC5
>> +#define XEN_X86_EMU_PIC (1U<<_XEN_X86_EMU_PIC)
>> +#define _XEN_X86_EMU_VGA6
>> +#define XEN_X86_EMU_VGA (1U<<_XEN_X86_EMU_VGA)
>> +#define _XEN_X86_EMU_IOMMU  7
>> +#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)
> While only used for a domctl (so far), I still think we should aim at
> making this a complete set (i.e. preempt future additions to the
> set if at all possible). I say this because - having looked again - I'm
> missing things like MTRR, PAT, and 8254 here.

Use (or not) of MTRR and PAT should be controlled exclusively via the
guests cpuid policy.  Unlike the above bits, they are architectural
components of the CPU itself, rather than external devices on the
motherboard.

~Andrew

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

Re: [Xen-devel] [PATCH] xen/x86: Adjust stack pointer in xen_sysexit

[Andy Lutomirski]

On Mon, Nov 16, 2015 at 8:25 AM, Boris Ostrovsky
 wrote:
> On 11/15/2015 01:02 PM, Andy Lutomirski wrote:
>>
>> On Nov 13, 2015 5:23 PM, "Boris Ostrovsky" 
>> wrote:
>>>
>>>
>>>
>>> On 11/13/2015 06:26 PM, Andy Lutomirski wrote:

 On Fri, Nov 13, 2015 at 3:18 PM, Boris Ostrovsky
  wrote:
>
> After 32-bit syscall rewrite, and specifically after commit
> 5f310f739b4c
> ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack
> frame that is passed to xen_sysexit is no longer a "standard" one (i.e.
> it's not pt_regs).
>
> We need to adjust it so that subsequent xen_iret can use it.

 I'm wondering if this should be more straightforward:

   movq%rsp, %rdi
   calldo_fast_syscall_32
   testl   %eax, %eax
   jz  .Lsyscall_32_done

   /* Opportunistic SYSRET */
 sysret32_from_system_call:
   XEN_DO_SYSRET32

 where XEN_DO_SYSRET32 is a simple pv op that, on Xen, jumps to a
 variant of Xen's iret path that knows that the fast path is okay.
>>>
>>>
>>>
>>> This patch is for 32-bit kernel. I actually haven't looked at compat code
>>> (probably because our tests don't try that), I need to do that too.
>>
>> In 4.4, it's almost identical (which was part of the point of this
>> whole series).  We use sysret32 instead of sysexit, but the underlying
>> structure is the same: munge the stack frame and register state
>> appropriately to use the fast return instruction in question and then
>> execute it.  In both cases, the only real difference from the IRET
>> path is that we're willing to lose the values of some subset of cx,
>> dx, and (on 64-bit kernels) r11.
>
>
>
> So it turned out that for compat mode we don't need to do anything since
> xen_sysret32 doesn't assume any stack format (or, rather, it assumes that it
> can't be used) and builds the IRET frame itself.
>

It's still a waste of effort, though.  Also, I'd eventually like the
number of places in Xen code in which rsp/esp is invalid to be exactly
zero, and this approach makes this harder or even impossible.

>
>>
>>> As for XEN_DO_SYSRET32 --- we'd presumably need to have a nop for
>>> baremetal otherwise current paravirt op will use native_usergs_sysret32 (for
>>> compat code). Which means a new pv_op, I think.
>>
>> Agreed, unless...
>>
>> Does Xen have a cpufeature?  Using ALTERNATIVE instead of a pvop could
>> be easier to follow and be less code at the same time.  Frankly,
>> following the control flow from asm through the pre-paravirt-patching
>> and post-paravirt-patching variants and into the final targets is
>> getting a little bit old, and ALTERNATIVE is crystal clear in
>> comparison (and has all the interesting info inline with the rest of
>> the asm).  Of course, it doesn't work early in boot, but that's fine
>> for anything involving user/kernel switches.
>
>
>
> We don't currently have a Xen-specific CPU feature. We could, in principle,
> add it but we can't replace all of current paravirt patching with a single
> feature since PVH guests use a subset of existing pv ops (and in the future
> it may become even more fine-grained).
>
> And I don't think we should go ALTERNATIVE route for one set of features and
> keep pv ops for the rest --- it should be either one or the other.

Does PVH hook into the entry asm code at all?  I thought it was just
boot code and drivers.

In any case, someone needs to do some serious review and cleanup on
the whole paravirt op mess.  We have a bunch of paravirt ops that
serve little purpose.

The paravirt infrastructure is a bit weird, too: it seems to
effectively have four states for each patch site.  There's:

1. The initial state, which is unoptimized and works on native.
Presumably any of these that happen early also need to work, if
slowly, on Xen.

2. The Xen state without text patching.  I'm not actually sure why
this exists at all.  Are there pvops that need to switch too early for
us to patch the text?

3. The native patched state.  This is supposedly optimal, but it
results in a few more NOPs than are really needed.

4. The Xen patched state.

Alternatives have only two states, and the code is much easier to
understand.  Also, alternatives avoid things like:

...
SWAPGS
...

The reader surely doesn't remember that this isn't guaranteed to be a
swapgs instruction on native.  Using:

ALTERNATIVE "swapgs" "" X86_FEATURE_XENPV

would be safer (it would get rid of the SWAPGS_UNSAFE_STACK mess) and
much clearer.  We could hide *that* behind a macro and no one would be
confused.  (Well, they'd be confused by the fact that Xen PV handles
gsbase very differently from native, but that has nothing to do with
the macro.)

I think we could convert piecemeal, and I wonder if this new patch for
32-bit native on 4.4 (this is needed for 4.4, right?) would be a good

Re: [Xen-devel] [PATCH v2 1/3] xsm/xen_version: Add XSM for the xen_version hypercall.

[Konrad Rzeszutek Wilk]

On Tue, Nov 10, 2015 at 02:51:35PM -0500, Daniel De Graaf wrote:
> On 06/11/15 14:36, Konrad Rzeszutek Wilk wrote:
> >All of XENVER_* have now an XSM check.
> >
> >The subops for XENVER_[compile_info|changeset|commandline|
> >extraversion] are now priviliged operations. To not break
> >guests we still return an string - but it is just ''.
> >
> >The rest: XENVER_[version|capabilities|
> >parameters|get_features|page_size|guest_handle] behave
> >as before - allowed by default for all guests.
> >
> >This is with the XSM default policy and with the dummy ones.
> >
> >Signed-off-by: Konrad Rzeszutek Wilk 
> 
> Comments below, inline.
> 
> [...]
> >diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
> >b/tools/flask/policy/policy/modules/xen/xen.te
> >index d35ae22..1ca0e65 100644
> >--- a/tools/flask/policy/policy/modules/xen/xen.te
> >+++ b/tools/flask/policy/policy/modules/xen/xen.te
> >@@ -73,6 +73,12 @@ allow dom0_t xen_t:xen2 {
> >  pmu_ctrl
> >  get_symbol
> >  };
> >+
> >+# Allow dom0 to use XENVER_compile_info|changeset|commandline]extraversion
> >+allow dom0_t xen_t:xen2 {
> >+version_priv
> >+};
> >+
> >  allow dom0_t xen_t:mmu memorymap;
> >
> >  # Allow dom0 to use these domctls on itself. For domctls acting on other
> 
> Minor tweak: if you don't want to add the new to the block a few lines above,
> the one-line permission syntax without braces (as seen below) looks better.

OK.
> 
> [...]
> >  DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> >  {
> >+bool_t deny = !!xsm_version_op(XSM_HOOK, cmd);
> >+
> 
> Since this call produces denials in the default policy, it should be marked
> as XSM_OTHER.


> 
> >diff --git a/xen/xsm/flask/policy/access_vectors 
> >b/xen/xsm/flask/policy/access_vectors
> >index effb59f..273459f 100644
> >--- a/xen/xsm/flask/policy/access_vectors
> >+++ b/xen/xsm/flask/policy/access_vectors
> >@@ -93,6 +93,8 @@ class xen2
> >  pmu_ctrl
> >  # PMU use (domains, including unprivileged ones, will be using this 
> > operation)
> >  pmu_use
> >+# XENVER_[compile_info|changeset|commandline|extraversion] usage.
> >+   version_priv
> >  }
> >
> >  # Classes domain and domain2 consist of operations that a domain performs 
> > on
> >@@ -242,6 +244,8 @@ class domain2
> >  mem_sharing
> >  # XEN_DOMCTL_psr_cat_op
> >  psr_cat_op
> >+# 
> >XENVER_[version|capabilities|parameters|get_features|page_size|guest_handle].
> >+version_use
> >  }
> >
> >  # Similar to class domain, but primarily contains domctls related to HVM 
> > domains
> >
> 
> I think that both version_priv and version_use belong in the same access
> vector (xen2) rather than placing version_use in domain2.

OK, it just that the 'xen2' says: "Class xen and xen2 consists of dom0-only 
operations
dealing with the  hypervisor itself." (from access_vectors) - hence the split 
in using
domain2 and xen2.
> 
> -- 
> Daniel De Graaf
> National Security Agency

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

Re: [Xen-devel] [RFC PATCH 5/6] libxl: add guest writable xenstore area for feature advertisement

[Ian Jackson]

Paul Durrant writes ("[RFC PATCH 5/6] libxl: add guest writable xenstore area 
for feature advertisement"):
> docs/misc/xenstore-paths documents a paths under a top-level ~/features
> area that a guest can use to advertise the ability to react to vif
> or vbd hotplug.

Acked-by: Ian Jackson 

As before.

Ian.

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

Re: [Xen-devel] [PATCH v4 4/4] docs: Introduce xenstore paths for guest network address information

[Ian Jackson]

Paul Durrant writes ("[PATCH v4 4/4] docs: Introduce xenstore paths for guest 
network address information"):
> +* MAC_ADDRESS -- 6 integers, in hexadecimal form, separated by ':',
> + specifying an ethernet MAC address.
> +* IPV4_ADDRESS -- 4 integers, in decimal form, separated by '.',
> +  specifying an IP version 4 address.
> +* IPV6_ADDRESS -- Up to 8 integers, in hexadecimal form, separated
> +  by ':', specifying an IP version 6 address.
> +  (Zero compression of addresses, using '::' notation,
> +  is allowed but not required).

Sorry for not mentioning this before, but you should probably
provide normative cross-references.

> + ~/attr/vif/$DEVID/name = STRING [w]
> +
> +A domain may write its internal 'friendly' name for a network device
> +using this path. A toolstack or UI may use this for display purposes
> +but, since it is entirely under the control of the guest, no
> +particular meaning should be inferred from the name.

Permitted character set ?  Encoding ?

> + ~/attr/vif/$DEVID/mac/$INDEX = MAC_ADDRESS [w]
> +
> +The guest may override the MAC address written in the vif backend by
> +the toolstack and hence the guest may write one of the paths of
> +this form with the unicast MAC address it is currently using. Other
> +paths may be used by the guest to write multicast addresses which
> +are in operation.

"Paths of this form" vs "other paths" is confusing.  If there is a
distinction between $INDEX==0 and others, you need to say so - but I
think you probably don't intend that.

> +The values written to these paths are under guest control and, as
> +such, they are primarily for display purposes and should not be used
> +for packet filtering or routing purposes.

Not using them for filtering or routing is not just for security
reasons but also to avoid hideous layer violation doom.  So I would
delete the whole section about `under guest control' (which is
obvious) and make it two sentences.  I would also say `must not'
rather than `should not'.

A similar comment applies to the IPv4 and IPv6 addresses.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH v4 2/4] docs: Introduce xenstore paths for PV driver information

[Paul Durrant]

> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 16 November 2015 17:36
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Ian Campbell; Jan Beulich; Keir (Xen.org);
> Tim (Xen.org)
> Subject: Re: [PATCH v4 2/4] docs: Introduce xenstore paths for PV driver
> information
> 
> Paul Durrant writes ("[PATCH v4 2/4] docs: Introduce xenstore paths for PV
> driver information"):
> > For domain management purposes it is convenient to be able to see
> > information about PV drivers in xenstore. The XAPI toolstack in
> > XenServer has always created a ~/drivers path for this purpose.
> >
> > This patch documents that path and also adds a specification of how
> > it should be used.
> ...
> > +* DISTRIBUTION -- information about a software distribution, comprised
> > +  of 3 or 4 space separated fields as follows:
> 
> I think you should also specify an allowable character set, and
> expected matching rules (if any).
> 

I'm unclear about what's legal. In xenstore.txt there's a paragraph:

" While xenstore and most tools and APIs are capable of dealing with
arbitrary binary data as values, this should generally be avoided.
Data should generally be human-readable for ease of management and
debugging; xenstore is not a high-performance facility and should be
used only for small amounts of control plane data.  Therefore xenstore
values should normally be 7-bit ASCII text strings containing bytes
0x20..0x7f only, and should not contain a trailing nul byte.  (The
APIs used for accessing xenstore generally add a nul when reading, for
the caller's convenience.)"

So, should we allow anything other than 7-bit ASCII?

> > +  VENDOR -- Commonly used vendor short name,
> > +e.g "Citrix" rather than "Citrix Systems
> > +Inc."
> > +
> > +  PRODUCT -- Commonly used product (e.g. driver) name
> > + without version information.
> 
> "If a toolstack needs to match on these values it should support Unix
> glob style matching" ?
> 

Yes, I can add that.

> > +  ATTRIBUTES -- Optional human readable text enclosed in
> > +parentheses to denote attributes of the
> > +software, e.g. "(debug)"
> 
> What are the parentheses for ?  How might a toolstack provide
> facilities to match this ?
> 

I was not expecting any matching on attributes, since it's optional anyway. I 
guess the parentheses are indeed redundant.

  Paul

> Ian.

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

[Xen-devel] [OSSTEST PATCH 7/7] ts-logs-capture: Attempt to power up a host before capturing its logs

[Ian Jackson]

If for any reason it's powered down, this is useful.

(In theory for a nested host, we could get the logs by grobbling in
its parent's view of its filesystem, but that is too much work.)

We do not trap the errors from this, so that if the PDU is broken (or
the L1 has not been created), we can fail more quickly.

Signed-off-by: Ian Jackson 
---
 ts-logs-capture |1 +
 1 file changed, 1 insertion(+)

diff --git a/ts-logs-capture b/ts-logs-capture
index 86fad93..73b7c5e 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -248,6 +248,7 @@ sub fetch_logs_guest ($) {
 }
 }
 
+power_state($ho,1);
 find_guests();
 fetch_xenctx_guest($_) foreach @guests;
 serial_fetch_logs($ho);
-- 
1.7.10.4


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

[Xen-devel] [OSSTEST PATCH 6/7] Nested: Make Osstest::PDU::guest idempotent

[Ian Jackson]

These methods are supposed to succeed, silently, if the host is
already in the required power state.

Signed-off-by: Ian Jackson 
---
 Osstest/PDU/guest.pm   |   13 +++--
 Osstest/TestSupport.pm |3 ++-
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/Osstest/PDU/guest.pm b/Osstest/PDU/guest.pm
index b6bf9a1..b708af5 100755
--- a/Osstest/PDU/guest.pm
+++ b/Osstest/PDU/guest.pm
@@ -49,10 +49,19 @@ sub pdu_power_state {
 die "$child->{Name} ?" unless $parent;
 
 logm("power $child->{Name} nested on $parent->{Name} ".($on+0));
+
+my $st = guest_get_state($parent, $child);
 if ($on) {
-   toolstack($parent)->create($child);
+   if ($st =~ m/^$guest_state_running_re$/o) {
+   } elsif (length($st)) { # exists but crashed or something ?
+   toolstack($parent)->destroy($child);
+   } else { # does not exist
+   toolstack($parent)->create($child);
+   }
 } else {
-   toolstack($parent)->destroy($child);
+   if (length($st)) {
+   toolstack($parent)->destroy($child);
+   }
 }
 }
 
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 6c08c6d..d1f7d36 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -97,7 +97,8 @@ BEGIN {
   prepareguest_part_lvmdisk prepareguest_part_diskimg
   prepareguest_part_xencfg
   guest_umount_lv guest_await guest_await_dhcp_tcp
-  guest_checkrunning target_check_ip guest_find_ether
+  guest_checkrunning $guest_state_running_re
+  target_check_ip guest_find_ether
   guest_find_domid guest_check_up guest_check_up_quick
   guest_get_state guest_await_reboot
   guest_await_shutdown guest_await_destroy guest_destroy
-- 
1.7.10.4


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