[Xen-devel] [xen-unstable-smoke test] 106677: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  607ad85d85f4856fa9feba44db4e16f033862eb0
baseline version:
 xen  48321fa86ddefe2fddf728dc972b01bb7c7c8559

Last test of basis   106664  2017-03-14 14:01:45 Z0 days
Failing since10  2017-03-14 16:01:04 Z0 days7 attempts
Testing same since   106673  2017-03-15 00:01:56 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Razvan Cojocaru 
  Roger Pau Monné 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  fail
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  broken  
 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


Not pushing.

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

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

Re: [Xen-devel] [PATCH v2] boot allocator: Use arch helper for virt_to_mfn on DIRECTMAP

[Vijay Kilari]

On Tue, Mar 14, 2017 at 9:02 PM, Julien Grall  wrote:
> Hello Vijay,
>
> On 13/03/17 11:43, vijay.kil...@gmail.com wrote:
>>
>> From: Vijaya Kumar K 
>>
>> On ARM, virt_to_mfn uses the hardware for address
>> translation. So if the virtual address is not mapped translation
>> fault is raised.On ARM, DIRECTMAP_VIRT region is direct mapped.
>
>
> This is not true. As I said before, all the memory will be direct mapped on
> ARM64 but not on ARM32.
>
> For ARM32, only xenheap will be direct mapped. So you may want to return
> is_xenheap_mfn(...). Or even return false in all the case. Either is fine by
> me, but it would need to be explained in the code.

Is this ok?.

/*
 * On ARM64 DIRECTMAP_VIRT region is directly mapped. Hence return true;
 * On ARM only xenheap memory is directly mapped. Hence return false.
 */
static inline bool_t arch_mfn_below_directmap_max_mfn(unsigned long mfn)
{
#ifdef CONFIG_ARM_64
return true;
#else
return false;
#endif
}

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

Re: [Xen-devel] [PATCH v3 4/7] xen/9pfs: connect to the backend

[Juergen Gross]

On 14/03/17 22:22, Stefano Stabellini wrote:
> Hi Juergen,
> 
> thank you for the review!
> 
> On Tue, 14 Mar 2017, Juergen Gross wrote:
>> On 14/03/17 00:50, Stefano Stabellini wrote:
>>> Implement functions to handle the xenbus handshake. Upon connection,
>>> allocate the rings according to the protocol specification.
>>>
>>> Initialize a work_struct and a wait_queue. The work_struct will be used
>>> to schedule work upon receiving an event channel notification from the
>>> backend. The wait_queue will be used to wait when the ring is full and
>>> we need to send a new request.
>>>
>>> Signed-off-by: Stefano Stabellini 
>>> CC: boris.ostrov...@oracle.com
>>> CC: jgr...@suse.com
>>> CC: Eric Van Hensbergen 
>>> CC: Ron Minnich 
>>> CC: Latchesar Ionkov 
>>> CC: v9fs-develo...@lists.sourceforge.net
>>> ---

>> Did you think about using request_threaded_irq() instead of a workqueue?
>> For an example see e.g. drivers/scsi/xen-scsifront.c
> 
> I like workqueues :-)  It might come down to personal preferences, but I
> think workqueues are more flexible and a better fit for this use case.
> Not only it is easy to schedule work in a workqueue from the interrupt
> handler, but also they can be used for sleeping in the request function
> if there is not enough room on the ring. Besides, they can easily be
> configured to share a single thread or to have multiple independent
> threads.

I'm fine with the workqueues as long as you have decided to use them
considering the alternatives. :-)

>> Can't you use xenbus_read_unsigned() instead of xenbus_read()?
> 
> I can use xenbus_read_unsigned in the other cases below, but not here,
> because versions is in the form: "1,3,4"

Is this documented somewhere?

Hmm, are any of the Xenstore entries documented? Shouldn't this be done
in xen_9pfs.h ?


Juergen


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

Re: [Xen-devel] [PATCH v7 3/3] x86: Make the GDT remapping read-only on 64-bit

[H. Peter Anvin]

,"Luis R . Rodriguez" ,Stanislaw Gruszka 
,Peter Zijlstra ,Josh Poimboeuf 
,Vitaly Kuznetsov ,Tim Chen 
,Joerg Roedel 
,=?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= ,the 
arch/x86 maintainers ,LKML 
,linux-...@vger.kernel.org,kasan-dev 
,Linux-MM ,Linux PM list 
,linux-...@vger.kernel.org,xen-de...@lists.xenproject.org,lgu...@lists.ozlabs.org,kvm
 list ,Kernel Hardening 

From: h...@zytor.com
Message-ID: <550f6209-025a-45e2-84e2-f00a3771c...@zytor.com>

On March 14, 2017 2:20:19 PM PDT, Thomas Garnier  wrote:
>On Tue, Mar 14, 2017 at 2:04 PM, Pavel Machek  wrote:
>> On Tue 2017-03-14 10:05:08, Thomas Garnier wrote:
>>> This patch makes the GDT remapped pages read-only to prevent
>corruption.
>>> This change is done only on 64-bit.
>>>
>>> The native_load_tr_desc function was adapted to correctly handle a
>>> read-only GDT. The LTR instruction always writes to the GDT TSS
>entry.
>>> This generates a page fault if the GDT is read-only. This change
>checks
>>> if the current GDT is a remap and swap GDTs as needed. This function
>was
>>> tested by booting multiple machines and checking hibernation works
>>> properly.
>>>
>>> KVM SVM and VMX were adapted to use the writeable GDT. On VMX, the
>>> per-cpu variable was removed for functions to fetch the original
>GDT.
>>> Instead of reloading the previous GDT, VMX will reload the fixmap
>GDT as
>>> expected. For testing, VMs were started and restored on multiple
>>> configurations.
>>>
>>> Signed-off-by: Thomas Garnier 
>>
>> Can we get the same change for 32-bit, too? Growing differences
>> between 32 and 64 bit are a bit of a problem...
>> Pavel
>
>It was discussed on previous versions that 32-bit read-only support
>would create issues that why it was favor for 64-bit only right now.
>
>>
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures)
>http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

We can't make the GDT read-only on 32 bits since we use task switches for 
last-resort recovery.  64 bits has IST instead.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Xen-devel] [xen-4.6-testing test] 106663: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 106556
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106556
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106556
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106556
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106556
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106556
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106556
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106556

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-1   63 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-4   63 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   63 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-2   63 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-5   63 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-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-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-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

version targeted for testing:
 xen  18949dc6e1a520b6430f128a6981318552ca7823
baseline version:
 xen  b0577dd0c600241abcaddeb8d75abb0d956fdae3

Last test of basis   106556  2017-03-08 16:44:47 Z6 days
Testing same since   106663  2017-03-14 13:41:59 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  Jan Beulich 

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   pass
 build-amd64-prev pass
 build-i386-prev

[Xen-devel] [xen-unstable-smoke test] 106675: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  607ad85d85f4856fa9feba44db4e16f033862eb0
baseline version:
 xen  48321fa86ddefe2fddf728dc972b01bb7c7c8559

Last test of basis   106664  2017-03-14 14:01:45 Z0 days
Failing since10  2017-03-14 16:01:04 Z0 days6 attempts
Testing same since   106673  2017-03-15 00:01:56 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Razvan Cojocaru 
  Roger Pau Monné 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  fail
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  broken  
 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


Not pushing.

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

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

Re: [Xen-devel] [PATCH v8 08/24] x86: refactor psr: set value: implement framework.

[Yi Sun]

On 17-03-14 04:24:51, Jan Beulich wrote:
> >>> On 14.03.17 at 10:21,  wrote:
> > On 17-03-14 00:29:09, Jan Beulich wrote:
> >> >>> Yi Sun  03/14/17 3:42 AM >>>
> >> >There are three scenarios. E.g.
> >> >1. User calls domctl interface on Dom0 to set a COS ID 1 for Dom1 into its
> >> >psr_cos_ids[]. Then, Dom1 is scheduled so that 'psr_ctxt_switch_to()' is
> >> >called which makes COS ID 1 work. For this case, we do not any action.
> >> >
> >> >2. Dom1 runs on CPU 1 and COS ID 1 is working. At same time, user calls 
> > domctl
> >> >interface on Dom0 to set a new COS ID 2 for Dom1 into psr_cos_ids[]. After
> >> >time slice ends, the Dom1 is scheduled again, the new COS ID 2 will work.
> >> >For this case, we don't need any action either.
> >> 
> >> And that's because of? I'd think the domctl caller can expect the new COS 
> >> ID
> >> to take effect immediately for all vCPU-s of the target domain.
> >> 
> >> >3. When a new COS ID is being set to psr_cos_ids[], 'psr_ctxt_switch_to()'
> >> >is called to access the same psr_cos_ids[] member through 'psr_assoc_cos'.
> >> >The COS ID is constrained by cos_mask so that it cannot exceeds the 
> >> >cos_max.
> >> >So even the COS ID got here is wrong, it is still a workable ID (within
> >> >cos_max). The functionality is still workable but of course the COS ID may
> >> >not be the one that user intends to use.
> >> >
> >> >If you think scenario 3 is not acceptable, I suggest to add read write 
> >> >lock 
> > as
> >> >below. How do you think? Thanks!
> >> >
> >> >static void psr_assoc_cos()
> >> >{
> >> >read_lock();
> >> >*reg = (*reg & ~cos_mask) |
> >> >(((uint64_t)cos << PSR_ASSOC_REG_SHIFT) & cos_mask);
> >> >read_unlock();
> >> >}
> >> >
> >> >int psr_set_val()
> >> >{
> >> >..
> >> >write_lock();
> >> >d->arch.psr_cos_ids[socket] = cos;
> >> >write_unlock();
> >> >..
> >> >}
> >> 
> >> I don't see how that would help. The domain could then still use a stale 
> >> COS
> >> ID. I see only two valid approaches: Either you pause the domain during the
> >> update, or you IPI CPUs running vCPU-s of that domain to reload their MSRs.
> >> The latter could become tricky afaict ...
> >> 
> > For IPI solution, could you please help to check if below codes can work?
> 
> Well, I did say "tricky", didn't I? What you suggest still leaves a
> time window, as the result of cpupool_domain_cpumask() may
> change behind your back. The simplest (and least tricky) solution
> would be to IPI all CPUs, and check whether any adjustment is
> needed inside the handler. However, you'd then need to make
> sure there's no context switch related race, similar to the VMCS
> one I've referred you to as example.
> 
Sorry, I may not fully understand your meaning. My thoughts are below.
1. We set 'd->arch.psr_cos_ids[socket] = cos;' in 'psr_set_val';

2. After that, we get valid cpumask through cpupool_domain_cpumask();

3. If the actual valid cpumask changed after that, the new cpu is valid so
   that the context switch happens. Then 'psr_ctxt_switch_to' is called to
   update the new cpu's ASSOC register with the new COS ID which has been
   set in step 1.

4. Send IPI to all cpus on cpumask got in step 2. They will update their
   ASSOC registers according to their domains psr_cos_ids[].

So I think this flow can cover all cpus which ASSOC registers need be updated.

What is your idea? Thanks!

BRs,
Sun Yi

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963
 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963

version targeted for testing:
 ovmf c03f5b2c42911c6af436beb7bbc4f63dd054fc83
baseline version:
 ovmf e0307a7dad02aa8c0cd8b3b0b9edce8ddb3fef2e

Last test of basis   105963  2017-02-21 21:43:31 Z   21 days
Failing since105980  2017-02-22 10:03:53 Z   20 days   57 attempts
Testing same since   106662  2017-03-14 13:29:07 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Ard Biesheuvel 
  Bi, Dandan 
  Brijesh Singh 
  Chao Zhang 
  Chen A Chen 
  Dandan Bi 
  edk2-devel On Behalf Of rthomaiy <[mailto:edk2-devel-boun...@lists.01.org]>
  Feng Tian 
  Fu Siyuan 
  Hao Wu 
  Hegde Nagaraj P 
  Hess Chen 
  Jeff Fan 
  Jiaxin Wu 
  Jiewen Yao 
  Laszlo Ersek 
  Leo Duran 
  Marvin Haeuser 
  Marvin Häuser 
  Paolo Bonzini 
  Qin Long 
  Richard Thomaiyar 
  Ruiyu Ni 
  Star Zeng 
  Wu Jiaxin 
  Yonghong Zhu 
  Zhang Lubo 
  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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

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

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

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


Not pushing.

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

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

[Xen-devel] [PATCH] tools/xl/xl_parse.c: Remove blank line.

[Zhang Chen]

Address Liu wei's comments.

Signed-off-by: Zhang Chen 
---
 tools/xl/xl_parse.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 0787337..faa9c61 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -524,7 +524,6 @@ int parse_nic_config(libxl_device_nic *nic, XLU_Config 
**config, char *token)
 replace_string(>colo_compare_out, oparg);
 } else if (MATCH_OPTION("colo_compare_notify_dev", token, oparg)) {
 replace_string(>colo_compare_notify_dev, oparg);
-
 } else if (MATCH_OPTION("colo_sock_sec_redirector0_id", token, oparg)) {
 replace_string(>colo_sock_sec_redirector0_id, oparg);
 } else if (MATCH_OPTION("colo_sock_sec_redirector0_ip", token, oparg)) {
-- 
2.7.4




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

Re: [Xen-devel] [PATCH V4 7/8] COLO-Proxy: Use socket to get checkpoint event.

[Zhang Chen]

On 03/14/2017 07:24 PM, Wei Liu wrote:

On Mon, Mar 06, 2017 at 10:59:25AM +0800, Zhang Chen wrote:

We use kernel colo proxy's way to get the checkpoint event
from qemu colo-compare.
Qemu colo-compare need add a API to support this(I will add this in qemu).
Qemu side patch:
  https://lists.nongnu.org/archive/html/qemu-devel/2017-02/msg07265.html

Signed-off-by: Zhang Chen 

Acked-by: Wei Liu 

But see below.


@@ -289,8 +393,19 @@ int colo_proxy_checkpoint(libxl__colo_proxy_state *cps,
   * event.
   */
  if (cps->is_userspace_proxy) {
-usleep(timeout_us);
-return 0;
+ret = colo_userspace_proxy_recv(cps, recvbuff, timeout_us);
+if (ret <= 0) {
+ret = 0;
+goto out1;
+}
+
+if (!strcmp(recvbuff, "DO_CHECKPOINT")) {
+ret = 1;
+} else {
+LOGD(ERROR, ao->domid, "receive qemu colo-compare checkpoint 
error");
+ret = 0;
+}
+goto out1;
  }
  
  size = colo_proxy_recv(cps, , timeout_us);

@@ -318,4 +433,7 @@ int colo_proxy_checkpoint(libxl__colo_proxy_state *cps,
  out:
  free(buff);
  return ret;
+
+out1:

Perhaps try to come up with a better name than out1? Subsequent patch is
welcome.



How about change 'out1' to 'out_userspace_proxy' ?
If OK, I will send a patch for it.

Thanks
Zhang Chen



.



--
Thanks
Zhang Chen




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

Re: [Xen-devel] [PATCH V4 5/8] COLO-Proxy: Add secondary userspace colo-proxy start args

[Zhang Chen]

On 03/14/2017 07:39 PM, Wei Liu wrote:

On Tue, Mar 14, 2017 at 11:24:12AM +, Wei Liu wrote:

On Mon, Mar 06, 2017 at 10:59:23AM +0800, Zhang Chen wrote:

Qemu need this args to start userspace colo-proxy.

Signed-off-by: Zhang Chen 

Acked-by: Wei Liu 


diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 88ef1c6..d2bbe26 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -516,6 +516,33 @@ int parse_nic_config(libxl_device_nic *nic, XLU_Config 
**config, char *token)
  replace_string(>colo_compare_sec_in, oparg);
  } else if (MATCH_OPTION("colo_compare_out", token, oparg)) {
  replace_string(>colo_compare_out, oparg);
+

Stray blank line -- will try to fix it up while committing.

Actually, removing this will cause rebase error for the next patch. I
will just send another patch to remove this blank line when I get around
to it.


Don't need to bother you, I will send a patch for it.

Thanks
Zhang Chen


Wei.


.



--
Thanks
Zhang Chen




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

[Xen-devel] [xen-4.7-testing test] 106661: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106540
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106540
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106540
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106540
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106540
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106540
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 106540

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

version targeted for testing:
 xen  099f67b7a1a1504bd32ac748991f1080400feb6f
baseline version:
 xen  8b7ab1eac8a088bf7c247e763ae58105980f84ee

Last test of basis   106540  2017-03-07 23:18:25 Z7 days
Testing same since   106661  2017-03-14 13:12:35 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  Jan Beulich 

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

[Xen-devel] [xen-unstable-smoke test] 106673: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  607ad85d85f4856fa9feba44db4e16f033862eb0
baseline version:
 xen  48321fa86ddefe2fddf728dc972b01bb7c7c8559

Last test of basis   106664  2017-03-14 14:01:45 Z0 days
Failing since10  2017-03-14 16:01:04 Z0 days5 attempts
Testing same since   106673  2017-03-15 00:01:56 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Razvan Cojocaru 
  Roger Pau Monné 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  fail
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  broken  
 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


Not pushing.

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

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

Re: [Xen-devel] [PATCH v2 1/9] configure: change CONFIG_XEN_BACKEND to be a target property

[Greg Kurz]

On Tue, 14 Mar 2017 13:23:09 -0700 (PDT)
Stefano Stabellini  wrote:

> On Tue, 14 Mar 2017, Stefano Stabellini wrote:
> > On Tue, 14 Mar 2017, Paolo Bonzini wrote:  
> > > On 14/03/2017 00:55, Stefano Stabellini wrote:  
> > > > CONFIG_XEN_BACKEND is currently set when the host supports Xen,
> > > > regardless of the chosen targets. As a consequence, Xen backends can be
> > > > enabled even on targets that don't support Xen.
> > > > 
> > > > Fix the issue by setting CONFIG_XEN_BACKEND only for targets that
> > > > support Xen.
> > > > 
> > > > Signed-off-by: Stefano Stabellini 
> > > > CC: gr...@kaod.org
> > > > CC: gr...@kaod.org
> > > > CC: pbonz...@redhat.com
> > > > CC: peter.mayd...@linaro.org
> > > > CC: r...@twiddle.net
> > > > CC: stefa...@redhat.com
> > > > ---
> > > >  configure | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/configure b/configure
> > > > index 6c21975..6d8f752 100755
> > > > --- a/configure
> > > > +++ b/configure
> > > > @@ -5442,7 +5442,6 @@ if test "$virglrenderer" = "yes" ; then
> > > >echo "VIRGL_LIBS=$virgl_libs" >> $config_host_mak
> > > >  fi
> > > >  if test "$xen" = "yes" ; then
> > > > -  echo "CONFIG_XEN_BACKEND=y" >> $config_host_mak
> > > >echo "CONFIG_XEN_CTRL_INTERFACE_VERSION=$xen_ctrl_version" >> 
> > > > $config_host_mak
> > > >if test "$xen_pv_domain_build" = "yes" ; then
> > > >  echo "CONFIG_XEN_PV_DOMAIN_BUILD=y" >> $config_host_mak
> > > > @@ -6028,6 +6027,7 @@ case "$target_name" in
> > > >i386|x86_64)
> > > >  if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
> > > >echo "CONFIG_XEN=y" >> $config_target_mak
> > > > +  echo "CONFIG_XEN_BACKEND=y" >> $config_target_mak
> > > >if test "$xen_pci_passthrough" = yes; then
> > > >  echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
> > > >fi
> > > >   
> > > 
> > > This messes up a bit the way xen_nic.o and friends are compiled, I
> > > think, because they are common-obj-y but they are only found when
> > > compiling in the target subdirectories.  So you end up building
> > > x86_64-softmmu/../hw/net/xen_nic.o
> > > 
> > > If you're unlucky, I believe this can lead to a link failure where a
> > > target is building xen_nic.o, while the other tries to link to a
> > > partially written object file.
> > > 
> > > I think the files should be changed from
> > > common-obj-$(CONFIG_XEN_BACKEND) to common-obj-$(CONFIG_XEN).
> > >
> > > The Makefile.objs change ensures that Xen backends are not enabled on
> > > targets that support Xen.  
> > 
> > Actually I thought about doing that instead of the configure change. It
> > makes sense to me.
> > 
> >   
> > > Then you add to Makefile:
> > > 
> > >  CONFIG_SOFTMMU := $(if $(filter %-softmmu,$(TARGET_DIRS)),y)
> > >  CONFIG_USER_ONLY := $(if $(filter %-user,$(TARGET_DIRS)),y)
> > > +CONFIG_XEN := $(CONFIG_XEN_BACKEND)
> > >  CONFIG_ALL=y
> > >  -include config-all-devices.mak
> > >  -include config-all-disas.mak
> > > 
> > > The Makefile change ensures that they are built before descending in the
> > > target-specific directories.  
> > 
> > But I don't understand this. Please correct me if I am wrong, but this
> > change looks like it would end up setting CONFIG_XEN every time that
> > CONFIG_XEN_BACKEND is set. Without the configure change at the top, it
> > would end up setting CONFIG_XEN whenever the host supports Xen, even for
> > non-x86 and non-ARM targets. What am I missing?  
> 
> FYI I made the following changes:
> 
> diff --git a/Makefile b/Makefile
> index 1c4c04f..b246138 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -26,6 +26,7 @@ endif
>  
>  CONFIG_SOFTMMU := $(if $(filter %-softmmu,$(TARGET_DIRS)),y)
>  CONFIG_USER_ONLY := $(if $(filter %-user,$(TARGET_DIRS)),y)
> +CONFIG_XEN := $(CONFIG_XEN_BACKEND)
>  CONFIG_ALL=y
>  -include config-all-devices.mak
>  -include config-all-disas.mak
> diff --git a/hw/block/Makefile.objs b/hw/block/Makefile.objs
> index d4c3ab7..e0ed980 100644
> --- a/hw/block/Makefile.objs
> +++ b/hw/block/Makefile.objs
> @@ -4,7 +4,7 @@ common-obj-$(CONFIG_SSI_M25P80) += m25p80.o
>  common-obj-$(CONFIG_NAND) += nand.o
>  common-obj-$(CONFIG_PFLASH_CFI01) += pflash_cfi01.o
>  common-obj-$(CONFIG_PFLASH_CFI02) += pflash_cfi02.o
> -common-obj-$(CONFIG_XEN_BACKEND) += xen_disk.o
> +common-obj-$(CONFIG_XEN) += xen_disk.o
>  common-obj-$(CONFIG_ECC) += ecc.o
>  common-obj-$(CONFIG_ONENAND) += onenand.o
>  common-obj-$(CONFIG_NVME_PCI) += nvme.o
> diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
> index 6ea76fe..725fdc4 100644
> --- a/hw/char/Makefile.objs
> +++ b/hw/char/Makefile.objs
> @@ -7,7 +7,7 @@ common-obj-$(CONFIG_SERIAL_ISA) += serial-isa.o
>  common-obj-$(CONFIG_SERIAL_PCI) += serial-pci.o
>  common-obj-$(CONFIG_VIRTIO) += virtio-console.o
>  common-obj-$(CONFIG_XILINX) += xilinx_uartlite.o
> -common-obj-$(CONFIG_XEN_BACKEND) += xen_console.o
> 

[Xen-devel] [linux-linus test] 106660: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254

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

version targeted for testing:
 linuxfb5fe0fd626c425ed41842c4318aa7ab6f3c2db7
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  614 days
Failing since 59348  2015-07-10 04:24:05 Z  613 days  336 attempts
Testing same since   106660  2017-03-14 13:00:54 Z0 days1 attempts


8066 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] [PATCH 07/18] xen/arm: Introduce a command line parameter for SErrors/Aborts

[Stefano Stabellini]

On Mon, 13 Mar 2017, Wei Chen wrote:
> In order to distinguish guest-generated SErrors from hypervisor-generated
> SErrors. We have to place SError checking code in every EL1 -> EL2 paths.
 ^ remove .

> That will be an overhead on entries caused by dsb/isb.
> 
> But not all platforms want to categorize the SErrors. For example, a host
> that is running with trusted guests. The administrator can confirm that
> all guests that are running on the host will not trigger such SErrors. In
> this user scene, we should provide some options to administrator to avoid
   ^use-case


> categorizing the SErrors. And then reduce the overhead of dsb/isb.
   ^ remove   ^ remove 


> We provided following 3 options to administrator to determine how to handle
> the SErrors:
> 
> * `diverse`:
>   The hypervisor will distinguish guest SErrors from hypervisor SErrors.
>   The guest generated SErrors will be forwarded to guests, the hypervisor
>   generated SErrors will cause the whole system crash.
>   It requires:
>   1. Place dsb/isb on all EL1 -> EL2 trap entries to categorize SErrors
>  correctly.
>   2. Place dsb/isb on EL2 -> EL1 return paths to prevent slipping hypervisor
>  SErrors to guests.
>   3. Place dsb/isb in context switch to isolate the SErrors between 2 vCPUs.
> 
> * `forward`:
>   The hypervisor will not distinguish guest SErrors from hypervisor SErrors.
>   All SErrors will be forwarded to guests, except the SErrors generated when
>   idle vCPU is running. The idle domain doesn't have the ability to hanle the
>   SErrors, so we have to crash the whole system when we get SErros with idle
>   vCPU. This option will avoid most overhead of the dsb/isb, except the 
> dsb/isb
>   in context switch which is used to isolate the SErrors between 2 vCPUs.
> 
> * `panic`:
>   The hypervisor will not distinguish guest SErrors from hypervisor SErrors.
>   All SErrors will crash the whole system. This option will avoid all overhead
>   of the dsb/isb.
> 
> Signed-off-by: Wei Chen 
> 
> ---
> About adding dsb/isb to prevent slipping Hypervisor SErrors to Guests if the
> selected option is "diverse". Some Hypervisor SErrors could not be avoid by
> software, for example ECC Error. But I don't know whether it's worth adding
> the overhead by default.
> ---
>  docs/misc/xen-command-line.markdown | 44 
> +
>  xen/arch/arm/traps.c| 19 
>  2 files changed, 63 insertions(+)
> 
> diff --git a/docs/misc/xen-command-line.markdown 
> b/docs/misc/xen-command-line.markdown
> index 4daf5b5..79554ce 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1481,6 +1481,50 @@ enabling more sockets and cores to go into deeper 
> sleep states.
>  
>  Set the serial transmit buffer size.
>  
> +### serrors (ARM)
> +> `= diverse | forward | panic`
> +
> +> Default: `diverse`
> +
> +This parameter is provided to administrator to determine how to handle the
> +SErrors.

  This parameter is provided to administrators to determine how the
  hypervisors handle SErrors.


> +In order to distinguish guest-generated SErrors from hypervisor-generated
> +SErrors. We have to place SError checking code in every EL1 -> EL2 paths.
  ^remove .

> +That will be an overhead on entries caused by dsb/isb. But not all platforms
   
   That will cause overhead on entries due to dsb/isb. However, not all 
platforms

> +need to categorize the SErrors. For example, a host that is running with
   ^ remove the

> +trusted guests. The administrator can confirm that all guests that are
> +running on the host will not trigger such SErrors. In this case, the
> +administrator can use this parameter to skip categorizing the SErrors. And
 ^ remove   ^ remove

> +reduce the overhead of dsb/isb.
> +
> +We provided following 3 options to administrator to determine how to handle
  ^ the following ^ administrators

> +the SErrors:
   ^ remove the


> +
> +* `diverse`:
> +  The hypervisor will distinguish guest SErrors from hypervisor SErrors.
> +  The guest generated SErrors will be forwarded to guests, the hypervisor
> +  generated SErrors will cause the whole system crash.
  ^ to crash

> +  It requires:
> +  1. Place dsb/isb on all EL1 -> EL2 trap entries to categorize SErrors
^ remove Place
> + correctly.
> +  2. Place dsb/isb on EL2 -> EL1 return paths to prevent slipping hypervisor
^ remove Place
> + SErrors to guests.
> +  3. Place dsb/isb in context switch to isolate the SErrors between 2 vCPUs.
^ remove Place ^ remove the
> +
> +* `forward`:
> +  The hypervisor will not distinguish guest SErrors from hypervisor SErrors.
> +  All SErrors will be forwarded to guests, except the SErrors generated when
> 

Re: [Xen-devel] [PATCH 06/18] xen/arm: Introduce a virtual abort injection helper

[Stefano Stabellini]

On Mon, 13 Mar 2017, Wei Chen wrote:
> When guest triggers async aborts, in most platform, such aborts
> will be routed to hypervisor. But we don't want the hypervisor
> to handle such aborts, so we have to route such aborts back to
> the guest.
> 
> This helper is using the HCR_EL2.VSE (HCR.VA for aarch32) bit to
> route such aborts back to the guest. If the guest PC had been
> advanced by SVC/HVC/SMC instructions before we caught the SError
> in hypervisor, we have to adjust the guest PC to exact address
> while the SError generated.
> 
> About HSR_EC_SVC32/64, even thought we don't trap SVC32/64 today,
> we would like them to be handled here. This would be useful when
> VM introspection will gain support of SVC32/64 trapping.
> 
> This helper will be used by the later patches in this series, we
> use #if 0 to disable it in this patch temporarily to remove the
> warning message of unused function from compiler.
> 
> Signed-off-by: Wei Chen 

Acked-by: Stefano Stabellini 

> ---
>  xen/arch/arm/traps.c| 32 
>  xen/include/asm-arm/processor.h |  1 +
>  2 files changed, 33 insertions(+)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index c11359d..e425832 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -618,6 +618,38 @@ static void inject_dabt_exception(struct cpu_user_regs 
> *regs,
>  #endif
>  }
>  
> +#if 0
> +/* Inject a virtual Abort/SError into the guest. */
> +static void inject_vabt_exception(struct cpu_user_regs *regs)
> +{
> +const union hsr hsr = { .bits = regs->hsr };
> +
> +/*
> + * SVC/HVC/SMC already have an adjusted PC (See ARM ARM DDI 0487A.j
> + * D1.10.1 for more details), which we need to correct in order to
> + * return to after having injected the SError.
> + */
> +switch ( hsr.ec )
> +{
> +case HSR_EC_SVC32:
> +case HSR_EC_HVC32:
> +case HSR_EC_SMC32:
> +#ifdef CONFIG_ARM_64
> +case HSR_EC_SVC64:
> +case HSR_EC_HVC64:
> +case HSR_EC_SMC64:
> +#endif
> +regs->pc -= hsr.len ? 4 : 2;
> +break;
> +
> +default:
> +break;
> +}
> +
> +current->arch.hcr_el2 |= HCR_VA;
> +}
> +#endif
> +
>  struct reg_ctxt {
>  /* Guest-side state */
>  uint32_t sctlr_el1;
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index 4b6338b..d7b0711 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -252,6 +252,7 @@
>  #define HSR_EC_HVC320x12
>  #define HSR_EC_SMC320x13
>  #ifdef CONFIG_ARM_64
> +#define HSR_EC_SVC640x15
>  #define HSR_EC_HVC640x16
>  #define HSR_EC_SMC640x17
>  #define HSR_EC_SYSREG   0x18
> -- 
> 2.7.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
> 

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

Re: [Xen-devel] [PATCH 04/18] xen/arm: Save HCR_EL2 when a guest took the SError

[Stefano Stabellini]

On Mon, 13 Mar 2017, Wei Chen wrote:
> The HCR_EL2.VSE (HCR.VA for aarch32) bit can be used to generate a
> virtual abort to guest. The HCR_EL2.VSE bit has a peculiar feature
> of getting cleared when the guest has taken the abort (this is the
> only bit that behaves as such in HCR_EL2 register).
> 
> This means that if we set the HCR_EL2.VSE bit to signal such an abort,
> we must preserve it in the guest context until it disappears from
> HCR_EL2, and at which point it must be cleared from the context. This
> is achieved by reading back from HCR_EL2 until the guest takes the
> fault.
> 
> If we preserved a pending VSE in guest context, we have to restore
> it to HCR_EL2 when context switch to this guest. This is achieved
> by writing saved HCR_EL2 value in guest context back to HCR_EL2
> register before return to guest. This had been done by the patch
> of "Restore HCR_EL2 register".
> 
> Signed-off-by: Wei Chen 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/traps.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 9792d02..476e2be 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2641,7 +2641,18 @@ static void do_trap_smc(struct cpu_user_regs *regs, 
> const union hsr hsr)
>  static void enter_hypervisor_head(struct cpu_user_regs *regs)
>  {
>  if ( guest_mode(regs) )
> +{
> +/*
> + * If we pended a virtual abort, preserve it until it gets cleared.
> + * See ARM ARM DDI 0487A.j D1.14.3 (Virtual Interrupts) for details,
> + * but the crucial bit is "On taking a vSError interrupt, HCR_EL2.VSE
> + * (alias of HCR.VA) is cleared to 0."
> + */
> +if ( current->arch.hcr_el2 & HCR_VA )
> +current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
> +
>  gic_clear_lrs(current);
> +}
>  }
>  
>  asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
> -- 
> 2.7.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
> 

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

Re: [Xen-devel] [PATCH 03/18] xen/arm: Avoid setting/clearing HCR_RW at every context switch

[Stefano Stabellini]

On Mon, 13 Mar 2017, Wei Chen wrote:
> The HCR_EL2 flags for 64-bit and 32-bit domains are different. But
> when we initialized the HCR_EL2 for vcpu0 of Dom0 and all vcpus of
> DomU in vcpu_initialise, we didn't know the domain's address size
> information. We had to use compatible flags to initialize HCR_EL2,
> and set HCR_RW for 64-bit domain or clear HCR_RW for 32-bit domain
> at every context switch.
> 
> But, after we added the HCR_EL2 to vcpu's context, this behaviour
> seems a little fussy. We can update the HCR_RW bit in vcpu's context
> as soon as we get the domain's address size to avoid setting/clearing
> HCR_RW at every context switch.
> 
> Signed-off-by: Wei Chen 
> ---
>  xen/arch/arm/arm64/domctl.c  | 6 ++
>  xen/arch/arm/domain.c| 5 +
>  xen/arch/arm/domain_build.c  | 7 +++
>  xen/arch/arm/p2m.c   | 5 -
>  xen/include/asm-arm/domain.h | 1 +
>  5 files changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/domctl.c b/xen/arch/arm/arm64/domctl.c
> index 44e1e7b..ab8781f 100644
> --- a/xen/arch/arm/arm64/domctl.c
> +++ b/xen/arch/arm/arm64/domctl.c
> @@ -14,6 +14,8 @@
>  
>  static long switch_mode(struct domain *d, enum domain_type type)
>  {
> +struct vcpu *v;
> +
>  if ( d == NULL )
>  return -EINVAL;
>  if ( d->tot_pages != 0 )
> @@ -23,6 +25,10 @@ static long switch_mode(struct domain *d, enum domain_type 
> type)
>  
>  d->arch.type = type;
>  
> +if ( is_64bit_domain(d) )
> +for_each_vcpu(d, v)
> +vcpu_switch_to_aarch64_mode(v);
> +
>  return 0;
>  }
>  
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 5d18bb0..69c2854 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -537,6 +537,11 @@ void vcpu_destroy(struct vcpu *v)
>  free_xenheap_pages(v->arch.stack, STACK_ORDER);
>  }
>  
> +void vcpu_switch_to_aarch64_mode(struct vcpu *v)
> +{
> +v->arch.hcr_el2 |= HCR_RW;
> +}

if possible, I would write it as a static inline function


>  int arch_domain_create(struct domain *d, unsigned int domcr_flags,
> struct xen_arch_domainconfig *config)
>  {
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index de59e5f..3abacc0 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2148,6 +2148,10 @@ int construct_dom0(struct domain *d)
>  return -EINVAL;
>  }
>  d->arch.type = kinfo.type;
> +
> +if ( is_64bit_domain(d) )
> +vcpu_switch_to_aarch64_mode(v);
> +
>  #endif
>  
>  allocate_memory(d, );
> @@ -2240,6 +2244,9 @@ int construct_dom0(struct domain *d)
>  printk("Failed to allocate dom0 vcpu %d on pcpu %d\n", i, cpu);
>  break;
>  }
> +
> +if ( is_64bit_domain(d) )
> +vcpu_switch_to_aarch64_mode(d->vcpu[i]);
>  }
>  
>  return 0;
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index c49bfa6..1cba0d0 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -136,11 +136,6 @@ void p2m_restore_state(struct vcpu *n)
>  WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
>  isb();
>  
> -if ( is_32bit_domain(n->domain) )
> -n->arch.hcr_el2 &= ~HCR_RW;
> -else
> -n->arch.hcr_el2 |= HCR_RW;
> -
>  WRITE_SYSREG(n->arch.sctlr, SCTLR_EL1);
>  isb();
>  
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 7b1dacc..68185e2 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -268,6 +268,7 @@ struct arch_vcpu
>  
>  void vcpu_show_execution_state(struct vcpu *);
>  void vcpu_show_registers(const struct vcpu *);
> +void vcpu_switch_to_aarch64_mode(struct vcpu *);
>  
>  unsigned int domain_max_vcpus(const struct domain *);
>  
> -- 
> 2.7.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
> 

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

