Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, September 24, 2015 3:52 PM
> To: Wu, Feng
> Cc: Andrew Cooper; Dario Faggioli; George Dunlap; George Dunlap; Tian, Kevin;
> xen-devel@lists.xen.org; Keir Fraser
> Subject: RE: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core 
> logic
> handling
> 
> >>> On 24.09.15 at 03:50,  wrote:
> > One issue is the number of vmexits is far far bigger than the number of
> > context switch. I test it for a quite short time and it shows there are
> > 2910043 vmexits and 71733 context switch (only count the number in
> > __context_switch() since we only change the PI state in this function).
> > If we change the PI state in each vmexit/vmentry, I am afraid this will
> > hurt the performance.
> 
> Note that George has already asked whether the updating of the
> PI descriptor is expensive, without you answering. 

Updating the PI descriptor needs to be atomic, I think it should be a little
expensive.

> If this is basically
> just a memory or VMCS field write, I don't think it really matters in
> which code path it sits, regardless of the frequency of either path
> being used. Also note that whatever measuring you do in an area
> like this, it'll only be an example, 

I DON'T think it is just an example, the vmexit numbers is definitely
far larger than context switch.

> unlikely to be representative of anything. 

I don't think so!

> Plus with the tendency to eliminate VMEXITs with newer
> hardware, the penalty of this sitting in the VMEXIT path ought to go
> down.

Broadwell is really very new hardware, the VMEXITs and the number
of context switch is not in the same order of magnitudes.

Thanks,
Feng

> 
> Jan
> 


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

[Xen-devel] [BUG] 16 vcpus + 2 vif bridge = issue ?

[Roman Shubovich]

hi

i have physical server with 40 cpu cores
and i need to create a hvm domu with at least 16 vcpus and 2 network bridges
when i start that domu i have some not understable issue - the second
bridge has no traffic from network (works only first interface - first
declared in config file). i can see traffic with tcpdum on dom0, but not on
vif interface that has been created by domu startup script.

when i reduce number of vcpu to 15 or less then bridges works fine

system:
dom0 ubuntu 14.04.03 kernel 3.18.21
domu ubuntu 14.04.03 kernel 3.18.21
tried xen:
xen 4.4
xen 4.5
xen 4.6
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Jan Beulich]

>>> On 23.09.15 at 17:55,  wrote:
> +#define KEYHANDLER(k, f, desc, diag)\
> +[k] = { .fn = (f), (desc), 0, (diag) }
> +
> +#define IRQ_KEYHANDLER(k, f, desc, diag)\
> +[k] = { .irq_fn = (f), (desc), 1, (diag) }

Parenthesizing desc and diag is really unnecessary.

> -void register_keyhandler(unsigned char key, struct keyhandler *handler)
> +void register_keyhandler(unsigned char key, keyhandler_fn_t fn,
> + const char *desc, bool_t diagnostic)
> +{
> +BUG_ON(key >= ARRAY_SIZE(key_table)); /* Key in range? */
> +ASSERT(!key_table[key].fn);   /* Clobbering something else? */
> +
> +key_table[key] = (struct keyhandler){ .fn = fn, desc, 0, diagnostic };

This is quite odd an initializer (mixing member designators with classic
initializers), but what's worse - it won't build with old gcc.

>  static void show_handlers(unsigned char key)
>  {
> -int i;
> +unsigned int i;
>  printk("'%c' pressed -> showing installed handlers\n", key);

Please also add the blank line missing above.

> --- a/xen/drivers/passthrough/vtd/extern.h
> +++ b/xen/drivers/passthrough/vtd/extern.h
> @@ -29,7 +29,7 @@
>  
>  void print_iommu_regs(struct acpi_drhd_unit *drhd);
>  void print_vtd_entries(struct iommu *iommu, int bus, int devfn, u64 gmfn);
> -extern struct keyhandler dump_iommu_info_keyhandler;
> +void vtd_dump_iommu_info(unsigned char key);

Any reason not to use the typedef here?

> +void register_irq_keyhandler(unsigned char key,
> + irq_keyhandler_fn_t *fn,
> + const char *desc,
> + bool_t diagnostic);

I wonder whether the last parameter is really useful here.

Jan


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

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

[Andrew Cooper]

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

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

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

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

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

---

v3:
 * Fix build on older GCC
 * Extra whitespace
 * More use of function typedefs.

v2:
 * Keep {,irq_}keyhandler_t's as function typedefs
 * Adjustment of initialiser macros
 * Trim more trailing whitespace
 * Implement register_irq_keyhandler()
 * Tweak wording of some descriptions

Note: I have avoided CC'ing all maintainers as this is largely a mechanical
change across the whole codebase.  Most non-mechanical changes are in common
code, but there is a trivial externing change
xen/drivers/passthrough/vtd/extern.h as previously the struct keyhandler was
in a different translation unit to the function it referenced.
---
 xen/arch/x86/acpi/cpu_idle.c |8 +-
 xen/arch/x86/hvm/irq.c   |8 +-
 xen/arch/x86/hvm/svm/vmcb.c  |8 +-
 xen/arch/x86/hvm/vmx/vmcs.c  |8 +-
 xen/arch/x86/io_apic.c   |7 +-
 xen/arch/x86/irq.c   |8 +-
 xen/arch/x86/mm/p2m-ept.c|8 +-
 xen/arch/x86/mm/shadow/common.c  |   14 +-
 xen/arch/x86/msi.c   |8 +-
 xen/arch/x86/nmi.c   |   15 +--
 xen/arch/x86/numa.c  |8 +-
 xen/arch/x86/time.c  |8 +-
 xen/common/event_channel.c   |8 +-
 xen/common/grant_table.c |9 +-
 xen/common/kexec.c   |7 +-
 xen/common/keyhandler.c  |  214 --
 xen/common/page_alloc.c  |   16 +--
 xen/common/timer.c   |8 +-
 xen/drivers/char/console.c   |   16 +--
 xen/drivers/passthrough/amd/iommu_intr.c |9 +-
 xen/drivers/passthrough/iommu.c  |8 +-
 xen/drivers/passthrough/pci.c|8 +-
 xen/drivers/passthrough/vtd/extern.h |2 +-
 xen/drivers/passthrough/vtd/iommu.c  |2 +-
 xen/drivers/passthrough/vtd/utils.c  |8 +-
 xen/include/xen/keyhandler.h |   71 +-
 26 files changed, 152 insertions(+), 342 deletions(-)

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

Re: [Xen-devel] [PATCH v4 3/4] tools: add tools support for Intel CDP

[Ian Campbell]

On Thu, 2015-09-24 at 12:07 +0100, Ian Campbell wrote:
> @@ -8517,8 +8535,19 @@ int main_psr_cat_cbm_set(int argc, char **argv)
> >  libxl_string_list_dispose(_list);
> >  free(value);
> >  break;
> > +case 'd':
> > +type = LIBXL_PSR_CBM_TYPE_L3_DATA;
> > +opt_data = 1;
> > +break;
> > +case 'c':
> > +type = LIBXL_PSR_CBM_TYPE_L3_CODE;
> > +opt_code = 1;
> > +break;
> >  }
> >  
> > +if (opt_data && opt_code)
> 
> Do you not mean !opt_data && !opt_code?
> 
> But also, isn't this assignment unnecessary since type is initialised to
> the same value when it is declared?
> 
> In fact, because of that initialisation, aren't opt_data and opt_code
> unnecessary, since you set type appropriately elsewhere.
> 
> Are -d and -c mutually exclusive, or is it expected that both can be
> given?

Also, is there error checking for passing -c or -d when CDP is not enabled
somewhere else?

Ian.


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

Re: [Xen-devel] [PATCH for 4.6] xen/arm: vgic: Correctly emulate write when byte is used

[Ian Campbell]

On Wed, 2015-09-23 at 14:23 +0100, Wei Liu wrote:
> On Tue, Sep 22, 2015 at 09:18:48PM +0100, Julien Grall wrote:
> > When a guest is writing a byte, the value will be located in bits[7:0]
> > of the register.
> > 
> > Although the current implementation is expecting the byte at the Nth
> > byte of the register where N = address & 4;
> > 
> > When the address is not 4-byte aligned, the corresponding byte in the
> > internal state will always be set to zero rather.
> > 
> > Note that byte access are only used for GICD_IPRIORITYR and
> > GICD_ITARGETSR. So the worst things that could happen is not setting
> > the
> > priority correctly and ignore the target vCPU written.
> > 
> > Signed-off-by: Julien Grall 
> > 
> 
> Subject to an ack / review from ARM folks:
> 
> Release-acked-by: Wei Liu 

Acked + applied to staging and staging-4.6, noted for later backport to 4.5
and 4.4.


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

Re: [Xen-devel] [PATCH v7 18/28] xen/arm: ITS: Export ITS info to Virtual ITS

[Ian Campbell]

On Thu, 2015-09-24 at 12:31 +0100, Julien Grall wrote:
> Hi Ian,
> 
> On 24/09/15 09:27, Ian Campbell wrote:
> > On Thu, 2015-09-24 at 10:56 +0530, Vijay Kilari wrote:
> > 
> > > > > +
> > > > >  plpi = its_get_plpi(pdev, i);
> > > > >  /* TODO: Route lpi */
> > > > >  }
> > > > > @@ -1366,6 +1374,8 @@ static int its_probe(struct dt_device_node
> > > > > *node)
> > > > >  its->phys_size = its_size;
> > > > >  typer = readl_relaxed(its_base + GITS_TYPER);
> > > > >  its->ite_size = ((typer >> 4) & 0xf) + 1;
> > > > > +its_data.eventID_bits = GITS_TYPER_IDBITS(typer);
> > > > > +its_data.devID_bits = GITS_TYPER_DEVBITS(typer);
> > > > 
> > > > The 2 fields will be override every time a new ITS node will be
> > > > initialized.
> > > > 
> > > > What ensure that all the ITS have the same number of Event ID and
> > > > Device ID?
> > > 
> > > Nothing of I thing of ensures this at HW level.
> > 
> > The question here is about the behaviour of the software emulation.
> > 
> > >  Either we should
> > > assume that all the ITS
> > > have number of Event and Device ID or we choose lower of all the
> > > ITS?.
> > 
> > Don't we need, if anything, the highest?
> 
> It's worth mentioning that there is no generic mechanism to notify if a
> command is invalid. So passing an out of range DevID and EventID in a
> command may potentially result to crashing Xen because we receive an
> SError.
> 
> So we can use the highest value only if we have all the safety in Xen to
> prevent to send any command invalid out of range value.

Oh, I thought this was the vits (so we could make whatever we wanted work).

If this is the physical ITS thing and these values can differ between
different ITSs in a system then surely these limits need to be recorded in
a per pits location.

Ian.

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

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

[Jan Beulich]

>>> On 24.09.15 at 13:47,  wrote:
> On 24/09/15 12:46, Jan Beulich wrote:
> On 24.09.15 at 13:05,  wrote:
>>> +static struct keyhandler {
>>> +union {
>>> +keyhandler_fn_t *fn;
>>> +irq_keyhandler_fn_t *irq_fn;
>>> +};
>>> +
>>> +const char *desc;/* Description for help message. 
> */
>>> +bool_t irq_callback, /* Call in irq context? if not, tasklet context. 
> */
>>> +diagnostic;  /* Include in 'dump all' handler.
> */
>>> +} key_table[128] __read_mostly =
>>> +{
>>> +#define KEYHANDLER(k, f, desc, diag)\
>>> +[k] = { .fn = (f), desc, 0, diag }
>>> +
>>> +#define IRQ_KEYHANDLER(k, f, desc, diag)\
>>> +[k] = { .irq_fn = (f), desc, 1, diag }
>> I'm sorry for noticing only now, but I'm afraid these (looking as
>> odd - but correct - as the other ones did) won't build with older
>> gcc either.
> 
> Urgh yes.  I think we might have to just explicitly typecast the
> pointer, because .irq_fn is uninitialised in older GCC.  Would that be ok?

Yes, certainly better than re-adding the u name. Another
alternative would be a void * as the first union alternative,
but I suppose future gcc might become more strict about
conversions between function and data pointers...

Jan


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

Re: [Xen-devel] [PATCH] xen: credit1: fix tickling when it happens from a remote pCPU

[Dario Faggioli]

On Thu, 2015-09-24 at 03:29 -0600, Jan Beulich wrote:
> > > > On 24.09.15 at 06:31,  wrote:
> > --- a/xen/common/sched_credit.c
> > +++ b/xen/common/sched_credit.c

> >  #define csched_balance_mask (CSCHED_PCPU(smp_processor_id())
> > ->balance_mask)
> >  
> > +#define csched_balance_mask_cpu(c) (CSCHED_PCPU(c)->balance_mask)
> 
> csched_runq_steal() gets called with peer_cpu's runqueue lock held
> afaics, but uses smp_processor_id()'s balance_mask. I.e. it looks to
> me that what Jürgen suggested as an option is actually a requirement.
> 
And I'm very much agreeable on taking his suggestion, because I
actually like it.

Correctness should not be an issue, though. In fact, here is the story
about csched_runq_steal():

 schedule()
   cpu = smp_processor_id()
   lock = pcpu_schedule_lock_irq(cpu);
   sched = this_cpu(scheduler);
   next_slice = sched->do_schedule(sched, ...); 
|
--> csched_schedule()
  cpu = smp_processor_id();
  snext = csched_load_balance(..., cpu, ...);
peer_cpu = xxx;
lock = pcpu_schedule_trylock(peer_cpu);
speer = csched_runq_steal(peer_cpu, cpu, ...);
  csched_balance_cpumask(..., csched_balance_mask);
pcpu_schedule_unlock(lock, peer_cpu);
   pcpu_schedule_unlock_irq(lock, cpu);

So, we can safely use smp_processor_id()'s scratch space, as we own its
runqueue lock too.

In any case, thanks a lot for having a look.
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



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

Re: [Xen-devel] [PATCH] x86/boot: Move/copy sections more efficiently

[Jan Beulich]

>>> On 24.09.15 at 10:14,  wrote:
> The ALIGN(STACK_SIZE) actually belongs with .bss.stack_aligned, but
> __init_end still needs page alignment because of the init sections being
> freed and returned to the domheap after boot.

Logically that change makes sense, but ...

> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -158,11 +158,13 @@ SECTIONS
> __xsm_initcall_start = .;
> *(.xsm_initcall.init)
> __xsm_initcall_end = .;
> +
> +   . = ALIGN(PAGE_SIZE);
>} :text
> -  . = ALIGN(STACK_SIZE);
>__init_end = .;
>  
>.bss : { /* BSS */
> +   . = ALIGN(STACK_SIZE);
> __bss_start = .;
> *(.bss.stack_aligned)
> . = ALIGN(PAGE_SIZE);

... any pages between __init_end and __bss_start will all of the
sudden no longer get freed. I.e. you'll want to move __init_end
as well (which belongs inside some section anyway).

Jan


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

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

[Jan Beulich]

>>> On 24.09.15 at 12:36,  wrote:

>>> +void register_irq_keyhandler(unsigned char key,
>>> + irq_keyhandler_fn_t *fn,
>>> + const char *desc,
>>> + bool_t diagnostic);
>> I wonder whether the last parameter is really useful here.
> 
> Yes.  There are diagnostic irq_keyhandlers, 'd' for example.

I know; I was wondering if we would ever reasonably gain ones
outside of keyhandler.c.

Jan


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

Re: [Xen-devel] [PATCH for-4.6] p2m/ept: Set the A bit only if PML is enabled

[Wei Liu]

On Thu, Sep 24, 2015 at 11:45:00AM +0100, Wei Liu wrote:
> On Thu, Sep 24, 2015 at 03:33:18AM -0600, Jan Beulich wrote:
> > >>> On 24.09.15 at 11:10,  wrote:
> > > At 01:02 -0600 on 24 Sep (1443056566), Jan Beulich wrote:
> > >> --- a/xen/arch/x86/mm/p2m-ept.c
> > >> +++ b/xen/arch/x86/mm/p2m-ept.c
> > >> @@ -130,14 +130,18 @@ static void ept_p2m_type_to_flags(struct 
> > >> p2m_domain *p2m, ept_entry_t *entry,
> > >>  break;
> > >>  case p2m_ram_rw:
> > >>  entry->r = entry->w = entry->x = 1;
> > >> -entry->a = entry->d = 1;
> > >> +entry->a = entry->d = cpu_has_ept_ad;
> > >>  break;
> > >>  case p2m_mmio_direct:
> > >>  entry->r = entry->x = 1;
> > >>  entry->w = !rangeset_contains_singleton(mmio_ro_ranges,
> > >>  entry->mfn);
> > >> -entry->a = 1;
> > >> -entry->d = entry->w;
> > >> +entry->a = cpu_has_ept_ad;
> > >> +entry->d = entry->w && cpu_has_ept_ad;
> > >>  break;
> > >>  case p2m_ram_logdirty:
> > >>  entry->r = entry->x = 1;
> > >> 
> > > 
> > > Sure, that works.  I still prefer putting the workaround on the CR3
> > > operation, so all the cost happens on the broken chip, but I'll shut
> > > up about that now. :)
> > 
> > And I agree to that for post-4.6. For 4.6 the easier to validate
> > fix still would seem to be a variation of what Ross posted.
> > 
> 
> I just finished this thread. Looks like HV maintainers have devised a
> plan for this issue.
> 
> Thank you all.

I forgot to mention should a patch appear please apply as you see fit.

Wei.

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

Re: [Xen-devel] [PATCH v4 3/4] tools: add tools support for Intel CDP

[Ian Campbell]

On Thu, 2015-09-17 at 17:35 +0800, He Chen wrote:
> diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c
> index 3378239..62963cf 100644
> --- a/tools/libxl/libxl_psr.c
> +++ b/tools/libxl/libxl_psr.c
> @@ -87,6 +87,9 @@ static void libxl__psr_cat_log_err_msg(libxl__gc *gc,
> int err)
>  case EEXIST:
>  msg = "The same CBM is already set to this domain";
>  break;
> +case EINVAL:
> +msg = "Unable to set code or data CBM when CDP is disabled";
> +break;

These overloading of the errno values are getting a bit thinly stretched.
The more so that EINVAL has a widely used more generic meaning.

Hypervisor maintainers, what is your opinion of this?

Since this is a sysctl I suppose we could consider adding a new PSR
specific error type with appropriate codes?


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

Re: [Xen-devel] [PATCH] Add missing license and copyright statements to public interface headers.

[Ian Campbell]

On Tue, 2015-09-22 at 16:02 +0200, Mike Belopuhov wrote:
> The copyright line indicates a person, a group of people and/or a company
> granting rights stated in the license text and is a required part of the
> license.
> 
> The year of the copyright is chosen to be the same as when the license has
> been applied to the file or when the file has been created in case there
> was no license.  It is possible to update or add additional years if major
> changes have been done to the the file, but is generally not a requirement.
> 
> Signed-off-by: Mike Belopuhov 

LGTM, thanks. I'll wait for Konrad and/or Boris to confirm that Oracle are
happy with this wording etc. Keir's one matches all his others so I think
we can assume it is ok unless we hear otherwise.

Wei, I can't think of a reason not to include this in 4.6, does that work
for you?

> ---
>  xen/include/public/arch-x86/pmu.h   | 22 ++
>  xen/include/public/hvm/e820.h   |  3 ++-
>  xen/include/public/hvm/hvm_info_table.h |  2 ++
>  xen/include/public/hvm/hvm_op.h |  2 ++
>  xen/include/public/hvm/hvm_xs_strings.h |  2 ++
>  xen/include/public/hvm/params.h |  2 ++
>  xen/include/public/io/protocols.h   |  2 ++
>  xen/include/public/physdev.h|  2 ++
>  xen/include/public/pmu.h| 22 ++
>  9 files changed, 58 insertions(+), 1 deletion(-)
> 
> diff --git xen/include/public/arch-x86/pmu.h xen/include/public/arch
> -x86/pmu.h
> index 1a53888..68ebf12 100644
> --- xen/include/public/arch-x86/pmu.h
> +++ xen/include/public/arch-x86/pmu.h
> @@ -1,5 +1,27 @@
> +/*
> + * Permission is hereby granted, free of charge, to any person obtaining
> a copy
> + * of this software and associated documentation files (the "Software"),
> to
> + * deal in the Software without restriction, including without
> limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense,
> and/or
> + * sell copies of the Software, and to permit persons to whom the
> Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
> SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Copyright (c) 2015 Oracle and/or its affiliates. All rights reserved.
> + */
> +
>  #ifndef __XEN_PUBLIC_ARCH_X86_PMU_H__
>  #define __XEN_PUBLIC_ARCH_X86_PMU_H__
>  
>  /* x86-specific PMU definitions */
>  
> diff --git xen/include/public/hvm/e820.h xen/include/public/hvm/e820.h
> index 5bdc227..6c58a37 100644
> --- xen/include/public/hvm/e820.h
> +++ xen/include/public/hvm/e820.h
> @@ -1,6 +1,5 @@
> -
>  /*
>   * Permission is hereby granted, free of charge, to any person obtaining
> a copy
>   * of this software and associated documentation files (the "Software"),
> to
>   * deal in the Software without restriction, including without
> limitation the
>   * rights to use, copy, modify, merge, publish, distribute, sublicense,
> and/or
> @@ -15,10 +14,12 @@
>   * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
> SHALL THE
>   * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
>   * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> ARISING
>   * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>   * DEALINGS IN THE SOFTWARE.
> + *
> + * Copyright (c) 2006, Keir Fraser
>   */
>  
>  #ifndef __XEN_PUBLIC_HVM_E820_H__
>  #define __XEN_PUBLIC_HVM_E820_H__
>  
> diff --git xen/include/public/hvm/hvm_info_table.h
> xen/include/public/hvm/hvm_info_table.h
> index 36085fa..9e3f807 100644
> --- xen/include/public/hvm/hvm_info_table.h
> +++ xen/include/public/hvm/hvm_info_table.h
> @@ -18,10 +18,12 @@
>   * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
> SHALL THE
>   * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
>   * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> ARISING
>   * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>   * DEALINGS IN THE SOFTWARE.
> + *
> + * Copyright (c) 2006, Keir Fraser
>   */
>  
>  #ifndef __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__
>  #define __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__
>  
> diff --git xen/include/public/hvm/hvm_op.h
> xen/include/public/hvm/hvm_op.h
> index 014546a..1606185 100644
> --- xen/include/public/hvm/hvm_op.h
> +++ xen/include/public/hvm/hvm_op.h

Re: [Xen-devel] [PATCH v4 3/4] tools: add tools support for Intel CDP

[Ian Campbell]

On Thu, 2015-09-17 at 11:38 +0100, Andrew Cooper wrote:
> @@ -320,6 +333,8 @@ int xc_psr_cat_get_l3_info(xc_interface *xch,
> > uint32_t socket,
> >  {
> >  *cos_max = sysctl.u.psr_cat_op.u.l3_info.cos_max;
> >  *cbm_len = sysctl.u.psr_cat_op.u.l3_info.cbm_len;
> > +*cdp_enabled = sysctl.u.psr_cat_op.u.l3_info.flags &
> > +   XEN_SYSCTL_PSR_CAT_L3_CDP;
> 
> !!(sysctl.u.psr_cat_op.u.l3_info.flags & XEN_SYSCTL_PSR_CAT_L3_CDP);
> 
> To turn it into a proper boolean, rather than a just a non-zero integer.

Given that *cdp_endabled is bool type does this not happen automagically?


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

Re: [Xen-devel] [PATCH v4 3/4] tools: add tools support for Intel CDP

[Ian Campbell]

On Thu, 2015-09-17 at 11:38 +0100, Andrew Cooper wrote:
> On 17/09/15 10:35, He Chen wrote:
> > @@ -2798,7 +2798,9 @@ enum xc_psr_cmt_type {
> >  typedef enum xc_psr_cmt_type xc_psr_cmt_type;
> >  
> >  enum xc_psr_cat_type {
> > -XC_PSR_CAT_L3_CBM = 1,
> > +XC_PSR_CAT_L3_CBM  = 1,
> > +XC_PSR_CAT_L3_CODE = 2,
> > +XC_PSR_CAT_L3_DATA = 3,
> >  };
> 
> No need for the explicit assignments here.  The exact values are not
> interesting and guaranteed to be as currently assigned.

No harm though I suppose.

> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index ebbb9a5..8128f54 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -8390,6 +8390,10 @@ static int psr_cat_hwinfo(void)
> >  }
> >  printf("%-16s: %u\n", "Socket ID", socketid);
> >  printf("%-16s: %uKB\n", "L3 Cache", l3_cache_size);
> > +if (info->cdp_enabled)
> > +printf("%-16s: Enabled\n", "CDP Status");
> > +else
> > +printf("%-16s: Disabled\n", "CDP Status");
> 
> printf("%-16s: %sabled\n", "CDP Status", info->cdp_enabled ? "En" :
> "Dis");
> 
> is rather shorter, if you prefer.

My preference would be along these lines but without the trick regarding
the common suffix on both words, i.e.

printf("%-16s: %s\n", "CDP Status",
   info->cdp_enabled ? "Enabled" : "Disabled");

As well as avoiding splitting the words this avoids duplicating the %-16s
and "CDP Status" compared with the original, which IMHO is the important
thing.

Ian.


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

Re: [Xen-devel] [PATCH for-4.6] p2m/ept: Set the A bit only if PML is enabled

[Wei Liu]

On Thu, Sep 24, 2015 at 03:33:18AM -0600, Jan Beulich wrote:
> >>> On 24.09.15 at 11:10,  wrote:
> > At 01:02 -0600 on 24 Sep (1443056566), Jan Beulich wrote:
> >> --- a/xen/arch/x86/mm/p2m-ept.c
> >> +++ b/xen/arch/x86/mm/p2m-ept.c
> >> @@ -130,14 +130,18 @@ static void ept_p2m_type_to_flags(struct p2m_domain 
> >> *p2m, ept_entry_t *entry,
> >>  break;
> >>  case p2m_ram_rw:
> >>  entry->r = entry->w = entry->x = 1;
> >> -entry->a = entry->d = 1;
> >> +entry->a = entry->d = cpu_has_ept_ad;
> >>  break;
> >>  case p2m_mmio_direct:
> >>  entry->r = entry->x = 1;
> >>  entry->w = !rangeset_contains_singleton(mmio_ro_ranges,
> >>  entry->mfn);
> >> -entry->a = 1;
> >> -entry->d = entry->w;
> >> +entry->a = cpu_has_ept_ad;
> >> +entry->d = entry->w && cpu_has_ept_ad;
> >>  break;
> >>  case p2m_ram_logdirty:
> >>  entry->r = entry->x = 1;
> >> 
> > 
> > Sure, that works.  I still prefer putting the workaround on the CR3
> > operation, so all the cost happens on the broken chip, but I'll shut
> > up about that now. :)
> 
> And I agree to that for post-4.6. For 4.6 the easier to validate
> fix still would seem to be a variation of what Ross posted.
> 

I just finished this thread. Looks like HV maintainers have devised a
plan for this issue.

Thank you all.

Wei.

> Jan

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

Re: [Xen-devel] [PATCH v7 17/28] xen/arm: ITS: Add GITS registers emulation

[Julien Grall]

On 24/09/15 06:07, Vijay Kilari wrote:
> On Tue, Sep 22, 2015 at 8:00 PM, Julien Grall  wrote:
>> Hi Vijay,
>>
>> On 18/09/15 14:09, vijay.kil...@gmail.com wrote:
> [...]
>>> +case 0x0010 ... 0x007c:
>>> +case 0xc000 ... 0xffcc:
>>> +/* Implementation defined -- write ignored */
>>> +goto write_ignore;
>>> +case GITS_CBASER:
>>> +/* XXX: support 32-bit access */
>>
>> You haven't asked my question on v6... What is missing to support 32-bt
>> support? AFAICT the register helpers should the job for you. Correct?
> 
>GITS_CBASER.Physical Address holds bits[47:12], Being at
> physical address at bits [47:12]  cannot be updated with single 32-bit access.

I'd like you to explain why GITS_CBASER can't be updated with single
32-bit access. Because, based on the spec it's possible (see 8.19.2 ARM
IHI 0069A):

"Bits [63:32] and bits [31:0] are accessible separately."

> I remember we discussed this on chat.

If you are mentioning the chat we had back in June, this was based on
the hardware spec (PRD03-GENC-009432 23.0) where the support of 32-bit
access wasn't not clearly mandatory.

Although, we had multiple discussion after by the mail with you saying
that 32-bit access should be supported based on the developer spec (IHI
0069A 8.1.3).

After this discussion, you've implemented the 32-bit access on some
register, but left some unintended. A month ago, I provided to you a
patch series which introduce helpers to handle any size access on
register...

While Linux is mostly using 64-bit access on 64-bit register (expect for
GITS_TYPER where there is one 32-bit access), other OS may decide to use
32-bit access because they may want to support GICv3 on aarch32.

We did the mistake to left some access size not implemented on GICv3
which lead to FreeBSD crashing when booting as a Xen guest with GICv3.
We should avoid to reproduce knowingly the same mistake for the ITS.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v4 3/4] tools: add tools support for Intel CDP

[Ian Campbell]

On Thu, 2015-09-17 at 17:35 +0800, He Chen wrote:
> @@ -8410,20 +8415,29 @@ static void psr_cat_print_one_domain_cbm(uint32_t
> domid, uint32_t socketid)
>  printf("%5d%25s", domid, domain_name);
>  free(domain_name);
>  
> -if (!libxl_psr_cat_get_cbm(ctx, domid, LIBXL_PSR_CBM_TYPE_L3_CBM,
> -   socketid, ))
> - printf("%#16"PRIx64, cbm);
> -
> +if (!cdp_enabled) {
> +if (!libxl_psr_cat_get_cbm(ctx, domid, LIBXL_PSR_CBM_TYPE_L3_CBM,
> +   socketid, ))
> +printf("%#16"PRIx64, cbm);
> +} else {
> +if (!libxl_psr_cat_get_cbm(ctx, domid, LIBXL_PSR_CBM_TYPE_L3_CODE,
> +   socketid, ))
> +printf("%10s%#8"PRIx64, "code:", cbm);
> +if (!libxl_psr_cat_get_cbm(ctx, domid, LIBXL_PSR_CBM_TYPE_L3_DATA,
> +   socketid, ))
> +printf("%10s%#8"PRIx64, "data:", cbm);
> +}

Does cdp being enabled mean that the original L3_CBM functionality is no
longer available then?

Please could you give an example of the new output format for this command
in the commit message.

>  static int psr_cat_show(uint32_t domid)
> @@ -8489,6 +8503,8 @@ int main_psr_cat_cbm_set(int argc, char **argv)
>  libxl_psr_cbm_type type = LIBXL_PSR_CBM_TYPE_L3_CBM;
>  uint64_t cbm;
>  int ret, opt = 0;
> +int opt_data = 0;
> +int opt_code = 0;
>  libxl_bitmap target_map;
>  char *value;
>  libxl_string_list socket_list;
> 
> [...]

> @@ -8517,8 +8535,19 @@ int main_psr_cat_cbm_set(int argc, char **argv)
>  libxl_string_list_dispose(_list);
>  free(value);
>  break;
> +case 'd':
> +type = LIBXL_PSR_CBM_TYPE_L3_DATA;
> +opt_data = 1;
> +break;
> +case 'c':
> +type = LIBXL_PSR_CBM_TYPE_L3_CODE;
> +opt_code = 1;
> +break;
>  }
>  
> +if (opt_data && opt_code)

