[Xen-devel] [xen-unstable baseline-only test] 67772: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67772 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67772/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
REGR. vs. 67767
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install   fail REGR. vs. 67767
 test-amd64-amd64-i386-pvgrub 10 guest-start   fail REGR. vs. 67767

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
fail like 67767
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67767
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67767
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 67767
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail like 67767
 test-amd64-i386-xl-qemut-debianhvm-amd64  9 debian-hvm-install fail like 67767
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail like 
67767
 test-amd64-i386-qemut-rhel6hvm-intel  9 redhat-install fail like 67767
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail like 
67767
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 67767
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install   fail like 67767
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 67767

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
 build-i386-rumprun5 rumprun-buildfail   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-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   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-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-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-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
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-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-xl-qemuu-win7-amd64 16 guest-stop 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-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-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 xen  9bb1865cca15b28be5aa185cd865b95b49e7b303
baseline version:
 xen  89c423a170de2fef08445ea9151bcfa15c45b217

Last test of basis67767  2016-09-27 02:14:01 Z1 days
Testing same since67772  2016-09-27 15:46:20 Z0 days1 attempts


People who touched revisions 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install  fail REGR. vs. 101172
 test-armhf-armhf-libvirt  6 xen-boot fail REGR. vs. 101172

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

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

version targeted for testing:
 qemuu25930ed60aad49f1fdd7de05272317c86ce1275b
baseline version:
 qemuu333ec4ca6a9f604331e2349cb91e9635f65d6462

Last test of basis   101172  2016-09-27 18:43:46 Z0 days
Testing same since   101173  2016-09-27 23:44:59 Z0 days1 attempts


People who touched revisions under test:
  David Gibson 
  Eduardo Habkost 
  Marc-André Lureau 
  Peter Maydell 

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

[Xen-devel] [PATCH] pvgrub: fix crash when booting kernel with p2m list outside kernel mapping

[Juergen Gross]

When trying to boot a kernel with the p2m list not mapped by the
initial kernel mapping it can happen that pvgrub is failing as it is
keeping some page tables mapped.

Unmap the additional page tables created for the special p2m mapping
will avoid this failure.

Reported-by: Sven Koehler 
Signed-off-by: Juergen Gross 
---
This is a backport candidate for 4.7
---
 stubdom/grub/kexec.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/stubdom/grub/kexec.c b/stubdom/grub/kexec.c
index 2ed4f6c..437a0a9 100644
--- a/stubdom/grub/kexec.c
+++ b/stubdom/grub/kexec.c
@@ -347,6 +347,8 @@ void kexec(void *kernel, long kernel_size, void *module, 
long module_size, char
 /* Unmap libxc's projection of the boot page table */
 seg = xc_dom_seg_to_ptr(dom, >pgtables_seg);
 munmap(seg, dom->pgtables_seg.vend - dom->pgtables_seg.vstart);
+seg = xc_dom_seg_to_ptr(dom, >p2m_seg);
+munmap(seg, dom->p2m_seg.vend - dom->p2m_seg.vstart);
 
 /* Unmap day0 pages to avoid having a r/w mapping of the future page table 
*/
 for (pfn = 0; pfn < allocated; pfn++)
-- 
2.6.6


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

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

[osstest service owner]

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

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  1e75ed8b64bc1a9b47e540e6f100f17ec6d97f1b
baseline version:
 xen  ecee7bfc18c69892e2a3b213448e592eceeccb7a

Last test of basis   101166  2016-09-27 10:05:46 Z0 days
Testing same since   101174  2016-09-28 02:07:06 Z0 days1 attempts


People who touched revisions under test:
  "Edgar E. Iglesias" 
  Edgar E. Iglesias 
  Julien Grall 
  Stefano Stabellini 
  Tamas K Lengyel 

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=1e75ed8b64bc1a9b47e540e6f100f17ec6d97f1b
+ . ./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 
1e75ed8b64bc1a9b47e540e6f100f17ec6d97f1b
+ branch=xen-unstable-smoke
+ revision=1e75ed8b64bc1a9b47e540e6f100f17ec6d97f1b
+ . ./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
+ '[' x1e75ed8b64bc1a9b47e540e6f100f17ec6d97f1b = 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
++ : 

Re: [Xen-devel] [Help] Trigger Watchdog when adding an IPI in vcpu_wake

[Wei Yang]

On Mon, Sep 26, 2016 at 12:18:06PM +0200, Dario Faggioli wrote:
>On Sat, 2016-09-24 at 11:39 +0800, Wei Yang wrote:
>> On Thu, Sep 22, 2016 at 11:12:15AM +0200, Dario Faggioli wrote:
>> > _Almost_ correct. However, the problem is more that vcpu_wake() can
>> > happen in response to an IRQ, and when you grab a spinlock in IRQ
>> > context, you need to disable IRQs.
>> > 
>> 
>> Ok, now I have a question to this sentence.
>> 
>> I have checked some posts which says in the interrupt handling, irq
>> would be
>> disabled. Well, this really depends on the implementation.
>> 
>> This means in Xen, irq is still enabled during interrupt handling?
>> Because of
>> this, we have to disable IRQ when we need to grab the spin lock?
>> 
>So, I don't think I'm getting all you're saying and asking.
>
>The situation is like this: currently, vcpu_wake() can be called both
>from inside or outside IRQ context, and both with IRQs enabled or
>disabled.
>
>Given this situation, to be safe, we need to disable IRQs when taking
>whatever spinlock vcpu_wake() (and the functions it calls, of course)
>calls. Since it takes the scheduler's runq lock, this means we need to
>take the lock with IRQ disabled.
>
>And because of that, _everyone_ that takes the schedulr's lock must do
>that with IRQs disabled. If we manage to *not* take the scheduler's
>lock with IRQ disabled in vcpu_wake(), we then can do the same
>everywhere else. But we can't do that with the current structure of the
>code, and that's why we're thinking to defer the actual wakeup --i.e.,
>the actual call to vcpu_wake()-- to a moment when:
> - IRQs are enabled,
> - we don't need to disable them.
>

Dario,

I appreciate your patience and almost get the background and your purpose.

First, let me give my conclusion. By taking the schedule lock with IRQ
enabled, it will improve the parallelism to some extend, while it would be
hard to say the net effect. Need more data from benchmark to verify.

Then, let me describe what I understand. (Maybe not correct :-))

This is all about the SMP, spinlock and IRQ/IRQ context.

Two basic assumptions:
a. all interrupt are the same priority, interrupt could not be preempted by 
others. 
b. in the whole interrupt handler, IRQ is disabled on local processor

Let's assume there is only one processor first,
1. If the spinlock just used in interrupt handler, looks it is save, no race
   condition.
2. While if the spinlock maybe used outside interrupt handler, ok, we need to
   at least disable IRQ when grab the lock outside interrupt handler.
   Otherwise there is deadlock.

Then if there are several CPUs in the system.
1. If the spinlock just used in interrupt handler, would this be still save to
   not disable the IRQ? It looks ok to me.
2. While if the spinlock maybe used outside interrupt handler, ok, we need to
   at least disable IRQ when grab the lock outside interrupt handler.

This leads to the spinlock usage convention: if a spinlock would be grabbed in
interrupt handler(IRQ context), we need to grab it with IRQ disabled _always_.

Then, to achieve your purpose -- grab the spinlock with IRQ enabled, you need
to move all the lock operation outside of the interrupt handler. What you are
doing in the code is to deffer the job to softirq when it is in_irq.

By now, I can understand your first part of your check. If vcpu_wake() is
not running in_irq() we can do the job directly now. But not the second part,
why we need to check the local irq is also enabled? In my mind, we need to
check it is not in_irq() is enough.

Thanks a lot for your time :-)

>This is it. About the following...
>
>> Looks I almost get every thing. Let me do a summary to see whether I
>> have got
>> your words.
>> 
>>    (spinlock usage convention in Xen)  &  (vcpu_wake() may happen in
>> an IRQ)
>> 
>This is ok.
>
>> =>
>> 
>>    (irq all disabled || irq all enabled) & (disable irq on grabbing
>> spinlock)
>> 
>This, I don't get it.
>
>> =>
>> 
>>    should grab schedule lock with IRQ disabled
>> 
>Yes, sounds right.
>
>Dario
>-- 
><> (Raistlin Majere)
>-
>Dario Faggioli, Ph.D, http://about.me/dario.faggioli
>Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)


-- 
Richard Yang\nHelp you, Help me

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

Re: [Xen-devel] [Xen-users] pvgrub: Error 9: Unknown boot failure

[Juergen Gross]

On 28/09/16 01:33, Sven Köhler wrote:
> Am 27.09.2016 um 14:52 schrieb Juergen Gross:
>> On 27/09/16 14:09, Sven Köhler wrote:
>>> Am 27.09.2016 um 14:02 schrieb Juergen Gross:
 On 27/09/16 13:13, Sven Köhler wrote:
> Am 27.09.2016 um 07:31 schrieb Juergen Gross:
>> On 27/09/16 00:48, Sven Köhler wrote:
>>> Am 26.09.2016 um 07:43 schrieb Juergen Gross:
 On 25/09/16 18:04, Sven Köhler wrote:
> Hi,
>
> I'm experiencing the bug below which was discussed on xen-devel 
> December
> last year buy Ian and Juergen. I'm using xen-pvgrub-4.7.0 on Gentoo.
>
> The bug only seems to occur with the last domU booted on my machine.
> Where do I find a patch that fixes that?

 The issue back in December was fixed by commit
 c8eb0ec277ae387e78d685523e0fee633e46f046 which is included in Xen 4.7.
 Either gentoo didn't update to the official Xen 4.7 release (including
 pvgrub) or you are seeing a new issue.
>>>
>>> From the looks of it, the Gentoo package is using the grub from the
>>> xen-4.7.0 tarball.
>>>
>>> I downgraded to pvgrub 4.6.3 and the problem went away.
>>>
>>> So I assume I'm seeing a new issue. How do I debug it?
>>
>> Interesting. Just tested it on upstream Xen and saw the same problem
>> with a rather old guest kernel (3.0 based, xen flavor), while a newer
>> kernel (4.1, pvops) is working.
>>
>> Can you give me some more details about the kernel you are trying to
>> boot?
>
> It's an unmodified 4.4.21 kernel which I compile by hand. The config is
> attached. Does that help?

 Not really. OTOH I think I don't need more help, as I've found a problem
 in pvgrub. I have a patch which seems to correct the issue. Are you fine
 with me adding you as the original reporter of the problem in the patch?
>>>
>>> Yes, I'm fine with adding me as the reporter.
>>> Do you want me to test the patch first?
>>
>> Sure. The attached patch is for Xen upstream, but I think it should
>> apply to Xen 4.7, too.
> 
> This patch solved the issue for me. My domU boots fine again after
> recompiling pvgrub with the patch applied.
> 
> Thanks!

Thank you for the test!


Juergen


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

Re: [Xen-devel] [v2 3/3] tools & docs: add L2 CAT support in tools and docs.

[Yi Sun]

Hi, Ian,

Any comments? That would be very appreciated. Thanks!

BRs,
Sun Yi

On 16-09-23 15:24:57, Yi Sun wrote:
> On 16-09-22 11:09:31, Ian Jackson wrote:
> > Yi Sun writes ("[v2 3/3] tools & docs: add L2 CAT support in tools and 
> > docs."):
> > > This patch is the xl/xc changes to support Intel L2 CAT
> > > (Cache Allocation Technology).
> > > 
> > > The new level option is introduced to original CAT setting
> > > command in order to set CBM for specified level CAT.
> > 
> > Thanks for this.  I have some comments about the libxl API and xl.
> > 
> > You'll see that I'm somewhat confused.  Please help enlighten me :-).
> > 
> > 
> Thank you very much for reviewing my patches and provide your comments!
> 
> Sorry to make you confused. I will try best to explain my intention ;-).
> 
> > > +#define L3_CAT 3
> > > +#define L2_CAT 2
> > > +int xc_psr_cat_get_info(xc_interface *xch, uint32_t socket, int lvl,
> > > +uint32_t *cos_max, uint32_t *cbm_len,
> > > +bool *cdp_enabled)
> > 
> > I find these defines rather odd.  You have chosen to use an integer
> > "level" to specify which cache to affect.  It probably wouldn't be
> > desirable to decouple these integer values from the names, but the
> > names are just integers with a funny hat on.
> > 
> > If these names are really useful they should be in the IDL.
> > 
> >
> Thanks! I will remove the macros and just use integer.
>  
> > > -int xc_psr_cat_get_l3_info(xc_interface *xch, uint32_t socket,
> > > -   uint32_t *cos_max, uint32_t *cbm_len,
> > > -   bool *cdp_enabled);
> > > +int xc_psr_cat_get_info(xc_interface *xch, uint32_t socket, int lvl,
> > > +uint32_t *cos_max, uint32_t *cbm_len,
> > > +bool *cdp_enabled);
> > 
> > This needs a new HAVE #define.
> > 
> > 
> Thanks! I will add one more HAVE #define in xl.h.
> 
> > > diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c
> > > index 99733f6..861d5a8 100644
> > > --- a/tools/libxl/libxl_psr.c
> > > +++ b/tools/libxl/libxl_psr.c
> > ..
> > > +static int psr_l2_cat_hwinfo(void)
> > > +{
> > > +int rc;
> > > +int i, nr;
> > > +libxl_psr_cat_info *info;
> > ...
> > > +for (i = 0; i < nr; i++) {
> > > +/* There is no CMT on L2 cache so far. */
> > > +printf("%-16s: %u\n", "Socket ID", info[i].id);
> > > +printf("%-16s: %u\n", "Maximum COS", info[i].cos_max);
> > > +printf("%-16s: %u\n", "CBM length", info[i].cbm_len);
> > > +printf("%-16s: %#llx\n", "Default CBM",
> > > +   (1ull << info[i].cbm_len) - 1);
> > 
> > I find this code confusing.
> > 
> > I don't understand why libxl needs to know about the properties of L2
> > vs L3 CAT.  If it does need to know these properties then probably the
> > IDL needs to know about them too, but the IDL is completely agnostic.
> > 
> psr_l2_cat_hwinfo() is implemented to get L2 CAT HW info back. Because this
> HW info is almost same as L3 CAT, I reuse the libxl_psr_cat_info defined
> in libxl_types.idl. If you think this is not good enough, I think I may add
> 'lvl' in libxl_psr_cat_info to express the level to handle?
> 
> > Perhaps libxl ought probably to be "thinner", and simply present whats
> > in the IDL ?
> >
> > For example:
> > 
> > > +if (lvl == 2) {
> > > +if (opt_data || opt_code) {
> > > +fprintf(stderr, "L2 CAT does not support CDP yet.\n");
> > > +return -1;
> > 
> > This should perhaps be done by calling libxl and getting a
> > notimplemented error ?
> > 
> I think your intention is to put more feature details into libxl_psr.c then
> the developer of other app will be easy to implement the app, right?
> 
> My concerns are below:
> 1. The application needs user to input the lvl option to know which lvl to
> operate anyway. Of course, we can use L3 as default option to be backward
> compatible. But to get/set L2, we still need user to input level. That means
> the application knows the level concept.
> 2. From the functional view, print what information out and how to operate
> should be decided by application but not the library.
> 
> So, I think it is acceptable to let xl know some L2 and L3 details and operate
> differently on different levels.
> 
> If my thought is not right, please correct me. Thank you!
> 
> > > +} else if (lvl == 3) {
> > > +if (opt_data && opt_code) {
> > > +fprintf(stderr, "Cannot handle -c and -d at the same 
> > > time\n");
> > > +return -1;
> > > +} else if (opt_data) {
> > > +type = LIBXL_PSR_CBM_TYPE_L3_CBM_DATA;
> > > +} else if (opt_code) {
> > > +type = LIBXL_PSR_CBM_TYPE_L3_CBM_CODE;
> > > +} else {
> > > +type = LIBXL_PSR_CBM_TYPE_L3_CBM;
> > > +}
> > 
> > Is this inability to do -c and -d really contingent on the cache
> > level ?
> > 
> Because '-c'(code) and 

[Xen-devel] [PULL 1/1] qdisk - hw/block/xen_disk: grant copy implementation

[Stefano Stabellini]

From: Paulina Szubarczyk 

Copy data operated on during request from/to local buffers to/from
the grant references.

Before grant copy operation local buffers must be allocated what is
done by calling ioreq_init_copy_buffers. For the 'read' operation,
first, the qemu device invokes the read operation on local buffers
and on the completion grant copy is called and buffers are freed.
For the 'write' operation grant copy is performed before invoking
write by qemu device.

A new value 'feature_grant_copy' is added to recognize when the
grant copy operation is supported by a guest.

Signed-off-by: Paulina Szubarczyk 
Reviewed-by: Stefano Stabellini 
Acked-by: Anthony PERARD 
Acked-by: Roger Pau Monné 
---
 configure   |  55 
 hw/block/xen_disk.c | 153 ++--
 include/hw/xen/xen_common.h |  14 
 3 files changed, 217 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index 8fa62ad..1fb343d 100755
--- a/configure
+++ b/configure
@@ -1955,6 +1955,61 @@ EOF
 /*
  * If we have stable libs the we don't want the libxc compat
  * layers, regardless of what CFLAGS we may have been given.
+ *
+ * Also, check if xengnttab_grant_copy_segment_t is defined and
+ * grant copy operation is implemented.
+ */
+#undef XC_WANT_COMPAT_EVTCHN_API
+#undef XC_WANT_COMPAT_GNTTAB_API
+#undef XC_WANT_COMPAT_MAP_FOREIGN_API
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#if !defined(HVM_MAX_VCPUS)
+# error HVM_MAX_VCPUS not defined
+#endif
+int main(void) {
+  xc_interface *xc = NULL;
+  xenforeignmemory_handle *xfmem;
+  xenevtchn_handle *xe;
+  xengnttab_handle *xg;
+  xen_domain_handle_t handle;
+  xengnttab_grant_copy_segment_t* seg = NULL;
+
+  xs_daemon_open();
+
+  xc = xc_interface_open(0, 0, 0);
+  xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
+  xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
+  xc_hvm_inject_msi(xc, 0, 0xf000, 0x);
+  xc_hvm_create_ioreq_server(xc, 0, HVM_IOREQSRV_BUFIOREQ_ATOMIC, NULL);
+  xc_domain_create(xc, 0, handle, 0, NULL, NULL);
+
+  xfmem = xenforeignmemory_open(0, 0);
+  xenforeignmemory_map(xfmem, 0, 0, 0, 0, 0);
+
+  xe = xenevtchn_open(0, 0);
+  xenevtchn_fd(xe);
+
+  xg = xengnttab_open(0, 0);
+  xengnttab_grant_copy(xg, 0, seg);
+
+  return 0;
+}
+EOF
+  compile_prog "" "$xen_libs $xen_stable_libs"
+then
+xen_ctrl_version=480
+xen=yes
+  elif
+  cat > $TMPC <= 480
+
+static void ioreq_free_copy_buffers(struct ioreq *ioreq)
+{
+int i;
+
+for (i = 0; i < ioreq->v.niov; i++) {
+ioreq->page[i] = NULL;
+}
+
+qemu_vfree(ioreq->pages);
+}
+
+static int ioreq_init_copy_buffers(struct ioreq *ioreq)
+{
+int i;
+
+if (ioreq->v.niov == 0) {
+return 0;
+}
+
+ioreq->pages = qemu_memalign(XC_PAGE_SIZE, ioreq->v.niov * XC_PAGE_SIZE);
+
+for (i = 0; i < ioreq->v.niov; i++) {
+ioreq->page[i] = ioreq->pages + i * XC_PAGE_SIZE;
+ioreq->v.iov[i].iov_base = ioreq->page[i];
+}
+
+return 0;
+}
+
+static int ioreq_grant_copy(struct ioreq *ioreq)
+{
+xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
+xengnttab_grant_copy_segment_t segs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+int i, count, rc;
+int64_t file_blk = ioreq->blkdev->file_blk;
+
+if (ioreq->v.niov == 0) {
+return 0;
+}
+
+count = ioreq->v.niov;
+
+for (i = 0; i < count; i++) {
+if (ioreq->req.operation == BLKIF_OP_READ) {
+segs[i].flags = GNTCOPY_dest_gref;
+segs[i].dest.foreign.ref = ioreq->refs[i];
+segs[i].dest.foreign.domid = ioreq->domids[i];
+segs[i].dest.foreign.offset = ioreq->req.seg[i].first_sect * 
file_blk;
+segs[i].source.virt = ioreq->v.iov[i].iov_base;
+} else {
+segs[i].flags = GNTCOPY_source_gref;
+segs[i].source.foreign.ref = ioreq->refs[i];
+segs[i].source.foreign.domid = ioreq->domids[i];
+segs[i].source.foreign.offset = ioreq->req.seg[i].first_sect * 
file_blk;
+segs[i].dest.virt = ioreq->v.iov[i].iov_base;
+}
+segs[i].len = (ioreq->req.seg[i].last_sect
+   - ioreq->req.seg[i].first_sect + 1) * file_blk;
+}
+
+rc = xengnttab_grant_copy(gnt, count, segs);
+
+if (rc) {
+xen_be_printf(>blkdev->xendev, 0,
+  "failed to copy data %d\n", rc);
+ioreq->aio_errors++;
+return -1;
+}
+
+for (i = 0; i < count; i++) {
+if (segs[i].status != GNTST_okay) {
+xen_be_printf(>blkdev->xendev, 3,
+  "failed to copy data %d for gref %d, domid %d\n",
+  segs[i].status, ioreq->refs[i], ioreq->domids[i]);
+ioreq->aio_errors++;
+rc = 

[Xen-devel] [PULL 0/1] tags/xen-20160927-tag

[Stefano Stabellini]

The following changes since commit 25930ed60aad49f1fdd7de05272317c86ce1275b:

  Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into 
staging (2016-09-27 23:10:12 +0100)

are available in the git repository at:


  git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160927-tag

for you to fetch changes up to b6eb9b45f7307638ff166401721ae6d0401e1d67:

  qdisk - hw/block/xen_disk: grant copy implementation (2016-09-27 18:18:55 
-0700)


Xen 2016/09/27


Paulina Szubarczyk (1):
  qdisk - hw/block/xen_disk: grant copy implementation

 configure   |  55 
 hw/block/xen_disk.c | 153 ++--
 include/hw/xen/xen_common.h |  14 
 3 files changed, 217 insertions(+), 5 deletions(-)

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

Re: [Xen-devel] [PATCH v4 0/7] xen/arm: Add support for mapping mmio-sram nodes into dom0

[Stefano Stabellini]

On Fri, 23 Sep 2016, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" 
> 
> This series adds support for mapping mmio-sram nodes into dom0
> as normal uncached MEMORY with RW perms.
> 
> If the no-memory-wc prop is present in the DTB node, we create
> DEVICE RW mappings instead.
> 
> Comments welcome!

Committed


> Best regards,
> Edgar
> 
> ChangeLog:
> 
> v3 -> v4:
> * Rename p2m_mmio_direct_nc -> p2m_mmio_direct_dev
> * Rename p2m_mem_nc p2m_mmio_direct_nc
> * Make p2m_mmio_direct_nc non-executable to match p2m_mmio_direct_c
> * Fix typos in comments regarding shareability
> * Add reference to ARMv8 specs for outer sharability attr
> * Add comment describing map_regions_p2mt
> * Mention the p2m type inheritance in the commit msg of path #6
> 
> v2 -> v3:
> * Drop RFC
> * Add comment on outer-shareable choice for non-cached mem
> * Spellfix existance -> existence
> * Add comment on props usage
> * Props matching now only supports a single property
> * Dropped p2m_access in plumbing for mapping attributes
> * Rename un/map_regions to un/map_regions_p2mt
> * Add path to mmio-sram device-tree bindings docs in commit msg
> * Add a comment on inheriting parent mem attributes
> * Dropped the mmio-sram bus
> 
> v1 -> v2
> * Replace the .map method with a list of match -> map attributes
> * Handle no-memory-wc by mapping as DEVICE RW
> * Generalize map_regions_rw_cache instead of adding new functions
> 
> Edgar E. Iglesias (7):
>   xen/arm: p2m: Rename p2m_mmio_direct_nc -> p2m_mmio_direct_dev
>   xen/arm: p2m: Add support for normal non-cacheable memory
>   xen/arm: Rename and generalize un/map_regions_rw_cache
>   xen/device-tree: Add __DT_MATCH macros without braces
>   xen/device-tree: Make dt_match_node match props
>   xen/arm: domain_build: Plumb for different mapping attributes
>   xen/arm: Map mmio-sram nodes as un-cached memory
> 
>  xen/arch/arm/domain_build.c   | 90 
> +--
>  xen/arch/arm/p2m.c| 42 ++--
>  xen/common/device_tree.c  |  5 ++-
>  xen/include/asm-arm/p2m.h | 24 +++-
>  xen/include/asm-arm/page.h|  1 +
>  xen/include/xen/device_tree.h | 20 --
>  6 files changed, 136 insertions(+), 46 deletions(-)
> 
> -- 
> 2.7.4
> 

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf eab26788156436a549610a299d2e297c22043e70
baseline version:
 ovmf 7807dea57fba6a019bb8641572e0159ffa03ad9e

Last test of basis67773  2016-09-27 15:47:51 Z0 days
Testing same since67774  2016-09-27 22:49:56 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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 eab26788156436a549610a299d2e297c22043e70
Author: Ard Biesheuvel 
Date:   Mon Sep 26 15:55:05 2016 -0700

MdePkg/BaseMemoryLibOptDxe: replace deprecated uses of IT blocks

The ARM architecture version 8 deprecates all uses of the IT instruction
except cases where it is followed by a single narrow instruction. So
replace any occurrences with equivalent sequences that adhere to the
new rules.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

commit c4f637077eb4504aa0109aac9983dfe85e5b2afb
Author: Ard Biesheuvel 
Date:   Mon Sep 26 15:51:45 2016 -0700

MdePkg/BaseMemoryLibOptDxe ARM: fix Thumb-2 bug in ScanMem()

The ARM ScanMem() in BaseMemoryLibOptDxe contains code from the open
source cortex-strings library, and inherited a bug from it where the
conditional execution of a sequence of instructions is erroneously
made dependent on the same condition. Since the final 'addeq' is
supposed to be dependent on the preceding 'tsteq' instruction, they
cannot be part of the same IT block.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 

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

Re: [Xen-devel] [for-4.8][PATCH v2 00/23] xen/arm: Rework the P2M code to follow break-before-make sequence

[Stefano Stabellini]

On Thu, 15 Sep 2016, Julien Grall wrote:
> Hello all,
> 
> The ARM architecture mandates the use of a break-before-make sequence when
> changing translation entries if the page table is shared between multiple
> CPUs whenever a valid entry is replaced by another valid entry (see D4.7.1
> in ARM DDI 0487A.j for more details).
> 
> The current P2M code does not respect this sequence and may result to
> break coherency on some processors.
> 
> Adapting the current implementation to use break-before-make sequence would
> imply some code duplication and more TLBs invalidations than necessary.
> For instance, if we are replacing a 4KB page and the current mapping in
> the P2M is using a 1GB superpage, the following steps will happen:
> 1) Shatter the 1GB superpage into a series of 2MB superpages
> 2) Shatter the 2MB superpage into a series of 4KB superpages
> 3) Replace the 4KB page
> 
> As the current implementation is shattering while descending and install
> the mapping before continuing to the next level, Xen would need to issue 3
> TLB invalidation instructions which is clearly inefficient.
> 
> Furthermore, all the operations which modify the page table are using the
> same skeleton. It is more complicated to maintain different code paths than
> having a generic function that set an entry and take care of the break-before-
> make sequence.
> 
> The new implementation is based on the x86 EPT one which, I think, fits
> quite well for the break-before-make sequence whilst keeping the code
> simple.
> 
> For all the changes see in each patch.
> 
> I have provided a branch based on upstream here:
> git://xenbits.xen.org/people/julieng/xen-unstable.git branch p2m-v2

Committed


> Comments are welcome.
> 
> Yours sincerely,
> 
> Cc: Razvan Cojocaru 
> Cc: Tamas K Lengyel 
> Cc: Shanker Donthineni 
> Cc: Dirk Behme 
> Cc: Edgar E. Iglesias 
> 
> Julien Grall (23):
>   xen/arm: do_trap_instr_abort_guest: Move the IPA computation out of
> the switch
>   xen/arm: p2m: Store in p2m_domain whether we need to clean the entry
>   xen/arm: p2m: Rename parameter in p2m_{remove,write}_pte...
>   xen/arm: p2m: Use typesafe gfn in p2m_mem_access_radix_set
>   xen/arm: p2m: Add a back pointer to domain in p2m_domain
>   xen/arm: traps: Move MMIO emulation code in a separate helper
>   xen/arm: traps: Check the P2M before injecting a data/instruction
> abort
>   xen/arm: p2m: Invalidate the TLBs when write unlocking the p2m
>   xen/arm: p2m: Change the type of level_shifts from paddr_t to uint8_t
>   xen/arm: p2m: Move the lookup helpers at the top of the file
>   xen/arm: p2m: Introduce p2m_get_root_pointer and use it in
> __p2m_lookup
>   xen/arm: p2m: Introduce p2m_get_entry and use it to implement
> __p2m_lookup
>   xen/arm: p2m: Replace all usage of __p2m_lookup with p2m_get_entry
>   xen/arm: p2m: Re-implement p2m_cache_flush using p2m_get_entry
>   xen/arm: p2m: Make p2m_{valid,table,mapping} helpers inline
>   xen/arm: p2m: Introduce a helper to check if an entry is a superpage
>   xen/arm: p2m: Introduce p2m_set_entry and __p2m_set_entry
>   xen/arm: p2m: Re-implement relinquish_p2m_mapping using
> p2m_{get,set}_entry
>   xen/arm: p2m: Re-implement p2m_remove_using using p2m_set_entry
>   xen/arm: p2m: Re-implement p2m_insert_mapping using p2m_set_entry
>   xen/arm: p2m: Re-implement p2m_set_mem_access using
> p2m_{set,get}_entry
>   xen/arm: p2m: Do not handle shattering in p2m_create_table
>   xen/arm: p2m: Export p2m_*_lock helpers
> 
>  xen/arch/arm/domain.c  |8 +-
>  xen/arch/arm/p2m.c | 1316 
> ++--
>  xen/arch/arm/traps.c   |  126 +++--
>  xen/include/asm-arm/p2m.h  |   63 +++
>  xen/include/asm-arm/page.h |8 +
>  5 files changed, 828 insertions(+), 693 deletions(-)
> 
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH v2] arm/mem_access: don't reinject stage 2 access exceptions

[Julien Grall]

Hello Andrew,

On 27/09/2016 17:07, Andrew Cooper wrote:

On 28/09/2016 01:01, Julien Grall wrote:

Hi Tamas,

On 03/08/2016 11:13, Tamas K Lengyel wrote:

The only way a guest may trip with stage 2 access violation is if
mem_access is
or was in-use, so reinjecting these exceptions to the guest is never
required.

Requested-by: Julien Grall 
Signed-off-by: Tamas K Lengyel 


Reviewed-by: Julien Grall 

Regards,


---
Cc: Stefano Stabellini 
Cc: Julien Grall 

v2: simplify the patch by never reinjecting the exception
---
 xen/arch/arm/traps.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index f509a00..da951c0 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2415,11 +2415,12 @@ static void do_trap_instr_abort_guest(struct
cpu_user_regs *regs,
 goto bad_insn_abort;
 }

-rc = p2m_mem_access_check(gpa, gva, npfec);
-
-/* Trap was triggered by mem_access, work here is done */
-if ( !rc )
-return;
+p2m_mem_access_check(gpa, gva, npfec);
+/*
+ * The only way to get here right now is because of mem_access,
+ * thus reinjecting the exception to the guest is never
required.
+ */
+return;


Ignoring errors is always a bad option.  Surely the correct solution is
therefore to ASSERT() that rc is 0.


p2m_mem_access_check returns a boolean to indicate whether a fault is 
coming from memaccess or not. You may receive a spurious permission 
fault if the page table have been modified between the time you receive 
the data abort and the time you try to handle the fault in memaccess.


So the ASSERT would be wrong here. The best solution is to return to the 
guest vCPU and retry the instruction.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4] vm_event: Implement ARM SMC events

[Julien Grall]

Hi Tamas,

On 16/09/2016 10:43, Tamas K Lengyel wrote:

The ARM SMC instructions are already configured to trap to Xen by default. In
this patch we allow a user-space process in a privileged domain to receive
notification of when such event happens through the vm_event subsystem by
introducing the PRIVILEGED_CALL type.

The intended use-case for this feature is for a monitor application to be able
insert tap-points into the domU kernel-code. For this task only unconditional
SMC instruction should be used.

Signed-off-by: Tamas K Lengyel 
Acked-by: Wei Liu 
Acked-by: Razvan Cojocaru 
---
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Julien Grall 

v4: Style fixes

Note: previous discussion around this patch proposed filtering SMCs with failed
  condition checks. As that patch is yet-to-be implemented and the 4.8
  code-freeze rapidly approaching I would like this patch to get included.
  In this patch a proper warning is placed in the public header for
  potential users not to rely on SMCs with failed condition checks being
  trapped. As the intended use-case for this feature doesn't use
  conditional SMCs this warning should be sufficient. Hardware that does
  issue events for SMCs with failed condition checks doesn't pose a problem
  for a monitor application in any way. The xen-access test tool illustrates
  how SMCs issued by the guest can be safely handled for all cases.


I will let Stefano decides whether we should include this patch as it in 
Xen 4.8.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] arm/mem_access: don't reinject stage 2 access exceptions

[Andrew Cooper]

On 28/09/2016 01:01, Julien Grall wrote:
> Hi Tamas,
>
> On 03/08/2016 11:13, Tamas K Lengyel wrote:
>> The only way a guest may trip with stage 2 access violation is if
>> mem_access is
>> or was in-use, so reinjecting these exceptions to the guest is never
>> required.
>>
>> Requested-by: Julien Grall 
>> Signed-off-by: Tamas K Lengyel 
>
> Reviewed-by: Julien Grall 
>
> Regards,
>
>> ---
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>>
>> v2: simplify the patch by never reinjecting the exception
>> ---
>>  xen/arch/arm/traps.c | 22 --
>>  1 file changed, 12 insertions(+), 10 deletions(-)
>>
>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>> index f509a00..da951c0 100644
>> --- a/xen/arch/arm/traps.c
>> +++ b/xen/arch/arm/traps.c
>> @@ -2415,11 +2415,12 @@ static void do_trap_instr_abort_guest(struct
>> cpu_user_regs *regs,
>>  goto bad_insn_abort;
>>  }
>>
>> -rc = p2m_mem_access_check(gpa, gva, npfec);
>> -
>> -/* Trap was triggered by mem_access, work here is done */
>> -if ( !rc )
>> -return;
>> +p2m_mem_access_check(gpa, gva, npfec);
>> +/*
>> + * The only way to get here right now is because of mem_access,
>> + * thus reinjecting the exception to the guest is never
>> required.
>> + */
>> +return;

Ignoring errors is always a bad option.  Surely the correct solution is
therefore to ASSERT() that rc is 0.

Doing so will catch the case where this comment is no longer accurate,
due to either a bug or change in semantics.

~Andrew

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

Re: [Xen-devel] [PATCH v2] arm/mem_access: don't reinject stage 2 access exceptions

[Julien Grall]

Hi Tamas,

On 03/08/2016 11:13, Tamas K Lengyel wrote:

The only way a guest may trip with stage 2 access violation is if mem_access is
or was in-use, so reinjecting these exceptions to the guest is never required.

Requested-by: Julien Grall 
Signed-off-by: Tamas K Lengyel 


Reviewed-by: Julien Grall 

Regards,


---
Cc: Stefano Stabellini 
Cc: Julien Grall 

v2: simplify the patch by never reinjecting the exception
---
 xen/arch/arm/traps.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index f509a00..da951c0 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2415,11 +2415,12 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 goto bad_insn_abort;
 }

-rc = p2m_mem_access_check(gpa, gva, npfec);
-
-/* Trap was triggered by mem_access, work here is done */
-if ( !rc )
-return;
+p2m_mem_access_check(gpa, gva, npfec);
+/*
+ * The only way to get here right now is because of mem_access,
+ * thus reinjecting the exception to the guest is never required.
+ */
+return;
 }
 break;
 }
