date:20160811

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

2016-08-11 Thread osstest service owner

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   5 xen-buildfail REGR. vs. 100381

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-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

version targeted for testing:
 libvirt  9aea8cd4ae76b5f62ea365dd56d4d9beb96bb024
baseline version:
 libvirt  5b8643099a99dc4ee0dac4bf543a874ffc4c314f

Last test of basis   100381  2016-08-10 04:20:25 Z1 days
Testing same since   100404  2016-08-11 04:20:33 Z0 days1 attempts


People who touched revisions under test:
  Chen Hanxiao 
  Cole Robinson 
  Erik Skultety 
  Jiri Denemark 
  Laine Stump 
  Michal Privoznik 

jobs:
 build-amd64-xsm  fail
 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   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  blocked 
 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


Not pushing.


commit 9aea8cd4ae76b5f62ea365dd56d4d9beb96bb024
Author: Michal Privoznik 
Date:   Tue Aug 9 19:25:44 2016 +0200

virNetDevMacVLanCreateWithVPortProfile: Drop @ret

Usually, this variable is used to hold the return value for a
function of ours. Well, this is not the case. Its use does not
match our pattern and therefore it is very misleading. Drop it
and define an alternative @rc variable, but only in that single
block where it is needed.

Signed-off-by: Michal Privoznik 

commit 42712002fd49e

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

2016-08-11 Thread osstest service owner

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  6 xen-boot fail REGR. vs. 100377
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
REGR. vs. 100377
 test-amd64-amd64-xl-qemuu-win7-amd64  9 windows-install  fail REGR. vs. 100377

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail  like 100377
 build-i386-rumpuserxen6 xen-buildfail  like 100377
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100377
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100377
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100377
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100377

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

Last test of basis   100377  2016-08-10 03:02:59 Z1 days
Testing same since   100395  2016-08-10 13:47:13 Z0 days1 attempts


People who touched revisions under test:
  Boris Ostrovsky 
  George Dunlap 
  Jan Beulich 

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

Re: [Xen-devel] [BUG] kernel BUG at drivers/block/xen-blkfront.c:1711

2016-08-11 Thread Evgenii Shatokhin

On 11.08.2016 05:10, Bob Liu wrote:

On 08/10/2016 10:54 PM, Evgenii Shatokhin wrote:

On 10.08.2016 15:49, Bob Liu wrote:

On 08/10/2016 08:33 PM, Evgenii Shatokhin wrote:

On 14.07.2016 15:04, Bob Liu wrote:

On 07/14/2016 07:49 PM, Evgenii Shatokhin wrote:

On 11.07.2016 15:04, Bob Liu wrote:

On 07/11/2016 04:50 PM, Evgenii Shatokhin wrote:

On 06.06.2016 11:42, Dario Faggioli wrote:

Just Cc-ing some Linux, block, and Xen on CentOS people...

Ping.

Any suggestions how to debug this or what might cause the problem?

Obviously, we cannot control Xen on the Amazon's servers. But perhaps there is
something we can do at the kernel's side, is it?

On Mon, 2016-06-06 at 11:24 +0300, Evgenii Shatokhin wrote:

(Resending this bug report because the message I sent last week did
not
make it to the mailing list somehow.)

Hi,

One of our users gets kernel panics from time to time when he tries
to
use his Amazon EC2 instance with CentOS7 x64 in it [1]. Kernel panic
happens within minutes from the moment the instance starts. The
problem
does not show up every time, however.

The user first observed the problem with a custom kernel, but it was
found later that the stock kernel 3.10.0-327.18.2.el7.x86_64 from
CentOS7 was affected as well.

Please try this patch:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7b0767502b5db11cb1f0daef2d01f6d71b1192dc

Regards,
Bob

Unfortunately, it did not help. The same BUG_ON() in blkfront_setup_indirect()
still triggers in our kernel based on RHEL's 3.10.0-327.18.2, where I added the
patch.

As far as I can see, the patch makes sure the indirect pages are added to the list
only if (!info->feature_persistent) holds. I suppose it holds in our case and
the pages are added to the list because the triggered BUG_ON() is here:

if (!info->feature_persistent && info->max_indirect_segments) {
<...>
BUG_ON(!list_empty(&info->indirect_pages));
<...>
}

That's odd.
Could you please try to reproduce this issue with a recent upstream kernel?