Do you not mean !opt_data && !opt_code?

But also, isn't this assignment unnecessary since type is initialised to
the same value when it is declared?

In fact, because of that initialisation, aren't opt_data and opt_code
unnecessary, since you set type appropriately elsewhere.

Are -d and -c mutually exclusive, or is it expected that both can be given?


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

Re: [Xen-devel] [PATCH v7 18/28] xen/arm: ITS: Export ITS info to Virtual ITS

[Julien Grall]

Hi Ian,

On 24/09/15 09:27, Ian Campbell wrote:
> On Thu, 2015-09-24 at 10:56 +0530, Vijay Kilari wrote:
> 
 +
  plpi = its_get_plpi(pdev, i);
  /* TODO: Route lpi */
  }
 @@ -1366,6 +1374,8 @@ static int its_probe(struct dt_device_node
 *node)
  its->phys_size = its_size;
  typer = readl_relaxed(its_base + GITS_TYPER);
  its->ite_size = ((typer >> 4) & 0xf) + 1;
 +its_data.eventID_bits = GITS_TYPER_IDBITS(typer);
 +its_data.devID_bits = GITS_TYPER_DEVBITS(typer);
>>>
>>> The 2 fields will be override every time a new ITS node will be
>>> initialized.
>>>
>>> What ensure that all the ITS have the same number of Event ID and
>>> Device ID?
>>
>> Nothing of I thing of ensures this at HW level.
> 
> The question here is about the behaviour of the software emulation.
> 
>>  Either we should
>> assume that all the ITS
>> have number of Event and Device ID or we choose lower of all the ITS?.
> 
> Don't we need, if anything, the highest?

It's worth mentioning that there is no generic mechanism to notify if a
command is invalid. So passing an out of range DevID and EventID in a
command may potentially result to crashing Xen because we receive an SError.

So we can use the highest value only if we have all the safety in Xen to
prevent to send any command invalid out of range value.

Regards,

-- 
Julien Grall

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

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

[Ian Campbell]

On Tue, 2015-09-15 at 12:19 +0100, Julien Grall wrote:
> On 15/09/15 12:15, Ian Campbell wrote:
> > On Tue, 2015-09-15 at 12:02 +0100, Julien Grall wrote:
> > > What about:
> > > 
> > > "The GICv4 is an extension of GICv3 (see 1.1 in ARM IHI 0069A) which
> > > means that the GICv3 driver can run normally on a GICv4 hardware.
> > > 
> > > Though, the GICv4-only feature won't be used."
> > 
> > I've a few grammatical quibbles, plus I think s/reporting/supporting/
> > in
> > the title.
> > 
> > So how about:
> > 
> > Subject: xen/arm: gic-v3: Allow Xen to run on hardware supporting GICv4
> > 
> > GICv4 is an extension of GICv3 (see 1.1 in ARM IHI 0069A) which means
> > that
> > the GICv3 driver can run normally on GICv4 hardware.
> > 
> > The GICv4-only features currently won't be used.
> > 
> > S-o-b: etc
> 
> I'm fine with this commit message.

Applied both to staging, thanks.


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

Re: [Xen-devel] Regression in RMRRs identity mapping for PVH Dom0

[Elena Ufimtseva]

On Thu, Sep 24, 2015 at 11:29:54AM +0100, Wei Liu wrote:
> Hi Elena
> 
> On Wed, Sep 23, 2015 at 11:56:12AM -0400, Elena Ufimtseva wrote:
> > Hi  
> > 
> > 
> > 
> > There is a regression in RMRR patch 
> > 5ae03990c120a7b3067a52d9784c9aa72c0705a6 in
> > new set_identity_p2m_entry. RMRRs are not being mapped in IOMMU for PVH 
> > Dom0.
> > This causes pages faults and some long 'hang-like' delays during boot and
> > device assignments.
> > 
> > 
> > During construct_dom0, in PVH path  p2m is being constructed and identity 
> > mapped
> > in IOMMU. The p2m type is p2m_mmio_direct and p2m access p2m_rwx.
> > New code used to map RMRRs invoked from rmrr_identity_mapping   
> > 
> > checks if p2m entry exists with same type and access and if yes, skips iommu
> > mapping. Since there are p2m entries for pvh dom0 iomem, RMRRs are not being
> > mapped in IOMMU.
> > 
> > 
> > This debug patch attached fixes this and Ill be glad to see if there is a 
> > more elegant fix.
> > 
> > 
> 
> From a release point of view, PVH Dom0 is not officially supported so I
> don't consider this issue a blocker.
> 
Understand.

> We can backport the proper fix to 4.6.1 if necessary, but I doubt this
> is the only fix we need to make PVH Dom0 work on 4.6. Am I right?

Dom0 PVH boots with some glitches on Intel platforms and with some others on
AMD and it will see for sure more patches. But this problem will
make Dom0 on some Intel platforms to hang, throw page faults or may not be able
to boot at all (as I have seend that happening for some devices when
doing work on extra RMRRs).
> 
> Wei.

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

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

[Andrew Cooper]

On 24/09/15 12:46, Jan Beulich wrote:
 On 24.09.15 at 13:05,  wrote:
>> +static struct keyhandler {
>> +union {
>> +keyhandler_fn_t *fn;
>> +irq_keyhandler_fn_t *irq_fn;
>> +};
>> +
>> +const char *desc;/* Description for help message. */
>> +bool_t irq_callback, /* Call in irq context? if not, tasklet context. */
>> +diagnostic;  /* Include in 'dump all' handler.*/
>> +} key_table[128] __read_mostly =
>> +{
>> +#define KEYHANDLER(k, f, desc, diag)\
>> +[k] = { .fn = (f), desc, 0, diag }
>> +
>> +#define IRQ_KEYHANDLER(k, f, desc, diag)\
>> +[k] = { .irq_fn = (f), desc, 1, diag }
> I'm sorry for noticing only now, but I'm afraid these (looking as
> odd - but correct - as the other ones did) won't build with older
> gcc either.

Urgh yes.  I think we might have to just explicitly typecast the
pointer, because .irq_fn is uninitialised in older GCC.  Would that be ok?

~Andrew

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

Re: [Xen-devel] [PATCH v7 20/28] xen/arm: ITS: Add virtual ITS availability check helper

[Julien Grall]

On 24/09/15 07:44, Vijay Kilari wrote:
> On Wed, Sep 23, 2015 at 2:22 PM, Julien Grall  wrote:
>> Hi Vijay,
>>
>> On 18/09/15 14:09, vijay.kil...@gmail.com wrote:
>>> From: Vijaya Kumar K 
>>>
>>> Introduce vgic_is_lpi_supported() helper function
>>> to know virtual ITS availability for a domain
>>>
>>> Signed-off-by: Vijaya Kumar K 
>>> ---
>>> v7: - its_enabled field is added to vgic structure
>>> ---
> [...]
>>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>>> index a5ab99d9..3555833 100644
>>> --- a/xen/arch/arm/vgic.c
>>> +++ b/xen/arch/arm/vgic.c
>>> @@ -62,6 +62,11 @@ struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, 
>>> unsigned int irq)
>>>  return vgic_get_rank(v, rank);
>>>  }
>>>
>>> +bool_t vgic_is_lpi_supported(struct domain *d)
>>> +{
>>> +return d->arch.vgic.its_enabled;
>>> +}
>>
>> Please move this helper as a static inline to allow the compiler
>> inlining the code.
>>
> 
>   This function is used in vgic-v3.c later. Hence this function is exported.

I though you knew that a static inline function can live in the header...

> 
>>> +
>>>  static void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
>>>  {
>>>  INIT_LIST_HEAD(>inflight);
>>> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
>>> index 011f85b..0f6f9d8 100644
>>> --- a/xen/include/asm-arm/domain.h
>>> +++ b/xen/include/asm-arm/domain.h
>>> @@ -93,6 +93,7 @@ struct arch_domain
>>>  int ctlr;
>>>  int nr_spis; /* Number of SPIs */
>>>  int nr_lpis; /* Number of LPIs */
>>> +bool_t its_enabled;
>>
>> The field is GICv3 specific and should go within the HAS_GICV3 section
>> below.
>>
>> Although, I don't think having this boolean is necessary. You can know
>> whether we support LPIs or not by checking either the nr_lpis > 0 or
>> vits != NULL.
>>
>> The former would be the best if you plan to keep an helper.
> 
> I will drop its_enabled field and helper will be updated as below.
> 
> bool_t vgic_is_lpi_supported(struct domain *d)
> {
> return (d->arch.vgic.nr_lpis != 0);
> }

+ static inline and move in the header.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH for-4.6] p2m/ept: Set the A bit only if PML is enabled

[Jan Beulich]

>>> On 24.09.15 at 11:10,  wrote:
> At 01:02 -0600 on 24 Sep (1443056566), Jan Beulich wrote:
>> --- a/xen/arch/x86/mm/p2m-ept.c
>> +++ b/xen/arch/x86/mm/p2m-ept.c
>> @@ -130,14 +130,18 @@ static void ept_p2m_type_to_flags(struct p2m_domain 
>> *p2m, ept_entry_t *entry,
>>  break;
>>  case p2m_ram_rw:
>>  entry->r = entry->w = entry->x = 1;
>> -entry->a = entry->d = 1;
>> +entry->a = entry->d = cpu_has_ept_ad;
>>  break;
>>  case p2m_mmio_direct:
>>  entry->r = entry->x = 1;
>>  entry->w = !rangeset_contains_singleton(mmio_ro_ranges,
>>  entry->mfn);
>> -entry->a = 1;
>> -entry->d = entry->w;
>> +entry->a = cpu_has_ept_ad;
>> +entry->d = entry->w && cpu_has_ept_ad;
>>  break;
>>  case p2m_ram_logdirty:
>>  entry->r = entry->x = 1;
>> 
> 
> Sure, that works.  I still prefer putting the workaround on the CR3
> operation, so all the cost happens on the broken chip, but I'll shut
> up about that now. :)

And I agree to that for post-4.6. For 4.6 the easier to validate
fix still would seem to be a variation of what Ross posted.

Jan


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

[Xen-devel] [xen-4.0-testing baseline-only test] 38026: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 38026 xen-4.0-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38026/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-rumpuserxen1 build-check(1)   blocked  n/a
 build-amd64-rumpuserxen   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-raw   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-i386-i386-xl 1 build-check(1)   blocked  n/a
 test-i386-i386-xl-winxpsp31 build-check(1)   blocked  n/a
 test-i386-i386-xl-credit2 1 build-check(1)   blocked  n/a
 test-i386-i386-xl-qcow2   1 build-check(1)   blocked  n/a
 test-i386-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-i386-i386-pv 1 build-check(1)   blocked  n/a
 test-i386-i386-xl-raw 1 build-check(1)   blocked  n/a
 test-i386-i386-xl-vhd 1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-i386-i386-xl-multivcpu   1 build-check(1)   blocked  n/a
 test-i386-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)   blocked  n/a
 test-i386-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-raw   1 build-check(1)   blocked  n/a
 test-i386-i386-libvirt-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-freebsd10-i386  1 build-check(1) blocked n/a
 test-i386-i386-libvirt-vhd1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-freebsd10-amd64  1 build-check(1)blocked n/a
 test-i386-i386-pair   1 build-check(1)   blocked  n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 build-check(1)  blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-vhd1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 build-check(1)   blocked  n/a
 test-i386-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 

Re: [Xen-devel] Regression in RMRRs identity mapping for PVH Dom0

[Jan Beulich]

>>> On 24.09.15 at 11:18,  wrote:
> AIUI the problem is that before the call to set_identity_p2m_entry(),
> PVH dom0 has a p2m entry covering this range but no IOMMU entry.  Is
> that right?  So the fix will be to make PVH dom0 construction set up
> the IOMMU correctly when it sets up the p2m.

Right, but with the current way of setting up PVH Dom0 I'm afraid
this will be rather intrusive to implement. Hence, however much I
dislike it, I wonder whether a variant of Elena's change (suitably
annotated with a phv fixme) wouldn't be a reasonable thing for 4.6.
With the switch to HVMlite the Dom0 setup will need to be re-done
anyway afaics.

Elena, as to the actual patch:

>--- a/xen/arch/x86/mm/p2m.c
>+++ b/xen/arch/x86/mm/p2m.c
>@@ -970,8 +970,10 @@ int set_identity_p2m_entry(struct domain *d, unsigned 
>long gfn,
> if ( p2mt == p2m_invalid || p2mt == p2m_mmio_dm )
> ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
> p2m_mmio_direct, p2ma);
>-else if ( mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct && a == p2ma )
>-ret = 0;
>+else if ( mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct )
>+if ( a == p2ma && !is_pvh_domain(d) )
>+ret = 0;
>+else ret = iommu_map_page(d, gfn, gfn, 
>IOMMUF_readable|IOMMUF_writable);

Besides this wanting figure braces, why do you pull the a == p2ma
check into the inner if()? If this is because of the P2M getting
populated with p2m_rwx, I think _that_ should be changed rather
than breaking the logic here (or, if done properly, complicating it).
There's no reason I can see to map MMIO regions rwx.

Also I think this wants to cover just hwdom and !iommu_use_hap_pt.

Jan

> else
> {
> if ( flag & XEN_DOMCTL_DEV_RDM_RELAXED )



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

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

[Andrew Cooper]

+void register_irq_keyhandler(unsigned char key,
+ irq_keyhandler_fn_t *fn,
+ const char *desc,
+ bool_t diagnostic);

I wonder whether the last parameter is really useful here.


Yes.  There are diagnostic irq_keyhandlers, 'd' for example.

All callers in practice will be __init, so overhead is not interesting, 
and it should be present for completeness.


~Andrew

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

Re: [Xen-devel] Regression in RMRRs identity mapping for PVH Dom0

[Elena Ufimtseva]

On Thu, Sep 24, 2015 at 04:31:09AM -0600, Jan Beulich wrote:
> >>> On 24.09.15 at 11:18,  wrote:
> > AIUI the problem is that before the call to set_identity_p2m_entry(),
> > PVH dom0 has a p2m entry covering this range but no IOMMU entry.  Is
> > that right?  So the fix will be to make PVH dom0 construction set up
> > the IOMMU correctly when it sets up the p2m.
> 
> Right, but with the current way of setting up PVH Dom0 I'm afraid
> this will be rather intrusive to implement. Hence, however much I
> dislike it, I wonder whether a variant of Elena's change (suitably
> annotated with a phv fixme) wouldn't be a reasonable thing for 4.6.
> With the switch to HVMlite the Dom0 setup will need to be re-done
> anyway afaics.

I agree here Jan. The PVH Dom0 up page tables is a sort of special case
on its own. And me, Andrew Cooper and Konrad talked about changing it,
but I have not yet started working on it yet, but I think its in my
plan.

> 
> Elena, as to the actual patch:
> 
> >--- a/xen/arch/x86/mm/p2m.c
> >+++ b/xen/arch/x86/mm/p2m.c
> >@@ -970,8 +970,10 @@ int set_identity_p2m_entry(struct domain *d, unsigned 
> >long gfn,
> > if ( p2mt == p2m_invalid || p2mt == p2m_mmio_dm )
> > ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
> > p2m_mmio_direct, p2ma);
> >-else if ( mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct && a == p2ma )
> >-ret = 0;
> >+else if ( mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct )
> >+if ( a == p2ma && !is_pvh_domain(d) )
> >+ret = 0;
> >+else ret = iommu_map_page(d, gfn, gfn, 
> >IOMMUF_readable|IOMMUF_writable);
> 
> Besides this wanting figure braces, why do you pull the a == p2ma
> check into the inner if()? If this is because of the P2M getting
> populated with p2m_rwx, I think _that_ should be changed rather
> than breaking the logic here (or, if done properly, complicating it).
> There's no reason I can see to map MMIO regions rwx.

Yes, that is why I did it, because of rwx. I will modify it. 
> 
> Also I think this wants to cover just hwdom and !iommu_use_hap_pt.

Yes, forgot about this one.
> 
> Jan
> 
> > else
> > {
> > if ( flag & XEN_DOMCTL_DEV_RDM_RELAXED )
> 
> 

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

Re: [Xen-devel] [PATCH v7 17/28] xen/arm: ITS: Add GITS registers emulation

[Ian Campbell]

On Thu, 2015-09-24 at 12:05 +0100, Julien Grall wrote:
> On 24/09/15 06:07, Vijay Kilari wrote:
> > On Tue, Sep 22, 2015 at 8:00 PM, Julien Grall 
> > wrote:
> > > Hi Vijay,
> > > 
> > > On 18/09/15 14:09, vijay.kil...@gmail.com wrote:
> > [...]
> > > > +case 0x0010 ... 0x007c:
> > > > +case 0xc000 ... 0xffcc:
> > > > +/* Implementation defined -- write ignored */
> > > > +goto write_ignore;
> > > > +case GITS_CBASER:
> > > > +/* XXX: support 32-bit access */
> > > 
> > > You haven't asked my question on v6... What is missing to support 32
> > > -bt
> > > support? AFAICT the register helpers should the job for you. Correct?
> > 
> >GITS_CBASER.Physical Address holds bits[47:12], Being at
> > physical address at bits [47:12]  cannot be updated with single 32-bit
> > access.
> 
> I'd like you to explain why GITS_CBASER can't be updated with single
> 32-bit access. Because, based on the spec it's possible (see 8.19.2 ARM
> IHI 0069A):
> 
> "Bits [63:32] and bits [31:0] are accessible separately."

You clearly can't update the entire 47:12 range atomically with a 32-bit
access, which I suppose is what Vijay means.

However, I don't see why it wouldn't be possible to update either bits
[47:32] or [31:12] independently, by modifying just those bits. If for some
reason an OS wanted to do so.

More plausibly an OS might want to change some of the flag bits outside of
the [47:12] range, on either end with a single 32-bit write to just the
half they are trying to change. Writing just [63:32] to flip the valid bit
seems pretty plausible OS behaviour.

> Ian

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

Re: [Xen-devel] [PATCH v2 for-4.6 0/2] libxl: devd fixes

[Ian Campbell]

On Wed, 2015-09-23 at 16:21 +0100, Wei Liu wrote:

> Release-acked-by: Wei Liu 

Both patches applied to staging and staging-4.6.



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

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

[Ian Campbell]