Re: [Xen-devel] [PATCH 02/18] xen/arm: Restore HCR_EL2 register

[Stefano Stabellini]

On Mon, 13 Mar 2017, Wei Chen wrote:
> Different domains may have different HCR_EL2 flags. For example, the
> 64-bit domain needs HCR_RW flag but the 32-bit does not need it. So
> we give each domain a default HCR_EL2 value and save it in the VCPU's
> context.
> 
> HCR_EL2 register has only one bit can be updated automatically without
> explicit write (HCR_VSE). But we haven't used this bit currently, so
> we can consider that the HCR_EL2 register will not be modified while
> the guest is running. So save the HCR_EL2 while guest exiting to
> hypervisor is not neccessary. We just have to restore this register for
> each VCPU while leaving hypervisor.
> 
> We prefer to restore HCR_EL2 in leave_hypervisor_tail rather than in
> ctxt_switch_to. Because the leave_hypervisor_tail is the closest place
> to the exception return. In this case, we don't need to warrant the
> HCR_EL2 will not be changed between ctxt_switch_to and exception return.

Please explain a bit better why it is good to restore HCR_EL2 in
leave_hypervisor_tail. Why is it a good thing that is closer to the
exception return? What can be the cause of a change in HCR_EL2?



> Even though we have restored HCR_EL2 in leave_hypervisor_tail, we still
> have to keep the write to HCR_EL2 in p2m_restore_state. That because
> p2m_restore_state could be used to switch between two p2m and possibly
> to do address translation using hardware. For instance when building
> the hardware domain, we are using the instruction to before copying
> data. During the translation, some bits of base register (such as SCTLR
> and HCR) could be cached in TLB and used for the translation.
> 
> We had some issues in the past (see commit b3cbe129d "xen: arm: Ensure
> HCR_EL2.RW is set correctly when building dom0"), so we should probably
> keep the write to HCR_EL2 in p2m_restore_state.
> 
> Signed-off-by: wei chen 
> ---
>  xen/arch/arm/domain.c|  2 ++
>  xen/arch/arm/p2m.c   | 15 +--
>  xen/arch/arm/traps.c |  1 +
>  xen/include/asm-arm/domain.h |  3 +++
>  4 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index bb327da..5d18bb0 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -513,6 +513,8 @@ int vcpu_initialise(struct vcpu *v)
>  
>  v->arch.actlr = READ_SYSREG32(ACTLR_EL1);
>  
> +v->arch.hcr_el2 = get_default_hcr_flags();
> +
>  processor_vcpu_initialise(v);
>  
>  if ( (rc = vcpu_vgic_init(v)) != 0 )
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 1fc6ca3..c49bfa6 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -128,26 +128,29 @@ void p2m_save_state(struct vcpu *p)
>  
>  void p2m_restore_state(struct vcpu *n)
>  {
> -register_t hcr;
>  struct p2m_domain *p2m = >domain->arch.p2m;
>  
>  if ( is_idle_vcpu(n) )
>  return;
>  
> -hcr = READ_SYSREG(HCR_EL2);
> -
>  WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
>  isb();
>  
>  if ( is_32bit_domain(n->domain) )
> -hcr &= ~HCR_RW;
> +n->arch.hcr_el2 &= ~HCR_RW;
>  else
> -hcr |= HCR_RW;
> +n->arch.hcr_el2 |= HCR_RW;

It makes sense to move this if/else statement to one of the vcpu
initialization functions, but I can see that you are going to do that in
a later patch, so that's OK.


>  WRITE_SYSREG(n->arch.sctlr, SCTLR_EL1);
>  isb();
>  
> -WRITE_SYSREG(hcr, HCR_EL2);
> +/*
> + * p2m_restore_state could be used to switch between two p2m and possibly
> + * to do address translation using hardware. And these operations may
> + * happen during the interval between enter/leave hypervior, so we should
> + * probably keep the write to HCR_EL2 here.
> + */

Please rewrite this to:

  p2m_restore_state could be used to switch between two p2m and possibly
  to do address translation using hardware. These operations may
  happen during the interval between enter/leave hypervior, so we need
  to restore the right HCR_EL2 here.


> +WRITE_SYSREG(n->arch.hcr_el2, HCR_EL2);
>  isb();
>  }
>  
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index d343c66..9792d02 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2811,6 +2811,7 @@ asmlinkage void leave_hypervisor_tail(void)
>  local_irq_disable();
>  if (!softirq_pending(smp_processor_id())) {
>  gic_inject();

Please add another in-code comment:

  Set HCR_EL2 in leave_hypervisor_tail, because it is the closest code
  site to the exception return and this is important because


> +WRITE_SYSREG(current->arch.hcr_el2, HCR_EL2);
>  return;
>  }
>  local_irq_enable();
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 09fe502..7b1dacc 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -204,6 +204,9 @@ struct arch_vcpu
>  

Re: [Xen-devel] [PATCH 01/18] xen/arm: Introduce a helper to get default HCR_EL2 flags

[Stefano Stabellini]

On Mon, 13 Mar 2017, Wei Chen wrote:
> We want to add HCR_EL2 register to Xen context switch. And each copy
> of HCR_EL2 in vcpu structure will be initialized with the same set
> of trap flags as the HCR_EL2 register. We introduce a helper here to
> represent these flags to be reused easily.
> 
> Signed-off-by: Wei Chen 
> ---
>  xen/arch/arm/traps.c| 11 ---
>  xen/include/asm-arm/processor.h |  2 ++
>  2 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 614501f..d343c66 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -115,6 +115,13 @@ static void __init parse_vwfi(const char *s)
>  }
>  custom_param("vwfi", parse_vwfi);
>  
> +register_t get_default_hcr_flags(void)
> +{
> +return  (HCR_PTW|HCR_BSU_INNER|HCR_AMO|HCR_IMO|HCR_FMO|HCR_VM|
> + (vwfi != NATIVE ? (HCR_TWI|HCR_TWE) : 0) |
> + HCR_TSC|HCR_TAC|HCR_SWIO|HCR_TIDCP|HCR_FB);
> +}

I haven't finished reading this series yet, but I would make this a
static inline function if possible


>  void init_traps(void)
>  {
>  /* Setup Hyp vector base */
> @@ -139,9 +146,7 @@ void init_traps(void)
>   CPTR_EL2);
>  
>  /* Setup hypervisor traps */
> -WRITE_SYSREG(HCR_PTW|HCR_BSU_INNER|HCR_AMO|HCR_IMO|HCR_FMO|HCR_VM|
> - (vwfi != NATIVE ? (HCR_TWI|HCR_TWE) : 0) |
> - HCR_TSC|HCR_TAC|HCR_SWIO|HCR_TIDCP|HCR_FB,HCR_EL2);
> +WRITE_SYSREG(get_default_hcr_flags(), HCR_EL2);
>  isb();
>  }
>  
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index afc0e9a..4b6338b 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -708,6 +708,8 @@ int call_smc(register_t function_id, register_t arg0, 
> register_t arg1,
>  
>  void do_trap_guest_error(struct cpu_user_regs *regs);
>  
> +register_t get_default_hcr_flags(void);
> +
>  #endif /* __ASSEMBLY__ */
>  #endif /* __ASM_ARM_PROCESSOR_H */
>  /*
> -- 
> 2.7.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
> 

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

[Xen-devel] [xen-unstable-smoke test] 106672: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  f812de1b8b3622b2788617b43830686404125d40
baseline version:
 xen  48321fa86ddefe2fddf728dc972b01bb7c7c8559

Last test of basis   106664  2017-03-14 14:01:45 Z0 days
Failing since10  2017-03-14 16:01:04 Z0 days4 attempts
Testing same since   106667  2017-03-14 18:01:56 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Jan Beulich 
  Juergen Gross 
  Razvan Cojocaru 
  Roger Pau Monné 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  fail
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  broken  
 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


Not pushing.

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

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

Re: [Xen-devel] [PATCH 3/3] xen/arm: p2m: Perform local TLB invalidation on vCPU migration

[Stefano Stabellini]

On Tue, 14 Mar 2017, Julien Grall wrote:
> Hi Stefano,
> 
> On 03/14/2017 10:39 PM, Stefano Stabellini wrote:
> > On Wed, 8 Mar 2017, Julien Grall wrote:
> > > On 08/03/2017 19:48, Stefano Stabellini wrote:
> > > > On Wed, 8 Mar 2017, Julien Grall wrote:
> > I see your point, it is a good idea to use the remaining space in struct
> > domain. The only issue is that a user could set CONFIG_NR_CPUS large
> > enough to push last_vcpu_ran beyond the page boundary. I think we need
> > to add a BUILD_BUG_ON(sizeof(struct domain) >= PAGE_SIZE).
> 
> There is already a BUILD_BUG_ON(sizeof(struct domain) > PAGE_SIZE) in
> alloc_domain_struct. Would it be enough for you?

Yeah, we don't need two :)

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

Re: [Xen-devel] [PATCH 3/3] xen/arm: p2m: Perform local TLB invalidation on vCPU migration

[Julien Grall]

Hi Stefano,

On 03/14/2017 10:39 PM, Stefano Stabellini wrote:

On Wed, 8 Mar 2017, Julien Grall wrote:

On 08/03/2017 19:48, Stefano Stabellini wrote:

On Wed, 8 Mar 2017, Julien Grall wrote:

I see your point, it is a good idea to use the remaining space in struct
domain. The only issue is that a user could set CONFIG_NR_CPUS large
enough to push last_vcpu_ran beyond the page boundary. I think we need
to add a BUILD_BUG_ON(sizeof(struct domain) >= PAGE_SIZE).


There is already a BUILD_BUG_ON(sizeof(struct domain) > PAGE_SIZE) in 
alloc_domain_struct. Would it be enough for you?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 3/3] xen/arm: p2m: Perform local TLB invalidation on vCPU migration

[Stefano Stabellini]

On Wed, 8 Mar 2017, Julien Grall wrote:
> On 08/03/2017 19:48, Stefano Stabellini wrote:
> > On Wed, 8 Mar 2017, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 08/03/17 18:58, Stefano Stabellini wrote:
> > > > On Wed, 8 Mar 2017, Julien Grall wrote:
> > > > > The ARM architecture allows an OS to have per-CPU page tables, as it
> > > > > guarantees that TLBs never migrate from one CPU to another.
> > > > > 
> > > > > This works fine until this is done in a guest. Consider the following
> > > > > scenario:
> > > > > - vcpu-0 maps P to V
> > > > > - vpcu-1 maps P' to V
> > > > > 
> > > > > If run on the same physical CPU, vcpu-1 can hit in TLBs generated by
> > > > > vcpu-0 accesses, and access the wrong physical page.
> > > > > 
> > > > > The solution to this is to keep a per-p2m map of which vCPU ran the
> > > > > last
> > > > > on each given pCPU and invalidate local TLBs if two vPCUs from the
> > > > > same
> > > > > VM run on the same CPU.
> > > > > 
> > > > > Unfortunately it is not possible to allocate per-cpu variable on the
> > > > > fly. So for now the size of the array is NR_CPUS, this is fine because
> > > > > we still have space in the structure domain. We may want to add an
> > > > > helper to allocate per-cpu variable in the future.
> > > > 
> > > > I think I understand the problem, thanks for the description. I have a
> > > > question: when a vcpu of a different domain is scheduled on a pcpu,
> > > > there is no impact on tlb flushes in relation to this problem, is there?
> > > > 
> > > > For example:
> > > > 
> > > > 1) vcpu0/domain1 -> pcpu0
> > > > 2) vcpu0/domain2 -> pcpu0
> > > > 3) vcpu1/domain1 -> pcpu0
> > > > 
> > > > In 3) we still need to do the flush_tlb_local(), no matter if 2)
> > > > happened or not, right?
> > > 
> > > That's correct. The last vCPU running is stored per p2m domain and belongs
> > > to
> > > the associated domain.
> > > 
> > > > 
> > > > Also, I have one suggestion below.
> > > 
> > > [...]
> > > 
> > > > > diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> > > > > index 0899523084..18c57f936e 100644
> > > > > --- a/xen/include/asm-arm/p2m.h
> > > > > +++ b/xen/include/asm-arm/p2m.h
> > > > > @@ -96,6 +96,9 @@ struct p2m_domain {
> > > > > 
> > > > >  /* back pointer to domain */
> > > > >  struct domain *domain;
> > > > > +
> > > > > +/* Keeping track on which CPU this p2m was used and for which
> > > > > vCPU */
> > > > > +uint8_t last_vcpu_ran[NR_CPUS];
> > > > >  };
> > > > 
> > > > NR_CPUS is usually much larger than cpu_possible_map. I think it would
> > > > be best to allocate last_vcpu_ran dynamically (after cpu_possible_map is
> > > > set). It should reduce the memory impact significantly.
> > > 
> > > Well, I thought about it when I wrote the patch. p2m_domain is currently
> > > embedded in the structure domain and Xen will always allocate a page even
> > > if
> > > structure is smaller. So for now, static allocation is the best.
> > 
> > Maybe I misunderstood your answer or my suggestion wasn't clear. What
> > is the problem with something like the following (untested)?
> 
> The problem is you allocate more memory than my current solution. As your code
> below clearly show it, p2m_domain is directly integrated in arch_domain.
> 
> The structure domain can never be bigger than PAGE_SIZE (see
> alloc_domanin_struct) and we will always allocate a page no matter the size of
> the structure domain. This patch is just filling hole in the page.
> 
> So why would we want to switch to something the increase the memory impact?

I see your point, it is a good idea to use the remaining space in struct
domain. The only issue is that a user could set CONFIG_NR_CPUS large
enough to push last_vcpu_ran beyond the page boundary. I think we need
to add a BUILD_BUG_ON(sizeof(struct domain) >= PAGE_SIZE).

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

[Xen-devel] [PATCH 2/3] Introduce the Xen 9pfs transport header

[Stefano Stabellini]

Define the ring according to the protocol specification, using the new
DEFINE_XEN_FLEX_RING_AND_INTF macro.

Signed-off-by: Stefano Stabellini 
CC: konrad.w...@oracle.com
---
 xen/include/public/io/9pfs.h | 42 ++
 1 file changed, 42 insertions(+)
 create mode 100644 xen/include/public/io/9pfs.h

diff --git a/xen/include/public/io/9pfs.h b/xen/include/public/io/9pfs.h
new file mode 100644
index 000..b38ee66
--- /dev/null
+++ b/xen/include/public/io/9pfs.h
@@ -0,0 +1,42 @@
+/*
+ * 9pfs.h -- Xen 9PFS transport
+ *
+ * Refer to docs/misc/9pfs.markdown for the specification
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2017 Stefano Stabellini 
+ */
+
+#ifndef __XEN_PUBLIC_IO_9PFS_H__
+#define __XEN_PUBLIC_IO_9PFS_H__
+
+#include "ring.h"
+
+struct xen_9pfs_header {
+   uint32_t size;
+   uint8_t id;
+   uint16_t tag;
+} __attribute__((packed));
+
+#define XEN_9PFS_RING_ORDER 6
+#define XEN_9PFS_RING_SIZE  XEN_FLEX_RING_SIZE(XEN_9PFS_RING_ORDER)
+DEFINE_XEN_FLEX_RING_AND_INTF(xen_9pfs);
+
+#endif
-- 
1.9.1


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

[Xen-devel] [PATCH 1/3] [RESEND v4] ring.h: introduce macros to handle monodirectional rings with multiple req sizes

[Stefano Stabellini]

This patch introduces macros, structs and functions to handle rings in
the format described by docs/misc/pvcalls.markdown and
docs/misc/9pfs.markdown. The index page (struct __name##_data_intf)
contains the indexes and the grant refs to setup two rings.

   Indexes page
   +--+
   |@0 $NAME_data_intf:   |
   |@76: ring_order = 1   |
   |@80: ref[0]+  |
   |@84: ref[1]+  |
   |   |  |
   |   |  |
   +--+
   |
   v (data ring)
   +---+---+
   |  @0->4098: in |
   |  ref[0]   |
   |---|
   |  @4099->8196: out |
   |  ref[1]   |
   +---+

$NAME_read_packet and $NAME_write_packet are provided to read or write
any data struct from/to the ring. In pvcalls, they are unused. In xen
9pfs, they are used to read or write the 9pfs header. In other protocols
they could be used to read/write the whole request structure. See
docs/misc/9pfs.markdown:Ring Usage to learn how to check how much data
is on the ring, and how to handle notifications.

There is a ring_size parameter to most functions so that protocols using
these macros don't have to have a statically defined ring order at build
time. In pvcalls for example, each new ring could have a different
order.

These macros don't help you share the indexes page or the event channels
needed for notifications. You can do that with other out of band
mechanisms, such as xenstore or another ring.

It is not possible to use a macro to define another macro with a
variable name. For this reason, this patch introduces static inline
functions instead, that are not C89 compliant. Additionally, the macro
defines a struct with a variable sized array, which is also not C89
compliant.

Signed-off-by: Stefano Stabellini 
CC: konrad.w...@oracle.com

---
Changes in v4:
- remove packet_t, use void* and size instead

Changes in v3:
- mention C89 compliance breakages
- constify parameters
- use unsigned chars for buffers
- add two macros, one doesn't define the struct

Changes in v2:
- fix typo
- remove leading underscores from names
- use UL
- do not parenthesize parameters
- code readability improvements

Give a look at the following branch to see how they are used with
pvcalls and xen-9pfs (the drivers are still work in progress):

git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 9pfs-async-v7
---
---
 xen/include/public/io/ring.h | 131 +++
 1 file changed, 131 insertions(+)

diff --git a/xen/include/public/io/ring.h b/xen/include/public/io/ring.h
index 801c0da..8ac9ca3 100644
--- a/xen/include/public/io/ring.h
+++ b/xen/include/public/io/ring.h
@@ -313,6 +313,137 @@ typedef struct __name##_back_ring __name##_back_ring_t
 (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r);  \
 } while (0)
 
+
+/*
+ * DEFINE_XEN_FLEX_RING_AND_INTF defines two monodirectional rings and
+ * functions to check if there is data on the ring, and to read and
+ * write to them.
+ *
+ * DEFINE_XEN_FLEX_RING is similar to DEFINE_XEN_FLEX_RING_AND_INTF, but
+ * does not define the indexes page. As different protocols can have
+ * extensions to the basic format, this macro allow them to define their
+ * own struct.
+ *
+ * XEN_FLEX_RING_SIZE
+ *   Convenience macro to calculate the size of one of the two rings
+ *   from the overall order.
+ *
+ * $NAME_mask
+ *   Function to apply the size mask to an index, to reduce the index
+ *   within the range [0-size].
+ *
+ * $NAME_read_packet
+ *   Function to read data from the ring. The amount of data to read is
+ *   specified by the "size" argument.
+ *
+ * $NAME_write_packet
+ *   Function to write data to the ring. The amount of data to write is
+ *   specified by the "size" argument.
+ *
+ * $NAME_get_ring_ptr
+ *   Convenience function that returns a pointer to read/write to the
+ *   ring at the right location.
+ *
+ * $NAME_data_intf
+ *   Indexes page, shared between frontend and backend. It also
+ *   contains the array of grant refs.
+ *
+ * $NAME_queued
+ *   Function to calculate how many bytes are currently on the ring,
+ *   ready to be read. It can also be used to calculate how much free
+ *   space is currently on the ring (ring_size - $NAME_queued()).
+ */
+#define XEN_FLEX_RING_SIZE(order) \
+(1UL << (order + PAGE_SHIFT - 1))
+
+#define DEFINE_XEN_FLEX_RING_AND_INTF(name)   \
+struct name##_data_intf { \
+RING_IDX in_cons, in_prod;\
+  

[Xen-devel] [PATCH 3/3] Introduce the pvcalls header

[Stefano Stabellini]

Define the ring and request and response structs according to the
specification. Use the new DEFINE_XEN_FLEX_RING macro.

Signed-off-by: Stefano Stabellini 
CC: konrad.w...@oracle.com
---
 xen/include/public/io/pvcalls.h | 138 
 1 file changed, 138 insertions(+)
 create mode 100644 xen/include/public/io/pvcalls.h

diff --git a/xen/include/public/io/pvcalls.h b/xen/include/public/io/pvcalls.h
new file mode 100644
index 000..074f52f
--- /dev/null
+++ b/xen/include/public/io/pvcalls.h
@@ -0,0 +1,138 @@
+/*
+ * pvcalls.h -- Xen PV Calls Protocol
+ *
+ * Refer to docs/misc/pvcalls.markdown for the specification
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2017 Stefano Stabellini 
+ */
+
+#ifndef __XEN_PUBLIC_IO_PVCALLS_H__
+#define __XEN_PUBLIC_IO_PVCALLS_H__
+
+#include "ring.h"
+
+struct pvcalls_data_intf {
+RING_IDX in_cons, in_prod, in_error;
+
+uint8_t pad1[52];
+
+RING_IDX out_cons, out_prod, out_error;
+
+uint8_t pad2[52];
+
+RING_IDX ring_order;
+grant_ref_t ref[];
+};
+DEFINE_XEN_FLEX_RING(pvcalls);
+
+#define PVCALLS_SOCKET 0
+#define PVCALLS_CONNECT1
+#define PVCALLS_RELEASE2
+#define PVCALLS_BIND   3
+#define PVCALLS_LISTEN 4
+#define PVCALLS_ACCEPT 5
+#define PVCALLS_POLL   6
+
+struct xen_pvcalls_request {
+uint32_t req_id; /* private to guest, echoed in response */
+uint32_t cmd;/* command to execute */
+union {
+struct xen_pvcalls_socket {
+uint64_t id;
+uint32_t domain;
+uint32_t type;
+uint32_t protocol;
+} socket;
+struct xen_pvcalls_connect {
+uint64_t id;
+uint8_t addr[28];
+uint32_t len;
+uint32_t flags;
+grant_ref_t ref;
+uint32_t evtchn;
+} connect;
+struct xen_pvcalls_release {
+uint64_t id;
+uint8_t reuse;
+} release;
+struct xen_pvcalls_bind {
+uint64_t id;
+uint8_t addr[28];
+uint32_t len;
+} bind;
+struct xen_pvcalls_listen {
+uint64_t id;
+uint32_t backlog;
+} listen;
+struct xen_pvcalls_accept {
+uint64_t id;
+uint64_t id_new;
+grant_ref_t ref;
+uint32_t evtchn;
+} accept;
+struct xen_pvcalls_poll {
+uint64_t id;
+} poll;
+/* dummy member to force sizeof(struct xen_pvcalls_request)
+ * to match across archs */
+struct xen_pvcalls_dummy {
+uint8_t dummy[56];
+} dummy;
+} u;
+};
+
+struct xen_pvcalls_response {
+uint32_t req_id;
+uint32_t cmd;
+int32_t ret;
+uint32_t pad;
+union {
+struct _xen_pvcalls_socket {
+uint64_t id;
+} socket;
+struct _xen_pvcalls_connect {
+uint64_t id;
+} connect;
+struct _xen_pvcalls_release {
+uint64_t id;
+} release;
+struct _xen_pvcalls_bind {
+uint64_t id;
+} bind;
+struct _xen_pvcalls_listen {
+uint64_t id;
+} listen;
+struct _xen_pvcalls_accept {
+uint64_t id;
+} accept;
+struct _xen_pvcalls_poll {
+uint64_t id;
+} poll;
+struct _xen_pvcalls_dummy {
+uint8_t dummy[8];
+} dummy;
+} u;
+};
+
+DEFINE_RING_TYPES(xen_pvcalls, struct xen_pvcalls_request,
+  struct xen_pvcalls_response);
+
+#endif
-- 
1.9.1


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

[Xen-devel] [xen-unstable-smoke test] 106670: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  f812de1b8b3622b2788617b43830686404125d40
baseline version:
 xen  48321fa86ddefe2fddf728dc972b01bb7c7c8559

Last test of basis   106664  2017-03-14 14:01:45 Z0 days
Failing since10  2017-03-14 16:01:04 Z0 days3 attempts
Testing same since   106667  2017-03-14 18:01:56 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Jan Beulich 
  Juergen Gross 
  Razvan Cojocaru 
  Roger Pau Monné 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  fail
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  broken  
 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


Not pushing.

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

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

[Xen-devel] [xen-4.8-testing test] 106659: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  049b13dce84655cd73ac4acc051e7df46af00a4f
baseline version:
 xen  2e68fda962226d4de916d5ceab9d9d6037d94d45

Last test of basis   106535  2017-03-07 19:40:21 Z7 days
Testing same since   106659  2017-03-14 12:13:14 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  Jan Beulich 

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

Re: [Xen-devel] [PATCH v3 4/7] xen/9pfs: connect to the backend

[Stefano Stabellini]

Hi Juergen,

thank you for the review!

On Tue, 14 Mar 2017, Juergen Gross wrote:
> On 14/03/17 00:50, Stefano Stabellini wrote:
> > Implement functions to handle the xenbus handshake. Upon connection,
> > allocate the rings according to the protocol specification.
> > 
> > Initialize a work_struct and a wait_queue. The work_struct will be used
> > to schedule work upon receiving an event channel notification from the
> > backend. The wait_queue will be used to wait when the ring is full and
> > we need to send a new request.
> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: boris.ostrov...@oracle.com
> > CC: jgr...@suse.com
> > CC: Eric Van Hensbergen 
> > CC: Ron Minnich 
> > CC: Latchesar Ionkov 
> > CC: v9fs-develo...@lists.sourceforge.net
> > ---
> >  net/9p/trans_xen.c | 240 
> > +
> >  1 file changed, 240 insertions(+)
> > 
> > diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> > index f072876..974bac3 100644
> > --- a/net/9p/trans_xen.c
> > +++ b/net/9p/trans_xen.c
> > @@ -41,6 +41,35 @@
> >  #include 
> >  #include 
> >  
> > +#define XEN_9PFS_NUM_RINGS 2
> > +
> > +/* One per ring, more than one per 9pfs share */
> > +struct xen_9pfs_dataring {
> > +   struct xen_9pfs_front_priv *priv;
> > +
> > +   struct xen_9pfs_data_intf *intf;
> > +   grant_ref_t ref;
> > +   int evtchn;
> > +   int irq;
> > +   spinlock_t lock;
> > +
> > +   struct xen_9pfs_data data;
> > +   wait_queue_head_t wq;
> > +   struct work_struct work;
> > +};
> > +
> > +/* One per 9pfs share */
> > +struct xen_9pfs_front_priv {
> > +   struct list_head list;
> > +   struct xenbus_device *dev;
> > +   char *tag;
> > +   struct p9_client *client;
> > +
> > +   int num_rings;
> > +   struct xen_9pfs_dataring *rings;
> > +};
> > +static LIST_HEAD(xen_9pfs_devs);
> > +
> >  static int p9_xen_cancel(struct p9_client *client, struct p9_req_t *req)
> >  {
> > return 0;
> > @@ -60,6 +89,21 @@ static int p9_xen_request(struct p9_client *client, 
> > struct p9_req_t *p9_req)
> > return 0;
> >  }
> >  
> > +static void p9_xen_response(struct work_struct *work)
> > +{
> > +}
> > +
> > +static irqreturn_t xen_9pfs_front_event_handler(int irq, void *r)
> > +{
> > +   struct xen_9pfs_dataring *ring = r;
> > +   BUG_ON(!ring || !ring->priv->client);
> > +
> > +   wake_up_interruptible(>wq);
> > +   schedule_work(>work);
> > +
> > +   return IRQ_HANDLED;
> > +}
> > +
> >  static struct p9_trans_module p9_xen_trans = {
> > .name = "xen",
> > .maxsize = (1 << (XEN_9PFS_RING_ORDER + XEN_PAGE_SHIFT)),
> > @@ -76,25 +120,221 @@ static int p9_xen_request(struct p9_client *client, 
> > struct p9_req_t *p9_req)
> > { "" }
> >  };
> >  
> > +static int xen_9pfs_front_free(struct xen_9pfs_front_priv *priv)
> 
> Return type void? You are always returning 0.

Good point