Thanks,
Bob

No luck with the upstream kernel 4.7.0 so far due to unrelated issues (bad
initrd, I suppose, so the system does not even boot).

However, the problem reproduced with the stable upstream kernel 3.14.74. After
the system booted the second time with this kernel, that BUG_ON triggered:
kernel BUG at drivers/block/xen-blkfront.c:1701

Could you please provide more detail on how to reproduce this bug? I'd like to
have a test.

Thanks!
Bob

As the user says, he uses an Amazon EC2 instance. Namely: HVM CentOS7 AMI on a
c3.large instance with EBS magnetic storage.

Oh, then it would be difficult to debug this issue.
The xen-blkfront communicates with xen-blkback(in dom0 or driver domain), but
that part is a black box when running Amazon EC2.
We can't see the source code of the backend side!

Yes, and another problem is, I am still unable to reproduce the issue in
my EC2 instance. However, the problem shows up rather often in the
user's instance.

Can this bug be reproduced on your own environment(xen + dom0)?

I haven't tried this yet.

At least 2 LVM partitions are needed:
* /, 20-30 Gb should be enough, ext4
* /vz, 5-10 Gb should be enough, ext4

Kernel 3.14.74 I was talking about:
https://www.dropbox.com/s/bhus3mubza87z86/kernel-3.14.74-1.test.x86_64.rpm?dl=1

Not sure if it is relevant, but the user may have installed additional packages
from https://download.openvz.org/virtuozzo/releases/7.0-rtm/x86_64/os/
repository. Namely: vzctl, vzmigrate, vzprocps, vztt-lib, vzctcalc, ploop,
prlctl, centos-7-x86_64-ez.

After the kernel and the other mentioned packages have been installed,
the user rebooted the instance to run that kernel 3.14.74.

Then - start the instance, wait 5 minutes, stop the instance, repeat. 2-20 such
iterations were usually enough to reproduce the problem. Can be automated with
the help of Amazon's API.

BTW, before the BUG_ON triggered this time, there was the following in dmesg.
Not sure if it is related but still:

Attach the full dmesg would be better.

Well, there is not much in the part the user was able to retrieve
besides what I have sent and the BUG_ON() splat. But here it is, anyway.

Regards,
Evgenii

Regards,
Bob

--
[2.835034] scsi0 : ata_piix
[2.840317] scsi1 : ata_piix
[2.842267] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc100 irq 14
[2.845861] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc108 irq 15
[2.853840] AVX version of gcm_enc/dec engaged.
[2.859963] xen_netfront: Initialising Xen virtual ethernet driver
[2.867156] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni)
[2.885861] blkfront: xvda: barrier or flush: disabled; persistent grants:
disabled; indirect descriptors: enabled;
[2.889046] alg: No test for crc32 (crc32-pclmul)
[2.899290] xvda: xvda1
[2.997751] blkfront: xvdc: flush diskcache:

Re: [Xen-devel] Livepatch, symbol resolutions between two livepatchs (new_symbol=0)

2016-08-11 Thread Ross Lagerwall


On 08/11/2016 02:28 AM, Konrad Rzeszutek Wilk wrote:

Hey Ross,

I am running in a symbol dependency issue that I am not exactly
sure how to solve.

I have an payload that introduces a new function (xen_foobar) which
will patch over xen_extra_version().


snip


As livepatch_symbols_lookup_by_name only looks for symbols that
have the ->new_symbol set. And xen_foobar does not. So the loading is
aborted.

Which makes sense - we don't want to match the symbols as they haven't
really been "finally loaded" in.

But what if the xen_foobar is applied. In that case we should
change the xen_foobar to be new_symbol=1?


I think you're confused about the purpose of new_symbol. The purpose is 
to ensure that you link against the correct symbol from the base 
hypervisor or the live patch that first introduced it. So, new_symbol=0 
is when a symbol overrides an existing symbol. new_symbol=1 is set when 
a symbol is new introduced in a live patch.


Since all the linking happens during load and not apply, it is perfectly 
OK to link against a symbol that hasn't been applied -- the dependencies 
are there to ensure that you can't apply a patch which links against 
unapplied symbols.


The assumption is that when overriding an existing symbol, the symbol in 
the payload has the same name as the one it is overriding. You're having 
issues above because you're breaking this assumption.




This following patch does that, but I am wondering if there is a better
way?


