[Xen-devel] [qemu-upstream-4.3-testing test] 61805: tolerable FAIL - PUSHED

[osstest service owner]

flight 61805 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61805/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64 19 guest-start/debianhvm.repeat fail 
in 61729 pass in 61805
 test-amd64-amd64-xl-qcow2 9 debian-di-install   fail pass in 61729
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 
61729

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail in 61729 like 60700
 test-amd64-i386-xl-raw9 debian-di-installfail   like 60700
 test-amd64-i386-libvirt  11 guest-start  fail   like 60700
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 60700

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 test-amd64-amd64-xl-raw   9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu92dae02ba02166cfcce020cb71021a73903ada2f
baseline version:
 qemuu20c1b1812de98ed789d55e22a43a4700fb765596

Last test of basis60700  2015-08-14 10:50:55 Z   30 days
Failing since 60903  2015-08-27 01:40:43 Z   18 days4 attempts
Testing same since61620  2015-09-08 12:11:41 Z5 days3 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Peter Lieven 

jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt pass
 test-amd64-i386-libvirt  fail
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-libvirt-qcow2   pass
 test-amd64-i386-libvirt-qcow2pass
 test-amd64-amd64-xl-qcow2fail
 test-amd64-i386-xl-qcow2 pass
 test-amd64-amd64-libvirt-raw pass
 test-amd64-i386-libvirt-raw  pass
 test-amd64-amd64-xl-raw  fail
 test-amd64-i386-xl-raw   fail
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-libvirt-vhd

Re: [Xen-devel] writing to read only scsi drives [and 1 more messages]

[Ian Jackson]

M A Young writes ("writing to read only scsi drives"):
> I thought I would check here in case this is a new security issue but it 
> was reported at https://bugzilla.redhat.com/show_bug.cgi?id=1257893 that 
> in HVM guests it was possible to write to scsi devices (either specified 
> as sda etc. in the configuration file or in a scsi device if the guest 
> kernel is booted with the xen_emul_unplug=never option) that were 
> specified as read only in the xl configuration file.

Thanks for passing this on.

This does not appear to be limited to SCSI.  Stefano has kindly
prepared a patch.  (See below for the current draft of that patch.)

I have assigned this issue Xen Security Advisory number 142.  There
will be no embargo because the issue is already public.

I am going to do some more tests to understand the scope of the
problem.

Ian.

Stefano Stabellini writes ("[PATCH for-4.6] libxl: handle read-only drives with 
qemu-xen"):
> The current libxl code doesn't deal with read-only drives at all.
> 
> Upstream QEMU and qemu-xen only support read-only cdrom drives: make
> sure to specify "readonly=on" for cdrom drives and return error in case
> the user requested a non-cdrom read-only drive.
> 
> Signed-off-by: Stefano Stabellini 
> ---
>  tools/libxl/libxl_dm.c |   13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 02c0162..468ff9c 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -1110,13 +1110,18 @@ static int 
> libxl__build_device_model_args_new(libxl__gc *gc,
>  if (disks[i].is_cdrom) {
>  if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY)
>  drive = libxl__sprintf
> -(gc, 
> "if=ide,index=%d,media=cdrom,cache=writeback,id=ide-%i",
> - disk, dev_number);
> +(gc, 
> "if=ide,index=%d,readonly=%s,media=cdrom,cache=writeback,id=ide-%i",
> + disk, disks[i].readwrite ? "off" : "on", 
> dev_number);
>  else
>  drive = libxl__sprintf
> -(gc, 
> "file=%s,if=ide,index=%d,media=cdrom,format=%s,cache=writeback,id=ide-%i",
> - disks[i].pdev_path, disk, format, dev_number);
> +(gc, 
> "file=%s,if=ide,index=%d,readonly=%s,media=cdrom,format=%s,cache=writeback,id=ide-%i",
> + disks[i].pdev_path, disk, disks[i].readwrite ? 
> "off" : "on", format, dev_number);
>  } else {
> +if (!disks[i].readwrite) {
> +LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "QEMU doesn't support 
> read-only disk drivers");
> +return ERROR_INVAL;
> +}
> +
>  if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY) {
>  LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "cannot support"
> " empty disk format for %s", disks[i].vdev);
> -- 
> 1.7.10.4
> 

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

Re: [Xen-devel] [PATCH OSSTEST 2/2] crontab-cambridge: Add distros-debian-stretch

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST 2/2] crontab-cambridge: Add 
distros-debian-stretch"):
> I thought I'd done this ages ago...

Acked-by: Ian Jackson 

Both patches.

Ian.

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

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

[Jan Beulich]

>>> On 14.09.15 at 11:36,  wrote:
> On 14 September 2015 at 11:31, Shannon Zhao  wrote:
>> My understanding is that if there are no EFI_MEMORY_RUNTIME regions, it
>> means we can't use runtime services and should not set the bit
>> EFI_RUNTIME_SERVICES of efi.flags. But if efi_virtmap_init() return
>> true, the bit will be set.
>>
> 
> As I said, if you don't want the EFI_RUNTIME_SERVICES bit to be set
> for other reasons, don't rig efi_virtmap_init() to return false when
> it shouldn't.
> 
>>> The absence of such regions is allowed by the spec, so
>>> efi_virtmap_init() is correct imo to return success.
>>>
>> Sorry, not well know about the spec. Could you point out where the spec
>> says this?
>>
> 
> Well, I think it doesn't work that way. You are claiming that a memory
> map without at least one EFI_MEMORY_RUNTIME constitutes an error
> condition, so the burden is on you to provide a reference to the spec
> that says you must have at least one such region.

Sure, from a spec pov you're right. But where would runtime
services code/data live when there's not a single region marked
as needing a runtime mapping. IOW while the spec doesn't say
so, assuming no runtime services when there's not at least one
executable region with the runtime flag set could serve as a stop
gap measure against flawed firmware.

Jan


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

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

[Juergen Gross]

On 09/14/2015 12:36 PM, George Dunlap wrote:

On Mon, Sep 14, 2015 at 4:48 AM, Juergen Gross  wrote:

On 09/11/2015 04:41 PM, Ian Campbell wrote:


On Fri, 2015-09-11 at 16:18 +0200, Juergen Gross wrote:


On 09/11/2015 04:09 PM, Ian Campbell wrote:


On Fri, 2015-09-11 at 15:55 +0200, Juergen Gross wrote:


On 09/11/2015 03:26 PM, Ian Campbell wrote:


On Thu, 2015-09-10 at 23:42 -0600, Chun Yan Liu wrote:




Do these fields have any particular size requirements arising
from
e.g. the
USB spec or from possible dom0 implementations?

If they have a well defined fixed size from a USB spec then
maybe
we
could
use the appropriate fixed size types?



Di> dn't see the size limitation. In Linux kernel code, busnum
and
devnum (here
'hostbus, hostaddr') are both 'int' type.



Is that a Linux-specific implementation detail or a fundamental
property of
USB? We should be designing the interface around Linux
implementation
details. It seems like something in the USB spec ought to define
precisely
the number of bits in both a bus number and a device address within
that
bus.



The USB spec is only about _the_ bus. How many buses a host can
operate and how they are numbered is outside the USB spec.

Devices are addressed via their ports in the USB protocol. devnum
is a unique index for a device on the bus, the USB protocol
equivalent
is a list of ports of:
- 1 member in case of direct attached devices
- multiple members in case of hubs between bus and device



Thanks for the info. So an "address" in the USB protocol is actually a
"path" and "hostbus" is an implementation dependent shorthand for all
but
the last link in that path.



I'm not sure in which direction you are looking. "address" is a path.
A path is normally a list of ports starting at the host and walking
through all hubs until you reach the device. The "bus" is the root
of that path. So the number of buses the host knows of is the number
of USB host adapters without any hub.



OK, I thought I understood but the above suggests not.

In USB speak, the address is a list of port numbers, which you follow from
the host bus which is the root.

In Linux speak a "bus" is actually each hub along that path.



No. Each hub is just a port which happens to have more ports behind it.


Let me try a worked example and see if I've got it right. Lets take this
topology:

ROOT0
   |-PORT0 +--HUB1
   |-PORT1-,   |-PORT0 -- DEVICE A
   |   `-PORT1 -- DEVICE B
   |
   `--HUB2
   |-PORT0 -- DEVICE C
   `-PORT1 -- HUB3
   |-PORT0 -- DEVICE D
   `-PORT1 -x

ROOT1 -- ... other stuff

In the USB protocol there are two buses corresponding to ROOT0 and ROOT1.

So in the protocol the address of DEVICE D on the bus associated with
ROOT0
is [1,1,0], that is PORT1 on ROOT0 => PORT1 on HUB2 => PORT0 on HUB3.

DEVICE A is [0,0] on the bus associated with ROOT0, similarly.

In the Linux numbering scheme each ROOTn or HUBn is given a bus number,
somewhat arbitrarily (although I'm sure there is a scheme by which they
allocated). So perhaps:

ROOT0==BUS1



Correct.


HUB1==BUS2



No, Just Bus1-Port0 or Bus1:Devnum1


HUB2==BUS2



Bus1-Port1 or Bus1:Devnum2


HUB3==BUS4



Bus1-Port1.Port1 or Bus1:Devnum3


ROOT1==BUS42



Bus2


And in this scheme the address is hostbus+hostaddr, so DEVICE D is [3,0],
that is hostbus==3==HUB3, and port 0. And DEVICE A is [2,0]



Device D: Bus1-Port1.Port1.Port0 or e.g. Bus1:Devnum4
Device A: Bus1-Port0.Port0 or e.g. Bus1:Devnum5


Is that right?


One bus can have up to 31 ports.



So the answer is that hostaddr can be 5 bits?



5*8 (7 hubs and a device at the last level) == 40, that's the 1 trillion
I suggested before. Things are a little bit more complicated. A devnum
in a bus is never assigned twice. So when you plug in a device, it might
get devnum 6. Unplug it and replug it again will lead to devnum 7.


   In theory I think up to 7 cascaded
hubs are possible, but I don't think the resulting theoretical maximum
of about 1 trillion devices on a bus is to be considered. :-)



And this suggests that in principal a Linux hostbus could be 5*7 bits ==
35
bits, maybe. Or at least that any USB address can be encoded in that many
bits.



Busnum can grow to arbitrary values. A new USB bus detected will get a
new bus number. Removing it and adding it again will again use a new
number.


FWIW libusb seems to define these as uint8:

http://libusb.org/static/api-1.0/group__dev.html#gaf2718609d50c8ded2704e4051b3d2925

(I *think* that "bus number" and "device address" correspond to busnum
and devnum...)

Anyone want to look into the Linux source code to find out how big it
will allow busnum / devnum to grow?


drivers/usb/core/hcd.c is using a bitmap to find the next bus number
currently not in use. It's size is USB_MAXBUS which in turn has the
value 64.

choose_devnum() in drivers/usb/core/hub.c is doing a similar job for
device numbers. 

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

[Laszlo Ersek]

On 09/14/15 11:22, Ian Campbell wrote:
> On Fri, 2015-09-11 at 17:28 +0200, Laszlo Ersek wrote:
>>
> [...]
>> For me that's not so clear-cut. OVMF is frequently used as a UEFI
>> development environment (it's better to brick a virtual machine than
>> your physical dev platform...)
> 
> One flip side to this is that people often virtualize in order to continue
> running their older platforms and applications, because upgrading them
> would be difficult for whatever reason.
> 
> There's an obvious tension between that and the desire to use OVMF as a
> development platform, but it seems to me that the developers are the ones
> who can more readily be expected to mess with the defaults.

Good points!

>> , so upstream should embrace new UEFI
>> features reasonably early, unless there are *grave* regressions.
>>
>> One example I named was the properties table feature (new in UEFI-2.5).
>> It would break Windows 7. Given the large number of users running
>> Windows 7 on OVMF (mainly for GPU passthrough), such a regression would
>> be serious.
>>
>> Breaking Debian Wheezy's and BITS's GRUB is also bad, but the former is
>> very old (and has a clear upgrade path)
> 
> Debian Wheezy is not very old, it's only a year older than RHEL7 (May 2013
> vs June 2014) and only a bit older than two years in absolute terms. It is
> also the subject of an LTS effort, which extends its lifetime to 2018.

(*)

> For comparison Windows 7 (which you argue regressing would be serious) was
> released in 2009 and there have been two major Windows releases since then.

(**)

> Given that and with consideration between the desire to run older platforms
> vs. a development environment it seems to me that Debian Wheezy has not yet
> reached the threshold for being ignored or for saying to users "you must
> now upgrade".

I believe I could argue against both (*) and (**), but it would not be
productive. :)

Instead, what matters is the (now) clear, significant user demand for
turning off PcdSetNxForStack by default. I'll send a followup patch for
my series to that end.

And, sorry about the inconvenience the regression may have caused, of
course ;)

Thanks!
Laszlo


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

Re: [Xen-devel] [PATCH v5 7/9] x86/intel_pstate: add a booting param to select the driver to load

[Jan Beulich]

>>> On 14.09.15 at 04:42,  wrote:
> By default, the old P-state driver (acpi-freq) is used. Adding
> "intel_pstate" to the Xen booting param list to enable the
> use of intel_pstate. However, if intel_pstate is enabled on a
> machine which does not support the driver (e.g. Nehalem), the
> old P-state driver will be loaded due to the failure loading of
> intel_pstate.
> 
> Also, adding the intel_pstate booting parameter to
> xen-command-line.markdown.
> 
> Signed-off-by: Wei Wang 
> ---

Was this a resend? Without any note it's unclear whether the earlier
or later one with the same title should be looked at.

Jan


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

Re: [Xen-devel] ANNOUNCEMENT: Xen 4.6 RC3

[Ian Jackson]

Wei Liu writes ("Re: [Xen-devel] ANNOUNCEMENT: Xen 4.6 RC3"):
> On Mon, Sep 14, 2015 at 12:11:47PM +0100, George Dunlap wrote:
> > I realize they all point the same place, but shouldn't we ideally be
> > using xenproject.org rather than xensource.com?  Particularly as the
> > latter hasn't actually existed as an entity for nearly 8 years? :-)
> 
> CC Ian.

"bits.xensource.com" is an akamai service which is being paid for by
Citrix and contains a variety of ... stuff.

I have no idea how much our download bandwidth is, which means I don't
know if we can host our tarballs etc. on xenbits.

Ian.

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

[Xen-devel] [OSSTEST PATCH] cs-bisection-step: Cope with graph-out (testids) containing ( ) etc.

[Ian Jackson]

cr-try-bisect launders / in the testid but relies on other characters
being handled appropriately by cs-bisection-step.  So for example it
can pass

  
graph-out=/home/logs/results/bisect/linux-linus/test-armhf-armhf-xl-arndale.leak-check--basis(8)

But cs-bisection step foolishly assumed that the --graph-out argument
did not contain any shell metacharacters.  Fix this.

Specifically:

 * Change invocations of perl's open to use the 3-argument form
 * Change invocations of system to pass individual arguments rather
   than constructing a shell script fragment and relying on the shell
   to split it up.
 * In particular, in the png processing pipeline, use the "sh -ec
   

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

[Juergen Gross]

On 09/14/2015 01:12 PM, Ian Jackson wrote:

Juergen Gross writes ("Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API"):

On 09/14/2015 12:36 PM, George Dunlap wrote:

Anyone want to look into the Linux source code to find out how big it
will allow busnum / devnum to grow?


drivers/usb/core/hcd.c is using a bitmap to find the next bus number
currently not in use. It's size is USB_MAXBUS which in turn has the
value 64.

choose_devnum() in drivers/usb/core/hub.c is doing a similar job for
device numbers. Here the highest number supported is 127.


We are defining an API, which shouldn't involve this kind of
implementation-grobbling.

At an API level, it seems that this Linux busnum is not documented to
have any particular number or behaviour or range or anything.  We
should use the biggest type we can use conveniently.


Agreed.


Do we need to worry that some bus might have 2^24 unplugs/plugs
(perhaps in some kind of software emulation) and that we need to use a
type which can hold a uint32_t or maybe even a uint64_t ?


uint128_t ? ;-)

I think 24 bits should be more than enough. Nobody will accept such huge
numbers without any need: they are to be used by users.


Juergen


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

Re: [Xen-devel] [PATCH v5 7/9] x86/intel_pstate: add a booting param to select the driver to load

[Wang, Wei W]

On 14/09/2015 19:18,  Jan Beulich wrote:
>>> On 14.09.15 at 04:42,  wrote:
> By default, the old P-state driver (acpi-freq) is used. Adding 
> "intel_pstate" to the Xen booting param list to enable the use of 
> intel_pstate. However, if intel_pstate is enabled on a machine which 
> does not support the driver (e.g. Nehalem), the old P-state driver 
> will be loaded due to the failure loading of intel_pstate.
> 
> Also, adding the intel_pstate booting parameter to 
> xen-command-line.markdown.
> 
> Signed-off-by: Wei Wang 
> ---

> Was this a resend? Without any note it's unclear whether the earlier or later 
> one with the same title should be looked at.

I just didn't see this one appearing in the mailing list, so I re-sent the  
[PATCH v5 7/9] separately. Sorry about the confusion.

Best,
Wei


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

[Xen-devel] [qemu-upstream-4.5-testing test] 61809: regressions - FAIL

[osstest service owner]

flight 61809 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61809/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-vhd9 debian-di-install fail REGR. vs. 60577
 test-amd64-i386-xl-raw9 debian-di-install fail REGR. vs. 60577
 test-amd64-amd64-xl-raw   9 debian-di-install fail REGR. vs. 60577

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-raw  9 debian-di-install fail REGR. vs. 60577
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail blocked in 60577
 test-amd64-i386-libvirt  11 guest-start  fail   like 60577
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 60577

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-i386-xl-qcow2  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass

version targeted for testing:
 qemuuc6dc376c4b5292769582137867d1be6c3960b5c7
baseline version:
 qemuuf74d682ee4878af6a8e943f5f0b595af92b20084

Last test of basis60577  2015-08-04 12:45:54 Z   40 days
Failing since 60964  2015-08-28 09:10:02 Z   17 days4 attempts
Testing same since61618  2015-09-08 12:11:46 Z5 days3 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Peter Lieven 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemuu-rhel6hvm-amd   

Re: [Xen-devel] __XEN_LATEST_INTERFACE_VERSION__ is still 0x00040600 in staging

[Razvan Cojocaru]

On 09/14/2015 03:13 PM, Jan Beulich wrote:
 On 14.09.15 at 13:53,  wrote:
>> I've found this out by accident, since I have some code that does some
>> #ifdef tricks based on __XEN_LATEST_INTERFACE_VERSION__, but while
>> running staging ("Xen version 4.7-unstable") it seems that in
>> xen/xen-compat.h we still have:
>>
>> #define __XEN_LATEST_INTERFACE_VERSION__ 0x00040600
>>
>> Is this intended?
> 
> Was there any incompatible interface change already that would
> have required bumping the value?

None, at least as far as my code is concerned. It's just that I've
already added a new libxc helper function with assorted HV-side code and
just assumed that __XEN_LATEST_INTERFACE_VERSION__ had been bumped to
0x00040700, so some of my own code wasn't being compiled as it depended
on that value. Of course, there's nothing wrong with the current
approach, I was just curious if bumps happen as soon as a new version is
out or only when the interface changes.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

[Daniel Kiper]

On Mon, Sep 14, 2015 at 11:43:27AM +0200, Ard Biesheuvel wrote:
> On 14 September 2015 at 11:25, Mark Rutland  wrote:
> > On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote:
> >> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote:
> >> > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote:
> >> > > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote:
> >>
> >> [...]
> >>
> >> > > > What's troublesome with the boot services?
> >> > > >
> >> > > > What can't be simulated?
> >> > >
> >> > > How do you want to access bare metal EFI boot services from dom0 if 
> >> > > they
> >> > > were shutdown long time ago before loading dom0 image?
> >> >
> >> > I don't want to.
> >> >
> >> > I asked "What can't be simulated?" because I assumed everything
> >> > necessary/mandatory could be simulated without needinng access to any
> >> > real EFI boot services.
> >> >
> >> > As far as I can see all that's necessary is to provide a compatible
> >> > interface.
> >>
> >> Could you be more precise what do you need? Please enumerate. UEFI spec has
> >> more than 2500 pages and I do not think that we need all stuff in dom0.
> >>
> >> > > What do you need from EFI boot services in dom0?
> >> >
> >> > The ability to call ExitBootServices() and SetVirtualAddressMap() on a
> >> > _virtual_ address map for _virtual_ services provided by the hypervisor.
> >>
> >> I am confused. Why do you need that? Please remember, EFI is owned and
> >> operated by Xen hypervisor. dom0 does not have direct access to EFI.
> >
> > Let's take a step back.
> >
> > My objection here is to passing the Dom0 kernel properties as if it were
> > booted with direct access to a full UEFI, then later fixing that up
> > (when Xen is detected and we apply its hypercall EFI implementation).
> >
>
> To be honest, I don't think that has ever been suggested here. What
> was suggested is to provide a minimal EFI like environment that allows
> the post-stub EFI code to proceed and find the ACPI root pointer.
>
> > If the kernel cannot use EFI natively, why pretend to the kernel that it
> > can? The hypercall implementation is _not_ EFI (though it provides
> > access to some services).
> >
>
> To get access to the ACPI root pointer, for which there is only one
> specified way of obtaining it on ARM, which is via the UEFI
> configuration table database
>
> > The two ways I can see providing Dom0 with EFI services are:
> >
> > * Have Xen create shims for any services, in which any hypercalls live,
> >   and pass these to the kernel with a virtual system table. This keeps
> >   the interface to the kernel the same regardless of Xen.
> >
> > * Have the kernel detect Xen EFI capability via Xen, without passing the
> >   usual native EFI parameters. This can then be installed into the
> >   kernel in a Xen-specific manner, and we know from the outset that
> >   Xen-specific caveats apply.
> >
> > As per my original email, I'm not against the renaming of the stub
> > parameters if we standardise the rest of the details, but I believe
> > that's orthogonal to the Xen Dom0 case.
> >
>
> Xen will not boot the kernel via the stub, but directly. It needs to
> supply a EFI like environment so that the kernel can boot via ACPI.
> There is no reason whatsoever to mock up boot services or other pieces
> of UEFI functionality that are not needed. The core kernel does not
> call any boot services or SetVirtualAddressMap/ConvertPointer, and
> there is already paravirtualized plumbing in place for the remaining
> runtime services.
>
> Hence my claim earlier that we should cope with the runtime services
> pointer being NULL, since that is really the only thing standing in

I suppose that you thought about EFI_INVALID_TABLE_ADDR...

> the way from the kernel side. If you feel that violates the spec in

If yes then you should know that dom0 on x86 EFI platform works
with efi.runtime == EFI_INVALID_TABLE_ADDR without any issue.
So, I think that all problems are solved.

Daniel

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

[Xen-devel] [PATCH] xen/arm: correct comment in enlighten.c

[Juergen Gross]

Correct a comment in arch/arm/xen/enlighten.c referencing a wrong
source file.

Signed-off-by: Juergen Gross 
---
 arch/arm/xen/enlighten.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index eeeab07..5421706 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -284,7 +284,7 @@ void xen_arch_resume(void) { }
 void xen_arch_suspend(void) { }
 
 
-/* In the hypervisor.S file. */
+/* In the hypercall.S file. */
 EXPORT_SYMBOL_GPL(HYPERVISOR_event_channel_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_grant_table_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_xen_version);
-- 
2.1.4


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

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

[George Dunlap]

On Mon, Sep 14, 2015 at 4:48 AM, Juergen Gross  wrote:
> On 09/11/2015 04:41 PM, Ian Campbell wrote:
>>
>> On Fri, 2015-09-11 at 16:18 +0200, Juergen Gross wrote:
>>>
>>> On 09/11/2015 04:09 PM, Ian Campbell wrote:

 On Fri, 2015-09-11 at 15:55 +0200, Juergen Gross wrote:
>
> On 09/11/2015 03:26 PM, Ian Campbell wrote:
>>
>> On Thu, 2015-09-10 at 23:42 -0600, Chun Yan Liu wrote:
>>>
>>>
 Do these fields have any particular size requirements arising
 from
 e.g. the
 USB spec or from possible dom0 implementations?

 If they have a well defined fixed size from a USB spec then
 maybe
 we
 could
 use the appropriate fixed size types?
>>>
>>>
>>> Di> dn't see the size limitation. In Linux kernel code, busnum
>>> and
>>> devnum (here
>>> 'hostbus, hostaddr') are both 'int' type.
>>
>>
>> Is that a Linux-specific implementation detail or a fundamental
>> property of
>> USB? We should be designing the interface around Linux
>> implementation
>> details. It seems like something in the USB spec ought to define
>> precisely
>> the number of bits in both a bus number and a device address within
>> that
>> bus.
>
>
> The USB spec is only about _the_ bus. How many buses a host can
> operate and how they are numbered is outside the USB spec.
>
> Devices are addressed via their ports in the USB protocol. devnum
> is a unique index for a device on the bus, the USB protocol
> equivalent
> is a list of ports of:
> - 1 member in case of direct attached devices
> - multiple members in case of hubs between bus and device


 Thanks for the info. So an "address" in the USB protocol is actually a
 "path" and "hostbus" is an implementation dependent shorthand for all
 but
 the last link in that path.
>>>
>>>
>>> I'm not sure in which direction you are looking. "address" is a path.
>>> A path is normally a list of ports starting at the host and walking
>>> through all hubs until you reach the device. The "bus" is the root
>>> of that path. So the number of buses the host knows of is the number
>>> of USB host adapters without any hub.
>>
>>
>> OK, I thought I understood but the above suggests not.
>>
>> In USB speak, the address is a list of port numbers, which you follow from
>> the host bus which is the root.
>>
>> In Linux speak a "bus" is actually each hub along that path.
>
>
> No. Each hub is just a port which happens to have more ports behind it.
>
>> Let me try a worked example and see if I've got it right. Lets take this
>> topology:
>>
>> ROOT0
>>   |-PORT0 +--HUB1
>>   |-PORT1-,   |-PORT0 -- DEVICE A
>>   |   `-PORT1 -- DEVICE B
>>   |
>>   `--HUB2
>>   |-PORT0 -- DEVICE C
>>   `-PORT1 -- HUB3
>>   |-PORT0 -- DEVICE D
>>   `-PORT1 -x
>>
>> ROOT1 -- ... other stuff
>>
>> In the USB protocol there are two buses corresponding to ROOT0 and ROOT1.
>>
>> So in the protocol the address of DEVICE D on the bus associated with
>> ROOT0
>> is [1,1,0], that is PORT1 on ROOT0 => PORT1 on HUB2 => PORT0 on HUB3.
>>
>> DEVICE A is [0,0] on the bus associated with ROOT0, similarly.
>>
>> In the Linux numbering scheme each ROOTn or HUBn is given a bus number,
>> somewhat arbitrarily (although I'm sure there is a scheme by which they
>> allocated). So perhaps:
>>
>> ROOT0==BUS1
>
>
> Correct.
>
>> HUB1==BUS2
>
>
> No, Just Bus1-Port0 or Bus1:Devnum1
>
>> HUB2==BUS2
>
>
> Bus1-Port1 or Bus1:Devnum2
>
>> HUB3==BUS4
>
>
> Bus1-Port1.Port1 or Bus1:Devnum3
>
>> ROOT1==BUS42
>
>
> Bus2
>
>> And in this scheme the address is hostbus+hostaddr, so DEVICE D is [3,0],
>> that is hostbus==3==HUB3, and port 0. And DEVICE A is [2,0]
>
>
> Device D: Bus1-Port1.Port1.Port0 or e.g. Bus1:Devnum4
> Device A: Bus1-Port0.Port0 or e.g. Bus1:Devnum5
>
>> Is that right?
>>
>>> One bus can have up to 31 ports.
>>
>>
>> So the answer is that hostaddr can be 5 bits?
>
>
> 5*8 (7 hubs and a device at the last level) == 40, that's the 1 trillion
> I suggested before. Things are a little bit more complicated. A devnum
> in a bus is never assigned twice. So when you plug in a device, it might
> get devnum 6. Unplug it and replug it again will lead to devnum 7.
>
>>>   In theory I think up to 7 cascaded
>>> hubs are possible, but I don't think the resulting theoretical maximum
>>> of about 1 trillion devices on a bus is to be considered. :-)
>>
>>
>> And this suggests that in principal a Linux hostbus could be 5*7 bits ==
>> 35
>> bits, maybe. Or at least that any USB address can be encoded in that many
>> bits.
>
>
> Busnum can grow to arbitrary values. A new USB bus detected will get a
> new bus number. Removing it and adding it again will again use a new
> number.

FWIW libusb seems to define these as uint8:

Re: [Xen-devel] [PATCH] x86/p2m: fix mismatched unlock

[George Dunlap]

On Mon, Sep 14, 2015 at 8:13 AM, Jan Beulich  wrote:
> Luckily, due to gfn_unlock() currently mapping to p2m_unlock(), this is
> only a cosmetic issue right now.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: George Dunlap 

> ---
> Despite its cosmetic nature I think it would be better to also fix this
> in 4.6.

I agree.

 -George

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

Re: [Xen-devel] [v2][PATCH] xen/vtd/iommu: permit group devices to passthrough in relaxed mode

[Jan Beulich]

>>> On 14.09.15 at 08:24,  wrote:
>>  OK, that explanation is fine to me as long as it's made clear no
>> security guarantee once admin uses 'relax' for any domain. Tiejun
>> could you resend patch with right warning/error type?
>>
> 
> Sure, but a little bit makes me confused when I'm trying to address 
> this. Actually most messages are same, except for logevel, so I did this 
> like,
> 
>  printk(XENLOG_G_INFO VTDPREFIX " Assign %04x:%02x:%02x.%u"
> " with shared RMRR at %"PRIx64" for Dom%d.",
> seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
> rmrr->base_address, d->domain_id);
>  if ( relaxed )
>  printk(XENLOG_G_WARNING VTDPREFIX " It's really risky.");
>  else
>  printk(XENLOG_G_ERR VTDPREFIX " So it's disallowed!");
>  printk(XENLOG_G_INFO VTDPREFIX "\n");
> 
> But looks its not better, so any idea?

Did you at least make an attempt to find other examples of where
we dynamically determine the log level to be used for a message?
I would assume that if you did, you'd have come to

printk(XENLOG_GUEST "%s" VTDPREFIX
   " It's %s to assign %04x:%02x:%02x.%u"
   " with shared RMRR at %"PRIx64" for Dom%d.\n",
   relaxed ? XENLOG_WARNING : XENLOG_ERROR,
   relaxed ? "risky" : "disallowed",
   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
   rmrr->base_address, d->domain_id);

pretty naturally.

Jan


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

Re: [Xen-devel] [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux

[Roger Pau Monné]

Hello,

El 14/09/15 a les 12.40, Julien Grall ha escrit:
> Hi Roger,
> 
> On 14/09/15 09:56, Roger Pau Monné wrote:
>> El 07/09/15 a les 17.33, Julien Grall ha escrit:
>>> Hi all,
>>>
>>> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
>>> hypercall interface and PV protocol are always based on 4KB page 
>>> granularity.
>>>
>>> Any attempt to boot a Linux guest with 64KB pages enabled will result to a
>>> guest crash.
>>>
>>> This series is a first attempt to allow those Linux running with the current
>>> hypercall interface and PV protocol.
>>>
>>> This solution has been chosen because we want to run Linux 64KB in released
>>> Xen ARM version or/and platform using an old version of Linux DOM0.
>>>
>>> There is room for improvement, such as support of 64KB grant, modification
>>> of PV protocol to support different page size... They will be explored in a
>>> separate patch series later.
>>>
>>> TODO list:
>>> - Convert swiotlb to 64KB
>>> - Convert xenfb to 64KB
>>> - Support for multiple page ring support
>>> - Support for 64KB in gnttdev
>>> - Support of non-indirect grant with 64KB frontend
>>> - It may be possible to move some common define between
>>> netback/netfront and blkfront/blkback in an header
>>>
>>> I've got most of the patches for the TODO items. I'm planning to send them 
>>> as
>>> a follow-up as it's not a requirement for a basic guests.
>>>
>>> All patches has been built tested for ARM32, ARM64, x86. But I haven't 
>>> tested
>>> to run it on x86 as I don't have a box with Xen x86 running. I would be
>>> happy if someone give a try and see possible regression for x86.
>>
>> Do you have figures regarding if/how much performance penalty do the
>> blkfront/blkback patches add to the traditional 4KB scenario (frontend
>> and backend running on guests using 4KB pages)?
> 
> Which benchmark do you advice? Although, I don't have SSD on this
> platform so it may be possible that the bottleneck will be the hard drive.

I've normally used a ramdisk in order to test performance, but it seems
nullblk would be a better option (it wasn't available before) and it
doesn't reduce the size of RAM available to the system:

https://www.kernel.org/doc/Documentation/block/null_blk.txt

>>
>> Since there's been no design document about this and the TODO list
>> doesn't contain it, I would like to know which plans do we have in order
>> to fix this properly.
> 
> Can you explain what kind of design document you were expecting? The
> support of 64KB page granularity is pretty straight-forward and there is
> not many way to do it. We have to split the page in 4KB chunk to feed
> the ring.

I was thinking about adding support for 64KB grants with the aim of
eventually removing the splitting done in xen-blkfront and the
grant-table code in general.

Some modifications would be needed in xen-blkback in order to support
mapping 64KB grants, but this could also be used by x86 if we ever
enable 2MB grants and allow them to be used in the block PV protocol,
while the current code can only be used by ARM.

> TBH, I'm expecting a small impact to the performance. It would be hard
> to get the exactly the same performance as today if we keep the helpers
> to avoid the backend dealing himself with the splitting and page
> granularity.
> 
> Although, if the performance impact is not acceptable, it may be
> possible to optimize gnttab_foreach_grant_in_range by moving the
> function inline. The current way to the loop is the fastest I've found
> (I've wrote a small program to test different way) and we will need it
> when different of size will be supported.

I don't expect the performance to drop massively with this patches
applied, but it would be good to al least have an idea of the impact.

Roger.


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

Re: [Xen-devel] ANNOUNCEMENT: Xen 4.6 RC3

[George Dunlap]

On Wed, Sep 9, 2015 at 2:12 PM, Wei Liu  wrote:
> Hi all
>
> Xen 4.6 RC3 has been tagged. You can check out the tag 4.6.0-rc3 in xen.git.
>
> The tarball can be downloaded from:
>
> http://bits.xensource.com/oss-xen/release/4.6.0-rc3/xen-4.6.0-rc3.tar.gz
>
> Signature for tarball:
>
> http://bits.xensource.com/oss-xen/release/4.6.0-rc3/xen-4.6.0-rc3.tar.gz.sig

I realize they all point the same place, but shouldn't we ideally be
using xenproject.org rather than xensource.com?  Particularly as the
latter hasn't actually existed as an entity for nearly 8 years? :-)

 -George

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

Re: [Xen-devel] [PATCH] x86/PoD: use clear_domain_page()

[George Dunlap]

On Mon, Sep 14, 2015 at 11:26 AM, Jan Beulich  wrote:
> Signed-off-by: Jan Beulich 

Acked-by: George Dunlap 

>
> --- a/xen/arch/x86/mm/p2m-pod.c
> +++ b/xen/arch/x86/mm/p2m-pod.c
> @@ -107,11 +107,7 @@ p2m_pod_cache_add(struct p2m_domain *p2m
>   * promise to provide zero pages. So we scrub pages before using.
>   */
>  for ( i = 0; i < (1 << order); i++ )
> -{
> -char *b = map_domain_page(_mfn(mfn_x(page_to_mfn(page)) + i));
> -clear_page(b);
> -unmap_domain_page(b);
> -}
> +clear_domain_page(_mfn(mfn_x(page_to_mfn(page)) + i));
>
>  /* First, take all pages off the domain list */
>  lock_page_alloc(p2m);
>
>
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

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

[Xen-devel] [ovmf test] 61817: regressions - FAIL

[osstest service owner]

flight 61817 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61817/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 60869
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 60869

version targeted for testing:
 ovmf 27b5bf5d4b0b495f40a95aa7cd63bcd5a10c6dc4
baseline version:
 ovmf ba1806251ff8ff695175b92ab5732eadbcd2f72e

Last test of basis60869  2015-08-25 03:03:43 Z   20 days
Failing since 60904  2015-08-27 01:40:43 Z   18 days   11 attempts
Testing same since61817  2015-09-11 21:41:42 Z2 days1 attempts


People who touched revisions under test:
  "Yao, Jiewen" 
  Ard Biesheuvel 
  Cecil Sheng 
  Cecil Sheng 
  Dandan Bi 
  eric Dong 
  Feng Tian 
  Fu Siyuan 
  Gary Ching-Pang Lin 
  Hao Wu 
  Heyi Guo 
  Jeff Fan 
  Jiaxin Wu 
  Jonathan Panozzo 
  Laszlo Ersek 
  Leif Lindholm 
  Liming Gao 
  Masamitsu MURASE 
  Qin Long 
  Qiu Shumin 
  Ruiyu Ni 
  Samer El-Haj-Mahmoud 
  Shifei Lu 
  Star Zeng 
  Sunny Wang 
  Yao, Jiewen 
  Yingke Liu 
  Zhang Lubo 

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



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

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

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

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


Not pushing.

(No revision log; it would be 2237 lines long.)

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

Re: [Xen-devel] [PATCH v6 00/31] Add ITS support

[Vijay Kilari]

On Mon, Sep 14, 2015 at 4:39 PM, Julien Grall  wrote:
> Hi Vijay,
>
> On 14/09/15 12:00, Vijay Kilari wrote:
>> I will take care of A & B in next revision.
>>
>> Is there any further comments on this series?. I have not received
>> any comments on last few patches (patch #25 to patch#30).
>
> I haven't commented the rest of the series because I'm expecting to see
> the remaining patches change after the comment related the LPI property
> table in patch #24.
>
> Actually, even in patch #24 I had some comments but I'm delaying them
> until the main one is fixed.

Ok. Expecting no further review on v6, I will send next revision.

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

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

[Ard Biesheuvel]

On 14 September 2015 at 14:28, Daniel Kiper  wrote:
> On Mon, Sep 14, 2015 at 11:43:27AM +0200, Ard Biesheuvel wrote:
>> On 14 September 2015 at 11:25, Mark Rutland  wrote:
>> > On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote:
>> >> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote:
>> >> > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote:
>> >> > > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote:
>> >>
>> >> [...]
>> >>
>> >> > > > What's troublesome with the boot services?
>> >> > > >
>> >> > > > What can't be simulated?
>> >> > >
>> >> > > How do you want to access bare metal EFI boot services from dom0 if 
>> >> > > they
>> >> > > were shutdown long time ago before loading dom0 image?
>> >> >
>> >> > I don't want to.
>> >> >
>> >> > I asked "What can't be simulated?" because I assumed everything
>> >> > necessary/mandatory could be simulated without needinng access to any
>> >> > real EFI boot services.
>> >> >
>> >> > As far as I can see all that's necessary is to provide a compatible
>> >> > interface.
>> >>
>> >> Could you be more precise what do you need? Please enumerate. UEFI spec 
>> >> has
>> >> more than 2500 pages and I do not think that we need all stuff in dom0.
>> >>
>> >> > > What do you need from EFI boot services in dom0?
>> >> >
>> >> > The ability to call ExitBootServices() and SetVirtualAddressMap() on a
>> >> > _virtual_ address map for _virtual_ services provided by the hypervisor.
>> >>
>> >> I am confused. Why do you need that? Please remember, EFI is owned and
>> >> operated by Xen hypervisor. dom0 does not have direct access to EFI.
>> >
>> > Let's take a step back.
>> >
>> > My objection here is to passing the Dom0 kernel properties as if it were
>> > booted with direct access to a full UEFI, then later fixing that up
>> > (when Xen is detected and we apply its hypercall EFI implementation).
>> >
>>
>> To be honest, I don't think that has ever been suggested here. What
>> was suggested is to provide a minimal EFI like environment that allows
>> the post-stub EFI code to proceed and find the ACPI root pointer.
>>
>> > If the kernel cannot use EFI natively, why pretend to the kernel that it
>> > can? The hypercall implementation is _not_ EFI (though it provides
>> > access to some services).
>> >
>>
>> To get access to the ACPI root pointer, for which there is only one
>> specified way of obtaining it on ARM, which is via the UEFI
>> configuration table database
>>
>> > The two ways I can see providing Dom0 with EFI services are:
>> >
>> > * Have Xen create shims for any services, in which any hypercalls live,
>> >   and pass these to the kernel with a virtual system table. This keeps
>> >   the interface to the kernel the same regardless of Xen.
>> >
>> > * Have the kernel detect Xen EFI capability via Xen, without passing the
>> >   usual native EFI parameters. This can then be installed into the
>> >   kernel in a Xen-specific manner, and we know from the outset that
>> >   Xen-specific caveats apply.
>> >
>> > As per my original email, I'm not against the renaming of the stub
>> > parameters if we standardise the rest of the details, but I believe
>> > that's orthogonal to the Xen Dom0 case.
>> >
>>
>> Xen will not boot the kernel via the stub, but directly. It needs to
>> supply a EFI like environment so that the kernel can boot via ACPI.
>> There is no reason whatsoever to mock up boot services or other pieces
>> of UEFI functionality that are not needed. The core kernel does not
>> call any boot services or SetVirtualAddressMap/ConvertPointer, and
>> there is already paravirtualized plumbing in place for the remaining
>> runtime services.
>>
>> Hence my claim earlier that we should cope with the runtime services
>> pointer being NULL, since that is really the only thing standing in
>
> I suppose that you thought about EFI_INVALID_TABLE_ADDR...
>

Simply whatever we decide, so perhaps EFI_INVALID_TABLE_ADDR is better
if x86 uses that already. But that value is still outside of the UEFI
spec, so in that sense, it is not more appropriate than NULL.

>> the way from the kernel side. If you feel that violates the spec in
>
> If yes then you should know that dom0 on x86 EFI platform works
> with efi.runtime == EFI_INVALID_TABLE_ADDR without any issue.
> So, I think that all problems are solved.
>

So there is precedent, which is good. But please note that x86 has a
lot of baggage and *lots* of quirks for buggy firmware that was only
ever tested with Windows. So before blindly copying x86 when it comes
to UEFI interworking, we still need to have the discussion whether
what x86 is appropriate for ARM as well (since it does not have the
above problems)

-- 
Ard.

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

Re: [Xen-devel] [PATCH] x86/PoD: use clear_domain_page()

[Andrew Cooper]

On 14/09/15 11:26, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] ANNOUNCEMENT: Xen 4.6 RC3

[Wei Liu]

On Mon, Sep 14, 2015 at 12:11:47PM +0100, George Dunlap wrote:
> On Wed, Sep 9, 2015 at 2:12 PM, Wei Liu  wrote:
> > Hi all
> >
> > Xen 4.6 RC3 has been tagged. You can check out the tag 4.6.0-rc3 in xen.git.
> >
> > The tarball can be downloaded from:
> >
> > http://bits.xensource.com/oss-xen/release/4.6.0-rc3/xen-4.6.0-rc3.tar.gz
> >
> > Signature for tarball:
> >
> > http://bits.xensource.com/oss-xen/release/4.6.0-rc3/xen-4.6.0-rc3.tar.gz.sig
> 
> I realize they all point the same place, but shouldn't we ideally be
> using xenproject.org rather than xensource.com?  Particularly as the
> latter hasn't actually existed as an entity for nearly 8 years? :-)
> 

CC Ian.

>  -George

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

Re: [Xen-devel] __XEN_LATEST_INTERFACE_VERSION__ is still 0x00040600 in staging

[Jan Beulich]

>>> On 14.09.15 at 13:53,  wrote:
> I've found this out by accident, since I have some code that does some
> #ifdef tricks based on __XEN_LATEST_INTERFACE_VERSION__, but while
> running staging ("Xen version 4.7-unstable") it seems that in
> xen/xen-compat.h we still have:
> 
> #define __XEN_LATEST_INTERFACE_VERSION__ 0x00040600
> 
> Is this intended?

Was there any incompatible interface change already that would
have required bumping the value?

Jan


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

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

[Daniel Kiper]

On Mon, Sep 14, 2015 at 10:25:19AM +0100, Mark Rutland wrote:
> On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote:
> > On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote:
> > > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote:
> > > > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote:
> >
> > [...]
> >
> > > > > What's troublesome with the boot services?
> > > > >
> > > > > What can't be simulated?
> > > >
> > > > How do you want to access bare metal EFI boot services from dom0 if they
> > > > were shutdown long time ago before loading dom0 image?
> > >
> > > I don't want to.
> > >
> > > I asked "What can't be simulated?" because I assumed everything
> > > necessary/mandatory could be simulated without needinng access to any
> > > real EFI boot services.
> > >
> > > As far as I can see all that's necessary is to provide a compatible
> > > interface.
> >
> > Could you be more precise what do you need? Please enumerate. UEFI spec has
> > more than 2500 pages and I do not think that we need all stuff in dom0.
> >
> > > > What do you need from EFI boot services in dom0?
> > >
> > > The ability to call ExitBootServices() and SetVirtualAddressMap() on a
> > > _virtual_ address map for _virtual_ services provided by the hypervisor.
> >
> > I am confused. Why do you need that? Please remember, EFI is owned and
> > operated by Xen hypervisor. dom0 does not have direct access to EFI.
>
> Let's take a step back.
>
> My objection here is to passing the Dom0 kernel properties as if it were
> booted with direct access to a full UEFI, then later fixing that up
> (when Xen is detected and we apply its hypercall EFI implementation).
>
> If the kernel cannot use EFI natively, why pretend to the kernel that it
> can? The hypercall implementation is _not_ EFI (though it provides
> access to some services).
>
> The two ways I can see providing Dom0 with EFI services are:
>
> * Have Xen create shims for any services, in which any hypercalls live,
>   and pass these to the kernel with a virtual system table. This keeps
>   the interface to the kernel the same regardless of Xen.
>
> * Have the kernel detect Xen EFI capability via Xen, without passing the
>   usual native EFI parameters. This can then be installed into the
>   kernel in a Xen-specific manner, and we know from the outset that
>   Xen-specific caveats apply.

It works on x86 in that way and I suppose that it can work in that way on ARM 
too.
So, just go and reuse existing code. That is all.

Daniel

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

[Xen-devel] [Patch V2] xen: use correct type for HYPERVISOR_memory_op()

[Juergen Gross]

HYPERVISOR_memory_op() is defined to return an "int" value. This is
wrong, as the Xen hypervisor will return "long".

The sub-function XENMEM_maximum_reservation returns the maximum
number of pages for the current domain. An int will overflow for a
domain configured with 8TB of memory or more.

Correct this by using the correct type.

Signed-off-by: Juergen Gross 
---
V2: change arm header as well to keep it in sync with x86
(requested by Julien Grall)
---
 arch/arm/include/asm/xen/hypercall.h | 2 +-
 arch/x86/include/asm/xen/hypercall.h | 4 ++--
 arch/x86/xen/setup.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h 
b/arch/arm/include/asm/xen/hypercall.h
index 712b50e..47f0d81 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -45,7 +45,7 @@ int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, 
unsigned int count);
 int HYPERVISOR_sched_op(int cmd, void *arg);
 int HYPERVISOR_event_channel_op(int cmd, void *arg);
 unsigned long HYPERVISOR_hvm_op(int op, void *arg);
-int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
+long HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
 int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
 int HYPERVISOR_tmem_op(void *arg);
diff --git a/arch/x86/include/asm/xen/hypercall.h 
b/arch/x86/include/asm/xen/hypercall.h
index 83aea80..4c20dd3 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -336,10 +336,10 @@ HYPERVISOR_update_descriptor(u64 ma, u64 desc)
return _hypercall4(int, update_descriptor, ma, ma>>32, desc, desc>>32);
 }
 
-static inline int
+static inline long
 HYPERVISOR_memory_op(unsigned int cmd, void *arg)
 {
-   return _hypercall2(int, memory_op, cmd, arg);
+   return _hypercall2(long, memory_op, cmd, arg);
 }
 
 static inline int
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index f5ef674..4ebfcec 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -548,7 +548,7 @@ static unsigned long __init xen_get_max_pages(void)
 {
unsigned long max_pages, limit;
domid_t domid = DOMID_SELF;
-   int ret;
+   long ret;
 
limit = xen_get_pages_limit();
max_pages = limit;
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v6 00/31] Add ITS support

[Vijay Kilari]

On Wed, Sep 9, 2015 at 8:59 PM, Ian Campbell  wrote:
> On Mon, 2015-08-31 at 16:36 +0530, vijay.kil...@gmail.com wrote:
>>  Some Major TODOs:
>>1) Avoid making vits_process_cmd() static in later point of time
>>2) How to handle LPI that does not have LPI config table entry.
>>3) Enable/disable ITS to Dom0
>
> I'm not quite sure what any of these 3 are, can you expand upon them
> please.
>
> Major TODOs I can think of (which may overlap those above which I don't
> understand):
>
>A. Ensuring that no aspect of the vITS is exposed to domains other than
>   dom0, so no mapping, no GICR registers relating to LPIs or ITS etc.
>B. A bug fat warning in the code vits_map_translation_space about the
>   issues with exposing this to dom0.
>C. The issue regarding what to do with physical LPIs which arrive before
>   the guest has mapped the corresponding event in the vits or which is
>   masked
>
> Have I missed anything?
>
> I think A and B are pretty straight forward to fix.
>
> C I think is a bit thornier, and IIRC we do not currently have a plan for
> how we can address this in a generic way. I think we might have some ideas
> which work only for PCI devices (or maybe only PCI-e devices?).
>
> Ian.

