Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Yu, Zhang]

On 2/4/2016 5:28 PM, Paul Durrant wrote:

-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 04 February 2016 08:51
To: George Dunlap; Ian Jackson
Cc: Paul Durrant; Kevin Tian; Wei Liu; Ian Campbell; Andrew Cooper; xen-
de...@lists.xen.org; Stefano Stabellini; zhiyuan...@intel.com; Jan Beulich;
Keir (Xen.org)
Subject: Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter
max_wp_ram_ranges.



On 2/4/2016 2:21 AM, George Dunlap wrote:

On Wed, Feb 3, 2016 at 5:41 PM, George Dunlap
 wrote:

I think at some point I suggested an alternate design based on marking
such gpfns with a special p2m type; I can't remember if that
suggestion was actually addressed or not.


FWIW, the thread where I suggested using p2m types was in response to

<1436163912-1506-2-git-send-email-yu.c.zh...@linux.intel.com>

Looking through it again, the main objection Paul gave[1]  was:

"And it's the assertion that use of write_dm will only be relevant to
gfns, and that all such notifications only need go to a single ioreq
server, that I have a problem with. Whilst the use of io ranges to
track gfn updates is, I agree, not ideal I think the overloading of
write_dm is not a step in the right direction."

Two issues raised here, about using only p2m types to implement

write_dm:

1. More than one ioreq server may want to use the write_dm functionality
2. ioreq servers may want to use write_dm for things other than individual

gpfns


My answer to #1 was:
1. At the moment, we only need to support a single ioreq server using

write_dm

2. It's not technically difficult to extend the number of servers
supported to something sensible, like 4 (using 4 different write_dm
p2m types)
3. The interface can be designed such that we can extend support to
multiple servers when we need to.

My answer to #2 was that there's no reason why using write_dm could be
used for both individual gpfns and ranges; there's no reason the
interface can't take a "start" and "count" argument, even if for the
time being "count" is almost always going to be 1.



Well, talking about "the 'count' always going to be 1". I doubt that. :)
Statistics in XenGT shows that, GPU page tables are very likely to
be allocated in contiguous gpfns.


Compare this to the downsides of the approach you're proposing:
1. Using 40 bytes of hypervisor space per guest GPU pagetable page (as
opposed to using a bit in the existing p2m table)
2. Walking down an RB tree with 8000 individual nodes to find out
which server to send the message to (rather than just reading the
value from the p2m table).


8K is an upper limit for the rangeset, in many cases the RB tree will
not contain that many nodes.


3. Needing to determine on a guest-by-guest basis whether to change the

limit

4. Needing to have an interface to make the limit even bigger, just in
case we find workloads that have even more GTTs.



Well, I have suggested in yesterday's reply. XenGT can choose not to
change this limit even when workloads are getting heavy - with
tradeoffs in the device model side.


I assume this means that the emulator can 'unshadow' GTTs (I guess on an LRU 
basis) so that it can shadow new ones when the limit has been exhausted?
If so, how bad is performance likely to be if we live with a lower limit and 
take the hit of unshadowing if the guest GTTs become heavily fragmented?


Thank you, Paul.

Well, I was told the emulator have approaches to delay the shadowing of
the GTT till future GPU commands are submitted. By now, I'm not sure
about the performance penalties if the limit is set too low. Although
we are confident 8K is a secure limit, it seems still too high to be
accepted. We will perform more experiments with this new approach to
find a balance between the lowest limit and the XenGT performance.

So another question is, if value of this limit really matters, will a
lower one be more acceptable(the current 256 being not enough)?

Thanks
Yu
find a

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

Re: [Xen-devel] new idl helper, append to Array

[Ian Campbell]

On Thu, 2016-02-04 at 10:23 +0100, Olaf Hering wrote:
> Ian,
> 
> in my pvscsi code I have two copies of a helper function which appends
> yet another instance of something to an Array, as shown below. This is
> similar to the _copy variant. Is it worth to let gentypes generate such
> a helper, like libxl_device_vscsictrl_append_vscsidev()?

If something can be autogenerated without too much trouble then I see no
reason not to do so.

I'd go with libxl__list_append as the naming scheme, which fits in
with libxl__list_free (which probably ought to be autogenerated too,
but isn't). So:

libxl_device_vscsidev_list_append(libxl_ctx *ctx,
                                  libxl_device_vscsidev *dev, int nr,
  libxl_device_vscsidev *new);
(if you intend for this to be internal then s/^libxl_/&_/ and
s/libxl_ctx \*ctx/libxl__gc *gc/)

Oh, I see you want it to take the type containing the array, that could
work to, you'd need to call it libxl__append_, so

libxl_device_vscsictrl_append_vscsidevs

which looks a bit odd (since the field name is plural and the IDL has no
way to find the singular). We could live with that, or s/append/append_to/
or make it varargs and take perhaps multiple new entries and a NULL
terminator.

I think the append_to variant is probably least gross.

Looks like various places such as libxl__append_nic_list_of_type could make
use of this helper too. As could xl_cmdimpl.c for ARRAY_EXTEND_INIT perhaps
(using it everywhere isn't mandatory of course, but if you feel inclined it
would be nice)

> While writing this I realize that libxl__realloc will not return, so my
> helper can be converted from returning int to void, and all the locals
> can be removed.

Indeed.

> static int vscsi_append_dev(libxl__gc *gc, libxl_device_vscsictrl *ctrl,
> libxl_device_vscsidev *dev)
> {
> int rc;
> libxl_device_vscsidev *devs;
> 
> devs = libxl__realloc(NOGC, ctrl->vscsidevs, sizeof(*dev) * 
> (ctrl->num_vscsidevs + 1));
> if (!devs) {
> rc = ERROR_NOMEM;
> goto out;
> }
> 
> ctrl->vscsidevs = devs;
> libxl_device_vscsidev_init(ctrl->vscsidevs + ctrl->num_vscsidevs);
> libxl_device_vscsidev_copy(CTX, ctrl->vscsidevs + ctrl->num_vscsidevs, 
> dev);

Wei, is it necessary to init the dst before copy into it?

> ctrl->num_vscsidevs++;
> rc = 0;
> out:
> return rc;
> }
> 
> 
> Olaf

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

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Jan Beulich]

>>> On 04.02.16 at 10:38,  wrote:
> So another question is, if value of this limit really matters, will a
> lower one be more acceptable(the current 256 being not enough)?

If you've carefully read George's replies, a primary aspect is
whether we wouldn't better revert commit f5a32c5b8e
("x86/HVM: differentiate IO/mem resources tracked by ioreq
server"), as with the alternative approach we wouldn't even
need HVMOP_IO_RANGE_WP_MEM afaict. And then the question
you raise would become irrelevant.

The part of the public interface being tools only allows some
freedom in when to do this, but I think it would be a bad idea
to ship 4.7 with this still in if you're not going to pursue this
route.

Jan


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

Re: [Xen-devel] [PATCH] tools: libxc: do not redefine evtchn_port_or_error_t in xc_evtchn_compat.c

[Wei Liu]

On Thu, Feb 04, 2016 at 10:19:55AM +, Ian Campbell wrote:
> Adding Olaf, I forgot that Reported-by doesn't turn into a Cc.
> 
> On Thu, 2016-02-04 at 10:15 +, Ian Campbell wrote:
> > This file stradles the xenevtchn and libxc evtchn_compat worlds, and
> > hence ends up with two evtchn_port_or_error_t typedefs which older
> > gcc's (and the C standard) do not like.
> > 
> > Avoid this by gating the compat definition on a gate provided by the
> > compat implementation.
> > 
> > Note that this would still be broken by an application which does:
> > #define XC_WANT_COMPAT_EVTCHN_API
> > #include 
> > #include 
> > 
> > Which effectively means that an application must be ported over to
> > xenevtchn in one go rather than incrementally (e.g. if it uses
> > evtchn's for multiple purposes). Since the port is actually fairly
> > mechanical I hope this is acceptable.
> > 
> > Reported-by: Olaf Hering 
> > Signed-off-by: Ian Campbell 
> > Cc: Andrew Cooper 
> > ---
> > I'm not super happy about this approach, due to the caveat in the
> > second half of the commit message.
> > 
> > Other approaches:
> > 
> > rename the libxenevtchn type, e.g.  xenevtchn_port_or_error_t?
> 
> Thinking about this some more this might be the best approach. The type is
> not used by qemu-xen, it is used by qemu-xen-traditional but we can fix
> that in lockstep.
> 
> All of the in tree users are easy, of course.
> 
> Thoughts?
> 

+1 for this

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

Re: [Xen-devel] [PATCH v2 07/11] xen/hvmlite: Initialize context for secondary VCPUs

[David Vrabel]

On 02/02/16 16:58, Boris Ostrovsky wrote:
> On 02/02/2016 11:21 AM, David Vrabel wrote:
>> This needs some more description in the commit message.
>>
>>> --- a/arch/x86/xen/smp.c
>>> +++ b/arch/x86/xen/smp.c
>> [...]
>>> +hctxt->cpu_regs.x86_32.cs_base = 0;
>>> +hctxt->cpu_regs.x86_32.cs_limit = ~0u;
>>> +hctxt->cpu_regs.x86_32.cs_ar = 0xc9b;
>>> +hctxt->cpu_regs.x86_32.ds_base = 0;
>>> +hctxt->cpu_regs.x86_32.ds_limit = ~0u;
>>> +hctxt->cpu_regs.x86_32.ds_ar = 0xc93;
>>> +hctxt->cpu_regs.x86_32.es_base = 0;
>>> +hctxt->cpu_regs.x86_32.es_limit = ~0u;
>>> +hctxt->cpu_regs.x86_32.es_ar = 0xc93;
>>> +hctxt->cpu_regs.x86_32.ss_base = 0;
>>> +hctxt->cpu_regs.x86_32.ss_limit = ~0u;
>>> +hctxt->cpu_regs.x86_32.ss_ar = 0xc93;
>>> +hctxt->cpu_regs.x86_32.tr_base = 0;
>>> +hctxt->cpu_regs.x86_32.tr_limit = 0xff;
>>> +hctxt->cpu_regs.x86_32.tr_ar = 0x8b;
>> Lots of hard-coded values here.  Should this be #defined somewhere?
> 
> We also don't need to set bases to zero since hctxt is kzalloc'd. I'll
> remove that and add a comment.
> 
> As for macros --- I couldn't find the bits defined symbolically anywhere
> and since this is the only place this is used the macros would be local
> here.

Ok.

David

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

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Ian Campbell]

On Thu, 2016-02-04 at 10:49 +, George Dunlap wrote:
> On Thu, Feb 4, 2016 at 8:51 AM, Yu, Zhang 
> wrote:
> > > Going forward, we probably will, at some point, need to implement a
> > > parallel "p2t" structure to keep track of types -- and probably will
> > > whether end up implementing 4 separate write_dm types or not (for the
> > > reasons you describe).
> > > 
> > 
> > Thank you, George. Could you please elaborate more about the idea of
> > "p2t"?
> 
> So the p2m table is a partially-sparse structure designed to map pfns
> to mfns.  At the bottom is a 64-bit entry that contains certain bits
> specified by the hardware (mfn number, permissions, other features).
> There are at the moment extra bits that aren't use, and in these bits
> we store information about the pfn that Xen wants to know -- among
> other things, the 'type' of the gpfn.
> 
> But as Andy pointed out, Intel are adding new features which take up
> more of these bits; and at the same time, Xen has more features for
> which using a p2m type is the most obvious solution.  So the idea
> would be to have a separate structure, similar to the p2m table, but
> wouldn't be used by the hardware -- it would only be used by Xen to
> map pfn to type (or whatever other information it wanted about the
> gpfn).  This does mean duplicating all the non-leaf nodes, as well as
> doing two sparse-tree-walks rather  than just one when looking up gpfn
> information.

FWIW ARM already has such a structure to support xenaccess, since ARM had
far fewer available bits to start with.

It is not quite the same as above since it is only populated with pages for
which xenaccess is in use rather than all pages (and is only consulted if
we have reason to believe the page might be subject to xenaccess). FWIW it
uses Xen's radix tree stuff.

Ian.

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

Re: [Xen-devel] [PATCH v7 08/18] tools/libxl: introduce libxl__domain_restore_device_model to load qemu state

[Wei Liu]

On Thu, Feb 04, 2016 at 01:24:41PM +0800, Wen Congyang wrote:
> On 02/04/2016 03:40 AM, Wei Liu wrote:
> > On Fri, Jan 29, 2016 at 01:27:24PM +0800, Wen Congyang wrote:
> >> In normal migration, the qemu state is passed to qemu as a parameter.
> >> With COLO, secondary vm is running. So we will do the following steps
> >> at every checkpoint:
> >> 1. suspend both primary vm and secondary vm
> >> 2. sync the state
> >> 3. resume both primary vm and secondary vm
> >> Primary will send qemu's state in step2, and secondary's qemu should
> >> read it and restore the state before it is resumed. We can not pass
> >> the state to qemu as a parameter because secondary QEMU already started
> >> at this point, so we introduce libxl__domain_restore_device_model() to
> >> do it. This API MUST be called before resuming secondary vm.
> >>
> >> Signed-off-by: Yang Hongyang 
> >> Signed-off-by: Wen Congyang 
> >> Cc: Anthony Perard 
> >> ---
> >>  tools/libxl/libxl_dom_save.c | 20 
> >>  tools/libxl/libxl_internal.h |  4 
> >>  tools/libxl/libxl_qmp.c  | 10 ++
> >>  3 files changed, 34 insertions(+)
> >>
> >> diff --git a/tools/libxl/libxl_dom_save.c b/tools/libxl/libxl_dom_save.c
> >> index cd2e7de..7383d2d 100644
> >> --- a/tools/libxl/libxl_dom_save.c
> >> +++ b/tools/libxl/libxl_dom_save.c
> >> @@ -518,6 +518,26 @@ int 
> >> libxl__restore_emulator_xenstore_data(libxl__domain_create_state *dcs,
> >>  return rc;
> >>  }
> >>  
> >> +int libxl__domain_restore_device_model(libxl__gc *gc, uint32_t domid,
> >> +   const char *restore_file)
> >> +{
> >> +int rc;
> >> +
> >> +switch (libxl__device_model_version_running(gc, domid)) {
> >> +case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
> >> +/* Will never be supported. */
> >> +rc = ERROR_INVAL;
> >> +break;
> > 
> > I'm not entirely sure if this statement would be true. The function name
> > is generic enough to indicate this case should be supported.
> > 
> > However, this function is not used anywhere in this series, so I don't
> > know whether my comment makes sense.
> > 
> > One way of moving forward is to stick this patch to COLO series itself.
> > Let's skip this in this prerequisite series.
> 
> OK, I will put it in the COLO series itself.
> This API is used for COLO, and COLO requries the newest qemu with block 
> replication.
> The block replication is still in the way. The tranditional qemu doesn't 
> support
> block replication and it is hard to backport it.
> 

OK. I'm asking you to support qemu-trad in COLO -- definitely not.

What I was getting at was: this function has a very generic name, which
suggests it will be used to consolidate some code inside libxl. I was
confused because it didn't handle the qemu-trad path (after all,
restoring device model is something you can do with qemu-trad).

As discussed, this patch will be moved to COLO series, let's discuss
that when you post this again.

Wei.

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

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Paul Durrant]

> -Original Message-
[snip]
> >>> Compare this to the downsides of the approach you're proposing:
> >>> 1. Using 40 bytes of hypervisor space per guest GPU pagetable page (as
> >>> opposed to using a bit in the existing p2m table)
> >>> 2. Walking down an RB tree with 8000 individual nodes to find out
> >>> which server to send the message to (rather than just reading the
> >>> value from the p2m table).
> >>
> >> 8K is an upper limit for the rangeset, in many cases the RB tree will
> >> not contain that many nodes.
> >>
> >>> 3. Needing to determine on a guest-by-guest basis whether to change
> the
> >> limit
> >>> 4. Needing to have an interface to make the limit even bigger, just in
> >>> case we find workloads that have even more GTTs.
> >>>
> >>
> >> Well, I have suggested in yesterday's reply. XenGT can choose not to
> >> change this limit even when workloads are getting heavy - with
> >> tradeoffs in the device model side.
> >
> > I assume this means that the emulator can 'unshadow' GTTs (I guess on an
> LRU basis) so that it can shadow new ones when the limit has been
> exhausted?
> > If so, how bad is performance likely to be if we live with a lower limit and
> take the hit of unshadowing if the guest GTTs become heavily fragmented?
> >
> Thank you, Paul.
> 
> Well, I was told the emulator have approaches to delay the shadowing of
> the GTT till future GPU commands are submitted. By now, I'm not sure
> about the performance penalties if the limit is set too low. Although
> we are confident 8K is a secure limit, it seems still too high to be
> accepted. We will perform more experiments with this new approach to
> find a balance between the lowest limit and the XenGT performance.
> 
> So another question is, if value of this limit really matters, will a
> lower one be more acceptable(the current 256 being not enough)?

Well, do you know conclusively that 256 is absolutely not enough, or is it just 
too low for acceptable performance?

  Paul

> 
> Thanks
> Yu
> find a
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] new idl helper, append to Array

[Olaf Hering]

On Thu, Feb 04, Ian Campbell wrote:

> I think the append_to variant is probably least gross.

libxl_device_vscsidev_append_to_vscsictrl() would work too.

This is what I will use for the time being (modulo introduced runtime bugs):

void libxl_device_vscsictrl_append_vscsidev(libxl_ctx *ctx,
libxl_device_vscsictrl *ctrl,
libxl_device_vscsidev *dev)
{
GC_INIT(ctx);
ctrl->vscsidevs = libxl__realloc(NOGC, ctrl->vscsidevs, sizeof(*dev) * 
(ctrl->num_vscsidevs + 1));
libxl_device_vscsidev_init(ctrl->vscsidevs + ctrl->num_vscsidevs);
libxl_device_vscsidev_copy(CTX, ctrl->vscsidevs + ctrl->num_vscsidevs, dev);
ctrl->num_vscsidevs++;
GC_FREE;
}


> Wei, is it necessary to init the dst before copy into it?

It would clear the padding between members, a plain copy will leave them
uninitialized.

Olaf

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

Re: [Xen-devel] [BUG] libxl: error: libxl_device.c:301:libxl__device_disk_set_backend: no suitable backend for disk

[Ian Campbell]