@@ -2462,11 +2463,12 @@ static void do_trap_data_abort_guest(struct 
cpu_user_regs *regs,
 .kind = dabt.s1ptw ? npfec_kind_in_gpt : npfec_kind_with_gla
 };

-rc = p2m_mem_access_check(info.gpa, info.gva, npfec);
-
-/* Trap was triggered by mem_access, work here is done */
-if ( !rc )
-return;
+p2m_mem_access_check(info.gpa, info.gva, npfec);
+/*
+ * The only way to get here right now is because of mem_access,
+ * thus reinjecting the exception to the guest is never required.
+ */
+return;
 }
 break;
 }



--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 7/7] xen/arm: Map mmio-sram nodes as un-cached memory

[Julien Grall]

Hi Edgar,

On 23/09/2016 11:53, Edgar E. Iglesias wrote:

From: "Edgar E. Iglesias" 

Map mmio-sram nodes as un-cached memory. If the node
has set the no-memory-wc property, we map it as device.

The DTS bindings for mmio-sram nodes can be found in the
Linux tree under Documentation/devicetree/bindings/sram/sram.txt.

Signed-off-by: Edgar E. Iglesias 


Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 3/7] xen/arm: Rename and generalize un/map_regions_rw_cache

[Julien Grall]

Hi Edgar,

On 23/09/2016 11:53, Edgar E. Iglesias wrote:

From: "Edgar E. Iglesias" 

Rename and generalize un/map_regions_rw_cache into
un/map_regions_p2mt. The new functions take the mapping
attributes as an argument.

No functional change.

Signed-off-by: Edgar E. Iglesias 


Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 2/7] xen/arm: p2m: Add support for normal non-cacheable memory

[Julien Grall]

Hi Edgar,

On 23/09/2016 11:53, Edgar E. Iglesias wrote:

From: "Edgar E. Iglesias" 

Add support for describing normal non-cacheable memory.

Signed-off-by: Edgar E. Iglesias 


Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [Xen-users] pvgrub: Error 9: Unknown boot failure

[Sven Köhler]

Am 27.09.2016 um 14:52 schrieb Juergen Gross:
> On 27/09/16 14:09, Sven Köhler wrote:
>> Am 27.09.2016 um 14:02 schrieb Juergen Gross:
>>> On 27/09/16 13:13, Sven Köhler wrote:
 Am 27.09.2016 um 07:31 schrieb Juergen Gross:
> On 27/09/16 00:48, Sven Köhler wrote:
>> Am 26.09.2016 um 07:43 schrieb Juergen Gross:
>>> On 25/09/16 18:04, Sven Köhler wrote:
 Hi,

 I'm experiencing the bug below which was discussed on xen-devel 
 December
 last year buy Ian and Juergen. I'm using xen-pvgrub-4.7.0 on Gentoo.

 The bug only seems to occur with the last domU booted on my machine.
 Where do I find a patch that fixes that?
>>>
>>> The issue back in December was fixed by commit
>>> c8eb0ec277ae387e78d685523e0fee633e46f046 which is included in Xen 4.7.
>>> Either gentoo didn't update to the official Xen 4.7 release (including
>>> pvgrub) or you are seeing a new issue.
>>
>> From the looks of it, the Gentoo package is using the grub from the
>> xen-4.7.0 tarball.
>>
>> I downgraded to pvgrub 4.6.3 and the problem went away.
>>
>> So I assume I'm seeing a new issue. How do I debug it?
>
> Interesting. Just tested it on upstream Xen and saw the same problem
> with a rather old guest kernel (3.0 based, xen flavor), while a newer
> kernel (4.1, pvops) is working.
>
> Can you give me some more details about the kernel you are trying to
> boot?

 It's an unmodified 4.4.21 kernel which I compile by hand. The config is
 attached. Does that help?
>>>
>>> Not really. OTOH I think I don't need more help, as I've found a problem
>>> in pvgrub. I have a patch which seems to correct the issue. Are you fine
>>> with me adding you as the original reporter of the problem in the patch?
>>
>> Yes, I'm fine with adding me as the reporter.
>> Do you want me to test the patch first?
> 
> Sure. The attached patch is for Xen upstream, but I think it should
> apply to Xen 4.7, too.

This patch solved the issue for me. My domU boots fine again after
recompiling pvgrub with the patch applied.

Thanks!


Regards,
  Sven

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 qemuu333ec4ca6a9f604331e2349cb91e9635f65d6462
baseline version:
 qemuu7cfdc02dae0d2ff58c897496cfdbbafc0eda0f3f

Last test of basis   101156  2016-09-26 20:14:27 Z1 days
Testing same since   101172  2016-09-27 18:43:46 Z0 days1 attempts


People who touched revisions under test:
  Alexey Kardashevskiy 
  Dmitry Fleytman 
  Gonglei 
  Greg Kurz 
  Jason Wang 
  Li Zhijian 
  Michael S. Tsirkin 
  Paolo Bonzini 
  Peter Lieven 
  Peter Maydell 
  Prasad J Pandit 
  Shmulik Ladkani 
  Shmulik Ladkani 
  Wen Congyang 
  Zhang Chen 

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 v4 1/7] xen/arm: p2m: Rename p2m_mmio_direct_nc -> p2m_mmio_direct_dev

[Julien Grall]

Hi Edgar,

On 23/09/2016 11:53, Edgar E. Iglesias wrote:

From: "Edgar E. Iglesias" 

Rename p2m_mmio_direct_nc to p2m_mmio_direct_dev to better
express that we are mapping device memory. This will allow us
to use p2m_mmio_direct_nc for Normal Non-Cached mappings.

No functional change.

Signed-off-by: Edgar E. Iglesias 


Reviewed-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC v7 07/14] efi: create new early memory allocator

[Julien Grall]

Hi Jan,

On 27/09/2016 01:06, Jan Beulich wrote:

On 26.09.16 at 22:01,  wrote:

On 25/09/2016 23:53, Jan Beulich wrote:

On 24.09.16 at 01:35,  wrote:

On 23/09/2016 22:47, Daniel Kiper wrote:

@@ -66,6 +67,7 @@ integer_param("xenheap_megabytes", opt_xenheap_megabytes);

 static __used void init_done(void)
 {
+free_ebmalloc_unused_mem();


I said no to this on the previous version. And I think Jan suggested a
per-arch way to do it. So why is it here?


No, I specifically did not. I intended this to be universal, but then I
wasn't really aware that on ARM the EFI loader is so much different
from x86's.

Before coming to a final conclusion I'd really like to understand how
you would see dynamic memory allocation to work for pieces of data
to be communicated from EFI loader to main Xen. That'll determine
whether I'll have to grumblingly accept this code to be x86-specific.


In the current state, all the communication from EFI loader to main Xen
should be done via the device-tree or the data have to be in init
section (bss is zeroed when leaving the EFI stub and before entering to
Xen).


This late .bss zeroing is something which, as Daniel had already
suggested, could (and imo should) be avoided (just like he already
needs to do for x86 in his series).


I am happy to see a such patch for ARM.




I am not against changing this behavior, however in the current state
this will not work at all. The call to the function will be misleading,
hence why I suggested a TODO for the time-being (for now the code is
only compiled on x86, anyway).


This doesn't really help make progress with the patch here. The
question isn't so much what current behavior should be, but what
sane behavior would be going forward. Again - we're needing your
input mainly to decide whether to put this allocator in common or
x86-specific code (with the goal of not having to move it later if at
all possible).


Unifying the behavior between x86 and ARM would be the best.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 14/16] livepatch: Initial ARM32 support.

[Julien Grall]

Hi Konrad,

On 27/09/2016 10:50, Konrad Rzeszutek Wilk wrote:

On Tue, Sep 27, 2016 at 09:39:06AM -0700, Julien Grall wrote:



   - Rebased on "livepatch: Drop _jmp from arch_livepatch_[apply,revert]_jmp"
   - Added explanation for the usage of data cache and why we need to sync it.


... you also replace the clean_and_invalidate to the old_ptr by
clean_and_invalidate to the new_ptr.


Ah yes! I had it in my patch queue but neglected to email it out.


Good, I wanted to make sure you replicate the change requested on ARM64 
to ARM32.




Here is what I have in the git branch:

From 8bf07ac18e2cfcf304860aa00ab157e1e7f77ed9 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Thu, 22 Sep 2016 20:15:09 -0400
Subject: [PATCH] livepatch: Initial ARM32 support.

The patch piggybacks on: livepatch: Initial ARM64 support, which
brings up all of the necessary livepatch infrastructure pieces in.

This patch adds three major pieces:

 1) ELF relocations. ARM32 uses SHT_REL instead of SHT_RELA which
means the adddendum had to be extracted from within the
instruction. Which required parsing BL/BLX, B/BL,
MOVT, and MOVW instructions.

The code was written from scratch using the ARM ELF manual
(and the ARM Architecture Reference Manual)

 2) Inserting an trampoline. We use the B (branch to address)
which uses an offset that is based on the PC value: PC + imm32.
Because we insert the branch at the start of the old function
we have to account for the instruction already being fetched
and subtract -8 from the delta (new_addr - old_addr). See
ARM DDI 0406C.c, see A2.3 (pg 45) and A8.8.18 pg (pg 334,335)

 3) Allows the test-cases to be built under ARM 32.
The "livepatch: tests: Make them compile under ARM64"
put in the right infrastructure for it and we piggyback on it.

Acked-by: Jan Beulich  [for non-ARM parts]
Signed-off-by: Konrad Rzeszutek Wilk 


Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 7807dea57fba6a019bb8641572e0159ffa03ad9e
baseline version:
 ovmf 333ba578fef4dff8921051410c5b56f63e7eeadb

Last test of basis67771  2016-09-27 09:18:56 Z0 days
Testing same since67773  2016-09-27 15:47:51 Z0 days1 attempts


People who touched revisions under test:
  Felix Polyudov 
  Gao, Liming 
  Hao Wu 
  Yonghong Zhu 

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 7807dea57fba6a019bb8641572e0159ffa03ad9e
Author: Hao Wu 
Date:   Tue Sep 27 10:07:18 2016 +0800

BaseTools: List missing source python files for Ecc tool in Makefile

Add missing python sources files that are dependent for Ecc tool in
Makefile.

Cc: Yonghong Zhu 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
Reviewed-by: Liming Gao 
Reviewed-by: Yonghong Zhu 

commit 324dd9b468fc53c1b162035334620e47a0637b41
Author: Yonghong Zhu 
Date:   Sun Sep 25 10:47:08 2016 +0800

BaseTools: Add some posixlike files for Linux

Add the posixlike files for Rsa2048Sha256Sign, Rsa2048Sha256GenerateKeys
and Pkcs7Sign.

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

commit 84ace59fd7c4a23e27e89756e449d058907b4ac6
Author: Gao, Liming 
Date:   Tue Sep 20 22:02:28 2016 +0800

MdePkg: Add SMM PciExpressLib Instance

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Felix Polyudov 
Reviewed-by: Liming Gao 

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

[Xen-devel] [xen-unstable test] 101169: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  ecee7bfc18c69892e2a3b213448e592eceeccb7a
baseline version:
 xen  9bb1865cca15b28be5aa185cd865b95b49e7b303

Last test of basis   101164  2016-09-27 09:15:42 Z0 days
Testing same since   101169  2016-09-27 15:44:16 Z0 days1 attempts


People who touched revisions under test:
  Roger Pau Monne 
  Roger Pau Monné 
  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  pass
 build-armhf-libvirt  pass
 build-i386-libvirt  

Re: [Xen-devel] [PATCH v7 14/14] x86: add multiboot2 protocol support for relocatable images

[Daniel Kiper]

On Mon, Sep 26, 2016 at 09:53:45AM -0600, Jan Beulich wrote:
> >>> On 23.09.16 at 23:47,  wrote:
> > @@ -383,10 +390,19 @@ __start:
> >  cmp %edi,MB2_fixed_total_size(%ebx)
> >  jbe trampoline_bios_setup
> >
> > +/* Get Xen image load base address from Multiboot2 information. */
> > +cmpl$MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR,MB2_tag_type(%ecx)
> > +jne 1f
> > +
> > +mov MB2_load_base_addr(%ecx),%esi
> > +sub $XEN_IMG_OFFSET,%esi
> > +jmp 9f
> > +
> > +1:
> >  /* Get mem_lower from Multiboot2 information. */
> >  cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,MB2_tag_type(%ecx)
> >  cmove   MB2_mem_lower(%ecx),%edx
> > -je  trampoline_bios_setup
> > +je  9f
> >
> >  /* EFI IA-32 platforms are not supported. */
> >  cmpl$MULTIBOOT2_TAG_TYPE_EFI32,MB2_tag_type(%ecx)
>
> Considering that you look for another tag type here, doesn't the
> branch target change above point out an issue in an earlier patch?

Good point. This change should be part of patch #8 introducing multiboot2
protocol support for EFI platforms.

Daniel

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

Re: [Xen-devel] [PATCH v7 12/14] x86: make Xen early boot code relocatable

[Daniel Kiper]

On Mon, Sep 26, 2016 at 09:03:30AM -0600, Jan Beulich wrote:
> >>> On 23.09.16 at 23:47,  wrote:
> > @@ -426,32 +453,65 @@ trampoline_bios_setup:
> >  xor %cl, %cl
> >
> >  trampoline_setup:
> > +/*
> > + * Called on legacy BIOS and EFI platforms.
> > + *
> > + * Initialize 0-15 bits of BOOT_FS segment descriptor base address.
> > + */
> > +mov %si,BOOT_FS+2+sym_esi(trampoline_gdt)
> > +
> > +/* Initialize 16-23 bits of BOOT_FS segment descriptor base 
> > address. */
> > +mov %esi,%edx
> > +shr $16,%edx
>
> I'd have liked it even better if you had done this with a single
> instruction, but anyway.

Do you think about "shld $16,%esi,%edx"?

> > @@ -474,23 +534,53 @@ trampoline_setup:
> >
> >  /* Stash TSC to calculate a good approximation of time-since-boot 
> > */
> >  rdtsc
> > -mov %eax,sym_phys(boot_tsc_stamp)
> > -mov %edx,sym_phys(boot_tsc_stamp+4)
> > +mov %eax,sym_fs(boot_tsc_stamp)
> > +mov %edx,sym_fs(boot_tsc_stamp)+4
> > +
> > +/*
> > + * Update frame addresses in page tables excluding l2_identmap
> > + * without its first entry which points to l1_identmap.
> > + */
> > +mov $((__page_tables_end-__page_tables_start)/8),%ecx
> > +mov $(((l2_identmap-__page_tables_start)/8)+2),%edx
>
> The +2 instead of +1 here is confusing. Why don't you do the natural
> thing here and ...
>
> > +1:  cmp 
> > $((l2_identmap+l2_identmap_sizeof-__page_tables_start)/8),%ecx
> > +cmove   %edx,%ecx
> > +je  2f
>
> ... simply drop this branch?

Make sense. I will do that.

> > +testl   $_PAGE_PRESENT,sym_fs(__page_tables_start)-8(,%ecx,8)
> > +jz  2f
> > +add %esi,sym_fs(__page_tables_start)-8(,%ecx,8)
> > +2:  loop1b
> > +
> > +/* Initialize L2 boot-map/direct map page table entries (14MB). */
> > +lea sym_esi(start),%ebx
> > +lea 
> > (1< > +shr $(L2_PAGETABLE_SHIFT-3),%ebx
> > +mov $8,%ecx
>
> The comment saying 14Mb kind of contradicts this being 8 here.

Ahhh... Right, comment is wrong.

> > +1:  mov %eax,sym_fs(l2_bootmap)-8(%ebx,%ecx,8)
> > +mov %eax,sym_fs(l2_identmap)-8(%ebx,%ecx,8)
> > +sub $(1< > +loop1b
> > +
> > +/* Initialize L3 boot-map page directory entry. */
> > +lea 
> > __PAGE_HYPERVISOR+(L2_PAGETABLE_ENTRIES*8)*3+sym_esi(l2_bootmap),%eax
> > +mov $4,%ecx
> > +1:  mov %eax,sym_fs(l3_bootmap)-8(,%ecx,8)
> > +sub $(L2_PAGETABLE_ENTRIES*8),%eax
> > +loop1b
> >
> >  /*
> >   * During boot, hook 4kB mappings of first 2MB of memory into L2.
> > - * This avoids mixing cachability for the legacy VGA region, and is
> > - * corrected when Xen relocates itself.
> > + * This avoids mixing cachability for the legacy VGA region.
> >   */
> > -mov $sym_phys(l1_identmap)+__PAGE_HYPERVISOR,%edi
> > -mov %edi,sym_phys(l2_xenmap)
> > +lea __PAGE_HYPERVISOR+sym_esi(l1_identmap),%edi
> > +mov %edi,sym_fs(l2_bootmap)
>
> Switching from l2_xenmap to l2_bootmap here?

Do we need first 2 MiB mapped in Xen image mapping? It looks that we do not.
Am I missing something?

I must initialize l2_bootmap first entry with l1_identmap here because
I removed relevant static initialization from x86_64.S.

> > @@ -121,8 +127,9 @@ GLOBAL(l2_identmap)
> >   * page.
> >   */
> >  GLOBAL(l2_xenmap)
> > -idx = 0
> > -.rept 8
> > +.quad 0
> > +idx = 1
> > +.rept 7
> >  .quad sym_phys(__image_base__) + (idx << L2_PAGETABLE_SHIFT) + 
> > (PAGE_HYPERVISOR | _PAGE_PSE)
> >  idx = idx + 1
> >  .endr
>
> How come the first entry doesn't need filling anymore? I think such
> less obvious changes should really get briefly mentioned/explained
> in the commit message.

Ditto. I will add a few words about that to commit message.

> > @@ -674,6 +671,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >
> >  printk("Command line: %s\n", cmdline);
> >
> > +printk("Xen image load base address: 0x%08lx\n", xen_phys_start);
>
> Please prefer %#lx in cases like this.

If I do that then 0 is displayed as 0 instead of 0x. I prefer
latter. If you do not care I can use "%#lx" as you wish.

> > @@ -1018,6 +1018,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >  : "memory" );
> >
> >  bootstrap_map(NULL);
> > +
> > +printk("New Xen image base address: %#08lx\n", xen_phys_start);
>
> # and a minimum width generally don't fit together well.

Why?

Daniel

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf eab26788156436a549610a299d2e297c22043e70
baseline version:
 ovmf 7807dea57fba6a019bb8641572e0159ffa03ad9e

Last test of basis   101165  2016-09-27 09:43:58 Z0 days
Testing same since   101170  2016-09-27 16:45:31 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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=eab26788156436a549610a299d2e297c22043e70
+ . ./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 
eab26788156436a549610a299d2e297c22043e70
+ branch=ovmf
+ revision=eab26788156436a549610a299d2e297c22043e70
+ . ./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
+ '[' xeab26788156436a549610a299d2e297c22043e70 = 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
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

[Xen-devel] [xtf test] 101171: all pass - PUSHED

[osstest service owner]

flight 101171 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101171/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  efe6103963c6756f5c7b7726adf4e2aea53cd51b
baseline version:
 xtf  b5c5332de4268d33a6f8eadc1d17c7b9cf0e7dc3

Last test of basis   100874  2016-09-10 12:13:11 Z   17 days
Testing same since   101171  2016-09-27 17:15:45 Z0 days1 attempts


People who touched revisions under test:
  Wei Liu 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   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=xtf
+ revision=efe6103963c6756f5c7b7726adf4e2aea53cd51b
+ . ./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 xtf 
efe6103963c6756f5c7b7726adf4e2aea53cd51b
+ branch=xtf
+ revision=efe6103963c6756f5c7b7726adf4e2aea53cd51b
+ . ./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=xtf
+ xenbranch=xen-unstable
+ '[' xxtf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xefe6103963c6756f5c7b7726adf4e2aea53cd51b = 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
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' 

Re: [Xen-devel] [PATCH v6 16/16] libxl/arm: Add the size of ACPI tables to maxmem

[Shannon Zhao]

On 2016/9/27 9:35, Wei Liu wrote:

On Tue, Sep 27, 2016 at 09:01:00AM -0700, Shannon Zhao wrote:



On 2016/9/27 2:41, Wei Liu wrote:

On Mon, Sep 26, 2016 at 02:54:55PM -0700, Shannon Zhao wrote:



On 2016/9/22 7:10, Wei Liu wrote:

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c

index 2924629..118beab 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -408,8 +408,15 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
}
}