On Wed, 2015-09-23 at 14:21 +0100, Wei Liu wrote:
> On Mon, Sep 21, 2015 at 11:57:34AM +0200, Vitaly Kuznetsov wrote:
> > Use existing create/restore path to perform 'soft reset' for HVM
> > domains. Tear everything down, e.g. destroy domain's device model,
> > remove the domain from xenstore, save toolstack record and start
> > over.
> > 
> > Signed-off-by: Vitaly Kuznetsov 
> 
> Acked-by: Wei Liu 

Applied to staging.


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

Re: [Xen-devel] [PATCH v7 17/28] xen/arm: ITS: Add GITS registers emulation

[Julien Grall]

On 24/09/15 12:29, Ian Campbell wrote:
> On Thu, 2015-09-24 at 12:05 +0100, Julien Grall wrote:
>> On 24/09/15 06:07, Vijay Kilari wrote:
>>> On Tue, Sep 22, 2015 at 8:00 PM, Julien Grall 
>>> wrote:
 Hi Vijay,

 On 18/09/15 14:09, vijay.kil...@gmail.com wrote:
>>> [...]
> +case 0x0010 ... 0x007c:
> +case 0xc000 ... 0xffcc:
> +/* Implementation defined -- write ignored */
> +goto write_ignore;
> +case GITS_CBASER:
> +/* XXX: support 32-bit access */

 You haven't asked my question on v6... What is missing to support 32
 -bt
 support? AFAICT the register helpers should the job for you. Correct?
>>>
>>>GITS_CBASER.Physical Address holds bits[47:12], Being at
>>> physical address at bits [47:12]  cannot be updated with single 32-bit
>>> access.
>>
>> I'd like you to explain why GITS_CBASER can't be updated with single
>> 32-bit access. Because, based on the spec it's possible (see 8.19.2 ARM
>> IHI 0069A):
>>
>> "Bits [63:32] and bits [31:0] are accessible separately."
> 
> You clearly can't update the entire 47:12 range atomically with a 32-bit
> access, which I suppose is what Vijay means.

The GITS_CBASER holds when address of the command queue which can only
be used when the ITS is enabled (i.e GITS_CTLR.Enable = 1).

As soon as GITS_CTLR.enable is set, it's not possible GITS_CBASER
becomes read-only. So we don't care about atomic access.

Although, the main problem is how the emulation for this register has
been written. As soon as the register is written, we are validating the
fields in the register and store in a convenient way. This give us
little possibility to correctly support 32-bit access.

Given that the register value is never used until GITS_CTLR.enable is
set, we could have validating GITS_CBASER and update our internal state
directly in GITS_CTLR.

Note that this remark is valid for any register relyiong on
GITS_CTLR.Enable and GICR_CTLR.Enable.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH] xen: credit1: fix tickling when it happens from a remote pCPU

[Jan Beulich]

>>> On 24.09.15 at 06:31,  wrote:
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -168,14 +168,16 @@ struct csched_pcpu {
>  };
>  
>  /*
> - * Convenience macro for accessing the per-PCPU cpumask we need for
> + * Convenience macros for accessing the per-PCPU cpumask we need for
>   * implementing the two steps (soft and hard affinity) balancing logic.
>   * It is stored in csched_pcpu so that serialization is not an issue,
> - * as there is a csched_pcpu for each PCPU and we always hold the
> - * runqueue spin-lock when using this.
> + * as there is a csched_pcpu for each PCPU, and we always hold the
> + * runqueue lock for the proper PCPU when using these.
>   */
>  #define csched_balance_mask (CSCHED_PCPU(smp_processor_id())->balance_mask)
>  
> +#define csched_balance_mask_cpu(c) (CSCHED_PCPU(c)->balance_mask)

csched_runq_steal() gets called with peer_cpu's runqueue lock held
afaics, but uses smp_processor_id()'s balance_mask. I.e. it looks to
me that what Jürgen suggested as an option is actually a requirement.

Jan

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

Re: [Xen-devel] [BUG] 16 vcpus + 2 vif bridge = issue ?

[Ian Campbell]

On Thu, 2015-09-24 at 09:56 +0100, Ian Campbell wrote:
> On Thu, 2015-09-24 at 03:16 +0300, Roman Shubovich wrote:
> > hi
> > 
> > i have physical server with 40 cpu cores
> > and i need to create a hvm domu with at least 16 vcpus and 2 network
> > bridges
> > when i start that domu i have some not understable issue - the second
> > bridge has no traffic from network (works only first interface - first
> > declared in config file). i can see traffic with tcpdum on dom0, but
> > not
> > on vif interface that has been created by domu startup script.
> > 
> > when i reduce number of vcpu to 15 or less then bridges works fine
> 
> Please post some logs:

Also I didn't notice this went to xen-devel@, which is a list for
_development_ of Xen. User support and configuration issues belong on xen
-users@.

If I had noticed this I would have added -users to the CC and moved -devel
to BCC in my previous reply. If you see this before you reply to my
previous mail please adjust the Cc's appropriately, otherwise please try
and remember to use the appropriate list next time.

Thanks,
Ian.

>  * dmesg of both host and guest
>  * output of these commands in dom0 while the guest is running with 2
> vifs
>configured (but only one working):
> * "brctl show"
> * "ifconfig -a"
>  * The output of "ifconfig -a" within the guest in the same
> configuration.
>  * The guest configuration file you are using.
> 
> Thanks.
> Ian.
> 
> > 
> > system:
> > dom0 ubuntu 14.04.03 kernel 3.18.21
> > domu ubuntu 14.04.03 kernel 3.18.21
> > tried xen:
> > xen 4.4
> > xen 4.5
> > xen 4.6
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

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

[Platform Team regression test user]

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

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

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] [PATCH v2] xen/keyhandler: Rework keyhandler infrastructure

[Andrew Cooper]

On 24/09/15 11:43, Jan Beulich wrote:

On 24.09.15 at 12:36,  wrote:
+void register_irq_keyhandler(unsigned char key,
+ irq_keyhandler_fn_t *fn,
+ const char *desc,
+ bool_t diagnostic);

I wonder whether the last parameter is really useful here.

Yes.  There are diagnostic irq_keyhandlers, 'd' for example.

I know; I was wondering if we would ever reasonably gain ones
outside of keyhandler.c.


I am not sure, but as I said, it should be present for completeness.  
The extra incurred overhead is not an issue.


~Andrew

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

Re: [Xen-devel] Regression in RMRRs identity mapping for PVH Dom0

[Elena Ufimtseva]