> > +{
> > +   int i, j;
> > +
> > +   list_del(>list);
> > +
> > +   for (i = 0; i < priv->num_rings; i++) {
> > +   if (priv->rings[i].intf == NULL)
> > +   break;
> > +   if (priv->rings[i].irq > 0)
> > +   unbind_from_irqhandler(priv->rings[i].irq, priv->dev);
> > +   if (priv->rings[i].data.in != NULL) {
> > +   for (j = 0; j < (1 << XEN_9PFS_RING_ORDER); j++)
> > +   
> > gnttab_end_foreign_access(priv->rings[i].intf->ref[j], 0, 0);
> > +   free_pages((unsigned long)priv->rings[i].data.in,
> > +   XEN_9PFS_RING_ORDER - (PAGE_SHIFT - 
> > XEN_PAGE_SHIFT));
> > +   }
> > +   gnttab_end_foreign_access(priv->rings[i].ref, 0, 0);
> > +   free_page((unsigned long)priv->rings[i].intf);
> > +   }
> > +   kfree(priv->rings);
> > +   kfree(priv);
> > +
> > +   return 0;
> > +}
> > +
> >  static int xen_9pfs_front_remove(struct xenbus_device *dev)
> >  {
> > +   int ret;
> > +   struct xen_9pfs_front_priv *priv = dev_get_drvdata(>dev);
> > +
> > +   dev_set_drvdata(>dev, NULL);
> > +   ret = xen_9pfs_front_free(priv);
> > +   return ret;
> > +}
> > +
> > +static int xen_9pfs_front_alloc_dataring(struct xenbus_device *dev,
> > +   struct xen_9pfs_dataring *ring)
> > +{
> > +   int i = 0;
> > +   int ret = -ENOMEM;
> > +   void *bytes = NULL;
> > +
> > +   init_waitqueue_head(>wq);
> > +   spin_lock_init(>lock);
> > +   INIT_WORK(>work, p9_xen_response);
> > +
> > +   ring->intf = (struct xen_9pfs_data_intf *) get_zeroed_page(GFP_KERNEL | 
> > __GFP_ZERO);
> 
> I don't think you need __GFP_ZERO here.

You are right


> > +   if (!ring->intf)
> > +   return ret;
> > +   ret = ring->ref = gnttab_grant_foreign_access(dev->otherend_id,
> > +   virt_to_gfn(ring->intf), 0);
> > +   if (ret < 0)
> > +   goto out;
> > +   bytes = (void*)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
> 
> Coding style: (void *)

OK


> > +   

Re: [Xen-devel] [PATCH v7 3/3] x86: Make the GDT remapping read-only on 64-bit

[Thomas Garnier]

On Tue, Mar 14, 2017 at 2:04 PM, Pavel Machek  wrote:
> On Tue 2017-03-14 10:05:08, Thomas Garnier wrote:
>> This patch makes the GDT remapped pages read-only to prevent corruption.
>> This change is done only on 64-bit.
>>
>> The native_load_tr_desc function was adapted to correctly handle a
>> read-only GDT. The LTR instruction always writes to the GDT TSS entry.
>> This generates a page fault if the GDT is read-only. This change checks
>> if the current GDT is a remap and swap GDTs as needed. This function was
>> tested by booting multiple machines and checking hibernation works
>> properly.
>>
>> KVM SVM and VMX were adapted to use the writeable GDT. On VMX, the
>> per-cpu variable was removed for functions to fetch the original GDT.
>> Instead of reloading the previous GDT, VMX will reload the fixmap GDT as
>> expected. For testing, VMs were started and restored on multiple
>> configurations.
>>
>> Signed-off-by: Thomas Garnier 
>
> Can we get the same change for 32-bit, too? Growing differences
> between 32 and 64 bit are a bit of a problem...
> Pavel

It was discussed on previous versions that 32-bit read-only support
would create issues that why it was favor for 64-bit only right now.

>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html



-- 
Thomas

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

Re: [Xen-devel] Future x86 emulator direction

[Razvan Cojocaru]

On 12/14/2016 09:37 AM, Razvan Cojocaru wrote:
> On 12/14/2016 09:14 AM, Jan Beulich wrote:
> On 13.12.16 at 23:02,  wrote:
>>> On 13/12/2016 21:55, Razvan Cojocaru wrote:
 On a somewhat related note, it's important to also figure out how best
 to avoid emulation races such as the LOCK CMPXCHG issue we've discussed
 in the past. Maybe that's also worth taking into consideration at this
 early stage.
>>>
>>> Funny you should ask that.
>>>
>>> The only possible way to do this safely is to have the emulator map the
>>> target frame(s) and execute a locked stub instruction with a memory
>>> operand pointing at the mapping.  We have no other way of interacting
>>> with the cache coherency fabric.
>>
>> Well, that approach is necessary only if one path (vCPU) can write
>> to a page, while another one needs emulation. If pages are globally
>> write-protected, an approach following the model from Razvan's
>> earlier patch (which I have no idea what has become of) would
>> seem to suffice.
> 
> As previously stated, you've raised performance concerns which seemed to
> require a different direction, namely the one Andrew is now suggesting,
> which indeed, aside from being somewhat faster is also safer for all
> cases (including the one you've mentioned, where one path can write
> normally and the other does so via emulation).
> 
> The old patch itself is still alive in the XenServer patch queue, albeit
> quite unlikely to be trivial to apply to the current Xen 4.9-unstable
> code in its current form:
> 
> https://github.com/xenserver/xen-4.7.pg/blob/master/master/xen-x86-emulate-syncrhonise-LOCKed-instruction-emulation.patch
> 
> Again, if you decide that this patch is preferable, I can try to rework
> it for the current version of Xen.

Sorry to revive this old thread, but I'm still not sure what the
upstream solution for this very real problem should be. Should I bring
back the old patch that synchronizes LOCKed CMPXCHGs (perhaps with
Andrew's kind help, as he's stated that they keep an up-to-date patch
that works against staging)? Or are you considering implementing a stub
as part of the work being done on the emulator?


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v7 3/3] x86: Make the GDT remapping read-only on 64-bit

[Pavel Machek]

On Tue 2017-03-14 10:05:08, Thomas Garnier wrote:
> This patch makes the GDT remapped pages read-only to prevent corruption.
> This change is done only on 64-bit.
> 
> The native_load_tr_desc function was adapted to correctly handle a
> read-only GDT. The LTR instruction always writes to the GDT TSS entry.
> This generates a page fault if the GDT is read-only. This change checks
> if the current GDT is a remap and swap GDTs as needed. This function was
> tested by booting multiple machines and checking hibernation works
> properly.
> 
> KVM SVM and VMX were adapted to use the writeable GDT. On VMX, the
> per-cpu variable was removed for functions to fetch the original GDT.
> Instead of reloading the previous GDT, VMX will reload the fixmap GDT as
> expected. For testing, VMs were started and restored on multiple
> configurations.
> 
> Signed-off-by: Thomas Garnier 

Can we get the same change for 32-bit, too? Growing differences
between 32 and 64 bit are a bit of a problem...
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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

Re: [Xen-devel] [PATCH v3 6/7] xen/9pfs: receive responses

[Stefano Stabellini]

On Tue, 14 Mar 2017, Juergen Gross wrote:
> On 14/03/17 00:50, Stefano Stabellini wrote:
> > Upon receiving a notification from the backend, schedule the
> > p9_xen_response work_struct. p9_xen_response checks if any responses are
> > available, if so, it reads them one by one, calling p9_client_cb to send
> > them up to the 9p layer (p9_client_cb completes the request). Handle the
> > ring following the Xen 9pfs specification.
> > 
> > Signed-off-by: Stefano Stabellini 
> > Reviewed-by: Boris Ostrovsky 
> > CC: jgr...@suse.com
> > CC: Eric Van Hensbergen 
> > CC: Ron Minnich 
> > CC: Latchesar Ionkov 
> > CC: v9fs-develo...@lists.sourceforge.net
> > ---
> >  net/9p/trans_xen.c | 55 
> > ++
> >  1 file changed, 55 insertions(+)
> > 
> > diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> > index b40bbcb..1a7eb52 100644
> > --- a/net/9p/trans_xen.c
> > +++ b/net/9p/trans_xen.c
> > @@ -168,6 +168,61 @@ static int p9_xen_request(struct p9_client *client, 
> > struct p9_req_t *p9_req)
> >  
> >  static void p9_xen_response(struct work_struct *work)
> >  {
> > +   struct xen_9pfs_front_priv *priv;
> > +   struct xen_9pfs_dataring *ring;
> > +   RING_IDX cons, prod, masked_cons, masked_prod;
> > +   struct xen_9pfs_header h;
> > +   struct p9_req_t *req;
> > +   int status;
> > +
> > +   ring = container_of(work, struct xen_9pfs_dataring, work);
> > +   priv = ring->priv;
> > +
> > +   while (1) {
> > +   cons = ring->intf->in_cons;
> > +   prod = ring->intf->in_prod;
> > +   virt_rmb();
> > +
> > +   if (xen_9pfs_queued(prod, cons, XEN_9PFS_RING_SIZE) < 
> > sizeof(h)) {
> > +   notify_remote_via_irq(ring->irq);
> > +   return;
> > +   }
> > +
> > +   masked_prod = xen_9pfs_mask(prod, XEN_9PFS_RING_SIZE);
> > +   masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
> > +
> > +   /* First, read just the header */
> > +   xen_9pfs_read_packet(ring->data.in,
> > +   masked_prod, _cons,
> > +   XEN_9PFS_RING_SIZE, , sizeof(h));
> > +
> > +   req = p9_tag_lookup(priv->client, h.tag);
> > +   if (!req || req->status != REQ_STATUS_SENT) {
> > +   dev_warn(>dev->dev, "Wrong req tag=%x\n", h.tag);
> > +   cons += h.size;
> > +   virt_mb();
> > +   ring->intf->in_cons = cons;
> > +   continue;
> > +   }
> > +
> > +   memcpy(req->rc, , sizeof(h));
> > +   req->rc->offset = 0;
> > +
> > +   masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
> > +   /* Then, read the whole packet (including the header) */
> > +   xen_9pfs_read_packet(ring->data.in,
> > +   masked_prod, _cons,
> > +   XEN_9PFS_RING_SIZE, req->rc->sdata, h.size);
> 
> Please align the parameters to the same column.

I am one of those heretics that use tabstop=4 :-)
I'll fix this though.


> > +
> > +   virt_mb();
> > +   cons += h.size;
> > +   ring->intf->in_cons = cons;
> > +
> > +   status = (req->status != REQ_STATUS_ERROR) ?
> > +   REQ_STATUS_RCVD : REQ_STATUS_ERROR;
> > +
> > +   p9_client_cb(priv->client, req, status);
> > +   }
> >  }
> >  
> >  static irqreturn_t xen_9pfs_front_event_handler(int irq, void *r)
> > 
> 
> 
> Juergen
> 

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

Re: [Xen-devel] [PATCH v3 3/7] xen/9pfs: introduce Xen 9pfs transport driver

[Stefano Stabellini]

On Tue, 14 Mar 2017, Juergen Gross wrote:
> On 14/03/17 00:50, Stefano Stabellini wrote:
> > Introduce the Xen 9pfs transport driver: add struct xenbus_driver to
> > register as a xenbus driver and add struct p9_trans_module to register
> > as v9fs driver.
> > 
> > All functions are empty stubs for now.
> > 
> > Signed-off-by: Stefano Stabellini 
> > Reviewed-by: Boris Ostrovsky 
> > CC: jgr...@suse.com
> > CC: Eric Van Hensbergen 
> > CC: Ron Minnich 
> > CC: Latchesar Ionkov 
> > CC: v9fs-develo...@lists.sourceforge.net
> > ---
> >  net/9p/trans_xen.c | 125 
> > +
> >  1 file changed, 125 insertions(+)
> >  create mode 100644 net/9p/trans_xen.c
> > 
> > diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> > new file mode 100644
> > index 000..f072876
> > --- /dev/null
> > +++ b/net/9p/trans_xen.c
> 
> > +static struct p9_trans_module p9_xen_trans = {
> > +   .name = "xen",
> > +   .maxsize = (1 << (XEN_9PFS_RING_ORDER + XEN_PAGE_SHIFT)),
> 
> I think you can remove the outer brackets.

OK

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

Re: [Xen-devel] [PATCH v2 1/9] configure: change CONFIG_XEN_BACKEND to be a target property

[Stefano Stabellini]

On Tue, 14 Mar 2017, Stefano Stabellini wrote:
> On Tue, 14 Mar 2017, Paolo Bonzini wrote:
> > On 14/03/2017 00:55, Stefano Stabellini wrote:
> > > CONFIG_XEN_BACKEND is currently set when the host supports Xen,
> > > regardless of the chosen targets. As a consequence, Xen backends can be
> > > enabled even on targets that don't support Xen.
> > > 
> > > Fix the issue by setting CONFIG_XEN_BACKEND only for targets that
> > > support Xen.
> > > 
> > > Signed-off-by: Stefano Stabellini 
> > > CC: gr...@kaod.org
> > > CC: gr...@kaod.org
> > > CC: pbonz...@redhat.com
> > > CC: peter.mayd...@linaro.org
> > > CC: r...@twiddle.net
> > > CC: stefa...@redhat.com
> > > ---
> > >  configure | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/configure b/configure
> > > index 6c21975..6d8f752 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -5442,7 +5442,6 @@ if test "$virglrenderer" = "yes" ; then
> > >echo "VIRGL_LIBS=$virgl_libs" >> $config_host_mak
> > >  fi
> > >  if test "$xen" = "yes" ; then
> > > -  echo "CONFIG_XEN_BACKEND=y" >> $config_host_mak
> > >echo "CONFIG_XEN_CTRL_INTERFACE_VERSION=$xen_ctrl_version" >> 
> > > $config_host_mak
> > >if test "$xen_pv_domain_build" = "yes" ; then
> > >  echo "CONFIG_XEN_PV_DOMAIN_BUILD=y" >> $config_host_mak
> > > @@ -6028,6 +6027,7 @@ case "$target_name" in
> > >i386|x86_64)
> > >  if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
> > >echo "CONFIG_XEN=y" >> $config_target_mak
> > > +  echo "CONFIG_XEN_BACKEND=y" >> $config_target_mak
> > >if test "$xen_pci_passthrough" = yes; then
> > >  echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
> > >fi
> > > 
> > 
> > This messes up a bit the way xen_nic.o and friends are compiled, I
> > think, because they are common-obj-y but they are only found when
> > compiling in the target subdirectories.  So you end up building
> > x86_64-softmmu/../hw/net/xen_nic.o
> > 
> > If you're unlucky, I believe this can lead to a link failure where a
> > target is building xen_nic.o, while the other tries to link to a
> > partially written object file.
> > 
> > I think the files should be changed from
> > common-obj-$(CONFIG_XEN_BACKEND) to common-obj-$(CONFIG_XEN).
> >
> > The Makefile.objs change ensures that Xen backends are not enabled on
> > targets that support Xen.
> 
> Actually I thought about doing that instead of the configure change. It
> makes sense to me.
> 
> 
> > Then you add to Makefile:
> > 
> >  CONFIG_SOFTMMU := $(if $(filter %-softmmu,$(TARGET_DIRS)),y)
> >  CONFIG_USER_ONLY := $(if $(filter %-user,$(TARGET_DIRS)),y)
> > +CONFIG_XEN := $(CONFIG_XEN_BACKEND)
> >  CONFIG_ALL=y
> >  -include config-all-devices.mak
> >  -include config-all-disas.mak
> > 
> > The Makefile change ensures that they are built before descending in the
> > target-specific directories.
> 
> But I don't understand this. Please correct me if I am wrong, but this
> change looks like it would end up setting CONFIG_XEN every time that
> CONFIG_XEN_BACKEND is set. Without the configure change at the top, it
> would end up setting CONFIG_XEN whenever the host supports Xen, even for
> non-x86 and non-ARM targets. What am I missing?

FYI I made the following changes:

diff --git a/Makefile b/Makefile
index 1c4c04f..b246138 100644
--- a/Makefile
+++ b/Makefile
@@ -26,6 +26,7 @@ endif
 
 CONFIG_SOFTMMU := $(if $(filter %-softmmu,$(TARGET_DIRS)),y)
 CONFIG_USER_ONLY := $(if $(filter %-user,$(TARGET_DIRS)),y)
+CONFIG_XEN := $(CONFIG_XEN_BACKEND)
 CONFIG_ALL=y
 -include config-all-devices.mak
 -include config-all-disas.mak
diff --git a/hw/block/Makefile.objs b/hw/block/Makefile.objs
index d4c3ab7..e0ed980 100644
--- a/hw/block/Makefile.objs
+++ b/hw/block/Makefile.objs
@@ -4,7 +4,7 @@ common-obj-$(CONFIG_SSI_M25P80) += m25p80.o
 common-obj-$(CONFIG_NAND) += nand.o
 common-obj-$(CONFIG_PFLASH_CFI01) += pflash_cfi01.o
 common-obj-$(CONFIG_PFLASH_CFI02) += pflash_cfi02.o
-common-obj-$(CONFIG_XEN_BACKEND) += xen_disk.o
+common-obj-$(CONFIG_XEN) += xen_disk.o
 common-obj-$(CONFIG_ECC) += ecc.o
 common-obj-$(CONFIG_ONENAND) += onenand.o
 common-obj-$(CONFIG_NVME_PCI) += nvme.o
diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
index 6ea76fe..725fdc4 100644
--- a/hw/char/Makefile.objs
+++ b/hw/char/Makefile.objs
@@ -7,7 +7,7 @@ common-obj-$(CONFIG_SERIAL_ISA) += serial-isa.o
 common-obj-$(CONFIG_SERIAL_PCI) += serial-pci.o
 common-obj-$(CONFIG_VIRTIO) += virtio-console.o
 common-obj-$(CONFIG_XILINX) += xilinx_uartlite.o
-common-obj-$(CONFIG_XEN_BACKEND) += xen_console.o
+common-obj-$(CONFIG_XEN) += xen_console.o
 common-obj-$(CONFIG_CADENCE) += cadence_uart.o
 
 obj-$(CONFIG_EXYNOS4) += exynos4210_uart.o
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 063889b..3d02e8b 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -5,7 +5,7 @@ common-obj-$(CONFIG_JAZZ_LED) += jazz_led.o
 

Re: [Xen-devel] [PATCH v2 5/9] xen/9pfs: connect to the frontend

[Stefano Stabellini]

On Tue, 14 Mar 2017, Juergen Gross wrote:
> On 14/03/17 00:55, Stefano Stabellini wrote:
> > Write the limits of the backend to xenstore. Connect to the frontend.
> > Upon connection, allocate the rings according to the protocol
> > specification.
> > 
> > Initialize a QEMUBH to schedule work upon receiving an event channel
> > notification from the frontend.
> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: anthony.per...@citrix.com
> > CC: jgr...@suse.com
> > CC: Aneesh Kumar K.V 
> > CC: Greg Kurz 
> > ---
> >  hw/9pfs/xen-9p-backend.c | 159 
> > ++-
> >  1 file changed, 158 insertions(+), 1 deletion(-)
> > 
> > diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
> > index 35032d3..0e4a133 100644
> > --- a/hw/9pfs/xen-9p-backend.c
> > +++ b/hw/9pfs/xen-9p-backend.c
> > @@ -17,8 +17,35 @@
> >  #include "qemu/config-file.h"
> >  #include "fsdev/qemu-fsdev.h"
> >  
> > +#define VERSIONS "1"
> > +#define MAX_RINGS 8
> > +#define MAX_RING_ORDER 8
> > +
> > +struct Xen9pfsRing {
> > +struct Xen9pfsDev *priv;
> > +
> > +int ref;
> > +xenevtchn_handle   *evtchndev;
> > +int evtchn;
> > +int local_port;
> > +struct xen_9pfs_data_intf *intf;
> > +unsigned char *data;
> > +struct xen_9pfs_data ring;
> > +
> > +QEMUBH *bh;
> > +
> > +/* local copies, so that we can read/write PDU data directly from
> > + * the ring */
> > +RING_IDX out_cons, out_size, in_cons;
> > +bool inprogress;
> > +};
> > +
> >  typedef struct Xen9pfsDev {
> >  struct XenDevice xendev;  /* must be first */
> > +V9fsState state;
> > +
> > +int num_rings;
> > +struct Xen9pfsRing *rings;
> >  } Xen9pfsDev;
> >  
> >  static ssize_t xen_9pfs_pdu_vmarshal(V9fsPDU *pdu,
> > @@ -67,22 +94,152 @@ static int xen_9pfs_init(struct XenDevice *xendev)
> >  return 0;
> >  }
> >  
> > +static void xen_9pfs_bh(void *opaque)
> > +{
> > +}
> > +
> > +static void xen_9pfs_evtchn_event(void *opaque)
> > +{
> > +}
> > +
> >  static int xen_9pfs_free(struct XenDevice *xendev)
> >  {
> > -return -1;
> > +int i;
> > +struct Xen9pfsDev *xen_9pdev = container_of(xendev, struct Xen9pfsDev, 
> > xendev);
> > +
> > +for (i = 0; i < xen_9pdev->num_rings; i++) {
> > +if (xen_9pdev->rings[i].data != NULL) {
> > +xengnttab_unmap(xen_9pdev->xendev.gnttabdev,
> > +xen_9pdev->rings[i].data,
> > +(1 << XEN_9PFS_RING_ORDER));
> > +}
> > +if (xen_9pdev->rings[i].intf != NULL) {
> > +xengnttab_unmap(xen_9pdev->xendev.gnttabdev,
> > +xen_9pdev->rings[i].intf,
> > +1);
> > +}
> > +if (xen_9pdev->rings[i].evtchndev > 0) {
> > +
> > qemu_set_fd_handler(xenevtchn_fd(xen_9pdev->rings[i].evtchndev),
> > +NULL, NULL, NULL);
> > +xenevtchn_unbind(xen_9pdev->rings[i].evtchndev, 
> > xen_9pdev->rings[i].local_port);
> > +}
> > +if (xen_9pdev->rings[i].bh != NULL) {
> > +qemu_bh_delete(xen_9pdev->rings[i].bh);
> > +}
> > +}
> > +g_free(xen_9pdev->rings);
> > +return 0;
> >  }
> >  
> >  static int xen_9pfs_connect(struct XenDevice *xendev)
> >  {
> > +int i;
> > +struct Xen9pfsDev *xen_9pdev = container_of(xendev, struct Xen9pfsDev, 
> > xendev);
> > +V9fsState *s = _9pdev->state;
> > +QemuOpts *fsdev;
> > +char *security_model, *path;
> > +
> > +if (xenstore_read_fe_int(_9pdev->xendev, "num-rings",
> > + _9pdev->num_rings) == -1 ||
> > +xen_9pdev->num_rings > MAX_RINGS) {
> 
> What if num_rings is < 1?

Good point, I'll add a check for that


> > +return -1;
> > +}
> > +
> > +xen_9pdev->rings = g_malloc0(xen_9pdev->num_rings * sizeof(struct 
> > Xen9pfsRing));
> > +for (i = 0; i < xen_9pdev->num_rings; i++) {
> > +char str[16];
> > +
> > +xen_9pdev->rings[i].priv = xen_9pdev;
> > +xen_9pdev->rings[i].evtchn = -1;
> > +xen_9pdev->rings[i].local_port = -1;
> > +
> > +sprintf(str, "ring-ref%u", i);
> 
> use g_strdup_printf()?

OK


> > +if (xenstore_read_fe_int(_9pdev->xendev, str,
> > + _9pdev->rings[i].ref) == -1) {
> > +goto out;
> > +}
> > +sprintf(str, "event-channel-%u", i);
> 
> use g_strdup_printf()?

Sure

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail in 106642 
pass in 106652
 test-armhf-armhf-libvirt-raw  4 host-ping-check-native fail pass in 106642

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail in 106642 like 
106627
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106627
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106627
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106627
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106627
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106627
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106627
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 106627

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

version targeted for testing:
 xen  bd8ad2a52aba4911ada897c72f8795172a09a193
baseline version:
 xen  9dc1e0cd81ee469d638d1962a92d9b4bd2972bfa

Last test of basis   106627  2017-03-13 01:57:28 Z1 days
Testing same since   106642  2017-03-13 21:14:25 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 

Re: [Xen-devel] [PATCH v2 4/9] xen/9pfs: introduce Xen 9pfs backend

[Stefano Stabellini]

On Tue, 14 Mar 2017, Juergen Gross wrote:
> On 14/03/17 00:55, Stefano Stabellini wrote:
> > Introduce the Xen 9pfs backend: add struct XenDevOps to register as a
> > Xen backend and add struct V9fsTransport to register as v9fs transport.
> > 
> > All functions are empty stubs for now.
> > 
> > Signed-off-by: Stefano Stabellini 
> > Reviewed-by: Greg Kurz 
> > CC: anthony.per...@citrix.com
> > CC: jgr...@suse.com
> > CC: Aneesh Kumar K.V 
> > CC: Greg Kurz 
> > ---
> >  hw/9pfs/xen-9p-backend.c | 96 
> > 
> >  1 file changed, 96 insertions(+)
> >  create mode 100644 hw/9pfs/xen-9p-backend.c
> > 
> > diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
> > new file mode 100644
> > index 000..35032d3
> > --- /dev/null
> > +++ b/hw/9pfs/xen-9p-backend.c
> > @@ -0,0 +1,96 @@
> > +/*
> > + * Xen 9p backend
> > + *
> > + * Copyright Aporeto 2017
> > + *
> > + * Authors:
> > + *  Stefano Stabellini 
> > + *
> > + */
> > +
> > +#include "qemu/osdep.h"
> > +
> > +#include "hw/hw.h"
> > +#include "hw/9pfs/9p.h"
> > +#include "hw/xen/xen_backend.h"
> > +#include "xen_9pfs.h"
> > +#include "qemu/config-file.h"
> > +#include "fsdev/qemu-fsdev.h"
> > +
> > +typedef struct Xen9pfsDev {
> > +struct XenDevice xendev;  /* must be first */
> > +} Xen9pfsDev;
> > +
> > +static ssize_t xen_9pfs_pdu_vmarshal(V9fsPDU *pdu,
> > + size_t offset,
> > + const char *fmt,
> > + va_list ap)
> > +{
> > +return 0;
> > +}
> > +
> > +static ssize_t xen_9pfs_pdu_vunmarshal(V9fsPDU *pdu,
> > +   size_t offset,
> > +   const char *fmt,
> > +   va_list ap)
> > +{
> > +return 0;
> > +}
> > +
> > +static void xen_9pfs_init_out_iov_from_pdu(V9fsPDU *pdu,
> > +   struct iovec **piov,
> > +   unsigned int *pniov)
> > +{
> > +}
> > +
> > +static void xen_9pfs_init_in_iov_from_pdu(V9fsPDU *pdu,
> > +  struct iovec **piov,
> > +  unsigned int *pniov,
> > +  size_t size)
> > +{
> > +}
> > +
> > +static void xen_9pfs_push_and_notify(V9fsPDU *pdu)
> > +{
> > +}
> > +
> > +static const struct V9fsTransport xen_9p_transport = {
> > +.pdu_vmarshal = xen_9pfs_pdu_vmarshal,
> > +.pdu_vunmarshal = xen_9pfs_pdu_vunmarshal,
> > +.init_in_iov_from_pdu = xen_9pfs_init_in_iov_from_pdu,
> > +.init_out_iov_from_pdu = xen_9pfs_init_out_iov_from_pdu,
> > +.push_and_notify = xen_9pfs_push_and_notify,
> > +};
> > +
> > +static int xen_9pfs_init(struct XenDevice *xendev)
> > +{
> > +return 0;
> > +}
> > +
> > +static int xen_9pfs_free(struct XenDevice *xendev)
> > +{
> > +return -1;
> > +}
> > +
> > +static int xen_9pfs_connect(struct XenDevice *xendev)
> > +{
> > +return 0;
> > +}
> > +
> > +static void xen_9pfs_alloc(struct XenDevice *xendev)
> > +{
> > +}
> > +
> > +static void xen_9pfs_disconnect(struct XenDevice *xendev)
> > +{
> > +}
> > +
> > +struct XenDevOps xen_9pfs_ops = {
> > +.size   = sizeof(Xen9pfsDev),
> > +.flags  = DEVOPS_FLAG_NEED_GNTDEV,
> > +.alloc  = xen_9pfs_alloc,
> > +.init   = xen_9pfs_init,
> > +.initialise= xen_9pfs_connect,
> 
> Alignment?

I'll fix, thanks


> > +.disconnect = xen_9pfs_disconnect,
> > +.free   = xen_9pfs_free,
> > +};
> > 


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

Re: [Xen-devel] [PATCH v2 08/17] tools: provide pkg-config file for libxengnttab

[Andrew Cooper]

On 14/03/17 13:31, Juergen Gross wrote:
> In order to be able to use pkg-config for obtaining linker- and
> compiler-flags provide a xengnttab.pc and a xengntshr.pc file.
>
> Signed-off-by: Juergen Gross 
> Acked-by: Wei Liu 

What is xengntshr.pc actually for?

(I am forward porting the XenServer patch queue, and rpm informs me that
there is no real libxengntshr)

All gntshr functionality is inside gnttab, and only a single shared
object exists.

In fact, I can't see why we have any *_libxengntshr infrastructure at
all (c/s a71ad0feada which introduced it originally doesn't help; they
weren't two libraries before either...).

The two uses of *_libxengntshr infrastructure are libxc and libvchan,
both of which reference *_libxengnttab immediately before.

~Andrew

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

[Xen-devel] [xen-unstable-smoke test] 106667: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  f812de1b8b3622b2788617b43830686404125d40
baseline version:
 xen  48321fa86ddefe2fddf728dc972b01bb7c7c8559

Last test of basis   106664  2017-03-14 14:01:45 Z0 days
Failing since10  2017-03-14 16:01:04 Z0 days2 attempts
Testing same since   106667  2017-03-14 18:01:56 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Jan Beulich 
  Juergen Gross 
  Razvan Cojocaru 
  Roger Pau Monné 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  fail
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  broken  
 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


Not pushing.

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

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

Re: [Xen-devel] WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

[Andrea Arcangeli]

Hello,

On Mon, Mar 13, 2017 at 10:21:45AM +0100, Michal Hocko wrote:
> On Fri 10-03-17 13:00:37, Reza Arbab wrote:
> > On Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote:
> > >OK, so while I was playing with this setup some more I probably got why
> > >this is done this way. All new memblocks are added to the zone Normal
> > >where they are accounted as spanned but not present.
> > 
> > It's not always zone Normal. See zone_for_memory(). This leads to a
> > workaround for having to do online_movable in descending block order.
> > Instead of this:
> > 
> > 1. probe block 34, probe block 33, probe block 32, ...
> > 2. online_movable 34, online_movable 33, online_movable 32, ...
> > 
> > you can online_movable the first block before adding the rest:
> 
> I do I enforce that behavior when the probe happens automagically?

What I provided as guide to online as movable in current and older
kernels is:

1) Remove udev rule
2) After adding memory with qemu/libvirt API run in the guest

--- workaround start 
#!/bin/bash
for i in `ls -d1 /sys/devices/system/memory/memory* | sort -nr -t y -k 5`; do 
if [ "`cat $i/state`" == "offline" ]; then echo online_movable > $i/state ; fi; 
done
--- workaround end 

That's how bad is onlining as movable for memory hotunplug.

> > 1. probe block 32, online_movable 32
> > 2. probe block 33, probe block 34, ...
> > - zone_for_memory() will cause these to start Movable
> > 3. online 33, online 34, ...
> > - they're already in Movable, so online_movable is equivalentr
> > 
> > I agree with your general sentiment that this stuff is very nonintuitive.
> 
> My criterion for nonintuitive is probably different because I would call
> this _completely_unusable_. Sorry for being so loud about this but the
> more I look into this area the more WTF code I see. This has seen close
> to zero review and seems to be building up more single usecase code on
> top of previous. We need to change this, seriously!

It's not a bug, but when I found it I called it a "constraint" and
when I debugged it (IIRC) it originated here:

} else if (online_type == MMOP_ONLINE_MOVABLE) {
if (!zone_can_shift(pfn, nr_pages, ZONE_MOVABLE, _shift))
return -EINVAL;
}

Fixing it so you could online as movable even if it wasn't the last
block was in my todo list but then we had other plans.

Unfortunately unless pfn+nr_pages of the newly created Movable zone
matches the end of the normal zone (or whatever was there that has to
be converted to Movable), it will fail onlining as movable.

To fix it is enough to check that everything from pfn to the end of
whatever zone existed there (or the end of the node perhaps safer) can
be converted as movable and just convert the whole thing as movable
instead of stopping at pfn+nr_pages.

Also note, onlining highmem physical ranges as movable requires yet
another config option to be set for the below check to pass
(CONFIG_MOVABLE_NODE=y), which I'm not exactly sure why anybody would
want to set =n, and perhaps would be candidate for dropping well
before considering to drop _DEFAULT_ONLINE and at best it should be
replaced with a kernel parameter to turn off the CONFIG_MOVABLE_NODE=y
behavior.

if ((zone_idx(zone) > ZONE_NORMAL ||
online_type == MMOP_ONLINE_MOVABLE) &&
!can_online_high_movable(zone))
return -EINVAL;