The patch is misusing new_symbol for something completely different from 
how it was intended so I hope there is a better way :-P




P.S.
The reason for this is that I am trying to implement NOP patching.
And to have some regression testing of this I wrote an function
(xen_foobar) which calls two functions: foo and bar - and their output is what
the call to XENVER_extra_version will show (b/c we patch over
xen_extra_version()).

Then there is another payload - which will want to NOP the call to
the 'bar' function inside xen_foobar. And for that I need to be able to
lookup the symbol of xen_foobar.


This is quite a different use case from what currently exists. Currently 
we're only ever interested in writing over the start of the function 
pointed to by a symbol from the base hypervisor or first instance of a 
symbol in a live patch (aka new_symbol=1). Now you need to be able to 
lookup and write over an arbitrary symbol -- how do you choose between 
the n different loaded versions of the same symbol?


I must admit to not seeing the point in NOP patching. It just seems to 
be a special case of arbitrary data patching that could be more easily 
achieved using other means.


Let's have a discussion about this and the symbol issues here at the Xen 
Summit in a couple of weeks time.


--
Ross Lagerwall

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

Re: [Xen-devel] [PATCH v2 01/25] arm/altp2m: Add first altp2m HVMOP stubs.

2016-08-11 Thread Julien Grall


Hello Tamas,

On 10/08/2016 16:49, Tamas K Lengyel wrote:

On Aug 10, 2016 03:52, "Julien Grall" mailto:julien.gr...@arm.com>> wrote:

On 09/08/2016 21:16, Tamas K Lengyel wrote:

On Wed, Aug 3, 2016 at 10:54 AM, Julien Grall 
> wrote:

There is a rcu_lock_domain_by_any_id before we get to this check here,
so any other CPU looking to disable altp2m would be waiting there for
the current op to finish up, so there is no race condition AFAICT.



No, rcu_lock_domain_by_any_id only prevents the domain to be fully

destroyed by "locking" the rcu. It does not prevent multiple concurrent
access. You can look at the code if you are not convinced.




Ah thanks for clarifying. Then indeed there could be concurrency issues
if there are multiple tools accessing this interface. Normally that
doesn't happen though but probably a good idea to enforce it anyway.


Well, you need to think about the worst case scenario when you implement 
an interface. If you don't lock properly, the state in Xen may be 
corrupted. For instance Xen may think altp2m is active whilst it is not 
properly initialized.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [XTF PATCH 3/3] xtf-runner: support two modes for getting output

2016-08-11 Thread Wei Liu

On Wed, Aug 10, 2016 at 04:07:30PM +0100, Wei Liu wrote:
[...]
>  
> +def run_test_logfile(opts, test):
> +""" Run a specific test via grepping log file"""
> +
> +fn = opts.logfile_dir + (opts.logfile_pattern % test)
> +local_time = time.strftime('%Y-%m-%d %H:%M:%S', time.localtime())
> +
> +# Use time to generate unique stamps
> +start_stamp = "= XTF TEST START %s =" % local_time
> +end_stamp = "= XTF TEST END %s =" % local_time
> +
> +print "Using %s" % fn
> +
> +f = open(fn, "ab")
> +f.write(start_stamp + "\n")
> +f.close()
> +

I think it would make more sense for the micro VM itself to write
stamps?

Wei.

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

Re: [Xen-devel] [PATCH v2 14/25] arm/altp2m: Make get_page_from_gva ready for altp2m.

2016-08-11 Thread Julien Grall




On 06/08/2016 18:58, Sergej Proskurin wrote:

Hi Julien,


Hello Sergej,


On 08/06/2016 03:45 PM, Julien Grall wrote:



On 06/08/2016 11:38, Sergej Proskurin wrote:

Hi Julien,


Hello Serge,


On 08/04/2016 01:59 PM, Julien Grall wrote:

Hello Sergej,

On 01/08/16 18:10, Sergej Proskurin wrote:

The function get_page_from_gva uses ARM's hardware support to
translate
gva's to machine addresses. This function is used, among others, for
memory regulation purposes, e.g, within the context of memory
ballooning.
To ensure correct behavior while altp2m is in use, we use the
host's p2m
table for the associated gva to ma translation. This is required at
this
point, as altp2m lazily copies pages from the host's p2m and even
might
be flushed because of changes to the host's p2m (as it is done within
the context of memory ballooning).


