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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-pair  9 xen-boot/src_hostfail REGR. vs. 101000
 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101000
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
101000
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-freebsd10-i386  6 xen-boot   fail REGR. vs. 101000

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 101389 pass in 
101413
 test-amd64-amd64-xl-multivcpu 14 guest-saverestore fail in 101389 pass in 
101424
 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
101413 pass in 101424
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
101413 pass in 101424
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 101413 pass in 
101424
 test-amd64-i386-freebsd10-amd64  6 xen-bootfail pass in 101389
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host  fail pass in 101398
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host  fail pass in 101398
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-bootfail pass in 101398
 test-amd64-i386-libvirt   6 xen-boot   fail pass in 101413
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail pass in 101413
 test-armhf-armhf-xl-rtds 11 guest-startfail pass in 101413

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101000
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101000
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101000

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt 12 migrate-support-check fail in 101413 never pass
 test-armhf-armhf-xl-rtds12 migrate-support-check fail in 101413 never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 101413 never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

[Stefano Stabellini]

On Fri, 14 Oct 2016, Andrew Cooper wrote:
> > I like the idea of keeping these info on pandoc on a git repo, like Lars
> > did with the governance.
> 
> I should hasten to add that perhaps picking on the security team in
> isolation was a poor move on my part, for which I apologise. There are
> multiple involved parties with different interests, all of which need
> attending to.

No worries, on my part I just think that we should write down these
things to remember, set expectations and to avoid surprises.


> The feature submitter (should) have a vested interest in getting code
> submitted (even as experimental/tech preview to start with), so that
> others can trial/debug/extend the feature.  Even having code upstream
> but disabled-by-default in Kconfig is a far better position for others
> to start from, than to be provided with instructions saying "there was a
> patch series several months ago on a mailing list".

Undeniably true.

 
> The reviewers/maintainers (should) have a vested interest in keeping the
> overall quality up.  Due to their appointment within the community, they
> have demonstrated knowledge and expertise in their respective areas, and
> the overall project relies on them to ask questions such as "How does $X
> work with $Y?" or "Have you considered $Z as an alternative?", and to
> come to a fair and unbiased opinion to the quality and worthiness of a
> feature.
> 
> The release manager has conflicted vested interests.  On the one hand,
> getting more features in a release is better on paper and in the press,
> but can certainly backfire when features aren't up to scratch. 
> Ultimately, if features in a release are substandard, the downstreams
> and end users will be the ones to bear the pain.  It is in the release
> managers best interest to ensure that the features which are finally
> accepted are actually ready.
> 
> Nothing is ever perfect, but a whole lot of stuff is perfectly good in
> common case, and useful for people in general.  This is why the feature
> doc template specifically has sections for know issues to be fixed, and
> areas for future improvement.  Any documentation (so long as it isn't
> factually incorrect) is better than nothing.
> 
> There seems to be general consensus that a status of "Supported" means
> "with security support", and I agree with this assessment.  Ultimately,
> the security team is accountable to whatever the project as a whole
> declares "Supported", but as the security team are all commiters and
> maintainer there is a large overlap of responsibility.  OTOH, the
> security team are also responsible for managing the fallout when things
> go wrong.
> 
> XSAs are bad publicity, and are a problem for downstreams (remember that
> we have plenty of downstreams who measure quantity of servers in units
> of a datacenter).  Another problem we as a community have is that no
> support status is written down; there is a 13ish? year backlog in this
> regard.  Writing details down in feature docs is intended to get
> everyone on the same, un-ambiguous, page.
> 
> We also have an unfortunate habit of new features appearing, being
> accepted, and (intentionally or unintentionally) available to guests. 
> Fastforward a bit, and it is discovered that said feature resembles a
> sieve in terms of security holes, and the common recourse is to publish
> an XSA stating "turn it off and don't use it with untrusted guests", or
> "here is a patch to actually turn it off, and still don't use it with
> untrusted guests", because we really can't re-engineer a feature in a
> security patch.  (Sorry to pick on TMEM here, but it is now 4 years of
> development later and it still has a lot of development left to go. 
> Reworking features in the light of a security hole can be very
> complicated, and lots of work.)

Yes, that's definitely a position we should try not to be in.


> There should be a high barrier to "Supported" status, because the cost
> of getting it wrong is equally high.  However, there are perfectly
> legitimate intermediate stages such as "Supported in these limited set
> of circumstances".  A number of features are not plausibly for use in
> production environments, but otherwise function fine for
> development/investigatory purposes.  In these cases, something like "no
> security support, but believed to be working fine" might be appropriate.

I agree on this. I think we need an intermediate step: "working but not
supported for security" is completely reasonable. When we say that it is
"working", it should be because we have automated testing for it (I
don't know if I would go as far as requiring it to be in OSSTest, any
automated testing, even third party, would do). If it is not
automatically tested, then it is just "best effort".

Finally some features involve some sort of ABI exposed to the guest. At
some point when the feature is "Supported", the ABI will be most
certainly maintained for backward compatibility. But the feature could
be fully 

Re: [Xen-devel] [PATCH v2 2/2] xen_platform: SUSE xenlinux unplug for emulated PCI

[Stefano Stabellini]