I would suggest to drop the constraints in online_pages and perhaps
also the CONFIG_MOVABLE_NODE option before going to drop the automatic
onlining in kernel.

Because of the above constraint the udev rule is unusable anyway for
onlining memory as movable so that it can be hotunplugged reliably
(well not so reliably, page_migrate does a loop and tries many times
but it occurred to me it failed once to offline and at next try it
worked, temporary page pins with O_DIRECT screw with page_migration,
rightfully so and no easy fix).

After the above constraint is fixed I suggest to look into fixing the
async onlining by making the udev rule run synchronously. Adding 4T to
a 8G guest is perfectly reasonable and normal operation, no excuse for
it to fail as long as you don't pretend such 4T to be unpluggable too
later (which we won't).

As I understand it, the whole point of _DEFFAULT_ONLINE=y is precisely
that it's easier to fix it in kernel than fixing the udev
rule. Furthermore the above constraint for the zone shifting which
breaks online_movable in udev is not an issue for _DEFFAULT_ONLINE=y
because kernel onlining is synchronous by design (no special
synchronous udev rule fix is required) so it can cope fine with the
existing above constraint by onlining as movable from the end of the
last zone in each node so that such constraint never gets in the way.

Extending _DEFFAULT_ONLINE=y so that it can also online as movable has
been worked on.

On a side note, kernelcore=xxx passed to a kernel with
_DEFFAULT_ONLINE=y should already allow to 

[Xen-devel] [linux-4.1 test] 106655: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 104301

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-vhd 3 host-install(3) broken in 106644 pass in 106655
 test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-stop fail in 106644 pass in 
106655
 test-armhf-armhf-xl-rtds  7 host-ping-check-xenfail pass in 106644
 test-amd64-amd64-rumprun-amd64 16 rumprun-demo-xenstorels/xenstorels.repeat 
fail pass in 106644

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104301
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 104301
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104301
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104301
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104301
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104301

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

version targeted for testing:
 linuxd9e0350d2575a20ee7783427da9bd6b6107eb983
baseline version:
 linuxf40b3cc69de8c97bbcdb74e3cffda06ffcad2cd7

Last test of basis   104301  2017-01-19 13:16:22 Z   54 days
Testing same since   106644  2017-03-13 22:17:49 Z0 days2 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Adrian Hunter 
  Akinobu Mita 

Re: [Xen-devel] [PATCH v2 1/9] configure: change CONFIG_XEN_BACKEND to be a target property

[Stefano Stabellini]

On Tue, 14 Mar 2017, Paolo Bonzini wrote:
> On 14/03/2017 00:55, Stefano Stabellini wrote:
> > CONFIG_XEN_BACKEND is currently set when the host supports Xen,
> > regardless of the chosen targets. As a consequence, Xen backends can be
> > enabled even on targets that don't support Xen.
> > 
> > Fix the issue by setting CONFIG_XEN_BACKEND only for targets that
> > support Xen.
> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: gr...@kaod.org
> > CC: gr...@kaod.org
> > CC: pbonz...@redhat.com
> > CC: peter.mayd...@linaro.org
> > CC: r...@twiddle.net
> > CC: stefa...@redhat.com
> > ---
> >  configure | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/configure b/configure
> > index 6c21975..6d8f752 100755
> > --- a/configure
> > +++ b/configure
> > @@ -5442,7 +5442,6 @@ if test "$virglrenderer" = "yes" ; then
> >echo "VIRGL_LIBS=$virgl_libs" >> $config_host_mak
> >  fi
> >  if test "$xen" = "yes" ; then
> > -  echo "CONFIG_XEN_BACKEND=y" >> $config_host_mak
> >echo "CONFIG_XEN_CTRL_INTERFACE_VERSION=$xen_ctrl_version" >> 
> > $config_host_mak
> >if test "$xen_pv_domain_build" = "yes" ; then
> >  echo "CONFIG_XEN_PV_DOMAIN_BUILD=y" >> $config_host_mak
> > @@ -6028,6 +6027,7 @@ case "$target_name" in
> >i386|x86_64)
> >  if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
> >echo "CONFIG_XEN=y" >> $config_target_mak
> > +  echo "CONFIG_XEN_BACKEND=y" >> $config_target_mak
> >if test "$xen_pci_passthrough" = yes; then
> >  echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
> >fi
> > 
> 
> This messes up a bit the way xen_nic.o and friends are compiled, I
> think, because they are common-obj-y but they are only found when
> compiling in the target subdirectories.  So you end up building
> x86_64-softmmu/../hw/net/xen_nic.o
> 
> If you're unlucky, I believe this can lead to a link failure where a
> target is building xen_nic.o, while the other tries to link to a
> partially written object file.
> 
> I think the files should be changed from
> common-obj-$(CONFIG_XEN_BACKEND) to common-obj-$(CONFIG_XEN).
>
> The Makefile.objs change ensures that Xen backends are not enabled on
> targets that support Xen.

Actually I thought about doing that instead of the configure change. It
makes sense to me.


> Then you add to Makefile:
> 
>  CONFIG_SOFTMMU := $(if $(filter %-softmmu,$(TARGET_DIRS)),y)
>  CONFIG_USER_ONLY := $(if $(filter %-user,$(TARGET_DIRS)),y)
> +CONFIG_XEN := $(CONFIG_XEN_BACKEND)
>  CONFIG_ALL=y
>  -include config-all-devices.mak
>  -include config-all-disas.mak
> 
> The Makefile change ensures that they are built before descending in the
> target-specific directories.

But I don't understand this. Please correct me if I am wrong, but this
change looks like it would end up setting CONFIG_XEN every time that
CONFIG_XEN_BACKEND is set. Without the configure change at the top, it
would end up setting CONFIG_XEN whenever the host supports Xen, even for
non-x86 and non-ARM targets. What am I missing?

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

Re: [Xen-devel] [PATCH v4] xen: don't save/restore the physmap on VM save/restore

[Stefano Stabellini]

On Tue, 14 Mar 2017, Igor Druzhinin wrote:
> Saving/restoring the physmap to/from xenstore was introduced to
> QEMU majorly in order to cover up the VRAM region restore issue.
> The sequence of restore operations implies that we should know
> the effective guest VRAM address *before* we have the VRAM region
> restored (which happens later). Unfortunately, in Xen environment
> VRAM memory does actually belong to a guest - not QEMU itself -
> which means the position of this region is unknown beforehand and
> can't be mapped into QEMU address space immediately.
> 
> Previously, recreating xenstore keys, holding the physmap, by the
> toolstack helped to get this information in place at the right
> moment ready to be consumed by QEMU to map the region properly.
> 
> The extraneous complexity of having those keys transferred by the
> toolstack and unnecessary redundancy prompted us to propose a
> solution which doesn't require any extra data in xenstore. The idea
> is to defer the VRAM region mapping till the point we actually know
> the effective address and able to map it. To that end, we initially
> just skip the mapping request for the framebuffer if we unable to
> map it now. Then, after the memory region restore phase, we perform
> the mapping again, this time successfully, and update the VRAM region
> metadata accordingly.
> 
> Signed-off-by: Igor Druzhinin 
> ---
> v4:
> * Use VGA post_load handler for vram_ptr update
> 
> v3:
> * Modify qemu_ram_ptr_length similarly with qemu_map_ram_ptr
> * Add a comment explaining qemu_map_ram_ptr and qemu_ram_ptr_length 
>   semantic change for Xen
> * Dropped some redundant changes
> 
> v2:
> * Fix some building and coding style issues
> ---
>  exec.c   |  16 +
>  hw/display/vga.c |   5 +++
>  xen-hvm.c| 104 
> ++-
>  3 files changed, 40 insertions(+), 85 deletions(-)
> 
> diff --git a/exec.c b/exec.c
> index aabb035..a1ac8cd 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -2008,6 +2008,14 @@ void *qemu_map_ram_ptr(RAMBlock *ram_block, ram_addr_t 
> addr)
>  }
>  
>  block->host = xen_map_cache(block->offset, block->max_length, 1);
> +if (block->host == NULL) {
> +/* In case we cannot establish the mapping right away we might
> + * still be able to do it later e.g. on a later stage of restore.
> + * We don't touch the block and return NULL here to indicate
> + * that intention.
> + */
> +return NULL;
> +}
>  }
>  return ramblock_ptr(block, addr);
>  }
> @@ -2041,6 +2049,14 @@ static void *qemu_ram_ptr_length(RAMBlock *ram_block, 
> ram_addr_t addr,
>  }
>  
>  block->host = xen_map_cache(block->offset, block->max_length, 1);
> +if (block->host == NULL) {
> +/* In case we cannot establish the mapping right away we might
> + * still be able to do it later e.g. on a later stage of restore.
> + * We don't touch the block and return NULL here to indicate
> + * that intention.
> + */
> +return NULL;
> +}
>  }
>  
>  return ramblock_ptr(block, addr);
> diff --git a/hw/display/vga.c b/hw/display/vga.c
> index 69c3e1d..f8aebe3 100644
> --- a/hw/display/vga.c
> +++ b/hw/display/vga.c
> @@ -2035,6 +2035,11 @@ static int vga_common_post_load(void *opaque, int 
> version_id)
>  {
>  VGACommonState *s = opaque;
>  
> +if (xen_enabled() && !s->vram_ptr) {
> +/* update VRAM region pointer in case we've failed
> + * the last time during init phase */
> +s->vram_ptr = memory_region_get_ram_ptr(>vram);
> +}

Please add a similar in-code comment at the point where we try to set
vram_ptr the first time. It might be suitable to add a debug printf if
vram_ptr is NULL then.


>  /* force refresh */
>  s->graphic_mode = -1;
>  vbe_update_vgaregs(s);
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 5043beb..8bedd9b 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -317,7 +317,6 @@ static int xen_add_to_physmap(XenIOState *state,
>  XenPhysmap *physmap = NULL;
>  hwaddr pfn, start_gpfn;
>  hwaddr phys_offset = memory_region_get_ram_addr(mr);
> -char path[80], value[17];
>  const char *mr_name;
>  
>  if (get_physmapping(state, start_addr, size)) {
> @@ -340,6 +339,22 @@ go_physmap:
>  DPRINTF("mapping vram to %"HWADDR_PRIx" - %"HWADDR_PRIx"\n",
>  start_addr, start_addr + size);
>  
> +mr_name = memory_region_name(mr);
> +
> +physmap = g_malloc(sizeof(XenPhysmap));
> +
> +physmap->start_addr = start_addr;
> +physmap->size = size;
> +physmap->name = mr_name;
> +physmap->phys_offset = phys_offset;
> +
> +QLIST_INSERT_HEAD(>physmap, physmap, list);
> +
> +if (runstate_check(RUN_STATE_INMIGRATE)) {
> +/* If we are migrating the region has been already mapped 

Re: [Xen-devel] [PATCH v3] xen: don't save/restore the physmap on VM save/restore

[Stefano Stabellini]

On Tue, 14 Mar 2017, Igor Druzhinin wrote:
> On 13/03/17 21:15, Stefano Stabellini wrote:
> > On Mon, 13 Mar 2017, Igor Druzhinin wrote:
> >> Saving/restoring the physmap to/from xenstore was introduced to
> >> QEMU majorly in order to cover up the VRAM region restore issue.
> >> The sequence of restore operations implies that we should know
> >> the effective guest VRAM address *before* we have the VRAM region
> >> restored (which happens later). Unfortunately, in Xen environment
> >> VRAM memory does actually belong to a guest - not QEMU itself -
> >> which means the position of this region is unknown beforehand and
> >> can't be mapped into QEMU address space immediately.
> >>
> >> Previously, recreating xenstore keys, holding the physmap, by the
> >> toolstack helped to get this information in place at the right
> >> moment ready to be consumed by QEMU to map the region properly.
> >>
> >> The extraneous complexity of having those keys transferred by the
> >> toolstack and unnecessary redundancy prompted us to propose a
> >> solution which doesn't require any extra data in xenstore. The idea
> >> is to defer the VRAM region mapping till the point we actually know
> >> the effective address and able to map it. To that end, we initially
> >> only register the pointer to the framebuffer without actual mapping.
> >> Then, during the memory region restore phase, we perform the mapping
> >> of the known address and update the VRAM region metadata (including
> >> previously registered pointer) accordingly.
> >>
> >> Signed-off-by: Igor Druzhinin 
> > 
> > Let me get this straight. The current sequence is:
> > 
> > - read physmap from xenstore, including vram and rom addresses
> > - vga initialization
> >   - register framebuffer with xen-hvm.c
> >   - set vram_ptr by mapping the vram region using xen_map_cache
> > - rtl8139 initialization
> >   - map rom files using xen_map_cache
> > 
> > The new sequence would be:
> > 
> > - vga initialization
> >   - register framebuffer and _ptr with xen-hvm.c
> >   - set vram_ptr to NULL because we don't know the vram address yet
> > - rtl8139 initialization
> >   - map rom files using xen_map_cache ???
> > - the vram address is discovered as part of the savevm file
> > - when the vram region is mapped into the guest, set vram_ptr to the right 
> > value
> > 
> > 
> > Is that right? If so, why can't we just move the
> > 
> >   s->vram_ptr = memory_region_get_ram_ptr(>vram);
> > 
> > line in vga.c to later? It would be better than changing the value of
> > vram_ptr behind the scenes. Clearer for the vga maintainers too.
> > 
> 
> Yes, it's one of the possible solutions. Probably would require more
> changes in VGA code. But I'll take a look at this.

Patch v4 is better in this regard, thanks.


> > But my main concern is actually rom files. The current physmap mechanism
> > also covers roms, such as the rtl8139 rom, which is used for pxebooting
> > from the VM. How do you plan to cover those?
> > 
> 
> Here is an excerpt from xen_add_to_physmap() which clearly indicates
> that the only region that we track now is VRAM region.
> 
> if (mr == framebuffer && start_addr > 0xb) {
> goto go_physmap;
> }
> return -1;
> 
> Maybe I'm missing something?

Looking at the code now, you are right that ROMs don't seem to be
tracked. We rely on QEMU "allocating" ROMs at the same addresses at
restore time. The allocation is skipped at the beginning of
xen_ram_alloc, but then the following xen_map_cache call will map the
ROM memory regardless. It works because the addresses are the same. (I
wonder if those addresses could change, causing a breakage.)


> >> v3:
> >> * Modify qemu_ram_ptr_length similarly with qemu_map_ram_ptr
> >> * Add a comment explaining qemu_map_ram_ptr and qemu_ram_ptr_length 
> >>   semantic change for Xen
> >> * Dropped some redundant changes
> >>
> >> v2:
> >> * Fix some building and coding style issues
> >>
> >> ---
> >>  exec.c   |  16 
> >>  hw/display/vga.c |   2 +-
> >>  include/hw/xen/xen.h |   2 +-
> >>  xen-hvm-stub.c   |   2 +-
> >>  xen-hvm.c| 111 
> >> ---
> >>  5 files changed, 44 insertions(+), 89 deletions(-)
> >>
> >> diff --git a/exec.c b/exec.c
> >> index aabb035..a1ac8cd 100644
> >> --- a/exec.c
> >> +++ b/exec.c
> >> @@ -2008,6 +2008,14 @@ void *qemu_map_ram_ptr(RAMBlock *ram_block, 
> >> ram_addr_t addr)
> >>  }
> >>  
> >>  block->host = xen_map_cache(block->offset, block->max_length, 1);
> >> +if (block->host == NULL) {
> >> +/* In case we cannot establish the mapping right away we might
> >> + * still be able to do it later e.g. on a later stage of 
> >> restore.
> >> + * We don't touch the block and return NULL here to indicate
> >> + * that intention.
> >> + */
> >> +return NULL;
> >> +}
> >>  }
> 

[Xen-devel] [PATCH] tools: Include due to glibc 2.25

[Anthony PERARD]

To fix the follwing error with glibc 2.25:
tap-ctl-allocate.c:109:13: error: In the GNU C Library, "makedev" is defined
 by . For historical compatibility, it is
 currently defined by  as well, but we plan to
 remove this soon. To use "makedev", include 
 directly. If you did not intend to use a system-defined macro
 "makedev", you should undefine it after including . [-Werror]
  err = mknod(devname, perm, makedev(major, minor));
 ^~~

Same thing with major() and minor() in
libxl__device_physdisk_major_minor().

Signed-off-by: Anthony PERARD 
---
 tools/blktap2/control/tap-ctl-allocate.c | 1 +
 tools/libxl/libxl_internal.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/tools/blktap2/control/tap-ctl-allocate.c 
b/tools/blktap2/control/tap-ctl-allocate.c
index 8a6471e987..0f15175cc7 100644
--- a/tools/blktap2/control/tap-ctl-allocate.c
+++ b/tools/blktap2/control/tap-ctl-allocate.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "tap-ctl.h"
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5bbede532e..235500dd06 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v3 14/21] x86/xen: split suspend.c for PV and PVHVM guests

[Vitaly Kuznetsov]

Slit the code in suspend.c into suspend_pv.c and suspend_hvm.c.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Juergen Gross 
---
Changes since v2:
   #include  added to suspend_pv.c [kbuild test robot]
---
 arch/x86/xen/Makefile  |  3 ++-
 arch/x86/xen/suspend.c | 54 --
 arch/x86/xen/suspend_hvm.c | 22 +++
 arch/x86/xen/suspend_pv.c  | 46 +++
 arch/x86/xen/xen-ops.h | 13 +++
 5 files changed, 83 insertions(+), 55 deletions(-)
 create mode 100644 arch/x86/xen/suspend_hvm.c
 create mode 100644 arch/x86/xen/suspend_pv.c

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 8da1ca9..cf8d6c5 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -15,7 +15,8 @@ obj-y := enlighten.o setup.o multicalls.o mmu.o irq.o 
\
grant-table.o suspend.o platform-pci-unplug.o \
p2m.o apic.o pmu.o enlighten_pv.o mmu_pv.o
 
-obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o mmu_hvm.o
+obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o mmu_hvm.o 
suspend_hvm.o
+obj-$(CONFIG_XEN_PV)   += suspend_pv.o
 obj-$(CONFIG_XEN_PVH)  += enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index 7f664c4..d6b1680 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -14,60 +14,6 @@
 #include "mmu.h"
 #include "pmu.h"
 
-static void xen_pv_pre_suspend(void)
-{
-   xen_mm_pin_all();
-
-   xen_start_info->store_mfn = mfn_to_pfn(xen_start_info->store_mfn);
-   xen_start_info->console.domU.mfn =
-   mfn_to_pfn(xen_start_info->console.domU.mfn);
-
-   BUG_ON(!irqs_disabled());
-
-   HYPERVISOR_shared_info = _dummy_shared_info;
-   if (HYPERVISOR_update_va_mapping(fix_to_virt(FIX_PARAVIRT_BOOTMAP),
-__pte_ma(0), 0))
-   BUG();
-}
-
-static void xen_hvm_post_suspend(int suspend_cancelled)
-{
-#ifdef CONFIG_XEN_PVHVM
-   int cpu;
-   if (!suspend_cancelled)
-   xen_hvm_init_shared_info();
-   xen_callback_vector();
-   xen_unplug_emulated_devices();
-   if (xen_feature(XENFEAT_hvm_safe_pvclock)) {
-   for_each_online_cpu(cpu) {
-   xen_setup_runstate_info(cpu);
-   }
-   }
-#endif
-}
-
-static void xen_pv_post_suspend(int suspend_cancelled)
-{
-   xen_build_mfn_list_list();
-
-   xen_setup_shared_info();
-
-   if (suspend_cancelled) {
-   xen_start_info->store_mfn =
-   pfn_to_mfn(xen_start_info->store_mfn);
-   xen_start_info->console.domU.mfn =
-   pfn_to_mfn(xen_start_info->console.domU.mfn);
-   } else {
-#ifdef CONFIG_SMP
-   BUG_ON(xen_cpu_initialized_map == NULL);
-   cpumask_copy(xen_cpu_initialized_map, cpu_online_mask);
-#endif
-   xen_vcpu_restore();
-   }
-
-   xen_mm_unpin_all();
-}
-
 void xen_arch_pre_suspend(void)
 {
if (xen_pv_domain())
diff --git a/arch/x86/xen/suspend_hvm.c b/arch/x86/xen/suspend_hvm.c
new file mode 100644
index 000..01afcad
--- /dev/null
+++ b/arch/x86/xen/suspend_hvm.c
@@ -0,0 +1,22 @@
+#include 
+
+#include 
+#include 
+#include 
+
+#include "xen-ops.h"
+
+void xen_hvm_post_suspend(int suspend_cancelled)
+{
+   int cpu;
+
+   if (!suspend_cancelled)
+   xen_hvm_init_shared_info();
+   xen_callback_vector();
+   xen_unplug_emulated_devices();
+   if (xen_feature(XENFEAT_hvm_safe_pvclock)) {
+   for_each_online_cpu(cpu) {
+   xen_setup_runstate_info(cpu);
+   }
+   }
+}
diff --git a/arch/x86/xen/suspend_pv.c b/arch/x86/xen/suspend_pv.c
new file mode 100644
index 000..3abe4f0
--- /dev/null
+++ b/arch/x86/xen/suspend_pv.c
@@ -0,0 +1,46 @@
+#include 
+
+#include 
+
+#include 
+#include 
+
+#include "xen-ops.h"
+
+void xen_pv_pre_suspend(void)
+{
+   xen_mm_pin_all();
+
+   xen_start_info->store_mfn = mfn_to_pfn(xen_start_info->store_mfn);
+   xen_start_info->console.domU.mfn =
+   mfn_to_pfn(xen_start_info->console.domU.mfn);
+
+   BUG_ON(!irqs_disabled());
+
+   HYPERVISOR_shared_info = _dummy_shared_info;
+   if (HYPERVISOR_update_va_mapping(fix_to_virt(FIX_PARAVIRT_BOOTMAP),
+__pte_ma(0), 0))
+   BUG();
+}
+
+void xen_pv_post_suspend(int suspend_cancelled)
+{
+   xen_build_mfn_list_list();
+
+   xen_setup_shared_info();
+
+   if (suspend_cancelled) {
+   xen_start_info->store_mfn =
+   pfn_to_mfn(xen_start_info->store_mfn);
+   xen_start_info->console.domU.mfn =
+   pfn_to_mfn(xen_start_info->console.domU.mfn);
+   } 

[Xen-devel] [PATCH v3 19/21] xen: create xen_create/destroy_contiguous_region() stubs for PVHVM only builds

[Vitaly Kuznetsov]

xen_create_contiguous_region()/xen_create_contiguous_region() are PV-only,
they both contain xen_feature(XENFEAT_auto_translated_physmap) check and
bail in the very beginning.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Juergen Gross 
---
 include/xen/xen-ops.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index b5486e6..f939114 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -34,11 +34,25 @@ u64 xen_steal_clock(int cpu);
 int xen_setup_shutdown_event(void);
 
 extern unsigned long *xen_contiguous_bitmap;
+
+#ifdef CONFIG_XEN_PV
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
unsigned int address_bits,
dma_addr_t *dma_handle);
 
 void xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int order);
+#else
+static inline int xen_create_contiguous_region(phys_addr_t pstart,
+  unsigned int order,
+  unsigned int address_bits,
+  dma_addr_t *dma_handle)
+{
+   return 0;
+}
+
+static inline void xen_destroy_contiguous_region(phys_addr_t pstart,
+unsigned int order) { }
+#endif
 
 struct vm_area_struct;
 
-- 
2.9.3


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

[Xen-devel] [PATCH v3 18/21] xen/balloon: decorate PV-only parts with #ifdef CONFIG_XEN_PV

[Vitaly Kuznetsov]

Balloon driver uses several PV-only concepts (xen_start_info,
xen_extra_mem,..) and it seems the simpliest solution to make HVM-only
build happy is to decorate these parts with #ifdefs.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Juergen Gross 
---
 drivers/xen/balloon.c | 30 --
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index a6d4378..50dcb68 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -709,6 +709,7 @@ void free_xenballooned_pages(int nr_pages, struct page 
**pages)
 }
 EXPORT_SYMBOL(free_xenballooned_pages);
 
+#ifdef CONFIG_XEN_PV
 static void __init balloon_add_region(unsigned long start_pfn,
  unsigned long pages)
 {
@@ -732,19 +733,22 @@ static void __init balloon_add_region(unsigned long 
start_pfn,
 
balloon_stats.total_pages += extra_pfn_end - start_pfn;
 }
+#endif
 
 static int __init balloon_init(void)
 {
-   int i;
-
if (!xen_domain())
return -ENODEV;
 
pr_info("Initialising balloon driver\n");
 
+#ifdef CONFIG_XEN_PV
balloon_stats.current_pages = xen_pv_domain()
? min(xen_start_info->nr_pages - xen_released_pages, max_pfn)
: get_num_physpages();
+#else
+   balloon_stats.current_pages = get_num_physpages();
+#endif
balloon_stats.target_pages  = balloon_stats.current_pages;
balloon_stats.balloon_low   = 0;
balloon_stats.balloon_high  = 0;
@@ -761,14 +765,20 @@ static int __init balloon_init(void)
register_sysctl_table(xen_root);
 #endif
 
-   /*
-* Initialize the balloon with pages from the extra memory
-* regions (see arch/x86/xen/setup.c).
-*/
-   for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++)
-   if (xen_extra_mem[i].n_pfns)
-   balloon_add_region(xen_extra_mem[i].start_pfn,
-  xen_extra_mem[i].n_pfns);
+#ifdef CONFIG_XEN_PV
+   {
+   int i;
+
+   /*
+* Initialize the balloon with pages from the extra memory
+* regions (see arch/x86/xen/setup.c).
+*/
+   for (i = 0; i < XEN_EXTRA_MEM_MAX_REGIONS; i++)
+   if (xen_extra_mem[i].n_pfns)
+   balloon_add_region(xen_extra_mem[i].start_pfn,
+  xen_extra_mem[i].n_pfns);
+   }
+#endif
 
return 0;
 }
-- 
2.9.3


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

[Xen-devel] [PATCH v3 21/21] x86/xen: rename some PV-only functions in smp_pv.c

[Vitaly Kuznetsov]

After code split between PV and HVM some functions in xen_smp_ops have
xen_pv_ prefix and some only xen_ which makes them look like they're
common for both PV and HVM while they're not. Rename all the rest to
have xen_pv_ prefix.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Juergen Gross 
---
 arch/x86/xen/smp_pv.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index 3a61e0e..39b130f 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -221,7 +221,7 @@ static void __init xen_pv_smp_prepare_boot_cpu(void)
xen_init_spinlocks();
 }
 
-static void __init xen_smp_prepare_cpus(unsigned int max_cpus)
+static void __init xen_pv_smp_prepare_cpus(unsigned int max_cpus)
 {
unsigned cpu;
unsigned int i;
@@ -337,7 +337,7 @@ cpu_initialize_context(unsigned int cpu, struct task_struct 
*idle)
return 0;
 }
 
-static int xen_cpu_up(unsigned int cpu, struct task_struct *idle)
+static int xen_pv_cpu_up(unsigned int cpu, struct task_struct *idle)
 {
int rc;
 
@@ -371,12 +371,12 @@ static int xen_cpu_up(unsigned int cpu, struct 
task_struct *idle)
return 0;
 }
 
-static void xen_smp_cpus_done(unsigned int max_cpus)
+static void xen_pv_smp_cpus_done(unsigned int max_cpus)
 {
 }
 
 #ifdef CONFIG_HOTPLUG_CPU
-static int xen_cpu_disable(void)
+static int xen_pv_cpu_disable(void)
 {
unsigned int cpu = smp_processor_id();
if (cpu == 0)
@@ -404,7 +404,7 @@ static void xen_pv_cpu_die(unsigned int cpu)
}
 }
 
-static void xen_play_dead(void) /* used only with HOTPLUG_CPU */
+static void xen_pv_play_dead(void) /* used only with HOTPLUG_CPU */
 {
play_dead_common();
HYPERVISOR_vcpu_op(VCPUOP_down, xen_vcpu_nr(smp_processor_id()), NULL);
@@ -421,7 +421,7 @@ static void xen_play_dead(void) /* used only with 
HOTPLUG_CPU */
 }
 
 #else /* !CONFIG_HOTPLUG_CPU */
-static int xen_cpu_disable(void)
+static int xen_pv_cpu_disable(void)
 {
return -ENOSYS;
 }
@@ -431,7 +431,7 @@ static void xen_pv_cpu_die(unsigned int cpu)
BUG();
 }
 
-static void xen_play_dead(void)
+static void xen_pv_play_dead(void)
 {
BUG();
 }
@@ -451,7 +451,7 @@ static void stop_self(void *v)
BUG();
 }
 
-static void xen_stop_other_cpus(int wait)
+static void xen_pv_stop_other_cpus(int wait)
 {
smp_call_function(stop_self, NULL, wait);
 }
@@ -478,15 +478,15 @@ static irqreturn_t xen_irq_work_interrupt(int irq, void 
*dev_id)
 
 static const struct smp_ops xen_smp_ops __initconst = {
.smp_prepare_boot_cpu = xen_pv_smp_prepare_boot_cpu,
-   .smp_prepare_cpus = xen_smp_prepare_cpus,
-   .smp_cpus_done = xen_smp_cpus_done,
+   .smp_prepare_cpus = xen_pv_smp_prepare_cpus,
+   .smp_cpus_done = xen_pv_smp_cpus_done,
 
-   .cpu_up = xen_cpu_up,
+   .cpu_up = xen_pv_cpu_up,
.cpu_die = xen_pv_cpu_die,
-   .cpu_disable = xen_cpu_disable,
-   .play_dead = xen_play_dead,
+   .cpu_disable = xen_pv_cpu_disable,
+   .play_dead = xen_pv_play_dead,
 
-   .stop_other_cpus = xen_stop_other_cpus,
+   .stop_other_cpus = xen_pv_stop_other_cpus,
.smp_send_reschedule = xen_smp_send_reschedule,
 
.send_call_func_ipi = xen_smp_send_call_function_ipi,
-- 
2.9.3


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

[Xen-devel] [PATCH v3 15/21] x86/xen: put setup.c, pmu.c and apic.c under CONFIG_XEN_PV

[Vitaly Kuznetsov]

xen_pmu_init/finish() functions are used in suspend.c and
enlighten.c, add stubs for now.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Juergen Gross 
---
 arch/x86/xen/Kconfig  | 2 +-
 arch/x86/xen/Makefile | 6 +++---
 arch/x86/xen/pmu.h| 5 +
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 6d15c34..3bcb091 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -6,7 +6,6 @@ config XEN
bool "Xen guest support"
depends on PARAVIRT
select PARAVIRT_CLOCK
-   select XEN_HAVE_VPMU
depends on X86_64 || (X86_32 && X86_PAE)
depends on X86_LOCAL_APIC && X86_TSC
help
@@ -19,6 +18,7 @@ config XEN_PV
default y
depends on XEN
select XEN_HAVE_PVMMU
+   select XEN_HAVE_VPMU
help
  Support running as a Xen PV guest.
 
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index cf8d6c5..f610651 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -10,13 +10,13 @@ nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_enlighten_pv.o  := $(nostackp)
 CFLAGS_mmu_pv.o:= $(nostackp)
 
-obj-y  := enlighten.o setup.o multicalls.o mmu.o irq.o \
+obj-y  := enlighten.o multicalls.o mmu.o irq.o \
time.o xen-asm.o xen-asm_$(BITS).o \
grant-table.o suspend.o platform-pci-unplug.o \
-   p2m.o apic.o pmu.o enlighten_pv.o mmu_pv.o
+   p2m.o enlighten_pv.o mmu_pv.o
 
 obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o mmu_hvm.o 
suspend_hvm.o
-obj-$(CONFIG_XEN_PV)   += suspend_pv.o
+obj-$(CONFIG_XEN_PV)   += setup.o apic.o pmu.o suspend_pv.o
 obj-$(CONFIG_XEN_PVH)  += enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
diff --git a/arch/x86/xen/pmu.h b/arch/x86/xen/pmu.h
index af5f0ad..4be5355 100644
--- a/arch/x86/xen/pmu.h
+++ b/arch/x86/xen/pmu.h
@@ -4,8 +4,13 @@
 #include 
 
 irqreturn_t xen_pmu_irq_handler(int irq, void *dev_id);
+#ifdef CONFIG_XEN_HAVE_VPMU
 void xen_pmu_init(int cpu);
 void xen_pmu_finish(int cpu);
+#else
+static inline void xen_pmu_init(int cpu) {}
+static inline void xen_pmu_finish(int cpu) {}
+#endif
 bool is_xen_pmu(int cpu);
 bool pmu_msr_read(unsigned int msr, uint64_t *val, int *err);
 bool pmu_msr_write(unsigned int msr, uint32_t low, uint32_t high, int *err);
-- 
2.9.3


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

[Xen-devel] [PATCH v3 16/21] x86/xen: define startup_xen for XEN PV only

[Vitaly Kuznetsov]

startup_xen references PV-only code, decorate it with #ifdef CONFIG_XEN_PV
to make PV-free builds possible.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Juergen Gross 
---
 arch/x86/xen/xen-head.S | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 37794e4..72a8e6a 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -16,6 +16,7 @@
 #include 
 #include 
 
+#ifdef CONFIG_XEN_PV
__INIT
 ENTRY(startup_xen)
cld
@@ -34,6 +35,7 @@ ENTRY(startup_xen)
jmp xen_start_kernel
 
__FINIT
+#endif
 
 .pushsection .text
.balign PAGE_SIZE
@@ -58,7 +60,9 @@ ENTRY(hypercall_page)
/* Map the p2m table to a 512GB-aligned user address. */
ELFNOTE(Xen, XEN_ELFNOTE_INIT_P2M,   .quad PGDIR_SIZE)
 #endif
+#ifdef CONFIG_XEN_PV
ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,  _ASM_PTR startup_xen)
+#endif
ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,
.ascii "!writable_page_tables|pae_pgdir_above_4gb")
-- 
2.9.3


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