I will take care of A & B in next revision.

Is there any further comments on this series?. I have not received
any comments on last few patches (patch #25 to patch#30).

>
>
>>
>> Changes in v5:
>>   - Added following new patches
>>   0001-xen-arm-Return-success-if-dt-node-does-not-have-irq-.patch
>>   0004-xen-arm-Set-nr_cpu_ids-to-available-number-of-cpus.patch
>>   0009-xen-arm-ITS-Export-ITS-info-to-Virtual-ITS.patch
>>   0013-xen-arm-ITS-Implement-gic_is_lpi-helper-function.patch
>>   - Split patch #12 into two patches #14 & #16
>>   0014-xen-arm-ITS-Allocate-irq-descriptors-for-LPIs.patch
>>   0016-xen-arm-ITS-Route-LPIs.patch
>>   - Introduce new API to route LPI (route_lpi_to_guest() )
>>   - Moved patch #8 in v4 as patch #19
>>   - irq_descritors for LPIs are allocated dynamically
>>   - Removed RB-tree for managing vitual its devices. Will be
>> introduced when pci-passthrough is implemented
>>   - its_add_device() api now takes nr_ites and DT its node as parameters
>>   - some function are kept as non-static when introduced in a patch for
>> compilation purpose and eventually made static when used.
>>   - Tested compilation for arm32
>>
>> Changes in v4:
>>   - Patch for rate limiting of error message is removed.
>>   - Patch #4 and #5 in v3 is merged
>>   - Merged #13 and #16 as one patch
>>   - hw_irq_controller is implemented for LPIs
>>   - GITS and GICR emulation for LPIs in separate patches
>>   - Removed build functions for ITS command in physical ITS driver
>>   - Added new patch to add and assign devices from platform file
>>   - Enable compilation of vits and pits driver in separate patch
>>   - Replace msi-parent property in all pci dt nodes to single
>> ITS node generated by Xen for Dom0
>>
>> Vijaya Kumar K (31):
>>   xen/dt: Handle correctly node with interrupt-map in
>> dt_for_each_irq_map
>>   xen/arm: Add bitmap_find_next_zero_area helper function
>>   xen: Add log2 functionality
>>   xen/arm: Set nr_cpu_ids to available number of cpus
>>   xen/arm: Rename NR_IRQs and vgic_num_irqs helper function
>>   xen/arm: ITS: Port ITS driver to Xen
>>   xen/arm: ITS: Add helper functions to manage its_devices
>>   xen/arm: ITS: Introduce msi_desc for LPIs
>>   xen/arm: ITS: Add APIs to add and assign device
>>   xen/arm: ITS: Introduce gic_is_lpi helper function
>>   xen/arm: ITS: Enable compilation of physical ITS driver
>>   xen/arm: Move vgic locking inside get_irq_priority callback
>>   xen/arm: ITS: implement hw_irq_controller for LPIs
>>   xen/arm: ITS: Initialize physical ITS and export lpi support
>>   xen/arm: ITS: Add virtual ITS driver
>>   xen/arm: ITS: Add virtual ITS commands support
>>   xen/arm: ITS: Store LPIs allocated and IRQ ID bits per domain
>>   xen/arm: ITS: Enable virtual ITS driver
>>   xen/arm: ITS: Export ITS info to Virtual ITS
>>   xen/arm: ITS: Introduce helper to get number of event IDs
>>   xen/arm: ITS: Add GITS registers emulation
>>   xen/arm: ITS: Add virtual ITS availability check helper
>>   xen/arm: ITS: Add 32-bit access to GICR_TYPER
>>   xen/arm: ITS: Add GICR register emulation
>>   xen/arm: ITS: Allocate irq descriptors for LPIs
>>   xen/arm: ITS: Allocate pending_lpi descriptors for LPIs
>>   xen/arm: ITS: Route LPIs
>>   xen/arm: ITS: Add domain specific ITS initialization
>>   xen/arm: ITS: Map ITS translation space
>>   xen/arm: ITS: Generate ITS node for Dom0
>>   xen/arm: ITS: Add pci devices in ThunderX
>>
>>  xen/arch/arm/Makefile |2 +
>>  xen/arch/arm/domain_build.c   |   11 +
>>  xen/arch/arm/gic-hip04.c  |   19 +-
>>  xen/arch/arm/gic-v2.c |   19 +-
>>  xen/arch/arm/gic-v3-its.c | 1594
>> 

[Xen-devel] [OSSTEST PATCH] Executive: Abolish use of the `configdb'

[Ian Jackson]

This was a database used by networking infrastructure on the
now-obsolete XenClient network in the Citrix Cambridge office (which
used some management tools developed by Mythic Beasts).

The production database in Cambridge no longer has the configdb, and
both instances have `HostDB_Executive_NoConfigDB 1' in the
configuration.  We think it very unlikely that anyone has as similar
arrangement.

Remove all the code for accessing this database.  We leave the config
settings `NoConfigDB' for now, for the benefit of ad-hoc trees which
are not immediately updated but which use their site's official
production-config.  They can be deleted later.

Signed-off-by: Ian Jackson 
---
 Osstest/HostDB/Executive.pm |   30 ++
 1 file changed, 2 insertions(+), 28 deletions(-)

diff --git a/Osstest/HostDB/Executive.pm b/Osstest/HostDB/Executive.pm
index 3fa9982..3e5eca2 100644
--- a/Osstest/HostDB/Executive.pm
+++ b/Osstest/HostDB/Executive.pm
@@ -98,34 +98,8 @@ END
 sub default_methods ($$) {
 my ($hd, $ho) = @_;
 
-return if $ho->{Flags}{'no-reinstall'};
-return if $ho->{Ether} && $ho->{Power};
-
-return if $c{HostDB_Executive_NoConfigDB};
-
-my $dbh_config= opendb('configdb');
-my $selname= $ho->{Fqdn};
-my $sth= $dbh_config->prepare(<execute($selname);
-my $row= $sth->fetchrow_hashref();
-my $name= $ho->{Name};
-die "$ho->{Ident} $name $selname ?" unless $row;
-die if $sth->fetchrow_hashref();
-$sth->finish();
-my $get= sub {
-   my ($k,$nowarn) = @_;
-   my $v= $row->{$k};
-   defined $v or $nowarn or
-   warn "host $name: undefined $k in configdb::ips\n";
-   return $v;
-};
-$ho->{Asset}= $get->('asset',1);
-$ho->{Ether} ||= $get->('hardware');
-$ho->{Power} ||= "statedb $ho->{Asset}";
-push @{ $ho->{Info} }, "(asset=$ho->{Asset})" if defined $ho->{Asset};
-$dbh_config->disconnect();
+# We used to look things up in the Mythic Beasts style configdb
+# here.  But that is gone now.
 }
 
 1;
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH v2] arm/xen: Enable user access to the kernel before issuing a privcmd call

[Stefano Stabellini]

On Mon, 14 Sep 2015, Russell King - ARM Linux wrote:
> On Mon, Sep 14, 2015 at 10:36:55AM +0100, Stefano Stabellini wrote:
> > On Fri, 11 Sep 2015, Russell King - ARM Linux wrote:
> > > If you'd like your ack on it, please send one, I can still do that.
> > 
> > Acked-by: Stefano Stabellini 
> 
> Sorry, that's a bit too late - I sent Linus the pull request on Saturday,
> but it missed the -rc1 release... still waiting for Linus to pull it.

No worries, thanks for letting me know.

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

Re: [Xen-devel] [OSSTEST PATCH] Executive: Abolish use of the `configdb'

[Ian Campbell]

On Mon, 2015-09-14 at 11:59 +0100, Ian Jackson wrote:
> This was a database used by networking infrastructure on the
> now-obsolete XenClient network in the Citrix Cambridge office (which
> used some management tools developed by Mythic Beasts).
> 
> The production database in Cambridge no longer has the configdb, and
> both instances have `HostDB_Executive_NoConfigDB 1' in the
> configuration.  We think it very unlikely that anyone has as similar
> arrangement.
> 
> Remove all the code for accessing this database.  We leave the config
> settings `NoConfigDB' for now, for the benefit of ad-hoc trees which
> are not immediately updated but which use their site's official
> production-config.  They can be deleted later.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

[Ard Biesheuvel]

On 14 September 2015 at 12:39, Jan Beulich  wrote:
 On 14.09.15 at 11:36,  wrote:
>> On 14 September 2015 at 11:31, Shannon Zhao  wrote:
>>> My understanding is that if there are no EFI_MEMORY_RUNTIME regions, it
>>> means we can't use runtime services and should not set the bit
>>> EFI_RUNTIME_SERVICES of efi.flags. But if efi_virtmap_init() return
>>> true, the bit will be set.
>>>
>>
>> As I said, if you don't want the EFI_RUNTIME_SERVICES bit to be set
>> for other reasons, don't rig efi_virtmap_init() to return false when
>> it shouldn't.
>>
 The absence of such regions is allowed by the spec, so
 efi_virtmap_init() is correct imo to return success.

>>> Sorry, not well know about the spec. Could you point out where the spec
>>> says this?
>>>
>>
>> Well, I think it doesn't work that way. You are claiming that a memory
>> map without at least one EFI_MEMORY_RUNTIME constitutes an error
>> condition, so the burden is on you to provide a reference to the spec
>> that says you must have at least one such region.
>
> Sure, from a spec pov you're right. But where would runtime
> services code/data live when there's not a single region marked
> as needing a runtime mapping. IOW while the spec doesn't say
> so, assuming no runtime services when there's not at least one
> executable region with the runtime flag set could serve as a stop
> gap measure against flawed firmware.
>

That in itself is a fair point. But the argument being made was that
it is in itself a bug for no EFI_MEMORY_RUNTIME regions to exist,
while the actual purpose of the patch is to prevent the
RuntimeServices pointer from being dereferenced on platforms like Xen
that may not be able to implement them.

But actually, even in case of Xen, you will need some
EFI_MEMORY_RUNTIME regions anyway, since the f/w vendor field and the
config and runtime services table pointers are translated to virtual
addresses by the firmware, which means the OS needs to translate them
back to physical addresses in order to dereference them before the VA
mapping is up. (I still think not using SetVirtualAddressMap() at all
would be the best approach for arm64, but unfortunately, most of my
colleagues disagree with me)

-- 
Ard.

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

Re: [Xen-devel] ANNOUNCEMENT: Xen 4.6 RC3

[Ian Campbell]

On Mon, 2015-09-14 at 12:13 +0100, Wei Liu wrote:
> On Mon, Sep 14, 2015 at 12:11:47PM +0100, George Dunlap wrote:
> > On Wed, Sep 9, 2015 at 2:12 PM, Wei Liu  wrote:
> > > Hi all
> > > 
> > > Xen 4.6 RC3 has been tagged. You can check out the tag 4.6.0-rc3 in
> > > xen.git.
> > > 
> > > The tarball can be downloaded from:
> > > 
> > > http://bits.xensource.com/oss-xen/release/4.6.0-rc3/xen-4.6.0-rc3.tar
> > > .gz
> > > 
> > > Signature for tarball:
> > > 
> > > http://bits.xensource.com/oss-xen/release/4.6.0-rc3/xen-4.6.0-rc3.tar
> > > .gz.sig
> > 
> > I realize they all point the same place, but shouldn't we ideally be
> > using xenproject.org rather than xensource.com?  Particularly as the
> > latter hasn't actually existed as an entity for nearly 8 years? :-)

$ wget http://bits.xenproject.org/oss-xen/release/4.6.0-rc3/xen-4.6.0-rc3.tar.gz
--2015-09-14 12:21:18--  
http://bits.xenproject.org/oss-xen/release/4.6.0-rc3/xen-4.6.0-rc3.tar.gz
Resolving bits.xenproject.org (bits.xenproject.org)... failed: Name or service 
not known.
wget: unable to resolve host address ‘bits.xenproject.org’

(nor bits.xen.org, FWIW)

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

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

Re: [Xen-devel] [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux

[Julien Grall]

On 14/09/15 12:04, Roger Pau Monné wrote:
> Hello,
> 
> El 14/09/15 a les 12.40, Julien Grall ha escrit:
>> Hi Roger,
>>
>> On 14/09/15 09:56, Roger Pau Monné wrote:
>>> El 07/09/15 a les 17.33, Julien Grall ha escrit:
 Hi all,

 ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
 hypercall interface and PV protocol are always based on 4KB page 
 granularity.

 Any attempt to boot a Linux guest with 64KB pages enabled will result to a
 guest crash.

 This series is a first attempt to allow those Linux running with the 
 current
 hypercall interface and PV protocol.

 This solution has been chosen because we want to run Linux 64KB in released
 Xen ARM version or/and platform using an old version of Linux DOM0.

 There is room for improvement, such as support of 64KB grant, modification
 of PV protocol to support different page size... They will be explored in a
 separate patch series later.

 TODO list:
 - Convert swiotlb to 64KB
 - Convert xenfb to 64KB
 - Support for multiple page ring support
 - Support for 64KB in gnttdev
 - Support of non-indirect grant with 64KB frontend
 - It may be possible to move some common define between
 netback/netfront and blkfront/blkback in an header

 I've got most of the patches for the TODO items. I'm planning to send them 
 as
 a follow-up as it's not a requirement for a basic guests.

 All patches has been built tested for ARM32, ARM64, x86. But I haven't 
 tested
 to run it on x86 as I don't have a box with Xen x86 running. I would be
 happy if someone give a try and see possible regression for x86.
>>>
>>> Do you have figures regarding if/how much performance penalty do the
>>> blkfront/blkback patches add to the traditional 4KB scenario (frontend
>>> and backend running on guests using 4KB pages)?
>>
>> Which benchmark do you advice? Although, I don't have SSD on this
>> platform so it may be possible that the bottleneck will be the hard drive.
> 
> I've normally used a ramdisk in order to test performance, but it seems
> nullblk would be a better option (it wasn't available before) and it
> doesn't reduce the size of RAM available to the system:
> 
> https://www.kernel.org/doc/Documentation/block/null_blk.txt

I will give a look to this.

>>>
>>> Since there's been no design document about this and the TODO list
>>> doesn't contain it, I would like to know which plans do we have in order
>>> to fix this properly.
>>
>> Can you explain what kind of design document you were expecting? The
>> support of 64KB page granularity is pretty straight-forward and there is
>> not many way to do it. We have to split the page in 4KB chunk to feed
>> the ring.
> 
> I was thinking about adding support for 64KB grants with the aim of
> eventually removing the splitting done in xen-blkfront and the
> grant-table code in general.

I'd like to see a basic support of 64KB page granularity upstream before
starting to think about performance improvement. And there is still a
lot to do.

Although, having 64KB grants won't remove the splitting as we would
still have to support frontend/backend which only handle 4KB grant.


>> TBH, I'm expecting a small impact to the performance. It would be hard
>> to get the exactly the same performance as today if we keep the helpers
>> to avoid the backend dealing himself with the splitting and page
>> granularity.
>>
>> Although, if the performance impact is not acceptable, it may be
>> possible to optimize gnttab_foreach_grant_in_range by moving the
>> function inline. The current way to the loop is the fastest I've found
>> (I've wrote a small program to test different way) and we will need it
>> when different of size will be supported.
> 
> I don't expect the performance to drop massively with this patches
> applied, but it would be good to al least have an idea of the impact.

I will only be able to give percentage. I guess this would be sufficient
for you?

Regards,

-- 
Julien Grall

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

[Xen-devel] __XEN_LATEST_INTERFACE_VERSION__ is still 0x00040600 in staging

[Razvan Cojocaru]

Hello,

I've found this out by accident, since I have some code that does some
#ifdef tricks based on __XEN_LATEST_INTERFACE_VERSION__, but while
running staging ("Xen version 4.7-unstable") it seems that in
xen/xen-compat.h we still have:

#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040600

Is this intended?


Thanks,
Razvan

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

[Xen-devel] [PATCH] libxc: remove useless stuff from domain builder

[Juergen Gross]

Remove unused fields from the domain builder and associated functions.

Signed-off-by: Juergen Gross 
---
 tools/libxc/include/xc_dom.h  | 2 --
 tools/python/xen/lowlevel/xc/xc.c | 8 ++--
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6192fba..5731098 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -132,7 +132,6 @@ struct xc_dom_image {
 xen_pfn_t total_pages;
 xen_pfn_t p2m_size; /* number of pfns covered by p2m */
 struct xc_dom_phys *phys_pages;
-int realmodearea_log;
 #if defined (__arm__) || defined(__aarch64__)
 xen_pfn_t rambank_size[GUEST_RAM_BANKS];
 #endif
@@ -157,7 +156,6 @@ struct xc_dom_image {
 
 xc_interface *xch;
 domid_t guest_domid;
-int8_t vhpt_size_log2; /* for IA64 */
 int8_t superpages;
 int claim_enabled; /* 0 by default, 1 enables it */
 int shadow_enabled;
diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index 9ab53fb..668e875 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -463,7 +463,6 @@ static PyObject *pyxc_linux_build(XcObject *self,
 char *image, *ramdisk = NULL, *cmdline = "", *features = NULL;
 int flags = 0;
 int store_evtchn, console_evtchn;
-int vhpt = 0;
 int superpages = 0;
 unsigned int mem_mb;
 unsigned long store_mfn = 0;
@@ -477,23 +476,20 @@ static PyObject *pyxc_linux_build(XcObject *self,
 "console_evtchn", "image",
 /* optional */
 "ramdisk", "cmdline", "flags",
-"features", "vhpt", "superpages", NULL };
+"features", "superpages", NULL };
 
 if ( !PyArg_ParseTupleAndKeywords(args, kwds, "s|ssisii", kwd_list,
   , _evtchn, _mb,
   _evtchn, ,
   /* optional */
   , , ,
-  , , ) )
+  , ) )
 return NULL;
 
 xc_dom_loginit(self->xc_handle);
 if (!(dom = xc_dom_allocate(self->xc_handle, cmdline, features)))
 return pyxc_error_to_exception(self->xc_handle);
 
-/* for IA64 */
-dom->vhpt_size_log2 = vhpt;
-
 dom->superpages = superpages;
 
 if ( xc_dom_linux_build(self->xc_handle, dom, domid, mem_mb, image,
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux

[Julien Grall]

Hi Roger,

On 14/09/15 09:56, Roger Pau Monné wrote:
> El 07/09/15 a les 17.33, Julien Grall ha escrit:
>> Hi all,
>>
>> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
>> hypercall interface and PV protocol are always based on 4KB page granularity.
>>
>> Any attempt to boot a Linux guest with 64KB pages enabled will result to a
>> guest crash.
>>
>> This series is a first attempt to allow those Linux running with the current
>> hypercall interface and PV protocol.
>>
>> This solution has been chosen because we want to run Linux 64KB in released
>> Xen ARM version or/and platform using an old version of Linux DOM0.
>>
>> There is room for improvement, such as support of 64KB grant, modification
>> of PV protocol to support different page size... They will be explored in a
>> separate patch series later.
>>
>> TODO list:
>> - Convert swiotlb to 64KB
>> - Convert xenfb to 64KB
>> - Support for multiple page ring support
>> - Support for 64KB in gnttdev
>> - Support of non-indirect grant with 64KB frontend
>> - It may be possible to move some common define between
>> netback/netfront and blkfront/blkback in an header
>>
>> I've got most of the patches for the TODO items. I'm planning to send them as
>> a follow-up as it's not a requirement for a basic guests.
>>
>> All patches has been built tested for ARM32, ARM64, x86. But I haven't tested
>> to run it on x86 as I don't have a box with Xen x86 running. I would be
>> happy if someone give a try and see possible regression for x86.
> 
> Do you have figures regarding if/how much performance penalty do the
> blkfront/blkback patches add to the traditional 4KB scenario (frontend
> and backend running on guests using 4KB pages)?

Which benchmark do you advice? Although, I don't have SSD on this
platform so it may be possible that the bottleneck will be the hard drive.

> 
> Since there's been no design document about this and the TODO list
> doesn't contain it, I would like to know which plans do we have in order
> to fix this properly.

Can you explain what kind of design document you were expecting? The
support of 64KB page granularity is pretty straight-forward and there is
not many way to do it. We have to split the page in 4KB chunk to feed
the ring.

TBH, I'm expecting a small impact to the performance. It would be hard
to get the exactly the same performance as today if we keep the helpers
to avoid the backend dealing himself with the splitting and page
granularity.

Although, if the performance impact is not acceptable, it may be
possible to optimize gnttab_foreach_grant_in_range by moving the
function inline. The current way to the loop is the fastest I've found
(I've wrote a small program to test different way) and we will need it
when different of size will be supported.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

[Laszlo Ersek]

On 09/12/15 01:06, Josh Triplett wrote:
> On Fri, Sep 11, 2015 at 11:27:32PM +0200, Laszlo Ersek wrote:
>> On 09/11/15 21:30, Josh Triplett wrote:
>>> On Fri, Sep 11, 2015 at 05:28:06PM +0200, Laszlo Ersek wrote:
 Breaking Debian Wheezy's and BITS's GRUB is also bad, but the former is
 very old (and has a clear upgrade path), while the latter is mainly used
 by developers (who can learn about the -fw_cfg switch by googling or
 asking on the least without huge trouble). In this case I'm leaning
 towards OVMF being "bleeding edge" by default. But, I could be convinced
 otherwise.
>>>
>>> I certainly think it makes sense for OVMF to adopt the feature sooner
>>> than normal, and I agree that OVMF serves as a test case.  But going
>>> directly from "not possible to turn on" to "turned on by default",
>>> without any period of "off by default but possible to turn on", seems a
>>> bit unfortunate.
>>>
>>> That said, we could certainly fix BITS to use newer GRUB2, and use
>>> (and document) -fw_cfg in the meantime.  So I won't push *too* hard for
>>> changing the default, just mildly.
>>
>> Okay. If I'll need to send a v2 for any reason, I'll incorporate this.
>> If not, then I can post a followup patch later (stating that it's due to
>> community feedback).
> 
> Thanks!
> 
>>> On a vaguely related note, what's the canonical place to report bugs in
>>> OVMF?
>>
>> (Bugs? What bugs? :))
>>
>> It's this list, .
> 
> There isn't a tracker of some kind?  That's unfortunate.

I won't disagree with you, but I'll note three things:

(1) There isn't much use to a bug tracker if there aren't enough human
resources to actually monitor that tracker, and work hard on the bugs. I
can offer to monitor this list and work on bugs reported here the best I
can. Bug fixing is hard and taxing; for *official* long-term bug
tracking, some form of legal relationship is usually necessary. I do
take my RHBZs very seriously.

(2) OvmfPkg is one platform in edk2. I don't think OVMF / OvmfPkg should
have its own separate tracker. And regarding a tracker for the entirety
of edk2, there used to be one (still on sf.net), and nobody (no
contributor or maintainer) cared. Goto (1).

(3) I've seen first hand how Fedora bug tracker entries, Debian bug
tracker entries, and upstream QEMU bug tracker entries are handled. Goto
(1). As I said, I try to do my best with bugs reported on the list, both
in tracking them and in fixing them, as my load allows.

> But thanks; I'll send mail to the list when we discover an issue while
> experimenting with BITS.

Yes, please do that. And thank you. In my experience, other package
maintainers (not just us in OvmfPkg) are pretty responsive if you report
bugs for their packages on the list, especially if you can narrow it
down (bisection, good reproducer etc).

> 
> (Also, if you don't intend to use github's issue tracker, you might want
> to turn it off so people don't file things there and expect a response.)

That's a very good point. Jordan, can you please disable the issue
tracker on github?

Thanks
Laszlo

> 
> - Josh Triplett
> 


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

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

[Jan Beulich]

>>> On 14.09.15 at 13:16,  wrote:
> (I still think not using SetVirtualAddressMap() at all
> would be the best approach for arm64, but unfortunately, most of my
> colleagues disagree with me)

Any reasons they have? I'm curious because we run x86 Xen without
using this function ...

Jan


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

Re: [Xen-devel] [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux

[Arnd Bergmann]

On Monday 14 September 2015 13:04:59 Roger Pau Monné wrote:
> > TBH, I'm expecting a small impact to the performance. It would be hard
> > to get the exactly the same performance as today if we keep the helpers
> > to avoid the backend dealing himself with the splitting and page
> > granularity.
> > 
> > Although, if the performance impact is not acceptable, it may be
> > possible to optimize gnttab_foreach_grant_in_range by moving the
> > function inline. The current way to the loop is the fastest I've found
> > (I've wrote a small program to test different way) and we will need it
> > when different of size will be supported.
> 
> I don't expect the performance to drop massively with this patches
> applied, but it would be good to al least have an idea of the impact.

Note that using 64kb pages in Linux tends to destroy performance
in Linux in any case, as the memory consumption for most workloads
explodes. In a virtualized environment you already tend to be
memory constrained, so any measurement should take that into account
and put the extra overhead into perspective to the massive overhead
of running 64kb pages when RAM is tight.

Arnd

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

Re: [Xen-devel] Dom0 crash with apache bench (ab)

[Christoffer Dall]

On Fri, Jul 31, 2015 at 03:17:56PM +0200, Christoffer Dall wrote:
> On Fri, Jul 31, 2015 at 12:28 PM, David Vrabel 
> wrote:
> 
> > On 31/07/15 11:24, Stefano Stabellini wrote:
> > > This is a Linux Dom0 crash on x86 (Dell PowerEdge R320, Xeon E5-2450),
> > > CC'ing relevant people. As you can see from the links below the crash
> > > is:
> > >
> > > [ 253.619326] Call Trace:
> > > [ 253.619330] 
> > > [ 253.619332] [] ? skb_copy_ubufs+0xa5/0x230
> > > [ 253.619347] [] __netif_receive_skb_core+0x6f5/0x940
> > > [ 253.619353] [] __netif_receive_skb+0x18/0x60
> > > [ 253.619360] [] netif_receive_skb_internal+0x28/0x90
> > > [ 253.619366] [] napi_gro_frags+0x125/0x1a0
> > > [ 253.619378] [] mlx4_en_process_rx_cq+0x753/0xb50
> > [mlx4_en]
> > > [ 253.619387] [] mlx4_en_poll_rx_cq+0x97/0x160
> > [mlx4_en]
> >
> > What makes you think this is Xen specific?  I suggest raising this the
> > the mlx4 maintainers.
> >
> >
> Linux native and KVM guests (same hw, same kernel version+config) run just
> fine under the same workload.
> 
Ping?

>From the fact that bare-metal and KVM works fine with this hardware I
still think it's reasonable to assume that it's a Xen issue and not a
mlx4 issue.

Is this completely flawed?

Thanks,
-Christoffer

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

Re: [Xen-devel] [PATCH] xen: use correct type for HYPERVISOR_memory_op()

[Juergen Gross]

Ping?

On 09/04/2015 02:50 PM, Juergen Gross wrote:

HYPERVISOR_memory_op() is defined to return an "int" value. This is
wrong, as the Xen hypervisor will return "long".

The sub-function XENMEM_maximum_reservation returns the maximum
number of pages for the current domain. An int will overflow for a
domain configured with 8TB of memory or more.

Correct this by using the correct type.

Signed-off-by: Juergen Gross 
---
  arch/x86/include/asm/xen/hypercall.h | 4 ++--
  arch/x86/xen/setup.c | 2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/xen/hypercall.h 
b/arch/x86/include/asm/xen/hypercall.h
index ca08a27..b7a735f 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -336,10 +336,10 @@ HYPERVISOR_update_descriptor(u64 ma, u64 desc)
return _hypercall4(int, update_descriptor, ma, ma>>32, desc, desc>>32);
  }

-static inline int
+static inline long
  HYPERVISOR_memory_op(unsigned int cmd, void *arg)
  {
-   return _hypercall2(int, memory_op, cmd, arg);
+   return _hypercall2(long, memory_op, cmd, arg);
  }

  static inline int
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index f5ef674..4ebfcec 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -548,7 +548,7 @@ static unsigned long __init xen_get_max_pages(void)
  {
unsigned long max_pages, limit;
domid_t domid = DOMID_SELF;
-   int ret;
+   long ret;

limit = xen_get_pages_limit();
max_pages = limit;




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

Re: [Xen-devel] [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux

[Julien Grall]

On 14/09/15 13:08, Roger Pau Monné wrote:
>> I'd like to see a basic support of 64KB page granularity upstream before
>> starting to think about performance improvement. And there is still a
>> lot to do.
> 
> I wasn't actually thinking of this as a performance improvement, but
> rather as a way of fixing this properly and removing the complexity
> added to xen-blkfront, thus providing a PV block protocol that natively
> supports 64KB pages. This would be like hardware components already do
> AFAIK, because I don't think there are other drivers in the Linux tree
> that do this kind of splitting.
> 
>> Although, having 64KB grants won't remove the splitting as we would
>> still have to support frontend/backend which only handle 4KB grant.
> 
> IMHO, given enough time I would just drop those.

The PV protocol has always been backward compatible.

Introducing the support of 64KB grant will require some changes in Xen
which won't surely be backported to older version. We still have to be
able to run new Linux guest on older Xen and vice versa.

To give you an example, Centos 7, which will support Xen and only 64KB
page granularity, will be supported for years. Dropping any splitting in
a short future (3-5 years) will just break those guests to boot on Xen.

AFAIK, we never took a such radical decision on Xen based on the
complexity of the code.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

[Ian Jackson]

Juergen Gross writes ("Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API"):
> On 09/14/2015 12:36 PM, George Dunlap wrote:
> > Anyone want to look into the Linux source code to find out how big it
> > will allow busnum / devnum to grow?
> 
> drivers/usb/core/hcd.c is using a bitmap to find the next bus number
> currently not in use. It's size is USB_MAXBUS which in turn has the
> value 64.
> 
> choose_devnum() in drivers/usb/core/hub.c is doing a similar job for
> device numbers. Here the highest number supported is 127.

We are defining an API, which shouldn't involve this kind of
implementation-grobbling.

At an API level, it seems that this Linux busnum is not documented to
have any particular number or behaviour or range or anything.  We
should use the biggest type we can use conveniently.

Do we need to worry that some bus might have 2^24 unplugs/plugs
(perhaps in some kind of software emulation) and that we need to use a
type which can hold a uint32_t or maybe even a uint64_t ?

Ian.

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

Re: [Xen-devel] [PATCH v6 00/31] Add ITS support

[Julien Grall]

Hi Vijay,

On 14/09/15 12:00, Vijay Kilari wrote:
> I will take care of A & B in next revision.
> 
> Is there any further comments on this series?. I have not received
> any comments on last few patches (patch #25 to patch#30).

I haven't commented the rest of the series because I'm expecting to see
the remaining patches change after the comment related the LPI property
table in patch #24.

Actually, even in patch #24 I had some comments but I'm delaying them
until the main one is fixed.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux

[Roger Pau Monné]

El 14/09/15 a les 13.21, Julien Grall ha escrit:
> On 14/09/15 12:04, Roger Pau Monné wrote:
>> Hello,
>>
>> El 14/09/15 a les 12.40, Julien Grall ha escrit:
>>> Hi Roger,
>>>
>>> On 14/09/15 09:56, Roger Pau Monné wrote:
 El 07/09/15 a les 17.33, Julien Grall ha escrit:
> Hi all,
>
> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, 
> Xen
> hypercall interface and PV protocol are always based on 4KB page 
> granularity.
>
> Any attempt to boot a Linux guest with 64KB pages enabled will result to a
> guest crash.
>
> This series is a first attempt to allow those Linux running with the 
> current
> hypercall interface and PV protocol.
>
> This solution has been chosen because we want to run Linux 64KB in 
> released
> Xen ARM version or/and platform using an old version of Linux DOM0.
>
> There is room for improvement, such as support of 64KB grant, modification
> of PV protocol to support different page size... They will be explored in 
> a
> separate patch series later.
>
> TODO list:
> - Convert swiotlb to 64KB
> - Convert xenfb to 64KB
> - Support for multiple page ring support
> - Support for 64KB in gnttdev
> - Support of non-indirect grant with 64KB frontend
> - It may be possible to move some common define between
> netback/netfront and blkfront/blkback in an header
>
> I've got most of the patches for the TODO items. I'm planning to send 
> them as
> a follow-up as it's not a requirement for a basic guests.
>
> All patches has been built tested for ARM32, ARM64, x86. But I haven't 
> tested
> to run it on x86 as I don't have a box with Xen x86 running. I would be
> happy if someone give a try and see possible regression for x86.

 Do you have figures regarding if/how much performance penalty do the
 blkfront/blkback patches add to the traditional 4KB scenario (frontend
 and backend running on guests using 4KB pages)?
>>>
>>> Which benchmark do you advice? Although, I don't have SSD on this
>>> platform so it may be possible that the bottleneck will be the hard drive.
>>
>> I've normally used a ramdisk in order to test performance, but it seems
>> nullblk would be a better option (it wasn't available before) and it
>> doesn't reduce the size of RAM available to the system:
>>
>> https://www.kernel.org/doc/Documentation/block/null_blk.txt
> 
> I will give a look to this.
> 

 Since there's been no design document about this and the TODO list
 doesn't contain it, I would like to know which plans do we have in order
 to fix this properly.
>>>
>>> Can you explain what kind of design document you were expecting? The
>>> support of 64KB page granularity is pretty straight-forward and there is
>>> not many way to do it. We have to split the page in 4KB chunk to feed
>>> the ring.
>>
>> I was thinking about adding support for 64KB grants with the aim of
>> eventually removing the splitting done in xen-blkfront and the
>> grant-table code in general.
> 
> I'd like to see a basic support of 64KB page granularity upstream before
> starting to think about performance improvement. And there is still a
> lot to do.

I wasn't actually thinking of this as a performance improvement, but
rather as a way of fixing this properly and removing the complexity
added to xen-blkfront, thus providing a PV block protocol that natively
supports 64KB pages. This would be like hardware components already do
AFAIK, because I don't think there are other drivers in the Linux tree
that do this kind of splitting.

> Although, having 64KB grants won't remove the splitting as we would
> still have to support frontend/backend which only handle 4KB grant.

IMHO, given enough time I would just drop those.

>>> TBH, I'm expecting a small impact to the performance. It would be hard
>>> to get the exactly the same performance as today if we keep the helpers
>>> to avoid the backend dealing himself with the splitting and page
>>> granularity.
>>>
>>> Although, if the performance impact is not acceptable, it may be
>>> possible to optimize gnttab_foreach_grant_in_range by moving the
>>> function inline. The current way to the loop is the fastest I've found
>>> (I've wrote a small program to test different way) and we will need it
>>> when different of size will be supported.
>>
>> I don't expect the performance to drop massively with this patches
>> applied, but it would be good to al least have an idea of the impact.
> 
> I will only be able to give percentage. I guess this would be sufficient
> for you?

Well, absolute numbers together with the standard deviation are IMHO the
best way to provide those figures (ie: see ministat(1) output for
example), but percentages should also be fine.

I'm just interested in knowing the performance difference between having
this patches applied or not when using 

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

[Ian Campbell]

On Mon, 2015-09-14 at 13:07 +0200, Laszlo Ersek wrote:
> Debian Wheezy is not very old, it's only a year older than RHEL7 (May
> > 2013
> > vs June 2014) and only a bit older than two years in absolute terms. It is
> > also the subject of an LTS effort, which extends its lifetime to 2018.
> 
> (*)
> 
> > For comparison Windows 7 (which you argue regressing would be serious) was
> > released in 2009 and there have been two major Windows releases since then.
> 
> (**)
> 
> > Given that and with consideration between the desire to run older platforms
> > vs. a development environment it seems to me that Debian Wheezy has not yet
> > reached the threshold for being ignored or for saying to users "you must
> > now upgrade".
> 
> I believe I could argue against both (*) and (**), but it would not be
> productive. :)

Yes, I'm sure we could be here until the cows come home to roost ;-)

> Instead, what matters is the (now) clear, significant user demand for
> turning off PcdSetNxForStack by default. I'll send a followup patch for
> my series to that end.

Thanks.

> And, sorry about the inconvenience the regression may have caused, of
> course ;)

No need to apologise, it was an experiment worth performing IMHO.

Ian.

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

Re: [Xen-devel] [PATCH] xen: use correct type for HYPERVISOR_memory_op()

[Julien Grall]

Hi Juergen,

On 04/09/15 13:50, Juergen Gross wrote:
> HYPERVISOR_memory_op() is defined to return an "int" value. This is
> wrong, as the Xen hypervisor will return "long".
> 
> The sub-function XENMEM_maximum_reservation returns the maximum
> number of pages for the current domain. An int will overflow for a
> domain configured with 8TB of memory or more.
> 
> Correct this by using the correct type.

Can you also fix the ARM version of the prototype
(arm/include/asm/xen/hypercall.h) in order to keep them in sync?

Regards,

> Signed-off-by: Juergen Gross 
> ---
>  arch/x86/include/asm/xen/hypercall.h | 4 ++--
>  arch/x86/xen/setup.c | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/hypercall.h 
> b/arch/x86/include/asm/xen/hypercall.h
> index ca08a27..b7a735f 100644
> --- a/arch/x86/include/asm/xen/hypercall.h
> +++ b/arch/x86/include/asm/xen/hypercall.h
> @@ -336,10 +336,10 @@ HYPERVISOR_update_descriptor(u64 ma, u64 desc)
>   return _hypercall4(int, update_descriptor, ma, ma>>32, desc, desc>>32);
>  }
>  
> -static inline int
> +static inline long
>  HYPERVISOR_memory_op(unsigned int cmd, void *arg)
>  {
> - return _hypercall2(int, memory_op, cmd, arg);
> + return _hypercall2(long, memory_op, cmd, arg);
>  }
>  
>  static inline int
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index f5ef674..4ebfcec 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -548,7 +548,7 @@ static unsigned long __init xen_get_max_pages(void)
>  {
>   unsigned long max_pages, limit;
>   domid_t domid = DOMID_SELF;
> - int ret;
> + long ret;
>  
>   limit = xen_get_pages_limit();
>   max_pages = limit;
> 


-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v3 1/4] x86: Support enable CDP by boot parameter and add get CDP status

[Jan Beulich]

>>> On 14.09.15 at 05:27,  wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -21,9 +21,16 @@
>  
>  #define PSR_CMT(1<<0)
>  #define PSR_CAT(1<<1)
> +#define PSR_CDP(1<<2)
>  
>  struct psr_cat_cbm {
> -uint64_t cbm;
> +union {
> +uint64_t cbm;
> +struct {
> +uint64_t code;
> +uint64_t data;
> +} cdp;
> +} u;

While in the public interfaces use of gcc extensions is not allowed
without very special care, please make use of such in internal
headers when that helps readability (as well as in the case patch
size): No need to name the union member of the outer structure.

> @@ -490,13 +519,33 @@ static void cat_cpu_init(void)
>  info->cos_to_cbm = temp_cos_to_cbm;
>  temp_cos_to_cbm = NULL;
>  /* cos=0 is reserved as default cbm(all ones). */
> -info->cos_to_cbm[0].cbm = (1ull << info->cbm_len) - 1;
> +info->cos_to_cbm[0].u.cbm = (1ull << info->cbm_len) - 1;
>  
>  spin_lock_init(>cbm_lock);
>  
>  set_bit(socket, cat_socket_enable);
> -printk(XENLOG_INFO "CAT: enabled on socket %u, cos_max:%u, 
> cbm_len:%u\n",
> -   socket, info->cos_max, info->cbm_len);

I fail to see a replacement for this message.

> +if ( (ecx & PSR_CAT_CDP_CAPABILITY) && (opt_psr & PSR_CDP) )
> +{
> +if ( test_bit(socket, cdp_socket_enable) )
> +return;

This will make future changes more cumbersome, especially if one
would not require CDP as a prereq. Please fold the two if()s,
allowing execution to progress past the outer if() in all cases.

> +rdmsrl(MSR_IA32_PSR_L3_QOS_CFG, val);
> +wrmsrl(MSR_IA32_PSR_L3_QOS_CFG, val | 1 << 
> PSR_L3_QOS_CDP_ENABLE_BIT);

Missing parentheses around the <<.

> +info->cos_to_cbm[0].u.cdp.code = (1ull << info->cbm_len) - 1;
> +info->cos_to_cbm[0].u.cdp.data = (1ull << info->cbm_len) - 1;
> +
> +/* We only write mask1 since mask0 is always all ones by default 
> */
> +wrmsrl(MSR_IA32_PSR_L3_MASK(1), (1ull << info->cbm_len) - 1);
> +
> +/* Cut half of cos_max when CDP enabled */
> +info->cos_max = info->cos_max / 2;

Please use /= or >>=.

> @@ -535,8 +588,9 @@ static void __init init_psr_cat(void)
>  
>  cat_socket_enable = xzalloc_array(unsigned long, 
> BITS_TO_LONGS(nr_sockets));
>  cat_socket_info = xzalloc_array(struct psr_cat_socket_info, nr_sockets);
> +cdp_socket_enable = xzalloc_array(unsigned long, 
> BITS_TO_LONGS(nr_sockets));
>  
> -if ( !cat_socket_enable || !cat_socket_info )
> +if ( !cat_socket_enable || !cat_socket_info || !cdp_socket_enable )
>  psr_cat_free();

No - just disable CDP if only that third allocation fails.

> --- a/xen/include/asm-x86/msr-index.h
> +++ b/xen/include/asm-x86/msr-index.h
> @@ -328,7 +328,10 @@
>  #define MSR_IA32_CMT_EVTSEL  0x0c8d
>  #define MSR_IA32_CMT_CTR 0x0c8e
>  #define MSR_IA32_PSR_ASSOC   0x0c8f
> +#define MSR_IA32_PSR_L3_QOS_CFG  0x0c81
>  #define MSR_IA32_PSR_L3_MASK(n)  (0x0c90 + (n))
> +#define MSR_IA32_PSR_L3_MASK_CODE(n) (0x0c90 + (n * 2 + 1))
> +#define MSR_IA32_PSR_L3_MASK_DATA(n) (0x0c90 + (n * 2))

Please always fully parenthesize uses of macro parameters (in fact
the parentheses you have could simply be moved to isolate just n).

> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -704,6 +704,8 @@ struct xen_sysctl_psr_cat_op {
>  struct {
>  uint32_t cbm_len;   /* OUT: CBM length */
>  uint32_t cos_max;   /* OUT: Maximum COS */
> +#define XEN_SYSCTL_PSR_CAT_L3_CDP   (1u << 0)
> +uint32_t flags; /* OUT: CAT flags */
>  } l3_info;

Even if only mildly incompatible, any interface change to sysctl (or
domctl) should make sure the respective interface version got
bumped after branching the previous release tree.

Jan

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

[Xen-devel] [PATCH] xen/keyhandler: Rework keyhandler infrastructure

[Andrew Cooper]

struct keyhandler does not contain much information, and requires a lot
of boilerplate to use.  It is far more convenient to have
register_keyhandler() take each piece of information a parameter,
especially when introducing temporary debugging keyhandlers.

This in turn allows struct keyhandler itself to become private to
keyhandler.c and for the key_table to become more efficient.

key_table doesn't need to contain 256 entries; all keys are ASCII
which limits them to 7 bits of index, rather than 8.  It can also
become a straight array, rather than an array of pointers.  struct
keyhandler itself can become smaller simply via reordering (losing 6
bytes of implicit padding).  The overall effect of this is the
key_table grows in size by 50%, but there are no longer 24-byte
keyhandler structures all over the data section.

All of the key_table entries in keyhandler.c can be initialised at
compile time rather than runtime.

Signed-off-by: Andrew Cooper 
CC: Jan Beulich 
CC: Keir Fraser 

---

Note: I have avoided CC'ing all maintainers as this is largely a mechanical
change across the whole codebase.  Most non-mechanical changes are in common
code, but there is a trivial externing change
xen/drivers/passthrough/vtd/extern.h as previously the struct keyhandler was
in a different translation unit to the function it referenced.

Further reduction in the size of the key_table could be achieved by
dropping the first 0x20 entries corresponding to ASCII control
characters, and by hiding the two boolean fields in the low-order bits
of the function pointer, but both of these feel like too much effort
for too little gain.
---
 xen/arch/x86/acpi/cpu_idle.c |8 +-
 xen/arch/x86/hvm/irq.c   |8 +-
 xen/arch/x86/hvm/svm/vmcb.c  |8 +-
 xen/arch/x86/hvm/vmx/vmcs.c  |8 +-
 xen/arch/x86/io_apic.c   |7 +-
 xen/arch/x86/irq.c   |8 +-
 xen/arch/x86/mm/p2m-ept.c|8 +-
 xen/arch/x86/mm/shadow/common.c  |   14 +--
 xen/arch/x86/msi.c   |8 +-
 xen/arch/x86/nmi.c   |   15 +--
 xen/arch/x86/numa.c  |8 +-
 xen/arch/x86/time.c  |8 +-
 xen/common/event_channel.c   |8 +-
 xen/common/grant_table.c |9 +-
 xen/common/kexec.c   |7 +-
 xen/common/keyhandler.c  |  199 --
 xen/common/page_alloc.c  |   16 +--
 xen/common/timer.c   |8 +-
 xen/drivers/char/console.c   |   16 +--
 xen/drivers/passthrough/amd/iommu_intr.c |9 +-
 xen/drivers/passthrough/iommu.c  |8 +-
 xen/drivers/passthrough/pci.c|8 +-
 xen/drivers/passthrough/vtd/extern.h |2 +-
 xen/drivers/passthrough/vtd/iommu.c  |2 +-
 xen/drivers/passthrough/vtd/utils.c  |8 +-
 xen/include/xen/keyhandler.h |   49 +++-
 26 files changed, 124 insertions(+), 333 deletions(-)

diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 15fe2e9..d1f99a7 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -334,15 +334,9 @@ static void dump_cx(unsigned char key)
 print_acpi_power(cpu, processor_powers[cpu]);
 }
 
-static struct keyhandler dump_cx_keyhandler = {
-.diagnostic = 1,
-.u.fn = dump_cx,
-.desc = "dump ACPI Cx structures"
-};
-
 static int __init cpu_idle_key_init(void)
 {
-register_keyhandler('c', _cx_keyhandler);
+register_keyhandler('c', dump_cx, "dump ACPI Cx structures", 1);
 return 0;
 }
 __initcall(cpu_idle_key_init);
diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index 50fcf73..990a2ca 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -527,15 +527,9 @@ static void dump_irq_info(unsigned char key)
 rcu_read_unlock(_read_lock);
 }
 
-static struct keyhandler dump_irq_info_keyhandler = {
-.diagnostic = 1,
-.u.fn = dump_irq_info,
-.desc = "dump HVM irq info"
-};
-
 static int __init dump_irq_info_key_init(void)
 {
-register_keyhandler('I', _irq_info_keyhandler);
+register_keyhandler('I', dump_irq_info, "dump HVM irq info", 1);
 return 0;
 }
 __initcall(dump_irq_info_key_init);
diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index b5d7165..9ea014f 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -303,15 +303,9 @@ static void vmcb_dump(unsigned char ch)
 printk("**\n");
 }
 
-static struct keyhandler vmcb_dump_keyhandler = {
-.diagnostic = 1,
-.u.fn = vmcb_dump,
-.desc = "dump AMD-V VMCBs"
-};
-
 void __init setup_vmcb_dump(void)
 {
-register_keyhandler('v', _dump_keyhandler);
+register_keyhandler('v', vmcb_dump, "dump AMD-V VMCBs", 1);

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

[George Dunlap]

On Mon, Sep 14, 2015 at 12:12 PM, Ian Jackson  wrote:
> Juergen Gross writes ("Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API"):
>> On 09/14/2015 12:36 PM, George Dunlap wrote:
>> > Anyone want to look into the Linux source code to find out how big it
>> > will allow busnum / devnum to grow?
>>
>> drivers/usb/core/hcd.c is using a bitmap to find the next bus number
>> currently not in use. It's size is USB_MAXBUS which in turn has the
>> value 64.
>>
>> choose_devnum() in drivers/usb/core/hub.c is doing a similar job for
>> device numbers. Here the highest number supported is 127.
>
> We are defining an API, which shouldn't involve this kind of
> implementation-grobbling.
>
> At an API level, it seems that this Linux busnum is not documented to
> have any particular number or behaviour or range or anything.  We
> should use the biggest type we can use conveniently
>
> Do we need to worry that some bus might have 2^24 unplugs/plugs
> (perhaps in some kind of software emulation) and that we need to use a
> type which can hold a uint32_t or maybe even a uint64_t ?

libusb is already a published API that supports uint8, or up to 255.
Following their lead seems like a reasonable thing to do.  If ever
that number goes above 255, basically every Linux program that touches
a USB device will need to be recompiled with a new version of libusb.

Is there any reason for Linux to go above 255?  Things I can think of:

1. Users have more than 255 devices plugged into the same bus.

2. A security / confusion issue due to devnum reuse when users plug
and unplug devices hundreds of times.

Both of these seem pretty unlikely.

I would personally go with uint8, but int16 or int32 certainly won't hurt.

 -George

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

Re: [Xen-devel] [PATCH v3 2/4] x86: add domctl cmd to set/get CDP code/data CBM

[Jan Beulich]

>>> On 14.09.15 at 05:27,  wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -288,14 +288,39 @@ int psr_get_cat_l3_info(unsigned int socket, uint32_t 
> *cbm_len,
>  return 0;
>  }
>  
> -int psr_get_l3_cbm(struct domain *d, unsigned int socket, uint64_t *cbm)
> +int psr_get_l3_cbm(struct domain *d, unsigned int socket,
> +   uint64_t *cbm, enum cbm_type type)
>  {
>  struct psr_cat_socket_info *info = get_cat_socket_info(socket);
> +bool_t cdp_enabled = test_bit(socket, cdp_socket_enable);
>  
>  if ( IS_ERR(info) )
>  return PTR_ERR(info);
>  
> -*cbm = info->cos_to_cbm[d->arch.psr_cos_ids[socket]].u.cbm;
> +if ( type == PSR_CBM_TYPE_L3 && cdp_enabled )
> +return -EXDEV;
> +
> +if ( (type == PSR_CBM_TYPE_L3_CODE || type == PSR_CBM_TYPE_L3_DATA)
> +&& !cdp_enabled )
> +return -EXDEV;

These checks really ought to go into the subsequent switch(). But
then I wonder why asking for code or data would be wrong when
!cdp_enabled? You could simple return the same mask for all three
variants in that case.

> +switch ( type )
> +{
> +case PSR_CBM_TYPE_L3:
> +*cbm = info->cos_to_cbm[d->arch.psr_cos_ids[socket]].u.cbm;
> +break;
> +
> +case PSR_CBM_TYPE_L3_CODE:
> +*cbm = info->cos_to_cbm[d->arch.psr_cos_ids[socket]].u.cdp.code;
> +break;
> +
> +case PSR_CBM_TYPE_L3_DATA:
> +*cbm = info->cos_to_cbm[d->arch.psr_cos_ids[socket]].u.cdp.data;
> +break;
> +
> +default:
> +return -EINVAL;

Considering that this is a helper function and "type" comes from a
caller inside the hypervisor, I'd really like to see an
ASSERT_UNREACHABLE() here.

> @@ -369,10 +394,53 @@ static int write_l3_cbm(unsigned int socket, unsigned 
> int cos,
>  return 0;
>  }
>  
> -int psr_set_l3_cbm(struct domain *d, unsigned int socket, uint64_t cbm)
> +static int find_cos(struct psr_cat_cbm *map, int cos_max,
> +uint64_t cbm_code, uint64_t cbm_data, bool_t cdp_enabled)
>  {
> -unsigned int old_cos, cos;
> -struct psr_cat_cbm *map, *found = NULL;
> +unsigned int cos;
> +
> +if ( !cdp_enabled )
> +{
> +for ( cos = 0; cos <= cos_max; cos++ )
> +if ( map[cos].ref && map[cos].u.cbm == cbm_code )
> +return cos;
> +}
> +else
> +{
> +for ( cos = 0; cos <= cos_max; cos++ )
> +if ( map[cos].ref && map[cos].u.cdp.code == cbm_code &&
> + map[cos].u.cdp.data == cbm_data )
> +return cos;
> +}

I think having just a single loop here with a suitable conditional
expression inside the if() would both shrink code size and allow
the compiler to produce better (smaller) code.

> +static int pick_avail_cos(struct psr_cat_cbm *map, int cos_max, int old_cos)
> +{
> +int cos;

In the function right above "cos" was unsigned int, which I think
is the correct type (also for "old_cos" and "cos_max").

> +int psr_set_l3_cbm(struct domain *d, unsigned int socket,
> +   uint64_t cbm, enum cbm_type type)
> +{
> +unsigned int old_cos, cos_max;
> +int cos, ret;

Whereas here I can see why it should be plain int.

> @@ -381,53 +449,79 @@ int psr_set_l3_cbm(struct domain *d, unsigned int 
> socket, uint64_t cbm)
>  if ( !psr_check_cbm(info->cbm_len, cbm) )
>  return -EINVAL;
>  
> +if ( !cdp_enabled && (type == PSR_CBM_TYPE_L3_CODE ||
> +type == PSR_CBM_TYPE_L3_DATA) )
> +return -EINVAL;
> +
> +cos_max = info->cos_max;
>  old_cos = d->arch.psr_cos_ids[socket];
>  map = info->cos_to_cbm;
>  
> -spin_lock(>cbm_lock);
>  
> -for ( cos = 0; cos <= info->cos_max; cos++ )
> +switch( type )
>  {
> -/* If still not found, then keep unused one. */
> -if ( !found && cos != 0 && map[cos].ref == 0 )
> -found = map + cos;
> -else if ( map[cos].u.cbm == cbm )
> -{
> -if ( unlikely(cos == old_cos) )
> -{
> -ASSERT(cos == 0 || map[cos].ref != 0);
> -spin_unlock(>cbm_lock);
> -return 0;
> -}
> -found = map + cos;
> +case PSR_CBM_TYPE_L3:
> +cbm_code = cbm;
> +cbm_data = cbm;

Wrong indentation.

>  break;
> -}
> -}
>  
> -/* If old cos is referred only by the domain, then use it. */
> -if ( !found && map[old_cos].ref == 1 )
> -found = map + old_cos;
> +case PSR_CBM_TYPE_L3_CODE:
> +cbm_code = cbm;
> +cbm_data = map[old_cos].u.cdp.data;
> +break;
>  
> -if ( !found )
> -{
> -spin_unlock(>cbm_lock);
> -return -EOVERFLOW;
> +case PSR_CBM_TYPE_L3_DATA:
> +cbm_code = map[old_cos].u.cdp.code;
> +cbm_data = cbm;
> +break;
> 

Re: [Xen-devel] [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux

[Stefano Stabellini]

On Mon, 14 Sep 2015, Roger Pau Monné wrote:
> IMHO this splitting is just a workaround for the fact that we don't have
> a 64KB PV block protocol, and this is the real problem that should be
> solved.

64K is a pure one guest kernel configuration option, not a platform wide
option. The hypervisor interfaces are still the same, the ABI is the
same and all the other guests are still the same, the Xen binary is
still the same.

A 64K block protocol could be a good performance imprevement, but should
not be required to run kernels which have different config options.


> In the long term this will put a burden on all blkfronts (if 64KB pages
> are also used by other OSes), while introducing a 64KB PV block protocol
> will make the blkfront implementation in all OSes very similar to what
> we have now, without replicating the splitting code amongst all the
> possible blkfront implementations.
>
> Granted that some changes to blkback will be needed in order to support
> mapping 64KB grants, but there are much fewer blkback implementations
> out there than blkfronts.

I don't think we can rely on blkback having something in order to run
new guests, otherwise we break compatibility: new guests won't run on
old hypervisors.___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH for 4.6] x86/mm: make {set, clear}_identity_p2m_mapping() work for HVM guests as well

[Andrew Cooper]

From: Malcolm Crossley 

For Intel IGD passthrough, the guest driver programs the device to DMA
to/from its RMRR.

c/s 619ecf8 "make {set,clear}_identity_p2m_mapping() work for PV guests"
was incomplete for pre-Broadwell systems which did not support shared
EPT.

The correct check to use is iommu_use_hap_pt() not
paging_mode_translate() as IOMMU mappings also need to be created for
HVM guests with separate EPT and IOMMU tables.

Signed-off-by: Malcolm Crossley 
Signed-off-by: Andrew Cooper 
CC: Jan Beulich 
CC: George Dunlap 
CC: Wei Liu 
---
 xen/arch/x86/mm/p2m.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index c4329d2..c7f437c 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -957,7 +957,7 @@ int set_identity_p2m_entry(struct domain *d, unsigned long 
gfn,
 struct p2m_domain *p2m = p2m_get_hostp2m(d);
 int ret;
 
-if ( !paging_mode_translate(p2m->domain) )
+if ( !iommu_use_hap_pt(d) )
 {
 if ( !need_iommu(d) )
 return 0;
@@ -1032,7 +1032,7 @@ int clear_identity_p2m_entry(struct domain *d, unsigned 
long gfn)
 struct p2m_domain *p2m = p2m_get_hostp2m(d);
 int ret;
 
-if ( !paging_mode_translate(d) )
+if ( !iommu_use_hap_pt(d) )
 {
 if ( !need_iommu(d) )
 return 0;
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux

[Roger Pau Monné]

Hello,

El 14/09/15 a les 14.47, Julien Grall ha escrit:
> On 14/09/15 13:08, Roger Pau Monné wrote:
>>> I'd like to see a basic support of 64KB page granularity upstream before
>>> starting to think about performance improvement. And there is still a
>>> lot to do.
>>
>> I wasn't actually thinking of this as a performance improvement, but
>> rather as a way of fixing this properly and removing the complexity
>> added to xen-blkfront, thus providing a PV block protocol that natively
>> supports 64KB pages. This would be like hardware components already do
>> AFAIK, because I don't think there are other drivers in the Linux tree
>> that do this kind of splitting.
>>
>>> Although, having 64KB grants won't remove the splitting as we would
>>> still have to support frontend/backend which only handle 4KB grant.
>>
>> IMHO, given enough time I would just drop those.
> 
> The PV protocol has always been backward compatible.
> 
> Introducing the support of 64KB grant will require some changes in Xen
> which won't surely be backported to older version. We still have to be
> able to run new Linux guest on older Xen and vice versa.

OK, so let's wait a couple of Xen and Linux releases before dropping
this from the Linux kernel once 64KB grant support is added. Guests
should still be able to boot, it's just the disk that won't be attached.

IMHO this splitting is just a workaround for the fact that we don't have
a 64KB PV block protocol, and this is the real problem that should be
solved.

In the long term this will put a burden on all blkfronts (if 64KB pages
are also used by other OSes), while introducing a 64KB PV block protocol
will make the blkfront implementation in all OSes very similar to what
we have now, without replicating the splitting code amongst all the
possible blkfront implementations.

Granted that some changes to blkback will be needed in order to support
mapping 64KB grants, but there are much fewer blkback implementations
out there than blkfronts.

> To give you an example, Centos 7, which will support Xen and only 64KB
> page granularity, will be supported for years. Dropping any splitting in
> a short future (3-5 years) will just break those guests to boot on Xen.

Can't the patches to support 64KB grants be backported to CentOS? In the
past you said that distros had no problem in picking the needed Xen
patches for 64KB support, I don't see how that would be different.

Also, a blkfront with the splitting code should also be able to work
perfectly fine once we have a 64KB PV block protocol, it will just be
treated like it's using 4KB pages, that's all.

> AFAIK, we never took a such radical decision on Xen based on the
> complexity of the code.

We never had to deal with a problem like this I'm afraid (mixing guests
with different page sizes), so I don't think we can make statements
about that.

And it's not just about the complexity, it's because as stated above
this IMHO is just sweeping the real problem under the carpet instead of
solving it.

Roger.


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

Re: [Xen-devel] [PATCH for 4.6] x86/mm: make {set, clear}_identity_p2m_mapping() work for HVM guests as well

[Jan Beulich]

>>> On 14.09.15 at 16:24,  wrote:
> For Intel IGD passthrough, the guest driver programs the device to DMA
> to/from its RMRR.
> 
> c/s 619ecf8 "make {set,clear}_identity_p2m_mapping() work for PV guests"
> was incomplete for pre-Broadwell systems which did not support shared
> EPT.
> 
> The correct check to use is iommu_use_hap_pt() not
> paging_mode_translate() as IOMMU mappings also need to be created for
> HVM guests with separate EPT and IOMMU tables.

No, at least not without a very good explanation:

> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -957,7 +957,7 @@ int set_identity_p2m_entry(struct domain *d, unsigned 
> long gfn,
>  struct p2m_domain *p2m = p2m_get_hostp2m(d);
>  int ret;
>  
> -if ( !paging_mode_translate(p2m->domain) )
> +if ( !iommu_use_hap_pt(d) )

Not only have these checks no reason to be in any way IOMMU
dependent (no other function around here does so), but also
both ept_set_entry() and p2m_pt_set_entry() take care to call
iommu_{,un}map_page() as needed (as I had already pointed
out back when we discussed the patch this one tries to complete).
If anything, it would be those low level functions that may need
tweaking (and which have a reason to consider IOMMU flags) if
for some reason they don't actually do the expected calls.

Jan


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

Re: [Xen-devel] [PATCH] libxc: remove useless stuff from domain builder

[Wei Liu]

On Mon, Sep 14, 2015 at 02:54:09PM +0200, Juergen Gross wrote:
> Remove unused fields from the domain builder and associated functions.
> 
> Signed-off-by: Juergen Gross 
> ---
>  tools/libxc/include/xc_dom.h  | 2 --
>  tools/python/xen/lowlevel/xc/xc.c | 8 ++--
>  2 files changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 6192fba..5731098 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -132,7 +132,6 @@ struct xc_dom_image {
>  xen_pfn_t total_pages;
>  xen_pfn_t p2m_size; /* number of pfns covered by p2m */
>  struct xc_dom_phys *phys_pages;
> -int realmodearea_log;
>  #if defined (__arm__) || defined(__aarch64__)
>  xen_pfn_t rambank_size[GUEST_RAM_BANKS];
>  #endif
> @@ -157,7 +156,6 @@ struct xc_dom_image {
>  
>  xc_interface *xch;
>  domid_t guest_domid;
> -int8_t vhpt_size_log2; /* for IA64 */
>  int8_t superpages;
>  int claim_enabled; /* 0 by default, 1 enables it */
>  int shadow_enabled;
> diff --git a/tools/python/xen/lowlevel/xc/xc.c 
> b/tools/python/xen/lowlevel/xc/xc.c
> index 9ab53fb..668e875 100644
> --- a/tools/python/xen/lowlevel/xc/xc.c
> +++ b/tools/python/xen/lowlevel/xc/xc.c
> @@ -463,7 +463,6 @@ static PyObject *pyxc_linux_build(XcObject *self,
>  char *image, *ramdisk = NULL, *cmdline = "", *features = NULL;
>  int flags = 0;
>  int store_evtchn, console_evtchn;
> -int vhpt = 0;
>  int superpages = 0;
>  unsigned int mem_mb;
>  unsigned long store_mfn = 0;
> @@ -477,23 +476,20 @@ static PyObject *pyxc_linux_build(XcObject *self,
>  "console_evtchn", "image",
>  /* optional */
>  "ramdisk", "cmdline", "flags",
> -"features", "vhpt", "superpages", NULL };
> +"features", "superpages", NULL };
>  
>  if ( !PyArg_ParseTupleAndKeywords(args, kwds, "s|ssisii", kwd_list,
  ^
This format string needs to be changed, too. It should be "iiis|ssisi",
i.e. one "i" needs to be removed.

>, _evtchn, _mb,
>_evtchn, ,
>/* optional */
>, , ,
> -  , , ) )
> +  , ) )
>  return NULL;
>  
>  xc_dom_loginit(self->xc_handle);
>  if (!(dom = xc_dom_allocate(self->xc_handle, cmdline, features)))
>  return pyxc_error_to_exception(self->xc_handle);
>  
> -/* for IA64 */
> -dom->vhpt_size_log2 = vhpt;
> -
>  dom->superpages = superpages;
>  
>  if ( xc_dom_linux_build(self->xc_handle, dom, domid, mem_mb, image,
> -- 
> 2.1.4

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

Re: [Xen-devel] [PATCH] xen/arm: correct comment in enlighten.c

[Stefano Stabellini]

On Mon, 14 Sep 2015, Juergen Gross wrote:
> Correct a comment in arch/arm/xen/enlighten.c referencing a wrong
> source file.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Stefano Stabellini 


>  arch/arm/xen/enlighten.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index eeeab07..5421706 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -284,7 +284,7 @@ void xen_arch_resume(void) { }
>  void xen_arch_suspend(void) { }
>  
>  
> -/* In the hypervisor.S file. */
> +/* In the hypercall.S file. */
>  EXPORT_SYMBOL_GPL(HYPERVISOR_event_channel_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_grant_table_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_xen_version);
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux

[Julien Grall]

On 14/09/15 15:29, Roger Pau Monné wrote:
>> To give you an example, Centos 7, which will support Xen and only 64KB
>> page granularity, will be supported for years. Dropping any splitting in
>> a short future (3-5 years) will just break those guests to boot on Xen.
> 
> Can't the patches to support 64KB grants be backported to CentOS? In the
> past you said that distros had no problem in picking the needed Xen
> patches for 64KB support, I don't see how that would be different.

Centos 7 is not yet released so it's more easy to get patch in. I don't
know what will be position when the guest is shipped.

I bet they will still want to support 64KB with older Xen (i.e where
64KB grant is not supported).

Anyway, I don't expect to see the 64KB grants support before next year
as my TODO list is already pretty full. So let's talk about it when I
(or someone else) will send an RFC to extend the grant size.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH] libxc: remove useless stuff from domain builder

[Juergen Gross]

On 09/14/2015 03:23 PM, Wei Liu wrote:

On Mon, Sep 14, 2015 at 02:54:09PM +0200, Juergen Gross wrote:

Remove unused fields from the domain builder and associated functions.

Signed-off-by: Juergen Gross 
---
  tools/libxc/include/xc_dom.h  | 2 --
  tools/python/xen/lowlevel/xc/xc.c | 8 ++--
  2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6192fba..5731098 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -132,7 +132,6 @@ struct xc_dom_image {
  xen_pfn_t total_pages;
  xen_pfn_t p2m_size; /* number of pfns covered by p2m */
  struct xc_dom_phys *phys_pages;
-int realmodearea_log;
  #if defined (__arm__) || defined(__aarch64__)
  xen_pfn_t rambank_size[GUEST_RAM_BANKS];
  #endif
@@ -157,7 +156,6 @@ struct xc_dom_image {

  xc_interface *xch;
  domid_t guest_domid;
-int8_t vhpt_size_log2; /* for IA64 */
  int8_t superpages;
  int claim_enabled; /* 0 by default, 1 enables it */
  int shadow_enabled;
diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index 9ab53fb..668e875 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -463,7 +463,6 @@ static PyObject *pyxc_linux_build(XcObject *self,
  char *image, *ramdisk = NULL, *cmdline = "", *features = NULL;
  int flags = 0;
  int store_evtchn, console_evtchn;
-int vhpt = 0;
  int superpages = 0;
  unsigned int mem_mb;
  unsigned long store_mfn = 0;
@@ -477,23 +476,20 @@ static PyObject *pyxc_linux_build(XcObject *self,
  "console_evtchn", "image",
  /* optional */
  "ramdisk", "cmdline", "flags",
-"features", "vhpt", "superpages", NULL };
+"features", "superpages", NULL };

  if ( !PyArg_ParseTupleAndKeywords(args, kwds, "s|ssisii", kwd_list,

   ^
This format string needs to be changed, too. It should be "iiis|ssisi",
i.e. one "i" needs to be removed.


Indeed.

BTW: you've removed two "i"s. It has to be "s|ssisi".


Juergen

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

[Xen-devel] [PATCH] xl: tighten parsing of "irq" and "iomem" list elements

[Jan Beulich]

While "ioport" list element parsing already validates that the entire
input string got consumed, its two siblings so far didn't.

Signed-off-by: Jan Beulich 

--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1730,7 +1730,7 @@ static void parse_config_data(const char
 exit(1);
 }
 ul = strtoul(buf, , 10);
-if (ep == buf) {
+if (ep == buf || *ep != '\0') {
 fprintf(stderr,
 "xl: Invalid argument parsing irq: %s\n", buf);
 exit(1);
@@ -1752,6 +1752,8 @@ static void parse_config_data(const char
 exit(-1);
 }
 for (i = 0; i < num_iomem; i++) {
+int used;
+
 buf = xlu_cfg_get_listitem (iomem, i);
 if (!buf) {
 fprintf(stderr,
@@ -1759,11 +1761,11 @@ static void parse_config_data(const char
 exit(1);
 }
 libxl_iomem_range_init(_info->iomem[i]);
-ret = sscanf(buf, "%" SCNx64",%" SCNx64"@%" SCNx64,
+ret = sscanf(buf, "%" SCNx64",%" SCNx64"%n@%" SCNx64"%n",
  _info->iomem[i].start,
- _info->iomem[i].number,
- _info->iomem[i].gfn);
-if (ret < 2) {
+ _info->iomem[i].number, ,
+ _info->iomem[i].gfn, );
+if (ret < 2 || buf[used] != '\0') {
 fprintf(stderr,
 "xl: Invalid argument parsing iomem: %s\n", buf);
 exit(1);



xl: tighten parsing of "irq" and "iomem" list elements

While "ioport" list element parsing already validates that the entire
input string got consumed, its two siblings so far didn't.

Signed-off-by: Jan Beulich 

--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1730,7 +1730,7 @@ static void parse_config_data(const char
 exit(1);
 }
 ul = strtoul(buf, , 10);
-if (ep == buf) {
+if (ep == buf || *ep != '\0') {
 fprintf(stderr,
 "xl: Invalid argument parsing irq: %s\n", buf);
 exit(1);
@@ -1752,6 +1752,8 @@ static void parse_config_data(const char
 exit(-1);
 }
 for (i = 0; i < num_iomem; i++) {
+int used;
+
 buf = xlu_cfg_get_listitem (iomem, i);
 if (!buf) {
 fprintf(stderr,
@@ -1759,11 +1761,11 @@ static void parse_config_data(const char
 exit(1);
 }
 libxl_iomem_range_init(_info->iomem[i]);
-ret = sscanf(buf, "%" SCNx64",%" SCNx64"@%" SCNx64,
+ret = sscanf(buf, "%" SCNx64",%" SCNx64"%n@%" SCNx64"%n",
  _info->iomem[i].start,
- _info->iomem[i].number,
- _info->iomem[i].gfn);
-if (ret < 2) {
+ _info->iomem[i].number, ,
+ _info->iomem[i].gfn, );
+if (ret < 2 || buf[used] != '\0') {
 fprintf(stderr,
 "xl: Invalid argument parsing iomem: %s\n", buf);
 exit(1);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

[Daniel Kiper]

On Mon, Sep 14, 2015 at 03:09:34PM +0200, Ard Biesheuvel wrote:
> On 14 September 2015 at 14:28, Daniel Kiper  wrote:
> > On Mon, Sep 14, 2015 at 11:43:27AM +0200, Ard Biesheuvel wrote:
> >> On 14 September 2015 at 11:25, Mark Rutland  wrote:
> >> > On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote:
> >> >> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote:
> >> >> > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote:
> >> >> > > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote:
> >> >>
> >> >> [...]
> >> >>
> >> >> > > > What's troublesome with the boot services?
> >> >> > > >
> >> >> > > > What can't be simulated?
> >> >> > >
> >> >> > > How do you want to access bare metal EFI boot services from dom0 if 
> >> >> > > they
> >> >> > > were shutdown long time ago before loading dom0 image?
> >> >> >
> >> >> > I don't want to.
> >> >> >
> >> >> > I asked "What can't be simulated?" because I assumed everything
> >> >> > necessary/mandatory could be simulated without needinng access to any
> >> >> > real EFI boot services.
> >> >> >
> >> >> > As far as I can see all that's necessary is to provide a compatible
> >> >> > interface.
> >> >>
> >> >> Could you be more precise what do you need? Please enumerate. UEFI spec 
> >> >> has
> >> >> more than 2500 pages and I do not think that we need all stuff in dom0.
> >> >>
> >> >> > > What do you need from EFI boot services in dom0?
> >> >> >
> >> >> > The ability to call ExitBootServices() and SetVirtualAddressMap() on a
> >> >> > _virtual_ address map for _virtual_ services provided by the 
> >> >> > hypervisor.
> >> >>
> >> >> I am confused. Why do you need that? Please remember, EFI is owned and
> >> >> operated by Xen hypervisor. dom0 does not have direct access to EFI.
> >> >
> >> > Let's take a step back.
> >> >
> >> > My objection here is to passing the Dom0 kernel properties as if it were
> >> > booted with direct access to a full UEFI, then later fixing that up
> >> > (when Xen is detected and we apply its hypercall EFI implementation).
> >> >
> >>
> >> To be honest, I don't think that has ever been suggested here. What
> >> was suggested is to provide a minimal EFI like environment that allows
> >> the post-stub EFI code to proceed and find the ACPI root pointer.
> >>
> >> > If the kernel cannot use EFI natively, why pretend to the kernel that it
> >> > can? The hypercall implementation is _not_ EFI (though it provides
> >> > access to some services).
> >> >
> >>
> >> To get access to the ACPI root pointer, for which there is only one
> >> specified way of obtaining it on ARM, which is via the UEFI
> >> configuration table database
> >>
> >> > The two ways I can see providing Dom0 with EFI services are:
> >> >
> >> > * Have Xen create shims for any services, in which any hypercalls live,
> >> >   and pass these to the kernel with a virtual system table. This keeps
> >> >   the interface to the kernel the same regardless of Xen.
> >> >
> >> > * Have the kernel detect Xen EFI capability via Xen, without passing the
> >> >   usual native EFI parameters. This can then be installed into the
> >> >   kernel in a Xen-specific manner, and we know from the outset that
> >> >   Xen-specific caveats apply.
> >> >
> >> > As per my original email, I'm not against the renaming of the stub
> >> > parameters if we standardise the rest of the details, but I believe
> >> > that's orthogonal to the Xen Dom0 case.
> >> >
> >>
> >> Xen will not boot the kernel via the stub, but directly. It needs to
> >> supply a EFI like environment so that the kernel can boot via ACPI.
> >> There is no reason whatsoever to mock up boot services or other pieces
> >> of UEFI functionality that are not needed. The core kernel does not
> >> call any boot services or SetVirtualAddressMap/ConvertPointer, and
> >> there is already paravirtualized plumbing in place for the remaining
> >> runtime services.
> >>
> >> Hence my claim earlier that we should cope with the runtime services
> >> pointer being NULL, since that is really the only thing standing in
> >
> > I suppose that you thought about EFI_INVALID_TABLE_ADDR...
> >
>
> Simply whatever we decide, so perhaps EFI_INVALID_TABLE_ADDR is better
> if x86 uses that already. But that value is still outside of the UEFI
> spec, so in that sense, it is not more appropriate than NULL.

Yep, you are right. However, I hope (I am not sure) that it was good reason
behind choosing that value in Linux kernel and I think that in EFI related
code it should be used as it is used right now.

> >> the way from the kernel side. If you feel that violates the spec in
> >
> > If yes then you should know that dom0 on x86 EFI platform works
> > with efi.runtime == EFI_INVALID_TABLE_ADDR without any issue.
> > So, I think that all problems are solved.
> >
>
> So there is precedent, which is good. But please note that x86 has a
> lot of baggage and *lots* of quirks for buggy 

Re: [Xen-devel] [Patch V2] xen: use correct type for HYPERVISOR_memory_op()

[Boris Ostrovsky]

On 09/14/2015 09:13 AM, Juergen Gross wrote:

HYPERVISOR_memory_op() is defined to return an "int" value. This is
wrong, as the Xen hypervisor will return "long".

The sub-function XENMEM_maximum_reservation returns the maximum
number of pages for the current domain. An int will overflow for a
domain configured with 8TB of memory or more.

Correct this by using the correct type.


Reviewed-by: Boris Ostrovsky 




Signed-off-by: Juergen Gross 
---
V2: change arm header as well to keep it in sync with x86
 (requested by Julien Grall)
---
  arch/arm/include/asm/xen/hypercall.h | 2 +-
  arch/x86/include/asm/xen/hypercall.h | 4 ++--
  arch/x86/xen/setup.c | 2 +-
  3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h 
b/arch/arm/include/asm/xen/hypercall.h
index 712b50e..47f0d81 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -45,7 +45,7 @@ int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, 
unsigned int count);
  int HYPERVISOR_sched_op(int cmd, void *arg);
  int HYPERVISOR_event_channel_op(int cmd, void *arg);
  unsigned long HYPERVISOR_hvm_op(int op, void *arg);
-int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
+long HYPERVISOR_memory_op(unsigned int cmd, void *arg);
  int HYPERVISOR_physdev_op(int cmd, void *arg);
  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
  int HYPERVISOR_tmem_op(void *arg);
diff --git a/arch/x86/include/asm/xen/hypercall.h 
b/arch/x86/include/asm/xen/hypercall.h
index 83aea80..4c20dd3 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -336,10 +336,10 @@ HYPERVISOR_update_descriptor(u64 ma, u64 desc)
return _hypercall4(int, update_descriptor, ma, ma>>32, desc, desc>>32);
  }
  
-static inline int

+static inline long
  HYPERVISOR_memory_op(unsigned int cmd, void *arg)
  {
-   return _hypercall2(int, memory_op, cmd, arg);
+   return _hypercall2(long, memory_op, cmd, arg);
  }
  
  static inline int

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index f5ef674..4ebfcec 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -548,7 +548,7 @@ static unsigned long __init xen_get_max_pages(void)
  {
unsigned long max_pages, limit;
domid_t domid = DOMID_SELF;
-   int ret;
+   long ret;
  
  	limit = xen_get_pages_limit();

max_pages = limit;



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

Re: [Xen-devel] [PATCH] KVM: arm64: add workaround for Cortex-A57 erratum #852523

[Will Deacon]

Hi Ian,

On Mon, Sep 14, 2015 at 04:36:28PM +0100, Ian Campbell wrote:
> On Mon, 2015-09-14 at 16:06 +0100, Will Deacon wrote:
> > When restoring the system register state for an AArch32 guest at EL2,
> > writes to DACR32_EL2 may not be correctly synchronised by Cortex-A57,
> > which can lead to the guest effectively running with junk in the DACR
> > and running into unexpected domain faults.
> 
> Thanks for the CC, dropping down to just the Xen folks/list and you guys.
> 
> The errata doc I've got doesn't yet cover this, so I've a few questions.

It should be updated in the next few days, but I wanted to get this out
ASAP since it's quite easy to hit under KVM (particularly with the new
domain-based PAN implementation for arch/arm/).

> > This patch works around the issue by re-ordering our restoration of the
> > AArch32 register aliases so that they happen before the AArch64 system
> > registers. Ensuring that the registers are restored in this order
> > guarantees that they will be correctly synchronised by the core.
> 
> Is it required that the AArch32 aliases are all restored strictly before
> the AArch64 sysregs, or just that at least one sysreg is restored after
> DACR32_EL2 (or a specific one?)?

Take your pick from: SCTLR_EL1, TCR_EL1, TTBR0_EL1, TTBR1_EL1, or
CONTEXTIDR_EL1. Writing any of those after DACR32_EL2 will avoid the
erratum.

> The Xen ctxt switch code[0] has DACR_EL2 in the midst of it all, and
> certainly followed by some sysregs, which I've got my fingers crossed
> happens to be sufficient (other than maybe adding a comment).

It looks like you restore CONTEXTIDR_EL1 fairly late, so you should be
ok.

Will

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

Re: [Xen-devel] [PATCH v11 11/11] (lib)xl: soft reset support

[Wei Liu]

Sorry for the delay.

FYI all other patches of this series were applied by Jan. You only need
to resend this one.

See below for a few comments.

On Fri, Sep 04, 2015 at 03:39:51PM +0200, Vitaly Kuznetsov wrote:
> Use existing create/restore path to perform 'soft reset' for HVM
> domains. Tear everything down, e.g. destroy domain's device model,
> remove the domain from xenstore, save toolstack record and start
> over.
> 
> Signed-off-by: Vitaly Kuznetsov 
> ---
> Changes since v10:
> - Adapt to 'migration v2' changes.
> - Use LIBXL_DEVICE_MODEL_SAVE_FILE as Qemu save file (and rename it to
>   LIBXL_DEVICE_MODEL_RESTORE_FILE later) to support stubdom case (as
>   we connect consoles to both files on create.
> - Fix coding style, minor description change in xl.cfg.pod.5 [Wei Liu]
> 
> Signed-off-by: Vitaly Kuznetsov 
> ---
>  docs/man/xl.cfg.pod.5|   8 +-
>  tools/libxl/libxl.c  |  22 -
>  tools/libxl/libxl.h  |  15 
>  tools/libxl/libxl_create.c   | 192 
> ++-
>  tools/libxl/libxl_internal.h |   4 +
>  tools/libxl/libxl_types.idl  |   2 +
>  tools/libxl/xl.h |   1 +
>  tools/libxl/xl_cmdimpl.c |  25 +-
>  8 files changed, 242 insertions(+), 27 deletions(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index c6345b8..d8c4186 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -349,6 +349,12 @@ destroy the domain.
>  write a "coredump" of the domain to F and then
>  restart the domain.
>  
> +=item B
> +
> +Reset all Xen specific interfaces for the Xen-aware HVM domain allowing
> +it to reestablish these interfaces and continue executing the domain. PV
> +guest is not supported.
> +

And "non-Xen-aware HVM will crash" ?  If there is no definite answer to
guest state maybe just saying "PV guest and non-Xen-aware HVM guests are
not supported" ?

It's important to let user know about the consequence because libxl
doesn't actually stop you from soft-resetting a HVM guest that is not
Xen-aware.

[...]
> +static int do_domain_soft_reset(libxl_ctx *ctx,
> +libxl_domain_config *d_config,
> +uint32_t domid_soft_reset,
> +const libxl_asyncop_how *ao_how,
> +const libxl_asyncprogress_how
> +*aop_console_how)
> +{
> +AO_CREATE(ctx, 0, ao_how);
> +libxl__domain_soft_reset_state *srs;
> +libxl__app_domain_create_state *cdcs;
> +libxl__domain_create_state *dcs;
> +libxl__domain_build_state *state;
> +libxl__domain_suspend_state *dss;
> +char *dom_path, *xs_store_mfn, *xs_console_mfn;
> +uint32_t domid_out;
> +int rc;
> +
> +GCNEW(srs);
> +cdcs = >cdcs;
> +dcs = >dcs;
> +state = >build_state;
> +dss = >dss;
> +
> +srs->cdcs.dcs.ao = ao;
> +srs->cdcs.dcs.guest_config = d_config;
> +libxl_domain_config_init(>cdcs.dcs.guest_config_saved);
> +libxl_domain_config_copy(ctx, >cdcs.dcs.guest_config_saved,
> + d_config);
> +cdcs->dcs.restore_fd = -1;
> +cdcs->dcs.domid_soft_reset = domid_soft_reset;
> +cdcs->dcs.callback = domain_create_cb;
> +libxl__ao_progress_gethow(>cdcs.dcs.aop_console_how,
> +  aop_console_how);
> +cdcs->domid_out = _out;
> +
> +dom_path = libxl__xs_get_dompath(gc, domid_soft_reset);
> +if (!dom_path) {
> +LOG(ERROR, "failed to read domain path");
> +return AO_CREATE_FAIL(ERROR_FAIL);

Sorry for not noticing this earlier. My bad and apologise.

This should be

   if (!dom_path) {
   LOG(...);
   rc = ERROR_FAIL;
   goto out;
   }

I.e. please use goto style error handling.

> +}
> +
> +xs_store_mfn = xs_read(ctx->xsh, XBT_NULL,
> +   GCSPRINTF("%s/store/ring-ref", dom_path),
> +   NULL);
> +state->store_mfn = xs_store_mfn ? atol(xs_store_mfn): 0;
> +free(xs_store_mfn);
> +
> +xs_console_mfn = xs_read(ctx->xsh, XBT_NULL,
> + GCSPRINTF("%s/console/ring-ref", dom_path),
> + NULL);
> +state->console_mfn = xs_console_mfn ? atol(xs_console_mfn): 0;
> +free(xs_console_mfn);
> +
> +dss->ao = ao;
> +dss->domid = domid_soft_reset;
> +dss->dm_savefile = GCSPRINTF(LIBXL_DEVICE_MODEL_SAVE_FILE".%d",
> + domid_soft_reset);
> +
> +rc = libxl__save_emulator_xenstore_data(dss, >toolstack_buf,
> +>toolstack_len);
> +if (rc) {
> +LOG(ERROR, "failed to save toolstack record.");
> +return AO_CREATE_FAIL(ERROR_FAIL);

Ditto, please use goto style error handling.

Furthermore please preserve rc from libxl__save_emulator_xenstore_data
instead of rewriting it with 

[Xen-devel] [PATCH] KVM: arm64: add workaround for Cortex-A57 erratum #852523

[Will Deacon]

When restoring the system register state for an AArch32 guest at EL2,
writes to DACR32_EL2 may not be correctly synchronised by Cortex-A57,
which can lead to the guest effectively running with junk in the DACR
and running into unexpected domain faults.

This patch works around the issue by re-ordering our restoration of the
AArch32 register aliases so that they happen before the AArch64 system
registers. Ensuring that the registers are restored in this order
guarantees that they will be correctly synchronised by the core.

Cc: 
Cc: Marc Zyngier 
Signed-off-by: Will Deacon 
---
 arch/arm64/kvm/hyp.S | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
index 3c4f641451bb..c4016d411f4a 100644
--- a/arch/arm64/kvm/hyp.S
+++ b/arch/arm64/kvm/hyp.S
@@ -739,6 +739,9 @@ ENTRY(__kvm_vcpu_run)
// Guest context
add x2, x0, #VCPU_CONTEXT
 
+   // We must restore the 32-bit state before the sysregs, thanks
+   // to Cortex-A57 erratum #852523.
+   restore_guest_32bit_state
bl __restore_sysregs
 
skip_debug_state x3, 1f
@@ -746,7 +749,6 @@ ENTRY(__kvm_vcpu_run)
kern_hyp_va x3
bl  __restore_debug
 1:
-   restore_guest_32bit_state
restore_guest_regs
 
// That's it, no more messing around.
-- 
2.1.4


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

Re: [Xen-devel] Dom0 crash with apache bench (ab)

[Konrad Rzeszutek Wilk]

On Mon, Sep 14, 2015 at 02:40:08PM +0200, Christoffer Dall wrote:
> On Fri, Jul 31, 2015 at 03:17:56PM +0200, Christoffer Dall wrote:
> > On Fri, Jul 31, 2015 at 12:28 PM, David Vrabel 
> > wrote:
> > 
> > > On 31/07/15 11:24, Stefano Stabellini wrote:
> > > > This is a Linux Dom0 crash on x86 (Dell PowerEdge R320, Xeon E5-2450),
> > > > CC'ing relevant people. As you can see from the links below the crash
> > > > is:
> > > >
> > > > [ 253.619326] Call Trace:
> > > > [ 253.619330] 
> > > > [ 253.619332] [] ? skb_copy_ubufs+0xa5/0x230
> > > > [ 253.619347] [] __netif_receive_skb_core+0x6f5/0x940
> > > > [ 253.619353] [] __netif_receive_skb+0x18/0x60
> > > > [ 253.619360] [] netif_receive_skb_internal+0x28/0x90
> > > > [ 253.619366] [] napi_gro_frags+0x125/0x1a0
> > > > [ 253.619378] [] mlx4_en_process_rx_cq+0x753/0xb50
> > > [mlx4_en]
> > > > [ 253.619387] [] mlx4_en_poll_rx_cq+0x97/0x160
> > > [mlx4_en]
> > >
> > > What makes you think this is Xen specific?  I suggest raising this the
> > > the mlx4 maintainers.
> > >
> > >
> > Linux native and KVM guests (same hw, same kernel version+config) run just
> > fine under the same workload.
> > 
> Ping?
> 
> >From the fact that bare-metal and KVM works fine with this hardware I
> still think it's reasonable to assume that it's a Xen issue and not a
> mlx4 issue.
> 
> Is this completely flawed?

I have a feeling it is an mlx4 issue but you don't easily reproduce it
under baremetal. Is there any way you could boot baremetal with
'iommu=soft swiotlb=force' to see if you can reproduce it under those
conditions?

thanks!
> 
> Thanks,
> -Christoffer
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 61627

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm  9 debian-installfail REGR. vs. 61627
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 61627
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 61627
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail like 61627
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 61627
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 61627
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 61627

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-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  ebe3fd9e736dda6cb141abe1241f0c8491125ebc
baseline version:
 xen  a7b39c8bd6cba3fe1c8012987b9e28bdbac7e92d

Last test of basis61627  2015-09-08 14:33:27 Z6 days
Failing since 61739  2015-09-10 06:45:52 Z4 days2 attempts
Testing same since61821  2015-09-12 01:18:23 Z2 days1 attempts


People who touched revisions under test:
  Boris Ostrovsky 
  Chris Brand 
  Daniel De Graaf 
  David Vrabel 
  Hanjun Guo 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jonathan Creekmore 
  Kouya Shimura 
  Len Brown 
  Rafael J. Wysocki 
  Razvan Cojocaru 
  Shannon Zhao 
  

Re: [Xen-devel] [PATCH] KVM: arm64: add workaround for Cortex-A57 erratum #852523

[Marc Zyngier]

On 14/09/15 16:06, Will Deacon wrote:
> When restoring the system register state for an AArch32 guest at EL2,
> writes to DACR32_EL2 may not be correctly synchronised by Cortex-A57,
> which can lead to the guest effectively running with junk in the DACR
> and running into unexpected domain faults.
> 
> This patch works around the issue by re-ordering our restoration of the
> AArch32 register aliases so that they happen before the AArch64 system
> registers. Ensuring that the registers are restored in this order
> guarantees that they will be correctly synchronised by the core.
> 
> Cc: 
> Cc: Marc Zyngier 
> Signed-off-by: Will Deacon 

Reviewed-by: Marc Zyngier 

I'll queue that together with the next batch of fixes.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

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

Re: [Xen-devel] Dom0 crash with apache bench (ab)

[Ian Campbell]

On Mon, 2015-09-14 at 14:40 +0200, Christoffer Dall wrote:
> On Fri, Jul 31, 2015 at 03:17:56PM +0200, Christoffer Dall wrote:
> > On Fri, Jul 31, 2015 at 12:28 PM, David Vrabel  > >
> > wrote:
> > 
> > > On 31/07/15 11:24, Stefano Stabellini wrote:
> > > > This is a Linux Dom0 crash on x86 (Dell PowerEdge R320, Xeon E5
> > > > -2450),
> > > > CC'ing relevant people. As you can see from the links below the
> > > > crash
> > > > is:
> > > > 
> > > > [ 253.619326] Call Trace:
> > > > [ 253.619330] 
> > > > [ 253.619332] [] ? skb_copy_ubufs+0xa5/0x230
> > > > [ 253.619347] []
> > > > __netif_receive_skb_core+0x6f5/0x940
> > > > [ 253.619353] [] __netif_receive_skb+0x18/0x60
> > > > [ 253.619360] []
> > > > netif_receive_skb_internal+0x28/0x90
> > > > [ 253.619366] [] napi_gro_frags+0x125/0x1a0
> > > > [ 253.619378] []
> > > > mlx4_en_process_rx_cq+0x753/0xb50
> > > [mlx4_en]
> > > > [ 253.619387] [] mlx4_en_poll_rx_cq+0x97/0x160
> > > [mlx4_en]
> > > 
> > > What makes you think this is Xen specific?  I suggest raising this
> > > the
> > > the mlx4 maintainers.
> > > 
> > > 
> > Linux native and KVM guests (same hw, same kernel version+config) run
> > just
> > fine under the same workload.
> > 
> Ping?
> 
> From the fact that bare-metal and KVM works fine with this hardware I
> still think it's reasonable to assume that it's a Xen issue and not a
> mlx4 issue.
> 
> Is this completely flawed?

My (somewhat educated) guess is that this is to do with the difference
between (pseudo-)physical addresses and machine (AKA real-physical)
addresses when running under Xen.

The way this often shows up is in drivers which do not make correct use of
the kernels DMA APIs but which happen to work on native x86 because
physical==bus address on x86.

Sometimes booting natively with 'iommu=soft swiotlb=force' can expose these
sorts of issues.

You are running 64-bit so I don't think the recent "config: Enable
NEED_DMA_MAP_STATE by default when SWIOTLB is selected" is likely to be
relevant (it's already unconditionally on for 64-bit).

The trace appears to be on rx from a physical nic, there shouldn't be any
magic Xen stuff (granted pages etc) getting themselves into that path at
all. If it were tx then maybe it might be an issue with foreign pages. In
any case I think you are able to repro with just dom0, i.e. never having
started a domU, is that right?
Ian.

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

Re: [Xen-devel] [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux

[Roger Pau Monné]

El 14/09/15 a les 16.54, Stefano Stabellini ha escrit:
> On Mon, 14 Sep 2015, Roger Pau Monné wrote:
>> IMHO this splitting is just a workaround for the fact that we don't have
>> a 64KB PV block protocol, and this is the real problem that should be
>> solved.
> 
> 64K is a pure one guest kernel configuration option, not a platform wide
> option. The hypervisor interfaces are still the same, the ABI is the
> same and all the other guests are still the same, the Xen binary is
> still the same.

Yes, I understand that, but the PV block protocol is missing 64KB page
support, and that's a fact that cannot be ignored. To put an example, is
there a hardware SATA controller on ARM that doesn't support 64KB pages
and needs a similar workaround?

> A 64K block protocol could be a good performance imprevement, but should
> not be required to run kernels which have different config options.
> 
>> In the long term this will put a burden on all blkfronts (if 64KB pages
>> are also used by other OSes), while introducing a 64KB PV block protocol
>> will make the blkfront implementation in all OSes very similar to what
>> we have now, without replicating the splitting code amongst all the
>> possible blkfront implementations.
>>
>> Granted that some changes to blkback will be needed in order to support
>> mapping 64KB grants, but there are much fewer blkback implementations
>> out there than blkfronts.
> 
> I don't think we can rely on blkback having something in order to run
> new guests, otherwise we break compatibility: new guests won't run on
> old hypervisors.

I agree that this is far from ideal, but I don't think it's so
outrageous. For example Linux PVOPS Dom0 kernels require Xen 4.0.1 at
least in order to run, because previous versions lack the necessary
IOAPIC setup hypercall. Also, it won't prevent guests from booting, it
would just prevent them from using blkfront, but you can still get a
root filesystem using iSCSI, NFS or other means.

I'm not saying that we shouldn't take those patches, I'm just saying
that IMHO this is a workaround, and I would like to see a plan and
somebody committed to have it fixed in a proper way, by introducing a
64KB PV block protocol.

Roger.


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

[Xen-devel] [PATCH] xen/arm: hvm_domain drop unused field instropection_enabled

[Julien Grall]

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/domain.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 56aa208..7ddaeaa 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -17,7 +17,6 @@ struct hvm_domain
 {
 uint64_t  params[HVM_NR_PARAMS];
 struct hvm_iommu  iommu;
-bool_tintrospection_enabled;
 }  __cacheline_aligned;
 
 #ifdef CONFIG_ARM_64
-- 
2.1.4


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

Re: [Xen-devel] Dom0 crash with apache bench (ab)

[Christoffer Dall]

On Mon, Sep 14, 2015 at 5:20 PM, Ian Campbell 
wrote:

> On Mon, 2015-09-14 at 14:40 +0200, Christoffer Dall wrote:
> > On Fri, Jul 31, 2015 at 03:17:56PM +0200, Christoffer Dall wrote:
> > > On Fri, Jul 31, 2015 at 12:28 PM, David Vrabel <
> david.vra...@citrix.com
> > > >
> > > wrote:
> > >
> > > > On 31/07/15 11:24, Stefano Stabellini wrote:
> > > > > This is a Linux Dom0 crash on x86 (Dell PowerEdge R320, Xeon E5
> > > > > -2450),
> > > > > CC'ing relevant people. As you can see from the links below the
> > > > > crash
> > > > > is:
> > > > >
> > > > > [ 253.619326] Call Trace:
> > > > > [ 253.619330] 
> > > > > [ 253.619332] [] ? skb_copy_ubufs+0xa5/0x230
> > > > > [ 253.619347] []
> > > > > __netif_receive_skb_core+0x6f5/0x940
> > > > > [ 253.619353] [] __netif_receive_skb+0x18/0x60
> > > > > [ 253.619360] []
> > > > > netif_receive_skb_internal+0x28/0x90
> > > > > [ 253.619366] [] napi_gro_frags+0x125/0x1a0
> > > > > [ 253.619378] []
> > > > > mlx4_en_process_rx_cq+0x753/0xb50
> > > > [mlx4_en]
> > > > > [ 253.619387] [] mlx4_en_poll_rx_cq+0x97/0x160
> > > > [mlx4_en]
> > > >
> > > > What makes you think this is Xen specific?  I suggest raising this
> > > > the
> > > > the mlx4 maintainers.
> > > >
> > > >
> > > Linux native and KVM guests (same hw, same kernel version+config) run
> > > just
> > > fine under the same workload.
> > >
> > Ping?
> >
> > From the fact that bare-metal and KVM works fine with this hardware I
> > still think it's reasonable to assume that it's a Xen issue and not a
> > mlx4 issue.
> >
> > Is this completely flawed?
>
> My (somewhat educated) guess is that this is to do with the difference
> between (pseudo-)physical addresses and machine (AKA real-physical)
> addresses when running under Xen.
>
> The way this often shows up is in drivers which do not make correct use of
> the kernels DMA APIs but which happen to work on native x86 because
> physical==bus address on x86.
>
> Sometimes booting natively with 'iommu=soft swiotlb=force' can expose these
> sorts of issues.
>

I'll give this a try.


>
> You are running 64-bit so I don't think the recent "config: Enable
> NEED_DMA_MAP_STATE by default when SWIOTLB is selected" is likely to be
> relevant (it's already unconditionally on for 64-bit).
>
> The trace appears to be on rx from a physical nic, there shouldn't be any
> magic Xen stuff (granted pages etc) getting themselves into that path at
> all. If it were tx then maybe it might be an issue with foreign pages. In
> any case I think you are able to repro with just dom0, i.e. never having
> started a domU, is that right?
>

As far as I remember and as far as I can interpret my own e-mail, yes.

Thanks for the feedback, I'll try the suggested approaches and also try
using v4.3-rc1 and take it up with the mlx4 maintainers if I still see the
issue.

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

[Xen-devel] [PATCH 1/2] xen/arm: gic-v3: Clean-up the GIC*_PIDR2_* definitions

[Julien Grall]

GICR_PIDR2 and GICD_PIDR2 use the same register layout. Rather than
define twice, one of which is an alias to the other, introduce GIC_PIDR2_*
defines.

Also:
* Use the same prefix for the mask and the value
* Integrate the shift in the value to avoid shifting in the code
* Use GICv* to match the value name in the spec
* Move them in a proper place

Signed-off-by: Julien Grall 
---
 xen/arch/arm/gic-v3.c |  8 
 xen/include/asm-arm/gic_v3_defs.h | 12 
 2 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index d1db1ce..4d623bf 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -639,8 +639,8 @@ static int __init gicv3_populate_rdist(void)
 {
 void __iomem *ptr = gicv3.rdist_regions[i].map_base;
 
-reg = readl_relaxed(ptr + GICR_PIDR2) & GICR_PIDR2_ARCH_REV_MASK;
-if ( (reg >> GICR_PIDR2_ARCH_REV_SHIFT) != GICR_PIDR2_ARCH_GICV3 )
+reg = readl_relaxed(ptr + GICR_PIDR2) & GIC_PIDR2_ARCH_MASK;
+if ( reg != GIC_PIDR2_ARCH_GICv3 )
 {
 dprintk(XENLOG_ERR,
 "GICv3: No redistributor present @%"PRIpaddr"\n",
@@ -1193,8 +1193,8 @@ static int __init gicv3_init(void)
 if ( !gicv3.map_dbase )
 panic("GICv3: Failed to ioremap for GIC distributor\n");
 
-reg = readl_relaxed(GICD + GICD_PIDR2) & GICD_PIDR2_ARCH_REV_MASK;
-if ( ((reg >> GICD_PIDR2_ARCH_REV_SHIFT) != GICD_PIDR2_ARCH_GICV3) )
+reg = readl_relaxed(GICD + GICD_PIDR2) & GIC_PIDR2_ARCH_MASK;
+if ( reg != GIC_PIDR2_ARCH_GICv3 )
  panic("GICv3: no distributor detected\n");
 
 if ( !dt_property_read_u32(node, "#redistributor-regions",
diff --git a/xen/include/asm-arm/gic_v3_defs.h 
b/xen/include/asm-arm/gic_v3_defs.h
index bf7b239..b0ac6ff 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -40,6 +40,10 @@
 #define GICD_PIDR5   (0xFFD4)
 #define GICD_PIDR7   (0xFFDC)
 
+/* Common between GICD_PIDR2 and GICR_PIDR2 */
+#define GIC_PIDR2_ARCH_MASK (0xf0)
+#define GIC_PIDR2_ARCH_GICv3(0x30)
+
 #define GICC_SRE_EL2_SRE (1UL << 0)
 #define GICC_SRE_EL2_DFB (1UL << 1)
 #define GICC_SRE_EL2_DIB (1UL << 2)
@@ -59,14 +63,6 @@
 #define GICR_WAKER_ProcessorSleep(1U << 1)
 #define GICR_WAKER_ChildrenAsleep(1U << 2)
 
-#define GICD_PIDR2_ARCH_REV_MASK (0xf0)
-#define GICD_PIDR2_ARCH_REV_SHIFT(0x4)
-#define GICD_PIDR2_ARCH_GICV3(0x3)
-
-#define GICR_PIDR2_ARCH_REV_MASK GICD_PIDR2_ARCH_REV_MASK
-#define GICR_PIDR2_ARCH_REV_SHIFTGICD_PIDR2_ARCH_REV_SHIFT
-#define GICR_PIDR2_ARCH_GICV3GICD_PIDR2_ARCH_GICV3
-
 #define GICR_SYNCR_NOT_BUSY  1
 /*
  * Implementation defined value JEP106?
-- 
2.1.4


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

[Xen-devel] [PATCH 0/2] GICv3: Clean up + enable support on GICv4

[Julien Grall]

Hi all,

This small patch series allow Xen to run on platform reporting GICv4
in the GIC*_PIDR2.

Sincerely yours,

Julien Grall (2):
  xen/arm: gic-v3: Clean-up the GIC*_PIDR2_* definitions
  xen/arm: gic-v3: Allow Xen to run on hardware reporting GICv4

 xen/arch/arm/gic-v3.c |  8 
 xen/include/asm-arm/gic_v3_defs.h | 13 +
 2 files changed, 9 insertions(+), 12 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH 2/2] xen/arm: gic-v3: Allow Xen to run on hardware reporting GICv4

[Julien Grall]

It seems that there is some hardware which report start to report GICv4
in the GIC*_PIDR2 register.

As GICv4 is a superset of GICv3, it should just work on Xen.

Reported-by: Andre Przywara 
Signed-off-by: Julien Grall 
---
 xen/arch/arm/gic-v3.c | 4 ++--
 xen/include/asm-arm/gic_v3_defs.h | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 4d623bf..1e3c19b 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -640,7 +640,7 @@ static int __init gicv3_populate_rdist(void)
 void __iomem *ptr = gicv3.rdist_regions[i].map_base;
 
 reg = readl_relaxed(ptr + GICR_PIDR2) & GIC_PIDR2_ARCH_MASK;
-if ( reg != GIC_PIDR2_ARCH_GICv3 )
+if ( reg != GIC_PIDR2_ARCH_GICv3 && reg != GIC_PIDR2_ARCH_GICv4 )
 {
 dprintk(XENLOG_ERR,
 "GICv3: No redistributor present @%"PRIpaddr"\n",
@@ -1194,7 +1194,7 @@ static int __init gicv3_init(void)
 panic("GICv3: Failed to ioremap for GIC distributor\n");
 
 reg = readl_relaxed(GICD + GICD_PIDR2) & GIC_PIDR2_ARCH_MASK;
-if ( reg != GIC_PIDR2_ARCH_GICv3 )
+if ( reg != GIC_PIDR2_ARCH_GICv3 && reg != GIC_PIDR2_ARCH_GICv4 )
  panic("GICv3: no distributor detected\n");
 
 if ( !dt_property_read_u32(node, "#redistributor-regions",
diff --git a/xen/include/asm-arm/gic_v3_defs.h 
b/xen/include/asm-arm/gic_v3_defs.h
index b0ac6ff..c6d73df 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -43,6 +43,7 @@
 /* Common between GICD_PIDR2 and GICR_PIDR2 */
 #define GIC_PIDR2_ARCH_MASK (0xf0)
 #define GIC_PIDR2_ARCH_GICv3(0x30)
+#define GIC_PIDR2_ARCH_GICv4(0x40)
 
 #define GICC_SRE_EL2_SRE (1UL << 0)
 #define GICC_SRE_EL2_DFB (1UL << 1)
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] KVM: arm64: add workaround for Cortex-A57 erratum #852523

[Ian Campbell]

On Mon, 2015-09-14 at 16:06 +0100, Will Deacon wrote:
> When restoring the system register state for an AArch32 guest at EL2,
> writes to DACR32_EL2 may not be correctly synchronised by Cortex-A57,
> which can lead to the guest effectively running with junk in the DACR
> and running into unexpected domain faults.

Thanks for the CC, dropping down to just the Xen folks/list and you guys.

The errata doc I've got doesn't yet cover this, so I've a few questions.

> This patch works around the issue by re-ordering our restoration of the
> AArch32 register aliases so that they happen before the AArch64 system
> registers. Ensuring that the registers are restored in this order
> guarantees that they will be correctly synchronised by the core.

Is it required that the AArch32 aliases are all restored strictly before
the AArch64 sysregs, or just that at least one sysreg is restored after
DACR32_EL2 (or a specific one?)?

The Xen ctxt switch code[0] has DACR_EL2 in the midst of it all, and
certainly followed by some sysregs, which I've got my fingers crossed
happens to be sufficient (other than maybe adding a comment).

Cheers,
Ian.

[0] 
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/domain.c;h=b2bfc7d293ada3cd1695873c014e71d809c8e69d;hb=HEAD#l104
 
> 
> Cc: 
> Cc: Marc Zyngier 
> Signed-off-by: Will Deacon 
> ---
>  arch/arm64/kvm/hyp.S | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
> index 3c4f641451bb..c4016d411f4a 100644
> --- a/arch/arm64/kvm/hyp.S
> +++ b/arch/arm64/kvm/hyp.S
> @@ -739,6 +739,9 @@ ENTRY(__kvm_vcpu_run)
>   // Guest context
>   add x2, x0, #VCPU_CONTEXT
>  
> + // We must restore the 32-bit state before the sysregs, thanks
> + // to Cortex-A57 erratum #852523.
> + restore_guest_32bit_state
>   bl __restore_sysregs
>  
>   skip_debug_state x3, 1f
> @@ -746,7 +749,6 @@ ENTRY(__kvm_vcpu_run)
>   kern_hyp_va x3
>   bl  __restore_debug
>  1:
> - restore_guest_32bit_state
>   restore_guest_regs
>  
>   // That's it, no more messing around.

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

Re: [Xen-devel] [PATCH v11 11/11] (lib)xl: soft reset support

[Vitaly Kuznetsov]

Wei Liu  writes:

> Sorry for the delay.
>
> FYI all other patches of this series were applied by Jan. You only need
> to resend this one.

Cool, I will.

>
> See below for a few comments.
>
> On Fri, Sep 04, 2015 at 03:39:51PM +0200, Vitaly Kuznetsov wrote:
>> Use existing create/restore path to perform 'soft reset' for HVM
>> domains. Tear everything down, e.g. destroy domain's device model,
>> remove the domain from xenstore, save toolstack record and start
>> over.
>> 
>> Signed-off-by: Vitaly Kuznetsov 
>> ---
>> Changes since v10:
>> - Adapt to 'migration v2' changes.
>> - Use LIBXL_DEVICE_MODEL_SAVE_FILE as Qemu save file (and rename it to
>>   LIBXL_DEVICE_MODEL_RESTORE_FILE later) to support stubdom case (as
>>   we connect consoles to both files on create.
>> - Fix coding style, minor description change in xl.cfg.pod.5 [Wei Liu]
>> 
>> Signed-off-by: Vitaly Kuznetsov 
>> ---
>>  docs/man/xl.cfg.pod.5|   8 +-
>>  tools/libxl/libxl.c  |  22 -
>>  tools/libxl/libxl.h  |  15 
>>  tools/libxl/libxl_create.c   | 192 
>> ++-
>>  tools/libxl/libxl_internal.h |   4 +
>>  tools/libxl/libxl_types.idl  |   2 +
>>  tools/libxl/xl.h |   1 +
>>  tools/libxl/xl_cmdimpl.c |  25 +-
>>  8 files changed, 242 insertions(+), 27 deletions(-)
>> 
>> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
>> index c6345b8..d8c4186 100644
>> --- a/docs/man/xl.cfg.pod.5
>> +++ b/docs/man/xl.cfg.pod.5
>> @@ -349,6 +349,12 @@ destroy the domain.
>>  write a "coredump" of the domain to F and then
>>  restart the domain.
>>  
>> +=item B
>> +
>> +Reset all Xen specific interfaces for the Xen-aware HVM domain allowing
>> +it to reestablish these interfaces and continue executing the domain. PV
>> +guest is not supported.
>> +
>
> And "non-Xen-aware HVM will crash" ?

Sorry, I should have replied to that suggestion earlier. Non-Xen-aware
HVM guest can't really trigger this action and (in theory) is capable of
doing kexec without any assistance.

> If there is no definite answer to
> guest state maybe just saying "PV guest and non-Xen-aware HVM guests are
> not supported" ?

This sounds correct.

>
> It's important to let user know about the consequence because libxl
> doesn't actually stop you from soft-resetting a HVM guest that is not
> Xen-aware.

The question is who (and when/how) is going to trigger this action? In
case someone does that while HVM domain (doesn't really matter if it is
Xen-aware or not) does not expect this action it will crash.

*In theory* nothing bad is going to happen to a non-Xen-aware HVM guest
if someone else will trigger this action for it (e.g. on 'reset'
signal), it will just get an assistance it doesn't need.

[...]

-- 
  Vitaly

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

Re: [Xen-devel] [PATCH 1/7] tools/hotplug: remove SELinux options from var-lib-xenstored.mount

[George Dunlap]

On 09/11/2015 07:31 AM, Olaf Hering wrote:
> On Thu, Sep 10, George Dunlap wrote:
> 
>> On Fri, Dec 19, 2014 at 11:25 AM, Olaf Hering  wrote:
>>> Using SELinux mount options per default breaks several systems.
>>> Either the context= mount option is not known at all to the kernel,
>>> as reported for ArchLinux. Or the default value "none" is unknown to
>>> SELinux, as reported for Fedora. In both cases the unit will fail.
>>>
>>> The proper place to specify mount options is /etc/fstab. Appearently
>>> systemd is kind enough to use values from there even if Options= or
>>> What= is specified in a .mount file.
>>
>> For the benefit of someone moonlighting as a CentOS package
>> maintainer, could you tell me how adding such an entry in a package is
>> normally done?  Or alternately, how you would recommend a package
>> maintainer to add the appropriate context?
> 
> George, I know nothing about SELinux.
> I think its either up to a rpm %post install script to fiddle with fstab
> and pray that the added lines fit the system policies. Or its up to the
> documentation team to describe how SELinux is supposed to be configured
> for the third party app "Xen" on CentOS.

Well if you "know nothing about SELinux", and you don't use it, and
don't have any test systems that use it, then why did you assert
"The proper place to specify [an SELinux mount context] is /etc/fstab"?
 This patchset was accepted because you represented it as the "right"
way of doing things.

So poking around CentOS 7, it looks like in most cases, after a tmpfs is
mounted, "restorecon -R $mountpoint" is also run, which restores the
default selinux tags.  Manually starting var-lib-xenstored, then running
restorecon, then manually starting xenstored.service seems to work.  So
at the moment I'm trying to figure out if there's a "right" way to get
restorecon run at the right time  (or alternately, a "right" way to
mount a tmpfs at /var/lib/xenstored such that it happens automatically).

If that doesn't work, then adding a xenstored configuration file that
can contain mount options is probably the best option.

 -George

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

Re: [Xen-devel] [PATCH] KVM: arm64: add workaround for Cortex-A57 erratum #852523

[Will Deacon]

On Mon, Sep 14, 2015 at 04:46:28PM +0100, Marc Zyngier wrote:
> On 14/09/15 16:06, Will Deacon wrote:
> > When restoring the system register state for an AArch32 guest at EL2,
> > writes to DACR32_EL2 may not be correctly synchronised by Cortex-A57,
> > which can lead to the guest effectively running with junk in the DACR
> > and running into unexpected domain faults.
> > 
> > This patch works around the issue by re-ordering our restoration of the
> > AArch32 register aliases so that they happen before the AArch64 system
> > registers. Ensuring that the registers are restored in this order
> > guarantees that they will be correctly synchronised by the core.
> > 
> > Cc: 
> > Cc: Marc Zyngier 
> > Signed-off-by: Will Deacon 
> 
> Reviewed-by: Marc Zyngier 
> 
> I'll queue that together with the next batch of fixes.

Great, thanks Marc.

Will

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

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

[osstest service owner]

flight 61839 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61839/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 61745

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 61745

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  da24ee8f47b2137bc273fa7005060d2feb00da05
baseline version:
 xen  a7b39c8bd6cba3fe1c8012987b9e28bdbac7e92d

Last test of basis61745  2015-09-10 11:13:18 Z4 days
Testing same since61839  2015-09-12 07:49:27 Z2 days1 attempts


People who touched revisions under test:
  Boris Ostrovsky 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Kouya Shimura 
  Stefano Stabellini 
  Wei Liu 

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

[Xen-devel] [linux-3.14 test] 61827: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-vhd   13 guest-saverestore fail REGR. vs. 60666
 test-amd64-i386-xl-qcow2 13 guest-saverestore fail REGR. vs. 60666
 test-amd64-amd64-xl-vhd  19 guest-start.2fail in 61263 REGR. vs. 60666
 test-amd64-amd64-xl-qcow219 guest-start.2fail in 61263 REGR. vs. 60666

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-xsm  3 host-install(3)  broken in 61522 pass in 61827
 test-amd64-i386-libvirt 18 guest-start/debian.repeat fail in 61263 pass in 
61827
 test-amd64-i386-xl-qemuu-ovmf-amd64 12 guest-saverestore fail in 61263 pass in 
61827
 test-amd64-i386-xl-qemuu-debianhvm-amd64 19 guest-start/debianhvm.repeat fail 
in 61263 pass in 61827
 test-amd64-i386-xl-qemut-debianhvm-amd64 18 guest-start.2 fail in 61263 pass 
in 61827
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 19 guest-start/win.repeat fail in 
61263 pass in 61827
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 16 
guest-start/debianhvm.repeat fail in 61522 pass in 61827
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 61522 pass in 61827
 test-amd64-amd64-xl-qcow210 guest-startfail in 61522 pass in 61827
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16 
guest-start/debianhvm.repeat fail in 61522 pass in 61827
 test-amd64-amd64-libvirt-qcow2 10 guest-start  fail in 61742 pass in 61827
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 18 guest-start.2 fail in 61742 pass 
in 61827
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail in 61742 pass in 61827
 test-amd64-amd64-xl-qemuu-ovmf-amd64 19 guest-start/debianhvm.repeat fail in 
61742 pass in 61827
 test-amd64-amd64-xl-vhd  13 guest-saverestore   fail pass in 61263
 test-amd64-amd64-libvirt-xsm 18 guest-start/debian.repeat   fail pass in 61522
 test-amd64-amd64-libvirt-qcow2 13 guest-saverestore fail pass in 61522
 test-amd64-i386-xl-qemuu-ovmf-amd64 19 guest-start/debianhvm.repeat fail pass 
in 61742
 test-amd64-amd64-libvirt-raw 17 guest-start/debian.repeat   fail pass in 61742
 test-amd64-amd64-libvirt-vhd 14 guest-saverestore.2 fail pass in 61742
 test-amd64-i386-libvirt-xsm  18 guest-start/debian.repeat   fail pass in 61742
 test-amd64-i386-libvirt-vhd   9 debian-di-install   fail pass in 61742
 test-amd64-i386-libvirt-raw  18 guest-destroy   fail pass in 61742
 test-amd64-i386-qemuu-rhel6hvm-intel 12 guest-start/redhat.repeat fail pass in 
61742
 test-amd64-amd64-xl-qcow213 guest-saverestore   fail pass in 61742
 test-amd64-i386-xl-qemut-debianhvm-amd64 19 guest-start/debianhvm.repeat fail 
pass in 61742
 test-amd64-amd64-xl-qemuu-winxpsp3 12 guest-saverestore fail pass in 61742
 test-amd64-i386-xl-qemut-win7-amd64  9 windows-install  fail pass in 61742

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-qcow2 13 guest-saverestorefail REGR. vs. 60666
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 
guest-localmigrate/x10 fail blocked in 60666
 test-amd64-amd64-libvirt-qcow2 14 guest-saverestore.2 fail in 61522 REGR. vs. 
60666
 test-amd64-amd64-libvirt-vhd 16 guest-start.2fail in 61522 REGR. vs. 60666
 test-amd64-i386-libvirt-vhd 13 guest-saverestore fail in 61522 REGR. vs. 60666
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 61522 like 60666
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 61522 like 60666
 test-armhf-armhf-libvirt  6 xen-boot fail   like 60666
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  like 60666
 test-armhf-armhf-xl   6 xen-boot fail   like 60666
 test-armhf-armhf-xl-credit2   6 xen-boot fail   like 60666
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 60666
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 60666

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-vhd  11 migrate-support-check fail in 61522 never pass
 test-armhf-armhf-libvirt-vhd  6 xen-boot fail   never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-armhf-armhf-xl-rtds  6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail never pass
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   never pass
 test-armhf-armhf-xl-raw   6 xen-boot fail   never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-armhf-armhf-xl-xsm   6 xen-boot fail   never pass
 

[Xen-devel] [linux-mingo-tip-master test] 61893: regressions - FAIL

[osstest service owner]

flight 61893 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61893/

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-raw   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-raw   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-libvirt-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-vhd1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 

[Xen-devel] [linux-3.18 test] 61882: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail REGR. vs. 58581

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 58581
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail baseline untested
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail baseline untested
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16 
guest-start/debianhvm.repeat fail baseline untested
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail baseline 
untested
 test-amd64-amd64-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-xl-credit2   6 xen-boot fail   like 58581
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail   like 58581
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  like 58581
 test-armhf-armhf-xl   6 xen-boot fail   like 58581
 test-armhf-armhf-xl-xsm   6 xen-boot fail   like 58581
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 58581
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 58581
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 58581

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-amd64-i386-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-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail   never pass

version targeted for testing:
 linuxfcd9bfdb9d884f1aab89124dee894e7d821bb5dc
baseline version:
 linuxd048c068d00da7d4cfa5ea7651933b99026958cf

Last test of basis58581  2015-06-15 09:42:22 Z   91 days
Failing since 58976  2015-06-29 19:43:23 Z   77 days   58 attempts
Testing same since61524  2015-09-07 11:48:03 Z7 days4 attempts


462 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] [v2][PATCH] xen/vtd/iommu: permit group devices to passthrough in relaxed mode

[Chen, Tiejun]

But looks its not better, so any idea?


Did you at least make an attempt to find other examples of where
we dynamically determine the log level to be used for a message?
I would assume that if you did, you'd have come to

 printk(XENLOG_GUEST "%s" VTDPREFIX


I didn't know this tip on Xen side and its really good.


" It's %s to assign %04x:%02x:%02x.%u"
" with shared RMRR at %"PRIx64" for Dom%d.\n",
relaxed ? XENLOG_WARNING : XENLOG_ERROR,
relaxed ? "risky" : "disallowed",
seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
rmrr->base_address, d->domain_id);

pretty naturally.



But I noticed my original patch is already merged into staging. So

Wei,

Do you think if we need a small patch to improved this? Maybe you can 
squash that if necessary.


Thanks
Tiejun

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

[Xen-devel] [xen-4.5-testing test] 61844: regressions - FAIL

[osstest service owner]

flight 61844 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61844/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   9 debian-installfail REGR. vs. 61513
 test-amd64-i386-xl-vhd9 debian-di-install fail REGR. vs. 61513

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-vhd  14 guest-saverestore.2   fail REGR. vs. 61309
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 61513
 test-amd64-i386-xl-qemuu-winxpsp3 13 guest-localmigrate   fail REGR. vs. 61513
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail blocked in 61513
 test-amd64-amd64-libvirt-raw  9 debian-di-installfail   like 61513
 test-amd64-i386-libvirt-raw   9 debian-di-installfail   like 61513
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 61513
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 61513
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 61513

Tests which did not succeed, but are not blocking:
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 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-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 build-amd64-prev  5 xen-buildfail   never pass
 build-i386-prev   5 xen-buildfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass

version targeted for testing:
 xen  ffb4e6387f489b6b5ce287f51db43cb37ebae064
baseline version:
 xen  ef89dc8c00087c8c1819e60bdad5527db70425e1

Last test of basis61513  2015-09-07 11:42:18 Z7 days
Failing since 61751  2015-09-10 14:07:54 Z4 days2 attempts
Testing same since61844  2015-09-12 15:58:20 Z2 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anshul Makkar 
  Aravind Gopalakrishnan 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jim Fehlig 
  Julien Grall 
  Roger Pau Monné 
  Wei Liu 

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

[Xen-devel] [PATCH] x86/p2m: fix mismatched unlock

[Jan Beulich]

Luckily, due to gfn_unlock() currently mapping to p2m_unlock(), this is
only a cosmetic issue right now.

Signed-off-by: Jan Beulich 
---
Despite its cosmetic nature I think it would be better to also fix this
in 4.6.

--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -912,7 +912,7 @@ static int set_typed_p2m_entry(struct do
 omfn = p2m->get_entry(p2m, gfn, , , 0, NULL, NULL);
 if ( p2m_is_grant(ot) || p2m_is_foreign(ot) )
 {
-p2m_unlock(p2m);
+gfn_unlock(p2m, gfn, 0);
 domain_crash(d);
 return -ENOENT;
 }



x86/p2m: fix mismatched unlock

Luckily, due to gfn_unlock() currently mapping to p2m_unlock(), this is
only a cosmetic issue right now.

Signed-off-by: Jan Beulich 
---
Despite its cosmetic nature I think it would be better to also fix this
in 4.6.

--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -912,7 +912,7 @@ static int set_typed_p2m_entry(struct do
 omfn = p2m->get_entry(p2m, gfn, , , 0, NULL, NULL);
 if ( p2m_is_grant(ot) || p2m_is_foreign(ot) )
 {
-p2m_unlock(p2m);
+gfn_unlock(p2m, gfn, 0);
 domain_crash(d);
 return -ENOENT;
 }
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

flight 61803 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61803/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 61525

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 seabios  75cb2b962d9c9e55afc5bae58d770f6ccdc826da
baseline version:
 seabios  ff28e3bb17b07baf8eac7be2c0aa958b7497f572

Last test of basis61525  2015-09-07 11:47:41 Z6 days
Testing same since61803  2015-09-11 18:09:27 Z2 days1 attempts


People who touched revisions under test:
  Kevin O'Connor 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [v2][PATCH] xen/vtd/iommu: permit group devices to passthrough in relaxed mode

[Tian, Kevin]

> From: Chen, Tiejun
> Sent: Monday, September 14, 2015 2:25 PM
> 
> > OK, that explanation is fine to me as long as it's made clear no
> > security guarantee once admin uses 'relax' for any domain. Tiejun
> > could you resend patch with right warning/error type?
> >
> 
> Sure, but a little bit makes me confused when I'm trying to address
> this. Actually most messages are same, except for logevel, so I did this
> like,
> 
>  printk(XENLOG_G_INFO VTDPREFIX " Assign %04x:%02x:%02x.%u"
> " with shared RMRR at %"PRIx64" for Dom%d.",
> seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
> rmrr->base_address, d->domain_id);
>  if ( relaxed )
>  printk(XENLOG_G_WARNING VTDPREFIX " It's really risky.");
>  else
>  printk(XENLOG_G_ERR VTDPREFIX " So it's disallowed!");
>  printk(XENLOG_G_INFO VTDPREFIX "\n");
> 
> But looks its not better, so any idea?
> 

en... not good. I'm going to ack original patch instead.

Thanks
Kevin

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

Re: [Xen-devel] [v2][PATCH] xen/vtd/iommu: permit group devices to passthrough in relaxed mode

[Tian, Kevin]

> From: Chen, Tiejun
> Sent: Wednesday, September 09, 2015 10:00 AM
> 
> Currently we don't allow passing through any group devices which are
> sharing same RMRR entry since it would break security among VMs. And
> indeed, we expect we can figure out a better way to handle this kind
> of case completely.
> 
> But before the group assignment gets implemented, we might make this
> permission dependent on our RMRR policy. So, now it would be allowed
> in the relaxed mode.
> 
> CC: Yang Zhang 
> CC: Kevin Tian 
> CC: Jan Beulich 
> CC: Wei Liu 
> Signed-off-by: Tiejun Chen 

Acked-by: Kevin Tian 

Thanks
Kevin


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

Re: [Xen-devel] [PATCH v11 11/11] (lib)xl: soft reset support

[Wei Liu]

On Mon, Sep 14, 2015 at 06:54:51PM +0200, Vitaly Kuznetsov wrote:
> Wei Liu  writes:
> 
> > Sorry for the delay.
> >
> > FYI all other patches of this series were applied by Jan. You only need
> > to resend this one.
> 
> Cool, I will.
> 
> >
> > See below for a few comments.
> >
> > On Fri, Sep 04, 2015 at 03:39:51PM +0200, Vitaly Kuznetsov wrote:
> >> Use existing create/restore path to perform 'soft reset' for HVM
> >> domains. Tear everything down, e.g. destroy domain's device model,
> >> remove the domain from xenstore, save toolstack record and start
> >> over.
> >> 
> >> Signed-off-by: Vitaly Kuznetsov 
> >> ---
> >> Changes since v10:
> >> - Adapt to 'migration v2' changes.
> >> - Use LIBXL_DEVICE_MODEL_SAVE_FILE as Qemu save file (and rename it to
> >>   LIBXL_DEVICE_MODEL_RESTORE_FILE later) to support stubdom case (as
> >>   we connect consoles to both files on create.
> >> - Fix coding style, minor description change in xl.cfg.pod.5 [Wei Liu]
> >> 
> >> Signed-off-by: Vitaly Kuznetsov 
> >> ---
> >>  docs/man/xl.cfg.pod.5|   8 +-
> >>  tools/libxl/libxl.c  |  22 -
> >>  tools/libxl/libxl.h  |  15 
> >>  tools/libxl/libxl_create.c   | 192 
> >> ++-
> >>  tools/libxl/libxl_internal.h |   4 +
> >>  tools/libxl/libxl_types.idl  |   2 +
> >>  tools/libxl/xl.h |   1 +
> >>  tools/libxl/xl_cmdimpl.c |  25 +-
> >>  8 files changed, 242 insertions(+), 27 deletions(-)
> >> 
> >> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> >> index c6345b8..d8c4186 100644
> >> --- a/docs/man/xl.cfg.pod.5
> >> +++ b/docs/man/xl.cfg.pod.5
> >> @@ -349,6 +349,12 @@ destroy the domain.
> >>  write a "coredump" of the domain to F and then
> >>  restart the domain.
> >>  
> >> +=item B
> >> +
> >> +Reset all Xen specific interfaces for the Xen-aware HVM domain allowing
> >> +it to reestablish these interfaces and continue executing the domain. PV
> >> +guest is not supported.
> >> +
> >
> > And "non-Xen-aware HVM will crash" ?
> 
> Sorry, I should have replied to that suggestion earlier. Non-Xen-aware
> HVM guest can't really trigger this action and (in theory) is capable of
> doing kexec without any assistance.
> 
> > If there is no definite answer to
> > guest state maybe just saying "PV guest and non-Xen-aware HVM guests are
> > not supported" ?
> 
> This sounds correct.
> 
> >
> > It's important to let user know about the consequence because libxl
> > doesn't actually stop you from soft-resetting a HVM guest that is not
> > Xen-aware.
> 
> The question is who (and when/how) is going to trigger this action? In
> case someone does that while HVM domain (doesn't really matter if it is
> Xen-aware or not) does not expect this action it will crash.
> 
> *In theory* nothing bad is going to happen to a non-Xen-aware HVM guest
> if someone else will trigger this action for it (e.g. on 'reset'
> signal), it will just get an assistance it doesn't need.
> 

OK then. We should still make it clear it is unsupported for
non-Xen-aware HVM guest even if it happens to work.

Wei.

> [...]
> 
> -- 
>   Vitaly

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

Re: [Xen-devel] [PATCH 1/7] tools/hotplug: remove SELinux options from var-lib-xenstored.mount

[Olaf Hering]

On Mon, Sep 14, George Dunlap wrote:

> Well if you "know nothing about SELinux", and you don't use it, and
> don't have any test systems that use it, then why did you assert
> "The proper place to specify [an SELinux mount context] is /etc/fstab"?
>  This patchset was accepted because you represented it as the "right"
> way of doing things.

Because at that time the way SELinux was handled failed on systems which
had SELinux disabled, or which did not recognize the option.
And I still think that mount options have to go into fstab.

Olaf

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

[Xen-devel] [qemu-upstream-4.4-testing test] 61799: regressions - FAIL

[osstest service owner]

flight 61799 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61799/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-vhd9 debian-di-install fail REGR. vs. 60565

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate fail in 61723 pass 
in 61799
 test-amd64-amd64-xl-qemuu-ovmf-amd64 19 guest-start/debianhvm.repeat fail in 
61723 pass in 61799
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 
61617
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate.2 fail pass in 61723

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-raw   9 debian-di-install fail REGR. vs. 60565
 test-amd64-amd64-libvirt 11 guest-start  fail   like 60565
 test-amd64-i386-libvirt  11 guest-start  fail   like 60565

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 61617 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail in 61617 never pass
 test-amd64-amd64-xl-raw   9 debian-di-installfail   never pass
 test-amd64-i386-libvirt-qcow2  9 debian-di-installfail  never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-i386-libvirt-pair 20 guest-start/debian   fail   never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu181e2e0ff39cbfeab173fa6d6b31839f00efcd06
baseline version:
 qemuu0fc147387f0b683d2dfefec7b1af569f17b72e9c

Last test of basis60565  2015-08-04 01:59:38 Z   41 days
Testing same since61617  2015-09-08 12:10:54 Z5 days3 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Peter Lieven 

jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt fail
 test-amd64-i386-libvirt  fail
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-libvirt-pairfail
 test-amd64-i386-libvirt-pair fail
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-libvirt-qcow2   pass
 test-amd64-i386-libvirt-qcow2fail
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-qcow2 pass
 test-amd64-amd64-libvirt-raw 

Re: [Xen-devel] [v2][PATCH] xen/vtd/iommu: permit group devices to passthrough in relaxed mode

[Chen, Tiejun]

OK, that explanation is fine to me as long as it's made clear no
security guarantee once admin uses 'relax' for any domain. Tiejun
could you resend patch with right warning/error type?



Sure, but a little bit makes me confused when I'm trying to address 
this. Actually most messages are same, except for logevel, so I did this 
like,


printk(XENLOG_G_INFO VTDPREFIX " Assign %04x:%02x:%02x.%u"
   " with shared RMRR at %"PRIx64" for Dom%d.",
   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
   rmrr->base_address, d->domain_id);
if ( relaxed )
printk(XENLOG_G_WARNING VTDPREFIX " It's really risky.");
else
printk(XENLOG_G_ERR VTDPREFIX " So it's disallowed!");
printk(XENLOG_G_INFO VTDPREFIX "\n");

But looks its not better, so any idea?

Thanks
Tiejun

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

[Xen-devel] Pv-grub and vTPM PCR extension

[Marcos Simo PIco]

Hi all,

I've been playing with vTPMs without any issue. I used to boot guests by 
providing the kernel from dom0. Then I wanted to boot my guests using 
pv-grub. Pv-grub succeeds connecting to the vTPM, however, PCRs are not 
extended. The only PCR reflecting measurements is PCR10 (IMA).


vTPMs seems to work properly in either cases, but I expected PCRs 4-5 to 
be extended when booting with pv-grub. Am I missing something?


This is how the guest's config file looks like:

#PV-GRUB
kernel = '/usr/lib/grub-xen/grub-x86_64-xen.bin'
extra = '(hd0,0)/boot/grub/menu.lst'
root = ''
#PV-GRUB

vcpus = '1'
memory = '3072'
disk=['tap:aio:/root/domu.img,xvda1,w']
name = 'domU'
vif = [ '','bridge=xenbr0']
dhcp = "dhcp"
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
vtpm=["backend=vtpm"]

Thanks for any help you can provide.

Best,
Marcos.

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

Re: [Xen-devel] [PATCH v3 1/4] x86: Support enable CDP by boot parameter and add get CDP status

[Chao Peng]

On Mon, Sep 14, 2015 at 11:27:04AM +0800, He Chen wrote:
> @@ -1165,9 +1165,9 @@ This option can be specified more than once (up to 8 
> times at present).
>  > `= `
>  
>  ### psr (Intel)
> -> `= List of ( cmt: | rmid_max: | cat: | 
> cos_max: )`
> +> `= List of ( cmt: | rmid_max: | cat: | 
> cos_max: | cdp: )`
>  
> -> Default: `psr=cmt:0,rmid_max:255,cat:0,cos_max:255`
> +> Default: `psr=cmt:0,rmid_max:255,cat:0,cos_max:255,cdp:0`
>  
>  Platform Shared Resource(PSR) Services.  Intel Haswell and later server
>  platforms offer information about the sharing of resources.
> @@ -1197,6 +1197,10 @@ The following resources are available:
>the cache allocation.
>* `cat` instructs Xen to enable/disable Cache Allocation Technology.
>* `cos_max` indicates the max value for COS ID.
> +* Code and Data Prioritization Technology (Broadwell and later). Information
> +  regarding the code cache and the data cache allocation. CDP is based on 
> CAT.
> +  * `cdp` instructs Xen to enable/disable Code and Data Prioritization.

It's better to have some description for cos_max here (e.g. if the
meaning is the same for CAT and CDP).

>  
>  set_bit(socket, cat_socket_enable);
> -printk(XENLOG_INFO "CAT: enabled on socket %u, cos_max:%u, 
> cbm_len:%u\n",
> -   socket, info->cos_max, info->cbm_len);

Then there will be no output in CAT-only mode. Probably not good just to
remove it. I guess you can add cdp information to it and then move it to
the end of the function.

> +
> +if ( (ecx & PSR_CAT_CDP_CAPABILITY) && (opt_psr & PSR_CDP) )
> +{
> +if ( test_bit(socket, cdp_socket_enable) )
> +return;
> +
> +rdmsrl(MSR_IA32_PSR_L3_QOS_CFG, val);
> +wrmsrl(MSR_IA32_PSR_L3_QOS_CFG, val | 1 << 
> PSR_L3_QOS_CDP_ENABLE_BIT);
> +
> +info->cos_to_cbm[0].u.cdp.code = (1ull << info->cbm_len) - 1;
> +info->cos_to_cbm[0].u.cdp.data = (1ull << info->cbm_len) - 1;
> +
> +/* We only write mask1 since mask0 is always all ones by default 
> */

Missing '.'

> +wrmsrl(MSR_IA32_PSR_L3_MASK(1), (1ull << info->cbm_len) - 1);
> +
> +/* Cut half of cos_max when CDP enabled */

Ditto.

> +info->cos_max = info->cos_max / 2;
> +
> +set_bit(socket, cdp_socket_enable);
> +printk(XENLOG_INFO "CDP: enabled on socket %u, cos_max:%u, 
> cbm_len:%u\n",
> +   socket, info->cos_max, info->cbm_len);
> +}
>  }
>  }
>  
> @@ -508,6 +557,8 @@ static void cat_cpu_fini(unsigned int cpu)
>  {
>  struct psr_cat_socket_info *info = cat_socket_info + socket;
>  
> +clear_bit(socket, cdp_socket_enable);
> +

It's better to move this below, together with that of cat_socket_enable.

>  if ( info->cos_to_cbm )
>  {
>  xfree(info->cos_to_cbm);
> @@ -523,6 +574,8 @@ static void __init psr_cat_free(void)
>  cat_socket_enable = NULL;
>  xfree(cat_socket_info);
>  cat_socket_info = NULL;
> +xfree(cdp_socket_enable);
> +cdp_socket_enable = NULL;
>  }
>  

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

Re: [Xen-devel] [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux

[Roger Pau Monné]

El 07/09/15 a les 17.33, Julien Grall ha escrit:
> Hi all,
> 
> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
> hypercall interface and PV protocol are always based on 4KB page granularity.
> 
> Any attempt to boot a Linux guest with 64KB pages enabled will result to a
> guest crash.
> 
> This series is a first attempt to allow those Linux running with the current
> hypercall interface and PV protocol.
> 
> This solution has been chosen because we want to run Linux 64KB in released
> Xen ARM version or/and platform using an old version of Linux DOM0.
> 
> There is room for improvement, such as support of 64KB grant, modification
> of PV protocol to support different page size... They will be explored in a
> separate patch series later.
> 
> TODO list:
> - Convert swiotlb to 64KB
> - Convert xenfb to 64KB
> - Support for multiple page ring support
> - Support for 64KB in gnttdev
> - Support of non-indirect grant with 64KB frontend
> - It may be possible to move some common define between
> netback/netfront and blkfront/blkback in an header
> 
> I've got most of the patches for the TODO items. I'm planning to send them as
> a follow-up as it's not a requirement for a basic guests.
> 
> All patches has been built tested for ARM32, ARM64, x86. But I haven't tested
> to run it on x86 as I don't have a box with Xen x86 running. I would be
> happy if someone give a try and see possible regression for x86.

Do you have figures regarding if/how much performance penalty do the
blkfront/blkback patches add to the traditional 4KB scenario (frontend
and backend running on guests using 4KB pages)?

Since there's been no design document about this and the TODO list
doesn't contain it, I would like to know which plans do we have in order
to fix this properly.

Roger.


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

Re: [Xen-devel] [PATCH v4 0/5] sched: credit2: introduce per-vcpu hard and soft affinity

[Dario Faggioli]

On Sun, 2015-07-12 at 22:13 -1000, Justin T. Weaver wrote:
> Hello,
> 
Hey Justin!

Sorry a ton for being so late again.

I'm now back at work after travelling and some vacations.

I'll be reviewing this ASAP, right after having done a bit of catch up
with the email backlog accumulated during this period... I should be
able to start the review today or, at most, tomorrow.

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


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