On Fri, 2 Sep 2016, Olaf Hering wrote:
> Implement SUSE specific unplug protocol for emulated PCI devices
> in PVonHVM guests. Its a simple 'outl(1, (ioaddr + 4));'.
> This protocol was implemented and used since Xen 3.0.4.
> It is used in all SUSE/SLES/openSUSE releases up to SLES11SP3 and
> openSUSE 12.3.
> 
> Signed-off-by: Olaf Hering 
> ---
>  hw/i386/xen/xen_platform.c | 31 ++-
>  1 file changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c
> index 53be3c7..6faee4c 100644
> --- a/hw/i386/xen/xen_platform.c
> +++ b/hw/i386/xen/xen_platform.c
> @@ -313,13 +313,42 @@ static void xen_platform_ioport_writeb(void *opaque, 
> hwaddr addr,
> uint64_t val, unsigned int size)
>  {
>  PCIXenPlatformState *s = opaque;
> +PCIDevice *pci_dev = PCI_DEVICE(s);
>  
>  switch (addr) {
>  case 0: /* Platform flags */
>  platform_fixed_ioport_writeb(opaque, 0, (uint32_t)val);
>  break;
> +case 4:
> +if (val == 1) {
> +/*
> + * SUSE unplug for Xenlinux
> + * xen-kmp used this since xen-3.0.4, instead the official 
> protocol
> + * from xen-3.3+ It did an unconditional "outl(1, (ioaddr + 4));"
> + * Pre VMDP 1.7 used 4 and 8 depending on how VMDP was 
> configured.
> + * If VMDP was to control both disk and LAN it would use 4.
> + * If it controlled just disk or just LAN, it would use 8 below.
> + */
> +blk_drain_all();
> +blk_flush_all();

I was about to send a pull request for this series but blk_flush_all
causes a build failure:

/local/qemu-upstream/hw/i386/xen/xen_platform.c: In function 
'xen_platform_ioport_writeb':
/local/qemu-upstream/hw/i386/xen/xen_platform.c:331:13: error: implicit 
declaration of function 'blk_flush_all' [-Werror=implicit-function-declaration]
/local/qemu-upstream/hw/i386/xen/xen_platform.c:331:13: error: nested extern 
declaration of 'blk_flush_all' [-Werror=nested-externs]
cc1: all warnings being treated as errors
make[1]: *** [hw/i386/xen/xen_platform.o] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [subdir-i386-softmmu] Error 2



> +pci_unplug_disks(pci_dev->bus);
> +pci_unplug_nics(pci_dev->bus);
> +}
> +break;
>  case 8:
> -log_writeb(s, (uint32_t)val);
> +switch (val) {
> +case 1:
> +blk_drain_all();
> +blk_flush_all();
> +pci_unplug_disks(pci_dev->bus);
> +break;
> +case 2:
> +pci_unplug_nics(pci_dev->bus);
> +break;
> +default:
> +log_writeb(s, (uint32_t)val);
> +break;
> +}
>  break;
>  default:
>  break;
> 

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

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

[Andrew Cooper]

On 13/10/2016 22:06, Stefano Stabellini wrote:
>
> Credit2 **Supperted**, instead of experimental.
 Supperted?  That's like supported right? ;p


 It is fine for you to propose that a feature should be upgraded to
 supported, and this is probably the best way to formally do so.

 However, final agreement of a feature becoming supported should
>>> include
 input from the security team. (At the end of the day, it is us with
 extra work if the feature isn't up to scratch.)
>>> Is this new? If so, should we formalize the change in process somewhere
>>> (patch to governance, etc.)?
>> This came about when we had .. XSA7? Which was the tmem one and came with 
>> the idea that anything that moves to Supported has to pass the security 
>> audit pass.

Off the top of my head, XSA-7 is the Intel silicon sysret bug.  ITYM
XSA-15, but your point still stands.

> Make sense. In that case we should definitely write it down somewhere.

My entire purpose with introducing feature docs to start with was to try
and do for feature what we now do very well for
docs/misc/xen-command-line.markdown  i.e. to keep the documentation
easy, and up to date.

This does involve the committers, maintainers and reviewers being
mindful to prompt for an update when necessary.  However, it is very
evident from the replies on-list these days that it has become second
nature to a lot of people to either patch the document in the first
place, or prompt others to do the same in submitted patches.

Overall, this is a very good position to be in, for the community as a
whole.  I am certainly hoping that in another couple of years, we as a
community have exactly the same "second nature" mindset when it comes to
keeping the feature docs up to date.

> I like the idea of keeping these info on pandoc on a git repo, like Lars
> did with the governance.

I should hasten to add that perhaps picking on the security team in
isolation was a poor move on my part, for which I apologise. There are
multiple involved parties with different interests, all of which need
attending to.

The feature submitter (should) have a vested interest in getting code
submitted (even as experimental/tech preview to start with), so that
others can trial/debug/extend the feature.  Even having code upstream
but disabled-by-default in Kconfig is a far better position for others
to start from, than to be provided with instructions saying "there was a
patch series several months ago on a mailing list".

The reviewers/maintainers (should) have a vested interest in keeping the
overall quality up.  Due to their appointment within the community, they
have demonstrated knowledge and expertise in their respective areas, and
the overall project relies on them to ask questions such as "How does $X
work with $Y?" or "Have you considered $Z as an alternative?", and to
come to a fair and unbiased opinion to the quality and worthiness of a
feature.

The release manager has conflicted vested interests.  On the one hand,
getting more features in a release is better on paper and in the press,
but can certainly backfire when features aren't up to scratch. 
Ultimately, if features in a release are substandard, the downstreams
and end users will be the ones to bear the pain.  It is in the release
managers best interest to ensure that the features which are finally
accepted are actually ready.

Nothing is ever perfect, but a whole lot of stuff is perfectly good in
common case, and useful for people in general.  This is why the feature
doc template specifically has sections for know issues to be fixed, and
areas for future improvement.  Any documentation (so long as it isn't
factually incorrect) is better than nothing.

There seems to be general consensus that a status of "Supported" means
"with security support", and I agree with this assessment.  Ultimately,
the security team is accountable to whatever the project as a whole
declares "Supported", but as the security team are all commiters and
maintainer there is a large overlap of responsibility.  OTOH, the
security team are also responsible for managing the fallout when things
go wrong.

XSAs are bad publicity, and are a problem for downstreams (remember that
we have plenty of downstreams who measure quantity of servers in units
of a datacenter).  Another problem we as a community have is that no
support status is written down; there is a 13ish? year backlog in this
regard.  Writing details down in feature docs is intended to get
everyone on the same, un-ambiguous, page.

We also have an unfortunate habit of new features appearing, being
accepted, and (intentionally or unintentionally) available to guests. 
Fastforward a bit, and it is discovered that said feature resembles a
sieve in terms of security holes, and the common recourse is to publish
an XSA stating "turn it off and don't use it with untrusted guests", or
"here is a patch to actually turn it off, and still don't use it with
untrusted guests", because 

[Xen-devel] [PATCH for-4.8] altp2m: don't attempt to unshare pages during change_altp2m_gfn op

[Tamas K Lengyel]

Attempting to change gfn mappings with altp2m on a memory shared page results
in a lock-order violation (mm locking order violation: 282 > 254), which
crashes the hypervisor. Don't attempt to automatically unshare such pages and
just fall back to failing the op if the page type is not correct.

Signed-off-by: Tamas K Lengyel 
---
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/mm/p2m.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 9526fff..6a45185 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2628,7 +2628,7 @@ int p2m_change_altp2m_gfn(struct domain *d, unsigned int 
idx,
 if ( !mfn_valid(mfn) )
 {
 mfn = __get_gfn_type_access(hp2m, gfn_x(old_gfn), , ,
-P2M_ALLOC | P2M_UNSHARE, _order, 0);
+P2M_ALLOC, _order, 0);
 
 if ( !mfn_valid(mfn) || t != p2m_ram_rw )
 goto out;
-- 
2.9.3


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-bootfail REGR. vs. 101365
 test-armhf-armhf-xl-arndale  11 guest-start  fail REGR. vs. 101365

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start  fail REGR. vs. 101365
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101365
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101365
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101365

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu692d88b4085559f1254d0e04d64a849ce8ab5932
baseline version:
 qemuu627eae7d729277c84f8e0ac07a8caab39c92c38d

Last test of basis   101365  2016-10-11 02:21:11 Z2 days
Failing since101395  2016-10-12 10:15:00 Z1 days3 attempts
Testing same since   101421  2016-10-13 14:46:06 Z0 days1 attempts


People who touched revisions under test:
  Cornelia Huck 
  Daniel P. Berrange 
  David Gibson 
  Eric Blake 
  Gerd Hoffmann 
  Hans de Goede 
  Lluís Vilanova 
  Marc-André Lureau 
  P J P 
  Peter Maydell 
  Stefan Hajnoczi 
  Thomas Huth 
  Vijay Kumar B 
  Vijay Kumar B. 

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
 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs. 
101396

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101396
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101396
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101396
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101396
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101396

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass

version targeted for testing:
 xen  38ab99b26bf4298a33105ec66f3f6a3f7e05a326
baseline version:
 xen  71b8b46111219a2f83f4f9ae06ac5409744ea86e

Last test of basis   101396  2016-10-12 11:16:02 Z1 days
Testing same since   101415  2016-10-13 06:04:49 Z0 days1 attempts


People who touched revisions under test:
  Alistair Francis 
  Edgar E. Iglesias 
  Ian Jackson 
  Wei Liu 

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

Re: [Xen-devel] [PATCH v2 10/10] xl: allow to set the ratelimit value online for Credit2

[Jim Fehlig]

On 09/29/2016 08:54 PM, Dario Faggioli wrote:

Last part of the wiring necessary for allowing to
change the value of the ratelimit_us parameter online,
for Credit2 (like it is already for Credit1).

Signed-off-by: Dario Faggioli 
Reviewed-by: George Dunlap 


Seeing this patch got me to thinking that it would be cool if libvirt supported 
Credit2 :-). Do you have any plans/time to do that?


Regards,
Jim


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

[Xen-devel] [DOC v7] PV Calls protocol design

[Stefano Stabellini]

Hi all,

This is the design document of the PV Calls protocol. You can find
prototypes of the Linux frontend and backend drivers here:

git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git pvcalls-7

To use them, make sure to enable CONFIG_XEN_PVCALLS in your kernel
config and add "pvcalls=1" to the command line of your DomU Linux
kernel. You also need the toolstack to create the initial xenstore nodes
for the protocol. To do that, please apply the attached patch to libxl
(the patch is based on Xen 4.7.0-rc3) and add "pvcalls=1" to your DomU
config file.

Please review!

Cheers,

Stefano


Changes in v7:
- add a glossary of Xen terms 
- add a paragraph on why Xen was chosen 
- wording improvements
- add links to xenstore documents and headers
- specify that the current version is "1"
- rename max-dataring-page-order to max-page-order
- rename networking-calls to function-calls
- add links to [Data ring] throughout the document
- explain the difference between req_id and id
- mention that future commands larger than 56 bytes will require a
  version increase
- mention that the list of commands is in calling order
- clarify that reuse data rings are found by ref
- rename ENOTSUPP to ENOTSUP
- add padding in struct pvcalls_data_intf for cachelining
- rename pvcalls_ring_queued to pvcalls_ring_unconsumed


Changes in v6:
- add reuse field in release command
- add "networking-calls" backend node on xenstore
- fixed tab/whitespace indentation

Changes in v5:
- clarify text
- rename id to req_id
- rename sockid to id
- move id to request and response specific fields
- add version node to xenstore

Changes in v4:
- rename xensock to pvcalls

Changes in v3:
- add a dummy element to struct xen_xensock_request to make sure the
  size of the struct is the same on both x86_32 and x86_64

Changes in v2:
- add max-dataring-page-order
- add "Publish backend features and transport parameters" to backend
  xenbus workflow
- update new cmd values
- update xen_xensock_request
- add backlog parameter to listen and binary layout
- add description of new data ring format (interface+data)
- modify connect and accept to reflect new data ring format
- add link to POSIX docs
- add error numbers
- add address format section and relevant numeric definitions
- add explicit mention of unimplemented commands
- add protocol node name
- add xenbus shutdown diagram
- add socket operation

---


# PV Calls Protocol version 1

## Glossary

The following is a list of terms and definitions used in the Xen
community. If you are a Xen contributor you can skip this section.

* PV

  Short for paravirtualized.

* Dom0

  First virtual machine that boots. In most configurations Dom0 is
  privileged and has control over hardware devices, such as network
  cards, graphic cards, etc.

* DomU

  Regular unprivileged Xen virtual machine.

* Domain

  A Xen virtual machine. Dom0 and all DomUs are all separate Xen
  domains.

* Guest

  Same as domain: a Xen virtual machine.

* Frontend

  Each DomU has one or more paravirtualized frontend drivers to access
  disks, network, console, graphics, etc. The presence of PV devices is
  advertized on XenStore, a cross domain key-value database. Frontends
  are similar in intent to the virtio drivers in Linux.

* Backend

  A Xen paravirtualized backend typically runs in Dom0 and it is used to
  export disks, network, console, graphics, etcs, to DomUs. Backends can
  live both in kernel space and in userspace. For example xen-blkback
  lives under drivers/block in the Linux kernel and xen_disk lives under
  hw/block in QEMU. Paravirtualized backends are similar in intent to
  virtio device emulators.

* VMX and SVM
  
  On Intel processors, VMX is the CPU flag for VT-x, hardware
  virtualization support. It corresponds to SVM on AMD processors.



## Rationale

PV Calls is a paravirtualized protocol that allows the implementation of
a set of POSIX functions in a different domain. The PV Calls frontend
sends POSIX function calls to the backend, which implements them and
returns a value to the frontend.

This version of the document covers networking function calls, such as
connect, accept, bind, release, listen, poll, recvmsg and sendmsg; but
the protocol is meant to be easily extended to cover different sets of
calls. Unimplemented commands return ENOTSUP.

PV Calls provide the following benefits:
* full visibility of the guest behavior on the backend domain, allowing
  for inexpensive filtering and manipulation of any guest calls
* excellent performance

Specifically, PV Calls for networking offer these advantages:
* guest networking works out of the box with VPNs, wireless networks and
  any other complex configurations on the host
* guest services listen on ports bound directly to the backend domain IP
  addresses
* localhost becomes a secure namespace for inter-VMs communications


## Design

### Why Xen?

PV Calls are part of an effort to create a secure runtime environment
for containers (OCI 

Re: [Xen-devel] [PATCH] acpi: don't register acpi_pad driver if running as xen dom0

[Rafael J. Wysocki]

On Wednesday, October 12, 2016 01:11:45 PM Juergen Gross wrote:
> When running as Xen dom0 a special processor_aggregator driver is
> needed. Don't register the standard driver in this case.
> 
> Without that check an error message:
> 
> "Error: Driver 'processor_aggregator' is already registered,
> aborting..."
> 
> will be displayed.
> 
> Signed-off-by: Juergen Gross 
> ---
>  drivers/acpi/acpi_pad.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
> index 8ea8211..1c3be12 100644
> --- a/drivers/acpi/acpi_pad.c
> +++ b/drivers/acpi/acpi_pad.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define ACPI_PROCESSOR_AGGREGATOR_CLASS  "acpi_pad"
>  #define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor Aggregator"
> @@ -477,6 +478,10 @@ static struct acpi_driver acpi_pad_driver = {
>  
>  static int __init acpi_pad_init(void)
>  {
> + /* Xen acpi pad is responsible when running as Xen Dom0. */
> + if (xen_initial_domain())
> + return -ENODEV;
> +
>   power_saving_mwait_init();
>   if (power_saving_mwait_eax == 0)
>   return -EINVAL;
> 

Applied.

Thanks,
Rafael


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

[Xen-devel] [ovmf baseline-only test] 67875: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67875 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67875/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 08354c34486947da17a36a605f9a4b000132123f
baseline version:
 ovmf a12b214ef9e002b3b7a7f7845bb025a2a8597dcc

Last test of basis67870  2016-10-13 06:23:21 Z0 days
Testing same since67875  2016-10-13 16:18:57 Z0 days1 attempts


People who touched revisions under test:
  Maurice Ma 
  Michael Kinney 
  Tapan Shah 
  Thomas Palmer 

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



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

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

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


Push not applicable.


commit 08354c34486947da17a36a605f9a4b000132123f
Author: Maurice Ma 
Date:   Wed Oct 12 18:00:44 2016 -0700

IntelFsp2Pkg/FspSecCore: Make FSP functions position independent

The current AsmGetFspInfoHeader function in FspHeader.nasm is
position dependent code since it uses absolute address. Change
to use relative address instead to make it position independent.

Cc: Jiewen Yao 
Cc: Giri P Mudusuru 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Maurice Ma 
Reviewed-by: Giri P Mudusuru 

commit 75351daf3e92c86b3d1669ba0e6d95a6e9a270a3
Author: Thomas Palmer 
Date:   Wed Oct 12 13:14:34 2016 -0700

ShellPkg/UefiShellTftpCommandLib: Update TFTP help text

Clear up some help text for the TFTP shell command

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Palmer 
Reviewed-by: Jaben Carsey 

commit dd170333f6444a4256e75356a8f0758a40bfb77d
Author: Michael Kinney 
Date:   Fri Oct 7 14:07:03 2016 -0700

BaseTools/GenFds: Support FDF sections in any order

https://bugzilla.tianocore.org/show_bug.cgi?id=141

This patch updates EDK II FDF parser in GenFds to allow sections
to be placed in any order in the FDF file.

Cc: Kelly Steele 
Cc: Yonghong Zhu 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
Reviewed-by: Yonghong Zhu 

commit a7ea752e59bbbf69c6d8a72ee6a8b7a0f77cca7c
Author: Tapan Shah 
Date:   Fri Oct 7 13:59:34 2016 -0700

ShellPkg:?cd \? command fails to go back to the root directory of a file 
system

Allows cd command to go back to the root directory when 'cd \' executed in 
system.

This change prevents last PathRemoveLastItem() call which truncates '\' 
from 'fs0:\'
in desired root path which is required to set CWD to the root directory.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tapan Shah 
Reviewed-by: Jaben Carsey 

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

[Xen-devel] [PATCH v2 2/2] x86/Intel: virtualize support for cpuid faulting

[Kyle Huey]

On HVM guests, the cpuid triggers a vm exit, so we can check the emulated
faulting state in vmx_do_cpuid and inject a GP(0) if CPL > 0. Notably no
hardware support for faulting on cpuid is necessary to emulate support with an
HVM guest.

On PV guests, hardware support is required so that userspace cpuid will trap
to xen. Xen already enables cpuid faulting on supported CPUs for pv guests (that
aren't the control domain, see the comment in intel_ctxt_switch_levelling).
Every PV guest cpuid will trap via a GP(0) to emulate_privileged_op (via
do_general_protection). Once there we simply decline to emulate cpuid if the
CPL > 0 and faulting is enabled, leaving the GP(0) for the guest kernel to
handle.

Signed-off-by: Kyle Huey 
---
 xen/arch/x86/hvm/vmx/vmx.c   | 24 ++--
 xen/arch/x86/traps.c | 30 ++
 xen/include/asm-x86/domain.h |  3 +++
 3 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index b9102ce..55201c1 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2427,16 +2427,25 @@ static void vmx_cpuid_intercept(
 
 HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx);
 }
 
 static int vmx_do_cpuid(struct cpu_user_regs *regs)
 {
 unsigned int eax, ebx, ecx, edx;
 unsigned int leaf, subleaf;
+struct segment_register sreg;
+struct vcpu *v = current;
+
+hvm_get_segment_register(v, x86_seg_ss, );
+if ( v->arch.cpuid_fault && sreg.attr.fields.dpl > 0 )
+{
+hvm_inject_hw_exception(TRAP_gp_fault, 0);
+return 0;
+}
 
 eax = regs->eax;
 ebx = regs->ebx;
 ecx = regs->ecx;
 edx = regs->edx;
 
 leaf = regs->eax;
 subleaf = regs->ecx;
@@ -2694,19 +2703,23 @@ static int vmx_msr_read_intercept(unsigned int msr, 
uint64_t *msr_content)
 case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
 case MSR_IA32_PEBS_ENABLE:
 case MSR_IA32_DS_AREA:
 if ( vpmu_do_rdmsr(msr, msr_content) )
 goto gp_fault;
 break;
 
 case MSR_INTEL_PLATFORM_INFO:
-if ( rdmsr_safe(MSR_INTEL_PLATFORM_INFO, *msr_content) )
-goto gp_fault;
+*msr_content = MSR_PLATFORM_INFO_CPUID_FAULTING;
+break;
+
+case MSR_INTEL_MISC_FEATURES_ENABLES:
 *msr_content = 0;
+if ( current->arch.cpuid_fault )
+*msr_content |= MSR_MISC_FEATURES_CPUID_FAULTING;
 break;
 
 default:
 if ( passive_domain_do_rdmsr(msr, msr_content) )
 goto done;
 switch ( long_mode_do_msr_read(msr, msr_content) )
 {
 case HNDL_unhandled:
@@ -2925,16 +2938,23 @@ static int vmx_msr_write_intercept(unsigned int msr, 
uint64_t msr_content)
 break;
 
 case MSR_INTEL_PLATFORM_INFO:
 if ( msr_content ||
  rdmsr_safe(MSR_INTEL_PLATFORM_INFO, msr_content) )
 goto gp_fault;
 break;
 
+case MSR_INTEL_MISC_FEATURES_ENABLES:
+if ( msr_content & ~MSR_MISC_FEATURES_CPUID_FAULTING )
+goto gp_fault;
+v->arch.cpuid_fault =
+!!(msr_content & MSR_MISC_FEATURES_CPUID_FAULTING);
+break;
+
 default:
 if ( passive_domain_do_wrmsr(msr, msr_content) )
 return X86EMUL_OKAY;
 
 if ( wrmsr_viridian_regs(msr, msr_content) ) 
 break;
 
 switch ( long_mode_do_msr_write(msr, msr_content) )
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 293ff8d..6d1c1ef 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1315,16 +1315,20 @@ static int emulate_forced_invalid_op(struct 
cpu_user_regs *regs)
 /* We only emulate CPUID. */
 if ( ( rc = copy_from_user(instr, (char *)eip, sizeof(instr))) != 0 )
 {
 propagate_page_fault(eip + sizeof(instr) - rc, 0);
 return EXCRET_fault_fixed;
 }
 if ( memcmp(instr, "\xf\xa2", sizeof(instr)) )
 return 0;
+/* Let the guest have this one */
+if ( current->arch.cpuid_fault && !guest_kernel_mode(current, regs) )
+return 0;
+
 eip += sizeof(instr);
 
 pv_cpuid(regs);
 
 instruction_done(regs, eip, 0);
 
 trace_trap_one_addr(TRC_PV_FORCED_INVALID_OP, regs->eip);
 
@@ -2474,16 +2478,27 @@ static int priv_op_read_msr(unsigned int reg, uint64_t 
*val,
 *val = 0;
 return X86EMUL_OKAY;
 
 case MSR_INTEL_PLATFORM_INFO:
 if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
  rdmsr_safe(MSR_INTEL_PLATFORM_INFO, *val) )
 break;
 *val = 0;
+if ( this_cpu(cpuid_faulting_enabled) )
+*val |= MSR_PLATFORM_INFO_CPUID_FAULTING;
+return X86EMUL_OKAY;
+
+case MSR_INTEL_MISC_FEATURES_ENABLES:
+if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
+ rdmsr_safe(MSR_INTEL_MISC_FEATURES_ENABLES, *val))
+break;
+*val = 0;
+

[Xen-devel] [PATCH v2 1/2] x86/Intel: Expose cpuid_faulting_enabled so it can be used elsewhere

[Kyle Huey]

---
 xen/arch/x86/cpu/intel.c| 3 ++-
 xen/include/asm-x86/cpuid.h | 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
index 7b60aaa..95c8e14 100644
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -27,19 +27,20 @@ static bool_t __init probe_intel_cpuid_faulting(void)
return 0;
 
expected_levelling_cap |= LCAP_faulting;
levelling_caps |=  LCAP_faulting;
__set_bit(X86_FEATURE_CPUID_FAULTING, boot_cpu_data.x86_capability);
return 1;
 }
 
+DEFINE_PER_CPU(bool_t, cpuid_faulting_enabled);
+
 static void set_cpuid_faulting(bool_t enable)
 {
-   static DEFINE_PER_CPU(bool_t, cpuid_faulting_enabled);
bool_t *this_enabled = _cpu(cpuid_faulting_enabled);
uint32_t hi, lo;
 
ASSERT(cpu_has_cpuid_faulting);
 
if (*this_enabled == enable)
return;
 
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index 8e3f639..af8eb9d 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -59,16 +59,19 @@ struct cpuidmasks
 };
 
 /* Per CPU shadows of masking MSR values, for lazy context switching. */
 DECLARE_PER_CPU(struct cpuidmasks, cpuidmasks);
 
 /* Default masking MSR values, calculated at boot. */
 extern struct cpuidmasks cpuidmask_defaults;
 
+/* Whether or not cpuid faulting is available for the current domain. */
+DECLARE_PER_CPU(bool_t, cpuid_faulting_enabled);
+
 #endif /* __ASSEMBLY__ */
 #endif /* !__X86_CPUID_H__ */
 
 /*
  * Local variables:
  * mode: C
  * c-file-style: "BSD"
  * c-basic-offset: 4

base-commit: 71b8b46111219a2f83f4f9ae06ac5409744ea86e
-- 
2.10.1


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

[Xen-devel] [PATCH v2] x86/Intel: virtualize support for cpuid faulting

[Kyle Huey]

rr (http://rr-project.org/), a Linux userspace record-and-replay reverse-
execution debugger, would like to trap and emulate the CPUID instruction.
This would allow us to a) mask away certain hardware features that rr does
not support (e.g. RDRAND) and b) enable trace portability across machines
by providing constant results. Patches for support in the Linux kernel are in
flight, and we'd like to be able to use this feature on virtualized Linux
instances as well.

Changes since the previous version:
- Rebased.
- Exposed cpuid_faulting_enabled outside of cpu/intel.c, as suggested by
  Andrew Cooper. This is now patch 1, and the original changes are in
  patch 2.
- Various style nits from Andrew Cooper and Jan Beulich.
- Additional style changes not suggested (primarily replacing ternaries with
  if (condition) value |= BIT for futureproofing).
- Check guest_kernel_mode instead of ring_0 in emulate_privileged_op.
- Check cpuid_fault and guest_kernel_mode in emulate_forced_invalid_op.


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

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

[Stefano Stabellini]

On Thu, 13 Oct 2016, Konrad Rzeszutek Wilk wrote:
> On October 13, 2016 2:13:19 PM EDT, Stefano Stabellini 
>  wrote:
> >On Thu, 13 Oct 2016, Andrew Cooper wrote:
> >> On 13/10/16 12:01, Dario Faggioli wrote:
> >> > Hey,
> >> >
> >> > "Just" as per the subject, I wrote feature documents for (almost)
> >all our
> >> > schedulers. No big deal, I'd say, apart from the fact that I'm
> >declaring
> >> > Credit2 **Supperted**, instead of experimental.
> >> 
> >> Supperted?  That's like supported right? ;p
> >> 
> >> 
> >> It is fine for you to propose that a feature should be upgraded to
> >> supported, and this is probably the best way to formally do so.
> >> 
> >> However, final agreement of a feature becoming supported should
> >include
> >> input from the security team. (At the end of the day, it is us with
> >> extra work if the feature isn't up to scratch.)
> >
> >Is this new? If so, should we formalize the change in process somewhere
> >(patch to governance, etc.)?
> 
> This came about when we had .. XSA7? Which was the tmem one and came with the 
> idea that anything that moves to Supported has to pass the security audit 
> pass.

Make sense. In that case we should definitely write it down somewhere. I
like the idea of keeping these info on pandoc on a git repo, like Lars
did with the governance.

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

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

[Konrad Rzeszutek Wilk]

On October 13, 2016 2:13:19 PM EDT, Stefano Stabellini  
wrote:
>On Thu, 13 Oct 2016, Andrew Cooper wrote:
>> On 13/10/16 12:01, Dario Faggioli wrote:
>> > Hey,
>> >
>> > "Just" as per the subject, I wrote feature documents for (almost)
>all our
>> > schedulers. No big deal, I'd say, apart from the fact that I'm
>declaring
>> > Credit2 **Supperted**, instead of experimental.
>> 
>> Supperted?  That's like supported right? ;p
>> 
>> 
>> It is fine for you to propose that a feature should be upgraded to
>> supported, and this is probably the best way to formally do so.
>> 
>> However, final agreement of a feature becoming supported should
>include
>> input from the security team. (At the end of the day, it is us with
>> extra work if the feature isn't up to scratch.)
>
>Is this new? If so, should we formalize the change in process somewhere
>(patch to governance, etc.)?

This came about when we had .. XSA7? Which was the tmem one and came with the 
idea that anything that moves to Supported has to pass the security audit pass.


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

Re: [Xen-devel] ANNOUNCEMENT] Xen 4.8 RC2 FULL SUCCESS 13.10.16

[Juergen Schinker]

* Hardware:
 Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz


* Software:

Debian testing is the Host
 

* Guest operating systems:
Guests Ubuntu 14.04 LTS Debian Stretch/Sid Ubuntu 16.04
 
* Functionality tested:
xl 
creating booting 
pygrub

* Comments:

Wei Liu is the man

- On 13 Oct, 2016, at 16:45, Wei Liu wei.l...@citrix.com wrote:

> Add back xen-devel

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

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Andrew Cooper]

On 13/10/16 19:59, Dan Williams wrote:
> On Thu, Oct 13, 2016 at 9:01 AM, Andrew Cooper
>  wrote:
>> On 13/10/16 16:40, Dan Williams wrote:
>>> On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich  wrote:
>>> [..]
> I think we can do the similar for Xen, like to lay another pseudo
> device on /dev/pmem and do the reservation, like 2. in my previous
> reply.
 Well, my opinion certainly doesn't count much here, but I continue to
 consider this a bad idea. For entities like drivers it may well be
 appropriate, but I think there ought to be an independent concept
 of "OS reserved", and in the Xen case this could then be shared
 between hypervisor and Dom0 kernel. Or if we were to consider Dom0
 "just a guest", things should even be the other way around: Xen gets
 all of the OS reserved space, and Dom0 needs something custom.
>>> You haven't made the case why Xen is special and other applications of
>>> persistent memory are not.
>> In a Xen system, Xen runs in the baremetal root-mode ring0, and dom0 is
>> a VM running in ring1/3 with the nvdimm driver.  This is the opposite
>> way around to the KVM model.
>>
>> Dom0, being the hardware domain, has default ownership of all the
>> hardware, but to gain access in the first place, it must request a
>> mapping from Xen.
> This is where my understanding the Xen model breaks down.  Are you
> saying dom0 can't access the persistent memory range unless the ring0
> agent has metadata storage space for tracking what it maps into dom0?

No.  I am trying to point out that the current suggestion wont work, and
needs re-designing.

Xen *must* be able to properly configure mappings of the NVDIMM for
dom0, *without* modifying any content on the NVDIMM.  Otherwise, data
corruption will occur.

Whether this means no Xen metadata, or the metadata living elsewhere in
regular ram, such as the main frametable, is an implementation detail.

>
>> Once dom0 has a mapping of the nvdimm, the nvdimm driver can go to work
>> and figure out what is on the DIMM, and which areas are safe to use.
> I don't understand this ordering of events.  Dom0 needs to have a
> mapping to even write the on-media structure to indicate a
> reservation.  So, initial dom0 access can't depend on metadata
> reservation already being present.

I agree.

Overall, I think the following is needed.

* Xen starts up.
** Xen might find some NVDIMM SPA/MFN ranges in the NFIT table, and
needs to note this information somehow.
** Xen might find some Type 7 E820 regions, and needs to note this
information somehow.
* Xen starts dom0.
* Once OSPM is running, a Xen component in Linux needs to collect and
report all NVDIMM SPA/MFN regions it knowns about.
** This covers the AML-only case, and the hotplug case.
* Dom0 requests a mapping of the NVDIMMs via the usual mechanism.
** This should work, as Xen is aware that there is something there to be
mapped (rather than just empty physical address space).
* Dom0 finds that some NVDIMM ranges are now available for use (probably
modelled as hotplug events).
* /dev/pmem $STUFF starts happening as normal.

At some pointer later after dom0 policy decisions are made (ultimately,
by the host administrator):
* If an area of NVDIMM is chosen for Xen to use, Dom0 needs to inform
Xen of the SPA/MFN regions which are safe to use.
* Xen then incorporates these regions into its idea of RAM, and starts
using them for whatever.

~Andrew

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

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Dan Williams]

On Thu, Oct 13, 2016 at 9:01 AM, Andrew Cooper
 wrote:
> On 13/10/16 16:40, Dan Williams wrote:
>> On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich  wrote:
>> [..]
 I think we can do the similar for Xen, like to lay another pseudo
 device on /dev/pmem and do the reservation, like 2. in my previous
 reply.
>>> Well, my opinion certainly doesn't count much here, but I continue to
>>> consider this a bad idea. For entities like drivers it may well be
>>> appropriate, but I think there ought to be an independent concept
>>> of "OS reserved", and in the Xen case this could then be shared
>>> between hypervisor and Dom0 kernel. Or if we were to consider Dom0
>>> "just a guest", things should even be the other way around: Xen gets
>>> all of the OS reserved space, and Dom0 needs something custom.
>> You haven't made the case why Xen is special and other applications of
>> persistent memory are not.
>
> In a Xen system, Xen runs in the baremetal root-mode ring0, and dom0 is
> a VM running in ring1/3 with the nvdimm driver.  This is the opposite
> way around to the KVM model.
>
> Dom0, being the hardware domain, has default ownership of all the
> hardware, but to gain access in the first place, it must request a
> mapping from Xen.

This is where my understanding the Xen model breaks down.  Are you
saying dom0 can't access the persistent memory range unless the ring0
agent has metadata storage space for tracking what it maps into dom0?
That can't be true because then PCI memory ranges would not work
without metadata reserve space.  Dom0 still needs to map and write the
DIMMs to even set up the struct page reservation, it isn't established
by default.

> Xen therefore needs to know and cope with being able
> to give dom0 a mapping to the nvdimms, without touching the content of
> the nvidmm itself (so as to avoid corrupting data).

Is it true that this metadata only comes into use when remapping the
dom0 discovered range(s) into a guest VM?

> Once dom0 has a mapping of the nvdimm, the nvdimm driver can go to work
> and figure out what is on the DIMM, and which areas are safe to use.

I don't understand this ordering of events.  Dom0 needs to have a
mapping to even write the on-media structure to indicate a
reservation.  So, initial dom0 access can't depend on metadata
reservation already being present.

> At this point, a Xen subsystem in Linux could choose one or more areas
> to hand back to the hypervisor to use as RAM/other.

To me all this configuration seems to come after the fact.  After dom0
sees /dev/pmemX devices, then it can go to work carving it up and
writing Xen specific metadata to the range(s).  The struct page
reservation never comes into the picture.  In fact, a raw mode
namespace (one without a reservation) could be used in this model, the
nvdimm core never needs to know what is happening.

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

Re: [Xen-devel] [PATCH] flask: add gcov_op check

[Daniel De Graaf]

On 10/13/2016 10:37 AM, Wei Liu wrote:

Signed-off-by: Wei Liu 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

[Stefano Stabellini]

On Thu, 13 Oct 2016, Andrew Cooper wrote:
> On 13/10/16 12:01, Dario Faggioli wrote:
> > Hey,
> >
> > "Just" as per the subject, I wrote feature documents for (almost) all our
> > schedulers. No big deal, I'd say, apart from the fact that I'm declaring
> > Credit2 **Supperted**, instead of experimental.
> 
> Supperted?  That's like supported right? ;p
> 
> 
> It is fine for you to propose that a feature should be upgraded to
> supported, and this is probably the best way to formally do so.
> 
> However, final agreement of a feature becoming supported should include
> input from the security team. (At the end of the day, it is us with
> extra work if the feature isn't up to scratch.)

Is this new? If so, should we formalize the change in process somewhere
(patch to governance, etc.)?

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  b5283627de6b7ba2b8d75ecf1edf0a46bcd83edb
baseline version:
 xen  38ab99b26bf4298a33105ec66f3f6a3f7e05a326

Last test of basis   101403  2016-10-12 15:03:35 Z1 days
Testing same since   101418  2016-10-13 12:06:49 Z0 days2 attempts


People who touched revisions under test:
  Ian Jackson 
  Jan Beulich 
  Lan Tianyu 
  Wei Liu 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=b5283627de6b7ba2b8d75ecf1edf0a46bcd83edb
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
b5283627de6b7ba2b8d75ecf1edf0a46bcd83edb
+ branch=xen-unstable-smoke
+ revision=b5283627de6b7ba2b8d75ecf1edf0a46bcd83edb
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' xb5283627de6b7ba2b8d75ecf1edf0a46bcd83edb = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.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
++ : 

Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit

[Wei Liu]

Add back xen-devel

On Thu, Oct 13, 2016 at 05:26:12PM +0100, Juergen Schinker wrote:
> 
> 
> - On 13 Oct, 2016, at 14:53, Wei Liu wei.l...@citrix.com wrote:
> 
> > Hmm... I think no amount of hand-holding is going to help you.
> > 
> > In your situation I would suggest you to use various tools available on
> > Linux to figure out why it hang. Tools like strace, ldd, gdb etc, but
> > that's going to be rather technical and the finding isn't going to be
> > useful or interesting to you in the long run. The hang is likely due to
> > mismatch in various bits in the system.
> > 
> > I think your best bet is to have a clean installation of Xen.
> > 
> > Wei.
> 
> I don't want hand holding - this is a bug report dude
> 
> I;m very technical and it is useful and interesting

Sorry if that came out offensive to you -- I didn't mean to.

If you're really interested in going down this rabbit hole, I think you
will need to do the following:

1. Make sure all the Xen related libraries are properly installed into
   the location you specified when building Xen.
2. Use ldd to check if xl / xenstored are the ones you installed.
3. Make sure they can find all the libraries (ldd should be handy).
4. Use strace to identify when and where they hang.

There is a lot information about Xen in general on wiki.xenproject.org.
If you need to get more information about the architecture / moving
parts of Xen, check out the wiki.

After identifying why they don't work, you will have a lot more
information to either submit a detailed bug report or start hunting down
these issues for fun and profit (!). :-)

There isn't enough information in the current report for me to tell what
goes wrong in your setup. The basic life cycle of running Xen (the
operations in your bug report) is constantly tested in Xen project CI
and all developers -- neither CI nor humans spotted bugs in those areas
in the past week.

Wei.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-i386  6 xen-boot   fail REGR. vs. 101000
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-pair  9 xen-boot/src_hostfail REGR. vs. 101000
 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101000
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
101000
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 101000

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-multivcpu 14 guest-saverestore fail in 101389 pass in 
101413
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 101389 pass in 
101413
 test-amd64-i386-freebsd10-amd64  6 xen-bootfail pass in 101389
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-bootfail pass in 101398
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host  fail pass in 101398
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host  fail pass in 101398
 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail pass 
in 101398
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail pass 
in 101398

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail REGR. vs. 101000
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101000
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101000
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101000

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 linux3cab355c2ff3a781b6ebe9d1a25bd4ebc1207430
baseline version:

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Andrew Cooper]

On 13/10/16 16:40, Dan Williams wrote:
> On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich  wrote:
> [..]
>>> I think we can do the similar for Xen, like to lay another pseudo
>>> device on /dev/pmem and do the reservation, like 2. in my previous
>>> reply.
>> Well, my opinion certainly doesn't count much here, but I continue to
>> consider this a bad idea. For entities like drivers it may well be
>> appropriate, but I think there ought to be an independent concept
>> of "OS reserved", and in the Xen case this could then be shared
>> between hypervisor and Dom0 kernel. Or if we were to consider Dom0
>> "just a guest", things should even be the other way around: Xen gets
>> all of the OS reserved space, and Dom0 needs something custom.
> You haven't made the case why Xen is special and other applications of
> persistent memory are not.

In a Xen system, Xen runs in the baremetal root-mode ring0, and dom0 is
a VM running in ring1/3 with the nvdimm driver.  This is the opposite
way around to the KVM model.

Dom0, being the hardware domain, has default ownership of all the
hardware, but to gain access in the first place, it must request a
mapping from Xen.  Xen therefore needs to know and cope with being able
to give dom0 a mapping to the nvdimms, without touching the content of
the nvidmm itself (so as to avoid corrupting data).

Once dom0 has a mapping of the nvdimm, the nvdimm driver can go to work
and figure out what is on the DIMM, and which areas are safe to use.

At this point, a Xen subsystem in Linux could choose one or more areas
to hand back to the hypervisor to use as RAM/other.

~Andrew

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

[Xen-devel] [linux-4.1 baseline-only test] 67872: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67872 linux-4.1 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67872/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail blocked 
in 67728
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail blocked 
in 67728
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail blocked in 67728
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 67728

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

version targeted for testing:
 linux91473db3a3257eacead8f4d84cf4bc96c447193f
baseline version:
 linux04cb720142764ebf3786eba1feb8fc4b6ef87fcf

Last test of basis67728  2016-09-18 23:15:34 Z   24 days
Testing same since67872  2016-10-13 08:19:29 Z0 days1 attempts


People who touched revisions under test:
  Akshay Bhat 
  Al Viro 
  Alan Stern 
  Andrew Morton 
  Anson Huang 
  Ard Biesheuvel 
  Ashish Samant 
  Balbir Singh 
  Benjamin Herrenschmidt 
  Boris Brezillon 
  Catalin Marinas 
  Chris Mason 
  Christoffer Dall 
  Clemens Gruber 
  Daniele Palmas 
  Dave Airlie 
  David S. Miller 
  Eric Biggers 
  Fabio Estevam 
  Felipe Balbi 
  Felix Fietkau 
  Greg Kroah-Hartman 

Re: [Xen-devel] [PATCH 02/15] xen: Fix coding style warnings

[Emil Condrea]

Oh, I see. Because gmail messes up the alignment but raw diff looked
fine I thought that you were seeing the same issue as I see on email client.

I will align the quoted strings properly with the first parameter and
I will send
another series.

Thanks,
Emil

On Thu, Oct 13, 2016 at 2:35 PM, Anthony PERARD
 wrote:
> On Thu, Oct 13, 2016 at 07:04:56AM +0300, Emil Condrea wrote:
>> On Tue, Oct 11, 2016 at 5:20 PM, Anthony PERARD
>>  wrote:
>> > On Tue, Oct 04, 2016 at 09:43:31AM +0300, Emil Condrea wrote:
>> >> Fixes:
>> >>  * WARNING: line over 80 characters
>> >>
>> >> Signed-off-by: Emil Condrea 
>> >> ---
>> >>  hw/block/xen_disk.c  |  3 ++-
>> >>  hw/char/xen_console.c|  6 --
>> >>  hw/display/xenfb.c   | 30 --
>> >>  hw/net/xen_nic.c | 12 
>> >>  hw/xen/xen_backend.c | 15 ++-
>> >>  include/hw/xen/xen_backend.h |  8 +---
>> >>  6 files changed, 49 insertions(+), 25 deletions(-)
>> >>
>> >> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
>> >> index 5aa350a..24edeb2 100644
>> >> --- a/hw/block/xen_disk.c
>> >> +++ b/hw/block/xen_disk.c
>> >> @@ -1068,7 +1068,8 @@ static int blk_connect(struct XenDevice *xendev)
>> >>  blk_set_enable_write_cache(blkdev->blk, !writethrough);
>> >>  } else {
>> >>  /* setup via qemu cmdline -> already setup for us */
>> >> -xen_be_printf(>xendev, 2, "get configured bdrv (cmdline 
>> >> setup)\n");
>> >> +xen_be_printf(>xendev, 2,
>> >> + "get configured bdrv (cmdline setup)\n");
>> >
>> > Arguments are usually aligned with the first one, so there is one
>> > missing space.
>>
>> I guess this is displayed wrongly in the email client as in mine but the 
>> source
>> of the email contains this patch http://pastebin.com/Sbk23h6m, which shows 
>> that
>> this line is aligned to the first parameter.
>
> My mail client runs in a terminal, also I've apply the patches to a
> local tree, so no display issue.
>
> Here, the quote is just below the open parentheses, but it's normally
> one space futher.
>
> If I ask Vim to realign it, I end up with this:
>  xen_be_printf(>xendev, 2,
> - "get configured bdrv (cmdline setup)\n");
> +  "get configured bdrv (cmdline setup)\n");
>
> You can also have a look at other call of xen_be_printf() in this
> function (blk_connect) to get an idea ;).
>
> --
> Anthony PERARD

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

[Xen-devel] [ovmf test] 101414: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 08354c34486947da17a36a605f9a4b000132123f
baseline version:
 ovmf a12b214ef9e002b3b7a7f7845bb025a2a8597dcc

Last test of basis   101402  2016-10-12 15:00:43 Z1 days
Testing same since   101414  2016-10-13 05:59:09 Z0 days1 attempts


People who touched revisions under test:
  Maurice Ma 
  Michael Kinney 
  Tapan Shah 
  Thomas Palmer 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=08354c34486947da17a36a605f9a4b000132123f
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
08354c34486947da17a36a605f9a4b000132123f
+ branch=ovmf
+ revision=08354c34486947da17a36a605f9a4b000132123f
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x08354c34486947da17a36a605f9a4b000132123f = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.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
++ : 

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Haozhong Zhang]

On 10/13/16 03:08 -0600, Jan Beulich wrote:

On 13.10.16 at 10:53,  wrote:

On 10/13/16 02:34 -0600, Jan Beulich wrote:

On 12.10.16 at 18:19,  wrote:

On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich  wrote:

On 12.10.16 at 17:42,  wrote:

On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich  wrote:

On 12.10.16 at 16:58,  wrote:

On 10/12/16 05:32 -0600, Jan Beulich wrote:

On 12.10.16 at 12:33,  wrote:

The layout is shown as the following diagram.

+---+---+---+--+--+
| whatever used | Partition | Super | Reserved | /dev/pmem0p1 |
|  by kernel|   Table   | Block | for Xen  |  |
+---+---+---+--+--+
\_ ___/
  V
 /dev/pmem0


I have to admit that I dislike this, for not being OS-agnostic.
Neither should there be any Xen-specific region, nor should the
"whatever used by kernel" one be restricted to just Linux. What
I could see is an OS-reserved area ahead of the partition table,
the exact usage of which depends on which OS is currently
running (and in the Xen case this might be both Xen _and_ the
Dom0 kernel, arbitrated by a tbd protocol). After all, when
running under Xen, the Dom0 may not have a need for as much
control data as it has when running on bare hardware, for it
controlling less (if any) of the actual memory ranges when Xen
is present.



Isn't this OS-reserved area still not OS-agnostic, as it requires OS
to know where the reserved area is?  Or do you mean it's not if it's
defined by a protocol that is accepted by all OSes?


The latter - we clearly won't get away without some agreement on
where to retrieve position and size of this area. I was simply
assuming that such a protocol already exists.



No, we should not mix the struct page reservation that the Dom0 kernel
may actively use with the Xen reservation that the Dom0 kernel does
not consume.  Explain again what is wrong with the partition approach?


Not sure what was unclear in my previous reply. I don't think there
should be apriori knowledge of whether Xen is (going to be) used on
a system, and even if it gets used, but just occasionally, it would
(apart from the abstract considerations already given) be a waste
of resources to set something aside that could be used for other
purposes while Xen is not running. Static partitioning should only be
needed for persistent data.


The reservation needs to be persistent / static even if the data is
volatile, as is the case with struct page, because we can't have the
size of the device change depending on use.  So, from the aspect of
wasting space while Xen is not in use, both partitions and the
intrinsic reservation approach suffer the same problem. Setting that
aside I don't want to mix 2 different use cases into the same
reservation.


Then you didn't understand what I've said: I certainly didn't mean
the reservation to vary from a device perspective. However, when
Xen is in use I don't see why part of that static reservation couldn't
be used by Xen, and another part by the Dom0 kernel. The kernel
obviously would need to ask the hypervisor how much of the space
is left, and where that area starts.



I think Dan means that there should be a clear separation between
reservations for different usages (kernel/xen/...). The libnvdimm
driver is for the linux kernel and only needs to maintain the
reservation for kernel functionality. For others including xen/dm/...,
if they want reservation for their own purpose, they should maintain
their own reservations out of libnvdimm driver and avoid bothering the
libnvdimm driver (e.g. add specific handling in libnvdimm driver).

IIUC, one existing example is device-mapper device (dm) which needs to
reserve on-device area for its own meta-data. Its choice is to store
the meta-data on the block device (/dev/pmemN) provided by the
libnvdimm driver.

I think we can do the similar for Xen, like to lay another pseudo
device on /dev/pmem and do the reservation, like 2. in my previous
reply.


Well, my opinion certainly doesn't count much here, but I continue to
consider this a bad idea. For entities like drivers it may well be
appropriate, but I think there ought to be an independent concept
of "OS reserved", and in the Xen case this could then be shared
between hypervisor and Dom0 kernel.


No such independent concept seems exist right now. It may be hard to
define such concept, because it's hard to know the common requirements
(e.g. size/alignment/...)  from ALL OSes. Making each component to
maintain its own reservation in its own way seems more flexible.


Or if we were to consider Dom0
"just a guest", things should even be the other way around: Xen gets
all of the OS reserved space, 

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Dan Williams]

On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich  wrote:
[..]
>> I think we can do the similar for Xen, like to lay another pseudo
>> device on /dev/pmem and do the reservation, like 2. in my previous
>> reply.
>
> Well, my opinion certainly doesn't count much here, but I continue to
> consider this a bad idea. For entities like drivers it may well be
> appropriate, but I think there ought to be an independent concept
> of "OS reserved", and in the Xen case this could then be shared
> between hypervisor and Dom0 kernel. Or if we were to consider Dom0
> "just a guest", things should even be the other way around: Xen gets
> all of the OS reserved space, and Dom0 needs something custom.

You haven't made the case why Xen is special and other applications of
persistent memory are not.  The current struct page reservation
supports fundamental address-ability of persistent memory namespaces
for the rest of the kernel.  The Xen reservation is application
specific.  XFS, EXT4, and DM also have application specific usages of
persistent memory and consume metadata space out of a block device. If
we don't need an XFS-mode nvdimm device, why do we need Xen-mode?

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

Re: [Xen-devel] [PATCH] xen-netback: fix type mismatch warning

[David Miller]

From: Arnd Bergmann 
Date: Wed, 12 Oct 2016 16:54:01 +0200

> Wiht the latest rework of the xen-netback driver, we get a warning
> on ARM about the types passed into min():
> 
> drivers/net/xen-netback/rx.c: In function 'xenvif_rx_next_chunk':
> include/linux/kernel.h:739:16: error: comparison of distinct pointer types 
> lacks a cast [-Werror]
> 
> The reason is that XEN_PAGE_SIZE is not size_t here. There
> is no actual bug, and we can easily avoid the warning using the
> min_t() macro instead of min().
> 
> Fixes: eb1723a29b9a ("xen-netback: refactor guest rx")
> Signed-off-by: Arnd Bergmann 

Applied, thanks.

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

Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit

[Wei Liu]

On Thu, Oct 13, 2016 at 11:02:09AM +0100, Juergen Schinker wrote:
> 
> 
> - On 13 Oct, 2016, at 09:29, Wei Liu wei.l...@citrix.com wrote:
> 
> > On Thu, Oct 13, 2016 at 10:10:46AM +0100, Juergen Schinker wrote:
> >> Right and still no solution
> >> 
> >> there is no xz-dev or libxz-dev;  I installed everything which just looks 
> >> remote
> >> like xz or lzma
> >> 
> > 
> > On Debian it is called liblzma-dev. Not sure what distro you use.
> > 
> >> building is no problem as I build with
> >> 
> >> ./configure --enable-githttp --enable-systemd --disable-rombios
> >> --disable-qemu-traditional --disable-stubdom --disable-docs
> >> 
> >> 
> > 
> > And you sorta worked around the lzma requirement by disabling rombios.
> > 
> > This issue you encountered is a different issue from Boris'.
>  
> no still no solution
> 
> the xz problem is only for xen-4.7 but i gave up on that
> 
> my last test was 4.8-rc2 which also didn't work ; building and booting 
> hypervizor is ok
> 
> xl tools  nope
> 
> creating or starting a VM  nope
> 
> xl -v cr something  hangs forever
> 
> restarting xencommons   hangs
> 
> restarting xenconsoled  hangs
> 
> sigh

Hmm... I think no amount of hand-holding is going to help you.

In your situation I would suggest you to use various tools available on
Linux to figure out why it hang. Tools like strace, ldd, gdb etc, but
that's going to be rather technical and the finding isn't going to be
useful or interesting to you in the long run. The hang is likely due to
mismatch in various bits in the system.

I think your best bet is to have a clean installation of Xen.

Wei.

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

[Xen-devel] [xen-unstable-smoke test] 101418: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt  5 xen-install  fail REGR. vs. 101403

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

version targeted for testing:
 xen  b5283627de6b7ba2b8d75ecf1edf0a46bcd83edb
baseline version:
 xen  38ab99b26bf4298a33105ec66f3f6a3f7e05a326

Last test of basis   101403  2016-10-12 15:03:35 Z0 days
Testing same since   101418  2016-10-13 12:06:49 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Jan Beulich 
  Lan Tianyu 
  Wei Liu 

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



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

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

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

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


Not pushing.


commit b5283627de6b7ba2b8d75ecf1edf0a46bcd83edb
Author: Wei Liu 
Date:   Thu Oct 13 12:03:17 2016 +0100

tools: check liblzma in configure for rombios

We upgraded ipxe in 38ab99b2 ("ipxe: update to new commit"). That
version of ipxe requires liblzma to build.

Check that in configure and document this in README.

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 

commit de05bd965afcd08769c1e21d98ba7c2e4de7394b
Author: Jan Beulich 
Date:   Thu Oct 13 13:07:25 2016 +0200

x86emul: correct {,F}CMOV and F{,U}COMI{,P} emulation

The FPU ones need to be executed with guest EFLAGS.{C,P,Z}F in context.

We also can't exclude someone wanting to hide the feature from (32-bit)
guests.

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

commit 610b4eda2ce2b87cccbc8f61bdec01052e54fc66
Author: Lan Tianyu 
Date:   Thu Oct 13 13:06:28 2016 +0200

keyhandler: rework process of nonirq keyhandler

Keyhandler may run for a long time in serial port driver's
timer handler on the large machine with a lot of physical
cpus(e,g dump_timerq()) when serial port driver works in
the poll mode(via the exception mechanism).

If a timer handler runs a long time, it will block nmi_timer_fn()
to feed NMI watchdog and cause Xen hypervisor panic. Inserting
process_pending_softirqs() in timer handler will not help. when timer
interrupt arrives, timer subsystem calls all expired timer handlers
before programming next timer interrupt. There is no timer interrupt
arriving to trigger timer softirq during run a timer handler.

This patch is to fix the issue to make nonirq keyhandler run in
tasklet when receive debug key from serial port.

Signed-off-by: Lan Tianyu 
Reviewed-by: Jan Beulich 
(qemu changes not included)

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

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

[Sander Eikelenboom]

Hi Jan / Wei,

Took a while before i had the chance to fiddle some more to find the actual 
culprit.
After analyzing the output of xl -v create somewhat more i came to the 
insight it was probably Qemu and not Xen causing the fault.

As a test I just used a qemu-xen binary build with xen-4.6.0 booting up a guest 
with
direct kernel boot mode on xen-unstable. And that old qemu binary works fine.

After testing i can conclude, Jan was right, the bisection was a red herring,
the problem is caused by some change in Qemu and not by something in the Xen 
tree.
(strange thing is that for as far as i know i did a "make distclean" between 
every build (taking a lot of time), which should have pulled a fresh qemu-xen 
tree and therefor the bisection should have lead to a commit with a Config.mk 
hash change for qemu-xen version.)

Will see if i can find some more time and bisect qemu and find the culprit.

--
Sander


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

Re: [Xen-devel] [PATCH] flask: add gcov_op check

[Konrad Rzeszutek Wilk]

On Thu, Oct 13, 2016 at 03:37:13PM +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu 
> ---
> Cc: Daniel De Graaf 
> Cc: Konrad Rzeszutek Wilk 

Reviewed-by: Konrad Rzeszutek Wilk 
> ---
>  tools/flask/policy/modules/dom0.te  | 2 +-
>  xen/xsm/flask/hooks.c   | 3 +++
>  xen/xsm/flask/policy/access_vectors | 2 ++
>  3 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/flask/policy/modules/dom0.te 
> b/tools/flask/policy/modules/dom0.te
> index 2d982d9..54c3572 100644
> --- a/tools/flask/policy/modules/dom0.te
> +++ b/tools/flask/policy/modules/dom0.te
> @@ -15,7 +15,7 @@ allow dom0_t xen_t:xen {
>  };
>  allow dom0_t xen_t:xen2 {
>   resource_op psr_cmt_op psr_cat_op pmu_ctrl get_symbol
> - get_cpu_levelling_caps get_cpu_featureset livepatch_op
> + get_cpu_levelling_caps get_cpu_featureset livepatch_op gcov_op
>  };
>  
>  # Allow dom0 to use all XENVER_ subops that have checks.
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 177c11f..040a251 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -822,6 +822,9 @@ static int flask_sysctl(int cmd)
>  case XEN_SYSCTL_livepatch_op:
>  return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
>  XEN2__LIVEPATCH_OP, NULL);
> +case XEN_SYSCTL_gcov_op:
> +return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
> +XEN2__GCOV_OP, NULL);
>  
>  default:
>  return avc_unknown_permission("sysctl", cmd);
> diff --git a/xen/xsm/flask/policy/access_vectors 
> b/xen/xsm/flask/policy/access_vectors
> index 49c9a9e..92e6da9 100644
> --- a/xen/xsm/flask/policy/access_vectors
> +++ b/xen/xsm/flask/policy/access_vectors
> @@ -99,6 +99,8 @@ class xen2
>  get_cpu_featureset
>  # XEN_SYSCTL_livepatch_op
>  livepatch_op
> +# XEN_SYSCTL_gcov_op
> +gcov_op
>  }
>  
>  # Classes domain and domain2 consist of operations that a domain performs on
> -- 
> 2.1.4
> 

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