On Thu, 2016-02-04 at 10:53 +1100, Alex Braunegg wrote:
> 
> There was a thread on this in 2013
> (http://lists.xen.org/archives/html/xen-devel/2013-03/msg00806.html) however
> I have looked at the disk configuration, and there is no phy: / raw: / file:
> prefix to the disk specification.

Not sure what is going on but I just wanted to mention that phy: etc
prefixes are considered legacy. See http://xenbits.xen.org/docs/4.6-testing
/misc/xl-disk-configuration.txt for the actual syntax and how phy: is
mapped.

Ian.

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

Re: [Xen-devel] [PATCH] tools: libxc: do not redefine evtchn_port_or_error_t in xc_evtchn_compat.c

[Olaf Hering]

On Thu, Feb 04, Ian Campbell wrote:

> Reported-by: Olaf Hering 

be05b53 + this change can be compiled in SLE11 and SLE12. Thanks.

Tested-by: Olaf Hering 

Olaf

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

Re: [Xen-devel] [PATCH v2 08/11] xen/hvmlite: Extend APIC operations for HVMlite guests

[Roger Pau Monné]

El 4/2/16 a les 11:04, David Vrabel ha escrit:
> On 01/02/16 15:38, Boris Ostrovsky wrote:
>> HVMlite guests need to be viewed as having APIC, otherwise smpboot code,
>> for example, will complain.
> 
> I think we should consider always giving HVMlite guests an emulated
> APIC.  I think this eliminates one of the biggest differences between
> HVMlite and native/KVM guests and will reduce the risk of future
> breakage in this area.

Right, I'm not opposed to that, but I think we should keep the hypercall
interface in order to bring up vCPUs. IMHO it's useful for unikernels
for example (do those support SMP?), and in general allows for
easier/faster CPU-bringup as compared to bare metal.

Then if we indeed decide to provide and emulated lapic, should we also
at least provide the ACPI MADT table in order to enumerate them?

Roger.


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

Re: [Xen-devel] [PATCH] x86/hvm: simplify emulation triggered by vm_event response

[Andrew Cooper]

On 04/02/16 12:27, Razvan Cojocaru wrote:
> Currently, after receiving a vm_event reply requesting emulation,
> the actual emulation is triggered in p2m_mem_access_check(),
> which means that we're waiting for the page fault to occur again
> before emulating.

Presumably this means that we re-enter the guest and exit immediately
for (hopefully) the same violation?

>  Aside from the performance impact, this
> complicates the code since between hvm_do_resume() and the second
> page fault it is possible that the latter becomes a completely
> new page fault - hence checking that EIP and the GPA match with
> the ones in the original page fault.

Presumably this occurs when we injected an event on the vmentry?

>  If they don't, duplicate
> EPT fault vm_events will occur, of which a monitoring application
> needs to be aware.
> This patch makes struct arch_vm_event smaller (since we no longer
> need to track eip and gpa), removes the checking code from
> p2m_mem_access_check(), and moves the emulation in hvm_do_resume().
>
> Signed-off-by: Razvan Cojocaru 
> ---
>  xen/arch/x86/hvm/hvm.c | 17 +
>  xen/arch/x86/mm/p2m.c  | 34 --
>  xen/include/asm-x86/vm_event.h |  2 --
>  3 files changed, 17 insertions(+), 36 deletions(-)

Gotta love that diffstat!

The logic makes sense, so Acked-by: Andrew Cooper
 for the x86-related nature, but it would be
nice to have a review from Tamas for the vm_event side of things.

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

Re: [Xen-devel] [PATCH v7 08/18] tools/libxl: introduce libxl__domain_restore_device_model to load qemu state

[Wei Liu]

On Thu, Feb 04, 2016 at 09:41:54AM +, Wei Liu wrote:
> On Thu, Feb 04, 2016 at 01:24:41PM +0800, Wen Congyang wrote:
> > On 02/04/2016 03:40 AM, Wei Liu wrote:
> > > On Fri, Jan 29, 2016 at 01:27:24PM +0800, Wen Congyang wrote:
> > >> In normal migration, the qemu state is passed to qemu as a parameter.
> > >> With COLO, secondary vm is running. So we will do the following steps
> > >> at every checkpoint:
> > >> 1. suspend both primary vm and secondary vm
> > >> 2. sync the state
> > >> 3. resume both primary vm and secondary vm
> > >> Primary will send qemu's state in step2, and secondary's qemu should
> > >> read it and restore the state before it is resumed. We can not pass
> > >> the state to qemu as a parameter because secondary QEMU already started
> > >> at this point, so we introduce libxl__domain_restore_device_model() to
> > >> do it. This API MUST be called before resuming secondary vm.
> > >>
> > >> Signed-off-by: Yang Hongyang 
> > >> Signed-off-by: Wen Congyang 
> > >> Cc: Anthony Perard 
> > >> ---
> > >>  tools/libxl/libxl_dom_save.c | 20 
> > >>  tools/libxl/libxl_internal.h |  4 
> > >>  tools/libxl/libxl_qmp.c  | 10 ++
> > >>  3 files changed, 34 insertions(+)
> > >>
> > >> diff --git a/tools/libxl/libxl_dom_save.c b/tools/libxl/libxl_dom_save.c
> > >> index cd2e7de..7383d2d 100644
> > >> --- a/tools/libxl/libxl_dom_save.c
> > >> +++ b/tools/libxl/libxl_dom_save.c
> > >> @@ -518,6 +518,26 @@ int 
> > >> libxl__restore_emulator_xenstore_data(libxl__domain_create_state *dcs,
> > >>  return rc;
> > >>  }
> > >>  
> > >> +int libxl__domain_restore_device_model(libxl__gc *gc, uint32_t domid,
> > >> +   const char *restore_file)
> > >> +{
> > >> +int rc;
> > >> +
> > >> +switch (libxl__device_model_version_running(gc, domid)) {
> > >> +case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
> > >> +/* Will never be supported. */
> > >> +rc = ERROR_INVAL;
> > >> +break;
> > > 
> > > I'm not entirely sure if this statement would be true. The function name
> > > is generic enough to indicate this case should be supported.
> > > 
> > > However, this function is not used anywhere in this series, so I don't
> > > know whether my comment makes sense.
> > > 
> > > One way of moving forward is to stick this patch to COLO series itself.
> > > Let's skip this in this prerequisite series.
> > 
> > OK, I will put it in the COLO series itself.
> > This API is used for COLO, and COLO requries the newest qemu with block 
> > replication.
> > The block replication is still in the way. The tranditional qemu doesn't 
> > support
> > block replication and it is hard to backport it.
> > 
> 
> OK. I'm asking you to support qemu-trad in COLO -- definitely not.
 ^ NOT

(Not enough caffeine in the morning, sorry.)

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

Re: [Xen-devel] [PATCH v2 08/11] xen/hvmlite: Extend APIC operations for HVMlite guests

[David Vrabel]

On 01/02/16 15:38, Boris Ostrovsky wrote:
> HVMlite guests need to be viewed as having APIC, otherwise smpboot code,
> for example, will complain.

I think we should consider always giving HVMlite guests an emulated
APIC.  I think this eliminates one of the biggest differences between
HVMlite and native/KVM guests and will reduce the risk of future
breakage in this area.

David

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

Re: [Xen-devel] [RFC] support more qdisk types

[Ian Campbell]

On Wed, 2016-02-03 at 19:53 -0700, Jim Fehlig wrote:
> > disk=[ 
> > 'backendtype=qdisk,format=raw,vdev=hda,access=rw,target=rbd:rbd/ubuntu1204.img'
> >  ]
> 
> I thought I tried disk config along those lines with no success. But I'll
> certainly take a closer look at using target= to encode the config needed by
> these qdisk block drivers. Thanks for the pointer.

It's certainly not impossible that this is buggy/has regressed, but if
possible it would be good to just fix it (and add a test case!)...

Ian.

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

Re: [Xen-devel] [BUG} libxl.c:5947:libxl_send_trigger: Send trigger 'reset' failed: Function not implemented

[Ian Campbell]

On Thu, 2016-02-04 at 08:50 +1100, Alex Braunegg wrote:
> [root@mynas-s5000xvn services]# /usr/sbin/xl reboot -F Windows_2008_R2
> Rebooting domain 5
> PV control interface not available: sending ACPI reset button event.
> libxl: error: libxl.c:5947:libxl_send_trigger: Send trigger 'reset' failed:
> Function not implemented
> reboot failed (rc=-3)

This is the one which should have worked, please can you run as:
/usr/sbin/xl -vvv reboot -F Windows_2008_R2
and report the full, verbose, logs.

> The VM in question is a clean install of Windows 2008 R2. The same issue
> occurs when attempting to use the 'shutdown' command.

Please can you provide your guest configuration file.

Ian.

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

[Xen-devel] [PATCH] x86/hvm: simplify emulation triggered by vm_event response

[Razvan Cojocaru]

Currently, after receiving a vm_event reply requesting emulation,
the actual emulation is triggered in p2m_mem_access_check(),
which means that we're waiting for the page fault to occur again
before emulating. Aside from the performance impact, this
complicates the code since between hvm_do_resume() and the second
page fault it is possible that the latter becomes a completely
new page fault - hence checking that EIP and the GPA match with
the ones in the original page fault. If they don't, duplicate
EPT fault vm_events will occur, of which a monitoring application
needs to be aware.
This patch makes struct arch_vm_event smaller (since we no longer
need to track eip and gpa), removes the checking code from
p2m_mem_access_check(), and moves the emulation in hvm_do_resume().

Signed-off-by: Razvan Cojocaru 
---
 xen/arch/x86/hvm/hvm.c | 17 +
 xen/arch/x86/mm/p2m.c  | 34 --
 xen/include/asm-x86/vm_event.h |  2 --
 3 files changed, 17 insertions(+), 36 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 35ec6c9..930d0e3 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -552,6 +552,23 @@ void hvm_do_resume(struct vcpu *v)
 {
 struct monitor_write_data *w = >arch.vm_event->write_data;
 
+if ( v->arch.vm_event->emulate_flags )
+{
+enum emul_kind kind = EMUL_KIND_NORMAL;
+
+if ( v->arch.vm_event->emulate_flags &
+ VM_EVENT_FLAG_SET_EMUL_READ_DATA )
+kind = EMUL_KIND_SET_CONTEXT;
+else if ( v->arch.vm_event->emulate_flags &
+  VM_EVENT_FLAG_EMULATE_NOWRITE )
+kind = EMUL_KIND_NOWRITE;
+
+hvm_mem_access_emulate_one(kind, TRAP_invalid_op,
+   HVM_DELIVER_NO_ERROR_CODE);
+
+v->arch.vm_event->emulate_flags = 0;
+}
+
 if ( w->do_write.msr )
 {
 hvm_msr_write_intercept(w->msr, w->value, 0);
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index a45ee35..47e7fad 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1639,7 +1639,6 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long 
gla,
 p2m_access_t p2ma;
 vm_event_request_t *req;
 int rc;
-unsigned long eip = guest_cpu_user_regs()->eip;
 
 if ( altp2m_active(d) )
 p2m = p2m_get_altp2m(v);
@@ -1698,39 +1697,6 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long 
gla,
 }
 }
 
-/* The previous vm_event reply does not match the current state. */
-if ( unlikely(v->arch.vm_event) &&
- (v->arch.vm_event->gpa != gpa || v->arch.vm_event->eip != eip) )
-{
-/* Don't emulate the current instruction, send a new vm_event. */
-v->arch.vm_event->emulate_flags = 0;
-
-/*
- * Make sure to mark the current state to match it again against
- * the new vm_event about to be sent.
- */
-v->arch.vm_event->gpa = gpa;
-v->arch.vm_event->eip = eip;
-}
-
-if ( unlikely(v->arch.vm_event) && v->arch.vm_event->emulate_flags )
-{
-enum emul_kind kind = EMUL_KIND_NORMAL;
-
-if ( v->arch.vm_event->emulate_flags &
- VM_EVENT_FLAG_SET_EMUL_READ_DATA )
-kind = EMUL_KIND_SET_CONTEXT;
-else if ( v->arch.vm_event->emulate_flags &
-  VM_EVENT_FLAG_EMULATE_NOWRITE )
-kind = EMUL_KIND_NOWRITE;
-
-hvm_mem_access_emulate_one(kind, TRAP_invalid_op,
-   HVM_DELIVER_NO_ERROR_CODE);
-
-v->arch.vm_event->emulate_flags = 0;
-return 1;
-}
-
 *req_ptr = NULL;
 req = xzalloc(vm_event_request_t);
 if ( req )
diff --git a/xen/include/asm-x86/vm_event.h b/xen/include/asm-x86/vm_event.h
index 5aff834..fff8326 100644
--- a/xen/include/asm-x86/vm_event.h
+++ b/xen/include/asm-x86/vm_event.h
@@ -28,8 +28,6 @@
  */
 struct arch_vm_event {
 uint32_t emulate_flags;
-unsigned long gpa;
-unsigned long eip;
 struct vm_event_emul_read_data emul_read_data;
 struct monitor_write_data write_data;
 };
-- 
1.9.1


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

[Xen-devel] [distros-debian-wheezy test] 38725: all pass

[Platform Team regression test user]

flight 38725 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38725/

Perfect :-)
All tests in this flight passed
baseline version:
 flight   38710

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass
 test-amd64-i386-i386-wheezy-netboot-pvgrub   pass
 test-amd64-i386-amd64-wheezy-netboot-pygrub  pass
 test-amd64-amd64-i386-wheezy-netboot-pygrub  pass



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

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

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


Push not applicable.


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

Re: [Xen-devel] new idl helper, append to Array

[Wei Liu]

On Thu, Feb 04, 2016 at 11:07:58AM +0100, Olaf Hering wrote:
> On Thu, Feb 04, Ian Campbell wrote:
> 
> > I think the append_to variant is probably least gross.
> 
> libxl_device_vscsidev_append_to_vscsictrl() would work too.
> 
> This is what I will use for the time being (modulo introduced runtime bugs):
> 
> void libxl_device_vscsictrl_append_vscsidev(libxl_ctx *ctx,
> libxl_device_vscsictrl *ctrl,
> libxl_device_vscsidev *dev)
> {
> GC_INIT(ctx);
> ctrl->vscsidevs = libxl__realloc(NOGC, ctrl->vscsidevs, sizeof(*dev) * 
> (ctrl->num_vscsidevs + 1));
> libxl_device_vscsidev_init(ctrl->vscsidevs + ctrl->num_vscsidevs);
> libxl_device_vscsidev_copy(CTX, ctrl->vscsidevs + ctrl->num_vscsidevs, 
> dev);
> ctrl->num_vscsidevs++;
> GC_FREE;
> }
> 
> 
> > Wei, is it necessary to init the dst before copy into it?
> 
> It would clear the padding between members, a plain copy will leave them
> uninitialized.
> 

There is that. Yes, _init memset the whole structure to zeros.

Wei.

> Olaf

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

Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

[Stefano Stabellini]

On Thu, 4 Feb 2016, Haozhong Zhang wrote:
> On 02/03/16 15:22, Stefano Stabellini wrote:
> > On Wed, 3 Feb 2016, George Dunlap wrote:
> > > On 03/02/16 12:02, Stefano Stabellini wrote:
> > > > On Wed, 3 Feb 2016, Haozhong Zhang wrote:
> > > >> Or, we can make a file system on /dev/pmem0, create files on it, set
> > > >> the owner of those files to xen-qemuuser-domid$domid, and then pass
> > > >> those files to QEMU. In this way, non-root QEMU should be able to
> > > >> mmap those files.
> > > >
> > > > Maybe that would work. Worth adding it to the design, I would like to
> > > > read more details on it.
> > > >
> > > > Also note that QEMU initially runs as root but drops privileges to
> > > > xen-qemuuser-domid$domid before the guest is started. Initially QEMU
> > > > *could* mmap /dev/pmem0 while is still running as root, but then it
> > > > wouldn't work for any devices that need to be mmap'ed at run time
> > > > (hotplug scenario).
> > >
> > > This is basically the same problem we have for a bunch of other things,
> > > right?  Having xl open a file and then pass it via qmp to qemu should
> > > work in theory, right?
> >
> > Is there one /dev/pmem? per assignable region?
> 
> Yes.
> 
> BTW, I'm wondering whether and how non-root qemu works with xl disk
> configuration that is going to access a host block device, e.g.
>  disk = [ '/dev/sdb,,hda' ]
> If that works with non-root qemu, I may take the similar solution for
> pmem.
 
Today the user is required to give the correct ownership and access mode
to the block device, so that non-root QEMU can open it. However in the
case of PCI passthrough, QEMU needs to mmap /dev/mem, as a consequence
the feature doesn't work at all with non-root QEMU
(http://marc.info/?l=xen-devel=145261763600528).

If there is one /dev/pmem device per assignable region, then it would be
conceivable to change its ownership so that non-root QEMU can open it.
Or, better, the file descriptor could be passed by the toolstack via
qmp.

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

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Ian Campbell]

On Wed, 2016-02-03 at 17:41 +, George Dunlap wrote:
> But of course, since they they aren't actually ranges but just gpfns,
> they're scattered randomly throughout the guest physical address
> space.

(Possibly) stupid question:

Since, AIUI, the in-guest GPU driver is XenGT aware could it not allocate a
contiguous range of pages at start of day to use as GPU PTs? Or even just N
contiguous regions, e.g. i think the "8K" refers to pages, which is 16 2M
allocations, which is a far more manageable number of ranges to track than
8096 individual pages.

Ian.

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

[Xen-devel] [PATCH] tools: libxc: do not redefine evtchn_port_or_error_t in xc_evtchn_compat.c

[Ian Campbell]

This file stradles the xenevtchn and libxc evtchn_compat worlds, and
hence ends up with two evtchn_port_or_error_t typedefs which older
gcc's (and the C standard) do not like.

Avoid this by gating the compat definition on a gate provided by the
compat implementation.

Note that this would still be broken by an application which does:
#define XC_WANT_COMPAT_EVTCHN_API
#include 
#include 

Which effectively means that an application must be ported over to
xenevtchn in one go rather than incrementally (e.g. if it uses
evtchn's for multiple purposes). Since the port is actually fairly
mechanical I hope this is acceptable.

Reported-by: Olaf Hering 
Signed-off-by: Ian Campbell 
Cc: Andrew Cooper 
---
I'm not super happy about this approach, due to the caveat in the
second half of the commit message.

Other approaches:

rename the libxenevtchn type, e.g.  xenevtchn_port_or_error_t?

Some sort of skank based on the header guard #defines, but that's
awful (and fragile).
---
 tools/libxc/include/xenctrl_compat.h | 2 ++
 tools/libxc/xc_evtchn_compat.c   | 1 +
 2 files changed, 3 insertions(+)

diff --git a/tools/libxc/include/xenctrl_compat.h 
b/tools/libxc/include/xenctrl_compat.h
index 93ccadb..afc3d88 100644
--- a/tools/libxc/include/xenctrl_compat.h
+++ b/tools/libxc/include/xenctrl_compat.h
@@ -51,7 +51,9 @@ void *xc_map_foreign_bulk(xc_interface *xch, uint32_t dom, 
int prot,
 #ifdef XC_WANT_COMPAT_EVTCHN_API
 
 typedef struct xenevtchn_handle xc_evtchn;
+#ifndef XC_BUILDING_COMPAT_EVTCHN_API
 typedef xc_evtchn_port_or_error_t evtchn_port_or_error_t;
+#endif
 
 xc_evtchn *xc_evtchn_open(xentoollog_logger *logger,
  unsigned open_flags);
diff --git a/tools/libxc/xc_evtchn_compat.c b/tools/libxc/xc_evtchn_compat.c
index 5d3e4ba..99da476 100644
--- a/tools/libxc/xc_evtchn_compat.c
+++ b/tools/libxc/xc_evtchn_compat.c
@@ -6,6 +6,7 @@
 #include 
 
 #define XC_WANT_COMPAT_EVTCHN_API
+#define XC_BUILDING_COMPAT_EVTCHN_API
 #include "xenctrl.h"
 
 xc_evtchn *xc_evtchn_open(xentoollog_logger *logger,
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] libxl/libxl_dm.c: Enable websocket functionality

[Ian Campbell]

On Thu, 2016-02-04 at 08:50 +1100, Alex Braunegg wrote:
> A better solution however in my mind would be to store the websocket & x509
> path in the .cfg file for each virtual machine:

Correct. This would involve adding the appropriate fields to the struct(s)
in tools/libxl/libxl_types.idl, populating them from the xl cfg parser
(xl_cmdimple.c) and obeying them in the code you have patched above.

Please also see http://wiki.xen.org/wiki/Submitting_Xen_Patches for
guidance on submitting patches to Xen, in particular the requirement for a
Signed-off-by (and what that means).

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[George Dunlap]

On Thu, Feb 4, 2016 at 8:51 AM, Yu, Zhang  wrote:
>> Going forward, we probably will, at some point, need to implement a
>> parallel "p2t" structure to keep track of types -- and probably will
>> whether end up implementing 4 separate write_dm types or not (for the
>> reasons you describe).
>>
>
> Thank you, George. Could you please elaborate more about the idea of
> "p2t"?

So the p2m table is a partially-sparse structure designed to map pfns
to mfns.  At the bottom is a 64-bit entry that contains certain bits
specified by the hardware (mfn number, permissions, other features).
There are at the moment extra bits that aren't use, and in these bits
we store information about the pfn that Xen wants to know -- among
other things, the 'type' of the gpfn.

But as Andy pointed out, Intel are adding new features which take up
more of these bits; and at the same time, Xen has more features for
which using a p2m type is the most obvious solution.  So the idea
would be to have a separate structure, similar to the p2m table, but
wouldn't be used by the hardware -- it would only be used by Xen to
map pfn to type (or whatever other information it wanted about the
gpfn).  This does mean duplicating all the non-leaf nodes, as well as
doing two sparse-tree-walks rather  than just one when looking up gpfn
information.

 -George

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

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[George Dunlap]

On Thu, Feb 4, 2016 at 9:38 AM, Yu, Zhang  wrote:
> On 2/4/2016 5:28 PM, Paul Durrant wrote:
>> I assume this means that the emulator can 'unshadow' GTTs (I guess on an
>> LRU basis) so that it can shadow new ones when the limit has been exhausted?
>> If so, how bad is performance likely to be if we live with a lower limit
>> and take the hit of unshadowing if the guest GTTs become heavily fragmented?
>>
> Thank you, Paul.
>
> Well, I was told the emulator have approaches to delay the shadowing of
> the GTT till future GPU commands are submitted. By now, I'm not sure
> about the performance penalties if the limit is set too low. Although
> we are confident 8K is a secure limit, it seems still too high to be
> accepted. We will perform more experiments with this new approach to
> find a balance between the lowest limit and the XenGT performance.

Just to check some of my assumptions:

I assume that unlike memory accesses, your GPU hardware cannot
'recover' from faults in the GTTs. That is, for memory, you can take a
page fault, fix up the pagetables, and then re-execute the original
instruction; but so far I haven't heard of any devices being able to
seamlessly re-execute a transaction after a fault.  Is my
understanding correct?

If that is the case, then for every top-level value (whatever the
equivalent of the CR3), you need to be able to shadow the entire GTT
tree below it, yes?  You can't use a trick that the memory shadow
pagetables can use, of unshadowing parts of the tree and reshadowing
them.

So as long as the currently-in-use GTT tree contains no more than
$LIMIT ranges, you can unshadow and reshadow; this will be slow, but
strictly speaking correct.

What do you do if the guest driver switches to a GTT such that the
entire tree takes up more than $LIMIT entries?

 -George

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

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Ian Campbell]

On Thu, 2016-02-04 at 11:08 +, Ian Campbell wrote:
> On Thu, 2016-02-04 at 10:49 +, George Dunlap wrote:
> > On Thu, Feb 4, 2016 at 8:51 AM, Yu, Zhang 
> > wrote:
> > > > Going forward, we probably will, at some point, need to implement a
> > > > parallel "p2t" structure to keep track of types -- and probably
> > > > will
> > > > whether end up implementing 4 separate write_dm types or not (for
> > > > the
> > > > reasons you describe).
> > > > 
> > > 
> > > Thank you, George. Could you please elaborate more about the idea of
> > > "p2t"?
> > 
> > So the p2m table is a partially-sparse structure designed to map pfns
> > to mfns.  At the bottom is a 64-bit entry that contains certain bits
> > specified by the hardware (mfn number, permissions, other features).
> > There are at the moment extra bits that aren't use, and in these bits
> > we store information about the pfn that Xen wants to know -- among
> > other things, the 'type' of the gpfn.
> > 
> > But as Andy pointed out, Intel are adding new features which take up
> > more of these bits; and at the same time, Xen has more features for
> > which using a p2m type is the most obvious solution.  So the idea
> > would be to have a separate structure, similar to the p2m table, but
> > wouldn't be used by the hardware -- it would only be used by Xen to
> > map pfn to type (or whatever other information it wanted about the
> > gpfn).  This does mean duplicating all the non-leaf nodes, as well as
> > doing two sparse-tree-walks rather  than just one when looking up gpfn
> > information.
> 
> FWIW ARM already has such a structure to support xenaccess, since ARM had
> far fewer available bits to start with.
> 
> It is not quite the same as above since it is only populated with pages for
> which xenaccess is in use rather than all pages (and is only consulted if
> we have reason to believe the page might be subject to xenaccess). FWIW it
> uses Xen's radix tree stuff.

A second FWIW in case it is useful, but Linux on 32-bit ARM (older ones
with 32-bit PTEs) allocates every PT page as a pair of pages, so it gets 32
software defined bits for every h/w visible pte at pte+4K.

If you wanted to avoid the order-1 allocations which that implies then I
suppose you could chain to the "pteext" page from the struct page of the
h/w visible page.

Ian.

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

Re: [Xen-devel] [PATCH] x86/hvm: simplify emulation triggered by vm_event response

[Razvan Cojocaru]

On 02/04/2016 02:36 PM, Andrew Cooper wrote:
> On 04/02/16 12:27, Razvan Cojocaru wrote:
>> Currently, after receiving a vm_event reply requesting emulation,
>> the actual emulation is triggered in p2m_mem_access_check(),
>> which means that we're waiting for the page fault to occur again
>> before emulating.
> 
> Presumably this means that we re-enter the guest and exit immediately
> for (hopefully) the same violation?

Yes, something along those lines: the original page fault occurs, a
vm_event is being sent to the application, which replies with the
EMULATE flag set (but does not lift the page restrictions). Now we're
hoping that the same instruction that has caused the first page fault
runs, which triggers a new page fault (thus a new call of
p2m_mem_access_check()). But in p2m_mem_access_check() we check to see
if emulate flags are set for the current VCPU, and if they are, we check
to see that the instruction is really the one that has caused the
original page fault, and if it is (i.e. both EIP and GPA match), we emulate.

The ideal case is the one where the second page fault is being caused by
the same instruction hitting the same page, and that happens most of the
time, but it unfortunately does not happen all of the time.

So when the second page fault is _not_ caused by the same instruction,
we just reset the emulate flags and carry on with regular processing,
which means that a new vm_event will be sent out about this new page
fault. But even though the application has reuquested that the page
fault that has triggered the last page fault be emulated, it wasn't (as
a design limitation). So now, when / if the old instruction hits the
page again, it will be received by the monitoring application as a new
hit, not still the old, unemulated one.

There are safeguards possible for this in the monitoring application,
but they too have limitations, and it is ultimately less efficient and
more error-prone that the alternative hopefully is.

>>  Aside from the performance impact, this
>> complicates the code since between hvm_do_resume() and the second
>> page fault it is possible that the latter becomes a completely
>> new page fault - hence checking that EIP and the GPA match with
>> the ones in the original page fault.
> 
> Presumably this occurs when we injected an event on the vmentry?

Any asynchronous-type cause of a page fault will do, hopefully I've been
able to explain somewhat above.

>>  If they don't, duplicate
>> EPT fault vm_events will occur, of which a monitoring application
>> needs to be aware.
>> This patch makes struct arch_vm_event smaller (since we no longer
>> need to track eip and gpa), removes the checking code from
>> p2m_mem_access_check(), and moves the emulation in hvm_do_resume().
>>
>> Signed-off-by: Razvan Cojocaru 
>> ---
>>  xen/arch/x86/hvm/hvm.c | 17 +
>>  xen/arch/x86/mm/p2m.c  | 34 --
>>  xen/include/asm-x86/vm_event.h |  2 --
>>  3 files changed, 17 insertions(+), 36 deletions(-)
> 
> Gotta love that diffstat!
> 
> The logic makes sense, so Acked-by: Andrew Cooper
>  for the x86-related nature, but it would be
> nice to have a review from Tamas for the vm_event side of things.

Thanks! Of course. Hopefully Tamas will like this, based on a
conversation we've had a few days ago here.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH V10 5/5] x86/hvm: pkeys, add pkeys support for cpuid handling

[Wei Liu]

On Thu, Feb 04, 2016 at 03:00:34PM +0800, Huaitong Han wrote:
> This patch adds pkeys support for cpuid handing.
> 
> Pkeys hardware support is CPUID.7.0.ECX[3]:PKU. software support is
> CPUID.7.0.ECX[4]:OSPKE and it reflects the support setting of CR4.PKE.
> 
> X86_FEATURE_OSXSAVE depends on guest X86_FEATURE_XSAVE, but cpu_has_xsave
> function reflects hypervisor X86_FEATURE_XSAVE, it is fixed too.
> 
> Signed-off-by: Huaitong Han 
> Reviewed-by: Jan Beulich 

Acked-by: Wei Liu 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 14 guest-saverestore.2 
fail REGR. vs. 79422
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 79422
 test-amd64-i386-qemut-rhel6hvm-amd 11 guest-start/redhat.repeat fail REGR. vs. 
79422

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 79422
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeatfail   like 79178
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 79379
 build-i386-rumpuserxen6 xen-buildfail   like 79422
 build-amd64-rumpuserxen   6 xen-buildfail   like 79422
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 79422
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 79422

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  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-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-xsm 12 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-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  0f2b207d464f6b2a3508934a86b79557d3d0f0fd
baseline version:
 xen  9937763265d9597e5f2439249b16d995842cdf0f

Last test of basis79422  2016-01-29 14:09:49 Z5 days
Failing since 79502  2016-01-30 20:16:40 Z4 days5 attempts
Testing same since80237  2016-02-03 14:52:06 Z0 days1 attempts


People who touched revisions under test:
  Alan.Robinson 
  Andrew Cooper 
  Boris Ostrovsky 
  Corneliu ZUZU 
  David Vrabel 
  Doug Goldstein 
  Graeme Gregory 
  Hanjun Guo 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jennifer Herbert 
  Juergen Gross 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Rafael J. Wysocki 
  Razvan Cojocaru 
  Roger Pau Monne 
  Roger Pau Monné 

Re: [Xen-devel] [PATCH] tools: libxc: do not redefine evtchn_port_or_error_t in xc_evtchn_compat.c

[Ian Campbell]

Adding Olaf, I forgot that Reported-by doesn't turn into a Cc.

On Thu, 2016-02-04 at 10:15 +, Ian Campbell wrote:
> This file stradles the xenevtchn and libxc evtchn_compat worlds, and
> hence ends up with two evtchn_port_or_error_t typedefs which older
> gcc's (and the C standard) do not like.
> 
> Avoid this by gating the compat definition on a gate provided by the
> compat implementation.
> 
> Note that this would still be broken by an application which does:
> #define XC_WANT_COMPAT_EVTCHN_API
> #include 
> #include 
> 
> Which effectively means that an application must be ported over to
> xenevtchn in one go rather than incrementally (e.g. if it uses
> evtchn's for multiple purposes). Since the port is actually fairly
> mechanical I hope this is acceptable.
> 
> Reported-by: Olaf Hering 
> Signed-off-by: Ian Campbell 
> Cc: Andrew Cooper 
> ---
> I'm not super happy about this approach, due to the caveat in the
> second half of the commit message.
> 
> Other approaches:
> 
> rename the libxenevtchn type, e.g.  xenevtchn_port_or_error_t?

Thinking about this some more this might be the best approach. The type is
not used by qemu-xen, it is used by qemu-xen-traditional but we can fix
that in lockstep.

All of the in tree users are easy, of course.

Thoughts?

> 
> Some sort of skank based on the header guard #defines, but that's
> awful (and fragile).
> ---
>  tools/libxc/include/xenctrl_compat.h | 2 ++
>  tools/libxc/xc_evtchn_compat.c   | 1 +
>  2 files changed, 3 insertions(+)
> 
> diff --git a/tools/libxc/include/xenctrl_compat.h
> b/tools/libxc/include/xenctrl_compat.h
> index 93ccadb..afc3d88 100644
> --- a/tools/libxc/include/xenctrl_compat.h
> +++ b/tools/libxc/include/xenctrl_compat.h
> @@ -51,7 +51,9 @@ void *xc_map_foreign_bulk(xc_interface *xch, uint32_t
> dom, int prot,
>  #ifdef XC_WANT_COMPAT_EVTCHN_API
>  
>  typedef struct xenevtchn_handle xc_evtchn;
> +#ifndef XC_BUILDING_COMPAT_EVTCHN_API
>  typedef xc_evtchn_port_or_error_t evtchn_port_or_error_t;
> +#endif
>  
>  xc_evtchn *xc_evtchn_open(xentoollog_logger *logger,
>   unsigned open_flags);
> diff --git a/tools/libxc/xc_evtchn_compat.c
> b/tools/libxc/xc_evtchn_compat.c
> index 5d3e4ba..99da476 100644
> --- a/tools/libxc/xc_evtchn_compat.c
> +++ b/tools/libxc/xc_evtchn_compat.c
> @@ -6,6 +6,7 @@
>  #include 
>  
>  #define XC_WANT_COMPAT_EVTCHN_API
> +#define XC_BUILDING_COMPAT_EVTCHN_API
>  #include "xenctrl.h"
>  
>  xc_evtchn *xc_evtchn_open(xentoollog_logger *logger,

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

Re: [Xen-devel] [PATCH v2 10/11] xen/hvmlite: Boot secondary CPUs

[David Vrabel]

On 01/02/16 15:38, Boris Ostrovsky wrote:
> HVMlite secondary VCPUs use baremetal bringup path (i.e. native_*
> smp_ops) but need to do some preparation in PV code.

If we always provided an emulated APIC could we use the native SMP
bring-up instead?

David


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

Re: [Xen-devel] [PATCH] tools: libxc: do not redefine evtchn_port_or_error_t in xc_evtchn_compat.c

[Andrew Cooper]

On 04/02/16 10:19, Ian Campbell wrote:
> Adding Olaf, I forgot that Reported-by doesn't turn into a Cc.
>
> On Thu, 2016-02-04 at 10:15 +, Ian Campbell wrote:
>> This file stradles the xenevtchn and libxc evtchn_compat worlds, and
>> hence ends up with two evtchn_port_or_error_t typedefs which older
>> gcc's (and the C standard) do not like.
>>
>> Avoid this by gating the compat definition on a gate provided by the
>> compat implementation.
>>
>> Note that this would still be broken by an application which does:
>> #define XC_WANT_COMPAT_EVTCHN_API
>> #include 
>> #include 
>>
>> Which effectively means that an application must be ported over to
>> xenevtchn in one go rather than incrementally (e.g. if it uses
>> evtchn's for multiple purposes). Since the port is actually fairly
>> mechanical I hope this is acceptable.
>>
>> Reported-by: Olaf Hering 
>> Signed-off-by: Ian Campbell 
>> Cc: Andrew Cooper 
>> ---
>> I'm not super happy about this approach, due to the caveat in the
>> second half of the commit message.
>>
>> Other approaches:
>>
>> rename the libxenevtchn type, e.g.  xenevtchn_port_or_error_t?
> Thinking about this some more this might be the best approach. The type is
> not used by qemu-xen, it is used by qemu-xen-traditional but we can fix
> that in lockstep.
>
> All of the in tree users are easy, of course.
>
> Thoughts?

Thinking about it, this looks like a better option.  It is also more in
line with the library naming.

~Andrew

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

Re: [Xen-devel] new idl helper, append to Array

[Wei Liu]

On Thu, Feb 04, 2016 at 09:58:14AM +, Ian Campbell wrote:
> On Thu, 2016-02-04 at 10:23 +0100, Olaf Hering wrote:
> > Ian,
> > 
> > in my pvscsi code I have two copies of a helper function which appends
> > yet another instance of something to an Array, as shown below. This is
> > similar to the _copy variant. Is it worth to let gentypes generate such
> > a helper, like libxl_device_vscsictrl_append_vscsidev()?
> 
> If something can be autogenerated without too much trouble then I see no
> reason not to do so.
> 
> I'd go with libxl__list_append as the naming scheme, which fits in
> with libxl__list_free (which probably ought to be autogenerated too,
> but isn't). So:
> 
> libxl_device_vscsidev_list_append(libxl_ctx *ctx,
>                                   libxl_device_vscsidev *dev, int nr,
>     libxl_device_vscsidev *new);
> (if you intend for this to be internal then s/^libxl_/&_/ and
> s/libxl_ctx \*ctx/libxl__gc *gc/)
> 
> Oh, I see you want it to take the type containing the array, that could
> work to, you'd need to call it libxl__append_, so
> 
> libxl_device_vscsictrl_append_vscsidevs
> 
> which looks a bit odd (since the field name is plural and the IDL has no
> way to find the singular). We could live with that, or s/append/append_to/
> or make it varargs and take perhaps multiple new entries and a NULL
> terminator.
> 
> I think the append_to variant is probably least gross.
> 
> Looks like various places such as libxl__append_nic_list_of_type could make
> use of this helper too. As could xl_cmdimpl.c for ARRAY_EXTEND_INIT perhaps
> (using it everywhere isn't mandatory of course, but if you feel inclined it
> would be nice)
> 
> > While writing this I realize that libxl__realloc will not return, so my
> > helper can be converted from returning int to void, and all the locals
> > can be removed.
> 
> Indeed.
> 
> > static int vscsi_append_dev(libxl__gc *gc, libxl_device_vscsictrl *ctrl,
> > libxl_device_vscsidev *dev)
> > {
> > int rc;
> > libxl_device_vscsidev *devs;
> > 
> > devs = libxl__realloc(NOGC, ctrl->vscsidevs, sizeof(*dev) * 
> > (ctrl->num_vscsidevs + 1));
> > if (!devs) {
> > rc = ERROR_NOMEM;
> > goto out;
> > }
> > 
> > ctrl->vscsidevs = devs;
> > libxl_device_vscsidev_init(ctrl->vscsidevs + ctrl->num_vscsidevs);
> > libxl_device_vscsidev_copy(CTX, ctrl->vscsidevs + ctrl->num_vscsidevs, 
> > dev);
> 
> Wei, is it necessary to init the dst before copy into it?
> 

I don't think it is absolutely necessary because every field inside dst
will be overwritten, but better safe than sorry.

Wei.

> > ctrl->num_vscsidevs++;
> > rc = 0;
> > out:
> > return rc;
> > }
> > 
> > 
> > Olaf

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

Re: [Xen-devel] [PATCH v2 07/11] xen/hvmlite: Initialize context for secondary VCPUs

[Doug Goldstein]

On 2/2/16 10:58 AM, Boris Ostrovsky wrote:
> On 02/02/2016 11:21 AM, David Vrabel wrote:
>> This needs some more description in the commit message.
>>
>>> --- a/arch/x86/xen/smp.c
>>> +++ b/arch/x86/xen/smp.c
>> [...]
>>> +hctxt->cpu_regs.x86_32.cs_base = 0;
>>> +hctxt->cpu_regs.x86_32.cs_limit = ~0u;
>>> +hctxt->cpu_regs.x86_32.cs_ar = 0xc9b;
>>> +hctxt->cpu_regs.x86_32.ds_base = 0;
>>> +hctxt->cpu_regs.x86_32.ds_limit = ~0u;
>>> +hctxt->cpu_regs.x86_32.ds_ar = 0xc93;
>>> +hctxt->cpu_regs.x86_32.es_base = 0;
>>> +hctxt->cpu_regs.x86_32.es_limit = ~0u;
>>> +hctxt->cpu_regs.x86_32.es_ar = 0xc93;
>>> +hctxt->cpu_regs.x86_32.ss_base = 0;
>>> +hctxt->cpu_regs.x86_32.ss_limit = ~0u;
>>> +hctxt->cpu_regs.x86_32.ss_ar = 0xc93;
>>> +hctxt->cpu_regs.x86_32.tr_base = 0;
>>> +hctxt->cpu_regs.x86_32.tr_limit = 0xff;
>>> +hctxt->cpu_regs.x86_32.tr_ar = 0x8b;
>> Lots of hard-coded values here.  Should this be #defined somewhere?
> 
> We also don't need to set bases to zero since hctxt is kzalloc'd. I'll
> remove that and add a comment.
> 
> As for macros --- I couldn't find the bits defined symbolically anywhere
> and since this is the only place this is used the macros would be local
> here.
> 
> -boris
> 

It could be useful to have them defined locally if only to give them
some more meaning by having a name rather than 0x8b. Just a thought.

-- 
Doug Goldstein



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

Re: [Xen-devel] [BUG] pci-passthrough generates "xen:events: Failed to obtain physical IRQ" for some devices

[Tommi Airikka]

Hi,

I patched the deb8u2 source with all four patches and built a new deb.

As two of the patches make some changes on the pcifront, I thought it could
be a good idea to first upgrade the domU 'bug' with the new linux-image.

domU 'bug' "uname -a":
Linux bug 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2a~test
(2016-02-04) x86_64 GNU/Linux

dom0 "uname -a":
Linux dom0 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2 (2016-01-02)
x86_64 GNU/Linux

At first, all seemed to be as expected. I still got the "Failed to obtain
physical IRQ" as the dom0 is not upgraded with the new linux-image.
But after a couple of minutes, I got "INFO: task khubd:205 blocked for more
than 120 seconds." with a call trace in dmesg (and there is a new call
trace periodically every 120 seconds).

domU 'bug' "dmesg":
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org)
(gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian
3.16.7-ckt20-1+deb8u2a~test (2016-02-04)
[0.00] Command line: root=/dev/xvda2 ro elevator=noop
root=/dev/xvda2 ro
[0.00] ACPI in unprivileged domain disabled
[0.00] 1-1 mapping on 8000->10
[0.00] Set 1015808 page(s) to 1-1 mapping
[0.00] 1-1 mapping on 10->800
[0.00] e820: BIOS-provided physical RAM map:
[0.00] Xen: [mem 0x-0x0009] usable
[0.00] Xen: [mem 0x000a-0x000f] reserved
[0.00] Xen: [mem 0x0010-0x07ff] usable
[0.00] Xen: [mem 0x0800-0xf1de3fff] unusable
[0.00] Xen: [mem 0xf1de4000-0xf1dedfff] ACPI data
[0.00] Xen: [mem 0xf1dee000-0xf7ff] reserved
[0.00] Xen: [mem 0xfec0-0xfeef] reserved
[0.00] Xen: [mem 0xff80-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] DMI not present or invalid.
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] AGP: No AGP bridge found
[0.00] e820: last_pfn = 0x8000 max_arch_pfn = 0x4
[0.00] Base memory trampoline at [8809a000] 9a000 size 24576
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] init_memory_mapping: [mem 0x07e0-0x07ff]
[0.00]  [mem 0x07e0-0x07ff] page 4k
[0.00] BRK [0x01b02000, 0x01b02fff] PGTABLE
[0.00] init_memory_mapping: [mem 0x0400-0x07df]
[0.00]  [mem 0x0400-0x07df] page 4k
[0.00] BRK [0x01b03000, 0x01b03fff] PGTABLE
[0.00] BRK [0x01b04000, 0x01b04fff] PGTABLE
[0.00] BRK [0x01b05000, 0x01b05fff] PGTABLE
[0.00] BRK [0x01b06000, 0x01b06fff] PGTABLE
[0.00] BRK [0x01b07000, 0x01b07fff] PGTABLE
[0.00] init_memory_mapping: [mem 0x0010-0x03ff]
[0.00]  [mem 0x0010-0x03ff] page 4k
[0.00] RAMDISK: [mem 0x01f18000-0x04a4efff]
[0.00] NUMA turned off
[0.00] Faking a node at [mem 0x-0x07ff]
[0.00] Initmem setup node 0 [mem 0x-0x07ff]
[0.00]   NODE_DATA [mem 0x07fe7000-0x07febfff]
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x1000-0x00ff]
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x1000-0x0009]
[0.00]   node   0: [mem 0x0010-0x07ff]
[0.00] On node 0 totalpages: 32671
[0.00]   DMA zone: 56 pages used for memmap
[0.00]   DMA zone: 21 pages reserved
[0.00]   DMA zone: 3999 pages, LIFO batch:0
[0.00]   DMA32 zone: 392 pages used for memmap
[0.00]   DMA32 zone: 28672 pages, LIFO batch:7
[0.00] SFI: Simple Firmware Interface v0.81
http://simplefirmware.org
[0.00] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
[0.00] nr_irqs_gsi: 16
[0.00] PM: Registered nosave memory: [mem 0x000a-0x000f]
[0.00] e820: [mem 0xf800-0xfebf] available for PCI devices
[0.00] Booting paravirtualized kernel on Xen
[0.00] Xen version: 4.4.1 (preserve-AD)
[0.00] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:1
nr_node_ids:1
[0.00] PERCPU: Embedded 27 pages/cpu @880007c0 s80896 r8192
d21504 u2097152
[0.00] pcpu-alloc: s80896 r8192 d21504 u2097152 alloc=1*2097152
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Node order, mobility grouping on.
Total pages: 32202
[0.00] Policy zone: DMA32
[

Re: [Xen-devel] [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

[Boris Ostrovsky]

On 02/04/2016 03:57 PM, Luis R. Rodriguez wrote:


Ah, well here lies the issue. As per hpa subarch was not designed for defining
a hypervisor, but rather at least subarch PC (0) [should be used if the
hardware is] "enumerable using standard PC mechanisms (PCI, ACPI) and doesn't
need a special boot flow". Does that follow the definition of HVMlite?


Yes. HVMlite is going to use baremetal boot flow.


OK great. That still means the code will run, and if we can avoid that
why not. I am fine with annotating this as future work to help. Let me
then ask as well, how about the rest of the code during and after
startup_32() and startup_64() -- are we sure that's all safe ?


I can't be sure, all I can say is that so far I haven't seen any problems.

-boris



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

Re: [Xen-devel] [BUG} libxl.c:5947:libxl_send_trigger: Send trigger 'reset' failed: Function not implemented

[Alex Braunegg]

Hi Ian,

Below is the output requested:

Guest Configuration:

-

builder='hvm'
memory = 2048
shadow_memory = 8
uuid = '27f4787c-89b2-46ab-a797-96ea6e84c511'
name = 'Windows_2008_R2'
vif = [ 'bridge=br0, mac=00:16:3e:96:49:10' ]
disk = [ 
'/dev/zvol/storage0/xen/Windows_2008_R2/disk_sda,,hda','/storage0/data-shares/iso/en_windows_server_2008_r2_standard_enterprise_datacenter_and_web_x64_dvd_x15-59754.iso,,hdc,cdrom'
 ]
# boot on floppy (a), hard disk (c) or CD-ROM (d)
# default: hard disk, cd-rom, floppy
boot='dc'
sdl=0
vnc=1
vncconsole=1
vnclisten='0.0.0.0'
stdvga=1
serial='pty'
usbdevice='tablet'
vncpasswd='bpC7fKtsDy'
vncdisplay=2
localtime=1
audio='1'
soundhw='ac97'

-

Reboot Log:
===

[root@mynas-s5000xvn /]# /usr/sbin/xl -vvv reboot -F Windows_2008_R2
Rebooting domain 9
PV control interface not available: sending ACPI reset button event.
libxl: error: libxl.c:5947:libxl_send_trigger: Send trigger 'reset' failed: 
Function not implemented
reboot failed (rc=-3)
xc: debug: hypercall buffer: total allocations:18 total releases:18
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:12 misses:2 toobig:4
[root@mynas-s5000xvn /]#


Shutdown Log:
=

[root@mynas-s5000xvn /]# /usr/sbin/xl -vvv shutdown -F Windows_2008_R2  
Shutting down domain 9
PV control interface not available: sending ACPI power button event.
xc: debug: hypercall buffer: total allocations:18 total releases:18
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:12 misses:2 toobig:4
[root@mynas-s5000xvn /]#


During this test, the shutdown of the guest system occurred - so potentially 
the shutdown command is working.



Best regards,

Alex



-Original Message-
From: Ian Campbell [mailto:ian.campb...@citrix.com] 
Sent: Thursday, 4 February 2016 9:58 PM
To: Alex Braunegg; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [BUG} libxl.c:5947:libxl_send_trigger: Send trigger 
'reset' failed: Function not implemented

On Thu, 2016-02-04 at 08:50 +1100, Alex Braunegg wrote:
> [root@mynas-s5000xvn services]# /usr/sbin/xl reboot -F Windows_2008_R2
> Rebooting domain 5
> PV control interface not available: sending ACPI reset button event.
> libxl: error: libxl.c:5947:libxl_send_trigger: Send trigger 'reset' failed:
> Function not implemented
> reboot failed (rc=-3)

This is the one which should have worked, please can you run as:
/usr/sbin/xl -vvv reboot -F Windows_2008_R2
and report the full, verbose, logs.

> The VM in question is a clean install of Windows 2008 R2. The same issue
> occurs when attempting to use the 'shutdown' command.

Please can you provide your guest configuration file.

Ian.


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

Re: [Xen-devel] Clarifying PVH mode requirements

[PGNet Dev]

On Mon, Feb 1, 2016 at 11:58 AM, Boris Ostrovsky
Current PVH implementation has never been described as
production-ready. What is happening now with HVMlite is
essentially bringing PVH to production-quality level.


So should I s/PVH/HVMlite/g?


 From user perspective that will be almost true. I am not sure it should
be classified as PV mode anymore since it's really an HVM guest without
any devices. But it's not there yet so it's too early to point your
editor there.

BTW, I don't think the flowchart in the wiki is correct as far as PVH is
concerned --- you can't use PVH unless HVM (and, in fact, PVHVM) is
supported.


Noting the very recent flurry of HVMLite activity, so where does PVH sit?

As it's not production-ready (and, atm, unusable here), is it planned to 
be?  Or is it being simply leap-frogged by HVMLite?



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

Re: [Xen-devel] [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

[Luis R. Rodriguez]

On Thu, Feb 04, 2016 at 12:51:38AM +, Andrew Cooper wrote:
> On 03/02/2016 23:59, Luis R. Rodriguez wrote:
> > On Wed, Feb 03, 2016 at 08:52:50PM +, Andrew Cooper wrote:
> >> On 03/02/16 18:55, Luis R. Rodriguez wrote:
> >>> We add new hypervisor type to close the semantic gap for hypervisor 
> >>> types, and
> >>> much like subarch enable also a subarch_data to let you pass and use your
> >>> hvmlite_start_info. This would not only help with the semantics but also 
> >>> help
> >>> avoid yet-another-entry point and force us to provide a well define 
> >>> structure
> >>> for considering code that should not run by pegging it as required or 
> >>> supported
> >>> for different early x86 code stubs.
> >> Was I unclear last time?  Xen *will not* be introducing Linux-specifics
> >> into the HVMLite starting ABI.
> > This does not have to be "Linux specifics" but rather a light way to enable
> > a hypervisor to clue in *any* OS of its hypervisor type, guest type, and
> > custom hypervisor data that can be used to populate needed OS specifics
> > about the guest. Perhaps Xen's own loader mechanism could be extended just
> > slightly to become *that* standard, its just right now it doesn't seem to
> > enable for generalizing this in a very useful way for OSes. Its all
> > custom stubs.
> 
> There are already standard x86 ways of doing this, via the hypervisor
> cpuid bits.  Xen presents itself normally in this regard, as do all the
> other hypervisors.

I don't think this is availably early in asm boot? Its why I think the
zero page is convenient. The boot loader should in theory know these
things, as well as if its in 32-bit, 64-bit, etc.

> It is completely backwards to expect a hypervisor (or toolstack in our
> case) to deliberately prod what it suspects might be a Linux binary in a
> way which it things a Linux binary might like to be prodded.

Perhaps prodding tons of info seems ludicrous, however prodding at least a
loader type and custom data pointer to interpret that so that then your stub
can interpret seems sensible for many reasons and I don't think prodding two
things is much to ask for, given the possible gains on clean architecture.
Its why I am suggesting perhaps this should just be standardized.

We need flexibility on both sides.

> >> Your perceived problem with multiple entry points is not a problem with
> >> multiple entry points; It is a problem with multiple different paths
> >> performing the same initialisation.
> > Its actually more of an issue with the lack of strong general semantics
> > available for different hypervisors and guest types and requirements for 
> > x86's
> > init path. What you end up with as collateral is multiple entry points, and
> > these can be sloppy and as you note can perform the same initialisation.
> > Another issue is the inability to proactively ensure new x86 init code
> > addresses different x86 requirements (cr4 shadow regression and Kasan still
> > being broken on Xen are two examples) and it just so happens that the lack 
> > of
> > semantics for the different guest types required to be evaluated is one 
> > issue
> > for x86.
> >
> > We can do better.
> 
> Even with a perfect startup() routine which caters for all runtime
> usecases, you cannot avoid having multiple entry stubs to cater for the
> different ways the binary might be started.
> 
> Unless you are volunteering to write a single stub which can first
> evaluate whether it is in 16/32/64bit mode, then create a safe stack to
> use, then evaluate how it was started (multiboot, legacy BIOS, EFI,
> etc.) and turn all this information into a zeropage.
> 
> I don't know that would be possible, but the point is moot as it
> definitely wouldn't be maintainable if it were possible.

I think some folks have hope at least some of it might be. I can't do this,
otherwise I would have done it already. Given my review of the commit logs on
different entry points, and code I do think its sensible to desire this to help
with semantics on startup and this should in turn help duplication, bugs, but I
obviously do not doubt its difficulty.

Its at least sensible in my mind to strive towards the best possible semantics
and code sharing from x86-64 bit onwards and if I can help with that I'll do
what I can.

> >> The Linux entry for PV guests is indeed completely horrible.  I am not
> >> trying to defend it in the slightest.
> >>
> >> However, the HVMLite entry which is a very short stub that sets up a
> >> zeropage and hands off to the native start routine is fine.
> > Its alright, and a huge stepping stone towards good architecture. We
> > however can do better.
> 
> Then we are generally in agreement.  However, at the risk of sounding
> like a grump old sod,  take this win first and then work on the next
> stepping stone.

I think this is fair.

> Review comments identifying "I am working on implementing a new $X which
> will make this area better/easier/more shiny in the future" are fine. 
> Review 

Re: [Xen-devel] [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary?

[Steven Haigh]

On 2016-02-05 09:22, Andrew Cooper wrote:

On 04/02/2016 22:06, Alex Braunegg wrote:

root 30511 46.4  0.1 398728  1860 ?RLsl 08:47   0:27
/usr/lib/xen/bin/qemu-system-i386 -xen-domid 6 -chardev
socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-6,server,n
owait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev
socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-6,server,nowait
-mon chardev=libxenstat-cmd,mode=control
-nodefaults -name test2 -vnc
0.0.0.0:0,websocket,x509=/etc/pki/xen,password,to=99 -display none 
-serial
pty -device VGA,vgamem_mb=16 -boot order=cd -usb -usbdevice tablet 
-soundhw
 ac97 -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:f1:48:8c 
-netdev
type=tap,id=net0,ifname=vif6.0-emu,script=no,downscript=no -machine 
xenfv -m

496 -drive file=/dev/zvol/stor
age0/xen/test2/disk_sda,if=ide,index=0,media=disk,format=raw,cache=writeback
-drive
file=/storage0/data-shares/iso/CentOS-6.5-x86_64-minimal.iso,if=ide,index=2,
readonly=on,media=c
drom,format=raw,cache=writeback,id=ide-5632

--

So - to me it appears that xl is performing some sort of x86_64 -> 
i386/i686

instruction translation to make things work.

Would this not be introducing a performance impediment by having some 
sort
of extra translation processing going on between xl and the qemu 
binary?


Qemu is only used for device emulation when used with Xen, not CPU
emulation.

The "-machine xenfv" tells this to Qemu, and "-xen-domid 6" tells it
which Xen domain to connect to.

All HVM domains run with hardware virtualisation extensions, which are
managed by Xen itself.


Hi Andrew,

Thanks for this response - to ensure I have this correct, there is no 
need for qemu-upstream to build qemu-system-x86_64 as the CPU is 
directly handled by Xen and not by qemu - thereby passing through the 
capabilities of the CPU directly to the guest. As such, as long as qemu 
starts on a 64 bit machine it will be able to run 64 bit OS/kernel etc.


I ask this as I see a number of qemu packages that do include 
qemu-system-x86_64 as well as qemu-system-i386 - which makes me seek 
clarification. I would assume that these are just not built to use Xen 
as the hypervisor for hardware acceleration?


--
Steven Haigh

Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897

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

[Xen-devel] [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary?

[Alex Braunegg]

Hi all,

Following on from Steven's question
(http://lists.xen.org/archives/html/xen-devel/2016-02/msg00801.html) - I
have a question around xl's usage of the 'qemu-system-i386' binary

When I was testing the changes required for enabling websockets, I was
testing qemu by itself (to validate that vnc & websockets were working
through qemu) by using the a command similar to the following:

/usr/lib/xen/bin/qemu-system-i386 -boot d -cdrom
/storage0/data-shares/iso/CentOS-6.5-x86_64-minimal.iso -vnc
:1,websocket,x509=/etc/pki/xen

In this case, proceeding past the 'Install' selection of the ISO Grub menu
always resulted in the following error:

This kernel requires an x86_64 CPU but only detected an i686 CPU
Unable to boot - please use a kernel appropriate for your CPU

I get this and understand why - I invoked qemu using 'qemu-system-i386'
which is emulating an i386 / i686 system.

This is where things get interesting - consider the following HVM
configuration (test2.cfg):

--

builder='hvm'
memory = 512
shadow_memory = 8
uuid = '4789b84d-3cdd-409f-9899-88bb13652176'
name = 'test2'
vif = [ 'bridge=br0, mac=00:16:3e:f1:48:8c' ]
disk = [
'/dev/zvol/storage0/xen/test2/disk_sda,,hda','/storage0/data-shares/iso/Cent
OS-6.5-x86_64-minimal.iso,,hdc,cdrom' ]
boot='cd'
sdl=0
vnc=1
vncconsole=1
vnclisten='0.0.0.0'
stdvga=1
serial='pty'
usbdevice='tablet'
vncpasswd='12fDKOkCEZ'
vncdisplay=0
localtime=1
audio='1'
soundhw='ac97'

--

When the configuration file is used via 'xl':

xl create /etc/xen/config/test2.cfg

The virtual machine starts without issue, there is no problem installing the
system, there is no OS warning about the CPU type. 

Looking at the ps output:

--

root 30511 46.4  0.1 398728  1860 ?RLsl 08:47   0:27
/usr/lib/xen/bin/qemu-system-i386 -xen-domid 6 -chardev
socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-6,server,n
owait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev
socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-6,server,nowait
-mon chardev=libxenstat-cmd,mode=control
-nodefaults -name test2 -vnc
0.0.0.0:0,websocket,x509=/etc/pki/xen,password,to=99 -display none -serial
pty -device VGA,vgamem_mb=16 -boot order=cd -usb -usbdevice tablet -soundhw
 ac97 -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:f1:48:8c -netdev
type=tap,id=net0,ifname=vif6.0-emu,script=no,downscript=no -machine xenfv -m
496 -drive file=/dev/zvol/stor
age0/xen/test2/disk_sda,if=ide,index=0,media=disk,format=raw,cache=writeback
-drive
file=/storage0/data-shares/iso/CentOS-6.5-x86_64-minimal.iso,if=ide,index=2,
readonly=on,media=c
drom,format=raw,cache=writeback,id=ide-5632

--

So - to me it appears that xl is performing some sort of x86_64 -> i386/i686
instruction translation to make things work.

Would this not be introducing a performance impediment by having some sort
of extra translation processing going on between xl and the qemu binary?




Best regards,

Alex








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

[Xen-devel] [PATCH v5 for Xen 4.7 0/4] Enable per-VCPU parameter settings for RTDS scheduler

[Chong Li]

[Goal]
The current xl sched-rtds tool can only set the VCPUs of a domain 
to the same parameter although the scheduler supports VCPUs with 
different parameters. This patchset is to enable xl sched-rtds 
tool to configure the VCPUs of a domain with different parameters.

This per-VCPU settings can be used in many scenarios. For example,
based on Dario's statement in our pervious discussion
(http://lists.xen.org/archives/html/xen-devel/2014-09/msg00423.html), 
if there are two real-time applications, which have different timing 
requirements, running in a multi-VCPU guest domain, it is beneficial 
to pin these two applications to two seperate VCPUs with different 
scheduling parameters.

What this patchset includes is a wanted and planned feature for RTDS 
scheudler(http://wiki.xenproject.org/wiki/RTDS-Based-Scheduler) in 
Xen 4.6. The interface design of the xl sched-rtds tool is based on 
Meng's previous discussion with Dario, George and Wei
(http://lists.xen.org/archives/html/xen-devel/2015-02/msg02606.html).
Basically, there are two main changes:

1) in xl, we create an array that records all VCPUs whose parameters 
are about to modify or output.

2) in libxl, we receive the array and call different xc functions to 
handle it.

3) in xen and libxc, we use 
XEN_DOMCTL_SCHEDOP_getvcpuinfo/putvcpuinfo(introduced by this
patchset) as the hypercall for per-VCPU operations(get/set method).


[Usage]
With this patchset in use, xl sched-rtds tool can:

1) show the budget and period of each VCPU of each domain, 
by using "xl sched-rtds -v all" command. An example would be like:

# xl sched-rtds -v all
Cpupool Pool-0: sched=RTDS
NameID VCPUPeriodBudget
Domain-0 00 1  4000
vm1  10   300   150
vm1  11   400   200
vm1  12 1  4000
vm1  13  1000   500
vm2  20 1  4000
vm2  21 1  4000

Using "xl sched-rtds" will output the default scheduling parameters
for each domain. An example would be like:

# xl sched-rtds
Cpupool Pool-0: sched=RTDS
NameIDPeriodBudget
Domain-0 0 1  4000
vm1  1 1  4000
vm2  2 1  4000


2) show the budget and period of each VCPU of a specific domain, 
by using, e.g., "xl sched-rtds -d vm1 -v all" command. The output 
would be like:

# xl sched-rtds -d vm1 -v all
NameID VCPUPeriodBudget
vm1  10   300   150
vm1  11   400   200
vm1  12 1  4000
vm1  13  1000   500

To show a subset of the parameters of the VCPUs of a specific domain, 
please use, e.g.,"xl sched-rtds -d vm1 -v 0 -v 3" command. 
The output would be:

# xl sched-rtds -d vm1 -v 0 -v 3
NameID VCPUPeriodBudget
vm1  10   300   150
vm1  13  1000   500

Using command, e.g., "xl sched-rtds -d vm1" will output the default
scheduling parameters of vm1. An example would be like:

# xl sched-rtds -d vm1
NameIDPeriodBudget
vm1  1 1  4000


3) Users can set the budget and period of multiple VCPUs of a 
specific domain with only one command, 
e.g., "xl sched-rtds -d vm1 -v 0 -p 100 -b 50 -v 3 -p 300 -b 150".

Users can set all VCPUs with the same parameters, by one command.
e.g., "xl sched-rtds -d vm1 -v all -p 500 -b 250".


---
Previous conclusion:
On PATCH v4, our concern was about the usage of hypercall_preemption_check
and the print of warning message (both in xen). These issues are addressed 
in this patch.


CC: 
CC: 
CC: 
CC: 
CC: 
CC: 
CC: 
CC: 
CC: 


Chong Li (4):
  xen: enable per-VCPU parameter settings for RTDS scheduler
  libxc: enable per-VCPU parameter settings for RTDS scheduler
  libxl: enable per-VCPU parameter settings for RTDS scheduler
  xl: enable per-VCPU parameter settings for RTDS scheduler

 docs/man/xl.pod.1 |   4 +
 tools/libxc/include/xenctrl.h |   8 ++
 tools/libxc/xc_rt.c   |  56 
 tools/libxl/libxl.c   | 249 +++---
 tools/libxl/libxl.h   |  19 +++
 tools/libxl/libxl_types.idl   |  16 +++
 

Re: [Xen-devel] [RFC v1 1/8] paravirt: rename paravirt_enabled to paravirt_legacy

[Luis R. Rodriguez]

On Wed, Jan 20, 2016 at 11:32 AM, Konrad Rzeszutek Wilk
 wrote:
> On Tue, Dec 15, 2015 at 02:16:30PM -0800, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez" 
>
> Hey Luis,
>
> Sorry for the long time to respond..
>>
>> paravirt_enabled conveys the idea that if this is set or if
>> paravirt_enabled() returns true you are in a paravirtualized
>> environment. This is not true, this is really only useful to
>> determine if you have a paravirtualization hypervisor that uses
>
> s/users//
>> supports legacy paravirtualized guests. At run time, this tells
>> us if we've booted into a Linux guest with support for legacy
>> paravirtualized guests.
>
> I know I suggested the name but when I look at the words
> 'paravirtualized legacy' immediately I thought about legacy PV
> drivers.. which we do not have in the code.

OK...

> The description:
>
>> + *   paravirtualized guests. Examples of features that
>> + *   characterize legacy paravirtualized guests are
>> + *   things such as the need for APM, PNP BIOS.
>
> Explains it very nicely.
>
> Perhaps (And sorry for that) it should be just called
>
> legacy_platform() ?
>
> Or
> ancient_platform() ?

No, we need to prefix this as its paravirt related, I've given this
silly little rename quite a bit of thought and have decided to stick
to paravirt_legacy() and just adding paravirt_legacy_free() as a
separate helper. The clarification can simply be placed through kdoc
form in documentation. More on this below.

> Since that would lead folks to immediately think of things
> that existed long time ago - such as APM or PNP BIOS.

Right.

> Other suggestions would be to piggyback on Microsoft pushing
> the option in the BIOS to have an "Legacy Free" option (PS/2,
> PnP, serial port, parallel port - all are disabled):
> https://en.wikipedia.org/wiki/Legacy-free_PC

Interesting, yes I like this as it has stronger semantics. I looked
further and it seems this concept of "legacy free" comes from the PC
system design guide [0] by both Microsoft and Intel. The latest of
such documents and the latest definitions of a PC 2001 contains the
concept of "legacy free" and defines it well on Page 50 [1] under the
"PC 2001 requirements". It notes:


The basic goal for the legacy-free system requirements is that the
operating system and devices do not use any of the following

  * ISA slots or devices
  * Legacy FDC
  *  PS/2, serial, parallel, and game ports

Revisions to the ACPI specification provide a mechanism that allows
the BIOS to report whether a system provides the services of these
components and interfaces. If the BIOS reports that the system is
legacy free, the system must meet the requirements provided in this
section.


[0] http://tech-insider.org/windows/research/2000/1102.html
[1] http://tech-insider.org/windows/research/acrobat/001102/03sys-2001.pdf

> Perhaps:
>
> legacy_free() ?

That's a negation of the question "is legacy?", so this would be a
separate call. Also this doesn't have a prefix.

Note that what is legacy on x86 today may be very legacy tomorrow and
later on there may be other notions of legacy... so sticking loosely
to at least the "PC 2001" definition seems to make sense here and
would limit scope and date the notion of "legacy" here for x86 and for
this paravirt hook. For now I don't see a need to include a date check
though as its a paravirt check anyway, but at least the definition
needs to limit the scope in its documentation for now.

This particular check is *if your hypervisor* supports legacy PC 2001
systems, so we do in the end need a prefix given the question as to
whether or not the kernel can determine you are on a legacy free
system or not is a separate possible question. The above definition
seems to indicate that ACPI should allow the BIOS to reoport if a
system is legacy free or not, so if such mechanisms exist, code that
currently has sprinkled paravirt_enabled() (we'll rename this soon)
could also have such checks for legacy free as well. Once, and if,
such system check is available perhaps we should prevent a legacy free
hypervisor from booting on a legacy system.

Likewise with such system check present if a PV legacy capable
hypervisor boots a legacy free system -- the code checks for
subsystems that are legacy would avoid running given that although
pavarit_supports_legacy() gives true, is_system_legacy() would give
false and avoid running.

Anyway, unless I hear of better suggestions I'm going to stick to
paravirt_legacy() and add paravirt_legacy_free(), and just expand on
the documentation to help clarify this is not for PV legacy drivers.

> Thank you!

 Luis

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

[Xen-devel] [PATCH v5 for Xen 4.7 3/4] libxl: enable per-VCPU parameter settings for RTDS scheduler

[Chong Li]

Add libxl_vcpu_sched_params_get/set and sched_rtds_vcpu_get/set
functions to support per-VCPU settings.

Signed-off-by: Chong Li 
Signed-off-by: Meng Xu 
Signed-off-by: Sisu Xi 

---
Changes on PATCH v4:
1) Coding style changes

Changes on PATCH v3:
1) Add sanity check on vcpuid

2) Add comments on per-domain and per-vcpu functions for libxl
users

Changes on PATCH v2:
1) New data structure (libxl_vcpu_sched_params and libxl_sched_params)
to help per-VCPU settings.

2) sched_rtds_vcpu_get now can return a random subset of the parameters
of the VCPUs of a specific domain.

CC: 
CC: 
CC: 
CC: 
CC: 
CC: 
CC: 
CC: 
---
 tools/libxl/libxl.c | 249 
 tools/libxl/libxl.h |  19 
 tools/libxl/libxl_types.idl |  16 +++
 3 files changed, 262 insertions(+), 22 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index bd3aac8..ac4a103 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5770,6 +5770,151 @@ static int sched_credit2_domain_set(libxl__gc *gc, 
uint32_t domid,
 return 0;
 }
 
+static int sched_rtds_validate_params(libxl__gc *gc, int period,
+ int budget, uint32_t *sdom_period,
+ uint32_t *sdom_budget)
+{
+if (period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT) {
+if (period < 1) {
+LOG(ERROR, "VCPU period is out of range, "
+   "valid values are larger than or equal to 1");
+return 1; /* error scheduling parameter */
+}
+*sdom_period = period;
+}
+
+if (budget != LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT) {
+if (budget < 1) {
+LOG(ERROR, "VCPU budget is not set or out of range, "
+   "valid values are larger than or equal to 1");
+return 1;
+}
+*sdom_budget = budget;
+}
+
+if (budget > period) {
+LOG(ERROR, "VCPU budget must be smaller than "
+   "or equal to VCPU period");
+return 1;
+}
+
+return 0; /* period and budget are valid */
+}
+
+static int sched_rtds_vcpu_get(libxl__gc *gc, uint32_t domid,
+   libxl_vcpu_sched_params *scinfo)
+{
+uint32_t num_vcpus;
+int rc, i;
+xc_dominfo_t info;
+struct xen_domctl_schedparam_vcpu *vcpus;
+
+rc = xc_domain_getinfo(CTX->xch, domid, 1, );
+if (rc < 0) {
+LOGE(ERROR, "getting domain info");
+return ERROR_FAIL;
+}
+
+num_vcpus = scinfo->num_vcpus ? scinfo->num_vcpus :
+info.max_vcpu_id + 1;
+
+GCNEW_ARRAY(vcpus, num_vcpus);
+
+if (scinfo->num_vcpus > 0)
+for (i=0; i < num_vcpus; i++) {
+if (scinfo->vcpus[i].vcpuid < 0 ||
+scinfo->vcpus[i].vcpuid > info.max_vcpu_id) {
+LOG(ERROR, "VCPU index is out of range, "
+   "valid values are within range from 0 to %d",
+   info.max_vcpu_id);
+return ERROR_INVAL;
+}
+vcpus[i].vcpuid = scinfo->vcpus[i].vcpuid;
+} else
+for (i=0; i < num_vcpus; i++)
+vcpus[i].vcpuid = i;
+
+rc = xc_sched_rtds_vcpu_get(CTX->xch, domid, vcpus, num_vcpus);
+if (rc != 0) {
+LOGE(ERROR, "getting vcpu sched rtds");
+return ERROR_FAIL;
+}
+scinfo->sched = LIBXL_SCHEDULER_RTDS;
+if (scinfo->num_vcpus == 0) {
+scinfo->num_vcpus = num_vcpus;
+scinfo->vcpus = libxl__calloc(NOGC, num_vcpus,
+sizeof(libxl_sched_params));
+}
+for(i = 0; i < num_vcpus; i++) {
+scinfo->vcpus[i].period = vcpus[i].s.rtds.period;
+scinfo->vcpus[i].budget = vcpus[i].s.rtds.budget;
+scinfo->vcpus[i].vcpuid = vcpus[i].vcpuid;
+}
+
+return 0;
+}
+
+static int sched_rtds_vcpu_set(libxl__gc *gc, uint32_t domid,
+   const libxl_vcpu_sched_params *scinfo)
+{
+int rc;
+int i;
+uint16_t max_vcpuid;
+xc_dominfo_t info;
+struct xen_domctl_schedparam_vcpu *vcpus;
+uint32_t num_vcpus;
+
+rc = xc_domain_getinfo(CTX->xch, domid, 1, );
+if (rc < 0) {
+LOGE(ERROR, "getting domain info");
+return ERROR_FAIL;
+}
+max_vcpuid = info.max_vcpu_id;
+
+if (scinfo->num_vcpus > 0) {
+num_vcpus = scinfo->num_vcpus;
+GCNEW_ARRAY(vcpus, num_vcpus);
+for (i = 0; i < num_vcpus; i++) {
+if (scinfo->vcpus[i].vcpuid < 0 ||
+scinfo->vcpus[i].vcpuid > max_vcpuid) {
+LOG(ERROR, "VCPU index is out of range, "
+   "valid values are within 

[Xen-devel] [PATCH v5 for Xen 4.7 4/4] xl: enable per-VCPU parameter settings for RTDS scheduler

[Chong Li]

Change main_sched_rtds and related output functions to support
per-VCPU settings.

Signed-off-by: Chong Li 
Signed-off-by: Meng Xu 
Signed-off-by: Sisu Xi 

---
Changes on PATCH v4:
1) Coding style changes

Changes on PATCH v3:
1) Support commands, e.g., "xl sched-rtds -d vm1" to output the
default scheduling parameters

Changes on PATCH v2:
1) Remove per-domain output functions for RTDS scheduler.

2) Users now use '-v all' to specify all VCPUs.

3) Support outputting a subset of the parameters of the VCPUs
of a specific domain.

4) When setting all VCPUs with the same parameters (by only one
command), no per-domain function is invoked.

CC: 
CC: 
CC: 
CC: 
CC: 
CC: 
---
 docs/man/xl.pod.1 |   4 +
 tools/libxl/xl_cmdimpl.c  | 305 --
 tools/libxl/xl_cmdtable.c |  10 +-
 3 files changed, 281 insertions(+), 38 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 4279c7c..f9ff917 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1051,6 +1051,10 @@ B
 Specify domain for which scheduler parameters are to be modified or retrieved.
 Mandatory for modifying scheduler parameters.
 
+=item B<-v VCPUID/all>, B<--vcpuid=VCPUID/all>
+
+Specify vcpu for which scheduler parameters are to be modified or retrieved.
+
 =item B<-p PERIOD>, B<--period=PERIOD>
 
 Period of time, in microseconds, over which to replenish the budget.
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2b6371d..b843fa5 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5823,6 +5823,39 @@ static int sched_domain_set(int domid, const 
libxl_domain_sched_params *scinfo)
 return 0;
 }
 