I was expecting to see some change in
p2m_mem_access_check_and_get_page. Is there any reason to not fix it?




I did not yet encounter any issues with
p2m_mem_access_check_and_get_page. According to ARM ARM, ATS1C** (see
gva_to_ipa_par) translates VA to IPA in non-secure privilege levels (as
it is the the case here). Thus, the 2nd level translation represented by
the (alt)p2m is not really considered at this point and hence make an
extension obsolete.

Or did you have anything else in mind?


The stage-1 page tables are living in the guest memory. So every time
you access an entry in the page table, you have to translate the IPA
(guest physical address) into a PA.

However, the underlying memory of those page table may have
restriction permission or does not exist in the altp2m at all. So the
translation will fail.



Please correct me if I am wrong but as far as I understand: the function
p2m_mem_access_check_and_get_page is called only from get_page_from_gva.
Also it is called only if the page translation within the function
get_page_from_gva was not successful. Because of the fact that we use
the hostp2m's 2nd stage translation table including the original memory
access permissions (please note the short sequence, where we temporarily
reset the VTTBR_EL2 of the hostp2m if altp2m is active), potential
faults (which would lead to the call of the function
p2m_mem_access_check_and_get_page) must have reasons beyond altp2m.


The translation in get_page_from_gva may fail if the permission in the 
hostp2m has been restricted by memaccess (for instance because 
default_access is not p2m_access_rwx).


So you will fallback to p2m_mem_access_check_and_get_page. This function 
is calling gva_to_ipa that will use the altp2m to do the translation.


Therefore I think you need to modify p2m_mem_access_check_and_get_page 
to cope with altp2m.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 3/3] x86/microcode: Avoid undefined behaviour from signed integer overflow

2016-08-11 Thread Tian, Kevin

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, August 05, 2016 9:50 PM
> To: Xen-devel
> Cc: Andrew Cooper; Jan Beulich; Tian, Kevin; Nakajima, Jun
> Subject: [PATCH 3/3] x86/microcode: Avoid undefined behaviour from signed 
> integer
> overflow
> 
> The checksum should be calculated using unsigned 32bit integers, as it is
> intended to overflow and end at 0.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH 1/2] x86/vmx: dump MSR load area

2016-08-11 Thread Jan Beulich

>>> On 10.08.16 at 16:25,  wrote:
> On Wed, Aug 10, 2016 at 04:44:21AM -0600, Jan Beulich wrote:
>> >>> On 10.08.16 at 08:59,  wrote:
>> > @@ -1879,6 +1893,13 @@ void vmcs_dump_vcpu(struct vcpu *v)
>> >   (SECONDARY_EXEC_ENABLE_VPID | 
>> > SECONDARY_EXEC_ENABLE_VM_FUNCTIONS) 
> 
>> > )
>> >  printk("Virtual processor ID = 0x%04x VMfunc controls = %016lx\n",
>> > vmr16(VIRTUAL_PROCESSOR_ID), vmr(VM_FUNCTION_CONTROL));
>> > +printk("EXIT MSR load count = 0x%04x\n",
>> > +   (uint32_t)vmr(VM_EXIT_MSR_LOAD_COUNT));
>> > +printk("EXIT MSR store count = 0x%04x\n",
>> > +   (uint32_t)vmr(VM_EXIT_MSR_STORE_COUNT));
>> > +printk("ENTRY MSR load count = 0x%04x\n",
>> > +   (uint32_t)vmr(VM_ENTRY_MSR_LOAD_COUNT));
>> 
>> First - do you really need to make three log lines out of these? And
>> then, please use vmr32(), as the neighboring vmr16() suggests.
>> Plus finally - please log all four counts consistently either in hex
>> or in dec.
> 
> With one line, output might look something like:
> (XEN) MSR load/store count ExitLoad=0x0001 ExitStore=0x0023 EntryLoad=0x0023
> 
> Spaces around = are inconsistent in the existing output and it seems
> that no space is more popular. Does this format seem better to you?

Yes.

> I see three counts here - are you talking about the msr_count above?

Yes.

> For msr_count I was thinking that this is internal Xen state, whereas
> the other values are VMCS fields where everything else is dumped in
> hex. I think printing msr_count is redundant (one could just count the
> lines of output), so I'll just remove it.

That's fine as an option of course.

Jan


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

Re: [Xen-devel] [PATCH v2 20/25] arm/altp2m: Add altp2m paging mechanism.

2016-08-11 Thread Julien Grall




On 10/08/2016 11:32, Sergej Proskurin wrote:

Hi Julien,


Hello Sergej,


[...]


 switch ( fsc )
 {
+case FSC_FLT_TRANS:
+{
+if ( altp2m_active(d) )
+{
+const struct npfec npfec = {
+.insn_fetch = 1,
+.gla_valid = 1,
+.kind = hsr.iabt.s1ptw ? npfec_kind_in_gpt :
npfec_kind_with_gla
+};
+
+/*
+ * Copy the entire page of the failing instruction
into the
+ * currently active altp2m view.
+ */
+if ( altp2m_lazy_copy(v, gpa, gva, npfec, &p2m) )
+return;


I forgot to mention that I think there is a race condition here. If
multiple vCPU (let say A and B) use the same altp2m, they may fault
here.

If vCPU A already fixed the fault, this function will return false and
continue. So this will lead to inject an instruction abort to the
guest.



I have solved this issue as well:

In altp2m_lazy_copy, we check whether the faulting address is already
mapped in the current altp2m view. The only reason why the current
altp2m should have a valid entry for the apparently faulting address is
that it was previously (almost simultaneously) mapped by another vcpu.
That is, if the mapping for the faulting address is valid in the altp2m,
we return true and hence let the guest retry (without injecting an
instruction/data abort exception) to access the address in question.


I am afraid that your description does not match the implementation of 
altp2m_lazy_copy in this version of the patch series.


If you find a valid entry in the altp2m, you will return 0 (i.e false). 
This will lead to inject an abort into the guest.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 2/2] x86/vmx: conditionally disable LBR support due to TSX format quirk

2016-08-11 Thread Jan Beulich

>>> On 10.08.16 at 17:47,  wrote:
> On Wed, Aug 10, 2016 at 06:34:10AM -0600, Jan Beulich wrote:
>> >>> On 10.08.16 at 08:59,  wrote:
>> > --- a/xen/arch/x86/hvm/vmx/vmx.c
>> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> > @@ -2576,8 +2576,22 @@ static const struct lbr_info 
>> > *last_branch_msr_get(void)
>> >  /* Haswell */
>> >  case 60: case 63: case 69: case 70:
>> >  /* Broadwell */
>> > -case 61: case 71: case 79: case 86:
>> > +case 61: case 71: case 79: case 86: {
>> > +u64 caps;
>> > +bool_t tsx_support = boot_cpu_has(X86_FEATURE_HLE) ||
>> > + boot_cpu_has(X86_FEATURE_RTM);
>> > +
>> > +rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
>> 
>> This is guarded by a X86_FEATURE_PDCM check in Linux - why
>> would we not need the same here?
> 
> You're right, it should be. It also seems to be missing from
> core2_vpmu_init().

Feel free to take the liberty to fix it there at once (but please
briefly mention this as an independent change in the description).

>> Also I think this RDMSR should be performed once at boot, not every
>> time we come here.
> 
> I thought you might say that. It didn't seem obviously right to put
> this in boot_cpu_data -- is that what you suggest?

Why boot_cpu_data? Just an ordinary (possibly per-CPU) static
in vmx.c.

Jan


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

Re: [Xen-devel] [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

2016-08-11 Thread Yu Zhang




On 8/10/2016 6:43 PM, Yu Zhang wrote:



On 8/10/2016 6:33 PM, Jan Beulich wrote:

On 10.08.16 at 10:09,  wrote:

On 8/8/2016 11:40 PM, Jan Beulich wrote:

On 12.07.16 at 11:02,  wrote:

@@ -178,8 +179,34 @@ static int hvmemul_do_io(
   break;
   case X86EMUL_UNHANDLEABLE:
   {
-struct hvm_ioreq_server *s =
-hvm_select_ioreq_server(curr->domain, &p);
+struct hvm_ioreq_server *s;
+
+if ( is_mmio )
+{
+unsigned long gmfn = paddr_to_pfn(addr);
+p2m_type_t p2mt;
+
+(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
+
+if ( p2mt == p2m_ioreq_server )
+{
+unsigned int flags;
+
+if ( dir != IOREQ_WRITE )
+s = NULL;
+else
+{
+s = p2m_get_ioreq_server(currd, &flags);
+
+if ( !(flags & P2M_IOREQ_HANDLE_WRITE_ACCESS) )
+s = NULL;
+}
+}
+else
+s = hvm_select_ioreq_server(currd, &p);
+}
+else
+s = hvm_select_ioreq_server(currd, &p);

Wouldn't it both be more natural and make the logic even easier
to follow if s got set to NULL up front, all the "else"-s dropped,
and a simple

  if ( !s )
  s = hvm_select_ioreq_server(currd, &p);

be done in the end?


Sorry, Jan. I tried to simplify above code, but found the new code is
still not very
clean,  because in some cases the s is supposed to return NULL instead
of to be
set from the hvm_select_ioreq_server().
To keep the same logic, the simplified code looks like this:

   case X86EMUL_UNHANDLEABLE:
   {
-struct hvm_ioreq_server *s =
-hvm_select_ioreq_server(curr->domain, &p);
+struct hvm_ioreq_server *s = NULL;
+p2m_type_t p2mt = p2m_invalid;
+
+if ( is_mmio && dir == IOREQ_WRITE )
+{
+unsigned long gmfn = paddr_to_pfn(addr);
+
+(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
+
+if ( p2mt == p2m_ioreq_server )
+{
+unsigned int flags;
+
+s = p2m_get_ioreq_server(currd, &flags);
+if ( !(flags & XEN_HVMOP_IOREQ_MEM_ACCESS_WRITE) )
+s = NULL;
+}
+}
+
+if ( !s && p2mt != p2m_ioreq_server )
+s = hvm_select_ioreq_server(currd, &p);

   /* If there is no suitable backing DM, just ignore 
accesses */

   if ( !s )

As you can see, definition of p2mt is moved outside the if ( is_mmio )
judgement,
and is checked against p2m_ioreq_server before we search the ioreq
server's rangeset
in hvm_select_ioreq_server(). So I am not quite satisfied with this
simplification.
Any suggestions?

I think it's better than the code was before, but an implicit part of
my suggestion was that I'm not really convinced the
" && p2mt != p2m_ioreq_server" part of your new conditional is
really needed: Would it indeed be wrong to hand such a request
to the "normal" ioreq server, instead of terminating it right away?
(I guess that's a question to you as much as to Paul.)



Thanks for your reply, Jan.
For " && p2mt != p2m_ioreq_server" condition, it is just to guarantee 
that if a write
operation is trapped, and at the same period, device model changed the 
status of

ioreq server, it should be discarded.


Hi Paul & Jan, any comments?


A second thought is, I am now more worried about the " && dir == 
IOREQ_WRITE"
condition, which we used previously to set s to NULL if it is not a 
write operation.
However, if HVM uses a read-modify-write instruction to operate on a 
write-protected
address, it will be treated as both read and write accesses in 
ept_handle_violation(). In
such situation, we need to emulate the read access first(by just 
returning the value being
fetched either in hypervisor or in device model), instead of 
discarding the read access.




Any suggestions about this guest read-modify-write instruction situation?
Is my depiction clear? :)

Thanks
Yu


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

Re: [Xen-devel] [PATCH v2 1/3] livepach: Add .livepatch.hooks functions and test-case

2016-08-11 Thread Jan Beulich

>>> On 10.08.16 at 11:46,  wrote:
> Odd. I've tried this simple example:
> 
> typedef int fn_t(void);
> 
> struct s {
>   unsigned n;
>   fn_t**fn;
>   fn_t*const*fnc;
>   const fn_t**cfn;
> };
> 
> int test1(const struct s*ps) {
>   unsigned i;
>   int rc = 0;
> 
>   for(i = 0; !rc && i < ps->n; ++i)
>   rc = ps->fn[i]();
> 
>   return rc;
> }
> 
> int test2(const struct s*ps) {
>   unsigned i;
>   int rc = 0;
> 
>   for(i = 0; !rc && i < ps->n; ++i)
>   rc = ps->fnc[i]();
> 
>   return rc;
> }
> 
> int test3(const struct s*ps) {
>   unsigned i;
>   int rc = 0;
> 
>   for(i = 0; !rc && i < ps->n; ++i)
>   rc = ps->cfn[i]();
> 
>   return rc;
> }
> 
> test1() and test2() get compiled identically. test3(), using the field
> with the misplaced const, oddly enough gets compiled slightly
> differently (and without a warning despite one would seem
> warranted), yet the call doesn't get omitted. If, however, I change
> the return type of fn_t to void, the function body of test3() ends
> up empty, which is a compiler bug afaict, but which also suggests
> that you've tried the variant with the misplaced const.

FTR: This is not a compiler bug, as specifically named undefined
in the C spec.

Jan


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

[Xen-devel] [qemu-mainline test] 100397: tolerable FAIL - PUSHED

2016-08-11 Thread osstest service owner

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 qemuu4b3e5c06a15298d870e81c2d3a5a16dc2a93f5cc
baseline version:
 qemuu2bb15bddf2607110820d5ce5aa43baac27292fb3

Last test of basis   100379  2016-08-10 04:09:54 Z1 days
Testing same since   100397  2016-08-10 17:16:06 Z0 days1 attempts


People who touched revisions under test:
  Cornelia Huck 
  CÃ©dric Le Goater 
  David Gibson 
  Gonglei 
  Laurent Vivier 
  Marc-AndrÃ© Lureau 
  Paolo Bonzini 
  Peter Maydell 
  Pranith Kumar 
  Radim KrÄmÃ¡Å 
  Thomas Huth 

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

Re: [Xen-devel] [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

2016-08-11 Thread Jan Beulich

>>> On 11.08.16 at 10:47,  wrote:
> On 8/10/2016 6:43 PM, Yu Zhang wrote:
>> For " && p2mt != p2m_ioreq_server" condition, it is just to guarantee 
>> that if a write
>> operation is trapped, and at the same period, device model changed the 
>> status of
>> ioreq server, it should be discarded.
> 
> Hi Paul & Jan, any comments?

Didn't Paul's "should behave like p2m_ram_rw" reply clarify things
sufficiently?

>> A second thought is, I am now more worried about the " && dir == 
>> IOREQ_WRITE"
>> condition, which we used previously to set s to NULL if it is not a 
>> write operation.
>> However, if HVM uses a read-modify-write instruction to operate on a 
>> write-protected
>> address, it will be treated as both read and write accesses in 
>> ept_handle_violation(). In
>> such situation, we need to emulate the read access first(by just 
>> returning the value being
>> fetched either in hypervisor or in device model), instead of 
>> discarding the read access.
> 
> Any suggestions about this guest read-modify-write instruction situation?
> Is my depiction clear? :)

Well, from your earlier reply I concluded that you'd just go ahead
and put this into patch form, which we'd then look at.

Jan


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

Re: [Xen-devel] [PATCH v2 08/25] arm/altp2m: Add HVMOP_altp2m_set_domain_state.

2016-08-11 Thread Julien Grall


Hello Sergej,

On 06/08/2016 11:36, Sergej Proskurin wrote:

+
+/* Initialize the new altp2m view. */
+rc = p2m_init_one(d, p2m);
+if ( rc )
+goto err;
+
+/* Allocate a root table for the altp2m view. */
+rc = p2m_alloc_table(p2m);
+if ( rc )
+goto err;
+
+p2m->p2m_class = p2m_alternate;
+p2m->access_required = 1;


Please use true here. Although, I am not sure why you want to enable
the access by default.



Will do.

p2m->access_required is true by default in the x86 implementation. Also,
there is currently no way to manually set access_required on altp2m.
Besides, I do not see a scenario, where it makes sense to run altp2m
without access_required set to true.


Please add a comment in the code to explain it.

[...]




+
+/*
+ * The altp2m_active state has been deactivated. It is
now safe to
+ * flush all altp2m views -- including altp2m[0].
+ */
+if ( ostate )
+altp2m_flush(d);


The function altp2m_flush is defined afterwards (in patch #9). Please
make sure that all the patches compile one by one.



The patches compile one by one. Please note that there is an
altp2m_flush stub inside of this patch.

+/* Flush all the alternate p2m's for a domain */
+static inline void altp2m_flush(struct domain *d)
+{
+/* Not yet implemented. */
+}


I don't want to see stubs that are been replaced later on within the 
same series. The patch #9 does not seem to depend on patch #8, so I 
don't see any reason why you can't swap the 2 patches.


Regards,

--
Julien Grall

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

1 2 3 >

1 - 100 of 209 matches

Mail list logo