[Xen-devel] [PATCH] flask: add gcov_op check

[Wei Liu]

Signed-off-by: Wei Liu 
---
Cc: Daniel De Graaf 
Cc: Konrad Rzeszutek Wilk 
---
 tools/flask/policy/modules/dom0.te  | 2 +-
 xen/xsm/flask/hooks.c   | 3 +++
 xen/xsm/flask/policy/access_vectors | 2 ++
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/modules/dom0.te 
b/tools/flask/policy/modules/dom0.te
index 2d982d9..54c3572 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -15,7 +15,7 @@ allow dom0_t xen_t:xen {
 };
 allow dom0_t xen_t:xen2 {
resource_op psr_cmt_op psr_cat_op pmu_ctrl get_symbol
-   get_cpu_levelling_caps get_cpu_featureset livepatch_op
+   get_cpu_levelling_caps get_cpu_featureset livepatch_op gcov_op
 };
 
 # Allow dom0 to use all XENVER_ subops that have checks.
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 177c11f..040a251 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -822,6 +822,9 @@ static int flask_sysctl(int cmd)
 case XEN_SYSCTL_livepatch_op:
 return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
 XEN2__LIVEPATCH_OP, NULL);
+case XEN_SYSCTL_gcov_op:
+return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
+XEN2__GCOV_OP, NULL);
 
 default:
 return avc_unknown_permission("sysctl", cmd);
diff --git a/xen/xsm/flask/policy/access_vectors 
b/xen/xsm/flask/policy/access_vectors
index 49c9a9e..92e6da9 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -99,6 +99,8 @@ class xen2
 get_cpu_featureset
 # XEN_SYSCTL_livepatch_op
 livepatch_op
+# XEN_SYSCTL_gcov_op
+gcov_op
 }
 
 # Classes domain and domain2 consist of operations that a domain performs on
-- 
2.1.4


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

Re: [Xen-devel] [PATCHv1 net] xen-netback: fix guest Rx stall detection (after guest Rx refactor)

[David Miller]

From: David Vrabel 
Date: Tue, 11 Oct 2016 16:48:27 +0100

> If a VIF has been ready for rx_stall_timeout (60s by default) and an
> Rx ring is drained of all requests an Rx stall will be incorrectly
> detected.  When this occurs and the guest Rx queue is empty, the Rx
> ring's event index will not be set and the frontend will not raise an
> event when new requests are placed on the ring, permanently stalling
> the VIF.
> 
> This is a regression introduced by eb1723a29b9a7 (xen-netback:
> refactor guest rx).
> 
> Fix this by reinstating the setting of queue->last_rx_time when
> placing a packet onto the guest Rx ring.
> 
> Signed-off-by: David Vrabel 

Applied.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  7 host-ping-check-xen  fail REGR. vs. 101365
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 101365

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 101365
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101365
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101365
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101365

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuuc264a8807299852fc45562768ae60ccc886cea91
baseline version:
 qemuu627eae7d729277c84f8e0ac07a8caab39c92c38d

Last test of basis   101365  2016-10-11 02:21:11 Z2 days
Failing since101395  2016-10-12 10:15:00 Z1 days2 attempts
Testing same since   101411  2016-10-13 02:15:32 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Eric Blake 
  Gerd Hoffmann 
  Hans de Goede 
  Lluís Vilanova 
  P J P 
  Peter Maydell 
  Stefan Hajnoczi 
  Vijay Kumar B 
  Vijay Kumar B. 

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-pvops

Re: [Xen-devel] [PATCH net] xen-netback: (re-)create a debugfs node for hash information

[David Miller]

From: Paul Durrant 
Date: Mon, 10 Oct 2016 09:30:53 +0100

> From: Paul Durrant 
> 
> It is useful to be able to see the hash configuration when running tests.
> This patch adds a debugfs node for that purpose.
> 
> The original version of this patch (commit c0c64c152389) was reverted due
> to build failures caused by a conflict with commit 0364a8824c02
> ("xen-netback: switch to threaded irq for control ring"). This new version
> of the patch is nearly identical to the original, the only difference
> being that creation of the debugfs node is predicated on 'ctrl_irq' being
> non-zero rather then the now non-existent 'ctrl_task'.
> 
> Signed-off-by: Paul Durrant 

Applied.

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

[Xen-devel] [PATCH v2 1/2] x86/vmx: Print the problematic MSR if a vmentry fails

[Andrew Cooper]

Sample error looks like:

  (XEN) Failed vm entry (exit reason 0x8022) caused by MSR loading (entry 
13).
  (XEN)   msr 068a, val 1fff80102af0, (mbz 0)
  (XEN) * VMCS Area **

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
---
CC: Jun Nakajima 
CC: Kevin Tian 

v2:
 * const, %lu, remove some commas, boundary check
---
 xen/arch/x86/hvm/vmx/vmx.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index b9102ce..b406989 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3104,8 +3104,23 @@ static void vmx_failed_vmentry(unsigned int exit_reason,
 printk("caused by invalid guest state (%ld).\n", exit_qualification);
 break;
 case EXIT_REASON_MSR_LOADING:
-printk("caused by MSR entry %ld loading.\n", exit_qualification);
+{
+unsigned long idx = exit_qualification - 1;
+const struct vmx_msr_entry *msr;
+
+printk("caused by MSR loading (entry %lu).\n", idx);
+
+if ( idx >= (PAGE_SIZE / sizeof(*msr)) )
+printk("  Entry out of range\n");
+else
+{
+msr = >arch.hvm_vmx.msr_area[idx];
+
+printk("  msr %08x val %016"PRIx64" (mbz %#x)\n",
+   msr->index, msr->data, msr->mbz);
+}
 break;
+}
 case EXIT_REASON_MCE_DURING_VMENTRY:
 printk("caused by machine check.\n");
 HVMTRACE_0D(MCE);
-- 
2.1.4


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

[Xen-devel] [PATCH v2 2/2] x86/vmx: Reduce the verbosity of the vmentry failure error reporting

[Andrew Cooper]

Identify the affected vcpu at the start of the message.  While tweaking this
area, add extra newlines between cases.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
---
CC: Jun Nakajima 
CC: Kevin Tian 

v2:
 * %lu
---
 xen/arch/x86/hvm/vmx/vmx.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index b406989..db12cdb 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3096,19 +3096,20 @@ static void vmx_failed_vmentry(unsigned int exit_reason,
 unsigned long exit_qualification;
 struct vcpu *curr = current;
 
-printk("Failed vm entry (exit reason %#x) ", exit_reason);
+printk("%pv vmentry failure (reason %#x): ", curr, exit_reason);
 __vmread(EXIT_QUALIFICATION, _qualification);
 switch ( failed_vmentry_reason )
 {
 case EXIT_REASON_INVALID_GUEST_STATE:
-printk("caused by invalid guest state (%ld).\n", exit_qualification);
+printk("Invalid guest state (%lu)\n", exit_qualification);
 break;
+
 case EXIT_REASON_MSR_LOADING:
 {
 unsigned long idx = exit_qualification - 1;
 const struct vmx_msr_entry *msr;
 
-printk("caused by MSR loading (entry %lu).\n", idx);
+printk("MSR loading (entry %lu)\n", idx);
 
 if ( idx >= (PAGE_SIZE / sizeof(*msr)) )
 printk("  Entry out of range\n");
@@ -3121,13 +3122,15 @@ static void vmx_failed_vmentry(unsigned int exit_reason,
 }
 break;
 }
+
 case EXIT_REASON_MCE_DURING_VMENTRY:
-printk("caused by machine check.\n");
+printk("MCE\n");
 HVMTRACE_0D(MCE);
 /* Already handled. */
 break;
+
 default:
-printk("reason not known yet!");
+printk("Unknown\n");
 break;
 }
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v4 1/2] gcov: add new interface and new formats support

[Konrad Rzeszutek Wilk]

> diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
> index 93f107c..2f64bb5 100644
> --- a/xen/common/sysctl.c
> +++ b/xen/common/sysctl.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
>  {
> @@ -395,6 +396,13 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
> u_sysctl)
>  }
>  break;
>  
> +#ifdef CONFIG_GCOV
> +case XEN_SYSCTL_gcov_op:
> +ret = sysctl_gcov_op(>u.gcov_op);
> +copyback = 1;
> +break;
> +#endif

Should there be an XSM entry in flask_sysctl for this?
And also in flask/policy/access_vectors

And in tools/flask/policy/policy.conf

Maybe that should be a seperate patch?

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

Re: [Xen-devel] [PATCH v4 1/2] gcov: add new interface and new formats support

[Wei Liu]

On Thu, Oct 13, 2016 at 09:38:45AM -0400, Konrad Rzeszutek Wilk wrote:
> > diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
> > index 93f107c..2f64bb5 100644
> > --- a/xen/common/sysctl.c
> > +++ b/xen/common/sysctl.c
> > @@ -28,6 +28,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
> >  {
> > @@ -395,6 +396,13 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
> > u_sysctl)
> >  }
> >  break;
> >  
> > +#ifdef CONFIG_GCOV
> > +case XEN_SYSCTL_gcov_op:
> > +ret = sysctl_gcov_op(>u.gcov_op);
> > +copyback = 1;
> > +break;
> > +#endif
> 
> Should there be an XSM entry in flask_sysctl for this?
> And also in flask/policy/access_vectors
> 
> And in tools/flask/policy/policy.conf
> 
> Maybe that should be a seperate patch?

Yes. That's planned. Didn't want to cram in too much stuff in one single
patch.

Wei.

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