+
+rc = libxl__arch_memory_constant(gc, info, state);
+if (rc < 0) {
+LOGE(ERROR, "Couldn't get arch constant memory size");
+return ERROR_FAIL;
+}
+
if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
-LIBXL_MAXMEM_CONSTANT) < 0) {
+LIBXL_MAXMEM_CONSTANT + rc) < 0) {

I think this LIBXL_MAXMEM_CONSTANT should be pushed to your helper
function, too.

So that, we can have all LIBXL_MAXMEM_CONSTANT removed in libxl
functions (see libxl.c and libxl_dom.c)


If we push LIBXL_MAXMEM_CONSTANT to the libxl_arch_memory_constant and
remove it from libxl.c, do we need to call libxl_arch_memory_constant there
in libxl_set_memory_target()?



Yes, we need to call that function everywhere to get consistent results.
That's the reason I asked you to consolidate it to a function.


Well it's a little awkward I think, since in libxl_domain_setmaxmem() and
libxl_set_memory_target() it seems it can't get the parameters info and
state for libxl__arch_memory_constant().
I'm not sure how to solve it. Wei, any suggestion?



Hmm...

The first question is can state be derived from build_info ? From my
quick skim of the code the answer is likely yes.

I'm not familiar with the relationship between these structures and not 
sure how to do this. Please give me some suggestion.



Then, you can call libxl_retrieve_domain_configuration to get
domain_config, then domain_config->build_info, so that you can derive
state from it.

Feel free to ask more questions.

Without such arrangement, ballooning is going to be broken for ARM
guests.


I see.

Thanks,
--
Shannon

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

Re: [Xen-devel] [PATCH v7 08/14] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Mon, Sep 26, 2016 at 09:12:40AM -0600, Jan Beulich wrote:
> >>> On 26.09.16 at 16:40,  wrote:
> > On 26/09/16 15:33, Jan Beulich wrote:
> > On 26.09.16 at 16:19,  wrote:
> >>> On 23/09/16 22:47, Daniel Kiper wrote:
>  +/*
>  + * Initialize BSS (no nasty surprises!).
>  + * It must be done earlier than in BIOS case
>  + * because efi_multiboot2() touches it.
>  + */
>  +lea .startof.(.bss)(%rip),%edi
>  +mov $.sizeof.(.bss),%ecx
> >>> Sorry, but you cannot use this syntax, for the same reasons why I won't
> >>> accept Jan's patch making similar changes elsewhere.
> >>>
> >>> Amongst other issues, you will break the Clang build with it.
> >> Did you verify meanwhile that this doesn't work with llvm?
> >
> > Yes.
> >
> > andrewcoop@andrewcoop:/local/xen.git/xen$ cat foo.c
> > #include 
> >
> > static unsigned int x;
> >
> > int main(void)
> > {
> > asm volatile("lea .startof.(.bss)(%%rip), %%rdi;"
> >  "mov $.sizeof.(.bss), %%rcx;"
> >  "mov $-1, %%rax;"
> >  "rep stosb;"
> >  ::: "memory", "rax", "rcx", "rdi");
> > printf("x: %#x\n", x);
> > }
> > andrewcoop@andrewcoop:/local/xen.git/xen$ gcc foo.c -o foo && ./foo
> > x: 0x
> > andrewcoop@andrewcoop:/local/xen.git/xen$ clang-3.8 foo.c -o foo && ./foo
> > foo.c:7:18: error: unexpected token in memory operand
> > asm volatile("lea .startof.(.bss)(%%rip), %%rdi;"
> >  ^
> > :1:16: note: instantiated into assembly here
> > lea .startof.(.bss)(%rip), %rdi;mov $.sizeof.(.bss), %rcx;mov
> > $-1, %rax;rep stosb;
> >   ^
> > foo.c:7:18: error: unexpected token in argument list
> > asm volatile("lea .startof.(.bss)(%%rip), %%rdi;"
> >  ^
> > :1:47: note: instantiated into assembly here
> > lea .startof.(.bss)(%rip), %rdi;mov $.sizeof.(.bss), %rcx;mov
> > $-1, %rax;rep stosb;
> >  ^
> > 2 errors generated.
>
> No, that's inline assembly, which does not match Daniel's use
> case. That's why I referred to llvm, as with assembly sources it
> should only be the linker which gets to see the symbols generated
> from those constructs (and if llvm supported them I'd then consider
> breaking out the assembly file changes from that patch of mine).

Guys, may I suggest using sym_phys(__bss_start)/sym_phys(__bss_end) as
it is in head.S right now? If .startof.()/.sizeof.() works as expected
and both of you accept it then later we can move to new approach. Does
it make sense?

Daniel

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

Re: [Xen-devel] [PATCH v7 08/14] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Mon, Sep 26, 2016 at 07:47:42AM -0600, Jan Beulich wrote:
> >>> On 23.09.16 at 23:47,  wrote:
> > This way Xen can be loaded on EFI platforms using GRUB2 and
> > other boot loaders which support multiboot2 protocol.
> >
> > Signed-off-by: Daniel Kiper 
> > Acked-by: Jan Beulich 
> > ---
> > v7 - suggestions/fixes:
> >- do not allocate twice memory for trampoline if we were
> >  loaded via multiboot2 protocol on EFI platform,
>
> If you fix bugs not noticed by a reviewer but by yourself, please
> drop all acks/R-b-s covering the code in question. And then I'm

OK.

> afraid I haven't even been able to locate that change - could you
> please point out what you did where?

The change is very subtle. I add trampoline_setup label behind

 /* From arch/x86/smpboot.c: start_eip had better be page-aligned! */
 xor %cl, %cl

instead of

 cmp %ecx,%edx   /* compare with BDA value */
 cmovb   %edx,%ecx   /* and use the smaller */

> > +/*
> > + * Initialize BSS (no nasty surprises!).
> > + * It must be done earlier than in BIOS case
> > + * because efi_multiboot2() touches it.
> > + */
> > +lea .startof.(.bss)(%rip),%edi
> > +mov $.sizeof.(.bss),%ecx
> > +shr $3,%ecx
> > +xor %eax,%eax
> > +rep stosq
> > +
> > +pop %rdi
> > +
> > +/*
> > + * efi_multiboot2() is called according to System V AMD64 ABI:
> > + *   - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
> > + *   - OUT: %rax - highest usable memory address below 1 MiB;
> > + * memory above this address is reserved for 
> > trampoline;
> > + * memory below this address is used for stack and 
> > as
> > + * a storage for boot data.
>
> How can you validly use memory below this address? (And I'd like to

Right, I should not do that blindly. As quick fix we can check in 
efi_arch_process_memory_map()
that chosen memory region has size cfg.size plus let's say 64 KiB. Is it 
sufficient
for you? However, I think that later (for 4.9?) we should consider what we 
discussed
here https://lists.xen.org/archives/html/xen-devel/2016-09/msg01424.html

> note that this also changed from v6, and the change to comments
> listed in the v7 section and supposedly suggested by me can't cover
> this, as I don't recall having asked for such an adjustment.)

Ah, sorry about that. I should be more precise.

Daniel

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

Re: [Xen-devel] [PATCH v5 14/16] livepatch: Initial ARM32 support.

[Konrad Rzeszutek Wilk]

On Tue, Sep 27, 2016 at 09:39:06AM -0700, Julien Grall wrote:
> Hi Konrad,
> 
> On 21/09/2016 10:32, Konrad Rzeszutek Wilk wrote:
> > The patch piggybacks on: livepatch: Initial ARM64 support, which
> > brings up all of the necessary livepatch infrastructure pieces in.
> > 
> > This patch adds three major pieces:
> > 
> >  1) ELF relocations. ARM32 uses SHT_REL instead of SHT_RELA which
> > means the adddendum had to be extracted from within the
> > instruction. Which required parsing BL/BLX, B/BL,
> > MOVT, and MOVW instructions.
> > 
> > The code was written from scratch using the ARM ELF manual
> > (and the ARM Architecture Reference Manual)
> > 
> >  2) Inserting an trampoline. We use the B (branch to address)
> > which uses an offset that is based on the PC value: PC + imm32.
> > Because we insert the branch at the start of the old function
> > we have to account for the instruction already being fetched
> > and subtract -8 from the delta (new_addr - old_addr). See
> > ARM DDI 0406C.c, see A2.3 (pg 45) and A8.8.18 pg (pg 334,335)
> > 
> >  3) Allows the test-cases to be built under ARM 32.
> > The "livepatch: tests: Make them compile under ARM64"
> > put in the right infrastructure for it and we piggyback on it.
> > 
> > Acked-by: Julien Grall 
> > Acked-by: Jan Beulich  [for non-ARM parts]
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > ---
> > Cc: Julien Grall 
> > Cc: Stefano Stabellini 
> > 
> > v2: First submission.
> > v3: Use LIVEPATCH_ARCH_RANGE instead of NEGATIVE_32MB macro
> >-Use PATCH_INSN_SIZE instead of the value 4.
> >-Ditch the old_ptr local variable.
> >-Use 8 for evaluating the branch instead of 4. Based on ARM docs.
> >-NOP patch up to sizeof(opaque) % PATCH_INSN_SIZE (so 7 instructions).
> >-Don't mask 0x00F_E_ after shifting, instead mask by 0x00F_F_.
> > The reason is that offset is constructed by shifting by two the insn
> > (except the first two bytes) by left which meant we would have cleared
> > offset[2]! - and jumped to a location that was -4 bytes off.
> >-Update commit description to have -8 instead of -4 delta and also
> > include reference to spec.
> > v4: Added Jan's Ack.
> >s/PATCH_INSN_SIZE/ARCH_PATCH_INSN_SIZE/
> >s/arch_livepatch_insn_len/livepatch_insn_len/
> >s/LIVEPATCH_ARCH_RANGE/ARCH_LIVEPATCH_RANGE/
> > v5: Added Julien's Ack.
> 
> IHMO my ack should not have been retained given that ...

Ooops!
> 
> >- Rebased on "livepatch: Drop _jmp from 
> > arch_livepatch_[apply,revert]_jmp"
> >- Added explanation for the usage of data cache and why we need to sync 
> > it.
> 
> ... you also replace the clean_and_invalidate to the old_ptr by
> clean_and_invalidate to the new_ptr.

Ah yes! I had it in my patch queue but neglected to email it out.

Here is what I have in the git branch:

From 8bf07ac18e2cfcf304860aa00ab157e1e7f77ed9 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Thu, 22 Sep 2016 20:15:09 -0400
Subject: [PATCH] livepatch: Initial ARM32 support.

The patch piggybacks on: livepatch: Initial ARM64 support, which
brings up all of the necessary livepatch infrastructure pieces in.

This patch adds three major pieces:

 1) ELF relocations. ARM32 uses SHT_REL instead of SHT_RELA which
means the adddendum had to be extracted from within the
instruction. Which required parsing BL/BLX, B/BL,
MOVT, and MOVW instructions.

The code was written from scratch using the ARM ELF manual
(and the ARM Architecture Reference Manual)

 2) Inserting an trampoline. We use the B (branch to address)
which uses an offset that is based on the PC value: PC + imm32.
Because we insert the branch at the start of the old function
we have to account for the instruction already being fetched
and subtract -8 from the delta (new_addr - old_addr). See
ARM DDI 0406C.c, see A2.3 (pg 45) and A8.8.18 pg (pg 334,335)

 3) Allows the test-cases to be built under ARM 32.
The "livepatch: tests: Make them compile under ARM64"
put in the right infrastructure for it and we piggyback on it.

Acked-by: Jan Beulich  [for non-ARM parts]
Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 

v2: First submission.
v3: Use LIVEPATCH_ARCH_RANGE instead of NEGATIVE_32MB macro
   -Use PATCH_INSN_SIZE instead of the value 4.
   -Ditch the old_ptr local variable.
   -Use 8 for evaluating the branch instead of 4. Based on ARM docs.
   -NOP patch up to sizeof(opaque) % PATCH_INSN_SIZE (so 7 instructions).
   -Don't mask 0x00F_E_ after shifting, instead mask by 0x00F_F_.
The reason is that offset is constructed by shifting by two the insn
(except the first two bytes) by left which 

Re: [Xen-devel] [PATCH RFC v7 07/14] efi: create new early memory allocator

[Daniel Kiper]

On Mon, Sep 26, 2016 at 07:37:45AM -0600, Jan Beulich wrote:
> >>> On 23.09.16 at 23:47,  wrote:
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -79,6 +79,10 @@ static size_t wstrlen(const CHAR16 * s);
> >  static int set_color(u32 mask, int bpp, u8 *pos, u8 *sz);
> >  static bool_t match_guid(const EFI_GUID *guid1, const EFI_GUID *guid2);
> >
> > +#ifndef CONFIG_ARM
> > +static void *ebmalloc(size_t size);
> > +#endif
>
> Leaving aside the ARM aspect (to be clarified by Julien), is there a
> reason you need to forward declare this here, rather than moving
> the whole addition from further down up immediately ahead of the
> inclusion point of efi-boot.h?

If you wish I can move ebmalloc code before efi-boot.h inclusion.
There is a pretty good chance that it will work here.

Daniel

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

Re: [Xen-devel] [PATCH v7 01/14] x86: move xen ELF end of image to 16 MiB

[Daniel Kiper]

On Mon, Sep 26, 2016 at 06:32:01AM -0600, Jan Beulich wrote:
> >>> On 26.09.16 at 13:34,  wrote:
> > On Mon, Sep 26, 2016 at 04:39:37AM -0600, Jan Beulich wrote:
> >> >>> On 23.09.16 at 23:47,  wrote:
> >> > It seems that from xen ELF image POV _end symbol properly determine
> >> > image end. However, taking into account that initial Xen image mapping
> >> > covers 16 MiB it looks that it is not sufficient. Currently bootloader
> >> > potentially may load xen ELF image at 1 MiB and let's say put Linux
> >> > kernel or initrd at 8 MiB. Nothing forbids it. This means that initially
> >> > Xen image mapping may cover not only Xen image but also loaded modules.
> >>
> >> Okay, up to here you just describe the state of things, which is fine.
> >>
> >> > So, let's move end of xen ELF image to 16 MiB. This way we avoid above
> >> > mentioned issue because bootloader will be forced to allocate 15 MiB
> >> > memory region for image. Then it (bootloader) would not be able to put
> >> > in this place anything else because from its POV simply this memory
> >> > region will be allocated and used.
> >>
> >> But here you state what the patch does, but not what problem you
> >> solve. And my problem here is that I don't see any problem to be
> >> solved: There may be an overlap of address ranges, but I don't see
> >> that memory being used in two different way. In fact the 16Mb
> >> mapping is just a mapping, without us using anything outside the
> >> Xen image range afaics.
> >
> > However, this begs the question: Why do we map 16 MiB in Xen image address
> > space if we do not expect anything sensible beyond the _end symbol?
>
> Because it allows the page tables to be pre-populated at build time?

I do not think this is full explanation. Though I can agree that 16 MiB mapping
is much easier to create during build but others probably could be created in
that or quite similar way too.

> > Should
> > not we stop just beyond the _end at 2 MiB boundary? This way if something
> > accesses anything between _end and 16 MiB via Xen image mapping then way of
> > failure is more predictable than now.
>
> But that's not necessarily better - we might end up with an early
> boot crash with a black screen.

It depends when failure happens.

> > IIRC, this region (from _end to 16 MiB)
> > is not even zeroed, so, unexpected things may happen.
>
> As long as it doesn't get accessed I don't see what unpredictable
> things you expect to happen.

Well, I do not say about deliberate access but accesses due to bugs.

Anyway, I have a feeling that you do not care about problems described
by me or even you do not think that they exist. I do not agree with you
(well, I agree this is not grave error) but you are maintainer, so,
I will drop this patch.

Daniel

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

Re: [Xen-devel] [Patch] x86emul: simplify prefix handling for VMFUNC

[Lai, Paul]

On Tue, Sep 27, 2016 at 02:26:00AM -0600, Jan Beulich wrote:
> >>> On 26.09.16 at 20:13,  wrote:
> > On Wed, Sep 21, 2016 at 10:22:32AM -0700, Lai, Paul wrote:
> >> On Wed, Sep 21, 2016 at 02:39:58AM -0600, Jan Beulich wrote:
> >> > >>> On 21.09.16 at 00:35,  wrote:
> >> > > On Tue, Sep 20, 2016 at 09:50:15AM -0600, Jan Beulich wrote:
> >> > >> 
> >> > >> Paul, there's been no reply to
> >> > >> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg00380.html
> >> > >>  
> >> > > 
> >> > > The refered to patch, commit a1b1572833, adds a check for vmfunc.
> >> > > I look a little time to look at the SDM and finally found the 
> >> > > reference.
> >> > > The vmfunc can be found in Table A-6 "Opcode Extensions for One- and 
> >> > > Two-
> >> > > byte Opcodes by Group Number" on page A-18 Vol. 2D of the
> >> > >  e64-ia-32-architectures-software-developer-manual-325462.pdf.
> >> > > The values for vmfunc match the values in the code.
> >> > > I also took the liberty of looking at the other existing cases in the
> >> > > switch statement, and can find RDTSCP and INVLPG. The CLZERO extension
> >> > > value is a mystery to me.
> >> > 
> >> > Well - the question raised was whether the documentation is
> >> > perhaps wrong.
> >> 
> >> VMFUNC allowing 66, F2, and F3 prefixes when
> >> > other opcodes in its neighborhood (e.g. xsetbv, xtest, xend)
> >> > don't seems at least suspicious. 
> >> 
> >> Thanks for the clearer problem statement. 
> >> 
> >> > Extensions originating from AMD
> >> > (rdtscp, clzero) can't be reasonably taken for reference.
> >> > 
> >> > Jan
> >> > 
> >> 
> >> I'll check
> >> 
> > At the bottom of the A-6 Table ("Opcode Extensions for One- and Two- byte
> > Opcodes by Group Number") there's a footnote that states
> >All blanks in all opcode maps are reserved and must not be used.
> >Do not depend on the operation of undefined or reserved locations
> > So, since the "pfx" value for Group 7 opcodes are "blank", none are allowed,
> > and an "#UD" is expected if a "pfx" is used.
> 
> This foot note can't possibly apply to the pfx column: Blank entries
> there mean at best "no prefix", but certainly not "reserved". Plus
> most opcodes allow namely the 66 prefix (as operand size override),
> and I'm also sure the F2 and F3 prefixes get ignored for many of
> the table entries.

Hi Jan:

My interpretation of the footnote comes from discussions with key people.
This is their understanding of the footnote.

> 
> > I also checked the narrative descriptions of vmfunc (and similar opcodes,
> > in particular the list in 25.1.3 "Instructions That Cause VM Exits
> > Conditionally").  None of the descriptions seem to state explicitly the
> > expected values of "pfx", nor the behavior of a "bad pfx".  That said, the
> > table and footnote seem to be the most explicit, cleanest way of 
> > communicating the information.
> 
> As mentioned elsewhere, the examples of other instructions (xsetbv,
> xgetbv, xend, xtest) were given because their instruction pages all
> mention 66, F2, and F3 as invalid, and they're all in the same group 7
> (and all in the same table column). enclu (documented in vol 3) btw
> also lists these prefixes as invalid.
> 
> Jan

Thanks for the reminder of xsetbv, xgetbv, xend, xtest.  I finally located their
opcode pages in Vol 2 5.2.  The descriptions of these opcodes disallows for
"pfx", which is consistent with the footnote.

Finally found the vmfunc opcode page in Vol 3 30.3, VMX Instruction Reference.
Agreed, there's no mention of prefixes, "pfx", on this page.  It appears
that the other VMX instructions in this section don't mention prefixes either.
Looking at Table A-6 "Opcode Extensions for One- and Two-Byte Opcodes":
vmcall, vmlaunch, vmresume, and vmxoff would need similar updating.

I can ask for updating of the VMX instuctions to include mention of prefixes.
Anything else as I gather requirements?

-Paul

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

Re: [Xen-devel] [PATCH] minios: make mini-os_app.o depend on included xen libraries

[Wei Liu]

On Tue, Sep 27, 2016 at 06:28:10PM +0200, Samuel Thibault wrote:
> Juergen Gross, on Tue 27 Sep 2016 14:06:24 +0200, wrote:
> > When building Mini-OS with an app which is using xen libraries like
> > libxenguest.a let mini-os_app.o depend on the library binaries as it
> > is statically linked with them.
> > 
> > While at it add "-T" before app.lds for linking mini-os_app.o to avoid
> > a linker warning.
> > 
> > Signed-off-by: Juergen Gross 
> 
> Acked-by: Samuel Thibault 
> 

Pushed. Thanks.

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

Re: [Xen-devel] [XTF PATCH] Makefile: introduce gtags target

[Andrew Cooper]

On 27/09/16 17:39, Wei Liu wrote:
> Signed-off-by: Wei Liu 
> ---
>  .gitignore |  3 +++
>  Makefile   | 10 +-
>  2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/.gitignore b/.gitignore
> index f69e7fc..28c7874 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -11,3 +11,6 @@
>  /selftests/test-*
>  /tests/*/test-*
>  /tests/*/info.json
> +/GPATH
> +/GRTAGS
> +/GTAGS
> diff --git a/Makefile b/Makefile
> index 17d784e..6767f72 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -50,11 +50,19 @@ install:
>   $(MAKE) -C $$D install; \
>   done
>  
> +define all_sources
> +( find include/ arch/ common/ tests/ -name "*.[hcsS]" )

Why the subshell?  It doesn't look necessary.

Otherwise, Reviewed-by: Andrew Cooper 

> +endef
> +
>  .PHONY: cscope
>  cscope:
> - find include/ arch/ common/ tests/ -name "*.[hcsS]" > cscope.files
> + $(all_sources) > cscope.files
>   cscope -b -q -k
>  
> +.PHONY: gtags
> +gtags:
> + $(all_sources) | gtags -f -
> +
>  .PHONY: clean
>  clean:
>   find . \( -name "*.o" -o -name "*.d" -o -name "*.lds" \) -delete


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

Re: [Xen-devel] [PATCH v5 05/16] livepatch: Initial ARM64 support.

[Julien Grall]

Hi Konrad,

On 23/09/2016 08:44, Konrad Rzeszutek Wilk wrote:

Here is the updated patch:
From deef8f6921c15a4d07209bfba1fc8697dbfeb605 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Mon, 19 Sep 2016 12:24:09 -0400
Subject: [PATCH v6] livepatch: Initial ARM64 support.

As compared to x86 the va of the hypervisor .text
is locked down - we cannot modify the running pagetables
to have the .ro flag unset. We borrow the same idea that
alternative patching has - which is to vmap the entire
.text region and use the alternative virtual address
for patching.

Since we are doing vmap we may fail, hence the
arch_livepatch_quiesce was changed (see "x86,arm:
Change arch_livepatch_quiesce() declaration") to return
an error value which will be bubbled in payload->rc and
provided to the user (along with messages in the ring buffer).

The livepatch virtual address space (where the new functions
are) needs to be close to the hypervisor virtual address
so that the trampoline can reach it. As such we re-use
the BOOT_RELOC_VIRT_START which is not used after bootup
(alternatively we can also use the space after the _end to
FIXMAP_ADDR(0), but that may be too small).

The ELF relocation engine at the start was coded from
the "ELF for the ARM 64-bit Architecture (AArch64)"
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf)
but after a while of trying to write the correct bit shifting
and masking from scratch I ended up borrowing from Linux, the
'reloc_insn_imm' (Linux v4.7 arch/arm64/kernel/module.c function.
See 257cb251925f854da435cbf79b140984413871ac "arm64: Loadable modules")

And while at it - we also utilize code from Linux to construct
the right branch instruction (see "arm64/insn: introduce
aarch64_insn_gen_{nop|branch_imm}() helper functions").

In the livepatch payload loading code we tweak the #ifdef to
only exclude ARM_32. The exceptions are not part of ARM 32/64 hence
they are still behind the #ifdef.

We also expand the MAINTAINERS file to include the arm64 and arm32
platform specific livepatch file.

Acked-by: Jan Beulich  [non-arm parts]
Signed-off-by: Konrad Rzeszutek Wilk 


You can add my acked-by on this version:

Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 14/16] livepatch: Initial ARM32 support.

[Julien Grall]

Hi Konrad,

On 21/09/2016 10:32, Konrad Rzeszutek Wilk wrote:

The patch piggybacks on: livepatch: Initial ARM64 support, which
brings up all of the necessary livepatch infrastructure pieces in.

This patch adds three major pieces:

 1) ELF relocations. ARM32 uses SHT_REL instead of SHT_RELA which
means the adddendum had to be extracted from within the
instruction. Which required parsing BL/BLX, B/BL,
MOVT, and MOVW instructions.

The code was written from scratch using the ARM ELF manual
(and the ARM Architecture Reference Manual)

 2) Inserting an trampoline. We use the B (branch to address)
which uses an offset that is based on the PC value: PC + imm32.
Because we insert the branch at the start of the old function
we have to account for the instruction already being fetched
and subtract -8 from the delta (new_addr - old_addr). See
ARM DDI 0406C.c, see A2.3 (pg 45) and A8.8.18 pg (pg 334,335)

 3) Allows the test-cases to be built under ARM 32.
The "livepatch: tests: Make them compile under ARM64"
put in the right infrastructure for it and we piggyback on it.

Acked-by: Julien Grall 
Acked-by: Jan Beulich  [for non-ARM parts]
Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 

v2: First submission.
v3: Use LIVEPATCH_ARCH_RANGE instead of NEGATIVE_32MB macro
   -Use PATCH_INSN_SIZE instead of the value 4.
   -Ditch the old_ptr local variable.
   -Use 8 for evaluating the branch instead of 4. Based on ARM docs.
   -NOP patch up to sizeof(opaque) % PATCH_INSN_SIZE (so 7 instructions).
   -Don't mask 0x00F_E_ after shifting, instead mask by 0x00F_F_.
The reason is that offset is constructed by shifting by two the insn
(except the first two bytes) by left which meant we would have cleared
offset[2]! - and jumped to a location that was -4 bytes off.
   -Update commit description to have -8 instead of -4 delta and also
include reference to spec.
v4: Added Jan's Ack.
   s/PATCH_INSN_SIZE/ARCH_PATCH_INSN_SIZE/
   s/arch_livepatch_insn_len/livepatch_insn_len/
   s/LIVEPATCH_ARCH_RANGE/ARCH_LIVEPATCH_RANGE/
v5: Added Julien's Ack.


IHMO my ack should not have been retained given that ...


   - Rebased on "livepatch: Drop _jmp from arch_livepatch_[apply,revert]_jmp"
   - Added explanation for the usage of data cache and why we need to sync it.


... you also replace the clean_and_invalidate to the old_ptr by 
clean_and_invalidate to the new_ptr.



diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
index 80f9646..3f47326 100644
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -3,28 +3,303 @@
  */

 #include 
+#include 
 #include 
 #include 
 #include 

+#include 
+#include 
+
 void arch_livepatch_apply(struct livepatch_func *func)
 {


[...]


+/*
+* When we upload the payload, it will go through the data cache
+* (the region is cacheable). Until the data cache is cleaned, the data
+* may not reach the memory. And in the case the data and instruction cache
+* are separated, we may read invalid instruction from the memory because
+* the data cache have not yet synced with the memory. Hence sync it.
+*/
+if ( func->new_addr )
+clean_and_invalidate_dcache_va_range(func->new_addr, func->new_size);


The clean_and_invalidate on the new_ptr needs to be add back here and ...


 }

 void arch_livepatch_revert(const struct livepatch_func *func)
 {
+uint32_t *new_ptr;
+unsigned int i, len;
+
+new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+len = livepatch_insn_len(func) / sizeof(uint32_t);
+for ( i = 0; i < len; i++ )
+{
+uint32_t insn;
+
+memcpy(, func->opaque + (i * sizeof(uint32_t)), 
ARCH_PATCH_INSN_SIZE);
+/* PATCH! */
+*(new_ptr + i) = insn;
+}


here. See the comments on the ARM64 part (i.e patch #5).


 }


Regards,

--
Julien Grall

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

[Xen-devel] [XTF PATCH] Makefile: introduce gtags target

[Wei Liu]

Signed-off-by: Wei Liu 
---
 .gitignore |  3 +++
 Makefile   | 10 +-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/.gitignore b/.gitignore
index f69e7fc..28c7874 100644
--- a/.gitignore
+++ b/.gitignore
@@ -11,3 +11,6 @@
 /selftests/test-*
 /tests/*/test-*
 /tests/*/info.json
+/GPATH
+/GRTAGS
+/GTAGS
diff --git a/Makefile b/Makefile
index 17d784e..6767f72 100644
--- a/Makefile
+++ b/Makefile
@@ -50,11 +50,19 @@ install:
$(MAKE) -C $$D install; \
done
 
+define all_sources
+( find include/ arch/ common/ tests/ -name "*.[hcsS]" )
+endef
+
 .PHONY: cscope
 cscope:
-   find include/ arch/ common/ tests/ -name "*.[hcsS]" > cscope.files
+   $(all_sources) > cscope.files
cscope -b -q -k
 
+.PHONY: gtags
+gtags:
+   $(all_sources) | gtags -f -
+
 .PHONY: clean
 clean:
find . \( -name "*.o" -o -name "*.d" -o -name "*.lds" \) -delete
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v6 16/16] libxl/arm: Add the size of ACPI tables to maxmem

[Wei Liu]

On Tue, Sep 27, 2016 at 09:01:00AM -0700, Shannon Zhao wrote:
> 
> 
> On 2016/9/27 2:41, Wei Liu wrote:
> >On Mon, Sep 26, 2016 at 02:54:55PM -0700, Shannon Zhao wrote:
> >>
> >>
> >>On 2016/9/22 7:10, Wei Liu wrote:
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> >index 2924629..118beab 100644
> >--- a/tools/libxl/libxl_dom.c
> >+++ b/tools/libxl/libxl_dom.c
> >@@ -408,8 +408,15 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> > }
> > }
> >
> >+
> >+rc = libxl__arch_memory_constant(gc, info, state);
> >+if (rc < 0) {
> >+LOGE(ERROR, "Couldn't get arch constant memory size");
> >+return ERROR_FAIL;
> >+}
> >+
> > if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> >-LIBXL_MAXMEM_CONSTANT) < 0) {
> >+LIBXL_MAXMEM_CONSTANT + rc) < 0) {
> >>>I think this LIBXL_MAXMEM_CONSTANT should be pushed to your helper
> >>>function, too.
> >>>
> >>>So that, we can have all LIBXL_MAXMEM_CONSTANT removed in libxl
> >>>functions (see libxl.c and libxl_dom.c)
> >>>
> >>If we push LIBXL_MAXMEM_CONSTANT to the libxl_arch_memory_constant and
> >>remove it from libxl.c, do we need to call libxl_arch_memory_constant there
> >>in libxl_set_memory_target()?
> >>
> >
> >Yes, we need to call that function everywhere to get consistent results.
> >That's the reason I asked you to consolidate it to a function.
> >
> Well it's a little awkward I think, since in libxl_domain_setmaxmem() and
> libxl_set_memory_target() it seems it can't get the parameters info and
> state for libxl__arch_memory_constant().
> I'm not sure how to solve it. Wei, any suggestion?
> 

Hmm...

The first question is can state be derived from build_info ? From my
quick skim of the code the answer is likely yes.

Then, you can call libxl_retrieve_domain_configuration to get
domain_config, then domain_config->build_info, so that you can derive
state from it.

Feel free to ask more questions.

Without such arrangement, ballooning is going to be broken for ARM
guests.


Wei.

> Thanks,
> -- 
> Shannon

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

Re: [Xen-devel] [PATCH] minios: make mini-os_app.o depend on included xen libraries

[Samuel Thibault]

Juergen Gross, on Tue 27 Sep 2016 14:06:24 +0200, wrote:
> When building Mini-OS with an app which is using xen libraries like
> libxenguest.a let mini-os_app.o depend on the library binaries as it
> is statically linked with them.
> 
> While at it add "-T" before app.lds for linking mini-os_app.o to avoid
> a linker warning.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Samuel Thibault 

> ---
>  Makefile | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 81b936f..1d2324c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -125,11 +125,18 @@ OBJS := $(filter-out $(OBJ_DIR)/lwip%.o $(LWO), $(OBJS))
>  ifeq ($(libc),y)
>  ifeq ($(CONFIG_XC),y)
>  APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/toollog 
> -whole-archive -lxentoollog -no-whole-archive
> +LIBS += 
> $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/toollog/libxentoollog.a
>  APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/evtchn 
> -whole-archive -lxenevtchn -no-whole-archive
> +LIBS += $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/evtchn/libxenevtchn.a
>  APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/gnttab 
> -whole-archive -lxengnttab -no-whole-archive
> +LIBS += $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/gnttab/libxengnttab.a
>  APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/call 
> -whole-archive -lxencall -no-whole-archive
> +LIBS += $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/call/libxencall.a
>  APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/foreignmemory 
> -whole-archive -lxenforeignmemory -no-whole-archive
> +LIBS += 
> $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/foreignmemory/libxenforeignmemory.a
>  APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH) 
> -whole-archive -lxenguest -lxenctrl -no-whole-archive
> +LIBS += $(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH)/libxenctrl.a
> +LIBS += $(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH)/libxenguest.a
>  endif
>  APP_LDLIBS += -lpci
>  APP_LDLIBS += -lz
> @@ -141,8 +148,8 @@ ifneq ($(APP_OBJS)-$(lwip),-y)
>  OBJS := $(filter-out $(OBJ_DIR)/daytime.o, $(OBJS))
>  endif
>  
> -$(OBJ_DIR)/$(TARGET)_app.o: $(APP_OBJS) app.lds
> - $(LD) -r -d $(LDFLAGS) -\( $^ -\) $(APP_LDLIBS) --undefined main -o $@
> +$(OBJ_DIR)/$(TARGET)_app.o: $(APP_OBJS) app.lds $(LIBS)
> + $(LD) -r -d $(LDFLAGS) -\( $(APP_OBJS) -T app.lds -\) $(APP_LDLIBS) 
> --undefined main -o $@
>  
>  ifneq ($(APP_OBJS),)
>  APP_O=$(OBJ_DIR)/$(TARGET)_app.o 
> -- 
> 2.6.6
> 

-- 
Samuel
#ifndef I_WISH_WORLD_WERE_PERFECT
/* It is not :-( All the routers (except for Linux) return only
...
 -+- linux/net/ipv4/ipip.c -+-

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

Re: [Xen-devel] [PATCH] minios: make mini-os_app.o depend on included xen libraries

[Wei Liu]

On Tue, Sep 27, 2016 at 06:03:28PM +0200, Juergen Gross wrote:
> On 27/09/16 17:56, Wei Liu wrote:
> > On Tue, Sep 27, 2016 at 02:06:24PM +0200, Juergen Gross wrote:
> >> When building Mini-OS with an app which is using xen libraries like
> >> libxenguest.a let mini-os_app.o depend on the library binaries as it
> >> is statically linked with them.
> >>
> >> While at it add "-T" before app.lds for linking mini-os_app.o to avoid
> >> a linker warning.
> >>
> >> Signed-off-by: Juergen Gross 
> >> ---
> >>  Makefile | 11 +--
> >>  1 file changed, 9 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/Makefile b/Makefile
> >> index 81b936f..1d2324c 100644
> >> --- a/Makefile
> >> +++ b/Makefile
> >> @@ -125,11 +125,18 @@ OBJS := $(filter-out $(OBJ_DIR)/lwip%.o $(LWO), 
> >> $(OBJS))
> >>  ifeq ($(libc),y)
> >>  ifeq ($(CONFIG_XC),y)
> >>  APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/toollog 
> >> -whole-archive -lxentoollog -no-whole-archive
> >> +LIBS += 
> >> $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/toollog/libxentoollog.a
> > 
> > I don't follow. Why is the original APP_LDLIBS not enough?
> 
> This just adds the parameters for ld to use the libs.
> 
> > The new dependency doesn't seem to generate any new rules. What do I
> > miss?
> 
> You snipped:
> 
> +$(OBJ_DIR)/$(TARGET)_app.o: $(APP_OBJS) app.lds $(LIBS)
> 
> which adds a dependency on the libs. Now mini-os_app.o will be relinked
> if any of the libs changed. That was not the case before. I realized
> that a modification of libxc wouldn't make it into pvgrub if I didn't
> do a "make clean" and pvgrub was built before.
> 

I see

Reviewed-by: Wei Liu 

> 
> Juergen

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

Re: [Xen-devel] [PATCH] xen/arm: Bring (c) headers in line with COPYING file

[Lars Kurth]

On 27/09/2016 16:35, "Konrad Rzeszutek Wilk" 
wrote:

>On Tue, Sep 27, 2016 at 03:16:50PM +0100, Lars Kurth wrote:
>> The COPYING file in the main xen.git tree applies to most files in the
>> xen tree, including the ones in this patch. It states:
>> 
>> [1]
>>  * Note that the only valid version of the GPL as far as the files in
>>  * this repository are concerned is _this_ particular version of the
>>  * license (i.e., *only* v2, not v2.2 or v3.x or whatever), unless
>>  * explicitly otherwise stated.
>> 
>> We do not have any GPLv3+ files in the Xen source, with the exception of
>> Bison generated files, which have a Bison exception and are thus safe.
>> 
>> However, there are a minority of files that are specifically GPL-2.0+,
>> stating
>> 
>> [2]
>>  * This program is free software; you can redistribute it and/or modify
>>  * it under the terms of the GNU General Public License as published by
>>  * the Free Software Foundation; either version 2 of the License, or
>>  * (at your option) any later version.
>> 
>> I could not find a single instance in our code base, which states
>> 
>> [3]
>>  * This program is free software; you can redistribute it and/or modify
>>  * it under the terms of the GNU General Public License as published by
>>  * the Free Software Foundation; either version 2 of the License, or
>>  * any later version.
>> 
>> It is impossible to know, what the intention of the contributor was
>> when a (c) header of form [2] was used. There are two possibilities
>> a) The contributor chose [2] intentionally
>> b) The contributor copied a header file from elsewhere (e.g. the FSF)
>>without understanding all the implications
>> The latter is more likely, which is also why we recently introduced
>> the CONTRIBUTING file with correct (c) headers
>> 
>> In all cases in our code base, code with a (c) header of form [2] is
>> linked against pure GPLv2 files, which in practice means that the
>> resulting binaries are always GPLv2. In addition, [1] clarifies this.
>> 
>> [2] allows the Xen Project to specifically choose GPLv2 and to modify
>> the (c) headers to that effect without express permission of the (c)
>> holders. This proposed patch makes use of this property. It also gives
>
>This patch hinges on the 'allow' part. That is that the Xen Project
>community
>can choose to modify its headers without express permission of the holders
>on removing the '(at your option)' statement from the license headers.
>Now it is not a relicense, nor changing the license but clarifying the
>semantics
>of how the code can be used in future.

That is correct. 

>Later in the description (see 'annotated' tags) are saying the same
>thing - that the community can decide this based on 'common practices'.
>
>Could you please point me to the 'common practices' and the 'allow'
>property?
>I would naively assume that this had happend in the past with other
>projects?
>Or perhaps the GPL had helpfully put a statement on their website giving
>clarification on this?

Unfortunately, the FSF FAQ does not cover this explicitly.

However, https://copyleft.org/guide/comprehensive-gpl-guidech3.html
Section 2.6, bullet point 3 does.


2.6 The Innovation of Optional “Or Any Later” Version

An interesting fact of all GPL licenses is that there are ultimately
multiple choices for use of the license. The FSF is the primary steward
of GPL (as discussed later in § 8.1 and § 9.17). However, those who wish
to license works under GPL are not required to automatically accept
changes made by the FSF for their own copyrighted works. Each licensor may
chose three different methods of licensing, as follows:

* explicitly name a single version of GPL for their work (usually
  indicated in shorthand by saying the license is “GPLvX-only”), or
* name no version of the GPL, thus they allow their downstream recipients
  to select any version of the GPL they choose (usually indicated in
  shorthand by saying the license is simply “GPL”), or
* name a specific version of GPL and give downstream recipients the
  option to choose that version “or any later version as published
  by the FSF” (usually indicated by saying the license is
  “GPLvX-or-later”)




As for the process, I don't know of a precedent. Maybe someone on the
list does have an example though.

Our community consists of both downstream recipients and (c) holders
and we don't know how downstream recipients use the code. If for example
a downstream recipient makes use of the GPLv2+ property, by copying
some files into a GPLv3 codebase, then we would restrict their freedom
and force them to fork the code. Older versions of those files in git
would still have that GPLv2+ property, but once we change the (c)
headers, inbound changes to those files would be made under the GPLv2
only from that point onwards.


My understanding was that legally, we don't need to follow this process,
but we don't want to unintentionally hurt any user making use of this
property. And 

[Xen-devel] [PATCH v2 04/30] xen/x86: allow calling {sh/hap}_set_allocation with the idle domain

[Roger Pau Monne]

... and using the "preempted" parameter. The solution relies on just calling
softirq_pending if the current domain is the idle domain.

Signed-off-by: Roger Pau Monné 
---
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/mm/hap/hap.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index b6d2c61..2dc82f5 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -379,7 +379,9 @@ hap_set_allocation(struct domain *d, unsigned long pages, 
int *preempted)
 break;
 
 /* Check to see if we need to yield and try again */