+static int sched_vcpu_get(libxl_scheduler sched, int domid,
+libxl_vcpu_sched_params *scinfo)
+{
+int rc;
+
+rc = libxl_vcpu_sched_params_get(ctx, domid, scinfo);
+if (rc) {
+fprintf(stderr, "libxl_vcpu_sched_params_get failed.\n");
+exit(-1);
+}
+if (scinfo->sched != sched) {
+fprintf(stderr, "libxl_vcpu_sched_params_get returned %s not %s.\n",
+libxl_scheduler_to_string(scinfo->sched),
+libxl_scheduler_to_string(sched));
+return 1;
+}
+
+return 0;
+}
+
+static int sched_vcpu_set(int domid, const libxl_vcpu_sched_params *scinfo)
+{
+int rc;
+
+rc = libxl_vcpu_sched_params_set(ctx, domid, scinfo);
+if (rc) {
+fprintf(stderr, "libxl_vcpu_sched_params_set failed.\n");
+exit(-1);
+}
+
+return rc;
+}
+
 static int sched_credit_params_set(int poolid, libxl_sched_credit_params 
*scinfo)
 {
 if (libxl_sched_credit_params_set(ctx, poolid, scinfo)) {
@@ -5942,6 +5975,38 @@ static int sched_rtds_domain_output(
 return 0;
 }
 
+static int sched_rtds_vcpu_output(
+int domid, libxl_vcpu_sched_params *scinfo)
+{
+char *domname;
+int rc = 0;
+int i;
+
+if (domid < 0) {
+printf("%-33s %4s %4s %9s %9s\n", "Name", "ID",
+"VCPU", "Period", "Budget");
+return 0;
+}
+
+rc = sched_vcpu_get(LIBXL_SCHEDULER_RTDS, domid, scinfo);
+if (rc)
+goto out;
+
+domname = libxl_domid_to_name(ctx, domid);
+for( i = 0; i < scinfo->num_vcpus; i++ ) {
+printf("%-33s %4d %4d %9"PRIu32" %9"PRIu32"\n",
+domname,
+domid,
+scinfo->vcpus[i].vcpuid,
+scinfo->vcpus[i].period,
+scinfo->vcpus[i].budget);
+}
+free(domname);
+
+out:
+return rc;
+}
+
 static int sched_rtds_pool_output(uint32_t poolid)
 {
 char *poolname;
@@ -6015,6 +6080,65 @@ static int sched_domain_output(libxl_scheduler sched, 
int (*output)(int),
 return 0;
 }
 
+static int sched_vcpu_output(libxl_scheduler sched,
+   int (*output)(int, libxl_vcpu_sched_params *),
+   int (*pooloutput)(uint32_t), const char 
*cpupool)
+{
+libxl_dominfo *info;
+libxl_cpupoolinfo *poolinfo = NULL;
+uint32_t poolid;
+int nb_domain, n_pools = 0, i, p;
+int rc = 0;
+
+if (cpupool) {
+if (libxl_cpupool_qualifier_to_cpupoolid(ctx, cpupool, , NULL)
+|| !libxl_cpupoolid_is_valid(ctx, poolid)) {
+fprintf(stderr, "unknown cpupool \'%s\'\n", cpupool);
+return -ERROR_FAIL;
+}
+}
+
+info = libxl_list_domain(ctx, _domain);
+if (!info) {
+fprintf(stderr, "libxl_list_domain failed.\n");
+return 1;
+}
+poolinfo = libxl_list_cpupool(ctx, _pools);
+if (!poolinfo) {
+fprintf(stderr, "error getting cpupool info\n");
+libxl_dominfo_list_free(info, nb_domain);
+return -ERROR_NOMEM;
+}
+
+for (p = 0; !rc && (p < n_pools); p++) {
+   

[Xen-devel] [PATCH v5 for Xen 4.7 2/4] libxc: enable per-VCPU parameter settings for RTDS scheduler

[Chong Li]

Add xc_sched_rtds_vcpu_get/set functions to interact with
Xen to get/set a domain's per-VCPU parameters.

Signed-off-by: Chong Li 
Signed-off-by: Meng Xu 
Signed-off-by: Sisu Xi 

---
Changes on PATCH v4:
1) Minor modifications on the function parameters.

Changes on PATCH v2:
1) Minor modifications due to the change of struct xen_domctl_scheduler_op.

CC: 
CC: 
CC: 
CC: 
CC: 
CC: 
---
 tools/libxc/include/xenctrl.h |  8 +++
 tools/libxc/xc_rt.c   | 56 +++
 2 files changed, 64 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 01a6dda..db13434 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -893,6 +893,14 @@ int xc_sched_rtds_domain_set(xc_interface *xch,
 int xc_sched_rtds_domain_get(xc_interface *xch,
 uint32_t domid,
 struct xen_domctl_sched_rtds *sdom);
+int xc_sched_rtds_vcpu_set(xc_interface *xch,
+uint32_t domid,
+struct xen_domctl_schedparam_vcpu *vcpus,
+uint32_t num_vcpus);
+int xc_sched_rtds_vcpu_get(xc_interface *xch,
+uint32_t domid,
+struct xen_domctl_schedparam_vcpu *vcpus,
+uint32_t num_vcpus);
 
 int
 xc_sched_arinc653_schedule_set(
diff --git a/tools/libxc/xc_rt.c b/tools/libxc/xc_rt.c
index d59e5ce..cb7bc1a 100644
--- a/tools/libxc/xc_rt.c
+++ b/tools/libxc/xc_rt.c
@@ -62,3 +62,59 @@ int xc_sched_rtds_domain_get(xc_interface *xch,
 
 return rc;
 }
+
+int xc_sched_rtds_vcpu_set(xc_interface *xch,
+   uint32_t domid,
+   struct xen_domctl_schedparam_vcpu *vcpus,
+   uint32_t num_vcpus)
+{
+int rc;
+DECLARE_DOMCTL;
+DECLARE_HYPERCALL_BOUNCE(vcpus, sizeof(*vcpus) * num_vcpus,
+XC_HYPERCALL_BUFFER_BOUNCE_IN);
+
+if ( xc_hypercall_bounce_pre(xch, vcpus) )
+return -1;
+
+domctl.cmd = XEN_DOMCTL_scheduler_op;
+domctl.domain = (domid_t) domid;
+domctl.u.scheduler_op.sched_id = XEN_SCHEDULER_RTDS;
+domctl.u.scheduler_op.cmd = XEN_DOMCTL_SCHEDOP_putvcpuinfo;
+domctl.u.scheduler_op.u.v.nr_vcpus = num_vcpus;
+set_xen_guest_handle(domctl.u.scheduler_op.u.v.vcpus, vcpus);
+domctl.u.scheduler_op.u.v.vcpu_index = 0;
+
+rc = do_domctl(xch, );
+
+xc_hypercall_bounce_post(xch, vcpus);
+
+return rc;
+}
+
+int xc_sched_rtds_vcpu_get(xc_interface *xch,
+   uint32_t domid,
+   struct xen_domctl_schedparam_vcpu *vcpus,
+   uint32_t num_vcpus)
+{
+int rc;
+DECLARE_DOMCTL;
+DECLARE_HYPERCALL_BOUNCE(vcpus, sizeof(*vcpus) * num_vcpus,
+XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
+
+if ( xc_hypercall_bounce_pre(xch, vcpus) )
+return -1;
+
+domctl.cmd = XEN_DOMCTL_scheduler_op;
+domctl.domain = (domid_t) domid;
+domctl.u.scheduler_op.sched_id = XEN_SCHEDULER_RTDS;
+domctl.u.scheduler_op.cmd = XEN_DOMCTL_SCHEDOP_getvcpuinfo;
+domctl.u.scheduler_op.u.v.nr_vcpus = num_vcpus;
+set_xen_guest_handle(domctl.u.scheduler_op.u.v.vcpus, vcpus);
+domctl.u.scheduler_op.u.v.vcpu_index = 0;
+
+rc = do_domctl(xch, );
+
+xc_hypercall_bounce_post(xch, vcpus);
+
+return rc;
+}
-- 
1.9.1


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

[Xen-devel] [PULL 44/49] fix MSI injection on Xen

[Michael S. Tsirkin]

From: Stefano Stabellini 

On Xen MSIs can be remapped into pirqs, which are a type of event
channels. It's mostly for the benefit of PCI passthrough devices, to
avoid the overhead of interacting with the emulated lapic.

However remapping interrupts and MSIs is also supported for emulated
devices, such as the e1000 and virtio-net.

When an interrupt or an MSI is remapped into a pirq, masking and
unmasking is done by masking and unmasking the event channel. The
masking bit on the PCI config space or MSI-X table should be ignored,
but it isn't at the moment.

As a consequence emulated devices which use MSI or MSI-X, such as
virtio-net, don't work properly (the guest doesn't receive any
notifications). The mechanism was working properly when xen_apic was
introduced, but I haven't narrowed down which commit in particular is
causing the regression.

Fix the issue by ignoring the masking bit for MSI and MSI-X which have
been remapped into pirqs.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 include/hw/xen/xen.h |  1 +
 hw/pci/msi.c |  9 -
 hw/pci/msix.c| 12 ++--
 hw/xen/xen_pt_msi.c  |  4 +---
 xen-hvm-stub.c   |  5 +
 xen-hvm.c|  9 +
 6 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 1b81b4b..c577354 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -33,6 +33,7 @@ int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num);
 void xen_piix3_set_irq(void *opaque, int irq_num, int level);
 void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len);
 void xen_hvm_inject_msi(uint64_t addr, uint32_t data);
+int xen_is_pirq_msi(uint32_t msi_data);
 
 qemu_irq *xen_interrupt_controller_init(void);
 
diff --git a/hw/pci/msi.c b/hw/pci/msi.c
index 8efa23d..85f21b8 100644
--- a/hw/pci/msi.c
+++ b/hw/pci/msi.c
@@ -20,6 +20,7 @@
 
 #include "qemu/osdep.h"
 #include "hw/pci/msi.h"
+#include "hw/xen/xen.h"
 #include "qemu/range.h"
 
 /* PCI_MSI_ADDRESS_LO */
@@ -254,13 +255,19 @@ void msi_reset(PCIDevice *dev)
 static bool msi_is_masked(const PCIDevice *dev, unsigned int vector)
 {
 uint16_t flags = pci_get_word(dev->config + msi_flags_off(dev));
-uint32_t mask;
+uint32_t mask, data;
+bool msi64bit = flags & PCI_MSI_FLAGS_64BIT;
 assert(vector < PCI_MSI_VECTORS_MAX);
 
 if (!(flags & PCI_MSI_FLAGS_MASKBIT)) {
 return false;
 }
 
+data = pci_get_word(dev->config + msi_data_off(dev, msi64bit));
+if (xen_is_pirq_msi(data)) {
+return false;
+}
+
 mask = pci_get_long(dev->config +
 msi_mask_off(dev, flags & PCI_MSI_FLAGS_64BIT));
 return mask & (1U << vector);
diff --git a/hw/pci/msix.c b/hw/pci/msix.c
index 4fea7ed..eb4ef11 100644
--- a/hw/pci/msix.c
+++ b/hw/pci/msix.c
@@ -19,6 +19,7 @@
 #include "hw/pci/msi.h"
 #include "hw/pci/msix.h"
 #include "hw/pci/pci.h"
+#include "hw/xen/xen.h"
 #include "qemu/range.h"
 
 #define MSIX_CAP_LENGTH 12
@@ -78,8 +79,15 @@ static void msix_clr_pending(PCIDevice *dev, int vector)
 
 static bool msix_vector_masked(PCIDevice *dev, unsigned int vector, bool fmask)
 {
-unsigned offset = vector * PCI_MSIX_ENTRY_SIZE + 
PCI_MSIX_ENTRY_VECTOR_CTRL;
-return fmask || dev->msix_table[offset] & PCI_MSIX_ENTRY_CTRL_MASKBIT;
+unsigned offset = vector * PCI_MSIX_ENTRY_SIZE;
+uint32_t *data = (uint32_t *)>msix_table[offset + 
PCI_MSIX_ENTRY_DATA];
+/* MSIs on Xen can be remapped into pirqs. In those cases, masking
+ * and unmasking go through the PV evtchn path. */
+if (xen_is_pirq_msi(*data)) {
+return false;
+}
+return fmask || dev->msix_table[offset + PCI_MSIX_ENTRY_VECTOR_CTRL] &
+PCI_MSIX_ENTRY_CTRL_MASKBIT;
 }
 
 bool msix_is_masked(PCIDevice *dev, unsigned int vector)
diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
index 5624685..9a16f2b 100644
--- a/hw/xen/xen_pt_msi.c
+++ b/hw/xen/xen_pt_msi.c
@@ -115,9 +115,7 @@ static int msi_msix_setup(XenPCIPassthroughState *s,
 
 assert((!is_msix && msix_entry == 0) || is_msix);
 
-if (gvec == 0) {
-/* if gvec is 0, the guest is asking for a particular pirq that
- * is passed as dest_id */
+if (xen_is_pirq_msi(data)) {
 *ppirq = msi_ext_dest_id(addr >> 32) | msi_dest_id(addr);
 if (!*ppirq) {
 /* this probably identifies an misconfiguration of the guest,
diff --git a/xen-hvm-stub.c b/xen-hvm-stub.c
index a6cb5d3..c500325 100644
--- a/xen-hvm-stub.c
+++ b/xen-hvm-stub.c
@@ -31,6 +31,11 @@ void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
 {
 }
 
+int xen_is_pirq_msi(uint32_t msi_data)
+{
+return 0;
+}
+
 void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr,
Error **errp)
 {
diff --git a/xen-hvm.c 

Re: [Xen-devel] HVMlite ABI specification DRAFT A

[Samuel Thibault]

Roger Pau Monné, on Thu 04 Feb 2016 20:21:24 +0100, wrote:
> > +1
> > We need that to pass parameters to gnumach modules.
> 
> Hm, parameters as in a string that's paired with a module,

That, yes. Just like the kernel command line. One per module.

> I see that multiboot provides a string associated with each module, we
> could do the same IMHO.

That's it.

> Just to be clear that we are on the same page, then the _entry struct
> becomes:
> 
> struct hvm_modlist_entry {
>   uint32_t paddr;
>   uint32_t size;
>   uint32_t cmdline_paddr;
> };
> 
> cmdline_paddr would work the same way as it does in the hvm_start_info
> struct (ie: physical address of a zero-terminated ASCII string).

That looks alright for me.

Samuel

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

Re: [Xen-devel] [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary?

[Andrew Cooper]

On 04/02/2016 22:06, Alex Braunegg wrote:
> root 30511 46.4  0.1 398728  1860 ?RLsl 08:47   0:27
> /usr/lib/xen/bin/qemu-system-i386 -xen-domid 6 -chardev
> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-6,server,n
> owait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev
> socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-6,server,nowait
> -mon chardev=libxenstat-cmd,mode=control
> -nodefaults -name test2 -vnc
> 0.0.0.0:0,websocket,x509=/etc/pki/xen,password,to=99 -display none -serial
> pty -device VGA,vgamem_mb=16 -boot order=cd -usb -usbdevice tablet -soundhw
>  ac97 -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:f1:48:8c -netdev
> type=tap,id=net0,ifname=vif6.0-emu,script=no,downscript=no -machine xenfv -m
> 496 -drive file=/dev/zvol/stor
> age0/xen/test2/disk_sda,if=ide,index=0,media=disk,format=raw,cache=writeback
> -drive
> file=/storage0/data-shares/iso/CentOS-6.5-x86_64-minimal.iso,if=ide,index=2,
> readonly=on,media=c
> drom,format=raw,cache=writeback,id=ide-5632
>
> --
>
> So - to me it appears that xl is performing some sort of x86_64 -> i386/i686
> instruction translation to make things work.
>
> Would this not be introducing a performance impediment by having some sort
> of extra translation processing going on between xl and the qemu binary?

Qemu is only used for device emulation when used with Xen, not CPU
emulation.

The "-machine xenfv" tells this to Qemu, and "-xen-domid 6" tells it
which Xen domain to connect to.

All HVM domains run with hardware virtualisation extensions, which are
managed by Xen itself.

~Andrew

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

[Xen-devel] [PATCH v5 for Xen 4.7 1/4] xen: enable per-VCPU parameter settings for RTDS scheduler

[Chong Li]

Add XEN_DOMCTL_SCHEDOP_getvcpuinfo and _putvcpuinfo hypercalls
to independently get and set the scheduling parameters of each
vCPU of a domain

Signed-off-by: Chong Li 
Signed-off-by: Meng Xu 
Signed-off-by: Sisu Xi 

---
Changes on PATCH v4:
1) Add uint32_t vcpu_index to struct xen_domctl_scheduler_op.
When processing XEN_DOMCTL_SCHEDOP_get/putvcpuinfo, we call
hypercall_preemption_check in case the current hypercall lasts
too long. If we decide to preempt the current hypercall, we record
the index of the most-recent finished vcpu into the vcpu_index of
struct xen_domctl_scheduler_op. So when we resume the hypercall after
preemption, we start processing from the posion specified by vcpu_index,
and don't need to repeat the work that has already been done in the
hypercall before the preemption.
(This design is based on the do_grant_table_op() in grant_table.c)

2) Coding style changes

Changes on PATCH v3:
1) Remove struct xen_domctl_schedparam_t.

2) Change struct xen_domctl_scheduler_op.

3) Check if period/budget is within a validated range

Changes on PATCH v2:
1) Change struct xen_domctl_scheduler_op, for transferring per-vcpu parameters
between libxc and hypervisor.

2) Handler of XEN_DOMCTL_SCHEDOP_getinfo now just returns the default budget and
period values of RTDS scheduler.

3) Handler of XEN_DOMCTL_SCHEDOP_getvcpuinfo now can return a random subset of
the parameters of the VCPUs of a specific domain

CC: 
CC: 
CC: 
CC: 
CC: 
CC: 
---
 xen/common/domctl.c |   5 ++
 xen/common/sched_credit.c   |   4 ++
 xen/common/sched_credit2.c  |   4 ++
 xen/common/sched_rt.c   | 127 ++--
 xen/common/schedule.c   |  15 --
 xen/include/public/domctl.h |  57 +++-
 6 files changed, 180 insertions(+), 32 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 46b967e..b294221 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -847,9 +847,14 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
 }
 
 case XEN_DOMCTL_scheduler_op:
+{
 ret = sched_adjust(d, >u.scheduler_op);
+if ( ret == -ERESTART )
+ret = hypercall_create_continuation(
+__HYPERVISOR_domctl, "h", u_domctl);
 copyback = 1;
 break;
+}
 
 case XEN_DOMCTL_getdomaininfo:
 {
diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 0dce790..455c684 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -1054,6 +1054,10 @@ csched_dom_cntl(
  * lock. Runq lock not needed anywhere in here. */
 spin_lock_irqsave(>lock, flags);
 
+if ( op->cmd == XEN_DOMCTL_SCHEDOP_putvcpuinfo ||
+ op->cmd == XEN_DOMCTL_SCHEDOP_getvcpuinfo )
+return -EINVAL;
+
 if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
 {
 op->u.credit.weight = sdom->weight;
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 3c49ffa..c3049a0 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1421,6 +1421,10 @@ csched2_dom_cntl(
  * runq lock to update csvcs. */
 spin_lock_irqsave(>lock, flags);
 
+if ( op->cmd == XEN_DOMCTL_SCHEDOP_putvcpuinfo ||
+ op->cmd == XEN_DOMCTL_SCHEDOP_getvcpuinfo )
+return -EINVAL;
+
 if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
 {
 op->u.credit2.weight = sdom->weight;
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 3f1d047..34ae48d 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -86,8 +86,21 @@
 #define RTDS_DEFAULT_PERIOD (MICROSECS(1))
 #define RTDS_DEFAULT_BUDGET (MICROSECS(4000))
 
+/*
+ * Max period: max delta of time type
+ * Min period: 100 us, considering the scheduling overhead
+ */
+#define RTDS_MAX_PERIOD (STIME_DELTA_MAX)
+#define RTDS_MIN_PERIOD (MICROSECS(10))
+
+/*
+ * Min budget: 100 us
+ */
+#define RTDS_MIN_BUDGET (MICROSECS(10))
+
 #define UPDATE_LIMIT_SHIFT  10
 #define MAX_SCHEDULE(MILLISECS(1))
+
 /*
  * Flags
  */
@@ -1129,26 +1142,18 @@ rt_dom_cntl(
 struct vcpu *v;
 unsigned long flags;
 int rc = 0;
-
+xen_domctl_schedparam_vcpu_t local_sched;
+s_time_t period, budget;
+uint32_t index;
 switch ( op->cmd )
 {
-case XEN_DOMCTL_SCHEDOP_getinfo:
-if ( d->max_vcpus > 0 )
-{
-spin_lock_irqsave(>lock, flags);
-svc = rt_vcpu(d->vcpu[0]);
-op->u.rtds.period = svc->period / MICROSECS(1);
-op->u.rtds.budget = svc->budget / MICROSECS(1);
-spin_unlock_irqrestore(>lock, flags);
-}
-else
-{
-/* If we don't have vcpus yet, let's just return the defaults. */
-op->u.rtds.period 

[Xen-devel] [BUG?] qemuu only built with i386-softmmu

[Steven Haigh]

Hi all,

Looking specifically at 4.6.0.

It seems that the Makefile for qemuu uses the following:
$$source/configure --enable-xen --target-list=i386-softmmu \
$(QEMU_XEN_ENABLE_DEBUG) \
--prefix=$(LIBEXEC) \
--libdir=$(LIBEXEC_LIB) \
--includedir=$(LIBEXEC_INC) \
--source-path=$$source \
--extra-cflags="-I$(XEN_ROOT)/tools/include \
-I$(XEN_ROOT)/tools/libxc/include \
-I$(XEN_ROOT)/tools/xenstore/include \
-I$(XEN_ROOT)/tools/xenstore/compat/include \
$(EXTRA_CFLAGS_QEMU_XEN)" \
--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
-L$(XEN_ROOT)/tools/xenstore \
$(QEMU_UPSTREAM_RPATH)" \
--bindir=$(LIBEXEC_BIN) \
--datadir=$(SHAREDIR)/qemu-xen \
--localstatedir=$(localstatedir) \
--disable-kvm \
--disable-docs \
--disable-guest-agent \
--python=$(PYTHON) \
$(CONFIG_QEMUU_EXTRA_ARGS) \
--cpu=$(IOEMU_CPU_ARCH) \
$(IOEMU_CONFIGURE_CROSS); \
$(MAKE) all

As such, this only builds the 32 bit version of qemuu. It seems that
starting a HVM with more than 4Gb of RAM fails:

libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch
w=0xa4d188: deregister unregistered
xc: detail: elf_parse_binary: phdr: paddr=0x10 memsz=0x5b3a4
xc: detail: elf_parse_binary: memory: 0x10 -> 0x15b3a4
xc: detail: VIRTUAL MEMORY ARRANGEMENT:
xc: detail:   Loader:   0010->0015b3a4
xc: detail:   Modules:  ->
xc: detail:   TOTAL:->00017f00
xc: detail:   ENTRY:00100600
xc: detail: PHYSICAL MEMORY ALLOCATION:
xc: detail:   4KB PAGES: 0x0200
xc: detail:   2MB PAGES: 0x05f7
xc: detail:   1GB PAGES: 0x0003
xc: detail: elf_load_binary: phdr 0 at 0x7ff67320f000 -> 0x7ff673260910
xc: error: Could not clear special pages (22 = Invalid argument):
Internal error
libxl: error: libxl_dom.c:1003:libxl__build_hvm: hvm building failed

In building my Xen 4.6.0 packages, I disable qemu-traditional and ONLY
build qemu-upstream - however as the value for i386-softmmu is not based
on variables, I'm not sure this makes a difference.

My question is, should this also build x86_64-softmmu as well as
i386-softmmu at a bare minimum?

-- 
Steven Haigh

Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897



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

Re: [Xen-devel] HVMlite ABI specification DRAFT A

[Andrew Cooper]

On 04/02/2016 22:21, Samuel Thibault wrote:
> Boris Ostrovsky, on Thu 04 Feb 2016 14:18:46 -0500, wrote:
>> On 02/04/2016 02:09 PM, Samuel Thibault wrote:
>>> Roger Pau Monné, on Thu 04 Feb 2016 18:48:14 +0100, wrote:
 struct hvm_start_info {
 #define HVM_START_MAGIC_VALUE 0x336ec578
 uint32_t magic; /* Contains the magic value 0x336ec578 
   */
 /* ("xEn3" with the 0x80 bit of the 
 "E" set).*/
 uint32_t flags; /* SIF_xxx flags.  
   */
 uint32_t cmdline_paddr; /* Physical address of the command 
 line. */
 uint32_t nr_modules;/* Number of modules passed to the 
 kernel.   */
 uint32_t modlist_paddr; /* Physical address of an array of 
   */
 /* hvm_modlist_entry.  
   */
 };
>>> Mmm, don't we also need a description of the initial page table, so that
>>> the guest kernel knows which part of the memory it shouldn't use until
>>> having initialized its own page table?  Or is there none in the guest
>>> physical memory at startup of HVMlite mode?
>> We start with paging off.
> So a 32bit hypervisor *has* to use segmentation to protect itself from
> domU?

This is an HVM domain, so uses hardware virtualisation extensions.  It
is not like a PV guest.

The HVMLite binary is free to choose its width and paging mode.  All
this document states is that the entry point shall be 32bit flat unpaged
mode.

~Andrew

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

[Xen-devel] Memory Sharing

[hanji unit]

Hello, does Xen support sharing memory pages between multiple domains
(such as as Dom0, DomU1, DomU2)? The Grant Table hypercalls seem
limited to:

IOCTL_GNTALLOC_ALLOC_GREF
IOCTL_GNTALLOC_DEALLOC_GREF
IOCTL_GNTALLOC_SET_UNMAP_NOTIFY

Is there any mechanism to not allocate, but only share existing pages?

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

[Xen-devel] [PATCH] x86emul: drop redundant #GP checks

[Jan Beulich]

in_protmode() implies !in_realmode(), so we don't need to check both.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3972,7 +3972,6 @@ x86_emulate(
 uint64_t msr_content;
 struct segment_register cs, ss;
 
-generate_exception_if(in_realmode(ctxt, ops), EXC_UD, -1);
 generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, -1);
 
 /* Inject #UD if syscall/sysret are disabled. */
@@ -4218,7 +4217,6 @@ x86_emulate(
 int lm;
 
 generate_exception_if(mode_ring0(), EXC_GP, 0);
-generate_exception_if(in_realmode(ctxt, ops), EXC_GP, 0);
 generate_exception_if(!in_protmode(ctxt, ops), EXC_GP, 0);
 
 fail_if(ops->read_msr == NULL);
@@ -4267,7 +4265,6 @@ x86_emulate(
 bool_t user64 = !!(rex_prefix & REX_W);
 
 generate_exception_if(!mode_ring0(), EXC_GP, 0);
-generate_exception_if(in_realmode(ctxt, ops), EXC_GP, 0);
 generate_exception_if(!in_protmode(ctxt, ops), EXC_GP, 0);
 
 fail_if(ops->read_msr == NULL);



x86emul: drop redundant #GP checks

in_protmode() implies !in_realmode(), so we don't need to check both.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3972,7 +3972,6 @@ x86_emulate(
 uint64_t msr_content;
 struct segment_register cs, ss;
 
-generate_exception_if(in_realmode(ctxt, ops), EXC_UD, -1);
 generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, -1);
 
 /* Inject #UD if syscall/sysret are disabled. */
@@ -4218,7 +4217,6 @@ x86_emulate(
 int lm;
 
 generate_exception_if(mode_ring0(), EXC_GP, 0);
-generate_exception_if(in_realmode(ctxt, ops), EXC_GP, 0);
 generate_exception_if(!in_protmode(ctxt, ops), EXC_GP, 0);
 
 fail_if(ops->read_msr == NULL);
@@ -4267,7 +4265,6 @@ x86_emulate(
 bool_t user64 = !!(rex_prefix & REX_W);
 
 generate_exception_if(!mode_ring0(), EXC_GP, 0);
-generate_exception_if(in_realmode(ctxt, ops), EXC_GP, 0);
 generate_exception_if(!in_protmode(ctxt, ops), EXC_GP, 0);
 
 fail_if(ops->read_msr == NULL);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 0/3] x86/mm: paging simplifications

[Jan Beulich]

1: mm: drop guest_{map,get_eff}_l1e() hooks
2: mm: make {cmpxchg,write}_guest_entry() hook shadow mode specific
3: shadow: remove a few 32-bit hypervisor leftovers

Signed-off-by: Jan Beulich 


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

[Xen-devel] [PATCH v4 09/17] xen/hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ

[Shannon Zhao]

From: Shannon Zhao 

Add a new delivery type:
val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI.
To the flag, bit 0 stands the interrupt mode is edge(1) or level(0) and
bit 1 stands the interrupt polarity is active low(1) or high(0).

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 include/xen/interface/hvm/params.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/xen/interface/hvm/params.h 
b/include/xen/interface/hvm/params.h
index 70ad208..5dd629f 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -53,6 +53,15 @@
  * if this delivery method is available.
  */
 
+#define HVM_PARAM_CALLBACK_TYPE_EVENT3
+/*
+ * val[15:8] is flag of event-channel interrupt:
+ *  bit 0: interrupt is edge(1) or level(0) triggered
+ *  bit 1: interrupt is active low(1) or high(0)
+ * val[7:0] is PPI number used by event-channel.
+ * This is only used by ARM/ARM64.
+ */
+
 #define HVM_PARAM_STORE_PFN1
 #define HVM_PARAM_STORE_EVTCHN 2
 
-- 
2.0.4



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

[Xen-devel] [PATCH v4 15/17] ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services

[Shannon Zhao]

From: Shannon Zhao 

When running on Xen hypervisor, runtime services are supported through
hypercall. Add a Xen specific function to initialize runtime services.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/arm/include/asm/xen/xen-ops.h   |  6 ++
 arch/arm/xen/Makefile|  1 +
 arch/arm/xen/efi.c   | 40 
 arch/arm64/include/asm/xen/xen-ops.h |  6 ++
 arch/arm64/xen/Makefile  |  1 +
 drivers/xen/Kconfig  |  2 +-
 6 files changed, 55 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/include/asm/xen/xen-ops.h
 create mode 100644 arch/arm/xen/efi.c
 create mode 100644 arch/arm64/include/asm/xen/xen-ops.h

diff --git a/arch/arm/include/asm/xen/xen-ops.h 
b/arch/arm/include/asm/xen/xen-ops.h
new file mode 100644
index 000..ec154e7
--- /dev/null
+++ b/arch/arm/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 1296952..2279521 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1,2 @@
 obj-y  := enlighten.o hypercall.o grant-table.o p2m.o mm.o
+obj-$(CONFIG_XEN_EFI) += efi.o
diff --git a/arch/arm/xen/efi.c b/arch/arm/xen/efi.c
new file mode 100644
index 000..16db419
--- /dev/null
+++ b/arch/arm/xen/efi.c
@@ -0,0 +1,40 @@
+/*
+ * Copyright (c) 2015, Linaro Limited, Shannon Zhao
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+/* Set XEN EFI runtime services function pointers. Other fields of struct efi,
+ * e.g. efi.systab, will be set like normal EFI.
+ */
+void __init xen_efi_runtime_setup(void)
+{
+   efi.get_time = xen_efi_get_time;
+   efi.set_time = xen_efi_set_time;
+   efi.get_wakeup_time  = xen_efi_get_wakeup_time;
+   efi.set_wakeup_time  = xen_efi_set_wakeup_time;
+   efi.get_variable = xen_efi_get_variable;
+   efi.get_next_variable= xen_efi_get_next_variable;
+   efi.set_variable = xen_efi_set_variable;
+   efi.query_variable_info  = xen_efi_query_variable_info;
+   efi.update_capsule   = xen_efi_update_capsule;
+   efi.query_capsule_caps   = xen_efi_query_capsule_caps;
+   efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count;
+   efi.reset_system = NULL; /* Functionality provided by Xen. 
*/
+}
+EXPORT_SYMBOL_GPL(xen_efi_runtime_setup);
diff --git a/arch/arm64/include/asm/xen/xen-ops.h 
b/arch/arm64/include/asm/xen/xen-ops.h
new file mode 100644
index 000..ec154e7
--- /dev/null
+++ b/arch/arm64/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm64/xen/Makefile b/arch/arm64/xen/Makefile
index 74a8d87..8ff8aa9 100644
--- a/arch/arm64/xen/Makefile
+++ b/arch/arm64/xen/Makefile
@@ -1,2 +1,3 @@
 xen-arm-y  += $(addprefix ../../arm/xen/, enlighten.o grant-table.o p2m.o 
mm.o)
 obj-y  := xen-arm.o hypercall.o
+obj-$(CONFIG_XEN_EFI) += $(addprefix ../../arm/xen/, efi.o)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 73708ac..d50571c 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -268,7 +268,7 @@ config XEN_HAVE_PVMMU
 
 config XEN_EFI
def_bool y
-   depends on X86_64 && EFI
+   depends on (ARM || ARM64 || X86_64) && EFI
 
 config XEN_AUTO_XLATE
def_bool y
-- 
2.0.4



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

[Xen-devel] [PATCH v4 08/17] Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen

[Shannon Zhao]

From: Shannon Zhao 

Sync the changes of HVM_PARAM_CALLBACK_VIA ABI introduced by
Xen commit  (public/hvm: export the HVM_PARAM_CALLBACK_VIA
ABI in the API).

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 include/xen/interface/hvm/params.h | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/include/xen/interface/hvm/params.h 
b/include/xen/interface/hvm/params.h
index a6c7991..70ad208 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -27,16 +27,31 @@
  * Parameter space for HVMOP_{set,get}_param.
  */
 
+#define HVM_PARAM_CALLBACK_IRQ 0
 /*
  * How should CPU0 event-channel notifications be delivered?
- * val[63:56] == 0: val[55:0] is a delivery GSI (Global System Interrupt).
- * val[63:56] == 1: val[55:0] is a delivery PCI INTx line, as follows:
- *  Domain = val[47:32], Bus  = val[31:16],
- *  DevFn  = val[15: 8], IntX = val[ 1: 0]
- * val[63:56] == 2: val[7:0] is a vector number.
+ *
  * If val == 0 then CPU0 event-channel notifications are not delivered.
+ * If val != 0, val[63:56] encodes the type, as follows:
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_GSI  0
+/*
+ * val[55:0] is a delivery GSI.  GSI 0 cannot be used, as it aliases val == 0,
+ * and disables all notifications.
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_PCI_INTX 1
+/*
+ * val[55:0] is a delivery PCI INTx line:
+ * Domain = val[47:32], Bus = val[31:16] DevFn = val[15:8], IntX = val[1:0]
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_VECTOR   2
+/*
+ * val[7:0] is a vector number.  Check for XENFEAT_hvm_callback_vector to know
+ * if this delivery method is available.
  */
-#define HVM_PARAM_CALLBACK_IRQ 0
 
 #define HVM_PARAM_STORE_PFN1
 #define HVM_PARAM_STORE_EVTCHN 2
-- 
2.0.4



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

[Xen-devel] [PATCH v4 00/17] Add ACPI support for Xen Dom0 on ARM64

[Shannon Zhao]

From: Shannon Zhao 

This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen
ACPI on ARM64 design document could be found from [1].

This patch set adds a new FDT node "uefi" under /hypervisor to pass UEFI
information. Introduce a bus notifier of AMBA and Platform bus to map
the new added device's MMIO space. Make Xen domain use
xlated_setup_gnttab_pages to setup grant table and a new hypercall to
get event-channel irq.

Regarding the initialization flow of Linux kernel, it needs to move
xen_early_init() before efi_init(). Then xen_early_init() will check
whether it runs on Xen through the /hypervisor node and efi_init() will
call a new function fdt_find_xen_uefi_params(), to parse those
xen,uefi-* parameters just like the existing efi_get_fdt_params().

And in arm64_enable_runtime_services() it will check whether it runs on
Xen and call another new function xen_efi_runtime_setup() to setup
runtime service instead of efi_native_runtime_setup(). The
xen_efi_runtime_setup() will assign the runtime function pointers with
the functions of driver/xen/efi.c.

And since we pass a /hypervisor node and a /chosen node to Dom0, it
needs to check whether the DTS only contains a /hypervisor node and a
/chosen node in acpi_boot_table_init().

Patches are tested on FVP base model. The corresponding Xen patches can
be fetched from [2].

Thanks,
Shannon

[1] http://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html
[2] http://git.linaro.org/people/shannon.zhao/xen.git  ACPI_XEN_ARM_V4

Changes since v3:
* rebase on linux master
* print a warning when there is no SPCR table
* rephase the commit message of PATCH 3
* rephase the words of PATCH 13
* use strcmp and factor the function in PATCH 16
* Add several ACKs and RBs, thanks a lot


Changes since v2:
* Use 0 to check if it should ignore the UART
* Fix the use of page_to_xen_pfn
* Factor ACPI and DT parts in xen_guest_init
* Check "uefi" node by full path
* Fix the statement of Documentation/devicetree/bindings/arm/xen.txt

Changes since v1:
* Rebase on linux mainline and wallclock patch from Stefano
* Refactor AMBA and platform device MMIO map to one file
* Use EFI_PARAVIRT to check if it supports XEN EFI
* Refactor Xen EFI codes
* Address other comments

Shannon Zhao (17):
  Xen: ACPI: Hide UART used by Xen
  xen/grant-table: Move xlated_setup_gnttab_pages to common place
  Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
  arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table
  xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
  Xen: ARM: Add support for mapping platform device mmio
  Xen: ARM: Add support for mapping AMBA device mmio
  Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen
  xen/hvm/params: Add a new delivery type for event-channel in
HVM_PARAM_CALLBACK_IRQ
  arm/xen: Get event-channel irq through HVM_PARAM when booting with
ACPI
  ARM: XEN: Move xen_early_init() before efi_init()
  ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
  ARM: Xen: Document UEFI support on Xen ARM virtual platforms
  XEN: EFI: Move x86 specific codes to architecture directory
  ARM64: XEN: Add a function to initialize Xen specific UEFI runtime
services
  FDT: Add a helper to get specified name subnode
  Xen: EFI: Parse DT parameters for Xen specific UEFI

 Documentation/devicetree/bindings/arm/xen.txt |  33 +
 arch/arm/include/asm/xen/xen-ops.h|   6 +
 arch/arm/xen/Makefile |   1 +
 arch/arm/xen/efi.c|  40 ++
 arch/arm/xen/enlighten.c  | 109 +++
 arch/arm64/include/asm/xen/xen-ops.h  |   6 +
 arch/arm64/kernel/acpi.c  |  12 +-
 arch/arm64/kernel/setup.c |   2 +-
 arch/arm64/xen/Makefile   |   1 +
 arch/x86/xen/efi.c| 112 
 arch/x86/xen/grant-table.c|  57 +---
 drivers/acpi/bus.c|  38 +-
 drivers/firmware/efi/arm-runtime.c|  17 ++-
 drivers/firmware/efi/efi.c|  45 ++-
 drivers/of/fdt.c  |  25 
 drivers/xen/Kconfig   |   2 +-
 drivers/xen/Makefile  |   1 +
 drivers/xen/arm-device.c  | 184 ++
 drivers/xen/efi.c | 174 +---
 drivers/xen/xlate_mmu.c   |  67 ++
 include/linux/of_fdt.h|   2 +
 include/xen/interface/hvm/params.h|  36 -
 include/xen/interface/memory.h|   1 +
 include/xen/xen-ops.h |  32 +++--
 24 files changed, 755 insertions(+), 248 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/xen-ops.h
 create mode 100644 arch/arm/xen/efi.c
 create mode 100644 

[Xen-devel] [PATCH v4 14/17] XEN: EFI: Move x86 specific codes to architecture directory

[Shannon Zhao]

From: Shannon Zhao 

Move x86 specific codes to architecture directory and export those EFI
runtime service functions. This will be useful for initializing runtime
service on ARM later.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/x86/xen/efi.c| 112 
 drivers/xen/efi.c | 174 ++
 include/xen/xen-ops.h |  30 ++---
 3 files changed, 168 insertions(+), 148 deletions(-)

diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index be14cc3..86527f1 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -20,10 +20,122 @@
 #include 
 #include 
 
+#include 
 #include 
+#include 
 
 #include 
 #include 
+#include 
+
+static efi_char16_t vendor[100] __initdata;
+
+static efi_system_table_t efi_systab_xen __initdata = {
+   .hdr = {
+   .signature  = EFI_SYSTEM_TABLE_SIGNATURE,
+   .revision   = 0, /* Initialized later. */
+   .headersize = 0, /* Ignored by Linux Kernel. */
+   .crc32  = 0, /* Ignored by Linux Kernel. */
+   .reserved   = 0
+   },
+   .fw_vendor  = EFI_INVALID_TABLE_ADDR, /* Initialized later. */
+   .fw_revision= 0,  /* Initialized later. */
+   .con_in_handle  = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .con_in = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .con_out_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .con_out= EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .stderr_handle  = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .stderr = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .runtime= (efi_runtime_services_t *)EFI_INVALID_TABLE_ADDR,
+ /* Not used under Xen. */
+   .boottime   = (efi_boot_services_t *)EFI_INVALID_TABLE_ADDR,
+ /* Not used under Xen. */
+   .nr_tables  = 0,  /* Initialized later. */
+   .tables = EFI_INVALID_TABLE_ADDR  /* Initialized later. */
+};
+
+static const struct efi efi_xen __initconst = {
+   .systab   = NULL, /* Initialized later. */
+   .runtime_version  = 0,/* Initialized later. */
+   .mps  = EFI_INVALID_TABLE_ADDR,
+   .acpi = EFI_INVALID_TABLE_ADDR,
+   .acpi20   = EFI_INVALID_TABLE_ADDR,
+   .smbios   = EFI_INVALID_TABLE_ADDR,
+   .smbios3  = EFI_INVALID_TABLE_ADDR,
+   .sal_systab   = EFI_INVALID_TABLE_ADDR,
+   .boot_info= EFI_INVALID_TABLE_ADDR,
+   .hcdp = EFI_INVALID_TABLE_ADDR,
+   .uga  = EFI_INVALID_TABLE_ADDR,
+   .uv_systab= EFI_INVALID_TABLE_ADDR,
+   .fw_vendor= EFI_INVALID_TABLE_ADDR,
+   .runtime  = EFI_INVALID_TABLE_ADDR,
+   .config_table = EFI_INVALID_TABLE_ADDR,
+   .get_time = xen_efi_get_time,
+   .set_time = xen_efi_set_time,
+   .get_wakeup_time  = xen_efi_get_wakeup_time,
+   .set_wakeup_time  = xen_efi_set_wakeup_time,
+   .get_variable = xen_efi_get_variable,
+   .get_next_variable= xen_efi_get_next_variable,
+   .set_variable = xen_efi_set_variable,
+   .query_variable_info  = xen_efi_query_variable_info,
+   .update_capsule   = xen_efi_update_capsule,
+   .query_capsule_caps   = xen_efi_query_capsule_caps,
+   .get_next_high_mono_count = xen_efi_get_next_high_mono_count,
+   .reset_system = NULL, /* Functionality provided by Xen. */
+   .set_virtual_address_map  = NULL, /* Not used under Xen. */
+   .memmap   = NULL, /* Not used under Xen. */
+   .flags= 0 /* Initialized later. */
+};
+
+static efi_system_table_t __init *xen_efi_probe(void)
+{
+   struct xen_platform_op op = {
+   .cmd = XENPF_firmware_info,
+   .u.firmware_info = {
+   .type = XEN_FW_EFI_INFO,
+   .index = XEN_FW_EFI_CONFIG_TABLE
+   }
+   };
+   union xenpf_efi_info *info = _info.u.efi_info;
+
+   if (!xen_initial_domain() || HYPERVISOR_platform_op() < 0)
+   return NULL;
+
+   /* Here we know that Xen runs on EFI platform. */
+
+   efi = efi_xen;
+
+   efi_systab_xen.tables = info->cfg.addr;
+   efi_systab_xen.nr_tables = info->cfg.nent;
+
+   op.cmd = XENPF_firmware_info;
+   op.u.firmware_info.type = XEN_FW_EFI_INFO;
+   

[Xen-devel] [PATCH v4 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI

[Shannon Zhao]

From: Shannon Zhao 

When it's a Xen domain0 booting with ACPI, it will supply a /chosen and
a /hypervisor node in DT. So check if it needs to enable ACPI.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
Acked-by: Hanjun Guo 
---
CC: Hanjun Guo 
---
 arch/arm64/kernel/acpi.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index d1ce8e2..4e92be0 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -67,10 +67,13 @@ static int __init dt_scan_depth1_nodes(unsigned long node,
 {
/*
 * Return 1 as soon as we encounter a node at depth 1 that is
-* not the /chosen node.
+* not the /chosen node, or /hypervisor node when running on Xen.
 */
-   if (depth == 1 && (strcmp(uname, "chosen") != 0))
-   return 1;
+   if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
+   if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
+   return 1;
+   }
+
return 0;
 }
 
@@ -184,7 +187,8 @@ void __init acpi_boot_table_init(void)
/*
 * Enable ACPI instead of device tree unless
 * - ACPI has been disabled explicitly (acpi=off), or
-* - the device tree is not empty (it has more than just a /chosen node)
+* - the device tree is not empty (it has more than just a /chosen node,
+*   and a /hypervisor node when running on Xen)
 *   and ACPI has not been force enabled (acpi=force)
 */
if (param_acpi_off ||
-- 
2.0.4



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

[Xen-devel] [PATCH v4 02/17] xen/grant-table: Move xlated_setup_gnttab_pages to common place

[Shannon Zhao]

From: Shannon Zhao 

Move xlated_setup_gnttab_pages to common place, so it can be reused by
ARM to setup grant table.

Rename it to xen_xlate_map_ballooned_pages.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/x86/xen/grant-table.c | 57 +--
 drivers/xen/xlate_mmu.c| 61 ++
 include/xen/xen-ops.h  |  2 ++
 3 files changed, 69 insertions(+), 51 deletions(-)

diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index e079500..de4144c 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -111,63 +111,18 @@ int arch_gnttab_init(unsigned long nr_shared)
 }
 
 #ifdef CONFIG_XEN_PVH
-#include 
 #include 
-#include 
-static int __init xlated_setup_gnttab_pages(void)
-{
-   struct page **pages;
-   xen_pfn_t *pfns;
-   void *vaddr;
-   int rc;
-   unsigned int i;
-   unsigned long nr_grant_frames = gnttab_max_grant_frames();
-
-   BUG_ON(nr_grant_frames == 0);
-   pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
-   if (!pages)
-   return -ENOMEM;
-
-   pfns = kcalloc(nr_grant_frames, sizeof(pfns[0]), GFP_KERNEL);
-   if (!pfns) {
-   kfree(pages);
-   return -ENOMEM;
-   }
-   rc = alloc_xenballooned_pages(nr_grant_frames, pages);
-   if (rc) {
-   pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
-   kfree(pages);
-   kfree(pfns);
-   return rc;
-   }
-   for (i = 0; i < nr_grant_frames; i++)
-   pfns[i] = page_to_pfn(pages[i]);
-
-   vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
-   if (!vaddr) {
-   pr_warn("%s Couldn't map %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
-   free_xenballooned_pages(nr_grant_frames, pages);
-   kfree(pages);
-   kfree(pfns);
-   return -ENOMEM;
-   }
-   kfree(pages);
-
-   xen_auto_xlat_grant_frames.pfn = pfns;
-   xen_auto_xlat_grant_frames.count = nr_grant_frames;
-   xen_auto_xlat_grant_frames.vaddr = vaddr;
-
-   return 0;
-}
-
+#include 
 static int __init xen_pvh_gnttab_setup(void)
 {
if (!xen_pvh_domain())
return -ENODEV;
 
-   return xlated_setup_gnttab_pages();
+   xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
+
+   return xen_xlate_map_ballooned_pages(_auto_xlat_grant_frames.pfn,
+_auto_xlat_grant_frames.vaddr,
+xen_auto_xlat_grant_frames.count);
 }
 /* Call it _before_ __gnttab_init as we need to initialize the
  * xen_auto_xlat_grant_frames first. */
diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 5063c5e..9692656 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -29,6 +29,8 @@
  */
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -37,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 typedef void (*xen_gfn_fn_t)(unsigned long gfn, void *data);
 
@@ -185,3 +188,61 @@ int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
return 0;
 }
 EXPORT_SYMBOL_GPL(xen_xlate_unmap_gfn_range);
+
+/**
+ * xen_xlate_map_ballooned_pages - map a new set of ballooned pages
+ * @gfns: returns the array of corresponding GFNs
+ * @virt: returns the virtual address of the mapped region
+ * @nr_grant_frames: number of GFNs
+ * @return 0 on success, error otherwise
+ *
+ * This allocates a set of ballooned pages and maps them into the
+ * kernel's address space.
+ */
+int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
+unsigned long nr_grant_frames)
+{
+   struct page **pages;
+   xen_pfn_t *pfns;
+   void *vaddr;
+   int rc;
+   unsigned int i;
+
+   BUG_ON(nr_grant_frames == 0);
+   pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
+   if (!pages)
+   return -ENOMEM;
+
+   pfns = kcalloc(nr_grant_frames, sizeof(pfns[0]), GFP_KERNEL);
+   if (!pfns) {
+   kfree(pages);
+   return -ENOMEM;
+   }
+   rc = alloc_xenballooned_pages(nr_grant_frames, pages);
+   if (rc) {
+   pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
+   nr_grant_frames, rc);
+   kfree(pages);
+   kfree(pfns);
+   return rc;
+   }
+   for (i = 0; i < nr_grant_frames; i++)
+   pfns[i] = page_to_pfn(pages[i]);
+
+   vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
+   if (!vaddr) {
+   pr_warn("%s Couldn't map %ld pfns rc:%d\n", 

[Xen-devel] [PATCH v4 05/17] xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio

[Shannon Zhao]

From: Shannon Zhao 

Add a new type of Xen map space for Dom0 to map device's MMIO region.

Signed-off-by: Shannon Zhao 
---
 include/xen/interface/memory.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index 2ecfe4f..9aa8988 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -160,6 +160,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
 #define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
* XENMEM_add_to_physmap_range only.
*/
+#define XENMAPSPACE_dev_mmio 5 /* device mmio region */
 
 /*
  * Sets the GPFN at which a particular page appears in the specified guest's
-- 
2.0.4



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

[Xen-devel] [PATCH v4 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn

[Shannon Zhao]

From: Shannon Zhao 

Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
refer to 4K pages.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 drivers/xen/xlate_mmu.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 9692656..28f728b 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -207,9 +207,12 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, 
void **virt,
void *vaddr;
int rc;
unsigned int i;
+   unsigned long nr_pages;
+   xen_pfn_t xen_pfn = 0;
 
BUG_ON(nr_grant_frames == 0);
-   pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
+   nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
+   pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
if (!pages)
return -ENOMEM;
 
@@ -218,22 +221,25 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t 
**gfns, void **virt,
kfree(pages);
return -ENOMEM;
}
-   rc = alloc_xenballooned_pages(nr_grant_frames, pages);
+   rc = alloc_xenballooned_pages(nr_pages, pages);
if (rc) {
-   pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
+   pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
+   nr_pages, rc);
kfree(pages);
kfree(pfns);
return rc;
}
-   for (i = 0; i < nr_grant_frames; i++)
-   pfns[i] = page_to_pfn(pages[i]);
+   for (i = 0; i < nr_grant_frames; i++) {
+   if ((i % XEN_PFN_PER_PAGE) == 0)
+   xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
+   pfns[i] = pfn_to_gfn(xen_pfn++);
+   }
 
-   vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
+   vaddr = vmap(pages, nr_pages, 0, PAGE_KERNEL);
if (!vaddr) {
-   pr_warn("%s Couldn't map %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
-   free_xenballooned_pages(nr_grant_frames, pages);
+   pr_warn("%s Couldn't map %ld pages rc:%d\n", __func__,
+   nr_pages, rc);
+   free_xenballooned_pages(nr_pages, pages);
kfree(pages);
kfree(pfns);
return -ENOMEM;
-- 
2.0.4



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

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

[osstest service owner]

flight 80469 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/80469/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3865 xen-build fail REGR. vs. 79947
 build-amd64   5 xen-build fail REGR. vs. 79947
 build-i386-xsm5 xen-build fail REGR. vs. 79947
 build-amd64-xsm   5 xen-build fail REGR. vs. 79947
 build-armhf   5 xen-build fail REGR. vs. 79947
 build-armhf-xsm   5 xen-build fail REGR. vs. 79947

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 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-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel  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-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  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-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 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-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  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-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 

[Xen-devel] [PATCH] x86/nHVM: avoid NULL deref during INVLPG intercept handling

[Jan Beulich]

When intercepting (or emulating) L1 guest INVLPG, the nested P2M
pointer may be (is?) NULL, and hence there's no point in calling
p2m_flush(). In fact doing so would cause a dereference of that NULL
pointer at least in the ASSERT() right at the beginning of the
function.

While so far nothing supports hap_invlpg() being reachable from the
INVLPG intercept paths (only INVLPG insn emulation would lead there),
and hence the code in question (added by dd6de3ab99 ["Implement
Nested-on-Nested"]) appears to be dead, this seems to be the change
which can be agreed on as an immediate fix. Ideally, however, the
problematic code would go away altogether. See thread at
lists.xenproject.org/archives/html/xen-devel/2016-01/msg03762.html.

Reported-by: 刘令 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -687,7 +687,8 @@ static bool_t hap_invlpg(struct vcpu *v,
  * Must perform the flush right now or an other vcpu may
  * use it when we use the next VMRUN emulation, otherwise.
  */
-p2m_flush(v, vcpu_nestedhvm(v).nv_p2m);
+if ( vcpu_nestedhvm(v).nv_p2m )
+p2m_flush(v, vcpu_nestedhvm(v).nv_p2m);
 return 1;
 }



x86/nHVM: avoid NULL deref during INVLPG intercept handling

When intercepting (or emulating) L1 guest INVLPG, the nested P2M
pointer may be (is?) NULL, and hence there's no point in calling
p2m_flush(). In fact doing so would cause a dereference of that NULL
pointer at least in the ASSERT() right at the beginning of the
function.

While so far nothing supports hap_invlpg() being reachable from the
INVLPG intercept paths (only INVLPG insn emulation would lead there),
and hence the code in question (added by dd6de3ab99 ["Implement
Nested-on-Nested"]) appears to be dead, this seems to be the change
which can be agreed on as an immediate fix. Ideally, however, the
problematic code would go away altogether. See thread at
lists.xenproject.org/archives/html/xen-devel/2016-01/msg03762.html.
   
Reported-by: 刘令 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -687,7 +687,8 @@ static bool_t hap_invlpg(struct vcpu *v,
  * Must perform the flush right now or an other vcpu may
  * use it when we use the next VMRUN emulation, otherwise.
  */
-p2m_flush(v, vcpu_nestedhvm(v).nv_p2m);
+if ( vcpu_nestedhvm(v).nv_p2m )
+p2m_flush(v, vcpu_nestedhvm(v).nv_p2m);
 return 1;
 }
 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary?

[Andrew Cooper]

On 04/02/2016 23:44, Alex Braunegg wrote:
> Hi Andrew,
>
> I don't know enough on the internals of xen / qemu here - however, based on
> what you said, an x86_64 OS with >4Gb memory should boot via xl - however in
> my case here it fails to start up:
>
> -
>
> [root@mynas-s5000xvn ~]# xl - create /etc/xen/config/Windows_2008_R2.cfg
>
> Parsing config from /etc/xen/config/Windows_2008_R2.cfg
> libxl: debug: libxl_create.c:1560:do_domain_create: ao 0x735690: create:
> how=(nil) callback=(nil) poller=0x734b70
> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk
> vdev=hda spec.backend=unknown
> libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk
> vdev=hda, using backend phy
> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk
> vdev=hdc spec.backend=unknown
> libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk
> vdev=hdc, using backend phy
> libxl: debug: libxl_create.c:945:initiate_domain_create: running bootloader
> libxl: debug: libxl_bootloader.c:324:libxl__bootloader_run: not a PV domain,
> skipping bootloader
> libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch
> w=0x736078: deregister unregistered
> xc: detail: elf_parse_binary: phdr: paddr=0x10 memsz=0x5b3a4
> xc: detail: elf_parse_binary: memory: 0x10 -> 0x15b3a4
> xc: detail: VIRTUAL MEMORY ARRANGEMENT:
> xc: detail:   Loader:   0010->0015b3a4
> xc: detail:   Modules:  ->
> xc: detail:   TOTAL:->00017f00
> xc: detail:   ENTRY:00100600
> xc: detail: PHYSICAL MEMORY ALLOCATION:
> xc: detail:   4KB PAGES: 0x0200
> xc: detail:   2MB PAGES: 0x05f7
> xc: detail:   1GB PAGES: 0x0003
> xc: detail: elf_load_binary: phdr 0 at 0x7efc906d7000 -> 0x7efc90728910
> xc: error: Could not clear special pages (22 = Invalid argument): Internal
> error
> libxl: error: libxl_dom.c:1003:libxl__build_hvm: hvm building failed

The problem is here, but it isn't immediately apparent why (other than
"failed to map special pages").

> Guest Config:
> =
>
> -
>
> builder='hvm'
> memory = 6144
> shadow_memory = 8

These values look suspicious to me.  What hardware is this running on?
Either you are on more modern hardware and shouldn't touch
shadow_memory, or you are on rather older hardware, at which point 8M of
shadow memory is probably too small for a 6G VM.

~Andrew

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

[Xen-devel] [PATCH v4 04/17] arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table

[Shannon Zhao]

From: Shannon Zhao 

Use xen_xlate_map_ballooned_pages to setup grant table. Then it doesn't
rely on DT or ACPI to pass the start address and size of grant table.

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..d94f726 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -282,18 +282,10 @@ static int __init xen_guest_init(void)
 {
struct xen_add_to_physmap xatp;
struct shared_info *shared_info_page = NULL;
-   struct resource res;
-   phys_addr_t grant_frames;
 
if (!xen_domain())
return 0;
 
-   if (of_address_to_resource(xen_node, GRANT_TABLE_PHYSADDR, )) {
-   pr_err("Xen grant table base address not found\n");
-   return -ENODEV;
-   }
-   grant_frames = res.start;
-
xen_events_irq = irq_of_parse_and_map(xen_node, 0);
if (!xen_events_irq) {
pr_err("Xen event channel interrupt not found\n");
@@ -328,7 +320,10 @@ static int __init xen_guest_init(void)
if (xen_vcpu_info == NULL)
return -ENOMEM;
 
-   if (gnttab_setup_auto_xlat_frames(grant_frames)) {
+   xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
+   if (xen_xlate_map_ballooned_pages(_auto_xlat_grant_frames.pfn,
+ _auto_xlat_grant_frames.vaddr,
+ xen_auto_xlat_grant_frames.count)) {
free_percpu(xen_vcpu_info);
return -ENOMEM;
}
-- 
2.0.4



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

[Xen-devel] [PATCH v4 10/17] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI

[Shannon Zhao]

From: Shannon Zhao 

When booting with ACPI, it could get the event-channel irq through
HVM_PARAM_CALLBACK_IRQ.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index d94f726..807a93e 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -278,6 +279,35 @@ void __init xen_early_init(void)
add_preferred_console("hvc", 0, NULL);
 }
 
+static void __init xen_acpi_guest_init(void)
+{
+#ifdef CONFIG_ACPI
+   struct xen_hvm_param a;
+   int interrupt, trigger, polarity;
+
+   a.domid = DOMID_SELF;
+   a.index = HVM_PARAM_CALLBACK_IRQ;
+   xen_events_irq = 0;
+
+   if (!HYPERVISOR_hvm_op(HVMOP_get_param, )) {
+   if ((a.value >> 56) == HVM_PARAM_CALLBACK_TYPE_EVENT) {
+   interrupt = a.value & 0xff;
+   trigger = ((a.value >> 8) & 0x1) ? ACPI_EDGE_SENSITIVE
+: ACPI_LEVEL_SENSITIVE;
+   polarity = ((a.value >> 8) & 0x2) ? ACPI_ACTIVE_LOW
+ : ACPI_ACTIVE_HIGH;
+   xen_events_irq = acpi_register_gsi(NULL, interrupt,
+  trigger, polarity);
+   }
+   }
+#endif
+}
+
+static void __init xen_dt_guest_init(void)
+{
+   xen_events_irq = irq_of_parse_and_map(xen_node, 0);
+}
+
 static int __init xen_guest_init(void)
 {
struct xen_add_to_physmap xatp;
@@ -286,7 +316,11 @@ static int __init xen_guest_init(void)
if (!xen_domain())
return 0;
 
-   xen_events_irq = irq_of_parse_and_map(xen_node, 0);
+   if (!acpi_disabled)
+   xen_acpi_guest_init();
+   else
+   xen_dt_guest_init();
+
if (!xen_events_irq) {
pr_err("Xen event channel interrupt not found\n");
return -ENODEV;
-- 
2.0.4



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

[Xen-devel] [PATCH v4 06/17] Xen: ARM: Add support for mapping platform device mmio

[Shannon Zhao]

From: Shannon Zhao 

Add a bus_notifier for platform bus device in order to map the device
mmio regions when DOM0 booting with ACPI.

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 drivers/xen/Makefile |   1 +
 drivers/xen/arm-device.c | 141 +++
 2 files changed, 142 insertions(+)
 create mode 100644 drivers/xen/arm-device.c

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 9b7a35c..415f286 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -9,6 +9,7 @@ CFLAGS_features.o   := $(nostackp)
 
 CFLAGS_efi.o   += -fshort-wchar
 
+dom0-$(CONFIG_ARM64) += arm-device.o
 dom0-$(CONFIG_PCI) += pci.o
 dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
 dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
new file mode 100644
index 000..76e26e5
--- /dev/null
+++ b/drivers/xen/arm-device.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright (c) 2015, Linaro Limited, Shannon Zhao
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int xen_unmap_device_mmio(struct resource *resource, unsigned int count)
+{
+   unsigned int i, j, nr;
+   int rc = 0;
+   struct resource *r;
+   struct xen_remove_from_physmap xrp;
+
+   for (i = 0; i < count; i++) {
+   r = [i];
+   nr = DIV_ROUND_UP(resource_size(r), XEN_PAGE_SIZE);
+   if ((resource_type(r) != IORESOURCE_MEM) || (nr == 0))
+   continue;
+
+   for (j = 0; j < nr; j++) {
+   xrp.domid = DOMID_SELF;
+   xrp.gpfn = XEN_PFN_DOWN(r->start) + j;
+   rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap,
+ );
+   if (rc)
+   return rc;
+   }
+   }
+
+   return rc;
+}
+
+static int xen_map_device_mmio(struct resource *resource, unsigned int count)
+{
+   unsigned int i, j, nr;
+   int rc = 0;
+   struct resource *r;
+   xen_pfn_t *gpfns;
+   xen_ulong_t *idxs;
+   int *errs;
+   struct xen_add_to_physmap_range xatp;
+
+   for (i = 0; i < count; i++) {
+   r = [i];
+   nr = DIV_ROUND_UP(resource_size(r), XEN_PAGE_SIZE);
+   if ((resource_type(r) != IORESOURCE_MEM) || (nr == 0))
+   continue;
+
+   gpfns = kzalloc(sizeof(xen_pfn_t) * nr, GFP_KERNEL);
+   idxs = kzalloc(sizeof(xen_ulong_t) * nr, GFP_KERNEL);
+   errs = kzalloc(sizeof(int) * nr, GFP_KERNEL);
+   if (!gpfns || !idxs || !errs) {
+   kfree(gpfns);
+   kfree(idxs);
+   kfree(errs);
+   return -ENOMEM;
+   }
+
+   for (j = 0; j < nr; j++) {
+   gpfns[j] = XEN_PFN_DOWN(r->start) + j;
+   idxs[j] = XEN_PFN_DOWN(r->start) + j;
+   }
+
+   xatp.domid = DOMID_SELF;
+   xatp.size = nr;
+   xatp.space = XENMAPSPACE_dev_mmio;
+
+   set_xen_guest_handle(xatp.gpfns, gpfns);
+   set_xen_guest_handle(xatp.idxs, idxs);
+   set_xen_guest_handle(xatp.errs, errs);
+
+   rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, );
+   kfree(gpfns);
+   kfree(idxs);
+   kfree(errs);
+   if (rc)
+   return rc;
+   }
+
+   return rc;
+}
+
+static int xen_platform_notifier(struct notifier_block *nb,
+unsigned long action, void *data)
+{
+   struct platform_device *pdev = to_platform_device(data);
+   int r = 0;
+
+   if (pdev->num_resources == 0 || pdev->resource == NULL)
+   return NOTIFY_OK;
+
+   switch (action) {
+   case BUS_NOTIFY_ADD_DEVICE:
+   r = xen_map_device_mmio(pdev->resource, pdev->num_resources);
+   break;
+   case BUS_NOTIFY_DEL_DEVICE:
+   r = xen_unmap_device_mmio(pdev->resource, pdev->num_resources);
+   break;
+   

[Xen-devel] [PATCH v4 07/17] Xen: ARM: Add support for mapping AMBA device mmio

[Shannon Zhao]

From: Shannon Zhao 

Add a bus_notifier for AMBA bus device in order to map the device
mmio regions when DOM0 booting with ACPI.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 drivers/xen/arm-device.c | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
index 76e26e5..3854043 100644
--- a/drivers/xen/arm-device.c
+++ b/drivers/xen/arm-device.c
@@ -139,3 +139,46 @@ static int __init register_xen_platform_notifier(void)
 }
 
 arch_initcall(register_xen_platform_notifier);
+
+#ifdef CONFIG_ARM_AMBA
+#include 
+
+static int xen_amba_notifier(struct notifier_block *nb,
+unsigned long action, void *data)
+{
+   struct amba_device *adev = to_amba_device(data);
+   int r = 0;
+
+   switch (action) {
+   case BUS_NOTIFY_ADD_DEVICE:
+   r = xen_map_device_mmio(>res, 1);
+   break;
+   case BUS_NOTIFY_DEL_DEVICE:
+   r = xen_unmap_device_mmio(>res, 1);
+   break;
+   default:
+   return NOTIFY_DONE;
+   }
+   if (r)
+   dev_err(>dev, "AMBA: Failed to %s device %s MMIO!\n",
+   action == BUS_NOTIFY_ADD_DEVICE ? "map" :
+   (action == BUS_NOTIFY_DEL_DEVICE ? "unmap" : "?"),
+   adev->dev.init_name);
+
+   return NOTIFY_OK;
+}
+
+static struct notifier_block amba_device_nb = {
+   .notifier_call = xen_amba_notifier,
+};
+
+static int __init register_xen_amba_notifier(void)
+{
+   if (!xen_initial_domain() || acpi_disabled)
+   return 0;
+
+   return bus_register_notifier(_bustype, _device_nb);
+}
+
+arch_initcall(register_xen_amba_notifier);
+#endif
-- 
2.0.4



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

[Xen-devel] [PATCH v4 17/17] Xen: EFI: Parse DT parameters for Xen specific UEFI

[Shannon Zhao]

From: Shannon Zhao 

Add a new function to parse DT parameters for Xen specific UEFI just
like the way for normal UEFI. Then it could reuse the existing codes.

If Xen supports EFI, initialize runtime services.

Signed-off-by: Shannon Zhao 
Reviewed-by: Matt Fleming 
Reviewed-by: Stefano Stabellini 
---
CC: Matt Fleming 
---
 arch/arm/xen/enlighten.c   |  6 +
 drivers/firmware/efi/arm-runtime.c | 17 +-
 drivers/firmware/efi/efi.c | 45 --
 3 files changed, 56 insertions(+), 12 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 0e542b8..026b5a7 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -261,6 +261,12 @@ static int __init fdt_find_hyper_node(unsigned long node, 
const char *uname,
!strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
hyper_node.version = s + strlen(hyper_node.prefix);
 
+   if (IS_ENABLED(CONFIG_XEN_EFI)) {
+   /* Check if Xen supports EFI */
+   if (of_get_flat_dt_subnode_by_name(node, "uefi") > 0)
+   set_bit(EFI_PARAVIRT, );
+   }
+
return 0;
 }
 
diff --git a/drivers/firmware/efi/arm-runtime.c 
b/drivers/firmware/efi/arm-runtime.c
index 6ae21e4..ac609b9 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 extern u64 efi_system_table;
 
@@ -107,13 +108,19 @@ static int __init arm_enable_runtime_services(void)
}
set_bit(EFI_SYSTEM_TABLES, );
 
-   if (!efi_virtmap_init()) {
-   pr_err("No UEFI virtual mapping was installed -- runtime 
services will not be available\n");
-   return -ENOMEM;
+   if (IS_ENABLED(CONFIG_XEN_EFI) && efi_enabled(EFI_PARAVIRT)) {
+   /* Set up runtime services function pointers for Xen Dom0 */
+   xen_efi_runtime_setup();
+   } else {
+   if (!efi_virtmap_init()) {
+   pr_err("No UEFI virtual mapping was installed -- 
runtime services will not be available\n");
+   return -ENOMEM;
+   }
+
+   /* Set up runtime services function pointers */
+   efi_native_runtime_setup();
}
 
-   /* Set up runtime services function pointers */
-   efi_native_runtime_setup();
set_bit(EFI_RUNTIME_SERVICES, );
 
efi.runtime_version = efi.systab->hdr.revision;
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2cd37da..1328cb7 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -500,12 +500,14 @@ device_initcall(efi_load_efivars);
FIELD_SIZEOF(struct efi_fdt_params, field) \
}
 
-static __initdata struct {
+struct params {
const char name[32];
const char propname[32];
int offset;
int size;
-} dt_params[] = {
+};
+
+static struct params fdt_params[] __initdata = {
UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
@@ -513,24 +515,45 @@ static __initdata struct {
UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
 };
 
+static struct params xen_fdt_params[] __initdata = {
+   UEFI_PARAM("System Table", "xen,uefi-system-table", system_table),
+   UEFI_PARAM("MemMap Address", "xen,uefi-mmap-start", mmap),
+   UEFI_PARAM("MemMap Size", "xen,uefi-mmap-size", mmap_size),
+   UEFI_PARAM("MemMap Desc. Size", "xen,uefi-mmap-desc-size", desc_size),
+   UEFI_PARAM("MemMap Desc. Version", "xen,uefi-mmap-desc-ver", desc_ver)
+};
+
 struct param_info {
int found;
void *params;
+   struct params *dt_params;
+   int size;
 };
 
 static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
   int depth, void *data)
 {
struct param_info *info = data;
+   struct params *dt_params = info->dt_params;
const void *prop;
void *dest;
u64 val;
-   int i, len;
+   int i, len, offset;
 
-   if (depth != 1 || strcmp(uname, "chosen") != 0)
-   return 0;
+   if (efi_enabled(EFI_PARAVIRT)) {
+   if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+   return 0;
 
-   for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
+   offset = of_get_flat_dt_subnode_by_name(node, "uefi");
+   if (offset < 0)
+   return 0;
+   node = offset;
+   } else {
+   if (depth != 1 || strcmp(uname, "chosen") != 0)
+   return 

[Xen-devel] [PATCH v4 11/17] ARM: XEN: Move xen_early_init() before efi_init()

[Shannon Zhao]

From: Shannon Zhao 

Move xen_early_init() before efi_init(), then when calling efi_init()
could initialize Xen specific UEFI.

Check if it runs on Xen hypervisor through the flat dts.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c  | 56 ++-
 arch/arm64/kernel/setup.c |  2 +-
 2 files changed, 42 insertions(+), 16 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 807a93e..0e542b8 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -53,8 +54,6 @@ struct xen_memory_region 
xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
 
 static __read_mostly unsigned int xen_events_irq;
 
-static __initdata struct device_node *xen_node;
-
 int xen_remap_domain_gfn_array(struct vm_area_struct *vma,
   unsigned long addr,
   xen_pfn_t *gfn, int nr,
@@ -238,6 +237,33 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
return IRQ_HANDLED;
 }
 
+static __initdata struct {
+   const char *compat;
+   const char *prefix;
+   const char *version;
+   bool found;
+} hyper_node = {"xen,xen", "xen,xen-", NULL, false};
+
+static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+   const void *s = NULL;
+   int len;
+
+   if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+   return 0;
+
+   if (of_flat_dt_is_compatible(node, hyper_node.compat))
+   hyper_node.found = true;
+
+   s = of_get_flat_dt_prop(node, "compatible", );
+   if (strlen(hyper_node.prefix) + 3  < len &&
+   !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
+   hyper_node.version = s + strlen(hyper_node.prefix);
+
+   return 0;
+}
+
 /*
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
@@ -245,26 +271,18 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
 #define GRANT_TABLE_PHYSADDR 0
 void __init xen_early_init(void)
 {
-   int len;
-   const char *s = NULL;
-   const char *version = NULL;
-   const char *xen_prefix = "xen,xen-";
-
-   xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
-   if (!xen_node) {
+   of_scan_flat_dt(fdt_find_hyper_node, NULL);
+   if (!hyper_node.found) {
pr_debug("No Xen support\n");
return;
}
-   s = of_get_property(xen_node, "compatible", );
-   if (strlen(xen_prefix) + 3  < len &&
-   !strncmp(xen_prefix, s, strlen(xen_prefix)))
-   version = s + strlen(xen_prefix);
-   if (version == NULL) {
+
+   if (hyper_node.version == NULL) {
pr_debug("Xen version not found\n");
return;
}
 
-   pr_info("Xen %s support found\n", version);
+   pr_info("Xen %s support found\n", hyper_node.version);
 
xen_domain_type = XEN_HVM_DOMAIN;
 
@@ -305,6 +323,14 @@ static void __init xen_acpi_guest_init(void)
 
 static void __init xen_dt_guest_init(void)
 {
+   struct device_node *xen_node;
+
+   xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
+   if (!xen_node) {
+   pr_err("Xen support was detected before, but it has 
disappeared\n");
+   return;
+   }
+
xen_events_irq = irq_of_parse_and_map(xen_node, 0);
 }
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 8119479..a4a2878 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
 */
local_async_enable();
 
+   xen_early_init();
efi_init();
arm64_memblock_init();
 
@@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
} else {
psci_acpi_init();
}
-   xen_early_init();
 
cpu_read_bootcpu_ops();
smp_init_cpus();
-- 
2.0.4



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

[Xen-devel] [PATCH v4 13/17] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

[Shannon Zhao]

From: Shannon Zhao 

Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
scan this to get the UEFI information.

Signed-off-by: Shannon Zhao 
Acked-by: Rob Herring 
---
CC: Rob Herring 
---
 Documentation/devicetree/bindings/arm/xen.txt | 33 +++
 1 file changed, 33 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/xen.txt 
b/Documentation/devicetree/bindings/arm/xen.txt
index 0f7b9c2..6f83f76 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -15,6 +15,26 @@ the following properties:
 - interrupts: the interrupt used by Xen to inject event notifications.
   A GIC node is also required.
 
+To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
+under /hypervisor with following parameters:
+
+
+Name  | Size   | Description
+
+xen,uefi-system-table | 64-bit | Guest physical address of the UEFI System
+ || Table.
+
+xen,uefi-mmap-start   | 64-bit | Guest physical address of the UEFI memory
+ || map.
+
+xen,uefi-mmap-size| 32-bit | Size in bytes of the UEFI memory map
+  || pointed to in previous entry.
+
+xen,uefi-mmap-desc-size   | 32-bit | Size in bytes of each entry in the UEFI
+  || memory map.
+
+xen,uefi-mmap-desc-ver| 32-bit | Version of the mmap descriptor format.
+
 
 Example (assuming #address-cells = <2> and #size-cells = <2>):
 
@@ -22,4 +42,17 @@ hypervisor {
compatible = "xen,xen-4.3", "xen,xen";
reg = <0 0xb000 0 0x2>;
interrupts = <1 15 0xf08>;
+   uefi {
+   xen,uefi-system-table = <0x>;
+   xen,uefi-mmap-start = <0x>;
+   xen,uefi-mmap-size = <0x>;
+   xen,uefi-mmap-desc-size = <0x>;
+   xen,uefi-mmap-desc-ver = <0x>;
+};
 };
+
+The format and meaning of the "xen,uefi-*" parameters are similar to those in
+Documentation/arm/uefi.txt, which are provided by the regular UEFI stub. 
However
+they differ because they are provided by the Xen hypervisor, together with a 
set
+of UEFI runtime services implemented via hypercalls, see
+http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.
-- 
2.0.4



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

[Xen-devel] [PATCH v4 01/17] Xen: ACPI: Hide UART used by Xen

[Shannon Zhao]

From: Shannon Zhao 

ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
CC: "Rafael J. Wysocki"  (supporter:ACPI)
CC: Len Brown  (supporter:ACPI)
CC: linux-a...@vger.kernel.org (open list:ACPI)
---
 drivers/acpi/bus.c | 38 +-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 891c42d..5b5433d 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -46,6 +46,7 @@ ACPI_MODULE_NAME("bus");
 struct acpi_device *acpi_root;
 struct proc_dir_entry *acpi_root_dir;
 EXPORT_SYMBOL(acpi_root_dir);
+static u64 spcr_uart_addr;
 
 #ifdef CONFIG_X86
 #ifdef CONFIG_ACPI_CUSTOM_DSDT
@@ -105,6 +106,22 @@ acpi_status acpi_bus_get_status_handle(acpi_handle handle,
return status;
 }
 
+static bool acpi_check_device_is_ignored(acpi_handle handle)
+{
+   acpi_status status;
+   u64 addr;
+
+   /* Check if it should ignore the UART device */
+   if (spcr_uart_addr != 0) {
+   status = acpi_evaluate_integer(handle, METHOD_NAME__ADR, NULL,
+  );
+   if (ACPI_SUCCESS(status) && addr == spcr_uart_addr)
+   return true;
+   }
+
+   return false;
+}
+
 int acpi_bus_get_status(struct acpi_device *device)
 {
acpi_status status;
@@ -114,7 +131,8 @@ int acpi_bus_get_status(struct acpi_device *device)
if (ACPI_FAILURE(status))
return -ENODEV;
 
-   acpi_set_device_status(device, sta);
+   if (!acpi_check_device_is_ignored(device->handle))
+   acpi_set_device_status(device, sta);
 
if (device->status.functional && !device->status.present) {
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device [%s] status [%08x]: "
@@ -1070,6 +1088,8 @@ EXPORT_SYMBOL_GPL(acpi_kobj);
 static int __init acpi_init(void)
 {
int result;
+   acpi_status status;
+   struct acpi_table_stao *stao_ptr;
 
if (acpi_disabled) {
printk(KERN_INFO PREFIX "Interpreter disabled.\n");
@@ -1082,6 +1102,22 @@ static int __init acpi_init(void)
acpi_kobj = NULL;
}
 
+   /* If there is STAO table, check whether it needs to ignore the UART
+* device in SPCR table.
+*/
+   status = acpi_get_table(ACPI_SIG_STAO, 0,
+   (struct acpi_table_header **)_ptr);
+   if (ACPI_SUCCESS(status) && stao_ptr->ignore_uart) {
+   struct acpi_table_spcr *spcr_ptr;
+
+   status = acpi_get_table(ACPI_SIG_SPCR, 0,
+   (struct acpi_table_header **)_ptr);
+   if (ACPI_SUCCESS(status))
+   spcr_uart_addr = spcr_ptr->serial_port.address;
+   else
+   printk(KERN_WARNING "STAO table present, but SPCR is 
missing.\n");
+   }
+
init_acpi_device_notify();
result = acpi_bus_init();
if (result) {
-- 
2.0.4



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

[Xen-devel] [PATCH v4 16/17] FDT: Add a helper to get specified name subnode

[Shannon Zhao]

From: Shannon Zhao 

Sometimes it needs to check if there is a node in FDT by full path.
Introduce this helper to get the specified name subnode if it exists.

Signed-off-by: Shannon Zhao 
---
CC: Rob Herring 
---
 drivers/of/fdt.c   | 25 +
 include/linux/of_fdt.h |  2 ++
 2 files changed, 27 insertions(+)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 655f79d..eacb188 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -645,6 +645,31 @@ int __init of_scan_flat_dt(int (*it)(unsigned long node,
 }
 
 /**
+ * of_get_flat_dt_subnode_by_name - get subnode of specified node by name
+ *
+ * @node: the parent node
+ * @uname: the name of subnode
+ * @return offset of the subnode, or -FDT_ERR_NOTFOUND if there is none
+ */
+
+int of_get_flat_dt_subnode_by_name(unsigned long node, const char *uname)
+{
+   const void *blob = initial_boot_params;
+   int offset;
+   const char *pathp;
+
+   for (offset = fdt_first_subnode(blob, node);
+offset >= 0;
+offset = fdt_next_subnode(blob, offset)) {
+   pathp = fdt_get_name(blob, offset, NULL);
+   if (strcmp(pathp, uname) == 0)
+   return offset;
+   }
+
+   return -FDT_ERR_NOTFOUND;
+}
+
+/**
  * of_get_flat_dt_root - find the root node in the flat blob
  */
 unsigned long __init of_get_flat_dt_root(void)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index df9ef38..fc28162 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -52,6 +52,8 @@ extern char __dtb_end[];
 extern int of_scan_flat_dt(int (*it)(unsigned long node, const char *uname,
 int depth, void *data),
   void *data);
+extern int of_get_flat_dt_subnode_by_name(unsigned long node,
+ const char *uname);
 extern const void *of_get_flat_dt_prop(unsigned long node, const char *name,
   int *size);
 extern int of_flat_dt_is_compatible(unsigned long node, const char *name);
-- 
2.0.4



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

Re: [Xen-devel] Adding Xen to the kbuild bot?

[Fengguang Wu]

Hi Andy,

CC more people on Xen testing -- in case OSStest already (or plans to)
cover such test case.

On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
> Hi all-
> 
> Would it make sense to add some basic Xen PV testing to the kbuild bot?

Do you mean to run basic Xen testing on the various kernel trees that
0day robot covers? That is, to catch kernel regressions when running
under Xen.

If the intention is to catch Xen regressions, the OSStest
infrastructure may be a better option:

git://xenbits.xen.org/osstest.git

> qemu can boot Xen like this:
> 
> qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
> kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
> 
> This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.

Got it. If you have simple working test scripts to illustrate test
details, it'd be a great help for integrating into OSStest or 0day.

> Linux has never been been able to do virtio under Xen, which will
> screw up your scripts, but I'm cautiously optimistic that virtio will
> work as expected on a Xen guest starting with Linux 4.6.  If you want
> to play around, it should work in this tree:
> 
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=virtio_dma
> 
> I'm hoping to get that queued up for real in the next couple of days.

Thanks,
Fengguang

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

Re: [Xen-devel] [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary?

[Alex Braunegg]

Hi Andrew,

I don't know enough on the internals of xen / qemu here - however, based on
what you said, an x86_64 OS with >4Gb memory should boot via xl - however in
my case here it fails to start up:

-

[root@mynas-s5000xvn ~]# xl - create /etc/xen/config/Windows_2008_R2.cfg

Parsing config from /etc/xen/config/Windows_2008_R2.cfg
libxl: debug: libxl_create.c:1560:do_domain_create: ao 0x735690: create:
how=(nil) callback=(nil) poller=0x734b70
libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk
vdev=hda spec.backend=unknown
libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk
vdev=hda, using backend phy
libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk
vdev=hdc spec.backend=unknown
libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk
vdev=hdc, using backend phy
libxl: debug: libxl_create.c:945:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:324:libxl__bootloader_run: not a PV domain,
skipping bootloader
libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch
w=0x736078: deregister unregistered
xc: detail: elf_parse_binary: phdr: paddr=0x10 memsz=0x5b3a4
xc: detail: elf_parse_binary: memory: 0x10 -> 0x15b3a4
xc: detail: VIRTUAL MEMORY ARRANGEMENT:
xc: detail:   Loader:   0010->0015b3a4
xc: detail:   Modules:  ->
xc: detail:   TOTAL:->00017f00
xc: detail:   ENTRY:00100600
xc: detail: PHYSICAL MEMORY ALLOCATION:
xc: detail:   4KB PAGES: 0x0200
xc: detail:   2MB PAGES: 0x05f7
xc: detail:   1GB PAGES: 0x0003
xc: detail: elf_load_binary: phdr 0 at 0x7efc906d7000 -> 0x7efc90728910
xc: error: Could not clear special pages (22 = Invalid argument): Internal
error
libxl: error: libxl_dom.c:1003:libxl__build_hvm: hvm building failed
libxl: error: libxl_create.c:1142:domcreate_rebuild_done: cannot (re-)build
domain: -3
libxl: error: libxl_dm.c:1956:kill_device_model: unable to find device model
pid in /local/domain/11/image/device-model-pid
libxl: error: libxl.c:1628:libxl__destroy_domid: libxl__destroy_device_model
failed for 11
libxl: debug: libxl.c:1719:devices_destroy_cb: forked pid 18569 for destroy
of domain 11
libxl: debug: libxl_create.c:1583:do_domain_create: ao 0x735690: inprogress:
poller=0x734b70, flags=i
libxl: debug: libxl_event.c:1874:libxl__ao_complete: ao 0x735690: complete,
rc=-3
libxl: debug: libxl_event.c:1843:libxl__ao__destroy: ao 0x735690: destroy
libxl: debug: libxl.c:1458:libxl_domain_destroy: ao 0x734bc0: create:
how=(nil) callback=(nil) poller=0x734b70
libxl: error: libxl.c:1591:libxl__destroy_domid: non-existant domain 11
libxl: error: libxl.c:1549:domain_destroy_callback: unable to destroy guest
with domid 11
libxl: error: libxl.c:1476:domain_destroy_cb: destruction of domain 11
failed
libxl: debug: libxl_event.c:1874:libxl__ao_complete: ao 0x734bc0: complete,
rc=-21
libxl: debug: libxl.c:1467:libxl_domain_destroy: ao 0x734bc0: inprogress:
poller=0x734b70, flags=ic
libxl: debug: libxl_event.c:1843:libxl__ao__destroy: ao 0x734bc0: destroy
xc: debug: hypercall buffer: total allocations:851 total releases:851
xc: debug: hypercall buffer: current allocations:0 maximum allocations:3
xc: debug: hypercall buffer: cache current size:3
xc: debug: hypercall buffer: cache hits:841 misses:3 toobig:7
[root@mynas-s5000xvn ~]#

-

Guest Config:
=

-

builder='hvm'
memory = 6144
shadow_memory = 8
uuid = '27f4787c-89b2-46ab-a797-96ea6e84c511'
name = 'Windows_2008_R2'
vif = [ 'bridge=br0, mac=00:16:3e:96:49:10' ]
disk = [
'/dev/zvol/storage0/xen/Windows_2008_R2/disk_sda,,hda','/storage0/data-share
s/iso/en_windows_server_2008_r2_standard_enterprise_datacenter_and_web_x64_d
vd_x15-59754.iso,,hdc,cdrom' ]
# boot on floppy (a), hard disk (c) or CD-ROM (d)
# default: hard disk, cd-rom, floppy
boot='dc'
sdl=0
vnc=1
vncconsole=1
vnclisten='0.0.0.0'
stdvga=1
serial='pty'
usbdevice='tablet'
vncpasswd='bpC7fKtsDy'
vncdisplay=2
localtime=1
audio='1'
soundhw='ac97'

-

xl info

-
host   : mynas-s5000xvn.localdomain
release: 4.3.4-1.el6.x86_64
version: #1 SMP Wed Jan 27 13:05:22 EST 2016
machine: x86_64
nr_cpus: 8
max_cpu_id : 7
nr_nodes   : 1
cores_per_socket   : 4
threads_per_core   : 1
cpu_mhz: 1861
hw_caps:
bfebfbff:20100800::0900:0004e3bd::0001:
virt_caps  : hvm
total_memory   : 8165
free_memory: 7046
sharing_freed_memory   : 0
sharing_used_memory: 0

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Zhiyuan Lv]

Hi George,

On Thu, Feb 04, 2016 at 11:06:33AM +, George Dunlap wrote:
> On Thu, Feb 4, 2016 at 9:38 AM, Yu, Zhang  wrote:
> > On 2/4/2016 5:28 PM, Paul Durrant wrote:
> >> I assume this means that the emulator can 'unshadow' GTTs (I guess on an
> >> LRU basis) so that it can shadow new ones when the limit has been 
> >> exhausted?
> >> If so, how bad is performance likely to be if we live with a lower limit
> >> and take the hit of unshadowing if the guest GTTs become heavily 
> >> fragmented?
> >>
> > Thank you, Paul.
> >
> > Well, I was told the emulator have approaches to delay the shadowing of
> > the GTT till future GPU commands are submitted. By now, I'm not sure
> > about the performance penalties if the limit is set too low. Although
> > we are confident 8K is a secure limit, it seems still too high to be
> > accepted. We will perform more experiments with this new approach to
> > find a balance between the lowest limit and the XenGT performance.
> 
> Just to check some of my assumptions:
> 
> I assume that unlike memory accesses, your GPU hardware cannot
> 'recover' from faults in the GTTs. That is, for memory, you can take a
> page fault, fix up the pagetables, and then re-execute the original
> instruction; but so far I haven't heard of any devices being able to
> seamlessly re-execute a transaction after a fault.  Is my
> understanding correct?

That's correct. At least for now, we do not have GPU page fault.

> 
> If that is the case, then for every top-level value (whatever the
> equivalent of the CR3), you need to be able to shadow the entire GTT
> tree below it, yes?  You can't use a trick that the memory shadow

That's right also.

> pagetables can use, of unshadowing parts of the tree and reshadowing
> them.
> 
> So as long as the currently-in-use GTT tree contains no more than
> $LIMIT ranges, you can unshadow and reshadow; this will be slow, but
> strictly speaking correct.
> 
> What do you do if the guest driver switches to a GTT such that the
> entire tree takes up more than $LIMIT entries?

GPU has some special properties different from CPU, which make things
easier. The GPU page table is constructed by CPU and used by GPU
workloads. GPU workload itself will not change the page table.
Meanwhile, GPU workload submission, in virtualized environment, is
controled by our device model. Then we can reshadow the whole table
every time before we submit workload. That can reduce the total number
required for write protection but with performance impact, because GPU
has to have more idle time waiting for CPU. Hope the info helps.
Thanks!

Regards,
-Zhiyuan

> 
>  -George

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

Re: [Xen-devel] [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary?

[Andrew Cooper]

On 04/02/2016 23:14, Steven Haigh wrote:
> On 2016-02-05 09:22, Andrew Cooper wrote:
>> On 04/02/2016 22:06, Alex Braunegg wrote:
>>> root 30511 46.4  0.1 398728  1860 ?RLsl 08:47   0:27
>>> /usr/lib/xen/bin/qemu-system-i386 -xen-domid 6 -chardev
>>> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-6,server,n
>>> owait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev
>>> socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-6,server,nowait
>>>
>>> -mon chardev=libxenstat-cmd,mode=control
>>> -nodefaults -name test2 -vnc
>>> 0.0.0.0:0,websocket,x509=/etc/pki/xen,password,to=99 -display none
>>> -serial
>>> pty -device VGA,vgamem_mb=16 -boot order=cd -usb -usbdevice tablet
>>> -soundhw
>>>  ac97 -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:f1:48:8c -netdev
>>> type=tap,id=net0,ifname=vif6.0-emu,script=no,downscript=no -machine
>>> xenfv -m
>>> 496 -drive file=/dev/zvol/stor
>>> age0/xen/test2/disk_sda,if=ide,index=0,media=disk,format=raw,cache=writeback
>>>
>>> -drive
>>> file=/storage0/data-shares/iso/CentOS-6.5-x86_64-minimal.iso,if=ide,index=2,
>>>
>>> readonly=on,media=c
>>> drom,format=raw,cache=writeback,id=ide-5632
>>>
>>> --
>>>
>>> So - to me it appears that xl is performing some sort of x86_64 ->
>>> i386/i686
>>> instruction translation to make things work.
>>>
>>> Would this not be introducing a performance impediment by having
>>> some sort
>>> of extra translation processing going on between xl and the qemu
>>> binary?
>>
>> Qemu is only used for device emulation when used with Xen, not CPU
>> emulation.
>>
>> The "-machine xenfv" tells this to Qemu, and "-xen-domid 6" tells it
>> which Xen domain to connect to.
>>
>> All HVM domains run with hardware virtualisation extensions, which are
>> managed by Xen itself.
>
> Hi Andrew,
>
> Thanks for this response - to ensure I have this correct, there is no
> need for qemu-upstream to build qemu-system-x86_64 as the CPU is
> directly handled by Xen and not by qemu

Correct.

> - thereby passing through the capabilities of the CPU directly to the
> guest. As such, as long as qemu starts on a 64 bit machine it will be
> able to run 64 bit OS/kernel etc.

Incorrect.  A 32bit Qemu is perfectly able to emulate devices for a
64bit OS.

The ABI of the emulated devices is not tied to the running width of Qemu
or the OS.

>
> I ask this as I see a number of qemu packages that do include
> qemu-system-x86_64 as well as qemu-system-i386 - which makes me seek
> clarification. I would assume that these are just not built to use Xen
> as the hypervisor for hardware acceleration?
>

This will just be down to the choice of the person who packaged qemu for
a particular distro.

~Andrew

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

Re: [Xen-devel] Memory Sharing

[Tamas K Lengyel]

On Thu, Feb 4, 2016 at 2:04 PM, hanji unit  wrote:

> Hello, does Xen support sharing memory pages between multiple domains
> (such as as Dom0, DomU1, DomU2)? The Grant Table hypercalls seem
> limited to:
>
> IOCTL_GNTALLOC_ALLOC_GREF
> IOCTL_GNTALLOC_DEALLOC_GREF
> IOCTL_GNTALLOC_SET_UNMAP_NOTIFY
>
> Is there any mechanism to not allocate, but only share existing pages?
>

There is, it's call mem_share in Xen, but it's not very well (khm at all)
documented. You can take a look at
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/tests/mem-sharing/memshrtool.c;h=437c7c9c472c0eff29b60e54f3de90e878de6d34;hb=HEAD
to see an outline of the tools-side functions that control it. I also have
a simple clone routine that deduplicates (clones) two identical VMs here
https://github.com/tklengyel/drakvuf/blob/master/src/xen_helper/xen_helper.c#L197
.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 60684
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 60684
 test-amd64-amd64-libvirt 15 guest-saverestore.2   fail REGR. vs. 60684
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail REGR. vs. 60684
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2   fail REGR. vs. 60684
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 60684

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 60684
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-xl-xsm   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-xl   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-i386-pair  22 guest-migrate/dst_host/src_host fail blocked in 60684
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 60684
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 60684

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   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-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass

version targeted for testing:
 linux3d79a4dd8eeba85b9db5f2b9cd74179e9ffc0269
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  175 days
Failing since 60712  2015-08-15 18:33:48 Z  173 days  123 attempts
Testing same since80380  2016-02-04 04:29:27 Z0 days1 attempts

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
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  fail
 test-amd64-i386-xl   fail
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  fail
 test-amd64-amd64-xl-xsm   

Re: [Xen-devel] [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary?

[Alex Braunegg]

Hi Andrew,

The Windows 2008 .cfg was built up using guidance from
http://www.virtuatopia.com/index.php/Virtualizing_Windows_Server_2008_with_X
en

If shadow_memory is not required - easy enough remove and retest. (which
after removing this line, the guest started without issue)

The physical server itself is an Intel S5000xvn motherboard with 2 x E5320
CPU's:

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Xeon(R) CPU   E5320  @ 1.86GHz
stepping: 7
microcode   : 0x69
cpu MHz : 1861.990
cache size  : 4096 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush
acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc arch_perfmon
rep_good nopl pni monitor est ssse3 cx16 hypervisor lahf_lm dtherm
bugs:
bogomips: 3723.98
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:


Best regards,

Alex


-Original Message-
From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew
Cooper
Sent: Friday, 5 February 2016 11:04 AM
To: Alex Braunegg; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [QUESTION] x86_64 -> i386/i686 CPU translation
between xl and qemu binary?

On 04/02/2016 23:44, Alex Braunegg wrote:
> Hi Andrew,
>
> I don't know enough on the internals of xen / qemu here - however, based
on
> what you said, an x86_64 OS with >4Gb memory should boot via xl - however
in
> my case here it fails to start up:
>
> -
>
> [root@mynas-s5000xvn ~]# xl - create
/etc/xen/config/Windows_2008_R2.cfg
>
> Parsing config from /etc/xen/config/Windows_2008_R2.cfg
> libxl: debug: libxl_create.c:1560:do_domain_create: ao 0x735690: create:
> how=(nil) callback=(nil) poller=0x734b70
> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk
> vdev=hda spec.backend=unknown
> libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk
> vdev=hda, using backend phy
> libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk
> vdev=hdc spec.backend=unknown
> libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk
> vdev=hdc, using backend phy
> libxl: debug: libxl_create.c:945:initiate_domain_create: running
bootloader
> libxl: debug: libxl_bootloader.c:324:libxl__bootloader_run: not a PV
domain,
> skipping bootloader
> libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch
> w=0x736078: deregister unregistered
> xc: detail: elf_parse_binary: phdr: paddr=0x10 memsz=0x5b3a4
> xc: detail: elf_parse_binary: memory: 0x10 -> 0x15b3a4
> xc: detail: VIRTUAL MEMORY ARRANGEMENT:
> xc: detail:   Loader:   0010->0015b3a4
> xc: detail:   Modules:  ->
> xc: detail:   TOTAL:->00017f00
> xc: detail:   ENTRY:00100600
> xc: detail: PHYSICAL MEMORY ALLOCATION:
> xc: detail:   4KB PAGES: 0x0200
> xc: detail:   2MB PAGES: 0x05f7
> xc: detail:   1GB PAGES: 0x0003
> xc: detail: elf_load_binary: phdr 0 at 0x7efc906d7000 -> 0x7efc90728910
> xc: error: Could not clear special pages (22 = Invalid argument): Internal
> error
> libxl: error: libxl_dom.c:1003:libxl__build_hvm: hvm building failed

The problem is here, but it isn't immediately apparent why (other than
"failed to map special pages").

> Guest Config:
> =
>
> -
>
> builder='hvm'
> memory = 6144
> shadow_memory = 8

These values look suspicious to me.  What hardware is this running on?
Either you are on more modern hardware and shouldn't touch
shadow_memory, or you are on rather older hardware, at which point 8M of
shadow memory is probably too small for a 6G VM.

~Andrew


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

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Jan Beulich]

>>> On 04.02.16 at 14:47,  wrote:
>> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
>> Sent: 04 February 2016 13:34
>>  * Is it possible for libxl to somehow tell from the rest of the
>>configuration that this larger limit should be applied ?
>> 
>>AFAICT there is nothing in libxl directly involving vgpu.  How can
>>libxl be used to create a guest with vgpu enabled ?  I had thought
>>that this was done merely with the existing PCI passthrough
>>configuration, but it now seems that somehow a second device model
>>would have to be started.  libxl doesn't have code to do that.
>> 
> 
> AIUI if the setting of the increased limit is tied to provisioning a gvt-g 
> instance for a VM then I don't there needs to be extra information in the VM 
> config. These seems like the most sensible thing to do.

I don't understand this: For one, it's still unclear to me on what basis
it would be known that a given VM is a "gvt-g instance". And even if
that's indeed derivable from something, the uncertainty about a
workable upper bound on the number of WP ranges would still seem
to demand the value to be specifiable separately...

>> I now understand that these mmio ranges are created by the device
>> model.  Of course the device model needs to be able to create mmio
>> ranges for the guest.  And since they consume hypervisor resources,
>> the number of these must be limited (device models not necessarily
>> being trusted).
> 
> ...but I think there is still an open question as to whether the toolstack 
> is allowed to set that limit for a VM or not. IMO the toolstack should be 
> allowed to set that limit when creating a domain.

... as you indicate here.

Jan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  e3e4ae8bb8314462496c2b065cfe4e8bc5205d5a
baseline version:
 xen  be05b5385fb261c1fa1cbb6b4bdc12a6e8676c4b

Last test of basis80228  2016-02-03 14:01:47 Z0 days
Testing same since80441  2016-02-04 11:00:46 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Huaitong Han 
  Jan Beulich 
  Kevin Tian 
  Shuai Ruan 
  Tim Deegan 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=e3e4ae8bb8314462496c2b065cfe4e8bc5205d5a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
e3e4ae8bb8314462496c2b065cfe4e8bc5205d5a
+ branch=xen-unstable-smoke
+ revision=e3e4ae8bb8314462496c2b065cfe4e8bc5205d5a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-unstable
+ '[' xe3e4ae8bb8314462496c2b065cfe4e8bc5205d5a = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
 

Re: [Xen-devel] [PATCH v2 08/11] xen/hvmlite: Extend APIC operations for HVMlite guests

[Boris Ostrovsky]

On 02/04/2016 07:14 AM, Roger Pau Monné wrote:

El 4/2/16 a les 11:04, David Vrabel ha escrit:

On 01/02/16 15:38, Boris Ostrovsky wrote:

HVMlite guests need to be viewed as having APIC, otherwise smpboot code,
for example, will complain.

I think we should consider always giving HVMlite guests an emulated
APIC.  I think this eliminates one of the biggest differences between
HVMlite and native/KVM guests and will reduce the risk of future
breakage in this area.

Right, I'm not opposed to that, but I think we should keep the hypercall
interface in order to bring up vCPUs. IMHO it's useful for unikernels
for example (do those support SMP?), and in general allows for
easier/faster CPU-bringup as compared to bare metal.


As I mentioned in another reply, we can manage without emulated apic by 
slightly extending PV APIC. However, it is rather fragile and I think 
not having to do this would be a great improvement from code reliability 
POV. And with Intel's vAPIC (and AMD's equivalent eventually, I suppose) 
we should get performance improvement as well.


What was the reason for not providing it? ACPI?



Then if we indeed decide to provide and emulated lapic, should we also
at least provide the ACPI MADT table in order to enumerate them?


This brings another question that I was going to ask. In the NVDIMM 
thread there is a discussion about where to implement ACPI tables and I 
think people are leaning toward doing in it qemu. With HVMlite we can 
only (??) implement MADT (and whatever we add later) in the toolstack 
and so we will have 3 places (qemu, hvmloader, toolstack) that build 
ACPI tables.


Can we have all this done in one place? Perhaps keep this code as a library?

-boris

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

Re: [Xen-devel] [PATCH v2] libxenevtchn: rename evtchn_port_or_errot_t as xenevtchn_port...

[Olaf Hering]

On Thu, Feb 04, Ian Campbell wrote:

> Cc: Olaf Hering 

Also this builds on SLE11/12.

Tested-by: Olaf Hering 

Olaf

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

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Ian Jackson]

Paul Durrant writes ("RE: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter 
max_wp_ram_ranges."):
> There are patches in the XenGT xen repo which add extra parameters
> into the VM config to allow libxl to provision a gvt-g instance (of
> which there are a finite number per GPU) for a VM. The increased
> limit could be applied when doing so and it may be feasible to
> determine (maybe from the version of the GPU h/w) what a reasonable
> limit is.

Right.  So in that case there would be no need for this user-visible
knob (along with its sadly not very helpful documentation) to be
exposed in the libxl stable API.

Ian.

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

Re: [Xen-devel] [PATCH v2 10/11] xen/hvmlite: Boot secondary CPUs

[Boris Ostrovsky]

On 02/04/2016 05:38 AM, David Vrabel wrote:

On 01/02/16 15:38, Boris Ostrovsky wrote:

HVMlite secondary VCPUs use baremetal bringup path (i.e. native_*
smp_ops) but need to do some preparation in PV code.

If we always provided an emulated APIC could we use the native SMP
bring-up instead?


We do use native SMP bringup now (wrapped in 
xen_hvm_cpu_up/xen_cpu_die/xen_play_dead)), I added a couple of PV APIC 
ops to help with that, most notably xen_wakeup_secondary_cpu().


-boris

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

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 04 February 2016 14:13
> To: Paul Durrant
> Cc: Andrew Cooper; George Dunlap; Ian Campbell; Ian Jackson; Stefano
> Stabellini; Wei Liu; Kevin Tian; zhiyuan...@intel.com; Zhang Yu; xen-
> de...@lists.xen.org; Keir (Xen.org)
> Subject: RE: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter
> max_wp_ram_ranges.
> 
> >>> On 04.02.16 at 14:47,  wrote:
> >> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> >> Sent: 04 February 2016 13:34
> >>  * Is it possible for libxl to somehow tell from the rest of the
> >>configuration that this larger limit should be applied ?
> >>
> >>AFAICT there is nothing in libxl directly involving vgpu.  How can
> >>libxl be used to create a guest with vgpu enabled ?  I had thought
> >>that this was done merely with the existing PCI passthrough
> >>configuration, but it now seems that somehow a second device model
> >>would have to be started.  libxl doesn't have code to do that.
> >>
> >
> > AIUI if the setting of the increased limit is tied to provisioning a gvt-g
> > instance for a VM then I don't there needs to be extra information in the
> VM
> > config. These seems like the most sensible thing to do.
> 
> I don't understand this: For one, it's still unclear to me on what basis
> it would be known that a given VM is a "gvt-g instance". And even if
> that's indeed derivable from something, the uncertainty about a
> workable upper bound on the number of WP ranges would still seem
> to demand the value to be specifiable separately...

There are patches in the XenGT xen repo which add extra parameters into the VM 
config to allow libxl to provision a gvt-g instance (of which there are a 
finite number per GPU) for a VM. The increased limit could be applied when 
doing so and it may be feasible to determine (maybe from the version of the GPU 
h/w) what a reasonable limit is.

  Paul

> 
> >> I now understand that these mmio ranges are created by the device
> >> model.  Of course the device model needs to be able to create mmio
> >> ranges for the guest.  And since they consume hypervisor resources,
> >> the number of these must be limited (device models not necessarily
> >> being trusted).
> >
> > ...but I think there is still an open question as to whether the toolstack
> > is allowed to set that limit for a VM or not. IMO the toolstack should be
> > allowed to set that limit when creating a domain.
> 
> ... as you indicate here.
> 
> Jan


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

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Tian, Kevin]

> From: Lv, Zhiyuan
> Sent: Friday, February 05, 2016 10:01 AM
> 
> Hi George,
> 
> On Thu, Feb 04, 2016 at 11:06:33AM +, George Dunlap wrote:
> > On Thu, Feb 4, 2016 at 9:38 AM, Yu, Zhang  
> > wrote:
> > > On 2/4/2016 5:28 PM, Paul Durrant wrote:
> > >> I assume this means that the emulator can 'unshadow' GTTs (I guess on an
> > >> LRU basis) so that it can shadow new ones when the limit has been 
> > >> exhausted?
> > >> If so, how bad is performance likely to be if we live with a lower limit
> > >> and take the hit of unshadowing if the guest GTTs become heavily 
> > >> fragmented?
> > >>
> > > Thank you, Paul.
> > >
> > > Well, I was told the emulator have approaches to delay the shadowing of
> > > the GTT till future GPU commands are submitted. By now, I'm not sure
> > > about the performance penalties if the limit is set too low. Although
> > > we are confident 8K is a secure limit, it seems still too high to be
> > > accepted. We will perform more experiments with this new approach to
> > > find a balance between the lowest limit and the XenGT performance.
> >
> > Just to check some of my assumptions:
> >
> > I assume that unlike memory accesses, your GPU hardware cannot
> > 'recover' from faults in the GTTs. That is, for memory, you can take a
> > page fault, fix up the pagetables, and then re-execute the original
> > instruction; but so far I haven't heard of any devices being able to
> > seamlessly re-execute a transaction after a fault.  Is my
> > understanding correct?
> 
> That's correct. At least for now, we do not have GPU page fault.
> 
> >
> > If that is the case, then for every top-level value (whatever the
> > equivalent of the CR3), you need to be able to shadow the entire GTT
> > tree below it, yes?  You can't use a trick that the memory shadow
> 
> That's right also.
> 
> > pagetables can use, of unshadowing parts of the tree and reshadowing
> > them.
> >
> > So as long as the currently-in-use GTT tree contains no more than
> > $LIMIT ranges, you can unshadow and reshadow; this will be slow, but
> > strictly speaking correct.
> >
> > What do you do if the guest driver switches to a GTT such that the
> > entire tree takes up more than $LIMIT entries?
> 
> GPU has some special properties different from CPU, which make things
> easier. The GPU page table is constructed by CPU and used by GPU
> workloads. GPU workload itself will not change the page table.
> Meanwhile, GPU workload submission, in virtualized environment, is
> controled by our device model. Then we can reshadow the whole table
> every time before we submit workload. That can reduce the total number
> required for write protection but with performance impact, because GPU
> has to have more idle time waiting for CPU. Hope the info helps.
> Thanks!
> 

Putting in another way, it's fully under mediation when a GPU page table 
(GTT) will be referenced by the GPU, so there're plenty of room to
optimize existing shadowing (always shadowing all recognized GPU page
tables), e.g. shadowing only active one when a VM is scheduled in. It's
a performance matter but no correctness issue.

This is why Yu mentioned earlier whether we can just set a default
limit which is good for majority of use cases, while extending our
device mode to drop/recreate some shadow tables upon the limitation
is hit. I think this matches how today's CPU shadow page table is
implemented, which also has a limitation of how many shadow pages
are allowed per-VM.

Thanks
Kevin

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

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Tian, Kevin]

> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: Friday, February 05, 2016 1:12 AM
> 
> On 04/02/16 14:08, Jan Beulich wrote:
>  On 04.02.16 at 14:33,  wrote:
> >> Jan Beulich writes ("Re: [Xen-devel] [PATCH v3 3/3] tools: introduce 
> >> parameter
> >> max_wp_ram_ranges."):
> >>> On 04.02.16 at 10:38,  wrote:
>  So another question is, if value of this limit really matters, will a
>  lower one be more acceptable(the current 256 being not enough)?
> >>>
> >>> If you've carefully read George's replies, [...]
> >>
> >> Thanks to George for the very clear explanation, and also to him for
> >> an illuminating in-person discussion.
> >>
> >> It is disturbing that as a result of me as a tools maintainer asking
> >> questions about what seems to me to be a troublesome a user-visible
> >> control setting in libxl, we are now apparently revisiting lower
> >> layers of the hypervisor design, which have already been committed.
> >>
> >> While I find George's line of argument convincing, neither I nor
> >> George are maintainers of the relevant hypervisor code.  I am not
> >> going to insist that anything in the hypervisor is done different and
> >> am not trying to use my tools maintainer position to that end.
> >>
> >> Clearly there has been a failure of our workflow to consider and
> >> review everything properly together.  But given where we are now, I
> >> think that this discussion about hypervisor internals is probably a
> >> distraction.
> >
> > While I recall George having made that alternative suggestion,
> > both Yu and Paul having reservations against it made me not
> > insist on that alternative. Instead I've been trying to limit some
> > of the bad effects that the variant originally proposed brought
> > with it. Clearly, with the more detailed reply George has now
> > given (involving areas where he is the maintainer for), I should
> > have been more demanding towards the exploration of that
> > alternative. That's clearly unfortunate, and I apologize for that,
> > but such things happen.
> >
> > As to one of the patches already having for committed - I'm not
> > worried about that at all. We can always revert, that's why the
> > thing is called "unstable".
> 
> It looks like I should have been more careful to catch up on the current
> state of things before I started arguing again -- please accept my
> apologies.

Thanks George for your careful thinking.

> 
> I see that patch 2/3 addresses the gpfn/io question in the commit
> message by saying, "Previously, a new hypercall or subop was suggested
> to map write-protected pages into ioreq server. However, it turned out
> handler of this new hypercall would be almost the same with the existing
> pair - HVMOP_[un]map_io_range_to_ioreq_server, and there's already a
> type parameter in this hypercall. So no new hypercall defined, only a
> new type is introduced."
> 
> And I see that 2/3 internally separates the WP_RAM type into a separate
> rangeset, whose size can be adjusted separately.
> 
> This addresses my complaint about the interface using gpfns rather than
> MMIO ranges as an interface (somewhat anyway).  Sorry for not
> acknowledging this at first.
> 
> The question of the internal implementation -- whether to use RB tree
> rangesets, or radix trees (as apparently ARM memaccess does) or p2m
> types -- is an internal implementation question.  I think p2m types is
> long-term the best way to go, but it won't hurt to have the current
> implementation checked in, as long as it doesn't have any impacts on the
> stable interface.

I'm still trying to understand your suggestion vs. this one. Today we
already have a p2m_mmio_write_dm type. It's there already, and any
write fault hitting that type will be delivered to ioreq server. Then next
open is how a ioreq server could know whether it should handle this
request or not, which is why some tracking structures (either RB/radix)
are created to maintain that specific information. It's under the assumption
that multiple ioreq servers co-exist, so a loop check on all ioreq servers
is required to identify the right target. And multiple ioreq servers are
real case in XenGT, because our vGPU device model is in kernel, as
part of Intel i915 graphics driver. So at least two ioreq servers already
exist, with one routing to XenGT in Dom0 kernel space and the other 
to the default Qemu in Dom0 user.

In your long-term approach with p2m types, looks you are proposing
encoding ioreq server ID in p2m type directly (e.g. 4bits), which then 
eliminates the need of tracking in ioreq server side so the whole
security concern is gone. And no limitation at all. Because available
p2m bits are limited, as Andrew pointed out, so it might be reasonable
to implement this approach when a new p2t structure is added, which
is why we consider it as a long-term approach.

Please correct me if above understanding is correct?

> 
> At the moment, as far as 

Re: [Xen-devel] [PATCH v7 5/5] PCI: ACPI: Add a generic ACPI based host controller

[Bjorn Helgaas]

Hi Jayachandran,

On Fri, Jan 29, 2016 at 02:35:40PM +0530, Jayachandran C wrote:
> Add a simple ACPI based PCI host controller under config option
> ACPI_PCI_HOST_GENERIC. This is done by providing an implementation
> of pci_acpi_scan_root().
> 
> The pci_mmcfg_list handling is done by the ACPI code, so we keep a
> reference to the pci_mmcfg_region in sysdata. The ECAM region will
> be already mapped, so map_bus can be implemented by using the
> virt pointer for the pci_mmcfg_region. pci_generic_config_read
> and pci_generic_config_write are used for config space read/write.
> 
> Also, we provide implementations of raw_pci_read and raw_pci_write
> hat are needed by ACPI based on the pci_mmcfg_list.
> 
> pci_acpi_set_companion() and acpi_pci_get_segment() are defined
> using sysdata of generic ACPI host controller so that PCI domain
> and ACPI companion are set in PCI code rather than platform code.
> 
> This code is currently enabled only for ARM64.
> 
> Signed-off-by: Jayachandran C 
> ---
>  drivers/acpi/Kconfig |   8 ++
>  drivers/acpi/Makefile|   1 +
>  drivers/acpi/pci_host_acpi.c | 186 
> +++
>  include/linux/pci-acpi.h |  17 
>  4 files changed, 212 insertions(+)
>  create mode 100644 drivers/acpi/pci_host_acpi.c

I'm speaking a little bit out of turn here, because this is ACPI code,
but I'm confused about pci_host_acpi.c.  We already have pci_root.c,
which is *supposed* to be arch-independent.  I know pci_root.c is
crufty and could be improved, but it does work today on x86 and ia64,
and it handles some generic things that pci_host_acpi.c does not,
e.g., _OSC, NUMA, host bridge hotplug, etc.

I'd really like to see pci_root.c improved so it could work on x86,
ia64, and arm64.  I'm sure that was probably the first thing you
tried, so likely there are issues there.  Are they insurmountable?

Bjorn

> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 82b96ee..65fb483 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -294,6 +294,14 @@ config ACPI_NUMA
>   depends on (X86 || IA64)
>   default y if IA64_GENERIC || IA64_SGI_SN2
>  
> +config ACPI_PCI_HOST_GENERIC
> + bool "Generic ACPI PCI host controller"
> + depends on ARM64 && ACPI
> + help
> +   Say Y here if you want to support a simple generic ACPI PCI host
> +   controller.
> +
> +
>  config ACPI_CUSTOM_DSDT_FILE
>   string "Custom DSDT Table file to include"
>   default ""
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 74976f1..346101c 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -41,6 +41,7 @@ acpi-y  += ec.o
>  acpi-$(CONFIG_ACPI_DOCK) += dock.o
>  acpi-y   += pci_root.o pci_link.o pci_irq.o
>  acpi-$(CONFIG_PCI_MMCONFIG)  += pci_mcfg.o
> +acpi-$(CONFIG_ACPI_PCI_HOST_GENERIC) += pci_host_acpi.o
>  acpi-y   += acpi_lpss.o acpi_apd.o
>  acpi-y   += acpi_platform.o
>  acpi-y   += acpi_pnp.o
> diff --git a/drivers/acpi/pci_host_acpi.c b/drivers/acpi/pci_host_acpi.c
> new file mode 100644
> index 000..9dbdd81
> --- /dev/null
> +++ b/drivers/acpi/pci_host_acpi.c
> @@ -0,0 +1,186 @@
> +/*
> + * Generic PCI host controller driver for ACPI based systems
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + *
> + * Copyright (c) 2015 Broadcom Corporation
> + *
> + * Based on drivers/pci/host/pci-host-generic.c
> + * Copyright (C) 2014 ARM Limited
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PREFIX   "pci-host-acpi:"
> +
> +/* sysdata pointer is ->root_info */
> +struct gen_acpi_root_info {
> + struct acpi_pci_root_info   common;
> + struct pci_mmcfg_region *mcfg;
> + boolmcfg_added;
> +};
> +
> +/* find mapping of a MCFG area */
> +static void __iomem *gen_acpi_map_cfg_bus(struct pci_bus *bus,
> + unsigned int devfn, int where)
> +{
> + struct gen_acpi_root_info *pci = bus->sysdata;
> + struct pci_mmcfg_region *mcfg = pci->mcfg;
> +
> + if (bus->number < mcfg->start_bus || bus->number > mcfg->end_bus)
> + return NULL;
> +
> + return mcfg->virt +
> +  

[Xen-devel] [linux-linus test] 80381: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 59254
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   8 leak-check/basis(8)   fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail REGR. vs. 
59254
 test-armhf-armhf-xl  15 guest-start/debian.repeat fail REGR. vs. 59254
 test-amd64-i386-xl   15 guest-localmigratefail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-xl-xsm   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail REGR. vs. 59254
 test-amd64-i386-pair   22 guest-migrate/dst_host/src_host fail REGR. vs. 59254
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 59254
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt 15 guest-saverestore.2  fail blocked in 59254
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   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-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 linuxb37a05c083c85c2657dca9bbe1f5d79dccf756d5
baseline version:
 linux

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 65543
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 65543

version targeted for testing:
 ovmf b2d0e0c51a6ca426ec5e9748130489eb8208af96
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z   58 days
Failing since 65593  2015-12-08 23:44:51 Z   58 days   63 attempts
Testing same since80399  2016-02-04 06:40:24 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Yao, Jiewen" 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Charles Duffy 
  Cinnamon Shia 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  Eric Dong 
  Eric Dong 
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Hao Wu 
  Hess Chen 
  Heyi Guo 
  Jaben Carsey 
  Jeff Fan 
  Jiaxin Wu 
  Jim Dailey 
  Jordan Justen 
  Karyne Mayer 
  Larry Hauch 
  Laszlo Ersek 
  Leekha Shaveta 
  Liming Gao 
  Mark Rutland 
  Michael Kinney 
  Michael Thomas 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Qin Long 
  Qiu Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Star Zeng 
  Tapan Shah 
  Vladislav Vovchenko 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  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 7977 lines long.)

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

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Tian, Kevin]

> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Thursday, February 04, 2016 6:06 PM
> 
> On Wed, 2016-02-03 at 17:41 +, George Dunlap wrote:
> > But of course, since they they aren't actually ranges but just gpfns,
> > they're scattered randomly throughout the guest physical address
> > space.
> 
> (Possibly) stupid question:
> 
> Since, AIUI, the in-guest GPU driver is XenGT aware could it not allocate a
> contiguous range of pages at start of day to use as GPU PTs? Or even just N
> contiguous regions, e.g. i think the "8K" refers to pages, which is 16 2M
> allocations, which is a far more manageable number of ranges to track than
> 8096 individual pages.
> 

We add XenGT awareness in guest driver at minimum requirement (e.g.
to handle address space ballooning due to graphics memory partitioning),
which only impacts hardware specific initialization code (thinking vgpu as
a new sku).

However we're hesitating to touch other general driver code, such as 
allocation policy you mentioned earlier. Changing that part specifically 
for one sku needs very strong reason to convince driver maintainer.

And we cannot assume above allocation policy can be always met. 

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

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Tian, Kevin]

> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Thursday, February 04, 2016 11:51 PM
> 
> > -Original Message-
> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > Sent: 04 February 2016 15:06
> > To: Paul Durrant
> > Cc: Jan Beulich; Andrew Cooper; George Dunlap; Ian Campbell; Stefano
> > Stabellini; Wei Liu; Kevin Tian; zhiyuan...@intel.com; Zhang Yu; xen-
> > de...@lists.xen.org; Keir (Xen.org)
> > Subject: RE: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter
> > max_wp_ram_ranges.
> >
> > Paul Durrant writes ("RE: [Xen-devel] [PATCH v3 3/3] tools: introduce
> > parameter max_wp_ram_ranges."):
> > > There are patches in the XenGT xen repo which add extra parameters
> > > into the VM config to allow libxl to provision a gvt-g instance (of
> > > which there are a finite number per GPU) for a VM. The increased
> > > limit could be applied when doing so and it may be feasible to
> > > determine (maybe from the version of the GPU h/w) what a reasonable
> > > limit is.
> >
> > Right.  So in that case there would be no need for this user-visible
> > knob (along with its sadly not very helpful documentation) to be
> > exposed in the libxl stable API.
> >
> 
> No, I really don't think that should be necessary. Libxl merely needs to 
> configure a limit in
> the hypervisor appropriate to the gvt-g instance that is provisioned.
> 

Agree.

Thanks
Kevin

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

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, February 04, 2016 10:13 PM
> 
> >>> On 04.02.16 at 14:47,  wrote:
> >> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> >> Sent: 04 February 2016 13:34
> >>  * Is it possible for libxl to somehow tell from the rest of the
> >>configuration that this larger limit should be applied ?
> >>
> >>AFAICT there is nothing in libxl directly involving vgpu.  How can
> >>libxl be used to create a guest with vgpu enabled ?  I had thought
> >>that this was done merely with the existing PCI passthrough
> >>configuration, but it now seems that somehow a second device model
> >>would have to be started.  libxl doesn't have code to do that.
> >>
> >
> > AIUI if the setting of the increased limit is tied to provisioning a gvt-g
> > instance for a VM then I don't there needs to be extra information in the VM
> > config. These seems like the most sensible thing to do.
> 
> I don't understand this: For one, it's still unclear to me on what basis
> it would be known that a given VM is a "gvt-g instance". And even if
> that's indeed derivable from something, the uncertainty about a
> workable upper bound on the number of WP ranges would still seem
> to demand the value to be specifiable separately...
> 

We'll invent a different parameter e.g. gvt-g from existing passthrough
one. So just for this question, a toolstack can know whether a VM is
provisioned with a vgpu based on that parameter from config file.

Thanks
Kevin

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

Re: [Xen-devel] [PATCH V10 2/5] x86/hvm: pkeys, add pkeys support for guest_walk_tables

[Jan Beulich]

>>> On 04.02.16 at 08:00,  wrote:
> Changes in v7:
> *Add static for pkey_fault.
> *Add a comment for page present check and adjust indentation.
> *Init pkru_ad and pkru_wd.

Sadly I've only now noticed that this hasn't been done the way it
was requested:

> --- a/xen/arch/x86/mm/guest_walk.c
> +++ b/xen/arch/x86/mm/guest_walk.c
> @@ -90,6 +90,53 @@ static uint32_t set_ad_bits(void *guest_p, void *walk_p, 
> int set_dirty)
>  return 0;
>  }
>  
> +#if GUEST_PAGING_LEVELS >= 4
> +static bool_t pkey_fault(struct vcpu *vcpu, uint32_t pfec,
> +uint32_t pte_flags, uint32_t pte_pkey)
> +{
> +uint32_t pkru = 0;
> +bool_t pkru_ad = 0, pkru_wd = 0;

These initializers are now pointless. Instead what I had asked to do
was ...

> +if ( is_pv_vcpu(vcpu) )
> +return 0;
> +
> +/*
> + * PKU:  additional mechanism by which the paging controls
> + * access to user-mode addresses based on the value in the
> + * PKRU register. A fault is considered as a PKU violation if all
> + * of the following conditions are true:
> + * 1.CR4_PKE=1.
> + * 2.EFER_LMA=1.
> + * 3.Page is present with no reserved bit violations.
> + * 4.The access is not an instruction fetch.
> + * 5.The access is to a user page.
> + * 6.PKRU.AD=1 or
> + *  the access is a data write and PKRU.WD=1 and
> + *  either CR0.WP=1 or it is a user access.
> + */
> +if ( !hvm_pku_enabled(vcpu) ||
> + !hvm_long_mode_enabled(vcpu) ||
> + !(pfec & PFEC_page_present) ||
> + (pfec & PFEC_reserved_bit) ||
> + (pfec & PFEC_insn_fetch) ||
> + !(pte_flags & _PAGE_USER) )
> +return 0;
> +
> +pkru = read_pkru();
> +if ( unlikely(pkru) )
> +{
> +pkru_ad = read_pkru_ad(pkru, pte_pkey);
> +pkru_wd = read_pkru_wd(pkru, pte_pkey);

... (quoting my reply to v6): "Please make these the declarations
(with initializers) of those variables."

No big deal, I can fix this up while committing, but it costs time
(of which I have always too little) nevertheless.

Jan


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