Re: [Xen-devel] [PATCH v3 for-4.8] libelf: fix symtab/strtab loading for 32bit domains

[Andrew Cooper]

On 13/10/16 13:48, Roger Pau Monne wrote:
> diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
> index 90bd8cb..70abbaf 100644
> --- a/xen/include/xen/libelf.h
> +++ b/xen/include/xen/libelf.h
> @@ -432,6 +432,16 @@ struct elf_dom_parms {
>  uint64_t virt_kend;
>  };
>  
> +/* Number of section header needed in order to fit the SYMTAB and STRTAB. */
> +#define ELF_BSDSYM_SECTIONS 3
> +struct elf_sym_header {
> +uint32_t size;
> +struct {
> +elf_ehdr header;
> +elf_shdr section[ELF_BSDSYM_SECTIONS];
> +} elf_header;
> +} __attribute__((packed));

__packed please, rather than opencoding it.  Also, should be between
struct and the structure name.

~Andrew

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

Re: [Xen-devel] [PATCH] x86emul: honor MXCSR.MM

[Andrew Cooper]

On 13/10/16 13:57, Jan Beulich wrote:
> Commit 6dc9ac9f52 ("x86emul: check alignment of SSE and AVX memory
> operands") didn't consider a specific AMD mode: Mis-alignment #GP
> faults can be masked on some of their hardware.
>
> Signed-off-by: Jan Beulich 

This highlights that the following CPUID dependency change is also required

diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
index 33e68eb..e803654 100755
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -185,8 +185,9 @@ def crunch_numbers(state):
 # the first place.
 APIC: [X2APIC],
 
-# AMD built MMXExtentions and 3DNow as extentions to MMX.
-MMX: [MMXEXT, _3DNOW],
+# AMD built MMXExtentions, 3DNow and SSE Misalignment as
extensions to
+# MMX.
+MMX: [MMXEXT, _3DNOW, MISALIGNSSE],
 
 # The FXSAVE/FXRSTOR instructions were introduced into hardware
before
 # SSE, which is why they behave differently based on
%CR4.OSFXSAVE and



>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -446,6 +446,9 @@ typedef union {
>  #define EFLG_PF   (1<<2)
>  #define EFLG_CF   (1<<0)
>  
> +/* MXCSR bit definitions. */
> +#define MXCSR_MM  (1U << 17)
> +
>  /* Exception definitions. */
>  #define EXC_DE  0
>  #define EXC_DB  1
> @@ -1253,6 +1256,7 @@ static bool_t vcpu_has(
>  
>  #define vcpu_has_clflush() vcpu_has(   1, EDX, 19, ctxt, ops)
>  #define vcpu_has_lzcnt() vcpu_has(0x8001, ECX,  5, ctxt, ops)
> +#define vcpu_has_misalignsse() vcpu_has(0x8001, ECX, 7, ctxt, ops)
>  #define vcpu_has_bmi1()  vcpu_has(0x0007, EBX,  3, ctxt, ops)
>  #define vcpu_has_hle()   vcpu_has(0x0007, EBX,  4, ctxt, ops)
>  #define vcpu_has_rtm()   vcpu_has(0x0007, EBX, 11, ctxt, ops)
> @@ -4675,7 +4679,13 @@ x86_emulate(
>  ea.bytes = vex.pfx & VEX_PREFIX_DOUBLE_MASK ? 8 : 4;
>  if ( ea.type == OP_MEM )
>  {
> -generate_exception_if((b >= 0x28) &&
> +uint32_t mxcsr = 0;
> +
> +if ( b < 0x28 )
> +mxcsr = MXCSR_MM;
> +else if ( vcpu_has_misalignsse() )
> +asm ( "stmxcsr %0" : "=m" (mxcsr) );
> +generate_exception_if(!(mxcsr & MXCSR_MM) &&
>!is_aligned(ea.mem.seg, ea.mem.off, 
> ea.bytes,
>ctxt, ops),
>EXC_GP, 0);
> @@ -4955,7 +4965,13 @@ x86_emulate(
>  }
>  if ( ea.type == OP_MEM )
>  {
> -generate_exception_if((vex.pfx == vex_66) &&
> +uint32_t mxcsr = 0;
> +
> +if ( vex.pfx != vex_66 )
> +mxcsr = MXCSR_MM;
> +else if ( vcpu_has_misalignsse() )
> +asm ( "stmxcsr %0" : "=m" (mxcsr) );
> +generate_exception_if(!(mxcsr & MXCSR_MM) &&
>!is_aligned(ea.mem.seg, ea.mem.off, 
> ea.bytes,
>ctxt, ops),
>EXC_GP, 0);

According to the docs, we should also be possibly raising #AC here.

~Andrew

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

Re: [Xen-devel] [PATCH 1/3] docs: Credit1 feature document.

[Dario Faggioli]

On Thu, 2016-10-13 at 12:47 +0100, Andrew Cooper wrote:
> On 13/10/16 12:02, Dario Faggioli wrote:
> > 
> > diff --git a/docs/features/credit.pandoc
> > b/docs/features/credit.pandoc
> > new file mode 100644
> > index 000..fed0da2
> > --- /dev/null
> > +++ b/docs/features/credit.pandoc
> 
> Simply "Credit" as a top level feature isn't very descriptive.  Can
> you
> see about working scheduler somewhere into the name?
> 
Yep, I wasn't sure whether or not to do that. Re-thinking things, I
agree that'd be better. I'll do.

> > @@ -0,0 +1,99 @@
> > +% Credit
> > +% Revision 1
> > +
> > +\clearpage
> > +
> > +# Basics
> > + ---
> > -
> > + Status: e.g. **Supported**
> > +
> > +Architecture(s): e.g. x86, arm
> > +
> > +  Component: e.g. Hypervisor
> > + ---
> > -
> 
> You should drop the e.g.'s.  
>
Which I was sure I'd have done... sorry.

> In cases like this where it really is just
> a software algorithm, I would suggest setting the architecture to
> all,
> or omitting the line entirely.  
>
Omitting the line is what I also was considering myself. Again, will
do.

> > +# Overview
> > +
> > +Credit (also known as Credit1) is the default virtual CPU (vCPU)
> > scheduler
> > +of the Xen hypervisor. The job of an hypervisor's scheduler is to
> > decide,
> > +among all the various vCPUs of the various virtual machines, which
> > ones
> > +should execute on the host's physical CPUs (pCPUs), at any given
> > point in
> > +time.
> 
> A lot of this is generic to all schedulers.
> 
Not really. Well, sure some is, but, at the end, this period is pretty
much the only one that is present, identical to itself, in all the
three documents (and I certainly can see about shortening or removing
it, if we don't want that).


And in fact, the rest...

> I wonder whether it might be better to have a schedulers meta-feature
> doc which deals with the common scheduler parts, including
> interactions
> on the Xen command line, xl, etc.
> 
...may look similar, but they're subtle differences spread around. And
the more subtle those differences, the higher the amount of cross-
referencing between different documents would be, making it more
difficult to read and understand what the situation is for one specific
scheduler.

xl interface is a good example: sub-commands are very similar, but then
the scheduling parameters are different for each scheduler.

The way in which you create a cpupool is the same (modulo the name=""),
but doesn't necessarily have to be, e.g., if we start allowing
specifing some of the global parameters of the scheduler on the command
line (e.g., "create a Credit cpupool, but with timeslice=10"). Not
possible right now, but doable, and even convenient (I've already have
plans for that :-P).

So, FWIW, I would stick with different documents.

> > +Once the system is live, for creating a cpupool with Credit as its
> > +scheduler, either compile a cpupool configuration file, as
> > described
> > +in `docs/man/xlcpupool.cfg.pod.5` (and as exemplified in
> > +`tools/examples/cpupool`), or use just `xl` directly:
> 
> I should see about ensuring that cross-references work with the
> HTML-generated versions of these docs.  You might be able to get away
> with just putting in a plain hyperlink here.
> 
I thought about that, but then ended up following suit from your
docs/feature/migration.pandoc.

I'll turn this in links if that's what you think is best. Personally, I
's say it makes the _text_ document a bit less readable, but I guess
the version we care about is the _HTML_ one?

Anyway, I'm basically ok with anything. :-)

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

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

Re: [Xen-devel] [PATCH v4 1/2] gcov: add new interface and new formats support

[Wei Liu]

On Thu, Oct 13, 2016 at 07:05:21AM -0600, Jan Beulich wrote:
> >>> On 13.10.16 at 14:04,  wrote:
> > A new sysctl interface for passing gcov data back to userspace. The new
> > interface uses a customised record file format. The new sysctl reuses
> > original sysctl number but renames the op to gcov_op.
> > 
> > Formats starting from gcc version 3.4 are supported. The code is
> > rewritten so that a new format can be easily added in the future.
> > Version specific code is grouped into different files. The format one
> > needs to use can be picked via Kconfig. The default format is the newest
> > one.
> > 
> > Userspace programs to handle extracted data will come in a later patch.
> > 
> > Signed-off-by: Wei Liu 
> 
> Acked-by: Jan Beulich 
> with one suggestion and one further adjustment:
> 
> > --- /dev/null
> > +++ b/xen/common/gcov/gcc_4_9.c
> > @@ -0,0 +1,35 @@
> > +/*
> > + *  This code provides functions to handle gcc's profiling data format
> > + *  introduced with gcc 4.7.
> > + *
> > + *  This file is based heavily on gcc_3_4.c file.
> 
> I think this is not really applicable here and in gcc_5.c.

OK. I will delete this.

> 
> > + *
> > + *  For a better understanding, refer to gcc source:
> > + *  gcc/gcov-io.h
> > + *  libgcc/libgcov.c
> > + *
> > + *  Uses gcc-internal data definitions.
> > + *
> > + *  Imported from Linux and modified for Xen by
> > + *Wei Liu 
> > + */
> > +
> > +#include "gcov.h"
> > +
> > +#if !(GCC_VERSION >= 40900 && GCC_VERSION < 50100)
> 
> This wants to be 5 now on the right side, afaict.
> 

Right. I missed this one place. I will fix it.

Thanks for your careful review.

Wei.

> Jan
> 

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

Re: [Xen-devel] [PATCH v3 for-4.8] libelf: fix symtab/strtab loading for 32bit domains

[Jan Beulich]

>>> On 13.10.16 at 14:48,  wrote:
> @@ -174,8 +171,8 @@ void elf_parse_bsdsyms(struct elf_binary *elf, uint64_t 
> pstart)
>  /* Space to store the size of the elf image */
>  sz = sizeof(uint32_t);
>  
> -/* Space for the elf and elf section headers */
> -sz += elf_uval(elf, elf->ehdr, e_ehsize) +
> +/* Space for the elf header and elf section headers */
> +sz += offsetof(struct elf_sym_header, elf_header.section) +
>ELF_BSDSYM_SECTIONS * elf_uval(elf, elf->ehdr, e_shentsize);

You've retained the inconsistency which I had asked to eliminate
when commenting on v2.

> --- a/xen/include/xen/libelf.h
> +++ b/xen/include/xen/libelf.h
> @@ -432,6 +432,16 @@ struct elf_dom_parms {
>  uint64_t virt_kend;
>  };
>  
> +/* Number of section header needed in order to fit the SYMTAB and STRTAB. */
> +#define ELF_BSDSYM_SECTIONS 3
> +struct elf_sym_header {
> +uint32_t size;
> +struct {
> +elf_ehdr header;
> +elf_shdr section[ELF_BSDSYM_SECTIONS];
> +} elf_header;
> +} __attribute__((packed));

This doesn't belong here - it's still an internal structure. At most this
might go into libelf-private.h, but I think best would be to keep in the
C file, just moving it up (and out of any function) there. And if you
were to move it into _any_ header, the comment would need
adjustment to make clear what part of the loader this actually is
relevant for.

Jan


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

Re: [Xen-devel] [PATCH v4 2/2] gcov: provide the capability to select gcov format automatically

[Jan Beulich]

>>> On 13.10.16 at 14:04,  wrote:
> And make it the default in Kconfig.
> 
> Signed-off-by: Wei Liu 
> ---
> v4: dropped Jan's ack

Feel free to re-instate.

Jan


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

Re: [Xen-devel] [PATCH v4 1/2] gcov: add new interface and new formats support

[Jan Beulich]

>>> On 13.10.16 at 14:04,  wrote:
> A new sysctl interface for passing gcov data back to userspace. The new
> interface uses a customised record file format. The new sysctl reuses
> original sysctl number but renames the op to gcov_op.
> 
> Formats starting from gcc version 3.4 are supported. The code is
> rewritten so that a new format can be easily added in the future.
> Version specific code is grouped into different files. The format one
> needs to use can be picked via Kconfig. The default format is the newest
> one.
> 
> Userspace programs to handle extracted data will come in a later patch.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 
with one suggestion and one further adjustment:

> --- /dev/null
> +++ b/xen/common/gcov/gcc_4_9.c
> @@ -0,0 +1,35 @@
> +/*
> + *  This code provides functions to handle gcc's profiling data format
> + *  introduced with gcc 4.7.
> + *
> + *  This file is based heavily on gcc_3_4.c file.

I think this is not really applicable here and in gcc_5.c.

> + *
> + *  For a better understanding, refer to gcc source:
> + *  gcc/gcov-io.h
> + *  libgcc/libgcov.c
> + *
> + *  Uses gcc-internal data definitions.
> + *
> + *  Imported from Linux and modified for Xen by
> + *Wei Liu 
> + */
> +
> +#include "gcov.h"
> +
> +#if !(GCC_VERSION >= 40900 && GCC_VERSION < 50100)

This wants to be 5 now on the right side, afaict.

Jan

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

[Xen-devel] [PATCH] x86emul: honor MXCSR.MM

[Jan Beulich]

Commit 6dc9ac9f52 ("x86emul: check alignment of SSE and AVX memory
operands") didn't consider a specific AMD mode: Mis-alignment #GP
faults can be masked on some of their hardware.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -446,6 +446,9 @@ typedef union {
 #define EFLG_PF   (1<<2)
 #define EFLG_CF   (1<<0)
 
+/* MXCSR bit definitions. */
+#define MXCSR_MM  (1U << 17)
+
 /* Exception definitions. */
 #define EXC_DE  0
 #define EXC_DB  1
@@ -1253,6 +1256,7 @@ static bool_t vcpu_has(
 
 #define vcpu_has_clflush() vcpu_has(   1, EDX, 19, ctxt, ops)
 #define vcpu_has_lzcnt() vcpu_has(0x8001, ECX,  5, ctxt, ops)
+#define vcpu_has_misalignsse() vcpu_has(0x8001, ECX, 7, ctxt, ops)
 #define vcpu_has_bmi1()  vcpu_has(0x0007, EBX,  3, ctxt, ops)
 #define vcpu_has_hle()   vcpu_has(0x0007, EBX,  4, ctxt, ops)
 #define vcpu_has_rtm()   vcpu_has(0x0007, EBX, 11, ctxt, ops)
@@ -4675,7 +4679,13 @@ x86_emulate(
 ea.bytes = vex.pfx & VEX_PREFIX_DOUBLE_MASK ? 8 : 4;
 if ( ea.type == OP_MEM )
 {
-generate_exception_if((b >= 0x28) &&
+uint32_t mxcsr = 0;
+
+if ( b < 0x28 )
+mxcsr = MXCSR_MM;
+else if ( vcpu_has_misalignsse() )
+asm ( "stmxcsr %0" : "=m" (mxcsr) );
+generate_exception_if(!(mxcsr & MXCSR_MM) &&
   !is_aligned(ea.mem.seg, ea.mem.off, ea.bytes,
   ctxt, ops),
   EXC_GP, 0);
@@ -4955,7 +4965,13 @@ x86_emulate(
 }
 if ( ea.type == OP_MEM )
 {
-generate_exception_if((vex.pfx == vex_66) &&
+uint32_t mxcsr = 0;
+
+if ( vex.pfx != vex_66 )
+mxcsr = MXCSR_MM;
+else if ( vcpu_has_misalignsse() )
+asm ( "stmxcsr %0" : "=m" (mxcsr) );
+generate_exception_if(!(mxcsr & MXCSR_MM) &&
   !is_aligned(ea.mem.seg, ea.mem.off, ea.bytes,
   ctxt, ops),
   EXC_GP, 0);



x86emul: honor MXCSR.MM

Commit 6dc9ac9f52 ("x86emul: check alignment of SSE and AVX memory
operands") didn't consider a specific AMD mode: Mis-alignment #GP
faults can be masked on some of their hardware.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -446,6 +446,9 @@ typedef union {
 #define EFLG_PF   (1<<2)
 #define EFLG_CF   (1<<0)
 
+/* MXCSR bit definitions. */
+#define MXCSR_MM  (1U << 17)
+
 /* Exception definitions. */
 #define EXC_DE  0
 #define EXC_DB  1
@@ -1253,6 +1256,7 @@ static bool_t vcpu_has(
 
 #define vcpu_has_clflush() vcpu_has(   1, EDX, 19, ctxt, ops)
 #define vcpu_has_lzcnt() vcpu_has(0x8001, ECX,  5, ctxt, ops)
+#define vcpu_has_misalignsse() vcpu_has(0x8001, ECX, 7, ctxt, ops)
 #define vcpu_has_bmi1()  vcpu_has(0x0007, EBX,  3, ctxt, ops)
 #define vcpu_has_hle()   vcpu_has(0x0007, EBX,  4, ctxt, ops)
 #define vcpu_has_rtm()   vcpu_has(0x0007, EBX, 11, ctxt, ops)
@@ -4675,7 +4679,13 @@ x86_emulate(
 ea.bytes = vex.pfx & VEX_PREFIX_DOUBLE_MASK ? 8 : 4;
 if ( ea.type == OP_MEM )
 {
-generate_exception_if((b >= 0x28) &&
+uint32_t mxcsr = 0;
+
+if ( b < 0x28 )
+mxcsr = MXCSR_MM;
+else if ( vcpu_has_misalignsse() )
+asm ( "stmxcsr %0" : "=m" (mxcsr) );
+generate_exception_if(!(mxcsr & MXCSR_MM) &&
   !is_aligned(ea.mem.seg, ea.mem.off, ea.bytes,
   ctxt, ops),
   EXC_GP, 0);
@@ -4955,7 +4965,13 @@ x86_emulate(
 }
 if ( ea.type == OP_MEM )
 {
-generate_exception_if((vex.pfx == vex_66) &&
+uint32_t mxcsr = 0;
+
+if ( vex.pfx != vex_66 )
+mxcsr = MXCSR_MM;
+else if ( vcpu_has_misalignsse() )
+asm ( "stmxcsr %0" : "=m" (mxcsr) );
+generate_exception_if(!(mxcsr & MXCSR_MM) &&
   !is_aligned(ea.mem.seg, ea.mem.off, ea.bytes,
   ctxt, ops),
   EXC_GP, 0);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 for-4.8] libelf: fix symtab/strtab loading for 32bit domains

[Roger Pau Monne]

Commit ed04ca introduced a bug in the symtab/strtab loading for 32bit
guests, that corrupted the section headers array due to the padding
introduced by the elf_shdr union.

The Elf section header array on 32bit should be accessible as an array of
Elf32_Shdr elements, and the union with Elf64_Shdr done in elf_shdr was
breaking this due to size differences between Elf32_Shdr and Elf64_Shdr.

Fix this by copying each section header one by one, and using the proper
size depending on the bitness of the guest kernel. While there, also fix
elf_parse_bsdsyms so that it takes into account the size of the elf_ehdr
struct instead of the native Elf header size.

Reported-by: Brian Marcotte 
Signed-off-by: Roger Pau Monné 
Acked-by: Ian Jackson 
---
Cc: Brian Marcotte 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Should be backported to Xen 4.7 stable branch.
---
Changes since v2:
 - Use offsetof to correctly account for the memory used by the elf header.

Changes since v1:
 - No need to calculate shdr_size again, it's already fetched from the
   original elf header.
 - Remove shdr variable.
 - Use offsetof instead of subtracting two sizeofs.
 - Fix elf_parse_bsdsyms so that it takes into account the size of elf_ehdr
   instead of the size of the native elf header.
---
 xen/common/libelf/libelf-loader.c | 44 ---
 xen/include/xen/libelf.h  | 10 +
 2 files changed, 37 insertions(+), 17 deletions(-)

diff --git a/xen/common/libelf/libelf-loader.c 
b/xen/common/libelf/libelf-loader.c
index 2626a40..3a83d61 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -21,9 +21,6 @@
 
 #include "libelf-private.h"
 
-/* Number of section header needed in order to fit the SYMTAB and STRTAB. */
-#define ELF_BSDSYM_SECTIONS 3
-
 /*  */
 
 elf_errorstatus elf_init(struct elf_binary *elf, const char *image_input, 
size_t size)
@@ -174,8 +171,8 @@ void elf_parse_bsdsyms(struct elf_binary *elf, uint64_t 
pstart)
 /* Space to store the size of the elf image */
 sz = sizeof(uint32_t);
 
-/* Space for the elf and elf section headers */
-sz += elf_uval(elf, elf->ehdr, e_ehsize) +
+/* Space for the elf header and elf section headers */
+sz += offsetof(struct elf_sym_header, elf_header.section) +
   ELF_BSDSYM_SECTIONS * elf_uval(elf, elf->ehdr, e_shentsize);
 sz = elf_round_up(elf, sz);
 
@@ -253,18 +250,11 @@ static void elf_load_bsdsyms(struct elf_binary *elf)
  * strtab, so we only need three section headers in our fake ELF
  * header (first section header is always the undefined section).
  */
-struct {
-uint32_t size;
-struct {
-elf_ehdr header;
-elf_shdr section[ELF_BSDSYM_SECTIONS];
-} __attribute__((packed)) elf_header;
-} __attribute__((packed)) header;
-
+struct elf_sym_header header;
 ELF_HANDLE_DECL(elf_ehdr) header_handle;
-unsigned long shdr_size;
+unsigned long shdr_size, ehdr_size;
 ELF_HANDLE_DECL(elf_shdr) section_handle;
-unsigned int link, rc;
+unsigned int link, rc, i;
 elf_ptrval header_base;
 elf_ptrval elf_header_base;
 elf_ptrval symtab_base;
@@ -394,15 +384,35 @@ do {  
  \
 header.size = strtab_base + elf_uval(elf, section_handle, sh_size) -
   elf_header_base;
 
-/* Load the headers. */
+/* Load the size plus elf header. */
+ehdr_size = offsetof(typeof(header), elf_header.section);
 rc = elf_load_image(elf, header_base, ELF_REALPTR2PTRVAL(),
-sizeof(header), sizeof(header));
+ehdr_size, ehdr_size);
 if ( rc != 0 )
 {
 elf_mark_broken(elf, "unable to load ELF headers into guest memory");
 return;
 }
 
+/*
+ * Load the section headers.
+ *
+ * NB: this _must_ be done one by one, and taking the bitness into account,
+ * so that the guest can treat this as an array of type Elf{32/64}_Shdr.
+ */
+for ( i = 0; i < ELF_BSDSYM_SECTIONS; i++ )
+{
+rc = elf_load_image(elf, header_base + ehdr_size + shdr_size * i,
+ELF_REALPTR2PTRVAL(_header.section[i]),
+shdr_size, shdr_size);
+if ( rc != 0 )
+{
+elf_mark_broken(elf,
+"unable to load ELF section header into guest memory");
+return;
+}
+}
+
 /* Remove 

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

[Wei Liu]

On Thu, Oct 13, 2016 at 01:44:28PM +0100, Dario Faggioli wrote:
> On Thu, 2016-10-13 at 12:28 +0100, Andrew Cooper wrote:
> > On 13/10/16 12:01, Dario Faggioli wrote:
> > > "Just" as per the subject, I wrote feature documents for (almost)
> > > all our
> > > schedulers. No big deal, I'd say, apart from the fact that I'm
> > > declaring
> > > Credit2 **Supperted**, instead of experimental.
> > 
> > Supperted?  That's like supported right? ;p
> > 
> Nah, 'supperted' is the new 'supported', didn't you know? :-P
> 
> > It is fine for you to propose that a feature should be upgraded to
> > supported, and this is probably the best way to formally do so.
> > 
> > However, final agreement of a feature becoming supported should
> > include
> > input from the security team. (At the end of the day, it is us with
> > extra work if the feature isn't up to scratch.)
> > 
> Ok, so, if that's the case, what's the process: resend (this patch) --
> or some other kind of formal request-- with secur...@xenproject.org
> Cc-ed?
> 

If you want these to be applied more quickly the best thing to do is to
leave the status experimental and later send another patch with
security@ CC'ed to change the status.

Wei.

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



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

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

[Dario Faggioli]

On Thu, 2016-10-13 at 12:28 +0100, Andrew Cooper wrote:
> On 13/10/16 12:01, Dario Faggioli wrote:
> > "Just" as per the subject, I wrote feature documents for (almost)
> > all our
> > schedulers. No big deal, I'd say, apart from the fact that I'm
> > declaring
> > Credit2 **Supperted**, instead of experimental.
> 
> Supperted?  That's like supported right? ;p
> 
Nah, 'supperted' is the new 'supported', didn't you know? :-P

> It is fine for you to propose that a feature should be upgraded to
> supported, and this is probably the best way to formally do so.
> 
> However, final agreement of a feature becoming supported should
> include
> input from the security team. (At the end of the day, it is us with
> extra work if the feature isn't up to scratch.)
> 
Ok, so, if that's the case, what's the process: resend (this patch) --
or some other kind of formal request-- with secur...@xenproject.org
Cc-ed?

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

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

Re: [Xen-devel] [Xen-users] Xen 4.2.4 and 4.6 hangs

[George Dunlap]

BCC'ing xen-devel, since this is clearly a xen-users question at the moment.

On Mon, Oct 10, 2016 at 9:52 PM, Soumendu Satapathy
 wrote:
> Hi there,
>
>
>
> I am trying to install and boot xen.  I followed the following procedure.
> There was no errors while installation. But when I select the grub entry it
> hangs.
>
>
>
> The following is the steps I followed.
>
> yum -y install centos-release-xen
> yum --enablerepo=centos-virt-xen -y update kernel
> yum --enablerepo=centos-virt-xen -y install xen
> /bin/grub-bootxen.sh
> reboot
> xl info
>
>
>
>
>
> I also tried to compile the xen4.2.4 source code . I did the following..
>
>
>
> $ ./configure
>
> $ make world
>
> $ make install
>
>
>
> After the above steps completed without errors, I added an entry to the
> grub.cfg and booted but like the above it hangs. But I am able to select the
> linux kernel and it boots properly. In both I get the following and then the
> xen hangs…
>
>
>
> Loading Xen 4.6
>
> Loading Linux 
>
> Loading initial ramdisk …
>
>
>
>
>
>
>
> Is there any steps we are missing?

It's not 100% clear here -- did you get the same result (Grub says
it's booting Xen then hangs) for both the CentOS packages and your own
build?

It looks like you got grub to attempt to load Xen, so as far as that
goes it looks like you did OK.

But there's not nearly enough information in this report to move
forward, and it looks like you've actively removed some important
information. :-)

What Linux kernel version are you using?  What version of CentOS, and
what Xen packages?  What hardware is it running on?  What does your
grub config look like?  Do you have a serial console attached?  Are
you using encryted (LUKS) disks?

Thanks,

 -George

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

[Xen-devel] [PATCH v4 2/2] gcov: provide the capability to select gcov format automatically

[Wei Liu]

And make it the default in Kconfig.

Signed-off-by: Wei Liu 
---
v4: dropped Jan's ack

Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/Kconfig.debug| 9 -
 xen/common/gcov/Makefile | 4 
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index b19b357..8139564 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -39,10 +39,17 @@ config GCOV
 choice
prompt "Specify Gcov format"
depends on GCOV
-   default GCOV_FORMAT_5
+   default GCOV_FORMAT_AUTODETECT
---help---
  The gcov format is determined by gcc version.
 
+ If unsure, choose "Autodetect".
+
+config GCOV_FORMAT_AUTODETECT
+   bool "Autodetect"
+   ---help---
+ Automatically select gcov format based on gcc version.
+
 config GCOV_FORMAT_5
bool "GCC 5 format"
---help---
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
index 6a304ab..1b61357 100644
--- a/xen/common/gcov/Makefile
+++ b/xen/common/gcov/Makefile
@@ -3,3 +3,7 @@ obj-$(CONFIG_GCOV_FORMAT_3_4) += gcc_3_4.o
 obj-$(CONFIG_GCOV_FORMAT_4_7) += gcc_4_7.o
 obj-$(CONFIG_GCOV_FORMAT_4_9) += gcc_4_9.o
 obj-$(CONFIG_GCOV_FORMAT_5)   += gcc_5.o
+obj-$(CONFIG_GCOV_FORMAT_AUTODETECT) += $(call cc-ifversion,lt,0x040700, \
+   gcc_3_4.o, $(call 
cc-ifversion,lt,0x040900, \
+   gcc_4_7.o, $(call 
cc-ifversion,lt,0x05, \
+   gcc_4_9.o, gcc_5.o)))
-- 
2.1.4


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

[Xen-devel] [PATCH v4 1/2] gcov: add new interface and new formats support

[Wei Liu]

A new sysctl interface for passing gcov data back to userspace. The new
interface uses a customised record file format. The new sysctl reuses
original sysctl number but renames the op to gcov_op.

Formats starting from gcc version 3.4 are supported. The code is
rewritten so that a new format can be easily added in the future.
Version specific code is grouped into different files. The format one
needs to use can be picked via Kconfig. The default format is the newest
one.

Userspace programs to handle extracted data will come in a later patch.

Signed-off-by: Wei Liu 
---
v4:
1. gcov conflicts with livepatch in Kconfig.
2. Finer grain formats

v3:
1. Check gcc version in gcc_*.c files.
2. Eliminate u32 / u64.
3. Mark __gcov_init as __init.
4. Fix a rebase error in v2.
5. Some other cosmetic fixes.

v2:
1. Use tab in Kconfig and indent help text properly.
2. Bump XEN_SYSCTL_INTERFACE_VERSION.
3. Fix cosmetic issues.

Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/Kconfig.debug   |  39 -
 xen/common/gcov/Makefile|   5 +
 xen/common/gcov/gcc_3_4.c   | 367 
 xen/common/gcov/gcc_4_7.c   | 204 
 xen/common/gcov/gcc_4_9.c   |  35 +
 xen/common/gcov/gcc_5.c |  35 +
 xen/common/gcov/gcov.c  | 257 +++
 xen/common/gcov/gcov.h  |  40 +
 xen/common/gcov/gcov_base.c |  60 
 xen/common/sysctl.c |   8 +
 xen/include/public/sysctl.h |  39 -
 xen/include/xen/gcov.h  |   9 ++
 12 files changed, 1091 insertions(+), 7 deletions(-)
 create mode 100644 xen/common/gcov/gcc_3_4.c
 create mode 100644 xen/common/gcov/gcc_4_7.c
 create mode 100644 xen/common/gcov/gcc_4_9.c
 create mode 100644 xen/common/gcov/gcc_5.c
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/common/gcov/gcov.h
 create mode 100644 xen/common/gcov/gcov_base.c
 create mode 100644 xen/include/xen/gcov.h

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index ef863dc..b19b357 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -30,16 +30,45 @@ config FRAME_POINTER
 
 config GCOV
bool "Gcov Support"
-   depends on BROKEN
+   depends on !LIVEPATCH
---help---
  Enable gcov (a test coverage program in GCC) support.
 
- Currently the data structure and hypercall interface are tied
- to GCC 3.4 gcov format. You need to have a version of GCC
- that is compatible with that format to make gcov work.
-
  If unsure, say N here.
 
+choice
+   prompt "Specify Gcov format"
+   depends on GCOV
+   default GCOV_FORMAT_5
+   ---help---
+ The gcov format is determined by gcc version.
+
+config GCOV_FORMAT_5
+   bool "GCC 5 format"
+   ---help---
+ Select this option to use the format specified in GCC 5.
+ Works in gcc version range [5, ...).
+
+config GCOV_FORMAT_4_9
+   bool "GCC 4.9 format"
+   ---help---
+ Select this option to use the format specified in GCC 4.9.
+ Works in gcc version range [4.9, 5).
+
+config GCOV_FORMAT_4_7
+   bool "GCC 4.7 format"
+   ---help---
+ Select this option to use the format specified in GCC 4.7.
+ Works in gcc version range [4.7, 4.9).
+
+config GCOV_FORMAT_3_4
+   bool "GCC 3.4 format"
+   ---help---
+ Select this option to use the format specified in GCC 3.4.
+ Works in gcc version range [3.4, 4.7).
+
+endchoice
+
 config LOCK_PROFILE
bool "Lock Profiling"
---help---
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
index e69de29..6a304ab 100644
--- a/xen/common/gcov/Makefile
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,5 @@
+obj-y += gcov_base.o gcov.o
+obj-$(CONFIG_GCOV_FORMAT_3_4) += gcc_3_4.o
+obj-$(CONFIG_GCOV_FORMAT_4_7) += gcc_4_7.o
+obj-$(CONFIG_GCOV_FORMAT_4_9) += gcc_4_9.o
+obj-$(CONFIG_GCOV_FORMAT_5)   += gcc_5.o
diff --git a/xen/common/gcov/gcc_3_4.c b/xen/common/gcov/gcc_3_4.c
new file mode 100644
index 000..3631f4b
--- /dev/null
+++ b/xen/common/gcov/gcc_3_4.c
@@ -0,0 +1,367 @@
+/*
+ *  This code provides functions to handle gcc's profiling data format
+ *  introduced with gcc 3.4. Future versions of gcc may change the gcov
+ *  format (as happened before), so all format-specific information needs
+ *  to be kept modular and easily exchangeable.
+ *
+ *  This file is based on gcc-internal definitions. Functions and data
+ *  structures are defined to be compatible with gcc counterparts.
+ *  For a better understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *Copyright IBM Corp. 2009
+ *Author(s): Peter 

[Xen-devel] [PATCH v4 0/2] Rework gcov support in Xen

[Wei Liu]

Only sending out two patches.

This series can be found at:

git://xenbits.xen.org/people/liuw/xen.git wip.rework-gcov-v$VERSION

Wei.

---
v2: see individual commits for changes.

Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 

Wei Liu (2):
  gcov: add new interface and new formats support
  gcov: provide the capability to select gcov format automatically

 xen/Kconfig.debug   |  46 +-
 xen/common/gcov/Makefile|   9 ++
 xen/common/gcov/gcc_3_4.c   | 367 
 xen/common/gcov/gcc_4_7.c   | 204 
 xen/common/gcov/gcc_4_9.c   |  35 +
 xen/common/gcov/gcc_5.c |  35 +
 xen/common/gcov/gcov.c  | 257 +++
 xen/common/gcov/gcov.h  |  40 +
 xen/common/gcov/gcov_base.c |  60 
 xen/common/sysctl.c |   8 +
 xen/include/public/sysctl.h |  39 -
 xen/include/xen/gcov.h  |   9 ++
 12 files changed, 1102 insertions(+), 7 deletions(-)
 create mode 100644 xen/common/gcov/gcc_3_4.c
 create mode 100644 xen/common/gcov/gcc_4_7.c
 create mode 100644 xen/common/gcov/gcc_4_9.c
 create mode 100644 xen/common/gcov/gcc_5.c
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/common/gcov/gcov.h
 create mode 100644 xen/common/gcov/gcov_base.c
 create mode 100644 xen/include/xen/gcov.h

-- 
2.1.4


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

Re: [Xen-devel] [PATCH 1/2] x86/vmx: Print the problematic MSR if a vmentry fails

[Andrew Cooper]

On 13/10/16 12:38, Jan Beulich wrote:
 On 13.10.16 at 13:15,  wrote:
>> Sample error looks like:
>>
>>   (XEN) Failed vm entry (exit reason 0x8022) caused by MSR loading 
>> (entry 13).
>>   (XEN)   msr 068a, val 1fff80102af0, (mbz 0)
>>   (XEN) * VMCS Area **
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 
> with
>
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -3104,8 +3104,23 @@ static void vmx_failed_vmentry(unsigned int 
>> exit_reason,
>>  printk("caused by invalid guest state (%ld).\n", 
>> exit_qualification);
>>  break;
>>  case EXIT_REASON_MSR_LOADING:
>> -printk("caused by MSR entry %ld loading.\n", exit_qualification);
>> +{
>> +unsigned long idx = exit_qualification - 1;
>> +struct vmx_msr_entry *msr;
> ... preferably const here

Will do.

>  (and the declaration perhaps moved into
> the more narrow scope it's needed in), ...

Cant, due to its use in the sizeof() expression.  (I tried that first)

>
>> +printk("caused by MSR loading (entry %ld).\n", idx);
> ... %lu (plus ideally the full stop dropped) here, and ...

Ok for %lu.  The full stop is dealt with in the following patch, so will
leave this as-is for consistency of both patches.

>
>> +if ( idx > (PAGE_SIZE / sizeof(*msr)) )
> ... >= here.
>
>> +printk("  Entry out of range\n");
>> +else
>> +{
>> +msr = >arch.hvm_vmx.msr_area[idx];
>> +
>> +printk("  msr %08x, val %016"PRIx64", (mbz %#x)\n",
> I'm also unsure about the usefulness of the commas here - at least
> the second one seems a little strange with the value in parentheses.

Ok.

~Andrew

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

Re: [Xen-devel] [PATCH 1/3] docs: Credit1 feature document.

[Andrew Cooper]

On 13/10/16 12:02, Dario Faggioli wrote:
> diff --git a/docs/features/credit.pandoc b/docs/features/credit.pandoc
> new file mode 100644
> index 000..fed0da2
> --- /dev/null
> +++ b/docs/features/credit.pandoc

Simply "Credit" as a top level feature isn't very descriptive.  Can you
see about working scheduler somewhere into the name?

> @@ -0,0 +1,99 @@
> +% Credit
> +% Revision 1
> +
> +\clearpage
> +
> +# Basics
> + 
> + Status: e.g. **Supported**
> +
> +Architecture(s): e.g. x86, arm
> +
> +  Component: e.g. Hypervisor
> + 

You should drop the e.g.'s.  In cases like this where it really is just
a software algorithm, I would suggest setting the architecture to all,
or omitting the line entirely.  I would expect that any new architecture
is going gain all the schedulers without modification?

> +
> +# Overview
> +
> +Credit (also known as Credit1) is the default virtual CPU (vCPU) scheduler
> +of the Xen hypervisor. The job of an hypervisor's scheduler is to decide,
> +among all the various vCPUs of the various virtual machines, which ones
> +should execute on the host's physical CPUs (pCPUs), at any given point in
> +time.

A lot of this is generic to all schedulers.

I wonder whether it might be better to have a schedulers meta-feature
doc which deals with the common scheduler parts, including interactions
on the Xen command line, xl, etc.

> +
> +# User details
> +
> +Xen supports multiple schedulers. As said, Credit is the default, so it
> +is used automatically, unless the `sched=$SCHED` (with `$SCHED` different
> +than `credit`) parameter is passed to Xen via the bootloader.
> +
> +Once the system is live, for creating a cpupool with Credit as its
> +scheduler, either compile a cpupool configuration file, as described
> +in `docs/man/xlcpupool.cfg.pod.5` (and as exemplified in
> +`tools/examples/cpupool`), or use just `xl` directly:

I should see about ensuring that cross-references work with the
HTML-generated versions of these docs.  You might be able to get away
with just putting in a plain hyperlink here.

~Andrew

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

Re: [Xen-devel] [PATCH 1/3] docs: Credit1 feature document.

[Wei Liu]

On Thu, Oct 13, 2016 at 12:02:28PM +0100, Dario Faggioli wrote:
> Signed-off-by: Dario Faggioli 
> ---
> Cc: George Dunlap 
> Cc: Wei Liu 
> Cc: Lars Kurth 
> Cc: Andrew Cooper 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> ---
>  docs/features/credit.pandoc |   99 
> +++
>  1 file changed, 99 insertions(+)
>  create mode 100644 docs/features/credit.pandoc
> 
> diff --git a/docs/features/credit.pandoc b/docs/features/credit.pandoc
> new file mode 100644
> index 000..fed0da2
> --- /dev/null
> +++ b/docs/features/credit.pandoc
> @@ -0,0 +1,99 @@
> +% Credit
> +% Revision 1
> +
> +\clearpage
> +
> +# Basics
> + 
> + Status: e.g. **Supported**
> +

Delete the "e.g." in all three documents, please.

> +Architecture(s): e.g. x86, arm
> +

And this should probably be "any".

Wei.

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

[Xen-devel] [libvirt test] 101412: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass

version targeted for testing:
 libvirt  e1a33ed18c0200e26d92eb2900943573fc0f7d60
baseline version:
 libvirt  043ba4a40a4ae26cf616146d0d1c129d65b156b8

Last test of basis   101386  2016-10-12 04:22:05 Z1 days
Testing same since   101412  2016-10-13 04:21:58 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Corey S. McQuay 
  Martin Kletzander 
  Michal Privoznik 
  Nitesh Konkar 
  Nitesh Konkar 
  Pavel Hrdina 
  Peter Krempa 

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-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd pass



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=e1a33ed18c0200e26d92eb2900943573fc0f7d60
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ 

Re: [Xen-devel] [PATCH 2/2] x86/vmx: Reduce the verbosity of the vmentry failure error reporting

[Jan Beulich]

>>> On 13.10.16 at 13:15,  wrote:
> Identify the affected vcpu at the start of the message.  While tweaking this
> area, add extra newlines between cases.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 
with ...

> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -3096,19 +3096,20 @@ static void vmx_failed_vmentry(unsigned int 
> exit_reason,
>  unsigned long exit_qualification;
>  struct vcpu *curr = current;
>  
> -printk("Failed vm entry (exit reason %#x) ", exit_reason);
> +printk("%pv vmentry failure (reason %#x): ", curr, exit_reason);
>  __vmread(EXIT_QUALIFICATION, _qualification);
>  switch ( failed_vmentry_reason )
>  {
>  case EXIT_REASON_INVALID_GUEST_STATE:
> -printk("caused by invalid guest state (%ld).\n", exit_qualification);
> +printk("Invalid guest state (%ld)\n", exit_qualification);

... %lu here.

Jan


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

Re: [Xen-devel] [PATCH 1/2] x86/vmx: Print the problematic MSR if a vmentry fails

[Jan Beulich]

>>> On 13.10.16 at 13:15,  wrote:
> Sample error looks like:
> 
>   (XEN) Failed vm entry (exit reason 0x8022) caused by MSR loading (entry 
> 13).
>   (XEN)   msr 068a, val 1fff80102af0, (mbz 0)
>   (XEN) * VMCS Area **
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 
with

> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -3104,8 +3104,23 @@ static void vmx_failed_vmentry(unsigned int 
> exit_reason,
>  printk("caused by invalid guest state (%ld).\n", exit_qualification);
>  break;
>  case EXIT_REASON_MSR_LOADING:
> -printk("caused by MSR entry %ld loading.\n", exit_qualification);
> +{
> +unsigned long idx = exit_qualification - 1;
> +struct vmx_msr_entry *msr;

... preferably const here (and the declaration perhaps moved into
the more narrow scope it's needed in), ...

> +printk("caused by MSR loading (entry %ld).\n", idx);

... %lu (plus ideally the full stop dropped) here, and ...

> +if ( idx > (PAGE_SIZE / sizeof(*msr)) )

... >= here.

> +printk("  Entry out of range\n");
> +else
> +{
> +msr = >arch.hvm_vmx.msr_area[idx];
> +
> +printk("  msr %08x, val %016"PRIx64", (mbz %#x)\n",

I'm also unsure about the usefulness of the commas here - at least
the second one seems a little strange with the value in parentheses.

Jan


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

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

[George Dunlap]

On 13/10/16 12:28, Andrew Cooper wrote:
> On 13/10/16 12:01, Dario Faggioli wrote:
>> Hey,
>>
>> "Just" as per the subject, I wrote feature documents for (almost) all our
>> schedulers. No big deal, I'd say, apart from the fact that I'm declaring
>> Credit2 **Supperted**, instead of experimental.
> 
> Supperted?  That's like supported right? ;p
> 
> 
> It is fine for you to propose that a feature should be upgraded to
> supported, and this is probably the best way to formally do so.
> 
> However, final agreement of a feature becoming supported should include
> input from the security team. (At the end of the day, it is us with
> extra work if the feature isn't up to scratch.)

Yes, interesting idea.  I don't think in our discussions of feature
lifecycle maturity we'd talked about that yet.

 -George

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

Re: [Xen-devel] [PATCH 02/15] xen: Fix coding style warnings

[Anthony PERARD]

On Thu, Oct 13, 2016 at 07:04:56AM +0300, Emil Condrea wrote:
> On Tue, Oct 11, 2016 at 5:20 PM, Anthony PERARD
>  wrote:
> > On Tue, Oct 04, 2016 at 09:43:31AM +0300, Emil Condrea wrote:
> >> Fixes:
> >>  * WARNING: line over 80 characters
> >>
> >> Signed-off-by: Emil Condrea 
> >> ---
> >>  hw/block/xen_disk.c  |  3 ++-
> >>  hw/char/xen_console.c|  6 --
> >>  hw/display/xenfb.c   | 30 --
> >>  hw/net/xen_nic.c | 12 
> >>  hw/xen/xen_backend.c | 15 ++-
> >>  include/hw/xen/xen_backend.h |  8 +---
> >>  6 files changed, 49 insertions(+), 25 deletions(-)
> >>
> >> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> >> index 5aa350a..24edeb2 100644
> >> --- a/hw/block/xen_disk.c
> >> +++ b/hw/block/xen_disk.c
> >> @@ -1068,7 +1068,8 @@ static int blk_connect(struct XenDevice *xendev)
> >>  blk_set_enable_write_cache(blkdev->blk, !writethrough);
> >>  } else {
> >>  /* setup via qemu cmdline -> already setup for us */
> >> -xen_be_printf(>xendev, 2, "get configured bdrv (cmdline 
> >> setup)\n");
> >> +xen_be_printf(>xendev, 2,
> >> + "get configured bdrv (cmdline setup)\n");
> >
> > Arguments are usually aligned with the first one, so there is one
> > missing space.
> 
> I guess this is displayed wrongly in the email client as in mine but the 
> source
> of the email contains this patch http://pastebin.com/Sbk23h6m, which shows 
> that
> this line is aligned to the first parameter.

My mail client runs in a terminal, also I've apply the patches to a
local tree, so no display issue.

Here, the quote is just below the open parentheses, but it's normally
one space futher.

If I ask Vim to realign it, I end up with this:
 xen_be_printf(>xendev, 2,
- "get configured bdrv (cmdline setup)\n");
+  "get configured bdrv (cmdline setup)\n");

You can also have a look at other call of xen_be_printf() in this
function (blk_connect) to get an idea ;).

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

[Andrew Cooper]

On 13/10/16 12:01, Dario Faggioli wrote:
> Hey,
>
> "Just" as per the subject, I wrote feature documents for (almost) all our
> schedulers. No big deal, I'd say, apart from the fact that I'm declaring
> Credit2 **Supperted**, instead of experimental.

Supperted?  That's like supported right? ;p


It is fine for you to propose that a feature should be upgraded to
supported, and this is probably the best way to formally do so.

However, final agreement of a feature becoming supported should include
input from the security team. (At the end of the day, it is us with
extra work if the feature isn't up to scratch.)

~Andrew

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

[Xen-devel] [PATCH 2/2] x86/vmx: Reduce the verbosity of the vmentry failure error reporting

[Andrew Cooper]

Identify the affected vcpu at the start of the message.  While tweaking this
area, add extra newlines between cases.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Jun Nakajima 
CC: Kevin Tian 
---
 xen/arch/x86/hvm/vmx/vmx.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 38cbcea..554f9e8 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3096,19 +3096,20 @@ static void vmx_failed_vmentry(unsigned int exit_reason,
 unsigned long exit_qualification;
 struct vcpu *curr = current;
 
-printk("Failed vm entry (exit reason %#x) ", exit_reason);
+printk("%pv vmentry failure (reason %#x): ", curr, exit_reason);
 __vmread(EXIT_QUALIFICATION, _qualification);
 switch ( failed_vmentry_reason )
 {
 case EXIT_REASON_INVALID_GUEST_STATE:
-printk("caused by invalid guest state (%ld).\n", exit_qualification);
+printk("Invalid guest state (%ld)\n", exit_qualification);
 break;
+
 case EXIT_REASON_MSR_LOADING:
 {
 unsigned long idx = exit_qualification - 1;
 struct vmx_msr_entry *msr;
 
-printk("caused by MSR loading (entry %ld).\n", idx);
+printk("MSR loading (entry %ld)\n", idx);
 
 if ( idx > (PAGE_SIZE / sizeof(*msr)) )
 printk("  Entry out of range\n");
@@ -3121,13 +3122,15 @@ static void vmx_failed_vmentry(unsigned int exit_reason,
 }
 break;
 }
+
 case EXIT_REASON_MCE_DURING_VMENTRY:
-printk("caused by machine check.\n");
+printk("MCE\n");
 HVMTRACE_0D(MCE);
 /* Already handled. */
 break;
+
 default:
-printk("reason not known yet!");
+printk("Unknown\n");
 break;
 }
 
-- 
2.1.4


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

[Xen-devel] [PATCH 1/2] x86/vmx: Print the problematic MSR if a vmentry fails

[Andrew Cooper]

Sample error looks like:

  (XEN) Failed vm entry (exit reason 0x8022) caused by MSR loading (entry 
13).
  (XEN)   msr 068a, val 1fff80102af0, (mbz 0)
  (XEN) * VMCS Area **

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Jun Nakajima 
CC: Kevin Tian 
---
 xen/arch/x86/hvm/vmx/vmx.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index b9102ce..38cbcea 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3104,8 +3104,23 @@ static void vmx_failed_vmentry(unsigned int exit_reason,
 printk("caused by invalid guest state (%ld).\n", exit_qualification);
 break;
 case EXIT_REASON_MSR_LOADING:
-printk("caused by MSR entry %ld loading.\n", exit_qualification);
+{
+unsigned long idx = exit_qualification - 1;
+struct vmx_msr_entry *msr;
+
+printk("caused by MSR loading (entry %ld).\n", idx);
+
+if ( idx > (PAGE_SIZE / sizeof(*msr)) )
+printk("  Entry out of range\n");
+else
+{
+msr = >arch.hvm_vmx.msr_area[idx];
+
+printk("  msr %08x, val %016"PRIx64", (mbz %#x)\n",
+   msr->index, msr->data, msr->mbz);
+}
 break;
+}
 case EXIT_REASON_MCE_DURING_VMENTRY:
 printk("caused by machine check.\n");
 HVMTRACE_0D(MCE);
-- 
2.1.4


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

Re: [Xen-devel] [PATCH for-4.8] tools: check liblzma in configure for rombios

[Ian Jackson]

Wei Liu writes ("[PATCH for-4.8] tools: check liblzma in configure for 
rombios"):
> We upgraded ipxe in 38ab99b2 ("ipxe: update to new commit"). That
> version of ipxe requires liblzma to build.
> 
> Check that in configure and document this in README.

Acked-by: Ian Jackson 

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

[Xen-devel] [PATCH 3/3] docs: RTDS feature document.

[Dario Faggioli]

Signed-off-by: Dario Faggioli 
---
Cc: Meng Xu 
Cc: George Dunlap 
Cc: Wei Liu 
Cc: Lars Kurth 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
---
 docs/features/rtds.pandoc |  125 +
 1 file changed, 125 insertions(+)
 create mode 100644 docs/features/rtds.pandoc

diff --git a/docs/features/rtds.pandoc b/docs/features/rtds.pandoc
new file mode 100644
index 000..76aa165
--- /dev/null
+++ b/docs/features/rtds.pandoc
@@ -0,0 +1,125 @@
+% RTDS
+% Revision 1
+
+\clearpage
+
+# Basics
+ 
+ Status: e.g. **Experimental**
+
+Architecture(s): e.g. x86, arm
+
+  Component: e.g. Hypervisor
+ 
+
+# Overview
+
+RTDS is one of the virtual CPU (vCPU) scheduler available in the Xen
+hypervisor. The job of an hypervisor's virtual CPU scheduler is to
+decide, among all the various vCPUs of the various virtual machines,
+which ones should execute on the host's physical CPUs (pCPUs), at any
+given point in time.
+
+RTDS is a real--time scheduler, so its purpose is enabling
+**deterministic** scheduling of the virtual machine's vCPUs. It has
+been originally developed in the context of the RT-Xen project.
+
+# User details
+
+RTDS is not in use by default. In order to use it as the Xen scheduler
+the following parameter should be passed to the hypervisor at boot:
+
+`sched=rtds`
+
+Once the system is live, for creating a cpupool with RTDS as its
+scheduler, either compile a cpupool configuration file, as described
+in `docs/man/xlcpupool.cfg.pod.5` (and as exemplified in
+`tools/examples/cpupool`), or use just `xl` directly:
+
+xl cpupool-create name=\"pool-rt\" sched=\"rtds\" cpus=[4,5,6,8]
+
+For checking or changing a VM's scheduling parameters from xl, do
+as follows:
+* `xl sched-rtds -d vm-rt`
+* `xl sched-rtds -d vm-rt -t 1 -b 25000`
+
+It is possible, for a multiple vCPUs VM, to change the parameters of
+each vCPU individually:
+* `xl sched-rtds -d vm-rt -v 0 -p 2 -b 1 -v 1 -p 45000 -b 12000`
+
+# Technical details
+
+The implementation entirely lives in the hypervisor. Xen has a
+pluggable, hook based, architecture for schedulers. RTDS code
+is all inside one file: `xen/common/sched_rt.c`
+
+In libxl, the availability of the RTDS scheduler is advertised by
+the presence of the LIBXL\_HAVE\_SCHED\_RTDS symbol. The ability of
+specifying different scheduling parameters for each vcpu has been
+introduced later, and is available if the following symbols are defined:
+* `LIBXL\_HAVE\_VCPU\_SCHED\_PARAMS`,
+* `LIBXL\_HAVE\_SCHED\_RTDS\_VCPU\_PARAMS`.
+
+# Limitations
+
+RTDS is a special purpose scheduling. This is by design, and not at
+all a limitation, but it is certainly something to keep in mind when
+thinking about using it. The purpose of the scheduler is enabling
+deterministic and statically analyzable behavior (as per the
+real-time academic literature), according to the scheduling parameters
+assigned to each vCPU.
+
+Using RTDS a the Xen scheduler, and/or for general purpose workloads
+is definitely possible, but the vCPU scheduling parameters (of both
+Domain0 and of the various VMs) would probably require tweaking, with
+respect to their default values.
+
+# Testing
+
+Any change done in RTDS must be tested by doing the following:
+
+* create a cpupool with RTDS as its scheduler,
+* create a few virtual machines a move them in and out of the pool,
+* create a few virtual machines, directly inside the pool, and verify
+  that they boot and can run some basic workload (e.g., login into them
+  and run simple commands),
+* shutdown/reboot the virtual machines,
+
+The fact that the system boots fine when passing `sched=rtds` to Xen
+should also be verified.
+
+Finally, to check that the scheduler is working properly (although only
+at a macroscopic level), the following should be done:
+
+* create a VM with 1 vCPU and put it in the RTDS cpupool,
+* set the scheduling parameters such as it has a 50% reservation, with
+  `xl sched-rtds -d vm -t 10 -b 5`,
+* run a CPU-burning process inside the VM (e.g., `yes`),
+* check with `xentop` (in Domain0) that the VM is getting no more than
+  50% pCPU time.
+
+# Areas for improvement
+
+* Work-conserving mode to be added;
+* performance assessment, especially focusing on what level of real-time
+  behavior the scheduler enables.
+
+# Known issues
+
+* OSSTest reports occasional failures on ARM.
+
+# References
+
+* "RT-Xen: Real-Time Virtualization" [XPDS14 

[Xen-devel] [PATCH 2/3] docs: Credit2 feature document.

[Dario Faggioli]

Since we are marking the feature as 'Supported', remove the
"this is experimental software" warning in the code at once.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
Cc: Wei Liu 
Cc: Lars Kurth 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
---
 docs/features/credit2.pandoc |  123 ++
 xen/common/sched_credit2.c   |2 -
 2 files changed, 123 insertions(+), 2 deletions(-)
 create mode 100644 docs/features/credit2.pandoc

diff --git a/docs/features/credit2.pandoc b/docs/features/credit2.pandoc
new file mode 100644
index 000..6203cec
--- /dev/null
+++ b/docs/features/credit2.pandoc
@@ -0,0 +1,123 @@
+% Credit2
+% Revision 1
+
+\clearpage
+
+# Basics
+ 
+ Status: e.g. **Supported**
+
+Architecture(s): e.g. x86, arm
+
+  Component: e.g. Hypervisor
+ 
+
+# Overview
+
+Credit2 is one of the virtual CPU (vCPU) scheduler available in the
+Xen hypervisor. The job of an hypervisor's virtual CPU scheduler is
+to decide, among all the various vCPUs of the various virtual machines,
+which ones should execute on the host's physical CPUs (pCPUs), at any
+given point in time.
+
+Credit2 was designed as a general purpose scheduler, with particular
+focus on improving handling of mixed workloads, scalability and
+support for low latency applications inside VMs, with respect to
+Credit1.
+
+# User details
+
+Credit2 is not in use by default. In order to use it as the Xen
+scheduler the following parameter should be passed to the hypervisor
+at boot:
+
+`sched=credit2`
+
+Other parameters are available for tuning the behavior of Credit2
+(see `docs/misc/xen-command-line.markdown` for a complete list and
+for their meaning).
+
+Once the system is live, for creating a cpupool with Credit2 as
+its scheduler, either compile a cpupool configuration file, as
+described in `docs/man/xlcpupool.cfg.pod.5` (and as exemplified
+in `tools/examples/cpupool`), or use just `xl` directly:
+
+xl cpupool-create name=\"pool1\" sched=\"credit2\" cpus=[1,2]
+
+Two kind of interactions with the scheduler are possible:
+
+* checking or changing the global parameters, via, e.g.:
+* `xl sched-credit2 -s`
+* `xl sched-credit2 -s -p pool1`
+* `xl sched-credit2 -s -r 100`
+* checking or changing a VM scheduling parameters, via, e.g.:
+* `xl sched-credit2 -d vm1`
+* `xl sched-credit2 -d vm1 -w 1024`
+
+# Technical details
+
+The implementation entirely lives in the hypervisor. Xen has a
+pluggable, hook based, architecture for schedulers. Credit2 code
+is all inside one file: `xen/common/sched_credit2.c`
+
+Global scheduling parameters, such as context switching rate
+limiting, is only available from Xen 4.8 onward. In libxl, the
+`LIBXL\_HAVE\_SCHED\_CREDIT2\_PARAMS` symbol is introduced to
+indicate their availability.
+
+# Limitations
+
+The Credit1 scheduler supports vCPU hard-affinity, vCPU soft-affinity
+and caps (see `docs/man/xl.pod.1.in` for more details). In Credit2,
+vCPU hard affinity is supported starting from Xen 4.8, while soft-affinity
+and caps are being implemented, but not supported yet in any released
+hypervisor.
+
+# Testing
+
+Any change done in Credit2 wants to be tested by doing at least the
+following:
+
+* boot the system with `sched=credit2`,
+* create a few virtual machine and verify that they boot and can
+  run some basic workload (e.g., login into them and run simple commands),
+* shutdown/reboot the virtual machines,
+* shutdown/reboot the system.
+
+Ideally, all the above steps should **also** be performed in a configuration
+where Credit2 is used as the scheduler of a cpupool, and by also doing the
+following:
+
+* move a virtual machine inside and outside a Credit2 cpupool.
+
+# Areas for improvement
+
+* Close the feature gap with Credit1 (i.e., finishing implementing vCPU
+  soft-affinity and caps);
+* vCPUs' reservations (similar to caps, but providing a vCPU with guarantees
+  about some pCPU time it will always be able to execute for);
+* benchmarking for assessing the best combination of values for the various
+  parameters (`sched\_credit2\_migrate\_resist`, `credit2\_balance\_over`,
+  `credit2\_balance\_under`)
+
+# Known issues
+
+* I/O oriented benchmarks (like network and disk throughput) have given
+  contradictory and non-conclusive results so far. Need to run more of
+  those.
+
+# References
+
+* "Scheduler development update", XenSummit Asia 2009 
[whitepaper](http://www-archive.xenproject.org/files/xensummit_intel09/George_Dunlap.pdf)
+* "Scheduling in 

[Xen-devel] [PATCH for-4.8] tools: check liblzma in configure for rombios

[Wei Liu]

We upgraded ipxe in 38ab99b2 ("ipxe: update to new commit"). That
version of ipxe requires liblzma to build.

Check that in configure and document this in README.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 

Rerun autogen.sh while committing.
---
 README |   1 +
 tools/config.h.in  |   3 ++
 tools/configure| 139 +++--
 tools/configure.ac |   2 +
 4 files changed, 99 insertions(+), 46 deletions(-)

diff --git a/README b/README
index 91f4a8b..b370ce2 100644
--- a/README
+++ b/README
@@ -82,6 +82,7 @@ disabled at compile time:
   information.
 * 16-bit x86 assembler, loader and compiler for qemu-traditional / rombios
   (dev86 rpm or bin86 & bcc debs)
+* Development install of liblzma for rombios
 
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If
diff --git a/tools/config.h.in b/tools/config.h.in
index f65eec4..58856bc 100644
--- a/tools/config.h.in
+++ b/tools/config.h.in
@@ -36,6 +36,9 @@
 /* Define to 1 if you have the `fdt' library (-lfdt). */
 #undef HAVE_LIBFDT
 
+/* Define to 1 if you have the `lzma' library (-llzma). */
+#undef HAVE_LIBLZMA
+
 /* Define to 1 if you have the `yajl' library (-lyajl). */
 #undef HAVE_LIBYAJL
 
diff --git a/tools/configure b/tools/configure
index e3cc3ea..25edfee 100755
--- a/tools/configure
+++ b/tools/configure
@@ -1696,6 +1696,52 @@ fi
 
 } # ac_fn_c_try_compile
 
+# ac_fn_c_try_link LINENO
+# ---
+# Try to link conftest.$ac_ext, and return whether this succeeded.
+ac_fn_c_try_link ()
+{
+  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
+  rm -f conftest.$ac_objext conftest$ac_exeext
+  if { { ac_try="$ac_link"
+case "(($ac_try" in
+  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+  *) ac_try_echo=$ac_try;;
+esac
+eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
+$as_echo "$ac_try_echo"; } >&5
+  (eval "$ac_link") 2>conftest.err
+  ac_status=$?
+  if test -s conftest.err; then
+grep -v '^ *+' conftest.err >conftest.er1
+cat conftest.er1 >&5
+mv -f conftest.er1 conftest.err
+  fi
+  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; } && {
+test -z "$ac_c_werror_flag" ||
+test ! -s conftest.err
+   } && test -s conftest$ac_exeext && {
+test "$cross_compiling" = yes ||
+test -x conftest$ac_exeext
+   }; then :
+  ac_retval=0
+else
+  $as_echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+   ac_retval=1
+fi
+  # Delete the IPA/IPO (Inter Procedural Analysis/Optimization) information
+  # created by the PGI compiler (conftest_ipa8_conftest.oo), as it would
+  # interfere with the next link command; also delete a directory that is
+  # left behind by Apple's compiler.  We do this before executing the actions.
+  rm -rf conftest.dSYM conftest_ipa8_conftest.oo
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  as_fn_set_status $ac_retval
+
+} # ac_fn_c_try_link
+
 # ac_fn_c_try_cpp LINENO
 # --
 # Try to preprocess conftest.$ac_ext, and return whether this succeeded.
@@ -1897,52 +1943,6 @@ $as_echo "$ac_res" >&6; }
 
 } # ac_fn_c_check_header_compile
 
-# ac_fn_c_try_link LINENO
-# ---
-# Try to link conftest.$ac_ext, and return whether this succeeded.
-ac_fn_c_try_link ()
-{
-  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
-  rm -f conftest.$ac_objext conftest$ac_exeext
-  if { { ac_try="$ac_link"
-case "(($ac_try" in
-  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
-  *) ac_try_echo=$ac_try;;
-esac
-eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
-$as_echo "$ac_try_echo"; } >&5
-  (eval "$ac_link") 2>conftest.err
-  ac_status=$?
-  if test -s conftest.err; then
-grep -v '^ *+' conftest.err >conftest.er1
-cat conftest.er1 >&5
-mv -f conftest.er1 conftest.err
-  fi
-  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
-  test $ac_status = 0; } && {
-test -z "$ac_c_werror_flag" ||
-test ! -s conftest.err
-   } && test -s conftest$ac_exeext && {
-test "$cross_compiling" = yes ||
-test -x conftest$ac_exeext
-   }; then :
-  ac_retval=0
-else
-  $as_echo "$as_me: failed program was:" >&5
-sed 's/^/| /' conftest.$ac_ext >&5
-
-   ac_retval=1
-fi
-  # Delete the IPA/IPO (Inter Procedural Analysis/Optimization) information
-  # created by the PGI compiler (conftest_ipa8_conftest.oo), as it would
-  # interfere with the next link command; also delete a directory that is
-  # left behind by Apple's compiler.  We do this before executing the actions.
-  rm -rf conftest.dSYM conftest_ipa8_conftest.oo
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
-  as_fn_set_status $ac_retval
-
-} # ac_fn_c_try_link
-
 # 

[Xen-devel] [PATCH 1/3] docs: Credit1 feature document.

[Dario Faggioli]

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Wei Liu 
Cc: Lars Kurth 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
---
 docs/features/credit.pandoc |   99 +++
 1 file changed, 99 insertions(+)
 create mode 100644 docs/features/credit.pandoc

diff --git a/docs/features/credit.pandoc b/docs/features/credit.pandoc
new file mode 100644
index 000..fed0da2
--- /dev/null
+++ b/docs/features/credit.pandoc
@@ -0,0 +1,99 @@
+% Credit
+% Revision 1
+
+\clearpage
+
+# Basics
+ 
+ Status: e.g. **Supported**
+
+Architecture(s): e.g. x86, arm
+
+  Component: e.g. Hypervisor
+ 
+
+# Overview
+
+Credit (also known as Credit1) is the default virtual CPU (vCPU) scheduler
+of the Xen hypervisor. The job of an hypervisor's scheduler is to decide,
+among all the various vCPUs of the various virtual machines, which ones
+should execute on the host's physical CPUs (pCPUs), at any given point in
+time.
+
+# User details
+
+Xen supports multiple schedulers. As said, Credit is the default, so it
+is used automatically, unless the `sched=$SCHED` (with `$SCHED` different
+than `credit`) parameter is passed to Xen via the bootloader.
+
+Once the system is live, for creating a cpupool with Credit as its
+scheduler, either compile a cpupool configuration file, as described
+in `docs/man/xlcpupool.cfg.pod.5` (and as exemplified in
+`tools/examples/cpupool`), or use just `xl` directly:
+
+xl cpupool-create name=\"pool1\" sched=\"credit\" cpus=[4,8]
+
+Two kind of interactions with the scheduler are possible:
+
+* checking or changing the global parameters, via, e.g.:
+* `xl sched-credit -s`
+* `xl sched-credit -s -p pool1`
+* `xl sched-credit -s -t 20`
+* checking or changing a VM's scheduling parameters, via, e.g.:
+* `xl sched-credit -d vm1`
+* `xl sched-credit -d vm1 -w 512`
+
+# Technical details
+
+Implementation entirely lives in the hypervisor. Xen has a pluggable, hook
+based, architecture for schedulers. Actual Credit code is all inside one
+file: `xen/common/sched_credit.c`.
+
+# Limitations
+
+In Credit, a vCPU has a priority, a status (i.e., active or inactive),
+a weight and some credits... and all these things interact in a rather
+involved way. Also, with years of use, things have gotten even more
+complex (due to, e.g., the introduction of boosting, caps and vCPU
+soft-affinity).
+
+Dealing with such complexity is starting to be an issue. Odd behavior
+or subtle scheduling anomalies, that is not always possible to act upon,
+have been identified already. [1][2][3]
+
+A certain lack of scalability and difficulties and weakness in dealing
+with mixed workloads and VMs with low latency requirements are other
+known problems. [4] For all these reasons, effort is ongoing to have
+Credit2 become the new default scheduler.
+
+# Testing
+
+Any change to Credit code must to be tested by doing at least the following:
+
+* create a few virtual machine and verify that they boot and can
+  run some basic workload (e.g., login into them and run simple commands),
+* shutdown/reboot the virtual machines,
+* shutdown the system.
+
+Ideally, all the above steps should **also** be performed in a configuration
+that includes cpupools, better if with pools using different schedulers, and
+by also doing the following:
+
+* move the virtual machines between cpupools.
+
+# References
+
+* [potential non-ideal behavior on hyperthreaded 
systems](https://lists.xenproject.org/archives/html/xen-devel/2014-07/msg01848.html)
 [1]
+* [long standing BOOST vs. migration 
bug](https://lists.xen.org/archives/html/xen-devel/2015-10/msg02851.html) [2]
+* [priority handling 
issues](https://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01362.html)
 [3]
+* "Scheduler development update", XenSummit Asia 2009 
[whitepaper](http://www-archive.xenproject.org/files/xensummit_intel09/George_Dunlap.pdf)
 [4]
+* "Scheduling in Xen" [XPDS15 
Presentation](http://events.linuxfoundation.org/sites/events/files/slides/Faggioli_XenSummit.pdf)
+* [Xen Project 
Scheduler](https://wiki.xenproject.org/wiki/Xen_Project_Schedulers)
+
+# History
+
+
+Date   Revision Version  Notes
+--   ---
+2016-10-10 1Xen 4.8  Document written
+--   ---


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

[Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers

[Dario Faggioli]

Hey,

"Just" as per the subject, I wrote feature documents for (almost) all our
schedulers. No big deal, I'd say, apart from the fact that I'm declaring
Credit2 **Supperted**, instead of experimental.

In fact, it's being tested by OSSTest for ages, and it's undergone a huge
amount of development, testing and benchmarking lately, and its current status
is finally good enough, IMO.

As a consequence of that, in patch 2, I'm also touching the code, but that's
just for removing a printk, so it should not be too big of a deal I hope.

This wiki page is listed among the references in Credit2's feature document:
https://wiki.xenproject.org/wiki/Credit2_Scheduler_Development.
If you go there checking it out, bear in mind that I'm updating and
re-organazing it by quite a bit, like right now.

Sorry if the Cc-list is a bit large, but that's the best I and
get_maintainers.pl could come up with. :-P

Thanks and Regards,
Dario
---
Dario Faggioli (3):
  docs: Credit1 feature document.
  docs: Credit2 feature document.
  docs: RTDS feature document.

 docs/features/credit.pandoc  |   99 +
 docs/features/credit2.pandoc |  123 +
 docs/features/rtds.pandoc|  125 ++
 xen/common/sched_credit2.c   |2 -
 4 files changed, 347 insertions(+), 2 deletions(-)
 create mode 100644 docs/features/credit.pandoc
 create mode 100644 docs/features/credit2.pandoc
 create mode 100644 docs/features/rtds.pandoc
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

Re: [Xen-devel] [PATCH] x86emul: correct {, F}CMOV and F{, U}COMI{, P} emulation

[Andrew Cooper]

On 13/10/16 07:41, Jan Beulich wrote:
> The FPU ones need to be executed with guest EFLAGS.{C,P,Z}F in context.
>
> We also can't exclude someone wanting to hide the feature from (32-bit)
> guests.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit

[Juergen Schinker]

- On 13 Oct, 2016, at 09:29, Wei Liu wei.l...@citrix.com wrote:

> On Thu, Oct 13, 2016 at 10:10:46AM +0100, Juergen Schinker wrote:
>> Right and still no solution
>> 
>> there is no xz-dev or libxz-dev;  I installed everything which just looks 
>> remote
>> like xz or lzma
>> 
> 
> On Debian it is called liblzma-dev. Not sure what distro you use.
> 
>> building is no problem as I build with
>> 
>> ./configure --enable-githttp --enable-systemd --disable-rombios
>> --disable-qemu-traditional --disable-stubdom --disable-docs
>> 
>> 
> 
> And you sorta worked around the lzma requirement by disabling rombios.
> 
> This issue you encountered is a different issue from Boris'.
 
no still no solution

the xz problem is only for xen-4.7 but i gave up on that

my last test was 4.8-rc2 which also didn't work ; building and booting 
hypervizor is ok

xl tools  nope

creating or starting a VM  nope

xl -v cr something  hangs forever

restarting xencommons   hangs

restarting xenconsoled  hangs

sigh

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

Re: [Xen-devel] [PATCH Altp2m cleanup 2/3 v10 2/2] Moving ept code to ept specific files as requested in: https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04323.html Renamed p2m_init_al

[Jan Beulich]

>>> On 12.10.16 at 01:40,  wrote:
> Signed-off-by: Paul Lai 
> Reviewed-by: Konrad Rzeszutek Wilk 
> ---
> v10
> Added Reviewed-by stamp

Same thing here - please address _all_ review comments. On v9
Konrad did say "someting is off with your title. I think you need to
add an extra newline." As it stands the patch title is definitely too
long.

Jan


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

Re: [Xen-devel] [PATCH Altp2m cleanup 2/3 v10 1/2] Move altp2m specific functions to altp2m files.

[Jan Beulich]

>>> On 12.10.16 at 01:40,  wrote:
> @@ -66,6 +67,63 @@ altp2m_vcpu_destroy(struct vcpu *v)
>  }
>  
>  /*
> + *  allocate and initialize memory for altp2m portion of domain
> + *
> + *  returns < 0 on error
> + *  returns 0 on no operation & success
> + */
> +int
> +altp2m_domain_init(struct domain *d)
> +{
> +int rc;
> +unsigned int i;
> +
> +if ( d == NULL )
> +return 0;

I'm sorry for not having paid attention before, but why do you add
this check?

> @@ -493,32 +494,25 @@ int hap_enable(struct domain *d, u32 mode)
>  goto out;
>  }
>  
> -for (i = 0; i < MAX_NESTEDP2M; i++) {
> +for (i = 0; i < MAX_NESTEDP2M; i++)
> +{

If you correct coding style issues, then please deal with all of them
at once. Albeit this code is unrelated to altp2m, so maybe you'd
better leave it alone in this patch.

>  rv = p2m_alloc_table(d->arch.nested_p2m[i]);
>  if ( rv != 0 )
> goto out;
>  }
>  
> -if ( hvm_altp2m_supported() )
> +if ( (rv = altp2m_domain_init(d)) < 0 )
>  {
> -/* Init alternate p2m data */
> -if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> +for (i = 0; i < MAX_NESTEDP2M; i++)

As said on v8: Coding style (you've moved the opening brace, but
you didn't insert blanks).

>  {
> -rv = -ENOMEM;
> -goto out;
> +p2m_teardown(d->arch.nested_p2m[i]);
>  }
>  
> -for ( i = 0; i < MAX_EPTP; i++ )
> -d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> -
> -for ( i = 0; i < MAX_ALTP2M; i++ )
> -{
> -rv = p2m_alloc_table(d->arch.altp2m_p2m[i]);
> -if ( rv != 0 )
> -   goto out;
> -}
> +if ( d->arch.paging.hap.total_pages != 0 )
> +hap_teardown(d, NULL);
>  
> -d->arch.altp2m_active = 0;
> +p2m_teardown(p2m_get_hostp2m(d));
> +goto out;
>  }

Repeating my v8 comment: "The portions of code removed in this
hunk went into altp2m_domain_init(). The additions, however, are
unexplained in the commit message and I'm not convinced they
actually properly deal with the previously missing error cleanup.
In particular I don't see how partial success of altp2m_domain_init()
is being dealt with." While it looks like the final part of that may
have been taken care of, may I once again remind you that it is a
waste of everyone's time unless _all_ comments given on a prior
version get addressed either verbally or in the next submitted
version? In particular (but please don't again take this as the only
thing needing changing/explaining) the call to hap_teardown()
looks unmotivated. Don't you mean to just undo the earlier
hap_set_allocation()? And then - did you check that cleanup is
(a) necessary here in the first place and (b) is now complete? I
ask because e.g. the nested p2m allocation loop doesn't appear
to be doing any cleanup either. It looks like this is wrong too,
but if you fix it you need to (1) confirm for yourself the change
is needed and (2) reason about the change in the commit message.
And it may well be that this again would better not be done here,
but in a prerequisite (and thus backportable) patch.

Jan


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

Re: [Xen-devel] per-domain logging

[Wei Liu]

On Thu, Oct 13, 2016 at 11:28:21AM +0200, Cedric Bosdonnat wrote:
> Hi Wei, Ian,
> 
> In quite a number of places, the domid we have in the function calling LOG*
> may be the one of a stubdom. In the log we want to output the domid of the
> domain the user knows about. Would there be a way to get it?
> 
> An example of that is do_pci_add. It has a libxl_is_stubdom call, suggesting
> that domid may not be the real domain id. An I wonder if there are other
> places where domid may be the one of a stubdom and I don't know it.
> 

The third argument of libxl_is_stubdom can be used to retrieve the
target domid.

If you find other places where you need to get the domid, please let me
know. I believe there are some fields embedded in various structs that
we can interrogate.

Wei.

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

Re: [Xen-devel] [PATCH V3] Xen/Keyhandler: Rework process of nonirq keyhandler

[Wei Liu]

On Thu, Oct 13, 2016 at 03:30:04AM -0600, Jan Beulich wrote:
> >>> On 13.10.16 at 12:06,  wrote:
> > Keyhandler may run for a long time in serial port driver's
> > timer handler on the large machine with a lot of physical
> > cpus(e,g dump_timerq()) when serial port driver works in
> > the poll mode(via the exception mechanism).
> > 
> > If a timer handler runs a long time, it will block nmi_timer_fn()
> > to feed NMI watchdog and cause Xen hypervisor panic. Inserting
> > process_pending_softirqs() in timer handler will not help. when timer
> > interrupt arrives, timer subsystem calls all expired timer handlers
> > before programming next timer interrupt. There is no timer interrupt
> > arriving to trigger timer softirq during run a timer handler.
> > 
> > This patch is to fix the issue to make nonirq keyhandler run in
> > tasklet when receive debug key from serial port.
> > 
> > Signed-off-by: Lan Tianyu 
> 
> Reviewed-by: Jan Beulich 
> with ...
> 
> > --- a/xen/include/xen/keyhandler.h
> > +++ b/xen/include/xen/keyhandler.h
> > @@ -46,7 +46,9 @@ void register_irq_keyhandler(unsigned char key,
> >   bool_t diagnostic);
> >  
> >  /* Inject a keypress into the key-handling subsystem. */
> > -extern void handle_keypress(unsigned char key, struct cpu_user_regs *regs);
> > +extern void handle_keypress(unsigned char key,
> > +   struct cpu_user_regs *regs,
> > +   bool async);
> 
> ... this also changed to force_tasklet. I guess the committer could,
> easily do that, but otoh I'm not sure we want/need this for 4.8 - Wei?
> 

I'm fine with putting this into 4.8. The tree is stable at the moment,
we can feed to few nice-to-have things.

Wei.

> Jan
> 

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

Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit

[Wei Liu]

On Thu, Oct 13, 2016 at 10:04:11AM +0100, Wei Liu wrote:
> On Wed, Oct 12, 2016 at 05:03:11PM -0400, Boris Ostrovsky wrote:
> > On 10/12/2016 05:27 AM, Wei Liu wrote:
> > > On Tue, Oct 11, 2016 at 08:31:31PM +0100, Juergen Schinker wrote:
> > >>  
> > >>> We're going to tag rc2 some time this week. Thanks for help testing Xen!
> > >>>
> > >>> Wei.
> > >>>
> >  J
> > 
> >  - On 11 Oct, 2016, at 09:37, Wei Liu wei.l...@citrix.com wrote:
> > 
> > > No, you can try to work around this issue by appending 
> > > --disable-rombios
> > > to your ./configure invocation. You can test major functionalities of
> > > Xen just fine without rombios.
> > >
> > > Wei.
> > >> Now for the fun of it I tried the RELEASE-4.7 
> > >>
> > >> and it turns out it has no support for xz-decompression 
> > >>
> > > That's probably because you don't have libzx development package
> > > installed when building Xen.
> > 
> > 
> > Which would be a new requirement for building Xen. And it broke our
> > (pre-historic) build server that never had it installed.
> > 
> 
> I don't think it breaks building Xen -- you just can't decompress xz
> format file, right? Otherwise Juergen would not have been able to build
> Xen.

Now I see what happened -- upstream ipxe now requires lzma to build.

I can document that in README.

Wei.

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

Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit

[Wei Liu]

On Thu, Oct 13, 2016 at 10:10:46AM +0100, Juergen Schinker wrote:
> Right and still no solution 
> 
> there is no xz-dev or libxz-dev;  I installed everything which just looks 
> remote like xz or lzma
> 

On Debian it is called liblzma-dev. Not sure what distro you use.

> building is no problem as I build with
> 
> ./configure --enable-githttp --enable-systemd --disable-rombios 
> --disable-qemu-traditional --disable-stubdom --disable-docs
> 
> 

And you sorta worked around the lzma requirement by disabling rombios.

This issue you encountered is a different issue from Boris'.

Wei.

> I'm thinking of building a special VM with only stable Debian and old gcc and 
> old everything - Pepperidge Farm remembers
> 
> and build there
> 
> - On 13 Oct, 2016, at 09:04, Wei Liu wei.l...@citrix.com wrote:
> 
> > I don't think it breaks building Xen -- you just can't decompress xz
> > format file, right? Otherwise Juergen would not have been able to build
> > Xen.
> > 
> > Wei.

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

Re: [Xen-devel] [PATCH V3] Xen/Keyhandler: Rework process of nonirq keyhandler

[Jan Beulich]

>>> On 13.10.16 at 12:06,  wrote:
> Keyhandler may run for a long time in serial port driver's
> timer handler on the large machine with a lot of physical
> cpus(e,g dump_timerq()) when serial port driver works in
> the poll mode(via the exception mechanism).
> 
> If a timer handler runs a long time, it will block nmi_timer_fn()
> to feed NMI watchdog and cause Xen hypervisor panic. Inserting
> process_pending_softirqs() in timer handler will not help. when timer
> interrupt arrives, timer subsystem calls all expired timer handlers
> before programming next timer interrupt. There is no timer interrupt
> arriving to trigger timer softirq during run a timer handler.
> 
> This patch is to fix the issue to make nonirq keyhandler run in
> tasklet when receive debug key from serial port.
> 
> Signed-off-by: Lan Tianyu 

Reviewed-by: Jan Beulich 
with ...

> --- a/xen/include/xen/keyhandler.h
> +++ b/xen/include/xen/keyhandler.h
> @@ -46,7 +46,9 @@ void register_irq_keyhandler(unsigned char key,
>   bool_t diagnostic);
>  
>  /* Inject a keypress into the key-handling subsystem. */
> -extern void handle_keypress(unsigned char key, struct cpu_user_regs *regs);
> +extern void handle_keypress(unsigned char key,
> + struct cpu_user_regs *regs,
> + bool async);

... this also changed to force_tasklet. I guess the committer could,
easily do that, but otoh I'm not sure we want/need this for 4.8 - Wei?

Jan


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

Re: [Xen-devel] per-domain logging

[Cedric Bosdonnat]

Hi Wei, Ian,

In quite a number of places, the domid we have in the function calling LOG*
may be the one of a stubdom. In the log we want to output the domid of the
domain the user knows about. Would there be a way to get it?

An example of that is do_pci_add. It has a libxl_is_stubdom call, suggesting
that domid may not be the real domain id. An I wonder if there are other
places where domid may be the one of a stubdom and I don't know it.

--
Cedric

On Mon, 2016-10-10 at 11:06 +0100, Wei Liu wrote:
> On Mon, Oct 10, 2016 at 09:03:49AM +0200, Cedric Bosdonnat wrote:
> > On Fri, 2016-10-07 at 15:09 +0100, Wei Liu wrote:
> > > Instead of trying to change all the format strings I think it would be
> > > better to have a new set of LOG macros that takes domid.
> > > 
> > > Something like:
> > >   LOGEVD(ERROR, errno, domid, "");
> > 
> > 
> > Sounds good to me, even if LOGEVD will just concatenate something like
> > "Domain %d: " to the "". At least this would be much cleaner in the
> > libxl code
> > 
> > > I would also like to have the log format written down in some document
> > > or header file.
> > 
> > 
> > You mean as a documentation? That would be in libxl, not in xtl, right?
> > We could have a comment above the LOG*D macros explaining what the message
> > will look like (Prepending 'Domain %d: " to the message passed to normal log
> > functions). And a comment on top of the current functions explaining all the
> > different things that are passed on to xtl.
> > 
> 
> 
> Presumably you will define LOG*D variants in libxl_internal.h, I think a
> comment there right before those macros will be good enough.
> 
> > > But let's step back a bit: have we agreed on the approach forward? This
> > > thread doesn't seem to have a clear conclusion yet.  Obviously I don't
> > > want you to waste your writing code that's going to be threw away.
> > 
> > 
> > I don't want to loose time either, but sometimes it's better to write some
> > code to check that what we are mentioning is possible.
> > 
> > > If you're happy with demuxing in libvirt, I won't object to it. Looks
> > > like there is relatively less code churn involved than other solutions,
> > > say, libxl keeping track of a set of per-domain xtl loggers.
> > 
> > 
> > Having a set of per-domain xtl logger is also possible, but with one logger
> > demuxing all messages, it's fairly easy to support both old log format
> > and new ones. And the format we get in the callbacks from libxl is something
> > like "%s%s%s%s%s", with things like file, line, function and message. Thus
> > adding a domain in there doesn't make much sense. I'ld more in favor of the
> > LOG*D family in libxl.
> > 
> 
> 
> Sure, fine by me.
> 
> Wei.
> 
> > --
> > Cedric
> 
> 
> 

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

Re: [Xen-devel] PCIe devices that are hotplugged after MMIO has been setup fail due to _CRS not covering 64-bit area

[Jan Beulich]

>>> On 12.10.16 at 23:15,  wrote:
> On Wed, Sep 28, 2016 at 03:21:08AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 16:43,  wrote:
>> > If the guest is booted with 'pci' we nicely expand the MMIO region below
>> > 4GB and try to fit in the BARs in there. If that fails (not enough
>> > space) we move it above the memory (64-bit). And throughout all of this
>> > we also update the _CRS field to cover these ranges.
>> > 
>> > (Note, I need to check if the 64-bit area is also set, I think it is).
>> > 
>> > But the situation is different if we hot-plug a device that has too big
>> > BAR to fit in the MMIO region. We move it in the 64-bit area but we
>> > don't update the _CRS. Which means that Linux will complain (unless
>> > booted with pci=nocrs)). Not sure about Windows but I would assume so
>> > to.
>> > 
>> > I was wondering what would be a good way to solve this? I looked at some
>> > Dell machines to see how they deal with hotplug PCIe devices and they
>> > just declared all the memory in the _CRS (including RAM).
>> > 
>> > We could do a hybrid - during bootup make the _CRS region have entry from
>> > end of RAM to .. end of memory?
>> 
>> End of physical address space you mean? Generally yes, but we
>> need to be a little careful there: For one, on AMD we'd better not
>> overlap with the HT area. And then there's this MTRR related
>> comment next to the setting of pci_hi_mem_end (albeit both HT
>> area start and end of PA space should be aligned well enough).
>> 
>> > Or perhaps add some extra logic between QEMU and ACPI AML to expand (or
>> > perhaps modify the last _CRS entry) when PCIe devices are hotplugged?
>> 
>> While that would be the most flexible variant, I'd be afraid of this
>> getting rather complicated. Or have you already got some
>> reasonable layout of how this would look like?
> 
> I did this and while all the plumbing works great and I can see that
> the pci_hi_len gets incremented by the size of the 64-bit BARS of the
> new device (and also decremented if hot-unplugged) I hit a snag:
> 
> Linux evaluates this only once (actually twice, but only during bootup).

Ah - quite reasonable to expect this won't change.

> For right now let me jump with the "simpler" solution of just
> hardcoding the end of physical address space and see how that works out.

Right.

Jan


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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Wei Liu]

On Thu, Oct 13, 2016 at 03:15:09AM -0600, Jan Beulich wrote:
> >>> On 13.10.16 at 10:49,  wrote:
> > On Thu, Oct 13, 2016 at 02:29:08AM -0600, Jan Beulich wrote:
> > [...]
> >> >> >> ... this structure's trailing fields actually getting used by the 
> >> >> >> code
> >> >> >> won't work well when changing compiler versions without cleaning
> >> >> >> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c
> >> >> >> #define-ing their GCOV_COUNTERS and then #include-ing this
> >> >> >> shared source file. Plus btw, I don't think gcc 5.0.x (the
> >> >> >> development variant of 5.x) would use anything different from
> >> >> >> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
> >> >> >> normally be necessary anymore with gcc 5+.
> >> >> >> 
> >> >> > 
> >> >> > I think you misread here: __GNUC_MINOR__ is the "x" part of 5.x.y, the
> >> >> > "y" part is __GNUC_PATCHLEVEL__.
> >> >> 
> >> >> No, I didn't. From 5.x onwards the information previously carried in
> >> >> __GNUC_PATCHLEVEL__ is now in __GNUC_MINOR__. And as much
> >> >> as previously you would not normally need to look at the former,
> >> >> with newer gcc you shouldn't need to look at the latter.
> >> >> 
> >> > 
> >> > I can't find relevant information in GCC cpp manual.
> >> > 
> >> > Specifically, I look at 4.9.4 and 5.4.0 doc:
> >> > 
> >> > 
> > https://gcc.gnu.org/onlinedocs/gcc-4.9.4/cpp/Common-Predefined-Macros.html#Comm
> >  
> > 
> >> > on-Predefined-Macros
> >> > 
> > https://gcc.gnu.org/onlinedocs/gcc-5.4.0/cpp/Common-Predefined-Macros.html#Comm
> >  
> > 
> >> > on-Predefined-Macros
> >> > 
> >> > The sections about __GNUC_* macros are identical, their semantics stay
> >> > the same.
> >> > 
> >> > What did I miss?
> >> 
> >> Their change in how version numbers get used. I'm sure you've noticed
> >> there never was a released 5.0.0 or 6.0.0, and that the stable updates
> >> following 5.1.0 were 5.2.0, 5.3.0, etc.
> >> 
> > 
> > OK. I found the bits at https://gcc.gnu.org/develop.html. I see what you
> > meant previously.
> > 
> > It doesn't seem to be a problem to me to compare to 5.1 though -- that's
> > the first release of gcc 5, which should be what people use anyway.
> 
> But your check should cover the introduction point of the feature,
> which is 5.0.0 imo.
> 
> > If it is the complexity of the macro that concerns you, now it has been
> > changed to use GCC_VERSION macro in gcov.h, which is a lot simpler to
> > reason about. Are you happy with such arrangement?
> 
> If you mean this to be an adjustment newer than v3, then I think
> I'd be fine with that, provided you cover the full range (as indicated
> above), i.e. starting at 5.0.0.
> 

OK. The check is now like:

#if GCC_VERSION < 5
#error "Wrong version of GCC used to compile gcov"
#endif

GCC_VERSION is a convenient marco that you can find in this patch.

Then all reference to gcc 5.1 will be changed to gcc 5.

Wei.

> Jan
> 

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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Jan Beulich]

>>> On 13.10.16 at 10:49,  wrote:
> On Thu, Oct 13, 2016 at 02:29:08AM -0600, Jan Beulich wrote:
> [...]
>> >> >> ... this structure's trailing fields actually getting used by the code
>> >> >> won't work well when changing compiler versions without cleaning
>> >> >> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c
>> >> >> #define-ing their GCOV_COUNTERS and then #include-ing this
>> >> >> shared source file. Plus btw, I don't think gcc 5.0.x (the
>> >> >> development variant of 5.x) would use anything different from
>> >> >> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
>> >> >> normally be necessary anymore with gcc 5+.
>> >> >> 
>> >> > 
>> >> > I think you misread here: __GNUC_MINOR__ is the "x" part of 5.x.y, the
>> >> > "y" part is __GNUC_PATCHLEVEL__.
>> >> 
>> >> No, I didn't. From 5.x onwards the information previously carried in
>> >> __GNUC_PATCHLEVEL__ is now in __GNUC_MINOR__. And as much
>> >> as previously you would not normally need to look at the former,
>> >> with newer gcc you shouldn't need to look at the latter.
>> >> 
>> > 
>> > I can't find relevant information in GCC cpp manual.
>> > 
>> > Specifically, I look at 4.9.4 and 5.4.0 doc:
>> > 
>> > 
> https://gcc.gnu.org/onlinedocs/gcc-4.9.4/cpp/Common-Predefined-Macros.html#Comm
>  
> 
>> > on-Predefined-Macros
>> > 
> https://gcc.gnu.org/onlinedocs/gcc-5.4.0/cpp/Common-Predefined-Macros.html#Comm
>  
> 
>> > on-Predefined-Macros
>> > 
>> > The sections about __GNUC_* macros are identical, their semantics stay
>> > the same.
>> > 
>> > What did I miss?
>> 
>> Their change in how version numbers get used. I'm sure you've noticed
>> there never was a released 5.0.0 or 6.0.0, and that the stable updates
>> following 5.1.0 were 5.2.0, 5.3.0, etc.
>> 
> 
> OK. I found the bits at https://gcc.gnu.org/develop.html. I see what you
> meant previously.
> 
> It doesn't seem to be a problem to me to compare to 5.1 though -- that's
> the first release of gcc 5, which should be what people use anyway.

But your check should cover the introduction point of the feature,
which is 5.0.0 imo.

> If it is the complexity of the macro that concerns you, now it has been
> changed to use GCC_VERSION macro in gcov.h, which is a lot simpler to
> reason about. Are you happy with such arrangement?

If you mean this to be an adjustment newer than v3, then I think
I'd be fine with that, provided you cover the full range (as indicated
above), i.e. starting at 5.0.0.

Jan


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

Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit

[Juergen Schinker]

Right and still no solution 

there is no xz-dev or libxz-dev;  I installed everything which just looks 
remote like xz or lzma

building is no problem as I build with

./configure --enable-githttp --enable-systemd --disable-rombios 
--disable-qemu-traditional --disable-stubdom --disable-docs


I'm thinking of building a special VM with only stable Debian and old gcc and 
old everything - Pepperidge Farm remembers

and build there

- On 13 Oct, 2016, at 09:04, Wei Liu wei.l...@citrix.com wrote:

> I don't think it breaks building Xen -- you just can't decompress xz
> format file, right? Otherwise Juergen would not have been able to build
> Xen.
> 
> Wei.

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

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Jan Beulich]

>>> On 13.10.16 at 10:53,  wrote:
> On 10/13/16 02:34 -0600, Jan Beulich wrote:
> On 12.10.16 at 18:19,  wrote:
>>> On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich  wrote:
>>> On 12.10.16 at 17:42,  wrote:
> On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich  wrote:
> On 12.10.16 at 16:58,  wrote:
>>> On 10/12/16 05:32 -0600, Jan Beulich wrote:
>>> On 12.10.16 at 12:33,  wrote:
> The layout is shown as the following diagram.
>
> +---+---+---+--+--+
> | whatever used | Partition | Super | Reserved | /dev/pmem0p1 |
> |  by kernel|   Table   | Block | for Xen  |  |
> +---+---+---+--+--+
> \_ ___/
>   V
>  /dev/pmem0

I have to admit that I dislike this, for not being OS-agnostic.
Neither should there be any Xen-specific region, nor should the
"whatever used by kernel" one be restricted to just Linux. What
I could see is an OS-reserved area ahead of the partition table,
the exact usage of which depends on which OS is currently
running (and in the Xen case this might be both Xen _and_ the
Dom0 kernel, arbitrated by a tbd protocol). After all, when
running under Xen, the Dom0 may not have a need for as much
control data as it has when running on bare hardware, for it
controlling less (if any) of the actual memory ranges when Xen
is present.

>>>
>>> Isn't this OS-reserved area still not OS-agnostic, as it requires OS
>>> to know where the reserved area is?  Or do you mean it's not if it's
>>> defined by a protocol that is accepted by all OSes?
>>
>> The latter - we clearly won't get away without some agreement on
>> where to retrieve position and size of this area. I was simply
>> assuming that such a protocol already exists.
>>
>
> No, we should not mix the struct page reservation that the Dom0 kernel
> may actively use with the Xen reservation that the Dom0 kernel does
> not consume.  Explain again what is wrong with the partition approach?

 Not sure what was unclear in my previous reply. I don't think there
 should be apriori knowledge of whether Xen is (going to be) used on
 a system, and even if it gets used, but just occasionally, it would
 (apart from the abstract considerations already given) be a waste
 of resources to set something aside that could be used for other
 purposes while Xen is not running. Static partitioning should only be
 needed for persistent data.
>>>
>>> The reservation needs to be persistent / static even if the data is
>>> volatile, as is the case with struct page, because we can't have the
>>> size of the device change depending on use.  So, from the aspect of
>>> wasting space while Xen is not in use, both partitions and the
>>> intrinsic reservation approach suffer the same problem. Setting that
>>> aside I don't want to mix 2 different use cases into the same
>>> reservation.
>>
>>Then you didn't understand what I've said: I certainly didn't mean
>>the reservation to vary from a device perspective. However, when
>>Xen is in use I don't see why part of that static reservation couldn't
>>be used by Xen, and another part by the Dom0 kernel. The kernel
>>obviously would need to ask the hypervisor how much of the space
>>is left, and where that area starts.
>>
> 
> I think Dan means that there should be a clear separation between
> reservations for different usages (kernel/xen/...). The libnvdimm
> driver is for the linux kernel and only needs to maintain the
> reservation for kernel functionality. For others including xen/dm/...,
> if they want reservation for their own purpose, they should maintain
> their own reservations out of libnvdimm driver and avoid bothering the
> libnvdimm driver (e.g. add specific handling in libnvdimm driver).
> 
> IIUC, one existing example is device-mapper device (dm) which needs to
> reserve on-device area for its own meta-data. Its choice is to store
> the meta-data on the block device (/dev/pmemN) provided by the
> libnvdimm driver.
> 
> I think we can do the similar for Xen, like to lay another pseudo
> device on /dev/pmem and do the reservation, like 2. in my previous
> reply.

Well, my opinion certainly doesn't count much here, but I continue to
consider this a bad idea. For entities like drivers it may well be
appropriate, but I think there ought to be an independent concept
of "OS reserved", and in the Xen case this could then be shared
between hypervisor and Dom0 kernel. Or if we 

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Haozhong Zhang]

+Dan Williams

I accidentally dropped him in my last reply. Add him back.

On 10/13/16 16:53 +0800, Haozhong Zhang wrote:

On 10/13/16 02:34 -0600, Jan Beulich wrote:

On 12.10.16 at 18:19,  wrote:

On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich  wrote:

On 12.10.16 at 17:42,  wrote:

On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich  wrote:

On 12.10.16 at 16:58,  wrote:

On 10/12/16 05:32 -0600, Jan Beulich wrote:

On 12.10.16 at 12:33,  wrote:

The layout is shown as the following diagram.

+---+---+---+--+--+
| whatever used | Partition | Super | Reserved | /dev/pmem0p1 |
|  by kernel|   Table   | Block | for Xen  |  |
+---+---+---+--+--+
   \_ ___/
 V
/dev/pmem0


I have to admit that I dislike this, for not being OS-agnostic.
Neither should there be any Xen-specific region, nor should the
"whatever used by kernel" one be restricted to just Linux. What
I could see is an OS-reserved area ahead of the partition table,
the exact usage of which depends on which OS is currently
running (and in the Xen case this might be both Xen _and_ the
Dom0 kernel, arbitrated by a tbd protocol). After all, when
running under Xen, the Dom0 may not have a need for as much
control data as it has when running on bare hardware, for it
controlling less (if any) of the actual memory ranges when Xen
is present.



Isn't this OS-reserved area still not OS-agnostic, as it requires OS
to know where the reserved area is?  Or do you mean it's not if it's
defined by a protocol that is accepted by all OSes?


The latter - we clearly won't get away without some agreement on
where to retrieve position and size of this area. I was simply
assuming that such a protocol already exists.



No, we should not mix the struct page reservation that the Dom0 kernel
may actively use with the Xen reservation that the Dom0 kernel does
not consume.  Explain again what is wrong with the partition approach?


Not sure what was unclear in my previous reply. I don't think there
should be apriori knowledge of whether Xen is (going to be) used on
a system, and even if it gets used, but just occasionally, it would
(apart from the abstract considerations already given) be a waste
of resources to set something aside that could be used for other
purposes while Xen is not running. Static partitioning should only be
needed for persistent data.


The reservation needs to be persistent / static even if the data is
volatile, as is the case with struct page, because we can't have the
size of the device change depending on use.  So, from the aspect of
wasting space while Xen is not in use, both partitions and the
intrinsic reservation approach suffer the same problem. Setting that
aside I don't want to mix 2 different use cases into the same
reservation.


Then you didn't understand what I've said: I certainly didn't mean
the reservation to vary from a device perspective. However, when
Xen is in use I don't see why part of that static reservation couldn't
be used by Xen, and another part by the Dom0 kernel. The kernel
obviously would need to ask the hypervisor how much of the space
is left, and where that area starts.



I think Dan means that there should be a clear separation between
reservations for different usages (kernel/xen/...). The libnvdimm
driver is for the linux kernel and only needs to maintain the
reservation for kernel functionality. For others including xen/dm/...,
if they want reservation for their own purpose, they should maintain
their own reservations out of libnvdimm driver and avoid bothering the
libnvdimm driver (e.g. add specific handling in libnvdimm driver).

IIUC, one existing example is device-mapper device (dm) which needs to
reserve on-device area for its own meta-data. Its choice is to store
the meta-data on the block device (/dev/pmemN) provided by the
libnvdimm driver.

I think we can do the similar for Xen, like to lay another pseudo
device on /dev/pmem and do the reservation, like 2. in my previous
reply.

Thanks,
Haozhong


The kernel needs to know about the struct page reservation because it
needs to manage the lifetime of page references vs the lifetime of the
device.  It does not have the same relationship with a Xen reservation
which is why I'm proposing they be managed separately.


I don't think I understand the difference you try to point out here.
Linux'es struct page and Xen's struct page_info serve the same
fundamental purpose.

Jan


___
Linux-nvdimm mailing list
linux-nvd...@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm


___
Xen-devel mailing list

Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit

[Wei Liu]

On Wed, Oct 12, 2016 at 05:03:11PM -0400, Boris Ostrovsky wrote:
> On 10/12/2016 05:27 AM, Wei Liu wrote:
> > On Tue, Oct 11, 2016 at 08:31:31PM +0100, Juergen Schinker wrote:
> >>  
> >>> We're going to tag rc2 some time this week. Thanks for help testing Xen!
> >>>
> >>> Wei.
> >>>
>  J
> 
>  - On 11 Oct, 2016, at 09:37, Wei Liu wei.l...@citrix.com wrote:
> 
> > No, you can try to work around this issue by appending --disable-rombios
> > to your ./configure invocation. You can test major functionalities of
> > Xen just fine without rombios.
> >
> > Wei.
> >> Now for the fun of it I tried the RELEASE-4.7 
> >>
> >> and it turns out it has no support for xz-decompression 
> >>
> > That's probably because you don't have libzx development package
> > installed when building Xen.
> 
> 
> Which would be a new requirement for building Xen. And it broke our
> (pre-historic) build server that never had it installed.
> 

I don't think it breaks building Xen -- you just can't decompress xz
format file, right? Otherwise Juergen would not have been able to build
Xen.

Wei.

> -boris
> 
> 
> >
> >> so it can't decompress the kernel via pygrub
> >>
> >> what
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > https://lists.xen.org/xen-devel
> 
> 

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

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Haozhong Zhang]

On 10/13/16 02:34 -0600, Jan Beulich wrote:

On 12.10.16 at 18:19,  wrote:

On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich  wrote:

On 12.10.16 at 17:42,  wrote:

On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich  wrote:

On 12.10.16 at 16:58,  wrote:

On 10/12/16 05:32 -0600, Jan Beulich wrote:

On 12.10.16 at 12:33,  wrote:

The layout is shown as the following diagram.

+---+---+---+--+--+
| whatever used | Partition | Super | Reserved | /dev/pmem0p1 |
|  by kernel|   Table   | Block | for Xen  |  |
+---+---+---+--+--+
\_ ___/
  V
 /dev/pmem0


I have to admit that I dislike this, for not being OS-agnostic.
Neither should there be any Xen-specific region, nor should the
"whatever used by kernel" one be restricted to just Linux. What
I could see is an OS-reserved area ahead of the partition table,
the exact usage of which depends on which OS is currently
running (and in the Xen case this might be both Xen _and_ the
Dom0 kernel, arbitrated by a tbd protocol). After all, when
running under Xen, the Dom0 may not have a need for as much
control data as it has when running on bare hardware, for it
controlling less (if any) of the actual memory ranges when Xen
is present.



Isn't this OS-reserved area still not OS-agnostic, as it requires OS
to know where the reserved area is?  Or do you mean it's not if it's
defined by a protocol that is accepted by all OSes?


The latter - we clearly won't get away without some agreement on
where to retrieve position and size of this area. I was simply
assuming that such a protocol already exists.



No, we should not mix the struct page reservation that the Dom0 kernel
may actively use with the Xen reservation that the Dom0 kernel does
not consume.  Explain again what is wrong with the partition approach?


Not sure what was unclear in my previous reply. I don't think there
should be apriori knowledge of whether Xen is (going to be) used on
a system, and even if it gets used, but just occasionally, it would
(apart from the abstract considerations already given) be a waste
of resources to set something aside that could be used for other
purposes while Xen is not running. Static partitioning should only be
needed for persistent data.


The reservation needs to be persistent / static even if the data is
volatile, as is the case with struct page, because we can't have the
size of the device change depending on use.  So, from the aspect of
wasting space while Xen is not in use, both partitions and the
intrinsic reservation approach suffer the same problem. Setting that
aside I don't want to mix 2 different use cases into the same
reservation.


Then you didn't understand what I've said: I certainly didn't mean
the reservation to vary from a device perspective. However, when
Xen is in use I don't see why part of that static reservation couldn't
be used by Xen, and another part by the Dom0 kernel. The kernel
obviously would need to ask the hypervisor how much of the space
is left, and where that area starts.



I think Dan means that there should be a clear separation between
reservations for different usages (kernel/xen/...). The libnvdimm
driver is for the linux kernel and only needs to maintain the
reservation for kernel functionality. For others including xen/dm/...,
if they want reservation for their own purpose, they should maintain
their own reservations out of libnvdimm driver and avoid bothering the
libnvdimm driver (e.g. add specific handling in libnvdimm driver).

IIUC, one existing example is device-mapper device (dm) which needs to
reserve on-device area for its own meta-data. Its choice is to store
the meta-data on the block device (/dev/pmemN) provided by the
libnvdimm driver.

I think we can do the similar for Xen, like to lay another pseudo
device on /dev/pmem and do the reservation, like 2. in my previous
reply.

Thanks,
Haozhong


The kernel needs to know about the struct page reservation because it
needs to manage the lifetime of page references vs the lifetime of the
device.  It does not have the same relationship with a Xen reservation
which is why I'm proposing they be managed separately.


I don't think I understand the difference you try to point out here.
Linux'es struct page and Xen's struct page_info serve the same
fundamental purpose.

Jan



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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Wei Liu]

On Thu, Oct 13, 2016 at 02:29:08AM -0600, Jan Beulich wrote:
[...]
> >> >> ... this structure's trailing fields actually getting used by the code
> >> >> won't work well when changing compiler versions without cleaning
> >> >> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c
> >> >> #define-ing their GCOV_COUNTERS and then #include-ing this
> >> >> shared source file. Plus btw, I don't think gcc 5.0.x (the
> >> >> development variant of 5.x) would use anything different from
> >> >> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
> >> >> normally be necessary anymore with gcc 5+.
> >> >> 
> >> > 
> >> > I think you misread here: __GNUC_MINOR__ is the "x" part of 5.x.y, the
> >> > "y" part is __GNUC_PATCHLEVEL__.
> >> 
> >> No, I didn't. From 5.x onwards the information previously carried in
> >> __GNUC_PATCHLEVEL__ is now in __GNUC_MINOR__. And as much
> >> as previously you would not normally need to look at the former,
> >> with newer gcc you shouldn't need to look at the latter.
> >> 
> > 
> > I can't find relevant information in GCC cpp manual.
> > 
> > Specifically, I look at 4.9.4 and 5.4.0 doc:
> > 
> > https://gcc.gnu.org/onlinedocs/gcc-4.9.4/cpp/Common-Predefined-Macros.html#Comm
> >  
> > on-Predefined-Macros
> > https://gcc.gnu.org/onlinedocs/gcc-5.4.0/cpp/Common-Predefined-Macros.html#Comm
> >  
> > on-Predefined-Macros
> > 
> > The sections about __GNUC_* macros are identical, their semantics stay
> > the same.
> > 
> > What did I miss?
> 
> Their change in how version numbers get used. I'm sure you've noticed
> there never was a released 5.0.0 or 6.0.0, and that the stable updates
> following 5.1.0 were 5.2.0, 5.3.0, etc.
> 

OK. I found the bits at https://gcc.gnu.org/develop.html. I see what you
meant previously.

It doesn't seem to be a problem to me to compare to 5.1 though -- that's
the first release of gcc 5, which should be what people use anyway.

If it is the complexity of the macro that concerns you, now it has been
changed to use GCC_VERSION macro in gcov.h, which is a lot simpler to
reason about. Are you happy with such arrangement?

If you feel strongly about this version comparison thing, I'm fine with
just comparing it to the major number, too.

Wei.

> Jan
> 

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

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Jan Beulich]

>>> On 12.10.16 at 18:19,  wrote:
> On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich  wrote:
> On 12.10.16 at 17:42,  wrote:
>>> On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich  wrote:
>>> On 12.10.16 at 16:58,  wrote:
> On 10/12/16 05:32 -0600, Jan Beulich wrote:
> On 12.10.16 at 12:33,  wrote:
>>> The layout is shown as the following diagram.
>>>
>>> +---+---+---+--+--+
>>> | whatever used | Partition | Super | Reserved | /dev/pmem0p1 |
>>> |  by kernel|   Table   | Block | for Xen  |  |
>>> +---+---+---+--+--+
>>> \_ ___/
>>>   V
>>>  /dev/pmem0
>>
>>I have to admit that I dislike this, for not being OS-agnostic.
>>Neither should there be any Xen-specific region, nor should the
>>"whatever used by kernel" one be restricted to just Linux. What
>>I could see is an OS-reserved area ahead of the partition table,
>>the exact usage of which depends on which OS is currently
>>running (and in the Xen case this might be both Xen _and_ the
>>Dom0 kernel, arbitrated by a tbd protocol). After all, when
>>running under Xen, the Dom0 may not have a need for as much
>>control data as it has when running on bare hardware, for it
>>controlling less (if any) of the actual memory ranges when Xen
>>is present.
>>
>
> Isn't this OS-reserved area still not OS-agnostic, as it requires OS
> to know where the reserved area is?  Or do you mean it's not if it's
> defined by a protocol that is accepted by all OSes?

 The latter - we clearly won't get away without some agreement on
 where to retrieve position and size of this area. I was simply
 assuming that such a protocol already exists.

>>>
>>> No, we should not mix the struct page reservation that the Dom0 kernel
>>> may actively use with the Xen reservation that the Dom0 kernel does
>>> not consume.  Explain again what is wrong with the partition approach?
>>
>> Not sure what was unclear in my previous reply. I don't think there
>> should be apriori knowledge of whether Xen is (going to be) used on
>> a system, and even if it gets used, but just occasionally, it would
>> (apart from the abstract considerations already given) be a waste
>> of resources to set something aside that could be used for other
>> purposes while Xen is not running. Static partitioning should only be
>> needed for persistent data.
> 
> The reservation needs to be persistent / static even if the data is
> volatile, as is the case with struct page, because we can't have the
> size of the device change depending on use.  So, from the aspect of
> wasting space while Xen is not in use, both partitions and the
> intrinsic reservation approach suffer the same problem. Setting that
> aside I don't want to mix 2 different use cases into the same
> reservation.

Then you didn't understand what I've said: I certainly didn't mean
the reservation to vary from a device perspective. However, when
Xen is in use I don't see why part of that static reservation couldn't
be used by Xen, and another part by the Dom0 kernel. The kernel
obviously would need to ask the hypervisor how much of the space
is left, and where that area starts.

> The kernel needs to know about the struct page reservation because it
> needs to manage the lifetime of page references vs the lifetime of the
> device.  It does not have the same relationship with a Xen reservation
> which is why I'm proposing they be managed separately.

I don't think I understand the difference you try to point out here.
Linux'es struct page and Xen's struct page_info serve the same
fundamental purpose.

Jan


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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Jan Beulich]

>>> On 12.10.16 at 19:07,  wrote:
> On Wed, Oct 12, 2016 at 09:42:17AM -0600, Jan Beulich wrote:
>> >>> On 12.10.16 at 17:33,  wrote:
>> > On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
>> >> >>> On 11.10.16 at 12:31,  wrote:
>> >> > --- /dev/null
>> >> > +++ b/xen/common/gcov/gcc_4_7.c
>> >> > @@ -0,0 +1,205 @@
>> >> > +/*
>> >> > + *  This code provides functions to handle gcc's profiling data format
>> >> > + *  introduced with gcc 4.7.
>> >> > + *
>> >> > + *  This file is based heavily on gcc_3_4.c file.
>> >> > + *
>> >> > + *  For a better understanding, refer to gcc source:
>> >> > + *  gcc/gcov-io.h
>> >> > + *  libgcc/libgcov.c
>> >> > + *
>> >> > + *  Uses gcc-internal data definitions.
>> >> > + *
>> >> > + *  Imported from Linux and modified for Xen by
>> >> > + *Wei Liu 
>> >> > + */
>> >> > +
>> >> > +#include 
>> >> > +
>> >> > +#include "gcov.h"
>> >> > +
>> >> > +#if GCC_VERSION < 40700
>> >> > +#error "Wrong version of GCC used to compile gcov"
>> >> > +#endif
>> >> > +
>> >> > +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
>> >> > +#define GCOV_COUNTERS   10
>> >> > +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
>> >> > +#define GCOV_COUNTERS   9
>> >> > +#else
>> >> > +#define GCOV_COUNTERS   8
>> >> > +#endif
>> >> 
>> >> I'm sorry for not having pointed this out on v2 (I had noticed it,
>> >> but then didn't finish analyzing the situation), but I'm afraid this
>> >> together with ...
>> >> 
>> >> > +struct gcov_info {
>> >> > +unsigned int version;
>> >> > +struct gcov_info *next;
>> >> > +unsigned int stamp;
>> >> > +const char *filename;
>> >> > +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
>> >> > +unsigned int n_functions;
>> >> > +struct gcov_fn_info **functions;
>> >> > +};
>> >> 
>> >> ... this structure's trailing fields actually getting used by the code
>> >> won't work well when changing compiler versions without cleaning
>> >> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c
>> >> #define-ing their GCOV_COUNTERS and then #include-ing this
>> >> shared source file. Plus btw, I don't think gcc 5.0.x (the
>> >> development variant of 5.x) would use anything different from
>> >> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
>> >> normally be necessary anymore with gcc 5+.
>> >> 
>> > 
>> > I think you misread here: __GNUC_MINOR__ is the "x" part of 5.x.y, the
>> > "y" part is __GNUC_PATCHLEVEL__.
>> 
>> No, I didn't. From 5.x onwards the information previously carried in
>> __GNUC_PATCHLEVEL__ is now in __GNUC_MINOR__. And as much
>> as previously you would not normally need to look at the former,
>> with newer gcc you shouldn't need to look at the latter.
>> 
> 
> I can't find relevant information in GCC cpp manual.
> 
> Specifically, I look at 4.9.4 and 5.4.0 doc:
> 
> https://gcc.gnu.org/onlinedocs/gcc-4.9.4/cpp/Common-Predefined-Macros.html#Comm
>  
> on-Predefined-Macros
> https://gcc.gnu.org/onlinedocs/gcc-5.4.0/cpp/Common-Predefined-Macros.html#Comm
>  
> on-Predefined-Macros
> 
> The sections about __GNUC_* macros are identical, their semantics stay
> the same.
> 
> What did I miss?

Their change in how version numbers get used. I'm sure you've noticed
there never was a released 5.0.0 or 6.0.0, and that the stable updates
following 5.1.0 were 5.2.0, 5.3.0, etc.

Jan


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

Re: [Xen-devel] [PATCH 15/15] xen: Rename xen_be_frontend_changed

[Paolo Bonzini]

> So we are better leave it as is. Maybe we need to rename some functions in
> that file.
>  __iirc__ adding xen_frontend.c is one of Stefano's comments in previous v6
>  or v7..

I agree; it's quite possible that code can be shared between backend and
frontend (renaming functions as needed), and it's good to have a generic
xen frontend mechanism instead of something specific to TPM.

Paolo

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

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

[Platform Team regression test user]

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

Perfect :-)
All tests in this flight passed as required
baseline version:
 flight   67812

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



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

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

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


Push not applicable.


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

[Xen-devel] [ovmf baseline-only test] 67870: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67870 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67870/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf a12b214ef9e002b3b7a7f7845bb025a2a8597dcc
baseline version:
 ovmf 50d4be4f4e3d5beb2c1aa58853b92e3cc1f4cb9a

Last test of basis67869  2016-10-12 15:49:42 Z0 days
Testing same since67870  2016-10-13 06:23:21 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Fu Siyuan 
  Giri P Mudusuru 
  Laszlo Ersek 
  Liming Gao 
  Ruiyu Ni 

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



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

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

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


Push not applicable.


commit a12b214ef9e002b3b7a7f7845bb025a2a8597dcc
Author: Liming Gao 
Date:   Sun Oct 9 10:20:30 2016 +0800

MdeModulePkg RegularExpressionDxe: Add the missing EFIAPI for the function

The function with the variable parameters should have EFIAPI.

Cc: Feng Tian 
Cc: Cinnamon Shia 
Cc: Cecil Sheng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Feng Tian 

commit d9c86bee92be2d95aad6583d9f591fa94cd35037
Author: Liming Gao 
Date:   Tue Oct 11 09:44:07 2016 +0800

DuetPkg DxeIpl and EfiLdr: Add the missing EFIAPI for the function

The function with the variable parameters should have EFIAPI.

Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Ruiyu Ni 

commit c3aa61b571b89223bd2b47b8769c169e2ced91f6
Author: Giri P Mudusuru 
Date:   Tue Oct 11 21:58:46 2016 -0700

IntelSiliconPkg: Fixing syntax bug in IGD_OPREGION_HEADER

Added missing ; for DVER in IGD_OPREGION_HEADER

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Giri P Mudusuru 
Reviewed-by: Jiewen Yao 

commit e294f58e69983624b8b1eef2b2e28983fa42421d
Author: Ruiyu Ni 
Date:   Tue Oct 11 13:00:48 2016 +0800

MdeModulePkg/MdeModulePkg.dec: Fix EBC build failure of PciBus driver

When PciBus is built as EBC, PcdPciDegradeResourceForOptionRom does
not have associated value resulting build failure.
The patch sets the default value to TRUE, covering the EBC ARCH.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Acked-by: Laszlo Ersek 
Acked-by: Ard Biesheuvel 
Reviewed-by: Feng Tian 

commit 3c0956379cb42d9262363b0a70b26d1ad02b7fc3
Author: Fu Siyuan 
Date:   Tue Sep 13 10:25:27 2016 +0800

NetworkPkg: Remove redundant code in HTTP boot driver.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
Reviewed-by: Sriram Subramanian 
Reviewed-by: Wu Jiaxin 
Reviewed-by: Zhang Lubo 

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

[Xen-devel] [linux-4.1 test] 101401: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeatfail  like 101004
 test-armhf-armhf-xl  15 guest-start/debian.repeatfail  like 101004
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeatfail  like 101004
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat   fail like 101004
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101004
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101004
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101004
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101004
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 101004
 test-armhf-armhf-xl-vhd   9 debian-di-installfail  like 101004

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass

version targeted for testing:
 linux91473db3a3257eacead8f4d84cf4bc96c447193f
baseline version:
 linux04cb720142764ebf3786eba1feb8fc4b6ef87fcf

Last test of basis   101004  2016-09-18 15:44:49 Z   24 days
Testing same since   101390  2016-10-12 06:51:19 Z1 days2 attempts


People who touched revisions under test:
  Akshay Bhat 
  Al Viro 
  Alan Stern 
  Andrew Morton 
  Anson Huang 
  Ard Biesheuvel 
  Ashish Samant 
  Balbir Singh 
  Benjamin Herrenschmidt 
  Boris Brezillon 
  Catalin Marinas 
  Chris Mason 
  Christoffer Dall 
  Clemens Gruber 
  Daniele Palmas 
  Dave Airlie 
  David S. Miller 
  Eric Biggers