[Xen-devel] [PATCH v3 10/21] x86/xen: split off smp_hvm.c

[Vitaly Kuznetsov]

Move PVHVM related code to smp_hvm.c. Drop 'static' qualifier from
xen_smp_send_reschedule(), xen_smp_send_call_function_ipi(),
xen_smp_send_call_function_single_ipi(), these functions will be moved to
common smp code when smp_pv.c is split.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Juergen Gross 
---
Changes since v2:
drop 'extern' qualifier newly added prototypes to smp.h [Juergen Gross]
---
 arch/x86/xen/Kconfig   |  4 
 arch/x86/xen/Makefile  |  1 +
 arch/x86/xen/smp.c | 57 +++--
 arch/x86/xen/smp.h |  3 +++
 arch/x86/xen/smp_hvm.c | 58 ++
 5 files changed, 69 insertions(+), 54 deletions(-)
 create mode 100644 arch/x86/xen/smp_hvm.c

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 5bb1434..6d15c34 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -37,6 +37,10 @@ config XEN_PVHVM
help
  Support running as a Xen PVHVM guest.
 
+config XEN_PVHVM_SMP
+   def_bool y
+   depends on XEN_PVHVM && SMP
+
 config XEN_512GB
bool "Limit Xen pv-domain memory to 512GB"
depends on XEN_PV && X86_64
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 5ca8d3eb..bc7df8c 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_XEN_PVH) += enlighten_pvh.o
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
 obj-$(CONFIG_SMP)  += smp.o
+obj-$(CONFIG_XEN_PVHVM_SMP)+= smp_hvm.o
 obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
 obj-$(CONFIG_XEN_DEBUG_FS) += debugfs.o
 obj-$(CONFIG_XEN_DOM0) += vga.o
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 53bf0a4..5939592 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -328,25 +328,6 @@ static void __init xen_pv_smp_prepare_boot_cpu(void)
xen_init_spinlocks();
 }
 
-static void __init xen_hvm_smp_prepare_boot_cpu(void)
-{
-   BUG_ON(smp_processor_id() != 0);
-   native_smp_prepare_boot_cpu();
-
-   /*
-* Setup vcpu_info for boot CPU.
-*/
-   xen_vcpu_setup(0);
-
-   /*
-* The alternative logic (which patches the unlock/lock) runs before
-* the smp bootup up code is activated. Hence we need to set this up
-* the core kernel is being patched. Otherwise we will have only
-* modules patched but not core code.
-*/
-   xen_init_spinlocks();
-}
-
 static void __init xen_smp_prepare_cpus(unsigned int max_cpus)
 {
unsigned cpu;
@@ -530,15 +511,6 @@ static void xen_pv_cpu_die(unsigned int cpu)
}
 }
 
-static void xen_hvm_cpu_die(unsigned int cpu)
-{
-   if (common_cpu_die(cpu) == 0) {
-   xen_smp_intr_free(cpu);
-   xen_uninit_lock_cpu(cpu);
-   xen_teardown_timer(cpu);
-   }
-}
-
 static void xen_play_dead(void) /* used only with HOTPLUG_CPU */
 {
play_dead_common();
@@ -566,11 +538,6 @@ static void xen_pv_cpu_die(unsigned int cpu)
BUG();
 }
 
-static void xen_hvm_cpu_die(unsigned int cpu)
-{
-   BUG();
-}
-
 static void xen_play_dead(void)
 {
BUG();
@@ -596,7 +563,7 @@ static void xen_stop_other_cpus(int wait)
smp_call_function(stop_self, NULL, wait);
 }
 
-static void xen_smp_send_reschedule(int cpu)
+void xen_smp_send_reschedule(int cpu)
 {
xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
 }
@@ -610,7 +577,7 @@ static void __xen_send_IPI_mask(const struct cpumask *mask,
xen_send_IPI_one(cpu, vector);
 }
 
-static void xen_smp_send_call_function_ipi(const struct cpumask *mask)
+void xen_smp_send_call_function_ipi(const struct cpumask *mask)
 {
int cpu;
 
@@ -625,7 +592,7 @@ static void xen_smp_send_call_function_ipi(const struct 
cpumask *mask)
}
 }
 
-static void xen_smp_send_call_function_single_ipi(int cpu)
+void xen_smp_send_call_function_single_ipi(int cpu)
 {
__xen_send_IPI_mask(cpumask_of(cpu),
  XEN_CALL_FUNCTION_SINGLE_VECTOR);
@@ -763,21 +730,3 @@ void __init xen_smp_init(void)
smp_ops = xen_smp_ops;
xen_fill_possible_map();
 }
-
-static void __init xen_hvm_smp_prepare_cpus(unsigned int max_cpus)
-{
-   native_smp_prepare_cpus(max_cpus);
-   WARN_ON(xen_smp_intr_init(0));
-
-   xen_init_lock_cpu(0);
-}
-
-void __init xen_hvm_smp_init(void)
-{
-   smp_ops.smp_prepare_cpus = xen_hvm_smp_prepare_cpus;
-   smp_ops.smp_send_reschedule = xen_smp_send_reschedule;
-   smp_ops.cpu_die = xen_hvm_cpu_die;
-   smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi;
-   smp_ops.send_call_func_single_ipi = 
xen_smp_send_call_function_single_ipi;
-   smp_ops.smp_prepare_boot_cpu = xen_hvm_smp_prepare_boot_cpu;
-}
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
index 33320ce..2e8cd56 100644
--- a/arch/x86/xen/smp.h
+++ b/arch/x86/xen/smp.h
@@ -14,6 +14,9 @@ extern void 

[Xen-devel] [PATCH v3 20/21] x86/xen: enable PVHVM-only builds

[Vitaly Kuznetsov]

Now everything is in place and we can move PV-only code under
CONFIG_XEN_PV. CONFIG_XEN_PV_SMP is created to support the change.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Juergen Gross 
---
 arch/x86/xen/Kconfig  | 4 
 arch/x86/xen/Makefile | 9 +
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 3bcb091..0279876 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -22,6 +22,10 @@ config XEN_PV
help
  Support running as a Xen PV guest.
 
+config XEN_PV_SMP
+   def_bool y
+   depends on XEN_PV && SMP
+
 config XEN_DOM0
bool "Xen PV Dom0 support"
default y
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index f610651..fffb0a1 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -12,16 +12,17 @@ CFLAGS_mmu_pv.o := $(nostackp)
 
 obj-y  := enlighten.o multicalls.o mmu.o irq.o \
time.o xen-asm.o xen-asm_$(BITS).o \
-   grant-table.o suspend.o platform-pci-unplug.o \
-   p2m.o enlighten_pv.o mmu_pv.o
+   grant-table.o suspend.o platform-pci-unplug.o
 
 obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o mmu_hvm.o 
suspend_hvm.o
-obj-$(CONFIG_XEN_PV)   += setup.o apic.o pmu.o suspend_pv.o
+obj-$(CONFIG_XEN_PV)   += setup.o apic.o pmu.o suspend_pv.o \
+   p2m.o enlighten_pv.o mmu_pv.o
 obj-$(CONFIG_XEN_PVH)  += enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
-obj-$(CONFIG_SMP)  += smp.o smp_pv.o
+obj-$(CONFIG_SMP)  += smp.o
+obj-$(CONFIG_XEN_PV_SMP)   += smp_pv.o
 obj-$(CONFIG_XEN_PVHVM_SMP)+= smp_hvm.o
 obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
 obj-$(CONFIG_XEN_DEBUG_FS) += debugfs.o
-- 
2.9.3


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

[Xen-devel] [PATCH v3 00/21] x86/xen: untangle PV and PVHVM guest support code

[Vitaly Kuznetsov]

Changes since v2:
- Rebase to 4.11.0-rc1+
- XEN_HAVE_PVMMU moved to config XEN_PV [Juergen Gross]
- .pin_vcpu kept for x86_hyper_xen_hvm to support PVH Dom0 in future
   [Juergen Gross]
- 'extern' qualifiers dropped from newly introduced function prototypes
  in headers [Juergen Gross]
- A couple of #includes added to address build issues with different
  configs [kbuild test robot].
- Juergen reviewed-bys added (hope they stand with the above mentioned
  changes).

The series can also be pulled from https://github.com/vittyvk/linux.git
 (xen_pv_hvm_split_v3 branch).

Some patches are known to produce checkpatch.pl WARNINGS and a couple of
ERRORs, I fixed a few (mostly in _hvm* code I split) and I refrained from
fixing the rest to make it easier to review. I think that we may leave PV
code as it is as sooner or later it will go away.

Original description:

I have a long-standing idea to separate PV and PVHVM code in kernel and 
introduce Kconfig options to make it possible to enable the required
parts only breaking the current 'all or nothing' approach.

Motivation:
- Xen related x86 code in kernel is rather big and it is unclear which
  parts of it are required for PV, for HVM or for both. With PVH coming
  into picture is becomes even more tangled. It makes it hard to
  understand/audit the code.

- In some case we may want to avoid bloating kernel by supporting Xen
  guests we don't need. In particular, 90% of the code in arch/x86/xen/ is
  required to support PV guests and one may require PVHVM support only.

- PV guests are supposed to go away one day and such code separation would
  help us to get ready.

This series adds XEN_PV Kconfig option and makes it possible to build PV-only
and PVHVM-only kernels. It also makes it possible to disable Dom0 support.

Some patches are rather big but this is mostly just moving code around, no
functional changes intended. I smoke tested it with PV-only and PVHVM-only
builds, booted and did save/restore test. I also tried the newly introduced
PVHv2 guest, it even worked!

Vitaly Kuznetsov (21):
  x86/xen: separate PV and HVM hypervisors
  x86/xen: globalize have_vcpu_info_placement
  x86/xen: add CONFIG_XEN_PV to Kconfig
  x86/xen: split off enlighten_pvh.c
  x86/xen: split off enlighten_hvm.c
  x86/xen: split off enlighten_pv.c
  x86/xen: split xen_smp_intr_init()/xen_smp_intr_free()
  x86/xen: split xen_smp_prepare_boot_cpu()
  x86/xen: split xen_cpu_die()
  x86/xen: split off smp_hvm.c
  x86/xen: split off smp_pv.c
  x86/xen: split off mmu_hvm.c
  x86/xen: split off mmu_pv.c
  x86/xen: split suspend.c for PV and PVHVM guests
  x86/xen: put setup.c, pmu.c and apic.c under CONFIG_XEN_PV
  x86/xen: define startup_xen for XEN PV only
  x86/xen: create stubs for HVM-only builds in page.h
  xen/balloon: decorate PV-only parts with #ifdef CONFIG_XEN_PV
  xen: create xen_create/destroy_contiguous_region() stubs for PVHVM
only builds
  x86/xen: enable PVHVM-only builds
  x86/xen: rename some PV-only functions in smp_pv.c

 arch/x86/include/asm/hypervisor.h |3 +-
 arch/x86/include/asm/xen/page.h   |   25 +
 arch/x86/kernel/cpu/hypervisor.c  |7 +-
 arch/x86/kernel/process_64.c  |2 +-
 arch/x86/xen/Kconfig  |   33 +-
 arch/x86/xen/Makefile |   16 +-
 arch/x86/xen/enlighten.c  | 1925 +
 arch/x86/xen/enlighten_hvm.c  |  213 +++
 arch/x86/xen/enlighten_pv.c   | 1522 
 arch/x86/xen/enlighten_pvh.c  |  115 ++
 arch/x86/xen/mmu.c| 2776 +
 arch/x86/xen/mmu_hvm.c|   79 ++
 arch/x86/xen/mmu_pv.c | 2635 +++
 arch/x86/xen/pmu.h|5 +
 arch/x86/xen/smp.c|  517 +--
 arch/x86/xen/smp.h|   16 +
 arch/x86/xen/smp_hvm.c|   58 +
 arch/x86/xen/smp_pv.c |  500 +++
 arch/x86/xen/suspend.c|   54 -
 arch/x86/xen/suspend_hvm.c|   22 +
 arch/x86/xen/suspend_pv.c |   46 +
 arch/x86/xen/xen-head.S   |4 +
 arch/x86/xen/xen-ops.h|   23 +
 drivers/xen/balloon.c |   30 +-
 include/xen/xen-ops.h |   14 +
 25 files changed, 5461 insertions(+), 5179 deletions(-)
 create mode 100644 arch/x86/xen/enlighten_hvm.c
 create mode 100644 arch/x86/xen/enlighten_pv.c
 create mode 100644 arch/x86/xen/enlighten_pvh.c
 create mode 100644 arch/x86/xen/mmu_hvm.c
 create mode 100644 arch/x86/xen/mmu_pv.c
 create mode 100644 arch/x86/xen/smp_hvm.c
 create mode 100644 arch/x86/xen/smp_pv.c
 create mode 100644 arch/x86/xen/suspend_hvm.c
 create mode 100644 arch/x86/xen/suspend_pv.c

-- 
2.9.3


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

[Xen-devel] [PATCH v3 12/21] x86/xen: split off mmu_hvm.c

[Vitaly Kuznetsov]

Move PVHVM related code to mmu_hvm.c.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Juergen Gross 
---
 arch/x86/xen/Makefile  |  2 +-
 arch/x86/xen/mmu.c | 74 --
 arch/x86/xen/mmu_hvm.c | 79 ++
 3 files changed, 80 insertions(+), 75 deletions(-)
 create mode 100644 arch/x86/xen/mmu_hvm.c

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index ebf3522..6a95a8b 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -15,7 +15,7 @@ obj-y := enlighten.o setup.o multicalls.o mmu.o irq.o 
\
grant-table.o suspend.o platform-pci-unplug.o \
p2m.o apic.o pmu.o enlighten_pv.o
 
-obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o
+obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o mmu_hvm.o
 obj-$(CONFIG_XEN_PVH)  += enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 37cb5aa..d7b9286 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2689,80 +2689,6 @@ void xen_destroy_contiguous_region(phys_addr_t pstart, 
unsigned int order)
 }
 EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
 
-#ifdef CONFIG_XEN_PVHVM
-#ifdef CONFIG_PROC_VMCORE
-/*
- * This function is used in two contexts:
- * - the kdump kernel has to check whether a pfn of the crashed kernel
- *   was a ballooned page. vmcore is using this function to decide
- *   whether to access a pfn of the crashed kernel.
- * - the kexec kernel has to check whether a pfn was ballooned by the
- *   previous kernel. If the pfn is ballooned, handle it properly.
- * Returns 0 if the pfn is not backed by a RAM page, the caller may
- * handle the pfn special in this case.
- */
-static int xen_oldmem_pfn_is_ram(unsigned long pfn)
-{
-   struct xen_hvm_get_mem_type a = {
-   .domid = DOMID_SELF,
-   .pfn = pfn,
-   };
-   int ram;
-
-   if (HYPERVISOR_hvm_op(HVMOP_get_mem_type, ))
-   return -ENXIO;
-
-   switch (a.mem_type) {
-   case HVMMEM_mmio_dm:
-   ram = 0;
-   break;
-   case HVMMEM_ram_rw:
-   case HVMMEM_ram_ro:
-   default:
-   ram = 1;
-   break;
-   }
-
-   return ram;
-}
-#endif
-
-static void xen_hvm_exit_mmap(struct mm_struct *mm)
-{
-   struct xen_hvm_pagetable_dying a;
-   int rc;
-
-   a.domid = DOMID_SELF;
-   a.gpa = __pa(mm->pgd);
-   rc = HYPERVISOR_hvm_op(HVMOP_pagetable_dying, );
-   WARN_ON_ONCE(rc < 0);
-}
-
-static int is_pagetable_dying_supported(void)
-{
-   struct xen_hvm_pagetable_dying a;
-   int rc = 0;
-
-   a.domid = DOMID_SELF;
-   a.gpa = 0x00;
-   rc = HYPERVISOR_hvm_op(HVMOP_pagetable_dying, );
-   if (rc < 0) {
-   printk(KERN_DEBUG "HVMOP_pagetable_dying not supported\n");
-   return 0;
-   }
-   return 1;
-}
-
-void __init xen_hvm_init_mmu_ops(void)
-{
-   if (is_pagetable_dying_supported())
-   pv_mmu_ops.exit_mmap = xen_hvm_exit_mmap;
-#ifdef CONFIG_PROC_VMCORE
-   register_oldmem_pfn_is_ram(_oldmem_pfn_is_ram);
-#endif
-}
-#endif
-
 #define REMAP_BATCH_SIZE 16
 
 struct remap_data {
diff --git a/arch/x86/xen/mmu_hvm.c b/arch/x86/xen/mmu_hvm.c
new file mode 100644
index 000..1c57f1c
--- /dev/null
+++ b/arch/x86/xen/mmu_hvm.c
@@ -0,0 +1,79 @@
+#include 
+#include 
+
+#include 
+#include 
+
+#include "mmu.h"
+
+#ifdef CONFIG_PROC_VMCORE
+/*
+ * This function is used in two contexts:
+ * - the kdump kernel has to check whether a pfn of the crashed kernel
+ *   was a ballooned page. vmcore is using this function to decide
+ *   whether to access a pfn of the crashed kernel.
+ * - the kexec kernel has to check whether a pfn was ballooned by the
+ *   previous kernel. If the pfn is ballooned, handle it properly.
+ * Returns 0 if the pfn is not backed by a RAM page, the caller may
+ * handle the pfn special in this case.
+ */
+static int xen_oldmem_pfn_is_ram(unsigned long pfn)
+{
+   struct xen_hvm_get_mem_type a = {
+   .domid = DOMID_SELF,
+   .pfn = pfn,
+   };
+   int ram;
+
+   if (HYPERVISOR_hvm_op(HVMOP_get_mem_type, ))
+   return -ENXIO;
+
+   switch (a.mem_type) {
+   case HVMMEM_mmio_dm:
+   ram = 0;
+   break;
+   case HVMMEM_ram_rw:
+   case HVMMEM_ram_ro:
+   default:
+   ram = 1;
+   break;
+   }
+
+   return ram;
+}
+#endif
+
+static void xen_hvm_exit_mmap(struct mm_struct *mm)
+{
+   struct xen_hvm_pagetable_dying a;
+   int rc;
+
+   a.domid = DOMID_SELF;
+   a.gpa = __pa(mm->pgd);
+   rc = HYPERVISOR_hvm_op(HVMOP_pagetable_dying, );
+   WARN_ON_ONCE(rc < 0);
+}
+
+static 

[Xen-devel] [PATCH v3 06/21] x86/xen: split off enlighten_pv.c

[Vitaly Kuznetsov]

Basically, enlighten.c is renamed to enlighten_pv.c and some code moved
out to common enlighten.c.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Juergen Gross 
---
Changes since v2:
   xen_pin_vcpu() left in enlighten.c
---
 arch/x86/xen/Makefile   |4 +-
 arch/x86/xen/enlighten.c| 1647 ++-
 arch/x86/xen/enlighten_pv.c | 1513 +++
 3 files changed, 1587 insertions(+), 1577 deletions(-)
 create mode 100644 arch/x86/xen/enlighten_pv.c

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 1bca75b..5ca8d3eb 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -7,13 +7,13 @@ endif
 
 # Make sure early boot has no stackprotector
 nostackp := $(call cc-option, -fno-stack-protector)
-CFLAGS_enlighten.o := $(nostackp)
+CFLAGS_enlighten_pv.o  := $(nostackp)
 CFLAGS_mmu.o   := $(nostackp)
 
 obj-y  := enlighten.o setup.o multicalls.o mmu.o irq.o \
time.o xen-asm.o xen-asm_$(BITS).o \
grant-table.o suspend.o platform-pci-unplug.o \
-   p2m.o apic.o pmu.o
+   p2m.o apic.o pmu.o enlighten_pv.o
 
 obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o
 obj-$(CONFIG_XEN_PVH)  += enlighten_pvh.o
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 6054364..cb2c5064 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1,92 +1,15 @@
-/*
- * Core of Xen paravirt_ops implementation.
- *
- * This file contains the xen_paravirt_ops structure itself, and the
- * implementations for:
- * - privileged instructions
- * - interrupt flags
- * - segment operations
- * - booting and setup
- *
- * Jeremy Fitzhardinge , XenSource Inc, 2007
- */
-
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
 #include 
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
-#include 
-#include 
 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 
-#ifdef CONFIG_ACPI
-#include 
-#include 
-#include 
-#include 
-#include 
-#endif
-
 #include "xen-ops.h"
-#include "mmu.h"
 #include "smp.h"
-#include "multicalls.h"
 #include "pmu.h"
 
 EXPORT_SYMBOL_GPL(hypercall_page);
@@ -133,14 +56,6 @@ EXPORT_SYMBOL_GPL(xen_start_info);
 
 struct shared_info xen_dummy_shared_info;
 
-void *xen_initial_gdt;
-
-RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
-
-static int xen_cpu_up_prepare_pv(unsigned int cpu);
-static int xen_cpu_up_online(unsigned int cpu);
-static int xen_cpu_dead_pv(unsigned int cpu);
-
 /*
  * Point at some empty memory to start with. We map the real shared_info
  * page as soon as fixmap is up and running.
@@ -162,18 +77,30 @@ struct shared_info *HYPERVISOR_shared_info = 
_dummy_shared_info;
  */
 int xen_have_vcpu_info_placement = 1;
 
-struct tls_descs {
-   struct desc_struct desc[3];
-};
+static int xen_cpu_up_online(unsigned int cpu)
+{
+   xen_init_lock_cpu(cpu);
+   return 0;
+}
 
-/*
- * Updating the 3 TLS descriptors in the GDT on every task switch is
- * surprisingly expensive so we avoid updating them if they haven't
- * changed.  Since Xen writes different descriptors than the one
- * passed in the update_descriptor hypercall we keep shadow copies to
- * compare against.
- */
-static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
+int xen_cpuhp_setup(int (*cpu_up_prepare_cb)(unsigned int),
+   int (*cpu_dead_cb)(unsigned int))
+{
+   int rc;
+
+   rc = cpuhp_setup_state_nocalls(CPUHP_XEN_PREPARE,
+  "x86/xen/hvm_guest:prepare",
+  cpu_up_prepare_cb, cpu_dead_cb);
+   if (rc >= 0) {
+   rc = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
+  "x86/xen/hvm_guest:online",
+  xen_cpu_up_online, NULL);
+   if (rc < 0)
+   cpuhp_remove_state_nocalls(CPUHP_XEN_PREPARE);
+   }
+
+   return rc >= 0 ? 0 : rc;
+}
 
 static void clamp_max_cpus(void)
 {
@@ -242,1511 +169,81 @@ void xen_vcpu_setup(int cpu)
}
 }
 
-/*
- * On restore, set the vcpu placement up again.
- * If it fails, then we're in a bad state, since
- * we can't back out from using it...
- */
-void xen_vcpu_restore(void)
+void xen_reboot(int reason)
 {
+   struct sched_shutdown r = { .reason = reason 

[Xen-devel] [PATCH v3 11/21] x86/xen: split off smp_pv.c

[Vitaly Kuznetsov]

Basically, smp.c is renamed to smp_pv.c and some code moved out to common
smp.c. struct xen_common_irq delcaration ended up in smp.h.

Reviewed-by: Juergen Gross 
Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/xen/Makefile |   2 +-
 arch/x86/xen/smp.c| 488 +---
 arch/x86/xen/smp.h|   5 +
 arch/x86/xen/smp_pv.c | 500 ++
 4 files changed, 509 insertions(+), 486 deletions(-)
 create mode 100644 arch/x86/xen/smp_pv.c

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index bc7df8c..ebf3522 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -20,7 +20,7 @@ obj-$(CONFIG_XEN_PVH) += enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
-obj-$(CONFIG_SMP)  += smp.o
+obj-$(CONFIG_SMP)  += smp.o smp_pv.o
 obj-$(CONFIG_XEN_PVHVM_SMP)+= smp_hvm.o
 obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
 obj-$(CONFIG_XEN_DEBUG_FS) += debugfs.o
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 5939592..82ac611 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -1,63 +1,21 @@
-/*
- * Xen SMP support
- *
- * This file implements the Xen versions of smp_ops.  SMP under Xen is
- * very straightforward.  Bringing a CPU up is simply a matter of
- * loading its initial context and setting it running.
- *
- * IPIs are handled through the Xen event mechanism.
- *
- * Because virtual CPUs can be scheduled onto any real CPU, there's no
- * useful topology information for the kernel to make use of.  As a
- * result, all CPUs are treated as if they're single-core and
- * single-threaded.
- */
-#include 
-#include 
-#include 
 #include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-
-#include 
-#include 
+#include 
+#include 
+#include 
 
-#include 
-#include 
 #include 
 
 #include 
 #include "xen-ops.h"
-#include "mmu.h"
 #include "smp.h"
-#include "pmu.h"
-
-cpumask_var_t xen_cpu_initialized_map;
 
-struct xen_common_irq {
-   int irq;
-   char *name;
-};
 static DEFINE_PER_CPU(struct xen_common_irq, xen_resched_irq) = { .irq = -1 };
 static DEFINE_PER_CPU(struct xen_common_irq, xen_callfunc_irq) = { .irq = -1 };
 static DEFINE_PER_CPU(struct xen_common_irq, xen_callfuncsingle_irq) = { .irq 
= -1 };
-static DEFINE_PER_CPU(struct xen_common_irq, xen_irq_work) = { .irq = -1 };
 static DEFINE_PER_CPU(struct xen_common_irq, xen_debug_irq) = { .irq = -1 };
-static DEFINE_PER_CPU(struct xen_common_irq, xen_pmu_irq) = { .irq = -1 };
 
 static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id);
 static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id);
-static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id);
 
 /*
  * Reschedule call back.
@@ -70,42 +28,6 @@ static irqreturn_t xen_reschedule_interrupt(int irq, void 
*dev_id)
return IRQ_HANDLED;
 }
 
-static void cpu_bringup(void)
-{
-   int cpu;
-
-   cpu_init();
-   touch_softlockup_watchdog();
-   preempt_disable();
-
-   /* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
-   if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
-   xen_enable_sysenter();
-   xen_enable_syscall();
-   }
-   cpu = smp_processor_id();
-   smp_store_cpu_info(cpu);
-   cpu_data(cpu).x86_max_cores = 1;
-   set_cpu_sibling_map(cpu);
-
-   xen_setup_cpu_clockevents();
-
-   notify_cpu_starting(cpu);
-
-   set_cpu_online(cpu, true);
-
-   cpu_set_state_online(cpu);  /* Implies full memory barrier. */
-
-   /* We can take interrupts now: we're officially "up". */
-   local_irq_enable();
-}
-
-asmlinkage __visible void cpu_bringup_and_idle(void)
-{
-   cpu_bringup();
-   cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
-}
-
 void xen_smp_intr_free(unsigned int cpu)
 {
if (per_cpu(xen_resched_irq, cpu).irq >= 0) {
@@ -135,23 +57,6 @@ void xen_smp_intr_free(unsigned int cpu)
}
 }
 
-void xen_smp_intr_free_pv(unsigned int cpu)
-{
-   if (per_cpu(xen_irq_work, cpu).irq >= 0) {
-   unbind_from_irqhandler(per_cpu(xen_irq_work, cpu).irq, NULL);
-   per_cpu(xen_irq_work, cpu).irq = -1;
-   kfree(per_cpu(xen_irq_work, cpu).name);
-   per_cpu(xen_irq_work, cpu).name = NULL;
-   }
-
-   if (per_cpu(xen_pmu_irq, cpu).irq >= 0) {
-   unbind_from_irqhandler(per_cpu(xen_pmu_irq, cpu).irq, NULL);
-   per_cpu(xen_pmu_irq, cpu).irq = -1;
-   kfree(per_cpu(xen_pmu_irq, cpu).name);
-   per_cpu(xen_pmu_irq, cpu).name = NULL;
-   }
-}
-
 int xen_smp_intr_init(unsigned int cpu)
 {
int rc;
@@ -209,360 +114,6 @@ int xen_smp_intr_init(unsigned int cpu)
return rc;
 }
 
-int xen_smp_intr_init_pv(unsigned int cpu)
-{
-   int rc;
-   char 

[Xen-devel] [PATCH v3 17/21] x86/xen: create stubs for HVM-only builds in page.h

[Vitaly Kuznetsov]

__pfn_to_mfn() is only used from PV code (mmu_pv.c, p2m.c) and from
page.h where all functions calling it check for
xen_feature(XENFEAT_auto_translated_physmap) first so we can replace
it with any stub to make build happy.

set_foreign_p2m_mapping()/clear_foreign_p2m_mapping() are used from
grant-table.c but only if !xen_feature(XENFEAT_auto_translated_physmap).

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Juergen Gross 
---
 arch/x86/include/asm/xen/page.h | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 33cbd3d..0bf4bb34 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -51,12 +51,30 @@ extern bool __set_phys_to_machine(unsigned long pfn, 
unsigned long mfn);
 extern unsigned long __init set_phys_range_identity(unsigned long pfn_s,
unsigned long pfn_e);
 
+#ifdef CONFIG_XEN_PV
 extern int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
   struct gnttab_map_grant_ref *kmap_ops,
   struct page **pages, unsigned int count);
 extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 struct gnttab_unmap_grant_ref *kunmap_ops,
 struct page **pages, unsigned int count);
