[Xen-devel] [PATCH] xen/pci: correct comment of pci_device_detect()

[Tiejun Chen]

Actually we always return 1 if pci device exists.

Signed-off-by: Tiejun Chen 
---
 xen/drivers/passthrough/pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 862e20f..6cb6e00 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -905,7 +905,7 @@ out:
 }
 
 /*
- * detect pci device, return 0 if it exists, or return 0
+ * detect pci device, return 1 if it exists, or return 0
  */
 int __init pci_device_detect(u16 seg, u8 bus, u8 dev, u8 func)
 {
-- 
1.9.1


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

Re: [Xen-devel] [PATCH v5 1/5] pci: add pci_iomap_wc() variants

[David Airlie]

> On Tue, May 19, 2015 at 4:02 PM, Bjorn Helgaas  wrote:
> > [-cc Venkatesh (bouncing)
> >
> > On Tue, May 19, 2015 at 5:46 PM, Luis R. Rodriguez
> >  wrote:
> >> On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas 
> >> wrote:
> >>> Acked-by: Bjorn Helgaas 
> >>
> >> Thanks! Who's tree should this go through?
> >
> > I don't know.  This is the only patch that went to linux-pci, so I
> > haven't seen the rest.
> 
> Oh I only rev'd a v5 for 1/5 as that's the only one that had feedback
> asking for changes.
> 
> Patch v4 2/5 was for "lib: devres: add pcim_iomap_wc() variants", you
> had questions about EXPORT_SYMBOL_GPL() and the fact that this is not
> yet used. I replied. This patch can then be ignored but again, I'd
> hate for folks to go in and try to add a non EXPORT_SYMBOL_GPL()
> symbol of this.
> 
> Patches v4 3-5 remain intact, I had addressed it to you, but failed to
> Cc linux-pci, I'll go ahead and bounce those now.
> 
> Just today Dave Arlie provided a Reviewed-by to some simple
> framebuffer device driver changes. I wonder if these changes should go
> through the framebuffer tree provided you already gave the Acked-by
> for the PCI parts, or if the PCI parts should go in first and only
> later (I guess we'd have to wait) then intake the driver changes that
> use the symbol.
> 
> What we decide should likely also apply to the series that adds
> pci_ioremap_wc_bar() and makes use of it on drivers.
> 
> Dave, Tomi, any preference?
> 

Maybe send Bjorn a pull request with a tree with the pci changes, and the fb 
changes reviewed-by me and acked by Tomi.

Seems like it could be the simplest path forward.

Dave.

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

Re: [Xen-devel] [RFC][PATCH 01/13] tools: introduce some new parameters to set rdm policy

[Chen, Tiejun]

On 2015/5/19 19:00, Wei Liu wrote:

On Tue, May 19, 2015 at 06:50:11PM +0800, Chen, Tiejun wrote:

On 2015/5/19 17:42, Wei Liu wrote:


[...]


want you want?


We have a little bit of complexity here,

"Default per-device RDM policy is 'force', while default global RDM policy
is 'try'. When both policies are specified on a given region, 'force' is
always preferred."



This is going to be done in actual code anyway.

This type is used both in global and per-device setting, so I envisage


Yes.


this to have an invalid value to start with. Appropriate default values


Sounds I should set this,

+libxl_rdm_reserve_flag = Enumeration("rdm_reserve_flag", [
+(-1, "invalid"),
+(0, "strict"),
+(1, "relaxed"),
+], init_val = "LIBXL_RDM_RESERVE_FLAG_INVALID")
+





Yet another question about this feature. The current setup suggests that
we must choose a policy, either "strict" or "relaxed", i.e. there is no
way to disable this feature, as in there is no "none" policy to skip
checking rdm conflict.

AIUI this feature is more like a bug fix to existing problem, so we
always want to enable it. And the default relaxed policy makes sure we
don't break guest that was working before this feature. Do I understand
this correctly?

If we risk breaking existing guests, we might want to consider adding a
"none" (name subject to improvement) policy to just skip RDM all
together.


We have this definition,

+libxl_rdm_reserve_type = Enumeration("rdm_reserve_type", [
+(0, "none"),
+(1, "host"),
+])

If we set 'type=none', this means we would do nothing actually since we
don't expose any rdms to guest. This behavior will ensue we go back the
existing scenario without our patch.



But this only works with global configuration and individual
configuration in PCI spec trumps this, right?


You're right.



Think about how an old configuration migrated to newer version of Xen
should work. For example, I don't have rdm= but have pci=['']. Do we
need to make sure this still work? I guess the answer is if it already


Definitely.


works before RDM it should continue to work as there is really no
conflict before. In this case whether  we enable RDM or not doesn't make
a difference to a guest that's already working before. Am I right?


I think we can set the default 'type' to NONE,

libxl__rdm_setdefault()
{
b_info->rdm.type = LIBXL_RDM_RESERVE_TYPE_NONE;

and then,

libxl__domain_device_construct_rdm()
{
...
/* Might not expose rdm. */
if (type == LIBXL_RDM_RESERVE_TYPE_NONE)
return 0;

This means we don't expose any rdm so we would never concern any policy 
anymore.



Thanks
Tiejun






Yes, and then don't forget to set the value to appropriate value in the
_setdefault functions for different types.




[...]


Spaces.


+if ( NULL == (buf2 = ptr = strdup(str)) )
+return ERROR_NOMEM;
+
+for(tok = ptr, end = ptr + strlen(ptr) + 1; ptr < end; ptr++) {
+switch(state) {


I thought initially you let me to follow that previous "if" :)



Just be consistent with other part of the source code.


I just refer to that existing xlu_pci_parse_bdf()...



Sorry I didn't mean to blame you for something that's not your fault.


Anyway I guess you mean I should do something like this,

 if (NULL == (buf2 = ptr = strdup(str)))
 return ERROR_NOMEM;

 for (tok = ptr, end = ptr + strlen(ptr) + 1; ptr < end; ptr++) {
 switch(state) {
 case STATE_TYPE:
 if (*ptr == '=') {
...



Fair enough. I prefer consistency.

Wei.


Thanks
Tiejun






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

[Xen-devel] [rumpuserxen test] 56792: regressions - FAIL

[osstest service user]

flight 56792 rumpuserxen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56792/

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a

version targeted for testing:
 rumpuserxen  3b91e44996ea6ae1276bce1cc44f38701c53ee6f
baseline version:
 rumpuserxen  30d72f3fc5e35cd53afd82c8179cc0e0b11146ad


People who touched revisions under test:
  Antti Kantee 
  Ian Jackson 
  Martin Lucina 
  Wei Liu 


jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-rumpuserxen-amd64   blocked 
 test-amd64-i386-rumpuserxen-i386 blocked 



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

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

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


Not pushing.

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

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

[Xen-devel] [xen-4.4-testing test] 56731: regressions - FAIL

[osstest service user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail REGR. vs. 
53875
 test-amd64-i386-xend-qemut-winxpsp3 16 guest-stop fail REGR. vs. 53875
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 53875

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-multivcpu 14 guest-start.2fail  like 53737
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail like 
53737

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-armhf-armhf-xl-credit2   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt 11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass

version targeted for testing:
 xen  226059859e6f5a80a5a1728e5dc8ccde50e25f80
baseline version:
 xen  cb296dd08587df2c59ef7ebc6d600cdace468bf2


People who touched revisions under test:
  Eugene Korenevsky 
  Jan Beulich 
  Ross Lagerwall 
  Suravee Suthikulpanit 


jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   pass
 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   blocked 
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-armhf-armhf-xl-arndale  pass
 test-amd64-amd64-xl-credit2  pass
 test-armhf-armhf-xl-credit2  fail
 test-armhf-armhf-xl-cubietruck   pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-i386-rumpuserxen-i386 blocked 
 test-amd64-i386

Re: [Xen-devel] [PATCH v7 03/14] x86: detect and initialize Intel CAT feature

[Chao Peng]

On Tue, May 19, 2015 at 11:22:54AM +0100, Jan Beulich wrote:
> >>> On 19.05.15 at 11:33,  wrote:
> > On Tue, May 19, 2015 at 09:42:07AM +0100, Jan Beulich wrote:
> >> >>> On 19.05.15 at 09:40,  wrote:
> >> > On Mon, May 18, 2015 at 02:33:51PM +0100, Jan Beulich wrote:
> >> >> >>> On 08.05.15 at 10:56,  wrote:
> >> >> > +static unsigned long *__read_mostly cat_socket_init_bitmap;
> >> >> > +static unsigned long *__read_mostly cat_socket_enable_bitmap;
> >> >> 
> >> >> Didn't we agree to fold these two into one? Apart from that the
> >> >> _bitmap name tag doesn't seem very useful...
> >> > 
> >> > Looks like this?
> >> > 
> >> > static unsigned long *__read_mostly cat_socket_init,
> >> >  *__read_mostly cat_socket_enable;
> >> 
> >> Yes, except that you will want to drop one (or make clear why you
> >> need both).
> > 
> > As said in the previous version, cat_socket_enable is the actual CAT
> > enabled status.
> > 
> > And cat_socket_init is used for performance optimization purpose only.
> > It indicate if the socket has been initialized, so that initialization
> > happens only once for each socket, but not __cpus_in_socket__ times.
> > 
> > There are three possibilities:
> > 1)  Not initialized;
> > 2)  Initialized, CAT disabled;
> > 3)  Initialized, CAT enabled;
> > 
> > So it's not possible to use only one bit to represent three values.
> 
> Why? The two bits get set together, and get cleared together. Even
> if they have formally different meaning, there is - afaict - no case
> where their values will differ (except for the brief period between
> setting one and then the other).

Do you want to try the failure initialization(both because CAT is not
even supported on the machine or fails to allocate cos_to_cbm) on and
on?

> 
> >> >> >  static int cpu_callback(
> >> >> >  struct notifier_block *nfb, unsigned long action, void *hcpu)
> >> >> >  {
> >> >> >  if ( action == CPU_STARTING )
> >> >> >  psr_cpu_init();
> >> >> > +else if ( action == CPU_DYING )
> >> >> > +psr_cpu_fini();
> >> >> 
> >> >> Are these the right notifiers for doing things involving memory
> >> >> allocation / freeing?
> >> > 
> >> > psr_cpu_fini() does not really have memory allocation/freeing but
> >> > psr_cpu_init() does have.
> >> 
> >> Hmm, wait - where did I see this allocation? Looking again, I don't see
> >> it now. But if there was one, then surely it would be wrong for _fini
> >> to not free it.
> >> 
> >> > While one thing to clarify is: psr_cpu_init() will not propagate
> >> > the error even when the memory allocation fails(instead it disables
> >> > the CAT on the socket).
> >> > 
> >> > If there is still problem then perhaps I need change CPU_STARTING back
> >> > to CPU_ONLINE and make on_selected_cpus() call on target cpu.
> >> 
> >> No, if there was any allocation needed, you should do the allocation
> >> in CPU_UP_PREPARE and the initialization in CPU_STARTING. But it
> >> looks like this is moot now anyway.
> > 
> > As I will add allocation in patch 4, so I will move psr_cpu_init() to
> > CPU_UP_PREPARE(As the allocation length is based on the cpuid result, so
> > the initialization will also be done here), but still need to move
> > psr_cpu_fini(which will add the freeing code) to CPU_DOWN_PREPARE?
> 
> CPU_DEAD you mean.

Yes, CPU_DEAD.

> 
> But again - only the allocation/freeing should be done in the
> alternative named notifications, not the actual data setup (as that
> iirc needs to run on the CPU).

I know this is the general rules, but for this case, I don't think it's
going to work to allocate memory in CPU_UP_PREPARE while do the
initialization later(in CPU_STARTING).

As said, the allocation has dependency on the result of the
initialization. E.g. before

info->cos_to_cbm = xzalloc_array(struct psr_cat_cbm,
 info->cos_max + 1UL);

info->cos_max must have been known.

Chao

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

Re: [Xen-devel] [PATCH v7 01/14] x86: add socket_to_cpumask

[Chao Peng]

On Tue, May 19, 2015 at 11:18:20AM +0100, Jan Beulich wrote:
> >>> On 19.05.15 at 11:51,  wrote:
> > On Tue, May 19, 2015 at 08:31:53AM +0100, Jan Beulich wrote:
> >> >>> On 19.05.15 at 09:10,  wrote:
> >> > On Tue, May 19, 2015 at 07:52:04AM +0100, Jan Beulich wrote:
> >> >> >>> On 19.05.15 at 08:47,  wrote:
> >> >> > On Tue, May 19, 2015 at 07:28:49AM +0100, Jan Beulich wrote:
> >> >> >> >>> On 19.05.15 at 08:12,  wrote:
> >> >> >> > On Mon, May 18, 2015 at 02:21:40PM +0100, Jan Beulich wrote:
> >> >> >> >> >>> On 08.05.15 at 10:56,  wrote:
> >> >> >> >> > @@ -112,6 +115,8 @@ static int __devinit 
> >> >> >> >> > MP_processor_info_x(struct 
> >> >> > mpc_config_processor *m,
> >> >> >> >> >  {
> >> >> >> >> > int ver, apicid, cpu = 0;
> >> >> >> >> > 
> >> >> >> >> > +   total_cpus++;
> >> >> >> >> > +
> >> >> >> >> > if (!(m->mpc_cpuflag & CPU_ENABLED)) {
> >> >> >> >> > if (!hotplug)
> >> >> >> >> > ++disabled_cpus;
> >> >> >> >> 
> >> >> >> >> Is there a reason you can't use disabled_cpus and avoid adding yet
> >> >> >> >> another variable?
> >> >> >> > 
> >> >> >> > The problem is not with disabled_cpus but with num_processors, 
> >> >> >> > which
> >> >> >> > does not keep the original detected cpus in current code.
> >> >> >> > Hence 'total_cpus = disabled_cpus + num_processors' may not be 
> >> >> >> > correct
> >> >> >> > in some cases.
> >> >> >> 
> >> >> >> Please be more specific about when this is a problem (I do note that
> >> >> >> I'm aware that the equation will not always hold, but during my
> >> >> >> inspection while reviewing your change I didn't see that this would
> >> >> >> ever become problematic).
> >> >> > 
> >> >> > What I really need is the original cpu count enumerated from MADT. If
> >> >> > not introduce total_cpus then the only way getting it AFAICS is
> >> >> > 'disabled_cpus + num_processors'.
> >> >> > 
> >> >> > The problem is that MP_processor_info_x() have some earlier returns
> >> >> > before increasing num_processors. In those cases, the cpu detected 
> >> >> > will
> >> >> > neither counted to disabled_cpus nor num_processors, which means
> >> >> > 'disabled_cpus + num_processors' is potentially small than what I 
> >> >> > need.
> >> >> 
> >> >> As said - I understand this. But you still fail to explain under what
> >> >> (realistic, i.e. other than someone bogusly setting NR_CPUS=1)
> >> >> conditions this ends up being a problem.
> >> > 
> >> > As we calculate nr_sockets with:
> >> > 
> >> > nr_sockets = total_cpus / _cpus_per_socket__
> >> > 
> >> > If the calculated total_cpus is smaller than the actual cpu count on the
> >> > hardware, then the nr_sockets is also potentially smaller than the
> >> > actual socket count on the hardware. This is not the expectation.
> >> 
> >> Sure - but you still don't say what is going to go wrong. Remember,
> >> when I asked you to change to the total count I gave an explicit
> >> example: Use of "nosmp" would have yielded a zero nr_sockets in
> >> the earlier code. Yet with the sum of num_processors and
> >> disabled_cpus this can't happen anymore afaict.
> > 
> > "nosmp" only has side effect on max_cpus and nr_cpu_ids, but they are
> > never used at all when calculating nr_sockets. So I can't see any reason
> > why with "num_processors + disabled_cpus" the nr_sockets would not be
> > zero, I think this is a bug that I should fix in nosmp case.
> 
> Did you really mean to say "would _not_ be zero"? Because afaict
> the above resolves to "would ever be zero".

Yes, I mean "would ever be zero".

> 
> >> Hence I'm looking
> >> forward to you detailing the conditions under which you would see
> >> an issue without introducing total_cpus.
> > 
> > As said before, with "num_processors + disabled_cpus" I may get a
> > smaller nr_sockets than the machine actually has. This is my exact
> > problem: I may miss enumerating some CAT-enabled sockets. While the
> > assumption is that I will follow your suggestion to make nr_socket >=
> > the socket count that the machine actually has.
> 
> Please can you stop repeating yourself? Yes, nr_sockets can get
> underestimated this way, but the cases where total_cpus !=
> num_processors + disabled_cpus are - afaict - such that this in
> the end does no harm. Other than the original case of nr_sockets
> ending up being zero when "nosmp". So to convince me of the
> opposite I'm afraid you won't get around constructing an explicit
> example where things break (and hence my earlier hint regarding
> NR_CPUS=1, as I wouldn't count this as a valid example).

My original thought is that with newly introduced total_cpus, nr_sockets
is less likely to be underestimated than with "num_processors +
disabled_cpus", if not now but for the future. But perhaps I understood 
it incorrectly.

While this is really not a big deal for me. And "num_processors +
disabled_cpus" does work for me now so I feel comfortable to use it.

I do have a problem w

Re: [Xen-devel] [V5] x86/cpuidle: get accurate C0 value with xenpm tool

[Han, Huaitong]

On Tue, 2015-05-19 at 10:01 +0100, Jan Beulich wrote:
> >>> On 14.05.15 at 07:23,  wrote:
> > @@ -1172,7 +1196,10 @@ int pmstat_get_cx_stat(uint32_t cpuid, struct 
> > pm_cx_stat *stat)
> >  {
> >  struct acpi_processor_power *power = processor_powers[cpuid];
> >  uint64_t idle_usage = 0, idle_res = 0;
> > -uint64_t usage[ACPI_PROCESSOR_MAX_POWER], 
> > res[ACPI_PROCESSOR_MAX_POWER];
> > +uint64_t last_state_update_tick, current_stime, current_tick;
> > +uint64_t usage[ACPI_PROCESSOR_MAX_POWER] = { 0 };
> > +uint64_t res_ticks[ACPI_PROCESSOR_MAX_POWER] = { 0 };
> > +uint64_t res[ACPI_PROCESSOR_MAX_POWER] = { 0 };
> 
> Not yet another array on the stack please - I can't see why you
> can't get away with just res[].
res_ticks just is a temp array. I can use a temp variable for
ticks_to_ns  transform, like "tmp=res[i];res[i]=ticks_to_ns(tmp);", and
the array named res[] is better in terms of origin source code.
> Jan
> 

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

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

[osstest service user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 56512
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-installfail REGR. vs. 56512

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64 13 guest-localmigrate  fail like 56512
 test-amd64-i386-freebsd10-i386 13 guest-localmigrate   fail like 56512
 test-amd64-i386-libvirt  11 guest-start  fail   like 56512
 test-amd64-amd64-libvirt 11 guest-start  fail   like 56512

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-xsm  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-amd64-libvirt-xsm 11 guest-start  fail   never pass
 test-amd64-i386-xl-xsm   11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail   never pass
 test-armhf-armhf-xl-xsm   6 xen-boot fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu62bf3df432d93fa6eb0f355c460d6d784b7cbc1a
baseline version:
 qemuu99e7627a70d1a23e30a514e5a4798005cf4eb3aa


People who touched revisions under test:
  Alistair Francis 
  Edgar E. Iglesias 
  Eduardo Habkost 
  Eric Blake 
  Greg Bellows 
  Markus Armbruster 
  Michael S. Tsirkin 
  Peter Crosthwaite 
  Peter Maydell 
  Timothy Baldwin 
  Timothy Edward Baldwin 


jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail
 test-amd64-amd64-libvirt-xsm fail
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  fail
 test-amd64-amd64-xl-xsm  fail
 test-armhf-armhf-xl-xsm  fail
 test-amd64-i386-xl-xsm   fail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail

Re: [Xen-devel] Xen BUG at page_alloc.c:1738 (Xen 4.5)

[Major Hayden]

I compiled Xen with debugging enabled and it appears to pass the
initial boot but then fails later in the boot process.  I'm working
through that now.  Here's what my source of page_alloc.c looks like
around line 1738:

1731 if ( likely(d) && likely(d != dom_cow) )
1732 {
1733 /* NB. May recursively lock from relinquish_memory(). */
1734 spin_lock_recursive(&d->page_alloc_lock);
1735
1736 for ( i = 0; i < (1 << order); i++ )
1737 {
1738 BUG_ON((pg[i].u.inuse.type_info & PGT_count_mask) != 0);
1739 page_list_del2(&pg[i], &d->page_list,
&d->arch.relmem_list);
1740 }
1741
1742 drop_dom_ref = !domain_adjust_tot_pages(d, -(1 << order));
1743
1744 spin_unlock_recursive(&d->page_alloc_lock);
1745
1746 /*
1747  * Normally we expect a domain to clear pages before
freeing them,
1748  * if it cares about the secrecy of their contents.
However, after
1749  * a domain has died we assume responsibility for erasure.
1750  */
1751 scrub = !!d->is_dying;
1752 }

On Tue, May 19, 2015 at 1:16 PM, Andrew Cooper
 wrote:
>
> Can you try a debug hypervisor and rerun, to confirm the stack trace and
> see whether any assertions fire.
>
> Can you identify exactly which line xen/common/page_alloc.c:1738 is in
> your source?

-- 
Major Hayden

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

Re: [Xen-devel] [PATCH v5 1/2] x86, platform, xen, kconfig: clarify kvmconfig is for kvm

[josh]

On Tue, May 19, 2015 at 04:57:17PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" 
> 
> We'll be adding options for xen as well.
> 
> Cc: Josh Triplett 
> Cc: Borislav Petkov 
> Cc: Pekka Enberg 
> Cc: David Rientjes 
> Cc: Michal Marek 
> Cc: Randy Dunlap 
> Cc: penb...@kernel.org
> Cc: levinsasha...@gmail.com
> Cc: mtosa...@redhat.com
> Cc: fengguang...@intel.com
> Cc: David Vrabel 
> Cc: Ian Campbell 
> Cc: Konrad Rzeszutek Wilk 
> Cc: xen-de...@lists.xenproject.org
> Cc: Masahiro Yamada 
> Acked-by: David Rientjes 
> Acked-by: Borislav Petkov 
> Acked-by: Michal Marek 
> Signed-off-by: Luis R. Rodriguez 

Reviewed-by: Josh Triplett 

>  scripts/kconfig/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index d9b1fef..6950032 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -139,7 +139,7 @@ help:
>   @echo  '  randconfig  - New config with random answer to all 
> options'
>   @echo  '  listnewconfig   - List new options'
>   @echo  '  olddefconfig- Same as silentoldconfig but sets new 
> symbols to their default value'
> - @echo  '  kvmconfig   - Enable additional options for guest kernel 
> support'
> + @echo  '  kvmconfig   - Enable additional options for kvm guest 
> kernel support'
>   @echo  '  tinyconfig  - Configure the tiniest possible kernel'
>  
>  # lxdialog stuff
> -- 
> 2.3.2.209.gd67f9d5.dirty
> 

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

[Xen-devel] [PATCH v5 2/2] x86, arm, platform, xen, kconfig: add xen defconfig helper

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" 

This lets you build a kernel which can support xen dom0
or xen guests by just using:

   make xenconfig

on both x86 and arm64 kernels. This also splits out the
options which are available currently to be built with x86
and 'make ARCH=arm64' under a shared config.

Technically xen supports a dom0 kernel and also a guest
kernel configuration but upon review with the xen team
since we don't have many dom0 options its best to just
combine these two into one.

Cc: Josh Triplett 
Cc: Borislav Petkov 
Cc: Pekka Enberg 
Cc: David Rientjes 
Cc: Michal Marek 
Cc: Randy Dunlap 
Cc: penb...@kernel.org
Cc: levinsasha...@gmail.com
Cc: mtosa...@redhat.com
Cc: fengguang...@intel.com
Cc: David Vrabel 
Cc: Ian Campbell 
Cc: Konrad Rzeszutek Wilk 
Cc: xen-de...@lists.xenproject.org
Cc: Masahiro Yamada 
Acked-by: Stefano Stabellini 
Acked-by: Julien Grall 
Acked-by: Michal Marek 
Acked-by: David Rientjes 
Reviewed-by: Josh Triplett 
Signed-off-by: Luis R. Rodriguez 
---
 arch/x86/configs/xen.config | 14 ++
 kernel/configs/xen.config   | 32 
 scripts/kconfig/Makefile|  5 +
 3 files changed, 51 insertions(+)
 create mode 100644 arch/x86/configs/xen.config
 create mode 100644 kernel/configs/xen.config

diff --git a/arch/x86/configs/xen.config b/arch/x86/configs/xen.config
new file mode 100644
index 000..fabad7f
--- /dev/null
+++ b/arch/x86/configs/xen.config
@@ -0,0 +1,14 @@
+CONFIG_HYPERVISOR_GUEST=y
+# x86 xen specific config options
+CONFIG_XEN_PV=y
+CONFIG_XEN_PVH=y
+CONFIG_XEN_MAX_DOMAIN_MEMORY=500
+CONFIG_XEN_SAVE_RESTORE=y
+# CONFIG_XEN_DEBUG_FS is not set
+CONFIG_XEN_MCE_LOG=y
+CONFIG_PCI_XEN=y
+CONFIG_XEN_ACPI_PROCESSOR=m
+# x86 specific backend drivers
+CONFIG_XEN_PCIDEV_BACKEND=m
+# x86 specific frontend drivers
+CONFIG_XEN_PCIDEV_FRONTEND=m
diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config
new file mode 100644
index 000..9d23733
--- /dev/null
+++ b/kernel/configs/xen.config
@@ -0,0 +1,32 @@
+CONFIG_PARAVIRT=y
+# generic config
+CONFIG_XEN=y
+CONFIG_XEN_DOM0=y
+# backend drivers
+CONFIG_XEN_BACKEND=y
+CONFIG_XEN_BLKDEV_BACKEND=m
+CONFIG_XEN_NETDEV_BACKEND=m
+CONFIG_HVC_XEN=y
+CONFIG_XEN_WDT=m
+CONFIG_XEN_SCSI_BACKEND=m
+# frontend drivers
+CONFIG_XEN_FRONTEND=y
+CONFIG_XEN_FBDEV_FRONTEND=m
+CONFIG_HVC_XEN_FRONTEND=y
+CONFIG_INPUT_XEN_KBDDEV_FRONTEND=m
+CONFIG_XEN_SCSI_FRONTEND=m
+# others
+CONFIG_XEN_BALLOON=y
+CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y
+CONFIG_XEN_SCRUB_PAGES=y
+CONFIG_XEN_DEV_EVTCHN=m
+CONFIG_XEN_BLKDEV_FRONTEND=m
+CONFIG_XEN_NETDEV_FRONTEND=m
+CONFIG_XENFS=m
+CONFIG_XEN_COMPAT_XENFS=y
+CONFIG_XEN_SYS_HYPERVISOR=y
+CONFIG_XEN_XENBUS_FRONTEND=y
+CONFIG_XEN_GNTDEV=m
+CONFIG_XEN_GRANT_DEV_ALLOC=m
+CONFIG_SWIOTLB_XEN=y
+CONFIG_XEN_PRIVCMD=m
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 6950032..f52abae 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -115,6 +115,10 @@ PHONY += kvmconfig
 kvmconfig: kvm_guest.config
@:
 
+PHONY += xenconfig
+xenconfig: xen.config
+   @:
+
 PHONY += tinyconfig
 tinyconfig:
$(Q)$(MAKE) -f $(srctree)/Makefile allnoconfig tiny.config
@@ -140,6 +144,7 @@ help:
@echo  '  listnewconfig   - List new options'
@echo  '  olddefconfig- Same as silentoldconfig but sets new 
symbols to their default value'
@echo  '  kvmconfig   - Enable additional options for kvm guest 
kernel support'
+   @echo  '  xenconfig   - Enable additional options for xen dom0 and 
guest kernel support'
@echo  '  tinyconfig  - Configure the tiniest possible kernel'
 
 # lxdialog stuff
-- 
2.3.2.209.gd67f9d5.dirty


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

[Xen-devel] [PATCH v5 1/2] x86, platform, xen, kconfig: clarify kvmconfig is for kvm

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" 

We'll be adding options for xen as well.

Cc: Josh Triplett 
Cc: Borislav Petkov 
Cc: Pekka Enberg 
Cc: David Rientjes 
Cc: Michal Marek 
Cc: Randy Dunlap 
Cc: penb...@kernel.org
Cc: levinsasha...@gmail.com
Cc: mtosa...@redhat.com
Cc: fengguang...@intel.com
Cc: David Vrabel 
Cc: Ian Campbell 
Cc: Konrad Rzeszutek Wilk 
Cc: xen-de...@lists.xenproject.org
Cc: Masahiro Yamada 
Acked-by: David Rientjes 
Acked-by: Borislav Petkov 
Acked-by: Michal Marek 
Signed-off-by: Luis R. Rodriguez 
---
 scripts/kconfig/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index d9b1fef..6950032 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -139,7 +139,7 @@ help:
@echo  '  randconfig  - New config with random answer to all 
options'
@echo  '  listnewconfig   - List new options'
@echo  '  olddefconfig- Same as silentoldconfig but sets new 
symbols to their default value'
-   @echo  '  kvmconfig   - Enable additional options for guest kernel 
support'
+   @echo  '  kvmconfig   - Enable additional options for kvm guest 
kernel support'
@echo  '  tinyconfig  - Configure the tiniest possible kernel'
 
 # lxdialog stuff
-- 
2.3.2.209.gd67f9d5.dirty


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

[Xen-devel] [PATCH v5 0/2] x86: add xenconfig

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" 

David Vrabel, please let me know if there are any issues. These two
patches are based on your xen/tip.git tree on the for-linus-4.1b branch.

This v5 is a respin the the old v4 series to work with the latest code.
I had stopped on the v4 at that time we were discussing doing major
Kconfig changes. In the end we decided to not go forward with tons of
Kconfig changes. As time went by though I did notice the v4 series required
on modification due to Masahiro Yamada's commit: "kbuild: add generic
mergeconfig target, %.config". This v5 series then simply adjusts
the target xenconfig to work with those changes.

The kconfig entries have not been changed but I did verify they're all
still there and those that arch specific remain arch specific.

Luis R. Rodriguez (2):
  x86, platform, xen, kconfig: clarify kvmconfig is for kvm
  x86, arm, platform, xen, kconfig: add xen defconfig helper

 arch/x86/configs/xen.config | 14 ++
 kernel/configs/xen.config   | 32 
 scripts/kconfig/Makefile|  7 ++-
 3 files changed, 52 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/configs/xen.config
 create mode 100644 kernel/configs/xen.config

-- 
2.3.2.209.gd67f9d5.dirty


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

Re: [Xen-devel] [PATCH v5 1/5] pci: add pci_iomap_wc() variants

[Luis R. Rodriguez]

On Tue, May 19, 2015 at 4:29 PM, David Airlie  wrote:
>
>> On Tue, May 19, 2015 at 4:02 PM, Bjorn Helgaas  wrote:
>> > [-cc Venkatesh (bouncing)
>> >
>> > On Tue, May 19, 2015 at 5:46 PM, Luis R. Rodriguez
>> >  wrote:
>> >> On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas 
>> >> wrote:
>> >>> Acked-by: Bjorn Helgaas 
>> >>
>> >> Thanks! Who's tree should this go through?
>> >
>> > I don't know.  This is the only patch that went to linux-pci, so I
>> > haven't seen the rest.
>>
>> Oh I only rev'd a v5 for 1/5 as that's the only one that had feedback
>> asking for changes.
>>
>> Patch v4 2/5 was for "lib: devres: add pcim_iomap_wc() variants", you
>> had questions about EXPORT_SYMBOL_GPL() and the fact that this is not
>> yet used. I replied. This patch can then be ignored but again, I'd
>> hate for folks to go in and try to add a non EXPORT_SYMBOL_GPL()
>> symbol of this.
>>
>> Patches v4 3-5 remain intact, I had addressed it to you, but failed to
>> Cc linux-pci, I'll go ahead and bounce those now.
>>
>> Just today Dave Arlie provided a Reviewed-by to some simple
>> framebuffer device driver changes. I wonder if these changes should go
>> through the framebuffer tree provided you already gave the Acked-by
>> for the PCI parts, or if the PCI parts should go in first and only
>> later (I guess we'd have to wait) then intake the driver changes that
>> use the symbol.
>>
>> What we decide should likely also apply to the series that adds
>> pci_ioremap_wc_bar() and makes use of it on drivers.
>>
>> Dave, Tomi, any preference?
>>
>
> Maybe send Bjorn a pull request with a tree with the pci changes, and the fb 
> changes reviewed-by me and acked by Tomi.
>
> Seems like it could be the simplest path forward.

Works with me, Bjorn, are you OK with that?

Dave, Tomi, I still need your Reviewed-by and Acked-by's Tomi on these
two PCI series. Please let me know if I should resend those first, but
I think I had Cc'd you folks already on them.

 Luis

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

[Xen-devel] [xen-4.5-testing test] 56728: tolerable FAIL - PUSHED

[osstest service user]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl   3 host-install(3)  broken in 56687 pass in 56728
 test-armhf-armhf-xl-arndale   7 host-ping-check-xen fail pass in 56687

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386 13 guest-localmigrate   fail like 52649
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 52649
 test-amd64-i386-freebsd10-amd64 13 guest-localmigrate  fail like 53019

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-arndale  12 migrate-support-check fail in 56687 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-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  0c4e0ef608c98abef6220b0b027d9ce8ec65fd5f
baseline version:
 xen  d41906197d9a89355f43d4359d795b1d0257a53a


People who touched revisions under test:
  Jan Beulich 


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-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  fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 pass
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-armhf-armhf-xl-arndale  fail
 test-amd64-amd64-xl-credit2  pass
 test-armhf-armhf-xl-credit2  pass
 test-armhf-armhf-xl-cubietruck   pass
 test-amd64-i386-freebsd10-i386   fail
 test-amd64-i386-rumpuserxen-i386 pass
 test-amd64-amd64-xl-pvh-intelfail
 test-amd64-i386-qemut-rhel6hvm-intel pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  

Re: [Xen-devel] [PATCH v5 1/5] pci: add pci_iomap_wc() variants

[Luis R. Rodriguez]

On Tue, May 19, 2015 at 4:02 PM, Bjorn Helgaas  wrote:
> [-cc Venkatesh (bouncing)
>
> On Tue, May 19, 2015 at 5:46 PM, Luis R. Rodriguez
>  wrote:
>> On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas  wrote:
>>> Acked-by: Bjorn Helgaas 
>>
>> Thanks! Who's tree should this go through?
>
> I don't know.  This is the only patch that went to linux-pci, so I
> haven't seen the rest.

Oh I only rev'd a v5 for 1/5 as that's the only one that had feedback
asking for changes.

Patch v4 2/5 was for "lib: devres: add pcim_iomap_wc() variants", you
had questions about EXPORT_SYMBOL_GPL() and the fact that this is not
yet used. I replied. This patch can then be ignored but again, I'd
hate for folks to go in and try to add a non EXPORT_SYMBOL_GPL()
symbol of this.

Patches v4 3-5 remain intact, I had addressed it to you, but failed to
Cc linux-pci, I'll go ahead and bounce those now.

Just today Dave Arlie provided a Reviewed-by to some simple
framebuffer device driver changes. I wonder if these changes should go
through the framebuffer tree provided you already gave the Acked-by
for the PCI parts, or if the PCI parts should go in first and only
later (I guess we'd have to wait) then intake the driver changes that
use the symbol.

What we decide should likely also apply to the series that adds
pci_ioremap_wc_bar() and makes use of it on drivers.

Dave, Tomi, any preference?

  Luis

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

Re: [Xen-devel] [PATCH v5 1/5] pci: add pci_iomap_wc() variants

[Bjorn Helgaas]

[-cc Venkatesh (bouncing)

On Tue, May 19, 2015 at 5:46 PM, Luis R. Rodriguez
 wrote:
> On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas  wrote:
>> Acked-by: Bjorn Helgaas 
>
> Thanks! Who's tree should this go through?

I don't know.  This is the only patch that went to linux-pci, so I
haven't seen the rest.

Bjorn

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

Re: [Xen-devel] [RFC 21/23] net/xen-netback: Make it running on 64KB page granularity

[Julien Grall]

Hi,

On 18/05/2015 13:54, Wei Liu wrote:

On Mon, May 18, 2015 at 01:11:26PM +0100, Julien Grall wrote:

On 15/05/15 16:31, Wei Liu wrote:

On Fri, May 15, 2015 at 01:35:42PM +0100, Julien Grall wrote:

On 15/05/15 03:35, Wei Liu wrote:

On Thu, May 14, 2015 at 06:01:01PM +0100, Julien Grall wrote:

The PV network protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity working as a
network backend on a non-modified Xen.

It's only necessary to adapt the ring size and break skb data in small
chunk of 4KB. The rest of the code is relying on the grant table code.

Although only simple workload is working (dhcp request, ping). If I try
to use wget in the guest, it will stall until a tcpdump is started on
the vif interface in DOM0. I wasn't able to find why.



I think in wget workload you're more likely to break down 64K pages to
4K pages. Some of your calculation of mfn, offset might be wrong.


If so, why tcpdump on the vif interface would make wget suddenly
working? Does it make netback use a different path?


No, but if might make core network component behave differently, this is
only my suspicion.

Do you see malformed packets with tcpdump?


I don't see any malformed packets with tcpdump. The connection is stalling
until tcpdump is started on the vif in dom0.



Hmm... Don't have immediate idea about this.

Ian said skb_orphan is called with tcpdump. If I remember correct that
would trigger the callback to release the slots in netback. It could be
that other part of Linux is holding onto the skbs for too long.

If you're wgetting from another host, I would suggest wgetting from Dom0
to limit the problem between Dom0 and DomU.


Thanks to Wei, I was able to narrow the problem. It looks like the 
problem is not coming from netback but somewhere else down in the 
network stack: wget/ssh between Dom0 64KB and DomU is working fine.


Although, wget/ssh between a guest and an external host doesn't work 
when Dom0 is using 64KB page granularity unless if I start a tcpdump on 
the vif in DOM0. Anyone an idea?


I have no issue to wget/ssh in DOM0 to an external host and the same 
kernel with 4KB page granularity (i.e same source code but rebuilt with 
4KB) doesn't show any issue with wget/ssh in the guest.


This has been tested on AMD Seattle, the guest kernel is the same on 
every test (4KB page granularity).


I'm planning to give a try tomorrow on X-gene (ARM64 board and I think 
64KB page granularity is supported) to see if I can reproduce the bug.



diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 0eda6e9..c2a5402 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -204,7 +204,7 @@ struct xenvif_queue { /* Per-queue data for xenvif */
  /* Maximum number of Rx slots a to-guest packet may use, including the
   * slot needed for GSO meta-data.
   */
-#define XEN_NETBK_RX_SLOTS_MAX (MAX_SKB_FRAGS + 1)
+#define XEN_NETBK_RX_SLOTS_MAX ((MAX_SKB_FRAGS + 1) * XEN_PFN_PER_PAGE)

  enum state_bit_shift {
 /* This bit marks that the vif is connected */

The function xenvif_wait_for_rx_work never returns. I guess it's because there
is not enough slot available.

For 64KB page granularity we ask for 16 times more slots than 4KB page
granularity. Although, it's very unlikely that all the slot will be used.

FWIW I pointed out the same problem on blkfront.



This is not going to work. The ring in netfront / netback has only 256
slots. Now you ask for netback to reserve more than 256 slots -- (17 +
1) * (64 / 4) = 288, which can never be fulfilled. See the call to
xenvif_rx_ring_slots_available.

I think XEN_NETBK_RX_SLOTS_MAX derived from the fact the each packet to
the guest cannot be larger than 64K. So you might be able to

#define XEN_NETBK_RX_SLOTS_MAX ((65536 / XEN_PAGE_SIZE) + 1)


I didn't know that packet cannot be larger than 64KB. That's simply a 
lot the problem.




Blk driver may have a different story. But the default ring size (1
page) yields even less slots than net (given that sizeof(union(req/rsp))
is larger IIRC).


I will see with Roger for Blkback.


--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 1/5] pci: add pci_iomap_wc() variants

[Luis R. Rodriguez]

On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas  wrote:
> Acked-by: Bjorn Helgaas 

Thanks! Who's tree should this go through?

  Luis

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

Re: [Xen-devel] [PATCH v5 1/5] pci: add pci_iomap_wc() variants

[Bjorn Helgaas]

On Thu, Apr 30, 2015 at 10:36:04AM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" 
> 
> This allows drivers to take advantage of write-combining
> when possible. The PCI specification does not allow for us
> to automatically identify a memory region which needs
> write-combining so drivers have to identify these areas
> on their own. There is IORESOURCE_PREFETCH but as clarified
> by Michael and confirmed later by Bjorn, PCI prefetch bit
> merely means bridges can combine writes and prefetch reads.
> Prefetch does not affect ordering rules and does not allow
> writes to be collapsed [0]. WC is stronger, it allows collapsing
> and changes ordering rules. WC can also hurt latency as small
> writes are buffered. Because of all this drivers needs to
> know what they are doing, we can't set a write-combining
> preference flag in the pci core automatically for drivers.
> 
> Lastly although there is also arch_phys_wc_add() this makes
> use of architecture specific write-combining *hacks* and
> the only one currently defined and used is MTRR for x86.
> MTRRs are legacy, limited in number, have restrictive size
> constraints, and are known to interact pooly with the BIOS.
> MTRRs should only really be considered on old video framebuffer
> drivers. If we made ioremap_wc() and similar calls start
> automatically adding MTRRs, then performance will vary wildly
> with the order of driver loading because we'll run out of MTRRs
> part-way through bootup.
> 
> There are a few motivations for phasing out of MTRR and
> helping driver change over to use write-combining with PAT:
> 
> a) Take advantage of PAT when available
> 
> b) Help bury MTRR code away, MTRR is architecture specific and on
>x86 its replaced by PAT
> 
> c) Help with the goal of eventually using _PAGE_CACHE_UC over
>_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
>de33c442e titled "x86 PAT: fix performance drop for glx,
>use UC minus for ioremap(), ioremap_nocache() and
>pci_mmap_page_range()")
> 
> [0] https://lkml.org/lkml/2015/4/21/714
> 
> Cc: Toshi Kani 
> Cc: Andy Lutomirski 
> Cc: Suresh Siddha 
> Cc: Ingo Molnar 
> Cc: Thomas Gleixner 
> Cc: Juergen Gross 
> Cc: Daniel Vetter 
> Cc: Dave Airlie 
> Cc: Bjorn Helgaas 
> Cc: Antonino Daplas 
> Cc: Jean-Christophe Plagniol-Villard 
> Cc: Tomi Valkeinen 
> Cc: Dave Hansen 
> Cc: Arnd Bergmann 
> Cc: Michael S. Tsirkin 
> Cc: venkatesh.pallip...@intel.com
> Cc: Stefan Bader 
> Cc: Ville Syrjälä 
> Cc: Mel Gorman 
> Cc: Vlastimil Babka 
> Cc: Borislav Petkov 
> Cc: Davidlohr Bueso 
> Cc: konrad.w...@oracle.com
> Cc: ville.syrj...@linux.intel.com
> Cc: david.vra...@citrix.com
> Cc: jbeul...@suse.com
> Cc: Roger Pau Monné 
> Cc: linux-fb...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: xen-de...@lists.xensource.com
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Luis R. Rodriguez 

Acked-by: Bjorn Helgaas 

> ---
> 
> This v5 makes the code return NULL for IORESOURCE_IO and fixes the commit
> log to clarify the conclusions reached for MTRR and our review of
> IORESOURCE_PREFETCH.
> 
>  include/asm-generic/pci_iomap.h | 14 ++
>  lib/pci_iomap.c | 61 
> +
>  2 files changed, 75 insertions(+)
> 
> diff --git a/include/asm-generic/pci_iomap.h b/include/asm-generic/pci_iomap.h
> index 7389c87..b1e17fc 100644
> --- a/include/asm-generic/pci_iomap.h
> +++ b/include/asm-generic/pci_iomap.h
> @@ -15,9 +15,13 @@ struct pci_dev;
>  #ifdef CONFIG_PCI
>  /* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
>  extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long 
> max);
> +extern void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar, unsigned 
> long max);
>  extern void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
>unsigned long offset,
>unsigned long maxlen);
> +extern void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
> + unsigned long offset,
> + unsigned long maxlen);
>  /* Create a virtual mapping cookie for a port on a given PCI device.
>   * Do not call this directly, it exists to make it easier for architectures
>   * to override */
> @@ -34,12 +38,22 @@ static inline void __iomem *pci_iomap(struct pci_dev 
> *dev, int bar, unsigned lon
>   return NULL;
>  }
>  
> +static inline void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar, 
> unsigned long max)
> +{
> + return NULL;
> +}
>  static inline void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
>   unsigned long offset,
>   unsigned long maxlen)
>  {
>   return NULL;
>  }
> +static inline void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
> +unsigned long offset,
> + 

[Xen-devel] [qemu-upstream-4.3-testing test] 56767: trouble: preparing/queued

[osstest service user]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  queued
 test-amd64-i386-freebsd10-amd64  queued
 test-amd64-i386-xl-qemuu-ovmf-amd64  queued
 test-amd64-i386-libvirt   queued
 test-amd64-amd64-pv   queued
 test-amd64-amd64-xl-sedf-pin  queued
 test-amd64-amd64-xl   queued
 test-amd64-amd64-xl-credit2   queued
 test-amd64-amd64-xl-sedf  queued
 test-amd64-i386-pvqueued
 test-amd64-i386-qemuu-rhel6hvm-intel  queued
 test-amd64-amd64-libvirt  queued
 test-amd64-i386-xlqueued
 test-amd64-amd64-xl-multivcpu  queued
 test-amd64-i386-pair  queued
 test-amd64-i386-qemuu-rhel6hvm-amd  queued
 build-amd64-libvirt   queued
 test-amd64-i386-freebsd10-i386  queued
 test-amd64-i386-xl-qemuu-win7-amd64  queued
 test-amd64-amd64-xl-qemuu-win7-amd64  queued
 test-amd64-amd64-pair queued
 build-i386-libvirtqueued
 test-amd64-amd64-xl-qemuu-debianhvm-amd64queued
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 queued
 test-amd64-i386-xl-qemuu-debianhvm-amd64 queued
 test-amd64-amd64-xl-qemuu-winxpsp3  queued
 build-amd64-pvops 2 hosts-allocate   running
 build-i3862 hosts-allocate   running
 build-amd64   2 hosts-allocate   running
 build-i386-pvops  2 hosts-allocate   running

version targeted for testing:
 qemuud7b34893e0ad5c84d898b34fda8a465dfd7e8376
baseline version:
 qemuu7f34050dc014ae8f4078d48aec97ec6553151bf2


People who touched revisions under test:
  Petr Matousek 


jobs:
 build-amd64  preparing
 build-i386   preparing
 build-amd64-libvirt  queued  
 build-i386-libvirt   queued  
 build-amd64-pvopspreparing
 build-i386-pvops preparing
 test-amd64-amd64-xl  queued  
 test-amd64-i386-xl   queued  
 test-amd64-i386-qemuu-rhel6hvm-amd   queued  
 test-amd64-amd64-xl-qemuu-debianhvm-amd64queued  
 test-amd64-i386-xl-qemuu-debianhvm-amd64 queued  
 test-amd64-i386-freebsd10-amd64  queued  
 test-amd64-amd64-xl-qemuu-ovmf-amd64 queued  
 test-amd64-i386-xl-qemuu-ovmf-amd64  queued  
 test-amd64-amd64-xl-qemuu-win7-amd64 queued  
 test-amd64-i386-xl-qemuu-win7-amd64  queued  
 test-amd64-amd64-xl-credit2  queued  
 test-amd64-i386-freebsd10-i386   queued  
 test-amd64-i386-qemuu-rhel6hvm-intel queued  
 test-amd64-amd64-libvirt queued  
 test-amd64-i386-libvirt  queued  
 test-amd64-amd64-xl-multivcpuqueued  
 test-amd64-amd64-pairqueued  
 test-amd64-i386-pair queued  
 test-amd64-amd64-xl-sedf-pin queued  
 test-amd64-amd64-pv  queued  
 test-amd64-i386-pv   queued  
 test-amd64-amd64-xl-sedf queued  
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 queued  
 test-amd64-amd64-xl-qemuu-winxpsp3   queued  



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

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

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

broken-job test-amd64-amd64-xl-qemuu-ovmf-amd64 queued
broken-job test-amd64-i386-freebsd10-amd64 queued
broken-job test-amd64-i386-xl-qemuu-

Re: [Xen-devel] [PATCH v4 2/2] x86, arm, platform, xen, kconfig: add xen defconfig helper

[Luis R. Rodriguez]

On Fri, Feb 13, 2015 at 01:15:18PM -0800, David Rientjes wrote:
> On Fri, 13 Feb 2015, Luis R. Rodriguez wrote:
> 
> > David,
> > 
> > since I'm making some Kconfig changes to Xen I think I should
> > fold this into that series with the modifications required
> > last so as to avoid other commits and have this go in clean
> > after all the changes, and have this go through you with
> > that.
> > 
> > Thoughts?
> > 
> 
> Sure, if you're planning on kconfig changes then I agree that this should 
> come later, either as part of the same patchset if it logically makes 
> sense or just in a follow-up patchset.

Long story short: the expected changes never panned out for a variety of
reasons, so I'm going to respn this again. David Vrabel, I plan on basing
this on your for-linus-4.1b branch, if there is a more suitable branch
please let me know.

  Luis

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

Re: [Xen-devel] [qemu-upstream-4.3-testing test] 56721: regressions - FAIL

[Ian Campbell]

On Tue, 2015-05-19 at 21:56 +0100, Andrew Cooper wrote:
> On 19/05/2015 21:49, osstest service user wrote:
> > flight 56721 qemu-upstream-4.3-testing real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/56721/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-i386-freebsd10-amd64 16 guest-localmigrate/x10 fail in 56637 
> > REGR. vs. 50282
> 
> Didn't this test get put on the permitted list?

Only guest-localmigrate and not guest-localmigrate/x10, because I didn't
have my brain on when I wrote that patch...

The real fix (updated FreeBSD images with the bug fixed) is in osstest's
own pretest branch now though, I'd expect a push of that overnight or
early tomorrow.

In the meantime I force pushed this one and killed flight 56767 which
was just testing the same thing again.

[...]
> > version targeted for testing:
> >  qemuud7b34893e0ad5c84d898b34fda8a465dfd7e8376
> > baseline version:
> >  qemuu7f34050dc014ae8f4078d48aec97ec6553151bf2
> >

osstest@osstest:~/branches/for-qemu-upstream-4.3-testing.git$ 
OSSTEST_CONFIG=production-config ./ap-push qemu-upstream-4.3-testing  
d7b34893e0ad5c84d898b34fda8a465dfd7e8376
+ branch=qemu-upstream-4.3-testing
+ revision=d7b34893e0ad5c84d898b34fda8a465dfd7e8376
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push 
qemu-upstream-4.3-testing d7b34893e0ad5c84d898b34fda8a465dfd7e8376
+ branch=qemu-upstream-4.3-testing
+ revision=d7b34893e0ad5c84d898b34fda8a465dfd7e8376
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-4.3-testing
+ '[' xqemuu = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-4.3-testing
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.3-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-4.3-testing

Re: [Xen-devel] [qemu-upstream-4.3-testing test] 56721: regressions - FAIL

[Andrew Cooper]

On 19/05/2015 21:49, osstest service user wrote:
> flight 56721 qemu-upstream-4.3-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/56721/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-freebsd10-amd64 16 guest-localmigrate/x10 fail in 56637 
> REGR. vs. 50282

Didn't this test get put on the permitted list?

~Andrew

>
> Tests which are failing intermittently (not blocking):
>  test-amd64-i386-freebsd10-amd64 13 guest-localmigrate fail in 55875 pass in 
> 56721
>  test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate fail in 55875 pass 
> in 56721
>  test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 55875 
> pass in 56721
>  test-amd64-i386-freebsd10-i386 13 guest-localmigrate fail in 56637 pass in 
> 56721
>  test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail in 56679 
> pass in 56721
>  test-amd64-i386-libvirt  11 guest-start fail pass in 
> 55875
>  test-amd64-i386-freebsd10-i386 16 guest-localmigrate/x10fail pass in 
> 56506
>  test-amd64-i386-freebsd10-amd64 15 guest-localmigrate.2 fail pass in 
> 56637
>  test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
> 56637
>  test-amd64-i386-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail pass in 
> 56679
>
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 16 guest-stop fail in 55875 like 
> 50282
>  test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 56637 like 
> 50282
>
> Tests which did not succeed, but are not blocking:
>  test-amd64-i386-libvirt  12 migrate-support-check fail in 55875 never 
> pass
>  test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never 
> pass
>  test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never 
> pass
>  test-amd64-amd64-libvirt 12 migrate-support-checkfail   never 
> pass
>
> version targeted for testing:
>  qemuud7b34893e0ad5c84d898b34fda8a465dfd7e8376
> baseline version:
>  qemuu7f34050dc014ae8f4078d48aec97ec6553151bf2
>
> 
> People who touched revisions under test:
>   Petr Matousek 
> 
>
> jobs:
>  build-amd64  pass
>  build-i386   pass
>  build-amd64-libvirt  pass
>  build-i386-libvirt   pass
>  build-amd64-pvopspass
>  build-i386-pvops pass
>  test-amd64-amd64-xl  pass
>  test-amd64-i386-xl   pass
>  test-amd64-i386-qemuu-rhel6hvm-amd   pass
>  test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
>  test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
>  test-amd64-i386-freebsd10-amd64  fail
>  test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
>  test-amd64-i386-xl-qemuu-ovmf-amd64  fail
>  test-amd64-amd64-xl-qemuu-win7-amd64 fail
>  test-amd64-i386-xl-qemuu-win7-amd64  fail
>  test-amd64-amd64-xl-credit2  pass
>  test-amd64-i386-freebsd10-i386   fail
>  test-amd64-i386-qemuu-rhel6hvm-intel pass
>  test-amd64-amd64-libvirt pass
>  test-amd64-i386-libvirt  fail
>  test-amd64-amd64-xl-multivcpupass
>  test-amd64-amd64-pairpass
>  test-amd64-i386-pair pass
>  test-amd64-amd64-xl-sedf-pin pass
>  test-amd64-amd64-pv  pass
>  test-amd64-i386-pv   pass
>  test-amd64-amd64-xl-sedf pass
>  test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
>  test-amd64-amd64-xl-qemuu-winxpsp3   pass
>
>
> 
> sg-report-flight on osstest.test-lab.xenproject.org
> logs: /home/osstest/pub/logs
> images: /home/osstest/pub/images
>
> Logs, config files, etc. are available at
> http://logs.test-lab.xenproject.org/osstest/logs
>
> Test harness code can be found at
> http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
>
>
> Not pushing.
>
> -

[Xen-devel] [qemu-upstream-4.3-testing test] 56721: regressions - FAIL

[osstest service user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-amd64 16 guest-localmigrate/x10 fail in 56637 REGR. 
vs. 50282

Tests which are failing intermittently (not blocking):
 test-amd64-i386-freebsd10-amd64 13 guest-localmigrate fail in 55875 pass in 
56721
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate fail in 55875 pass 
in 56721
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 55875 
pass in 56721
 test-amd64-i386-freebsd10-i386 13 guest-localmigrate fail in 56637 pass in 
56721
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail in 56679 
pass in 56721
 test-amd64-i386-libvirt  11 guest-start fail pass in 55875
 test-amd64-i386-freebsd10-i386 16 guest-localmigrate/x10fail pass in 56506
 test-amd64-i386-freebsd10-amd64 15 guest-localmigrate.2 fail pass in 56637
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
56637
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail pass in 56679

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 16 guest-stop fail in 55875 like 50282
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 56637 like 50282

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt  12 migrate-support-check fail in 55875 never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuud7b34893e0ad5c84d898b34fda8a465dfd7e8376
baseline version:
 qemuu7f34050dc014ae8f4078d48aec97ec6553151bf2


People who touched revisions under test:
  Petr Matousek 


jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt pass
 test-amd64-i386-libvirt  fail
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-xl-sedf-pin pass
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-xl-sedf pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass



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

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

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


Not pushing.


commit d7b34893e0ad5c84d898b34fda8a465dfd7e8376
Author: Petr Matousek 
Date:   Wed May 6 09:48:59 2015 +0200

fdc: force the fifo access to be in bounds of the allocated buffer

During processing of certain commands such as FD_CMD_READ_ID and
FD_CMD_DRIVE

[Xen-devel] [linux-linus test] 56718: tolerable FAIL - PUSHED

[osstest service user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt  11 guest-start   fail REGR. vs. 50329
 test-amd64-amd64-libvirt 11 guest-start   fail REGR. vs. 50329
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail blocked 
in 50329
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail blocked in 50329
 test-amd64-i386-freebsd10-amd64  9 freebsd-install fail like 50329
 test-amd64-i386-freebsd10-i386  9 freebsd-install  fail like 50329
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 50329
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 50329

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-i386-libvirt-xsm  11 guest-start  fail   never pass
 test-amd64-amd64-xl-qemuu-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-xsm  11 guest-start  fail   never pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-xl-xsm   11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 11 guest-start  fail   never pass
 test-armhf-armhf-xl-xsm   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass

version targeted for testing:
 linuxe26081808edadfd257c6c9d81014e3b25e9a6118
baseline version:
 linux1cced5015b171415169d938fb179c44fe060dc15


2034 people touched revisions under test,
not listing them all


jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm fail
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail
 test-amd64-amd64-libvirt-xsm fail
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  fail
 test-amd64-amd64-xl-xsm  fail
 test-armhf-armhf-xl-xsm  fail
 test-amd64-i386-xl-xsm   fail
 test-amd64-amd64-xl-pvh-amd

Re: [Xen-devel] [PATCH v10 05/10] xen: Add vmware_port support

[Andrew Cooper]

On 15/05/15 00:34, Don Slutz wrote:
> This includes adding is_vmware_port_enabled
>
> This is a new xen_arch_domainconfig flag,
> XEN_DOMCTL_CONFIG_VMWARE_PORT_MASK.
>
> This enables limited support of VMware's hyper-call.
>
> This is both a more complete support then in currently provided by
> QEMU and/or KVM and less.  The missing part requires QEMU changes
> and has been left out until the QEMU patches are accepted upstream.
>
> VMware's hyper-call is also known as VMware Backdoor I/O Port.
>
> Note: this support does not depend on vmware_hw being non-zero.
>
> Summary is that VMware treats "in (%dx),%eax" (or "out %eax,(%dx)")
> to port 0x5658 specially.  Note: since many operations return data
> in EAX, "in (%dx),%eax" is the one to use.  The other lengths like
> "in (%dx),%al" will still do things, only AL part of EAX will be
> changed.  For "out %eax,(%dx)" of all lengths, EAX will remain
> unchanged.
>
> An open source example of using this is:
>
> http://open-vm-tools.sourceforge.net/
>
> Which only uses "inl (%dx)".  Also
>
> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009458
>
> Some of the best info is at:
>
> https://sites.google.com/site/chitchatvmback/backdoor
>
> Signed-off-by: Don Slutz 
> ---
> v10:
> Probably better as EOPNOTSUPP, as it is a configuration problem.
> This function looks as if it should be static.
> I would suggest putting vmport_register declaration in hvm.h ...
> As indicated before, I don't think this is a good use case for a
> domain creation flag.
>   Switch to the new config way.
> struct domain *d => struct domain *currd
> Are you sure you don't want to zero the high halves of 64-bit ...
>   Comment added.
>Then just have this handled into the default case.
>   Reworked new_eax handling.
>is_hvm_domain(currd)
>And - why here rather than before the switch() or even right at the
>start of the function?
>   Moved to start.
>With that, is it really correct that OUT updates the other registers
>just like IN? If so, this deserves a comment, so that readers won't
>think this is in error.
>  All done in comment at start.
>
>
> v9:
>   Switch to x86_emulator to handle #GP code moved to next patch.
> Can you explain why a HVM param isn't suitable here?
>   Issue with changing QEMU on the fly.
>   Andrew Cooper: My recommendation is still to use a creation flag
> So no change.
> Please move SVM's identical definition into ...
>   Did this as #1.  No longer needed, but since the patch was ready
>   I have included it.
> --Lots of questions about code that no long is part of this patch. --
> With this, is handling other than 32-bit in/out really
> meaningful/correct?
>   Added comment about this.
> Since you can't get here for PV, I can't see what you need this.
>   Changed to an ASSERT.
> Why version 4?
>   Added comment about this.
> -- Several questions about register changes.
>   Re-coded to use new_eax and set *val to this.
>   Change to generealy use reg->_e..
> These ei1/ei2 checks belong in the callers imo -
>   Moved.
> the "port" function parameter isn't even checked
>   Add check for exact match.
> If dropping the code is safe without also forbidding the
> combination of nested and VMware emulation.
>   Added the forbidding the combination of nested and VMware.
>   Mostly do to the cases of the nested virtual code is the one
>   to handle VMware stuff if needed, not the root one.  Also I am
>   having issues testing xen nested in xen and using hvm.
>
> v7:
>   More on AMD in the commit message.
>   Switch to only change 32bit part of registers, what VMware
> does.
> Too much logging and tracing.
>   Dropped a lot of it.  This includes vmport_debug=
>
> v6:
>   Dropped the attempt to use svm_nextrip_insn_length via
>   __get_instruction_length (added in v2).  Just always look
>   at upto 15 bytes on AMD.
>
> v5:
>   we should make sure that svm_vmexit_gp_intercept is not executed for
>   any other guest.
> Added an ASSERT on is_vmware_port_enabled.
>   magic integers?
> Added #define for them.
>   I am fairly certain that you need some brackets here.
> Added brackets.
>
>  xen/arch/x86/domain.c |   4 ++
>  xen/arch/x86/hvm/hvm.c|   9 +++
>  xen/arch/x86/hvm/vmware/Makefile  |   1 +
>  xen/arch/x86/hvm/vmware/vmport.c  | 143 
> ++
>  xen/include/asm-x86/hvm/domain.h  |   3 +
>  xen/include/asm-x86/hvm/hvm.h |   2 +
>  xen/include/public/arch-x86/xen.h |   4 ++
>  7 files changed, 166 insertions(+)
>  create mode 100644 xen/arch/x86/hvm/vmware/vmport.c
>
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index bc3d3a5..153048a 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86

[Xen-devel] [PATCH] xen/x86: Don't unconditionally touch the hvm_domain union during domain construction

[Andrew Cooper]

It may not be the appropriate half to touch.

Drop the superfluous mem_sharing_enabled assignment, and move the hap_enabled
assignment to a suitable conditional before it is actually needed.

Signed-off-by: Andrew Cooper 
CC: Keir Fraser 
CC: Jan Beulich 
---
 xen/arch/x86/domain.c |   11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 1f1550e..6e9464c 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -513,12 +513,6 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 int i, paging_initialised = 0;
 int rc = -ENOMEM;
 
-d->arch.hvm_domain.hap_enabled =
-has_hvm_container_domain(d) &&
-hvm_funcs.hap_supported &&
-(domcr_flags & DOMCRF_hap);
-d->arch.hvm_domain.mem_sharing_enabled = 0;
-
 d->arch.s3_integrity = !!(domcr_flags & DOMCRF_s3_integrity);
 
 INIT_LIST_HEAD(&d->arch.pdev_list);
@@ -541,7 +535,12 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 }
 
 if ( has_hvm_container_domain(d) )
+{
+d->arch.hvm_domain.hap_enabled =
+hvm_funcs.hap_supported && (domcr_flags & DOMCRF_hap);
+
 rc = create_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0, NULL, NULL);
+}
 else if ( is_idle_domain(d) )
 rc = 0;
 else
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH v10 02/10] xen: Add support for VMware cpuid leaves

[Andrew Cooper]

On 15/05/15 00:34, Don Slutz wrote:
> This is done by adding xen_arch_domainconfig vmware_hw. It is set to
> the VMware virtual hardware version.
>
> Currently 0, 3-4, 6-11 are good values.  However the
> code only checks for == 0 or != 0 or >= 7.
>
> If non-zero then
>   Return VMware's cpuid leaves.  If >= 7 return data, else
>   return 0.
>
> The support of hypervisor cpuid leaves has not been agreed to.
>
> MicroSoft Hyper-V (AKA viridian) currently must be at 0x4000.
>
> VMware currently must be at 0x4000.
>
> KVM currently must be at 0x4000 (from Seabios).
>
> Xen can be found at the first otherwise unused 0x100 aligned
> offset between 0x4000 and 0x4001.
>
> http://download.microsoft.com/download/F/B/0/FB0D01A3-8E3A-4F5F-AA59-08C8026D3B8A/requirements-for-implementing-microsoft-hypervisor-interface.docx
>
> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009458
>
> http://lwn.net/Articles/301888/
>   Attempted to get this cleaned up.
>
> So based on this, I picked the order:
>
> Xen at 0x4000 or
> Viridian or VMware at 0x4000 and Xen at 0x4100
>
> If both Viridian and VMware selected, report an error.
>
> Since I need to change xen/arch/x86/hvm/Makefile; also add
> a newline at end of file.
>
> Signed-off-by: Don Slutz 
> Reviewed-by: Andrew Cooper 
> ---
> v10:
> Did not add "Reviewed-by: Andrew Cooper "
> because of changes here to do things the new way.
>   Reword comment message to reflect new way.

In which case by above tag doesn't count.

>
> v9:
> s/vmware_hw/vmware_hwver/i
> Change -EXDEV to EOPNOTSUPP.
>   Done.
> adding another subdirectory: xen/arch/x86/hvm/vmware
> Much will depend on the discussion of the subsequent patches.
>   TBD.
> So for versions < 7 there's effectively no CPUID support at all?
>   Changed to check at entry.
> The comment /* Params for VMware */ seems wrong...
>   Changed to /* emulated VMware Hardware Version */
> Also please use d, not _d in #define is_vmware_domain()
>   Changed.  Line is now > 80 characters, so split into 2.
>
> v7:
>   Prevent setting of HVM_PARAM_VIRIDIAN if HVM_PARAM_VMWARE_HW set.
> v5:
>   Given how is_viridian and is_vmware are defined I think '||' is more
>   appropriate.
> Fixed.
>   The names of all three functions are bogus.
> removed static support routines.
>   This hunk is unrelated, but is perhaps something better fixed.
> Added to commit message.
>   include  (IIRC) please.
> Done.
>   At least 1 pair of brackets please, especially as the placement of
>   brackets affects the result of this particular calculation.
> Switch to "100ull / APIC_BUS_CYCLE_NS"  
>
>  xen/arch/x86/domain.c |  2 ++
>  xen/arch/x86/hvm/Makefile |  1 +
>  xen/arch/x86/hvm/hvm.c| 11 ++
>  xen/arch/x86/hvm/vmware/Makefile  |  1 +
>  xen/arch/x86/hvm/vmware/cpuid.c   | 75 
> +++
>  xen/arch/x86/traps.c  |  8 +++--
>  xen/include/asm-x86/hvm/domain.h  |  3 ++
>  xen/include/asm-x86/hvm/hvm.h |  6 
>  xen/include/asm-x86/hvm/vmware.h  | 33 +
>  xen/include/public/arch-x86/xen.h |  2 +-
>  10 files changed, 139 insertions(+), 3 deletions(-)
>  create mode 100644 xen/arch/x86/hvm/vmware/Makefile
>  create mode 100644 xen/arch/x86/hvm/vmware/cpuid.c
>  create mode 100644 xen/include/asm-x86/hvm/vmware.h
>
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 1f1550e..bc3d3a5 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -518,6 +518,8 @@ int arch_domain_create(struct domain *d, unsigned int 
> domcr_flags,
>  hvm_funcs.hap_supported &&
>  (domcr_flags & DOMCRF_hap);
>  d->arch.hvm_domain.mem_sharing_enabled = 0;
> +if ( config )
> +d->arch.hvm_domain.vmware_hwver = config->vmware_hwver;

Urgh - as a result of this I have found a differet bug in this
function.  Please rebase this change over my bugfix patch which I will
post shortly.

>  
>  d->arch.s3_integrity = !!(domcr_flags & DOMCRF_s3_integrity);
>  
> diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
> index 69af47f..284ca75 100644
> --- a/xen/arch/x86/hvm/Makefile
> +++ b/xen/arch/x86/hvm/Makefile
> @@ -1,5 +1,6 @@
>  subdir-y += svm
>  subdir-y += vmx
> +subdir-y += vmware
>  
>  obj-y += asid.o
>  obj-y += emulate.o
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 689e402..05c80e9 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -59,6 +59,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -4253,6 +4254,9 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
> unsigned int *ebx,
>  if ( cpuid_viridian_leaves(input, eax, ebx, ecx, edx) )
>  return;
>  
> +if ( cpuid_vmware_leaves(inp

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

[osstest service user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl   9 debian-install fail REGR. vs. 52209-bisect
 test-amd64-amd64-pair   15 debian-install/dst_host fail REGR. vs. 52715-bisect
 test-amd64-i386-pair15 debian-install/dst_host fail REGR. vs. 56366-bisect

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf  9 debian-installfail blocked in 56366-bisect
 test-amd64-amd64-libvirt  9 debian-installfail blocked in 56366-bisect
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail blocked in 56366-bisect
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail blocked in 56366-bisect
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail blocked in 56366-bisect
 test-amd64-i386-libvirt   9 debian-installfail blocked in 56366-bisect
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail blocked in 56366-bisect
 test-amd64-amd64-xl-sedf-pin  9 debian-installfail blocked in 56366-bisect
 test-amd64-i386-freebsd10-i386 15 guest-localmigrate.2 fail blocked in 
56366-bisect
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail blocked in 56366-bisect
 test-amd64-i386-xl9 debian-installfail blocked in 56366-bisect
 test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail blocked in 56366-bisect
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail blocked in 56366-bisect
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail blocked in 56366-bisect
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail blocked in 56366-bisect
 test-amd64-i386-rumpuserxen-i386  6 xen-boot  fail blocked in 56366-bisect
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail blocked in 56366-bisect
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail blocked in 56366-bisect
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 
56366-bisect

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-amd64-xl-credit2   9 debian-install   fail   never pass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-amd64-xl-pvh-amd   9 debian-install   fail   never pass
 test-amd64-i386-xl-xsm9 debian-install   fail   never pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-amd64-xl-pvh-intel  9 debian-install   fail  never pass
 test-amd64-amd64-libvirt-xsm  9 debian-install   fail   never pass
 test-amd64-amd64-xl-xsm   9 debian-install   fail   never pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 linux56b48fcda5076d4070ab00df32ff5ff834e0be86
baseline version:
 linuxbb4a05a0400ed6d2f1e13d1f82f289ff74300a70


370 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  fail
 test-amd64-i386-xl   fail
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm fail
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail
 test-amd64-amd64-libvirt-xsm fail 

Re: [Xen-devel] [RFC v2] xSplice design

[Lars Kurth]

Adding Don Slutz as he requested to be added
Lars

On 15/05/2015 20:44, "Konrad Rzeszutek Wilk" 
wrote:

>Hey!
>
>During the Xen Hacka^H^H^H^HProject Summit? we chatted about live-patching
>the hypervisor. We sketched out how it could be done, and brainstormed
>some of the problems.
>
>I took that and wrote an design - which is very much RFC. The design is
>laid out in two sections - the format of the ELF payload - and then the
>hypercalls to act on it.
>
>Hypercall preemption has caused a couple of XSAs so I've baked the need
>for that in the design so we hopefully won't have an XSA for this code.
>
>There are two big *TODO* in the design which I had hoped to get done
>before sending this out - however I am going on vacation for two weeks
>so I figured it would be better to send this off for folks to mull now
>then to have it languish.
>
>Please feel free to add more folks on the CC list.
>
>Enjoy!
>
>
># xSplice Design v1 (EXTERNAL RFC v2)
>
>## Rationale
>
>A mechanism is required to binarily patch the running hypervisor with new
>opcodes that have come about due to primarily security updates.
>
>This document describes the design of the API that would allow us to
>upload to the hypervisor binary patches.
>
>## Glossary
>
> * splice - patch in the binary code with new opcodes
> * trampoline - a jump to a new instruction.
> * payload - telemetries of the old code along with binary blob of the new
>   function (if needed).
> * reloc - telemetries contained in the payload to construct proper
>trampoline.
>
>## Multiple ways to patch
>
>The mechanism needs to be flexible to patch the hypervisor in multiple
>ways
>and be as simple as possible. The compiled code is contiguous in memory
>with
>no gaps - so we have no luxury of 'moving' existing code and must either
>insert a trampoline to the new code to be executed - or only modify
>in-place
>the code if there is sufficient space. The placement of new code has to
>be done
>by hypervisor and the virtual address for the new code is allocated
>dynamically.
>i
>This implies that the hypervisor must compute the new offsets when
>splicing
>in the new trampoline code. Where the trampoline is added (inside
>the function we are patching or just the callers?) is also important.
>
>To lessen the amount of code in hypervisor, the consumer of the API
>is responsible for identifying which mechanism to employ and how many
>locations
>to patch. Combinations of modifying in-place code, adding trampoline, etc
>has to be supported. The API should allow read/write any memory within
>the hypervisor virtual address space.
>
>We must also have a mechanism to query what has been applied and a
>mechanism
>to revert it if needed.
>
>We must also have a mechanism to: provide an copy of the old code - so
>that
>the hypervisor can verify it against the code in memory; the new code;
>the symbol name of the function to be patched; or offset from the symbol;
>or virtual address.
>
>The complications that this design will encounter are explained later
>in this document.
>
>## Patching code
>
>The first mechanism to patch that comes in mind is in-place replacement.
>That is replace the affected code with new code. Unfortunately the x86
>ISA is variable size which places limits on how much space we have
>available
>to replace the instructions.
>
>The second mechanism is by replacing the call or jump to the
>old function with the address of the new function.
>
>A third mechanism is to add a jump to the new function at the
>start of the old function.
>
>### Example of trampoline and in-place splicing
>
>As example we will assume the hypervisor does not have XSA-132 (see
>*domctl/sysctl: don't leak hypervisor stack to toolstacks*
>4ff3449f0e9d175ceb9551d3f2aecb59273f639d) and we would like to binary
>patch
>the hypervisor with it. The original code looks as so:
>
>
>   48 89 e0  mov%rsp,%rax
>   48 25 00 80 ff ff and$0x8000,%rax
>
>
>while the new patched hypervisor would be:
>
>
>   48 c7 45 b8 00 00 00 00   movq   $0x0,-0x48(%rbp)
>   48 c7 45 c0 00 00 00 00   movq   $0x0,-0x40(%rbp)
>   48 c7 45 c8 00 00 00 00   movq   $0x0,-0x38(%rbp)
>   48 89 e0  mov%rsp,%rax
>   48 25 00 80 ff ff and$0x8000,%rax
>
>
>This is inside the arch_do_domctl. This new change adds 21 extra
>bytes of code which alters all the offsets inside the function. To alter
>these offsets and add the extra 21 bytes of code we might not have enough
>space in .text to squeze this in.
>
>As such we could simplify this problem by only patching the site
>which calls arch_do_domctl:
>
>
>:  
> e8 4b b1 05 00  callq  82d08015fbb9 
>
>
>with a new address for where the new `arch_do_domctl` would be (this
>area would be allocated dynamically).
>
>Astute readers will wonder what we need to do if we were to patch
>`do_domctl`
>- which is not called directly by hypervisor but on behalf of the guests
>via
>the `compat_hypercall_table` and `

Re: [Xen-devel] [PATCH 4/4] x86: switch default mapping attributes to non-executable

[Andrew Cooper]

On 18/05/15 13:47, Jan Beulich wrote:
> Only a very limited subset of mappings need to be done as executable
> ones; in particular the direct mapping should not be executable to
> limit the damage attackers can cause by exploiting security relevant
> bugs.
>
> The EFI change at once includes an adjustment to set NX only when
> supported by the hardware.
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -293,7 +293,7 @@ struct vcpu_guest_context *alloc_vcpu_gu
>  free_vcpu_guest_context(NULL);
>  return NULL;
>  }
> -__set_fixmap(idx - i, page_to_mfn(pg), __PAGE_HYPERVISOR);
> +__set_fixmap(idx - i, page_to_mfn(pg), __PAGE_HYPERVISOR_RW);
>  per_cpu(vgc_pages[i], cpu) = pg;
>  }
>  return (void *)fix_to_virt(idx);
> --- a/xen/arch/x86/domain_page.c
> +++ b/xen/arch/x86/domain_page.c
> @@ -160,7 +160,7 @@ void *map_domain_page(unsigned long mfn)
>  
>  spin_unlock(&dcache->lock);
>  
> -l1e_write(&MAPCACHE_L1ENT(idx), l1e_from_pfn(mfn, __PAGE_HYPERVISOR));
> +l1e_write(&MAPCACHE_L1ENT(idx), l1e_from_pfn(mfn, __PAGE_HYPERVISOR_RW));
>  
>   out:
>  local_irq_restore(flags);
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4416,7 +4416,7 @@ long set_gdt(struct vcpu *v, 
>  for ( i = 0; i < nr_pages; i++ )
>  {
>  v->arch.pv_vcpu.gdt_frames[i] = frames[i];
> -l1e_write(&pl1e[i], l1e_from_pfn(frames[i], __PAGE_HYPERVISOR));
> +l1e_write(&pl1e[i], l1e_from_pfn(frames[i], __PAGE_HYPERVISOR_RW));
>  }
>  
>  xfree(pfns);
> @@ -6004,7 +6004,7 @@ int create_perdomain_mapping(struct doma
>  if ( !IS_NIL(ppg) )
>  *ppg++ = pg;
>  l1tab[l1_table_offset(va)] =
> -l1e_from_page(pg, __PAGE_HYPERVISOR | _PAGE_AVAIL0);
> +l1e_from_page(pg, __PAGE_HYPERVISOR_RW | _PAGE_AVAIL0);
>  l2e_add_flags(*pl2e, _PAGE_AVAIL0);
>  }
>  else
> @@ -6133,7 +6133,7 @@ void memguard_init(void)
>  (unsigned long)__va(start),
>  start >> PAGE_SHIFT,
>  (__pa(&_end) + PAGE_SIZE - 1 - start) >> PAGE_SHIFT,
> -__PAGE_HYPERVISOR|MAP_SMALL_PAGES);
> +__PAGE_HYPERVISOR_RW|MAP_SMALL_PAGES);
>  BUG_ON(start != xen_phys_start);
>  map_pages_to_xen(
>  XEN_VIRT_START,
> @@ -6146,7 +6146,7 @@ static void __memguard_change_range(void
>  {
>  unsigned long _p = (unsigned long)p;
>  unsigned long _l = (unsigned long)l;
> -unsigned int flags = __PAGE_HYPERVISOR | MAP_SMALL_PAGES;
> +unsigned int flags = __PAGE_HYPERVISOR_RW | MAP_SMALL_PAGES;
>  
>  /* Ensure we are dealing with a page-aligned whole number of pages. */
>  ASSERT((_p&~PAGE_MASK) == 0);
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -900,7 +900,7 @@ void __init noreturn __start_xen(unsigne
>  /* The only data mappings to be relocated are in the Xen area. */
>  pl2e = __va(__pa(l2_xenmap));
>  *pl2e++ = l2e_from_pfn(xen_phys_start >> PAGE_SHIFT,
> -   PAGE_HYPERVISOR | _PAGE_PSE);
> +   PAGE_HYPERVISOR_RWX | _PAGE_PSE);
>  for ( i = 1; i < L2_PAGETABLE_ENTRIES; i++, pl2e++ )
>  {
>  if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
> @@ -1087,7 +1087,7 @@ void __init noreturn __start_xen(unsigne
>  /* This range must not be passed to the boot allocator and
>   * must also not be mapped with _PAGE_GLOBAL. */
>  map_pages_to_xen((unsigned long)__va(map_e), PFN_DOWN(map_e),
> - PFN_DOWN(e - map_e), __PAGE_HYPERVISOR);
> + PFN_DOWN(e - map_e), __PAGE_HYPERVISOR_RW);
>  }
>  if ( s < map_s )
>  {
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -895,6 +895,33 @@ void __init subarch_init_memory(void)
>  share_xen_page_with_privileged_guests(page, XENSHARE_readonly);
>  }
>  }
> +
> +/* Mark low 16Mb of direct map NX if hardware supports it. */
> +if ( !cpu_has_nx )
> +return;
> +
> +v = DIRECTMAP_VIRT_START + (1UL << 20);

What about 0-1MB ?

> +l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(v)])[l3_table_offset(v)];
> +ASSERT(l3e_get_flags(l3e) & _PAGE_PRESENT);
> +do {
> +l2e = l3e_to_l2e(l3e)[l2_table_offset(v)];
> +ASSERT(l2e_get_flags(l2e) & _PAGE_PRESENT);
> +if ( l2e_get_flags(l2e) & _PAGE_PSE )
> +{
> +l2e_add_flags(l2e, _PAGE_NX_BIT);
> +l3e_to_l2e(l3e)[l2_table_offset(v)] = l2e;
> +v += 1 << L2_PAGETABLE_SHIFT;
> +}
> +else
> +{
> +l1_pgentry_t l1e = l2e_to_l1e(l2e)[l1_table_offset(v)];
> +
> +ASSERT(l1e_get_flags(l1e) & _PAGE_PRESENT);
> +l1e

Re: [Xen-devel] [PATCHv1] xen/events: don't bind non-percpu VIRQs with percpu chip

[Boris Ostrovsky]

On 05/19/2015 01:50 PM, David Vrabel wrote:

A non-percpu VIRQ (e.g., VIRQ_CONSOLE) may be freed on a different
VCPU than it is bound to.  This can result in a race between
handle_percpu_irq() and removing the action in __free_irq() because
handle_percpu_irq() does not take desc->lock.  The interrupt handler
sees a NULL action and oopses.

Only use the percpu chip/handler for per-CPU VIRQs (like VIRQ_TIMER).

   # cat /proc/interrupts | grep virq
40:  87246  0  xen-percpu-virq  timer0
44:  0  0  xen-percpu-virq  debug0
47:  0  20995  xen-percpu-virq  timer1
51:  0  0  xen-percpu-virq  debug1
69:  0  0   xen-dyn-virq  xen-pcpu
74:  0  0   xen-dyn-virq  mce
75: 29  0   xen-dyn-virq  hvc_console

Signed-off-by: David Vrabel 
Cc: 


Since we also use percpu handler when binding for IPIs should we also 
set explicitly set IRQF_PERCPU in bind_ipi_to_irqhandler() (and drop it 
from call sites)?


Regardless of that,

Reviewed-by: Boris Ostrovsky 



---
  drivers/tty/hvc/hvc_xen.c|2 +-
  drivers/xen/events/events_base.c |   12 
  include/xen/events.h |2 +-
  3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 5bab1c6..7a3d146 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -289,7 +289,7 @@ static int xen_initial_domain_console_init(void)
return -ENOMEM;
}
  
-	info->irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);

+   info->irq = bind_virq_to_irq(VIRQ_CONSOLE, 0, false);
info->vtermno = HVC_COOKIE;
  
  	spin_lock(&xencons_lock);

diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 2b8553b..3838795 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -957,7 +957,7 @@ unsigned xen_evtchn_nr_channels(void)
  }
  EXPORT_SYMBOL_GPL(xen_evtchn_nr_channels);
  
-int bind_virq_to_irq(unsigned int virq, unsigned int cpu)

+int bind_virq_to_irq(unsigned int virq, unsigned int cpu, bool percpu)
  {
struct evtchn_bind_virq bind_virq;
int evtchn, irq, ret;
@@ -971,8 +971,12 @@ int bind_virq_to_irq(unsigned int virq, unsigned int cpu)
if (irq < 0)
goto out;
  
-		irq_set_chip_and_handler_name(irq, &xen_percpu_chip,

- handle_percpu_irq, "virq");
+   if (percpu)
+   irq_set_chip_and_handler_name(irq, &xen_percpu_chip,
+ handle_percpu_irq, 
"virq");
+   else
+   irq_set_chip_and_handler_name(irq, &xen_dynamic_chip,
+ handle_edge_irq, "virq");
  
  		bind_virq.virq = virq;

bind_virq.vcpu = cpu;
@@ -1062,7 +1066,7 @@ int bind_virq_to_irqhandler(unsigned int virq, unsigned 
int cpu,
  {
int irq, retval;
  
-	irq = bind_virq_to_irq(virq, cpu);

+   irq = bind_virq_to_irq(virq, cpu, irqflags & IRQF_PERCPU);
if (irq < 0)
return irq;
retval = request_irq(irq, handler, irqflags, devname, dev_id);
diff --git a/include/xen/events.h b/include/xen/events.h
index 5321cd9..7d95fdf 100644
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -17,7 +17,7 @@ int bind_evtchn_to_irqhandler(unsigned int evtchn,
  irq_handler_t handler,
  unsigned long irqflags, const char *devname,
  void *dev_id);
-int bind_virq_to_irq(unsigned int virq, unsigned int cpu);
+int bind_virq_to_irq(unsigned int virq, unsigned int cpu, bool percpu);
  int bind_virq_to_irqhandler(unsigned int virq, unsigned int cpu,
irq_handler_t handler,
unsigned long irqflags, const char *devname,



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

Re: [Xen-devel] [PATCH V3 3/6] libxl: add pvusb API

[Ian Campbell]

On Tue, 2015-05-19 at 19:06 +0100, George Dunlap wrote:
> > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> > index 6bc75c5..cbe3519 100644
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> > @@ -114,6 +114,12 @@
> >  #define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1
> >
> >  /*
> > + * LIBXL_HAVE_PVUSB indicates the functions for doing hot-plug of
> > + * USB devices through pvusb.
> > + */
> > +#define LIBXL_HAVE_PVUSB 1
> 
> It seems like we should document somewhere how we expect these to be
> used -- namely the connection between usbctrl and usb devices.  In
> particular, that you can either add a usbctrl, and then add a usb
> device to it specifically; or if you don't specify a usbctrl when
> calling usb_add, it will find the most reasonable one to add it to,
> even creating one for you if you didn't have one.

(I've not checked if this exists in the series yet, but...)

I'd like to see some docs added to libxl.h as an addendum to the
existing:

 * Devices
 * ===
 *
 * Each device is represented by a libxl_device_ data structure
 ...

stuff which describes the general form of interfaces used for those
classes of device which distinguish the controller from the devices
themselves in the libxl API.

The new docs should then be applicable to e..g the pvscsi stuff as well.

The goal is to avoid having numerous subtly different style of device
interaction in the libxl API by grouping them into the least number of
logical groups (thus far 2: ones with explicit controllers and those
without) each with a consistent API.

Ian.


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

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

[osstest service user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 56375
 test-armhf-armhf-xl-multivcpu 17 leak-check/check fail REGR. vs. 56375

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64 13 guest-localmigrate fail REGR. vs. 56375
 test-amd64-amd64-libvirt 11 guest-start   fail REGR. vs. 56375
 test-amd64-i386-freebsd10-i386 15 guest-localmigrate.2   fail blocked in 56375
 test-armhf-armhf-libvirt 11 guest-start  fail   like 56375
 test-amd64-i386-libvirt  11 guest-start  fail   like 56375
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 56544-bisect

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-amd64-xl-xsm  11 guest-start  fail   never pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-i386-xl-xsm   11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 11 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  11 guest-start  fail   never pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-xsm   6 xen-boot fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-armhf-armhf-xl-sedf 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  0d7a599afff0665c74f328f6af85e556688d7908
baseline version:
 xen  e13013dbf1d5997915548a3b5f1c39594d8c1d7b


People who touched revisions under test:
  David Vrabel 
  George Dunlap 
  Ian Campbell 
  Jan Beulich 
  Julien Grall  (ARM)
  Konrad Rzeszutek Wilk 
  Roger Pau Monné 


jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm fail
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail
 test-amd64-amd64-libvirt-xsm fail
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  fa

Re: [Xen-devel] [PATCH V3 3/6] libxl: add pvusb API

[George Dunlap]

On Sun, Apr 19, 2015 at 4:50 AM, Chunyan Liu  wrote:
> +int libxl_device_usbctrl_getinfo(libxl_ctx *ctx, uint32_t domid,
> +libxl_device_usbctrl *usbctrl,
> +libxl_usbctrlinfo *usbctrlinfo)
> +{
> +GC_INIT(ctx);
> +char *dompath, *usbctrlpath;
> +char *val;
> +int rc = 0;
> +
> +usbctrlinfo->devid = usbctrl->devid;
> +usbctrlinfo->ports = usbctrl->ports;
> +usbctrlinfo->version = usbctrl->version;

...and following on from the previous mail, it looks like the other
device_*_getinfo() functions *only* read devid -- which means you just
have to make the struct and fill in devid, and getinfo() will tell
*you* the ports, the version, and so on.

 -George

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

Re: [Xen-devel] [PATCH v2 5/6] flask/policy: Add SECINITSID_DOMU as default domU SSID

[Ian Campbell]

On Tue, 2015-05-19 at 13:02 -0400, Daniel De Graaf wrote:
> On 05/19/2015 09:44 AM, Ian Campbell wrote:
> > From: Daniel De Graaf 
> >
> > Acked-by: Ian Campbell 
> > ---
> > Daniel -- this is from your example patch in
> > <2b0e.8050...@tycho.nsa.gov> and so needs your S-o-b, please.
> 
> Signed-off-by: Daniel De Graaf 
> 
> Or you can apply the combined patch that I am also sending that adds
> INITSIDs for both domU and domDM.

I might as well to this and handle setting a default ssid for the
stubdom in the following patch in a v3 series at the same time.

Thanks!

Ian.



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

Re: [Xen-devel] [PATCH V3 3/6] libxl: add pvusb API

[George Dunlap]

On Sun, Apr 19, 2015 at 4:50 AM, Chunyan Liu  wrote:
> +int libxl_device_usb_getinfo(libxl_ctx *ctx, char *busid, libxl_usbinfo 
> *usbinfo)
> +{

Sorry, missed something.  This function is wrong.  It gives you
information about a *host* USB device; but should properly give you
information about a *guest* USB device.  The
libxl_device_disk_getinfo() counterpart, for example, takes a domid
and a virtual device (from within a libxl_disk structure) and returns
information about that virtual device.

Hrm... which makes me wonder whether we should use  as a
unique "handle" for usb devices in the interface, or have a separate
devid for the devices themselves.

 -George

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

Re: [Xen-devel] Xen BUG at page_alloc.c:1738 (Xen 4.5)

[Andrew Cooper]

On 19/05/15 19:06, Major Hayden wrote:
> Hello there,
>
> I've been doing some testing of Xen 4.5 on Fedora 22 (due out within a week) 
> and I have an error that prevents the server from booting in the very early 
> boot process:
>
>> (XEN) Xen call trace:
>> (XEN)[] free_domheap_pages+0x240/0x430
>> (XEN)[] mmio_ro_do_page_fault+0x114/0x160
>> (XEN)[] do_page_fault+0x1a0/0x4f0
>> (XEN)[] handle_exception_saved+0x2e/0x6c
>> (XEN) 
>> (XEN) 
>> (XEN) 
>> (XEN) Panic on CPU 0:
>> (XEN) Xen BUG at page_alloc.c:1738
>> (XEN) 
> The full output is over in a Github Gist[1].
>
> I've tested this on some physical machines (Dell, HP, and SuperMicro servers) 
> as well as within a KVM virtual machine but I get the same boot error each 
> time.  It occurs with Xen 4.5 and Linux 3.17-4.0.x.  Xen 4.5.1-rc1 fails in 
> the same way.  I've opened a Red Hat Bug[2] as well as a Xen bug[3] on it.
>
> The code within free_domheap_pages() hasn't changed much since late 2014 so 
> I'm not sure if that's the culprit.  Does anyone have any suggestions on how 
> to debug it further?
>
> Thanks in advance!
>
> [1] https://gist.github.com/major/baa0e2eee7de51a2bcd1
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1219197
> [3] http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1908

Can you try a debug hypervisor and rerun, to confirm the stack trace and
see whether any assertions fire.

Can you identify exactly which line xen/common/page_alloc.c:1738 is in
your source?

~Andrew

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

[Xen-devel] Xen BUG at page_alloc.c:1738 (Xen 4.5)

[Major Hayden]

Hello there,

I've been doing some testing of Xen 4.5 on Fedora 22 (due out within a week) 
and I have an error that prevents the server from booting in the very early 
boot process:

> (XEN) Xen call trace:
> (XEN)[] free_domheap_pages+0x240/0x430
> (XEN)[] mmio_ro_do_page_fault+0x114/0x160
> (XEN)[] do_page_fault+0x1a0/0x4f0
> (XEN)[] handle_exception_saved+0x2e/0x6c
> (XEN) 
> (XEN) 
> (XEN) 
> (XEN) Panic on CPU 0:
> (XEN) Xen BUG at page_alloc.c:1738
> (XEN) 

The full output is over in a Github Gist[1].

I've tested this on some physical machines (Dell, HP, and SuperMicro servers) 
as well as within a KVM virtual machine but I get the same boot error each 
time.  It occurs with Xen 4.5 and Linux 3.17-4.0.x.  Xen 4.5.1-rc1 fails in the 
same way.  I've opened a Red Hat Bug[2] as well as a Xen bug[3] on it.

The code within free_domheap_pages() hasn't changed much since late 2014 so I'm 
not sure if that's the culprit.  Does anyone have any suggestions on how to 
debug it further?

Thanks in advance!

[1] https://gist.github.com/major/baa0e2eee7de51a2bcd1
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1219197
[3] http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1908

--
Major Hayden

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

Re: [Xen-devel] [PATCH V3 3/6] libxl: add pvusb API

[George Dunlap]

On Sun, Apr 19, 2015 at 4:50 AM, Chunyan Liu  wrote:
> Add pvusb APIs, including:
>  - attach/detach (create/destroy) virtual usb controller.
>  - attach/detach usb device
>  - list usb controller and usb devices
>  - some other helper functions
>
> Signed-off-by: Chunyan Liu 
> Signed-off-by: Simon Cao 

OK, getting closer. :-)

A number of comments:

> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 6bc75c5..cbe3519 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -114,6 +114,12 @@
>  #define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1
>
>  /*
> + * LIBXL_HAVE_PVUSB indicates the functions for doing hot-plug of
> + * USB devices through pvusb.
> + */
> +#define LIBXL_HAVE_PVUSB 1

It seems like we should document somewhere how we expect these to be
used -- namely the connection between usbctrl and usb devices.  In
particular, that you can either add a usbctrl, and then add a usb
device to it specifically; or if you don't specify a usbctrl when
calling usb_add, it will find the most reasonable one to add it to,
even creating one for you if you didn't have one.


> diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_pvusb.c
> new file mode 100644
> index 000..4e4975a
> --- /dev/null
> +++ b/tools/libxl/libxl_pvusb.c

> +int libxl__device_usbctrl_add(libxl__gc *gc, uint32_t domid,
> +  libxl_device_usbctrl *usbctrl)
> +{
> +int rc = 0;
> +
> +rc = libxl__device_usbctrl_setdefault(gc, domid, usbctrl);
> +if (rc < 0) goto out;
> +
> +if (usbctrl->devid == -1) {

Hmm, I was doing to say that this shouldn't be a magic constant, but
it looks like that's what all the other devices do :-/

> +static bool is_usb_in_array(libxl_device_usb *usbs, int num,
> +libxl_device_usb *usb)
> +{
> +int i;
> +
> +for (i = 0; i < num; i++) {
> +if (!strcmp(usbs[i].busid, usb->busid) )

Here (and elsewhere) you should probably use the COMPARE_USB() macro
you define in this patch.

> +/* check if USB device type is assignable */
> +static bool is_usb_assignable(libxl__gc *gc, libxl_device_usb *usb)
> +{
> +libxl_ctx *ctx = libxl__gc_owner(gc);
> +int classcode;
> +char *filename;
> +void *buf;
> +
> +assert(usb->busid);
> +
> +filename = GCSPRINTF(SYSFS_USB_DEV"/%s/bDeviceClass", usb->busid);
> +if (libxl_read_file_contents(ctx, filename, &buf, NULL) < 0)
> +return false;
> +
> +sscanf(buf, "%x", &classcode);
> +if (classcode == USBHUB_CLASS_CODE)
> +return false;
> +
> +return true;

Just checking, is it really the case that *all* USB classes are
assignable, *except* for hubs?

This is a minor thing, but this might be simper to do this:

 return classcode != USBHUB_CLASS_CODE;

> +/* get usb devices under certain usb controller */
> +static int libxl__device_usb_list(libxl__gc *gc, uint32_t domid, int usbctrl,
> +  libxl_device_usb **usbs, int *num)
> +{
> +char *be_path, *num_devs;
> +int n, i;
> +
> +*usbs = NULL;
> +*num = 0;
> +
> +be_path = GCSPRINTF("%s/backend/vusb/%d/%d",
> +libxl__xs_get_dompath(gc, 0), domid, usbctrl);
> +num_devs = libxl__xs_read(gc, XBT_NULL,
> +  GCSPRINTF("%s/num-ports", be_path));
> +if (!num_devs)
> +return 0;
> +
> +n = atoi(num_devs);
> +*usbs = calloc(n, sizeof(libxl_device_usb));
> +
> +for (i = 0; i < n; i++) {
> +char *busid;
> +libxl_device_usb *usb = NULL;
> +
> +busid = libxl__xs_read(gc, XBT_NULL,
> +   GCSPRINTF("%s/port/%d", be_path, i + 1));
> +if (busid && strcmp(busid, "")) {
> +usb = *usbs + *num;
> +usb->ctrl = usbctrl;
> +usb->port = i + 1;
> +usb->busid = strdup(busid);

This needs to populate the hostbus / hostaddr as well; busid is pretty
useless to users / external callers.

> +/* get all usb devices of the domain */
> +static libxl_device_usb *
> +libxl_device_usb_list_all(libxl__gc *gc, uint32_t domid, int *num)
> +{
> +char **usbctrls;
> +unsigned int nd, i, j;
> +char *be_path;
> +int rc;
> +libxl_device_usb *usbs = NULL;
> +
> +*num = 0;
> +
> +be_path = GCSPRINTF("/local/domain/%d/backend/vusb/%d",
> +LIBXL_TOOLSTACK_DOMID, domid);
> +usbctrls = libxl__xs_directory(gc, XBT_NULL, be_path, &nd);
> +
> +for (i = 0; i < nd; i++) {
> +int nc = 0;
> +libxl_device_usb *tmp = NULL;
> +rc = libxl__device_usb_list(gc, domid, atoi(usbctrls[i]), &tmp, &nc);
> +if (!nc) continue;
> +
> +usbs = realloc(usbs, sizeof(libxl_device_usb)*((*num) + nc));
> +for(j = 0; j < nc; j++) {
> +usbs[*num].ctrl = tmp[j].ctrl;
> +usbs[*num].port = tmp[j].port;
> +usbs[*num].busid = strdup(tmp[j].busid);

This needs to copy the hostaddr and busaddr a

[Xen-devel] [PATCHv1] xen/events: don't bind non-percpu VIRQs with percpu chip

[David Vrabel]

A non-percpu VIRQ (e.g., VIRQ_CONSOLE) may be freed on a different
VCPU than it is bound to.  This can result in a race between
handle_percpu_irq() and removing the action in __free_irq() because
handle_percpu_irq() does not take desc->lock.  The interrupt handler
sees a NULL action and oopses.

Only use the percpu chip/handler for per-CPU VIRQs (like VIRQ_TIMER).

  # cat /proc/interrupts | grep virq
   40:  87246  0  xen-percpu-virq  timer0
   44:  0  0  xen-percpu-virq  debug0
   47:  0  20995  xen-percpu-virq  timer1
   51:  0  0  xen-percpu-virq  debug1
   69:  0  0   xen-dyn-virq  xen-pcpu
   74:  0  0   xen-dyn-virq  mce
   75: 29  0   xen-dyn-virq  hvc_console

Signed-off-by: David Vrabel 
Cc: 
---
 drivers/tty/hvc/hvc_xen.c|2 +-
 drivers/xen/events/events_base.c |   12 
 include/xen/events.h |2 +-
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 5bab1c6..7a3d146 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -289,7 +289,7 @@ static int xen_initial_domain_console_init(void)
return -ENOMEM;
}
 
-   info->irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
+   info->irq = bind_virq_to_irq(VIRQ_CONSOLE, 0, false);
info->vtermno = HVC_COOKIE;
 
spin_lock(&xencons_lock);
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 2b8553b..3838795 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -957,7 +957,7 @@ unsigned xen_evtchn_nr_channels(void)
 }
 EXPORT_SYMBOL_GPL(xen_evtchn_nr_channels);
 
-int bind_virq_to_irq(unsigned int virq, unsigned int cpu)
+int bind_virq_to_irq(unsigned int virq, unsigned int cpu, bool percpu)
 {
struct evtchn_bind_virq bind_virq;
int evtchn, irq, ret;
@@ -971,8 +971,12 @@ int bind_virq_to_irq(unsigned int virq, unsigned int cpu)
if (irq < 0)
goto out;
 
-   irq_set_chip_and_handler_name(irq, &xen_percpu_chip,
- handle_percpu_irq, "virq");
+   if (percpu)
+   irq_set_chip_and_handler_name(irq, &xen_percpu_chip,
+ handle_percpu_irq, 
"virq");
+   else
+   irq_set_chip_and_handler_name(irq, &xen_dynamic_chip,
+ handle_edge_irq, "virq");
 
bind_virq.virq = virq;
bind_virq.vcpu = cpu;
@@ -1062,7 +1066,7 @@ int bind_virq_to_irqhandler(unsigned int virq, unsigned 
int cpu,
 {
int irq, retval;
 
-   irq = bind_virq_to_irq(virq, cpu);
+   irq = bind_virq_to_irq(virq, cpu, irqflags & IRQF_PERCPU);
if (irq < 0)
return irq;
retval = request_irq(irq, handler, irqflags, devname, dev_id);
diff --git a/include/xen/events.h b/include/xen/events.h
index 5321cd9..7d95fdf 100644
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -17,7 +17,7 @@ int bind_evtchn_to_irqhandler(unsigned int evtchn,
  irq_handler_t handler,
  unsigned long irqflags, const char *devname,
  void *dev_id);
-int bind_virq_to_irq(unsigned int virq, unsigned int cpu);
+int bind_virq_to_irq(unsigned int virq, unsigned int cpu, bool percpu);
 int bind_virq_to_irqhandler(unsigned int virq, unsigned int cpu,
irq_handler_t handler,
unsigned long irqflags, const char *devname,
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH v5 1/5] pci: add pci_iomap_wc() variants

[Luis R. Rodriguez]

On Thu, Apr 30, 2015 at 10:36:04AM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" 

<-- snip -->
> ---
> 
> This v5 makes the code return NULL for IORESOURCE_IO and fixes the commit
> log to clarify the conclusions reached for MTRR and our review of
> IORESOURCE_PREFETCH.
> 
>  include/asm-generic/pci_iomap.h | 14 ++
>  lib/pci_iomap.c | 61 
> +
>  2 files changed, 75 insertions(+)

Hey Bjorn, any feedack on this series? Thanks.

  Luis

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

Re: [Xen-devel] [PATCH 3/4] x86: move I/O emulation stubs off the stack

[Andrew Cooper]

On 18/05/15 13:47, Jan Beulich wrote:
> This is needed as stacks are going to become non-executable.
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2006,7 +2006,7 @@ static int emulate_privileged_op(struct 
> ? (*(u32 *)®s->reg = (val)) \
> : (*(u16 *)®s->reg = (val)))
>  unsigned long code_base, code_limit;
> -char io_emul_stub[32];
> +char *io_emul_stub = NULL;
>  void (*io_emul)(struct cpu_user_regs *) __attribute__((__regparm__(1)));
>  uint64_t val;
>  
> @@ -2195,6 +2195,9 @@ static int emulate_privileged_op(struct 
>   * GPR context. This is needed for some systems which (ab)use IN/OUT
>   * to communicate with BIOS code in system-management mode.
>   */

The comment (just out of context) needs tweaking.

> +io_emul_stub = map_domain_page(this_cpu(stubs.mfn)) +
> +   (this_cpu(stubs.addr) & (PAGE_SIZE - 1)) +
> +   STUB_BUF_SIZE / 2;
>  /* movq $host_to_guest_gpr_switch,%rcx */
>  io_emul_stub[0] = 0x48;
>  io_emul_stub[1] = 0xb9;
> @@ -2212,7 +2215,7 @@ static int emulate_privileged_op(struct 
>  io_emul_stub[15] = 0xc3;
>  
>  /* Handy function-typed pointer to the stub. */
> -io_emul = (void *)io_emul_stub;
> +io_emul = (void *)(this_cpu(stubs.addr) + STUB_BUF_SIZE / 2);

As an unrelated observation during review, the two gpr switch functions
should probably gain some knowledge of TRAP_regs_partial

~Andrew

>  
>  if ( ioemul_handle_quirk )
>  ioemul_handle_quirk(opcode, &io_emul_stub[12], regs);
> @@ -2777,9 +2780,13 @@ static int emulate_privileged_op(struct 
>   done:
>  instruction_done(regs, eip, bpmatch);
>   skip:
> +if ( io_emul_stub )
> +unmap_domain_page(io_emul_stub);
>  return EXCRET_fault_fixed;
>  
>   fail:
> +if ( io_emul_stub )
> +unmap_domain_page(io_emul_stub);
>  return 0;
>  }
>  
>
>
>


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

Re: [Xen-devel] Status of Credit2 and Credit1 [was: Re: Xen 4.6 Development Update (four months reminder)]

[Wei Liu]

On Sat, May 16, 2015 at 03:15:21AM +0200, Dario Faggioli wrote:
> On Wed, 2015-05-13 at 06:01 +0100, wei.l...@citrix.com wrote:
> 
> > = Prognosis =
> > 
> > The states are: none -> fair -> ok -> good -> done
> > 
> > none - nothing yet
> > fair - still working on it, patches are prototypes or RFC
> > ok   - patches posted, acting on review
> > good - some last minute pieces
> > done - all done, might have bugs
> 
> > == Hypervisor == 
> 
> > *  Credit2 production ready (none)
> >cpu reservation
> >   -  George Dunlap
> >
> No work on this yet, AFAIK. I may be able to look into it in a couple of
> weeks, but I still am not sure.
> 
> > === Hypervisor X86 === 
> 
> > *  HT enabled with credit has 7.9 per perf drop. (none)
> >kernbench demonstrated it
> >http://www.gossamer-threads.com/lists/xen/devel/339409
> >This has existed since credit1 introduction.
> >   -  Dario Faggioli
> >
> Let me clarify this a bit.
> 
> First of all, let me point out that the issue only shows up in
> under-loaded systems (i.e., with less active vcPUs then the host has
> pCPUs). In any case, this is something inherent in Credit1 architecture,
> and I don't have a sensible idea on how to deal with it without causing
> other problems.
> 
> I am working on some improvement to Credit1 (e.g., introducing load
> tracking and basing some decisions on it), which hopefully will help
> better performance even in this case, but I'm not actively working on
> fixing this (if it can be fixed).
> 

I have moved this to deferred section. Is this OK?

Wei.

> Regards,
> Dario



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

Re: [Xen-devel] [PATCH 2/4] x86emul: move stubs off the stack

[Andrew Cooper]

On 18/05/15 13:46, Jan Beulich wrote:
> This is needed as stacks are going to become non-executable.
>
> Signed-off-by: Jan Beulich 
>
> --- a/tools/tests/x86_emulator/x86_emulate.c
> +++ b/tools/tests/x86_emulator/x86_emulate.c
> @@ -17,4 +17,8 @@ typedef bool bool_t;
>  #define __packed __attribute__((packed))
>  
>  #include "x86_emulate/x86_emulate.h"
> +
> +#define get_stub(stb) ((void *)((stb).addr = (uintptr_t)(stb).buf))
> +#define put_stub(stb)
> +
>  #include "x86_emulate/x86_emulate.c"
> --- a/xen/arch/x86/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate.c
> @@ -9,6 +9,7 @@
>   *Keir Fraser 
>   */
>  
> +#include 
>  #include 
>  #include  /* mark_regs_dirty() */
>  #include  /* current_cpu_info */
> @@ -17,8 +18,22 @@
>  /* Avoid namespace pollution. */
>  #undef cmpxchg
>  #undef cpuid
> +#undef wbinvd
>  
>  #define cpu_has_amd_erratum(nr) \
>  cpu_has_amd_erratum(¤t_cpu_data, AMD_ERRATUM_##nr)
>  
> +#define get_stub(stb) ({   \
> +(stb).addr = this_cpu(stubs.addr) + STUB_BUF_SIZE / 2; \
> +((stb).ptr = map_domain_page(this_cpu(stubs.mfn))) +   \
> +((stb).addr & (PAGE_SIZE - 1));\
> +})
> +#define put_stub(stb) ({   \
> +if ( (stb).ptr )   \
> +{  \
> +unmap_domain_page((stb).ptr);  \
> +(stb).ptr = NULL;  \
> +}  \
> +})
> +

These don't need to be macros, and I suspect a compiler would choose to
out-of-line get_stub() if it could.

>  #include "x86_emulate/x86_emulate.c"
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -717,11 +717,14 @@ do{ struct fpu_insn_ctxt fic;   
>  } while (0)
>  
>  #define emulate_fpu_insn_stub(_bytes...)\
> -do{ uint8_t stub[] = { _bytes, 0xc3 };  \
> -struct fpu_insn_ctxt fic = { .insn_bytes = sizeof(stub)-1 };\
> +do{ uint8_t *buf = get_stub(stub);  \
> +unsigned int _nr = sizeof((uint8_t[]){ _bytes });   \
> +struct fpu_insn_ctxt fic = { .insn_bytes = _nr };\

Alignment of backslashes.

> +memcpy(buf, ((uint8_t[]){ _bytes, 0xc3 }), _nr + 1);\
>  get_fpu(X86EMUL_FPU_fpu, &fic); \
> -(*(void(*)(void))stub)();   \
> +stub.func();\
>  put_fpu(&fic);  \
> +put_stub(stub); \
>  } while (0)
>  
>  static unsigned long _get_rep_prefix(
> @@ -1458,6 +1461,7 @@ x86_emulate(
>  struct operand src = { .reg = REG_POISON };
>  struct operand dst = { .reg = REG_POISON };
>  enum x86_swint_type swint_type;
> +struct x86_emulate_stub stub = {};
>  DECLARE_ALIGNED(mmval_t, mmval);
>  /*
>   * Data operand effective address (usually computed from ModRM).
> @@ -3792,6 +3796,7 @@ x86_emulate(
>  
>   done:
>  _put_fpu();
> +put_stub(stub);
>  return rc;
>  
>   twobyte_insn:
> @@ -4007,9 +4012,15 @@ x86_emulate(
> /* {,v}movss xmm,xmm/m32 */
> /* {,v}movsd xmm,xmm/m64 */
>  {
> -uint8_t stub[] = { 0x3e, 0x3e, 0x0f, b, modrm, 0xc3 };
> -struct fpu_insn_ctxt fic = { .insn_bytes = sizeof(stub)-1 };
> +uint8_t *buf = get_stub(stub);
> +struct fpu_insn_ctxt fic = { .insn_bytes = 5 };
>  
> +buf[0] = 0x3e;
> +buf[1] = 0x3e;
> +buf[2] = 0x0f;
> +buf[3] = b;
> +buf[4] = modrm;
> +buf[5] = 0xc3;
>  if ( vex.opcx == vex_none )
>  {
>  if ( vex.pfx & VEX_PREFIX_DOUBLE_MASK )
> @@ -4017,7 +4028,7 @@ x86_emulate(
>  else
>  vcpu_must_have_sse();
>  ea.bytes = 16;
> -SET_SSE_PREFIX(stub[0], vex.pfx);
> +SET_SSE_PREFIX(buf[0], vex.pfx);
>  get_fpu(X86EMUL_FPU_xmm, &fic);
>  }
>  else
> @@ -4044,15 +4055,16 @@ x86_emulate(
>  /* convert memory operand to (%rAX) */
>  rex_prefix &= ~REX_B;
>  vex.b = 1;
> -stub[4] &= 0x38;
> +buf[4] &= 0x38;
>  }
>  if ( !rc )
>  {
> -   copy_REX_VEX(stub, rex_prefix, vex);
> -   asm volatile ( "call *%0" : : "r" (stub), "a" (mmvalp)
> +   copy_REX_VEX(buf, rex_prefix, vex);
> +   asm volatile ( "call *%0" : : "r" (stub.func), "a" (mmvalp)
>   : "memory" );
>  }
>  put_fpu(&fic);
> +put_stub(stub);
>  if (

Re: [Xen-devel] [PATCH 3/4] libxc: rework vnuma bits in setup_guest

[Wei Liu]

On Tue, May 19, 2015 at 06:14:27PM +0100, Wei Liu wrote:
[...]
> > >>
> > >>Does having high memory mean that we need to have 2 vnodes? We should be
> > >Yes, see the comment above.
> > >
> > >>able to cope with multiple vmemranges per node, right?
> > >
> > >Yes. That's already done in libxl's function to build hvm vmemranges.
> > >
> > >This is only a simple dummy layout so nothing fancy happens here.
> > 
> > 
> > Right. But having multiple vnodes for a dummy topology looks to me a little
> > counter-intuitive: people often assume that when number of nodes is 1 we
> > don't have any NUMA-ness. Here we may need to look at vnode_to_pnode
> > (possibly at both of the elements) to realize that this is a dummy layout.
> > 
> > And given that this layout can be expressed with nr_vnodes=1 &&
> > nr_vmemranges=2 I am not sure what we gain by having two vnodes.
> > 
> 
> Ah, so that's a bug: args->nr_vnodes++ should be deleted.
> 
> We still only have one vnode (nid = 0). That vnode contains two
> vmemranges.
> 

And because no code in setup_guest uses that value so the bug doesn't
affect the final guest layout. It will be fixed in version 2
nonetheless.

Wei.

> Wei.
> 
> > -boris
> > 
> > >
> > >Wei.
> > >
> > >>-boris
> > >>
> > >>
> > >>>+}
> > >>>+
> > >>>+args->vmemranges = dummy_vmemrange;
> > >>>+args->vnode_to_pnode = dummy_vnode_to_pnode;
> > >>>  }
> > >>>

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

Re: [Xen-devel] [PATCH 3/4] libxc: rework vnuma bits in setup_guest

[Boris Ostrovsky]

On 05/19/2015 01:14 PM, Wei Liu wrote:

On Tue, May 19, 2015 at 01:03:59PM -0400, Boris Ostrovsky wrote:

On 05/19/2015 12:31 PM, Wei Liu wrote:

On Tue, May 19, 2015 at 12:23:07PM -0400, Boris Ostrovsky wrote:

On 05/18/2015 11:34 AM, Wei Liu wrote:

Make the setup process similar to PV counterpart. That is, to allocate a
P2M array that covers the whole memory range and start from there. This
is clearer than using an array with no holes in it.

Also the dummy layout should take MMIO hole into consideration. We might
end up having two vmemranges in the dummy layout.

Signed-off-by: Wei Liu 
Cc: Ian Campbell 
Cc: Ian Jackson 
---
  tools/libxc/xc_hvm_build_x86.c | 66 --
  1 file changed, 50 insertions(+), 16 deletions(-)

diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index df4b7ed..77678f1 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -238,6 +238,7 @@ static int setup_guest(xc_interface *xch,
  {
  xen_pfn_t *page_array = NULL;
  unsigned long i, vmemid, nr_pages = args->mem_size >> PAGE_SHIFT;
+unsigned long p2m_size;
  unsigned long target_pages = args->mem_target >> PAGE_SHIFT;
  unsigned long entry_eip, cur_pages, cur_pfn;
  void *hvm_info_page;
@@ -254,8 +255,8 @@ static int setup_guest(xc_interface *xch,
  xen_pfn_t special_array[NR_SPECIAL_PAGES];
  xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
  uint64_t total_pages;
-xen_vmemrange_t dummy_vmemrange;
-unsigned int dummy_vnode_to_pnode;
+xen_vmemrange_t dummy_vmemrange[2];
+unsigned int dummy_vnode_to_pnode[2];
  memset(&elf, 0, sizeof(elf));
  if ( elf_init(&elf, image, image_size) != 0 )
@@ -275,17 +276,37 @@ static int setup_guest(xc_interface *xch,
  if ( args->nr_vmemranges == 0 )
  {
-/* Build dummy vnode information */
-dummy_vmemrange.start = 0;
-dummy_vmemrange.end   = args->mem_size;
-dummy_vmemrange.flags = 0;
-dummy_vmemrange.nid   = 0;
-args->nr_vmemranges = 1;
-args->vmemranges = &dummy_vmemrange;
+/* Build dummy vnode information
+ *
+ * Guest physical address space layout:
+ * [0, hole_start) [hole_start, 4G) [4G, highmem_end)
+ *
+ * Of course if there is no high memory, the second vmemrange
+ * has no effect on the actual result.
+ */
-dummy_vnode_to_pnode = XC_NUMA_NO_NODE;
+dummy_vmemrange[0].start = 0;
+dummy_vmemrange[0].end   = args->lowmem_end;
+dummy_vmemrange[0].flags = 0;
+dummy_vmemrange[0].nid   = 0;
+dummy_vnode_to_pnode[0]  = XC_NUMA_NO_NODE;
+args->nr_vmemranges = 1;
  args->nr_vnodes = 1;
-args->vnode_to_pnode = &dummy_vnode_to_pnode;
+
+if ( args->highmem_end > (1ULL << 32) )
+{
+dummy_vmemrange[1].start = 1ULL << 32;
+dummy_vmemrange[1].end   = args->highmem_end;
+dummy_vmemrange[1].flags = 0;
+dummy_vmemrange[1].nid   = 0;
+dummy_vnode_to_pnode[1]  = XC_NUMA_NO_NODE;
+
+args->nr_vmemranges++;
+args->nr_vnodes++;

(+Dario)

Does having high memory mean that we need to have 2 vnodes? We should be

Yes, see the comment above.


able to cope with multiple vmemranges per node, right?


Yes. That's already done in libxl's function to build hvm vmemranges.

This is only a simple dummy layout so nothing fancy happens here.



Right. But having multiple vnodes for a dummy topology looks to me a little
counter-intuitive: people often assume that when number of nodes is 1 we
don't have any NUMA-ness. Here we may need to look at vnode_to_pnode
(possibly at both of the elements) to realize that this is a dummy layout.

And given that this layout can be expressed with nr_vnodes=1 &&
nr_vmemranges=2 I am not sure what we gain by having two vnodes.



Ah, so that's a bug: args->nr_vnodes++ should be deleted.



And dummy_vnode_to_pnode[2] should become a scalar.

-boris




We still only have one vnode (nid = 0). That vnode contains two
vmemranges.

Wei.


-boris



Wei.


-boris



+}
+
+args->vmemranges = dummy_vmemrange;
+args->vnode_to_pnode = dummy_vnode_to_pnode;
  }




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

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

[osstest service user]

flight 56719 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56719/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 11 guest-start   fail REGR. vs. 53854
 test-amd64-i386-libvirt  11 guest-start   fail REGR. vs. 53854
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 53854

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 11 guest-start  fail   never pass

version targeted for testing:
 libvirt  a5b55bd93106b8e678964f1dbf363dca3af76286
baseline version:
 libvirt  fd74e231751334b64af0934b680c5cc62f652453


People who touched revisions under test:
  Andrea Bolognani 
  Boris Fiuczynski 
  Cole Robinson 
  Daniel Hansel 
  Jim Fehlig 
  Jiri Denemark 
  John Ferlan 
  Ján Tomko 
  Laine Stump 
  Luyao Huang 
  Martin Kletzander 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  Pavel Hrdina 
  Peter Krempa 
  Richard W.M. Jones 
  Roman Bogorodskiy 
  Tony Krowiak 
  Tony Krowiak 
  Viktor Mihajlovski 
  Wang Yufei 
  Zhang Bo 


jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  fail
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-xsm fail
 test-armhf-armhf-libvirt-xsm blocked
 test-amd64-i386-libvirt-xsm  fail
 test-amd64-amd64-libvirt fail
 test-armhf-armhf-libvirt blocked
 test-amd64-i386-libvirt  fail



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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH 3/4] libxc: rework vnuma bits in setup_guest

[Wei Liu]

On Tue, May 19, 2015 at 01:03:59PM -0400, Boris Ostrovsky wrote:
> On 05/19/2015 12:31 PM, Wei Liu wrote:
> >On Tue, May 19, 2015 at 12:23:07PM -0400, Boris Ostrovsky wrote:
> >>On 05/18/2015 11:34 AM, Wei Liu wrote:
> >>>Make the setup process similar to PV counterpart. That is, to allocate a
> >>>P2M array that covers the whole memory range and start from there. This
> >>>is clearer than using an array with no holes in it.
> >>>
> >>>Also the dummy layout should take MMIO hole into consideration. We might
> >>>end up having two vmemranges in the dummy layout.
> >>>
> >>>Signed-off-by: Wei Liu 
> >>>Cc: Ian Campbell 
> >>>Cc: Ian Jackson 
> >>>---
> >>>  tools/libxc/xc_hvm_build_x86.c | 66 
> >>> --
> >>>  1 file changed, 50 insertions(+), 16 deletions(-)
> >>>
> >>>diff --git a/tools/libxc/xc_hvm_build_x86.c 
> >>>b/tools/libxc/xc_hvm_build_x86.c
> >>>index df4b7ed..77678f1 100644
> >>>--- a/tools/libxc/xc_hvm_build_x86.c
> >>>+++ b/tools/libxc/xc_hvm_build_x86.c
> >>>@@ -238,6 +238,7 @@ static int setup_guest(xc_interface *xch,
> >>>  {
> >>>  xen_pfn_t *page_array = NULL;
> >>>  unsigned long i, vmemid, nr_pages = args->mem_size >> PAGE_SHIFT;
> >>>+unsigned long p2m_size;
> >>>  unsigned long target_pages = args->mem_target >> PAGE_SHIFT;
> >>>  unsigned long entry_eip, cur_pages, cur_pfn;
> >>>  void *hvm_info_page;
> >>>@@ -254,8 +255,8 @@ static int setup_guest(xc_interface *xch,
> >>>  xen_pfn_t special_array[NR_SPECIAL_PAGES];
> >>>  xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
> >>>  uint64_t total_pages;
> >>>-xen_vmemrange_t dummy_vmemrange;
> >>>-unsigned int dummy_vnode_to_pnode;
> >>>+xen_vmemrange_t dummy_vmemrange[2];
> >>>+unsigned int dummy_vnode_to_pnode[2];
> >>>  memset(&elf, 0, sizeof(elf));
> >>>  if ( elf_init(&elf, image, image_size) != 0 )
> >>>@@ -275,17 +276,37 @@ static int setup_guest(xc_interface *xch,
> >>>  if ( args->nr_vmemranges == 0 )
> >>>  {
> >>>-/* Build dummy vnode information */
> >>>-dummy_vmemrange.start = 0;
> >>>-dummy_vmemrange.end   = args->mem_size;
> >>>-dummy_vmemrange.flags = 0;
> >>>-dummy_vmemrange.nid   = 0;
> >>>-args->nr_vmemranges = 1;
> >>>-args->vmemranges = &dummy_vmemrange;
> >>>+/* Build dummy vnode information
> >>>+ *
> >>>+ * Guest physical address space layout:
> >>>+ * [0, hole_start) [hole_start, 4G) [4G, highmem_end)
> >>>+ *
> >>>+ * Of course if there is no high memory, the second vmemrange
> >>>+ * has no effect on the actual result.
> >>>+ */
> >>>-dummy_vnode_to_pnode = XC_NUMA_NO_NODE;
> >>>+dummy_vmemrange[0].start = 0;
> >>>+dummy_vmemrange[0].end   = args->lowmem_end;
> >>>+dummy_vmemrange[0].flags = 0;
> >>>+dummy_vmemrange[0].nid   = 0;
> >>>+dummy_vnode_to_pnode[0]  = XC_NUMA_NO_NODE;
> >>>+args->nr_vmemranges = 1;
> >>>  args->nr_vnodes = 1;
> >>>-args->vnode_to_pnode = &dummy_vnode_to_pnode;
> >>>+
> >>>+if ( args->highmem_end > (1ULL << 32) )
> >>>+{
> >>>+dummy_vmemrange[1].start = 1ULL << 32;
> >>>+dummy_vmemrange[1].end   = args->highmem_end;
> >>>+dummy_vmemrange[1].flags = 0;
> >>>+dummy_vmemrange[1].nid   = 0;
> >>>+dummy_vnode_to_pnode[1]  = XC_NUMA_NO_NODE;
> >>>+
> >>>+args->nr_vmemranges++;
> >>>+args->nr_vnodes++;
> >>(+Dario)
> >>
> >>Does having high memory mean that we need to have 2 vnodes? We should be
> >Yes, see the comment above.
> >
> >>able to cope with multiple vmemranges per node, right?
> >
> >Yes. That's already done in libxl's function to build hvm vmemranges.
> >
> >This is only a simple dummy layout so nothing fancy happens here.
> 
> 
> Right. But having multiple vnodes for a dummy topology looks to me a little
> counter-intuitive: people often assume that when number of nodes is 1 we
> don't have any NUMA-ness. Here we may need to look at vnode_to_pnode
> (possibly at both of the elements) to realize that this is a dummy layout.
> 
> And given that this layout can be expressed with nr_vnodes=1 &&
> nr_vmemranges=2 I am not sure what we gain by having two vnodes.
> 

Ah, so that's a bug: args->nr_vnodes++ should be deleted.

We still only have one vnode (nid = 0). That vnode contains two
vmemranges.

Wei.

> -boris
> 
> >
> >Wei.
> >
> >>-boris
> >>
> >>
> >>>+}
> >>>+
> >>>+args->vmemranges = dummy_vmemrange;
> >>>+args->vnode_to_pnode = dummy_vnode_to_pnode;
> >>>  }
> >>>

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

Re: [Xen-devel] [PATCH v2 5/6] flask/policy: Add SECINITSID_DOMU as default domU SSID

[Daniel De Graaf]

On 05/19/2015 09:44 AM, Ian Campbell wrote:

From: Daniel De Graaf 

Acked-by: Ian Campbell 
---
Daniel -- this is from your example patch in
<2b0e.8050...@tycho.nsa.gov> and so needs your S-o-b, please.


Signed-off-by: Daniel De Graaf 

Or you can apply the combined patch that I am also sending that adds
INITSIDs for both domU and domDM.


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

[Xen-devel] [PATCH] flask/policy: add initial SIDs for domU/domDM

[Daniel De Graaf]

Add default security contexts to the XSM policy for use by the toolstack
when a domain is created without specifying an explicit security label.

Signed-off-by: Daniel De Graaf 
---

 docs/misc/xsm-flask.txt  |  6 +++---
 tools/flask/policy/policy/initial_sids   |  4 
 tools/flask/policy/policy/modules/xen/xen.te | 11 +++
 xen/xsm/flask/policy/initial_sids|  2 ++
 4 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index d63a8a7..7249f40 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -213,9 +213,9 @@ that can be used without dom0 disaggregation. The main 
types for domUs are:
  - nomigrate_t is a domain that must be created via the nomigrate_t_building
type, and whose memory cannot be read by dom0 once created
 
-HVM domains with stubdomain device models use two types (one per domain):
- - domHVM_t is an HVM domain that uses a stubdomain device model
- - dm_dom_t is the device model for a domain with type domHVM_t
+HVM domains with stubdomain device models also need a type for the stub domain.
+The example policy defines dm_dom_t for the device model of a domU_t domain;
+there are no device model types defined for the other domU types.
 
 One disadvantage of using type enforcement to enforce isolation is that a new
 type is needed for each group of domains. The user field can be used to address
diff --git a/tools/flask/policy/policy/initial_sids 
b/tools/flask/policy/policy/initial_sids
index 5de0bbf..6b7b7ef 100644
--- a/tools/flask/policy/policy/initial_sids
+++ b/tools/flask/policy/policy/initial_sids
@@ -12,3 +12,7 @@ sid irq gen_context(system_u:object_r:irq_t,s0)
 sid iomem gen_context(system_u:object_r:iomem_t,s0)
 sid ioport gen_context(system_u:object_r:ioport_t,s0)
 sid device gen_context(system_u:object_r:device_t,s0)
+
+# Initial SIDs used by the toolstack for domains without defined labels
+sid domU gen_context(system_u:system_r:domU_t,s0)
+sid domDM gen_context(system_u:system_r:dm_dom_t,s0)
diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
b/tools/flask/policy/policy/modules/xen/xen.te
index e555d11..ce70639 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -151,18 +151,13 @@ domain_comms(domU_t, prot_domU_t)
 domain_comms(prot_domU_t, prot_domU_t)
 domain_self_comms(prot_domU_t)
 
-# domHVM_t is meant to be paired with a qemu-dm stub domain of type dm_dom_t
-declare_domain(domHVM_t)
-create_domain(dom0_t, domHVM_t)
-manage_domain(dom0_t, domHVM_t)
-domain_comms(dom0_t, domHVM_t)
-domain_self_comms(domHVM_t)
-
+# Device model for domU_t.  You can define distinct types for device models for
+# domains of other types, or add more make_device_model lines for this type.
 declare_domain(dm_dom_t)
 create_domain(dom0_t, dm_dom_t)
 manage_domain(dom0_t, dm_dom_t)
 domain_comms(dom0_t, dm_dom_t)
-make_device_model(dom0_t, dm_dom_t, domHVM_t)
+make_device_model(dom0_t, dm_dom_t, domU_t)
 
 # nomigrate_t must be built via the nomigrate_t_building label; once built,
 # dom0 cannot read its memory.
diff --git a/xen/xsm/flask/policy/initial_sids 
b/xen/xsm/flask/policy/initial_sids
index e508bde..7eca70d 100644
--- a/xen/xsm/flask/policy/initial_sids
+++ b/xen/xsm/flask/policy/initial_sids
@@ -13,4 +13,6 @@ sid ioport
 sid iomem
 sid irq
 sid device
+sid domU
+sid domDM
 # FLASK
-- 
2.1.0


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

Re: [Xen-devel] [PATCH 3/4] libxc: rework vnuma bits in setup_guest

[Boris Ostrovsky]

On 05/19/2015 12:31 PM, Wei Liu wrote:

On Tue, May 19, 2015 at 12:23:07PM -0400, Boris Ostrovsky wrote:

On 05/18/2015 11:34 AM, Wei Liu wrote:

Make the setup process similar to PV counterpart. That is, to allocate a
P2M array that covers the whole memory range and start from there. This
is clearer than using an array with no holes in it.

Also the dummy layout should take MMIO hole into consideration. We might
end up having two vmemranges in the dummy layout.

Signed-off-by: Wei Liu 
Cc: Ian Campbell 
Cc: Ian Jackson 
---
  tools/libxc/xc_hvm_build_x86.c | 66 --
  1 file changed, 50 insertions(+), 16 deletions(-)

diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index df4b7ed..77678f1 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -238,6 +238,7 @@ static int setup_guest(xc_interface *xch,
  {
  xen_pfn_t *page_array = NULL;
  unsigned long i, vmemid, nr_pages = args->mem_size >> PAGE_SHIFT;
+unsigned long p2m_size;
  unsigned long target_pages = args->mem_target >> PAGE_SHIFT;
  unsigned long entry_eip, cur_pages, cur_pfn;
  void *hvm_info_page;
@@ -254,8 +255,8 @@ static int setup_guest(xc_interface *xch,
  xen_pfn_t special_array[NR_SPECIAL_PAGES];
  xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
  uint64_t total_pages;
-xen_vmemrange_t dummy_vmemrange;
-unsigned int dummy_vnode_to_pnode;
+xen_vmemrange_t dummy_vmemrange[2];
+unsigned int dummy_vnode_to_pnode[2];
  memset(&elf, 0, sizeof(elf));
  if ( elf_init(&elf, image, image_size) != 0 )
@@ -275,17 +276,37 @@ static int setup_guest(xc_interface *xch,
  if ( args->nr_vmemranges == 0 )
  {
-/* Build dummy vnode information */
-dummy_vmemrange.start = 0;
-dummy_vmemrange.end   = args->mem_size;
-dummy_vmemrange.flags = 0;
-dummy_vmemrange.nid   = 0;
-args->nr_vmemranges = 1;
-args->vmemranges = &dummy_vmemrange;
+/* Build dummy vnode information
+ *
+ * Guest physical address space layout:
+ * [0, hole_start) [hole_start, 4G) [4G, highmem_end)
+ *
+ * Of course if there is no high memory, the second vmemrange
+ * has no effect on the actual result.
+ */
-dummy_vnode_to_pnode = XC_NUMA_NO_NODE;
+dummy_vmemrange[0].start = 0;
+dummy_vmemrange[0].end   = args->lowmem_end;
+dummy_vmemrange[0].flags = 0;
+dummy_vmemrange[0].nid   = 0;
+dummy_vnode_to_pnode[0]  = XC_NUMA_NO_NODE;
+args->nr_vmemranges = 1;
  args->nr_vnodes = 1;
-args->vnode_to_pnode = &dummy_vnode_to_pnode;
+
+if ( args->highmem_end > (1ULL << 32) )
+{
+dummy_vmemrange[1].start = 1ULL << 32;
+dummy_vmemrange[1].end   = args->highmem_end;
+dummy_vmemrange[1].flags = 0;
+dummy_vmemrange[1].nid   = 0;
+dummy_vnode_to_pnode[1]  = XC_NUMA_NO_NODE;
+
+args->nr_vmemranges++;
+args->nr_vnodes++;

(+Dario)

Does having high memory mean that we need to have 2 vnodes? We should be

Yes, see the comment above.


able to cope with multiple vmemranges per node, right?


Yes. That's already done in libxl's function to build hvm vmemranges.

This is only a simple dummy layout so nothing fancy happens here.



Right. But having multiple vnodes for a dummy topology looks to me a 
little counter-intuitive: people often assume that when number of nodes 
is 1 we don't have any NUMA-ness. Here we may need to look at 
vnode_to_pnode (possibly at both of the elements) to realize that this 
is a dummy layout.


And given that this layout can be expressed with nr_vnodes=1 && 
nr_vmemranges=2 I am not sure what we gain by having two vnodes.


-boris



Wei.


-boris



+}
+
+args->vmemranges = dummy_vmemrange;
+args->vnode_to_pnode = dummy_vnode_to_pnode;
  }




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

Re: [Xen-devel] [PATCH 1/4] x86: move syscall trampolines off the stack

[Andrew Cooper]

On 18/05/15 13:46, Jan Beulich wrote:
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -603,6 +604,42 @@ static int do_boot_cpu(int apicid, int c
>  return rc;
>  }
>  
> +unsigned long alloc_stub_page(unsigned int cpu, unsigned long *mfn)
> +{
> +unsigned long stub_va;
> +struct page_info *pg;
> +
> +if ( *mfn )
> +pg = mfn_to_page(*mfn);
> +else
> +{
> +nodeid_t node = cpu_to_node(cpu);
> +unsigned int memflags = node != NUMA_NO_NODE ? MEMF_node(node) : 0;
> +
> +pg = alloc_domheap_page(NULL, memflags);
> +if ( !pg )
> +return 0;
> +
> +unmap_domain_page(memset(__map_domain_page(pg), 0xcc, PAGE_SIZE));

Seems like memset_page(pg, int val) might be a nice piece of cleanup.

> +}
> +
> +stub_va = XEN_VIRT_END - (cpu + 1) * PAGE_SIZE;
> +if ( map_pages_to_xen(stub_va, page_to_mfn(pg), 1,
> +  PAGE_HYPERVISOR_RX | MAP_SMALL_PAGES) )
> +{
> +if ( !*mfn )
> +free_domheap_page(pg);
> +stub_va = 0;
> +}
> +else
> +{
> +stub_va += (cpu & ~(STUBS_PER_PAGE - 1)) * STUB_BUF_SIZE;

"(cpu & ~(STUBS_PER_PAGE - 1)) * STUB_BUF_SIZE" comes up very frequently
through this patch.

I think the logic would be easier to read given:

#define STUB_OFFSET(cpu) (((cpu) & ~(STUBS_PER_PAGE - 1)) * STUB_BUF_SIZE)

> +*mfn = page_to_mfn(pg);
> +}
> +
> +return stub_va;
> +}
> +
>  void cpu_exit_clear(unsigned int cpu)
>  {
>  cpu_uninit(cpu);
> @@ -616,6 +653,24 @@ static void cpu_smpboot_free(unsigned in
>  free_cpumask_var(per_cpu(cpu_sibling_mask, cpu));
>  free_cpumask_var(per_cpu(cpu_core_mask, cpu));
>  
> +if ( per_cpu(stubs.addr, cpu) )
> +{
> +unsigned long mfn = per_cpu(stubs.mfn, cpu);
> +unsigned char *stub_page = map_domain_page(mfn);
> +unsigned int i;
> +
> +memset(stub_page + (cpu & (STUBS_PER_PAGE - 1)) * STUB_BUF_SIZE,
> +   0xcc, STUB_BUF_SIZE);
> +for ( i = 0; i < STUBS_PER_PAGE; ++i )
> +if ( stub_page[i * STUB_BUF_SIZE] != 0xcc)
> +break;

There is a race condition between allocate and free, as
write_stub_trampoline() is written by the cpu itself.  Just finding 0xcc
here doesn't mean there isn't a different cpu in the process of coming
up and intending to use the stub page.

I suspect the race can be fixed by having the alloc side clobber the
first instruction, perhaps to ud2 ?

(Also, style at the end of the if)

> +unmap_domain_page(stub_page);
> +destroy_xen_mappings(per_cpu(stubs.addr, cpu) & PAGE_MASK,
> + (per_cpu(stubs.addr, cpu) | ~PAGE_MASK) + 1);
> +if ( i == STUBS_PER_PAGE )
> +free_domheap_page(mfn_to_page(mfn));
> +}
> +
>  order = get_order_from_pages(NR_RESERVED_GDT_PAGES);
>  free_xenheap_pages(per_cpu(gdt_table, cpu), order);
>  
> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -219,7 +219,19 @@ ENTRY(compat_post_handle_exception)
>  movb  $0,TRAPBOUNCE_flags(%rdx)
>  jmp   compat_test_all_events
>  

I would be tempted to leave a comment here referring to 'lstar_enter'
for stack/register details.

> -ENTRY(compat_syscall)
> +ENTRY(cstar_enter)
> +sti
> +movq  8(%rsp),%rax /* Restore %rax. */
> +movq  $FLAT_KERNEL_SS,8(%rsp)
> +pushq %r11
> +pushq $FLAT_USER_CS32
> +pushq %rcx
> +pushq $0
> +SAVE_VOLATILE TRAP_syscall
> +GET_CURRENT(%rbx)
> +movq  VCPU_domain(%rbx),%rcx
> +cmpb  $0,DOMAIN_is_32bit_pv(%rcx)
> +jeswitch_to_kernel
>  cmpb  $0,VCPU_syscall32_disables_events(%rbx)
>  movzwl VCPU_syscall32_sel(%rbx),%esi
>  movq  VCPU_syscall32_addr(%rbx),%rax
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -13,9 +13,8 @@
>  #include 
>  #include 
>  
> -ALIGN
>  /* %rbx: struct vcpu */
> -switch_to_kernel:
> +ENTRY(switch_to_kernel)
>  leaq  VCPU_trap_bounce(%rbx),%rdx
>  /* TB_eip = (32-bit syscall && syscall32_addr) ?
>   *  syscall32_addr : syscall_addr */
> @@ -114,22 +113,21 @@ restore_all_xen:
>   *  Vector directly to the registered arch.syscall_addr.
>   *
>   * Initial work is done by per-CPU stack trampolines. At this point %rsp

The trampolines are no longer on the stack, so I think this line needs
editing as well.

> - * has been initialised to point at the correct Xen stack, and %rsp, %rflags
> - * and %cs have been saved. All other registers are still to be saved onto
> - * the stack, starting with %rip, and an appropriate %ss must be saved into
> - * the space left by the trampoline.
> + * has been initialised to point at the correct Xen stack, %rsp has bee

Re: [Xen-devel] [PATCH v2 6/6] libxl: assign a default ssidref (XSM label) to guests

[Wei Liu]

On Tue, May 19, 2015 at 05:23:21PM +0100, Ian Campbell wrote:
> On Tue, 2015-05-19 at 16:54 +0100, Wei Liu wrote:
> 
> > > @@ -42,6 +44,9 @@ int libxl__domain_create_info_setdefault(libxl__gc *gc,
> > >  libxl_defbool_setdefault(&c_info->run_hotplug_scripts, true);
> > >  libxl_defbool_setdefault(&c_info->driver_domain, false);
> > >  
> > > +if (!c_info->ssidref)
> > > +c_info->ssidref = SECINITSID_DOMU;
> > > +
> > 
> > Do we want to add SECINITSID_DM in previous patch and set
> > device_model_ssidref here?
> 
> Daniel proposed something which involved changes to the policy, so I was
> deferring that change until after that.
> 
> The relevant bit of the previous thread is up until
> <1431946593.4944.36.ca...@citrix.com>.
> 

Right. I missed that one.

Acked-by: Wei Liu 

Wei.

> Ian.

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

Re: [Xen-devel] [PATCH 3/4] libxc: rework vnuma bits in setup_guest

[Wei Liu]

On Tue, May 19, 2015 at 12:23:07PM -0400, Boris Ostrovsky wrote:
> On 05/18/2015 11:34 AM, Wei Liu wrote:
> >Make the setup process similar to PV counterpart. That is, to allocate a
> >P2M array that covers the whole memory range and start from there. This
> >is clearer than using an array with no holes in it.
> >
> >Also the dummy layout should take MMIO hole into consideration. We might
> >end up having two vmemranges in the dummy layout.
> >
> >Signed-off-by: Wei Liu 
> >Cc: Ian Campbell 
> >Cc: Ian Jackson 
> >---
> >  tools/libxc/xc_hvm_build_x86.c | 66 
> > --
> >  1 file changed, 50 insertions(+), 16 deletions(-)
> >
> >diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
> >index df4b7ed..77678f1 100644
> >--- a/tools/libxc/xc_hvm_build_x86.c
> >+++ b/tools/libxc/xc_hvm_build_x86.c
> >@@ -238,6 +238,7 @@ static int setup_guest(xc_interface *xch,
> >  {
> >  xen_pfn_t *page_array = NULL;
> >  unsigned long i, vmemid, nr_pages = args->mem_size >> PAGE_SHIFT;
> >+unsigned long p2m_size;
> >  unsigned long target_pages = args->mem_target >> PAGE_SHIFT;
> >  unsigned long entry_eip, cur_pages, cur_pfn;
> >  void *hvm_info_page;
> >@@ -254,8 +255,8 @@ static int setup_guest(xc_interface *xch,
> >  xen_pfn_t special_array[NR_SPECIAL_PAGES];
> >  xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
> >  uint64_t total_pages;
> >-xen_vmemrange_t dummy_vmemrange;
> >-unsigned int dummy_vnode_to_pnode;
> >+xen_vmemrange_t dummy_vmemrange[2];
> >+unsigned int dummy_vnode_to_pnode[2];
> >  memset(&elf, 0, sizeof(elf));
> >  if ( elf_init(&elf, image, image_size) != 0 )
> >@@ -275,17 +276,37 @@ static int setup_guest(xc_interface *xch,
> >  if ( args->nr_vmemranges == 0 )
> >  {
> >-/* Build dummy vnode information */
> >-dummy_vmemrange.start = 0;
> >-dummy_vmemrange.end   = args->mem_size;
> >-dummy_vmemrange.flags = 0;
> >-dummy_vmemrange.nid   = 0;
> >-args->nr_vmemranges = 1;
> >-args->vmemranges = &dummy_vmemrange;
> >+/* Build dummy vnode information
> >+ *
> >+ * Guest physical address space layout:
> >+ * [0, hole_start) [hole_start, 4G) [4G, highmem_end)
> >+ *
> >+ * Of course if there is no high memory, the second vmemrange
> >+ * has no effect on the actual result.
> >+ */
> >-dummy_vnode_to_pnode = XC_NUMA_NO_NODE;
> >+dummy_vmemrange[0].start = 0;
> >+dummy_vmemrange[0].end   = args->lowmem_end;
> >+dummy_vmemrange[0].flags = 0;
> >+dummy_vmemrange[0].nid   = 0;
> >+dummy_vnode_to_pnode[0]  = XC_NUMA_NO_NODE;
> >+args->nr_vmemranges = 1;
> >  args->nr_vnodes = 1;
> >-args->vnode_to_pnode = &dummy_vnode_to_pnode;
> >+
> >+if ( args->highmem_end > (1ULL << 32) )
> >+{
> >+dummy_vmemrange[1].start = 1ULL << 32;
> >+dummy_vmemrange[1].end   = args->highmem_end;
> >+dummy_vmemrange[1].flags = 0;
> >+dummy_vmemrange[1].nid   = 0;
> >+dummy_vnode_to_pnode[1]  = XC_NUMA_NO_NODE;
> >+
> >+args->nr_vmemranges++;
> >+args->nr_vnodes++;
> 
> (+Dario)
> 
> Does having high memory mean that we need to have 2 vnodes? We should be

Yes, see the comment above.

> able to cope with multiple vmemranges per node, right?


Yes. That's already done in libxl's function to build hvm vmemranges.

This is only a simple dummy layout so nothing fancy happens here.

Wei.

> 
> -boris
> 
> 
> >+}
> >+
> >+args->vmemranges = dummy_vmemrange;
> >+args->vnode_to_pnode = dummy_vnode_to_pnode;
> >  }
> >

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

Re: [Xen-devel] [PATCH v2 6/6] libxl: assign a default ssidref (XSM label) to guests

[Ian Campbell]

On Tue, 2015-05-19 at 16:54 +0100, Wei Liu wrote:

> > @@ -42,6 +44,9 @@ int libxl__domain_create_info_setdefault(libxl__gc *gc,
> >  libxl_defbool_setdefault(&c_info->run_hotplug_scripts, true);
> >  libxl_defbool_setdefault(&c_info->driver_domain, false);
> >  
> > +if (!c_info->ssidref)
> > +c_info->ssidref = SECINITSID_DOMU;
> > +
> 
> Do we want to add SECINITSID_DM in previous patch and set
> device_model_ssidref here?

Daniel proposed something which involved changes to the policy, so I was
deferring that change until after that.

The relevant bit of the previous thread is up until
<1431946593.4944.36.ca...@citrix.com>.

Ian.


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

Re: [Xen-devel] [PATCH 3/4] libxc: rework vnuma bits in setup_guest

[Boris Ostrovsky]

On 05/18/2015 11:34 AM, Wei Liu wrote:

Make the setup process similar to PV counterpart. That is, to allocate a
P2M array that covers the whole memory range and start from there. This
is clearer than using an array with no holes in it.

Also the dummy layout should take MMIO hole into consideration. We might
end up having two vmemranges in the dummy layout.

Signed-off-by: Wei Liu 
Cc: Ian Campbell 
Cc: Ian Jackson 
---
  tools/libxc/xc_hvm_build_x86.c | 66 --
  1 file changed, 50 insertions(+), 16 deletions(-)

diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index df4b7ed..77678f1 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -238,6 +238,7 @@ static int setup_guest(xc_interface *xch,
  {
  xen_pfn_t *page_array = NULL;
  unsigned long i, vmemid, nr_pages = args->mem_size >> PAGE_SHIFT;
+unsigned long p2m_size;
  unsigned long target_pages = args->mem_target >> PAGE_SHIFT;
  unsigned long entry_eip, cur_pages, cur_pfn;
  void *hvm_info_page;
@@ -254,8 +255,8 @@ static int setup_guest(xc_interface *xch,
  xen_pfn_t special_array[NR_SPECIAL_PAGES];
  xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
  uint64_t total_pages;
-xen_vmemrange_t dummy_vmemrange;
-unsigned int dummy_vnode_to_pnode;
+xen_vmemrange_t dummy_vmemrange[2];
+unsigned int dummy_vnode_to_pnode[2];
  
  memset(&elf, 0, sizeof(elf));

  if ( elf_init(&elf, image, image_size) != 0 )
@@ -275,17 +276,37 @@ static int setup_guest(xc_interface *xch,
  
  if ( args->nr_vmemranges == 0 )

  {
-/* Build dummy vnode information */
-dummy_vmemrange.start = 0;
-dummy_vmemrange.end   = args->mem_size;
-dummy_vmemrange.flags = 0;
-dummy_vmemrange.nid   = 0;
-args->nr_vmemranges = 1;
-args->vmemranges = &dummy_vmemrange;
+/* Build dummy vnode information
+ *
+ * Guest physical address space layout:
+ * [0, hole_start) [hole_start, 4G) [4G, highmem_end)
+ *
+ * Of course if there is no high memory, the second vmemrange
+ * has no effect on the actual result.
+ */
  
-dummy_vnode_to_pnode = XC_NUMA_NO_NODE;

+dummy_vmemrange[0].start = 0;
+dummy_vmemrange[0].end   = args->lowmem_end;
+dummy_vmemrange[0].flags = 0;
+dummy_vmemrange[0].nid   = 0;
+dummy_vnode_to_pnode[0]  = XC_NUMA_NO_NODE;
+args->nr_vmemranges = 1;
  args->nr_vnodes = 1;
-args->vnode_to_pnode = &dummy_vnode_to_pnode;
+
+if ( args->highmem_end > (1ULL << 32) )
+{
+dummy_vmemrange[1].start = 1ULL << 32;
+dummy_vmemrange[1].end   = args->highmem_end;
+dummy_vmemrange[1].flags = 0;
+dummy_vmemrange[1].nid   = 0;
+dummy_vnode_to_pnode[1]  = XC_NUMA_NO_NODE;
+
+args->nr_vmemranges++;
+args->nr_vnodes++;


(+Dario)

Does having high memory mean that we need to have 2 vnodes? We should be 
able to cope with multiple vmemranges per node, right?


-boris



+}
+
+args->vmemranges = dummy_vmemrange;
+args->vnode_to_pnode = dummy_vnode_to_pnode;
  }




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

Re: [Xen-devel] [PATCH v9 1/6] tools/libxl: Check if fdt_{first, next}_subnode are present in libfdt

[Julien Grall]

On 19/05/15 12:03, Ian Campbell wrote:
> On Tue, 2015-05-19 at 11:39 +0100, Julien Grall wrote:
>> Hi,
>>
>> On 13/05/2015 19:33, Julien Grall wrote:
>>> +#ifndef LIBXL_LIBFDT_COMPAT_H
>>> +#define LIBXL_LIBFDT_COMPAT_H
>>> +
>>> +#if !HAVE_DECL_FDT_FIRST_SUBNODE
>>> +int fdt_first_subnode(const void *fdt, int offset);
>>> +#endif
>>> +
>>> +#if !HAVE_DECL_FDT_NEXT_SUBNODE
>>> +int fdt_next_subnode(const void *fdt, int offset);
>>> +#endif
>>> +
>>> +#endif
>>
>> I've just noticed that I forgot to hide the 2 new functions as suggested 
>> by Ian.
>>
>> I can resend this series or send a follow-up.
> 
> Perhaps just send an update of this one patch?

I will resend this patch by tomorrow.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] How to turn off persistent grant in xen

[HANNAS YAYA Issa]

Got it. Thank you

Hannas

On Tue, 19 May 2015 17:41:41 +0200, Roger Pau Monné wrote:

El 19/05/15 a les 16.17, HANNAS YAYA Issa ha escrit:

Hi
I want to disable persistent grant in xen. I tried to use xenbus to
disable it. What I did is modifying this line in
drivers/block/xenblkback/xenbus.c:

791err = xenbus_printf(xbt, dev->nodename, "feature-persistent",
"%u", 1);


and put this

791err = xenbus_printf(xbt, dev->nodename, "feature-persistent",
"%u", 0);

but the problem is my domain crash.

I think it is not the only thing to do in order to disable 
persistent

grant.


You only disabled it in the backend, so blkfront is announcing
persistent grant support while blkback is not. This means that 
blkback
will use persistent grants (because it sees the frontend supports 
them),

but blkfront will not.

You also need to disable the feature announcement from the frontend,
just grep for feature-persistent in xen-blkfront.c.

Roger.



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

Re: [Xen-devel] Xen/arm: Virtual ITS command queue handling

[Julien Grall]

On 19/05/15 15:48, Ian Campbell wrote:
>> A software would be buggy if no INV/INVALL is sent after change the LPI
>> configuration table.
> 
> Specifically _guest_ software.
> 
> AIUI the ITS is not required to reread the LPI cfg table unless an
> INV/INVALL is issued, but it is allowed to do so if it wants, i.e. it
> could pickup the config change at any point after the write to the cfg
> table. Is that correct?

Yes.

> If so then as long as it cannot blow up in Xen's face (i.e. an interrupt
> storm) I think between a write to the LPI config table and the next
> associated INV/INVALL we are entitled either continue using the old
> config until the INV/INVALL, to immediately enact the change or anything
> in the middle. I think this gives a fair bit of flexibility.

The interrupt is deprivileged by Xen and EOI by the guest. I don't think
it's possible to produce an interrupt storm.

> You've proposed something at the "immediately enact" end of the
> spectrum.

Yes, it one suggestion among another.

>> As suggested on a previous mail, I think we can get rid of sending
>> INV/INVALL command to the pITS by trapping the LPI configuration table:
> 
> The motivation here is simply to avoid the potential negative impact on
> the system of a guest which fills its command queue with INVALL
> commands?

Right.

> I think we don't especially care about INV since they are targeted. We
> care about INVALL because they are global. INV handling comes along for
> the ride though.
> 
>> For every write access, when the vLPIs is valid (i.e associated to a
>> device/interrupt), Xen will toggle the enable bit in the hardware LPIs
>> configuration table, send an INV * and sync his internal state. This
>> requiring to be able to translate the vLPIs to a (device,ID).
> 
> "INV *"? You don't mean INVALL I think, but rather INV of the specific
> device?

Yes, I mean INV command.

> 
> One possible downside is that you will convert this guest vits
> interaction:
> for all LPIs
> enable LPI
> INVALL
> 
> Into this pits interaction:
> for all LPIs
> enable LPI
> INV LPI
> 
> Also sequences of events with toggle things back and forth before
> invalidating are similarly made more synchronous. (Such sequences seem
> dumb to me, but kernel side abstractions sometimes lead to such things).

Correct, this will result to send much more command to the ITS.

>> INVALL/INV command could be ignored and directly increment CREADR (with
>> some care) because it only ensure that the command has been executed,
>> not fully completed. A SYNC would be required from the guest in order to
>> ensure the completion.
>>
>> Therefore we would need more care for the SYNC. Maybe by injecting a
>> SYNC when it's necessary.
>>
>> Note that we would need Xen to send command on behalf of the guest (i.e
>> not part of the command queue).
> 
> A guest may do this:
> Enqueue command A
> Enqueue command B
> Change LPI1 cfg table
> Change LPI2 cfg table
> Enqueue command C
> Enqueue command D
> Enqueue INV LPI2
> Enqueue INV LPI1
> 
> With your change this would end up going to the PITS as:
> Enqueue command A
> Enqueue command B
> Change LPI1 cfg table
> Enqueue INV LPI1
> Change LPI2 cfg table
> Enqueue INV LPI2
> Enqueue command C
> Enqueue command D
> 
> Note that the INV's have been reordered WRT command C and D as well as
> each other. Are there sequences of commands where this may make a
> semantic difference?

AFAICT, the commands don't change their semantics following the state of
LPI configuration.

> What if command C is a SYNC for example?

That would not be a problem. As soon as the OS write into the LPI
configuration it can expect that the ITS will take the change a anytime.

>> With this solution, it would be possible to have a small amount of time
>> where the pITS doesn't use the correct the configuration (i.e the
>> interrupt not yet enabled/disabled). Xen is able to cooperate with that
>> and will queue the interrupt to the guest.
> 
> I think it is inherent in the h/w design that an LPI may still be
> delivered after the cfg table has changed or even the INV enqueued, it
> is only guaranteed to take effect with a sync following the INV.

Right.

> I had in mind a lazier scheme which I'll mention for completeness not
> because I necessarily think it is better.

I wasn't expected to have a correct solution from the beginning ;). I
was more a first step for a better one such as yours.

> For each vits we maintain a bit map which marks LPI cfg table entries as
> dirty. Possibly a count of dirty entries too.
> 
> On trap of cfg table write we propagate the change to the physical table
> and set the corresponding dirty bit (and count++ if we are doing that)
> 
> On INV we insert the corresponding INV to the PITS iff
> test_and_clear(dirty, LPI) and count--.

Re: [Xen-devel] [PATCH v2 2/6] xen: flask: Pass output directory as a parameter to mkflask.sh

[Wei Liu]

On Tue, May 19, 2015 at 02:44:34PM +0100, Ian Campbell wrote:
> When called from the tools side in a later patch we will want to
> direct its output to the appropriate place.
> 
> Signed-off-by: Ian Campbell 

Acked-by: Wei Liu 

> ---
>  xen/xsm/flask/Makefile  |2 +-
>  xen/xsm/flask/policy/mkflask.sh |9 ++---
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/xsm/flask/Makefile b/xen/xsm/flask/Makefile
> index 1256512..12fc3a9 100644
> --- a/xen/xsm/flask/Makefile
> +++ b/xen/xsm/flask/Makefile
> @@ -22,7 +22,7 @@ ALL_H_FILES = $(FLASK_H_FILES) $(AV_H_FILES)
>  $(obj-y) ss/built_in.o: $(ALL_H_FILES)
>  
>  $(FLASK_H_FILES): $(FLASK_H_DEPEND)
> - $(CONFIG_SHELL) policy/mkflask.sh $(AWK) $(FLASK_H_DEPEND)
> + $(CONFIG_SHELL) policy/mkflask.sh $(AWK) include $(FLASK_H_DEPEND)
>  
>  $(AV_H_FILES): $(AV_H_DEPEND)
>   $(CONFIG_SHELL) policy/mkaccess_vector.sh $(AWK) $(AV_H_DEPEND)
> diff --git a/xen/xsm/flask/policy/mkflask.sh b/xen/xsm/flask/policy/mkflask.sh
> index e8d8fb5..9e24020 100644
> --- a/xen/xsm/flask/policy/mkflask.sh
> +++ b/xen/xsm/flask/policy/mkflask.sh
> @@ -8,10 +8,13 @@ set -e
>  awk=$1
>  shift 1
>  
> +output_dir=$1
> +shift 1
> +
>  # output file
> -output_file="include/flask.h"
> -debug_file="include/class_to_string.h"
> -debug_file2="include/initial_sid_to_string.h"
> +output_file="$output_dir/flask.h"
> +debug_file="$output_dir/class_to_string.h"
> +debug_file2="$output_dir/initial_sid_to_string.h"
>  
>  cat $* | $awk "
>  BEGIN{
> -- 
> 1.7.10.4

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

Re: [Xen-devel] [PATCH v2 3/6] xen: flask: Restrict generated header to xen + tools

[Wei Liu]

On Tue, May 19, 2015 at 02:44:35PM +0100, Ian Campbell wrote:
> This isn't strictly necessary but since it is going to be exposed via
> tools/include in a later patch this will help prevent accidental
> leakage beyond the tools.
> 
> Signed-off-by: Ian Campbell 

Acked-by: Wei Liu 

> ---
>  xen/xsm/flask/policy/mkflask.sh |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/xen/xsm/flask/policy/mkflask.sh b/xen/xsm/flask/policy/mkflask.sh
> index 9e24020..989a323 100644
> --- a/xen/xsm/flask/policy/mkflask.sh
> +++ b/xen/xsm/flask/policy/mkflask.sh
> @@ -28,6 +28,7 @@ BEGIN   {
>  
>   printf("#ifndef _SELINUX_FLASK_H_\n") > outfile;
>   printf("#define _SELINUX_FLASK_H_\n") > outfile;
> + printf("\n#if defined(__XEN__) || defined(__XEN_TOOLS__)\n") > 
> outfile;
>   printf("\n/*\n * Security object class definitions\n */\n") > 
> outfile;
>   printf("/* This file is automatically generated.  Do not edit. 
> */\n") > debugfile;
>   printf("/*\n * Security object class definitions\n */\n") > 
> debugfile;
> @@ -91,6 +92,7 @@ END {
>   for (i = 0; i < 34; i++) 
>   printf(" ") > outfile; 
>   printf("%d\n", sid_value) > outfile; 
> + printf("\n#endif /* __XEN__ || __XEN_TOOLS__ */\n") > outfile;
>   printf("\n#endif\n") > outfile;
>   printf("};\n\n") > debugfile2;
>   }'
> -- 
> 1.7.10.4

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

Re: [Xen-devel] [PATCH v2 4/6] tools: Expose XSM Flask initial SIDs list to tools

[Wei Liu]

On Tue, May 19, 2015 at 02:44:36PM +0100, Ian Campbell wrote:
> By generating tools/include/xen-xsm/flask/flask.h using the same tool
> as used during the hypervisor build.
> 
> Note that this is done regardless of whether XSM is enabled, since we
> want the tools to be agnostic to whether or not XSM is enabled in the
> hypervisor
> 
> Signed-off-by: Ian Campbell 

Acked-by: Wei Liu 

> ---
>  .gitignore |1 +
>  tools/include/Makefile |   16 ++--
>  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index c6185a0..3bc9cd9 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -147,6 +147,7 @@ tools/hotplug/Linux/xen-hotplug-common.sh
>  tools/hotplug/Linux/xendomains
>  tools/hotplug/NetBSD/rc.d/xencommons
>  tools/include/xen/*
> +tools/include/xen-xsm/*
>  tools/include/xen-foreign/*.(c|h|size)
>  tools/include/xen-foreign/checker
>  tools/libxl/libxlu_cfg_y.output
> diff --git a/tools/include/Makefile b/tools/include/Makefile
> index 601f79c..869b3f3 100644
> --- a/tools/include/Makefile
> +++ b/tools/include/Makefile
> @@ -1,8 +1,11 @@
>  XEN_ROOT = $(CURDIR)/../..
>  include $(XEN_ROOT)/tools/Rules.mk
>  
> +# Relative to $(XEN_ROOT)/xen/xsm/flask
> +FLASK_H_DEPEND := policy/initial_sids
> +
>  .PHONY: all
> -all: xen-foreign xen/.dir
> +all: xen-foreign xen/.dir xen-xsm/.dir
>  
>  .PHONY: xen-foreign
>  xen-foreign:
> @@ -19,6 +22,15 @@ xen/.dir:
>   ln -s ../xen-foreign xen/foreign
>   touch $@
>  
> +# Not xen/xsm as that clashes with link to
> +# $(XEN_ROOT)/xen/include/public/xsm above.
> +xen-xsm/.dir: $(XEN_ROOT)/xen/xsm/flask/policy/mkflask.sh \
> +   $(patsubst %,$(XEN_ROOT)/xen/xsm/flask/%,$(FLASK_H_DEPEND))
> + mkdir -p xen-xsm/flask
> + cd $(XEN_ROOT)/xen/xsm/flask/ && \
> + $(SHELL) policy/mkflask.sh $(AWK) $(CURDIR)/xen-xsm/flask 
> $(FLASK_H_DEPEND)
> + touch $@
> +
>  .PHONY: install
>  install: all
>   $(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)/xen/arch-x86
> @@ -47,7 +59,7 @@ install: all
>  
>  .PHONY: clean
>  clean:
> - rm -rf xen
> + rm -rf xen xen-xsm
>   $(MAKE) -C xen-foreign clean
>  
>  
> -- 
> 1.7.10.4

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

Re: [Xen-devel] [PATCH v2 6/6] libxl: assign a default ssidref (XSM label) to guests

[Wei Liu]

On Tue, May 19, 2015 at 02:44:38PM +0100, Ian Campbell wrote:
> We have now arranged for SECINITSID_DOMU to be defined (it corresponds
> to system_u:system_r:domU_t in the default policy). Use it as the
> default for the SSID of every domain.
> 
> Signed-off-by: Ian Campbell 
> Cc: Daniel De Graaf 
> Cc: wei.l...@citrix.com
> ---
> v2: Set ssidref rather than label. It is no longer necessary to
> reorder things in libxl.c.
> ---
>  tools/libxl/libxl_create.c |5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index f0da7dc..c9b2fec 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -25,6 +25,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  int libxl__domain_create_info_setdefault(libxl__gc *gc,
>   libxl_domain_create_info *c_info)
>  {
> @@ -42,6 +44,9 @@ int libxl__domain_create_info_setdefault(libxl__gc *gc,
>  libxl_defbool_setdefault(&c_info->run_hotplug_scripts, true);
>  libxl_defbool_setdefault(&c_info->driver_domain, false);
>  
> +if (!c_info->ssidref)
> +c_info->ssidref = SECINITSID_DOMU;
> +

Do we want to add SECINITSID_DM in previous patch and set
device_model_ssidref here?

Wei.

>  return 0;
>  }
>  
> -- 
> 1.7.10.4

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

Re: [Xen-devel] World-switch architected component flushing/invalidating.

[Ian Campbell]

On Tue, 2015-05-19 at 15:23 +, Mazen Ezzeddine (Student) wrote:
> Is there a header file to include and use already-implemented
> xen-specific functions for cache/TLB/branchPredictor invalidating?
> Could you please route me to the Xen file where they are implemented.

I suggest you use a tool such as "grep" to search for some key words and
associated register names in the xen source tree. You may want to pay
particular attention to xen/include/asm-arm.

Ian.



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

Re: [Xen-devel] [RFC PATCH 08/13] xen-netback: clone skb if skb->xmit_more is set

[Wei Liu]

On Tue, May 12, 2015 at 07:18:32PM +0200, Joao Martins wrote:
> On xenvif_start_xmit() we have an additional queue to the netback RX
> kthread that will sends the packet. When using burst>1 pktgen sets
> skb->xmit_more to tell the driver that there more skbs in the queue.
> However, pktgen transmits the same skb  times, which leads to
> the BUG below. Long story short adding the same skb in the rx_queue
> queue leads to crash. Specifically, having pktgen running with burst=2
> what happens is: when we queue the second skb (that is the same as
> the first queued skb), the list will have the tail element with skb->prev
> which is the skb itself. On skb_unlink (i.e. when dequeueing the skb)
> skb->prev will become NULL, but still having list->next pointing to the
> unlinked skb. Because of this skb_peek will still return an skb, which
> will redo the skb_unlink trying to set (skb->prev)->next where skb->prev
> is now NULL, thus leading to the crash (trace below).
> 

>From your description this doesn't sound Xen specific. Sounds like
pktgen breaks in any driver that has an internal queue, which is plenty.

> I'm not sure what the best way to fix this but since it's only happening
> when we use pktgen with burst>1: I chose doing an skb_clone when we don't
> use persistent grants and skb->xmit_more flag is set, and when
> CONFIG_NET_PKTGEN is compiled builtin.
> 

I don't think we should do this.

Wei.

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

Re: [Xen-devel] How to turn off persistent grant in xen

[Roger Pau Monné]

El 19/05/15 a les 16.17, HANNAS YAYA Issa ha escrit:
> Hi
> I want to disable persistent grant in xen. I tried to use xenbus to
> disable it. What I did is modifying this line in
> drivers/block/xenblkback/xenbus.c:
> 
> 791err = xenbus_printf(xbt, dev->nodename, "feature-persistent",
> "%u", 1);
> 
> 
> and put this
> 
> 791err = xenbus_printf(xbt, dev->nodename, "feature-persistent",
> "%u", 0);
> 
> but the problem is my domain crash.
> 
> I think it is not the only thing to do in order to disable persistent
> grant.

You only disabled it in the backend, so blkfront is announcing
persistent grant support while blkback is not. This means that blkback
will use persistent grants (because it sees the frontend supports them),
but blkfront will not.

You also need to disable the feature announcement from the frontend,
just grep for feature-persistent in xen-blkfront.c.

Roger.


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

Re: [Xen-devel] [PATCH v2 1/6] tools: Add AWK to set of tools checked for by configure

[Wei Liu]

On Tue, May 19, 2015 at 02:44:33PM +0100, Ian Campbell wrote:
> We are going to need this to generate the userspace flask.h header.
> 
> Please rerun autogen.sh when committing.
> 
> Signed-off-by: Ian Campbell 

Acked-by: Wei Liu 

> ---
>  config/Tools.mk.in |1 +
>  tools/configure.ac |2 ++
>  2 files changed, 3 insertions(+)
> 
> diff --git a/config/Tools.mk.in b/config/Tools.mk.in
> index e7da99d..d67352e 100644
> --- a/config/Tools.mk.in
> +++ b/config/Tools.mk.in
> @@ -23,6 +23,7 @@ AS86:= @AS86@
>  LD86:= @LD86@
>  BCC := @BCC@
>  IASL:= @IASL@
> +AWK := @AWK@
>  FETCHER := @FETCHER@
>  SEABIOS_PATH:= @seabios_path@
>  OVMF_PATH   := @ovmf_path@
> diff --git a/tools/configure.ac b/tools/configure.ac
> index d31c2f3..c975dfc 100644
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -247,6 +247,7 @@ AC_ARG_VAR([AS86], [Path to as86 tool])
>  AC_ARG_VAR([LD86], [Path to ld86 tool])
>  AC_ARG_VAR([BCC], [Path to bcc tool])
>  AC_ARG_VAR([IASL], [Path to iasl tool])
> +AC_ARG_VAR([AWK], [Path to awk tool])
>  
>  # Checks for programs.
>  AC_PROG_CC
> @@ -255,6 +256,7 @@ AC_PROG_INSTALL
>  AC_PATH_PROG([BISON], [bison])
>  AC_PATH_PROG([FLEX], [flex])
>  AX_PATH_PROG_OR_FAIL([PERL], [perl])
> +AX_PATH_PROG_OR_FAIL([AWK], [awk])
>  
>  AC_PROG_OCAML
>  AC_PROG_FINDLIB
> -- 
> 1.7.10.4

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

Re: [Xen-devel] [RFC 22/23] xen/privcmd: Add support for Linux 64KB page granularity

[David Vrabel]

On 14/05/15 18:01, Julien Grall wrote:
> The hypercall interface (as well as the toolstack) is always using 4KB
> page granularity. When the toolstack is asking for mapping a series of
> guest PFN in a batch, it expects to have the page map contiguously in
> its virtual memory.
> 
> When Linux is using 64KB page granularity, the privcmd driver will have
> to map multiple Xen PFN in a single Linux page.
> 
> Note that this solution works on page granularity which is a multiple of
> 4KB.
[...]
> --- a/drivers/xen/xlate_mmu.c
> +++ b/drivers/xen/xlate_mmu.c
> @@ -63,6 +63,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned 
> long fgmfn,
>  
>  struct remap_data {
>   xen_pfn_t *fgmfn; /* foreign domain's gmfn */
> + xen_pfn_t *egmfn; /* end foreign domain's gmfn */

I don't know what you mean by "end foreign domain".

>   pgprot_t prot;
>   domid_t  domid;
>   struct vm_area_struct *vma;
> @@ -78,17 +79,23 @@ static int remap_pte_fn(pte_t *ptep, pgtable_t token, 
> unsigned long addr,
>  {
>   struct remap_data *info = data;
>   struct page *page = info->pages[info->index++];
> - unsigned long pfn = page_to_pfn(page);
> - pte_t pte = pte_mkspecial(pfn_pte(pfn, info->prot));
> + unsigned long pfn = xen_page_to_pfn(page);
> + pte_t pte = pte_mkspecial(pfn_pte(page_to_pfn(page), info->prot));
>   int rc;
> -
> - rc = map_foreign_page(pfn, *info->fgmfn, info->domid);
> - *info->err_ptr++ = rc;
> - if (!rc) {
> - set_pte_at(info->vma->vm_mm, addr, ptep, pte);
> - info->mapped++;
> + uint32_t i;
> +
> + for (i = 0; i < XEN_PFN_PER_PAGE; i++) {
> + if (info->fgmfn == info->egmfn)
> + break;
> +
> + rc = map_foreign_page(pfn++, *info->fgmfn, info->domid);
> + *info->err_ptr++ = rc;
> + if (!rc) {
> + set_pte_at(info->vma->vm_mm, addr, ptep, pte);
> + info->mapped++;
> + }
> + info->fgmfn++;

This doesn't make any sense to me.  Don't you need to gather the foreign
GFNs into batches of PAGE_SIZE / XEN_PAGE_SIZE and map these all at once
into a 64 KiB page?  I don't see how you can have a set_pte_at() for
each foreign GFN.

David

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

Re: [Xen-devel] [RFC PATCH 00/13] Persistent grant maps for xen net drivers

[Wei Liu]

On Tue, May 12, 2015 at 07:18:24PM +0200, Joao Martins wrote:

> There have been recently[3] some discussions and issues raised on
> persistent grants for the block layer, though the numbers above
> show some significant improvements specially on more network intensive
> workloads and provide a margin for comparison against future map/unmap
> improvements.
> 
> Any comments or suggestions are welcome,
> Thanks!

Thanks, the numbers certainly look interesting.

I'm just a bit concerned about the complexity of netback. I've
commented on individual patches, we can discuss the issues there.

Wei.

> Joao
> 
> [1] http://article.gmane.org/gmane.linux.network/249383
> [2] http://bit.ly/1IhJfXD
> [3] http://lists.xen.org/archives/html/xen-devel/2015-02/msg02292.html
> 
> Joao Martins (13):
>   xen-netback: add persistent grant tree ops
>   xen-netback: xenbus feature persistent support
>   xen-netback: implement TX persistent grants
>   xen-netback: implement RX persistent grants
>   xen-netback: refactor xenvif_rx_action
>   xen-netback: copy buffer on xenvif_start_xmit()
>   xen-netback: add persistent tree counters to debugfs
>   xen-netback: clone skb if skb->xmit_more is set
>   xen-netfront: move grant_{ref,page} to struct grant
>   xen-netfront: refactor claim/release grant
>   xen-netfront: feature-persistent xenbus support
>   xen-netfront: implement TX persistent grants
>   xen-netfront: implement RX persistent grants
> 
>  drivers/net/xen-netback/common.h|  79 
>  drivers/net/xen-netback/interface.c |  78 +++-
>  drivers/net/xen-netback/netback.c   | 873 
> ++--
>  drivers/net/xen-netback/xenbus.c|  24 +
>  drivers/net/xen-netfront.c  | 362 ---
>  5 files changed, 1216 insertions(+), 200 deletions(-)
> 
> -- 
> 2.1.3

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

Re: [Xen-devel] [RFC PATCH 07/13] xen-netback: add persistent tree counters to debugfs

[Wei Liu]

On Tue, May 12, 2015 at 07:18:31PM +0200, Joao Martins wrote:
> Prints the total/max number of persistent grants and how many of
> them are in use.
> 
> Signed-off-by: Joao Martins 

Reviewed-by: Wei Liu 

> ---
>  drivers/net/xen-netback/xenbus.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/net/xen-netback/xenbus.c 
> b/drivers/net/xen-netback/xenbus.c
> index 766f7e5..1e6f27a 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -121,6 +121,17 @@ static int xenvif_read_io_ring(struct seq_file *m, void 
> *v)
>  skb_queue_len(&queue->rx_queue),
>  netif_tx_queue_stopped(dev_queue) ? "stopped" : "running");
>  
> + if (queue->vif->persistent_grants) {
> + seq_printf(m, "\nRx persistent_gnts: in_use %d max %d gnts 
> %d\n",
> +atomic_read(&queue->rx_gnts_tree.gnt_in_use),
> +queue->rx_gnts_tree.gnt_max,
> +queue->rx_gnts_tree.gnt_c);
> + seq_printf(m, "\nTx persistent_gnts: in_use %d max %d gnts 
> %d\n",
> +atomic_read(&queue->tx_gnts_tree.gnt_in_use),
> +queue->tx_gnts_tree.gnt_max,
> +queue->tx_gnts_tree.gnt_c);
> + }
> +
>   return 0;
>  }
>  
> -- 
> 2.1.3

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

Re: [Xen-devel] [RFC PATCH 06/13] xen-netback: copy buffer on xenvif_start_xmit()

[Wei Liu]

On Tue, May 12, 2015 at 07:18:30PM +0200, Joao Martins wrote:
> By introducing persistent grants we speed up the RX thread with the
> decreased copy cost, that leads to a throughput decrease of 20%.
> It is observed that the rx_queue stays mostly at 10% of its capacity,
> as opposed to full capacity when using grant copy. And a finer measure
> with lock_stat (below with pkt_size 64, burst 1) shows much higher wait
> queue contention on queue->wq, which hints that the RX kthread is
> waits/wake_up more often, that is actually doing work.
> 
> Without persistent grants:
> 
> class namecon-bouncescontentions   waittime-min   waittime-max
> waittime-total   waittime-avgacq-bounces   acquisitions   holdtime-min
> holdtime-max holdtime-total   holdtime-avg
> --
> &queue->wq:   792792   0.36  24.36
> 1140.30   1.44   42081002671   0.00
> 46.75  538164.02   0.54
> --
> &queue->wq326  [] __wake_up+0x2f/0x80
> &queue->wq410  [] finish_wait+0x4f/0xa0
> &queue->wq 56  [] prepare_to_wait+0x2b/0xb0
> --
> &queue->wq202  [] prepare_to_wait+0x2b/0xb0
> &queue->wq467  [] __wake_up+0x2f/0x80
> &queue->wq123  [] finish_wait+0x4f/0xa0
> 
> With persistent grants:
> 
> &queue->wq:   61834  61836   0.32  30.12
> 99710.27   1.61 2414001125308   0.00
> 75.61 1106578.82   0.98
> --
> &queue->wq 5079[] __wake_up+0x2f/0x80
> &queue->wq56280[] finish_wait+0x4f/0xa0
> &queue->wq  479[] prepare_to_wait+0x2b/0xb0
> --
> &queue->wq 1005[] finish_wait+0x4f/0xa0
> &queue->wq56761[] __wake_up+0x2f/0x80
> &queue->wq 4072[] prepare_to_wait+0x2b/0xb0
> 
> Also, with persistent grants, we don't require batching grant copy ops
> (besides the initial copy+map) which makes me believe that deferring
> the skb to the RX kthread just adds up unnecessary overhead (for this
> particular case). This patch proposes copying the buffer on
> xenvif_start_xmit(), which lets us both remove the contention on
> queue->wq and lock on rx_queue. Here, an alternative to
> xenvif_rx_action routine is added namely xenvif_rx_map() that maps
> and copies the buffer to the guest. This is only used when persistent
> grants are used, since it would otherwise mean an hypercall per
> packet.
> 
> Improvements are up to a factor of 2.14 with a single queue getting us
> from 1.04 Mpps to 1.7 Mpps (burst 1, pkt_size 64) and 1.5 to 2.6 Mpps
> (burst 2, pkt_size 64) compared to using the kthread. Maximum with grant
> copy is 1.2 Mpps, irrespective of the burst. All of this, measured on
> an Intel(R) Xeon(R) CPU E5-1650 v2 @ 3.50GHz.
> 
> Signed-off-by: Joao Martins 
> ---
>  drivers/net/xen-netback/common.h|  2 ++
>  drivers/net/xen-netback/interface.c | 11 +---
>  drivers/net/xen-netback/netback.c   | 52 
> +
>  3 files changed, 51 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/common.h 
> b/drivers/net/xen-netback/common.h
> index 23deb6a..f3ece12 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -363,6 +363,8 @@ void xenvif_kick_thread(struct xenvif_queue *queue);
>  
>  int xenvif_dealloc_kthread(void *data);
>  
> +int xenvif_rx_map(struct xenvif_queue *queue, struct sk_buff *skb);
> +
>  void xenvif_rx_queue_tail(struct xenvif_queue *queue, struct sk_buff *skb);
>  
>  /* Determine whether the needed number of slots (req) are available,
> diff --git a/drivers/net/xen-netback/interface.c 
> b/drivers/net/xen-netback/interface.c
> index 1103568..dfe2b7b 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -109,7 +109,8 @@ static irqreturn_t xenvif_rx_interrupt(int irq, void 
> *dev_id)
>  {
>   struct xenvif_queue *queue = dev_id;
>  
> - xenvif_kick_thread(queue);
> + if (!queue->vif->persistent_grants)
> + xenvif_kick_thread(queue);
>  
>   return IRQ_HANDLED;
>  }
> @@ -168,8 +169,12 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct 
> net_device *dev)
>   cb = XENVIF_RX_CB(skb);
>   cb->expires = jiffies + vif->drain_timeout;
>  
> - xenvif_rx_queue_tail(queue, skb);
> - xenvif_kick_thread(queue);
> + if (!queue->vif->persistent_grants) {
> + xenvif_rx_queue_tail(queue, skb);
> + xenvif_kick_thread(queue);
> + } else if (xenvif_rx_map(queue, skb)) {
> + return NETDEV_TX_BUSY;
> + }
>  

We now have two different functions for guest RX, one is xenvif_rx_map,
the other is xenvif_rx_action. They look very similar. Can we only have
one?

>   return NETDEV_TX_OK;
>  
> diff --git a/drivers/net/xen-netback/netback.c 
> b/d

Re: [Xen-devel] [PATCH v21 02/14] x86/VPMU: Add public xenpmu.h

[Jan Beulich]

>>> On 19.05.15 at 16:40,  wrote:
> On 05/19/2015 02:48 AM, Jan Beulich wrote:
> On 18.05.15 at 18:12,  wrote:
>>> On 05/18/2015 11:15 AM, Jan Beulich wrote:
>>> On 08.05.15 at 23:06,  wrote:
> +/*
> + * Architecture-specific information describing state of the processor at
> + * the time of PMU interrupt.
> + * Fields of this structure marked as RW for guest can only be written 
> by the
> + * guest when PMU_CACHED bit in pmu_flags is set (which is done by the
> + * hypervisor during PMU interrupt). Hypervisor will read updated data in
> + * XENPMU_flush hypercall and clear PMU_CACHED bit.
> + */
> +struct xen_pmu_arch {
> +union {
> +/*
> + * Processor's registers at the time of interrupt.
> + * RW for hypervisor, RO for guests.
> + */
> +struct xen_pmu_regs regs;
> +/* Padding for adding new registers to xen_pmu_regs in the 
> future */
> +#define XENPMU_REGS_PAD_SZ  64
> +uint8_t pad[XENPMU_REGS_PAD_SZ];
> +} r;
> +
> +/* RW for hypervisor, RO for guest */
> +uint64_t pmu_flags;
> +
> +/*
> + * APIC LVTPC register.
> + * RW for both hypervisor and guest.
> + * Only APIC_LVT_MASKED bit is loaded by the hypervisor into hardware
> + * during XENPMU_flush.
> + */
> +union {
> +uint32_t lapic_lvtpc;
> +uint64_t pad;
> +} l;
> +
> +/*
> + * Vendor-specific PMU registers.
> + * RW for both hypervisor and guest.
> + * Guest's updates to this field are verified and then loaded by the
> + * hypervisor into hardware during XENPMU_flush
> + */
> +union {
> +struct xen_pmu_amd_ctxt amd;
> +struct xen_pmu_intel_ctxt intel;
> +
> +/*
> + * Padding for contexts (fixed parts only, does not include MSR 
> banks
> + * that are specified by offsets)
> + */
> +#define XENPMU_CTXT_PAD_SZ  128
> +uint8_t pad[XENPMU_CTXT_PAD_SZ];
> +} c;
> +};
 Marking all the fields RW for the hypervisor is certainly correct from
 a permissions pov, but requires close auditing that the hypervisor
 doesn't ever read a field twice, potentially getting different results
 and hence inconsistent internal state. Therefore - do all of the fields
 _need_ to be RW for the hypervisor? If not, marking the ones
 where this isn't needed as WO would be much preferred, to limit
 the scope of whats needs to be audited.
>>> Right, all arch-independent bits are WO for hypervisor as are
>>> xen_pmu_regs above. I in fact meant to label them as such but for
>>> reasons that I can't remember now decided to mark them as RW.
>> Okay, that simplifies things for review purposes: Of the left
>> fields, lapic_lvtpc can easily be verified to be read just once, and
>> the vendor specific context gets copied into hypervisor memory
>> once before doing verification and loading. Which leaves pmu_flags:
>> Can you clarify how the read-write behavior there is expected to
>> be (perhaps by slightly extending the respective comment)? I ask
>> in particular because I don't recall having seen any read-once
>> enforcement in the code.
> 
> 
> pmu_flags are not read-once by neither hypervisor nor the guest. The 
> hypervisor uses PMU_CACHED flag (which it sets in the PMU interrupt) to 
> later determine whether or not to perform things like VPMU load (if the 
> flag is set then there is no reason to load). This may happen more than 
> once.
> 
> The rest of flags are WO by the hypervisor.
> 
> For the guest PMU_CACHED is indication that it shouldn't write MSRs 
> directly but rather do this into the shared page.
> 
> I don't believe that if guest writes flags (PMU_CACHED specifically) it 
> will have any effect on the hypervisor or other guests. It will 
> certainly affect the guest itself as it will probably mess up its VPMU 
> state. For example, we may end up loading the VPMU context when it 
> shouldn't be and that may result in an unexpected interrupt for the guest.
> I can easily add a hypervisor-private flag for this purpose (into 
> vpmu_struct.flags) to make things more cleanly delineated (i.e. 
> pmu_flags will be strictly WO by hypervisor and RO by the guest).

That would be good imo.

> I 
> still want to keep PMU_CACHED flag for the guest though so that it knows 
> where to write MSRs (Linux PV guests don't need this right now but other 
> guests may find this useful).

Understood.

Jan

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

Re: [Xen-devel] [RFC PATCH 05/13] xen-netback: refactor xenvif_rx_action

[Wei Liu]

On Tue, May 12, 2015 at 07:18:29PM +0200, Joao Martins wrote:
> Refactor xenvif_rx_action by dividing it into build_gops and
> submit, similar to what xenvif_tx_action looks like.
> 
> Signed-off-by: Joao Martins 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [RFC PATCH 04/13] xen-netback: implement RX persistent grants

[Wei Liu]

On Tue, May 12, 2015 at 07:18:28PM +0200, Joao Martins wrote:
> It starts by doing a lookup in the tree for a gref. If no persistent
> grant is found on the tree, it will do grant copy and prepare
> the grant maps. Finally valides the grant map and adds it to the tree.

validates?

> After mapped these grants can be pulled from the tree in the subsequent
> requests. If it's out of pages in the tree pool, it will fallback to
> grant copy.
> 

Again, this looks complicated. Why use combined scheme? I will do
detailed reviews after we're sure we need such scheme.

> It adds four new fields in the netrx_pending_operations: copy_done
> to track how many copies were made; map_prod and map_cons to track
> how many maps are outstanding validation and finally copy_page for
> the correspondent page (in tree) for copy_gref.
> 
> Results are 1.04 Mpps measured with pktgen (pkt_size 64, burst 1)
> with persistent grants versus 1.23 Mpps with grant copy (20%
> regression). With persistent grants it adds up contention on
> queue->wq as the kthread_guest_rx goes to sleep more often. If we
> speed up the sender (burst 2,4 and 8) it goes up to 1.7 Mpps with
> persistent grants. This issue is addressed in later a commit, by
> copying the skb on xenvif_start_xmit() instead of going through
> the RX kthread.
> 
> Signed-off-by: Joao Martins 
> ---
>  drivers/net/xen-netback/common.h|   7 ++
>  drivers/net/xen-netback/interface.c |  14 ++-
>  drivers/net/xen-netback/netback.c   | 190 
> ++--
>  3 files changed, 178 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/common.h 
> b/drivers/net/xen-netback/common.h
> index e5ee220..23deb6a 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -235,6 +235,13 @@ struct xenvif_queue { /* Per-queue data for xenvif */
>  
>   struct gnttab_copy grant_copy_op[MAX_GRANT_COPY_OPS];
>  
> + /* To map the grefs to be added to the tree */
> + struct gnttab_map_grant_ref rx_map_ops[XEN_NETIF_RX_RING_SIZE];
> + struct page *rx_pages_to_map[XEN_NETIF_RX_RING_SIZE];
> + /* Only used if feature-persistent = 1 */

This comment applies to rx_map_ops and rx_pages_to_map as well. Could
you move it up?

> + struct persistent_gnt_tree rx_gnts_tree;
> + struct page *rx_gnts_pages[XEN_NETIF_RX_RING_SIZE];
> +
>   /* We create one meta structure per ring request we consume, so
>* the maximum number is the same as the ring size.
>*/
> diff --git a/drivers/net/xen-netback/interface.c 
> b/drivers/net/xen-netback/interface.c

[...]

>  
> diff --git a/drivers/net/xen-netback/netback.c 
> b/drivers/net/xen-netback/netback.c
> index 529d7c3..738b6ee 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -413,14 +413,62 @@ static void xenvif_rx_queue_drop_expired(struct 
> xenvif_queue *queue)
>  }
>  
>  struct netrx_pending_operations {
> + unsigned map_prod, map_cons;
>   unsigned copy_prod, copy_cons;
>   unsigned meta_prod, meta_cons;
>   struct gnttab_copy *copy;
>   struct xenvif_rx_meta *meta;
>   int copy_off;
>   grant_ref_t copy_gref;
> + struct page *copy_page;
> + unsigned copy_done;
>  };
>  
> +static void xenvif_create_rx_map_op(struct xenvif_queue *queue,
> + struct gnttab_map_grant_ref *mop,
> + grant_ref_t ref,
> + struct page *page)

Rename it to xenvif_rx_create_map_op to be consistent with
xenvif_tx_create_map_op?

> +{
> + queue->rx_pages_to_map[mop - queue->rx_map_ops] = page;
> + gnttab_set_map_op(mop,
> +   (unsigned long)page_to_kaddr(page),
> +   GNTMAP_host_map,
> +   ref, queue->vif->domid);
> +}
> +

[...]

> +
> + persistent_gnt = xenvif_pgrant_new(tree, gop_map);
> + if (unlikely(!persistent_gnt)) {
> + netdev_err(queue->vif->dev,
> +"Couldn't add gref to the tree! ref: %d",
> +gop_map->ref);
> + xenvif_page_unmap(queue, gop_map->handle, &page);
> + put_free_pages(tree, &page, 1);
> + kfree(persistent_gnt);
> + persistent_gnt = NULL;

persistent_gnt is already NULL.

So the kfree and = NULL is pointless.

> + continue;
> + }
> +
> + put_persistent_gnt(tree, persistent_gnt);
> + }
> +}
> +
> +/*
>   * This is a twin to xenvif_gop_skb.  Assume that xenvif_gop_skb was
>   * used to set up the operations on the top of
>   * netrx_pending_operations, which have since been done.  Check that
>   * they didn't give any errors and advance over them.
>   */
> -static int xenvif_check_gop(struct xenvif *vif, int nr_meta_slots,
> +static int xenvif_check_gop(struct xenvif_queue *q

Re: [Xen-devel] [RFC 17/23] xen/grant-table: Make it running on 64KB granularity

[David Vrabel]

On 14/05/15 18:00, Julien Grall wrote:
> The Xen interface is using 4KB page granularity. This means that each
> grant is 4KB.
> 
> The current implementation allocates a Linux page per grant. On Linux
> using 64KB page granularity, only the first 4KB of the page will be
> used.
> 
> We could decrease the memory wasted by sharing the page with multiple
> grant. It will require some care with the {Set,Clear}ForeignPage macro.
> 
> Note that no changes has been made in the x86 code because both Linux
> and Xen will only use 4KB page granularity.

Reviewed-by: David Vrabel 

David

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

Re: [Xen-devel] [RFC 16/23] xen/events: fifo: Make it running on 64KB granularity

[David Vrabel]

On 14/05/15 18:00, Julien Grall wrote:
> Only use the first 4KB of the page to store the events channel info. It
> means that we will wast 60KB every time we allocate page for:
>  * control block: a page is allocating per CPU
>  * event array: a page is allocating everytime we need to expand it
> 
> I think we can reduce the memory waste for the 2 areas by:
> 
> * control block: sharing between multiple vCPUs. Although it will
> require some bookkeeping in order to not free the page when the CPU
> goes offline and the other CPUs sharing the page still there
> 
> * event array: always extend the array event by 64K (i.e 16 4K
> chunk). That would require more care when we fail to expand the
> event channel.

I think you want an xen_alloc_page_for_xen() or similar to allocate a 4
KiB size/aligned block.

But as-is:

Reviewed-by: David Vrabel 

David

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

Re: [Xen-devel] [RFC PATCH 03/13] xen-netback: implement TX persistent grants

[Wei Liu]

On Tue, May 12, 2015 at 07:18:27PM +0200, Joao Martins wrote:
> Introduces persistent grants for TX path which follows similar code path
> as the grant mapping.
> 
> It starts by checking if there's a persistent grant available for header
> and frags grefs and if so setting it in tx_pgrants. If no persistent grant
> is found in the tree for the header it will resort to grant copy (but
> preparing the map ops and add them laster). For the frags it will use the
 ^
 later

> tree page pool, and in case of no pages it fallbacks to grant map/unmap
> using mmap_pages. When skb destructor callback gets called we release the
> slot and persistent grant within the callback to avoid waking up the
> dealloc thread. As long as there are no unmaps to done the dealloc thread
> will remain inactive.
> 

This scheme looks complicated. Can we just only use one
scheme at a time? What's the rationale for using this combined scheme?
Maybe you're thinking about using a max_grants < ring_size to save
memory?

Only skim the patch. I will do detailed reviews after we're sure this is
the right way to go.

> Results show an improvement of 46% (1.82 vs 1.24 Mpps, 64 pkt size)
> measured with pktgen and up to over 48% (21.6 vs 14.5 Gbit/s) measured
> with iperf (TCP) with 4 parallel flows 1 queue vif, DomU to Dom0.
> Tests ran on a Intel Xeon E5-1650 v2 with HT disabled.
> 
> Signed-off-by: Joao Martins 
> ---
>  drivers/net/xen-netback/common.h|  12 ++
>  drivers/net/xen-netback/interface.c |  46 +
>  drivers/net/xen-netback/netback.c   | 341 
> +++-
>  3 files changed, 360 insertions(+), 39 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/common.h 
> b/drivers/net/xen-netback/common.h
> index e70ace7..e5ee220 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -191,6 +191,15 @@ struct xenvif_queue { /* Per-queue data for xenvif */
>   struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
>   struct gnttab_map_grant_ref tx_map_ops[MAX_PENDING_REQS];
>   struct gnttab_unmap_grant_ref tx_unmap_ops[MAX_PENDING_REQS];
> +
> + /* Tree to store the TX grants
> +  * Only used if feature-persistent = 1
> +  */
> + struct persistent_gnt_tree tx_gnts_tree;
> + struct page *tx_gnts_pages[XEN_NETIF_TX_RING_SIZE];
> + /* persistent grants in use */
> + struct persistent_gnt *tx_pgrants[MAX_PENDING_REQS];
> +
>   /* passed to gnttab_[un]map_refs with pages under (un)mapping */
>   struct page *pages_to_map[MAX_PENDING_REQS];
>   struct page *pages_to_unmap[MAX_PENDING_REQS];
> @@ -361,6 +370,9 @@ void xenvif_zerocopy_callback(struct ubuf_info *ubuf, 
> bool zerocopy_success);
>  
>  /* Unmap a pending page and release it back to the guest */
>  void xenvif_idx_unmap(struct xenvif_queue *queue, u16 pending_idx);
> +void xenvif_page_unmap(struct xenvif_queue *queue,
> +grant_handle_t handle,
> +struct page **page);
>  
>  static inline pending_ring_idx_t nr_pending_reqs(struct xenvif_queue *queue)
>  {
> diff --git a/drivers/net/xen-netback/interface.c 
> b/drivers/net/xen-netback/interface.c
> index 1a83e19..6f996ac 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -456,6 +456,34 @@ struct xenvif *xenvif_alloc(struct device *parent, 
> domid_t domid,
>   return vif;
>  }
>  
> +static int init_persistent_gnt_tree(struct persistent_gnt_tree *tree,
> + struct page **pages, int max)
> +{
> + int err;
> +
> + tree->gnt_max = min_t(unsigned, max, xenvif_max_pgrants);
> + tree->root.rb_node = NULL;
> + atomic_set(&tree->gnt_in_use, 0);
> +
> + err = gnttab_alloc_pages(tree->gnt_max, pages);
> + if (!err) {
> + tree->free_pages_num = 0;
> + INIT_LIST_HEAD(&tree->free_pages);
> + put_free_pages(tree, pages, tree->gnt_max);
> + }
> +
> + return err;
> +}
> +
> +static void deinit_persistent_gnt_tree(struct persistent_gnt_tree *tree,
> +struct page **pages)
> +{
> + free_persistent_gnts(tree, tree->gnt_c);
> + BUG_ON(!RB_EMPTY_ROOT(&tree->root));
> + tree->gnt_c = 0;
> + gnttab_free_pages(tree->gnt_max, pages);
> +}
> +
>  int xenvif_init_queue(struct xenvif_queue *queue)
>  {
>   int err, i;
> @@ -496,9 +524,23 @@ int xenvif_init_queue(struct xenvif_queue *queue)
> .ctx = NULL,
> .desc = i };
>   queue->grant_tx_handle[i] = NETBACK_INVALID_HANDLE;
> + queue->tx_pgrants[i] = NULL;
> + }
> +
> + if (queue->vif->persistent_grants) {
> + err = init_persistent_gnt_tree(&queue->tx_gnts_tree,
> +queue->tx_gnts_pages,
> +XEN_NETIF_TX_RING

[Xen-devel] World-switch architected component flushing/invalidating.

[Mazen Ezzeddine (Student)]

Dear all,


Could you please hint me about the below:

I need to flush/invalidate all architected components (all levels of 
D-cache/I-cache, I-TLB D-TLB, branch predictor etc..) on Xen world/Domain 
switch running on a dual core ARM cortex A-15.

As such, am I on the safe side if I include the invalidate/flush code in the 
function :

static void schedule(void)

{

-

-

// code for invalidation of architected components

context_switch(prev, next);

}


Is there a header file to include and use already-implemented xen-specific 
functions for cache/TLB/branchPredictor invalidating? Could you please route me 
to the Xen file where they are implemented.


Thank you for sharing your experience.



Best regards.



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

Re: [Xen-devel] [RFC 15/23] xen/balloon: Don't rely on the page granularity is the same for Xen and Linux

[David Vrabel]

On 14/05/15 18:00, Julien Grall wrote:
> For ARM64 guests, Linux is able to support either 64K or 4K page
> granularity. Although, the hypercall interface is always based on 4K
> page granularity.
> 
> With 64K page granuliarty, a single page will be spread over multiple
> Xen frame.
> 
> When a driver request/free a balloon page, the balloon driver will have
> to split the Linux page in 4K chunk before asking Xen to add/remove the
> frame from the guest.
> 
> Note that this can work on any page granularity assuming it's a multiple
> of 4K.
[...]
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -91,7 +91,7 @@ struct balloon_stats balloon_stats;
>  EXPORT_SYMBOL_GPL(balloon_stats);
>  
>  /* We increase/decrease in batches which fit in a page */
> -static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)];
> +static xen_pfn_t frame_list[XEN_PAGE_SIZE / sizeof(unsigned long)];

PAGE_SIZE is appropriate here, since this is a guest-side array.

> + if (!(i % XEN_PFN_PER_PAGE)) {

Ick.  Can you refactor this into a loop per page calling a function that
loops per MFN.

Also similar tests elsewhere.

David

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

[Xen-devel] Windows 2008 r2 smp guest booting hang with viridian=true on ovmf(xen latest version 4.5.1-rc1 + latest edk2)

[Fanhenglong]

Hi all,

I have test win2008 r2 guest on ovmf with xen latest version + edk2 latest
Xen :  
4.5.1-rc1
Edk2 :  e2ab3f819f4e8165c24bd6f4fdc24ef17bdf458b (date:2015/5/18)
and come across a problem:
when the viridian flag is true,win2008 r2 guest can boot success with unique 
processor, but will hang with smp processor on ovmf;
the viridian flag is false, win2008 r2 guest can boot success both in unique 
and smp processor on ovmf;

if win2008 r2 with viridian=faulse, it may bring 0x101 bluescreen
http://old-list-archives.xenproject.org/archives/html/xen-users/2009-07/msg00661.html

I try to resolve the problem,
I also run the same testcase on kvm and vmvare ,vm also have the same question, 
vmare is ok;
so I print the cupid function return value in vmvare guest os,
the below table show the detailed information in vmvare guest os,
get cpu id 0 : 000b 756e6547 6c65746e 49656e69
get cpu id 1 : 000106a5 00010800 80982201 0fabfbff
get cpu id 2 : 55035a01 00f0b2e4  09ca212c
get cpu id 3 :    
get cpu id 4 :    
get cpu id 5 :    
get cpu id 4000 : 4010 61774d56 4d566572 65726177
get cpu id 4001 :    
get cpu id 4002 :    
get cpu id 4003 :    
get cpu id 4004 :    
get cpu id 4005 :    
get cpu id 4006 :    
get cpu id 4070 :   00ac 0012
get cpu id 4071 :   00ac 0012
get cpu id 4072 :   00ac 0012
get cpu id 4073 :   00ac 0012
get cpu id 4100 :   00ac 
get cpu id 4101 :   00ac 
get cpu id 4102 :   00ac 
get cpu id 4103 :   00ac 
get cpu id 4104 :   00ac 
get cpu id 4105 :   00ac 
get cpu id 4106 :   00ac 
get cpu id 8000 : 8008   
get cpu id 8001 :   0001 2810
get cpu id 8002 : 65746e49 2952286c 6f655820 2952286e
get cpu id 8003 : 55504320 20202020 20202020 45202020
get cpu id 8004 : 30323535 20402020 37322e32 007a4847
get cpu id 8005 :    
get cpu id 8006 :   01006040 
get cpu id 8007 :    0100
get cpu id 8008 : 3028   
get cpu id 8009 :   00ac 



I modified cpuid_viridian_leaves function in  xen/arch/x86/hvm/viridian.c (as 
the following red bold code)
to return value 0 for cupid (function=4001), and win2008 r2 smp guest 
can boot success on ovmf;

int cpuid_viridian_leaves(unsigned int leaf, unsigned int *eax,
  unsigned int *ebx, unsigned int *ecx,
  unsigned int *edx)
{
struct domain *d = current->domain;

if ( !is_viridian_domain(d) )
return 0;

leaf -= 0x4000;
if ( leaf > 6 )
return 0;

*eax = *ebx = *ecx = *edx = 0;
switch ( leaf )
{
case 0:
*eax = 0x4006; /* Maximum leaf */
*ebx = 0x7263694d; /* Magic numbers  */
*ecx = 0x666F736F;
*edx = 0x76482074;
break;
case 1:
//original code *eax = 0x31237648; /* Version number */
   *eax = 0; //code after modified
break;


   based on hyperv spec, Microsoft Hypervisor CPUID Leaves,
   0x4001
Hypervisor vendor-neutral interface identification. This determines the 
semantics of the leaves from 0x4002 through 0x40FF.
 EAX  0x31237648-"Hv#1"
 EBX  Reserved
 ECX  Reserved
 EDX  Reserved

May be in xen platform,  if window 2008 r2 guest os boot in ovmf, the 
cupid(function=0x4001) must not return EAX 0x31237648-"Hv#1",

Can anyone have idea about how to boot window 2008 r2 guest in ovmf and do not 
bring other problem(eg,0x101 bluescreen)?

Thanks!







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

Re: [Xen-devel] [RFC PATCH 02/13] xen-netback: xenbus feature persistent support

[Wei Liu]

On Tue, May 12, 2015 at 07:18:26PM +0200, Joao Martins wrote:
> Checks for "feature-persistent" that indicates persistent grants
> support. Adds max_persistent_grants module param that specifies the max
> number of persistent grants, which if set to zero disables persistent
> grants.
> 
> Signed-off-by: Joao Martins 

This patch needs to be moved later. The feature needs to be implemented
first.

Also you need to patch netif.h to document this new feature. To do this,
you need to patch the master netif.h in Xen tree then sync the change to
Linux. Of course I don't mind if we discuss wording in the Linux
copy then you devise a patch for Xen.

Wei.

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

Re: [Xen-devel] [PATCH] xen: fix building on ARM with CONFIG_HIBERNATE_CALLBACKS

[David Vrabel]

On 19/05/15 15:49, Boris Ostrovsky wrote:
> On 05/19/2015 10:36 AM, Arnd Bergmann wrote:
>> On Tuesday 19 May 2015 09:57:19 Boris Ostrovsky wrote:
>>> On 05/19/2015 08:58 AM, Arnd Bergmann wrote:
 A recent bug fix for x86 broke Xen on ARM for the case that
 CONFIG_HIBERNATE_CALLBACKS is enabled:

 drivers/built-in.o: In function `do_suspend':
 /git/arm-soc/drivers/xen/manage.c:134: undefined reference to
 `xen_arch_suspend'
 drivers/built-in.o:(.debug_addr+0xc3f4): undefined reference to
 `xen_arch_suspend'

 It is not clear to me what needs to be done here, but this
 patch avoids the build error by adding a stub for the
 missing function.
>>> This is already fixed in Xen staging tree.
>> I see. Any chance to get that fix into linux-next soon?
> 
> 
> David, are you going to send pull request to Linus before rc5?

Yes.

David

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

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

[osstest service user]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail in 56671 pass in 
56707
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail pass in 56671

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never 
pass

version targeted for testing:
 ovmf 54ae9c08e8e78089ce186d0a632731943b8f436c
baseline version:
 ovmf f1f0f0deb6e64df6b7c04ead7330afecf5537e46


People who touched revisions under test:
  Jeff Fan 
  Ruiyu Ni 
  Star Zeng 


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



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

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

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


Not pushing.


commit 54ae9c08e8e78089ce186d0a632731943b8f436c
Author: Ruiyu Ni 
Date:   Mon May 18 05:30:35 2015 +

MdeModulePkg: Fix comments typo in UefiBootManagerLib.h

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17466 
6f19259b-4bc3-4df7-8a09-765794883524

commit 44cff56257cc2943a94be2ada9b2249a80decc49
Author: Ruiyu Ni 
Date:   Mon May 18 05:30:01 2015 +

Nt32Pkg: Use different FILE_GUID.

Use different FILE_GUID other than the one used by 
PlatformBootManagerLibNull.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17465 
6f19259b-4bc3-4df7-8a09-765794883524

commit 987a8a64a147ff7f0d813487b995fe7eb5aa5423
Author: Ruiyu Ni 
Date:   Mon May 18 05:29:01 2015 +

SourceLevelDebugPkg: Fix Serial Port connection cannot be setup

The root cause is SerialPortDebugCommunicationLib returns NULL debug port 
handle causing the CompressData() doesn't send the compressed data.
The fix doesn't rely on the debug port handle value and uses Send parameter 
to indicate whether to send the compressed data.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Reviewed-by: Jeff Fan 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17464 
6f19259b-4bc3-4df7-8a09-765794883524

commit f3b6e048e2454c4692bcd66c7592aefde14bcfa4
Author: Star Zeng 
Date:   Mon May 18 01:46:40 2015 +

MdeModulePkg PiSmmCoreMemoryAllocationLib: Get SMRAM ranges

 from FullSmramRanges and FullSmramRangeCount in SmmCorePrivate by 
Constructor.

It can avoid potential first call to FreePool() -> BufferInSmram() ->
if (mSmramRanges == NULL) { GetS

Re: [Xen-devel] [xen-unstable test] 56456: regressions - FAIL

[Roger Pau Monné]

El 19/05/15 a les 12.29, Jan Beulich ha escrit:
 On 19.05.15 at 12:20,  wrote:
>> At 12:19 +0100 on 18 May (1431951570), Jan Beulich wrote:
>> On 18.05.15 at 12:50,  wrote:
 El 18/05/15 a les 12.17, Tim Deegan ha escrit:
>  - have map_dirty_bitmap() DTRT, with something like access_ok() +
>a linear-pagetable lookup to find the frame.

 That was my first intention, but AFAICT we have no function in tree to
 resolve a PV guest VA into a GFN/MFN. The closest thing I could find was
 using guest_walk_tables + guest_walk_to_gfn in order to obtain the gfn.
 Should I send a patch to introduce a pv_gva_to_gfn function based on that?
>>>
>>> Isn't that what we have the linear page table and guest_map_l1e()
>>> for?
>>
>> Yes, or in this case guest_get_eff_l1e().  We'd want to make sure we
>> get_page() the underlying page as well to guard against it being freed
>> and reused while we have a mapping.
>>
>> That won't check user/supervisor or write permissions in the upper
>> levels of the tree.  OTOH, __copy_to_user() doesn't either, so maybe
>> we don't care.
> 
> Hmm, permissions are being checked by __copy_to_user() afaict
> (due to us using the actual page tables), so that being bypassed
> here would seem wrong then.

The only way I see to check for permissions of all levels is to use
guest_walk_tables instead of guest_get_eff_l1e, but that's going to make
this quite slow (as compared to the previous implementation).

Roger.

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

Re: [Xen-devel] [PATCH] xen: fix building on ARM with CONFIG_HIBERNATE_CALLBACKS

[Boris Ostrovsky]

On 05/19/2015 10:36 AM, Arnd Bergmann wrote:

On Tuesday 19 May 2015 09:57:19 Boris Ostrovsky wrote:

On 05/19/2015 08:58 AM, Arnd Bergmann wrote:

A recent bug fix for x86 broke Xen on ARM for the case that
CONFIG_HIBERNATE_CALLBACKS is enabled:

drivers/built-in.o: In function `do_suspend':
/git/arm-soc/drivers/xen/manage.c:134: undefined reference to `xen_arch_suspend'
drivers/built-in.o:(.debug_addr+0xc3f4): undefined reference to 
`xen_arch_suspend'

It is not clear to me what needs to be done here, but this
patch avoids the build error by adding a stub for the
missing function.

This is already fixed in Xen staging tree.

I see. Any chance to get that fix into linux-next soon?



David, are you going to send pull request to Linus before rc5?

-boris

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

Re: [Xen-devel] Xen/arm: Virtual ITS command queue handling

[Ian Campbell]

On Tue, 2015-05-19 at 15:05 +0100, Julien Grall wrote:
> On 19/05/15 13:48, Vijay Kilari wrote:
> > On Tue, May 19, 2015 at 5:49 PM, Ian Campbell  
> > wrote:
> >> On Tue, 2015-05-19 at 17:40 +0530, Vijay Kilari wrote:
>  If a guest issues (for example) a MOVI which is not followed by an
>  INV/INVALL on native then what would trigger the LPI configuration to be
>  applied by the h/w?
> 
>  If a guest is required to send an INV/INVALL in order for some change to
>  take affect and it does not do so then it is buggy, isn't it?
> >>>
> >>> agreed.
> >>>
> 
>  IOW all Xen needs to do is to propagate any guest initiated INV/INVALL
>  as/when it occurs in the command queue. I don't think we need to
>  fabricate an additional INV/INVALL while emulating a MOVI.
> 
>  What am I missing?
> >>>
> >>> back to point:
> >>>
> >>> INV has device id so not an issue.
> >>> INVALL does not have device id to know pITS to send.
> >>> For that reason Xen is expected to insert INVALL at proper
> >>> places similar to SYNC and ignore INV/INVALL of guest.
> >>
> >> Why wouldn't Xen just insert an INVALL in to all relevant pITS in
> >> response to an INVALL from the guest?
> > 
> > If INVALL is sent on all pITS, then we need to wait for all pITS to complete
> > the command before we update CREADR of vITS.
> > 
> >>
> >> If you are proposing something different then please be explicit by what
> >> you mean by "proper places similar to SYNC". Ideally by proposing some
> >> new text which I can use in the document.
> > 
> > If the platform has more than 1 pITS, The ITS commands are mapped
> > from vITS to pITS using device ID provided with ITS command.
> > 
> > However SYNC and INVALL does not have device ID.
> > In such case there could be two ways to handle
> > 1) SYNC and INVALL of guest will be sent to pITS based on previous ITS 
> > commands
> > of guest
> > 2) Xen will insert/append SYNC and INVALL to guest ITS commands
> > where-ever required and ignore guest
> >SYNC and INVALL commands
> > 
> > IMO (2) would be better as approach (1) might fail to handle
> > scenario where-in guest is sending only SYNC & INVALL commands.
> 
> When the guest send a SYNC, it expects all the command to be completed.
> If you send SYNC only when you think it's required we will end up to
> unexpected behavior.
> 
> Now, for INVALL, as said on a previous mail it's never required after an
> instruction. It's used to ask the ITS to invalid his cache of the LPI
> configuration.
> 
> A software would be buggy if no INV/INVALL is sent after change the LPI
> configuration table.

Specifically _guest_ software.

AIUI the ITS is not required to reread the LPI cfg table unless an
INV/INVALL is issued, but it is allowed to do so if it wants, i.e. it
could pickup the config change at any point after the write to the cfg
table. Is that correct?

If so then as long as it cannot blow up in Xen's face (i.e. an interrupt
storm) I think between a write to the LPI config table and the next
associated INV/INVALL we are entitled either continue using the old
config until the INV/INVALL, to immediately enact the change or anything
in the middle. I think this gives a fair bit of flexibility.

You've proposed something at the "immediately enact" end of the
spectrum.

> As suggested on a previous mail, I think we can get rid of sending
> INV/INVALL command to the pITS by trapping the LPI configuration table:

The motivation here is simply to avoid the potential negative impact on
the system of a guest which fills its command queue with INVALL
commands?

I think we don't especially care about INV since they are targeted. We
care about INVALL because they are global. INV handling comes along for
the ride though.

> For every write access, when the vLPIs is valid (i.e associated to a
> device/interrupt), Xen will toggle the enable bit in the hardware LPIs
> configuration table, send an INV * and sync his internal state. This
> requiring to be able to translate the vLPIs to a (device,ID).

"INV *"? You don't mean INVALL I think, but rather INV of the specific
device?

One possible downside is that you will convert this guest vits
interaction:
for all LPIs
enable LPI
INVALL

Into this pits interaction:
for all LPIs
enable LPI
INV LPI

Also sequences of events with toggle things back and forth before
invalidating are similarly made more synchronous. (Such sequences seem
dumb to me, but kernel side abstractions sometimes lead to such things).

> INVALL/INV command could be ignored and directly increment CREADR (with
> some care) because it only ensure that the command has been executed,
> not fully completed. A SYNC would be required from the guest in order to
> ensure the completion.
> 
> Therefore we would need more care for the SYNC. Maybe by injecting a
> SYNC when it's necessary.
> 
> Note that we would need Xen to send command on behalf of the gu

Re: [Xen-devel] [PATCH v21 02/14] x86/VPMU: Add public xenpmu.h

[Boris Ostrovsky]

On 05/19/2015 02:48 AM, Jan Beulich wrote:

On 18.05.15 at 18:12,  wrote:

On 05/18/2015 11:15 AM, Jan Beulich wrote:

On 08.05.15 at 23:06,  wrote:

+/*
+ * Architecture-specific information describing state of the processor at
+ * the time of PMU interrupt.
+ * Fields of this structure marked as RW for guest can only be written by the
+ * guest when PMU_CACHED bit in pmu_flags is set (which is done by the
+ * hypervisor during PMU interrupt). Hypervisor will read updated data in
+ * XENPMU_flush hypercall and clear PMU_CACHED bit.
+ */
+struct xen_pmu_arch {
+union {
+/*
+ * Processor's registers at the time of interrupt.
+ * RW for hypervisor, RO for guests.
+ */
+struct xen_pmu_regs regs;
+/* Padding for adding new registers to xen_pmu_regs in the future */
+#define XENPMU_REGS_PAD_SZ  64
+uint8_t pad[XENPMU_REGS_PAD_SZ];
+} r;
+
+/* RW for hypervisor, RO for guest */
+uint64_t pmu_flags;
+
+/*
+ * APIC LVTPC register.
+ * RW for both hypervisor and guest.
+ * Only APIC_LVT_MASKED bit is loaded by the hypervisor into hardware
+ * during XENPMU_flush.
+ */
+union {
+uint32_t lapic_lvtpc;
+uint64_t pad;
+} l;
+
+/*
+ * Vendor-specific PMU registers.
+ * RW for both hypervisor and guest.
+ * Guest's updates to this field are verified and then loaded by the
+ * hypervisor into hardware during XENPMU_flush
+ */
+union {
+struct xen_pmu_amd_ctxt amd;
+struct xen_pmu_intel_ctxt intel;
+
+/*
+ * Padding for contexts (fixed parts only, does not include MSR banks
+ * that are specified by offsets)
+ */
+#define XENPMU_CTXT_PAD_SZ  128
+uint8_t pad[XENPMU_CTXT_PAD_SZ];
+} c;
+};

Marking all the fields RW for the hypervisor is certainly correct from
a permissions pov, but requires close auditing that the hypervisor
doesn't ever read a field twice, potentially getting different results
and hence inconsistent internal state. Therefore - do all of the fields
_need_ to be RW for the hypervisor? If not, marking the ones
where this isn't needed as WO would be much preferred, to limit
the scope of whats needs to be audited.

Right, all arch-independent bits are WO for hypervisor as are
xen_pmu_regs above. I in fact meant to label them as such but for
reasons that I can't remember now decided to mark them as RW.

Okay, that simplifies things for review purposes: Of the left
fields, lapic_lvtpc can easily be verified to be read just once, and
the vendor specific context gets copied into hypervisor memory
once before doing verification and loading. Which leaves pmu_flags:
Can you clarify how the read-write behavior there is expected to
be (perhaps by slightly extending the respective comment)? I ask
in particular because I don't recall having seen any read-once
enforcement in the code.



pmu_flags are not read-once by neither hypervisor nor the guest. The 
hypervisor uses PMU_CACHED flag (which it sets in the PMU interrupt) to 
later determine whether or not to perform things like VPMU load (if the 
flag is set then there is no reason to load). This may happen more than 
once.


The rest of flags are WO by the hypervisor.

For the guest PMU_CACHED is indication that it shouldn't write MSRs 
directly but rather do this into the shared page.


I don't believe that if guest writes flags (PMU_CACHED specifically) it 
will have any effect on the hypervisor or other guests. It will 
certainly affect the guest itself as it will probably mess up its VPMU 
state. For example, we may end up loading the VPMU context when it 
shouldn't be and that may result in an unexpected interrupt for the guest.
I can easily add a hypervisor-private flag for this purpose (into 
vpmu_struct.flags) to make things more cleanly delineated (i.e. 
pmu_flags will be strictly WO by hypervisor and RO by the guest). I 
still want to keep PMU_CACHED flag for the guest though so that it knows 
where to write MSRs (Linux PV guests don't need this right now but other 
guests may find this useful).


-boris

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

Re: [Xen-devel] [PATCH] xen: fix building on ARM with CONFIG_HIBERNATE_CALLBACKS

[Arnd Bergmann]

On Tuesday 19 May 2015 09:57:19 Boris Ostrovsky wrote:
> On 05/19/2015 08:58 AM, Arnd Bergmann wrote:
> > A recent bug fix for x86 broke Xen on ARM for the case that
> > CONFIG_HIBERNATE_CALLBACKS is enabled:
> >
> > drivers/built-in.o: In function `do_suspend':
> > /git/arm-soc/drivers/xen/manage.c:134: undefined reference to 
> > `xen_arch_suspend'
> > drivers/built-in.o:(.debug_addr+0xc3f4): undefined reference to 
> > `xen_arch_suspend'
> >
> > It is not clear to me what needs to be done here, but this
> > patch avoids the build error by adding a stub for the
> > missing function.
> 
> This is already fixed in Xen staging tree.

I see. Any chance to get that fix into linux-next soon?

Arnd

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

Re: [Xen-devel] [RFC 13/23] xen/xenbus: Use Xen page definition

[Julien Grall]

Hi David,

On 19/05/15 14:59, David Vrabel wrote:
> On 14/05/15 18:00, Julien Grall wrote:
>> The xenstore ring is always based on the page granularity of Xen.
> [...]
>> --- a/drivers/xen/xenbus/xenbus_probe.c
>> +++ b/drivers/xen/xenbus/xenbus_probe.c
>> @@ -713,7 +713,7 @@ static int __init xenstored_local_init(void)
>>  
>>  xen_store_mfn = xen_start_info->store_mfn =
>>  pfn_to_mfn(virt_to_phys((void *)page) >>
>> -   PAGE_SHIFT);
>> +   XEN_PAGE_SHIFT);
> 
> This is page_to_mfn() that you adjusted in the previous patch.

Right, I think there is a couple of other places where page_to_mfn can
be used.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [RFC 12/23] xen: Extend page_to_mfn to take an offset in the page

[Julien Grall]

Hi David,

On 19/05/15 14:57, David Vrabel wrote:
> On 14/05/15 18:00, Julien Grall wrote:
>> With 64KB page granularity support in Linux, a page will be split accross
>> multiple MFN (Xen is using 4KB page granularity). Thoses MFNs may not be
>> contiguous.
>>
>> With the offset in the page, the helper will be able to know which MFN
>> the driver needs to retrieve.
> 
> I think a gnttab_grant_foreign_access_ref()-like helper that takes a
> page would be better.
>
> You will probably want this helper able to return/fill a set of refs for
> 64 KiB pages.

I will see what I can do.

Although, I think this patch is still valid to avoid wrong usage with
64KB page granularity by the caller.

The developer may think that MFN are contiguous which is not always true.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] Xen/arm: Virtual ITS command queue handling

[Ian Campbell]

On Tue, 2015-05-19 at 19:34 +0530, Vijay Kilari wrote:
> On Tue, May 19, 2015 at 7:24 PM, Ian Campbell  wrote:
> > On Tue, 2015-05-19 at 14:36 +0100, Ian Campbell wrote:
> >> On Tue, 2015-05-19 at 14:27 +0100, Julien Grall wrote:
> >> > With the multiple vITS we would have to retrieve the number of vITS.
> >> > Maybe by extending the xen_arch_domainconfig?
> >>
> >> I'm sure we can find a way.
> >>
> >> The important question is whether we want to go for a N:N vits:pits
> >> mapping or 1:N.
> >>
> >> So far I think we are leaning (slightly?) towards the 1:N model, if we
> >> can come up with a satisfactory answer for what to do with global
> >> commands.
> >
> > Actually, Julien just mentioned NUMA which I think is a strong argument
> > for the N:N model.
> >
> > We need to make a choice here one way or another, since it has knock on
> > effects on other parts, e.g the handling of SYNC and INVALL etc.
> >
> > Given that N:N seems likely to be simpler from the Xen side and in any
> > case doesn't preclude us moving to a 1:N model (or even a 2:N model etc)
> > in the future how about we start with that?
> >
> > If there is agreement in taking this direction then I will adjust the
> > relevant sections of the document to reflect this.
> 
> Yes, this make Xen side simple. Most important point to discuss is
> 
> 1) How Xen maps vITS to pITS. its0 -> vits0?

The choices are basically either Xen chooses and the tools get told (or
"Just Know" the result), or the tools choose and setup the mapping in
Xen via hypercalls.

> 2) When PCI device is assigned to DomU, how does domU choose
> vITS to send commands.  AFAIK, the BDF of assigned device
> is different from actual BDF in DomU.

AIUI this is described in the firmware tables.

e.g. in DT via the msi-parent phandle on the PCI root complex or
individual device.

Is there an assumption here that a single PCI root bridge is associated
with a single ITS block? Or can different devices on a PCI bus use
different ITS blocks?

Ian.


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

Re: [Xen-devel] [RFC 10/23] xen/biomerge: WORKAROUND always says the biovec are not mergeable

[Julien Grall]

Hi Boris,

On 15/05/15 16:54, Boris Ostrovsky wrote:
> On 05/14/2015 01:00 PM, Julien Grall wrote:
>> When Linux is using 64K page granularity, every page will be slipt in
>> multiple non-contiguous 4K MFN.
>>
>> I'm not sure how to handle efficiently the check to know whether we can
>> merge 2 biovec with a such case. So for now, always says that biovec are
>> not mergeable.
>>
>> Signed-off-by: Julien Grall 
>> Cc: Konrad Rzeszutek Wilk 
>> Cc: Boris Ostrovsky 
>> Cc: David Vrabel 
>> ---
>>   drivers/xen/biomerge.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/xen/biomerge.c b/drivers/xen/biomerge.c
>> index 0edb91c..20387c2 100644
>> --- a/drivers/xen/biomerge.c
>> +++ b/drivers/xen/biomerge.c
>> @@ -9,6 +9,9 @@ bool xen_biovec_phys_mergeable(const struct bio_vec
>> *vec1,
>>   unsigned long mfn1 = pfn_to_mfn(page_to_pfn(vec1->bv_page));
>>   unsigned long mfn2 = pfn_to_mfn(page_to_pfn(vec2->bv_page));
>>   +/* TODO: Implement it correctly */
>> +return 0;
>> +
>>   return __BIOVEC_PHYS_MERGEABLE(vec1, vec2) &&
>>   ((mfn1 == mfn2) || ((mfn1+1) == mfn2));
>>   }
> 
> 
> I think this is a bit too blunt.  Perhaps check first whether page sizes
> are different in the hypervisor and the guest?

Sounds good.

> 
> (And I am not sure we need __BIOVEC_PHYS_MERGEABLE() test here as it is
> already checked by BIOVEC_PHYS_MERGEABLE() which appears to be the only
> user of xen_biovec_phys_mergeable())

I can send a patch to drop __BIOVEC_PHYS_MERGEABLE.

Regards,

-- 
Julien Grall

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

[Xen-devel] How to turn off persistent grant in xen

[HANNAS YAYA Issa]

Hi
I want to disable persistent grant in xen. I tried to use xenbus to 
disable it. What I did is modifying this line in 
drivers/block/xenblkback/xenbus.c:


791	err = xenbus_printf(xbt, dev->nodename, "feature-persistent", "%u", 
1);



and put this

791	err = xenbus_printf(xbt, dev->nodename, "feature-persistent", "%u", 
0);


but the problem is my domain crash.

I think it is not the only thing to do in order to disable persistent 
grant.

Please can you help me.

Thank you

HANNAS

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

Re: [Xen-devel] [PATCH v2] xen/pcifront: Remove usage of struct timeval

[Boris Ostrovsky]

On 05/19/2015 02:08 AM, Tina Ruchandani wrote:

struct timeval uses a 32-bit field for representing seconds,
which will overflow in the year 2038 and beyond. This patch replaces
struct timeval with 64-bit ktime_t which is 2038 safe.
The patch is part of a larger effort to remove instances of
32-bit timekeeping variables (timeval, time_t and timespec)
from the kernel.

Signed-off-by: Tina Ruchandani 
Suggested-by: Arnd Bergmann 


Reviewed-by: Boris Ostrovsky 



--
Changes in v2:
- Use monotonic time (ktime_get_ns()) instead of real time
since we only care about elapsed delta here.
- Use macro ktime_get_ns() instead of getting ktime_t and
converting it to ns.
---
  drivers/pci/xen-pcifront.c | 8 +++-
  1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 7cfd2db..c4796c8 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -20,6 +20,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  #include 

@@ -115,7 +116,6 @@ static int do_pci_op(struct pcifront_device *pdev, struct 
xen_pci_op *op)
evtchn_port_t port = pdev->evtchn;
unsigned irq = pdev->irq;
s64 ns, ns_timeout;
-   struct timeval tv;
  
  	spin_lock_irqsave(&pdev->sh_info_lock, irq_flags);
  
@@ -132,8 +132,7 @@ static int do_pci_op(struct pcifront_device *pdev, struct xen_pci_op *op)

 * (in the latter case we end up continually re-executing poll() with a
 * timeout in the past). 1s difference gives plenty of slack for error.
 */
-   do_gettimeofday(&tv);
-   ns_timeout = timeval_to_ns(&tv) + 2 * (s64)NSEC_PER_SEC;
+   ns_timeout = ktime_get_ns() + 2 * (s64)NSEC_PER_SEC;
  
  	xen_clear_irq_pending(irq);
  
@@ -141,8 +140,7 @@ static int do_pci_op(struct pcifront_device *pdev, struct xen_pci_op *op)

(unsigned long *)&pdev->sh_info->flags)) {
xen_poll_irq_timeout(irq, jiffies + 3*HZ);
xen_clear_irq_pending(irq);
-   do_gettimeofday(&tv);
-   ns = timeval_to_ns(&tv);
+   ns = ktime_get_ns();
if (ns > ns_timeout) {
dev_err(&pdev->xdev->dev,
"pciback not responding!!!\n");



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

Re: [Xen-devel] [RFC 02/23] xen/xenbus: client: Fix call of virt_to_mfn in xenbus_grant_ring

[Julien Grall]

Hi David,

On 19/05/15 14:51, David Vrabel wrote:
>> --- a/drivers/xen/xenbus/xenbus_client.c
>> +++ b/drivers/xen/xenbus/xenbus_client.c
>> @@ -379,16 +379,16 @@ int xenbus_grant_ring(struct xenbus_device *dev, void 
>> *vaddr,
>>  int i, j;
>>  
>>  for (i = 0; i < nr_pages; i++) {
>> -unsigned long addr = (unsigned long)vaddr +
>> -(PAGE_SIZE * i);
>>  err = gnttab_grant_foreign_access(dev->otherend_id,
>> -  virt_to_mfn(addr), 0);
>> +  virt_to_mfn(vaddr), 0);
>>  if (err < 0) {
>>  xenbus_dev_fatal(dev, err,
>>   "granting access to ring page");
>>  goto fail;
>>  }
>>  grefs[i] = err;
>> +
>> +vaddr = (char *)vaddr + PAGE_SIZE;
> 
> You don't need the cast here since vaddr is a void *.

Arithmetic on void pointer is a GCC extension [1]. I wasn't sure what is
the Linux policy on it.

Regards,

[1] https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html#Pointer-Arith


-- 
Julien Grall

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

Re: [Xen-devel] Xen/arm: Virtual ITS command queue handling

[Julien Grall]

On 19/05/15 14:54, Ian Campbell wrote:
> On Tue, 2015-05-19 at 14:36 +0100, Ian Campbell wrote:
>> On Tue, 2015-05-19 at 14:27 +0100, Julien Grall wrote:
>>> With the multiple vITS we would have to retrieve the number of vITS.
>>> Maybe by extending the xen_arch_domainconfig?
>>
>> I'm sure we can find a way.
>>
>> The important question is whether we want to go for a N:N vits:pits
>> mapping or 1:N.
>>
>> So far I think we are leaning (slightly?) towards the 1:N model, if we
>> can come up with a satisfactory answer for what to do with global
>> commands.
> 
> Actually, Julien just mentioned NUMA which I think is a strong argument
> for the N:N model.
> 
> We need to make a choice here one way or another, since it has knock on
> effects on other parts, e.g the handling of SYNC and INVALL etc.
> 
> Given that N:N seems likely to be simpler from the Xen side and in any
> case doesn't preclude us moving to a 1:N model (or even a 2:N model etc)
> in the future how about we start with that?

+1.

-- 
Julien Grall

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

Re: [Xen-devel] Xen/arm: Virtual ITS command queue handling

[Julien Grall]

On 19/05/15 13:48, Vijay Kilari wrote:
> On Tue, May 19, 2015 at 5:49 PM, Ian Campbell  wrote:
>> On Tue, 2015-05-19 at 17:40 +0530, Vijay Kilari wrote:
 If a guest issues (for example) a MOVI which is not followed by an
 INV/INVALL on native then what would trigger the LPI configuration to be
 applied by the h/w?

 If a guest is required to send an INV/INVALL in order for some change to
 take affect and it does not do so then it is buggy, isn't it?
>>>
>>> agreed.
>>>

 IOW all Xen needs to do is to propagate any guest initiated INV/INVALL
 as/when it occurs in the command queue. I don't think we need to
 fabricate an additional INV/INVALL while emulating a MOVI.

 What am I missing?
>>>
>>> back to point:
>>>
>>> INV has device id so not an issue.
>>> INVALL does not have device id to know pITS to send.
>>> For that reason Xen is expected to insert INVALL at proper
>>> places similar to SYNC and ignore INV/INVALL of guest.
>>
>> Why wouldn't Xen just insert an INVALL in to all relevant pITS in
>> response to an INVALL from the guest?
> 
> If INVALL is sent on all pITS, then we need to wait for all pITS to complete
> the command before we update CREADR of vITS.
> 
>>
>> If you are proposing something different then please be explicit by what
>> you mean by "proper places similar to SYNC". Ideally by proposing some
>> new text which I can use in the document.
> 
> If the platform has more than 1 pITS, The ITS commands are mapped
> from vITS to pITS using device ID provided with ITS command.
> 
> However SYNC and INVALL does not have device ID.
> In such case there could be two ways to handle
> 1) SYNC and INVALL of guest will be sent to pITS based on previous ITS 
> commands
> of guest
> 2) Xen will insert/append SYNC and INVALL to guest ITS commands
> where-ever required and ignore guest
>SYNC and INVALL commands
> 
> IMO (2) would be better as approach (1) might fail to handle
> scenario where-in guest is sending only SYNC & INVALL commands.

When the guest send a SYNC, it expects all the command to be completed.
If you send SYNC only when you think it's required we will end up to
unexpected behavior.

Now, for INVALL, as said on a previous mail it's never required after an
instruction. It's used to ask the ITS to invalid his cache of the LPI
configuration.

A software would be buggy if no INV/INVALL is sent after change the LPI
configuration table.

As suggested on a previous mail, I think we can get rid of sending
INV/INVALL command to the pITS by trapping the LPI configuration table:

For every write access, when the vLPIs is valid (i.e associated to a
device/interrupt), Xen will toggle the enable bit in the hardware LPIs
configuration table, send an INV * and sync his internal state. This
requiring to be able to translate the vLPIs to a (device,ID).

INVALL/INV command could be ignored and directly increment CREADR (with
some care) because it only ensure that the command has been executed,
not fully completed. A SYNC would be required from the guest in order to
ensure the completion.

Therefore we would need more care for the SYNC. Maybe by injecting a
SYNC when it's necessary.

Note that we would need Xen to send command on behalf of the guest (i.e
not part of the command queue).

With this solution, it would be possible to have a small amount of time
where the pITS doesn't use the correct the configuration (i.e the
interrupt not yet enabled/disabled). Xen is able to cooperate with that
and will queue the interrupt to the guest.

Regards,

-- 
Julien Grall

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