-if ( preempted && hypercall_preempt_check() )
+if ( preempted &&
+ (is_idle_vcpu(current) ? softirq_pending(smp_processor_id()) :
+  hypercall_preempt_check()) )
 {
 *preempted = 1;
 return 0;
-- 
2.7.4 (Apple Git-66)


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

Re: [Xen-devel] [PATCH] minios: make mini-os_app.o depend on included xen libraries

[Juergen Gross]

On 27/09/16 17:56, Wei Liu wrote:
> On Tue, Sep 27, 2016 at 02:06:24PM +0200, Juergen Gross wrote:
>> When building Mini-OS with an app which is using xen libraries like
>> libxenguest.a let mini-os_app.o depend on the library binaries as it
>> is statically linked with them.
>>
>> While at it add "-T" before app.lds for linking mini-os_app.o to avoid
>> a linker warning.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  Makefile | 11 +--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/Makefile b/Makefile
>> index 81b936f..1d2324c 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -125,11 +125,18 @@ OBJS := $(filter-out $(OBJ_DIR)/lwip%.o $(LWO), 
>> $(OBJS))
>>  ifeq ($(libc),y)
>>  ifeq ($(CONFIG_XC),y)
>>  APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/toollog 
>> -whole-archive -lxentoollog -no-whole-archive
>> +LIBS += 
>> $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/toollog/libxentoollog.a
> 
> I don't follow. Why is the original APP_LDLIBS not enough?

This just adds the parameters for ld to use the libs.

> The new dependency doesn't seem to generate any new rules. What do I
> miss?

You snipped:

+$(OBJ_DIR)/$(TARGET)_app.o: $(APP_OBJS) app.lds $(LIBS)

which adds a dependency on the libs. Now mini-os_app.o will be relinked
if any of the libs changed. That was not the case before. I realized
that a modification of libxc wouldn't make it into pvgrub if I didn't
do a "make clean" and pvgrub was built before.


Juergen

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

Re: [Xen-devel] [PATCH v6 16/16] libxl/arm: Add the size of ACPI tables to maxmem

[Shannon Zhao]

On 2016/9/27 2:41, Wei Liu wrote:

On Mon, Sep 26, 2016 at 02:54:55PM -0700, Shannon Zhao wrote:



On 2016/9/22 7:10, Wei Liu wrote:

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c

index 2924629..118beab 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -408,8 +408,15 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 }
 }

+
+rc = libxl__arch_memory_constant(gc, info, state);
+if (rc < 0) {
+LOGE(ERROR, "Couldn't get arch constant memory size");
+return ERROR_FAIL;
+}
+
 if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