+#else
+static inline int
+set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
+   struct gnttab_map_grant_ref *kmap_ops,
+   struct page **pages, unsigned int count)
+{
+   return 0;
+}
+
+static inline int
+clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
+ struct gnttab_unmap_grant_ref *kunmap_ops,
+ struct page **pages, unsigned int count)
+{
+   return 0;
+}
+#endif
 
 /*
  * Helper functions to write or read unsigned long values to/from
@@ -72,6 +90,7 @@ static inline int xen_safe_read_ulong(unsigned long *addr, 
unsigned long *val)
return __get_user(*val, (unsigned long __user *)addr);
 }
 
+#ifdef CONFIG_XEN_PV
 /*
  * When to use pfn_to_mfn(), __pfn_to_mfn() or get_phys_to_machine():
  * - pfn_to_mfn() returns either INVALID_P2M_ENTRY or the mfn. No indicator
@@ -98,6 +117,12 @@ static inline unsigned long __pfn_to_mfn(unsigned long pfn)
 
return mfn;
 }
+#else
+static inline unsigned long __pfn_to_mfn(unsigned long pfn)
+{
+   return pfn;
+}
+#endif
 
 static inline unsigned long pfn_to_mfn(unsigned long pfn)
 {
-- 
2.9.3


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

[Xen-devel] [PATCH v3 03/21] x86/xen: add CONFIG_XEN_PV to Kconfig

[Vitaly Kuznetsov]

All code to support Xen PV will get under this new option. For the
beginning, check for it in the common code.

Signed-off-by: Vitaly Kuznetsov 
---
Changes since v2:
   select XEN_HAVE_PVMMU moved to config XEN_PV [Juergen Gross]
---
 arch/x86/kernel/cpu/hypervisor.c |  4 +++-
 arch/x86/kernel/process_64.c |  2 +-
 arch/x86/xen/Kconfig | 23 ++-
 3 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index a77f18d..ce6fcc3 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -28,8 +28,10 @@
 
 static const __initconst struct hypervisor_x86 * const hypervisors[] =
 {
-#ifdef CONFIG_XEN
+#ifdef CONFIG_XEN_PV
_hyper_xen_pv,
+#endif
+#ifdef CONFIG_XEN_PVHVM
_hyper_xen_hvm,
 #endif
_hyper_vmware,
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index d6b784a..338ed9a 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -440,7 +440,7 @@ __switch_to(struct task_struct *prev_p, struct task_struct 
*next_p)
 task_thread_info(prev_p)->flags & _TIF_WORK_CTXSW_PREV))
__switch_to_xtra(prev_p, next_p, tss);
 
-#ifdef CONFIG_XEN
+#ifdef CONFIG_XEN_PV
/*
 * On Xen PV, IOPL bits in pt_regs->flags have no effect, and
 * current_pt_regs()->flags may not match the current task's
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 76b6dbd..5bb1434 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -6,7 +6,6 @@ config XEN
bool "Xen guest support"
depends on PARAVIRT
select PARAVIRT_CLOCK
-   select XEN_HAVE_PVMMU
select XEN_HAVE_VPMU
depends on X86_64 || (X86_32 && X86_PAE)
depends on X86_LOCAL_APIC && X86_TSC
@@ -15,18 +14,32 @@ config XEN
  kernel to boot in a paravirtualized environment under the
  Xen hypervisor.
 
+config XEN_PV
+   bool "Xen PV guest support"
+   default y
+   depends on XEN
+   select XEN_HAVE_PVMMU
+   help
+ Support running as a Xen PV guest.
+
 config XEN_DOM0
-   def_bool y
-   depends on XEN && PCI_XEN && SWIOTLB_XEN
+   bool "Xen PV Dom0 support"
+   default y
+   depends on XEN_PV && PCI_XEN && SWIOTLB_XEN
depends on X86_IO_APIC && ACPI && PCI
+   help
+ Support running as a Xen PV Dom0 guest.
 
 config XEN_PVHVM
-   def_bool y
+   bool "Xen PVHVM guest support"
+   default y
depends on XEN && PCI && X86_LOCAL_APIC
+   help
+ Support running as a Xen PVHVM guest.
 
 config XEN_512GB
bool "Limit Xen pv-domain memory to 512GB"
-   depends on XEN && X86_64
+   depends on XEN_PV && X86_64
default y
help
  Limit paravirtualized user domains to 512GB of RAM.
-- 
2.9.3


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

[Xen-devel] [PATCH v3 02/21] x86/xen: globalize have_vcpu_info_placement

[Vitaly Kuznetsov]

have_vcpu_info_placement applies to both PV and HVM and as we're going
to split the code we need to make it global.

Rename to xen_have_vcpu_info_placement.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Juergen Gross 
---
 arch/x86/xen/enlighten.c | 12 ++--
 arch/x86/xen/xen-ops.h   |  2 ++
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 999ba13..f0784a6 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -164,7 +164,7 @@ struct shared_info *HYPERVISOR_shared_info = 
_dummy_shared_info;
  *
  * 0: not available, 1: available
  */