On Thu, Sep 24, 2015 at 10:18:54AM +0100, Tim Deegan wrote:
> At 15:17 +0800 on 24 Sep (1443107852), Chen, Tiejun wrote:
> > On 9/23/2015 11:56 PM, Elena Ufimtseva wrote:
> > > Hi
> > >
> > > There is a regression in RMRR patch 
> > > 5ae03990c120a7b3067a52d9784c9aa72c0705a6 in
> > > new set_identity_p2m_entry. RMRRs are not being mapped in IOMMU for PVH 
> > > Dom0.
> > > This causes pages faults and some long 'hang-like' delays during boot and
> > > device assignments.
> > >
> > > During construct_dom0, in PVH path  p2m is being constructed and identity 
> > > mapped
> > > in IOMMU. The p2m type is p2m_mmio_direct and p2m access p2m_rwx.
> > > New code used to map RMRRs invoked from rmrr_identity_mapping
> > > checks if p2m entry exists with same type and access and if yes, skips 
> > > iommu
> > > mapping. Since there are p2m entries for pvh dom0 iomem, RMRRs are not 
> > > being
> > > mapped in IOMMU.
> > >
> > > This debug patch attached fixes this and Ill be glad to see if there is a 
> > > more elegant fix.
> > 
> > Based on your explanation, sounds pvh always creates this mapping 
> > beforehand, so what about this?
> > 
> > diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> > index cf8485e..d026845 100644
> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -964,7 +964,7 @@ int set_identity_p2m_entry(struct domain *d, 
> > unsigned long gfn,
> >   struct p2m_domain *p2m = p2m_get_hostp2m(d);
> >   int ret;
> > 
> > -if ( !paging_mode_translate(p2m->domain) )
> > +if ( !paging_mode_translate(p2m->domain) || is_pvh_domain(d) )
> 
> Sorry, but that wouldn't be safe. :(  PVH domains need the same
> protection as any other paging_mode_translate ones.
> 
> AIUI the problem is that before the call to set_identity_p2m_entry(),
> PVH dom0 has a p2m entry covering this range but no IOMMU entry.  Is
> that right?  So the fix will be to make PVH dom0 construction set up
> the IOMMU correctly when it sets up the p2m.

Yes, thats right. Rework of construct_dom0 and its PVH part should help.
> 
> Cheers,
> 
> Tim.

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

Re: [Xen-devel] [PATCH v4 3/4] tools: add tools support for Intel CDP

[Jan Beulich]

>>> On 24.09.15 at 13:00,  wrote:
> On Thu, 2015-09-17 at 17:35 +0800, He Chen wrote:
>> diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c
>> index 3378239..62963cf 100644
>> --- a/tools/libxl/libxl_psr.c
>> +++ b/tools/libxl/libxl_psr.c
>> @@ -87,6 +87,9 @@ static void libxl__psr_cat_log_err_msg(libxl__gc *gc,
>> int err)
>>  case EEXIST:
>>  msg = "The same CBM is already set to this domain";
>>  break;
>> +case EINVAL:
>> +msg = "Unable to set code or data CBM when CDP is disabled";
>> +break;
> 
> These overloading of the errno values are getting a bit thinly stretched.
> The more so that EINVAL has a widely used more generic meaning.
> 
> Hypervisor maintainers, what is your opinion of this?
> 
> Since this is a sysctl I suppose we could consider adding a new PSR
> specific error type with appropriate codes?

I'd prefer using recognizable -E... values; a specific error type
to me seems to go too far. Surely out of the several dozen
possibilities a handful of not-so-common ones can be picked?

Jan


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

Re: [Xen-devel] [PATCH v4 4/4] docs: add document to introduce CDP command

[Jan Beulich]

>>> On 24.09.15 at 13:22,  wrote:
> On Thu, 2015-09-17 at 17:35 +0800, He Chen wrote:
>> Add new CDP options with CAT commands in xl interface man page.
>> --- a/docs/man/xl.pod.1
>> +++ b/docs/man/xl.pod.1
>> @@ -1530,6 +1530,12 @@ applications. In the Xen implementation, CAT is
>> used to control cache allocation
>>  on VM basis. To enforce cache on a specific domain, just set capacity
>> bitmasks
>>  (CBM) for the domain.
>>  
>> +Intel Broadwell and later server platforms also offer Code/Data 
> Prioritization
>> +(CDP) for cache allocation, which support
> 
>allocations,
> 
>>  specifying code or data cache for
> 
> It seems like a word is missing, perhaps "size" as in "code or data case
> size"? Or perhaps "priority"?

No, talk is really about the kind of cache.

>> --- a/docs/misc/xl-psr.markdown
>> +++ b/docs/misc/xl-psr.markdown
>> @@ -14,7 +14,7 @@ tracks cache utilization of memory accesses according
>> to the RMID and reports
>>  monitored data via a counter register.
>>  
>>  For more detailed information please refer to Intel SDM chapter
>> -"17.14 - Platform Shared Resource Monitoring: Cache Monitoring Technology".
>> +"17.15 - Platform Shared Resource Monitoring: Cache Monitoring Technology".
> 
> Was the chapter number just wrong, or are these things prone to changing?
> 
> If the latter then we should either omit them or we need to refer to a
> specific revision of the SDM as well.

They change all the time; I previously suggested to Intel folks to
omit the numbers and just make sure the titles get quoted fully
and correctly.

Jan


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

Re: [Xen-devel] [PATCH for-4.6] p2m/ept: Set the A bit only if PML is enabled

[Jan Beulich]

>>> On 24.09.15 at 11:13,  wrote:

>>> etc along with adjusting the existing gating of PML on AD being
>>> available (perhaps by simply stripping the respective bit from what
>>> we read from MSR_IA32_VMX_EPT_VPID_CAP). Of course this
>>> then ignores the fact that the erratum only affects the A bit, but
>>> I think we can live with that.
>>>
>>> I also think the currently slightly strange setting of the ept_ad bit
>>> should be changed: There's no point setting the bit for domains
>>> not getting PML enabled (and incurring the overhead of the
>>> hardware updating the bits); imo this should instead be done in
>>> ept_enable_pml() / vmx_domain_enable_pml() (and undone in
>>> the respective disable function).
>> Yep.
> 
> Just as a note, in the non PML case, the AD enable bit in EPTP is left 
> clear, which means that the A/D bits in the EPTs have no effect.

Not exactly: eptp.ad gets turned on when the hardware supports
PML, not when the guest gets PML enabled. I.e. for all the time the
guest runs without PML enabled there still is A/D checking overhead
(yet, because of the way we set them by default, there may not
be any page table updates by the hardware). Of course this may,
depending on how it's actually implemented in hardware, not mean
any performance effect at all.

Jan


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

Re: [Xen-devel] [PATCH] xen: credit1: fix tickling when it happens from a remote pCPU

[Dario Faggioli]

On Thu, 2015-09-24 at 08:44 +0200, Juergen Gross wrote:
> On 09/24/2015 06:31 AM, Dario Faggioli wrote:
> > Signed-off-by: Dario Faggioli 
> 
> Reviewed-by: Juergen Gross 
> 
> regardless whether you address my suggestion below or not.

> > --- a/xen/common/sched_credit.c
> > +++ b/xen/common/sched_credit.c
> > @@ -168,14 +168,16 @@ struct csched_pcpu {

> >   #define csched_balance_mask (CSCHED_PCPU(smp_processor_id())
> > ->balance_mask)
> 
> Wouldn't it make sense to get rid of that macro? After your patch it
> is
> used only in csched_runq_steal() which is called with cpu being
> always
> smp_processor_id(). You'd eliminate a possible source of future error
> and avoid multiple evaluation of smp_processor_id().
> 
Right. As said to Jan, I like this. I'll respin the patch with only the
new macro.

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



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

Re: [Xen-devel] Regression in RMRRs identity mapping for PVH Dom0

[Wei Liu]

Hi Elena

On Wed, Sep 23, 2015 at 11:56:12AM -0400, Elena Ufimtseva wrote:
> Hi
>   
>   
>   
> There is a regression in RMRR patch 5ae03990c120a7b3067a52d9784c9aa72c0705a6 
> in
> new set_identity_p2m_entry. RMRRs are not being mapped in IOMMU for PVH Dom0.
> This causes pages faults and some long 'hang-like' delays during boot and
> device assignments.
>   
>   
> During construct_dom0, in PVH path  p2m is being constructed and identity 
> mapped
> in IOMMU. The p2m type is p2m_mmio_direct and p2m access p2m_rwx.
> New code used to map RMRRs invoked from rmrr_identity_mapping 
>   
> checks if p2m entry exists with same type and access and if yes, skips iommu
> mapping. Since there are p2m entries for pvh dom0 iomem, RMRRs are not being
> mapped in IOMMU.
>   
>   
> This debug patch attached fixes this and Ill be glad to see if there is a 
> more elegant fix.
>   
>   

>From a release point of view, PVH Dom0 is not officially supported so I
don't consider this issue a blocker.

We can backport the proper fix to 4.6.1 if necessary, but I doubt this
is the only fix we need to make PVH Dom0 work on 4.6. Am I right?

Wei.

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

Re: [Xen-devel] [PATCH v4 3/4] tools: add tools support for Intel CDP

[Andrew Cooper]

On 24/09/15 11:57, Ian Campbell wrote:

On Thu, 2015-09-17 at 11:38 +0100, Andrew Cooper wrote:

@@ -320,6 +333,8 @@ int xc_psr_cat_get_l3_info(xc_interface *xch,

uint32_t socket,
  {
  *cos_max = sysctl.u.psr_cat_op.u.l3_info.cos_max;
  *cbm_len = sysctl.u.psr_cat_op.u.l3_info.cbm_len;
+*cdp_enabled = sysctl.u.psr_cat_op.u.l3_info.flags &
+   XEN_SYSCTL_PSR_CAT_L3_CDP;

!!(sysctl.u.psr_cat_op.u.l3_info.flags & XEN_SYSCTL_PSR_CAT_L3_CDP);

To turn it into a proper boolean, rather than a just a non-zero integer.

Given that *cdp_endabled is bool type does this not happen automagically?



Hmm - spec says yes.  Any assignment of a non-zero integer to a _Bool is 
will be converted to a 1.


~Andrew

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

Re: [Xen-devel] [PATCH v4 4/4] docs: add document to introduce CDP command

[Ian Campbell]

On Thu, 2015-09-17 at 17:35 +0800, He Chen wrote:
> Add new CDP options with CAT commands in xl interface man page.
> Add description of CDP in xl-psr.markdown.

It would have been fine to include this in the previous patch by the way.

> 
> Signed-off-by: He Chen 
> ---
>  docs/man/xl.pod.1 | 14 ++
>  docs/misc/xl-psr.markdown | 44 +++--
> ---
>  2 files changed, 53 insertions(+), 5 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> index f22c3f3..3c7107d 100644
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -1530,6 +1530,12 @@ applications. In the Xen implementation, CAT is
> used to control cache allocation
>  on VM basis. To enforce cache on a specific domain, just set capacity
> bitmasks
>  (CBM) for the domain.
>  
> +Intel Broadwell and later server platforms also offer Code/Data 
> Prioritization
> +(CDP) for cache allocation, which support

   allocations,

>  specifying code or data cache for

It seems like a word is missing, perhaps "size" as in "code or data case
size"? Or perhaps "priority"?

> +applications. CDP is used on VM basis in the Xen implementation. To specify

"used on a per VM basis"

> +code or data CBM for the domain, CDP feature must be enabled and CBM type
> +options need to be specified when setting CBM.

I asked on patch 3 whether these options were mutually exclusive or not,
the answer should be reflected in the documentation too please.

> diff --git a/docs/misc/xl-psr.markdown b/docs/misc/xl-psr.markdown
> index 3545912..5eb97cc 100644
> --- a/docs/misc/xl-psr.markdown
> +++ b/docs/misc/xl-psr.markdown
> @@ -14,7 +14,7 @@ tracks cache utilization of memory accesses according
> to the RMID and reports
>  monitored data via a counter register.
>  
>  For more detailed information please refer to Intel SDM chapter
> -"17.14 - Platform Shared Resource Monitoring: Cache Monitoring Technology".
> +"17.15 - Platform Shared Resource Monitoring: Cache Monitoring Technology".

Was the chapter number just wrong, or are these things prone to changing?

If the latter then we should either omit them or we need to refer to a
specific revision of the SDM as well.

>  
>  In Xen's implementation, each domain in the system can be assigned a
> RMID
>  independently, while RMID=0 is reserved for monitoring domains that
> don't
> @@ -91,17 +91,42 @@ For example, assuming a system with 8 portions and 3
> domains:
> first domain exclusive access to half the cache, and the other two
> exclusive
> access to one quarter each.
>  
> -For more detailed information please refer to Intel SDM chapter
> -"17.15 - Platform Shared Resource Control: Cache Allocation Technology".
> -


>  In Xen's implementation, CBM can be configured with libxl/xl interfaces but
>  COS is maintained in hypervisor only. The cache partition granularity is per
>  domain, each domain has COS=0 assigned by default, the corresponding CBM is
>  all-ones, which means all the cache resource can be used by default.
>  
> +Code/Data Prioritization (CDP) Technology is an extension of CAT, which is
> +available on Intel Broadwell and later server platforms. CDP enables 
> isolation
> +and separate prioritization of code and data fetches to the L3 cache in a
> +software configurable manner, which can enable workload prioritization and
> +tuning of cache capacity to the characteristics of the workload. CDP extends
> +Cache Allocation Technology (CAT) by providing separate code and data masks
> +per Class of Service (COS).

Looks good.

> +
> +CDP can be enabled by adding `psr=cdp` to Xen bootline.

"bootline" => "command line"

> +
> +When CDP is enabled,
> +
> + * the CAT masks are re-mapped into interleaved pairs of masks for data or 
> code
> +   fetches.
> +
> + * the range of COS for CAT is re-indexed, with the lower-half of the COS
> +   range available for CDP.
> +
> +CDP allows OS or Hypervisor to partition cache allocation more fine-grained,

 ^the   ^in a  

> +code cache and data cache can be specified respectively. With CDP enabled,

End fine-grained with a full-stop and then:

The code cache and data cache can be specified separately

or s/separately/independently/?

(I think, I'm not 100% sure what you meant by "respectively", so maybe the
suggestion is wrong)

> +one COS corresponds to two CBMs (code CBM & data CBM), since the sum of CBMs
> +is fixed, that means the number of available COSes will reduce to half when

   reduce by half

Ian.

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

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

[Jan Beulich]

>>> On 24.09.15 at 13:05,  wrote:
> +static struct keyhandler {
> +union {
> +keyhandler_fn_t *fn;
> +irq_keyhandler_fn_t *irq_fn;
> +};
> +
> +const char *desc;/* Description for help message. */
> +bool_t irq_callback, /* Call in irq context? if not, tasklet context. */
> +diagnostic;  /* Include in 'dump all' handler.*/
> +} key_table[128] __read_mostly =
> +{
> +#define KEYHANDLER(k, f, desc, diag)\
> +[k] = { .fn = (f), desc, 0, diag }
> +
> +#define IRQ_KEYHANDLER(k, f, desc, diag)\
> +[k] = { .irq_fn = (f), desc, 1, diag }

I'm sorry for noticing only now, but I'm afraid these (looking as
odd - but correct - as the other ones did) won't build with older
gcc either.

Jan


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

Re: [Xen-devel] [PATCH] x86emul: support clzero

[Andrew Cooper]

On 24/09/15 09:02, Jan Beulich wrote:
 On 23.09.15 at 19:37,  wrote:
>> On 22/09/15 14:06, Jan Beulich wrote:
>>> ... in anticipation of this possibly going to get used by guests for
>>> basic thinks like memset() or clearing or pages.
>>>
>>> Since the emulation doesn't use clzero itself, checking the guest's
>>> CPUID for the feature to be exposed is (intentionally) being avoided
>>> here. All that's required is sensible guest side data for the clflush
>>> line size.
>>>
>>> Signed-off-by: Jan Beulich 
>> Where have you found this instruction?  Googling, I have found a
>> presentation talking about it being new in the new AMD Zen cores, but I
>> still can't locate any technical documentation on the matter.
> Sadly no technical documentation so far, despite me pinging for it
> after the respective binutils patch
> (https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=029f3522619e8b77a7b848be23f4c13e50087d8b)
> got posted and went in.

While I don't see an obvious issue with your patch, I can't claim to
have reviewed it without some documentation to refer to.

Aravind/Suravee: Any ideas when the AMD manuals might be updated to
include this?

~Andrew

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

Re: [Xen-devel] [PATCH] x86emul: support clzero

[Jan Beulich]

>>> On 23.09.15 at 19:37,  wrote:
> On 22/09/15 14:06, Jan Beulich wrote:
>> ... in anticipation of this possibly going to get used by guests for
>> basic thinks like memset() or clearing or pages.
>>
>> Since the emulation doesn't use clzero itself, checking the guest's
>> CPUID for the feature to be exposed is (intentionally) being avoided
>> here. All that's required is sensible guest side data for the clflush
>> line size.
>>
>> Signed-off-by: Jan Beulich 
> 
> Where have you found this instruction?  Googling, I have found a
> presentation talking about it being new in the new AMD Zen cores, but I
> still can't locate any technical documentation on the matter.

Sadly no technical documentation so far, despite me pinging for it
after the respective binutils patch
(https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=029f3522619e8b77a7b848be23f4c13e50087d8b)
got posted and went in.

Jan


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

[Xen-devel] [PATCH] x86/boot: Move/copy sections more efficiently

[Andrew Cooper]

Both the trampoline copy and BSS initialise can be performed more
efficiently by using 4-byte variants of the string operations.

The ALIGN(STACK_SIZE) actually belongs with .bss.stack_aligned, but
__init_end still needs page alignment because of the init sections being
freed and returned to the domheap after boot.

Note concerning Intel ERMSB, which indicate that byte MOVS are
efficient.  ERMSB and non-aliased aligned MOVSD scale with identical
complexity albeit ERMSB doesn't have a small setup overhead (which falls
into the nose, given the length of the REP).  On non-ERMSB systems
however, MOVSD scales 4 times better than MOVSB.

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

---
v2: Better patch description.  No functional change.
---
 xen/arch/x86/boot/head.S |9 +
 xen/arch/x86/xen.lds.S   |5 -
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index f63b349..2b38048 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -128,7 +128,8 @@ __start:
 mov $sym_phys(__bss_end),%ecx
 sub %edi,%ecx
 xor %eax,%eax
-rep stosb
+shr $2,%ecx
+rep stosl
 
 /* Interrogate CPU extended features via CPUID. */
 mov $0x8000,%eax
@@ -197,8 +198,8 @@ __start:
 
 /* Copy bootstrap trampoline to low memory, below 1MB. */
 mov $sym_phys(trampoline_start),%esi
-mov $trampoline_end - trampoline_start,%ecx
-rep movsb
+mov $((trampoline_end - trampoline_start) / 4),%ecx
+rep movsl
 
 /* Jump into the relocated trampoline. */
 lret
@@ -210,6 +211,6 @@ reloc:
 
 ENTRY(trampoline_start)
 #include "trampoline.S"
-GLOBAL(trampoline_end)
+ENTRY(trampoline_end)
 
 #include "x86_64.S"
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 6553cff..c1180b2 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -158,11 +158,13 @@ SECTIONS
__xsm_initcall_start = .;
*(.xsm_initcall.init)
__xsm_initcall_end = .;
+
+   . = ALIGN(PAGE_SIZE);
   } :text
-  . = ALIGN(STACK_SIZE);
   __init_end = .;
 
   .bss : { /* BSS */
+   . = ALIGN(STACK_SIZE);
__bss_start = .;
*(.bss.stack_aligned)
. = ALIGN(PAGE_SIZE);
@@ -175,6 +177,7 @@ SECTIONS
*(.bss.percpu.read_mostly)
. = ALIGN(SMP_CACHE_BYTES);
__per_cpu_data_end = .;
+   . = ALIGN(8);
__bss_end = .;
   } :text
   _end = . ;
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH 4/4] x86/PoD: shorten certain operations on higher order ranges

[Jan Beulich]

>>> On 23.09.15 at 19:10,  wrote:
> On 09/15/2015 08:37 AM, Jan Beulich wrote:
>> @@ -574,41 +576,46 @@ recount:
>>   * + There are PoD entries to handle, or
>>   * + There is ram left, and we want to steal it
>>   */
>> -for ( i=0;
>> -  i<(1<0 || (steal_for_cache && ram > 0));
>> -  i++)
>> +for ( i = 0;
>> +  i < (1UL << order) && (pod > 0 || (steal_for_cache && ram > 0));
>> +  i += n )
>>  {
>>  mfn_t mfn;
>>  p2m_type_t t;
>>  p2m_access_t a;
>> +unsigned int cur_order;
>>  
>> -mfn = p2m->get_entry(p2m, gpfn + i, , , 0, NULL, NULL);
>> +mfn = p2m->get_entry(p2m, gpfn + i, , , 0, _order, NULL);
>> +if ( order < cur_order )
>> +cur_order = order;
>> +n = 1UL << cur_order;
>>  if ( t == p2m_populate_on_demand )
>>  {
>> -p2m_set_entry(p2m, gpfn + i, _mfn(INVALID_MFN), 0, p2m_invalid,
>> -  p2m->default_access);
>> -p2m->pod.entry_count--;
>> +p2m_set_entry(p2m, gpfn + i, _mfn(INVALID_MFN), cur_order,
>> +  p2m_invalid, p2m->default_access);
>> +p2m->pod.entry_count -= n;
>>  BUG_ON(p2m->pod.entry_count < 0);
>> -pod--;
>> +pod -= n;
>>  }
>>  else if ( steal_for_cache && p2m_is_ram(t) )
>>  {
>>  struct page_info *page;
>> +unsigned int j;
>>  
>>  ASSERT(mfn_valid(mfn));
>>  
>>  page = mfn_to_page(mfn);
>>  
>> -p2m_set_entry(p2m, gpfn + i, _mfn(INVALID_MFN), 0, p2m_invalid,
>> -  p2m->default_access);
>> -set_gpfn_from_mfn(mfn_x(mfn), INVALID_M2P_ENTRY);
>> -
>> -p2m_pod_cache_add(p2m, page, 0);
>> +p2m_set_entry(p2m, gpfn + i, _mfn(INVALID_MFN), cur_order,
>> +  p2m_invalid, p2m->default_access);
>> +for ( j = 0; j < n; ++j )
>> +set_gpfn_from_mfn(mfn_x(mfn), INVALID_M2P_ENTRY);
>> +p2m_pod_cache_add(p2m, page, cur_order);
>>  
>>  steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
> 
> This code will now steal an entire 2MiB page even if we only need a few
> individual pages, then free it below (calling p2m_pod_set_cache_target()).
> 
> Upon reflection, this is actually a feature -- if we have singleton
> pages in the cache, we can free those first, hopefully keeping the 2MiB
> page together.
> 
> It would be good to have a comment here to that effect, though; perhaps:
> 
> "If we need less than 1< than we actually need.  This will be rectified below, however; and
> stealing too much and then freeing what we need may allow us to free
> smaller pages from the cache, and avoid breaking up superpages."

Good point - I didn't really notice this change in behavior. Comment
added.

> It occurs to me that the steal_for_cache calculations are also wrong
> here --it should be (p2m->pod.entry_count - pod > p2m->pod.count) --
> i.e., we should steal if liabilities would be greater than assets
> *after* this function completed, not before.

In another patch (by you?) perhaps?

> Otherwise, everything else looks good, thanks.
> 
> I assume you'll resubmit this when the patch it depends on leaves RFC?
> In which case I'll wait until I see that version to Ack it.

The dependencies were patches 1 and 2 in this series, which
already went in. Patch 3 (the RFC one) was independent; in the
one here we just leverage what was needed as a prereq for that
other one.

Jan


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

Re: [Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Ian Campbell]

On Wed, 2015-09-23 at 18:36 +0100, Stefano Stabellini wrote:
> On Wed, 23 Sep 2015, Ian Campbell wrote:
> > On Tue, 2015-09-22 at 22:31 +0100, Stefano Stabellini wrote: 
> > > The oldest Xen version I build-test for every pull request is Xen 4.0.0,

I setup a build trees for 4.0 thru 4.6 yesterday to test this, what a
pain 4.1 and 4.0 are to build with a modern gcc! (Mostly newer compiler
warnings and mostly, but not all, fixes which I could just backport
from newer Xen, the exceptions were a couple of things which were
removed before they needed to be fixed)

> > > I think it is very reasonable to remove anything older than that.
> > > I am OK with removing Xen 4.0.0 too, but I would like a warning to be
> > > sent ahead of time to qemu-devel to see if anybody complains.
> > 
> > There is not much point in removing <=3.4 support and keeping 4.0, since
> > 4.0.0 was the last one which used a plain int as a handle, anything older
> > than 4.0.0 is trivial if 4.0.0 is supported.
> > 
> > One approach I am considering in order to keep 4.0.0 support and earlier
> > was to turn the "int fd" for <=4.0 into a pointer by having the open
> > wrapper do malloc(sizeof int) and the using wrappers do xc_foo(*handle).
> > 
> > This way all the different variants take pointers and we have less hoops to
> > jump through to typedef everything in the correct way for each variant.
> > 
> > If you would rather avoid doing that then I think dropping 4.0.0 support
> > would be the way to go and I'll send a mail to qemu-devel.
>  
> I would rather drop 4.0 support.

Supporting 4.0 didn't turn out quite as ugly as I had feared.

So before I send an email to qemu-devel to propose dropping 4.0 what do
you think of the following which handles the evtchn case, there is a
similar patch for gnttab and a (yet to be written) patch for the
foreign memory mapping case.

The relevant bit for this discussion is the 4.0.0 definition of
xenevtchn_open in xen_common.h, the rest is just adjusting it to use
the API of the new library (for reasons explained in the commit
message).

commit d97f6bb5045685d766d85b8cd004ce007fe29120
Author: Ian Campbell 
Date:   Wed Sep 23 17:30:15 2015 +0100

xen: Switch to libxenevtchn interface for compat shims.

In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.

One such library will be libxenevtchn which provides access to event
channels.

In preparation for this switch the compatibility layer in xen_common.h
(which support building with older versions of Xen) to use what will
be the new library API. This means that the evtchn shim will disappear
for versions of Xen which include libxenevtchn.

To simplify things for the <= 4.0.0 support we wrap the int fd in a
malloc(sizeof int) such that the handle is always a pointer. This
leads to less typedef headaches and the need for
XC_HANDLER_INITIAL_VALUE etc for these interfaces.

Build tested with 4.1 and 4.5.

Note that this patch does not add any support for actually using
libxenevtchn, it just adjusts the existing shims.

Note that xc_evtchn_alloc_unbound functionality remains in libxenctrl,
since that functionality is not exposed by /dev/xen/evtchn.

Signed-off-by: Ian Campbell 

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index b2cb22b..1fd8e01 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -243,19 +243,19 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
 xendev->debug  = debug;
 xendev->local_port = -1;
 
-xendev->evtchndev = xen_xc_evtchn_open(NULL, 0);
-if (xendev->evtchndev == XC_HANDLER_INITIAL_VALUE) {
+xendev->evtchndev = xenevtchn_open(NULL, 0);
+if (xendev->evtchndev == NULL) {
 xen_be_printf(NULL, 0, "can't open evtchn device\n");
 g_free(xendev);
 return NULL;
 }
-fcntl(xc_evtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
+fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
 
 if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
 xendev->gnttabdev = xen_xc_gnttab_open(NULL, 0);
 if (xendev->gnttabdev == XC_HANDLER_INITIAL_VALUE) {
 xen_be_printf(NULL, 0, "can't open gnttab device\n");
-xc_evtchn_close(xendev->evtchndev);
+xenevtchn_close(xendev->evtchndev);
 g_free(xendev);
 return NULL;
 }
@@ -306,8 +306,8 @@ static struct XenDevice *xen_be_del_xendev(int dom, int dev)
 g_free(xendev->fe);
 }
 
-if (xendev->evtchndev != XC_HANDLER_INITIAL_VALUE) {
-xc_evtchn_close(xendev->evtchndev);
+if (xendev->evtchndev != NULL) {
+xenevtchn_close(xendev->evtchndev);
 }
 if (xendev->gnttabdev != 

Re: [Xen-devel] [PATCH v6 12/29] xen/x86: allow disabling the emulated local apic

[Jan Beulich]

>>> On 23.09.15 at 17:45,  wrote:
> El 16/09/15 a les 12.05, Jan Beulich ha escrit:
> On 04.09.15 at 14:08,  wrote:
>> Also - aren't all the changes to this file (and perhaps othersfurther
>> down) bug fixes in their own right?
> 
> Whether they should be considered bugs or not it's hard to tell. There
> was no code that executed this paths before with this configuration, and
> probably nobody considered running HVM guests without an emulated lapic
> a possibility, so I would argue that they are merely omissions.

Whether these were active or latent bugs doesn't really matter.
What I'd prefer is for the code adjustments not directly related to
the feature suppression you work on to be in their own patch, so
that the two steps taken can be viewed as two steps. Particularly
if it later turns out that one or more of those apparent latent bugs
are found to be actively harming some special case, backporting
that adjustment without the feature suppression parts would
become a straightforward option.

Jan


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

Re: [Xen-devel] [PATCH for-4.6] p2m/ept: Set the A bit only if PML is enabled

[Tim Deegan]

At 01:02 -0600 on 24 Sep (1443056566), Jan Beulich wrote:
> >>> On 23.09.15 at 17:46,  wrote:
> > At 16:18 +0100 on 23 Sep (1443025126), Wei Liu wrote:
> >> With the discussion still not finalised I'm a bit worried that this
> >> issue will block the release.
> >> 
> >> I think we have a few options here. I will list them in order of my
> >> preference. Please correct me if I'm talking non-sense, and feel free to
> >> add more options if I miss anything.
> >> 
> >> 1. Disable PML on broken chips, gate access to A bit (or AD) with PML.
> > 
> > I don't much like tying this to PML: this is not a PML-related bug and
> > there may be CPUs that have A/D but not PML.
> > 
> > Better to have a global read-mostly bool cpu_has_vmx_ept_broken_access_bit,
> > or whatever name the maintainers prefer. :)
> 
> Actually I'd suggest a positive identification (e.g. cpu_has_ept_ad),
> which would get forced off on known broken chips. And then, in a
> slight variation of the previously proposed patch, at least for the
> immediate 4.6 needs do
> 
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -130,14 +130,18 @@ static void ept_p2m_type_to_flags(struct p2m_domain 
> *p2m, ept_entry_t *entry,
>  break;
>  case p2m_ram_rw:
>  entry->r = entry->w = entry->x = 1;
> -entry->a = entry->d = 1;
> +entry->a = entry->d = cpu_has_ept_ad;
>  break;
>  case p2m_mmio_direct:
>  entry->r = entry->x = 1;
>  entry->w = !rangeset_contains_singleton(mmio_ro_ranges,
>  entry->mfn);
> -entry->a = 1;
> -entry->d = entry->w;
> +entry->a = cpu_has_ept_ad;
> +entry->d = entry->w && cpu_has_ept_ad;
>  break;
>  case p2m_ram_logdirty:
>  entry->r = entry->x = 1;
> 

Sure, that works.  I still prefer putting the workaround on the CR3
operation, so all the cost happens on the broken chip, but I'll shut
up about that now. :)

> etc along with adjusting the existing gating of PML on AD being
> available (perhaps by simply stripping the respective bit from what
> we read from MSR_IA32_VMX_EPT_VPID_CAP). Of course this
> then ignores the fact that the erratum only affects the A bit, but
> I think we can live with that.
> 
> I also think the currently slightly strange setting of the ept_ad bit
> should be changed: There's no point setting the bit for domains
> not getting PML enabled (and incurring the overhead of the
> hardware updating the bits); imo this should instead be done in
> ept_enable_pml() / vmx_domain_enable_pml() (and undone in
> the respective disable function).

Yep.

> >> 2. Implement general framework to detect broken chips and apply quirks.
> >> 
> >> I take that there is no general framework at the moment, otherwise the
> >> patch would have used that.
> > 
> > We already have code that detects specific chips and adjusts things,
> > e.g. init_intel() in arch/x86/cpu/intel.c.  That seems like a good
> > place to set the global flag above, or...
> 
> Together with the above I'm not sure that would be the best place
> to deal with this (EPT specific) erratum; I think this would better be
> contained to VMX/EPT code.

Agreed.

Tim.

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

Re: [Xen-devel] Regression in RMRRs identity mapping for PVH Dom0

[Tim Deegan]

At 15:17 +0800 on 24 Sep (1443107852), Chen, Tiejun wrote:
> On 9/23/2015 11:56 PM, Elena Ufimtseva wrote:
> > Hi
> >
> > There is a regression in RMRR patch 
> > 5ae03990c120a7b3067a52d9784c9aa72c0705a6 in
> > new set_identity_p2m_entry. RMRRs are not being mapped in IOMMU for PVH 
> > Dom0.
> > This causes pages faults and some long 'hang-like' delays during boot and
> > device assignments.
> >
> > During construct_dom0, in PVH path  p2m is being constructed and identity 
> > mapped
> > in IOMMU. The p2m type is p2m_mmio_direct and p2m access p2m_rwx.
> > New code used to map RMRRs invoked from rmrr_identity_mapping
> > checks if p2m entry exists with same type and access and if yes, skips iommu
> > mapping. Since there are p2m entries for pvh dom0 iomem, RMRRs are not being
> > mapped in IOMMU.
> >
> > This debug patch attached fixes this and Ill be glad to see if there is a 
> > more elegant fix.
> 
> Based on your explanation, sounds pvh always creates this mapping 
> beforehand, so what about this?
> 
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index cf8485e..d026845 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -964,7 +964,7 @@ int set_identity_p2m_entry(struct domain *d, 
> unsigned long gfn,
>   struct p2m_domain *p2m = p2m_get_hostp2m(d);
>   int ret;
> 
> -if ( !paging_mode_translate(p2m->domain) )
> +if ( !paging_mode_translate(p2m->domain) || is_pvh_domain(d) )

Sorry, but that wouldn't be safe. :(  PVH domains need the same
protection as any other paging_mode_translate ones.

AIUI the problem is that before the call to set_identity_p2m_entry(),
PVH dom0 has a p2m entry covering this range but no IOMMU entry.  Is
that right?  So the fix will be to make PVH dom0 construction set up
the IOMMU correctly when it sets up the p2m.

Cheers,

Tim.

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

[Xen-devel] [linux-3.14 test] 62270: regressions - trouble: broken/fail/pass

[osstest service owner]

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

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 13 guest-localmigrate 
fail REGR. vs. 60666
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 18 guest-start.2 fail REGR. vs. 60666
 test-amd64-i386-xl-qcow2 13 guest-saverestore fail REGR. vs. 60666
 test-amd64-i386-xl-vhd   13 guest-saverestore fail REGR. vs. 60666
 test-amd64-amd64-xl-qcow219 guest-start.2 fail REGR. vs. 60666
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 60666
 test-amd64-amd64-xl-vhd  13 guest-saverestore fail REGR. vs. 60666
 test-amd64-i386-xl-qemuu-ovmf-amd64 19 guest-start/debianhvm.repeat fail REGR. 
vs. 60666

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-raw  3 host-install(3) broken REGR. vs. 60666
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 60666
 test-amd64-i386-libvirt-xsm  18 guest-start/debian.repeat fail REGR. vs. 60666
 test-amd64-amd64-libvirt-qcow2 13 guest-saverestore   fail REGR. vs. 60666
 test-amd64-i386-libvirt  18 guest-start/debian.repeat fail REGR. vs. 60666
 test-amd64-i386-libvirt-vhd  13 guest-saverestore fail REGR. vs. 60666
 test-amd64-amd64-libvirt-vhd 16 guest-start.2 fail REGR. vs. 60666
 test-amd64-amd64-libvirt-xsm 17 guest-start.2 fail REGR. vs. 60666
 test-amd64-i386-libvirt-qcow2 13 guest-saverestorefail REGR. vs. 60666
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  like 60666
 test-armhf-armhf-xl   6 xen-boot fail   like 60666
 test-armhf-armhf-libvirt  6 xen-boot fail   like 60666
 test-armhf-armhf-xl-credit2   6 xen-boot fail   like 60666
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 60666
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 60666
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 60666

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

version targeted for testing:
 linux4772a34b8cfb53e95d1fa884880d4620e7417ba6
baseline version:
 linux9b8b905951bde404f20a7bd4b37a5134f3484569

Last test of basis60666  2015-08-12 06:12:25 Z   43 days
Failing since 60747  2015-08-17 05:56:00 Z   38 days   19 attempts
Testing same since62270  2015-09-22 05:10:37 Z2 days1 attempts

Re: [Xen-devel] [PATCH for-4.6] p2m/ept: Set the A bit only if PML is enabled

[Andrew Cooper]

etc along with adjusting the existing gating of PML on AD being
available (perhaps by simply stripping the respective bit from what
we read from MSR_IA32_VMX_EPT_VPID_CAP). Of course this
then ignores the fact that the erratum only affects the A bit, but
I think we can live with that.

I also think the currently slightly strange setting of the ept_ad bit
should be changed: There's no point setting the bit for domains
not getting PML enabled (and incurring the overhead of the
hardware updating the bits); imo this should instead be done in
ept_enable_pml() / vmx_domain_enable_pml() (and undone in
the respective disable function).

Yep.


Just as a note, in the non PML case, the AD enable bit in EPTP is left 
clear, which means that the A/D bits in the EPTs have no effect.


Therefore, despite the unconditional setting of the A/D bits, there is 
still no MMU overhead.


~Andrew

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

Re: [Xen-devel] [PATCH] xen: credit1: fix tickling when it happens from a remote pCPU

[Juergen Gross]

On 09/24/2015 06:31 AM, Dario Faggioli wrote:

especially if that is also from a different cpupool than the
processor of the vCPU that triggered the tickling.

In fact, it is possible that we get as far as calling vcpu_unblock()-->
vcpu_wake()-->csched_vcpu_wake()-->__runq_tickle() for the vCPU 'vc',
but all while running on a pCPU that is different from 'vc->processor'.

For instance, this can happen when an HVM domain runs in a cpupool,
with a different scheduler than the default one, and issues IOREQs
to Dom0, running in Pool-0 with the default scheduler.
In fact, right in this case, the following crash can be observed:

(XEN) [ Xen-4.7-unstable  x86_64  debug=y  Tainted:C ]
(XEN) CPU:7
(XEN) RIP:e008:[] __runq_tickle+0x18f/0x430
(XEN) RFLAGS: 00010086   CONTEXT: hypervisor (d1v0)
(XEN) rax: 0001   rbx: 8303184fee00   rcx: 
(XEN) ... ... ...
(XEN) Xen stack trace from rsp=83031fa57a08:
(XEN)82d0801fe664 82d08033c820 00010002 000a0001
(XEN)6831   
(XEN) ... ... ...
(XEN) Xen call trace:
(XEN)[] __runq_tickle+0x18f/0x430
(XEN)[] csched_vcpu_wake+0x10b/0x110
(XEN)[] vcpu_wake+0x20a/0x3ce
(XEN)[] vcpu_unblock+0x4b/0x4e
(XEN)[] vcpu_kick+0x17/0x61
(XEN)[] vcpu_mark_events_pending+0x2c/0x2f
(XEN)[] evtchn_fifo_set_pending+0x381/0x3f6
(XEN)[] notify_via_xen_event_channel+0xc9/0xd6
(XEN)[] hvm_send_ioreq+0x3e9/0x441
(XEN)[] hvmemul_do_io+0x23f/0x2d2
(XEN)[] hvmemul_do_io_buffer+0x33/0x64
(XEN)[] hvmemul_do_pio_buffer+0x35/0x37
(XEN)[] handle_pio+0x58/0x14c
(XEN)[] vmx_vmexit_handler+0x16b3/0x1bea
(XEN)[] vmx_asm_vmexit_handler+0x41/0xc0

In this case, pCPU 7 is not in Pool-0, while the (Dom0's) vCPU being
woken is. pCPU's 7 pool has a different scheduler than credit, but it
is, however, right from pCPU 7 that we are waking the Dom0's vCPUs.
Therefore, the current code tries to access csched_balance_mask for
pCPU 7, but that is not defined, and hence the Oops.

(Note that, in case the two pools run the same scheduler we see no
Oops, but things are still conceptually wrong.)

Cure things by providing a second macro allowing to fetch the scratch
mask of a specific pCPU (instead than always using smp_processor_id()),
and use that one in __runq_tickle(), with such pCPU equal to the
processor of the vCPU being woken.

Signed-off-by: Dario Faggioli 


Reviewed-by: Juergen Gross 

regardless whether you address my suggestion below or not.


---
Cc: George Dunlap 
Cc: Juergen Gross 
---
  xen/common/sched_credit.c |   15 +--
  1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index a1945ac..f58c3d9 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -168,14 +168,16 @@ struct csched_pcpu {
  };

  /*
- * Convenience macro for accessing the per-PCPU cpumask we need for
+ * Convenience macros for accessing the per-PCPU cpumask we need for
   * implementing the two steps (soft and hard affinity) balancing logic.
   * It is stored in csched_pcpu so that serialization is not an issue,
- * as there is a csched_pcpu for each PCPU and we always hold the
- * runqueue spin-lock when using this.
+ * as there is a csched_pcpu for each PCPU, and we always hold the
+ * runqueue lock for the proper PCPU when using these.
   */
  #define csched_balance_mask (CSCHED_PCPU(smp_processor_id())->balance_mask)


Wouldn't it make sense to get rid of that macro? After your patch it is
used only in csched_runq_steal() which is called with cpu being always
smp_processor_id(). You'd eliminate a possible source of future error
and avoid multiple evaluation of smp_processor_id().


Juergen



+#define csched_balance_mask_cpu(c) (CSCHED_PCPU(c)->balance_mask)
+
  /*
   * Virtual CPU
   */
@@ -412,9 +414,10 @@ __runq_tickle(unsigned int cpu, struct csched_vcpu *new)

  /* Are there idlers suitable for new (for this balance step)? */
  csched_balance_cpumask(new->vcpu, balance_step,
-   csched_balance_mask);
-cpumask_and(csched_balance_mask, csched_balance_mask, _mask);
-new_idlers_empty = cpumask_empty(csched_balance_mask);
+   csched_balance_mask_cpu(cpu));
+cpumask_and(csched_balance_mask_cpu(cpu),
+csched_balance_mask_cpu(cpu), _mask);
+new_idlers_empty = cpumask_empty(csched_balance_mask_cpu(cpu));

  /*
   * Let's not be too harsh! If there aren't idlers suitable





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

Re: [Xen-devel] [PATCH] Remove a set operation for VCPU_KICK_SOFTIRQ when post interrupt to vm.

[Liuqiming (John)]

On 2015/9/24 11:25, Zhang, Yang Z wrote:

Liuqiming (John) wrote on 2015-09-24:

On 2015/9/23 21:41, Zhang, Yang Z wrote:

Hanweidong (Randy) wrote on 2015-09-23:

Zhang, Yang Z wrote on ent: 2015年9月23日 11:51:

VCPU_KICK_SOFTIRQ when post interrupt to vm.

Zhang, Yang Z wrote on 2015-09-08:

Liuqiming (John) wrote on 2015-09-08:

Ok, I will try to explain, correct me if I got anything wrong:

The problem here is not interrupts lost but interrupts not
delivered in time.

there are basically two path to inject an interrupt into VM  (or
vCPU to another vCPU):
Path 1, the traditional way:
 1) set bit  in vlapic IRR field which represent an interrupt,
 then kick vcpu 2) a VCPU_KICK_SOFTIRQ softirq raised 3) if
 VCPU_KICK_SOFTIRQ bit not set, then set it, otherwise
return

and

 do nothing 4) send an EVENT_CHECK_VECTOR IPI  to target

vcpu

5)

 target vcpu will VMEXIT due to
EXIT_REASON_EXTERNAL_INTERRUPT

6)

 the interrupt handler basically do nothing 7) interrupt in IRR
 will be evaluated 8) VCPU_KICK_SOFTIRQ will be cleared when
 do_softirq 9) there will be an interrupt inject into vcpu when
 VMENTRY Path 2, the Posted-interrupt way (current logic):
1)

set

 bit in posted-interrupt descriptor which represent an
 interrupt 2) if VCPU_KICK_SOFTIRQ bit not set, then set it,
 otherwise return and do nothing 3) send an
 POSTED_INTR_NOTIFICATION_VECTOR IPI to target vcpu 4) if
 target vcpu in non-ROOT mode it will receive the
interrupt immediately otherwise interrupt will be injected when
VMENTRY

As the first operation in both path is setting a interrupt
represent bit, so no interrupts will lost.

The issue is:
in path 2, the first interrupt will cause VCPU_KICK_SOFTIRQ set
to 1, and unless a VMEXIT occured or somewhere called do_softirq
directly, VCPU_KICK_SOFTIRQ will not cleared, that will make the
later interrupts injection  ignored at step 2), which will delay
irq handler process in VM.

And because path 2 set VCPU_KICK_SOFTIRQ to 1, the kick vcpu
logic in path 1 will also return in step 3), which make this
vcpu only can handle interrupt when some other reason cause VMEXIT.

Nice catch! But without set the softirq, the interrupt delivery
also will be delay. Look at the code in vmx_do_vmentry:

cli
  <---the virtual interrupt occurs here will
be delay. Because there is no softirq pending and the following
posted interrupt may consumed by another running VCPU, so the
target VCPU will not aware there is pending virtual interrupt before next 
vmexit.
cmp  %ecx,(%rdx,%rax,1)
jnz  .Lvmx_process_softirqs

I need more time to think it.

Hi Qiming,

Can you help to take a look at this patch? Also, if possible,
please help to do a testing since I don't have machine to test it.
Thanks very much.

diff --git a/xen/arch/x86/hvm/vmx/entry.S
b/xen/arch/x86/hvm/vmx/entry.S index 664ed83..1ebb5d0 100644
--- a/xen/arch/x86/hvm/vmx/entry.S
+++ b/xen/arch/x86/hvm/vmx/entry.S
@@ -77,6 +77,9 @@ UNLIKELY_START(ne, realmode)
   call vmx_enter_realmode
   UNLIKELY_END(realmode)
+bt   $0,VCPU_vmx_pi_ctrl(%rbx)
+jc   .Lvmx_do_vmentry
+
   mov  %rsp,%rdi
   call vmx_vmenter_helper
   mov  VCPU_hvm_guest_cr2(%rbx),%rax diff --git
a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index
e0e9e75..315ce65 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1678,8 +1678,9 @@ static void
__vmx_deliver_posted_interrupt(struct
vcpu *v)
   {
   unsigned int cpu = v->processor;
-if ( !test_and_set_bit(VCPU_KICK_SOFTIRQ,
_pending(cpu))
- && (cpu != smp_processor_id()) )
+if ( !test_bit(VCPU_KICK_SOFTIRQ, _pending(cpu))
+ && pi_test_on(>arch.hvm_vmx.pi_desc)

Why need pi_test_on() here?

on bit is cleared means the interrupt is consumed by target VCPU
already. So there is no need to send the PI.

Best regards,
Yang


Hi Yang,

I had a question about the "outstanding-notification" bit
(POSTED_INTR_ON)  handling.
It's not very clear in Intel manual. From what I learned, this bit is
set by software when send an interrupt to vcpu and cleared by hardware
when interrupt delivered, right?

from the source code, there is a test_and_set op for this bit in
function vmx_deliver_posted_intr,

else if ( !pi_test_and_set_on(>arch.hvm_vmx.pi_desc) )
  {
  __vmx_deliver_posted_interrupt(v);
  return;
  }
so when we enter __vmx_deliver_posted_interrupt to send ipi, this bit
is already set on, the "pi_test_on" code is meaningless.

The on bit will be cleared at any time.

That's true, just feel the logic is a little confusing,
the outside test(vmx_deliver_posted_intr) say: "the bit is not 1, lets 
set it to 1 and do the delivery"
the inner test(__vmx_deliver_posted_interrupt) say:"the bit is 1, let's 
do the delivery"

And another thought, the clear bit action performed only 

Re: [Xen-devel] Regression in RMRRs identity mapping for PVH Dom0

[Chen, Tiejun]

On 9/23/2015 11:56 PM, Elena Ufimtseva wrote:

Hi

There is a regression in RMRR patch 5ae03990c120a7b3067a52d9784c9aa72c0705a6 in
new set_identity_p2m_entry. RMRRs are not being mapped in IOMMU for PVH Dom0.
This causes pages faults and some long 'hang-like' delays during boot and
device assignments.

During construct_dom0, in PVH path  p2m is being constructed and identity mapped
in IOMMU. The p2m type is p2m_mmio_direct and p2m access p2m_rwx.
New code used to map RMRRs invoked from rmrr_identity_mapping
checks if p2m entry exists with same type and access and if yes, skips iommu
mapping. Since there are p2m entries for pvh dom0 iomem, RMRRs are not being
mapped in IOMMU.

This debug patch attached fixes this and Ill be glad to see if there is a more 
elegant fix.


Based on your explanation, sounds pvh always creates this mapping 
beforehand, so what about this?


diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index cf8485e..d026845 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -964,7 +964,7 @@ int set_identity_p2m_entry(struct domain *d, 
unsigned long gfn,

 struct p2m_domain *p2m = p2m_get_hostp2m(d);
 int ret;

-if ( !paging_mode_translate(p2m->domain) )
+if ( !paging_mode_translate(p2m->domain) || is_pvh_domain(d) )
 {
 if ( !need_iommu(d) )
 return 0;

Thanks
Tiejun

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

Re: [Xen-devel] [PATCH] Remove a set operation for VCPU_KICK_SOFTIRQ when post interrupt to vm.

[Zhang, Yang Z]

Liuqiming (John) wrote on 2015-09-24:
> 
> 
> On 2015/9/24 11:25, Zhang, Yang Z wrote:
>> Liuqiming (John) wrote on 2015-09-24:
>>> On 2015/9/23 21:41, Zhang, Yang Z wrote:
 Hanweidong (Randy) wrote on 2015-09-23:
> Zhang, Yang Z wrote on ent: 2015年9月23日 11:51:
>> VCPU_KICK_SOFTIRQ when post interrupt to vm.
>> 
>> Zhang, Yang Z wrote on 2015-09-08:
>>> Liuqiming (John) wrote on 2015-09-08:
 Ok, I will try to explain, correct me if I got anything wrong:
 
 The problem here is not interrupts lost but interrupts not
 delivered in time.
 
 there are basically two path to inject an interrupt into VM  (or
 vCPU to another vCPU):
 Path 1, the traditional way:
  1) set bit  in vlapic IRR field which represent an interrupt,
  then kick vcpu 2) a VCPU_KICK_SOFTIRQ softirq raised 3) if
  VCPU_KICK_SOFTIRQ bit not set, then set it, otherwise
 return
>> and
  do nothing 4) send an EVENT_CHECK_VECTOR IPI  to
> target
> vcpu
>> 5)
  target vcpu will VMEXIT due to
 EXIT_REASON_EXTERNAL_INTERRUPT
>> 6)
  the interrupt handler basically do nothing 7) interrupt
  in IRR will be evaluated 8) VCPU_KICK_SOFTIRQ will be
  cleared when do_softirq 9) there will be an interrupt
  inject into vcpu when VMENTRY Path 2, the
  Posted-interrupt way (current
> logic):
 1)
>> set
  bit in posted-interrupt descriptor which represent an
  interrupt 2) if VCPU_KICK_SOFTIRQ bit not set, then set
  it, otherwise return and do nothing 3) send an
  POSTED_INTR_NOTIFICATION_VECTOR IPI to target vcpu 4) if
  target vcpu in non-ROOT mode it will receive the
 interrupt immediately otherwise interrupt will be injected when
 VMENTRY
 
 As the first operation in both path is setting a interrupt
 represent bit, so no interrupts will lost.
 
 The issue is:
 in path 2, the first interrupt will cause VCPU_KICK_SOFTIRQ set
 to 1, and unless a VMEXIT occured or somewhere called do_softirq
 directly, VCPU_KICK_SOFTIRQ will not cleared, that will make the
 later interrupts injection  ignored at step 2), which will delay
 irq handler process in VM.
 
 And because path 2 set VCPU_KICK_SOFTIRQ to 1, the kick vcpu
 logic in path 1 will also return in step 3), which make this
 vcpu only can handle interrupt when some other reason cause
> VMEXIT.
>>> Nice catch! But without set the softirq, the interrupt delivery
>>> also will be delay. Look at the code in vmx_do_vmentry:
>>> 
>>> cli
>>>   <---the virtual interrupt occurs here will
>>> be delay. Because there is no softirq pending and the following
>>> posted interrupt may consumed by another running VCPU, so the
>>> target VCPU will not aware there is pending virtual interrupt
>>> before next vmexit. cmp  %ecx,(%rdx,%rax,1) jnz 
>>> .Lvmx_process_softirqs
>>> 
>>> I need more time to think it.
>> Hi Qiming,
>> 
>> Can you help to take a look at this patch? Also, if possible,
>> please help to do a testing since I don't have machine to test it.
>> Thanks very much.
>> 
>> diff --git a/xen/arch/x86/hvm/vmx/entry.S
>> b/xen/arch/x86/hvm/vmx/entry.S index 664ed83..1ebb5d0 100644
>> --- a/xen/arch/x86/hvm/vmx/entry.S
>> +++ b/xen/arch/x86/hvm/vmx/entry.S
>> @@ -77,6 +77,9 @@ UNLIKELY_START(ne, realmode)
>>call vmx_enter_realmode
>>UNLIKELY_END(realmode)
>> +bt   $0,VCPU_vmx_pi_ctrl(%rbx)
>> +jc   .Lvmx_do_vmentry
>> +
>>mov  %rsp,%rdi
>>call vmx_vmenter_helper
>>mov  VCPU_hvm_guest_cr2(%rbx),%rax diff --git
>> a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index
>> e0e9e75..315ce65 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -1678,8 +1678,9 @@ static void
>> __vmx_deliver_posted_interrupt(struct
>> vcpu *v)
>>{
>>unsigned int cpu = v->processor;
>> -if ( !test_and_set_bit(VCPU_KICK_SOFTIRQ,
>> _pending(cpu))
>> - && (cpu != smp_processor_id()) )
>> +if ( !test_bit(VCPU_KICK_SOFTIRQ, _pending(cpu))
>> + && pi_test_on(>arch.hvm_vmx.pi_desc)
> Why need pi_test_on() here?
 on bit is cleared means the interrupt is consumed by target VCPU
 already. So there is no need to send the PI.
 
 Best regards,
 Yang
 
>>> Hi Yang,
>>> 
>>> I had a question about the "outstanding-notification" bit
>>> (POSTED_INTR_ON)  handling.
>>> It's not 

Re: [Xen-devel] [PATCH RFC v2] x86/p2m: use large pages for MMIO mappings

[Jan Beulich]

>>> On 23.09.15 at 18:22,  wrote:
> On 09/22/2015 01:56 PM, Jan Beulich wrote:
>> When mapping large BARs (e.g. the frame buffer of a graphics card) the
>> overhead of establishing such mappings using only 4k pages has,
>> particularly after the XSA-125 fix, become unacceptable. Alter the
>> XEN_DOMCTL_memory_mapping semantics once again, so that there's no
>> longer a fixed amount of guest frames that represents the upper limit
>> of what a single invocation can map. Instead bound execution time by
>> limiting the number of iterations (regardless of page size).
> 
> FWIW most of the code looks OK to me.
> 
> The final version should probably mention somewhere exactly what the
> changed semantics are -- specifically, that returning >0 means, "I
> mapped this many, keep mapping the rest".

Done, but this is subject to change anyway (because of ...

>> Signed-off-by: Jan Beulich 
>> ---
>> RFC reasons:
>> - ARM side unimplemented (and hence libxc for now made cope with both
>>   models), the main issue (besides my inability to test any change
>>   there) being the many internal uses of map_mmio_regions())
>> - error unmapping in map_mmio_regions() and error propagation to caller
>>   from unmap_mmio_regions() are not really satisfactory (for the latter
>>   a possible model might be to have the function - and hence the
>>   domctl - return the [non-zero] number of completed entries upon
>>   error, requiring the caller to re-invoke the hypercall to then obtain
>>   the actual error for the failed slot)

... this open question).

>> @@ -2240,19 +2240,24 @@ int xc_domain_memory_mapping(
>>  domctl.u.memory_mapping.nr_mfns = nr;
>>  domctl.u.memory_mapping.first_gfn = first_gfn + done;
>>  domctl.u.memory_mapping.first_mfn = first_mfn + done;
>> -err = do_domctl(xch, );
>> -if ( err && errno == E2BIG )
>> +rc = do_domctl(xch, );
>> +if ( rc < 0 && errno == E2BIG )
>>  {
>>  if ( max_batch_sz <= 1 )
>>  break;
>>  max_batch_sz >>= 1;
>>  continue;
>>  }
>> +if ( rc > 0 )
>> +{
>> +done += rc;
>> +continue;
>> +}
>>  /* Save the first error... */
>>  if ( !ret )
>> -ret = err;
>> +ret = rc;
>>  /* .. and ignore the rest of them when removing. */
>> -if ( err && add_mapping != DPCI_REMOVE_MAPPING )
>> +if ( rc && add_mapping != DPCI_REMOVE_MAPPING )
>>  break;
> 
> Would it make more sense to structure this something like this:
> ---
> rc = do_domctl()
> 
> if( rc < 0 ) {
>   if ( errno == E2BIG ) { blah; continue; }
>   /* Other error stuff */
> } else if ( rc > 0 )
>nr = rc;
> 
> done += nr;
> ---

Not sure - I aimed at minimal changes to the existing code (but I
may well have missed that goal). I guess I'll wait for a tools
maintainer's opinion...

>> @@ -2045,22 +2091,47 @@ int map_mmio_regions(struct domain *d,
>>  {
>>  int ret = 0;
>>  unsigned long i;
>> +unsigned int iter, order;
>>  
>>  if ( !paging_mode_translate(d) )
>>  return 0;
>>  
>> -for ( i = 0; !ret && i < nr; i++ )
>> +for ( iter = i = 0; i < nr && iter < MAP_MMIO_MAX_ITER;
>> +  i += 1UL << order, ++iter )
>>  {
>> -ret = set_mmio_p2m_entry(d, start_gfn + i, _mfn(mfn + i),
>> - p2m_get_hostp2m(d)->default_access);
>> -if ( ret )
>> +for ( order = mmio_order(d, (start_gfn + i) | (mfn + i), nr - i); ;
>> +  order = ret - 1 )
> 
> I think you need a comment explaining what this (start_gfn + 1 ) | (mfn
> + i) stuff is about; maybe something like:
> 
> /* OR'ing the gfn and mfn values will return an order suitable to both */
> 
> (I assume that's what's going on here?)

Yes. Comments added (once per function using mmio_order()).

> No comments otherwise.

What a pity - I had hoped for some response on at least the middle
of the three RFC reasons.

Jan

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

Re: [Xen-devel] [PATCH v7 18/28] xen/arm: ITS: Export ITS info to Virtual ITS

[Ian Campbell]

On Thu, 2015-09-24 at 10:56 +0530, Vijay Kilari wrote:

> > > +
> > >  plpi = its_get_plpi(pdev, i);
> > >  /* TODO: Route lpi */
> > >  }
> > > @@ -1366,6 +1374,8 @@ static int its_probe(struct dt_device_node
> > > *node)
> > >  its->phys_size = its_size;
> > >  typer = readl_relaxed(its_base + GITS_TYPER);
> > >  its->ite_size = ((typer >> 4) & 0xf) + 1;
> > > +its_data.eventID_bits = GITS_TYPER_IDBITS(typer);
> > > +its_data.devID_bits = GITS_TYPER_DEVBITS(typer);
> > 
> > The 2 fields will be override every time a new ITS node will be
> > initialized.
> > 
> > What ensure that all the ITS have the same number of Event ID and
> > Device ID?
> 
> Nothing of I thing of ensures this at HW level.

The question here is about the behaviour of the software emulation.

>  Either we should
> assume that all the ITS
> have number of Event and Device ID or we choose lower of all the ITS?.

Don't we need, if anything, the highest?


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

Re: [Xen-devel] [BUG] 16 vcpus + 2 vif bridge = issue ?

[Ian Campbell]

On Thu, 2015-09-24 at 03:16 +0300, Roman Shubovich wrote:
> hi
> 
> i have physical server with 40 cpu cores
> and i need to create a hvm domu with at least 16 vcpus and 2 network
> bridges
> when i start that domu i have some not understable issue - the second
> bridge has no traffic from network (works only first interface - first
> declared in config file). i can see traffic with tcpdum on dom0, but not
> on vif interface that has been created by domu startup script.
> 
> when i reduce number of vcpu to 15 or less then bridges works fine

Please post some logs:

 * dmesg of both host and guest
 * output of these commands in dom0 while the guest is running with 2 vifs
   configured (but only one working):
* "brctl show"
* "ifconfig -a"
 * The output of "ifconfig -a" within the guest in the same configuration.
 * The guest configuration file you are using.

Thanks.
Ian.

> 
> system:
> dom0 ubuntu 14.04.03 kernel 3.18.21
> domu ubuntu 14.04.03 kernel 3.18.21
> tried xen:
> xen 4.4
> xen 4.5
> xen 4.6
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH for-4.6] p2m/ept: Set the A bit only if PML is enabled

[Jan Beulich]

>>> On 23.09.15 at 17:46,  wrote:
> At 16:18 +0100 on 23 Sep (1443025126), Wei Liu wrote:
>> With the discussion still not finalised I'm a bit worried that this
>> issue will block the release.
>> 
>> I think we have a few options here. I will list them in order of my
>> preference. Please correct me if I'm talking non-sense, and feel free to
>> add more options if I miss anything.
>> 
>> 1. Disable PML on broken chips, gate access to A bit (or AD) with PML.
> 
> I don't much like tying this to PML: this is not a PML-related bug and
> there may be CPUs that have A/D but not PML.
> 
> Better to have a global read-mostly bool cpu_has_vmx_ept_broken_access_bit,
> or whatever name the maintainers prefer. :)

Actually I'd suggest a positive identification (e.g. cpu_has_ept_ad),
which would get forced off on known broken chips. And then, in a
slight variation of the previously proposed patch, at least for the
immediate 4.6 needs do

--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -130,14 +130,18 @@ static void ept_p2m_type_to_flags(struct p2m_domain *p2m, 
ept_entry_t *entry,
 break;
 case p2m_ram_rw:
 entry->r = entry->w = entry->x = 1;
-entry->a = entry->d = 1;
+entry->a = entry->d = cpu_has_ept_ad;
 break;
 case p2m_mmio_direct:
 entry->r = entry->x = 1;
 entry->w = !rangeset_contains_singleton(mmio_ro_ranges,
 entry->mfn);
-entry->a = 1;
-entry->d = entry->w;
+entry->a = cpu_has_ept_ad;
+entry->d = entry->w && cpu_has_ept_ad;
 break;
 case p2m_ram_logdirty:
 entry->r = entry->x = 1;

etc along with adjusting the existing gating of PML on AD being
available (perhaps by simply stripping the respective bit from what
we read from MSR_IA32_VMX_EPT_VPID_CAP). Of course this
then ignores the fact that the erratum only affects the A bit, but
I think we can live with that.

I also think the currently slightly strange setting of the ept_ad bit
should be changed: There's no point setting the bit for domains
not getting PML enabled (and incurring the overhead of the
hardware updating the bits); imo this should instead be done in
ept_enable_pml() / vmx_domain_enable_pml() (and undone in
the respective disable function).

>> 2. Implement general framework to detect broken chips and apply quirks.
>> 
>> I take that there is no general framework at the moment, otherwise the
>> patch would have used that.
> 
> We already have code that detects specific chips and adjusts things,
> e.g. init_intel() in arch/x86/cpu/intel.c.  That seems like a good
> place to set the global flag above, or...

Together with the above I'm not sure that would be the best place
to deal with this (EPT specific) erratum; I think this would better be
contained to VMX/EPT code.

Jan


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

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

[Jan Beulich]

>>> On 24.09.15 at 03:50,  wrote:
> One issue is the number of vmexits is far far bigger than the number of
> context switch. I test it for a quite short time and it shows there are
> 2910043 vmexits and 71733 context switch (only count the number in
> __context_switch() since we only change the PI state in this function).
> If we change the PI state in each vmexit/vmentry, I am afraid this will
> hurt the performance.

Note that George has already asked whether the updating of the
PI descriptor is expensive, without you answering. If this is basically
just a memory or VMCS field write, I don't think it really matters in
which code path it sits, regardless of the frequency of either path
being used. Also note that whatever measuring you do in an area
like this, it'll only be an example, unlikely to be representative of
anything. Plus with the tendency to eliminate VMEXITs with newer
hardware, the penalty of this sitting in the VMEXIT path ought to go
down.

Jan



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

Re: [Xen-devel] [PATCH] x86: detect CMOS aliasing on ports other then 0x70/0x71

[Jan Beulich]

>>> On 23.09.15 at 20:34,  wrote:
> On 22/09/15 14:10, Jan Beulich wrote:
>> +for ( offs = 2; offs < 8; offs <<= 1 )
>> +{
>> +bool_t read = 1;
>> +
>> +for ( i = RTC_REG_D + 1; i < 0x80; ++i )
>> +{
>> +uint8_t normal, alt;
>> +unsigned long flags;
>> +
>> +if ( i == acpi_gbl_FADT.century )
>> +continue;
>> +
>> +spin_lock_irqsave(_lock, flags);
>> +
>> +normal = CMOS_READ(i);
>> +if ( inb(RTC_PORT(offs)) != i )
>> +read = 0;
>> +
>> +alt = inb(RTC_PORT(offs + 1));
>> +
>> +spin_unlock_irqrestore(_lock, flags);
>> +
>> +if ( normal != alt )
>> +break;
> 
> Even with a manual to hand, this logic is quite hard to understand. 
> Furthermore, I still cant spot how your r/w vs w/o logic is supposed to
> work.  It doesn't check the writability of the alias, but of the aliases
> index.

But that's the only interesting thing. A w/o alias would be rather
strange. It's the index register that traditionally hasn't been
readable, but has got means added in some chipsets to be read
back. For the moment we don't make use of this information
anyway, i.e. it's more a thing usable for validation that what the
logic determines matches with how the chipset is documented to
behave (if someone wanted to check that).

> However, it is not robust to the system servicing an SMI and altering
> the CMOS ram in the middle of this loop.  Such a modification would
> cause the loop to believe that this specific 'offs' is not an alias even
> when it actually is.
> 
> One option would be to reread the non-aliased port again, but that would
> add yet more io reads.

SMI is always a problem. Even if we re-read the register, we still
couldn't be sure we haven't got hit by another SMI. Considering
the index/data port access model I would anyway consider it quite
bad for firmware to modify the CMOS in an SMI.

Jan


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

Re: [Xen-devel] [PATCH for-4.6] p2m/ept: Set the A bit only if PML is enabled

[Tim Deegan]

At 10:13 +0100 on 24 Sep (1443089607), Andrew Cooper wrote:
> 
> >> etc along with adjusting the existing gating of PML on AD being
> >> available (perhaps by simply stripping the respective bit from what
> >> we read from MSR_IA32_VMX_EPT_VPID_CAP). Of course this
> >> then ignores the fact that the erratum only affects the A bit, but
> >> I think we can live with that.
> >>
> >> I also think the currently slightly strange setting of the ept_ad bit
> >> should be changed: There's no point setting the bit for domains
> >> not getting PML enabled (and incurring the overhead of the
> >> hardware updating the bits); imo this should instead be done in
> >> ept_enable_pml() / vmx_domain_enable_pml() (and undone in
> >> the respective disable function).
> > Yep.
> 
> Just as a note, in the non PML case, the AD enable bit in EPTP is left 
> clear, which means that the A/D bits in the EPTs have no effect.

I assumed the enable bit was what we were talking about -- the actual
A/D bits in EPTEs should always be _set_ to avoid extra faults.  So
that sounds like we're already doing the right thing.

Cheers,

Tim.

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

Re: [Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Fabio Fantoni]

Il 24/09/2015 09:15, Ian Campbell ha scritto:

On Wed, 2015-09-23 at 18:36 +0100, Stefano Stabellini wrote:

On Wed, 23 Sep 2015, Ian Campbell wrote:

On Tue, 2015-09-22 at 22:31 +0100, Stefano Stabellini wrote:

The oldest Xen version I build-test for every pull request is Xen 4.0.0,

I setup a build trees for 4.0 thru 4.6 yesterday to test this, what a
pain 4.1 and 4.0 are to build with a modern gcc! (Mostly newer compiler
warnings and mostly, but not all, fixes which I could just backport
from newer Xen, the exceptions were a couple of things which were
removed before they needed to be fixed)


I think it is very reasonable to remove anything older than that.
I am OK with removing Xen 4.0.0 too, but I would like a warning to be
sent ahead of time to qemu-devel to see if anybody complains.

There is not much point in removing <=3.4 support and keeping 4.0, since
4.0.0 was the last one which used a plain int as a handle, anything older
than 4.0.0 is trivial if 4.0.0 is supported.

One approach I am considering in order to keep 4.0.0 support and earlier
was to turn the "int fd" for <=4.0 into a pointer by having the open
wrapper do malloc(sizeof int) and the using wrappers do xc_foo(*handle).

This way all the different variants take pointers and we have less hoops to
jump through to typedef everything in the correct way for each variant.

If you would rather avoid doing that then I think dropping 4.0.0 support
would be the way to go and I'll send a mail to qemu-devel.
  
I would rather drop 4.0 support.

Supporting 4.0 didn't turn out quite as ugly as I had feared.


Even if seems that major of distro use newer qemu version instead older 
with xen seems that keep updated also xen to latest stable version (or 
at least previous) and the cases where can uses next qemu version with 
very old xen I think is at least very rare.
Another thing is that upstream qemu on older xen not had good support 
(at least for hvm domUs) and when I started to use it some years ago 
seems that was with too very few users.

There are also some problem, for example this:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=2e814a017155b885e4d4b5a88dc05e7367a9722a
without hvm domUs with emulated vga don't start with qemu>=1.4, applied 
to xen 4.3 and backported only in stable-4.2
Therefore excluded recent unexpected that I not know for a working 
support of hvm domUsat least xen 4.2 is needed.
In my cases I had saw good hvm domUs support with upstream qemu for 
production use only starting from xen 4.3.
I think is good know if older xen is really used with newer (more 
exactly next for these changes) qemu instead wasting time supporting and 
testing also many older xen versions.

In any cases thanks to all for any xen and qemu improvements.

Sorry for my bad english.



So before I send an email to qemu-devel to propose dropping 4.0 what do
you think of the following which handles the evtchn case, there is a
similar patch for gnttab and a (yet to be written) patch for the
foreign memory mapping case.

The relevant bit for this discussion is the 4.0.0 definition of
xenevtchn_open in xen_common.h, the rest is just adjusting it to use
the API of the new library (for reasons explained in the commit
message).

commit d97f6bb5045685d766d85b8cd004ce007fe29120
Author: Ian Campbell 
Date:   Wed Sep 23 17:30:15 2015 +0100

 xen: Switch to libxenevtchn interface for compat shims.
 
 In Xen 4.7 we are refactoring parts libxenctrl into a number of

 separate libraries which will provide backward and forward API and ABI
 compatiblity.
 
 One such library will be libxenevtchn which provides access to event

 channels.
 
 In preparation for this switch the compatibility layer in xen_common.h

 (which support building with older versions of Xen) to use what will
 be the new library API. This means that the evtchn shim will disappear
 for versions of Xen which include libxenevtchn.
 
 To simplify things for the <= 4.0.0 support we wrap the int fd in a

 malloc(sizeof int) such that the handle is always a pointer. This
 leads to less typedef headaches and the need for
 XC_HANDLER_INITIAL_VALUE etc for these interfaces.
 
 Build tested with 4.1 and 4.5.
 
 Note that this patch does not add any support for actually using

 libxenevtchn, it just adjusts the existing shims.
 
 Note that xc_evtchn_alloc_unbound functionality remains in libxenctrl,

 since that functionality is not exposed by /dev/xen/evtchn.
 
 Signed-off-by: Ian Campbell 


diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index b2cb22b..1fd8e01 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -243,19 +243,19 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
  xendev->debug  = debug;
  xendev->local_port = -1;
  
-xendev->evtchndev = 

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

[Jan Beulich]

>>> On 24.09.15 at 14:09,  wrote:
> This appears to work for me.

Looks okay with ...

> --- a/xen/common/keyhandler.c
> +++ b/xen/common/keyhandler.c
> @@ -43,10 +43,10 @@
>  } key_table[128] __read_mostly =
>  {
>  #define KEYHANDLER(k, f, desc, diag)\
> -[k] = { .fn = (f), desc, 0, diag }
> +[k] = { { f }, desc, 0, diag }
>  
>  #define IRQ_KEYHANDLER(k, f, desc, diag)\
> -[k] = { .irq_fn = (f), desc, 1, diag }
> +[k] = { { (keyhandler_fn_t*)f }, desc, 1, diag }

... parenthesizes added around f and a blank put ahead of the *
here.

Jan


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

Re: [Xen-devel] [PATCH v4 3/4] tools: add tools support for Intel CDP

[Ian Campbell]

On Thu, 2015-09-24 at 05:50 -0600, Jan Beulich wrote:
> > > > On 24.09.15 at 13:00,  wrote:
> > On Thu, 2015-09-17 at 17:35 +0800, He Chen wrote:
> > > diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c
> > > index 3378239..62963cf 100644
> > > --- a/tools/libxl/libxl_psr.c
> > > +++ b/tools/libxl/libxl_psr.c
> > > @@ -87,6 +87,9 @@ static void libxl__psr_cat_log_err_msg(libxl__gc
> > > *gc,
> > > int err)
> > >  case EEXIST:
> > >  msg = "The same CBM is already set to this domain";
> > >  break;
> > > +case EINVAL:
> > > +msg = "Unable to set code or data CBM when CDP is disabled";
> > > +break;
> > 
> > These overloading of the errno values are getting a bit thinly
> > stretched.
> > The more so that EINVAL has a widely used more generic meaning.
> > 
> > Hypervisor maintainers, what is your opinion of this?
> > 
> > Since this is a sysctl I suppose we could consider adding a new PSR
> > specific error type with appropriate codes?
> 
> I'd prefer using recognizable -E... values;

_If_ the -E values somehow map sensibly onto the PSR errors, otherwise they
aren't really recognisable any more.

>  a specific error type
> to me seems to go too far. Surely out of the several dozen
> possibilities a handful of not-so-common ones can be picked?

I was thinking in particular EINVAL was not in the not-so-common bracket.

The current code already uses 9 values FWIW.

Ian.

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

Re: [Xen-devel] [PATCH v4 3/4] tools: add tools support for Intel CDP

[Jan Beulich]

>>> On 24.09.15 at 14:07,  wrote:
> On Thu, 2015-09-24 at 05:50 -0600, Jan Beulich wrote:
>>  a specific error type
>> to me seems to go too far. Surely out of the several dozen
>> possibilities a handful of not-so-common ones can be picked?
> 
> I was thinking in particular EINVAL was not in the not-so-common bracket.

Which I fully agree with.

> The current code already uses 9 values FWIW.

Right, but ENXIO would e.g. seem to be a reasonable fit for
"Unable to set code or data CBM when CDP is disabled".

Jan


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

[Xen-devel] [xen-4.6-testing test] 62273: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   3 host-install(3) broken REGR. vs. 62015

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 
62015
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 62015
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 62015

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

version targeted for testing:
 xen  b18491f5ca8e4d2f31501e4575e61d559b419e10
baseline version:
 xen  70d63e48077f8fee8eda6d8d95eeda52a34d9077

Last test of basis62015  2015-09-14 22:22:30 Z9 days
Failing since 62089  2015-09-17 06:48:20 Z7 days3 attempts
Testing same since62273  2015-09-22 07:01:25 Z2 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Chunyan Liu 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Stefano Stabellini 
  Tiejun Chen 

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

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

[Andrew Cooper]

On 24/09/15 12:58, Jan Beulich wrote:
 On 24.09.15 at 13:47,  wrote:
>> On 24/09/15 12:46, Jan Beulich wrote:
>> On 24.09.15 at 13:05,  wrote:
 +static struct keyhandler {
 +union {
 +keyhandler_fn_t *fn;
 +irq_keyhandler_fn_t *irq_fn;
 +};
 +
 +const char *desc;/* Description for help message. 
>> */
 +bool_t irq_callback, /* Call in irq context? if not, tasklet context. 
>> */
 +diagnostic;  /* Include in 'dump all' handler.
>> */
 +} key_table[128] __read_mostly =
 +{
 +#define KEYHANDLER(k, f, desc, diag)\
 +[k] = { .fn = (f), desc, 0, diag }
 +
 +#define IRQ_KEYHANDLER(k, f, desc, diag)\
 +[k] = { .irq_fn = (f), desc, 1, diag }
>>> I'm sorry for noticing only now, but I'm afraid these (looking as
>>> odd - but correct - as the other ones did) won't build with older
>>> gcc either.
>> Urgh yes.  I think we might have to just explicitly typecast the
>> pointer, because .irq_fn is uninitialised in older GCC.  Would that be ok?
> Yes, certainly better than re-adding the u name. Another
> alternative would be a void * as the first union alternative,
> but I suppose future gcc might become more strict about
> conversions between function and data pointers...

This appears to work for me.

diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 7d168e9..8c43d85 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -43,10 +43,10 @@
 } key_table[128] __read_mostly =
 {
 #define KEYHANDLER(k, f, desc, diag)\
-[k] = { .fn = (f), desc, 0, diag }
+[k] = { { f }, desc, 0, diag }
 
 #define IRQ_KEYHANDLER(k, f, desc, diag)\
-[k] = { .irq_fn = (f), desc, 1, diag }
+[k] = { { (keyhandler_fn_t*)f }, desc, 1, diag }
 
 IRQ_KEYHANDLER('A', do_toggle_alt_key, "toggle alternative key
handling", 0),
 IRQ_KEYHANDLER('d', dump_registers, "dump registers", 1),


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

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

[Andrew Cooper]

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

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

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

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

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

---

v4:
 * More build fixes with older GCC

v3:
 * Fix build on older GCC
 * Extra whitespace
 * More use of function typedefs.

v2:
 * Keep {,irq_}keyhandler_t's as function typedefs
 * Adjustment of initialiser macros
 * Trim more trailing whitespace
 * Implement register_irq_keyhandler()
 * Tweak wording of some descriptions

Note: I have avoided CC'ing all maintainers as this is largely a mechanical
change across the whole codebase.  Most non-mechanical changes are in common
code, but there is a trivial externing change
xen/drivers/passthrough/vtd/extern.h as previously the struct keyhandler was
in a different translation unit to the function it referenced.
---
 xen/arch/x86/acpi/cpu_idle.c |8 +-
 xen/arch/x86/hvm/irq.c   |8 +-
 xen/arch/x86/hvm/svm/vmcb.c  |8 +-
 xen/arch/x86/hvm/vmx/vmcs.c  |8 +-
 xen/arch/x86/io_apic.c   |7 +-
 xen/arch/x86/irq.c   |8 +-
 xen/arch/x86/mm/p2m-ept.c|8 +-
 xen/arch/x86/mm/shadow/common.c  |   14 +-
 xen/arch/x86/msi.c   |8 +-
 xen/arch/x86/nmi.c   |   15 +--
 xen/arch/x86/numa.c  |8 +-
 xen/arch/x86/time.c  |8 +-
 xen/common/event_channel.c   |8 +-
 xen/common/grant_table.c |9 +-
 xen/common/kexec.c   |7 +-
 xen/common/keyhandler.c  |  214 --
 xen/common/page_alloc.c  |   16 +--
 xen/common/timer.c   |8 +-
 xen/drivers/char/console.c   |   16 +--
 xen/drivers/passthrough/amd/iommu_intr.c |9 +-
 xen/drivers/passthrough/iommu.c  |8 +-
 xen/drivers/passthrough/pci.c|8 +-
 xen/drivers/passthrough/vtd/extern.h |2 +-
 xen/drivers/passthrough/vtd/iommu.c  |2 +-
 xen/drivers/passthrough/vtd/utils.c  |8 +-
 xen/include/xen/keyhandler.h |   71 +-
 26 files changed, 152 insertions(+), 342 deletions(-)

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

Re: [Xen-devel] [PATCH v4 3/4] tools: add tools support for Intel CDP

[Ian Campbell]

On Thu, 2015-09-24 at 06:20 -0600, Jan Beulich wrote:
> > > > On 24.09.15 at 14:07,  wrote:
> > On Thu, 2015-09-24 at 05:50 -0600, Jan Beulich wrote:
> > >  a specific error type
> > > to me seems to go too far. Surely out of the several dozen
> > > possibilities a handful of not-so-common ones can be picked?
> > 
> > I was thinking in particular EINVAL was not in the not-so-common
> > bracket.
> 
> Which I fully agree with.
> 
> > The current code already uses 9 values FWIW.
> 
> Right, but ENXIO would e.g. seem to be a reasonable fit for
> "Unable to set code or data CBM when CDP is disabled".

That would be better yes (sorry I didn't check if this came up in the
review of the hypervisor side)

Ian.

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

Re: [Xen-devel] [PATCH v7 23/28] xen/arm: ITS: Allocate pending_lpi descriptors for LPIs

[Julien Grall]

On 18/09/15 14:09, vijay.kil...@gmail.com wrote:
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 6a5c6a0..49630a3 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -101,6 +101,9 @@ struct arch_domain
>   * struct arch_vcpu.
>   */
>  struct pending_irq *pending_irqs;
> +#ifdef HAS_GICV3
> +struct pending_irq *pending_lpis;
> +#endif

It's rather strange to expose nr_lpis, vgic_is_domain_lpi to anyone but
not pending_lpis.

Please either expose to anyone anything related to LPIs or nothing. But
not only some of them for convenience in the code.

As for physical LPIs I would much prefer to see this code compiled for
everyone.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH] x86emul: support clzero

[Jan Beulich]

>>> On 24.09.15 at 13:59,  wrote:
> On 24/09/15 09:02, Jan Beulich wrote:
> On 23.09.15 at 19:37,  wrote:
>>> On 22/09/15 14:06, Jan Beulich wrote:
 ... in anticipation of this possibly going to get used by guests for
 basic thinks like memset() or clearing or pages.

 Since the emulation doesn't use clzero itself, checking the guest's
 CPUID for the feature to be exposed is (intentionally) being avoided
 here. All that's required is sensible guest side data for the clflush
 line size.

 Signed-off-by: Jan Beulich 
>>> Where have you found this instruction?  Googling, I have found a
>>> presentation talking about it being new in the new AMD Zen cores, but I
>>> still can't locate any technical documentation on the matter.
>> Sadly no technical documentation so far, despite me pinging for it
>> after the respective binutils patch
>> 
> (https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=029f3
>  
> 522619e8b77a7b848be23f4c13e50087d8b)
>> got posted and went in.
> 
> While I don't see an obvious issue with your patch, I can't claim to
> have reviewed it without some documentation to refer to.

Understood. Depending on the actual semantics the patch may allow
the instruction to be used (emulated) in more cases than on actual
hardware, which I don't see as an issue. That's mainly due to the
undefinedness of "cache line" for memory types not using the cache
(i.e. the instruction may not do what one might expect on WC or UC
memory, which is what I've been trying to find out since said
binutils posting, but I'm pretty certain it would at best be undefined;
us giving it defined behavior would not violate that).

Jan


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

Re: [Xen-devel] [PATCH] Add missing license and copyright statements to public interface headers.

[Boris Ostrovsky]

On 09/24/2015 06:45 AM, Ian Campbell wrote:

On Tue, 2015-09-22 at 16:02 +0200, Mike Belopuhov wrote:

The copyright line indicates a person, a group of people and/or a company
granting rights stated in the license text and is a required part of the
license.

The year of the copyright is chosen to be the same as when the license has
been applied to the file or when the file has been created in case there
was no license.  It is possible to update or add additional years if major
changes have been done to the the file, but is generally not a requirement.

Signed-off-by: Mike Belopuhov 

LGTM, thanks. I'll wait for Konrad and/or Boris to confirm that Oracle are
happy with this wording etc.


This looks like we were told it should look, so I am OK with this.

-boris


Keir's one matches all his others so I think
we can assume it is ok unless we hear otherwise.

Wei, I can't think of a reason not to include this in 4.6, does that work
for you?


---
  xen/include/public/arch-x86/pmu.h   | 22 ++
  xen/include/public/hvm/e820.h   |  3 ++-
  xen/include/public/hvm/hvm_info_table.h |  2 ++
  xen/include/public/hvm/hvm_op.h |  2 ++
  xen/include/public/hvm/hvm_xs_strings.h |  2 ++
  xen/include/public/hvm/params.h |  2 ++
  xen/include/public/io/protocols.h   |  2 ++
  xen/include/public/physdev.h|  2 ++
  xen/include/public/pmu.h| 22 ++
  9 files changed, 58 insertions(+), 1 deletion(-)

diff --git xen/include/public/arch-x86/pmu.h xen/include/public/arch
-x86/pmu.h
index 1a53888..68ebf12 100644
--- xen/include/public/arch-x86/pmu.h
+++ xen/include/public/arch-x86/pmu.h
@@ -1,5 +1,27 @@
+/*
+ * Permission is hereby granted, free of charge, to any person obtaining
a copy
+ * of this software and associated documentation files (the "Software"),
to
+ * deal in the Software without restriction, including without
limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or
+ * sell copies of the Software, and to permit persons to whom the
Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be
included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2015 Oracle and/or its affiliates. All rights reserved.
+ */
+
  #ifndef __XEN_PUBLIC_ARCH_X86_PMU_H__
  #define __XEN_PUBLIC_ARCH_X86_PMU_H__
  
  /* x86-specific PMU definitions */
  
diff --git xen/include/public/hvm/e820.h xen/include/public/hvm/e820.h

index 5bdc227..6c58a37 100644
--- xen/include/public/hvm/e820.h
+++ xen/include/public/hvm/e820.h
@@ -1,6 +1,5 @@
-
  /*
   * Permission is hereby granted, free of charge, to any person obtaining
a copy
   * of this software and associated documentation files (the "Software"),
to
   * deal in the Software without restriction, including without
limitation the
   * rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or
@@ -15,10 +14,12 @@
   * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE
   * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
   * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING
   * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
   * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2006, Keir Fraser
   */
  
  #ifndef __XEN_PUBLIC_HVM_E820_H__

  #define __XEN_PUBLIC_HVM_E820_H__
  
diff --git xen/include/public/hvm/hvm_info_table.h

xen/include/public/hvm/hvm_info_table.h
index 36085fa..9e3f807 100644
--- xen/include/public/hvm/hvm_info_table.h
+++ xen/include/public/hvm/hvm_info_table.h
@@ -18,10 +18,12 @@
   * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE
   * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
   * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING
   * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
   * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2006, Keir Fraser
   */
  
  #ifndef __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__

  #define __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__
  
diff --git xen/include/public/hvm/hvm_op.h

xen/include/public/hvm/hvm_op.h
index 014546a..1606185 100644
--- xen/include/public/hvm/hvm_op.h
+++ xen/include/public/hvm/hvm_op.h
@@ -14,10 +14,12 @@
   * FITNESS FOR A PARTICULAR PURPOSE AND 

[Xen-devel] EFI GetNextVariableName hang/crash

[Marek Marczykowski-Górecki]

Hi,

I have well known problem of buggy firmware, where GetNextVariableName
doesn't work from dom0 running on Xen. I've read both threads about
this:
"EFI GetNextVariableName crashes when running under Xen, but not under
Linux. efi-rs=0 works. No memmap issues"
http://lists.xenproject.org/archives/html/xen-devel/2015-01/msg03164.html
"Xen master hangs"
http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04830.html

My system is Dell E6420, BIOS A21

I've tried your workarounds: -mapbs, efi=attr=uc, -noexitboot (with your
patch applied for that). Most tests were done on 4.4.3, but using newer
version (stable-4.5, stable-4.6) doesn't help.

Without any workaround enabled, it simply hangs, with -noexitboot it
crashes (depending on -mapbs and efi=attr=uc the crash is slightly
different). Below I attach one of such crash (with both -mapbs and
efi=attr=uc enabled).

Since this bug is quite common, and on some systems it will never be
fixed in the firmware, I think the most reliable workaround would be to
use SetVirtualAddressMap. Yes, this will break kexec, but at least
system will start. Also on desktop systems (where apparently this bug is
most common) I think very few people care about kexec...

How hard would be to get SetVirtualAddressMap code working? I've tried
that #ifdef-ed code and unsurprisingly it crashes.

=
The console output from SetVirtualAddressMap crash:

(XEN) Xen version 4.4.3-rc1 (user@) (gcc (GCC) 4.9.2 20150212 (Red Hat 
4.9.2-6)) debug=n Thu Sep 24 04:27:51 CEST 2015
(XEN) Latest ChangeSet: Thu Sep 24 03:00:24 2015 +0200 git:48de6e2-dirty
(XEN) Bootloader: EFI
(XEN) Command line: loglvl=all console=com1 com1=115200n1 conswitch=ax 
efi=attr=uc
(XEN) Video information:
(XEN)  VGA is graphics mode 1600x900, 32 bpp
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) EFI RAM map:
(XEN)   - 8000 (reserved)
(XEN)  8000 - 0004e000 (usable)
(XEN)  0004e000 - 000a (reserved)
(XEN)  0010 - 2000 (usable)
(XEN)  2000 - 2020 (reserved)
(XEN)  2020 - 4000 (usable)
(XEN)  4000 - 4020 (reserved)
(XEN)  4020 - 91a36000 (usable)
(XEN)  91a36000 - 91fb5000 (reserved)
(XEN)  91fb5000 - c6b12000 (usable)
(XEN)  c6b12000 - c6b6a000 (reserved)
(XEN)  c6b6a000 - c6be1000 (usable)
(XEN)  c6be1000 - c6c08000 (reserved)
(XEN)  c6c08000 - c6c0c000 (usable)
(XEN)  c6c0c000 - c722d000 (reserved)
(XEN)  c722d000 - c7236000 (usable)
(XEN)  c7236000 - c723f000 (reserved)
(XEN)  c723f000 - c7412000 (usable)
(XEN)  c7412000 - ca9e7000 (reserved)
(XEN)  ca9e7000 - cabe7000 (ACPI NVS)
(XEN)  cabe7000 - cabff000 (ACPI data)
(XEN)  cabff000 - cac0 (reserved)
(XEN)  cb80 - cfa0 (reserved)
(XEN)  fed1c000 - fed2 (reserved)
(XEN)  ffc0 - ffc2 (reserved)
(XEN)  0001 - 00042e00 (usable)
(XEN) ACPI: RSDP CABFEF98, 0024 (r2 DELL  )
(XEN) ACPI: XSDT CABFDE18, 007C (r1 DELLCBX3 6222004 MSFT10013)
(XEN) ACPI: FACP CAB77D98, 00F4 (r4 DELLCBX3 6222004 MSFT10013)
(XEN) ACPI: DSDT CAB45018, 885D (r2 INT430 SYSFexxx 1001 INTL 20090903)
(XEN) ACPI: FACS CABD4D40, 0040
(XEN) ACPI: APIC CABFCF18, 00CC (r2 DELLCBX3 6222004 MSFT10013)
(XEN) ACPI: TCPA CABD5D18, 0032 (r20 0)
(XEN) ACPI: SSDT CAB78A98, 02F9 (r1 DELLTP  TPM 3000 INTL 20090903)
(XEN) ACPI: MCFG CABD5C98, 003C (r1 DELL   SNDYBRDG  6222004 MSFT   97)
(XEN) ACPI: HPET CABD5C18, 0038 (r1 A M I   PCHHPET  6222004 AMI.3)
(XEN) ACPI: BOOT CABD5B98, 0028 (r1 DELL   CBX3  6222004 AMI 10013)
(XEN) ACPI: SSDT CAB5C018, 0804 (r1  PmRef  Cpu0Ist 3000 INTL 20090903)
(XEN) ACPI: SSDT CAB5B018, 0996 (r1  PmRefCpuPm 3000 INTL 20090903)
(XEN) ACPI: DMAR CAB77C18, 00E8 (r1 INTEL  SNB 1 INTL1)
(XEN) ACPI: SLIC CAB65C18, 0176 (r3 DELLCBX3 6222004 MSFT10013)
(XEN) System RAM: 16195MB (16583872kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at -00042e00
(XEN) Domain heap initialised
(XEN) SMBIOS 2.6 present.
(XEN) DMI 2.6 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT - cabd4e40/cabd4d40, 
using 32
(XEN) ACPI: wakeup_vec[cabd4e4c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee0
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 6:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] 

Re: [Xen-devel] [PATCH] Add missing license and copyright statements to public interface headers.

[Konrad Rzeszutek Wilk]

On September 24, 2015 9:17:08 AM EDT, Boris Ostrovsky 
 wrote:
>On 09/24/2015 06:45 AM, Ian Campbell wrote:
>> On Tue, 2015-09-22 at 16:02 +0200, Mike Belopuhov wrote:
>>> The copyright line indicates a person, a group of people and/or a
>company
>>> granting rights stated in the license text and is a required part of
>the
>>> license.
>>>
>>> The year of the copyright is chosen to be the same as when the
>license has
>>> been applied to the file or when the file has been created in case
>there
>>> was no license.  It is possible to update or add additional years if
>major
>>> changes have been done to the the file, but is generally not a
>requirement.
>>>
>>> Signed-off-by: Mike Belopuhov 
>> LGTM, thanks. I'll wait for Konrad and/or Boris to confirm that
>Oracle are
>> happy with this wording etc.
>
>This looks like we were told it should look, so I am OK with this.
>

Ditto, though I think you need to provide an official Acked-by.

>-boris
>
>> Keir's one matches all his others so I think
>> we can assume it is ok unless we hear otherwise.
>>
>> Wei, I can't think of a reason not to include this in 4.6, does that
>work
>> for you?
>>
>>> ---
>>>   xen/include/public/arch-x86/pmu.h   | 22
>++
>>>   xen/include/public/hvm/e820.h   |  3 ++-
>>>   xen/include/public/hvm/hvm_info_table.h |  2 ++
>>>   xen/include/public/hvm/hvm_op.h |  2 ++
>>>   xen/include/public/hvm/hvm_xs_strings.h |  2 ++
>>>   xen/include/public/hvm/params.h |  2 ++
>>>   xen/include/public/io/protocols.h   |  2 ++
>>>   xen/include/public/physdev.h|  2 ++
>>>   xen/include/public/pmu.h| 22
>++
>>>   9 files changed, 58 insertions(+), 1 deletion(-)
>>>
>>> diff --git xen/include/public/arch-x86/pmu.h xen/include/public/arch
>>> -x86/pmu.h
>>> index 1a53888..68ebf12 100644
>>> --- xen/include/public/arch-x86/pmu.h
>>> +++ xen/include/public/arch-x86/pmu.h
>>> @@ -1,5 +1,27 @@
>>> +/*
>>> + * Permission is hereby granted, free of charge, to any person
>obtaining
>>> a copy
>>> + * of this software and associated documentation files (the
>"Software"),
>>> to
>>> + * deal in the Software without restriction, including without
>>> limitation the
>>> + * rights to use, copy, modify, merge, publish, distribute,
>sublicense,
>>> and/or
>>> + * sell copies of the Software, and to permit persons to whom the
>>> Software is
>>> + * furnished to do so, subject to the following conditions:
>>> + *
>>> + * The above copyright notice and this permission notice shall be
>>> included in
>>> + * all copies or substantial portions of the Software.
>>> + *
>>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>>> EXPRESS OR
>>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>>> MERCHANTABILITY,
>>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
>EVENT
>>> SHALL THE
>>> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
>>> OTHER
>>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>>> ARISING
>>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>OTHER
>>> + * DEALINGS IN THE SOFTWARE.
>>> + *
>>> + * Copyright (c) 2015 Oracle and/or its affiliates. All rights
>reserved.
>>> + */
>>> +
>>>   #ifndef __XEN_PUBLIC_ARCH_X86_PMU_H__
>>>   #define __XEN_PUBLIC_ARCH_X86_PMU_H__
>>>   
>>>   /* x86-specific PMU definitions */
>>>   
>>> diff --git xen/include/public/hvm/e820.h
>xen/include/public/hvm/e820.h
>>> index 5bdc227..6c58a37 100644
>>> --- xen/include/public/hvm/e820.h
>>> +++ xen/include/public/hvm/e820.h
>>> @@ -1,6 +1,5 @@
>>> -
>>>   /*
>>>* Permission is hereby granted, free of charge, to any person
>obtaining
>>> a copy
>>>* of this software and associated documentation files (the
>"Software"),
>>> to
>>>* deal in the Software without restriction, including without
>>> limitation the
>>>* rights to use, copy, modify, merge, publish, distribute,
>sublicense,
>>> and/or
>>> @@ -15,10 +14,12 @@
>>>* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
>EVENT
>>> SHALL THE
>>>* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
>OR
>>> OTHER
>>>* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>>> ARISING
>>>* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>OTHER
>>>* DEALINGS IN THE SOFTWARE.
>>> + *
>>> + * Copyright (c) 2006, Keir Fraser
>>>*/
>>>   
>>>   #ifndef __XEN_PUBLIC_HVM_E820_H__
>>>   #define __XEN_PUBLIC_HVM_E820_H__
>>>   
>>> diff --git xen/include/public/hvm/hvm_info_table.h
>>> xen/include/public/hvm/hvm_info_table.h
>>> index 36085fa..9e3f807 100644
>>> --- xen/include/public/hvm/hvm_info_table.h
>>> +++ xen/include/public/hvm/hvm_info_table.h
>>> @@ -18,10 +18,12 @@
>>>* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
>EVENT
>>> SHALL THE
>>>* AUTHORS OR COPYRIGHT 

Re: [Xen-devel] EFI GetNextVariableName hang/crash

[Ross Lagerwall]

On 09/24/2015 03:53 PM, Marek Marczykowski-Górecki wrote:

Hi,

I have well known problem of buggy firmware, where GetNextVariableName
doesn't work from dom0 running on Xen. I've read both threads about
this:
"EFI GetNextVariableName crashes when running under Xen, but not under
Linux. efi-rs=0 works. No memmap issues"
http://lists.xenproject.org/archives/html/xen-devel/2015-01/msg03164.html
"Xen master hangs"
http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04830.html

My system is Dell E6420, BIOS A21

I've tried your workarounds: -mapbs, efi=attr=uc, -noexitboot (with your
patch applied for that). Most tests were done on 4.4.3, but using newer
version (stable-4.5, stable-4.6) doesn't help.

Without any workaround enabled, it simply hangs, with -noexitboot it
crashes (depending on -mapbs and efi=attr=uc the crash is slightly
different). Below I attach one of such crash (with both -mapbs and
efi=attr=uc enabled).

Since this bug is quite common, and on some systems it will never be
fixed in the firmware, I think the most reliable workaround would be to
use SetVirtualAddressMap. Yes, this will break kexec, but at least
system will start. Also on desktop systems (where apparently this bug is
most common) I think very few people care about kexec...

How hard would be to get SetVirtualAddressMap code working? I've tried
that #ifdef-ed code and unsurprisingly it crashes.

=
The console output from SetVirtualAddressMap crash:

(XEN) Xen version 4.4.3-rc1 (user@) (gcc (GCC) 4.9.2 20150212 (Red Hat 
4.9.2-6)) debug=n Thu Sep 24 04:27:51 CEST 2015
(XEN) Latest ChangeSet: Thu Sep 24 03:00:24 2015 +0200 git:48de6e2-dirty
(XEN) Bootloader: EFI
(XEN) Command line: loglvl=all console=com1 com1=115200n1 conswitch=ax 
efi=attr=uc
(XEN) Video information:
(XEN)  VGA is graphics mode 1600x900, 32 bpp
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) EFI RAM map:
(XEN)   - 8000 (reserved)
(XEN)  8000 - 0004e000 (usable)
(XEN)  0004e000 - 000a (reserved)
(XEN)  0010 - 2000 (usable)
(XEN)  2000 - 2020 (reserved)
(XEN)  2020 - 4000 (usable)
(XEN)  4000 - 4020 (reserved)
(XEN)  4020 - 91a36000 (usable)
(XEN)  91a36000 - 91fb5000 (reserved)
(XEN)  91fb5000 - c6b12000 (usable)
(XEN)  c6b12000 - c6b6a000 (reserved)
(XEN)  c6b6a000 - c6be1000 (usable)
(XEN)  c6be1000 - c6c08000 (reserved)
(XEN)  c6c08000 - c6c0c000 (usable)
(XEN)  c6c0c000 - c722d000 (reserved)
(XEN)  c722d000 - c7236000 (usable)
(XEN)  c7236000 - c723f000 (reserved)
(XEN)  c723f000 - c7412000 (usable)
(XEN)  c7412000 - ca9e7000 (reserved)
(XEN)  ca9e7000 - cabe7000 (ACPI NVS)
(XEN)  cabe7000 - cabff000 (ACPI data)
(XEN)  cabff000 - cac0 (reserved)
(XEN)  cb80 - cfa0 (reserved)
(XEN)  fed1c000 - fed2 (reserved)
(XEN)  ffc0 - ffc2 (reserved)
(XEN)  0001 - 00042e00 (usable)
(XEN) ACPI: RSDP CABFEF98, 0024 (r2 DELL  )
(XEN) ACPI: XSDT CABFDE18, 007C (r1 DELLCBX3 6222004 MSFT10013)
(XEN) ACPI: FACP CAB77D98, 00F4 (r4 DELLCBX3 6222004 MSFT10013)
(XEN) ACPI: DSDT CAB45018, 885D (r2 INT430 SYSFexxx 1001 INTL 20090903)
(XEN) ACPI: FACS CABD4D40, 0040
(XEN) ACPI: APIC CABFCF18, 00CC (r2 DELLCBX3 6222004 MSFT10013)
(XEN) ACPI: TCPA CABD5D18, 0032 (r20 0)
(XEN) ACPI: SSDT CAB78A98, 02F9 (r1 DELLTP  TPM 3000 INTL 20090903)
(XEN) ACPI: MCFG CABD5C98, 003C (r1 DELL   SNDYBRDG  6222004 MSFT   97)
(XEN) ACPI: HPET CABD5C18, 0038 (r1 A M I   PCHHPET  6222004 AMI.3)
(XEN) ACPI: BOOT CABD5B98, 0028 (r1 DELL   CBX3  6222004 AMI 10013)
(XEN) ACPI: SSDT CAB5C018, 0804 (r1  PmRef  Cpu0Ist 3000 INTL 20090903)
(XEN) ACPI: SSDT CAB5B018, 0996 (r1  PmRefCpuPm 3000 INTL 20090903)
(XEN) ACPI: DMAR CAB77C18, 00E8 (r1 INTEL  SNB 1 INTL1)
(XEN) ACPI: SLIC CAB65C18, 0176 (r3 DELLCBX3 6222004 MSFT10013)
(XEN) System RAM: 16195MB (16583872kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at -00042e00
(XEN) Domain heap initialised
(XEN) SMBIOS 2.6 present.
(XEN) DMI 2.6 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT - cabd4e40/cabd4d40, 
using 32
(XEN) ACPI: wakeup_vec[cabd4e4c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee0
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 

Re: [Xen-devel] [PATCH v2] x86/bigmem: eliminate struct domain address width restriction

[Jan Beulich]

>>> On 22.09.15 at 14:51,  wrote:
> PDX-es are 64 bits wide in that case, and hence no limit needs to be
> enforced.
> 
> Reported-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 
> Reviewed-by: Andrew Cooper 

Wei - another one I should have Cc-ed you on. Relevant to 4.6 as
that bigmem thing is new.

Jan

> ---
> v2: Use "const unsigned int bits = 0" instead of #define / #undef
> (as suggested by IanC).
> 
> --- unstable.orig/xen/arch/x86/domain.c   2015-09-22 12:54:38.0 
> +0200
> +++ unstable/xen/arch/x86/domain.c2015-08-26 09:24:28.0 +0200
> @@ -204,6 +204,7 @@ smap_check_policy_t smap_policy_change(s
>  return old_policy;
>  }
>  
> +#ifndef CONFIG_BIGMEM
>  /*
>   * The hole may be at or above the 44-bit boundary, so we need to determine
>   * the total bit count until reaching 32 significant (not squashed out) 
> bits
> @@ -225,10 +226,14 @@ static unsigned int __init noinline _dom
>  
>  return bits;
>  }
> +#endif
>  
>  struct domain *alloc_domain_struct(void)
>  {
>  struct domain *d;
> +#ifdef CONFIG_BIGMEM
> +const unsigned int bits = 0;
> +#else
>  /*
>   * We pack the PDX of the domain structure into a 32-bit field within
>   * the page_info structure. Hence the MEMF_bits() restriction.
> @@ -237,6 +242,7 @@ struct domain *alloc_domain_struct(void)
>  
>  if ( unlikely(!bits) )
>   bits = _domain_struct_bits();
> +#endif
>  
>  BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
>  d = alloc_xenheap_pages(0, MEMF_bits(bits));




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

[Xen-devel] [PATCH] xen: sched: rename vcpu_destroy perf counter to vcpu_remove

[Dario Faggioli]

It seems this have had to be done as part of 7e6b926a
("cpupools: Make interface more consistent"), which
renamed the function but not the counter.

In fact, because of cpupools, vcpus are not only removed
from a scheduler when they are destroyed, but also when
domains move between pools.

Make the related statistics counter reflect that more
properly.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Juergen Gross 
Cc: Meng Xu 
Cc: Jan Beulich 
---
 xen/common/sched_credit.c|2 +-
 xen/common/sched_credit2.c   |2 +-
 xen/common/sched_rt.c|2 +-
 xen/include/xen/perfc_defn.h |2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index a1945ac..fb05276 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -927,7 +927,7 @@ csched_vcpu_remove(const struct scheduler *ops, struct vcpu 
*vc)
 struct csched_dom * const sdom = svc->sdom;
 unsigned long flags;
 
-SCHED_STAT_CRANK(vcpu_destroy);
+SCHED_STAT_CRANK(vcpu_remove);
 
 if ( test_and_clear_bit(CSCHED_FLAG_VCPU_PARKED, >flags) )
 {
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 75e0321..135cf88 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -917,7 +917,7 @@ csched2_vcpu_remove(const struct scheduler *ops, struct 
vcpu *vc)
 {
 spinlock_t *lock;
 
-SCHED_STAT_CRANK(vcpu_destroy);
+SCHED_STAT_CRANK(vcpu_remove);
 
 /* Remove from runqueue */
 lock = vcpu_schedule_lock_irq(vc);
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 4372486..31b0a9e 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -648,7 +648,7 @@ rt_vcpu_remove(const struct scheduler *ops, struct vcpu *vc)
 struct rt_dom * const sdom = svc->sdom;
 spinlock_t *lock;
 
-SCHED_STAT_CRANK(vcpu_destroy);
+SCHED_STAT_CRANK(vcpu_remove);
 
 BUG_ON( sdom == NULL );
 
diff --git a/xen/include/xen/perfc_defn.h b/xen/include/xen/perfc_defn.h
index 526002d..43d1dfd 100644
--- a/xen/include/xen/perfc_defn.h
+++ b/xen/include/xen/perfc_defn.h
@@ -20,7 +20,7 @@ PERFCOUNTER(schedule,   "sched: specific 
scheduler")
 PERFCOUNTER(dom_init,   "sched: dom_init")
 PERFCOUNTER(dom_destroy,"sched: dom_destroy")
 PERFCOUNTER(vcpu_init,  "sched: vcpu_init")
-PERFCOUNTER(vcpu_destroy,   "sched: vcpu_destroy")
+PERFCOUNTER(vcpu_remove,"sched: vcpu_remove")
 PERFCOUNTER(vcpu_sleep, "sched: vcpu_sleep")
 PERFCOUNTER(vcpu_wake_running,  "sched: vcpu_wake_running")
 PERFCOUNTER(vcpu_wake_onrunq,   "sched: vcpu_wake_onrunq")


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

[Xen-devel] Commit moratorium for possible rc4

[Ian Campbell]

Wei,

It seems like rc4 is about due, but you are away.

So in anticipation of you getting back and wanting to cut rc4 ASAP we
discussed on IRC and decided to institute a commit moratorium from ~now so
that on Monday when you get back stable-4.6 == staging-4.6 (hopefully!) and
you can either call it rc4 or decide there are other things which need to
be committed before rc4.

Committers, please get any commits you think need to be in rc4 done today
or else wait until Wei is back and gives the all clear.

Cheers,
Ian.

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

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

[Jan Beulich]

>>> On 17.09.15 at 11:35,  wrote:
> Add boot parameter `psr=cdp` to enable CDP at boot time.
> Intel Code/Data Prioritization(CDP) feature is based on CAT. Note that
> cos_max would be half when CDP is on. struct psr_cat_cbm is extended to
> support CDP operation. Extend psr_get_cat_l3_info sysctl to get CDP
> status.
> 
> Signed-off-by: He Chen 

Brief list of changes in v4 missing here.

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

Didn't we already agree to remove this unnecessary u?

> @@ -261,8 +270,14 @@ static struct psr_cat_socket_info 
> *get_cat_socket_info(unsigned int socket)
>  return cat_socket_info + socket;
>  }
>  
> +static inline bool_t cdp_is_enabled(unsigned int socket,
> +unsigned long *cdp_socket_enable)
> +{
> +return (cdp_socket_enable && test_bit(socket, cdp_socket_enable));

Stray pair of parentheses.

> @@ -387,16 +421,16 @@ int psr_set_l3_cbm(struct domain *d, unsigned int 
> socket, uint64_t cbm)
>  }
>  
>  cos = found - map;
> -if ( found->cbm != cbm )
> +if ( found->u.cbm != cbm )
>  {
> -int ret = write_l3_cbm(socket, cos, cbm);
> +int ret = write_l3_cbm(socket, cos, cbm, 0, 0);

I think it would be more natural to pass cbm twice instead of passing
zero for cbm_data. The change also looks misplaced here, as there's
no other caller of write_l3_cbm() until (presumably) the next patch.

> --- a/xen/include/asm-x86/psr.h
> +++ b/xen/include/asm-x86/psr.h
> @@ -27,6 +27,15 @@
>  /* L3 Monitoring Features */
>  #define PSR_CMT_L3_OCCUPANCY   0x1
>  
> +/* CDP Capability */
> +#define PSR_CAT_CDP_CAPABILITY   (1u << 2)
> +
> +/* L3 CDP Enable bit*/
> +#define PSR_L3_QOS_CDP_ENABLE_BIT   0x0
> +
> +/* L3 CDP flag bit */
> +#define PSR_CAT_FLAG_L3_CDP   (1u << 0)

Afaict this is the same as ...

> @@ -704,6 +704,8 @@ struct xen_sysctl_psr_cat_op {
>  struct {
>  uint32_t cbm_len;   /* OUT: CBM length */
>  uint32_t cos_max;   /* OUT: Maximum COS */
> +#define XEN_SYSCTL_PSR_CAT_L3_CDP   (1u << 0)

... this. In which case only the latter (public) one should be kept.

Also at the very least the # belongs in column 1.

Jan


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

Re: [Xen-devel] [PATCH] Add missing license and copyright statements to public interface headers.

[Wei Liu]

On Thu, Sep 24, 2015 at 11:45:56AM +0100, Ian Campbell wrote:
> On Tue, 2015-09-22 at 16:02 +0200, Mike Belopuhov wrote:
> > The copyright line indicates a person, a group of people and/or a company
> > granting rights stated in the license text and is a required part of the
> > license.
> > 
> > The year of the copyright is chosen to be the same as when the license has
> > been applied to the file or when the file has been created in case there
> > was no license.  It is possible to update or add additional years if major
> > changes have been done to the the file, but is generally not a requirement.
> > 
> > Signed-off-by: Mike Belopuhov 
> 
> LGTM, thanks. I'll wait for Konrad and/or Boris to confirm that Oracle are
> happy with this wording etc. Keir's one matches all his others so I think
> we can assume it is ok unless we hear otherwise.
> 
> Wei, I can't think of a reason not to include this in 4.6, does that work
> for you?
> 

Of course this should be included in 4.6.

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

Re: [Xen-devel] Commit moratorium for possible rc4

[Wei Liu]

On Thu, Sep 24, 2015 at 04:37:14PM +0100, Ian Campbell wrote:
> Wei,
> 
> It seems like rc4 is about due, but you are away.
> 
> So in anticipation of you getting back and wanting to cut rc4 ASAP we
> discussed on IRC and decided to institute a commit moratorium from ~now so
> that on Monday when you get back stable-4.6 == staging-4.6 (hopefully!) and
> you can either call it rc4 or decide there are other things which need to
> be committed before rc4.
> 
> Committers, please get any commits you think need to be in rc4 done today
> or else wait until Wei is back and gives the all clear.
> 

Thanks for doing this!

(I was planning to send an email tomorrow saying similar things)

> Cheers,
> Ian.

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

Re: [Xen-devel] [PATCH v2] x86/bigmem: eliminate struct domain address width restriction

[Wei Liu]

On Thu, Sep 24, 2015 at 09:35:50AM -0600, Jan Beulich wrote:
> >>> On 22.09.15 at 14:51,  wrote:
> > PDX-es are 64 bits wide in that case, and hence no limit needs to be
> > enforced.
> > 
> > Reported-by: Andrew Cooper 
> > Signed-off-by: Jan Beulich 
> > Reviewed-by: Andrew Cooper 
> 
> Wei - another one I should have Cc-ed you on. Relevant to 4.6 as
> that bigmem thing is new.
> 

Release-acked-by: Wei Liu 

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

Re: [Xen-devel] [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries

[Ian Campbell]

(dropping mini-os-devel and some cc's, adding David)

Hi David,

On Wed, 2015-07-15 at 16:46 +0100, Ian Campbell wrote:
> (this is clearly not 4.6 material, aiming for 4.7)
> 
> In <1431963008.4944.80.ca...@citrix.com> I proposed stabilising some
> parts of the libxenctrl API/ABI by disaggregating into separate
> libraries.
> 
[...]
> Still to come would be libraries for specific out of tree purposes
> (device model, kexec),

For kexec I have ("S" column is "interface to the left is stable A(BP)I"):

Interface  S Underlying Interface   S Other 
users
-- - -- - 
---
`xc__hypercall_buffer_array_alloc`   Should use libxencall
`xc_hypercall_buffer_array_create`   Should use libxencall
`xc_hypercall_buffer_array_des...`   Should use libxencall
`xc_interface_close`
`xc_interface_open`
`xc_get_max_cpus`  N `xc_physinfo=SYSCTL_physinfo`  N many
`xc_version`   N `XENVER_capabilities`  Y 
libxl,others
`xc_get_machine_memory_map`N `XENMEM_machine_memory_map`Y libxl

`xc_kexec_exec`N `KEXEC_CMD_kexec`  Y None
`xc_kexec_get_range`   N `KEXEC_CMD_kexec_get_range`Y None
`xc_kexec_load`N `KEXEC_CMD_kexec_load` Y None
`xc_kexec_unload`  N `KEXEC_CMD_kexec_unload`   Y None

It seems to me that there is not all that much utility to providing a
stable libxenkexec containing those last four, and that they might as well
be moved to kexec-tools where they can be implemented using the new
libxencall (which also includes the buffer allocation stuff for the first
3).

What do you think?

That would just leave xc_get_max_cpus, xc_version and
xc_get_machine_memory_map, which I'm still pondering.

Ian.

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

[Xen-devel] List etiquette [Was: Re: EFI GetNextVariableName hang/crash]

[Dario Faggioli]

[Unrelated to anything technical, dropping some Cc-s]

On Thu, 2015-09-24 at 16:26 +0100, Ross Lagerwall wrote:
> On 09/24/2015 03:53 PM, Marek Marczykowski-Górecki wrote:

> > (XEN) Xen call trace:
> > (XEN)[] ca9e6f98
> > (XEN)[] csched_vcpu_wake+0x1b7/0x4b0
> > (XEN)[] efi_runtime_call+0x76f/0x870
> > (XEN)[] efi_runtime_call+0x6ed/0x870
> > (XEN)[] do_platform_op+0x504/0x1300
> > (XEN)[] syscall_enter+0xa9/0xae
> > (XEN)
> > (XEN) Pagetable walk from ca9e6f98:
> > (XEN)  L4[0x000] = c6a9f063 
> > (XEN)  L3[0x003] = 93e74063 
> > (XEN)  L2[0x054] = c6c0b063 
> > (XEN)  L1[0x1e6] =  
> > [   32.312081] a(XEN)
> > (XEN) 
> > (XEN) Panic on CPU 3:
> > (XEN) FATAL PAGE FAULT
> > (XEN) [error_code=0010]
> > (XEN) Faulting linear address: ca9e6f98
> > (XEN) 
> > (XEN)
> > (XEN) Reboot in five seconds...
> > 

> XenServer has a patch specifically for this issue (which seems to
> happen 
> on Dell machines):
> https://github.com/xenserver/xen-4.6.pg/blob/master/master/0002-efi-E
> nsure-incorrectly-typed-runtime-services-get-ma.patch
> 
Can you trim when quoting? It's certainly not ideal to have to scroll
down so much to get to the real content, especially in cases like this,
when it's really not necessary.

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



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

Re: [Xen-devel] [PATCH] x86/PV: properly populate descriptor tables

[Wei Liu]

On Wed, Sep 23, 2015 at 09:34:16AM -0600, Jan Beulich wrote:
> Us extending the GDT limit past the Xen descriptors so far meant that
> guests (including user mode programs) accessing any descriptor table
> slot above the original OS'es limit but below the first Xen descriptor
> caused a #PF, converted to a #GP in our #PF handler. Which is quite
> different from the native behavior, where some of such accesses (LAR
> and LSL) don't fault. Mimic that behavior by mapping a blank page into
> unused slots.
> 
> While not strictly required, treat the LDT the same for consistency.
> 
> Reported-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 
> ---
> Not sure about 4.6 here: Beyond Andrew noticing I don't think anyone
> ran into this issue in a real world environment, and hence it doesn't
> seem to be too critical to get this fixed.
> 

Given that this is not absolutely essential (fix critical bug or
regressions) I would like it to go in after 4.6.

Wei.

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

[Xen-devel] [linux-3.4 test] 62277: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail baseline untested
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail blocked in 30511
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 30511
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 30511
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 30511

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

version targeted for testing:
 linux4a55c0cfdd8a8b0c39eba5e696c36c33d0879684
baseline version:
 linuxbb4a05a0400ed6d2f1e13d1f82f289ff74300a70

Last test of basis30511  2014-09-29 16:37:46 Z  359 days
Failing since 32004  2014-12-02 04:10:03 Z  296 days  220 attempts
Testing same since62277  2015-09-22 10:38:22 Z2 days1 attempts


591 people touched revisions under test,
not listing them all

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  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 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 fail
 test-amd64-amd64-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-xl-xsm  pass
 test-amd64-i386-xl-xsm   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   fail
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 

[Xen-devel] Make ready for 4.6! Xen Project Document Day is Wednesday, Sept 30

[Russ Pavlicek]

Our next Xen Project Document Day is this Wednesday, September 30!

OUR THEME OF THE MONTH: "Ready for 4.6"

This month, we prepare for the release of Xen Project 4.6 early next
month. We need to make sure that users of the new release can find the
documentation they need to make it all work. So, this month, we need
to:

- Add new documentation for new features
- Modify existing documentation for anything which is changing in the
newest release, and
- Deprecate old documentation, letting people know that certain
information is applies only to older releases

Check out the current documentation, and anything which doesn't map to
4.6 (or 4.5, for that matter) commands or best practices will need
improvement.

More detailed information can be found in the TODO document (below).
And, as always, feel free to add any other documentation which you
believe to be necessary.

All the information you need to participate in Document Day is here:

http://wiki.xenproject.org/wiki/Xen_Document_Days

Also take a look at the current TODO list to see other items which
need attention:

http://wiki.xenproject.org/wiki/Xen_Document_Days/TODO

Please think about how you can help out.  If you haven't requested
to be made a Wiki editor, save time and do it now so you are ready to
go on Document Day.  Just fill out the form below:

http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html

We hope to see you Wednesday in #xendocs!

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

Re: [Xen-devel] [BUG] XEN domU crash when PV grub chainloads 32-bit domU grub

[Andreas Sundstrom]

On 2015-09-23 16:18, Ian Campbell wrote:
> On Wed, 2015-09-23 at 12:47 +, Andreas Sundstrom wrote:
>> Citerar Ian Campbell :
>>
>>> Along those lines, if the _host_ has buckets of RAM then might it be
>>> worth
>>> restricting it in case the issue is with getting MFNs which are not
>>> representably by the 32-bit PV interfaces? (IIRC the limit is ~160G due
>>> to
>>> the size of the m2p hole, a 32-bit MFN spans 16TB so it's unlikely to
>>> be
>>> that).
>>>
>>> Likewise maybe the issue is with full addresses which don't fit in a 32
>>> -bit
>>> number (which is maybe more likely to happen if grub uses a 1:1 mapping
>>> like I would guess it does), so limiting the host to <4GB might also be
>>> interesting?
>>>
>>
>> If this was meant for me I will need more information to understand  
>> what to test.
>> dom0 has either 12G or 8G memory in my test machines if that makes a  
>> difference.
> 
> It was, sorry for not being clear.
> 
> How much memory do the test machines have?
> 
> If it is more than 160G then try booting with "mem=160G" on the hypervisor
> (not Linux) command line. You can just edit that in via grub.
> 
> Then try with mem=4G (which might require shrinking dom0 too of course).

Well as I said my test machines only have 12 and 8G of memory.
I did a quick test with mem=2G though just to be sure, it failed on
first attempt.

/Andreas


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

[Xen-devel] [OSSTEST PATCH 2/3] Shell fixup: Make all invocations of `.' (`source') use ./

[Ian Jackson]

In POSIX, `.' (the shell builtin) respects PATH, and does not search
`.' (the current directory).

Change all the invocations which refer to files which are part of
osstest to say `. ./foo' instead of simply `. foo'.

I have checked the results of
  git-grep '^[ \t]*\. [^./]'
after this patch and the remaining five hits are of no concern.

As a double-check of my hand-editing, I have also done this
  perl -i~ -pe 's#^(\s*\. )\./#$1#' *
and verified that the resulting tree is almost identical to that
before this commit.  There is one difference, where the original
code already said `. ./job'.

Signed-off-by: Ian Jackson 
---
 ap-fetch-version   |6 +++---
 ap-fetch-version-baseline  |2 +-
 ap-fetch-version-baseline-late |6 +++---
 ap-fetch-version-old   |6 +++---
 ap-print-url   |6 +++---
 ap-push|6 +++---
 ap-qemu-revision   |4 ++--
 ap-qemu-url|4 ++--
 cr-all-branch-statuses |2 +-
 cr-daily-branch|4 ++--
 cr-try-bisect  |4 ++--
 cr-try-bisect-adhoc|6 +++---
 cri-args-hostlists |6 +++---
 cri-common |4 ++--
 cri-lock-repos |2 +-
 make-distros-flight|6 +++---
 make-flight|8 
 mg-all-branch-statuses |2 +-
 mg-cpu-microcode-update|4 ++--
 mg-debian-installer-update |4 ++--
 mg-debian-installer-update-all |2 +-
 mg-execute-flight  |2 +-
 mg-pxe-loader-update   |4 ++--
 standalone |2 +-
 standalone-reset   |4 ++--
 25 files changed, 53 insertions(+), 53 deletions(-)

diff --git a/ap-fetch-version b/ap-fetch-version
index 62adf79..086aa62 100755
--- a/ap-fetch-version
+++ b/ap-fetch-version
@@ -20,10 +20,10 @@
 set -e
 
 branch=$1
-. cri-lock-repos
-. cri-common
+. ./cri-lock-repos
+. ./cri-common
 select_xenbranch
-. ap-common
+. ./ap-common
 
 if info_linux_tree "$branch"; then
repo_tree_rev_fetch_git linux \
diff --git a/ap-fetch-version-baseline b/ap-fetch-version-baseline
index e693e16..8889d1e 100755
--- a/ap-fetch-version-baseline
+++ b/ap-fetch-version-baseline
@@ -21,7 +21,7 @@ set -e
 
 branch=$1
 
-. cri-lock-repos
+. ./cri-lock-repos
 
 : ${BASE_TREE_LINUX:=git://xenbits.xen.org/people/ianc/linux-2.6.git}
 : ${BASE_TAG_LINUX:=xen/next-2.6.32}
diff --git a/ap-fetch-version-baseline-late b/ap-fetch-version-baseline-late
index ef1a8b1..3db443d 100755
--- a/ap-fetch-version-baseline-late
+++ b/ap-fetch-version-baseline-late
@@ -22,10 +22,10 @@ set -e
 branch=$1
 new=$2
 
-. cri-lock-repos
-. cri-common
+. ./cri-lock-repos
+. ./cri-common
 select_xenbranch
-. ap-common
+. ./ap-common
 
 case "$branch" in
 
diff --git a/ap-fetch-version-old b/ap-fetch-version-old
index 716fc8f..9d5487a 100755
--- a/ap-fetch-version-old
+++ b/ap-fetch-version-old
@@ -20,10 +20,10 @@
 set -e
 
 branch=$1
-. cri-lock-repos
-. cri-common
+. ./cri-lock-repos
+. ./cri-common
 select_xenbranch
-. ap-common
+. ./ap-common
 
 : ${BASE_TAG_LINUX2639:=tested/2.6.39.x}
 : ${BASE_LOCALREV_LINUX:=daily-cron.$branch.old}
diff --git a/ap-print-url b/ap-print-url
index c161169..1b178c7 100755
--- a/ap-print-url
+++ b/ap-print-url
@@ -20,10 +20,10 @@
 set -e
 
 branch=$1
-. cri-lock-repos
-. cri-common
+. ./cri-lock-repos
+. ./cri-common
 select_xenbranch
-. ap-common
+. ./ap-common
 
 if info_linux_tree "$branch"; then
echo $TREE_LINUX_THIS
diff --git a/ap-push b/ap-push
index aa0ec3d..ea21887 100755
--- a/ap-push
+++ b/ap-push
@@ -21,13 +21,13 @@ set -ex
 
 branch=$1
 revision=$2
-. cri-lock-repos
-. cri-common
+. ./cri-lock-repos
+. ./cri-common
 select_xenbranch
 
 : ${TAG_LINUX2639:=tested/2.6.39.x}
 
-. ap-common
+. ./ap-common
 
 TREE_LINUX=$PUSH_TREE_LINUX
 TREE_QEMU_MAINLINE=$PUSH_TREE_QEMU_MAINLINE
diff --git a/ap-qemu-revision b/ap-qemu-revision
index abfa650..de105ca 100755
--- a/ap-qemu-revision
+++ b/ap-qemu-revision
@@ -22,8 +22,8 @@ set -e
 xenbranch=$1
 xenrevision=$2
 
-. cri-lock-repos
-. ap-common
+. ./cri-lock-repos
+. ./ap-common
 
 cd "$repos/xen"
 git cat-file blob $xenrevision:Config.mk | perl -ne '
diff --git a/ap-qemu-url b/ap-qemu-url
index 1161a46..6ed704a 100755
--- a/ap-qemu-url
+++ b/ap-qemu-url
@@ -21,7 +21,7 @@ set -e
 
 xenbranch=$1
 
-. cri-lock-repos
-. ap-common
+. ./cri-lock-repos
+. ./ap-common
 
 echo $TREE_QEMU
diff --git a/cr-all-branch-statuses b/cr-all-branch-statuses
index f9885db..f4ed46e 100755
--- a/cr-all-branch-statuses
+++ b/cr-all-branch-statuses
@@ -18,7 +18,7 @@
 
 set -ex
 
-. cri-args-hostlists
+. ./cri-args-hostlists
 branch=$1; shift
 
 check_stop all-branch-statuses.
diff --git a/cr-daily-branch b/cr-daily-branch
index dd9c30a..06f4b38 100755
--- a/cr-daily-branch
+++ b/cr-daily-branch
@@ -19,8 +19,8 @@
 
 set -ex
 
-. cri-args-hostlists

[Xen-devel] [OSSTEST PATCH 3/3] Shell fixup: Use bash in posix mode

[Ian Jackson]

When bash is started as /bin/sh it run in posix compatibility mode.
But when invoked as /bin/bash it does some things ... differently.

Most notably:

   Subshells spawned to execute command substitutions inherit the
   value of the -e option from the parent shell.  When not in posix
   mode, bash clears the -e option in such subshells.

It is a mystery why anyone thought the `non-posix' behaviour was
desirable.  One effect in practice is that osstest's cr-daily-branch
can blunder on if one of its version fetches fails.

AFAICT the only documented way to get rid of this anomalous behaviour
is to switch bash to posix mode.  I have read through the wheezy
bash(1) manpage and searched for posix, and the following behavioural
differences are described:

 * Differences in interative startup (not relevant to us).
 * Minor (irrelevant) differences in which startup files are read
   during noninteractive startup.  (Eg, BASH_ENV not honoured.)
 * Differences to the parsing of invocations of `time'
 * `test a == b' may be unsupported (but it's wrong and we say `=')
 * -e not inherited by some subshells (this is what I am trying to fix)
 * `.' and `source' do not search the cwd.
 * `set' with no arguments does not print shell functions etc.

So I think, with the previous patch, that these changes are all
desirable or at least harmless.

I have not added `set -o posix' to shell script fragments invoked by
various scripts (eg Perl and Tcl scripts).  Those scripts might be
processed by bash if /bin/sh is bash, but when is invoked as sh it
runs in posix mode anyway.

I have done some ad-hoc testing but it seems like much of this is
difficult to test.  I suggest we push it at a time when we can keep a
close eye on the behaviour.

Signed-off-by: Ian Jackson 
---
 ap-fetch-version|2 +-
 ap-fetch-version-baseline   |2 +-
 ap-fetch-version-baseline-late  |2 +-
 ap-fetch-version-old|2 +-
 ap-print-url|2 +-
 ap-push |2 +-
 ap-qemu-revision|2 +-
 ap-qemu-url |2 +-
 cr-all-branch-statuses  |2 +-
 cr-daily-branch |2 +-
 cr-for-branches |2 +-
 cr-try-bisect   |2 +-
 cr-try-bisect-adhoc |2 +-
 cri-getprevxenbranch|2 +-
 invoke-daemon   |4 +++-
 make-distros-flight |2 +-
 make-flight |2 +-
 mg-adjust-flight-makexrefs  |2 +-
 mg-all-branch-statuses  |2 +-
 mg-branch-setup |2 +-
 mg-cpu-microcode-update |2 +-
 mg-debian-installer-update  |2 +-
 mg-debian-installer-update-all  |2 +-
 mg-execute-flight   |2 +-
 mg-pxe-loader-update|2 +-
 mg-update-live  |2 +-
 sa-forget-flight|2 +-
 sa-init-db  |2 +-
 sg-hg-heads |2 +-
 standalone  |2 +-
 standalone-generate-dump-flight-runvars |2 +-
 standalone-reset|2 +-
 32 files changed, 34 insertions(+), 32 deletions(-)

diff --git a/ap-fetch-version b/ap-fetch-version
index 086aa62..6fa7588 100755
--- a/ap-fetch-version
+++ b/ap-fetch-version
@@ -17,7 +17,7 @@
 # along with this program.  If not, see .
 
 
-set -e
+set -e -o posix
 
 branch=$1
 . ./cri-lock-repos
diff --git a/ap-fetch-version-baseline b/ap-fetch-version-baseline
index 8889d1e..2e42508 100755
--- a/ap-fetch-version-baseline
+++ b/ap-fetch-version-baseline
@@ -17,7 +17,7 @@
 # along with this program.  If not, see .
 
 
-set -e
+set -e -o posix
 
 branch=$1
 
diff --git a/ap-fetch-version-baseline-late b/ap-fetch-version-baseline-late
index 3db443d..9856ec9 100755
--- a/ap-fetch-version-baseline-late
+++ b/ap-fetch-version-baseline-late
@@ -17,7 +17,7 @@
 # along with this program.  If not, see .
 
 
-set -e
+set -e -o posix
 
 branch=$1
 new=$2
diff --git a/ap-fetch-version-old b/ap-fetch-version-old
index 9d5487a..66d51f8 100755
--- a/ap-fetch-version-old
+++ b/ap-fetch-version-old
@@ -17,7 +17,7 @@
 # along with this program.  If not, see .
 
 
-set -e
+set -e -o posix
 
 branch=$1
 . ./cri-lock-repos
diff --git a/ap-print-url b/ap-print-url
index 1b178c7..4088852 100755
--- a/ap-print-url
+++ b/ap-print-url
@@ -17,7 +17,7 @@
 # along with this program.  If not, see .
 
 
-set -e
+set -e -o posix
 
 branch=$1
 . ./cri-lock-repos
diff --git a/ap-push b/ap-push
index ea21887..d2195f2 

[Xen-devel] [OSSTEST PATCH 1/3] Remove obsolete file "test.sched"

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 test.sched |5 -
 1 file changed, 5 deletions(-)
 delete mode 100755 test.sched

diff --git a/test.sched b/test.sched
deleted file mode 100755
index ca309fb..000
--- a/test.sched
+++ /dev/null
@@ -1,5 +0,0 @@
-#!/bin/sh
-set -e
-./ts-install-debian
-./ts-build-prep
-./ts-build-xen
-- 
1.7.10.4


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

Re: [Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Ian Campbell]

On Thu, 2015-09-24 at 20:33 +0100, Stefano Stabellini wrote:
> On Thu, 24 Sep 2015, Ian Campbell wrote:
> > On Wed, 2015-09-23 at 18:36 +0100, Stefano Stabellini wrote:
> > > On Wed, 23 Sep 2015, Ian Campbell wrote:
> > > > On Tue, 2015-09-22 at 22:31 +0100, Stefano Stabellini wrote: 
> > > > > The oldest Xen version I build-test for every pull request is
> Xen 4.0.0,
> > 
> > I setup a build trees for 4.0 thru 4.6 yesterday to test this, what
> a
> > pain 4.1 and 4.0 are to build with a modern gcc! (Mostly newer
> compiler
> > warnings and mostly, but not all, fixes which I could just backport
> > from newer Xen, the exceptions were a couple of things which were
> > removed before they needed to be fixed)
> > 
> > > > > I think it is very reasonable to remove anything older than
> that.
> > > > > I am OK with removing Xen 4.0.0 too, but I would like a
> warning to be
> > > > > sent ahead of time to qemu-devel to see if anybody complains.
> > > > 
> > > > There is not much point in removing <=3.4 support and keeping
> 4.0, since
> > > > 4.0.0 was the last one which used a plain int as a handle,
> anything older
> > > > than 4.0.0 is trivial if 4.0.0 is supported.
> > > > 
> > > > One approach I am considering in order to keep 4.0.0 support
> and earlier
> > > > was to turn the "int fd" for <=4.0 into a pointer by having the
> open
> > > > wrapper do malloc(sizeof int) and the using wrappers do
> xc_foo(*handle).
> > > > 
> > > > This way all the different variants take pointers and we have
> less hoops to
> > > > jump through to typedef everything in the correct way for each
> variant.
> > > > 
> > > > If you would rather avoid doing that then I think dropping
> 4.0.0 support
> > > > would be the way to go and I'll send a mail to qemu-devel.
> > >  
> > > I would rather drop 4.0 support.
> > 
> > Supporting 4.0 didn't turn out quite as ugly as I had feared.
> > 
> > So before I send an email to qemu-devel to propose dropping 4.0
> what do
> > you think of the following which handles the evtchn case, there is
> a
> > similar patch for gnttab and a (yet to be written) patch for the
> > foreign memory mapping case.
> > 
> > The relevant bit for this discussion is the 4.0.0 definition of
> > xenevtchn_open in xen_common.h, the rest is just adjusting it to
> use
> > the API of the new library (for reasons explained in the commit
> > message).
> 
> I think that it is OK in principle.
> 
> 
> > diff --git a/include/hw/xen/xen_common.h
> b/include/hw/xen/xen_common.h
> > index 5923290..5700c1b 100644
> > --- a/include/hw/xen/xen_common.h
> > +++ b/include/hw/xen/xen_common.h
> > @@ -39,17 +39,37 @@ static inline void *xc_map_foreign_bulk(int
> xc_handle, uint32_t dom, int prot,
> >  #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 410
> >  
> >  typedef int XenXC;
> > -typedef int XenEvtchn;
> > +typedef int xenevtchn_handle;
> >  typedef int XenGnttab;
>  
> ...
> 
> > @@ -108,17 +128,20 @@ static inline void xs_close(struct xs_handle
> *xsh)
> >  #else
> >  
> >  typedef xc_interface *XenXC;
> > -typedef xc_evtchn *XenEvtchn;
> > +typedef xc_evtchn xenevtchn_handle;
> >  typedef xc_gnttab *XenGnttab;
> >  
> 
> There is no reasons why we couldn't have a small compat shim on Xen >
> 4.6 too, so I would change the definition of XenEvtchn for newer
> versions of Xen and avoid some of the renaming in this patch to reduce
> the changes.
> 
> For example, why not define xc_evtchn_fd as xenevtchn_fd for Xen > 4.6?
> So that we don't need to go and rename all the call sites?

The idea was that the code would use the new stable API names from the
stable libraries going forward, rather than using a shim to turn the
stable APIs back into the old ones.

Ian.

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

[Xen-devel] [PATCH] vt-d: Fix IM bit mask and unmask of Fault Event Control Register.

[Quan Xu]

Signed-off-by: Quan Xu 
---
 xen/drivers/passthrough/vtd/iommu.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 3d98fea..f31d41b 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -992,10 +992,13 @@ static void dma_msi_unmask(struct irq_desc *desc)
 {
 struct iommu *iommu = desc->action->dev_id;
 unsigned long flags;
+u32 sts;
 
 /* unmask it */
 spin_lock_irqsave(>register_lock, flags);
-dmar_writel(iommu->reg, DMAR_FECTL_REG, 0);
+sts = dmar_readl(iommu->reg, DMAR_FECTL_REG);
+sts &= ~DMA_FECTL_IM;
+dmar_writel(iommu->reg, DMAR_FECTL_REG, sts);
 spin_unlock_irqrestore(>register_lock, flags);
 iommu->msi.msi_attrib.host_masked = 0;
 }
@@ -1004,10 +1007,13 @@ static void dma_msi_mask(struct irq_desc *desc)
 {
 unsigned long flags;
 struct iommu *iommu = desc->action->dev_id;
+u32 sts;
 
 /* mask it */
 spin_lock_irqsave(>register_lock, flags);
-dmar_writel(iommu->reg, DMAR_FECTL_REG, DMA_FECTL_IM);
+sts = dmar_readl(iommu->reg, DMAR_FECTL_REG);
+sts |= DMA_FECTL_IM;
+dmar_writel(iommu->reg, DMAR_FECTL_REG, sts);
 spin_unlock_irqrestore(>register_lock, flags);
 iommu->msi.msi_attrib.host_masked = 1;
 }
-- 
1.8.3.2


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

[Xen-devel] [PATCH V7 4/7] libxl: add libxl_device_usb_assignable_list API

[Chunyan Liu]

Add API for listing assignable USB devices info.
Assignable USB device means the USB device type is assignable and
it's not assigned to any guest yet.

Signed-off-by: Chunyan Liu 
---
This could be squashed with previous patch. Split because there is
some dispute on this. If this is acceptable, could be squashed,
otherwise could be removed.

 tools/libxl/libxl.h   |  3 +++
 tools/libxl/libxl_pvusb.c | 55 +++
 2 files changed, 58 insertions(+)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 633bfc1..c41b9de 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1450,6 +1450,9 @@ int libxl_device_usbctrl_getinfo(libxl_ctx *ctx, uint32_t 
domid,
  libxl_usbctrlinfo *usbctrlinfo);
 
 /* USB Devices */
+libxl_device_usb *
+libxl_device_usb_assignable_list(libxl_ctx *ctx, int *num);
+
 int libxl_device_usb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_usb *usb,
  const libxl_asyncop_how *ao_how)
  LIBXL_EXTERNAL_CALLERS_ONLY;
diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_pvusb.c
index d4b997f..b683e60 100644
--- a/tools/libxl/libxl_pvusb.c
+++ b/tools/libxl/libxl_pvusb.c
@@ -573,6 +573,61 @@ static bool is_usb_assignable(libxl__gc *gc, 
libxl_device_usb *usb)
 return classcode != USBHUB_CLASS_CODE;
 }
 
+libxl_device_usb *
+libxl_device_usb_assignable_list(libxl_ctx *ctx, int *num)
+{
+GC_INIT(ctx);
+libxl_device_usb *usbs = NULL;
+libxl_device_usb *assigned;
+int num_assigned;
+struct dirent *de;
+DIR *dir;
+
+*num = 0;
+
+if (get_assigned_devices(gc, , _assigned) < 0) {
+LOG(ERROR, "cannot determine if device is assigned");
+goto out;
+}
+
+if (!(dir = opendir(SYSFS_USB_DEV)))
+goto out;
+
+while ((de = readdir(dir))) {
+libxl_device_usb *usb;
+uint8_t bus = -1, addr = -1;
+
+if (!de->d_name)
+continue;
+
+usb_busaddr_from_busid(gc, de->d_name, , );
+if (bus < 1 || addr < 1)
+continue;
+
+GCNEW(usb);
+usb->u.hostdev.hostbus = bus;
+usb->u.hostdev.hostaddr = addr;
+
+if (!is_usb_assignable(gc, usb))
+continue;
+
+if (is_usbdev_in_array(assigned, num_assigned, usb))
+continue;
+
+usbs = libxl__realloc(NOGC, usbs, sizeof(*usbs) * (*num + 1));
+libxl_device_usb_init(usbs + *num);
+usbs[*num].u.hostdev.hostbus = bus;
+usbs[*num].u.hostdev.hostaddr = addr;
+(*num)++;
+}
+
+closedir(dir);
+
+out:
+GC_FREE;
+return usbs;
+}
+
 /* get usb devices under certain usb controller */
 static int
 libxl__device_usb_list_for_usbctrl(libxl__gc *gc, uint32_t domid,
-- 
2.1.4


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