-LIBXL_MAXMEM_CONSTANT) < 0) {
+LIBXL_MAXMEM_CONSTANT + rc) < 0) {

I think this LIBXL_MAXMEM_CONSTANT should be pushed to your helper
function, too.

So that, we can have all LIBXL_MAXMEM_CONSTANT removed in libxl
functions (see libxl.c and libxl_dom.c)


If we push LIBXL_MAXMEM_CONSTANT to the libxl_arch_memory_constant and
remove it from libxl.c, do we need to call libxl_arch_memory_constant there
in libxl_set_memory_target()?



Yes, we need to call that function everywhere to get consistent results.
That's the reason I asked you to consolidate it to a function.

Well it's a little awkward I think, since in libxl_domain_setmaxmem() 
and libxl_set_memory_target() it seems it can't get the parameters info 
and state for libxl__arch_memory_constant().

I'm not sure how to solve it. Wei, any suggestion?

Thanks,
--
Shannon

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

[Xen-devel] [PATCH v2 12/30] xen/x86: make print_e820_memory_map global

[Roger Pau Monne]

So that it can be called from the Dom0 builder.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/e820.c| 2 +-
 xen/include/asm-x86/e820.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
index ef077a5..48e35f9 100644
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -87,7 +87,7 @@ static void __init add_memory_region(unsigned long long start,
 e820.nr_map++;
 }
 
-static void __init print_e820_memory_map(struct e820entry *map, unsigned int 
entries)
+void __init print_e820_memory_map(struct e820entry *map, unsigned int entries)
 {
 unsigned int i;
 
diff --git a/xen/include/asm-x86/e820.h b/xen/include/asm-x86/e820.h
index d9ff4eb..9dad76a 100644
--- a/xen/include/asm-x86/e820.h
+++ b/xen/include/asm-x86/e820.h
@@ -31,6 +31,7 @@ extern int e820_change_range_type(
 extern int e820_add_range(
 struct e820map *, uint64_t s, uint64_t e, uint32_t type);
 extern unsigned long init_e820(const char *, struct e820entry *, unsigned int 
*);
+extern void print_e820_memory_map(struct e820entry *map, unsigned int entries);
 extern struct e820map e820;
 
 /* These symbols live in the boot trampoline. */
-- 
2.7.4 (Apple Git-66)


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

[Xen-devel] [PATCH v2 26/30] xen/x86: add PCIe emulation

[Roger Pau Monne]

Add a new MMIO handler that traps accesses to PCIe regions, as discovered by
Xen from the MCFG ACPI table. The handler used is the same as the one used
for accesses to the IO PCI configuration space.

Signed-off-by: Roger Pau Monné 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/io.c | 177 --
 1 file changed, 171 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index 779babb..088e3ec 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -46,6 +46,8 @@
 #include 
 #include 
 
+#include "../x86_64/mmconfig.h"
+
 /* Set permissive mode for HVM Dom0 PCI pass-through by default */
 static bool_t opt_dom0permissive = 1;
 boolean_param("dom0permissive", opt_dom0permissive);
@@ -363,7 +365,7 @@ static int hvm_pt_pci_config_access_check(struct 
hvm_pt_device *d,
 }
 
 static int hvm_pt_pci_read_config(struct hvm_pt_device *d, uint32_t addr,
-  uint32_t *data, int len)
+  uint32_t *data, int len, bool pcie)
 {
 uint32_t val = 0;
 struct hvm_pt_reg_group *reg_grp_entry = NULL;
@@ -377,7 +379,7 @@ static int hvm_pt_pci_read_config(struct hvm_pt_device *d, 
uint32_t addr,
 unsigned int func = PCI_FUNC(d->pdev->devfn);
 
 /* Sanity checks. */
-if ( hvm_pt_pci_config_access_check(d, addr, len) )
+if ( !pcie && hvm_pt_pci_config_access_check(d, addr, len) )
 return X86EMUL_UNHANDLEABLE;
 
 /* Find register group entry. */
@@ -468,7 +470,7 @@ static int hvm_pt_pci_read_config(struct hvm_pt_device *d, 
uint32_t addr,
 }
 
 static int hvm_pt_pci_write_config(struct hvm_pt_device *d, uint32_t addr,
-uint32_t val, int len)
+uint32_t val, int len, bool pcie)
 {
 int index = 0;
 struct hvm_pt_reg_group *reg_grp_entry = NULL;
@@ -485,7 +487,7 @@ static int hvm_pt_pci_write_config(struct hvm_pt_device *d, 
uint32_t addr,
 unsigned int func = PCI_FUNC(d->pdev->devfn);
 
 /* Sanity checks. */
-if ( hvm_pt_pci_config_access_check(d, addr, len) )
+if ( !pcie && hvm_pt_pci_config_access_check(d, addr, len) )
 return X86EMUL_UNHANDLEABLE;
 
 /* Find register group entry. */
@@ -677,7 +679,7 @@ static int hw_dpci_portio_read(const struct hvm_io_handler 
*handler,
 if ( dev != NULL )
 {
 reg = (currd->arch.pci_cf8 & 0xfc) | (addr & 0x3);
-rc = hvm_pt_pci_read_config(dev, reg, , size);
+rc = hvm_pt_pci_read_config(dev, reg, , size, false);
 if ( rc == X86EMUL_OKAY )
 {
 read_unlock(>arch.hvm_domain.pt_lock);
@@ -722,7 +724,7 @@ static int hw_dpci_portio_write(const struct hvm_io_handler 
*handler,
 if ( dev != NULL )
 {
 reg = (currd->arch.pci_cf8 & 0xfc) | (addr & 0x3);
-rc = hvm_pt_pci_write_config(dev, reg, data32, size);
+rc = hvm_pt_pci_write_config(dev, reg, data32, size, false);
 if ( rc == X86EMUL_OKAY )
 {
 read_unlock(>arch.hvm_domain.pt_lock);
@@ -1002,6 +1004,166 @@ static const struct hvm_io_ops hw_dpci_portio_ops = {
 .write = hw_dpci_portio_write
 };
 
+static struct acpi_mcfg_allocation *pcie_find_mmcfg(unsigned long addr)
+{
+int i;
+
+for ( i = 0; i < pci_mmcfg_config_num; i++ )
+{
+unsigned long start, end;
+
+start = pci_mmcfg_config[i].address;
+end = pci_mmcfg_config[i].address +
+  ((pci_mmcfg_config[i].end_bus_number + 1) << 20);
+if ( addr >= start && addr < end )
+return _mmcfg_config[i];
+}
+
+return NULL;
+}
+
+static struct hvm_pt_device *hw_pcie_get_device(unsigned int seg,
+unsigned int bus,
+unsigned int slot,
+unsigned int func)
+{
+struct hvm_pt_device *dev;
+struct domain *d = current->domain;
+
+list_for_each_entry( dev, >arch.hvm_domain.pt_devices, entries )
+{
+if ( dev->pdev->seg != seg || dev->pdev->bus != bus ||
+ dev->pdev->devfn != PCI_DEVFN(slot, func) )
+continue;
+
+return dev;
+}
+
+return NULL;
+}
+
+static void pcie_decode_addr(unsigned long addr, unsigned int *bus,
+ unsigned int *slot, unsigned int *func,
+ unsigned int *reg)
+{
+
+*bus = (addr >> 20) & 0xff;
+*slot = (addr >> 15) & 0x1f;
+*func = (addr >> 12) & 0x7;
+*reg = addr & 0xfff;
+}
+
+static int pcie_range(struct vcpu *v, unsigned long addr)
+{
+
+return pcie_find_mmcfg(addr) != NULL ? 1 : 0;
+}
+
+static int pcie_read(struct vcpu *v, unsigned long addr,
+ unsigned int len, unsigned long *pval)
+{
+

[Xen-devel] [PATCH v2 27/30] x86/msixtbl: disable MSI-X intercepts for domains without an ioreq server

[Roger Pau Monne]

The current msixtbl intercepts only partially trap MSI-X accesses, but are
not complete, there's missing logic in order to setup PIRQs and bind them to
domains. Disable them for domains without at least an ioreq server (PVH).

Signed-off-by: Roger Pau Monné 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
NB: this is a preparatory patch for introducing a complete MSI-X emulation
layer into Xen. Long term the current msixtbl code should be replaced with
the complete MSI-X emulation introduced in later patches.
---
 xen/arch/x86/hvm/ioreq.c| 11 +++
 xen/drivers/passthrough/io.c|  4 +++-
 xen/include/asm-x86/hvm/ioreq.h |  1 +
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index d2245e2..b09fa96 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -772,6 +772,17 @@ int hvm_destroy_ioreq_server(struct domain *d, ioservid_t 
id)
 return rc;
 }
 
+int hvm_has_ioreq_server(struct domain *d)
+{
+int empty;
+
+spin_lock_recursive(>arch.hvm_domain.ioreq_server.lock);
+empty = list_empty(>arch.hvm_domain.ioreq_server.list);
+spin_unlock_recursive(>arch.hvm_domain.ioreq_server.lock);
+
+return !empty;
+}
+
 int hvm_get_ioreq_server_info(struct domain *d, ioservid_t id,
   unsigned long *ioreq_pfn,
   unsigned long *bufioreq_pfn,
diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index edd8dbd..1e5e365 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static DEFINE_PER_CPU(struct list_head, dpci_list);
@@ -384,7 +385,8 @@ int pt_irq_create_bind(
 pirq_dpci->dom = d;
 /* bind after hvm_irq_dpci is setup to avoid race with irq 
handler*/
 rc = pirq_guest_bind(d->vcpu[0], info, 0);
-if ( rc == 0 && pt_irq_bind->u.msi.gtable )
+if ( rc == 0 && pt_irq_bind->u.msi.gtable &&
+ hvm_has_ioreq_server(d) )
 {
 rc = msixtbl_pt_register(d, info, pt_irq_bind->u.msi.gtable);
 if ( unlikely(rc) )
diff --git a/xen/include/asm-x86/hvm/ioreq.h b/xen/include/asm-x86/hvm/ioreq.h
index fbf2c74..6456cd2 100644
--- a/xen/include/asm-x86/hvm/ioreq.h
+++ b/xen/include/asm-x86/hvm/ioreq.h
@@ -31,6 +31,7 @@ int hvm_get_ioreq_server_info(struct domain *d, ioservid_t id,
   unsigned long *ioreq_pfn,
   unsigned long *bufioreq_pfn,
   evtchn_port_t *bufioreq_port);
+int hvm_has_ioreq_server(struct domain *d);
 int hvm_map_io_range_to_ioreq_server(struct domain *d, ioservid_t id,
  uint32_t type, uint64_t start,
  uint64_t end);
-- 
2.7.4 (Apple Git-66)


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

[Xen-devel] [PATCH v2 11/30] xen/x86: split Dom0 build into PV and PVHv2

[Roger Pau Monne]

Split the Dom0 builder into two different functions, one for PV (and classic
PVH), and another one for PVHv2. Introduce a new command line parameter,
dom0hvm in order to request the creation of a PVHv2 Dom0.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since RFC:
 - Add documentation for the new command line option.
 - Simplify the logic in construct_dom0.
---
 docs/misc/xen-command-line.markdown |  7 +++
 xen/arch/x86/domain_build.c | 24 +++-
 xen/arch/x86/setup.c|  9 +
 3 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 8ff57fa..59d7210 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -663,6 +663,13 @@ Pin dom0 vcpus to their respective pcpus
 
 Flag that makes a 64bit dom0 boot in PVH mode. No 32bit support at present.
 
+### dom0hvm
+> `= `
+
+> Default: `false`
+
+Flag that makes a dom0 boot in PVHv2 mode.
+
 ### dtuart (ARM)
 > `= path [:options]`
 
diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index ffd0521..78980ae 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -952,7 +952,7 @@ static int __init setup_permissions(struct domain *d)
 return rc;
 }
 
-int __init construct_dom0(
+static int __init construct_dom0_pv(
 struct domain *d,
 const module_t *image, unsigned long image_headroom,
 module_t *initrd,
@@ -1657,6 +1657,28 @@ out:
 return rc;
 }
 
+static int __init construct_dom0_hvm(struct domain *d, const module_t *image,
+ unsigned long image_headroom,
+ module_t *initrd,
+ void *(*bootstrap_map)(const module_t *),
+ char *cmdline)
+{
+
+printk("** Building a PVH Dom0 **\n");
+
+return 0;
+}
+
+int __init construct_dom0(struct domain *d, const module_t *image,
+  unsigned long image_headroom, module_t *initrd,
+  void *(*bootstrap_map)(const module_t *),
+  char *cmdline)
+{
+
+return (is_hvm_domain(d) ? construct_dom0_hvm : construct_dom0_pv)
+   (d, image, image_headroom, initrd,bootstrap_map, cmdline);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 1d27a6f..9272318 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -75,6 +75,10 @@ unsigned long __read_mostly cr4_pv32_mask;
 static bool_t __initdata opt_dom0pvh;
 boolean_param("dom0pvh", opt_dom0pvh);
 
+/* Boot dom0 in HVM mode */
+static bool_t __initdata opt_dom0hvm;
+boolean_param("dom0hvm", opt_dom0hvm);
+
 /*  Linux config option: propagated to domain0. */
 /* "acpi=off":Sisables both ACPI table parsing and interpreter. */
 /* "acpi=force":  Override the disable blacklist.   */
@@ -1495,6 +1499,11 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 if ( opt_dom0pvh )
 domcr_flags |= DOMCRF_pvh | DOMCRF_hap;
 
+if ( opt_dom0hvm ) {
+domcr_flags |= DOMCRF_hvm | (hvm_funcs.hap_supported ? DOMCRF_hap : 0);
+config.emulation_flags = XEN_X86_EMU_LAPIC|XEN_X86_EMU_IOAPIC;
+}
+
 /*
  * Create initial domain 0.
  * x86 doesn't support arch-configuration. So it's fine to pass
-- 
2.7.4 (Apple Git-66)


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

[Xen-devel] [PATCH v2 09/30] x86/vtd: fix and simplify mapping RMRR regions

[Roger Pau Monne]

The current code used by Intel VTd will only map RMRR regions for the
hardware domain, but will fail to map RMRR regions for unprivileged domains
unless the page tables are shared between EPT and IOMMU. Fix this and
simplify the code, removing the {set/clear}_identity_p2m_entry helpers and
just using the normal MMIO mapping functions. Introduce a new MMIO
mapping/unmapping helper, that takes care of checking for pending IRQs if
the mapped region is big enough that it cannot be done in one shot.

Signed-off-by: Roger Pau Monné 
---
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Kevin Tian 
Cc: Feng Wu 
---
 xen/arch/x86/mm/p2m.c   | 86 -
 xen/drivers/passthrough/vtd/iommu.c | 21 +
 xen/include/asm-x86/p2m.h   |  5 ---
 xen/include/xen/p2m-common.h| 30 +
 4 files changed, 42 insertions(+), 100 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 9526fff..44492ae 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1029,56 +1029,6 @@ int set_mmio_p2m_entry(struct domain *d, unsigned long 
gfn, mfn_t mfn,
 return set_typed_p2m_entry(d, gfn, mfn, order, p2m_mmio_direct, access);
 }
 
-int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
-   p2m_access_t p2ma, unsigned int flag)
-{
-p2m_type_t p2mt;
-p2m_access_t a;
-mfn_t mfn;
-struct p2m_domain *p2m = p2m_get_hostp2m(d);
-int ret;
-
-if ( !paging_mode_translate(p2m->domain) )
-{
-if ( !need_iommu(d) )
-return 0;
-return iommu_map_page(d, gfn, gfn, IOMMUF_readable|IOMMUF_writable);
-}
-
-gfn_lock(p2m, gfn, 0);
-
-mfn = p2m->get_entry(p2m, gfn, , , 0, NULL, NULL);
-
-if ( p2mt == p2m_invalid || p2mt == p2m_mmio_dm )
-ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
-p2m_mmio_direct, p2ma);
-else if ( mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct && a == p2ma )
-{
-ret = 0;
-/*
- * PVH fixme: during Dom0 PVH construction, p2m entries are being set
- * but iomem regions are not mapped with IOMMU. This makes sure that
- * RMRRs are correctly mapped with IOMMU.
- */
-if ( is_hardware_domain(d) && !iommu_use_hap_pt(d) )
-ret = iommu_map_page(d, gfn, gfn, IOMMUF_readable|IOMMUF_writable);
-}
-else
-{
-if ( flag & XEN_DOMCTL_DEV_RDM_RELAXED )
-ret = 0;
-else
-ret = -EBUSY;
-printk(XENLOG_G_WARNING
-   "Cannot setup identity map d%d:%lx,"
-   " gfn already mapped to %lx.\n",
-   d->domain_id, gfn, mfn_x(mfn));
-}
-
-gfn_unlock(p2m, gfn, 0);
-return ret;
-}
-
 /*
  * Returns:
  *0for success
@@ -1127,42 +1077,6 @@ int clear_mmio_p2m_entry(struct domain *d, unsigned long 
gfn, mfn_t mfn,
 return rc;
 }
 
-int clear_identity_p2m_entry(struct domain *d, unsigned long gfn)
-{
-p2m_type_t p2mt;
-p2m_access_t a;
-mfn_t mfn;
-struct p2m_domain *p2m = p2m_get_hostp2m(d);
-int ret;
-
-if ( !paging_mode_translate(d) )
-{
-if ( !need_iommu(d) )
-return 0;
-return iommu_unmap_page(d, gfn);
-}
-
-gfn_lock(p2m, gfn, 0);
-
-mfn = p2m->get_entry(p2m, gfn, , , 0, NULL, NULL);
-if ( p2mt == p2m_mmio_direct && mfn_x(mfn) == gfn )
-{
-ret = p2m_set_entry(p2m, gfn, INVALID_MFN, PAGE_ORDER_4K,
-p2m_invalid, p2m->default_access);
-gfn_unlock(p2m, gfn, 0);
-}
-else
-{
-gfn_unlock(p2m, gfn, 0);
-printk(XENLOG_G_WARNING
-   "non-identity map d%d:%lx not cleared (mapped to %lx)\n",
-   d->domain_id, gfn, mfn_x(mfn));
-ret = 0;
-}
-
-return ret;
-}
-
 /* Returns: 0 for success, -errno for failure */
 int set_shared_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)
 {
diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 919993e..714a19e 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1896,6 +1896,7 @@ static int rmrr_identity_mapping(struct domain *d, bool_t 
map,
 unsigned long end_pfn = PAGE_ALIGN_4K(rmrr->end_address) >> PAGE_SHIFT_4K;
 struct mapped_rmrr *mrmrr;
 struct domain_iommu *hd = dom_iommu(d);
+int ret = 0;
 
 ASSERT(pcidevs_locked());
 ASSERT(rmrr->base_address < rmrr->end_address);
@@ -1909,8 +1910,6 @@ static int rmrr_identity_mapping(struct domain *d, bool_t 
map,
 if ( mrmrr->base == rmrr->base_address &&
  mrmrr->end == rmrr->end_address )
 {
-int ret = 0;
-
 if ( map )
 {
 

[Xen-devel] [PATCH v2 28/30] xen/x86: add MSI-X emulation to PVHv2 Dom0

[Roger Pau Monne]

This requires adding handlers to the PCI configuration space, plus a MMIO
handler for the MSI-X table, the PBA is left mapped directly into the guest.
The implementation is based on the one already found in the passthrough
code from QEMU.

Signed-off-by: Roger Pau Monné 
---
Paul Durrant 
Jan Beulich 
Andrew Cooper 
---
 xen/arch/x86/hvm/io.c |   2 +
 xen/arch/x86/hvm/vmsi.c   | 498 ++
 xen/drivers/passthrough/pci.c |   6 +-
 xen/include/asm-x86/hvm/io.h  |  26 +++
 xen/include/asm-x86/msi.h |   4 +-
 5 files changed, 534 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index 088e3ec..11b7313 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -867,6 +867,7 @@ static struct hvm_pt_handler_init *hwdom_pt_handlers[] = {
 _pt_bar_init,
 _pt_vf_bar_init,
 _pt_msi_init,
+_pt_msix_init,
 };
 
 int hwdom_add_device(struct pci_dev *pdev)
@@ -1176,6 +1177,7 @@ void register_dpci_portio_handler(struct domain *d)
 {
 handler->ops = _dpci_portio_ops;
 register_mmio_handler(d, _mmio_ops);
+register_mmio_handler(d, _mmio_ops);
 }
 else
 handler->ops = _portio_ops;
diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index 75ba429..92c3b50 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static void vmsi_inj_irq(
 struct vlapic *target,
@@ -1162,3 +1163,500 @@ struct hvm_pt_handler_init hvm_pt_msi_init = {
 .handlers = vmsi_handler,
 .init = vmsi_group_init,
 };
+
+/* MSI-X */
+#define latch(fld) latch[PCI_MSIX_ENTRY_##fld / sizeof(uint32_t)]
+
+static int vmsix_update_one(struct hvm_pt_device *s, int entry_nr,
+uint32_t vec_ctrl)
+{
+struct hvm_pt_msix_entry *entry = NULL;
+xen_domctl_bind_pt_irq_t bind;
+bool bound = true;
+struct irq_desc *desc;
+unsigned long flags;
+int irq;
+int pirq;
+int rc;
+
+if ( entry_nr < 0 || entry_nr >= s->msix->total_entries )
+return -EINVAL;
+
+entry = >msix->msix_entry[entry_nr];
+
+if ( !entry->updated )
+goto mask;
+
+pirq = entry->pirq;
+
+/*
+ * Update the entry addr and data to the latest values only when the
+ * entry is masked or they are all masked, as required by the spec.
+ * Addr and data changes while the MSI-X entry is unmasked get deferred
+ * until the next masked -> unmasked transition.
+ */
+if ( s->msix->maskall ||
+ (entry->latch(VECTOR_CTRL_OFFSET) & PCI_MSIX_VECTOR_BITMASK) )
+{
+entry->addr = entry->latch(LOWER_ADDR_OFFSET) |
+  ((uint64_t)entry->latch(UPPER_ADDR_OFFSET) << 32);
+entry->data = entry->latch(DATA_OFFSET);
+}
+
+if ( pirq == -1 )
+{
+struct msi_info msi_info;
+//struct irq_desc *desc;
+int index = -1;
+
+/* Init physical one */
+printk_pdev(s->pdev, XENLOG_DEBUG, "setup MSI-X (entry: %d).\n",
+entry_nr);
+
+memset(_info, 0, sizeof(msi_info));
+msi_info.seg = s->pdev->seg;
+msi_info.bus = s->pdev->bus;
+msi_info.devfn = s->pdev->devfn;
+msi_info.table_base = s->msix->table_base;
+msi_info.entry_nr = entry_nr;
+
+rc = physdev_map_pirq(DOMID_SELF, MAP_PIRQ_TYPE_MSI, ,
+  , _info);
+if ( rc )
+{
+/*
+ * Do not broadcast this error, since there's nothing else
+ * that can be done (MSI-X setup should have been successful).
+ * Guest MSI would be actually not working.
+ */
+
+printk_pdev(s->pdev, XENLOG_ERR,
+  "can not map MSI-X (entry: %d)!\n", entry_nr);
+return rc;
+}
+entry->pirq = pirq;
+bound = false;
+}
+
+ASSERT(entry->pirq != -1);
+
+if ( bound )
+{
+printk_pdev(s->pdev, XENLOG_DEBUG, "destroy bind MSI-X entry %d\n",
+entry_nr);
+bind.hvm_domid = DOMID_SELF;
+bind.machine_irq = entry->pirq;
+bind.irq_type = PT_IRQ_TYPE_MSI;
+bind.u.msi.gvec = msi_vector(entry->data);
+bind.u.msi.gflags = msi_gflags(entry->data, entry->addr);
+bind.u.msi.gtable = s->msix->table_base;
+
+pcidevs_lock();
+rc = pt_irq_destroy_bind(current->domain, );
+pcidevs_unlock();
+if ( rc )
+{
+printk_pdev(s->pdev, XENLOG_ERR, "updating of MSI-X failed: %d\n",
+rc);
+rc = physdev_unmap_pirq(DOMID_SELF, entry->pirq);
+if ( rc )
+printk_pdev(s->pdev, XENLOG_ERR,
+"unmapping of MSI pirq %d failed: %d\n",
+

[Xen-devel] [PATCH v2 23/30] xen/x86: route legacy PCI interrupts to Dom0

[Roger Pau Monne]

This is done adding some Dom0 specific logic to the IO APIC emulation inside
of Xen, so that writes to the IO APIC registers that should unmask an
interrupt will take care of setting up this interrupt with Xen. A Dom0
specific EIO handler also has to be used, since Xen doesn't know the
topology of the PCI devices and it just has to passthrough what Dom0 does.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Paul Durrant 
---
 xen/arch/x86/hvm/irq.c   |   9 +++
 xen/arch/x86/hvm/vioapic.c   |  28 -
 xen/arch/x86/physdev.c   |   4 --
 xen/drivers/passthrough/io.c | 144 ++-
 xen/include/asm-x86/hvm/io.h |   2 +
 xen/include/asm-x86/irq.h|   5 ++
 xen/include/xen/hvm/irq.h|   3 +
 xen/include/xen/iommu.h  |   1 +
 8 files changed, 177 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index 5323d7c..be9b648 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -88,6 +88,15 @@ void hvm_pci_intx_assert(
 spin_unlock(>arch.hvm_domain.irq_lock);
 }
 
+void hvm_hw_gsi_assert(struct domain *d, unsigned int gsi)
+{
+
+ASSERT(is_hardware_domain(d));
+spin_lock(>arch.hvm_domain.irq_lock);
+assert_gsi(d, gsi);
+spin_unlock(>arch.hvm_domain.irq_lock);
+}
+
 static void __hvm_pci_intx_deassert(
 struct domain *d, unsigned int device, unsigned int intx)
 {
diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
index 611be87..18305be 100644
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -148,6 +148,29 @@ static void vioapic_write_redirent(
 unmasked = unmasked && !ent.fields.mask;
 }
 
+if ( is_hardware_domain(d) && unmasked )
+{
+int ret, gsi;
+
+/* Interrupt has been unmasked */
+gsi = idx;
+ret = mp_register_gsi(gsi, ent.fields.trig_mode, ent.fields.polarity);
+if ( ret && ret != -EEXIST )
+{
+gdprintk(XENLOG_WARNING,
+ "%s: error registering GSI %d\n", __func__, ret);
+}
+if ( !ret )
+{
+ret = physdev_map_pirq(DOMID_SELF, MAP_PIRQ_TYPE_GSI, , ,
+   NULL);
+BUG_ON(ret);
+
+ret = pt_irq_bind_hw_domain(gsi);
+BUG_ON(ret);
+}
+}
+
 *pent = ent;
 
 if ( idx == 0 )
@@ -409,7 +432,10 @@ void vioapic_update_EOI(struct domain *d, u8 vector)
 if ( iommu_enabled )
 {
 spin_unlock(>arch.hvm_domain.irq_lock);
-hvm_dpci_eoi(d, gsi, ent);
+if ( is_hardware_domain(d) )
+hvm_hw_dpci_eoi(d, gsi, ent);
+else
+hvm_dpci_eoi(d, gsi, ent);
 spin_lock(>arch.hvm_domain.irq_lock);
 }
 
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 0bea6e1..27dcbf4 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -19,10 +19,6 @@
 #include 
 #include 
 
-int physdev_map_pirq(domid_t, int type, int *index, int *pirq_p,
- struct msi_info *);
-int physdev_unmap_pirq(domid_t, int pirq);
-
 #include "x86_64/mmconfig.h"
 
 #ifndef COMPAT
diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 66577b6..edd8dbd 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -159,26 +159,29 @@ static int pt_irq_guest_eoi(struct domain *d, struct 
hvm_pirq_dpci *pirq_dpci,
 static void pt_irq_time_out(void *data)
 {
 struct hvm_pirq_dpci *irq_map = data;
-const struct hvm_irq_dpci *dpci;
 const struct dev_intx_gsi_link *digl;
 
 spin_lock(_map->dom->event_lock);
 
-dpci = domain_get_irq_dpci(irq_map->dom);
-ASSERT(dpci);
-list_for_each_entry ( digl, _map->digl_list, list )
+if ( !is_hardware_domain(irq_map->dom) )
 {
-unsigned int guest_gsi = hvm_pci_intx_gsi(digl->device, digl->intx);
-const struct hvm_girq_dpci_mapping *girq;
-
-list_for_each_entry ( girq, >girq[guest_gsi], list )
+const struct hvm_irq_dpci *dpci = domain_get_irq_dpci(irq_map->dom);
+ASSERT(dpci);
+list_for_each_entry ( digl, _map->digl_list, list )
 {
-struct pirq *pirq = pirq_info(irq_map->dom, girq->machine_gsi);
+unsigned int guest_gsi = hvm_pci_intx_gsi(digl->device, 
digl->intx);
+const struct hvm_girq_dpci_mapping *girq;
+
+list_for_each_entry ( girq, >girq[guest_gsi], list )
+{
+struct pirq *pirq = pirq_info(irq_map->dom, girq->machine_gsi);
 
-pirq_dpci(pirq)->flags |= HVM_IRQ_DPCI_EOI_LATCH;
+pirq_dpci(pirq)->flags |= HVM_IRQ_DPCI_EOI_LATCH;
+}
+hvm_pci_intx_deassert(irq_map->dom, digl->device, digl->intx);
 }
-

[Xen-devel] [PATCH v2 06/30] x86/paging: introduce paging_set_allocation

[Roger Pau Monne]

... and remove hap_set_alloc_for_pvh_dom0.

Signed-off-by: Roger Pau Monné 
Acked-by: Tim Deegan 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Tim Deegan 
---
Changes since RFC:
 - Make paging_set_allocation preemtable.
 - Move comments.
---
 xen/arch/x86/domain_build.c | 17 +
 xen/arch/x86/mm/hap/hap.c   | 14 +-
 xen/arch/x86/mm/paging.c| 16 
 xen/arch/x86/mm/shadow/common.c |  7 +--
 xen/include/asm-x86/hap.h   |  2 +-
 xen/include/asm-x86/paging.h|  7 +++
 xen/include/asm-x86/shadow.h|  8 
 7 files changed, 47 insertions(+), 24 deletions(-)

diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index 0a02d65..04d6cb0 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -35,7 +35,6 @@
 #include 
 #include  /* for bzimage_parse */
 #include 
-#include 
 #include 
 
 #include 
@@ -1383,15 +1382,25 @@ int __init construct_dom0(
  nr_pages);
 }
 
-if ( is_pvh_domain(d) )
-hap_set_alloc_for_pvh_dom0(d, dom0_paging_pages(d, nr_pages));
-
 /*
  * We enable paging mode again so guest_physmap_add_page will do the
  * right thing for us.
  */
 d->arch.paging.mode = save_pvh_pg_mode;
 
+if ( is_pvh_domain(d) )
+{
+int preempted;
+
+do {
+preempted = 0;
+paging_set_allocation(d, dom0_paging_pages(d, nr_pages),
+  );
+process_pending_softirqs();
+} while ( preempted );
+}
+
+
 /* Write the phys->machine and machine->phys table entries. */
 for ( pfn = 0; pfn < count; pfn++ )
 {
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 2dc82f5..4420e4e 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -334,7 +334,7 @@ hap_get_allocation(struct domain *d)
 
 /* Set the pool of pages to the required number of pages.
  * Returns 0 for success, non-zero for failure. */
-static int
+int
 hap_set_allocation(struct domain *d, unsigned long pages, int *preempted)
 {
 struct page_info *pg;
@@ -640,18 +640,6 @@ int hap_domctl(struct domain *d, xen_domctl_shadow_op_t 
*sc,
 }
 }
 
-void __init hap_set_alloc_for_pvh_dom0(struct domain *d,
-   unsigned long hap_pages)
-{
-int rc;
-
-paging_lock(d);
-rc = hap_set_allocation(d, hap_pages, NULL);
-paging_unlock(d);
-
-BUG_ON(rc);
-}
-
 static const struct paging_mode hap_paging_real_mode;
 static const struct paging_mode hap_paging_protected_mode;
 static const struct paging_mode hap_paging_pae_mode;
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index cc44682..2717bd3 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -954,6 +954,22 @@ void paging_write_p2m_entry(struct p2m_domain *p2m, 
unsigned long gfn,
 safe_write_pte(p, new);
 }
 
+int paging_set_allocation(struct domain *d, unsigned long pages, int 
*preempted)
+{
+int rc;
+
+ASSERT(paging_mode_enabled(d));
+
+paging_lock(d);
+if ( hap_enabled(d) )
+rc = hap_set_allocation(d, pages, preempted);
+else
+rc = sh_set_allocation(d, pages, preempted);
+paging_unlock(d);
+
+return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index d3cc2cc..53ffe1a 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1609,12 +1609,7 @@ shadow_free_p2m_page(struct domain *d, struct page_info 
*pg)
 paging_unlock(d);
 }
 
-/* Set the pool of shadow pages to the required number of pages.
- * Input will be rounded up to at least shadow_min_acceptable_pages(),
- * plus space for the p2m table.
- * Returns 0 for success, non-zero for failure. */
-static int sh_set_allocation(struct domain *d, unsigned long pages,
- int *preempted)
+int sh_set_allocation(struct domain *d, unsigned long pages, int *preempted)
 {
 struct page_info *sp;
 unsigned int lower_bound;
diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h
index c613836..9d59430 100644
--- a/xen/include/asm-x86/hap.h
+++ b/xen/include/asm-x86/hap.h
@@ -46,7 +46,7 @@ int   hap_track_dirty_vram(struct domain *d,
XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
 
 extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);
-void hap_set_alloc_for_pvh_dom0(struct domain *d, unsigned long num_pages);
+int hap_set_allocation(struct domain *d, unsigned long pages, int *preempted);
 
 #endif /* XEN_HAP_H */
 
diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h
index 56eef6b..c2d60d3 100644
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ 

[Xen-devel] [PATCH v2 24/30] x86/vmsi: add MSI emulation for hardware domain

[Roger Pau Monne]

Import the MSI handlers from QEMU into Xen. This allows Xen to detect
accesses to the MSI registers and correctly setup PIRQs for physical devices
that are then bound to the hardware domain.

The current logic only allows the usage of a single MSI interrupt per
device, so the maximum queue size announced by the device is unconditionally
set to 0 (1 vector only).

Signed-off-by: Roger Pau Monné 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/io.c|  59 +
 xen/arch/x86/hvm/vmsi.c  | 538 +++
 xen/include/asm-x86/hvm/io.h |  28 +++
 xen/include/asm-x86/msi.h|  32 +++
 xen/include/xen/hvm/irq.h|   1 +
 xen/include/xen/pci_regs.h   |   4 +
 6 files changed, 662 insertions(+)

diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index 4db0266..779babb 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -864,6 +864,7 @@ static int hvm_pt_add_register(struct hvm_pt_device *dev,
 static struct hvm_pt_handler_init *hwdom_pt_handlers[] = {
 _pt_bar_init,
 _pt_vf_bar_init,
+_pt_msi_init,
 };
 
 int hwdom_add_device(struct pci_dev *pdev)
@@ -931,6 +932,64 @@ int hwdom_add_device(struct pci_dev *pdev)
 return 0;
 }
 
+/* Generic handlers for HVM PCI pass-through. */
+int hvm_pt_common_reg_init(struct hvm_pt_device *s,
+   struct hvm_pt_reg_handler *handler,
+   uint32_t real_offset, uint32_t *data)
+{
+*data = handler->init_val;
+return 0;
+}
+
+int hvm_pt_word_reg_read(struct hvm_pt_device *s, struct hvm_pt_reg *reg,
+ uint16_t *value, uint16_t valid_mask)
+{
+struct hvm_pt_reg_handler *handler = reg->handler;
+uint16_t valid_emu_mask = 0;
+uint16_t *data = >val.word;
+
+/* emulate word register */
+valid_emu_mask = handler->emu_mask & valid_mask;
+*value = HVM_PT_MERGE_VALUE(*value, *data, ~valid_emu_mask);
+
+return 0;
+}
+
+int hvm_pt_long_reg_read(struct hvm_pt_device *s, struct hvm_pt_reg *reg,
+ uint32_t *value, uint32_t valid_mask)
+{
+struct hvm_pt_reg_handler *handler = reg->handler;
+uint32_t valid_emu_mask = 0;
+uint32_t *data = >val.dword;
+
+/* emulate long register */
+valid_emu_mask = handler->emu_mask & valid_mask;
+*value = HVM_PT_MERGE_VALUE(*value, *data, ~valid_emu_mask);
+
+return 0;
+}
+
+int hvm_pt_long_reg_write(struct hvm_pt_device *s, struct hvm_pt_reg *reg,
+  uint32_t *val, uint32_t dev_value,
+  uint32_t valid_mask)
+{
+struct hvm_pt_reg_handler *handler = reg->handler;
+uint32_t writable_mask = 0;
+uint32_t throughable_mask = hvm_pt_get_throughable_mask(s, handler,
+valid_mask);
+uint32_t *data = >val.dword;
+
+/* modify emulate register */
+writable_mask = handler->emu_mask & ~handler->ro_mask & valid_mask;
+*data = HVM_PT_MERGE_VALUE(*val, *data, writable_mask);
+
+/* create value for writing to I/O device register */
+*val = HVM_PT_MERGE_VALUE(*val, dev_value & ~handler->rw1c_mask,
+  throughable_mask);
+
+return 0;
+}
+
 static const struct hvm_io_ops dpci_portio_ops = {
 .accept = dpci_portio_accept,
 .read = dpci_portio_read,
diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index d81c5d4..75ba429 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -624,3 +624,541 @@ void msix_write_completion(struct vcpu *v)
 if ( msixtbl_write(v, ctrl_address, 4, 0) != X86EMUL_OKAY )
 gdprintk(XENLOG_WARNING, "MSI-X write completion failure\n");
 }
+
+/* MSI emulation. */
+
+/* Helper to check supported MSI features. */
+#define vmsi_check_type(offset, flags, what) \
+((offset) == ((flags) & PCI_MSI_FLAGS_64BIT ? \
+  PCI_MSI_##what##_64 : PCI_MSI_##what##_32))
+
+static inline uint64_t msi_addr64(struct hvm_pt_msi *msi)
+{
+return (uint64_t)msi->addr_hi << 32 | msi->addr_lo;
+}
+
+/* Helper for updating a PIRQ-vMSI bind. */
+static int vmsi_update_bind(struct hvm_pt_msi *msi)
+{
+xen_domctl_bind_pt_irq_t bind;
+struct hvm_pt_device *s = container_of(msi, struct hvm_pt_device, msi);
+int rc;
+
+ASSERT(msi->pirq != -1);
+
+bind.hvm_domid = DOMID_SELF;
+bind.machine_irq = msi->pirq;
+bind.irq_type = PT_IRQ_TYPE_MSI;
+bind.u.msi.gvec = msi_vector(msi->data);
+bind.u.msi.gflags = msi_gflags(msi->data, msi_addr64(msi));
+bind.u.msi.gtable = 0;
+
+pcidevs_lock();
+rc = pt_irq_create_bind(current->domain, );
+pcidevs_unlock();
+if ( rc )
+{
+printk_pdev(s->pdev, XENLOG_ERR,
+  "updating of MSI failed. (err: %d)\n", rc);
+rc = physdev_unmap_pirq(DOMID_SELF, msi->pirq);
+if 

[Xen-devel] [PATCH v2 22/30] xen/x86: support PVHv2 Dom0 BAR remapping

[Roger Pau Monne]

Add handlers to detect attemps from a PVHv2 Dom0 to change the position of
the PCI BARs and properly remap them.

Signed-off-by: Roger Pau Monné 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/io.c |   2 +
 xen/drivers/passthrough/pci.c | 307 ++
 xen/include/asm-x86/hvm/io.h  |  19 +++
 xen/include/xen/pci.h |   3 +
 4 files changed, 331 insertions(+)

diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index 7de1de3..4db0266 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -862,6 +862,8 @@ static int hvm_pt_add_register(struct hvm_pt_device *dev,
 }
 
 static struct hvm_pt_handler_init *hwdom_pt_handlers[] = {
+_pt_bar_init,
+_pt_vf_bar_init,
 };
 
 int hwdom_add_device(struct pci_dev *pdev)
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 6d831dd..60c9e74 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -633,6 +633,313 @@ static int pci_size_bar(unsigned int seg, unsigned int 
bus, unsigned int slot,
 return 0;
 }
 
+static bool bar_reg_is_vf(uint32_t real_offset, uint32_t handler_offset)
+{
+if ( real_offset - handler_offset == PCI_SRIOV_BAR )
+return true;
+else
+return false;
+}
+
+static int bar_reg_init(struct hvm_pt_device *s,
+struct hvm_pt_reg_handler *handler,
+uint32_t real_offset, uint32_t *data)
+{
+uint8_t seg, bus, slot, func;
+uint64_t addr, size;
+uint32_t val;
+unsigned int index = handler->offset / 4;
+bool vf = bar_reg_is_vf(real_offset, handler->offset);
+struct hvm_pt_bar *bars = (vf ? s->vf_bars : s->bars);
+int num_bars = (vf ? PCI_SRIOV_NUM_BARS : s->num_bars);
+int rc;
+
+if ( index >= num_bars )
+{
+*data = HVM_PT_INVALID_REG;
+return 0;
+}
+
+seg = s->pdev->seg;
+bus = s->pdev->bus;
+slot = PCI_SLOT(s->pdev->devfn);
+func = PCI_FUNC(s->pdev->devfn);
+val = pci_conf_read32(seg, bus, slot, func, real_offset);
+
+if ( index > 0 && bars[index - 1].type == HVM_PT_BAR_MEM64_LO )
+bars[index].type = HVM_PT_BAR_MEM64_HI;
+else if ( (val & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO )
+{
+bars[index].type = HVM_PT_BAR_UNUSED;
+}
+else if ( (val & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
+  PCI_BASE_ADDRESS_MEM_TYPE_64 )
+bars[index].type = HVM_PT_BAR_MEM64_LO;
+else
+bars[index].type = HVM_PT_BAR_MEM32;
+
+if ( bars[index].type == HVM_PT_BAR_MEM32 ||
+ bars[index].type == HVM_PT_BAR_MEM64_LO )
+{
+/* Size the BAR and map it. */
+rc = pci_size_bar(seg, bus, slot, func, real_offset - handler->offset,
+  num_bars, , , );
+if ( rc )
+{
+printk_pdev(s->pdev, XENLOG_ERR, "unable to size BAR#%d\n",
+index);
+return rc;
+}
+
+if ( size == 0 )
+bars[index].type = HVM_PT_BAR_UNUSED;
+else
+{
+printk_pdev(s->pdev, XENLOG_DEBUG,
+"Mapping BAR#%u: %#lx size: %u\n", index, addr, size);
+rc = modify_mmio_11(s->pdev->domain, PFN_DOWN(addr),
+DIV_ROUND_UP(size, PAGE_SIZE), true);
+if ( rc )
+{
+printk_pdev(s->pdev, XENLOG_ERR,
+"failed to map BAR#%d into memory map: %d\n",
+index, rc);
+return rc;
+}
+}
+}
+
+*data = bars[index].type == HVM_PT_BAR_UNUSED ? HVM_PT_INVALID_REG : val;
+return 0;
+}
+
+/* Only allow writes to check the size of the BARs */
+static int allow_bar_write(struct hvm_pt_bar *bar, struct hvm_pt_reg *reg,
+   struct pci_dev *pdev, uint32_t val)
+{
+uint32_t mask;
+
+if ( bar->type == HVM_PT_BAR_MEM64_HI )
+mask = ~0;
+else
+mask = (uint32_t) PCI_BASE_ADDRESS_MEM_MASK;
+
+if ( val != ~0 && (val & mask) != (reg->val.dword & mask) )
+{
+printk_pdev(pdev, XENLOG_ERR,
+"changing the position of the BARs is not yet supported: 
%#x\n",
+val);
+return -EINVAL;
+}
+
+return 0;
+}
+
+static int bar_reg_write(struct hvm_pt_device *s, struct hvm_pt_reg *reg,
+ uint32_t *val, uint32_t dev_value, uint32_t 
valid_mask)
+{
+int index = reg->handler->offset / 4;
+
+return allow_bar_write(>bars[index], reg, s->pdev, *val);
+}
+
+static int vf_bar_reg_write(struct hvm_pt_device *s, struct hvm_pt_reg *reg,
+uint32_t *val, uint32_t dev_value,
+uint32_t valid_mask)
+{
+int index = reg->handler->offset / 4;
+
+

[Xen-devel] [PATCH v2 30/30] xen: allow setting the store pfn HVM parameter

[Roger Pau Monne]

Xen already allows setting the store event channel, and this parameter is
not used by Xen at all.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/hvm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index bc4f7bc..5c3aa2a 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4982,6 +4982,7 @@ static int hvm_allow_set_param(struct domain *d,
 case HVM_PARAM_STORE_EVTCHN:
 case HVM_PARAM_CONSOLE_EVTCHN:
 case HVM_PARAM_X87_FIP_WIDTH:
+case HVM_PARAM_STORE_PFN:
 break;
 /*
  * The following parameters must not be set by the guest
-- 
2.7.4 (Apple Git-66)


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

[Xen-devel] [PATCH v2 18/30] xen/x86: setup PVHv2 Dom0 ACPI tables

[Roger Pau Monne]

This maps all the regions in the e820 marked as E820_ACPI or E820_NVS and
the top-level ACPI tables discovered by Xen to Dom0 1:1. It also shadows the
page(s) where the native MADT is placed by mapping a RAM page over it,
copying the original data and modifying it afterwards in order to represent
the real CPU topology exposed to Dom0.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
FWIW, I think that the current approach that I've used in order to craft the
MADT is not the best one, IMHO it would be better to place the MADT at the
end of the E820_ACPI region (expanding it's size one page), and modify the
XSDT/RSDT in order to point to it, that way we avoid shadowing any other
ACPI data that might be at the same page as the native MADT (and that needs
to be modified by Dom0).
---
 xen/arch/x86/domain_build.c | 274 
 1 file changed, 274 insertions(+)

diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index 8ea54ae..407f742 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -38,6 +39,8 @@
 #include 
 #include 
 
+#include 
+
 #include 
 #include 
 #include 
@@ -50,6 +53,8 @@ static long __initdata dom0_max_nrpages = LONG_MAX;
 #define HVM_VM86_TSS_SIZE   128
 
 static unsigned int __initdata hvm_mem_stats[MAX_ORDER + 1];
+static unsigned int __initdata acpi_intr_overrrides = 0;
+static struct acpi_madt_interrupt_override __initdata *intsrcovr = NULL;
 
 /*
  * dom0_mem=[min:,][max:,][]
@@ -1999,6 +2004,7 @@ static int __init hvm_load_kernel(struct domain *d, const 
module_t *image,
 last_addr += sizeof(mod);
 start_info.magic = XEN_HVM_START_MAGIC_VALUE;
 start_info.flags = SIF_PRIVILEGED | SIF_INITDOMAIN;
+start_info.rsdp_paddr = acpi_os_get_root_pointer();
 rc = hvm_copy_to_guest_phys(last_addr, _info, sizeof(start_info));
 if ( rc != HVMCOPY_okay )
 {
@@ -2111,6 +2117,267 @@ static int __init hvm_setup_cpus(struct domain *d, 
paddr_t entry,
 return 0;
 }
 
+static int __init acpi_count_intr_ov(struct acpi_subtable_header *header,
+ const unsigned long end)
+{
+
+acpi_intr_overrrides++;
+return 0;
+}
+
+static int __init acpi_set_intr_ov(struct acpi_subtable_header *header,
+   const unsigned long end)
+{
+struct acpi_madt_interrupt_override *intr =
+container_of(header, struct acpi_madt_interrupt_override, header);
+
+ACPI_MEMCPY(intsrcovr, intr, sizeof(*intr));
+intsrcovr++;
+
+return 0;
+}
+
+static void __init acpi_zap_table_signature(char *name)
+{
+struct acpi_table_header *table;
+acpi_status status;
+union {
+char str[ACPI_NAME_SIZE];
+uint32_t bits;
+} signature;
+char tmp;
+int i;
+
+status = acpi_get_table(name, 0, );
+if ( ACPI_SUCCESS(status) )
+{
+memcpy([0], >signature[0], ACPI_NAME_SIZE);
+for ( i = 0; i < ACPI_NAME_SIZE / 2; i++ )
+{
+tmp = signature.str[ACPI_NAME_SIZE - i - 1];
+signature.str[ACPI_NAME_SIZE - i - 1] = signature.str[i];
+signature.str[i] = tmp;
+}
+write_atomic((uint32_t*)>signature[0], signature.bits);
+}
+}
+
+static int __init hvm_setup_acpi(struct domain *d)
+{
+struct vcpu *saved_current, *v = d->vcpu[0];
+unsigned long pfn, nr_pages;
+uint64_t size, start_addr, end_addr;
+uint64_t madt_addr[2] = { 0, 0 };
+struct acpi_table_header *table;
+struct acpi_table_madt *madt;
+struct acpi_madt_io_apic *io_apic;
+struct acpi_madt_local_apic *local_apic;
+acpi_status status;
+int rc, i;
+
+printk("** Setup ACPI tables **\n");
+
+/* ZAP the HPET, SLIT, SRAT, MPST and PMTT tables. */
+acpi_zap_table_signature(ACPI_SIG_HPET);
+acpi_zap_table_signature(ACPI_SIG_SLIT);
+acpi_zap_table_signature(ACPI_SIG_SRAT);
+acpi_zap_table_signature(ACPI_SIG_MPST);
+acpi_zap_table_signature(ACPI_SIG_PMTT);
+
+/* Map ACPI tables 1:1 */
+for ( i = 0; i < d->arch.nr_e820; i++ )
+{
+if ( d->arch.e820[i].type != E820_ACPI &&
+ d->arch.e820[i].type != E820_NVS )
+continue;
+
+pfn = PFN_DOWN(d->arch.e820[i].addr);
+nr_pages = DIV_ROUND_UP(d->arch.e820[i].size, PAGE_SIZE);
+
+rc = modify_mmio_11(d, pfn, nr_pages, true);
+if ( rc )
+{
+printk(
+"Failed to map ACPI region %#lx - %#lx into Dom0 memory map\n",
+   pfn, pfn + nr_pages);
+return rc;
+}
+}
+/*
+ * Since most memory maps provided by hardware are wrong, make sure each
+ * top-level table is properly mapped into Dom0.
+ */
+for( i = 0; i < acpi_gbl_root_table_list.count; 

[Xen-devel] [PATCH v2 08/30] xen/x86: do the PCI scan unconditionally

[Roger Pau Monne]

Instead of being tied to the presence of an IOMMU

Signed-off-by: Roger Pau Monné 
Suggested-by: Andrew Cooper 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Suravee Suthikulpanit 
Cc: Kevin Tian 
Cc: Feng Wu 
---
 xen/arch/x86/setup.c| 2 ++
 xen/drivers/passthrough/amd/pci_amd_iommu.c | 3 ++-
 xen/drivers/passthrough/vtd/iommu.c | 2 --
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 8ae897a..1d27a6f 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1443,6 +1443,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 
 early_msi_init();
 
+scan_pci_devices();
+
 iommu_setup();/* setup iommu if available */
 
 smp_prepare_cpus(max_cpus);
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c 
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index 94a25a4..d12575d 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -219,7 +219,8 @@ int __init amd_iov_detect(void)
 
 if ( !amd_iommu_perdev_intremap )
 printk(XENLOG_WARNING "AMD-Vi: Using global interrupt remap table is 
not recommended (see XSA-36)!\n");
-return scan_pci_devices();
+
+return 0;
 }
 
 static int allocate_domain_resources(struct domain_iommu *hd)
diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 48f120b..919993e 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2299,8 +2299,6 @@ int __init intel_vtd_setup(void)
 P(iommu_hap_pt_share, "Shared EPT tables");
 #undef P
 
-scan_pci_devices();
-
 ret = init_vtd_hw();
 if ( ret )
 goto error;
-- 
2.7.4 (Apple Git-66)


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

[Xen-devel] [PATCH v2 16/30] xen/x86: parse Dom0 kernel for PVHv2

[Roger Pau Monne]

Introduce a helper to parse the Dom0 kernel.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/domain_build.c | 138 
 1 file changed, 138 insertions(+)

diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index c590c58..effebf1 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -39,6 +39,7 @@
 #include 
 
 #include 
+#include 
 
 static long __initdata dom0_nrpages;
 static long __initdata dom0_min_nrpages;
@@ -1886,12 +1887,141 @@ static int __init hvm_setup_p2m(struct domain *d)
 return 0;
 }
 
+static int __init hvm_load_kernel(struct domain *d, const module_t *image,
+  unsigned long image_headroom,
+  module_t *initrd, char *image_base,
+  char *cmdline, paddr_t *entry,
+  paddr_t *start_info_addr)
+{
+char *image_start = image_base + image_headroom;
+unsigned long image_len = image->mod_end;
+struct elf_binary elf;
+struct elf_dom_parms parms;
+paddr_t last_addr;
+struct hvm_start_info start_info;
+struct hvm_modlist_entry mod;
+struct vcpu *saved_current, *v = d->vcpu[0];
+int rc;
+
+printk("** Parsing Dom0 kernel **\n");
+
+if ( (rc = bzimage_parse(image_base, _start, _len)) != 0 )
+{
+printk("Error trying to detect bz compressed kernel\n");
+return rc;
+}
+
+if ( (rc = elf_init(, image_start, image_len)) != 0 )
+{
+printk("Unable to init ELF\n");
+return rc;
+}
+#ifdef VERBOSE
+elf_set_verbose();
+#endif
+elf_parse_binary();
+if ( (rc = elf_xen_parse(, )) != 0 )
+{
+printk("Unable to parse kernel for ELFNOTES\n");
+return rc;
+}
+
+if ( parms.phys_entry == UNSET_ADDR32 ) {
+printk("Unable to find kernel entry point, aborting\n");
+return -EINVAL;
+}
+
+printk("OS: %s version: %s loader: %s bitness: %s\n", parms.guest_os,
+   parms.guest_ver, parms.loader,
+   elf_64bit() ? "64-bit" : "32-bit");
+
+printk("** Loading Dom0 kernel **\n");
+/* Copy the OS image and free temporary buffer. */
+elf.dest_base = (void *)(parms.virt_kstart - parms.virt_base);
+elf.dest_size = parms.virt_kend - parms.virt_kstart;
+
+saved_current = current;
+set_current(v);
+
+rc = elf_load_binary();
+if ( rc < 0 )
+{
+printk("Failed to load kernel: %d\n", rc);
+printk("Xen dom0 kernel broken ELF: %s\n", elf_check_broken());
+goto out;
+}
+
+last_addr = ROUNDUP(parms.virt_kend - parms.virt_base, PAGE_SIZE);
+printk("** Copying Dom0 modules **\n");
+
+rc = hvm_copy_to_guest_phys(last_addr, mfn_to_virt(initrd->mod_start),
+initrd->mod_end);
+if ( rc != HVMCOPY_okay )
+{
+printk("Unable to copy initrd to guest\n");
+rc = -EFAULT;
+goto out;
+}
+
+mod.paddr = last_addr;
+mod.size = initrd->mod_end;
+last_addr += ROUNDUP(initrd->mod_end, PAGE_SIZE);
+
+/* Free temporary buffers. */
+discard_initial_images();
+
+printk("** Setting up start-of-day info **\n");
+
+memset(_info, 0, sizeof(start_info));
+if ( cmdline != NULL )
+{
+rc = hvm_copy_to_guest_phys(last_addr, cmdline, strlen(cmdline) + 1);
+if ( rc != HVMCOPY_okay )
+{
+printk("Unable to copy guest command line\n");
+rc = -EFAULT;
+goto out;
+}
+start_info.cmdline_paddr = last_addr;
+last_addr += ROUNDUP(strlen(cmdline) + 1, 8);
+}
+rc = hvm_copy_to_guest_phys(last_addr, , sizeof(mod));
+if ( rc != HVMCOPY_okay )
+{
+printk("Unable to copy guest modules\n");
+rc = -EFAULT;
+goto out;
+}
+
+start_info.modlist_paddr = last_addr;
+start_info.nr_modules = 1;
+last_addr += sizeof(mod);
+start_info.magic = XEN_HVM_START_MAGIC_VALUE;
+start_info.flags = SIF_PRIVILEGED | SIF_INITDOMAIN;
+rc = hvm_copy_to_guest_phys(last_addr, _info, sizeof(start_info));
+if ( rc != HVMCOPY_okay )
+{
+printk("Unable to copy start info to guest\n");
+rc = -EFAULT;
+goto out;
+}
+
+*entry = parms.phys_entry;
+*start_info_addr = last_addr;
+rc = 0;
+
+out:
+set_current(saved_current);
+return rc;
+}
+
 static int __init construct_dom0_hvm(struct domain *d, const module_t *image,
  unsigned long image_headroom,
  module_t *initrd,
  void *(*bootstrap_map)(const module_t *),
  char *cmdline)
 {
+paddr_t entry, start_info;
 int rc;
 
 printk("** Building a PVH Dom0 **\n");

[Xen-devel] [PATCH v2 15/30] xen/x86: populate PVHv2 Dom0 physical memory map

[Roger Pau Monne]

Craft the Dom0 e820 memory map and populate it.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since RFC:
 - Use IS_ALIGNED instead of checking with PAGE_MASK.
 - Use the new %pB specifier in order to print sizes in human readable form.
 - Create a VM86 TSS for hardware that doesn't support unrestricted mode.
 - Subtract guest RAM for the identity page table and the VM86 TSS.
 - Split the creation of the unrestricted mode helper structures to a
   separate function.
 - Use preemption with paging_set_allocation.
 - Use get_order_from_bytes_floor.
---
 xen/arch/x86/domain_build.c | 257 ++--
 1 file changed, 251 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index 982bb5f..c590c58 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -43,6 +44,11 @@ static long __initdata dom0_nrpages;
 static long __initdata dom0_min_nrpages;
 static long __initdata dom0_max_nrpages = LONG_MAX;
 
+/* Size of the VM86 TSS for virtual 8086 mode to use. */
+#define HVM_VM86_TSS_SIZE   128
+
+static unsigned int __initdata hvm_mem_stats[MAX_ORDER + 1];
+
 /*
  * dom0_mem=[min:,][max:,][]
  * 
@@ -304,7 +310,8 @@ static unsigned long __init compute_dom0_nr_pages(
 avail -= max_pdx >> s;
 }
 
-need_paging = opt_dom0_shadow || (is_pvh_domain(d) && !iommu_hap_pt_share);
+need_paging = opt_dom0_shadow || (has_hvm_container_domain(d) &&
+  (!iommu_hap_pt_share || !paging_mode_hap(d)));
 for ( ; ; need_paging = 0 )
 {
 nr_pages = dom0_nrpages;
@@ -336,7 +343,8 @@ static unsigned long __init compute_dom0_nr_pages(
 avail -= dom0_paging_pages(d, nr_pages);
 }
 
-if ( (parms->p2m_base == UNSET_ADDR) && (dom0_nrpages <= 0) &&
+if ( is_pv_domain(d) &&
+ (parms->p2m_base == UNSET_ADDR) && (dom0_nrpages <= 0) &&
  ((dom0_min_nrpages <= 0) || (nr_pages > min_pages)) )
 {
 /*
@@ -547,11 +555,12 @@ static __init void pvh_map_all_iomem(struct domain *d, 
unsigned long nr_pages)
 ASSERT(nr_holes == 0);
 }
 
-static __init void pvh_setup_e820(struct domain *d, unsigned long nr_pages)
+static __init void hvm_setup_e820(struct domain *d, unsigned long nr_pages)
 {
 struct e820entry *entry, *entry_guest;
 unsigned int i;
 unsigned long pages, cur_pages = 0;
+uint64_t start, end;
 
 /*
  * Craft the e820 memory map for Dom0 based on the hardware e820 map.
@@ -579,8 +588,19 @@ static __init void pvh_setup_e820(struct domain *d, 
unsigned long nr_pages)
 continue;
 }
 
-*entry_guest = *entry;
-pages = PFN_UP(entry_guest->size);
+/*
+ * Make sure the start and length are aligned to PAGE_SIZE, because
+ * that's the minimum granularity of the 2nd stage translation.
+ */
+start = ROUNDUP(entry->addr, PAGE_SIZE);
+end = (entry->addr + entry->size) & PAGE_MASK;
+if ( start >= end )
+continue;
+
+entry_guest->type = E820_RAM;
+entry_guest->addr = start;
+entry_guest->size = end - start;
+pages = PFN_DOWN(entry_guest->size);
 if ( (cur_pages + pages) > nr_pages )
 {
 /* Truncate region */
@@ -591,6 +611,8 @@ static __init void pvh_setup_e820(struct domain *d, 
unsigned long nr_pages)
 {
 cur_pages += pages;
 }
+ASSERT(IS_ALIGNED(entry_guest->addr, PAGE_SIZE) &&
+   IS_ALIGNED(entry_guest->size, PAGE_SIZE));
  next:
 d->arch.nr_e820++;
 entry_guest++;
@@ -1641,7 +1663,7 @@ static int __init construct_dom0_pv(
 dom0_update_physmap(d, pfn, mfn, 0);
 
 pvh_map_all_iomem(d, nr_pages);
-pvh_setup_e820(d, nr_pages);
+hvm_setup_e820(d, nr_pages);
 }
 
 if ( d->domain_id == hardware_domid )
@@ -1657,15 +1679,238 @@ out:
 return rc;
 }
 
+/* Populate an HVM memory range using the biggest possible order. */
+static void __init hvm_populate_memory_range(struct domain *d, uint64_t start,
+ uint64_t size)
+{
+static unsigned int __initdata memflags = MEMF_no_dma|MEMF_exact_node;
+unsigned int order;
+struct page_info *page;
+int rc;
+
+ASSERT(IS_ALIGNED(size, PAGE_SIZE) && IS_ALIGNED(start, PAGE_SIZE));
+
+order = MAX_ORDER;
+while ( size != 0 )
+{
+order = min(get_order_from_bytes_floor(size), order);
+page = alloc_domheap_pages(d, order, memflags);
+if ( page == NULL )
+{
+if ( order == 0 && memflags )
+{
+/* Try again without any memflags. */
+memflags = 0;
+order = MAX_ORDER;
+   

[Xen-devel] [PATCH v2 19/30] xen/dcpi: add a dpci passthrough handler for hardware domain

[Roger Pau Monne]

This is very similar to the PCI trap used for the traditional PV(H) Dom0.

Signed-off-by: Roger Pau Monné 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/io.c | 72 ++-
 xen/arch/x86/traps.c  | 39 ---
 xen/drivers/passthrough/pci.c | 39 +++
 xen/include/xen/pci.h |  2 ++
 4 files changed, 112 insertions(+), 40 deletions(-)

diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index 1e7a5f9..31d54dc 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -247,12 +247,79 @@ static int dpci_portio_write(const struct hvm_io_handler 
*handler,
 return X86EMUL_OKAY;
 }
 
+static bool_t hw_dpci_portio_accept(const struct hvm_io_handler *handler,
+const ioreq_t *p)
+{
+if ( (p->addr == 0xcf8 && p->size == 4) || (p->addr & 0xfffc) == 0xcfc)
+{
+return 1;
+}
+
+return 0;
+}
+
+static int hw_dpci_portio_read(const struct hvm_io_handler *handler,
+uint64_t addr,
+uint32_t size,
+uint64_t *data)
+{
+struct domain *currd = current->domain;
+
+if ( addr == 0xcf8 )
+{
+ASSERT(size == 4);
+*data = currd->arch.pci_cf8;
+return X86EMUL_OKAY;
+}
+
+ASSERT((addr & 0xfffc) == 0xcfc);
+size = min(size, 4 - ((uint32_t)addr & 3));
+if ( size == 3 )
+size = 2;
+if ( pci_cfg_ok(currd, addr & 3, size, NULL) )
+*data = pci_conf_read(currd->arch.pci_cf8, addr & 3, size);
+
+return X86EMUL_OKAY;
+}
+
+static int hw_dpci_portio_write(const struct hvm_io_handler *handler,
+uint64_t addr,
+uint32_t size,
+uint64_t data)
+{
+struct domain *currd = current->domain;
+uint32_t data32;
+
+if ( addr == 0xcf8 )
+{
+ASSERT(size == 4);
+currd->arch.pci_cf8 = data;
+return X86EMUL_OKAY;
+}
+
+ASSERT((addr & 0xfffc) == 0xcfc);
+size = min(size, 4 - ((uint32_t)addr & 3));
+if ( size == 3 )
+size = 2;
+data32 = data;
+if ( pci_cfg_ok(currd, addr & 3, size, ) )
+pci_conf_write(currd->arch.pci_cf8, addr & 3, size, data);
+
+return X86EMUL_OKAY;
+}
+
 static const struct hvm_io_ops dpci_portio_ops = {
 .accept = dpci_portio_accept,
 .read = dpci_portio_read,
 .write = dpci_portio_write
 };
 
+static const struct hvm_io_ops hw_dpci_portio_ops = {
+.accept = hw_dpci_portio_accept,
+.read = hw_dpci_portio_read,
+.write = hw_dpci_portio_write
+};
+
 void register_dpci_portio_handler(struct domain *d)
 {
 struct hvm_io_handler *handler = hvm_next_io_handler(d);
@@ -261,7 +328,10 @@ void register_dpci_portio_handler(struct domain *d)
 return;
 
 handler->type = IOREQ_TYPE_PIO;
-handler->ops = _portio_ops;
+if ( is_hardware_domain(d) )
+handler->ops = _dpci_portio_ops;
+else
+handler->ops = _portio_ops;
 }
 
 /*
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 24d173f..f3c5c9e 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2076,45 +2076,6 @@ static bool_t admin_io_okay(unsigned int port, unsigned 
int bytes,
 return ioports_access_permitted(d, port, port + bytes - 1);
 }
 
-static bool_t pci_cfg_ok(struct domain *currd, unsigned int start,
- unsigned int size, uint32_t *write)
-{
-uint32_t machine_bdf;
-
-if ( !is_hardware_domain(currd) )
-return 0;
-
-if ( !CF8_ENABLED(currd->arch.pci_cf8) )
-return 1;
-
-machine_bdf = CF8_BDF(currd->arch.pci_cf8);
-if ( write )
-{
-const unsigned long *ro_map = pci_get_ro_map(0);
-
-if ( ro_map && test_bit(machine_bdf, ro_map) )
-return 0;
-}
-start |= CF8_ADDR_LO(currd->arch.pci_cf8);
-/* AMD extended configuration space access? */
-if ( CF8_ADDR_HI(currd->arch.pci_cf8) &&
- boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
- boot_cpu_data.x86 >= 0x10 && boot_cpu_data.x86 <= 0x17 )
-{
-uint64_t msr_val;
-
-if ( rdmsr_safe(MSR_AMD64_NB_CFG, msr_val) )
-return 0;
-if ( msr_val & (1ULL << AMD64_NB_CFG_CF8_EXT_ENABLE_BIT) )
-start |= CF8_ADDR_HI(currd->arch.pci_cf8);
-}
-
-return !write ?
-   xsm_pci_config_permission(XSM_HOOK, currd, machine_bdf,
- start, start + size - 1, 0) == 0 :
-   pci_conf_write_intercept(0, machine_bdf, start, size, write) >= 0;
-}
-
 uint32_t guest_io_read(unsigned int port, unsigned int bytes,
struct domain *currd)
 {
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 

[Xen-devel] [PATCH v2 29/30] xen/x86: allow PVHv2 to perform foreign memory mappings

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
---
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 44492ae..c989b60 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2793,7 +2793,7 @@ int p2m_add_foreign(struct domain *tdom, unsigned long 
fgfn,
 struct domain *fdom;
 
 ASSERT(tdom);
-if ( foreigndom == DOMID_SELF || !is_pvh_domain(tdom) )
+if ( foreigndom == DOMID_SELF || !has_hvm_container_domain(tdom) )
 return -EINVAL;
 /*
  * pvh fixme: until support is added to p2m teardown code to cleanup any
-- 
2.7.4 (Apple Git-66)


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

[Xen-devel] [PATCH v2 20/30] xen/x86: add the basic infrastructure to import QEMU passthrough code

[Roger Pau Monne]

Most of this code has been picked up from QEMU and modified so it can be
plugged into the internal Xen IO handlers. The structure of the handlers has
been keep quite similar to QEMU, so existing handlers can be imported
without a lot of effort.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Paul Durrant 
---
 docs/misc/xen-command-line.markdown |   8 +
 xen/arch/x86/hvm/hvm.c  |   2 +
 xen/arch/x86/hvm/io.c   | 621 
 xen/include/asm-x86/hvm/domain.h|   4 +
 xen/include/asm-x86/hvm/io.h| 176 ++
 xen/include/xen/pci.h   |   5 +
 6 files changed, 816 insertions(+)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 59d7210..78130c8 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -670,6 +670,14 @@ Flag that makes a 64bit dom0 boot in PVH mode. No 32bit 
support at present.
 
 Flag that makes a dom0 boot in PVHv2 mode.
 
+### dom0permissive
+> `= `
+
+> Default: `true`
+
+Select mode of PCI pass-through when using a PVHv2 Dom0, either permissive or
+not.
+
 ### dtuart (ARM)
 > `= path [:options]`
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index a291f82..bc4f7bc 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -632,6 +632,8 @@ int hvm_domain_initialise(struct domain *d)
 goto fail1;
 }
 memset(d->arch.hvm_domain.io_bitmap, ~0, HVM_IOBITMAP_SIZE);
+INIT_LIST_HEAD(>arch.hvm_domain.pt_devices);
+rwlock_init(>arch.hvm_domain.pt_lock);
 }
 else
 d->arch.hvm_domain.io_bitmap = hvm_io_bitmap;
diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index 31d54dc..7de1de3 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -46,6 +46,10 @@
 #include 
 #include 
 
+/* Set permissive mode for HVM Dom0 PCI pass-through by default */
+static bool_t opt_dom0permissive = 1;
+boolean_param("dom0permissive", opt_dom0permissive);
+
 void send_timeoffset_req(unsigned long timeoff)
 {
 ioreq_t p = {
@@ -258,12 +262,403 @@ static bool_t hw_dpci_portio_accept(const struct 
hvm_io_handler *handler,
 return 0;
 }
 
+static struct hvm_pt_device *hw_dpci_get_device(struct domain *d)
+{
+uint8_t bus, slot, func;
+uint32_t addr;
+struct hvm_pt_device *dev;
+
+/* Decode bus, slot and func. */
+addr = CF8_BDF(d->arch.pci_cf8);
+bus = PCI_BUS(addr);
+slot = PCI_SLOT(addr);
+func = PCI_FUNC(addr);
+
+list_for_each_entry( dev, >arch.hvm_domain.pt_devices, entries )
+{
+if ( dev->pdev->seg != 0 || dev->pdev->bus != bus ||
+ dev->pdev->devfn != PCI_DEVFN(slot,func) )
+continue;
+
+return dev;
+}
+
+return NULL;
+}
+
+/* Dispatchers */
+
+/* Find emulate register group entry */
+struct hvm_pt_reg_group *hvm_pt_find_reg_grp(struct hvm_pt_device *d,
+ uint32_t address)
+{
+struct hvm_pt_reg_group *entry = NULL;
+
+/* Find register group entry */
+list_for_each_entry( entry, >register_groups, entries )
+{
+/* check address */
+if ( (entry->base_offset <= address)
+ && ((entry->base_offset + entry->size) > address) )
+return entry;
+}
+
+/* Group entry not found */
+return NULL;
+}
+
+/* Find emulate register entry */
+struct hvm_pt_reg *hvm_pt_find_reg(struct hvm_pt_reg_group *reg_grp,
+   uint32_t address)
+{
+struct hvm_pt_reg *reg_entry = NULL;
+struct hvm_pt_reg_handler *handler = NULL;
+uint32_t real_offset = 0;
+
+/* Find register entry */
+list_for_each_entry( reg_entry, _grp->registers, entries )
+{
+handler = reg_entry->handler;
+real_offset = reg_grp->base_offset + handler->offset;
+/* Check address */
+if ( (real_offset <= address)
+ && ((real_offset + handler->size) > address) )
+return reg_entry;
+}
+
+return NULL;
+}
+
+static int hvm_pt_pci_config_access_check(struct hvm_pt_device *d,
+  uint32_t addr, int len)
+{
+/* Check offset range */
+if ( addr >= 0xFF )
+{
+printk_pdev(d->pdev, XENLOG_DEBUG,
+"failed to access register with offset exceeding 0xFF. "
+"(addr: 0x%02x, len: %d)\n", addr, len);
+return -EDOM;
+}
+
+/* Check read size */
+if ( (len != 1) && (len != 2) && (len != 4) )
+{
+printk_pdev(d->pdev, XENLOG_DEBUG,
+"failed to access register with invalid access length. "
+"(addr: 0x%02x, len: %d)\n", addr, len);
+return -EINVAL;
+}
+
+/* Check offset alignment */
+if ( addr & (len - 1) )
+{
+printk_pdev(d->pdev, 

[Xen-devel] [PATCH v2 25/30] xen/x86: add all PCI devices to PVHv2 Dom0

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/domain_build.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index 407f742..b4a14a3 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -2378,6 +2378,25 @@ static int __init hvm_setup_acpi(struct domain *d)
 return 0;
 }
 
+static int __init hvm_setup_pci(struct domain *d)
+{
+struct pci_dev *pdev;
+int rc;
+
+printk("** Adding PCI devices **\n");
+
+pcidevs_lock();
+list_for_each_entry( pdev, >arch.pdev_list, domain_list )
+{
+rc = hwdom_add_device(pdev);
+if ( rc )
+return rc;
+}
+pcidevs_unlock();
+
+return 0;
+}
+
 static int __init construct_dom0_hvm(struct domain *d, const module_t *image,
  unsigned long image_headroom,
  module_t *initrd,
@@ -2426,6 +2445,13 @@ static int __init construct_dom0_hvm(struct domain *d, 
const module_t *image,
 return rc;
 }
 
+rc = hvm_setup_pci(d);
+if ( rc )
+{
+printk("Failed to add PCI devices: %d\n", rc);
+return rc;
+}
+
 return 0;
 }
 
-- 
2.7.4 (Apple Git-66)


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

[Xen-devel] [PATCH v2 21/30] xen/pci: split code to size BARs from pci_add_device

[Roger Pau Monne]

Because it's also going to be used by other code.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
---
 xen/drivers/passthrough/pci.c | 86 ++-
 1 file changed, 53 insertions(+), 33 deletions(-)

diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index a53b4c8..6d831dd 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -587,6 +587,52 @@ static void pci_enable_acs(struct pci_dev *pdev)
 pci_conf_write16(seg, bus, dev, func, pos + PCI_ACS_CTRL, ctrl);
 }
 
+static int pci_size_bar(unsigned int seg, unsigned int bus, unsigned int slot,
+unsigned int func, unsigned int base,
+unsigned int max_bars, unsigned int *index,
+uint64_t *addr, uint64_t *size)
+{
+unsigned int idx = base + *index * 4;
+u32 bar = pci_conf_read32(seg, bus, slot, func, idx);
+u32 hi = 0;
+
+*addr = *size = 0;
+
+ASSERT((bar & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_MEMORY);
+pci_conf_write32(seg, bus, slot, func, idx, ~0);
+if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
+ PCI_BASE_ADDRESS_MEM_TYPE_64 )
+{
+if ( *index >= max_bars )
+{
+printk(XENLOG_WARNING
+   "device %04x:%02x:%02x.%u with 64-bit BAR in last slot\n",
+   seg, bus, slot, func);
+return -EINVAL;
+}
+hi = pci_conf_read32(seg, bus, slot, func, idx + 4);
+pci_conf_write32(seg, bus, slot, func, idx + 4, ~0);
+}
+*size = pci_conf_read32(seg, bus, slot, func, idx) &
+PCI_BASE_ADDRESS_MEM_MASK;
+if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
+ PCI_BASE_ADDRESS_MEM_TYPE_64 )
+{
+*size |= (u64)pci_conf_read32(seg, bus, slot, func, idx + 4) << 32;
+pci_conf_write32(seg, bus, slot, func, idx + 4, hi);
+}
+else if ( *size )
+*size |= (u64)~0 << 32;
+pci_conf_write32(seg, bus, slot, func, idx, bar);
+*size = - *size;
+*addr = (bar & PCI_BASE_ADDRESS_MEM_MASK) | ((u64)hi << 32);
+if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
+ PCI_BASE_ADDRESS_MEM_TYPE_64 )
+++*index;
+
+return 0;
+}
+
 int pci_add_device(u16 seg, u8 bus, u8 devfn,
const struct pci_dev_info *info, nodeid_t node)
 {
@@ -651,7 +697,7 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
 {
 unsigned int idx = pos + PCI_SRIOV_BAR + i * 4;
 u32 bar = pci_conf_read32(seg, bus, slot, func, idx);
-u32 hi = 0;
+uint64_t addr;
 
 if ( (bar & PCI_BASE_ADDRESS_SPACE) ==
  PCI_BASE_ADDRESS_SPACE_IO )
@@ -662,38 +708,12 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
seg, bus, slot, func, i);
 continue;
 }
-pci_conf_write32(seg, bus, slot, func, idx, ~0);
-if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
- PCI_BASE_ADDRESS_MEM_TYPE_64 )
-{
-if ( i >= PCI_SRIOV_NUM_BARS )
-{
-printk(XENLOG_WARNING
-   "SR-IOV device %04x:%02x:%02x.%u with 64-bit"
-   " vf BAR in last slot\n",
-   seg, bus, slot, func);
-break;
-}
-hi = pci_conf_read32(seg, bus, slot, func, idx + 4);
-pci_conf_write32(seg, bus, slot, func, idx + 4, ~0);
-}
-pdev->vf_rlen[i] = pci_conf_read32(seg, bus, slot, func, idx) &
-   PCI_BASE_ADDRESS_MEM_MASK;
-if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
- PCI_BASE_ADDRESS_MEM_TYPE_64 )
-{
-pdev->vf_rlen[i] |= (u64)pci_conf_read32(seg, bus,
- slot, func,
- idx + 4) << 32;
-pci_conf_write32(seg, bus, slot, func, idx + 4, hi);
-}
-else if ( pdev->vf_rlen[i] )
-pdev->vf_rlen[i] |= (u64)~0 << 32;
-pci_conf_write32(seg, bus, slot, func, idx, bar);
-pdev->vf_rlen[i] = -pdev->vf_rlen[i];
-if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
- PCI_BASE_ADDRESS_MEM_TYPE_64 )
-++i;
+ret = pci_size_bar(seg, bus, slot, func, pos + PCI_SRIOV_BAR,
+   PCI_SRIOV_NUM_BARS, , ,
+   >vf_rlen[i]);
+if ( ret )
+printk_pdev(pdev, XENLOG_WARNING,
+"failed to 

[Xen-devel] [PATCH v2 17/30] xen/x86: setup PVHv2 Dom0 CPUs

[Roger Pau Monne]

Initialize Dom0 BSP/APs and setup the memory and IO permissions.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
The logic used to setup the CPUID leaves is extremely simplistic (and
probably wrong for hardware different than mine). I'm not sure what's the
best way to deal with this, the code that currently sets the CPUID leaves
for HVM guests lives in libxc, maybe moving it xen/common would be better?
---
 xen/arch/x86/domain_build.c | 103 
 1 file changed, 103 insertions(+)

diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index effebf1..8ea54ae 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -40,6 +40,7 @@
 
 #include 
 #include 
+#include 
 
 static long __initdata dom0_nrpages;
 static long __initdata dom0_min_nrpages;
@@ -2015,6 +2016,101 @@ out:
 return rc;
 }
 
+static int __init hvm_setup_cpus(struct domain *d, paddr_t entry,
+ paddr_t start_info)
+{
+vcpu_hvm_context_t cpu_ctx;
+struct vcpu *v = d->vcpu[0];
+int cpu, i, rc;
+struct {
+uint32_t index;
+uint32_t count;
+} cpuid_leaves[] = {
+{0, XEN_CPUID_INPUT_UNUSED},
+{1, XEN_CPUID_INPUT_UNUSED},
+{2, XEN_CPUID_INPUT_UNUSED},
+{4, 0},
+{4, 1},
+{4, 2},
+{4, 3},
+{4, 4},
+{7, 0},
+{0xa, XEN_CPUID_INPUT_UNUSED},
+{0xd, 0},
+{0x8000, XEN_CPUID_INPUT_UNUSED},
+{0x8001, XEN_CPUID_INPUT_UNUSED},
+{0x8002, XEN_CPUID_INPUT_UNUSED},
+{0x8003, XEN_CPUID_INPUT_UNUSED},
+{0x8004, XEN_CPUID_INPUT_UNUSED},
+{0x8005, XEN_CPUID_INPUT_UNUSED},
+{0x8006, XEN_CPUID_INPUT_UNUSED},
+{0x8007, XEN_CPUID_INPUT_UNUSED},
+{0x8008, XEN_CPUID_INPUT_UNUSED},
+};
+
+printk("** Setting up BSP/APs **\n");
+
+cpu = v->processor;
+for ( i = 1; i < d->max_vcpus; i++ )
+{
+cpu = cpumask_cycle(cpu, _cpus);
+setup_dom0_vcpu(d, i, cpu);
+}
+
+memset(_ctx, 0, sizeof(cpu_ctx));
+
+cpu_ctx.mode = VCPU_HVM_MODE_32B;
+
+cpu_ctx.cpu_regs.x86_32.ebx = start_info;
+cpu_ctx.cpu_regs.x86_32.eip = entry;
+cpu_ctx.cpu_regs.x86_32.cr0 = X86_CR0_PE | X86_CR0_ET;
+
+cpu_ctx.cpu_regs.x86_32.cs_limit = ~0u;
+cpu_ctx.cpu_regs.x86_32.ds_limit = ~0u;
+cpu_ctx.cpu_regs.x86_32.ss_limit = ~0u;
+cpu_ctx.cpu_regs.x86_32.tr_limit = 0x67;
+cpu_ctx.cpu_regs.x86_32.cs_ar = 0xc9b;
+cpu_ctx.cpu_regs.x86_32.ds_ar = 0xc93;
+cpu_ctx.cpu_regs.x86_32.ss_ar = 0xc93;
+cpu_ctx.cpu_regs.x86_32.tr_ar = 0x8b;
+
+rc = arch_set_info_hvm_guest(v, _ctx);
+if ( rc )
+{
+printk("Unable to setup Dom0 BSP context: %d\n", rc);
+return rc;
+}
+clear_bit(_VPF_down, >pause_flags);
+
+for ( i = 0; i < ARRAY_SIZE(cpuid_leaves); i++ )
+{
+d->arch.cpuids[i].input[0] = cpuid_leaves[i].index;
+d->arch.cpuids[i].input[1] = cpuid_leaves[i].count;
+if ( d->arch.cpuids[i].input[1] == XEN_CPUID_INPUT_UNUSED )
+cpuid(d->arch.cpuids[i].input[0], >arch.cpuids[i].eax,
+  >arch.cpuids[i].ebx, >arch.cpuids[i].ecx,
+  >arch.cpuids[i].edx);
+else
+cpuid_count(d->arch.cpuids[i].input[0], d->arch.cpuids[i].input[1],
+>arch.cpuids[i].eax, >arch.cpuids[i].ebx,
+>arch.cpuids[i].ecx, >arch.cpuids[i].edx);
+/* XXX: we need to do much more filtering here. */
+if ( d->arch.cpuids[i].input[0] == 1 )
+d->arch.cpuids[i].ecx &= ~X86_FEATURE_VMX;
+}
+
+rc = setup_permissions(d);
+if ( rc )
+{
+panic("Unable to setup Dom0 permissions: %d\n", rc);
+return rc;
+}
+
+update_domain_wallclock_time(d);
+
+return 0;
+}
+
 static int __init construct_dom0_hvm(struct domain *d, const module_t *image,
  unsigned long image_headroom,
  module_t *initrd,
@@ -2049,6 +2145,13 @@ static int __init construct_dom0_hvm(struct domain *d, 
const module_t *image,
 return rc;
 }
 
+rc = hvm_setup_cpus(d, entry, start_info);
+if ( rc )
+{
+printk("Failed to setup Dom0 CPUs: %d\n", rc);
+return rc;
+}
+
 return 0;
 }
 
-- 
2.7.4 (Apple Git-66)


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

[Xen-devel] [PATCH v2 14/30] xen/mm: add a ceil sufix to current page calculation routine

[Roger Pau Monne]

... and introduce a floor variant.

Signed-off-by: Roger Pau Monné 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Boris Ostrovsky 
Cc: Suravee Suthikulpanit 
Cc: Konrad Rzeszutek Wilk 
---
 xen/arch/arm/domain.c|  2 +-
 xen/arch/arm/domain_build.c  | 16 +---
 xen/arch/arm/kernel.c|  4 ++--
 xen/arch/arm/percpu.c|  3 ++-
 xen/arch/x86/domain.c|  2 +-
 xen/arch/x86/domain_build.c  |  4 ++--
 xen/arch/x86/hvm/svm/nestedsvm.c |  8 
 xen/arch/x86/hvm/svm/vmcb.c  |  5 +++--
 xen/arch/x86/percpu.c|  3 ++-
 xen/arch/x86/smpboot.c   |  4 ++--
 xen/common/kexec.c   |  2 +-
 xen/common/page_alloc.c  |  2 +-
 xen/common/tmem_xen.c|  2 +-
 xen/common/xmalloc_tlsf.c|  6 +++---
 xen/drivers/char/console.c   |  6 +++---
 xen/drivers/char/serial.c|  2 +-
 xen/drivers/passthrough/amd/iommu_init.c | 17 +
 xen/drivers/passthrough/pci.c|  2 +-
 xen/include/asm-x86/flushtlb.h   |  2 +-
 xen/include/xen/mm.h | 12 +++-
 20 files changed, 56 insertions(+), 48 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 20bb2ba..1f6b0a4 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -661,7 +661,7 @@ void arch_domain_destroy(struct domain *d)
 free_xenheap_page(d->shared_info);
 #ifdef CONFIG_ACPI
 free_xenheap_pages(d->arch.efi_acpi_table,
-   get_order_from_bytes(d->arch.efi_acpi_len));
+   get_order_from_bytes_ceil(d->arch.efi_acpi_len));
 #endif
 domain_io_free(d);
 }
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 35ab08d..cabe030 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -73,14 +73,8 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
 
 static unsigned int get_11_allocation_size(paddr_t size)
 {
-/*
- * get_order_from_bytes returns the order greater than or equal to
- * the given size, but we need less than or equal. Adding one to
- * the size pushes an evenly aligned size into the next order, so
- * we can then unconditionally subtract 1 from the order which is
- * returned.
- */
-return get_order_from_bytes(size + 1) - 1;
+
+return get_order_from_bytes_floor(size);
 }
 
 /*
@@ -238,8 +232,8 @@ fail:
 static void allocate_memory(struct domain *d, struct kernel_info *kinfo)
 {
 const unsigned int min_low_order =
-get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
-const unsigned int min_order = get_order_from_bytes(MB(4));
+get_order_from_bytes_ceil(min_t(paddr_t, dom0_mem, MB(128)));
+const unsigned int min_order = get_order_from_bytes_ceil(MB(4));
 struct page_info *pg;
 unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
 int i;
@@ -1828,7 +1822,7 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( rc != 0 )
 return rc;
 
-order = get_order_from_bytes(d->arch.efi_acpi_len);
+order = get_order_from_bytes_ceil(d->arch.efi_acpi_len);
 d->arch.efi_acpi_table = alloc_xenheap_pages(order, 0);
 if ( d->arch.efi_acpi_table == NULL )
 {
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 3f6cce3..0d9986b 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -291,7 +291,7 @@ static __init int kernel_decompress(struct bootmodule *mod)
 return -EFAULT;
 
 output_size = output_length(input, size);
-kernel_order_out = get_order_from_bytes(output_size);
+kernel_order_out = get_order_from_bytes_ceil(output_size);
 pages = alloc_domheap_pages(NULL, kernel_order_out, 0);
 if ( pages == NULL )
 {
@@ -463,7 +463,7 @@ static int kernel_elf_probe(struct kernel_info *info,
 
 memset(>elf.elf, 0, sizeof(info->elf.elf));
 
-info->elf.kernel_order = get_order_from_bytes(size);
+info->elf.kernel_order = get_order_from_bytes_ceil(size);
 info->elf.kernel_img = alloc_xenheap_pages(info->elf.kernel_order, 0);
 if ( info->elf.kernel_img == NULL )
 panic("Cannot allocate temporary buffer for kernel");
diff --git a/xen/arch/arm/percpu.c b/xen/arch/arm/percpu.c
index e545024..954e92f 100644
--- a/xen/arch/arm/percpu.c
+++ b/xen/arch/arm/percpu.c
@@ -7,7 +7,8 @@
 
 unsigned long __per_cpu_offset[NR_CPUS];
 #define INVALID_PERCPU_AREA (-(long)__per_cpu_start)
-#define PERCPU_ORDER (get_order_from_bytes(__per_cpu_data_end-__per_cpu_start))
+#define PERCPU_ORDER \
+

[Xen-devel] [PATCH v2 01/30] xen/x86: move setup of the VM86 TSS to the domain builder

[Roger Pau Monne]

This is also required for PVHv2 guests if they want to use real-mode, and
hvmloader is not executed for those kind of guests.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/firmware/hvmloader/hvmloader.c | 17 -
 tools/libxc/include/xc_dom.h |  2 +-
 tools/libxc/xc_dom_x86.c | 16 
 3 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index bbd4e34..9eabbd8 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -176,21 +176,6 @@ static void cmos_write_memory_size(void)
 cmos_outb(0x35, (uint8_t)( alt_mem >> 8));
 }
 
-/*
- * Set up an empty TSS area for virtual 8086 mode to use. 
- * The only important thing is that it musn't have any bits set 
- * in the interrupt redirection bitmap, so all zeros will do.
- */
-static void init_vm86_tss(void)
-{
-void *tss;
-
-tss = mem_alloc(128, 128);
-memset(tss, 0, 128);
-hvm_param_set(HVM_PARAM_VM86_TSS, virt_to_phys(tss));
-printf("vm86 TSS at %08lx\n", virt_to_phys(tss));
-}
-
 static void apic_setup(void)
 {
 /*
@@ -398,8 +383,6 @@ int main(void)
 hvm_param_set(HVM_PARAM_ACPI_IOPORTS_LOCATION, 1);
 }
 
-init_vm86_tss();
-
 cmos_write_memory_size();
 
 printf("BIOS map:\n");
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index de7dca9..e1cfaad 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -20,7 +20,7 @@
 #include 
 
 #define INVALID_PFN ((xen_pfn_t)-1)
-#define X86_HVM_NR_SPECIAL_PAGES8
+#define X86_HVM_NR_SPECIAL_PAGES9
 #define X86_HVM_END_SPECIAL_REGION  0xff000u
 
 /* --- typedefs and structs  */
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 0eab8a7..1676a3c 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -59,6 +59,7 @@
 #define SPECIALPAGE_IOREQ5
 #define SPECIALPAGE_IDENT_PT 6
 #define SPECIALPAGE_CONSOLE  7
+#define SPECIALPAGE_VM86TSS  8
 #define special_pfn(x) \
 (X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES + (x))
 
@@ -590,6 +591,7 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
 {
 unsigned long i;
 uint32_t *ident_pt, domid = dom->guest_domid;
+void *tss;
 int rc;
 xen_pfn_t special_array[X86_HVM_NR_SPECIAL_PAGES];
 xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
@@ -699,6 +701,20 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
 xc_hvm_param_set(xch, domid, HVM_PARAM_IDENT_PT,
  special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT);
 
+/*
+ * Set up an empty TSS area for virtual 8086 mode to use.
+ * The only important thing is that it musn't have any bits set
+ * in the interrupt redirection bitmap, so all zeros will do.
+ */
+if ( (tss = xc_map_foreign_range(
+  xch, domid, PAGE_SIZE, PROT_READ | PROT_WRITE,
+  special_pfn(SPECIALPAGE_VM86TSS))) == NULL )
+goto error_out;
+memset(tss, 0, 128);
+munmap(tss, PAGE_SIZE);
+xc_hvm_param_set(xch, domid, HVM_PARAM_VM86_TSS,
+ special_pfn(SPECIALPAGE_VM86TSS) << PAGE_SHIFT);
+
 dom->console_pfn = special_pfn(SPECIALPAGE_CONSOLE);
 dom->xenstore_pfn = special_pfn(SPECIALPAGE_XENSTORE);
 dom->parms.virt_hypercall = -1;
-- 
2.7.4 (Apple Git-66)


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

[Xen-devel] [PATCH v2 05/30] xen/x86: assert that local_events_need_delivery is not called by the idle domain

[Roger Pau Monne]

It doesn't make sense since the idle domain doesn't receive any events.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/include/asm-x86/event.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/include/asm-x86/event.h b/xen/include/asm-x86/event.h
index a82062e..d589d6f 100644
--- a/xen/include/asm-x86/event.h
+++ b/xen/include/asm-x86/event.h
@@ -23,6 +23,9 @@ int hvm_local_events_need_delivery(struct vcpu *v);
 static inline int local_events_need_delivery(void)
 {
 struct vcpu *v = current;
+
+ASSERT(!is_idle_vcpu(v));
+
 return (has_hvm_container_vcpu(v) ? hvm_local_events_need_delivery(v) :
 (vcpu_info(v, evtchn_upcall_pending) &&
  !vcpu_info(v, evtchn_upcall_mask)));
-- 
2.7.4 (Apple Git-66)


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

[Xen-devel] [PATCH v2 13/30] xen: introduce a new format specifier to print sizes in human-readable form

[Roger Pau Monne]

Introduce a new %pB format specifier to print sizes (in bytes) in a
human-readable form.

Signed-off-by: Roger Pau Monné 
---
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 
---
 docs/misc/printk-formats.txt |  5 +
 xen/common/vsprintf.c| 15 +++
 2 files changed, 20 insertions(+)

diff --git a/docs/misc/printk-formats.txt b/docs/misc/printk-formats.txt
index 525108f..0ee3504 100644
--- a/docs/misc/printk-formats.txt
+++ b/docs/misc/printk-formats.txt
@@ -30,3 +30,8 @@ Domain and vCPU information:
 
%pv Domain and vCPU ID from a 'struct vcpu *' (printed as
"dv")
+
+Size in human readable form:
+
+   %pZ Size in human-readable form (input size must be in bytes).
+ e.g.  24MB
diff --git a/xen/common/vsprintf.c b/xen/common/vsprintf.c
index f92fb67..2dadaec 100644
--- a/xen/common/vsprintf.c
+++ b/xen/common/vsprintf.c
@@ -386,6 +386,21 @@ static char *pointer(char *str, char *end, const char 
**fmt_ptr,
 *str = 'v';
 return number(str + 1, end, v->vcpu_id, 10, -1, -1, 0);
 }
+case 'Z':
+{
+static const char units[][3] = {"B", "KB", "MB", "GB", "TB"};
+size_t size = (size_t)arg;
+int i = 0;
+
+/* Advance parents fmt string, as we have consumed 'B' */
+++*fmt_ptr;
+
+while ( ++i < sizeof(units) && size >= 1024 )
+size >>= 10; /* size /= 1024 */
+
+str = number(str, end, size, 10, -1, -1, 0);
+return string(str, end, units[i-1], -1, -1, 0);
+}
 }
 
 if ( field_width == -1 )
-- 
2.7.4 (Apple Git-66)


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

[Xen-devel] [PATCH v2 10/30] xen/x86: allow the emulated APICs to be enbled for the hardware domain

[Roger Pau Monne]

Allow the use of both the emulated local APIC and IO APIC for the hardware
domain.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since RFC:
 - Move the emulation flags check to a separate helper.
---
 xen/arch/x86/domain.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 3c4b094..332e7f0 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -509,6 +509,29 @@ void vcpu_destroy(struct vcpu *v)
 xfree(v->arch.pv_vcpu.trap_ctxt);
 }
 
+static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
+{
+
+if ( is_hvm_domain(d) )
+{
+if ( is_hardware_domain(d) &&
+ emflags != (XEN_X86_EMU_PIT|XEN_X86_EMU_LAPIC|XEN_X86_EMU_IOAPIC))
+return false;
+if ( !is_hardware_domain(d) &&
+ emflags != XEN_X86_EMU_ALL && emflags != 0 )
+return false;
+}
+else
+{
+/* PV or classic PVH. */
+if ( is_hardware_domain(d) && emflags != XEN_X86_EMU_PIT )
+return false;
+if ( !is_hardware_domain(d) && emflags != 0 )
+return false;
+}
+return true;
+}
+
 int arch_domain_create(struct domain *d, unsigned int domcr_flags,
struct xen_arch_domainconfig *config)
 {
@@ -553,9 +576,8 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 }
 if ( is_hardware_domain(d) )
 config->emulation_flags |= XEN_X86_EMU_PIT;
-if ( config->emulation_flags != 0 &&
- (config->emulation_flags !=
-  (is_hvm_domain(d) ? XEN_X86_EMU_ALL : XEN_X86_EMU_PIT)) )
+
+if ( !emulation_flags_ok(d, config->emulation_flags) )
 {
 printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation "
"with the current selection of emulators: %#x\n",
-- 
2.7.4 (Apple Git-66)


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

[Xen-devel] [PATCH v2 07/30] xen/x86: split the setup of Dom0 permissions to a function

[Roger Pau Monne]

So that it can also be used by the PVH-specific domain builder. This is just
code motion, it should not introduce any functional change.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/domain_build.c | 164 +++-
 1 file changed, 86 insertions(+), 78 deletions(-)

diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index 04d6cb0..ffd0521 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -869,6 +869,89 @@ static __init void setup_pv_physmap(struct domain *d, 
unsigned long pgtbl_pfn,
 unmap_domain_page(l4start);
 }
 
+static int __init setup_permissions(struct domain *d)
+{
+unsigned long mfn;
+int i, rc = 0;
+
+/* The hardware domain is initially permitted full I/O capabilities. */
+rc |= ioports_permit_access(d, 0, 0x);
+rc |= iomem_permit_access(d, 0UL, (1UL << (paddr_bits - PAGE_SHIFT)) - 1);
+rc |= irqs_permit_access(d, 1, nr_irqs_gsi - 1);
+
+/*
+ * Modify I/O port access permissions.
+ */
+/* Master Interrupt Controller (PIC). */
+rc |= ioports_deny_access(d, 0x20, 0x21);
+/* Slave Interrupt Controller (PIC). */
+rc |= ioports_deny_access(d, 0xA0, 0xA1);
+/* Interval Timer (PIT). */
+rc |= ioports_deny_access(d, 0x40, 0x43);
+/* PIT Channel 2 / PC Speaker Control. */
+rc |= ioports_deny_access(d, 0x61, 0x61);
+/* ACPI PM Timer. */
+if ( pmtmr_ioport )
+rc |= ioports_deny_access(d, pmtmr_ioport, pmtmr_ioport + 3);
+/* PCI configuration space (NB. 0xcf8 has special treatment). */
+rc |= ioports_deny_access(d, 0xcfc, 0xcff);
+/* Command-line I/O ranges. */
+process_dom0_ioports_disable(d);
+
+/*
+ * Modify I/O memory access permissions.
+ */
+/* Local APIC. */
+if ( mp_lapic_addr != 0 )
+{
+mfn = paddr_to_pfn(mp_lapic_addr);
+rc |= iomem_deny_access(d, mfn, mfn);
+}
+/* I/O APICs. */
+for ( i = 0; i < nr_ioapics; i++ )
+{
+mfn = paddr_to_pfn(mp_ioapics[i].mpc_apicaddr);
+if ( !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
+rc |= iomem_deny_access(d, mfn, mfn);
+}
+/* MSI range. */
+rc |= iomem_deny_access(d, paddr_to_pfn(MSI_ADDR_BASE_LO),
+paddr_to_pfn(MSI_ADDR_BASE_LO +
+ MSI_ADDR_DEST_ID_MASK));
+/* HyperTransport range. */
+if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+rc |= iomem_deny_access(d, paddr_to_pfn(0xfdULL << 32),
+paddr_to_pfn((1ULL << 40) - 1));
+
+/* Remove access to E820_UNUSABLE I/O regions above 1MB. */
+for ( i = 0; i < e820.nr_map; i++ )
+{
+unsigned long sfn, efn;
+sfn = max_t(unsigned long, paddr_to_pfn(e820.map[i].addr), 0x100ul);
+efn = paddr_to_pfn(e820.map[i].addr + e820.map[i].size - 1);
+if ( (e820.map[i].type == E820_UNUSABLE) &&
+ (e820.map[i].size != 0) &&
+ (sfn <= efn) )
+rc |= iomem_deny_access(d, sfn, efn);
+}
+
+/* Prevent access to HPET */
+if ( hpet_address )
+{
+u8 prot_flags = hpet_flags & ACPI_HPET_PAGE_PROTECT_MASK;
+
+mfn = paddr_to_pfn(hpet_address);
+if ( prot_flags == ACPI_HPET_PAGE_PROTECT4 )
+rc |= iomem_deny_access(d, mfn, mfn);
+else if ( prot_flags == ACPI_HPET_PAGE_PROTECT64 )
+rc |= iomem_deny_access(d, mfn, mfn + 15);
+else if ( ro_hpet )
+rc |= rangeset_add_singleton(mmio_ro_ranges, mfn);
+}
+
+return rc;
+}
+
 int __init construct_dom0(
 struct domain *d,
 const module_t *image, unsigned long image_headroom,
@@ -1539,84 +1622,9 @@ int __init construct_dom0(
 if ( test_bit(XENFEAT_supervisor_mode_kernel, parms.f_required) )
 panic("Dom0 requires supervisor-mode execution");
 
-rc = 0;
-
-/* The hardware domain is initially permitted full I/O capabilities. */
-rc |= ioports_permit_access(d, 0, 0x);
-rc |= iomem_permit_access(d, 0UL, (1UL << (paddr_bits - PAGE_SHIFT)) - 1);
-rc |= irqs_permit_access(d, 1, nr_irqs_gsi - 1);
-
-/*
- * Modify I/O port access permissions.
- */
-/* Master Interrupt Controller (PIC). */
-rc |= ioports_deny_access(d, 0x20, 0x21);
-/* Slave Interrupt Controller (PIC). */
-rc |= ioports_deny_access(d, 0xA0, 0xA1);
-/* Interval Timer (PIT). */
-rc |= ioports_deny_access(d, 0x40, 0x43);
-/* PIT Channel 2 / PC Speaker Control. */
-rc |= ioports_deny_access(d, 0x61, 0x61);
-/* ACPI PM Timer. */
-if ( pmtmr_ioport )
-rc |= ioports_deny_access(d, pmtmr_ioport, pmtmr_ioport + 3);
-/* PCI configuration space (NB. 0xcf8 has special treatment). */
-rc |= ioports_deny_access(d, 0xcfc, 0xcff);
-/* Command-line I/O ranges. */
-

[Xen-devel] [PATCH v2 02/30] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests

[Roger Pau Monne]

On PVHv2 guests we explicitly want to use native methods for routing
interrupts.

Introduce a new XEN_X86_EMU_USE_PIRQ to notify Xen whether a HVM guest can
route physical interrupts (even from emulated devices) over event channels.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/hvm.c| 23 +++
 xen/arch/x86/physdev.c|  5 +++--
 xen/common/kernel.c   |  3 ++-
 xen/include/public/arch-x86/xen.h |  4 +++-
 4 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 7bad845..a291f82 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4117,6 +4117,8 @@ static long hvm_memory_op(int cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 
 static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
+struct domain *d = current->domain;
+
 switch ( cmd )
 {
 default:
@@ -4128,7 +4130,9 @@ static long hvm_physdev_op(int cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 case PHYSDEVOP_eoi:
 case PHYSDEVOP_irq_status_query:
 case PHYSDEVOP_get_free_pirq:
-return do_physdev_op(cmd, arg);
+return ((d->arch.emulation_flags & XEN_X86_EMU_USE_PIRQ) ||
+   is_pvh_vcpu(current)) ?
+do_physdev_op(cmd, arg) : -ENOSYS;
 }
 }
 
@@ -4161,17 +4165,20 @@ static long hvm_memory_op_compat32(int cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 static long hvm_physdev_op_compat32(
 int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
+struct domain *d = current->domain;
+
 switch ( cmd )
 {
-case PHYSDEVOP_map_pirq:
-case PHYSDEVOP_unmap_pirq:
-case PHYSDEVOP_eoi:
-case PHYSDEVOP_irq_status_query:
-case PHYSDEVOP_get_free_pirq:
-return compat_physdev_op(cmd, arg);
+case PHYSDEVOP_map_pirq:
+case PHYSDEVOP_unmap_pirq:
+case PHYSDEVOP_eoi:
+case PHYSDEVOP_irq_status_query:
+case PHYSDEVOP_get_free_pirq:
+return (d->arch.emulation_flags & XEN_X86_EMU_USE_PIRQ) ?
+compat_physdev_op(cmd, arg) : -ENOSYS;
 break;
 default:
-return -ENOSYS;
+return -ENOSYS;
 break;
 }
 }
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 5a49796..0bea6e1 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -94,7 +94,8 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int 
*pirq_p,
 int pirq, irq, ret = 0;
 void *map_data = NULL;
 
-if ( domid == DOMID_SELF && is_hvm_domain(d) )
+if ( domid == DOMID_SELF && is_hvm_domain(d) &&
+ (d->arch.emulation_flags & XEN_X86_EMU_USE_PIRQ) )
 {
 /*
  * Only makes sense for vector-based callback, else HVM-IRQ logic
@@ -265,7 +266,7 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
 if ( ret )
 goto free_domain;
 
-if ( is_hvm_domain(d) )
+if ( is_hvm_domain(d) && (d->arch.emulation_flags & XEN_X86_EMU_USE_PIRQ) )
 {
 spin_lock(>event_lock);
 if ( domain_pirq_to_emuirq(d, pirq) != IRQ_UNBOUND )
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index d0edb13..a82f55f 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -332,7 +332,8 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 case guest_type_hvm:
 fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
  (1U << XENFEAT_hvm_callback_vector) |
- (1U << XENFEAT_hvm_pirqs);
+ ((d->arch.emulation_flags & XEN_X86_EMU_USE_PIRQ) 
?
+ (1U << XENFEAT_hvm_pirqs) : 0);
 break;
 }
 #endif
diff --git a/xen/include/public/arch-x86/xen.h 
b/xen/include/public/arch-x86/xen.h
index cdd93c1..da6f4f2 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -283,12 +283,14 @@ struct xen_arch_domainconfig {
 #define XEN_X86_EMU_IOMMU   (1U<<_XEN_X86_EMU_IOMMU)
 #define _XEN_X86_EMU_PIT8
 #define XEN_X86_EMU_PIT (1U<<_XEN_X86_EMU_PIT)
+#define _XEN_X86_EMU_USE_PIRQ   9
+#define XEN_X86_EMU_USE_PIRQ(1U<<_XEN_X86_EMU_USE_PIRQ)
 
 #define XEN_X86_EMU_ALL (XEN_X86_EMU_LAPIC | XEN_X86_EMU_HPET |  \
  XEN_X86_EMU_PM | XEN_X86_EMU_RTC |  \
  XEN_X86_EMU_IOAPIC | XEN_X86_EMU_PIC |  \
  XEN_X86_EMU_VGA | XEN_X86_EMU_IOMMU |   \
- XEN_X86_EMU_PIT)
+ XEN_X86_EMU_PIT | XEN_X86_EMU_USE_PIRQ)
 uint32_t emulation_flags;
 };
 #endif
-- 
2.7.4 (Apple Git-66)


___
Xen-devel mailing list
Xen-devel@lists.xen.org

[Xen-devel] [PATCH v2 00/30] PVHv2 Dom0

[Roger Pau Monne]

Hello,

This is the first "complete" PVHv2 implementation in the sense that
it has feature parity with classic PVH Dom0. It is still very experimental,
but I've managed to boot it on all Intel boxes I've tried (OK, only 3 so far).
I've also tried on an AMD box, but sadly the ACPI tables there didn't contain
any RMRR regions and the IOMMU started spitting a bunch of page faults caused
by devices trying to access memory regions marked as reserved in the e820.

Here is the list of most relevant changes compared to classic PVH or PV:

 - An emulated local APIC (for each vCPU) and IO APIC is provided to Dom0.
 - The MADT has been replaced in order to reflect the real topology seen by
   the guest. This needs a little bit more of work so that the new MADT is
   not placed over the old one.
 - BARs of PCI devices are automatically mapped by Xen into Dom0 memory space.
   Currently there's no support for changing the position of the BARs, and Xen
   will just crash the domain if this is attempted.
 - Interrupts from physical devices are configured and routed using native
   mechanism, PIRQs are not available to this PVH Dom0 implementation at all.
   Xen will automatically detect the features of the physical devices available
   to Dom0, and will setup traps/handlers in order to intercept all relevant
   configuration accesses.
 - Access to PCIe regions is also trapped by Xen, so configuration can be done
   using the IO ports or the memory mapped configuration areas, as supported
   by each device.
 - Some ACPI tables are zapped (it's signature is inverted) to prevent Dom0
   from poking at them, those are: HPET, SLIT, SRAT, MPST and PMTT.

I know this series is quite big, but I think some of the initial changes can
go in as bugfixes, which would help me reduce the size.

Thanks, Roger.

Changes in this series:
 docs/misc/printk-formats.txt|5 +
 docs/misc/xen-command-line.markdown |   15 +
 tools/firmware/hvmloader/hvmloader.c|   17 -
 tools/libxc/include/xc_dom.h|2 +-
 tools/libxc/xc_dom_x86.c|   16 +
 xen/arch/arm/domain.c   |2 +-
 xen/arch/arm/domain_build.c |   16 +-
 xen/arch/arm/kernel.c   |4 +-
 xen/arch/arm/percpu.c   |3 +-
 xen/arch/x86/domain.c   |   30 +-
 xen/arch/x86/domain_build.c | 1003 +++---
 xen/arch/x86/e820.c |2 +-
 xen/arch/x86/hvm/hvm.c  |   26 +-
 xen/arch/x86/hvm/io.c   |  921 +++-
 xen/arch/x86/hvm/ioreq.c|   11 +
 xen/arch/x86/hvm/irq.c  |9 +
 xen/arch/x86/hvm/svm/nestedsvm.c|8 +-
 xen/arch/x86/hvm/svm/vmcb.c |5 +-
 xen/arch/x86/hvm/vioapic.c  |   28 +-
 xen/arch/x86/hvm/vmsi.c | 1036 +++
 xen/arch/x86/mm/hap/hap.c   |   22 +-
 xen/arch/x86/mm/p2m.c   |   88 +--
 xen/arch/x86/mm/paging.c|   16 +
 xen/arch/x86/mm/shadow/common.c |   10 +-
 xen/arch/x86/percpu.c   |3 +-
 xen/arch/x86/physdev.c  |9 +-
 xen/arch/x86/setup.c|   11 +
 xen/arch/x86/smpboot.c  |4 +-
 xen/arch/x86/traps.c|   39 -
 xen/common/kernel.c |3 +-
 xen/common/kexec.c  |2 +-
 xen/common/page_alloc.c |2 +-
 xen/common/tmem_xen.c   |2 +-
 xen/common/vsprintf.c   |   15 +
 xen/common/xmalloc_tlsf.c   |6 +-
 xen/drivers/char/console.c  |6 +-
 xen/drivers/char/serial.c   |2 +-
 xen/drivers/passthrough/amd/iommu_init.c|   17 +-
 xen/drivers/passthrough/amd/pci_amd_iommu.c |3 +-
 xen/drivers/passthrough/io.c|  148 +++-
 xen/drivers/passthrough/pci.c   |  438 ++-
 xen/drivers/passthrough/vtd/iommu.c |   23 +-
 xen/include/asm-x86/domain.h|   12 +-
 xen/include/asm-x86/e820.h  |1 +
 xen/include/asm-x86/event.h |3 +
 xen/include/asm-x86/flushtlb.h  |2 +-
 xen/include/asm-x86/hap.h   |2 +-
 xen/include/asm-x86/hvm/domain.h|4 +
 xen/include/asm-x86/hvm/io.h|  251 +++
 xen/include/asm-x86/hvm/ioreq.h |1 +
 xen/include/asm-x86/irq.h   |5 +
 xen/include/asm-x86/msi.h   |   34 +
 xen/include/asm-x86/p2m.h   |5 -
 xen/include/asm-x86/paging.h|7 +
 xen/include/asm-x86/shadow.h|8 +
 xen/include/public/arch-x86/xen.h   |4 +-
 

[Xen-devel] [PATCH v2 03/30] xen/x86: fix parameters and return value of *_set_allocation functions

[Roger Pau Monne]

Return should be an int, and the number of pages should be an unsigned long.

Signed-off-by: Roger Pau Monné 
---
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Tim Deegan 
---
 xen/arch/x86/mm/hap/hap.c   |  6 +++---
 xen/arch/x86/mm/shadow/common.c |  7 +++
 xen/include/asm-x86/domain.h| 12 ++--
 3 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 3218fa2..b6d2c61 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -325,7 +325,7 @@ static void hap_free_p2m_page(struct domain *d, struct 
page_info *pg)
 static unsigned int
 hap_get_allocation(struct domain *d)
 {
-unsigned int pg = d->arch.paging.hap.total_pages
+unsigned long pg = d->arch.paging.hap.total_pages
 + d->arch.paging.hap.p2m_pages;
 
 return ((pg >> (20 - PAGE_SHIFT))
@@ -334,8 +334,8 @@ hap_get_allocation(struct domain *d)
 
 /* Set the pool of pages to the required number of pages.
  * Returns 0 for success, non-zero for failure. */
-static unsigned int
-hap_set_allocation(struct domain *d, unsigned int pages, int *preempted)
+static int
+hap_set_allocation(struct domain *d, unsigned long pages, int *preempted)
 {
 struct page_info *pg;
 
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 21607bf..d3cc2cc 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1613,9 +1613,8 @@ shadow_free_p2m_page(struct domain *d, struct page_info 
*pg)
  * Input will be rounded up to at least shadow_min_acceptable_pages(),
  * plus space for the p2m table.
  * Returns 0 for success, non-zero for failure. */
-static unsigned int sh_set_allocation(struct domain *d,
-  unsigned int pages,
-  int *preempted)
+static int sh_set_allocation(struct domain *d, unsigned long pages,
+ int *preempted)
 {
 struct page_info *sp;
 unsigned int lower_bound;
@@ -1692,7 +1691,7 @@ static unsigned int sh_set_allocation(struct domain *d,
 /* Return the size of the shadow pool, rounded up to the nearest MB */
 static unsigned int shadow_get_allocation(struct domain *d)
 {
-unsigned int pg = d->arch.paging.shadow.total_pages
+unsigned long pg = d->arch.paging.shadow.total_pages
 + d->arch.paging.shadow.p2m_pages;
 return ((pg >> (20 - PAGE_SHIFT))
 + ((pg & ((1 << (20 - PAGE_SHIFT)) - 1)) ? 1 : 0));
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 5807a1f..11ac2a5 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -93,9 +93,9 @@ struct shadow_domain {
 
 /* Memory allocation */
 struct page_list_head freelist;
-unsigned int  total_pages;  /* number of pages allocated */
-unsigned int  free_pages;   /* number of pages on freelists */
-unsigned int  p2m_pages;/* number of pages allocates to p2m */
+unsigned long  total_pages;  /* number of pages allocated */
+unsigned long  free_pages;   /* number of pages on freelists */
+unsigned long  p2m_pages;/* number of pages allocates to p2m */
 
 /* 1-to-1 map for use when HVM vcpus have paging disabled */
 pagetable_t unpaged_pagetable;
@@ -155,9 +155,9 @@ struct shadow_vcpu {
 //
 struct hap_domain {
 struct page_list_head freelist;
-unsigned int  total_pages;  /* number of pages allocated */
-unsigned int  free_pages;   /* number of pages on freelists */
-unsigned int  p2m_pages;/* number of pages allocates to p2m */
+unsigned long  total_pages;  /* number of pages allocated */
+unsigned long  free_pages;   /* number of pages on freelists */
+unsigned long  p2m_pages;/* number of pages allocates to p2m */
 };
 
 //
-- 
2.7.4 (Apple Git-66)


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

Re: [Xen-devel] [PATCH] minios: make mini-os_app.o depend on included xen libraries

[Wei Liu]

On Tue, Sep 27, 2016 at 02:06:24PM +0200, Juergen Gross wrote:
> When building Mini-OS with an app which is using xen libraries like
> libxenguest.a let mini-os_app.o depend on the library binaries as it
> is statically linked with them.
> 
> While at it add "-T" before app.lds for linking mini-os_app.o to avoid
> a linker warning.
> 
> Signed-off-by: Juergen Gross 
> ---
>  Makefile | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 81b936f..1d2324c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -125,11 +125,18 @@ OBJS := $(filter-out $(OBJ_DIR)/lwip%.o $(LWO), $(OBJS))
>  ifeq ($(libc),y)
>  ifeq ($(CONFIG_XC),y)
>  APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/toollog 
> -whole-archive -lxentoollog -no-whole-archive
> +LIBS += 
> $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/toollog/libxentoollog.a

I don't follow. Why is the original APP_LDLIBS not enough?

The new dependency doesn't seem to generate any new rules. What do I
miss?

Wei.

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

Re: [Xen-devel] [PATCH 09/17] SVM: use generic instruction decoding

[Andrew Cooper]

On 27/09/16 14:56, Jan Beulich wrote:
 On 27.09.16 at 15:42,  wrote:
>> On 15/09/16 07:55, Jan Beulich wrote:
>> On 14.09.16 at 19:56,  wrote:
 On 08/09/16 14:14, Jan Beulich wrote:
>  int __get_instruction_length_from_list(struct vcpu *v,
>  const enum instruction_index *list, unsigned int list_count)
>  {
>  struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
> -unsigned int i, j, inst_len = 0;
> -enum instruction_index instr = 0;
> -u8 buf[MAX_INST_LEN];
> -const u8 *opcode = NULL;
> -unsigned long fetch_addr, fetch_limit;
> -unsigned int fetch_len, max_len;
> +struct hvm_emulate_ctxt ctxt;
> +struct x86_emulate_state *state;
> +unsigned int inst_len, j, modrm_rm, modrm_reg;
> +int modrm_mod;
>  
> +#ifdef NDEBUG
 Presumably this is just for your testing?
>>> No, I actually meant it to stay that way. Along the lines of the extra
>>> debugging code we have in map_domain_page().
>> I was never very happy with the older version of this debugging.  Surely
>> in a case like this, we should use the intercept information when
>> available, and check it against the emulator in a debug build.
>>
>> That way, we don't entirely change the underlying logic in this function
>> between a debug and non debug build.
> But that is exactly what the code is doing:
>
> #ifndef NDEBUG
> if ( vmcb->exitcode == VMEXIT_IOIO )
> j = vmcb->exitinfo2 - vmcb->rip;
> else
> j = svm_nextrip_insn_length(v);
> if ( j && j != inst_len )
> {
> gprintk(XENLOG_WARNING, "insn-len[%02x]=%u (exp %u)\n",
> ctxt.ctxt.opcode, inst_len, j);
> return j;
> }
> #endif
>
> I.e. in case of a mismatch we use the data from hardware, plus a
> message gets logged. In case of a match we further exercise the
> opcode lookup logic, which non-debug builds would never hit on
> capable hardware.

Ah yes - I see now.  The split between #ifdef NDEBUG and #ifndef NDEBUG
is the confusing factor.

~Andrew

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

Re: [Xen-devel] [PATCH v7] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Wei Liu]

On Tue, Sep 27, 2016 at 10:46:18AM -0400, Boris Ostrovsky wrote:
> Some code (specifically, introduced by commit 801d469ad ("[HVM] ACPI
> support patch 3 of 4: ACPI _PRT table.")) has only been licensed under
> GPLv2. We want to prevent this code from showing up in non-GPL
> binaries which might become possible after we make ACPI builder code
> available to users other than hvmloader.
> 
> There are two pieces that we need to be careful about:
> (1) A small chunk of code in dsdt.asl that implements _PIC method
> (2) A chunk of ASL generator in mk_dsdt.c that describes with PCI
> interrupt routing.
> 
> This code will now be generated by a GPL-only script which will be
> invoked only when ACPI builder's Makefile is called with GPL variable
> set.
> 
> We also strip license header from generated ASL files to prevent
> inadverent use of those files with incorrect license.
> 
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] xen/arm: Bring (c) headers in line with COPYING file

[Konrad Rzeszutek Wilk]

On Tue, Sep 27, 2016 at 03:16:50PM +0100, Lars Kurth wrote:
> The COPYING file in the main xen.git tree applies to most files in the
> xen tree, including the ones in this patch. It states:
> 
> [1]
>  * Note that the only valid version of the GPL as far as the files in
>  * this repository are concerned is _this_ particular version of the
>  * license (i.e., *only* v2, not v2.2 or v3.x or whatever), unless
>  * explicitly otherwise stated.
> 
> We do not have any GPLv3+ files in the Xen source, with the exception of
> Bison generated files, which have a Bison exception and are thus safe.
> 
> However, there are a minority of files that are specifically GPL-2.0+,
> stating
> 
> [2]
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License as published by
>  * the Free Software Foundation; either version 2 of the License, or
>  * (at your option) any later version.
> 
> I could not find a single instance in our code base, which states
> 
> [3]
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License as published by
>  * the Free Software Foundation; either version 2 of the License, or
>  * any later version.
> 
> It is impossible to know, what the intention of the contributor was
> when a (c) header of form [2] was used. There are two possibilities
> a) The contributor chose [2] intentionally
> b) The contributor copied a header file from elsewhere (e.g. the FSF)
>without understanding all the implications
> The latter is more likely, which is also why we recently introduced
> the CONTRIBUTING file with correct (c) headers
> 
> In all cases in our code base, code with a (c) header of form [2] is
> linked against pure GPLv2 files, which in practice means that the
> resulting binaries are always GPLv2. In addition, [1] clarifies this.
> 
> [2] allows the Xen Project to specifically choose GPLv2 and to modify
> the (c) headers to that effect without express permission of the (c)
> holders. This proposed patch makes use of this property. It also gives

This patch hinges on the 'allow' part. That is that the Xen Project community
can choose to modify its headers without express permission of the holders
on removing the '(at your option)' statement from the license headers.
Now it is not a relicense, nor changing the license but clarifying the semantics
of how the code can be used in future.

Later in the description (see 'annotated' tags) are saying the same
thing - that the community can decide this based on 'common practices'.

Could you please point me to the 'common practices' and the 'allow' property?
I would naively assume that this had happend in the past with other projects?
Or perhaps the GPL had helpfully put a statement on their website giving
clarification on this?

Thanks!

> anyone the right, to copy files from the Xen Project into a another
> codebase and to explicitly choose GPLv3 or a later version without
> obtaining the permission of the (c) holders.
> 
> When large vendors go through their internal approval process to
> decide whether to allow their employees to contribute to projects, they
> tend to perform a license and/or patent review. Depending on the company,
> that process can be very different for L/GPLv2 versus L/GPLv3 codebases
> (which contains a broad expressed patent license and a "patent defense"
> provision).
> 
> We had a concrete instance, where the approval process took excessively
> long due to the use of [2] in a large number of files. The intention
> of this patch is to avoid such delays in future, when other potential
> contributors perform a license/patent review.
> 
> There is no downside to the project regarding this change, as our
> codebase is primarily GPLv2. The change does however restrict the
> freedom of people to copy files into other codebases which are not
> GPLv2 or not GPLv2 compatible (such as GPLv3 codebases).
> 


> Common practice for changes like this, is to invite the community to
> provide input and to execute the change, if there are no unresolvable
> objections.


> 
> Note that I will prepare some more patches of this type, by functional
> area to make it easier to add all the right maintainers to the CC
> list, once we have a decision on this one.



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

[Xen-devel] [PATCH v7 14/16] public/hvm/params.h: Add macros for HVM_PARAM_CALLBACK_TYPE_PPI

[Shannon Zhao]

Add macros for HVM_PARAM_CALLBACK_TYPE_PPI operation values and update
them in evtchn_fixup().

Also use HVM_PARAM_CALLBACK_IRQ_TYPE_MASK in hvm_set_callback_via().

Cc: Jan Beulich 
Cc: Andrew Cooper 
Signed-off-by: Shannon Zhao 
---
 xen/arch/arm/domain_build.c | 9 ++---
 xen/arch/x86/hvm/irq.c  | 2 +-
 xen/include/public/hvm/params.h | 3 +++
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 35ab08d..0cf7dc3 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2016,9 +2016,12 @@ static void evtchn_fixup(struct domain *d, struct 
kernel_info *kinfo)
d->arch.evtchn_irq);
 
 /* Set the value of domain param HVM_PARAM_CALLBACK_IRQ */
-val = (u64)HVM_PARAM_CALLBACK_TYPE_PPI << 56;
-val |= (2 << 8); /* Active-low level-sensitive  */
-val |= d->arch.evtchn_irq & 0xff;
+val = MASK_INSR(HVM_PARAM_CALLBACK_TYPE_PPI,
+HVM_PARAM_CALLBACK_IRQ_TYPE_MASK);
+/* Active-low level-sensitive  */
+val |= MASK_INSR(HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_LOW_LEVEL,
+ HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_MASK);
+val |= d->arch.evtchn_irq;
 d->arch.hvm_domain.params[HVM_PARAM_CALLBACK_IRQ] = val;
 
 /*
diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index 5323d7c..e597114 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -325,7 +325,7 @@ void hvm_set_callback_via(struct domain *d, uint64_t via)
 unsigned int gsi=0, pdev=0, pintx=0;
 uint8_t via_type;
 
-via_type = (uint8_t)(via >> 56) + 1;
+via_type = (uint8_t)MASK_EXTR(via, HVM_PARAM_CALLBACK_IRQ_TYPE_MASK) + 1;
 if ( ((via_type == HVMIRQ_callback_gsi) && (via == 0)) ||
  (via_type > HVMIRQ_callback_vector) )
 via_type = HVMIRQ_callback_none;
diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
index f7338a3..8b126e2 100644
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -30,6 +30,7 @@
  */
 
 #define HVM_PARAM_CALLBACK_IRQ 0
+#define HVM_PARAM_CALLBACK_IRQ_TYPE_MASK 0xFF00ULL
 /*
  * How should CPU0 event-channel notifications be delivered?
  *
@@ -66,6 +67,8 @@
  * This is only used by ARM/ARM64 and masking/eoi the interrupt associated to
  * the notification is handled by the interrupt controller.
  */
+#define HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_MASK  0xFF00
+#define HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_LOW_LEVEL 2
 #endif
 
 /*
-- 
2.10.0.windows.1


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 333ba578fef4dff8921051410c5b56f63e7eeadb
baseline version:
 ovmf f6be48e9907d8bb8f8534df50049ce428c38f719

Last test of basis67768  2016-09-27 03:18:24 Z0 days
Testing same since67771  2016-09-27 09:18:56 Z0 days1 attempts


People who touched revisions under test:
  Chao Zhang 
  Liming Gao 
  Yonghong Zhu 
  Zhang, Chao B 

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 333ba578fef4dff8921051410c5b56f63e7eeadb
Author: Yonghong Zhu 
Date:   Wed Sep 21 10:39:11 2016 +0800

BaseTools: support generating image package from BMP/JPEG/PNG files

BaseTools add support to generating image package from BMP/JPEG/PNG
files.
1) New file type *.idf Image definition file to describe HII image
resource. It is the ASCII text file, and includes one or more "#image
IMAGE_ID [TRANSPARENT] ImageFileName".
2) New IMAGE_TOKEN macro is used to refer to IMAGE_ID.
3) New AutoGen header file $(MODULE_NAME)ImgDefs.h to include the
generated ImageId definition.
4) New $(MODULE_NAME)Idf.hpk or $(MODULE_NAME)Images are generated
as the output binary HII image package.

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

commit 4f0ae88cde9caf65cbb9f534ce2b28d14add1e0d
Author: Liming Gao 
Date:   Wed Sep 21 10:39:09 2016 +0800

MdePkg UefiHii: Add IMAGE_TOKEN macro to access image resource in C and VFR

Cc: Eric Dong 
Cc: Dandan Bi 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Eric Dong 
Reviewed-by: Dandan Bi 

commit 2fa0e11df2504fea85e02f1b635f88a4d284bc6a
Author: Liming Gao 
Date:   Thu Sep 22 10:03:42 2016 +0800

MdeModulePkg FormBrowserEx: Change its structure name with EDKII_ prefix

EDKII implementation protocol should be with EDKII_ prefix.

V2: add gEdkiiFormBrowserExProtocolGuid to align its structure name.

Cc: Eric Dong 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Feng Tian 

commit 053f31e3d025f535af0626538f3d1a2415c67d2d
Author: Zhang, Chao B 
Date:   Mon Sep 26 10:31:15 2016 +0800

SecurityPkg: Tcg: New field for User Confirmation Status

Add a new field in TcgNVS for PP operation user confirmation status,
instead of previous logic overriding Request. Previous logic causes
Get Pending TPM Operation Requested sub function return wrong value.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang 
Reviewed-by: Yao Jiewen 
Reviewed-by: Long Qin 

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

[Xen-devel] [xen-unstable test] 101164: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-qcow2  6 xen-boot   fail in 101159 pass in 101164
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 101159 pass 
in 101164
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat  fail pass in 101159
 test-amd64-amd64-xl-rtds  6 xen-boot   fail pass in 101159

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

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

version targeted for testing:
 xen  9bb1865cca15b28be5aa185cd865b95b49e7b303
baseline version:
 xen  89c423a170de2fef08445ea9151bcfa15c45b217

Last test of basis   101154  2016-09-26 17:45:12 Z0 days
Testing same since   101159  2016-09-27 02:14:10 Z0 days2 attempts


People who touched revisions under test:
  Razvan Cojocaru 
  Tamas K Lengyel 

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

[Xen-devel] [PATCH v7 04/16] libxl/arm: Estimate the size of ACPI tables

[Shannon Zhao]

Estimate the size of ACPI tables and reserve a memory map space for ACPI
tables.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm_acpi.c | 100 +++
 xen/include/acpi/actbl1.h|   2 +
 2 files changed, 102 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 0851411..33a25ff 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -34,12 +34,110 @@ extern const unsigned char dsdt_anycpu_arm[];
 _hidden
 extern const int dsdt_anycpu_arm_len;
 
+enum {
+RSDP,
+XSDT,
+GTDT,
+MADT,
+FADT,
+DSDT,
+MAX_TABLE_NUMS,
+};
+
+struct acpitable {
+uint64_t addr;
+size_t size;
+};
+
+static int libxl__estimate_madt_size(libxl__gc *gc,
+ const libxl_domain_build_info *info,
+ const xc_domain_configuration_t 
*xc_config,
+ size_t *size)
+{
+int rc = 0;
+
+switch (xc_config->gic_version) {
+case XEN_DOMCTL_CONFIG_GIC_V2:
+*size = sizeof(struct acpi_table_madt) +
+ACPI_MADT_GICC_SIZE_v5 * info->max_vcpus +
+sizeof(struct acpi_madt_generic_distributor);
+break;
+case XEN_DOMCTL_CONFIG_GIC_V3:
+*size = sizeof(struct acpi_table_madt) +
+ACPI_MADT_GICC_SIZE_v5 * info->max_vcpus +
+sizeof(struct acpi_madt_generic_distributor) +
+sizeof(struct acpi_madt_generic_redistributor);
+break;
+default:
+LOG(ERROR, "Unknown GIC version");
+rc = ERROR_FAIL;
+break;
+}
+
+return rc;
+}
+
+static int libxl__estimate_acpi_size(libxl__gc *gc,
+ libxl_domain_build_info *info,
+ struct xc_dom_image *dom,
+ xc_domain_configuration_t *xc_config,
+ struct acpitable acpitables[])
+{
+int rc;
+size_t size;
+
+acpitables[RSDP].addr = GUEST_ACPI_BASE;
+acpitables[RSDP].size = sizeof(struct acpi_table_rsdp);
+dom->acpi_modules[0].length += ROUNDUP(acpitables[RSDP].size, 3);
+
+acpitables[XSDT].addr = GUEST_ACPI_BASE + dom->acpi_modules[0].length;
+/*
+ * Currently only 3 tables(GTDT, FADT, MADT) are pointed by XSDT. Alloc
+ * entries for them.
+ */
+acpitables[XSDT].size = sizeof(struct acpi_table_xsdt) +
+sizeof(uint64_t) * 2;
+dom->acpi_modules[0].length += ROUNDUP(acpitables[XSDT].size, 3);
+
+acpitables[GTDT].addr = GUEST_ACPI_BASE + dom->acpi_modules[0].length;
+acpitables[GTDT].size = sizeof(struct acpi_table_gtdt);
+dom->acpi_modules[0].length += ROUNDUP(acpitables[GTDT].size, 3);
+
+acpitables[MADT].addr = GUEST_ACPI_BASE + dom->acpi_modules[0].length;
+
+rc = libxl__estimate_madt_size(gc, info, xc_config, );
+if (rc < 0)
+goto out;
+
+acpitables[MADT].size = size;
+dom->acpi_modules[0].length += ROUNDUP(acpitables[MADT].size, 3);
+
+acpitables[FADT].addr = GUEST_ACPI_BASE + dom->acpi_modules[0].length;
+acpitables[FADT].size = sizeof(struct acpi_table_fadt);
+dom->acpi_modules[0].length += ROUNDUP(acpitables[FADT].size, 3);
+
+acpitables[DSDT].addr = GUEST_ACPI_BASE + dom->acpi_modules[0].length;
+acpitables[DSDT].size = dsdt_anycpu_arm_len;
+dom->acpi_modules[0].length += ROUNDUP(acpitables[DSDT].size, 3);
+
+assert(dom->acpi_modules[0].length <= GUEST_ACPI_SIZE);
+dom->acpi_modules[0].data = libxl__zalloc(gc, dom->acpi_modules[0].length);
+
+rc = 0;
+out:
+return rc;
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 libxl__domain_build_state *state,
 struct xc_dom_image *dom)
 {
 const libxl_version_info *vers;
 int rc = 0;
+struct acpitable acpitables[MAX_TABLE_NUMS];
+
+/* convenience aliases */
+xc_domain_configuration_t *xc_config = >config;
 
 vers = libxl_get_version_info(CTX);
 if (vers == NULL) {
@@ -54,6 +152,8 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
 dom->acpi_modules[0].length = 0;
 dom->acpi_modules[0].guest_addr_out = GUEST_ACPI_BASE;
 
+rc = libxl__estimate_acpi_size(gc, info, dom, xc_config, acpitables);
+
 out:
 return rc;
 }
diff --git a/xen/include/acpi/actbl1.h b/xen/include/acpi/actbl1.h
index ed5cd2d..e199136 100644
--- a/xen/include/acpi/actbl1.h
+++ b/xen/include/acpi/actbl1.h
@@ -786,6 +786,8 @@ struct acpi_madt_generic_interrupt {
u8 reserved2[3];
 };
 
+#define ACPI_MADT_GICC_SIZE_v5  76
+
 /* Masks for Flags field above */
 
 /* ACPI_MADT_ENABLED(1)  Processor is usable if set */
-- 
2.10.0.windows.1


___
Xen-devel mailing list

Re: [Xen-devel] [Outreachy]Code Standards Checking using clang-format

[Wei Liu]

On Tue, Sep 27, 2016 at 09:22:37AM -0500, Doug Goldstein wrote:
> On 9/26/16 3:53 PM, nimisha agarwal wrote:
> > Hello,
> >  I wish to take part in the Outreach Program this time. The
> > second  project that interest me is *Code Standards Checking using
> > clang-format. *I am currently looking through clang-format so I could
> > get to know how to use it.
> > To get started, if you could suggest couple of small bitesize work-items
> > so I could start contributing and get familiar with the codebase.
> > 
> > 
> > Regards,
> > Nimisha
> 
> Hi Nimisha,
> 
> Sounds great. At this time I'm personally not very familiar with some
> bite sized items to get started with contributing but I've CC'd Wei and
> I'm hoping he's got some ideas.

I don't have anything in mind at the moment.

However, I think it would be more useful to design a small task to test
applicants' proficiency in the skills we care about than ask them to
make simple modifications to the code base.

See  for an example.

Wei.


> 
> -- 
> Doug Goldstein
> 




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

Re: [Xen-devel] [Qemu-devel] [PATCH] xenpv: Fix qemu_uuid compiling error

[Eric Blake]

On 09/27/2016 04:20 AM, Fam Zheng wrote:
> 9c5ce8db2 switched the type of qemu_uuid and this should have followed.
> Fix it.
> 
> Signed-off-by: Fam Zheng 
> ---
>  hw/xenpv/xen_domainbuild.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Eric Blake 

> 
> diff --git a/hw/xenpv/xen_domainbuild.c b/hw/xenpv/xen_domainbuild.c
> index b439b0e..457a897 100644
> --- a/hw/xenpv/xen_domainbuild.c
> +++ b/hw/xenpv/xen_domainbuild.c
> @@ -232,7 +232,7 @@ int xen_domain_build_pv(const char *kernel, const char 
> *ramdisk,
>  unsigned long xenstore_mfn = 0, console_mfn = 0;
>  int rc;
>  
> -memcpy(uuid, qemu_uuid, sizeof(uuid));
> +memcpy(uuid, _uuid, sizeof(uuid));
>  rc = xen_domain_create(xen_xc, ssidref, uuid, flags, _domid);
>  if (rc < 0) {
>  fprintf(stderr, "xen: xc_domain_create() failed\n");
> 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



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

[Xen-devel] [distros-debian-snapshot test] 67770: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-armhf-daily-netboot-pygrub 9 debian-di-install fail blocked 
in 67732
 test-amd64-i386-i386-daily-netboot-pvgrub 9 debian-di-install fail blocked in 
67732
 test-amd64-i386-amd64-weekly-netinst-pygrub 9 debian-di-install fail blocked 
in 67732
 test-amd64-i386-amd64-daily-netboot-pygrub 9 debian-di-install fail blocked in 
67732
 test-amd64-amd64-amd64-daily-netboot-pvgrub 9 debian-di-install fail blocked 
in 67732
 test-amd64-i386-i386-weekly-netinst-pygrub 9 debian-di-install fail blocked in 
67732
 test-amd64-amd64-i386-daily-netboot-pygrub 9 debian-di-install fail blocked in 
67732
 test-amd64-amd64-i386-weekly-netinst-pygrub 9 debian-di-install fail blocked 
in 67732
 test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail blocked 
in 67732

baseline version:
 flight   67732

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   fail
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   fail
 test-amd64-amd64-amd64-current-netinst-pygrubpass
 test-amd64-i386-amd64-current-netinst-pygrub pass
 test-amd64-amd64-i386-current-netinst-pygrub pass
 test-amd64-i386-i386-current-netinst-pygrub  pass
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



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] [PATCH v7] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Boris Ostrovsky]

Some code (specifically, introduced by commit 801d469ad ("[HVM] ACPI
support patch 3 of 4: ACPI _PRT table.")) has only been licensed under
GPLv2. We want to prevent this code from showing up in non-GPL
binaries which might become possible after we make ACPI builder code
available to users other than hvmloader.

There are two pieces that we need to be careful about:
(1) A small chunk of code in dsdt.asl that implements _PIC method
(2) A chunk of ASL generator in mk_dsdt.c that describes with PCI
interrupt routing.

This code will now be generated by a GPL-only script which will be
invoked only when ACPI builder's Makefile is called with GPL variable
set.

We also strip license header from generated ASL files to prevent
inadverent use of those files with incorrect license.

Signed-off-by: Boris Ostrovsky 
---
Changes in V7
* Choose link's name as `echo "A B C D" | cut -d" " -f $i`
* Add !#/bin/sh
* Add spaces in $(( expression )) 


 tools/firmware/hvmloader/Makefile|   3 +
 tools/firmware/hvmloader/acpi/Makefile   |  14 ++-
 tools/firmware/hvmloader/acpi/dsdt.asl   |  14 ---
 tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh | 117 +++
 tools/firmware/hvmloader/acpi/mk_dsdt.c  |  68 +
 5 files changed, 132 insertions(+), 84 deletions(-)
 create mode 100755 tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index 9f7357f..a1844d0 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -65,6 +65,9 @@ ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 ROMS += $(ROMBIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
 endif
 
+# Certain parts of ACPI builder are GPL-only
+export GPL := y
+
 .PHONY: all
 all: subdirs-all
$(MAKE) hvmloader
diff --git a/tools/firmware/hvmloader/acpi/Makefile 
b/tools/firmware/hvmloader/acpi/Makefile
index f63e734..c23626d 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/firmware/hvmloader/acpi/Makefile
@@ -17,7 +17,8 @@
 XEN_ROOT = $(CURDIR)/../../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
-C_SRC = build.c dsdt_anycpu.c dsdt_15cpu.c static_tables.c 
dsdt_anycpu_qemu_xen.c
+C_SRC-$(GPL) = build.c dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
+C_SRC = build.c static_tables.c $(C_SRC-y)
 OBJS  = $(patsubst %.c,%.o,$(C_SRC))
 
 CFLAGS += $(CFLAGS_xeninclude)
@@ -36,18 +37,25 @@ ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
 mk_dsdt: mk_dsdt.c
$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
 
-dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl mk_dsdt
+ifeq ($(GPL),y)
+dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl gpl/mk_dsdt_gpl.sh 
mk_dsdt
awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
+   # Strip license comment
+   sed -i '1,/\*\//{/\/\*/,/\*\//d}' $@.$(TMP_SUFFIX)
+   $(SHELL) gpl/mk_dsdt_gpl.sh >> $@.$(TMP_SUFFIX)
cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
./mk_dsdt --debug=$(debug) --dm-version qemu-xen >> $@.$(TMP_SUFFIX)
mv -f $@.$(TMP_SUFFIX) $@
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
-dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl mk_dsdt
+dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl gpl/mk_dsdt_gpl.sh mk_dsdt
awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
+   sed -i '1,/\*\//{/\/\*/,/\*\//d}' $@.$(TMP_SUFFIX)
+   $(SHELL) gpl/mk_dsdt_gpl.sh >> $@.$(TMP_SUFFIX)
cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
./mk_dsdt --debug=$(debug) --maxcpu $*  >> $@.$(TMP_SUFFIX)
mv -f $@.$(TMP_SUFFIX) $@
+endif
 
 $(filter dsdt_%.c,$(C_SRC)): %.c: iasl %.asl
iasl -vs -p $* -tc $*.asl
diff --git a/tools/firmware/hvmloader/acpi/dsdt.asl 
b/tools/firmware/hvmloader/acpi/dsdt.asl
index 4f6db79..13811cf 100644
--- a/tools/firmware/hvmloader/acpi/dsdt.asl
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl
@@ -26,20 +26,6 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
 Name (\APCL, 0x0001)
 Name (\PUID, 0x00)
 
-/* _S3 and _S4 are in separate SSDTs */
-Name (\_S5, Package (0x04)
-{
-0x00,  /* PM1a_CNT.SLP_TYP */
-0x00,  /* PM1b_CNT.SLP_TYP */
-0x00,  /* reserved */
-0x00   /* reserved */
-})
-
-Name(PICD, 0)
-Method(_PIC, 1)
-{
-Store(Arg0, PICD) 
-}
 
 Scope (\_SB)
 {
diff --git a/tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh 
b/tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh
new file mode 100755
index 000..38fe01a
--- /dev/null
+++ b/tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh
@@ -0,0 +1,117 @@
+#!/bin/sh
+
+# This program is free software; you can redistribute it and/or modify it
+# under the terms and conditions of the GNU General Public License,
+# version 2, as published by the Free Software Foundation.
+#
+# This program is distributed in the hope it will be 

Re: [Xen-devel] PVHv2 vs HVMlite

[Juergen Gross]

On 27/09/16 16:19, David Vrabel wrote:
> On 27/09/16 15:08, Boris Ostrovsky wrote:
>> I will be dusting off Linux domU PVHv2 patches now that ACPI changes are
>> getting close to being accepted.
>>
>> Last version of that patch referred to these guests as 'hvmlite',
>> including in names of variables, routines etc. I was hesitant to remove
>> "classic" PVH code and use "pvh" instead of "hvmlite" because we didn't
>> have dom0 v2 support and so I kept existing PVHv1 code intact.
>>
>> Do we still want to do this (i.e. keep v1 code and use "hvmlite")? FWIW,
>> I am not aware of anyone using PVH dom0 (or PVH domU for that matter).
> 
> I think we should remove the PVHv1 code from Linux and then reuse the
> "pvh" name.

+1


Juergen


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

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

[Konrad Rzeszutek Wilk]

Hey!

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?

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?

I am wondering what folks think is the best way going forward?

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

Re: [Xen-devel] PVHv2 vs HVMlite

[Konrad Rzeszutek Wilk]

On Tue, Sep 27, 2016 at 03:19:32PM +0100, David Vrabel wrote:
> On 27/09/16 15:08, Boris Ostrovsky wrote:
> > I will be dusting off Linux domU PVHv2 patches now that ACPI changes are
> > getting close to being accepted.
> > 
> > Last version of that patch referred to these guests as 'hvmlite',
> > including in names of variables, routines etc. I was hesitant to remove
> > "classic" PVH code and use "pvh" instead of "hvmlite" because we didn't
> > have dom0 v2 support and so I kept existing PVHv1 code intact.
> > 
> > Do we still want to do this (i.e. keep v1 code and use "hvmlite")? FWIW,
> > I am not aware of anyone using PVH dom0 (or PVH domU for that matter).
> 
> I think we should remove the PVHv1 code from Linux and then reuse the
> "pvh" name.

+1

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

[Xen-devel] [xen-unstable baseline-only test] 67767: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67767 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67767/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-migrupgrade  9 xen-boot/src_host fail REGR. vs. 67758

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
fail like 67758
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67758
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67758
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 67758
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail like 67758
 test-amd64-i386-xl-qemut-debianhvm-amd64  9 debian-hvm-install fail like 67758
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail like 
67758
 test-amd64-i386-qemut-rhel6hvm-intel  9 redhat-install fail like 67758
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail like 
67758
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 67758
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install   fail like 67758
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 67758

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
 build-i386-rumprun5 rumprun-buildfail   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-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   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-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-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-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
 test-amd64-amd64-xl-pvh-intel 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
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-amd64-libvirt 12 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-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop 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-vhd 11 migrate-support-checkfail   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-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 xen  89c423a170de2fef08445ea9151bcfa15c45b217
baseline version:
 xen  a75f34462612a05547fc43d192705a9c31cad7fb

Last test of basis67758  2016-09-24 01:15:59 Z3 days
Testing same since67767  2016-09-27 02:14:01 Z0 days1 attempts


People who touched revisions under test:
  

Re: [Xen-devel] [Outreachy]Code Standards Checking using clang-format

[Doug Goldstein]

On 9/26/16 3:53 PM, nimisha agarwal wrote:
> Hello,
>  I wish to take part in the Outreach Program this time. The
> second  project that interest me is *Code Standards Checking using
> clang-format. *I am currently looking through clang-format so I could
> get to know how to use it.
> To get started, if you could suggest couple of small bitesize work-items
> so I could start contributing and get familiar with the codebase.
> 
> 
> Regards,
> Nimisha

Hi Nimisha,

Sounds great. At this time I'm personally not very familiar with some
bite sized items to get started with contributing but I've CC'd Wei and
I'm hoping he's got some ideas.

-- 
Doug Goldstein



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

Re: [Xen-devel] PVHv2 vs HVMlite

[David Vrabel]

On 27/09/16 15:08, Boris Ostrovsky wrote:
> I will be dusting off Linux domU PVHv2 patches now that ACPI changes are
> getting close to being accepted.
> 
> Last version of that patch referred to these guests as 'hvmlite',
> including in names of variables, routines etc. I was hesitant to remove
> "classic" PVH code and use "pvh" instead of "hvmlite" because we didn't
> have dom0 v2 support and so I kept existing PVHv1 code intact.
> 
> Do we still want to do this (i.e. keep v1 code and use "hvmlite")? FWIW,
> I am not aware of anyone using PVH dom0 (or PVH domU for that matter).

I think we should remove the PVHv1 code from Linux and then reuse the
"pvh" name.

David

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

[Xen-devel] [PATCH] xen/arm: Bring (c) headers in line with COPYING file

[Lars Kurth]

The COPYING file in the main xen.git tree applies to most files in the
xen tree, including the ones in this patch. It states:

[1]
 * Note that the only valid version of the GPL as far as the files in
 * this repository are concerned is _this_ particular version of the
 * license (i.e., *only* v2, not v2.2 or v3.x or whatever), unless
 * explicitly otherwise stated.

We do not have any GPLv3+ files in the Xen source, with the exception of
Bison generated files, which have a Bison exception and are thus safe.

However, there are a minority of files that are specifically GPL-2.0+,
stating

[2]
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.

I could not find a single instance in our code base, which states

[3]
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * any later version.

It is impossible to know, what the intention of the contributor was
when a (c) header of form [2] was used. There are two possibilities
a) The contributor chose [2] intentionally
b) The contributor copied a header file from elsewhere (e.g. the FSF)
   without understanding all the implications
The latter is more likely, which is also why we recently introduced
the CONTRIBUTING file with correct (c) headers

In all cases in our code base, code with a (c) header of form [2] is
linked against pure GPLv2 files, which in practice means that the
resulting binaries are always GPLv2. In addition, [1] clarifies this.

[2] allows the Xen Project to specifically choose GPLv2 and to modify
the (c) headers to that effect without express permission of the (c)
holders. This proposed patch makes use of this property. It also gives
anyone the right, to copy files from the Xen Project into a another
codebase and to explicitly choose GPLv3 or a later version without
obtaining the permission of the (c) holders.

When large vendors go through their internal approval process to
decide whether to allow their employees to contribute to projects, they
tend to perform a license and/or patent review. Depending on the company,
that process can be very different for L/GPLv2 versus L/GPLv3 codebases
(which contains a broad expressed patent license and a "patent defense"
provision).

We had a concrete instance, where the approval process took excessively
long due to the use of [2] in a large number of files. The intention
of this patch is to avoid such delays in future, when other potential
contributors perform a license/patent review.

There is no downside to the project regarding this change, as our
codebase is primarily GPLv2. The change does however restrict the
freedom of people to copy files into other codebases which are not
GPLv2 or not GPLv2 compatible (such as GPLv3 codebases).

Common practice for changes like this, is to invite the community to
provide input and to execute the change, if there are no unresolvable
objections.

Note that I will prepare some more patches of this type, by functional
area to make it easier to add all the right maintainers to the CC
list, once we have a decision on this one.

Signed-off-by: Lars Kurth 
---
 xen/arch/arm/acpi/boot.c| 7 +++
 xen/arch/arm/acpi/lib.c | 7 +++
 xen/arch/arm/arm32/debug-8250.inc   | 7 +++
 xen/arch/arm/arm32/debug-exynos4210.inc | 7 +++
 xen/arch/arm/arm32/debug-pl011.inc  | 7 +++
 xen/arch/arm/arm32/debug-scif.inc   | 7 +++
 xen/arch/arm/arm32/debug.S  | 7 +++
 xen/arch/arm/arm32/head.S   | 7 +++
 xen/arch/arm/arm32/proc-caxx.c  | 7 +++
 xen/arch/arm/arm32/proc-v7.S| 7 +++
 xen/arch/arm/arm32/traps.c  | 7 +++
 xen/arch/arm/arm64/debug-8250.inc   | 7 +++
 xen/arch/arm/arm64/debug-cadence.inc| 7 +++
 xen/arch/arm/arm64/debug-pl011.inc  | 7 +++
 xen/arch/arm/arm64/debug.S  | 7 +++
 xen/arch/arm/arm64/head.S   | 7 +++
 xen/arch/arm/arm64/lib/find_next_bit.c  | 5 ++---
 xen/arch/arm/arm64/traps.c  | 7 +++
 xen/arch/arm/cpu.c  | 7 +++
 xen/arch/arm/decode.c   | 7 +++
 xen/arch/arm/decode.h   | 7 +++
 xen/arch/arm/device.c   | 7 +++
 xen/arch/arm/domain.c   | 7 +++
 xen/arch/arm/efi/efi-dom0.c | 7 +++
 xen/arch/arm/gic-v2.c   | 7 +++
 xen/arch/arm/gic-v3.c   | 7 +++
 xen/arch/arm/gic.c  | 7 +++
 xen/arch/arm/io.c   | 7 +++
 xen/arch/arm/irq.c  | 7 +++
 xen/arch/arm/mm.c 

[Xen-devel] PVHv2 vs HVMlite

[Boris Ostrovsky]

I will be dusting off Linux domU PVHv2 patches now that ACPI changes are
getting close to being accepted.

Last version of that patch referred to these guests as 'hvmlite',
including in names of variables, routines etc. I was hesitant to remove
"classic" PVH code and use "pvh" instead of "hvmlite" because we didn't
have dom0 v2 support and so I kept existing PVHv1 code intact.

Do we still want to do this (i.e. keep v1 code and use "hvmlite")? FWIW,
I am not aware of anyone using PVH dom0 (or PVH domU for that matter).

-boris

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

Re: [Xen-devel] [PATCH 08/17] x86emul: generate and make use of canonical opcode representation

[Andrew Cooper]

On 15/09/16 07:43, Jan Beulich wrote:
 On 14.09.16 at 19:30,  wrote:
>>> @@ -435,6 +438,51 @@ struct x86_emulate_ctxt
>>>  void *data;
>>>  };
>>>  
>>> +/*
>>> + * This encodes the opcode extension in a "natural" way:
>> I am not sure what you mean by natural way here.  All you seem to mean
>> is that you are encoding instructions with the following method
> Hence the quotes. Do you have a suggestion for a better word?

It doesn't need qualifying at all.  It is fine to state simply that this
is the representation chosen to be used.

The commit message is the better place to make an argument as to why
this is a sensible representation, but as this comment is simply a
description of the encoding format, the "natural" feels out of place.

>
>>> +#define X86EMUL_OPC_PFX_MASK 0x0300
>>> +# define X86EMUL_OPC_66(ext, byte)   (X86EMUL_OPC(ext, byte) | 0x0100)
>>> +# define X86EMUL_OPC_F3(ext, byte)   (X86EMUL_OPC(ext, byte) | 0x0200)
>>> +# define X86EMUL_OPC_F2(ext, byte)   (X86EMUL_OPC(ext, byte) | 0x0300)
>> The PFX mask is moderately obvious from here, but a sentence describing
>> what is legitimate to add in the future wouldn't go amiss.
> I don't understand the "what is legitimate to add in the future"
> part: Nothing should be added to this set.

It occurs to me that using only 2 bits rather than 8 bits for the prefix
information would help the compiler make a smaller switch statements.

>
>>> +
>>> +#define X86EMUL_OPC_KIND_MASK0x3000
>>> +#define X86EMUL_OPC_VEX_ 0x1000
>> OTOH, I am rather more confused about what is eligible for inclusion
>> into "kind".  Also, what does a kind of 0 indicate?
> VEX, XOP, and EVEX are the valid non-zero kinds. Zero (I would
> say obviously) means neither of those three.

It is not clear how "kind" is a suitable collective term for VEX/XOP/EVEX.

Or in other words, X86EMUL_OPC_KIND_MASK doesn't provide any hint that
the operation is referring to a legacy or vex encoding of the instruction.

Would s/kind/encoding/ be ok?  At that point, X86EMUL_OPC_LEGACY_ with a
value of 0 might be useful.  (e.g. perhaps (opcode &
X86EMUL_OPC_ENCODING_MASK) == X86EMUL_OPC_LEGACY_?)

>
>>> +# define X86EMUL_OPC_VEX(ext, byte) \
>>> +(X86EMUL_OPC(ext, byte) | X86EMUL_OPC_VEX_)
>>> +# define X86EMUL_OPC_VEX_66(ext, byte) \
>>> +(X86EMUL_OPC_66(ext, byte) | X86EMUL_OPC_VEX_)
>>> +# define X86EMUL_OPC_VEX_F3(ext, byte) \
>>> +(X86EMUL_OPC_F3(ext, byte) | X86EMUL_OPC_VEX_)
>>> +# define X86EMUL_OPC_VEX_F2(ext, byte) \
>>> +(X86EMUL_OPC_F2(ext, byte) | X86EMUL_OPC_VEX_)
>>> +#define X86EMUL_OPC_EVEX_0x2000
>>> +# define X86EMUL_OPC_EVEX(ext, byte) \
>>> +(X86EMUL_OPC(ext, byte) | X86EMUL_OPC_EVEX_)
>>> +# define X86EMUL_OPC_EVEX_66(ext, byte) \
>>> +(X86EMUL_OPC_66(ext, byte) | X86EMUL_OPC_EVEX_)
>>> +# define X86EMUL_OPC_EVEX_F3(ext, byte) \
>>> +(X86EMUL_OPC_F3(ext, byte) | X86EMUL_OPC_EVEX_)
>>> +# define X86EMUL_OPC_EVEX_F2(ext, byte) \
>>> +(X86EMUL_OPC_F2(ext, byte) | X86EMUL_OPC_EVEX_)
>> Why do we go to the effort of spelling out the individual VEX/EVEX
>> possibilities, but not the XOP ones?
> Because I need some of them right away, but we currently don't
> emulate any XOP insns. If you feel strongly about it, I surely can
> add XOP ones.

Thats ok - I presume we will be gaining some in due course.

~Andrew

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