-static int have_vcpu_info_placement = 1;
+int xen_have_vcpu_info_placement = 1;
 
 struct tls_descs {
struct desc_struct desc[3];
@@ -228,7 +228,7 @@ void xen_vcpu_setup(int cpu)
per_cpu(xen_vcpu, cpu) =
_shared_info->vcpu_info[xen_vcpu_nr(cpu)];
 
-   if (!have_vcpu_info_placement) {
+   if (!xen_have_vcpu_info_placement) {
if (cpu >= MAX_VIRT_CPUS)
clamp_max_cpus();
return;
@@ -251,7 +251,7 @@ void xen_vcpu_setup(int cpu)
 
if (err) {
printk(KERN_DEBUG "register_vcpu_info failed: err=%d\n", err);
-   have_vcpu_info_placement = 0;
+   xen_have_vcpu_info_placement = 0;
clamp_max_cpus();
} else {
/* This cpu is using the registered vcpu info, even if
@@ -280,7 +280,7 @@ void xen_vcpu_restore(void)
 
xen_setup_runstate_info(cpu);
 
-   if (have_vcpu_info_placement)
+   if (xen_have_vcpu_info_placement)
xen_vcpu_setup(cpu);
 
if (other_cpu && is_up &&
@@ -1159,7 +1159,7 @@ void xen_setup_vcpu_info_placement(void)
 * xen_vcpu_setup managed to place the vcpu_info within the
 * percpu area for all cpus, so make use of it.
 */
-   if (have_vcpu_info_placement) {
+   if (xen_have_vcpu_info_placement) {
pv_irq_ops.save_fl = __PV_IS_CALLEE_SAVE(xen_save_fl_direct);
pv_irq_ops.restore_fl = 
__PV_IS_CALLEE_SAVE(xen_restore_fl_direct);
pv_irq_ops.irq_disable = 
__PV_IS_CALLEE_SAVE(xen_irq_disable_direct);
@@ -1178,7 +1178,7 @@ static unsigned xen_patch(u8 type, u16 clobbers, void 
*insnbuf,
 
 #define SITE(op, x)\
case PARAVIRT_PATCH(op.x):  \
-   if (have_vcpu_info_placement) { \
+   if (xen_have_vcpu_info_placement) { \
start = (char *)xen_##x##_direct;   \
end = xen_##x##_direct_end; \
reloc = xen_##x##_direct_reloc; \
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index f6a41c4..2b162f6 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -76,6 +76,8 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id);
 
 bool xen_vcpu_stolen(int vcpu);
 
+extern int xen_have_vcpu_info_placement;
+
 void xen_vcpu_setup(int cpu);
 void xen_setup_vcpu_info_placement(void);
 
-- 
2.9.3


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

[Xen-devel] [PATCH v3 09/21] x86/xen: split xen_cpu_die()

[Vitaly Kuznetsov]

Split xen_cpu_die() into xen_pv_cpu_die() and xen_hvm_cpu_die() to support
further splitting of smp.c.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Juergen Gross 
---
 arch/x86/xen/smp.c | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index d068b14..53bf0a4 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -514,10 +514,10 @@ static int xen_cpu_disable(void)
return 0;
 }
 
-static void xen_cpu_die(unsigned int cpu)
+static void xen_pv_cpu_die(unsigned int cpu)
 {
-   while (xen_pv_domain() && HYPERVISOR_vcpu_op(VCPUOP_is_up,
-xen_vcpu_nr(cpu), NULL)) {
+   while (HYPERVISOR_vcpu_op(VCPUOP_is_up,
+ xen_vcpu_nr(cpu), NULL)) {
__set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(HZ/10);
}
@@ -530,6 +530,15 @@ static void xen_cpu_die(unsigned int cpu)
}
 }
 
+static void xen_hvm_cpu_die(unsigned int cpu)
+{
+   if (common_cpu_die(cpu) == 0) {
+   xen_smp_intr_free(cpu);
+   xen_uninit_lock_cpu(cpu);
+   xen_teardown_timer(cpu);
+   }
+}
+
 static void xen_play_dead(void) /* used only with HOTPLUG_CPU */
 {
play_dead_common();
@@ -552,7 +561,12 @@ static int xen_cpu_disable(void)
return -ENOSYS;
 }
 
-static void xen_cpu_die(unsigned int cpu)
+static void xen_pv_cpu_die(unsigned int cpu)
+{
+   BUG();
+}
+
+static void xen_hvm_cpu_die(unsigned int cpu)
 {
BUG();
 }
@@ -733,7 +747,7 @@ static const struct smp_ops xen_smp_ops __initconst = {
.smp_cpus_done = xen_smp_cpus_done,
 
.cpu_up = xen_cpu_up,
-   .cpu_die = xen_cpu_die,
+   .cpu_die = xen_pv_cpu_die,
.cpu_disable = xen_cpu_disable,
.play_dead = xen_play_dead,
 
@@ -762,7 +776,7 @@ void __init xen_hvm_smp_init(void)
 {
smp_ops.smp_prepare_cpus = xen_hvm_smp_prepare_cpus;
smp_ops.smp_send_reschedule = xen_smp_send_reschedule;
-   smp_ops.cpu_die = xen_cpu_die;
+   smp_ops.cpu_die = xen_hvm_cpu_die;
smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi;
smp_ops.send_call_func_single_ipi = 
xen_smp_send_call_function_single_ipi;
smp_ops.smp_prepare_boot_cpu = xen_hvm_smp_prepare_boot_cpu;
-- 
2.9.3


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

[Xen-devel] [PATCH v3 07/21] x86/xen: split xen_smp_intr_init()/xen_smp_intr_free()

[Vitaly Kuznetsov]

xen_smp_intr_init() and xen_smp_intr_free() have PV-specific code and as
a praparatory change to splitting smp.c we need to split these fucntions.
Create xen_smp_intr_init_pv()/xen_smp_intr_free_pv().

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Juergen Gross 
---
Changes since v2:
'extern' qualifier dropped from xen_smp_intr_init/free() prototypes.
---
 arch/x86/xen/enlighten_pv.c |  9 +
 arch/x86/xen/smp.c  | 29 ++---
 arch/x86/xen/smp.h  |  8 
 3 files changed, 35 insertions(+), 11 deletions(-)

diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 11443cc..cae1551 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1478,12 +1478,21 @@ static int xen_cpu_up_prepare_pv(unsigned int cpu)
 cpu, rc);
return rc;
}
+
+   rc = xen_smp_intr_init_pv(cpu);
+   if (rc) {
+   WARN(1, "xen_smp_intr_init_pv() for CPU %d failed: %d\n",
+cpu, rc);
+   return rc;
+   }
+
return 0;
 }
 
 static int xen_cpu_dead_pv(unsigned int cpu)
 {
xen_smp_intr_free(cpu);
+   xen_smp_intr_free_pv(cpu);
 
xen_teardown_timer(cpu);
 
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 7ff2f1b..9be801e 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -133,9 +133,10 @@ void xen_smp_intr_free(unsigned int cpu)
kfree(per_cpu(xen_callfuncsingle_irq, cpu).name);
per_cpu(xen_callfuncsingle_irq, cpu).name = NULL;
}
-   if (xen_hvm_domain())
-   return;
+}
 
+void xen_smp_intr_free_pv(unsigned int cpu)
+{
if (per_cpu(xen_irq_work, cpu).irq >= 0) {
unbind_from_irqhandler(per_cpu(xen_irq_work, cpu).irq, NULL);
per_cpu(xen_irq_work, cpu).irq = -1;
@@ -149,11 +150,12 @@ void xen_smp_intr_free(unsigned int cpu)
kfree(per_cpu(xen_pmu_irq, cpu).name);
per_cpu(xen_pmu_irq, cpu).name = NULL;
}
-};
+}
+
 int xen_smp_intr_init(unsigned int cpu)
 {
int rc;
-   char *resched_name, *callfunc_name, *debug_name, *pmu_name;
+   char *resched_name, *callfunc_name, *debug_name;
 
resched_name = kasprintf(GFP_KERNEL, "resched%d", cpu);
rc = bind_ipi_to_irqhandler(XEN_RESCHEDULE_VECTOR,
@@ -200,12 +202,17 @@ int xen_smp_intr_init(unsigned int cpu)
per_cpu(xen_callfuncsingle_irq, cpu).irq = rc;
per_cpu(xen_callfuncsingle_irq, cpu).name = callfunc_name;
 
-   /*
-* The IRQ worker on PVHVM goes through the native path and uses the
-* IPI mechanism.
-*/
-   if (xen_hvm_domain())
-   return 0;
+   return 0;
+
+ fail:
+   xen_smp_intr_free(cpu);
+   return rc;
+}
+
+int xen_smp_intr_init_pv(unsigned int cpu)
+{
+   int rc;
+   char *callfunc_name, *pmu_name;
 
callfunc_name = kasprintf(GFP_KERNEL, "irqwork%d", cpu);
rc = bind_ipi_to_irqhandler(XEN_IRQ_WORK_VECTOR,
@@ -234,7 +241,7 @@ int xen_smp_intr_init(unsigned int cpu)
return 0;
 
  fail:
-   xen_smp_intr_free(cpu);
+   xen_smp_intr_free_pv(cpu);
return rc;
 }
 
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
index 9beef33..33320ce 100644
--- a/arch/x86/xen/smp.h
+++ b/arch/x86/xen/smp.h
@@ -11,6 +11,8 @@ extern void xen_send_IPI_self(int vector);
 
 extern int xen_smp_intr_init(unsigned int cpu);
 extern void xen_smp_intr_free(unsigned int cpu);
+int xen_smp_intr_init_pv(unsigned int cpu);
+void xen_smp_intr_free_pv(unsigned int cpu);
 
 #else /* CONFIG_SMP */
 
@@ -19,6 +21,12 @@ static inline int xen_smp_intr_init(unsigned int cpu)
return 0;
 }
 static inline void xen_smp_intr_free(unsigned int cpu) {}
+
+static inline int xen_smp_intr_init_pv(unsigned int cpu)
+{
+   return 0;
+}
+static inline void xen_smp_intr_free_pv(unsigned int cpu) {}
 #endif /* CONFIG_SMP */
 
 #endif
-- 
2.9.3


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

Re: [Xen-devel] DomU UEFI configuration

[Anthony PERARD]

On Tue, Mar 14, 2017 at 02:06:09PM +, Marcos E. Matsunaga wrote:
> Hi Anthony,
> 
> 
> I am trying to run a DomU guest using OVMF. I have built xen staging with
> --with-ovmf option. I am able to install a new guest but I am unable to boot
> it (see the attached image).
> 
> The xl.cfg file I am using:
> 
> name='test_uefi'
> memory=16384
> disk=['file:/home/IMAGES/FEDORA/FC25/Fedora-Server-dvd-x86_64-25-1.3.iso,hdc:cdrom,r','/Repo/VM/test_uefi/System_UEFI.qcow2,raw,hda,w']
> #disk=['/Repo/VM/test_uefi/System_UEFI.qcow2,raw,hda,w']
> vif=['mac=00:16:3e:ff:ee:01,bridge=xenbr0',
> 'mac=00:16:3e:ff:00:01,bridge=xenbr2']
> guest_os_type='default'
> bios='ovmf'
> serial='pty'
> xen_platform_pci=0
> device_model_version='qemu-xen'
> builder='hvm'
> on_poweroff='destroy'
> boot='dc'
> vnc=1
> vnclisten='0.0.0.0:5'
> stdvga=1
> videoram=16
> on_crash='restart'
> on_reboot='restart'
> vcpus=8
> maxmem=16384
> 
> Konrad Wilk suggested me to use try adding:
> 
> device_model_args_hvm=["fw_cfg","file=./my_blob.bin"];

Those are not QEMU options, so that would not work. And I don't think
using -fw_cfg would work with xen (if the options exist) as we almost
don't use fw_cfg.

> But that didn't work. I also tried something similar to how KVM uses:
> 
> device_model_args_hvm=['-drive','file=/Repo/VM/perf1_uefi/OVMF_VARS.fd,if=pflash,format=raw,unit=1'];
> 
> It also didn't work.

:(. I never tried, I'm not sure if it can work. Compare to KVM, we put
OVMF.fd into RAM instead of a pflash device emulated by QEMU.

Maybe one would need to load OVMF_CODE.fd instead of OVMF.fd, and OVMF
could then use OVMF_VARS.fd, but I never tried.

> How do you specify the NVRAM image to store the boot order?

-- 
Anthony PERARD

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

[Xen-devel] [PATCH v3 08/21] x86/xen: split xen_smp_prepare_boot_cpu()

[Vitaly Kuznetsov]

Split xen_smp_prepare_boot_cpu() into xen_pv_smp_prepare_boot_cpu() and
xen_hvm_smp_prepare_boot_cpu() to support further splitting of smp.c.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Juergen Gross 
---
 arch/x86/xen/smp.c | 49 ++---
 1 file changed, 30 insertions(+), 19 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 9be801e..d068b14 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -297,35 +297,46 @@ static void __init xen_filter_cpu_maps(void)
 
 }
 
-static void __init xen_smp_prepare_boot_cpu(void)
+static void __init xen_pv_smp_prepare_boot_cpu(void)
 {
BUG_ON(smp_processor_id() != 0);
native_smp_prepare_boot_cpu();
 
-   if (xen_pv_domain()) {
-   if (!xen_feature(XENFEAT_writable_page_tables))
-   /* We've switched to the "real" per-cpu gdt, so make
-* sure the old memory can be recycled. */
-   make_lowmem_page_readwrite(xen_initial_gdt);
+   if (!xen_feature(XENFEAT_writable_page_tables))
+   /* We've switched to the "real" per-cpu gdt, so make
+* sure the old memory can be recycled. */
+   make_lowmem_page_readwrite(xen_initial_gdt);
 
 #ifdef CONFIG_X86_32
-   /*
-* Xen starts us with XEN_FLAT_RING1_DS, but linux code
-* expects __USER_DS
-*/
-   loadsegment(ds, __USER_DS);
-   loadsegment(es, __USER_DS);
+   /*
+* Xen starts us with XEN_FLAT_RING1_DS, but linux code
+* expects __USER_DS
+*/
+   loadsegment(ds, __USER_DS);
+   loadsegment(es, __USER_DS);
 #endif
 
-   xen_filter_cpu_maps();
-   xen_setup_vcpu_info_placement();
-   }
+   xen_filter_cpu_maps();
+   xen_setup_vcpu_info_placement();
+
+   /*
+* The alternative logic (which patches the unlock/lock) runs before
+* the smp bootup up code is activated. Hence we need to set this up
+* the core kernel is being patched. Otherwise we will have only
+* modules patched but not core code.
+*/
+   xen_init_spinlocks();
+}
+
+static void __init xen_hvm_smp_prepare_boot_cpu(void)
+{
+   BUG_ON(smp_processor_id() != 0);
+   native_smp_prepare_boot_cpu();
 
/*
 * Setup vcpu_info for boot CPU.
 */
-   if (xen_hvm_domain())
-   xen_vcpu_setup(0);
+   xen_vcpu_setup(0);
 
/*
 * The alternative logic (which patches the unlock/lock) runs before
@@ -717,7 +728,7 @@ static irqreturn_t xen_irq_work_interrupt(int irq, void 
*dev_id)
 }
 
 static const struct smp_ops xen_smp_ops __initconst = {
-   .smp_prepare_boot_cpu = xen_smp_prepare_boot_cpu,
+   .smp_prepare_boot_cpu = xen_pv_smp_prepare_boot_cpu,
.smp_prepare_cpus = xen_smp_prepare_cpus,
.smp_cpus_done = xen_smp_cpus_done,
 
@@ -754,5 +765,5 @@ void __init xen_hvm_smp_init(void)
smp_ops.cpu_die = xen_cpu_die;
smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi;
smp_ops.send_call_func_single_ipi = 
xen_smp_send_call_function_single_ipi;
-   smp_ops.smp_prepare_boot_cpu = xen_smp_prepare_boot_cpu;
+   smp_ops.smp_prepare_boot_cpu = xen_hvm_smp_prepare_boot_cpu;
 }
-- 
2.9.3


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

[Xen-devel] [PATCH v3 05/21] x86/xen: split off enlighten_hvm.c

[Vitaly Kuznetsov]

Move PVHVM related code to enlighten_hvm.c. Three functions:
xen_cpuhp_setup(), xen_reboot(), xen_emergency_restart() are shared, drop
static qualifier from them. These functions will go to common code once
it is split from enlighten.c.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Juergen Gross 
---
Changes since v2:
   xen_pin_vcpu() exported as we use it for HVM too.
   #include /#include  added [kbuild test robot]
---
 arch/x86/xen/Makefile|   1 +
 arch/x86/xen/enlighten.c | 212 +-
 arch/x86/xen/enlighten_hvm.c | 213 +++
 arch/x86/xen/xen-ops.h   |   8 ++
 4 files changed, 227 insertions(+), 207 deletions(-)
 create mode 100644 arch/x86/xen/enlighten_hvm.c

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 348128b..1bca75b 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -15,6 +15,7 @@ obj-y := enlighten.o setup.o multicalls.o mmu.o irq.o 
\
grant-table.o suspend.o platform-pci-unplug.o \
p2m.o apic.o pmu.o
 
+obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o
 obj-$(CONFIG_XEN_PVH)  += enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 3a3bee2..6054364 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -45,10 +45,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -140,10 +138,8 @@ void *xen_initial_gdt;
 RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 
 static int xen_cpu_up_prepare_pv(unsigned int cpu);
-static int xen_cpu_up_prepare_hvm(unsigned int cpu);
 static int xen_cpu_up_online(unsigned int cpu);
 static int xen_cpu_dead_pv(unsigned int cpu);
-static int xen_cpu_dead_hvm(unsigned int cpu);
 
 /*
  * Point at some empty memory to start with. We map the real shared_info
@@ -1282,7 +1278,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
.end_context_switch = xen_end_context_switch,
 };
 
-static void xen_reboot(int reason)
+void xen_reboot(int reason)
 {
struct sched_shutdown r = { .reason = reason };
int cpu;
@@ -1299,7 +1295,7 @@ static void xen_restart(char *msg)
xen_reboot(SHUTDOWN_reboot);
 }
 
-static void xen_emergency_restart(void)
+void xen_emergency_restart(void)
 {
xen_reboot(SHUTDOWN_reboot);
 }
@@ -1435,8 +1431,8 @@ static void __init xen_dom0_set_legacy_features(void)
x86_platform.legacy.rtc = 1;
 }
 
-static int xen_cpuhp_setup(int (*cpu_up_prepare_cb)(unsigned int),
-  int (*cpu_dead_cb)(unsigned int))
+int xen_cpuhp_setup(int (*cpu_up_prepare_cb)(unsigned int),
+   int (*cpu_dead_cb)(unsigned int))
 {
int rc;
 
@@ -1660,79 +1656,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
 #endif
 }
 
-void __ref xen_hvm_init_shared_info(void)
-{
-   int cpu;
-   struct xen_add_to_physmap xatp;
-   static struct shared_info *shared_info_page = 0;
-
-   if (!shared_info_page)
-   shared_info_page = (struct shared_info *)
-   extend_brk(PAGE_SIZE, PAGE_SIZE);
-   xatp.domid = DOMID_SELF;
-   xatp.idx = 0;
-   xatp.space = XENMAPSPACE_shared_info;
-   xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
-   if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, ))
-   BUG();
-
-   HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
-
-   /* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
-* page, we use it in the event channel upcall and in some pvclock
-* related functions. We don't need the vcpu_info placement
-* optimizations because we don't use any pv_mmu or pv_irq op on
-* HVM.
-* When xen_hvm_init_shared_info is run at boot time only vcpu 0 is
-* online but xen_hvm_init_shared_info is run at resume time too and
-* in that case multiple vcpus might be online. */
-   for_each_online_cpu(cpu) {
-   /* Leave it to be NULL. */
-   if (xen_vcpu_nr(cpu) >= MAX_VIRT_CPUS)
-   continue;
-   per_cpu(xen_vcpu, cpu) =
-   _shared_info->vcpu_info[xen_vcpu_nr(cpu)];
-   }
-}
-
-#ifdef CONFIG_XEN_PVHVM
-static void __init init_hvm_pv_info(void)
-{
-   int major, minor;
-   uint32_t eax, ebx, ecx, edx, base;
-
-   base = xen_cpuid_base();
-   eax = cpuid_eax(base + 1);
-
-   major = eax >> 16;
-   minor = eax & 0x;
-   printk(KERN_INFO "Xen version %d.%d.\n", major, minor);
-
-   xen_domain_type = XEN_HVM_DOMAIN;
-
-   /* PVH set up hypercall page in xen_prepare_pvh(). */
-   if (xen_pvh_domain())
-   pv_info.name = "Xen PVH";
-   else {
-   u64 pfn;
-   

[Xen-devel] [PATCH v3 01/21] x86/xen: separate PV and HVM hypervisors

[Vitaly Kuznetsov]

As a preparation to splitting the code we need to untangle it:

x86_hyper_xen -> x86_hyper_xen_hvm and x86_hyper_xen_pv
xen_platform() -> xen_platform_hvm() and xen_platform_pv()
xen_cpu_up_prepare() -> xen_cpu_up_prepare_pv() and xen_cpu_up_prepare_hvm()
xen_cpu_dead() -> xen_cpu_dead_pv() and xen_cpu_dead_pv_hvm()

Add two parameters to xen_cpuhp_setup() to pass proper cpu_up_prepare and
cpu_dead hooks. xen_set_cpu_features() is now PV-only so the redundant
xen_pv_domain() check can be dropped.

Signed-off-by: Vitaly Kuznetsov 
---
Changes since v2:
   .pin_vcpu kept for x86_hyper_xen_hvm to support PVH Dom0 in future
   [Juergen Gross]
---
 arch/x86/include/asm/hypervisor.h |   3 +-
 arch/x86/kernel/cpu/hypervisor.c  |   3 +-
 arch/x86/xen/enlighten.c  | 114 +-
 3 files changed, 79 insertions(+), 41 deletions(-)

diff --git a/arch/x86/include/asm/hypervisor.h 
b/arch/x86/include/asm/hypervisor.h
index 67942b6..6f7545c6 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -53,7 +53,8 @@ extern const struct hypervisor_x86 *x86_hyper;
 /* Recognized hypervisors */
 extern const struct hypervisor_x86 x86_hyper_vmware;
 extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
-extern const struct hypervisor_x86 x86_hyper_xen;
+extern const struct hypervisor_x86 x86_hyper_xen_pv;
+extern const struct hypervisor_x86 x86_hyper_xen_hvm;
 extern const struct hypervisor_x86 x86_hyper_kvm;
 
 extern void init_hypervisor(struct cpuinfo_x86 *c);
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index 35691a6..a77f18d 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -29,7 +29,8 @@
 static const __initconst struct hypervisor_x86 * const hypervisors[] =
 {
 #ifdef CONFIG_XEN
-   _hyper_xen,
+   _hyper_xen_pv,
+   _hyper_xen_hvm,
 #endif
_hyper_vmware,
_hyper_ms_hyperv,
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index ec1d5c4..999ba13 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -139,9 +139,11 @@ void *xen_initial_gdt;
 
 RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 
-static int xen_cpu_up_prepare(unsigned int cpu);
+static int xen_cpu_up_prepare_pv(unsigned int cpu);
+static int xen_cpu_up_prepare_hvm(unsigned int cpu);
 static int xen_cpu_up_online(unsigned int cpu);
-static int xen_cpu_dead(unsigned int cpu);
+static int xen_cpu_dead_pv(unsigned int cpu);
+static int xen_cpu_dead_hvm(unsigned int cpu);
 
 /*
  * Point at some empty memory to start with. We map the real shared_info
@@ -1447,13 +1449,14 @@ static void __init xen_dom0_set_legacy_features(void)
x86_platform.legacy.rtc = 1;
 }
 
-static int xen_cpuhp_setup(void)
+static int xen_cpuhp_setup(int (*cpu_up_prepare_cb)(unsigned int),
+  int (*cpu_dead_cb)(unsigned int))
 {
int rc;
 
rc = cpuhp_setup_state_nocalls(CPUHP_XEN_PREPARE,
   "x86/xen/hvm_guest:prepare",
-  xen_cpu_up_prepare, xen_cpu_dead);
+  cpu_up_prepare_cb, cpu_dead_cb);
if (rc >= 0) {
rc = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
   "x86/xen/hvm_guest:online",
@@ -1559,7 +1562,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
   possible map and a non-dummy shared_info. */
per_cpu(xen_vcpu, 0) = _shared_info->vcpu_info[0];
 
-   WARN_ON(xen_cpuhp_setup());
+   WARN_ON(xen_cpuhp_setup(xen_cpu_up_prepare_pv, xen_cpu_dead_pv));
 
local_irq_disable();
early_boot_irqs_disabled = true;
@@ -1840,28 +1843,41 @@ static void __init init_hvm_pv_info(void)
 }
 #endif
 
-static int xen_cpu_up_prepare(unsigned int cpu)
+static int xen_cpu_up_prepare_pv(unsigned int cpu)
 {
int rc;
 
-   if (xen_hvm_domain()) {
-   /*
-* This can happen if CPU was offlined earlier and
-* offlining timed out in common_cpu_die().
-*/
-   if (cpu_report_state(cpu) == CPU_DEAD_FROZEN) {
-   xen_smp_intr_free(cpu);
-   xen_uninit_lock_cpu(cpu);
-   }
+   xen_setup_timer(cpu);
 
-   if (cpu_acpi_id(cpu) != U32_MAX)
-   per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu);
-   else
-   per_cpu(xen_vcpu_id, cpu) = cpu;
-   xen_vcpu_setup(cpu);
+   rc = xen_smp_intr_init(cpu);
+   if (rc) {
+   WARN(1, "xen_smp_intr_init() for CPU %d failed: %d\n",
+cpu, rc);
+   return rc;
+   }
+   return 0;
+}
+
+static int xen_cpu_up_prepare_hvm(unsigned int cpu)
+{
+   int rc;
+
+   /*
+* This can happen if CPU was offlined earlier and
+* 

[Xen-devel] [PATCH v3 04/21] x86/xen: split off enlighten_pvh.c

[Vitaly Kuznetsov]

Create enlighten_pvh.c by splitting off PVH related code from enlighten.c,
put it under CONFIG_XEN_PVH.

Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Juergen Gross 
---
Changes since v2:
#include  added [kbuild test robot]
---
 arch/x86/xen/Makefile|   2 +
 arch/x86/xen/enlighten.c | 110 -
 arch/x86/xen/enlighten_pvh.c | 115 +++
 3 files changed, 117 insertions(+), 110 deletions(-)
 create mode 100644 arch/x86/xen/enlighten_pvh.c

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index cb0164a..348128b 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -15,6 +15,8 @@ obj-y := enlighten.o setup.o multicalls.o mmu.o irq.o 
\
grant-table.o suspend.o platform-pci-unplug.o \
p2m.o apic.o pmu.o
 
+obj-$(CONFIG_XEN_PVH)  += enlighten_pvh.o
+
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
 obj-$(CONFIG_SMP)  += smp.o
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index f0784a6..3a3bee2 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -179,20 +179,6 @@ struct tls_descs {
  */
 static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
 
-#ifdef CONFIG_XEN_PVH
-/*
- * PVH variables.
- *
- * xen_pvh and pvh_bootparams need to live in data segment since they
- * are used after startup_{32|64}, which clear .bss, are invoked.
- */
-bool xen_pvh __attribute__((section(".data"))) = 0;
-struct boot_params pvh_bootparams __attribute__((section(".data")));
-
-struct hvm_start_info pvh_start_info;
-unsigned int pvh_start_info_sz = sizeof(pvh_start_info);
-#endif
-
 static void clamp_max_cpus(void)
 {
 #ifdef CONFIG_SMP
@@ -1674,102 +1660,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
 #endif
 }
 
-#ifdef CONFIG_XEN_PVH
-
-static void xen_pvh_arch_setup(void)
-{
-#ifdef CONFIG_ACPI
-   /* Make sure we don't fall back to (default) ACPI_IRQ_MODEL_PIC. */
-   if (nr_ioapics == 0)
-   acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
-#endif
-}
-
-static void __init init_pvh_bootparams(void)
-{
-   struct xen_memory_map memmap;
-   unsigned int i;
-   int rc;
-
-   memset(_bootparams, 0, sizeof(pvh_bootparams));
-
-   memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_map);
-   set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_map);
-   rc = HYPERVISOR_memory_op(XENMEM_memory_map, );
-   if (rc) {
-   xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
-   BUG();
-   }
-
-   if (memmap.nr_entries < E820MAX - 1) {
-   pvh_bootparams.e820_map[memmap.nr_entries].addr =
-   ISA_START_ADDRESS;
-   pvh_bootparams.e820_map[memmap.nr_entries].size =
-   ISA_END_ADDRESS - ISA_START_ADDRESS;
-   pvh_bootparams.e820_map[memmap.nr_entries].type =
-   E820_RESERVED;
-   memmap.nr_entries++;
-   } else
-   xen_raw_printk("Warning: Can fit ISA range into e820\n");
-
-   sanitize_e820_map(pvh_bootparams.e820_map,
- ARRAY_SIZE(pvh_bootparams.e820_map),
- _entries);
-
-   pvh_bootparams.e820_entries = memmap.nr_entries;
-   for (i = 0; i < pvh_bootparams.e820_entries; i++)
-   e820_add_region(pvh_bootparams.e820_map[i].addr,
-   pvh_bootparams.e820_map[i].size,
-   pvh_bootparams.e820_map[i].type);
-
-   pvh_bootparams.hdr.cmd_line_ptr =
-   pvh_start_info.cmdline_paddr;
-
-   /* The first module is always ramdisk. */
-   if (pvh_start_info.nr_modules) {
-   struct hvm_modlist_entry *modaddr =
-   __va(pvh_start_info.modlist_paddr);
-   pvh_bootparams.hdr.ramdisk_image = modaddr->paddr;
-   pvh_bootparams.hdr.ramdisk_size = modaddr->size;
-   }
-
-   /*
-* See Documentation/x86/boot.txt.
-*
-* Version 2.12 supports Xen entry point but we will use default x86/PC
-* environment (i.e. hardware_subarch 0).
-*/
-   pvh_bootparams.hdr.version = 0x212;
-   pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
-}
-
-/*
- * This routine (and those that it might call) should not use
- * anything that lives in .bss since that segment will be cleared later.
- */
-void __init xen_prepare_pvh(void)
-{
-   u32 msr;
-   u64 pfn;
-
-   if (pvh_start_info.magic != XEN_HVM_START_MAGIC_VALUE) {
-   xen_raw_printk("Error: Unexpected magic value (0x%08x)\n",
-   pvh_start_info.magic);
-   BUG();
-   }
-
-   xen_pvh = 1;
-
-   msr = cpuid_ebx(xen_cpuid_base() + 2);
-   pfn = __pa(hypercall_page);
-   wrmsr_safe(msr, 

[Xen-devel] [xen-unstable-smoke test] 106666: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  721b64d1f9e46940acccefd1a630b2f860766fdf
baseline version:
 xen  48321fa86ddefe2fddf728dc972b01bb7c7c8559

Last test of basis   106664  2017-03-14 14:01:45 Z0 days
Testing same since   10  2017-03-14 16:01:04 Z0 days1 attempts


People who touched revisions under test:
  Juergen Gross 
  Razvan Cojocaru 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  fail
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  broken  
 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


Not pushing.


commit 721b64d1f9e46940acccefd1a630b2f860766fdf
Author: Juergen Gross 
Date:   Tue Mar 14 16:04:42 2017 +0100

tools/libxl: correct distclean target

Commit 3e5f1a63b53920763 ("tools: adapt xenlight.pc and xlutil.pc to
new pkg-config scheme") introduced an error for "make distclean" as
*.pc.in are deleted which are now files in git.

Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 

commit 8e437da379da6cb017692e71a28319f92f73b60b
Author: Juergen Gross 
Date:   Tue Mar 14 16:04:41 2017 +0100

tools: correct build in directory below tools

Recent changes to create *.pc files introduced a bug when trying to
build a library from a directory below tools as PKG_CONFIG_DIR wouldn't
be set. Correct this by adding a default value to Rules.mk.

Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 

commit 6622e7f4c81812c6f14437e501596f496f7e571b
Author: Razvan Cojocaru 
Date:   Tue Mar 14 15:30:18 2017 +0200

tools/libxc: Exposed XEN_DOMCTL_getvcpuextstate

It's useful for an introspection tool to be able to inspect
XSAVE states. Xen already has a DOMCTL that can be used for this
purpose, but it had no public libxc wrapper. This patch adds
xc_vcpu_get_extstate().

Signed-off-by: Razvan Cojocaru 
Acked-by: Wei Liu 

commit 3e5f1a63b53920763f4db2bd87e703334d334fd9
Author: Juergen Gross 
Date:   Tue Mar 14 14:31:24 2017 +0100

tools: adapt xenlight.pc and xlutil.pc to new pkg-config scheme

Instead of generating the *.pc.in files at configure time use the new
pkg-config scheme for those files. Add the dependencies to other Xen
libraries as needed.

Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 

commit eed254709a535d494c65564abb27ad9ce68d45e9
Author: Juergen Gross 
Date:   Tue Mar 14 14:31:23 2017 +0100

tools: provide pkg-config file for libxenblktapctl

In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenblktapctl.pc file.

Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 

commit 42affa826e52c69c74fabd44656264fa37a4e0e5
Author: 

[Xen-devel] [PATCH v7 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size

[Thomas Garnier]

This patch aligns MODULES_END to the beginning of the Fixmap section.
It optimizes the space available for both sections. The address is
pre-computed based on the number of pages required by the Fixmap
section.

It will allow GDT remapping in the Fixmap section. The current
MODULES_END static address does not provide enough space for the kernel
to support a large number of processors.

Signed-off-by: Thomas Garnier 
---
Based on next-20170308
---
 Documentation/x86/x86_64/mm.txt | 5 -
 arch/x86/include/asm/pgtable_64_types.h | 3 ++-
 arch/x86/kernel/module.c| 1 +
 arch/x86/mm/dump_pagetables.c   | 1 +
 arch/x86/mm/kasan_init_64.c | 1 +
 mm/vmalloc.c| 1 +
 6 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index 5724092db811..ee3f9c30957c 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -19,7 +19,7 @@ ff00 - ff7f (=39 bits) %esp fixup 
stacks
 ffef - fffe (=64 GB) EFI region mapping space
 ... unused hole ...
 8000 - 9fff (=512 MB)  kernel text mapping, from phys 0
-a000 - ff5f (=1526 MB) module mapping space
+a000 - ff5f (=1526 MB) module mapping space (variable)
 ff60 - ffdf (=8 MB) vsyscalls
 ffe0 -  (=2 MB) unused hole
 
@@ -39,6 +39,9 @@ memory window (this size is arbitrary, it can be raised later 
if needed).
 The mappings are not part of any other kernel PGD and are only available
 during EFI runtime calls.
 
+The module mapping space size changes based on the CONFIG requirements for the
+following fixmap section.
+
 Note that if CONFIG_RANDOMIZE_MEMORY is enabled, the direct mapping of all
 physical memory, vmalloc/ioremap space and virtual memory map are randomized.
 Their order is preserved but their base will be offset early at boot time.
diff --git a/arch/x86/include/asm/pgtable_64_types.h 
b/arch/x86/include/asm/pgtable_64_types.h
index 3a264200c62f..bb05e21cf3c7 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -67,7 +67,8 @@ typedef struct { pteval_t pte; } pte_t;
 #endif /* CONFIG_RANDOMIZE_MEMORY */
 #define VMALLOC_END(VMALLOC_START + _AC((VMALLOC_SIZE_TB << 40) - 1, UL))
 #define MODULES_VADDR(__START_KERNEL_map + KERNEL_IMAGE_SIZE)
-#define MODULES_END  _AC(0xff00, UL)
+/* The module sections ends with the start of the fixmap */
+#define MODULES_END   __fix_to_virt(__end_of_fixed_addresses + 1)
 #define MODULES_LEN   (MODULES_END - MODULES_VADDR)
 #define ESPFIX_PGD_ENTRY _AC(-2, UL)
 #define ESPFIX_BASE_ADDR (ESPFIX_PGD_ENTRY << PGDIR_SHIFT)
diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
index 477ae806c2fa..fad61caac75e 100644
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if 0
 #define DEBUGP(fmt, ...)   \
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 58b5bee7ea27..75efeecc85eb 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -20,6 +20,7 @@
 
 #include 
 #include 
+#include 
 
 /*
  * The dumper groups pagetable entries of the same type into one, and for
diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
index 8d63d7a104c3..1bde19ef86bd 100644
--- a/arch/x86/mm/kasan_init_64.c
+++ b/arch/x86/mm/kasan_init_64.c
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 
 extern pgd_t early_level4_pgt[PTRS_PER_PGD];
 extern struct range pfn_mapped[E820_X_MAX];
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 32979d945766..1fc9598ed019 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "internal.h"
 
-- 
2.12.0.367.g23dc2f6d3c-goog


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

[Xen-devel] [PATCH v7 2/3] x86: Remap GDT tables in the Fixmap section

[Thomas Garnier]

Each processor holds a GDT in its per-cpu structure. The sgdt
instruction gives the base address of the current GDT. This address can
be used to bypass KASLR memory randomization. With another bug, an
attacker could target other per-cpu structures or deduce the base of
the main memory section (PAGE_OFFSET).

This patch relocates the GDT table for each processor inside the
Fixmap section. The space is reserved based on number of supported
processors.

For consistency, the remapping is done by default on 32 and 64-bit.

Each processor switches to its remapped GDT at the end of
initialization. For hibernation, the main processor returns with the
original GDT and switches back to the remapping at completion.

This patch was tested on both architectures. Hibernation and KVM were
both tested specially for their usage of the GDT.

Thanks to Boris Ostrovsky  for testing and
recommending changes for Xen support.

Signed-off-by: Thomas Garnier 
---
Based on next-20170308
---
 arch/x86/entry/vdso/vma.c |  2 +-
 arch/x86/include/asm/desc.h   | 58 ---
 arch/x86/include/asm/fixmap.h |  4 +++
 arch/x86/include/asm/processor.h  |  1 +
 arch/x86/include/asm/stackprotector.h |  2 +-
 arch/x86/kernel/acpi/sleep.c  |  2 +-
 arch/x86/kernel/apm_32.c  |  6 ++--
 arch/x86/kernel/cpu/common.c  | 29 --
 arch/x86/kernel/setup_percpu.c|  2 +-
 arch/x86/kernel/smpboot.c |  2 +-
 arch/x86/platform/efi/efi_32.c|  4 +--
 arch/x86/power/cpu.c  |  7 +++--
 arch/x86/xen/enlighten.c  |  5 ++-
 arch/x86/xen/mmu.c|  1 +
 arch/x86/xen/smp.c|  2 +-
 drivers/lguest/x86/core.c |  6 ++--
 drivers/pnp/pnpbios/bioscalls.c   | 10 +++---
 17 files changed, 114 insertions(+), 29 deletions(-)

diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 226ca70dc6bd..5c5d4d7618e6 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -354,7 +354,7 @@ static void vgetcpu_cpu_init(void *arg)
d.p = 1;/* Present */
d.d = 1;/* 32-bit */
 
-   write_gdt_entry(get_cpu_gdt_table(cpu), GDT_ENTRY_PER_CPU, , 
DESCTYPE_S);
+   write_gdt_entry(get_cpu_gdt_rw(cpu), GDT_ENTRY_PER_CPU, , DESCTYPE_S);
 }
 
 static int vgetcpu_online(unsigned int cpu)
diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index 1548ca92ad3f..4b5ef0c64291 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -38,6 +39,7 @@ extern struct desc_ptr idt_descr;
 extern gate_desc idt_table[];
 extern const struct desc_ptr debug_idt_descr;
 extern gate_desc debug_idt_table[];
+extern pgprot_t pg_fixmap_gdt_flags;
 
 struct gdt_page {
struct desc_struct gdt[GDT_ENTRIES];
@@ -45,11 +47,57 @@ struct gdt_page {
 
 DECLARE_PER_CPU_PAGE_ALIGNED(struct gdt_page, gdt_page);
 
-static inline struct desc_struct *get_cpu_gdt_table(unsigned int cpu)
+/* Provide the original GDT */
+static inline struct desc_struct *get_cpu_gdt_rw(unsigned int cpu)
 {
return per_cpu(gdt_page, cpu).gdt;
 }
 
+static inline unsigned long get_cpu_gdt_rw_vaddr(unsigned int cpu)
+{
+   return (unsigned long)get_cpu_gdt_rw(cpu);
+}
+
+/* Provide the current original GDT */
+static inline struct desc_struct *get_current_gdt_rw(void)
+{
+   return this_cpu_ptr(_page)->gdt;
+}
+
+static inline unsigned long get_current_gdt_rw_vaddr(void)
+{
+   return (unsigned long)get_current_gdt_rw();
+}
+
+/* Get the fixmap index for a specific processor */
+static inline unsigned int get_cpu_gdt_ro_index(int cpu)
+{
+   return FIX_GDT_REMAP_BEGIN + cpu;
+}
+
+/* Provide the fixmap address of the remapped GDT */
+static inline struct desc_struct *get_cpu_gdt_ro(int cpu)
+{
+   unsigned int idx = get_cpu_gdt_ro_index(cpu);
+   return (struct desc_struct *)__fix_to_virt(idx);
+}
+
+static inline unsigned long get_cpu_gdt_ro_vaddr(int cpu)
+{
+   return (unsigned long)get_cpu_gdt_ro(cpu);
+}
+
+/* Provide the current read-only GDT */
+static inline struct desc_struct *get_current_gdt_ro(void)
+{
+   return get_cpu_gdt_ro(smp_processor_id());
+}
+
+static inline unsigned long get_current_gdt_ro_vaddr(void)
+{
+   return (unsigned long)get_current_gdt_ro();
+}
+
 #ifdef CONFIG_X86_64
 
 static inline void pack_gate(gate_desc *gate, unsigned type, unsigned long 
func,
@@ -174,7 +222,7 @@ static inline void set_tssldt_descriptor(void *d, unsigned 
long addr, unsigned t
 
 static inline void __set_tss_desc(unsigned cpu, unsigned int entry, void *addr)
 {
-   struct desc_struct *d = get_cpu_gdt_table(cpu);
+   struct desc_struct *d = get_cpu_gdt_rw(cpu);
tss_desc tss;
 
set_tssldt_descriptor(, (unsigned 

[Xen-devel] [PATCH v7 3/3] x86: Make the GDT remapping read-only on 64-bit

[Thomas Garnier]

This patch makes the GDT remapped pages read-only to prevent corruption.
This change is done only on 64-bit.

The native_load_tr_desc function was adapted to correctly handle a
read-only GDT. The LTR instruction always writes to the GDT TSS entry.
This generates a page fault if the GDT is read-only. This change checks
if the current GDT is a remap and swap GDTs as needed. This function was
tested by booting multiple machines and checking hibernation works
properly.

KVM SVM and VMX were adapted to use the writeable GDT. On VMX, the
per-cpu variable was removed for functions to fetch the original GDT.
Instead of reloading the previous GDT, VMX will reload the fixmap GDT as
expected. For testing, VMs were started and restored on multiple
configurations.

Signed-off-by: Thomas Garnier 
---
Based on next-20170308
---
 arch/x86/include/asm/desc.h  | 106 +--
 arch/x86/include/asm/processor.h |   1 +
 arch/x86/kernel/cpu/common.c |  28 ---
 arch/x86/kvm/svm.c   |   4 +-
 arch/x86/kvm/vmx.c   |  12 ++---
 5 files changed, 96 insertions(+), 55 deletions(-)

diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index 4b5ef0c64291..ec05f9c1a62c 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -248,9 +248,77 @@ static inline void native_set_ldt(const void *addr, 
unsigned int entries)
}
 }
 
+static inline void native_load_gdt(const struct desc_ptr *dtr)
+{
+   asm volatile("lgdt %0"::"m" (*dtr));
+}
+
+static inline void native_load_idt(const struct desc_ptr *dtr)
+{
+   asm volatile("lidt %0"::"m" (*dtr));
+}
+
+static inline void native_store_gdt(struct desc_ptr *dtr)
+{
+   asm volatile("sgdt %0":"=m" (*dtr));
+}
+
+static inline void native_store_idt(struct desc_ptr *dtr)
+{
+   asm volatile("sidt %0":"=m" (*dtr));
+}
+
+/*
+ * The LTR instruction marks the TSS GDT entry as busy. On 64-bit, the GDT is
+ * a read-only remapping. To prevent a page fault, the GDT is switched to the
+ * original writeable version when needed.
+ */
+#ifdef CONFIG_X86_64
 static inline void native_load_tr_desc(void)
 {
+   struct desc_ptr gdt;
+   int cpu = raw_smp_processor_id();
+   bool restore = 0;
+   struct desc_struct *fixmap_gdt;
+
+   native_store_gdt();
+   fixmap_gdt = get_cpu_gdt_ro(cpu);
+
+   /*
+* If the current GDT is the read-only fixmap, swap to the original
+* writeable version. Swap back at the end.
+*/
+   if (gdt.address == (unsigned long)fixmap_gdt) {
+   load_direct_gdt(cpu);
+   restore = 1;
+   }
asm volatile("ltr %w0"::"q" (GDT_ENTRY_TSS*8));
+   if (restore)
+   load_fixmap_gdt(cpu);
+}
+#else
+static inline void native_load_tr_desc(void)
+{
+   asm volatile("ltr %w0"::"q" (GDT_ENTRY_TSS*8));
+}
+#endif
+
+static inline unsigned long native_store_tr(void)
+{
+   unsigned long tr;
+
+   asm volatile("str %0":"=r" (tr));
+
+   return tr;
+}
+
+static inline void native_load_tls(struct thread_struct *t, unsigned int cpu)
+{
+   struct desc_struct *gdt = get_cpu_gdt_rw(cpu);
+   unsigned int i;
+
+   for (i = 0; i < GDT_ENTRY_TLS_ENTRIES; i++)
+   gdt[GDT_ENTRY_TLS_MIN + i] = t->tls_array[i];
 }
 
 DECLARE_PER_CPU(bool, __tss_limit_invalid);
@@ -305,44 +373,6 @@ static inline void invalidate_tss_limit(void)
this_cpu_write(__tss_limit_invalid, true);
 }
 
-static inline void native_load_gdt(const struct desc_ptr *dtr)
-{
-   asm volatile("lgdt %0"::"m" (*dtr));
-}
-
-static inline void native_load_idt(const struct desc_ptr *dtr)
-{
-   asm volatile("lidt %0"::"m" (*dtr));
-}
-
-static inline void native_store_gdt(struct desc_ptr *dtr)
-{
-   asm volatile("sgdt %0":"=m" (*dtr));
-}
-
-static inline void native_store_idt(struct desc_ptr *dtr)
-{
-   asm volatile("sidt %0":"=m" (*dtr));
-}
-
-static inline unsigned long native_store_tr(void)
-{
-   unsigned long tr;
-
-   asm volatile("str %0":"=r" (tr));
-
-   return tr;
-}
-
-static inline void native_load_tls(struct thread_struct *t, unsigned int cpu)
-{
-   struct desc_struct *gdt = get_cpu_gdt_rw(cpu);
-   unsigned int i;
-
-   for (i = 0; i < GDT_ENTRY_TLS_ENTRIES; i++)
-   gdt[GDT_ENTRY_TLS_MIN + i] = t->tls_array[i];
-}
-
 /* This intentionally ignores lm, since 32-bit apps don't have that field. */
 #define LDT_empty(info)\
((info)->base_addr  == 0&&  \
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 2ec4d2dc559b..28828f1f99a4 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -716,6 +716,7 @@ extern struct desc_ptr  early_gdt_descr;
 
 extern void cpu_set_gdt(int);
 extern void switch_to_new_gdt(int);
+extern void 

Re: [Xen-devel] help please...

[Wei Liu]

On Mon, Mar 13, 2017 at 10:36:50AM +0800, 刘瑞丰 wrote:
> [image: 内嵌图片 1]
> 

Please don't send pictures to mailing list. Not everyone can see them
(some people use text based email clients) and they consume a lot of
bandwidth combined.

> it reports:
> 
> checking for PyArg_ParseTuple in -lpython2.7... no
> configure: error: Unable to find a suitable python development library
> configure: error: ./configure failed for tools
> 
> -
> My system is ubuntu16.04 LTS, with kernel linux-4.8.10
> I have installed python2.7 & python3.7 including python*-dev

You seem to have done the right thing.

The next thing to do is to create a program to link against those
library to figure out if it is an issue in Xen build system or your
Linux installation.

Wei.

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

[Xen-devel] [PATCH v4] xen: don't save/restore the physmap on VM save/restore

[Igor Druzhinin]

Saving/restoring the physmap to/from xenstore was introduced to
QEMU majorly in order to cover up the VRAM region restore issue.
The sequence of restore operations implies that we should know
the effective guest VRAM address *before* we have the VRAM region
restored (which happens later). Unfortunately, in Xen environment
VRAM memory does actually belong to a guest - not QEMU itself -
which means the position of this region is unknown beforehand and
can't be mapped into QEMU address space immediately.

Previously, recreating xenstore keys, holding the physmap, by the
toolstack helped to get this information in place at the right
moment ready to be consumed by QEMU to map the region properly.

The extraneous complexity of having those keys transferred by the
toolstack and unnecessary redundancy prompted us to propose a
solution which doesn't require any extra data in xenstore. The idea
is to defer the VRAM region mapping till the point we actually know
the effective address and able to map it. To that end, we initially
just skip the mapping request for the framebuffer if we unable to
map it now. Then, after the memory region restore phase, we perform
the mapping again, this time successfully, and update the VRAM region
metadata accordingly.

Signed-off-by: Igor Druzhinin 
---
v4:
* Use VGA post_load handler for vram_ptr update

v3:
* Modify qemu_ram_ptr_length similarly with qemu_map_ram_ptr
* Add a comment explaining qemu_map_ram_ptr and qemu_ram_ptr_length 
  semantic change for Xen
* Dropped some redundant changes

v2:
* Fix some building and coding style issues
---
 exec.c   |  16 +
 hw/display/vga.c |   5 +++
 xen-hvm.c| 104 ++-
 3 files changed, 40 insertions(+), 85 deletions(-)

diff --git a/exec.c b/exec.c
index aabb035..a1ac8cd 100644
--- a/exec.c
+++ b/exec.c
@@ -2008,6 +2008,14 @@ void *qemu_map_ram_ptr(RAMBlock *ram_block, ram_addr_t 
addr)
 }
 
 block->host = xen_map_cache(block->offset, block->max_length, 1);
+if (block->host == NULL) {
+/* In case we cannot establish the mapping right away we might
+ * still be able to do it later e.g. on a later stage of restore.
+ * We don't touch the block and return NULL here to indicate
+ * that intention.
+ */
+return NULL;
+}
 }
 return ramblock_ptr(block, addr);
 }
@@ -2041,6 +2049,14 @@ static void *qemu_ram_ptr_length(RAMBlock *ram_block, 
ram_addr_t addr,
 }
 
 block->host = xen_map_cache(block->offset, block->max_length, 1);
+if (block->host == NULL) {
+/* In case we cannot establish the mapping right away we might
+ * still be able to do it later e.g. on a later stage of restore.
+ * We don't touch the block and return NULL here to indicate
+ * that intention.
+ */
+return NULL;
+}
 }
 
 return ramblock_ptr(block, addr);
diff --git a/hw/display/vga.c b/hw/display/vga.c
index 69c3e1d..f8aebe3 100644
--- a/hw/display/vga.c
+++ b/hw/display/vga.c
@@ -2035,6 +2035,11 @@ static int vga_common_post_load(void *opaque, int 
version_id)
 {
 VGACommonState *s = opaque;
 
+if (xen_enabled() && !s->vram_ptr) {
+/* update VRAM region pointer in case we've failed
+ * the last time during init phase */
+s->vram_ptr = memory_region_get_ram_ptr(>vram);
+}
 /* force refresh */
 s->graphic_mode = -1;
 vbe_update_vgaregs(s);
diff --git a/xen-hvm.c b/xen-hvm.c
index 5043beb..8bedd9b 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -317,7 +317,6 @@ static int xen_add_to_physmap(XenIOState *state,
 XenPhysmap *physmap = NULL;
 hwaddr pfn, start_gpfn;
 hwaddr phys_offset = memory_region_get_ram_addr(mr);
-char path[80], value[17];
 const char *mr_name;
 
 if (get_physmapping(state, start_addr, size)) {
@@ -340,6 +339,22 @@ go_physmap:
 DPRINTF("mapping vram to %"HWADDR_PRIx" - %"HWADDR_PRIx"\n",
 start_addr, start_addr + size);
 
+mr_name = memory_region_name(mr);
+
+physmap = g_malloc(sizeof(XenPhysmap));
+
+physmap->start_addr = start_addr;
+physmap->size = size;
+physmap->name = mr_name;
+physmap->phys_offset = phys_offset;
+
+QLIST_INSERT_HEAD(>physmap, physmap, list);
+
+if (runstate_check(RUN_STATE_INMIGRATE)) {
+/* If we are migrating the region has been already mapped */
+return 0;
+}
+
 pfn = phys_offset >> TARGET_PAGE_BITS;
 start_gpfn = start_addr >> TARGET_PAGE_BITS;
 for (i = 0; i < size >> TARGET_PAGE_BITS; i++) {
@@ -350,49 +365,17 @@ go_physmap:
 if (rc) {
 DPRINTF("add_to_physmap MFN %"PRI_xen_pfn" to PFN %"
 PRI_xen_pfn" failed: %d (errno: %d)\n", idx, gpfn, rc, 
errno);
+
+QLIST_REMOVE(physmap, list);
+g_free(physmap);
  

Re: [Xen-devel] [PATCH v3 2/4] x86: remove PVHv1 code

[Wei Liu]

On Tue, Mar 14, 2017 at 10:27:25AM +, Wei Liu wrote:
> On Mon, Mar 13, 2017 at 04:50:12PM +, Wei Liu wrote:
> > On Fri, Mar 03, 2017 at 12:25:06PM +, Roger Pau Monne wrote:
> > > This removal applies to both the hypervisor and the toolstack side of 
> > > PVHv1.
> > > 
> > > Note that on the toolstack side a new PVH domain type is introduced to 
> > > libxl.
> > > The "none" device model version is removed, together with the "pvh" field 
> > > in
> > > the create info struct (the defines announcing those features are also 
> > > removed
> > > from libxl.h). The canonical way to create a PVH guest in libxl is to add
> > > "pvh=1" to the guest config file.
> > > 
> > > Signed-off-by: Roger Pau Monné 
> > > Reviewed-by: Andrew Cooper 
> > > Acked-by: George Dunlap 
> > > Reviewed-by: Paul Durrant 
> > > Acked-by: Elena Ufimtseva 
> > > Reviewed-by: Kevin Tian 
> > > ---
> > > Changes since v1:
> > >  - Remove dom0pvh option from the command line docs.
> > >  - Bump domctl interface version due to the removed CDF flag.
> > >  - Introduce LIBXL_DOMAIN_TYPE_PVH.
> > >  - Remove "none" from the valid device model version options.
> > >  - Update the xl.cfg(5) man page to reflect the changes.
> > > 
> > > ---
> > > Cc: Ian Jackson 
> > > Cc: Wei Liu 
> > > Cc: Elena Ufimtseva 
> > > Cc: Jan Beulich 
> > > Cc: Andrew Cooper 
> > > Cc: Paul Durrant 
> > > Cc: Jun Nakajima 
> > > Cc: Kevin Tian 
> > > Cc: George Dunlap 
> > > Cc: Razvan Cojocaru 
> > > Cc: Tamas K Lengyel 
> > > ---
> > >  docs/man/xl.cfg.pod.5.in|  16 +-
> > >  docs/misc/pvh-readme.txt|  63 
> > >  docs/misc/xen-command-line.markdown |   7 -
> > >  tools/debugger/gdbsx/xg/xg_main.c   |   4 +-
> > >  tools/libxc/include/xc_dom.h|   1 -
> > >  tools/libxc/include/xenctrl.h   |   2 +-
> > >  tools/libxc/xc_cpuid_x86.c  |  13 +-
> > >  tools/libxc/xc_dom_core.c   |   9 --
> > >  tools/libxc/xc_dom_x86.c|  49 +++---
> > >  tools/libxc/xc_domain.c |   1 -
> > >  tools/libxl/libxl.h |  22 +--
> > >  tools/libxl/libxl_console.c |   1 +
> > >  tools/libxl/libxl_create.c  |  64 +++-
> > >  tools/libxl/libxl_disk.c|  10 +-
> > >  tools/libxl/libxl_dm.c  |   2 +
> > >  tools/libxl/libxl_dom.c |  86 ++-
> > >  tools/libxl/libxl_dom_save.c|   7 +-
> > >  tools/libxl/libxl_dom_suspend.c |   4 +-
> > >  tools/libxl/libxl_domain.c  |  18 +--
> > >  tools/libxl/libxl_internal.h|   1 -
> > >  tools/libxl/libxl_mem.c |   1 +
> > >  tools/libxl/libxl_nic.c |   7 +-
> > >  tools/libxl/libxl_pci.c |   9 +-
> > >  tools/libxl/libxl_stream_read.c |   8 +-
> > >  tools/libxl/libxl_stream_write.c|  14 +-
> > >  tools/libxl/libxl_types.idl | 115 ---
> > >  tools/libxl/libxl_usb.c |   4 +-
> > >  tools/libxl/libxl_x86.c |  31 ++--
> > >  tools/libxl/libxl_x86_acpi.c|   3 +-
> > >  tools/xl/xl_parse.c |   8 +-
> > [...]
> > > +[("hvm", libxl_domain_build_info_hvm),
> > > + ("pvh", libxl_domain_build_info_hvm),
> > 
> > This "pvh" field is never used in code - instead you fill in the hvm
> > fields. It is problematic because people don't know how to use this.
> > 
> > Either we don't want this, or you would have to (tediously) fill this
> > in. I think the latter is what Ian has asked for. Unfortunately C
> > doesn't have good support for meta-programming.
> 
> On second thought, let's look at this from user's perspective. A user of
> libxl would certainly use .u.pvh field to construct a pvh guest, so I
> think we need the pvh struct.
> 
> Since .u.pvh and .u.hvm share the same layout and type-punning via union
> is allowed even when strict-aliasing is enabled, this patch *might* just
> work. (Can someone familiar with C standard check this?)
> 
> Ultimately I would like to avoid tricky code like this even it conforms
> to C standard. Let me check if there is a way forward.
> 

The more I think about this, the more I realise we're trying to do two
things at the same time: to remove PVHv1 code and repurpose toolstack
elements (xl pvh option, and b_info etc). This is the reason why this
series has been dragging on longer than necessary. And no doubt doing
the two at the same time will make this patch difficult to review.

Hence I propose to do one thing at a time. This patch should just remove
the PVHv1 implementation, and 

Re: [Xen-devel] WTH is going on with memory hotplug sysf interface

[Michal Hocko]

On Tue 14-03-17 12:05:59, YASUAKI ISHIMATSU wrote:
> 
> 
> On 03/13/2017 05:19 AM, Michal Hocko wrote:
> >On Fri 10-03-17 12:39:27, Yasuaki Ishimatsu wrote:
> >>On 03/10/2017 08:58 AM, Michal Hocko wrote:
[...]
> >>># echo online_movable > /sys/devices/system/memory/memory34/state
> >>># grep . /sys/devices/system/memory/memory3?/valid_zones
> >>>/sys/devices/system/memory/memory32/valid_zones:Normal
> >>>/sys/devices/system/memory/memory33/valid_zones:Normal Movable
> >>>/sys/devices/system/memory/memory34/valid_zones:Movable Normal
> >>>
> >>
> >>I think there is no strong reason which kernel has the restriction.
> >>By setting the restrictions, it seems to have made management of
> >>these zone structs simple.
> >
> >Could you be more specific please? How could this make management any
> >easier when udev is basically racing with the physical hotplug and the
> >result is basically undefined?
> >
> 
> When changing zone from NORMAL(N) to MOVALBE(M), we must resize both zones,
> zone->zone_start_pfn and zone->spanned_pages. Currently there is the
> restriction.
> 
> So we just simply change:
>   zone(N)->spanned_pages -= nr_pages
>   zone(M)->zone_start_pfn -= nr_pages

Yes I understand how this made the implementation simpler. I was
questioning how this made user management any easier. Changing
valid zones which races with the hotplug consumer (e.g. udev) sounds
like a terrible idea to me.

Anyway, it seems that the initial assumption/restriction that all
pages have to start on the zone Normal is not really needed. I have a
preliminary patch which removes that and associates newly added pages
with a zone at the online time and it seems to be working reasonably
well. I have to iron out some corners before I post it.
-- 
Michal Hocko
SUSE Labs

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

Re: [Xen-devel] WTH is going on with memory hotplug sysf interface

[YASUAKI ISHIMATSU]

On 03/13/2017 05:19 AM, Michal Hocko wrote:

On Fri 10-03-17 12:39:27, Yasuaki Ishimatsu wrote:

On 03/10/2017 08:58 AM, Michal Hocko wrote:

[...]

OK so I did with -m 2G,slots=4,maxmem=4G -numa node,mem=1G -numa node,mem=1G 
which generated
[...]
[0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009]
[0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x0010-0x3fff]
[0.00] ACPI: SRAT: Node 1 PXM 1 [mem 0x4000-0x7fff]
[0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x1-0x27fff] hotplug
[0.00] NUMA: Node 0 [mem 0x-0x0009] + [mem 
0x0010-0x3fff] -> [mem 0x-0x3fff]
[0.00] NODE_DATA(0) allocated [mem 0x3fffc000-0x3fff]
[0.00] NODE_DATA(1) allocated [mem 0x7ffdc000-0x7ffd]
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x1000-0x00ff]
[0.00]   DMA32[mem 0x0100-0x7ffd]
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x1000-0x0009efff]
[0.00]   node   0: [mem 0x0010-0x3fff]
[0.00]   node   1: [mem 0x4000-0x7ffd]

so there is neither any normal zone nor movable one at the boot time.
Then I hotplugged 1G slot
(qemu) object_add memory-backend-ram,id=mem1,size=1G
(qemu) device_add pc-dimm,id=dimm1,memdev=mem1

unfortunatelly the memory didn't show up automatically and I got
[  116.375781] acpi PNP0C80:00: Enumeration failure

so I had to probe it manually (prbably the BIOS my qemu uses doesn't
support auto probing - I haven't really dug further). Anyway the SRAT
table printed during the boot told that we should start at 0x1

# echo 0x1 > /sys/devices/system/memory/probe
# grep . /sys/devices/system/memory/memory32/valid_zones
Normal Movable

which looks reasonably right? Both Normal and Movable zones are allowed

# echo $((0x1+(128<<20))) > /sys/devices/system/memory/probe
# grep . /sys/devices/system/memory/memory3?/valid_zones
/sys/devices/system/memory/memory32/valid_zones:Normal
/sys/devices/system/memory/memory33/valid_zones:Normal Movable

Huh, so our valid_zones have changed under our feet...

# echo $((0x1+2*(128<<20))) > /sys/devices/system/memory/probe
# grep . /sys/devices/system/memory/memory3?/valid_zones
/sys/devices/system/memory/memory32/valid_zones:Normal
/sys/devices/system/memory/memory33/valid_zones:Normal
/sys/devices/system/memory/memory34/valid_zones:Normal Movable

and again. So only the last memblock is considered movable. Let's try to
online them now.

# echo online_movable > /sys/devices/system/memory/memory34/state
# grep . /sys/devices/system/memory/memory3?/valid_zones
/sys/devices/system/memory/memory32/valid_zones:Normal
/sys/devices/system/memory/memory33/valid_zones:Normal Movable
/sys/devices/system/memory/memory34/valid_zones:Movable Normal



I think there is no strong reason which kernel has the restriction.
By setting the restrictions, it seems to have made management of
these zone structs simple.


Could you be more specific please? How could this make management any
easier when udev is basically racing with the physical hotplug and the
result is basically undefined?



When changing zone from NORMAL(N) to MOVALBE(M), we must resize both zones,
zone->zone_start_pfn and zone->spanned_pages. Currently there is the
restriction.

So we just simply change:
  zone(N)->spanned_pages -= nr_pages
  zone(M)->zone_start_pfn -= nr_pages

But if every memory can change zone with no restriction, we must recalculate
these zones spanned_pages and zone_start_pfn follows:

  memory section #
   1 2 3 4 5 6 7
  |N|M|N|N|N|M|M|
 |
  |N|N|N|N|N|M|M|
 * change memory section #2 from MOVABLE to NORMAL.
   then we must find next movable memory section (#6) and resize these zones.

I think when implementing movable memory, there is no requirement of this.
So kernel has the current restriction.

Thanks,
Yasuaki Ishimatsu

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

Re: [Xen-devel] [PATCH 10/10] x86/cpuid: Always enable faulting for the control domain

[Wei Liu]

On Tue, Mar 14, 2017 at 09:13:08AM -0600, Jan Beulich wrote:
> >>> On 14.03.17 at 16:06,  wrote:
> > On Mon, Mar 13, 2017 at 05:48:44AM -0600, Jan Beulich wrote:
> >> >>> On 10.03.17 at 18:10,  wrote:
> >> > On 28/02/17 09:31, Jan Beulich wrote:
> >> > On 27.02.17 at 16:10,  wrote:
> >> >>> On 22/02/17 10:10, Jan Beulich wrote:
> >> >>> On 22.02.17 at 11:00,  wrote:
> >> > On 22/02/17 09:23, Jan Beulich wrote:
> >> > On 20.02.17 at 12:00,  wrote:
> >> >>> The domain builder in libxc no longer depends on leaked CPUID 
> >> >>> information 
> > to
> >> >>> properly construct HVM domains.  Remove the control domain 
> >> >>> exclusion.
> >> >> Am I missing some intermediate step? As long as there's a raw
> >> >> CPUID invocation in xc_cpuid_x86.c (which is still there in staging
> >> >> and I don't recall this series removing it) it at least _feels_ 
> >> >> unsafe.
> >> > Strictly speaking, the domain builder part of this was completed 
> >> > after
> >> > my xsave adjustments.  All the guest-type-dependent information now
> >> > comes from non-cpuid sources in libxc, or Xen ignores the toolstack
> >> > values and recalculates information itself.
> >> >
> >> > However, until the Intel leaves were complete, dom0 had a hard time
> >> > booting with this change as there were no toolstack-provided policy 
> >> > and
> >> > no leakage from hardware.
> >>  So what are the CPUID uses in libxc then needed for at this point?
> >>  Could they be removed in a prereq patch to make clear all needed
> >>  information is now being obtained via hypercalls?
> >> >>> I'd prefer to defer that work.  The next chunk of CPUID work is going 
> >> >>> to
> >> >>> be redesigning and reimplementing the hypervisor/libxc interface, and
> >> >>> all cpuid() calls in libxc will fall out there, but its not a trivial
> >> >>> set of changes to make.
> >> >> With that, could you live with deferring the patch here until then?
> >> > 
> >> > We currently have a lot of dom0 implicit dependencies on leaked CPUID
> >> > state into PV dom0.
> >> > 
> >> > With this series, I believe I have identified all leaked dependencies,
> >> > and I really want to prevent is introducing any new implicit dependences
> >> > accidentally.
> >> 
> >> I can certainly understand this, but the state libxc code is in then
> >> makes this a rather implicit thing, instead of being fully explicit. I
> >> think I'd like to have another (tools or REST) maintainer voice a 3rd
> >> opinion. Extending Cc list ...
> > 
> > I'm not sure I follow the implicit vs explicit bit.
> 
> Right now libxc still uses the CPUID instruction, thus implicitly (via
> CPUID faulting / masking) obtaining the intended (filtered) state of
> individual feature flags. The intended explicit way would be for it
> to instead use hypercalls to retrieve the information.
> 

AFAICT having this patch won't make things worse than before, with the
added benefit of avoiding dependencies of leaked information. If my
understanding is correct, I'm slightly in favour of committing it now.

Wei.

> Jan
> 

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

[Xen-devel] 2017 Xen Project Developer and Design Summit: CfP open from now to April 14, Event is held July 11-13, 2017 in Budapest

[Lars Kurth]

Dear Community Members, 

I am excited to announce that registration and the call for proposals is open 
for Xen Project Developer and Design Summit 2017, which will be held in 
Budapest, Hungary from July 11-13, 2017. The Xen Project Developer and Design 
Summit combines the formats of Xen Project Developer Summits with Xen Project 
Hackathons, and brings together the Xen Project’s community. We will aim to 
have talks in the mornings and smaller interactive design and problem solving 
sessions in the afternoon. 

Note that the CfP period is quite short: if you need extra time, or you 
otherwise have difficulties with the CfP please contact me via 
community.mana...@xenproject.org.

Submit a Talk
=

Several formats are being accepted for speaking proposals, including: 

* Presentations and Panels: these are presentations and panels as we always had 
them at Developer Summits in the past
* Interactive design and problem solving sessions. These sessions can be 
submitted as part of the CFP, but we will reserve a number of design sessions 
to be allocated during the event. Proposers of design sessions are expected to 
host and moderate design sessions following the format we have used at Xen 
Project Hackathons. If you have not participated in these in the past, check 
out past event reports from 2016 
(https://blog.xenproject.org/2016/04/26/xen-project-hackathon-16-event-report), 
2015 
(https://blog.xenproject.org/2015/05/07/xen-project-hackathon-15-event-report) 
and 2013 
(https://blog.xenproject.org/2013/05/28/event-report-xen-hackathon-2013). 

Never talked at a conference before? Don’t worry! We encourage new speakers to 
submit for our events and have plenty of resources to help you prepare for your 
presentation. 

Here are some dates to remember for submissions and in general:

* CFP Close: April 14, 2017
* CFP Notifications: May 5, 2017
* Schedule Announced: May 16, 2017
* Event: July 11-13, 2017

What is different to past events?
=

* We are merging the 2 day Hackathons and 2 day Developer summit into a 
combined 3 day event.
* It is possible to submit Interactive design and problem solving sessions (or 
Hackathon sessions) via the CFP.
* Lunch will be provided 

Registration


Registration information is available at 
https://events.linuxfoundation.org/events/xen-developer-and-design-summit/attend/register

Travel stipends are only available for students or individuals that are not 
associated with a company. 

Accommodation and other information
===

General information about the event can be found on 
http://events.linuxfoundation.org/events/xen-developer-and-design-summit

Note that the following information is not yet in place: we will add this 
shortly
- visa letter requests
- hotel block booking information

If you have any questions, please contact me via 
community.mana...@xenproject.org 

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

Re: [Xen-devel] [PATCH] xen/arm: Register re-mapped Xen area as a temporary virtual region

[Julien Grall]

Hello Wei,

On 14/03/17 09:27, Wei Chen wrote:

While we're doing apply_alternatives, we will generate new instructions


I didn't spot this on the first review. apply_alternatives does not call 
__apply_alternatives_multi_stop, so please clarify the problem.


Cheers,

--
Julien Grall

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

[Xen-devel] [xen-unstable-smoke test] 106664: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  48321fa86ddefe2fddf728dc972b01bb7c7c8559
baseline version:
 xen  ffb8499504e3a3d065bd44fdc1e15d0e6b74ce9f

Last test of basis   106658  2017-03-14 12:02:07 Z0 days
Testing same since   106664  2017-03-14 14:01:45 Z0 days1 attempts


People who touched revisions under test:
  Wei Liu 
  Zhang Chen 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 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=48321fa86ddefe2fddf728dc972b01bb7c7c8559
+ . ./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 
48321fa86ddefe2fddf728dc972b01bb7c7c8559
+ branch=xen-unstable-smoke
+ revision=48321fa86ddefe2fddf728dc972b01bb7c7c8559
+ . ./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.8-testing
+ '[' x48321fa86ddefe2fddf728dc972b01bb7c7c8559 = 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
++ : 

Re: [Xen-devel] [PATCH] xen/arm: Register re-mapped Xen area as a temporary virtual region

[Julien Grall]

Hello Wei,

Title: I would add alternative to make clear this is touching alternative.

On 14/03/17 09:27, Wei Chen wrote:

While we're doing apply_alternatives, we will generate new instructions
if required. The new instructions need to update the Xen text section,
but Xen text section is read-only. So we re-map Xen to a new virtual
address to enable write access.

The targets of the new generated instructions are located in this
re-mapped Xen area. But we haven't register this area as a virtual
region, so the checking code determines the targets are not in the
Xen text section, the new instructions could not be generated.

In this patch, we register the re-mapped Xen area as a temporary
virtual region to make the new instructions can be generated
successfully.

Signed-off-by: Wei Chen 
---


This patch would need to be backported on Xen 4.8.

For the rest, see Konrad's comment.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] boot allocator: Use arch helper for virt_to_mfn on DIRECTMAP

[Julien Grall]

Hello Vijay,

On 13/03/17 11:43, vijay.kil...@gmail.com wrote:

From: Vijaya Kumar K 

On ARM, virt_to_mfn uses the hardware for address
translation. So if the virtual address is not mapped translation
fault is raised.On ARM, DIRECTMAP_VIRT region is direct mapped.


This is not true. As I said before, all the memory will be direct mapped 
on ARM64 but not on ARM32.


For ARM32, only xenheap will be direct mapped. So you may want to return 
is_xenheap_mfn(...). Or even return false in all the case. Either is 
fine by me, but it would need to be explained in the code.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] tools: correct build in directory below tools

[Wei Liu]

On Tue, Mar 14, 2017 at 04:04:41PM +0100, Juergen Gross wrote:
> Recent changes to create *.pc files introduced a bug when trying to
> build a library from a directory below tools as PKG_CONFIG_DIR wouldn't
> be set. Correct this by adding a default value to Rules.mk.
> 
> Signed-off-by: Juergen Gross 

Hmm... This isn't pretty.

But off the top of my head I can't think of anything better, and to fix
the immediate issue:

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 10/10] x86/cpuid: Always enable faulting for the control domain

[Jan Beulich]

>>> On 14.03.17 at 16:06,  wrote:
> On Mon, Mar 13, 2017 at 05:48:44AM -0600, Jan Beulich wrote:
>> >>> On 10.03.17 at 18:10,  wrote:
>> > On 28/02/17 09:31, Jan Beulich wrote:
>> > On 27.02.17 at 16:10,  wrote:
>> >>> On 22/02/17 10:10, Jan Beulich wrote:
>> >>> On 22.02.17 at 11:00,  wrote:
>> > On 22/02/17 09:23, Jan Beulich wrote:
>> > On 20.02.17 at 12:00,  wrote:
>> >>> The domain builder in libxc no longer depends on leaked CPUID 
>> >>> information 
> to
>> >>> properly construct HVM domains.  Remove the control domain exclusion.
>> >> Am I missing some intermediate step? As long as there's a raw
>> >> CPUID invocation in xc_cpuid_x86.c (which is still there in staging
>> >> and I don't recall this series removing it) it at least _feels_ 
>> >> unsafe.
>> > Strictly speaking, the domain builder part of this was completed after
>> > my xsave adjustments.  All the guest-type-dependent information now
>> > comes from non-cpuid sources in libxc, or Xen ignores the toolstack
>> > values and recalculates information itself.
>> >
>> > However, until the Intel leaves were complete, dom0 had a hard time
>> > booting with this change as there were no toolstack-provided policy and
>> > no leakage from hardware.
>>  So what are the CPUID uses in libxc then needed for at this point?
>>  Could they be removed in a prereq patch to make clear all needed
>>  information is now being obtained via hypercalls?
>> >>> I'd prefer to defer that work.  The next chunk of CPUID work is going to
>> >>> be redesigning and reimplementing the hypervisor/libxc interface, and
>> >>> all cpuid() calls in libxc will fall out there, but its not a trivial
>> >>> set of changes to make.
>> >> With that, could you live with deferring the patch here until then?
>> > 
>> > We currently have a lot of dom0 implicit dependencies on leaked CPUID
>> > state into PV dom0.
>> > 
>> > With this series, I believe I have identified all leaked dependencies,
>> > and I really want to prevent is introducing any new implicit dependences
>> > accidentally.
>> 
>> I can certainly understand this, but the state libxc code is in then
>> makes this a rather implicit thing, instead of being fully explicit. I
>> think I'd like to have another (tools or REST) maintainer voice a 3rd
>> opinion. Extending Cc list ...
> 
> I'm not sure I follow the implicit vs explicit bit.

Right now libxc still uses the CPUID instruction, thus implicitly (via
CPUID faulting / masking) obtaining the intended (filtered) state of
individual feature flags. The intended explicit way would be for it
to instead use hypercalls to retrieve the information.

Jan


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

Re: [Xen-devel] [PATCH] tools/libxl: correct distclean target

[Wei Liu]

On Tue, Mar 14, 2017 at 04:04:42PM +0100, Juergen Gross wrote:
> Commit 3e5f1a63b53920763 ("tools: adapt xenlight.pc and xlutil.pc to
> new pkg-config scheme") introduced an error for "make distclean" as
> *.pc.in are deleted which are now files in git.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

[James Bottomley]

On Tue, 2017-03-14 at 12:29 +, Reshetova, Elena wrote:
> > Elena Reshetova  writes:
> > 
> > > refcount_t type and corresponding API should be
> > > used instead of atomic_t when the variable is used as
> > > a reference counter. This allows to avoid accidental
> > > refcounter overflows that might lead to use-after-free
> > > situations.
> > > 
> > > Signed-off-by: Elena Reshetova 
> > > Signed-off-by: Hans Liljestrand 
> > > Signed-off-by: Kees Cook 
> > > Signed-off-by: David Windsor 
> > > ---
> > >  drivers/md/md.c | 6 +++---
> > >  drivers/md/md.h | 3 ++-
> > >  2 files changed, 5 insertions(+), 4 deletions(-)
> > 
> > When booting linux-next (specifically 5be4921c9958ec) I'm seeing
> > the
> > backtrace below. I suspect this patch is just exposing an existing
> > issue?
> 
> Yes, we have actually been following this issue in the another
> thread. 
> It looks like the object is re-used somehow, but I can't quite
> understand how just by reading the code. 
> This was what I put into the previous thread:
> 
> "The log below indicates that you are using your refcounter in a bit
> weird way in mddev_find(). 
> However, I can't find the place (just by reading the code) where you
> would increment refcounter from zero (vs. setting it to one).
> It looks like you either iterate over existing nodes (and increment
> their counters, which should be >= 1 at the time of increment) or
> create a new node, but then mddev_init() sets the counter to 1. "
> 
> If you can help to understand what is going on with the object
> creation/destruction, would be appreciated!
> 
> Also Shaohua Li stopped this patch coming from his tree since the 
> issue was caught at that time, so we are not going to merge this 
> until we figure it out. 

Asking on the correct list (dm-devel) would have got you the easy
answer:  The refcount behind mddev->active is a genuine atomic.  It has
refcount properties but only if the array fails to initialise (in that
case, final put kills it).  Once it's added to the system as a gendisk,
it cannot be freed until md_free().  Thus its ->active count can go to
zero (when it becomes inactive; usually because of an unmount). On a
simple allocation regardless of outcome, the last executed statement in
md_alloc is mddev_put(): that destroys the device if we didn't manage
to create it or returns 0 and adds an inactive device to the system
which the user can get with mddev_find().

James



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

Re: [Xen-devel] [PATCH 10/10] x86/cpuid: Always enable faulting for the control domain

[Wei Liu]

On Mon, Mar 13, 2017 at 05:48:44AM -0600, Jan Beulich wrote:
> >>> On 10.03.17 at 18:10,  wrote:
> > On 28/02/17 09:31, Jan Beulich wrote:
> > On 27.02.17 at 16:10,  wrote:
> >>> On 22/02/17 10:10, Jan Beulich wrote:
> >>> On 22.02.17 at 11:00,  wrote:
> > On 22/02/17 09:23, Jan Beulich wrote:
> > On 20.02.17 at 12:00,  wrote:
> >>> The domain builder in libxc no longer depends on leaked CPUID 
> >>> information to
> >>> properly construct HVM domains.  Remove the control domain exclusion.
> >> Am I missing some intermediate step? As long as there's a raw
> >> CPUID invocation in xc_cpuid_x86.c (which is still there in staging
> >> and I don't recall this series removing it) it at least _feels_ unsafe.
> > Strictly speaking, the domain builder part of this was completed after
> > my xsave adjustments.  All the guest-type-dependent information now
> > comes from non-cpuid sources in libxc, or Xen ignores the toolstack
> > values and recalculates information itself.
> >
> > However, until the Intel leaves were complete, dom0 had a hard time
> > booting with this change as there were no toolstack-provided policy and
> > no leakage from hardware.
>  So what are the CPUID uses in libxc then needed for at this point?
>  Could they be removed in a prereq patch to make clear all needed
>  information is now being obtained via hypercalls?
> >>> I'd prefer to defer that work.  The next chunk of CPUID work is going to
> >>> be redesigning and reimplementing the hypervisor/libxc interface, and
> >>> all cpuid() calls in libxc will fall out there, but its not a trivial
> >>> set of changes to make.
> >> With that, could you live with deferring the patch here until then?
> > 
> > We currently have a lot of dom0 implicit dependencies on leaked CPUID
> > state into PV dom0.
> > 
> > With this series, I believe I have identified all leaked dependencies,
> > and I really want to prevent is introducing any new implicit dependences
> > accidentally.
> 
> I can certainly understand this, but the state libxc code is in then
> makes this a rather implicit thing, instead of being fully explicit. I
> think I'd like to have another (tools or REST) maintainer voice a 3rd
> opinion. Extending Cc list ...
> 

I'm not sure I follow the implicit vs explicit bit.

Wei.

> Jan
> 

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

[Xen-devel] [PATCH] tools/libxl: correct distclean target

[Juergen Gross]

Commit 3e5f1a63b53920763 ("tools: adapt xenlight.pc and xlutil.pc to
new pkg-config scheme") introduced an error for "make distclean" as
*.pc.in are deleted which are now files in git.

Signed-off-by: Juergen Gross 
---
 tools/libxl/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 12ab2a1..566b706 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -337,7 +337,6 @@ clean:
$(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR) clean
 
 distclean: clean
-   $(RM) -f xenlight.pc.in xlutil.pc.in
 
 realclean: distclean
$(RM) -f $(AUTOSRCS) $(AUTOINCS)
-- 
2.10.2


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

[Xen-devel] [PATCH] tools: correct build in directory below tools

[Juergen Gross]

Recent changes to create *.pc files introduced a bug when trying to
build a library from a directory below tools as PKG_CONFIG_DIR wouldn't
be set. Correct this by adding a default value to Rules.mk.

Signed-off-by: Juergen Gross 
---
 tools/Rules.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/Rules.mk b/tools/Rules.mk
index 8b8c48e..a888560 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -249,6 +249,8 @@ $(XEN_ROOT)/config/Tools.mk:
$(error You have to run ./configure before building or installing the 
tools)
 endif
 
+PKG_CONFIG_DIR ?= $(XEN_ROOT)/tools/pkg-config
+
 $(PKG_CONFIG_DIR)/%.pc: %.pc.in Makefile
mkdir -p $(PKG_CONFIG_DIR)
@sed -e 's!@@version@@!$(PKG_CONFIG_VERSION)!g' \
-- 
2.10.2


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

Re: [Xen-devel] [PATCH] EFI: retrieve and expose Apple device properties

[Andrew Cooper]

On 14/03/17 14:42, Jan Beulich wrote:
> Apple's EFI drivers supply device properties which are needed to
> support Macs optimally. They contain vital information which cannot be
> obtained any other way (e.g. Thunderbolt Device ROM). They're also used
> to convey the current device state so that OS drivers can pick up where
> EFI drivers left (e.g. GPU mode setting).
>
> Reference: Linux commit 58c5475aba67706b31d9237808d5d3d54074e5ea (see
> there for the full original commit message, only the initial part of
> which is being reproduced above)
>
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 

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

[Xen-devel] [qemu-mainline test] 106648: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
106641 REGR. vs. 106574

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken pass in 
106641
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 3 host-install(3) broken pass in 
106641

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106574
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106574
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106574
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106574
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 106574
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106574

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

version targeted for testing:
 qemuu5bac3c39c82e149515c10643acafd1d292433775
baseline version:
 qemuudd4d2578215cd380f40a38028a9904e15b135ef3

Last test of basis   106574  2017-03-09 19:12:40 Z4 days
Failing since106635  2017-03-13 11:48:20 Z1 days3 attempts
Testing same since   106641  2017-03-13 20:45:59 Z0 days2 attempts


People who touched revisions under test:
  Alex Bennée 
  Alexander Boettcher 
  Eduardo Habkost 

Re: [Xen-devel] [PATCH] tools/libxc: Exposed XEN_DOMCTL_getvcpuextstate

[Wei Liu]

On Tue, Mar 14, 2017 at 03:30:18PM +0200, Razvan Cojocaru wrote:
> It's useful for an introspection tool to be able to inspect
> XSAVE states. Xen already has a DOMCTL that can be used for this
> purpose, but it had no public libxc wrapper. This patch adds
> xc_vcpu_get_extstate().
> 
> Signed-off-by: Razvan Cojocaru 

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH] EFI: retrieve and expose Apple device properties

[Jan Beulich]

Apple's EFI drivers supply device properties which are needed to
support Macs optimally. They contain vital information which cannot be
obtained any other way (e.g. Thunderbolt Device ROM). They're also used
to convey the current device state so that OS drivers can pick up where
EFI drivers left (e.g. GPU mode setting).

Reference: Linux commit 58c5475aba67706b31d9237808d5d3d54074e5ea (see
there for the full original commit message, only the initial part of
which is being reproduced above)

Signed-off-by: Jan Beulich 

--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -38,6 +38,8 @@
   { 0xf2fd1544, 0x9794, 0x4a2c, {0x99, 0x2e, 0xe5, 0xbb, 0xcf, 0x20, 0xe3, 
0x94} }
 #define SHIM_LOCK_PROTOCOL_GUID \
   { 0x605dab50, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 
0x23} }
+#define APPLE_PROPERTIES_PROTOCOL_GUID \
+  { 0x91bd12fe, 0xf6c3, 0x44fb, { 0xa5, 0xb7, 0x51, 0x22, 0xab, 0x30, 0x3a, 
0xe0} }
 
 typedef EFI_STATUS
 (/* _not_ EFIAPI */ *EFI_SHIM_LOCK_VERIFY) (
@@ -48,6 +50,44 @@ typedef struct {
 EFI_SHIM_LOCK_VERIFY Verify;
 } EFI_SHIM_LOCK_PROTOCOL;
 
+struct _EFI_APPLE_PROPERTIES;
+
+typedef EFI_STATUS
+(EFIAPI *EFI_APPLE_PROPERTIES_GET) (
+IN struct _EFI_APPLE_PROPERTIES *This,
+IN const EFI_DEVICE_PATH *Device,
+IN const CHAR16 *PropertyName,
+OUT VOID *Buffer,
+IN OUT UINT32 *BufferSize);
+
+typedef EFI_STATUS
+(EFIAPI *EFI_APPLE_PROPERTIES_SET) (
+IN struct _EFI_APPLE_PROPERTIES *This,
+IN const EFI_DEVICE_PATH *Device,
+IN const CHAR16 *PropertyName,
+IN const VOID *Value,
+IN UINT32 ValueLen);
+
+typedef EFI_STATUS
+(EFIAPI *EFI_APPLE_PROPERTIES_DELETE) (
+IN struct _EFI_APPLE_PROPERTIES *This,
+IN const EFI_DEVICE_PATH *Device,
+IN const CHAR16 *PropertyName);
+
+typedef EFI_STATUS
+(EFIAPI *EFI_APPLE_PROPERTIES_GETALL) (
+IN struct _EFI_APPLE_PROPERTIES *This,
+OUT VOID *Buffer,
+IN OUT UINT32 *BufferSize);
+
+typedef struct _EFI_APPLE_PROPERTIES {
+UINTN Version; /* 0x1 */
+EFI_APPLE_PROPERTIES_GET Get;
+EFI_APPLE_PROPERTIES_SET Set;
+EFI_APPLE_PROPERTIES_DELETE Delete;
+EFI_APPLE_PROPERTIES_GETALL GetAll;
+} EFI_APPLE_PROPERTIES;
+
 union string {
 CHAR16 *w;
 char *s;
@@ -900,6 +940,46 @@ static void __init efi_variables(void)
 }
 }
 
+static void __init efi_get_apple_properties(void)
+{
+static EFI_GUID __initdata props_guid = APPLE_PROPERTIES_PROTOCOL_GUID;
+EFI_APPLE_PROPERTIES *props;
+UINT32 size = 0;
+VOID *data;
+EFI_STATUS status;
+
+if ( efi_bs->LocateProtocol(_guid, NULL,
+(void **)) != EFI_SUCCESS )
+return;
+if ( props->Version != 0x1 )
+{
+PrintStr(L"Warning: Unsupported Apple device properties version: ");
+DisplayUint(props->Version, 0);
+PrintStr(newline);
+return;
+}
+
+props->GetAll(props, NULL, );
+if ( !size ||
+ efi_bs->AllocatePool(EfiRuntimeServicesData, size,
+  ) != EFI_SUCCESS )
+return;
+
+status = props->GetAll(props, data, );
+if ( status == EFI_SUCCESS )
+{
+efi_apple_properties_addr = (UINTN)data;
+efi_apple_properties_len = size;
+}
+else
+{
+efi_bs->FreePool(data);
+PrintStr(L"Warning: Could not query Apple device properties: ");
+DisplayUint(status, 0);
+PrintStr(newline);
+}
+}
+
 static void __init efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN 
gop_mode)
 {
 EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
@@ -1208,6 +1288,9 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
 /* Get snapshot of variable store parameters. */
 efi_variables();
 
+/* Collect Apple device properties, if any. */
+efi_get_apple_properties();
+
 efi_arch_memory_setup();
 
 if ( gop )
--- a/xen/common/efi/efi.h
+++ b/xen/common/efi/efi.h
@@ -36,3 +36,6 @@ extern const struct efi_pci_rom *efi_pci
 
 extern UINT64 efi_boot_max_var_store_size, efi_boot_remain_var_store_size,
   efi_boot_max_var_size;
+
+extern UINT64 efi_apple_properties_addr;
+extern UINTN efi_apple_properties_len;
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -56,6 +56,9 @@ UINT64 __read_mostly efi_boot_max_var_st
 UINT64 __read_mostly efi_boot_remain_var_store_size;
 UINT64 __read_mostly efi_boot_max_var_size;
 
+UINT64 __read_mostly efi_apple_properties_addr;
+UINTN __read_mostly efi_apple_properties_len;
+
 /* Bit field representing available EFI features/properties. */
 unsigned int efi_flags;
 
@@ -271,6 +274,14 @@ int efi_get_info(uint32_t idx, union xen
 }
 return -ESRCH;
 }
+
+case XEN_FW_EFI_APPLE_PROPERTIES:
+if ( !efi_apple_properties_len )
+return -ENODATA;
+info->apple_properties.address = efi_apple_properties_addr;
+info->apple_properties.size = efi_apple_properties_len;
+break;
+
 

Re: [Xen-devel] [PATCH] x86emul: correct {,v}{ld,st}mxcsr handling

[Andrew Cooper]

On 14/03/17 14:12, Jan Beulich wrote:
> Calls to get_fpu() were missing. Calls to put_fpu() are deliberately
> not being added: Neither instruction can raise #XM, so the catch-all
> _put_fpu() is just fine here.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH RFC 0/4] Fix issues with zero-length records in migration v2

[Wei Liu]

On Tue, Mar 14, 2017 at 01:50:44PM +, Andrew Cooper wrote:
> On 14/03/17 13:20, Julien Grall wrote:
> > Hi Andrew,
> >
> > On 21/07/16 18:17, Andrew Cooper wrote:
> >> This series is RFC because it has only had compile testing thusfar.
> >>
> >> On AMD hardware supporting Debug Extentions, migration of a PV guest
> >> which is
> >> not currently using Debug Extentions fails, as the save side writes a
> >> X86_PV_VCPU_MSRS record with 0 content, which the receving side
> >> chokes on.
> >>
> >> It was alway the intention that such a record would be omitted, but that
> >> obviously didn't go as intended.
> >>
> >> Adjust the docs to clarify that such records should be omitted, but that
> >> receving sides should tolerate their presence.
> >
> > Last December you requested this series to be a blocker for Xen 4.9
> > (see [1]). Do you have any update on the status?
> 
> As previously identified, my opinion is that the code as presented in v1
> is correct, and there have been no reasonable arguments to the contrary.
> 
> I can post v1 again, but it won't be altered.
> 

What about the subthread starting from
<22422.18745.380486.234...@mariner.uk.xensource.com> ?

> ~Andrew

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

Re: [Xen-devel] [PATCH v2 04/17] tools: install PKG_INSTALLDIR in tools/Makefile

[Wei Liu]

On Tue, Mar 14, 2017 at 02:31:11PM +0100, Juergen Gross wrote:
> Instead of installing $(PKG_INSTALLDIR) in multiple Makefiles below
> tools, do so in tools/Makefile.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH] x86emul: correct {,v}{ld,st}mxcsr handling

[Jan Beulich]

Calls to get_fpu() were missing. Calls to put_fpu() are deliberately
not being added: Neither instruction can raise #XM, so the catch-all
_put_fpu() is just fine here.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -6509,6 +6509,7 @@ x86_emulate(
 vcpu_must_have(sse);
 ldmxcsr:
 generate_exception_if(src.type != OP_MEM, EXC_UD);
+get_fpu(vex.opcx ? X86EMUL_FPU_ymm : X86EMUL_FPU_xmm, );
 generate_exception_if(src.val & ~mxcsr_mask, EXC_GP, 0);
 asm volatile ( "ldmxcsr %0" :: "m" (src.val) );
 break;
@@ -6518,6 +6519,7 @@ x86_emulate(
 vcpu_must_have(sse);
 stmxcsr:
 generate_exception_if(dst.type != OP_MEM, EXC_UD);
+get_fpu(vex.opcx ? X86EMUL_FPU_ymm : X86EMUL_FPU_xmm, );
 asm volatile ( "stmxcsr %0" : "=m" (dst.val) );
 break;
 



x86emul: correct {,v}{ld,st}mxcsr handling

Calls to get_fpu() were missing. Calls to put_fpu() are deliberately
not being added: Neither instruction can raise #XM, so the catch-all
_put_fpu() is just fine here.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -6509,6 +6509,7 @@ x86_emulate(
 vcpu_must_have(sse);
 ldmxcsr:
 generate_exception_if(src.type != OP_MEM, EXC_UD);
+get_fpu(vex.opcx ? X86EMUL_FPU_ymm : X86EMUL_FPU_xmm, );
 generate_exception_if(src.val & ~mxcsr_mask, EXC_GP, 0);
 asm volatile ( "ldmxcsr %0" :: "m" (src.val) );
 break;
@@ -6518,6 +6519,7 @@ x86_emulate(
 vcpu_must_have(sse);
 stmxcsr:
 generate_exception_if(dst.type != OP_MEM, EXC_UD);
+get_fpu(vex.opcx ? X86EMUL_FPU_ymm : X86EMUL_FPU_xmm, );
 asm volatile ( "stmxcsr %0" : "=m" (dst.val) );
 break;
 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel