Re: [Xen-devel] [sh_eth.c] Problem in dma_map_single()

[Wonseok Ko]

Hi Konrad,

In dma_capable(), it checks that mask, size and address of device.

Currently, it dosen't pass to first condition code as below:

if (!dev->dma_mask)

return 0;

It shows the device doesn't have dma_mask bit. So I tried to set the
dma_mask bit in sh_eth.c

My approaches:
1. I tried to set a mask bit(dev->dma_mask) to use
dma_coerce_mask_and_coherent()
in sh_eth_drv_probe(), but it doesn't work.
2. forced set dev->dma_mask without kernel api. I passed to dma_capable()
but driver cannot work.

sh_eth driver want to get valid DMA descriptor to set DMA descriptor
address for Rx and Tx.
I tried to set the some bits(such as dma_mask) to get valid dma address
forcibly, in this configuration sh_eth cannot work.

My question is if I want to get valid dma address with xen swiotlb(suchas
map_page, set_dma_mask and so on)?




Thanks,
Wonseok.

2016-04-13 2:10 GMT+09:00 Konrad Rzeszutek Wilk :

> On Tue, Apr 12, 2016 at 04:54:55PM +0900, Wonseok Ko wrote:
> > Hi,
> >
> > I'm trying to enable ethernet driver in Domain0 for R-Car H2, but it
> > doesn't work. The root cause of the problem is that driver cannot satisfy
> > the condition of dma_capable(). I found the same problem in the mailing
>
> So what can be done about making it dma_capable() ?
>
> > list, but the problem is still remaining I guess. previous mail: (
> > http://lists.xen.org/archives/html/xen-devel/2014-10/msg03170.html)
> >
> > Does anyone give me advise?
> >
> > My environment as below:
> > - dom0 linux version: 4.3
> > - xen version: 4.6 commit(40d7a7454835c2f7c639c78f6c09e7b6f0e4a4e2)
> >
> >
> > Thanks,
> > Wonseok.
>
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  ad584cbb6cfd4a13dfe6bb80650edbebc7fba8a9
baseline version:
 libvirt  799ced1f80b10d32815615e4d342aa71f8e1c113

Last test of basis90907  2016-04-11 04:50:43 Z2 days
Testing same since91073  2016-04-12 04:32:24 Z1 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Cole Robinson 
  Martin Kletzander 
  Nikolay Shirokovskiy 
  Pavel Hrdina 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd pass



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=ad584cbb6cfd4a13dfe6bb80650edbebc7fba8a9
+ . ./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 libvirt 
ad584c

[Xen-devel] [PATCH V2] vm_event: Allow subscribing to write events for specific MSR-s

[Razvan Cojocaru]

Previously, subscribing to MSR write events was an all-or-none
approach, with special cases for introspection MSR-s. This patch
allows the vm_event consumer to specify exactly what MSR-s it is
interested in, and as a side-effect gets rid of the
vmx_introspection_force_enabled_msrs[] special case.
This replaces the previously posted "xen: Filter out MSR write
events" patch.

Signed-off-by: Razvan Cojocaru 

---
Changes since V1:
 - Removed ARM stubs.
 - Corrected domain_unpause(d) omission.
 - Moved enable / disable and query functions from vm_event.c to
   monitor.c.
---
 tools/libxc/include/xenctrl.h  |  4 +-
 tools/libxc/xc_monitor.c   |  6 +--
 xen/arch/x86/hvm/event.c   |  3 +-
 xen/arch/x86/hvm/hvm.c |  3 +-
 xen/arch/x86/hvm/vmx/vmcs.c| 26 ++---
 xen/arch/x86/hvm/vmx/vmx.c | 10 ++---
 xen/arch/x86/monitor.c | 79 --
 xen/arch/x86/vm_event.c| 10 +
 xen/include/asm-x86/domain.h   |  4 +-
 xen/include/asm-x86/hvm/hvm.h  |  8 ++--
 xen/include/asm-x86/hvm/vmx/vmcs.h |  7 
 xen/include/asm-x86/monitor.h  |  2 +
 xen/include/public/domctl.h|  3 +-
 13 files changed, 99 insertions(+), 66 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index f5a034a..9698d46 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2183,8 +2183,8 @@ int xc_monitor_get_capabilities(xc_interface *xch, 
domid_t domain_id,
 int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t domain_id,
  uint16_t index, bool enable, bool sync,
  bool onchangeonly);
-int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, bool enable,
-  bool extended_capture);
+int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, uint32_t msr,
+  bool enable);
 int xc_monitor_singlestep(xc_interface *xch, domid_t domain_id, bool enable);
 int xc_monitor_software_breakpoint(xc_interface *xch, domid_t domain_id,
bool enable);
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index b1705dd..78131b2 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -86,8 +86,8 @@ int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t 
domain_id,
 return do_domctl(xch, &domctl);
 }
 
-int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, bool enable,
-  bool extended_capture)
+int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, uint32_t msr,
+  bool enable)
 {
 DECLARE_DOMCTL;
 
@@ -96,7 +96,7 @@ int xc_monitor_mov_to_msr(xc_interface *xch, domid_t 
domain_id, bool enable,
 domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
 : XEN_DOMCTL_MONITOR_OP_DISABLE;
 domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR;
-domctl.u.monitor_op.u.mov_to_msr.extended_capture = extended_capture;
+domctl.u.monitor_op.u.mov_to_msr.msr = msr;
 
 return do_domctl(xch, &domctl);
 }
diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
index 56c5514..015910b 100644
--- a/xen/arch/x86/hvm/event.c
+++ b/xen/arch/x86/hvm/event.c
@@ -57,9 +57,8 @@ bool_t hvm_event_cr(unsigned int index, unsigned long value, 
unsigned long old)
 void hvm_event_msr(unsigned int msr, uint64_t value)
 {
 struct vcpu *curr = current;
-struct arch_domain *ad = &curr->domain->arch;
 
-if ( ad->monitor.mov_to_msr_enabled )
+if ( arch_monitor_is_msr_enabled(curr->domain, msr) )
 {
 vm_event_request_t req = {
 .reason = VM_EVENT_REASON_MOV_TO_MSR,
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index f24126d..7c2a98c 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3695,7 +3695,6 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 bool_t mtrr;
 unsigned int edx, index;
 int ret = X86EMUL_OKAY;
-struct arch_domain *currad = ¤t->domain->arch;
 
 HVMTRACE_3D(MSR_WRITE, msr,
(uint32_t)msr_content, (uint32_t)(msr_content >> 32));
@@ -3703,7 +3702,7 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 hvm_cpuid(1, NULL, NULL, NULL, &edx);
 mtrr = !!(edx & cpufeat_mask(X86_FEATURE_MTRR));
 
-if ( may_defer && unlikely(currad->monitor.mov_to_msr_enabled) )
+if ( may_defer && unlikely(arch_monitor_is_msr_enabled(v->domain, msr)) )
 {
 ASSERT(v->arch.vm_event);
 
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 8284281..f92f4b8 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -108,18 +109,6 @@ u64 vmx_ept_vpid_cap __read_mostly;
 u64 vmx_vmfunc __read_mo

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 86491
 build-i386-libvirt5 libvirt-build fail REGR. vs. 86491
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 86491
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail REGR. vs. 86491
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail REGR. vs. 86491

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

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

version targeted for testing:
 xen  8b27d2b8af898597367e2a97aaed3e3404eda5af
baseline version:
 xen  a6f2cdb633bf519244a16674031b8034b581ba7f

Last test of basis86491  2016-03-17 15:24:59 Z   26 days
Failing since 86560  2016-03-18 10:56:34 Z   25 days   27 attempts
Testing same since91053  2016-04-12 01:13:11 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andrew Cooper  [for the Ocaml stubs]
  Anthony PERARD 
  Boris Ostrovsky 
  Changlong Xie 
  Chong Li 
  Chong Li 
  Chunyan Liu 
  Dagaen Golomb 
  Daniel De Graaf 
  Daniel De Graaf  [XSM bits]
  Dario Fagggioli 
  Dario Faggioli 
  Dasaratharaman Chandramouli 
  Dave Scott 
  David Scott 
  David Vrabel 
  Doug Goldstein 
  Fu Wei 
  George Dunlap 
  George Dunlap 
  George Dunlap  [xenctx bits]
  Harmandeep Kaur 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jim Fehlig 
  Joao Martins 
  Jonathan Davies

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

[Jan Beulich]

>>> Ian Jackson  04/12/16 6:47 PM >>>
>George Dunlap writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested 
>Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ 
>>but sane."):
>> Well we know which option Andy prefers, but are there other options
>> that Andy is not absolutely opposed to?  And we don't know anything
>> about which option Jan prefers at all, except that it's not #4.
>
>Let me go a bit further than George.
>
>It's clear that there are various options, most of which are
>tolerable.  Buit if I'm trying to help referee a disagreement between
>Andrew and Jan I would prefer to be choosing between Andrew's
>preferred answer and Jan's preferred answer.
>
>Jan: AFAICT it's clear that you would still like the current patch
>reverted.  Can you please say what, if anything, you would like to
>replace it with ?

That patch doesn't need replacing by anything. It's the follow-up patch adding
support to retrieve the build-id which would need a replacement, and several
options have been put on the table. As mentioned before, I'd prefer the variant
of the new sub-op getting added to the existing version hypercall, with the
needed length argument passed either via a structure element, with the
structure pointed to by the 2nd hypercall argument, or with the high bits of
the first hypercall argument re-purposed to allow (and for this sub-op require)
holding a length. Which of these two sub-options is chosen I don't really care
much.

Jan


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

Re: [Xen-devel] Question about the XEN platform pci

[Wu, Bob]

Subject: Re: [Xen-devel] Question about the XEN platform pci

The INTx interrupt of this platform device can be used by Xen in HVM case to 
notify the guest of pending events in the event channel. However that's usually 
not used in favor of vector callbacks support in Xen where a vector is injected 
directly to the vCPU bypassing LAPIC.

(that said, the platform-pci driver in linux is actually broken when vector 
callbacks are not used anyway)

I also think that the grant-table lives on this PCI device MMIO BAR (?!)

If you looked at hw/i386/xen/xen_platform.c in QEMU source , you will get a 
general idea what this device is supposed todo (like logging to syslog stuff 
for example).

That said the platform device is really not fully utilized anyway in Linux.


Yes, the answer is my expected, so the biggest reason of platform PCI still 
existing in the kernel code is that INTx interrupt or vector callback will need 
the help of it.
Thanks Karim.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Xen-users] DomU fails to reboot with storage driver domain

[Alex Velazquez]

On Fri, Apr 1, 2016 at 9:54 AM, Wei Liu  wrote:
> On Fri, Apr 01, 2016 at 02:43:32PM +0100, Ian Jackson wrote:
>> Wei Liu writes ("Re: [Xen-users] DomU fails to reboot with storage driver 
>> domain"):
>> > On Fri, Apr 01, 2016 at 01:04:42PM +0200, Roger Pau Monné wrote:
>> > > TBH, I don't see an easy way to solve this, I've thought about fetching
>> > > the "backend" node from the xenstore frontend path of each device, but
>> > > that's not safe since the guest can modify those entries.
>> > >
>> > Interrogating frontend  is not entirely unsafe because we can validate
>> > that path before reading from it. There is also a backend-id field that
>> > we can use if that make validation easier -- no need to parse a frontend
>> > provided string.
>> >
>> > Another fix is to fetch all backend domain name / domid from JSON, then
>> > fetch all xenstore backend entries. This is safe because JSON is not
>> > controlled by guest. This might require adding locks to multiple APIs,
>> > but luckily that wouldn't change their semantics.
>> >
>> > Ian, do you have better ideas?
>>
>> Either of these two approaches sound good.
>>
>> I'm not sure why using the JSON domid would need any additional
>> locking.  The code here already has the JSON in its hand, doesn't it ?
>> But using the domain _name_ rather than the domid is wrong, and I
>> think the JSON might have only the name.
>>
>
> The APIs that retrieve lists of devices will need to lock JSON config
> as well, which they don't currently do because they only reference
> xenstore.
>
>> I think the xenstore approach is probably better.  I think it may be
>> best to use (with checking) the frontend's backend path, since ideally
>> we would find the corresponding device entry directly.
>>
>> But I am happy with whatever is most convenient.
>>
>
> Interrogating frontend is more convenient.
>
>> I think we should fix this for 4.7 and the fix is a bugfix so OK to go
>> in after the freeze.
>>
>
> Yes, it's a bug that should be fixed. I can give it a stab next week
> when I'm back in office unless someone else beats me to it.
>
> Wei.
>
>> Ian.

Hi all,

Not sure that there's any further information I can provide to help
with this, as it sounds like a viable solution has been proposed.
However, if/when there is a patch available, I am happy to test it out
on my end.

Thanks,
Alex

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

Re: [Xen-devel] [PATCH v7 25/24] symbols/xsplice: Implement fast symbol names -> virtual addresses lookup

[Konrad Rzeszutek Wilk]

On Tue, Apr 12, 2016 at 10:03:12PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 12, 2016 at 04:59:02PM -0400, Konrad Rzeszutek Wilk wrote:
> > The current mechanism is geared towards fast virtual address ->
> > symbol names lookup. This is fine for the normal use cases
> > (BUG_ON, WARN_ON, etc), but for xSplice - where we need to find
> > hypervisor symbols - it is slow.
> .. snip..
> > NEW CODE:
> > Searching for symbols is simplified as we can do a binary search
> > on symbol_names_sorted (and using symbols_markers_sorted). Since the
> > symbols are sorted it takes on average 13 calls to symbols_expand_symbol.
> 
> And there is a bug somewhere. The virtual address that was tied to
> 'printk' actually ended up being tied to 'printed.21561'!
> 
> As such, when reviewing this code be aware there is something I must have 
> missed!



diff --git a/xen/common/symbols.c b/xen/common/symbols.c
index cfea93e..3d7e5b2 100644
--- a/xen/common/symbols.c
+++ b/xen/common/symbols.c
@@ -261,7 +261,7 @@ unsigned long symbols_lookup_by_name(const char *symname)
 else if ( rc > 0 )
 low = mid + 1;
 else
-return symbols_address(symbols_addresses_index_sorted[low]);
+return symbols_address(symbols_addresses_index_sorted[mid]);
 }
 return 0;
 }

Fixes it.

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

Re: [Xen-devel] [PATCH v7 25/24] symbols/xsplice: Implement fast symbol names -> virtual addresses lookup

[Konrad Rzeszutek Wilk]

On Tue, Apr 12, 2016 at 04:59:02PM -0400, Konrad Rzeszutek Wilk wrote:
> The current mechanism is geared towards fast virtual address ->
> symbol names lookup. This is fine for the normal use cases
> (BUG_ON, WARN_ON, etc), but for xSplice - where we need to find
> hypervisor symbols - it is slow.
.. snip..
> NEW CODE:
> Searching for symbols is simplified as we can do a binary search
> on symbol_names_sorted (and using symbols_markers_sorted). Since the
> symbols are sorted it takes on average 13 calls to symbols_expand_symbol.

And there is a bug somewhere. The virtual address that was tied to
'printk' actually ended up being tied to 'printed.21561'!

As such, when reviewing this code be aware there is something I must have 
missed!

Also:

>  static void write_src(void)
.. snip..
> + /* Debug data. */
> + printf(" # %s [idx=%u] [%c]", table[i].symbol, table[i].idx, 
> table[i].type);

This shouldn't be there..

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-i386 10 guest-start fail REGR. vs. 86454
 test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 86454
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
86454
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 86454
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 86454
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 86454
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 86454
 test-amd64-amd64-qemuu-nested-intel  9 debian-hvm-install fail REGR. vs. 86454
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 86454
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
86454
 test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-installfail REGR. vs. 86454
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 86454
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 
86454
 test-amd64-i386-qemuu-rhel6hvm-amd  9 redhat-install  fail REGR. vs. 86454
 test-amd64-amd64-qemuu-nested-amd  9 debian-hvm-install   fail REGR. vs. 86454
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. 
vs. 86454
 test-armhf-armhf-xl-cubietruck 16 guest-start.2   fail REGR. vs. 86454

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 86454
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 86454
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 86454

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

version targeted for testing:
 qemuu4e71220387e88a22e03e47cabd5aafe105147746
baseline version:
 qemuud1f8764099022bc1173f2413331b26d4ff609a0c

Last test of basis86454  2016-03-17 06:01:30 Z   26 days
Failing since 86547  2016-03-18 07:12:41 Z   25 days   25 attempts
Testing same since91031  2016-04-11 21:29:49 Z1 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Bennée 
  Alex Bligh 
  Alex Williamson 
  Alexey Kardashevskiy 
  Andrew Baumann 
  Andrey Smetanin 
  Anthony Perard 
  Aurelien Jarno 
  Bandan Das 
  Bastian Koppelmann 
  B

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 66399
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 66399
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 
66399
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat fail REGR. vs. 66399
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail REGR. vs. 
66399
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. 
vs. 66399
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 66399
 test-armhf-armhf-xl-multivcpu 16 guest-start.2fail REGR. vs. 66399

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
in 89248 pass in 91008
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 90845 pass 
in 91008
 test-armhf-armhf-xl  15 guest-start/debian.repeat   fail pass in 89248
 test-armhf-armhf-xl-arndale  15 guest-start/debian.repeat   fail pass in 90845

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

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

version targeted for testing:
 linux206f91a12c5f69c9b4dfd4e0029043794a046933
baseline version:
 linux07cc49f66973f49a391c91bf4b158fa0f2562ca8

Last test of basis66399  2015-12-15 18:20:39 Z  119 days
Failing since 78925  2016-01-24 13:50:39 Z   79 days   85 attempts
Testing same since89248  2016-04-06 22:18:27 Z6 days4 attempts


520 people touched revisions under test,
not listing them all

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

[Xen-devel] [PATCH v2] x86/init: disable pnpbios and rtc for X86_SUBARCH_CE4100

[Luis R. Rodriguez]

As per hpa CE4100 platforms can also disable pnpbios [0].
Then Sebastian also recently noted that CE4100 also disables
RTC probe, to do that Sebastian had long ago added the RTC
of_have_populated_dt() check, he noted that it was meant to
skip the RTC probe on all OF platforms but as of now, CE4100
was the only x86 DT using this.

We can just fold this requirement into the platform quirk
then. This now means that all of these  match platform quirks
for pnpbios and RTC preferences:

  * X86_SUBARCH_XEN
  * X86_SUBARCH_LGUEST
  * X86_SUBARCH_INTEL_MID
  * X86_SUBARCH_CE4100

[0] http://lkml.kernel.org/r/5702b5c2.7070...@zytor.com
[1] http://lkml.kernel.org/r/570b52ea.60...@linutronix.de

Suggested-by: H. Peter Anvin 
Suggested-by: Sebastian Andrzej Siewior 
Signed-off-by: Luis R. Rodriguez 
---

This series on the other paravirt_enabled() series, I'll be testing
one more change to update one patch to reduce more space on __init,
the 0-day testing should be done by tomorrow and then I can adjust
the size computation on impact size.

 arch/x86/kernel/platform-quirks.c | 1 +
 arch/x86/kernel/rtc.c | 3 ---
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/x86/kernel/platform-quirks.c 
b/arch/x86/kernel/platform-quirks.c
index 853919484340..b2f8a33b36ff 100644
--- a/arch/x86/kernel/platform-quirks.c
+++ b/arch/x86/kernel/platform-quirks.c
@@ -17,6 +17,7 @@ void __init x86_early_init_platform_quirks(void)
case X86_SUBARCH_XEN:
case X86_SUBARCH_LGUEST:
case X86_SUBARCH_INTEL_MID:
+   case X86_SUBARCH_CE4100:
x86_platform.legacy.devices.pnpbios = 0;
x86_platform.legacy.rtc = 0;
break;
diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index ff4f4180fefd..eceaa082ec3f 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -186,9 +186,6 @@ static __init int add_rtc_cmos(void)
}
}
 #endif
-   if (of_have_populated_dt())
-   return 0;
-
if (!x86_platform.legacy.rtc)
return -ENODEV;
 
-- 
2.7.2


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

Re: [Xen-devel] [PATCH v1 0/2] x86/init: extend quirk use

[Luis R. Rodriguez]

On Mon, Apr 11, 2016 at 09:31:54AM +0200, Sebastian Andrzej Siewior wrote:
> On 04/09/2016 02:22 AM, Luis R. Rodriguez wrote:
> > What seems a bit odd is CE4100 leaves RTC enabled, can someone
> > confirm if indeed it really needs it, or can it also disable it
> > as with Xen, lguest, and Intel MID ?
> 
> So what you do with "x86_platform.legacy.rtc" is to skip
> add_rtc_cmos().

Yeap.

> For ce4100 I added of_have_populated_dt() to skip the probe.

Ah look at that.. x86 using device tree. Wasn't aware.

> If you plan to add this to CE4100 you could remove the
> "of_have_populated_dt()". It was meant to skip the RTC probe on all OF
> platforms but as of now, CE4100 is the only.

Indeed, this would clean up the add_rtc_cmos() path more and make
the semantics required for this a platform specific quirk which can
instead more easily be set by the platform on the generic:

x86_early_init_platform_quirks()

Will go a head and remove this hack as part of the CE4100 patch, and
also add CE4100 to the list of subarchs that need the RTC quirk.

  Luis

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

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

[Luis R. Rodriguez]

On Fri, Apr 08, 2016 at 11:58:54PM +0200, Luis R. Rodriguez wrote:
> On Fri, Apr 08, 2016 at 03:16:14PM +0100, George Dunlap wrote:
> > On 07/04/16 19:51, Luis R. Rodriguez wrote:
> > > While Andrew's position is right in that perhaps only Xen tools have to 
> > > deal
> > > with the HVMLite specific entry, it would also still mean diverging from 
> > > ARM's
> > > own EFI entry only position, which I'd like to clarify that ARM has no 
> > > custom
> > > Xen entry, we should strive to match that. Anything far from that to me 
> > > really
> > > deserves an explanation, specially if we are going to argue that HVMLite 
> > > is
> > > the best that x86 Xen can do.
> > > 
> > > Ultimately unifying entry approaches for Xen in a streamlined fashion 
> > > seems
> > > like a sensible thing to strive for. Anything we push in the other 
> > > direction,
> > > as small as it can be, should deserve at least a 'hey, wait a minute'...
> > 
> > Quick factual correction here.
> > 
> > "Since ARM guests only use the EFI entry point, x86 guests should also
> > only use the EFI entry point" is certainly a reasonable argument to make.
> > 
> > However, dom0 on ARM does not use the EFI entry point.  When starting
> > dom0, Xen uses the native entry point (the one that UBoot uses) and
> > hands dom0 a device-tree node.  The reason this is possible on ARM is
> > that there are no assumptions made about what hardware is or is not
> > present on the system -- everything that needs to be communicated about
> > what is or is not present can be passed in DT.
> > 
> > So it is incorrect to say that ARM has an "EFI entry only" position.
> > 
> > (On ACPI systems, it does apparently generate some UEFI informational
> > tables, which it passes to the dom0 kernel via DT; and the kernel
> > unpacks and puts in the right place.  Normal Xen ARM guests can use EFI,
> > but that's because we start OVMF in the guest context to provide the EFI
> > services.  These may be where the idea that ARM guests use only the UEFI
> > entry point came from.)
> > 
> > Obviously it would be nice if we could use the native entry point on x86
> > as well, but there's decades of legacy hardware and backwards
> > compatibility to deal with there.
> 
> OK thanks for the clarification -- still no custom entries for Xen!
> We should strive for that, at the very least.
> 
> You do have a point about the legacy stuff. There are two options there:
> 
>   * Fold legacy support under HVMLite -- which seems to be what we
> currently want to do (we should evaluate the implications and
> requirements here for that); or
> 
>   * Leave legacy stuff on the old PV path; this may be something to
> bring to the table if we had in place a proactive solution to
> avoid further fallout from the architecture of the huge differences
> on the entries. The work I'm doing should help with that. (We should
> also evaluate the implications and requirements here for that as
> well).

Also, x86 does have a history of short DT use. Just pointing that its there as
an option as well. I'll Cc you on some thread about that.

  Luis

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

Re: [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?

[Wei Liu]

On Tue, Apr 12, 2016 at 03:31:46PM -0600, Jim Fehlig wrote:
> Wei Liu wrote:
> > Hi libvirt maintainers,
> 
> Sorry for the delay. Slowly catching up on mail after vacation...
> 
> > 
> > Xen's control library libxenlight (libxl) requires application
> > (libvirt in this case) to explictily define LIBXL_API_VERSION.
> 
> Where is this requirement written? :-)
> 
> > This is
> > lacking at the moment so libvirt's libxl driver always gets the latest
> > APIs.
> 
> IMO, that is what we want for upstream libvirt. Downstreams can choose a
> specific version if they want.
> 
> > We changed one of the APIs in libxl so libvirt's libxl driver
> > can't build at the moment.
> 
> A quick glance ahead in my libvirt mail tells me you fixed this with the
> preferred LIBXL_HAVE_* pattern.
> 

It's already done that way. :-)

Wei.

> Regards,
> Jim

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

Re: [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?

[Jim Fehlig]

Wei Liu wrote:
> Hi libvirt maintainers,

Sorry for the delay. Slowly catching up on mail after vacation...

> 
> Xen's control library libxenlight (libxl) requires application
> (libvirt in this case) to explictily define LIBXL_API_VERSION.

Where is this requirement written? :-)

> This is
> lacking at the moment so libvirt's libxl driver always gets the latest
> APIs.

IMO, that is what we want for upstream libvirt. Downstreams can choose a
specific version if they want.

> We changed one of the APIs in libxl so libvirt's libxl driver
> can't build at the moment.

A quick glance ahead in my libvirt mail tells me you fixed this with the
preferred LIBXL_HAVE_* pattern.

Regards,
Jim

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

Re: [Xen-devel] xenpm and scheduler

[Dario Faggioli]

On Tue, 2016-04-12 at 17:46 +, tutu sky wrote:
> yeah, running xenpm gives short comments on its commands and their
> options but not about how to establish it.
> 
I do not understand what you mean with 'establishing' xenpm. If you run
Xen on a machine that has power management and/or frequency scaling
capabilities, you'll be able to use the various xenpm commands.

It most likely will have to be a real hardware box, as I don't think
emulation or nested virtualization satisfies the above condition (for
most of the emulator and hypervisor that I know of). You also need to
use a sufficiently recent Linux dom0 kernel. Konrad knows better than
me what's the minimum necessary version, but I don't think this is a
problem (i.e., any kernel since the last couple of years should work
fine).

Or was it something else you were asking?

Dario

> I try my best for this :)
> thanks a lot.
> 
> 
> From: Konrad Rzeszutek Wilk 
> Sent: Tuesday, April 12, 2016 5:08 PM
> To: tutu sky
> Cc: Dario Faggioli; Meng Xu; Xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] xenpm and scheduler
> 
> On Tue, Apr 12, 2016 at 05:04:04PM +, tutu sky wrote:
> > 
> > Thanks Konrad. I will do :)
> > Yeah, I believe so. as i can see that there is not any bios
> > settings for power management in there (vmware).  I hope you be the
> > correct party which i want to ask this question: there is a
> > tutorial here in this page:
> > 1) http://xenserver.org/partners/developing-products-for-xenserver/
> > 19-dev-help/138-xs-dev-perf-turbo.html
> > 
> > which i know as a quick guide for establishing xenpm. my Q is that,
> > are this page and this two page of xen.wiki below enough for
> > establishing xenpm and make it work totally?
> > 
> > 2) http://wiki.xenproject.org/wiki/Xenpm_command
> > 3) http://wiki.xenproject.org/wiki/Xen_power_management
> > 
> >  if yes, there is a problem, when i compiled xen from source, there
> > is not any xensource folder in /opt folder in dom0 to follow the
> > instructions in (1) address. i did all those instructions in dom0
> > config file instead.
> Xen source != XenServer.
> 
> 
> > 
> > 
> > if these guides are not enough in your point of view too, i think
> > (just as a suggestion), xenpm needs more documentation, in order to
> > clarify it's activation and usage progress. it remains a silent
> > area in this giant project although is quiet usable.
> > 
> If you run 'xenpm' by itself it gives you the options.
> 
> Patches to make an manpage for xenpm are always warmly welcome!
> > 
> > thanks and regards.
> > 
> > 
> > From: Konrad Rzeszutek Wilk 
> > Sent: Tuesday, April 12, 2016 1:41 PM
> > To: tutu sky
> > Cc: Dario Faggioli; Meng Xu; Xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] xenpm and scheduler
> > 
> > On Tue, Apr 12, 2016 at 11:50:42AM +, tutu sky wrote:
> > > 
> > > Thanks Dario,
> > > Yeah, I do like playing with xenpm and try understanding
> > > relationship between this and scheduler. but i established a xen
> > > environment on vmware, but xenpm does not work correctly and even
> > > for 'cpufreq', it is silent at all! so it does not let me try to
> > > play with :(. I asked this problem before in the user and devel
> > > lists both,  but no body answered me. how can i track the
> > > problem, from who (I know that power management is out of your
> > > maintenance scope)?? (may xenpm have the same problem on a real
> > > platform (again) instead of vmware?)
> > > thanks a lot.
> > You will have to.
> > 
> > I don't believe VMWare exposes C and P states to guests so
> > therefore
> > there is no power freqeuency in play.
> > 
> > > 
> > > regards.
> > > 
> > > From: Dario Faggioli 
> > > Sent: Tuesday, April 12, 2016 8:10 AM
> > > To: tutu sky; Meng Xu
> > > Cc: Xen-devel@lists.xen.org
> > > Subject: Re: [Xen-devel] xenpm and scheduler
> > > 
> > > On Tue, 2016-04-12 at 03:52 +, tutu sky wrote:
> > > > 
> > > > Thanks Xu. I will do as desired about cross messaging.
> > > > 
> > > > i need it because i exactly want to know that which part of the
> > > > scheduler's corde (credit), takes effect from this feature.
> > > > because
> > > > it is important to me knowing that where would be trade off
> > > > between
> > > > idle state and doing load balancing, while cpuidle feature is
> > > > activated. in other side it's important again for me that what
> > > > will
> > > > happen for 'cap; and 'weight' decreasing in a case that one
> > > > core's
> > > > frequency is lower than another one in the same socket
> > > > (actually when
> > > > cpufreq feature is enable).
> > > > 
> > > Currently, there is no interaction between the scheduler and the
> > > power
> > > management and frequency scaling layers.
> > > 
> > > > 
> > > > Am i clear enough? can you give me an answer or maybe some
> > > > lines of
> > > > schedule.c or sched_credit.c's code which i can track t

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

[Andy Lutomirski]

On Sun, Apr 10, 2016 at 10:12 PM, Juergen Gross  wrote:
> On 08/04/16 22:40, Luis R. Rodriguez wrote:
>> On Wed, Apr 06, 2016 at 10:40:08AM +0100, David Vrabel wrote:
>>> On 06/04/16 03:40, Luis R. Rodriguez wrote:

 * You don't need full EFI emulation
>>>
>>> I think needing any EFI emulation inside Xen (which is where it would
>>> need to be for dom0) is not suitable because of the increase in
>>> hypervisor ABI.
>>
>> Is this because of timing on architecture / design of HVMLite, or
>> a general position that the complexity to deal with EFI emulation
>> is too much for Xen's taste ?
>
> The Xen hypervisor should be as small as possible. Adding an EFI
> emulator will be adding quite some code. This should be done after a
> very thorough evaluation only.
>
>> ARM already went the EFI entry way for domU -- it went the OVMF route,
>> would such a possibility be possible for x86 domU HVMLite ? If not why
>> not, I mean it would seem to make sense to at least mimic the same type
>> of early boot environment, and perhaps there are some lessons to be
>> learned from that effort too.
>
> The final solution must be appropriate for dom0, too. So don't try
> to limit the discussion to domU. If dom0 isn't going to be acceptable
> there will no need to discuss domU.
>
>> Are there some lessons to be learned with ARM's effort? What are they?
>> If that could be re-done again with any type of cleaner path, what
>> could that be that could help the x86 side ?
>>
>> Although emulating EFI may require work, some folks have pointed out
>> that the amount of work may not be that much. If that is done can
>> we instead rely on the same code to replace OVMF to support both
>> Xen ARM and Xen HVMLite on x86 ? What would be the pros / cons of
>> this ?
>>
>>> I also still do not understand your objection to the current tiny stub.
>>
>> Its more of a hypothetical -- can an EFI entry be used instead given
>> it already does exactly what the new small entry does ? Its also rather
>> odd to add a new entry without evaluating fully a possible alternative
>> that would provide the same exact mechanism.
>
> The interface isn't the new entry only. It should be evaluated how much
> of the early EFI boot path would be common to the HVMlite one. What
> would be gained by using the same entry but having two different boot
> paths after it? You still need a way to distinguish between bare metal
> EFI and HVMlite. And Xen needs a way to find out whether a kernel is
> supporting HVMlite to boot it in the correct mode.
>
>> A full technical unbiased evaluation of the different approaches is what I'd
>> hope we could strive to achieve through discussion and peer review, thinking
>> and prioritizing ultimately what is best to minimize the impact on Linux
>> and also help take advantage of the best features possible through both
>> means. Thinking long term, not immediate short term.
>
> Sure.

FWIW, someone just pointed me to u-boot's EFI implementation.
u-boot's lib/efi_loader contains a tiny (<3k LOC, 10kB compiled) UEFI
implementation that's sufficient to boot a Linux EFI payload.

An argument against making Xen's default domU entry use UEFI is that
it might become unnecessarily awkward to do something like
chainloading to OVMF.   But maybe OVMF can be compiled as a UEFI
binary :)

--Andy

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

Re: [Xen-devel] [PATCH v5 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

[Luis R. Rodriguez]

On Mon, Apr 11, 2016 at 08:50:19AM +0200, Juergen Gross wrote:
> On 09/04/16 01:40, Luis R. Rodriguez wrote:
> > We have 4 types of x86 platforms that disable RTC:
> > 
> >   * Intel MID
> >   * Lguest - uses paravirt
> >   * Xen dom-U - uses paravirt
> >   * x86 on legacy systems annotated with an ACPI legacy flag
> > 
> > We can consolidate all of these into a platform specific legacy
> > quirk set early in boot through i386_start_kernel() and through
> > x86_64_start_reservations(). This deals with the RTC quirks which
> > we can rely on through the hardware subarch, the ACPI check can
> > be dealt with separately.
> > 
> > For Xen things are bit more complex given that the @X86_SUBARCH_XEN
> > x86_hardware_subarch is shared on for Xen which uses the PV path for
> > both domU and dom0. Since the semantics for differentiating between
> > the two are Xen specific we provide a platform helper to help override
> > default legacy features -- x86_platform.set_legacy_features(). Use
> > of this helper is highly discouraged, its only purpose should be
> > to account for the lack of semantics available within your given
> > x86_hardware_subarch.
> > 
> > As per 0-day, this bumps the vmlinux size using i386-tinyconfig as
> > follows:
> > 
> > TOTAL   TEXT   init.textx86_early_init_platform_quirks()
> > +70 +62+62  +43
> > 
> > Only 8 bytes overhead total, as the main increase in size is
> > all removed via __init.
> 
> I think this could be even less (see comment below).

Indeed.

> 
> > 
> > v2: split the subarch check from the ACPI check, clarify
> > on the ACPI change commit log why ordering works
> > v3: add x86_platform.set_legacy_features() to account for dom0,
> > add also size impact on vmlinux as per 0-day report
> 
> You missed the v5 changes here.


Sorry this was a mismatch, the v3 notes are the v5 notes, the
discrepancy between this and the subject was that the patches
have changed over time to be split out on their own and so 
iterations have been meshed / split, etc.. I'll just
update the accounting to match the subject next.

In next replies it would really help if you trim your review on
patches by removing context of the e-mail for hunks / file without
feedback, and only keep the file name / hunk for which you are
commenting on.

For instance:

> > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> > index 40487f1ecb4c..e066fcf87c3d 100644
> > --- a/arch/x86/xen/enlighten.c
> > +++ b/arch/x86/xen/enlighten.c
> > @@ -1192,7 +1192,6 @@ static const struct pv_info xen_info __initconst = {
> >  #ifdef CONFIG_X86_64
> > .extra_user_64bit_cs = FLAT_USER_CS64,
> >  #endif
> > -   .features = 0,
> > .name = "Xen",
> >  };
> >  
> > @@ -1505,6 +1504,11 @@ static void __init xen_pvh_early_guest_init(void)
> >  }
> >  #endif/* CONFIG_XEN_PVH */
> >  
> > +static void xen_dom0_set_legacy_features(void)
> 
> Can't you make this __init ?

Indeed, will change.

  Luis

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

[Xen-devel] [PATCH v7 25/24] symbols/xsplice: Implement fast symbol names -> virtual addresses lookup

[Konrad Rzeszutek Wilk]

The current mechanism is geared towards fast virtual address ->
symbol names lookup. This is fine for the normal use cases
(BUG_ON, WARN_ON, etc), but for xSplice - where we need to find
hypervisor symbols - it is slow.

To understand this patch, a description of the existing
method is explained first. For folks familar go to 'NEW CODE:'.

HOW IT WORKS:

The symbol table lookup mechanism uses a simple encoding mechanism
where it extracts the common ascii characters that the symbol's use.

This saves us space. The lookup mechanism is geared towards looking
up symbols based on address. We have one 0..N (where N is
the number of symbols, so 6849 for example) table:

symbols_addresses[0..N]

And an 1-1 (in a loose fashion) of the symbols (encoded) in a
symbols_names stream of size N.

The N is variable (later on that below)

The symbols_names are sorted based on symbols_addresses, which
means that the decoded entries inside symbols_names are not in
ascending or descending order.

There is also the encoding mechanism - the table of 255 entries
called symbols_token_index[]. And the symbols_token_table which
is an stream of ASCIIZ characters, such as (it really
is not a table as the values are variable):

@0   .asciz  "credit"
@6   .asciz  "mask"
..
@300 .asciz  "S"

And the symbols_token_index:
@0.short  0
@1.short  7
@2.short  12
@4.short  16
...
@84 .short  300

The relationship between them is that the symbols_token_index
gives us the offset to symbols_token_table.

The symbol_names[] array is a stream of encoded values. Each value
follows the same pattern -  followed by .
And the another  followed by .

Hence to find the right one you need to read , add 
(to skip over), read , add , and so on until one
finds the right tuple offset.

The  are the indicies into the symbols_token_index.

Meaning if you have:
  0x04, 0x54, 0xda, 0xe2, 0x74
  [4, 84, 218, 226, 116 in human numbering]

The 0x04 tells us that the symbol is four bytes past this one (so next
symbol offset starts at 5). If we lookup symbols_token_index[84] we get 300.
symbols_token[300] gets us the "S". And so on, the string eventually
end up being decode to be 'S_stext'. The first character is the type,
then optionally follwed by the filename (and # right after filename)
and then lastly the symbol, such as:

tvpmu_intel.c#core2_vpmu_do_interrupt

Keep in mind that there are two fixed sized tables:
symbols_addresses[0..symbols_num_syms], and
symbols_markers[0..symbols_num_syms/255].

The symbols_markers is used to speed searching for the right address.
It gives us the offsets within symbol_names that start at the .

The way to find a symbol based on the address is:
1) Figure out the 'tuple offset' from symbols_address[0..symbols_num_syms].
   This table is sorted by virtual addresses so finding the value is simple.
2) Get starting offset of symbol_names by retrieving value of
   symbol_markers['tuple offset' / 255].
3). Iterate up to 'tuple_offset & 255' in symbols_markers stream starting
   at 'offset'.
4). Decode the 

This however does not work very well if we want to search the other
way - we have the symbol name and want to find the address.

NEW CODE:

To make that work we add three tables:
1) symbols_addresses_index_sorted[0..symbols_num_syms]. The values are
 indicies into symbols_addresses array. This is a 1-1 table:

 symbols_addresses_index_sorted:
 .long   6315
 .long   6097

 To get the address of a symbol at offset 0 in symbols_name_sorted
 (see below) we look in symbols_addresses_index_sorted[0] to get
 6315 and then look in symbols_addresses_index[6315] to find it.

2) The symbols_names_sorted stream - same format as symbols_names but
 constructued by sorting the [filename#] by ,
 then [filename#] and lastly type. Recall that symbol_names is sorted
 based on addresses of the symbols.

3) To make it simpler to search we also add an symbols_markers_sorted
 array (of size symbols_num_syms/255).

Searching for symbols is simplified as we can do a binary search
on symbol_names_sorted (and using symbols_markers_sorted). Since the
symbols are sorted it takes on average 13 calls to symbols_expand_symbol.

Doing small tests (search for five different symbols) using the old
and new mechanism show 2ms vs 0ms improvement.

Signed-off-by: Konrad Rzeszutek Wilk 
---
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 

v7: New
---
---
 xen/arch/x86/Makefile  |  3 ++
 xen/common/Kconfig | 12 ++
 xen/common/symbols-dummy.c |  6 +++
 xen/common/symbols.c   | 75 
 xen/tools/symbols.c| 95 +++---
 5 files changed, 179 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index d46cf49..485f681 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -84,6 +84,9 @@ endif
 
 ifdef CONFIG_XSPLICE
 all_symbols = --all-symbols
+ifdef CONFIG_FAST_SYMBOL_LOOKUP
+all_s

Re: [Xen-devel] [PATCH v7] xSplice v1 design and implementation.

[Konrad Rzeszutek Wilk]

On Mon, Apr 11, 2016 at 10:32:20AM -0400, Konrad Rzeszutek Wilk wrote:
> > *Hypervisor Maintainers*
> >
> > Jan, the hypervisor patches #2, #5-#17, #21-#23 need your Ack.
> 
> s/Ack./Ack please./
> > *Are there any TODOs left from v5 or v6 reviews?*
> >
> > One I hope can be deferred - that is xensyms_read which we use in
> >  "[PATCH v7 12/24] xsplice,symbols: Implement symbol name resolution on
> >  address." is not the fastest. It will need some tweaking (or a new
> > function will have to be written) and I hope that this can be done in v4.8.
> 
> Let me correct myself. I am right now looking at it - so I may have it
> ready soonish but there are also bugs to work on.

And here is the patch. Please see

 [PATCH v7 25/24] symbols/xsplice: Implement fast symbol names -> virtual

 xen/arch/x86/Makefile  |  3 ++
 xen/common/Kconfig | 12 ++
 xen/common/symbols-dummy.c |  6 +++
 xen/common/symbols.c   | 75 
 xen/tools/symbols.c| 95 +++---
 5 files changed, 179 insertions(+), 12 deletions(-)

Konrad Rzeszutek Wilk (1):
  symbols/xsplice: Implement fast symbol names -> virtual addresses lookup


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

Re: [Xen-devel] [PATCH v5 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

[Luis R. Rodriguez]

On Mon, Apr 11, 2016 at 09:49:56AM -0400, Boris Ostrovsky wrote:
> On 04/08/2016 07:40 PM, Luis R. Rodriguez wrote:
> 
> diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
> index 1ae89a2721d6..8bb8c1a4615a 100644
> --- a/arch/x86/include/asm/x86_init.h
> +++ b/arch/x86/include/asm/x86_init.h
> @@ -142,6 +142,15 @@ struct x86_cpuinit_ops {
>  struct timespec;
>  /**
> + * struct x86_legacy_features - legacy x86 features
> + *
> + * @rtc: this device has a CMOS real-time clock present
> + */
> +struct x86_legacy_features {
> + int rtc;
> +};
> +
> +/**
>   * struct x86_platform_ops - platform specific runtime functions
>   * @calibrate_tsc:   calibrate TSC
>   * @get_wallclock:   get time from HW clock like RTC etc.
> @@ -152,6 +161,14 @@ struct timespec;
>   * @save_sched_clock_state:  save state for sched_clock() on suspend
>   * @restore_sched_clock_state:   restore state for sched_clock() on 
> resume
>   * @apic_post_init:  adjust apic if neeeded
> + * @legacy:  legacy features
> + * @set_legacy_features: override legacy features. Use of this callback
> + *   is highly discouraged. You should only need
> + *   this if your hardware platform requires further
> + *   custom fine tuning far beyong what may be
> + *   possible in x86_early_init_platform_quirks() by
> + *   only using the current x86_hardware_subarch
> + *   semantics.
>   */
>  struct x86_platform_ops {
>   unsigned long (*calibrate_tsc)(void);
> @@ -165,6 +182,8 @@ struct x86_platform_ops {
>   void (*save_sched_clock_state)(void);
>   void (*restore_sched_clock_state)(void);
>   void (*apic_post_init)(void);
> + struct x86_legacy_features legacy;
> 
> 
> I don't think this belongs here --- we are in the ops structure.

Bike shed thing -- I went with what Ingo suggested [0], which was to
embed things under x86_platform, and that happens to be this struct.

So unless I hear otherwise from the maintainer I'm sticking with it.

http://lkml.kernel.org/r/20160224083259.ga20...@gmail.com

  Luis

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

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

[Tamas K Lengyel]

Yes, I have been shuffling this struct around and didn't check the
>> layout. Will fix. I'll also try to make this struct usable for aarch64
>> too.
>>
>
> You may want to give a look to vcpu_guest_core_regs in public/arch-arm.h
>

Thanks, so the easiest way to be compatible with both it seems is to just
declare all registers 64-bit wide. The userspace can then mask the unused
bits if necessary.

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

[Xen-devel] [PATCHv8] x86/ept: defer the invalidation until the p2m lock is released

[David Vrabel]

Holding the p2m lock while calling ept_sync_domain() is very expensive
since it does an on_selected_cpus() call.  IPIs on many socket
machines can be very slow and on_selected_cpus() is serialized.

It is safe to defer the invalidate until the p2m lock is released
except for two cases:

1. When freeing a page table page (since partial translations may be
   cached).
2. When reclaiming a zero page as part of PoD.

For these cases, add p2m_tlb_flush_sync() calls which will immediately
perform the invalidate before the page is freed or reclaimed.

Signed-off-by: David Vrabel 
---
v8:
- p2m_tlb_flush_and_unlock() -> p2m_unlock_and_tlb_flush().
- p2m_unlock_and_tlb_flush() now does the unlock and the p2m
  implementation need only provide a tlb_flush() op.

v7:
- Add some more p2m_tlb_flush_sync() calls to PoD.
- More comments.

v6:
- Move p2m_tlb_flush_sync() to immediately before p2m_free_ptp().  It was
  called all the time otherwise.

v5:
- add p2m_tlb_flush_sync() and call it before freeing pgae table pages
  and reclaiming zeroed pod pages.

v2:
- use per-p2m list for deferred pages.
- update synced_mask while holding write lock.
---
 xen/arch/x86/mm/mm-locks.h | 23 +++
 xen/arch/x86/mm/p2m-ept.c  | 39 +++
 xen/arch/x86/mm/p2m-pod.c  |  4 
 xen/arch/x86/mm/p2m.c  | 26 ++
 xen/include/asm-x86/p2m.h  | 22 ++
 5 files changed, 98 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/mm-locks.h
index 8a40986..086c8bb 100644
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -265,14 +265,21 @@ declare_mm_lock(altp2mlist)
  */
 
 declare_mm_rwlock(altp2m);
-#define p2m_lock(p) \
-{   \
-if ( p2m_is_altp2m(p) ) \
-mm_write_lock(altp2m, &(p)->lock);  \
-else\
-mm_write_lock(p2m, &(p)->lock); \
-}
-#define p2m_unlock(p) mm_write_unlock(&(p)->lock);
+#define p2m_lock(p) \
+do {\
+if ( p2m_is_altp2m(p) ) \
+mm_write_lock(altp2m, &(p)->lock);  \
+else\
+mm_write_lock(p2m, &(p)->lock); \
+(p)->defer_flush++; \
+} while (0)
+#define p2m_unlock(p)   \
+do {\
+if ( --(p)->defer_flush == 0 )  \
+p2m_unlock_and_tlb_flush(p);\
+else\
+mm_write_unlock(&(p)->lock);\
+} while (0)
 #define gfn_lock(p,g,o)   p2m_lock(p)
 #define gfn_unlock(p,g,o) p2m_unlock(p)
 #define p2m_read_lock(p)  mm_read_lock(p2m, &(p)->lock)
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 3cb6868..1ed5b47 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -264,6 +264,7 @@ static void ept_free_entry(struct p2m_domain *p2m, 
ept_entry_t *ept_entry, int l
 unmap_domain_page(epte);
 }
 
+p2m_tlb_flush_sync(p2m);
 p2m_free_ptp(p2m, mfn_to_page(ept_entry->mfn));
 }
 
@@ -1096,15 +1097,10 @@ static void __ept_sync_domain(void *info)
  */
 }
 
-void ept_sync_domain(struct p2m_domain *p2m)
+static void ept_sync_domain_prepare(struct p2m_domain *p2m)
 {
 struct domain *d = p2m->domain;
 struct ept_data *ept = &p2m->ept;
-/* Only if using EPT and this domain has some VCPUs to dirty. */
-if ( !paging_mode_hap(d) || !d->vcpu || !d->vcpu[0] )
-return;
-
-ASSERT(local_irq_is_enabled());
 
 if ( nestedhvm_enabled(d) && !p2m_is_nestedp2m(p2m) )
 p2m_flush_nestedp2m(d);
@@ -1117,9 +1113,35 @@ void ept_sync_domain(struct p2m_domain *p2m)
  *of an EP4TA reuse is still needed.
  */
 cpumask_setall(ept->invalidate);
+}
+
+static void ept_sync_domain_mask(struct p2m_domain *p2m, const cpumask_t *mask)
+{
+on_selected_cpus(mask, __ept_sync_domain, p2m, 1);
+}
+
+void ept_sync_domain(struct p2m_domain *p2m)
+{
+struct domain *d = p2m->domain;
 
-on_selected_cpus(d->domain_dirty_cpumask,
- __ept_sync_domain, p2m, 1);
+/* Only if using EPT and this domain has some VCPUs to dirty. */
+if ( !paging_mode_hap(d) || !d->vcpu || !d->vcpu[0] )
+return;
+
+ept_sync_domain_prepare(p2m);
+
+if ( p2m->defer_flush )
+{
+p2m->need_flush = 1;
+return;
+}
+
+ept_sync_domain_mask(p2m, d->domain_dirty_cpumask);
+}
+
+static void ept_tlb_flush(struct p2m_domain *p2m)
+{
+ept_sync_domain_mask(p2m, p2m->domain->domain_dirty_cpumask);
 }
 
 static void ept_enable_pml(struct p2m_domain *p2m)
@@ -1170,6 +1192,7 @@ int ept_p2m_init(struct p2m_domain *p2m)
 p2m->change_entry_type_range = ept_change_en

[Xen-devel] [PATCHv8 0/1] x86/ept: reduce translation invalidation impact

[David Vrabel]

This series improves the performance of EPT by further reducing the
impact of the translation invalidations (ept_sync_domain()). By:

a) Deferring invalidations until the p2m write lock is released.

Prior to this change a 16 VCPU guest could not be successfully
migrated on an (admittedly slow) 160 PCPU box because the p2m write
lock was held for such extended periods of time.  This starved the
read lock needed (by the toolstack) to map the domain's memory,
triggering the watchdog.

After this change a 64 VCPU guest could be successfully migrated.

ept_sync_domain() is very expensive because:

a) it uses on_selected_cpus() and the IPI cost can be particularly
   high for a multi-socket machine.

b) on_selected_cpus() is serialized by its own spin lock.

On this particular box, ept_sync_domain() could take ~3-5 ms.

Simply using a fair rw lock was not sufficient to resolve this (but it
was an improvement) as the cost of the ept_sync_domain calls() was
still delaying the read locks enough for the watchdog to trigger (the
toolstack maps a batch of 1024 GFNs at a time, which means trying to
acquire the p2m read lock 1024 times).

Changes in v8:

- p2m_tlb_flush_and_unlock() -> p2m_unlock_and_tlb_flush().
- p2m_unlock_and_tlb_flush() now does the unlock and the p2m
  implementation need only provide a tlb_flush() op.

Changes in v7:

- Add some more p2m_tlb_flush_sync() calls to PoD.
- More comments.

Changes in v6:

- Fix performance bug in patch #2.
- Improve comments.

Changes in v5:

- Fix PoD by explicitly doing an invalidation before reclaiming zero
  pages.
- Use the same mechanism for dealing with freeing page table pages.
  This isn't a common path and its simpler than the deferred list.

Changes in v4:

- __ept_sync_domain() is a no-op -- invalidates are done before VMENTER.
- initialize ept->invalidate to all ones so the initial invalidate is
  always done.

Changes in v3:

- Drop already applied "x86/ept: remove unnecessary sync after
  resolving misconfigured entries".
- Replaced "mm: don't free pages until mm locks are released" with
  "x86/ept: invalidate guest physical mappings on VMENTER".

Changes in v2:

- Use a per-p2m (not per-CPU) list for page table pages to be freed.
- Hold the write lock while updating the synced_mask.

David


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

Re: [Xen-devel] [PATCH] vm_event: Allow subscribing to write events for specific MSR-s

[Razvan Cojocaru]

On 04/12/16 20:49, Tamas K Lengyel wrote:
> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
> index 1fec412..1be058a 100644
> --- a/xen/arch/x86/monitor.c
> +++ b/xen/arch/x86/monitor.c
> @@ -20,6 +20,7 @@
>   */
> 
>  #include 
> +#include 
>  #include 
> 
>  int arch_monitor_domctl_event(struct domain *d,
> @@ -77,25 +78,25 @@ int arch_monitor_domctl_event(struct domain *d,
> 
>  case XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR:
>  {
> -bool_t old_status = ad->monitor.mov_to_msr_enabled;
> +bool_t old_status;
> +int rc;
> +u32 msr = mop->u.mov_to_msr.msr;
> 
> -if ( unlikely(old_status == requested_status) )
> -return -EEXIST;
> +domain_pause(d);
> 
> -if ( requested_status && mop->u.mov_to_msr.extended_capture &&
> - !hvm_enable_msr_exit_interception(d) )
> -return -EOPNOTSUPP;
> +old_status = vm_event_is_msr_enabled(d, msr);
> 
> -domain_pause(d);
> +if ( unlikely(old_status == requested_status) )
> +return -EEXIST;
> 
> 
> Moving this test after the domain gets paused will leave the guest
> paused on error condition. Any reason why this rearrangement is necessary?

The rearrangement is necessary because vm_event_is_msr_enabled() uses
the per-domain bitmap to do its job, so I thought having the domain
paused when checking it would work best.

Leaving the domain paused there is an oversight, I need to correct that,
so thanks for noticing!

> -if ( requested_status && mop->u.mov_to_msr.extended_capture )
> -ad->monitor.mov_to_msr_extended = 1;
> +if ( requested_status )
> +rc = vm_event_enable_msr(d, msr);
>  else
> -ad->monitor.mov_to_msr_extended = 0;
> +rc = vm_event_disable_msr(d, msr);
> 
> -ad->monitor.mov_to_msr_enabled = requested_status;
>  domain_unpause(d);
> -break;
> +
> +return rc;
>  }
> 
>  case XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP:
> diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
> index 5635603..b851e39 100644
> --- a/xen/arch/x86/vm_event.c
> +++ b/xen/arch/x86/vm_event.c
> @@ -27,6 +27,13 @@ int vm_event_init_domain(struct domain *d)
>  {
>  struct vcpu *v;
> 
> +d->arch.monitor_msr_bitmap = alloc_xenheap_page();
> +
> +if ( !d->arch.monitor_msr_bitmap )
> +return -ENOMEM;
> +
> +memset(d->arch.monitor_msr_bitmap, 0, PAGE_SIZE);
> +
>  for_each_vcpu ( d, v )
>  {
>  if ( v->arch.vm_event )
> @@ -55,11 +62,66 @@ void vm_event_cleanup_domain(struct domain *d)
>  v->arch.vm_event = NULL;
>  }
> 
> +free_xenheap_page(d->arch.monitor_msr_bitmap);
> +d->arch.monitor_msr_bitmap = NULL;
> +
>  d->arch.mem_access_emulate_each_rep = 0;
>  memset(&d->arch.monitor, 0, sizeof(d->arch.monitor));
>  memset(&d->monitor, 0, sizeof(d->monitor));
>  }
> 
> +int vm_event_enable_msr(struct domain *d, u32 msr)
> 
> 
> This function..
>  
> 
> +{
> +if ( !d->arch.monitor_msr_bitmap )
> +return -EINVAL;
> +
> +if ( msr <= 0x1fff )
> +set_bit(msr, d->arch.monitor_msr_bitmap +
> 0x000/BYTES_PER_LONG);
> +else if ( (msr >= 0xc000) && (msr <= 0xc0001fff) )
> +{
> +msr &= 0x1fff;
> +set_bit(msr, d->arch.monitor_msr_bitmap +
> 0x400/BYTES_PER_LONG);
> +}
> +
> +hvm_enable_msr_interception(d, msr);
> +
> +return 0;
> +}
> +
> +int vm_event_disable_msr(struct domain *d, u32 msr)
> 
> 
> ..and this..
>  
> 
> +{
> +if ( !d->arch.monitor_msr_bitmap )
> +return -EINVAL;
> +
> +if ( msr <= 0x1fff )
> +clear_bit(msr, d->arch.monitor_msr_bitmap +
> 0x000/BYTES_PER_LONG);
> +else if ( (msr >= 0xc000) && (msr <= 0xc0001fff) )
> +{
> +msr &= 0x1fff;
> +clear_bit(msr, d->arch.monitor_msr_bitmap +
> 0x400/BYTES_PER_LONG);
> +}
> +
> +return 0;
> +}
> +
> +bool_t vm_event_is_msr_enabled(const struct domain *d, u32 msr)
> 
>  
> ..and this one has nothing to do with vm_event really. These belong in
> the monitor.c side.
>  
> 
> +{
> +bool_t rc = 0;
> +
> +if ( !d->arch.monitor_msr_bitmap )
> +return 0;
> +
> +if ( msr <= 0x1fff )
> +rc = test_bit(msr, d->arch.monitor_msr_bitmap +
> 0x000/BYTES_PER_LONG);
> +else if ( (msr >= 0xc000) && (msr <= 0xc0001fff) )
> +{
> +msr &= 0x1fff;
> +rc = test_bit(msr, d->arch.monitor_msr_bitmap +
> 0x400/BYTES

Re: [Xen-devel] [PATCH] vm_event: Allow subscribing to write events for specific MSR-s

[Tamas K Lengyel]

>
> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
> index 1fec412..1be058a 100644
> --- a/xen/arch/x86/monitor.c
> +++ b/xen/arch/x86/monitor.c
> @@ -20,6 +20,7 @@
>   */
>
>  #include 
> +#include 
>  #include 
>
>  int arch_monitor_domctl_event(struct domain *d,
> @@ -77,25 +78,25 @@ int arch_monitor_domctl_event(struct domain *d,
>
>  case XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR:
>  {
> -bool_t old_status = ad->monitor.mov_to_msr_enabled;
> +bool_t old_status;
> +int rc;
> +u32 msr = mop->u.mov_to_msr.msr;
>
> -if ( unlikely(old_status == requested_status) )
> -return -EEXIST;
> +domain_pause(d);
>
> -if ( requested_status && mop->u.mov_to_msr.extended_capture &&
> - !hvm_enable_msr_exit_interception(d) )
> -return -EOPNOTSUPP;
> +old_status = vm_event_is_msr_enabled(d, msr);
>
> -domain_pause(d);
> +if ( unlikely(old_status == requested_status) )
> +return -EEXIST;
>

Moving this test after the domain gets paused will leave the guest paused
on error condition. Any reason why this rearrangement is necessary?


>
> -if ( requested_status && mop->u.mov_to_msr.extended_capture )
> -ad->monitor.mov_to_msr_extended = 1;
> +if ( requested_status )
> +rc = vm_event_enable_msr(d, msr);
>  else
> -ad->monitor.mov_to_msr_extended = 0;
> +rc = vm_event_disable_msr(d, msr);
>
> -ad->monitor.mov_to_msr_enabled = requested_status;
>  domain_unpause(d);
> -break;
> +
> +return rc;
>  }
>
>  case XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP:
> diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
> index 5635603..b851e39 100644
> --- a/xen/arch/x86/vm_event.c
> +++ b/xen/arch/x86/vm_event.c
> @@ -27,6 +27,13 @@ int vm_event_init_domain(struct domain *d)
>  {
>  struct vcpu *v;
>
> +d->arch.monitor_msr_bitmap = alloc_xenheap_page();
> +
> +if ( !d->arch.monitor_msr_bitmap )
> +return -ENOMEM;
> +
> +memset(d->arch.monitor_msr_bitmap, 0, PAGE_SIZE);
> +
>  for_each_vcpu ( d, v )
>  {
>  if ( v->arch.vm_event )
> @@ -55,11 +62,66 @@ void vm_event_cleanup_domain(struct domain *d)
>  v->arch.vm_event = NULL;
>  }
>
> +free_xenheap_page(d->arch.monitor_msr_bitmap);
> +d->arch.monitor_msr_bitmap = NULL;
> +
>  d->arch.mem_access_emulate_each_rep = 0;
>  memset(&d->arch.monitor, 0, sizeof(d->arch.monitor));
>  memset(&d->monitor, 0, sizeof(d->monitor));
>  }
>
> +int vm_event_enable_msr(struct domain *d, u32 msr)
>

This function..


> +{
> +if ( !d->arch.monitor_msr_bitmap )
> +return -EINVAL;
> +
> +if ( msr <= 0x1fff )
> +set_bit(msr, d->arch.monitor_msr_bitmap + 0x000/BYTES_PER_LONG);
> +else if ( (msr >= 0xc000) && (msr <= 0xc0001fff) )
> +{
> +msr &= 0x1fff;
> +set_bit(msr, d->arch.monitor_msr_bitmap + 0x400/BYTES_PER_LONG);
> +}
> +
> +hvm_enable_msr_interception(d, msr);
> +
> +return 0;
> +}
> +
> +int vm_event_disable_msr(struct domain *d, u32 msr)
>

..and this..


> +{
> +if ( !d->arch.monitor_msr_bitmap )
> +return -EINVAL;
> +
> +if ( msr <= 0x1fff )
> +clear_bit(msr, d->arch.monitor_msr_bitmap + 0x000/BYTES_PER_LONG);
> +else if ( (msr >= 0xc000) && (msr <= 0xc0001fff) )
> +{
> +msr &= 0x1fff;
> +clear_bit(msr, d->arch.monitor_msr_bitmap + 0x400/BYTES_PER_LONG);
> +}
> +
> +return 0;
> +}
> +
> +bool_t vm_event_is_msr_enabled(const struct domain *d, u32 msr)
>

..and this one has nothing to do with vm_event really. These belong in the
monitor.c side.


> +{
> +bool_t rc = 0;
> +
> +if ( !d->arch.monitor_msr_bitmap )
> +return 0;
> +
> +if ( msr <= 0x1fff )
> +rc = test_bit(msr, d->arch.monitor_msr_bitmap +
> 0x000/BYTES_PER_LONG);
> +else if ( (msr >= 0xc000) && (msr <= 0xc0001fff) )
> +{
> +msr &= 0x1fff;
> +rc = test_bit(msr, d->arch.monitor_msr_bitmap +
> 0x400/BYTES_PER_LONG);
> +}
> +
> +return rc;
> +}
> +
>  void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
>  {
>  if ( !is_hvm_domain(d) || !atomic_read(&v->vm_event_pause_count) )
>
>
Cheers,
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] xenpm and scheduler

[tutu sky]

yeah, running xenpm gives short comments on its commands and their options but 
not about how to establish it.

I try my best for this :)
thanks a lot.


From: Konrad Rzeszutek Wilk 
Sent: Tuesday, April 12, 2016 5:08 PM
To: tutu sky
Cc: Dario Faggioli; Meng Xu; Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xenpm and scheduler

On Tue, Apr 12, 2016 at 05:04:04PM +, tutu sky wrote:
> Thanks Konrad. I will do :)
> Yeah, I believe so. as i can see that there is not any bios settings for 
> power management in there (vmware).  I hope you be the correct party which i 
> want to ask this question: there is a tutorial here in this page:
> 1) 
> http://xenserver.org/partners/developing-products-for-xenserver/19-dev-help/138-xs-dev-perf-turbo.html
>
> which i know as a quick guide for establishing xenpm. my Q is that, are this 
> page and this two page of xen.wiki below enough for establishing xenpm and 
> make it work totally?
>
> 2) http://wiki.xenproject.org/wiki/Xenpm_command
> 3) http://wiki.xenproject.org/wiki/Xen_power_management
>
>  if yes, there is a problem, when i compiled xen from source, there is not 
> any xensource folder in /opt folder in dom0 to follow the instructions in (1) 
> address. i did all those instructions in dom0 config file instead.

Xen source != XenServer.


>
> if these guides are not enough in your point of view too, i think (just as a 
> suggestion), xenpm needs more documentation, in order to clarify it's 
> activation and usage progress. it remains a silent area in this giant project 
> although is quiet usable.
>

If you run 'xenpm' by itself it gives you the options.

Patches to make an manpage for xenpm are always warmly welcome!
> thanks and regards.
>
> 
> From: Konrad Rzeszutek Wilk 
> Sent: Tuesday, April 12, 2016 1:41 PM
> To: tutu sky
> Cc: Dario Faggioli; Meng Xu; Xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] xenpm and scheduler
>
> On Tue, Apr 12, 2016 at 11:50:42AM +, tutu sky wrote:
> > Thanks Dario,
> > Yeah, I do like playing with xenpm and try understanding relationship 
> > between this and scheduler. but i established a xen environment on vmware, 
> > but xenpm does not work correctly and even for 'cpufreq', it is silent at 
> > all! so it does not let me try to play with :(. I asked this problem before 
> > in the user and devel lists both,  but no body answered me. how can i track 
> > the problem, from who (I know that power management is out of your 
> > maintenance scope)?? (may xenpm have the same problem on a real platform 
> > (again) instead of vmware?)
> > thanks a lot.
>
> You will have to.
>
> I don't believe VMWare exposes C and P states to guests so therefore
> there is no power freqeuency in play.
>
> > regards.
> > 
> > From: Dario Faggioli 
> > Sent: Tuesday, April 12, 2016 8:10 AM
> > To: tutu sky; Meng Xu
> > Cc: Xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] xenpm and scheduler
> >
> > On Tue, 2016-04-12 at 03:52 +, tutu sky wrote:
> > > Thanks Xu. I will do as desired about cross messaging.
> > >
> > > i need it because i exactly want to know that which part of the
> > > scheduler's corde (credit), takes effect from this feature. because
> > > it is important to me knowing that where would be trade off between
> > > idle state and doing load balancing, while cpuidle feature is
> > > activated. in other side it's important again for me that what will
> > > happen for 'cap; and 'weight' decreasing in a case that one core's
> > > frequency is lower than another one in the same socket (actually when
> > > cpufreq feature is enable).
> > >
> > Currently, there is no interaction between the scheduler and the power
> > management and frequency scaling layers.
> >
> > > Am i clear enough? can you give me an answer or maybe some lines of
> > > schedule.c or sched_credit.c's code which i can track them to notice
> > > the effect of xenpm on scheduler part of the view?
> > >
> > If you're saying that, for instance, the CPUs changing frequency can or
> > should affect some aspects of the scheduling algorithms (like credits
> > burning rate in Credit1 and Credit2, and budget burning rate in RTDS),
> > that is an interesting point which may indeed make sense, or at least
> > would deserve more investigation.
> >
> > But again, right now, there's no line of code to read to understand the
> > relationship, as there's no relationship at all.
> >
> > If you want to experiment on playing with xenpm, and seeing what effect
> > it has on scheduling, that will be very welcome. :-)
> >
> > Regards,
> > Dario
> > --
> > <> (Raistlin Majere)
> > -
> > Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> >
> >
> > ___
> > Xen-devel mailing list
>

Re: [Xen-devel] [PATCH v2 3/3] xenfb: remove out_cons in xenfb_handle_events

[Stefano Stabellini]

On Tue, 12 Apr 2016, Wei Liu wrote:
> The variable out_cons was only used to temporarily hold the consumer
> index. Use cons directly to simplify code a bit.
> 
> No functional change introduced.
> 
> Signed-off-by: Wei Liu 

Except for the fact that it is based on patch #2, which is wrong, this
looks OK.

Acked-by: Stefano Stabellini 


> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> ---
>  hw/display/xenfb.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> index 7f4fad7..7d50efb 100644
> --- a/hw/display/xenfb.c
> +++ b/hw/display/xenfb.c
> @@ -770,16 +770,16 @@ static void xenfb_invalidate(void *opaque)
>  
>  static void xenfb_handle_events(struct XenFB *xenfb)
>  {
> -uint32_t prod, cons, out_cons;
> +uint32_t prod, cons;
>  struct xenfb_page *page = xenfb->c.page;
>  
>  prod = page->out_prod;
> -out_cons = page->out_cons;
> +cons = page->out_cons;
>  xen_rmb();
> -if (prod - out_cons > XENFB_OUT_RING_LEN) {
> +if (prod - cons > XENFB_OUT_RING_LEN) {
>  return;
>  }
> -for (cons = out_cons; cons != prod; cons++) {
> +for ( ; cons != prod; cons++) {
>   union xenfb_out_event *event = &XENFB_OUT_RING_REF(page, cons);
>  uint8_t type = event->type;
>   int x, y, w, h;
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [PATCH v2 2/3] xenfb: move xen_rmb to the correct location

[Stefano Stabellini]

On Tue, 12 Apr 2016, Wei Liu wrote:
> On Tue, Apr 12, 2016 at 02:38:13PM +0100, Andrew Cooper wrote:
> > On 12/04/16 13:57, David Vrabel wrote:
> > > On 12/04/16 11:43, Wei Liu wrote:
> > >> It should be placed before first time producer and consumer are used.
> > > This change isn't necessary and is confusing as this is not what this
> > > barrier is for.
> > >
> > > The barrier needs to be between the load of prod and the load of the
> > > ring contents (there's even a comment that says this).  This pairs with
> > > the corresponding write barrier between the store of the ring contents
> > > and the store of prod (in the other end).
> > 
> > Looking further, this code will compile to multiple reads of the page,
> > because there is no ACCESS_ONCE().  This code is still vulnerable to
> > XSA-155.

There is no ACCESS_ONCE in QEMU, the closest thing to it is atomic_read.


> Oops, accidentally kicked over a can of worms. Should have just sent
> patch 1. :-)
> 
> Jokes aside, more time is needed to fix this properly. So maybe we
> should just upstream patch #1 first. Stefano? Anthony?

Sure

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

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

[Tamas K Lengyel]

On Tue, Apr 12, 2016 at 11:05 AM, Corneliu ZUZU 
wrote:

> On 4/12/2016 7:24 PM, Julien Grall wrote:
>
>> Hello,
>>
>> On 12/04/2016 16:01, Tamas K Lengyel wrote:
>>
>>>
>>> On Apr 12, 2016 01:51, "Corneliu ZUZU" >> > wrote:
>>>  >
>>>  > On 4/11/2016 10:47 PM, Tamas K Lengyel wrote:
>>>  >>
>>>  >> From: Tamas K Lengyel >> >
>>>  >>
>>>  >> The ARM SMC instructions are already configured to trap to Xen by
>>> default. In
>>>  >> this patch we allow a user-space process in a privileged domain to
>>> receive
>>>  >> notification of when such event happens through the vm_event
>>> subsystem.
>>>  >>
>>>  >> This patch will likely needs to be broken up into several smaller
>>> patches.
>>>  >> Right now what this patch adds (and could be broken into smaller
>>> patches
>>>  >> accordingly):
>>>  >>  - Implement monitor_op domctl handler for SOFTWARE_BREAKPOINTs
>>> on ARM
>>>  >>  - Implement vm_event register fill/set routines for ARM. This
>>> required
>>>  >>  removing the function from common as the function prototype
>>> now
>>>  >>  differs on the two archs.
>>>  >>  - Sending notification as SOFTWARE_BREAKPOINT vm_event from the
>>> SMC trap
>>>  >>  handlers.
>>>  >>  - Extend the xen-access test tool to receive SMC notification
>>> and step
>>>  >>  the PC manually in the reply.
>>>  >>
>>>  >> I'm sending it as an RFC to gather feedback on what has been
>>> overlooked in this
>>>  >> revision. This patch has been tested on a Cubietruck board and works
>>> fine,
>>>  >> but would probably not work on 64-bit boards.
>>>  >
>>>  >
>>>  > Hi Tamas,
>>>  >
>>>  > If I may, I'm still unable to work at the moment, being ill, but I'm
>>> checking the xen-devel lists from time to time.
>>>  > Your patch caught my attention, reminding me of the conversation we
>>> had some time ago on this matter.
>>>  > The only real reason I don't see SMC (secure-monitor-call) as being
>>> an ideal candidate for this is that, according to the ARM manuals, SMC
>>> should directly cause undefined exception if executed from user-mode
>>> (EL0), instead of a hypervisor trap - isn't that the case on the machine
>>> you tested this on or is this really only for the EL1 of domains?
>>>
>>
>> This paragraph is part of Corneliu's answer but it gives the impression
>> you wrote it. Can you configure your e-mail client to quote properly?
>>
>>
>>> That's correct, it can only be issued by the kernel. So as long as you
>>> want to monitor the kernel it can be used just fine. I can also envision
>>> trampoline-like traps (syscalls injected into EL0 to trigger SMC) but
>>> that's beyond the scope I intend this for now.
>>>
>>
> Then indeed SMC is the -easiest- way to go, @ least until user-mode
> breakpoints are implemented.
>
>
>>>  >
>>>  > Also:
>>>  > - SMC, by definition, is a call to the secure side, it doesn't relate
>>> to debugging directly (it's a syscall to the 'secure' side). There is a
>>> viable INT3 equivalent on ARM, that being the BKPT/BRK instruction,
>>> using that instead would require a bit more effort (but would,
>>> conceptually, be more correct) and might be less performant, I suppose
>>> that's why you didn't go for that?
>>>
>>
>> BKPT/BRK could be used by the guest for debugging. You would need to
>> differentiate a breakpoint inserted by Xen or by a debugger in the guest.
>>
>
> Isn't that also the case for X86's INT3? I guess differentiation is done
> based on the bkpt address/privilege level? On ARM that could also
> (partially) be done by looking @ the immediate value of the BKPT/BRK
> instruction. Another thing I realized might be troublesome with NOT using
> BKPT/BRK would be that on ARMv7 BKPT is always unconditional, even in IT
> blocks. IDK if that applies to SMC, but if it doesn't you'd have to check
> for that as well to make sure the breakpoint is actually executed.
>
>
>>
>>> I would have to double check but AFAIK those instructions can't be
>>> configured to trap to the hypervisor directly. So while SMC was not
>>> intended to be a breakpoint, conceptually it's the closest thing we have
>>> an on ARM to the INT3 instruction when configured to trap to the VMM.
>>>
>>
>>
> Please see AArch32 HDCR.TDE and AArch64 MDCR_EL2.TDE bits. Since
> activating this bit would imply additional (in this context -unwanted-)
> traps, the performance hit of having this bit set might be significant.
>

Right, actually I believe KVM already implemented this, I was just under
the impression it was only for aarch64. As for performance overhead I'm not
that worried about it, rather I need to make sure the presence of the
monitoring can remain stealthy. I know on KVM for example this type of
trapping renders the guest to be unable to use singlestepping, which would
easily reveal the presence of the external monitor (see
https://lists.cs.columbia.edu/pipermail/kvmarm/2015-May/014589.html). So
this will need to be lo

Re: [Xen-devel] [PATCH v2 1/3] xenfb: use the correct condition to avoid excessive looping

[Stefano Stabellini]

On Tue, 12 Apr 2016, Wei Liu wrote:
> In commit ac0487e1 ("xenfb.c: avoid expensive loops when prod <=
> out_cons"), ">=" was used. In fact, a full ring is a legit state.
> Correct the test to use ">".
> 
> Reported-by: "Hao, Xudong" 
> Signed-off-by: Wei Liu 
> Tested-by: "Hao, Xudong" 
> Acked-by: Anthony Perard 

Acked-by: Stefano Stabellini 

I'll add it to my queue


> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> 
> Backport candidate to our own tree.
> ---
>  hw/display/xenfb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> index 40b096a..9866dfd 100644
> --- a/hw/display/xenfb.c
> +++ b/hw/display/xenfb.c
> @@ -775,7 +775,7 @@ static void xenfb_handle_events(struct XenFB *xenfb)
>  
>  prod = page->out_prod;
>  out_cons = page->out_cons;
> -if (prod - out_cons >= XENFB_OUT_RING_LEN) {
> +if (prod - out_cons > XENFB_OUT_RING_LEN) {
>  return;
>  }
>  xen_rmb();   /* ensure we see ring contents up to prod */
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [sh_eth.c] Problem in dma_map_single()

[Konrad Rzeszutek Wilk]

On Tue, Apr 12, 2016 at 04:54:55PM +0900, Wonseok Ko wrote:
> Hi,
> 
> I'm trying to enable ethernet driver in Domain0 for R-Car H2, but it
> doesn't work. The root cause of the problem is that driver cannot satisfy
> the condition of dma_capable(). I found the same problem in the mailing

So what can be done about making it dma_capable() ?

> list, but the problem is still remaining I guess. previous mail: (
> http://lists.xen.org/archives/html/xen-devel/2014-10/msg03170.html)
> 
> Does anyone give me advise?
> 
> My environment as below:
> - dom0 linux version: 4.3
> - xen version: 4.6 commit(40d7a7454835c2f7c639c78f6c09e7b6f0e4a4e2)
> 
> 
> Thanks,
> Wonseok.

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


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

Re: [Xen-devel] xenpm and scheduler

[Konrad Rzeszutek Wilk]

On Tue, Apr 12, 2016 at 05:04:04PM +, tutu sky wrote:
> Thanks Konrad. I will do :)
> Yeah, I believe so. as i can see that there is not any bios settings for 
> power management in there (vmware).  I hope you be the correct party which i 
> want to ask this question: there is a tutorial here in this page:
> 1) 
> http://xenserver.org/partners/developing-products-for-xenserver/19-dev-help/138-xs-dev-perf-turbo.html
> 
> which i know as a quick guide for establishing xenpm. my Q is that, are this 
> page and this two page of xen.wiki below enough for establishing xenpm and 
> make it work totally?
> 
> 2) http://wiki.xenproject.org/wiki/Xenpm_command
> 3) http://wiki.xenproject.org/wiki/Xen_power_management
> 
>  if yes, there is a problem, when i compiled xen from source, there is not 
> any xensource folder in /opt folder in dom0 to follow the instructions in (1) 
> address. i did all those instructions in dom0 config file instead.

Xen source != XenServer.


> 
> if these guides are not enough in your point of view too, i think (just as a 
> suggestion), xenpm needs more documentation, in order to clarify it's 
> activation and usage progress. it remains a silent area in this giant project 
> although is quiet usable.
>

If you run 'xenpm' by itself it gives you the options.

Patches to make an manpage for xenpm are always warmly welcome!
> thanks and regards.
> 
> 
> From: Konrad Rzeszutek Wilk 
> Sent: Tuesday, April 12, 2016 1:41 PM
> To: tutu sky
> Cc: Dario Faggioli; Meng Xu; Xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] xenpm and scheduler
> 
> On Tue, Apr 12, 2016 at 11:50:42AM +, tutu sky wrote:
> > Thanks Dario,
> > Yeah, I do like playing with xenpm and try understanding relationship 
> > between this and scheduler. but i established a xen environment on vmware, 
> > but xenpm does not work correctly and even for 'cpufreq', it is silent at 
> > all! so it does not let me try to play with :(. I asked this problem before 
> > in the user and devel lists both,  but no body answered me. how can i track 
> > the problem, from who (I know that power management is out of your 
> > maintenance scope)?? (may xenpm have the same problem on a real platform 
> > (again) instead of vmware?)
> > thanks a lot.
> 
> You will have to.
> 
> I don't believe VMWare exposes C and P states to guests so therefore
> there is no power freqeuency in play.
> 
> > regards.
> > 
> > From: Dario Faggioli 
> > Sent: Tuesday, April 12, 2016 8:10 AM
> > To: tutu sky; Meng Xu
> > Cc: Xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] xenpm and scheduler
> >
> > On Tue, 2016-04-12 at 03:52 +, tutu sky wrote:
> > > Thanks Xu. I will do as desired about cross messaging.
> > >
> > > i need it because i exactly want to know that which part of the
> > > scheduler's corde (credit), takes effect from this feature. because
> > > it is important to me knowing that where would be trade off between
> > > idle state and doing load balancing, while cpuidle feature is
> > > activated. in other side it's important again for me that what will
> > > happen for 'cap; and 'weight' decreasing in a case that one core's
> > > frequency is lower than another one in the same socket (actually when
> > > cpufreq feature is enable).
> > >
> > Currently, there is no interaction between the scheduler and the power
> > management and frequency scaling layers.
> >
> > > Am i clear enough? can you give me an answer or maybe some lines of
> > > schedule.c or sched_credit.c's code which i can track them to notice
> > > the effect of xenpm on scheduler part of the view?
> > >
> > If you're saying that, for instance, the CPUs changing frequency can or
> > should affect some aspects of the scheduling algorithms (like credits
> > burning rate in Credit1 and Credit2, and budget burning rate in RTDS),
> > that is an interesting point which may indeed make sense, or at least
> > would deserve more investigation.
> >
> > But again, right now, there's no line of code to read to understand the
> > relationship, as there's no relationship at all.
> >
> > If you want to experiment on playing with xenpm, and seeing what effect
> > it has on scheduling, that will be very welcome. :-)
> >
> > Regards,
> > Dario
> > --
> > <> (Raistlin Majere)
> > -
> > Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> >
> >
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel

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

Re: [Xen-devel] xenpm and scheduler

[tutu sky]

Thanks Konrad. I will do :)
Yeah, I believe so. as i can see that there is not any bios settings for power 
management in there (vmware).  I hope you be the correct party which i want to 
ask this question: there is a tutorial here in this page:
1) 
http://xenserver.org/partners/developing-products-for-xenserver/19-dev-help/138-xs-dev-perf-turbo.html

which i know as a quick guide for establishing xenpm. my Q is that, are this 
page and this two page of xen.wiki below enough for establishing xenpm and make 
it work totally?

2) http://wiki.xenproject.org/wiki/Xenpm_command
3) http://wiki.xenproject.org/wiki/Xen_power_management

 if yes, there is a problem, when i compiled xen from source, there is not any 
xensource folder in /opt folder in dom0 to follow the instructions in (1) 
address. i did all those instructions in dom0 config file instead.

if these guides are not enough in your point of view too, i think (just as a 
suggestion), xenpm needs more documentation, in order to clarify it's 
activation and usage progress. it remains a silent area in this giant project 
although is quiet usable.

thanks and regards.


From: Konrad Rzeszutek Wilk 
Sent: Tuesday, April 12, 2016 1:41 PM
To: tutu sky
Cc: Dario Faggioli; Meng Xu; Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xenpm and scheduler

On Tue, Apr 12, 2016 at 11:50:42AM +, tutu sky wrote:
> Thanks Dario,
> Yeah, I do like playing with xenpm and try understanding relationship between 
> this and scheduler. but i established a xen environment on vmware, but xenpm 
> does not work correctly and even for 'cpufreq', it is silent at all! so it 
> does not let me try to play with :(. I asked this problem before in the user 
> and devel lists both,  but no body answered me. how can i track the problem, 
> from who (I know that power management is out of your maintenance scope)?? 
> (may xenpm have the same problem on a real platform (again) instead of 
> vmware?)
> thanks a lot.

You will have to.

I don't believe VMWare exposes C and P states to guests so therefore
there is no power freqeuency in play.

> regards.
> 
> From: Dario Faggioli 
> Sent: Tuesday, April 12, 2016 8:10 AM
> To: tutu sky; Meng Xu
> Cc: Xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] xenpm and scheduler
>
> On Tue, 2016-04-12 at 03:52 +, tutu sky wrote:
> > Thanks Xu. I will do as desired about cross messaging.
> >
> > i need it because i exactly want to know that which part of the
> > scheduler's corde (credit), takes effect from this feature. because
> > it is important to me knowing that where would be trade off between
> > idle state and doing load balancing, while cpuidle feature is
> > activated. in other side it's important again for me that what will
> > happen for 'cap; and 'weight' decreasing in a case that one core's
> > frequency is lower than another one in the same socket (actually when
> > cpufreq feature is enable).
> >
> Currently, there is no interaction between the scheduler and the power
> management and frequency scaling layers.
>
> > Am i clear enough? can you give me an answer or maybe some lines of
> > schedule.c or sched_credit.c's code which i can track them to notice
> > the effect of xenpm on scheduler part of the view?
> >
> If you're saying that, for instance, the CPUs changing frequency can or
> should affect some aspects of the scheduling algorithms (like credits
> burning rate in Credit1 and Credit2, and budget burning rate in RTDS),
> that is an interesting point which may indeed make sense, or at least
> would deserve more investigation.
>
> But again, right now, there's no line of code to read to understand the
> relationship, as there's no relationship at all.
>
> If you want to experiment on playing with xenpm, and seeing what effect
> it has on scheduling, that will be very welcome. :-)
>
> Regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Corneliu ZUZU]

On 4/12/2016 7:24 PM, Julien Grall wrote:

Hello,

On 12/04/2016 16:01, Tamas K Lengyel wrote:


On Apr 12, 2016 01:51, "Corneliu ZUZU" mailto:cz...@bitdefender.com>> wrote:
 >
 > On 4/11/2016 10:47 PM, Tamas K Lengyel wrote:
 >>
 >> From: Tamas K Lengyel mailto:tkleng...@sec.in.tum.de>>
 >>
 >> The ARM SMC instructions are already configured to trap to Xen by
default. In
 >> this patch we allow a user-space process in a privileged domain to
receive
 >> notification of when such event happens through the vm_event 
subsystem.

 >>
 >> This patch will likely needs to be broken up into several smaller
patches.
 >> Right now what this patch adds (and could be broken into smaller 
patches

 >> accordingly):
 >>  - Implement monitor_op domctl handler for SOFTWARE_BREAKPOINTs
on ARM
 >>  - Implement vm_event register fill/set routines for ARM. This
required
 >>  removing the function from common as the function 
prototype now

 >>  differs on the two archs.
 >>  - Sending notification as SOFTWARE_BREAKPOINT vm_event from the
SMC trap
 >>  handlers.
 >>  - Extend the xen-access test tool to receive SMC notification
and step
 >>  the PC manually in the reply.
 >>
 >> I'm sending it as an RFC to gather feedback on what has been
overlooked in this
 >> revision. This patch has been tested on a Cubietruck board and works
fine,
 >> but would probably not work on 64-bit boards.
 >
 >
 > Hi Tamas,
 >
 > If I may, I'm still unable to work at the moment, being ill, but I'm
checking the xen-devel lists from time to time.
 > Your patch caught my attention, reminding me of the conversation we
had some time ago on this matter.
 > The only real reason I don't see SMC (secure-monitor-call) as being
an ideal candidate for this is that, according to the ARM manuals, SMC
should directly cause undefined exception if executed from user-mode
(EL0), instead of a hypervisor trap - isn't that the case on the machine
you tested this on or is this really only for the EL1 of domains?


This paragraph is part of Corneliu's answer but it gives the 
impression you wrote it. Can you configure your e-mail client to quote 
properly?




That's correct, it can only be issued by the kernel. So as long as you
want to monitor the kernel it can be used just fine. I can also envision
trampoline-like traps (syscalls injected into EL0 to trigger SMC) but
that's beyond the scope I intend this for now.


Then indeed SMC is the -easiest- way to go, @ least until user-mode 
breakpoints are implemented.




 >
 > Also:
 > - SMC, by definition, is a call to the secure side, it doesn't relate
to debugging directly (it's a syscall to the 'secure' side). There is a
viable INT3 equivalent on ARM, that being the BKPT/BRK instruction,
using that instead would require a bit more effort (but would,
conceptually, be more correct) and might be less performant, I suppose
that's why you didn't go for that?


BKPT/BRK could be used by the guest for debugging. You would need to 
differentiate a breakpoint inserted by Xen or by a debugger in the guest.


Isn't that also the case for X86's INT3? I guess differentiation is done 
based on the bkpt address/privilege level? On ARM that could also 
(partially) be done by looking @ the immediate value of the BKPT/BRK 
instruction. Another thing I realized might be troublesome with NOT 
using BKPT/BRK would be that on ARMv7 BKPT is always unconditional, even 
in IT blocks. IDK if that applies to SMC, but if it doesn't you'd have 
to check for that as well to make sure the breakpoint is actually executed.






I would have to double check but AFAIK those instructions can't be
configured to trap to the hypervisor directly. So while SMC was not
intended to be a breakpoint, conceptually it's the closest thing we have
an on ARM to the INT3 instruction when configured to trap to the VMM.




Please see AArch32 HDCR.TDE and AArch64 MDCR_EL2.TDE bits. Since 
activating this bit would imply additional (in this context -unwanted-) 
traps, the performance hit of having this bit set might be significant.



Whilst any access to SMC currently results to inject an undefined 
exception, it may not be the case in the future. There have been 
discussion to allow guest issuing SMC call (see [1]).


I think the safest instruction would be HVC #imm. Xen is only using a 
small number of immediate. You could allocate a specific value for 
software debugging.




IMHO that would also be better conceptually, although it would still 
suffer from the limitation of not being available from user-space (and 
potentially from the above IT block issue).




 > - SMC can be disabled by the secure side (over which Xen doesn't have
control) - not really a problem on though, since the hypervisor trap
happens before that check
 > But these 2 are conceptual problems, they don't impede usage of SMC
as you intend in practice.

Sure, the TrustZone is more privileged then the hypervisor so you need
to take that into account 

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

[Ian Jackson]

George Dunlap writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested 
Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ 
but sane."):
> Well we know which option Andy prefers, but are there other options
> that Andy is not absolutely opposed to?  And we don't know anything
> about which option Jan prefers at all, except that it's not #4.

Let me go a bit further than George.

It's clear that there are various options, most of which are
tolerable.  Buit if I'm trying to help referee a disagreement between
Andrew and Jan I would prefer to be choosing between Andrew's
preferred answer and Jan's preferred answer.

Jan: AFAICT it's clear that you would still like the current patch
reverted.  Can you please say what, if anything, you would like to
replace it with ?

Thanks,
Ian.

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

Re: [Xen-devel] [sh_eth.c] Problem in dma_map_single()

[Julien Grall]

(CC Stefano and Konrad)

On 12/04/2016 08:54, Wonseok Ko wrote:

Hi,

I'm trying to enable ethernet driver in Domain0 for R-Car H2, but it
doesn't work. The root cause of the problem is that driver cannot
satisfy the condition of dma_capable(). I found the same problem in the
mailing list, but the problem is still remaining I guess. previous mail:
(http://lists.xen.org/archives/html/xen-devel/2014-10/msg03170.html)

Does anyone give me advise?

My environment as below:
- dom0 linux version: 4.3
- xen version: 4.6 commit(40d7a7454835c2f7c639c78f6c09e7b6f0e4a4e2)


Thanks,
Wonseok.


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



--
Julien Grall

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

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

[Julien Grall]

Hello,

On 12/04/2016 16:01, Tamas K Lengyel wrote:


On Apr 12, 2016 01:51, "Corneliu ZUZU" mailto:cz...@bitdefender.com>> wrote:
 >
 > On 4/11/2016 10:47 PM, Tamas K Lengyel wrote:
 >>
 >> From: Tamas K Lengyel mailto:tkleng...@sec.in.tum.de>>
 >>
 >> The ARM SMC instructions are already configured to trap to Xen by
default. In
 >> this patch we allow a user-space process in a privileged domain to
receive
 >> notification of when such event happens through the vm_event subsystem.
 >>
 >> This patch will likely needs to be broken up into several smaller
patches.
 >> Right now what this patch adds (and could be broken into smaller patches
 >> accordingly):
 >>  - Implement monitor_op domctl handler for SOFTWARE_BREAKPOINTs
on ARM
 >>  - Implement vm_event register fill/set routines for ARM. This
required
 >>  removing the function from common as the function prototype now
 >>  differs on the two archs.
 >>  - Sending notification as SOFTWARE_BREAKPOINT vm_event from the
SMC trap
 >>  handlers.
 >>  - Extend the xen-access test tool to receive SMC notification
and step
 >>  the PC manually in the reply.
 >>
 >> I'm sending it as an RFC to gather feedback on what has been
overlooked in this
 >> revision. This patch has been tested on a Cubietruck board and works
fine,
 >> but would probably not work on 64-bit boards.
 >
 >
 > Hi Tamas,
 >
 > If I may, I'm still unable to work at the moment, being ill, but I'm
checking the xen-devel lists from time to time.
 > Your patch caught my attention, reminding me of the conversation we
had some time ago on this matter.
 > The only real reason I don't see SMC (secure-monitor-call) as being
an ideal candidate for this is that, according to the ARM manuals, SMC
should directly cause undefined exception if executed from user-mode
(EL0), instead of a hypervisor trap - isn't that the case on the machine
you tested this on or is this really only for the EL1 of domains?


This paragraph is part of Corneliu's answer but it gives the impression 
you wrote it. Can you configure your e-mail client to quote properly?




That's correct, it can only be issued by the kernel. So as long as you
want to monitor the kernel it can be used just fine. I can also envision
trampoline-like traps (syscalls injected into EL0 to trigger SMC) but
that's beyond the scope I intend this for now.

 >
 > Also:
 > - SMC, by definition, is a call to the secure side, it doesn't relate
to debugging directly (it's a syscall to the 'secure' side). There is a
viable INT3 equivalent on ARM, that being the BKPT/BRK instruction,
using that instead would require a bit more effort (but would,
conceptually, be more correct) and might be less performant, I suppose
that's why you didn't go for that?


BKPT/BRK could be used by the guest for debugging. You would need to 
differentiate a breakpoint inserted by Xen or by a debugger in the guest.




I would have to double check but AFAIK those instructions can't be
configured to trap to the hypervisor directly. So while SMC was not
intended to be a breakpoint, conceptually it's the closest thing we have
an on ARM to the INT3 instruction when configured to trap to the VMM.


Whilst any access to SMC currently results to inject an undefined 
exception, it may not be the case in the future. There have been 
discussion to allow guest issuing SMC call (see [1]).


I think the safest instruction would be HVC #imm. Xen is only using a 
small number of immediate. You could allocate a specific value for 
software debugging.




 > - SMC can be disabled by the secure side (over which Xen doesn't have
control) - not really a problem on though, since the hypervisor trap
happens before that check
 > But these 2 are conceptual problems, they don't impede usage of SMC
as you intend in practice.

Sure, the TrustZone is more privileged then the hypervisor so you need
to take that into account as well when you consider your threat model.
If the TZ is malicious though IMHO there isn't much you can do on the
hypervisor side anyway. So in the usecase I have for this I control the
TZ as well.


Regards,

[1] http://lists.xen.org/archives/html/xen-devel/2015-07/txtwZfvJnXlYG.txt

--
Julien Grall

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

Re: [Xen-devel] [PATCH 09/46] tools/hotplug: use XEN_LOCK_DIR instead of hardcoded path

[Olaf Hering]

On Mon, Apr 11, George Dunlap wrote:

> if [ -d ${XEN_LOCK_DIR}/subsys ] ; then
> LOCKFILE=${XEN_LOCK_DIR}/subsys/xendomains
> else
> LOCKFILE=${XEN_LOCK_DIR}/xendomains
> fi

This will probably work, yes.

Olaf

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  ac703c285a4fbfcb85c19364ea0c67780bf16c2d
baseline version:
 xen  8b27d2b8af898597367e2a97aaed3e3404eda5af

Last test of basis91017  2016-04-11 20:01:16 Z0 days
Testing same since91132  2016-04-12 14:03:43 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=ac703c285a4fbfcb85c19364ea0c67780bf16c2d
+ . ./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 
ac703c285a4fbfcb85c19364ea0c67780bf16c2d
+ branch=xen-unstable-smoke
+ revision=ac703c285a4fbfcb85c19364ea0c67780bf16c2d
+ . ./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.6-testing
+ '[' xac703c285a4fbfcb85c19364ea0c67780bf16c2d = 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/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github

Re: [Xen-devel] Question about the XEN platform pci

[Roger Pau Monné]

Please don't top post.

On Tue, Apr 12, 2016 at 05:33:47PM +0200, karim.allah.ah...@gmail.com wrote:
> The INTx interrupt of this platform device can be used by Xen in HVM case to
> notify the guest of pending events in the event channel. However that's 
> usually
> not used in favor of vector callbacks support in Xen where a vector is 
> injected
> directly to the vCPU bypassing LAPIC.
> 
> (that said, the platform-pci driver in linux is actually broken when vector
> callbacks are not used anyway)
> 
> I also think that the grant-table lives on this PCI device MMIO BAR (?!)

Not really, grant table can live anywhere, but it's usually placed there 
because the OS knows there's nothing in this MMIO region.
 
Roger.

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

[Xen-devel] [PATCH v2] xen: change the sizes of memory fields in the HVM start info to be 64bits

[Roger Pau Monne]

At the moment the only consumer of this structure is x86, but other arches
might also use it, so make all the fields 64bits. On x86 Xen will still try
to place everything below the 4GiB boundary, but that might not be feasible
in other arches.

Signed-off-by: Roger Pau Monné 
Requested-by: Jan Beulich 
---
Cc: Wei Liu 
Cc: Andrew Cooper 
Cc: Jan Beulich 
Cc: Ian Jackson 
---
Changes since v1:
 - Only convert to 64bit the fields that contain memory addresses.
 - Move the position of nr_modules so all the 32bit fields are packed
   together.
 - Move the position of modlist_paddr to it's after nr_modules.
---
 tools/libxc/include/xc_dom.h |  6 +++---
 xen/include/public/xen.h | 16 +---
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6ebe946..6cb10c4 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -231,11 +231,11 @@ struct hvm_start_info {
 /* ("xEn3" with the 0x80 bit of the "E" set).*/
 uint32_t version;   /* Version of this structure.*/
 uint32_t flags; /* SIF_xxx flags.*/
-uint32_t cmdline_paddr; /* Physical address of the command line. */
 uint32_t nr_modules;/* Number of modules passed to the kernel.   */
-uint32_t modlist_paddr; /* Physical address of an array of   */
+uint64_t modlist_paddr; /* Physical address of an array of   */
 /* hvm_modlist_entry.*/
-uint32_t rsdp_paddr;/* Physical address of the RSDP ACPI data*/
+uint64_t cmdline_paddr; /* Physical address of the command line. */
+uint64_t rsdp_paddr;/* Physical address of the RSDP ACPI data*/
 /* structure.*/
 } __attribute__((packed));
 
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 97a5ae5..6ed74ef 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -829,16 +829,16 @@ typedef struct start_info start_info_t;
  *  8 ++
  *| flags  | SIF_xxx flags.
  * 12 ++
- *| cmdline_paddr  | Physical address of the command line,
- *|| a zero-terminated ASCII string.
- * 16 ++
  *| nr_modules | Number of modules passed to the kernel.
- * 20 ++
+ * 16 ++
  *| modlist_paddr  | Physical address of an array of modules
  *|| (layout of the structure below).
  * 24 ++
+ *| cmdline_paddr  | Physical address of the command line,
+ *|| a zero-terminated ASCII string.
+ * 32 ++
  *| rsdp_paddr | Physical address of the RSDP ACPI data structure.
- * 28 ++
+ * 40 ++
  *
  * The layout of each entry in the module structure is the following:
  *
@@ -853,8 +853,10 @@ typedef struct start_info start_info_t;
  *| reserved   |
  * 32 ++
  *
- * The address and size of the modules is a 64bit unsigned integer. However
- * Xen will always try to place all modules below the 4GiB boundary.
+ * The address and sizes are always a 64bit little endian unsigned integer.
+ *
+ * NB: Xen on x86 will always try to place all the data below the 4GiB
+ * boundary.
  */
 #define XEN_HVM_START_MAGIC_VALUE 0x336ec578
 
-- 
2.6.4 (Apple Git-63)


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

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

[Julien Grall]

Hello Tamas,

On 12/04/2016 16:05, Tamas K Lengyel wrote:

On Apr 11, 2016 22:31, "Jan Beulich" mailto:jbeul...@suse.com>> wrote:
 >
 > >>> Tamas K Lengyel mailto:ta...@tklengyel.com>> 04/11/16 9:47 PM >>>


[...]


 >
 > >+uint64_t ttbr0;
 > >+uint64_t ttbr1;
 > >+uint32_t _pad;
 > >+};
 >
 > This padding field is pretty strange: Without the adjustment to pc
there are 16
 > 32-bit fields (not counting the padding one), so I don't see why
padding would be
 > needed at all. And with pc adjusted the padding field would surely
better go
 > ahead of the two remaining 64-bit ones.

Yes, I have been shuffling this struct around and didn't check the
layout. Will fix. I'll also try to make this struct usable for aarch64 too.


You may want to give a look to vcpu_guest_core_regs in public/arch-arm.h

Regards,

--
Julien Grall

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

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

[osstest service owner]

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

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. 65543
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 65543

version targeted for testing:
 ovmf 479d5c4175e77f1cd7e61855fa3c9f83c330ef4f
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  126 days
Failing since 65593  2015-12-08 23:44:51 Z  125 days  142 attempts
Testing same since91000  2016-04-11 17:59:20 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin Haeuser 
  Marvin Häuser 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian, Feng 
  Vladislav Vovchenko 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zeng, Star 
  Zhang Lubo 
  Zhang, Chao B 
  Zhang, Lubo 
  Zhangfei Gao 

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 18859 lines long.)

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

Re: [Xen-devel] [PATCH v3 2/5] xentrace: Memory/Page Mapping support for DOMID_XEN on ARM

[Julien Grall]

Hi George,

On 11/04/2016 10:52, George Dunlap wrote:

On Fri, Apr 8, 2016 at 6:58 PM, Andrew Cooper  wrote:

On 08/04/16 16:49, Jan Beulich wrote:

On 08.04.16 at 12:42,  wrote:

On 04/04/16 19:48, Benjamin Sanda wrote:

+else
+{
+/* retrieve the page to determine read/write or read only mapping */
+mfn = paddr >> PAGE_SHIFT;
+if (mfn_valid(mfn))
+{
+page = mfn_to_page(mfn);
+*t = (page->u.inuse.type_info == PGT_writable_page ?
+p2m_ram_rw : p2m_ram_ro);

Unfortunately, xenmem_add_to_physmap_one will ignore the return type and
will always map using the type p2m_map_foreign. I would introduce
a new type p2m_map_foreign_ro to allow read-only foreign mapping.

I've looked at the x86 code (p2m_add_foreign) and I haven't been able to
find how the page will be mapped read-only in the guest P2M.
get_page_from_gfn will always return p2m_raw_rw for DOMID_XEN as it's a
non translated domain.

Andrew and Jan, do you know how this is supposed to work when xentrace
is used in a HVM domain? Does x86 Xen always mapped Read-Write the page?

I don't think that case is being taken care of right now: xentrace
is to be used by privileged guests only anyway, and the only
HVM-like privileged guest would be a PVHv1 Dom0 (which likely
no-one cared about to make work with xentrace so far).


Answer to questions of the form "Has anyone considered $X for a
privileged HVM domain on x86" are almost always "No".

The real question is whether the domain making the mapping needs to
write into the pages or not.  If xentrace has to update shared pointers,
then it needs to be rw.  If it simply consumes the data without any
backwards notification, then it should be ro.


It does access shared pointers, and so needs at lest one page to be
rw.  At the moment there's sort of two levels: the "trace info"
page(s), mapped RO, which has the list of all the MFNs used for the
actual trace data, and the trace data MFNs themselves, which are
mapped RW.

Re Julien's question about how DOMID_XEN pages are marked RO on x86
when get_page_from_gfn() always returns p2m_ram_rw: The answer is that
get_page_from_gfn() is only really used by the p2m code.  For PV
guests, it's the page type that restricts a page's type to RO or RW.
trace.c calls share_xen_page_with_privileged_guests(), which on x86
calls xen/arch/x86/mm.c:share_xen_page_with_guest(), which sets the
type to PGT_writable_page.


Thank you for the explanation.

The ARM implementation of share_xen_page_with_guest is nearly the same 
as the x86 one. However, the type is never used so far for the P2M code.


So far, all ARM domains have been auto-translated. DOMID_XEN is the 
first non auto-translated domain.


We could make DOMID_XEN an auto-translated domain by introducing page 
table for dummy domain. This would make the code cleaner but use more 
memory (allocation of 3 level of page tables).


Stefano, do you have any opinions on this?

Regards,

--
Julien Grall

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

Re: [Xen-devel] Question about the XEN platform pci

[Konrad Rzeszutek Wilk]

On Tue, Apr 12, 2016 at 05:33:47PM +0200, karim.allah.ah...@gmail.com wrote:
> The INTx interrupt of this platform device can be used by Xen in HVM case to
> notify the guest of pending events in the event channel. However that's 
> usually
> not used in favor of vector callbacks support in Xen where a vector is 
> injected
> directly to the vCPU bypassing LAPIC.
> 
> (that said, the platform-pci driver in linux is actually broken when vector
> callbacks are not used anyway)

Oh? Is there an report/bug somewhere?

Thanks!
> 
> I also think that the grant-table lives on this PCI device MMIO BAR (?!)

The area may be usurped for grant-table as the OS won't touch that memory
area (it after all belongs to the device).
> 
> If you looked at hw/i386/xen/xen_platform.c in QEMU source , you will get a
> general idea what this device is supposed todo (like logging to syslog stuff
> for example).
> 
> That said the platform device is really not fully utilized anyway in Linux.
> 
> On Tue, Apr 12, 2016 at 4:09 PM, Konrad Rzeszutek Wilk
>  wrote:
> > On Tue, Apr 12, 2016 at 02:19:48AM +, Wu, Bob wrote:
> >>
> >> Really thanks for your reply.
> >
> > Hey!
> >
> > CC-ing Xen-devel back on. Please do not drop it and please don't
> > top-post.
> >>
> >> Can you explain a little more?
> >
> > I am not sure what you want me to explain. Perhaps if you
> > read http://xenbits.xen.org/docs/unstable/misc/hvm-emulated-unplug.html
> > it may become clearer?
> >
> >> Is the xen platform pci driver the only purpose for telling QEMU  that 
> >> don’t emulate the IDE driver?
> >
> > And network.
> >> I think it can be done by a simple way, but don't need use this huge 
> >> platform driver.
> >
> > ?
> >>
> >> I guess this is for PCI pass through in XEN HVM mode, but don't sure.
> >
> > No.
> >>
> >> Thanks,
> >> Bob
> >>
> >>
> >> -Original Message-
> >> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> >> Sent: 2016年4月11日 22:24
> >> To: Wu, Bob
> >> Cc: xen-devel@lists.xen.org
> >> Subject: Re: [Xen-devel] Question about the XEN platform pci
> >>
> >> On Fri, Apr 08, 2016 at 08:52:08AM +, Wu, Bob wrote:
> >> >
> >> > Sorry bother, I read the XEN source code recently, and found the XEN
> >> > platform PCI code under drivers/xen/platform-pci.c, and I can't fully 
> >> > under this driver's affect, can anybody explain a little for me?
> >> >
> >> > Is the platform PCI driver for PV-split-PCI-driver-model such as the 
> >> > pci-frontend/pci-backend? or for PCI pass-through model? Or for other 
> >> > purpose?
> >> > I saw the xenbus_pcifront_driver/ xenbus_xen_pcibk_driver are registered 
> >> > on XENBUS, so I guess the platform-PCI-driver is not for PV PCI driver.
> >> >
> >>
> >> It is for the QEMU driver. To tell QEMU to stop emulating the IDE/network.
> >>
> >> > Really thank you for your replay.
> >> >
> >> > Thanks,
> >> > Bob
> >> >
> >>
> >> > ___
> >> > Xen-devel mailing list
> >> > Xen-devel@lists.xen.org
> >> > http://lists.xen.org/xen-devel
> >>
> >
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> 
> 
> -- 
> Karim Allah Ahmed.

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

Re: [Xen-devel] Question about the XEN platform pci

[karim.allah.ah...@gmail.com]

The INTx interrupt of this platform device can be used by Xen in HVM case to
notify the guest of pending events in the event channel. However that's usually
not used in favor of vector callbacks support in Xen where a vector is injected
directly to the vCPU bypassing LAPIC.

(that said, the platform-pci driver in linux is actually broken when vector
callbacks are not used anyway)

I also think that the grant-table lives on this PCI device MMIO BAR (?!)

If you looked at hw/i386/xen/xen_platform.c in QEMU source , you will get a
general idea what this device is supposed todo (like logging to syslog stuff
for example).

That said the platform device is really not fully utilized anyway in Linux.

On Tue, Apr 12, 2016 at 4:09 PM, Konrad Rzeszutek Wilk
 wrote:
> On Tue, Apr 12, 2016 at 02:19:48AM +, Wu, Bob wrote:
>>
>> Really thanks for your reply.
>
> Hey!
>
> CC-ing Xen-devel back on. Please do not drop it and please don't
> top-post.
>>
>> Can you explain a little more?
>
> I am not sure what you want me to explain. Perhaps if you
> read http://xenbits.xen.org/docs/unstable/misc/hvm-emulated-unplug.html
> it may become clearer?
>
>> Is the xen platform pci driver the only purpose for telling QEMU  that don’t 
>> emulate the IDE driver?
>
> And network.
>> I think it can be done by a simple way, but don't need use this huge 
>> platform driver.
>
> ?
>>
>> I guess this is for PCI pass through in XEN HVM mode, but don't sure.
>
> No.
>>
>> Thanks,
>> Bob
>>
>>
>> -Original Message-
>> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
>> Sent: 2016年4月11日 22:24
>> To: Wu, Bob
>> Cc: xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] Question about the XEN platform pci
>>
>> On Fri, Apr 08, 2016 at 08:52:08AM +, Wu, Bob wrote:
>> >
>> > Sorry bother, I read the XEN source code recently, and found the XEN
>> > platform PCI code under drivers/xen/platform-pci.c, and I can't fully 
>> > under this driver's affect, can anybody explain a little for me?
>> >
>> > Is the platform PCI driver for PV-split-PCI-driver-model such as the 
>> > pci-frontend/pci-backend? or for PCI pass-through model? Or for other 
>> > purpose?
>> > I saw the xenbus_pcifront_driver/ xenbus_xen_pcibk_driver are registered 
>> > on XENBUS, so I guess the platform-PCI-driver is not for PV PCI driver.
>> >
>>
>> It is for the QEMU driver. To tell QEMU to stop emulating the IDE/network.
>>
>> > Really thank you for your replay.
>> >
>> > Thanks,
>> > Bob
>> >
>>
>> > ___
>> > Xen-devel mailing list
>> > Xen-devel@lists.xen.org
>> > http://lists.xen.org/xen-devel
>>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



-- 
Karim Allah Ahmed.

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

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

[Jan Beulich]

>>> George Dunlap  04/12/16 4:38 PM >>>
>On Tue, Apr 12, 2016 at 2:56 PM, Konrad Rzeszutek Wilk 
> wrote:
>> options (1-4) seem perfectly fine to me.  FWIW my preferred color
>> would probably be 1 because it's the easiest and least inconsistent
>> with the current state of things. My least favorite would be 3,
>> because although each individual piece of information is only in one
>> place, the path to get there is duplicated; both the kernel developer
>> and the hypervisor developer are forced to continue to deal with both.
>
> The state is that 1-3 have been Nacked by Andrew, 4 has been
> Nacked by Jan. And 5) (the original way) was way way back Nacked
> as well.

No, I only withdrew my ack. Hence an ack from another REST maintainer
would suffice for it to stay in as it is now.

>There's a difference between "I think this other way is better" and "I
>am absolutely opposed to this".
>
>Well we know which option Andy prefers, but are there other options
>that Andy is not absolutely opposed to?  And we don't know anything
>about which option Jan prefers at all, except that it's not #4.

 As said in another reply - a suitable variant of 2.

Jan


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

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

[Konrad Rzeszutek Wilk]

On Tue, Apr 12, 2016 at 09:17:29AM -0600, Jan Beulich wrote:
> >>> George Dunlap  04/12/16 11:58 AM >>>
> >On Mon, Apr 11, 2016 at 6:46 PM, Jan Beulich  wrote:
> >>> ISTM that the lower duplication (which in principle is an advantage
> >>> which will be time limited if we are ever able to completely remove
> >>> teh old hypercall) comes with the cost of (in the long term) increased
> >>> mess in this particular subop.
> >>
> >> We cannot, ever, remove a not toolstack limited hypercall completely
> >> (or if, then only by Kconfig option so that people knowing none of the
> >> guests they care about use such deprecated ones).
> >
> >We need to keep the hypercall around and functioning for ABI
> >compatibility, but we could at least remove it from the public headers
> >and point people to using the new one instead.  (Discussion about the
> >merit of this idea below.)
> 
> Please don't forget that guests use this to be deprecated hypercall as one of 
> the
> cheapest possible ways to call into the hypervisor just to get events 
> delivered.
> I'm afraid the new hypercall would mean (slightly) more overhead. In fact I'm
> afraid the addition of the XSM call to the old one already had some of this 
> effect
> namely when XSM is enabled: Konrad - was this considered when you added
> that?

Yes, and I raised it up as well :-)

However, now that we dropped the XSM checks for some of the sub-ops,
it is pointless to do the XSM checks for them (they just do
function functions calls that end up with return 0).

I can most certainly add back the mask of flags - so only specific sub-ops
go through the XSM check. Let me write a patch for this and send it
out for review shortly.
> 
> >OK, so here are the options I see:
> >
> >1. Use the existing hypercall with the existing call semantics for
> >build-id -- i.e., require the caller to have a large but fixed-length
> >buffer (maybe 1024 or 2048).
> 
> I think it was explained even on this thread that a fixed size may indeed not
> be suitable here.
> 
> >2. Use the existing hypercall but wedge in different calling semantics
> >for the build-id subop.  We could have just that subop pay attention
> >to an extra argument as a length, for example, and return an error if
> >the length is too short.  Or we could make essentially a flag that
> >asks, "How much space if I were to execute this subop for real?"
> 
> A suitable variant of this is what I've been arguing for.
> 
> Jan
> 

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

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

[Tamas K Lengyel]

> >> @@ -254,6 +279,7 @@ typedef struct vm_event_st {
> >  >union {
> >  >union {
> >  >struct vm_event_regs_x86 x86;
> >> +struct vm_event_regs_arm arm;
> >  >} regs;
> >
> >  Does this alter the x86 ABI? Perhaps the ARM structure is
small enough for
> > this to not happen now, but what's the general idea about not breaking
other
> > arch'es ABIs when adding support for a new arch here?
>
> I'd suggest modifying VM_EVENT_INTERFACE_VERSION whenever that becomes
> the case.
>

Yeap, that's what I had in mind too, if we end up changing the layout or
the size of the struct we will increment the version.

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

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

[Tamas K Lengyel]

On Apr 12, 2016 08:58, "Konrad Rzeszutek Wilk" 
wrote:
>
> On Mon, Apr 11, 2016 at 01:47:22PM -0600, Tamas K Lengyel wrote:
> > From: Tamas K Lengyel 
> >
> > The ARM SMC instructions are already configured to trap to Xen by
default. In
> > this patch we allow a user-space process in a privileged domain to
receive
> > notification of when such event happens through the vm_event subsystem.
> >
> > This patch will likely needs to be broken up into several smaller
patches.
> > Right now what this patch adds (and could be broken into smaller patches
> > accordingly):
> > - Implement monitor_op domctl handler for SOFTWARE_BREAKPOINTs on
ARM
> > - Implement vm_event register fill/set routines for ARM. This
required
> > removing the function from common as the function prototype now
> > differs on the two archs.
> > - Sending notification as SOFTWARE_BREAKPOINT vm_event from the SMC
trap
> > handlers.
> > - Extend the xen-access test tool to receive SMC notification and
step
> > the PC manually in the reply.
> >
> > I'm sending it as an RFC to gather feedback on what has been overlooked
in this
> > revision. This patch has been tested on a Cubietruck board and works
fine,
> > but would probably not work on 64-bit boards.
>
> I only have some small nitpicking.
> > +++ b/xen/arch/arm/traps.c
> > @@ -41,6 +41,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "decode.h"
> >  #include "vtimer.h"
> > @@ -2449,6 +2450,21 @@ bad_data_abort:
> >  inject_dabt_exception(regs, info.gva, hsr.len);
> >  }
> >
> > +static void do_trap_smc(struct cpu_user_regs *regs)
> > +{
> > +int rc = 0;
>
> Newline here

Ack.

> > +if ( current->domain->arch.monitor.software_breakpoint_enabled )
> > +{
> > +rc = vm_event_smc(regs);
> > +}
> > +
> > +if ( rc != 1 )
> > +{
> > +GUEST_BUG_ON(!psr_mode_is_32bit(regs->cpsr));
>
> This differs a bit from below. Should there be an comment explaining why
> we expect it be only in 32-bit mode?
>
> > +inject_undef32_exception(regs);
>
> Below you do inject_undef64_exception?
>
> Perhaps there should be an check if it is 32 or 64-bit?

Yes, indeed there should be.

>
> > +}
> > +}
> > +
> >  static void enter_hypervisor_head(struct cpu_user_regs *regs)
> >  {
> >  if ( guest_mode(regs) )
> > @@ -2524,7 +2540,7 @@ asmlinkage void do_trap_hypervisor(struct
cpu_user_regs *regs)
> >   */
> >  GUEST_BUG_ON(!psr_mode_is_32bit(regs->cpsr));
> >  perfc_incr(trap_smc32);
> > -inject_undef32_exception(regs);
> > +do_trap_smc(regs);
> >  break;
> >  case HSR_EC_HVC32:
> >  GUEST_BUG_ON(!psr_mode_is_32bit(regs->cpsr));
> > @@ -2557,7 +2573,7 @@ asmlinkage void do_trap_hypervisor(struct
cpu_user_regs *regs)
> >   */
> >  GUEST_BUG_ON(psr_mode_is_32bit(regs->cpsr));
> >  perfc_incr(trap_smc64);
> > -inject_undef64_exception(regs, hsr.len);
> > +do_trap_smc(regs);
>
> As in here.. Now it will call inject_undef32_exception. That can't
> be healthy?

Ack.

>
> >  break;
> >  case HSR_EC_SYSREG:
> >  GUEST_BUG_ON(psr_mode_is_32bit(regs->cpsr));
> > diff --git a/xen/arch/arm/vm_event.c b/xen/arch/arm/vm_event.c
> > new file mode 100644
> > index 000..d997313
> > --- /dev/null
> > +++ b/xen/arch/arm/vm_event.c
> > @@ -0,0 +1,95 @@
> > +/*
> > + * arch/arm/vm_event.c
> > + *
> > + * Architecture-specific vm_event handling routines
> > + *
> > + * Copyright (c) 2015 Tamas K Lengyel (ta...@tklengyel.com)
>
> 2016?

Yeap.

> Also .. shouldn't the company be attributed as well? I see BitDefender
> on some of them so not sure what hte relationship you have with them.

I'm not affiliated with BitDefender in any way and at the moment I'm just
doing this on my own as I'm no longer with Novetta either.

>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public
> > + * License v2 as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > + * General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public
> > + * License along with this program; If not, see <
http://www.gnu.org/licenses/>.
> > + */
> > +
> > +#include 
> > +#include 
> > +
> > +static inline
> > +void vm_event_fill_regs(vm_event_request_t *req,
> > +const struct cpu_user_regs *regs)
> > +{
> > +req->data.regs.arm.r0 = regs->r0;
> > +req->data.regs.arm.r1 = regs->r1;
> > +req->data.regs.arm.r2 = regs->r2;
> > +req->data.regs.arm.r3 = regs->r3;
> > +req->data.regs.arm.r4 = regs->r4;
> > +req->data.regs.arm.r5 = regs->r5

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

[Jan Beulich]

>>> George Dunlap  04/12/16 11:58 AM >>>
>On Mon, Apr 11, 2016 at 6:46 PM, Jan Beulich  wrote:
>>> ISTM that the lower duplication (which in principle is an advantage
>>> which will be time limited if we are ever able to completely remove
>>> teh old hypercall) comes with the cost of (in the long term) increased
>>> mess in this particular subop.
>>
>> We cannot, ever, remove a not toolstack limited hypercall completely
>> (or if, then only by Kconfig option so that people knowing none of the
>> guests they care about use such deprecated ones).
>
>We need to keep the hypercall around and functioning for ABI
>compatibility, but we could at least remove it from the public headers
>and point people to using the new one instead.  (Discussion about the
>merit of this idea below.)

Please don't forget that guests use this to be deprecated hypercall as one of 
the
cheapest possible ways to call into the hypervisor just to get events delivered.
I'm afraid the new hypercall would mean (slightly) more overhead. In fact I'm
afraid the addition of the XSM call to the old one already had some of this 
effect
namely when XSM is enabled: Konrad - was this considered when you added
that?

>OK, so here are the options I see:
>
>1. Use the existing hypercall with the existing call semantics for
>build-id -- i.e., require the caller to have a large but fixed-length
>buffer (maybe 1024 or 2048).

I think it was explained even on this thread that a fixed size may indeed not
be suitable here.

>2. Use the existing hypercall but wedge in different calling semantics
>for the build-id subop.  We could have just that subop pay attention
>to an extra argument as a length, for example, and return an error if
>the length is too short.  Or we could make essentially a flag that
>asks, "How much space if I were to execute this subop for real?"

A suitable variant of this is what I've been arguing for.

Jan


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

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

[Jan Beulich]

>>> "Yu, Zhang"  04/12/16 11:47 AM >>>
>On 4/12/2016 12:31 AM, Jan Beulich wrote:
> On 11.04.16 at 13:14,  wrote:
>>> On 4/9/2016 6:28 AM, Jan Beulich wrote:
>>> On 31.03.16 at 12:53,  wrote:
> +if ( s->id == id )
> +{
> +rc = p2m_set_ioreq_server(d, flags, s);
> +if ( rc == 0 )
> +gdprintk(XENLOG_DEBUG, "%u %s type 
> HVMMEM_ioreq_server.\n",
> + s->id, (flags != 0) ? "mapped to" : "unmapped 
> from");

 Why gdprintk()? I don't think the current domain is of much
 interest here. What would be of interest is the subject domain.

>>>
>>> s->id is not the domain_id, but id of the ioreq server.
>>
>> That's understood. But gdprintk() itself logs the current domain,
>> which isn't as useful as the subject one.
>
>Oh, I see. So the correct routine here should be dprintk(), right?

Yes.

 And with all three bits now possibly being clear, aren't we risking the
 entries to be mis-treated as not-present ones?
>>>
>>> Hah. You got me. Thanks! :)
>>> Now I realized it would be difficult if we wanna to emulate the read
>>> operations for HVM. According to Intel mannual, entry->r is to be
>>> cleared, so should entry->w if we do not want ept misconfig. And
>>> with both read and write permissions being forbidden, entry->x can be
>>> set only on processors with EXECUTE_ONLY capability.
>>> To avoid any entry to be mis-treated as not-present. We have several
>>> solutions:
>>> a> do not support the read emulation for now - we have no such usage
>>> case;
>>> b> add the check of p2m_t against p2m_ioreq_server in is_epte_present -
>>> a bit weird to me.
>>> Which one do you prefer? or any other suggestions?
>>
>> That question would also need to be asked to others who had
>> suggested supporting both. I'd be fine with a, but I also don't view
>> b as too awkward.
>
>According to Intel mannual, an entry is regarded as not present, if
>bit0:2 is 0. So adding a p2m type check in is_epte_present() means we
>will change its semantics, if this is acceptable(with no hurt to
>hypervisor). I'd prefer option b>

Perhaps time for the VMX maintainers to chime in - such a change is acceptable
only if it doesn't result in changed hardware behavior. I can't think of any 
such off
the top of my head, but this really should be confirmed by the maintainers 
before
deciding to go such a route.

Jan


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

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

[Tamas K Lengyel]

On Apr 11, 2016 22:31, "Jan Beulich"  wrote:
>
> >>> Tamas K Lengyel  04/11/16 9:47 PM >>>
> >--- a/xen/include/public/vm_event.h
> >+++ b/xen/include/public/vm_event.h
> >@@ -166,6 +166,31 @@ struct vm_event_regs_x86 {
>  >uint32_t _pad;
>  >};
>  >
> >+struct vm_event_regs_arm {
> >+uint32_t r0;
> >+uint32_t r1;
> >+uint32_t r2;
> >+uint32_t r3;
> >+uint32_t r4;
> >+uint32_t r5;
> >+uint32_t r6;
> >+uint32_t r7;
> >+uint32_t r8;
> >+uint32_t r9;
> >+uint32_t r10;
> >+uint32_t r11;
> >+uint32_t r12;
> >+
> >+uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked
(see below) */
> >+uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as
lr_usr. */
> >+
> >+uint32_t cpsr; /* Return mode */
> >+uint64_t pc;
>
> Why uint64_t instead of uint32_t?

No apparent reason, will fix.

>
> >+uint64_t ttbr0;
> >+uint64_t ttbr1;
> >+uint32_t _pad;
> >+};
>
> This padding field is pretty strange: Without the adjustment to pc there
are 16
> 32-bit fields (not counting the padding one), so I don't see why padding
would be
> needed at all. And with pc adjusted the padding field would surely better
go
> ahead of the two remaining 64-bit ones.

Yes, I have been shuffling this struct around and didn't check the layout.
Will fix. I'll also try to make this struct usable for aarch64 too.

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

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

[Tamas K Lengyel]

On Apr 12, 2016 01:51, "Corneliu ZUZU"  wrote:
>
> On 4/11/2016 10:47 PM, Tamas K Lengyel wrote:
>>
>> From: Tamas K Lengyel 
>>
>> The ARM SMC instructions are already configured to trap to Xen by
default. In
>> this patch we allow a user-space process in a privileged domain to
receive
>> notification of when such event happens through the vm_event subsystem.
>>
>> This patch will likely needs to be broken up into several smaller
patches.
>> Right now what this patch adds (and could be broken into smaller patches
>> accordingly):
>>  - Implement monitor_op domctl handler for SOFTWARE_BREAKPOINTs on
ARM
>>  - Implement vm_event register fill/set routines for ARM. This
required
>>  removing the function from common as the function prototype now
>>  differs on the two archs.
>>  - Sending notification as SOFTWARE_BREAKPOINT vm_event from the SMC
trap
>>  handlers.
>>  - Extend the xen-access test tool to receive SMC notification and
step
>>  the PC manually in the reply.
>>
>> I'm sending it as an RFC to gather feedback on what has been overlooked
in this
>> revision. This patch has been tested on a Cubietruck board and works
fine,
>> but would probably not work on 64-bit boards.
>
>
> Hi Tamas,
>
> If I may, I'm still unable to work at the moment, being ill, but I'm
checking the xen-devel lists from time to time.
> Your patch caught my attention, reminding me of the conversation we had
some time ago on this matter.
> The only real reason I don't see SMC (secure-monitor-call) as being an
ideal candidate for this is that, according to the ARM manuals, SMC should
directly cause undefined exception if executed from user-mode (EL0),
instead of a hypervisor trap - isn't that the case on the machine you
tested this on or is this really only for the EL1 of domains?

That's correct, it can only be issued by the kernel. So as long as you want
to monitor the kernel it can be used just fine. I can also envision
trampoline-like traps (syscalls injected into EL0 to trigger SMC) but
that's beyond the scope I intend this for now.

>
> Also:
> - SMC, by definition, is a call to the secure side, it doesn't relate to
debugging directly (it's a syscall to the 'secure' side). There is a viable
INT3 equivalent on ARM, that being the BKPT/BRK instruction, using that
instead would require a bit more effort (but would, conceptually, be more
correct) and might be less performant, I suppose that's why you didn't go
for that?

I would have to double check but AFAIK those instructions can't be
configured to trap to the hypervisor directly. So while SMC was not
intended to be a breakpoint, conceptually it's the closest thing we have an
on ARM to the INT3 instruction when configured to trap to the VMM.

> - SMC can be disabled by the secure side (over which Xen doesn't have
control) - not really a problem on though, since the hypervisor trap
happens before that check
> But these 2 are conceptual problems, they don't impede usage of SMC as
you intend in practice.

Sure, the TrustZone is more privileged then the hypervisor so you need to
take that into account as well when you consider your threat model. If the
TZ is malicious though IMHO there isn't much you can do on the hypervisor
side anyway. So in the usecase I have for this I control the TZ as well.

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

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

[Konrad Rzeszutek Wilk]

On Tue, Apr 12, 2016 at 03:38:31PM +0100, George Dunlap wrote:
> On Tue, Apr 12, 2016 at 2:56 PM, Konrad Rzeszutek Wilk
>  wrote:
> >> 3. We could use a new hypercall only for new functionality, with the
> >> proposed new semantics.  This would at minimum be build-id, but
> >> probably also extraversion, compileinfo, changeset, maybe
> >> capabilities_info.
> >>
> >> 4. Have the new hypercall replace the old hypercall.  The new
> >> hypercall will duplicate all the functionality of the old hypercall.
> >> Deprecate the hypercall for a release or two, then remove it from the
> >> public headers (although keep the code, because we need to maintain
> >> backwards compatibility).
> >
> > 5). Stick the build-id in the xsplice sysctl. Or just in the sysctl.
> 
> Which is somewhat similar to #3, except that instead of being in its
> own hypercall, it's with a bunch of other related functionality.  I'd
> be OK with that color too; it's not a great color but I think it's
> better than 3. :-)
> 
> >> This does seem to me an awful lot like a bike shed. :-)  All of the
> >
> > This is really past bike shedding - all the bikes shed have been
> > already built (for all those options).
> 
> You mean, the shed already has 3 layers of paint, a layer of
> wallpaper, and a layer of plastic siding? :-)


Yes. Very much so!
> 
> >> options (1-4) seem perfectly fine to me.  FWIW my preferred color
> >> would probably be 1 because it's the easiest and least inconsistent
> >> with the current state of things. My least favorite would be 3,
> >> because although each individual piece of information is only in one
> >> place, the path to get there is duplicated; both the kernel developer
> >> and the hypervisor developer are forced to continue to deal with both.
> >>
> >
> >
> > The state is that 1-3 have been Nacked by Andrew, 4 has been
> > Nacked by Jan. And 5) (the original way) was way way back Nacked
> > as well.
> 
> There's a difference between "I think this other way is better" and "I
> am absolutely opposed to this".
> 
> Well we know which option Andy prefers, but are there other options
> that Andy is not absolutely opposed to?  And we don't know anything
> about which option Jan prefers at all, except that it's not #4.

/me nods. Thank you for pointing that out.

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

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

[Konrad Rzeszutek Wilk]

On Mon, Apr 11, 2016 at 01:47:22PM -0600, Tamas K Lengyel wrote:
> From: Tamas K Lengyel 
> 
> The ARM SMC instructions are already configured to trap to Xen by default. In
> this patch we allow a user-space process in a privileged domain to receive
> notification of when such event happens through the vm_event subsystem.
> 
> This patch will likely needs to be broken up into several smaller patches.
> Right now what this patch adds (and could be broken into smaller patches
> accordingly):
> - Implement monitor_op domctl handler for SOFTWARE_BREAKPOINTs on ARM
> - Implement vm_event register fill/set routines for ARM. This required
> removing the function from common as the function prototype now
> differs on the two archs.
> - Sending notification as SOFTWARE_BREAKPOINT vm_event from the SMC trap
> handlers.
> - Extend the xen-access test tool to receive SMC notification and step
> the PC manually in the reply.
> 
> I'm sending it as an RFC to gather feedback on what has been overlooked in 
> this
> revision. This patch has been tested on a Cubietruck board and works fine,
> but would probably not work on 64-bit boards.

I only have some small nitpicking.
> +++ b/xen/arch/arm/traps.c
> @@ -41,6 +41,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "decode.h"
>  #include "vtimer.h"
> @@ -2449,6 +2450,21 @@ bad_data_abort:
>  inject_dabt_exception(regs, info.gva, hsr.len);
>  }
>  
> +static void do_trap_smc(struct cpu_user_regs *regs)
> +{
> +int rc = 0;

Newline here
> +if ( current->domain->arch.monitor.software_breakpoint_enabled )
> +{
> +rc = vm_event_smc(regs);
> +}
> +
> +if ( rc != 1 )
> +{
> +GUEST_BUG_ON(!psr_mode_is_32bit(regs->cpsr));

This differs a bit from below. Should there be an comment explaining why
we expect it be only in 32-bit mode?

> +inject_undef32_exception(regs);

Below you do inject_undef64_exception?

Perhaps there should be an check if it is 32 or 64-bit?

> +}
> +}
> +
>  static void enter_hypervisor_head(struct cpu_user_regs *regs)
>  {
>  if ( guest_mode(regs) )
> @@ -2524,7 +2540,7 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs 
> *regs)
>   */
>  GUEST_BUG_ON(!psr_mode_is_32bit(regs->cpsr));
>  perfc_incr(trap_smc32);
> -inject_undef32_exception(regs);
> +do_trap_smc(regs);
>  break;
>  case HSR_EC_HVC32:
>  GUEST_BUG_ON(!psr_mode_is_32bit(regs->cpsr));
> @@ -2557,7 +2573,7 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs 
> *regs)
>   */
>  GUEST_BUG_ON(psr_mode_is_32bit(regs->cpsr));
>  perfc_incr(trap_smc64);
> -inject_undef64_exception(regs, hsr.len);
> +do_trap_smc(regs);

As in here.. Now it will call inject_undef32_exception. That can't
be healthy?

>  break;
>  case HSR_EC_SYSREG:
>  GUEST_BUG_ON(psr_mode_is_32bit(regs->cpsr));
> diff --git a/xen/arch/arm/vm_event.c b/xen/arch/arm/vm_event.c
> new file mode 100644
> index 000..d997313
> --- /dev/null
> +++ b/xen/arch/arm/vm_event.c
> @@ -0,0 +1,95 @@
> +/*
> + * arch/arm/vm_event.c
> + *
> + * Architecture-specific vm_event handling routines
> + *
> + * Copyright (c) 2015 Tamas K Lengyel (ta...@tklengyel.com)

2016?
Also .. shouldn't the company be attributed as well? I see BitDefender
on some of them so not sure what hte relationship you have with them.

> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public
> + * License v2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see 
> .
> + */
> +
> +#include 
> +#include 
> +
> +static inline
> +void vm_event_fill_regs(vm_event_request_t *req,
> +const struct cpu_user_regs *regs)
> +{
> +req->data.regs.arm.r0 = regs->r0;
> +req->data.regs.arm.r1 = regs->r1;
> +req->data.regs.arm.r2 = regs->r2;
> +req->data.regs.arm.r3 = regs->r3;
> +req->data.regs.arm.r4 = regs->r4;
> +req->data.regs.arm.r5 = regs->r5;
> +req->data.regs.arm.r6 = regs->r6;
> +req->data.regs.arm.r7 = regs->r7;
> +req->data.regs.arm.r8 = regs->r8;
> +req->data.regs.arm.r9 = regs->r9;
> +req->data.regs.arm.r10 = regs->r10;
> +req->data.regs.arm.r11 = regs->r11;
> +req->data.regs.arm.r12 = regs->r12;
> +req->data.regs.arm.sp = regs->sp;
> +req->data.regs.arm.lr = regs->lr;
> +req->data.regs.arm.pc = regs->pc;
> +req->data.regs.arm.cpsr = regs->cpsr;
> +req->data.

Re: [Xen-devel] [PATCH] vm_event: Allow subscribing to write events for specific MSR-s

[Razvan Cojocaru]

On 04/12/2016 05:42 PM, Julien Grall wrote:
> Hello Razvan,
> 
> On 12/04/2016 15:34, Razvan Cojocaru wrote:
>> Previously, subscribing to MSR write events was an all-or-none
>> approach, with special cases for introspection MSR-s. This patch
>> allows the vm_event consumer to specify exactly what MSR-s it is
>> interested in, and as a side-effect gets rid of the
>> vmx_introspection_force_enabled_msrs[] special case.
>> This replaces the previously posted "xen: Filter out MSR write
>> events" patch.
>>
>> Signed-off-by: Razvan Cojocaru 
>> ---
>>   tools/libxc/include/xenctrl.h  |  4 +--
>>   tools/libxc/xc_monitor.c   |  6 ++--
>>   xen/arch/x86/hvm/event.c   |  3 +-
>>   xen/arch/x86/hvm/hvm.c |  3 +-
>>   xen/arch/x86/hvm/vmx/vmcs.c| 26 ++--
>>   xen/arch/x86/hvm/vmx/vmx.c | 10 ++
>>   xen/arch/x86/monitor.c | 25 +++
>>   xen/arch/x86/vm_event.c| 62
>> ++
>>   xen/include/asm-arm/vm_event.h | 21 +
> 
> Can you explain why you've added stubs for ARM when nobody in the common
> code is calling them?

Got carried away, just assumed symmetry is required. Will remove them in V2.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH] vm_event: Allow subscribing to write events for specific MSR-s

[Julien Grall]

Hello Razvan,

On 12/04/2016 15:34, Razvan Cojocaru wrote:

Previously, subscribing to MSR write events was an all-or-none
approach, with special cases for introspection MSR-s. This patch
allows the vm_event consumer to specify exactly what MSR-s it is
interested in, and as a side-effect gets rid of the
vmx_introspection_force_enabled_msrs[] special case.
This replaces the previously posted "xen: Filter out MSR write
events" patch.

Signed-off-by: Razvan Cojocaru 
---
  tools/libxc/include/xenctrl.h  |  4 +--
  tools/libxc/xc_monitor.c   |  6 ++--
  xen/arch/x86/hvm/event.c   |  3 +-
  xen/arch/x86/hvm/hvm.c |  3 +-
  xen/arch/x86/hvm/vmx/vmcs.c| 26 ++--
  xen/arch/x86/hvm/vmx/vmx.c | 10 ++
  xen/arch/x86/monitor.c | 25 +++
  xen/arch/x86/vm_event.c| 62 ++
  xen/include/asm-arm/vm_event.h | 21 +


Can you explain why you've added stubs for ARM when nobody in the common 
code is calling them?


Regards,

--
Julien Grall

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

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

[George Dunlap]

On Tue, Apr 12, 2016 at 2:56 PM, Konrad Rzeszutek Wilk
 wrote:
>> 3. We could use a new hypercall only for new functionality, with the
>> proposed new semantics.  This would at minimum be build-id, but
>> probably also extraversion, compileinfo, changeset, maybe
>> capabilities_info.
>>
>> 4. Have the new hypercall replace the old hypercall.  The new
>> hypercall will duplicate all the functionality of the old hypercall.
>> Deprecate the hypercall for a release or two, then remove it from the
>> public headers (although keep the code, because we need to maintain
>> backwards compatibility).
>
> 5). Stick the build-id in the xsplice sysctl. Or just in the sysctl.

Which is somewhat similar to #3, except that instead of being in its
own hypercall, it's with a bunch of other related functionality.  I'd
be OK with that color too; it's not a great color but I think it's
better than 3. :-)

>> This does seem to me an awful lot like a bike shed. :-)  All of the
>
> This is really past bike shedding - all the bikes shed have been
> already built (for all those options).

You mean, the shed already has 3 layers of paint, a layer of
wallpaper, and a layer of plastic siding? :-)

>> options (1-4) seem perfectly fine to me.  FWIW my preferred color
>> would probably be 1 because it's the easiest and least inconsistent
>> with the current state of things. My least favorite would be 3,
>> because although each individual piece of information is only in one
>> place, the path to get there is duplicated; both the kernel developer
>> and the hypervisor developer are forced to continue to deal with both.
>>
>
>
> The state is that 1-3 have been Nacked by Andrew, 4 has been
> Nacked by Jan. And 5) (the original way) was way way back Nacked
> as well.

There's a difference between "I think this other way is better" and "I
am absolutely opposed to this".

Well we know which option Andy prefers, but are there other options
that Andy is not absolutely opposed to?  And we don't know anything
about which option Jan prefers at all, except that it's not #4.

 -George

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

Re: [Xen-devel] [PATCH v2] docs: add misc/qemu-backends.txt

[Wei Liu]

On Mon, Apr 11, 2016 at 03:04:09PM +0200, Juergen Gross wrote:
> Document the interface between qemu and libxl regarding backends
> supported by qemu.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Wei Liu 

> ---
> v2: - replace variable Xenstore path parts () with bash-like syntax
>   ($XYZ) as requested by Konrad Wilk
> - add remark about de-privileged qemu as requested by Stefano
>   Stabellini
> - add comma as suggested by Andrew Cooper
> ---
>  docs/misc/qemu-backends.txt | 21 +
>  1 file changed, 21 insertions(+)
>  create mode 100644 docs/misc/qemu-backends.txt
> 
> diff --git a/docs/misc/qemu-backends.txt b/docs/misc/qemu-backends.txt
> new file mode 100644
> index 000..b8e1799
> --- /dev/null
> +++ b/docs/misc/qemu-backends.txt
> @@ -0,0 +1,21 @@
> +In order to know whether qemu supports a specific backend type libxl
> +needs a way to obtain this information.
> +
> +As each qemu instance owns a path (named $QEMU from now on) in
> +Xenstore, the backend information is presented there. $QEMU is built
> +from the domain id where the qemu instance is running $BACKEND_DOM,
> +and the domain id of the target domain of the qemu process $DOMID:
> +
> +$QEMU = /local/domain/$BACKEND_DOM/device-model/$DOMID
> +
> +Before signalling qemu is running by writing "running" to $QEMU/state
> +qemu will create a Xenstore node for each supported backend under
> +$QEMU/backends with the backend type as name (e.g.  $QEMU/backends/qdisk
> +for the qdisk backend). In case qemu is running de-privileged (not as
> +user root) the backend nodes must be written before qemu is dropping
> +privileges.
> +
> +libxl can assume a backend of a specific type $TYPE is supported if:
> +- $QEMU/backends/$TYPE is existing in Xenstore
> +- or $QEMU/backends is not existing and $TYPE is one of:
> +  "console", "vkbd", "vfb", "qdisk", "qnic"
> -- 
> 2.6.6
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

[Xen-devel] [PATCH] vm_event: Allow subscribing to write events for specific MSR-s

[Razvan Cojocaru]

Previously, subscribing to MSR write events was an all-or-none
approach, with special cases for introspection MSR-s. This patch
allows the vm_event consumer to specify exactly what MSR-s it is
interested in, and as a side-effect gets rid of the
vmx_introspection_force_enabled_msrs[] special case.
This replaces the previously posted "xen: Filter out MSR write
events" patch.

Signed-off-by: Razvan Cojocaru 
---
 tools/libxc/include/xenctrl.h  |  4 +--
 tools/libxc/xc_monitor.c   |  6 ++--
 xen/arch/x86/hvm/event.c   |  3 +-
 xen/arch/x86/hvm/hvm.c |  3 +-
 xen/arch/x86/hvm/vmx/vmcs.c| 26 ++--
 xen/arch/x86/hvm/vmx/vmx.c | 10 ++
 xen/arch/x86/monitor.c | 25 +++
 xen/arch/x86/vm_event.c| 62 ++
 xen/include/asm-arm/vm_event.h | 21 +
 xen/include/asm-x86/domain.h   |  4 +--
 xen/include/asm-x86/hvm/hvm.h  |  8 ++---
 xen/include/asm-x86/hvm/vmx/vmcs.h |  7 -
 xen/include/asm-x86/vm_event.h |  6 
 xen/include/public/domctl.h|  3 +-
 14 files changed, 122 insertions(+), 66 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index f5a034a..9698d46 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2183,8 +2183,8 @@ int xc_monitor_get_capabilities(xc_interface *xch, 
domid_t domain_id,
 int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t domain_id,
  uint16_t index, bool enable, bool sync,
  bool onchangeonly);
-int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, bool enable,
-  bool extended_capture);
+int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, uint32_t msr,
+  bool enable);
 int xc_monitor_singlestep(xc_interface *xch, domid_t domain_id, bool enable);
 int xc_monitor_software_breakpoint(xc_interface *xch, domid_t domain_id,
bool enable);
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index b1705dd..78131b2 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -86,8 +86,8 @@ int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t 
domain_id,
 return do_domctl(xch, &domctl);
 }
 
-int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, bool enable,
-  bool extended_capture)
+int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, uint32_t msr,
+  bool enable)
 {
 DECLARE_DOMCTL;
 
@@ -96,7 +96,7 @@ int xc_monitor_mov_to_msr(xc_interface *xch, domid_t 
domain_id, bool enable,
 domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
 : XEN_DOMCTL_MONITOR_OP_DISABLE;
 domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR;
-domctl.u.monitor_op.u.mov_to_msr.extended_capture = extended_capture;
+domctl.u.monitor_op.u.mov_to_msr.msr = msr;
 
 return do_domctl(xch, &domctl);
 }
diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
index 56c5514..25d55de 100644
--- a/xen/arch/x86/hvm/event.c
+++ b/xen/arch/x86/hvm/event.c
@@ -57,9 +57,8 @@ bool_t hvm_event_cr(unsigned int index, unsigned long value, 
unsigned long old)
 void hvm_event_msr(unsigned int msr, uint64_t value)
 {
 struct vcpu *curr = current;
-struct arch_domain *ad = &curr->domain->arch;
 
-if ( ad->monitor.mov_to_msr_enabled )
+if ( vm_event_is_msr_enabled(curr->domain, msr) )
 {
 vm_event_request_t req = {
 .reason = VM_EVENT_REASON_MOV_TO_MSR,
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index f24126d..ce78627 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3695,7 +3695,6 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 bool_t mtrr;
 unsigned int edx, index;
 int ret = X86EMUL_OKAY;
-struct arch_domain *currad = ¤t->domain->arch;
 
 HVMTRACE_3D(MSR_WRITE, msr,
(uint32_t)msr_content, (uint32_t)(msr_content >> 32));
@@ -3703,7 +3702,7 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 hvm_cpuid(1, NULL, NULL, NULL, &edx);
 mtrr = !!(edx & cpufeat_mask(X86_FEATURE_MTRR));
 
-if ( may_defer && unlikely(currad->monitor.mov_to_msr_enabled) )
+if ( may_defer && unlikely(vm_event_is_msr_enabled(v->domain, msr)) )
 {
 ASSERT(v->arch.vm_event);
 
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 8284281..fd5c772 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static bool_t __read_mostly opt_vpid_enabled = 1;
@@ -108,18 +109,6 @@ u64 vmx_ept_vpid_cap __read_mostly;
 u64 vmx_vmfunc __read_mostly;
 bool_t vmx_virt_exception __read_mostly;
 
-const u32 vmx

Re: [Xen-devel] Question about the XEN platform pci

[Konrad Rzeszutek Wilk]

On Tue, Apr 12, 2016 at 02:19:48AM +, Wu, Bob wrote:
> 
> Really thanks for your reply.

Hey!

CC-ing Xen-devel back on. Please do not drop it and please don't
top-post.
> 
> Can you explain a little more?

I am not sure what you want me to explain. Perhaps if you
read http://xenbits.xen.org/docs/unstable/misc/hvm-emulated-unplug.html
it may become clearer?

> Is the xen platform pci driver the only purpose for telling QEMU  that don’t 
> emulate the IDE driver?

And network.
> I think it can be done by a simple way, but don't need use this huge platform 
> driver.

?
> 
> I guess this is for PCI pass through in XEN HVM mode, but don't sure.

No. 
> 
> Thanks,
> Bob
> 
> 
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] 
> Sent: 2016年4月11日 22:24
> To: Wu, Bob
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Question about the XEN platform pci
> 
> On Fri, Apr 08, 2016 at 08:52:08AM +, Wu, Bob wrote:
> > 
> > Sorry bother, I read the XEN source code recently, and found the XEN 
> > platform PCI code under drivers/xen/platform-pci.c, and I can't fully under 
> > this driver's affect, can anybody explain a little for me?
> > 
> > Is the platform PCI driver for PV-split-PCI-driver-model such as the 
> > pci-frontend/pci-backend? or for PCI pass-through model? Or for other 
> > purpose?
> > I saw the xenbus_pcifront_driver/ xenbus_xen_pcibk_driver are registered on 
> > XENBUS, so I guess the platform-PCI-driver is not for PV PCI driver.
> > 
> 
> It is for the QEMU driver. To tell QEMU to stop emulating the IDE/network.
> 
> > Really thank you for your replay.
> > 
> > Thanks,
> > Bob
> > 
> 
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

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

Re: [Xen-devel] [PATCH v2 2/3] xenfb: move xen_rmb to the correct location

[Wei Liu]

On Tue, Apr 12, 2016 at 02:38:13PM +0100, Andrew Cooper wrote:
> On 12/04/16 13:57, David Vrabel wrote:
> > On 12/04/16 11:43, Wei Liu wrote:
> >> It should be placed before first time producer and consumer are used.
> > This change isn't necessary and is confusing as this is not what this
> > barrier is for.
> >
> > The barrier needs to be between the load of prod and the load of the
> > ring contents (there's even a comment that says this).  This pairs with
> > the corresponding write barrier between the store of the ring contents
> > and the store of prod (in the other end).
> 
> Looking further, this code will compile to multiple reads of the page,
> because there is no ACCESS_ONCE().  This code is still vulnerable to
> XSA-155.
> 

Oops, accidentally kicked over a can of worms. Should have just sent
patch 1. :-)

Jokes aside, more time is needed to fix this properly. So maybe we
should just upstream patch #1 first. Stefano? Anthony?

Wei.

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

[Xen-devel] [PATCH] tools: fix compile errors with -Og

[Olaf Hering]

At least gcc-4.8 and older fails to recognize that err is always
initialized, the build fails:
  xc_cpupool.c: In function 'xc_cpupool_removecpu':
  xc_cpupool.c:168:5: error: 'err' may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
return err;

Fix this in blktap2 and libxc.

Signed-off-by: Olaf Hering 
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/blktap2/drivers/tapdisk-vbd.c | 6 +++---
 tools/libxc/xc_cpupool.c| 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/blktap2/drivers/tapdisk-vbd.c 
b/tools/blktap2/drivers/tapdisk-vbd.c
index 89ef9ed..31bc2fe 100644
--- a/tools/blktap2/drivers/tapdisk-vbd.c
+++ b/tools/blktap2/drivers/tapdisk-vbd.c
@@ -516,7 +516,7 @@ tapdisk_vbd_free_stack(td_vbd_t *vbd)
 int
 tapdisk_vbd_open_stack(td_vbd_t *vbd, uint16_t storage, td_flag_t flags)
 {
-   int i, err;
+   int i, err = 0;
 
vbd->flags   = flags;
vbd->storage = storage;
@@ -932,7 +932,7 @@ tapdisk_vbd_open_image(td_vbd_t *vbd, td_image_t *image)
 static int
 tapdisk_vbd_close_and_reopen_image(td_vbd_t *vbd, td_image_t *image)
 {
-   int i, err;
+   int i, err = 0;
 
td_close(image);
 
@@ -972,7 +972,7 @@ tapdisk_vbd_pause(td_vbd_t *vbd)
 int
 tapdisk_vbd_resume(td_vbd_t *vbd, const char *path, uint16_t drivertype)
 {
-   int i, err;
+   int i, err = 0;
 
if (!td_flag_test(vbd->state, TD_VBD_PAUSED)) {
EPRINTF("resume request for unpaused vbd %s\n", vbd->name);
diff --git a/tools/libxc/xc_cpupool.c b/tools/libxc/xc_cpupool.c
index 261b9c9..abf707d 100644
--- a/tools/libxc/xc_cpupool.c
+++ b/tools/libxc/xc_cpupool.c
@@ -151,7 +151,7 @@ int xc_cpupool_removecpu(xc_interface *xch,
  int cpu)
 {
 unsigned retries;
-int err;
+int err = 0;
 DECLARE_SYSCTL;
 
 sysctl.cmd = XEN_SYSCTL_cpupool_op;

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

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

[Konrad Rzeszutek Wilk]

On Tue, Apr 12, 2016 at 10:58:09AM +0100, George Dunlap wrote:
> On Mon, Apr 11, 2016 at 6:46 PM, Jan Beulich  wrote:
> [snip]
> >> ISTM that the lower duplication (which in principle is an advantage
> >> which will be time limited if we are ever able to completely remove
> >> teh old hypercall) comes with the cost of (in the long term) increased
> >> mess in this particular subop.
> >
> > We cannot, ever, remove a not toolstack limited hypercall completely
> > (or if, then only by Kconfig option so that people knowing none of the
> > guests they care about use such deprecated ones).
> 
> We need to keep the hypercall around and functioning for ABI
> compatibility, but we could at least remove it from the public headers
> and point people to using the new one instead.  (Discussion about the
> merit of this idea below.)
> 
> [snip]
> >> ISTM that the lower duplication (which in principle is an advantage
> >> which will be time limited if we are ever able to completely remove
> >> teh old hypercall) comes with the cost of (in the long term) increased
> >> mess in this particular subop.
> >>
> >> Is that right ?  Obviously this cost is not very significant.  But
> >> maybe the duplication isn't that significant either.  I was kind of
> >> expecting to find stronger arguments on both sides in this
> >> discussion...
> >
> > If, btw, the cost of having to read the length argument from guest
> > memory was deemed undesirable, we'd certainly have the option
> > of specifying it to be passed through, say, the high half of the
> > current "cmd" parameter.
> 
> OK, so here are the options I see:
> 
> 1. Use the existing hypercall with the existing call semantics for
> build-id -- i.e., require the caller to have a large but fixed-length
> buffer (maybe 1024 or 2048).
> 
> 2. Use the existing hypercall but wedge in different calling semantics
> for the build-id subop.  We could have just that subop pay attention
> to an extra argument as a length, for example, and return an error if
> the length is too short.  Or we could make essentially a flag that
> asks, "How much space if I were to execute this subop for real?"

You can't wedge in the extra argument. Tried that an Jan pointed out
that we clobber it (specifically we clobber any non-used arguments).
> 
> 3. We could use a new hypercall only for new functionality, with the
> proposed new semantics.  This would at minimum be build-id, but
> probably also extraversion, compileinfo, changeset, maybe
> capabilities_info.
> 
> 4. Have the new hypercall replace the old hypercall.  The new
> hypercall will duplicate all the functionality of the old hypercall.
> Deprecate the hypercall for a release or two, then remove it from the
> public headers (although keep the code, because we need to maintain
> backwards compatibility).

5). Stick the build-id in the xsplice sysctl. Or just in the sysctl.

> 
> Honestly I still don't quite understand what the problem is with #1 --
> if build-id is mainly meant to be a UUID or a hash of the build to
> make sure that you're applying the right hotfix (please correct me if
> I'm wrong here -- I haven't had time to actually follow the patch
> series), 256 bytes should be enough for a properly hashed build, and
> 2048 should be more than enough.  Requiring the caller to have a
> 2048-byte buffer before calling doesn't really seem like that much of
> a hardship to me.  Basically:
> 
> a. It's nicer to have arbitrary-length strings (2-4), but reasonably
> large fixed-length ones aren't awful (1)
> 
> b. It's nicer for hypercall consumers to have a single hypercall with
> consistent semantics (1,4), but having two hypercalls (3) or a single
> one with inconsistent semantics (2) aren't that bad either.
> 
> c. It's nicer for hypervisor maintainers to have a single place to
> support any given bit of functionality (1-3), but having a slightly
> duplicated functionality that only has to be supported in an ABI
> backwards-compatible manner isn't that bad either (4).
> 
> This does seem to me an awful lot like a bike shed. :-)  All of the

This is really past bike shedding - all the bikes shed have been
already built (for all those options).

> options (1-4) seem perfectly fine to me.  FWIW my preferred color
> would probably be 1 because it's the easiest and least inconsistent
> with the current state of things. My least favorite would be 3,
> because although each individual piece of information is only in one
> place, the path to get there is duplicated; both the kernel developer
> and the hypervisor developer are forced to continue to deal with both.
> 


The state is that 1-3 have been Nacked by Andrew, 4 has been
Nacked by Jan. And 5) (the original way) was way way back Nacked
as well.

I believe this conversation is to break a tie-breaker between maintainers.
(See http://www.xenproject.org/governance.html, Refereeing).

That is any of the REST maintainers or Project Leads will override the
Nack/Acks. Granted, Jan, me, and Andrew are exclud

Re: [Xen-devel] [PATCH v2 2/3] xenfb: move xen_rmb to the correct location

[Andrew Cooper]

On 12/04/16 13:57, David Vrabel wrote:
> On 12/04/16 11:43, Wei Liu wrote:
>> It should be placed before first time producer and consumer are used.
> This change isn't necessary and is confusing as this is not what this
> barrier is for.
>
> The barrier needs to be between the load of prod and the load of the
> ring contents (there's even a comment that says this).  This pairs with
> the corresponding write barrier between the store of the ring contents
> and the store of prod (in the other end).

Looking further, this code will compile to multiple reads of the page,
because there is no ACCESS_ONCE().  This code is still vulnerable to
XSA-155.

~Andrew

>
> David
>
>> Signed-off-by: Wei Liu 
>> ---
>> Cc: Stefano Stabellini 
>> Cc: Anthony Perard 
>>
>> Backport candidate to our own tree.
>> ---
>>  hw/display/xenfb.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
>> index 9866dfd..7f4fad7 100644
>> --- a/hw/display/xenfb.c
>> +++ b/hw/display/xenfb.c
>> @@ -775,10 +775,10 @@ static void xenfb_handle_events(struct XenFB *xenfb)
>>  
>>  prod = page->out_prod;
>>  out_cons = page->out_cons;
>> +xen_rmb();
>>  if (prod - out_cons > XENFB_OUT_RING_LEN) {
>>  return;
>>  }
>> -xen_rmb();  /* ensure we see ring contents up to prod */
>>  for (cons = out_cons; cons != prod; cons++) {
>>  union xenfb_out_event *event = &XENFB_OUT_RING_REF(page, cons);
>>  uint8_t type = event->type;
>>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


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

Re: [Xen-devel] [PATCH v4 1/3] libxc: do some retries in xc_cpupool_removecpu() for EBUSY case

[Wei Liu]

On Tue, Apr 12, 2016 at 03:45:06PM +0200, Juergen Gross wrote:
> On 12/04/16 15:02, Olaf Hering wrote:
> > On Thu, Mar 10, Juergen Gross wrote:
> > 
> >> +#define NUM_RMCPU_BUSY_RETRIES 5
> >> +
> >>  int xc_cpupool_removecpu(xc_interface *xch,
> >>   uint32_t poolid,
> >>   int cpu)
> >>  {
> >> +unsigned retries;
> >> +int err;
> >>  DECLARE_SYSCTL;
> >>  
> >>  sysctl.cmd = XEN_SYSCTL_cpupool_op;
> >>  sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_RMCPU;
> >>  sysctl.u.cpupool_op.cpupool_id = poolid;
> >>  sysctl.u.cpupool_op.cpu = (cpu < 0) ? XEN_SYSCTL_CPUPOOL_PAR_ANY : 
> >> cpu;
> >> -return do_sysctl_save(xch, &sysctl);
> >> +for ( retries = 0; retries < NUM_RMCPU_BUSY_RETRIES; retries++ ) {
> >> +err = do_sysctl_save(xch, &sysctl);
> >> +if ( err < 0 && errno == EBUSY )
> >> +sleep(1);
> >> +else
> >> +break;
> >> +}
> >> +return err;
> > 
> > This may fail with gcc-4.8, at least with -Og in 13.1:
> > 
> > [  105s] xc_cpupool.c: In function 'xc_cpupool_removecpu':
> > [  105s] xc_cpupool.c:168:5: error: 'err' may be used uninitialized in this 
> > function [-Werror=maybe-uninitialized]
> > [  105s]  return err;
> > [  105s]  ^
> 
> IMO this is a compiler bug. The compiler could detect easily that err
> can't be uninitialized at the return statement (e.g. via loop
> unrolling).
> 
> I can do a patch, of course. The question is whether I should. :-)
> 

You should -- and document that it is to make buggy compiler happy.
We've done this before.

Wei.

> 
> Juergen

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

Re: [Xen-devel] [PATCH v4 1/3] libxc: do some retries in xc_cpupool_removecpu() for EBUSY case

[Olaf Hering]

On Tue, Apr 12, Juergen Gross wrote:

> IMO this is a compiler bug. The compiler could detect easily that err
> can't be uninitialized at the return statement (e.g. via loop
> unrolling).

There is another place like that in blktap2. There was some discussion
about -Og usage in tools, not sure if it will replace -O0 one day.
I will send a patch to fix both cases so that xen is prepared for such
switch.

Olaf

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

Re: [Xen-devel] [PATCH v4 1/3] libxc: do some retries in xc_cpupool_removecpu() for EBUSY case

[Juergen Gross]

On 12/04/16 15:02, Olaf Hering wrote:
> On Thu, Mar 10, Juergen Gross wrote:
> 
>> +#define NUM_RMCPU_BUSY_RETRIES 5
>> +
>>  int xc_cpupool_removecpu(xc_interface *xch,
>>   uint32_t poolid,
>>   int cpu)
>>  {
>> +unsigned retries;
>> +int err;
>>  DECLARE_SYSCTL;
>>  
>>  sysctl.cmd = XEN_SYSCTL_cpupool_op;
>>  sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_RMCPU;
>>  sysctl.u.cpupool_op.cpupool_id = poolid;
>>  sysctl.u.cpupool_op.cpu = (cpu < 0) ? XEN_SYSCTL_CPUPOOL_PAR_ANY : cpu;
>> -return do_sysctl_save(xch, &sysctl);
>> +for ( retries = 0; retries < NUM_RMCPU_BUSY_RETRIES; retries++ ) {
>> +err = do_sysctl_save(xch, &sysctl);
>> +if ( err < 0 && errno == EBUSY )
>> +sleep(1);
>> +else
>> +break;
>> +}
>> +return err;
> 
> This may fail with gcc-4.8, at least with -Og in 13.1:
> 
> [  105s] xc_cpupool.c: In function 'xc_cpupool_removecpu':
> [  105s] xc_cpupool.c:168:5: error: 'err' may be used uninitialized in this 
> function [-Werror=maybe-uninitialized]
> [  105s]  return err;
> [  105s]  ^

IMO this is a compiler bug. The compiler could detect easily that err
can't be uninitialized at the return statement (e.g. via loop
unrolling).

I can do a patch, of course. The question is whether I should. :-)


Juergen

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

Re: [Xen-devel] xenpm and scheduler

[Konrad Rzeszutek Wilk]

On Tue, Apr 12, 2016 at 11:50:42AM +, tutu sky wrote:
> Thanks Dario,
> Yeah, I do like playing with xenpm and try understanding relationship between 
> this and scheduler. but i established a xen environment on vmware, but xenpm 
> does not work correctly and even for 'cpufreq', it is silent at all! so it 
> does not let me try to play with :(. I asked this problem before in the user 
> and devel lists both,  but no body answered me. how can i track the problem, 
> from who (I know that power management is out of your maintenance scope)?? 
> (may xenpm have the same problem on a real platform (again) instead of 
> vmware?)
> thanks a lot.

You will have to.

I don't believe VMWare exposes C and P states to guests so therefore
there is no power freqeuency in play.

> regards.
> 
> From: Dario Faggioli 
> Sent: Tuesday, April 12, 2016 8:10 AM
> To: tutu sky; Meng Xu
> Cc: Xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] xenpm and scheduler
> 
> On Tue, 2016-04-12 at 03:52 +, tutu sky wrote:
> > Thanks Xu. I will do as desired about cross messaging.
> >
> > i need it because i exactly want to know that which part of the
> > scheduler's corde (credit), takes effect from this feature. because
> > it is important to me knowing that where would be trade off between
> > idle state and doing load balancing, while cpuidle feature is
> > activated. in other side it's important again for me that what will
> > happen for 'cap; and 'weight' decreasing in a case that one core's
> > frequency is lower than another one in the same socket (actually when
> > cpufreq feature is enable).
> >
> Currently, there is no interaction between the scheduler and the power
> management and frequency scaling layers.
> 
> > Am i clear enough? can you give me an answer or maybe some lines of
> > schedule.c or sched_credit.c's code which i can track them to notice
> > the effect of xenpm on scheduler part of the view?
> >
> If you're saying that, for instance, the CPUs changing frequency can or
> should affect some aspects of the scheduling algorithms (like credits
> burning rate in Credit1 and Credit2, and budget burning rate in RTDS),
> that is an interesting point which may indeed make sense, or at least
> would deserve more investigation.
> 
> But again, right now, there's no line of code to read to understand the
> relationship, as there's no relationship at all.
> 
> If you want to experiment on playing with xenpm, and seeing what effect
> it has on scheduling, that will be very welcome. :-)
> 
> Regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 
86513
 test-amd64-i386-xl-qemut-win7-amd64 20 leak-check/check   fail REGR. vs. 86513
 test-amd64-amd64-xl-qemuu-win7-amd64 20 leak-check/check  fail REGR. vs. 86513

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 90846 pass in 
90979
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 90846 pass in 
90979
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail in 90846 pass in 90979
 test-amd64-amd64-i386-pvgrub  9 debian-di-install  fail in 90846 pass in 90979
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 90846 pass in 90979
 test-armhf-armhf-xl-arndale   6 xen-bootfail pass in 90846
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail pass in 
90846
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail pass in 90846

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

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

version targeted for testing:
 linuxb36eba9b4dd4344ed51b8f644049aeac606ccff2
baseline version:
 linuxd439e869d612dd7a338ac75a4afc3646a5e67370

Last test of basis86513  2016-03-17 21:21:40 Z   25 days
Testing same since89247  2016-04-06 22:15:59 Z5 days4 attempts


People who touched revisions under test:
  Alex Deucher 
  Avery Pennarun 
  Catalin Marinas 
  Chris Bainbridge 
  Emmanuel G

Re: [Xen-devel] [for-4.7 v2 1/5] drivers/pl011: ACPI: The interrupt should always be high level triggered

[Konrad Rzeszutek Wilk]

On Tue, Apr 12, 2016 at 09:00:42AM +0800, Shannon Zhao wrote:
> 
> 
> On 2016/4/11 22:07, Konrad Rzeszutek Wilk wrote:
> > On Mon, Apr 11, 2016 at 02:33:33PM +0100, Julien Grall wrote:
> >> The SPCR does not specify if the interrupt is edge or level triggered.
> >> So the configuration needs to be hardcoded in the code.
> >>
> >> Based on the PL011 TRM (see 2.2.8 in ARM DDI 0183G), the interrupt 
> >> generated
> >> will be active high. Whilst the wording may be interpreted differently,
> >> the SBSA (section 4.3.2 in ARM-DEN-0029 v2.3) states the PL011 is
> >> implemented with a level triggered interrupt.
> >>
> >> So the driver should configure the interrupt as high level triggered.
> >>
> >> Signed-off-by: Julien Grall 
> > 
> > Shannon, Stefano,
> > 
> > Please reply whether you are OK with this patch. Thanks!
> 
> Reviewed-by: Shannon Zhao 

Thanks. applied.

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

Re: [Xen-devel] [PATCHv7] x86/ept: defer the invalidation until the p2m lock is released

[David Vrabel]

On 03/02/16 03:44, Tian, Kevin wrote:
>> From: David Vrabel [mailto:david.vra...@citrix.com]
>> Sent: Tuesday, February 02, 2016 12:27 AM

Looks like I forgot about this patch.

>> It is safe to defer the invalidate until the p2m lock is released
>> except for two cases:
>>
>> 1. When freeing a page table page (since partial translations may be
>>cached).
>> 2. When reclaiming a zero page as part of PoD.
>>
>> For these cases, add p2m_tlb_flush_sync() calls which will immediately
>> perform the invalidate before the page is freed or reclaimed.
>>
>> Signed-off-by: David Vrabel 
> [...]
>> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
>> index c094320..43c7f1b 100644
>> --- a/xen/arch/x86/mm/p2m-ept.c
>> +++ b/xen/arch/x86/mm/p2m-ept.c
>> @@ -263,6 +263,7 @@ static void ept_free_entry(struct p2m_domain *p2m, 
>> ept_entry_t
>> *ept_entry, int l
>>  unmap_domain_page(epte);
>>  }
>>
>> +p2m_tlb_flush_sync(p2m);
>>  p2m_free_ptp(p2m, mfn_to_page(ept_entry->mfn));
>>  }
>>
>> @@ -1095,15 +1096,10 @@ static void __ept_sync_domain(void *info)
>>   */
>>  }
>>
>> -void ept_sync_domain(struct p2m_domain *p2m)
>> +static void ept_sync_domain_prepare(struct p2m_domain *p2m)
>>  {
>>  struct domain *d = p2m->domain;
>>  struct ept_data *ept = &p2m->ept;
>> -/* Only if using EPT and this domain has some VCPUs to dirty. */
>> -if ( !paging_mode_hap(d) || !d->vcpu || !d->vcpu[0] )
>> -return;
>> -
>> -ASSERT(local_irq_is_enabled());
>>
>>  if ( nestedhvm_enabled(d) && !p2m_is_nestedp2m(p2m) )
>>  p2m_flush_nestedp2m(d);
> 
> should we postpone nestedp2m flush similarly, which also incurs 
> on_selected_cpus when holding p2m lock?

Possibly.  I have not looked at the nestedp2m stuff as it wasn't a use
case I cared about.

I think any changes in this area could be done separately.

>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -325,6 +325,25 @@ void p2m_flush_hardware_cached_dirty(struct domain *d)
>>  }
>>  }
>>
>> +/*
>> + * Force a synchronous P2M TLB flush if a deferred flush is pending.
>> + *
>> + * Must be called with the p2m lock held.
>> + */
>> +void p2m_tlb_flush_sync(struct p2m_domain *p2m)
>> +{
>> +if ( p2m->need_flush )
>> +p2m->flush_and_unlock(p2m, 0);
>> +}
>> +
>> +void p2m_tlb_flush_and_unlock(struct p2m_domain *p2m)
>> +{
>> +if ( p2m->need_flush )
>> +p2m->flush_and_unlock(p2m, 1);
>> +else
>> +mm_write_unlock(&p2m->lock);
>> +}
> 
> prefer to move general stuff into this function, then you could just
> keep a flush() callback, e.g.:
> 
> void p2m_tlb_flush_and_unlock(struct p2m_domain *p2m)
> {
> if ( p2m->need_flush )
> {
> p2m->need_flush = 0;
> mm_write_unlock(&p2m->lock);
> p2m->flush(p2m);
> }
> else
> mm_write_unlock(&p2m->lock);
> }
> 
> Same for p2m_tlb_flush_sync.

I'm sure there was a reason why I did it like this but I can't remember.
 Let me try your suggestion.

David


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

Re: [Xen-devel] [PATCH v4 1/3] libxc: do some retries in xc_cpupool_removecpu() for EBUSY case

[Olaf Hering]

On Thu, Mar 10, Juergen Gross wrote:

> +#define NUM_RMCPU_BUSY_RETRIES 5
> +
>  int xc_cpupool_removecpu(xc_interface *xch,
>   uint32_t poolid,
>   int cpu)
>  {
> +unsigned retries;
> +int err;
>  DECLARE_SYSCTL;
>  
>  sysctl.cmd = XEN_SYSCTL_cpupool_op;
>  sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_RMCPU;
>  sysctl.u.cpupool_op.cpupool_id = poolid;
>  sysctl.u.cpupool_op.cpu = (cpu < 0) ? XEN_SYSCTL_CPUPOOL_PAR_ANY : cpu;
> -return do_sysctl_save(xch, &sysctl);
> +for ( retries = 0; retries < NUM_RMCPU_BUSY_RETRIES; retries++ ) {
> +err = do_sysctl_save(xch, &sysctl);
> +if ( err < 0 && errno == EBUSY )
> +sleep(1);
> +else
> +break;
> +}
> +return err;

This may fail with gcc-4.8, at least with -Og in 13.1:

[  105s] xc_cpupool.c: In function 'xc_cpupool_removecpu':
[  105s] xc_cpupool.c:168:5: error: 'err' may be used uninitialized in this 
function [-Werror=maybe-uninitialized]
[  105s]  return err;
[  105s]  ^


Olaf

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

Re: [Xen-devel] [PATCH v2 2/3] xenfb: move xen_rmb to the correct location

[David Vrabel]

On 12/04/16 11:43, Wei Liu wrote:
> It should be placed before first time producer and consumer are used.

This change isn't necessary and is confusing as this is not what this
barrier is for.

The barrier needs to be between the load of prod and the load of the
ring contents (there's even a comment that says this).  This pairs with
the corresponding write barrier between the store of the ring contents
and the store of prod (in the other end).

David

> 
> Signed-off-by: Wei Liu 
> ---
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> 
> Backport candidate to our own tree.
> ---
>  hw/display/xenfb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> index 9866dfd..7f4fad7 100644
> --- a/hw/display/xenfb.c
> +++ b/hw/display/xenfb.c
> @@ -775,10 +775,10 @@ static void xenfb_handle_events(struct XenFB *xenfb)
>  
>  prod = page->out_prod;
>  out_cons = page->out_cons;
> +xen_rmb();
>  if (prod - out_cons > XENFB_OUT_RING_LEN) {
>  return;
>  }
> -xen_rmb();   /* ensure we see ring contents up to prod */
>  for (cons = out_cons; cons != prod; cons++) {
>   union xenfb_out_event *event = &XENFB_OUT_RING_REF(page, cons);
>  uint8_t type = event->type;
> 


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

Re: [Xen-devel] xenpm and scheduler

[tutu sky]

Thanks Dario,
Yeah, I do like playing with xenpm and try understanding relationship between 
this and scheduler. but i established a xen environment on vmware, but xenpm 
does not work correctly and even for 'cpufreq', it is silent at all! so it does 
not let me try to play with :(. I asked this problem before in the user and 
devel lists both,  but no body answered me. how can i track the problem, from 
who (I know that power management is out of your maintenance scope)?? (may 
xenpm have the same problem on a real platform (again) instead of vmware?)
thanks a lot.
regards.

From: Dario Faggioli 
Sent: Tuesday, April 12, 2016 8:10 AM
To: tutu sky; Meng Xu
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xenpm and scheduler

On Tue, 2016-04-12 at 03:52 +, tutu sky wrote:
> Thanks Xu. I will do as desired about cross messaging.
>
> i need it because i exactly want to know that which part of the
> scheduler's corde (credit), takes effect from this feature. because
> it is important to me knowing that where would be trade off between
> idle state and doing load balancing, while cpuidle feature is
> activated. in other side it's important again for me that what will
> happen for 'cap; and 'weight' decreasing in a case that one core's
> frequency is lower than another one in the same socket (actually when
> cpufreq feature is enable).
>
Currently, there is no interaction between the scheduler and the power
management and frequency scaling layers.

> Am i clear enough? can you give me an answer or maybe some lines of
> schedule.c or sched_credit.c's code which i can track them to notice
> the effect of xenpm on scheduler part of the view?
>
If you're saying that, for instance, the CPUs changing frequency can or
should affect some aspects of the scheduling algorithms (like credits
burning rate in Credit1 and Credit2, and budget burning rate in RTDS),
that is an interesting point which may indeed make sense, or at least
would deserve more investigation.

But again, right now, there's no line of code to read to understand the
relationship, as there's no relationship at all.

If you want to experiment on playing with xenpm, and seeing what effect
it has on scheduling, that will be very welcome. :-)

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


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

[Xen-devel] [PATCH v2 3/3] xenfb: remove out_cons in xenfb_handle_events

[Wei Liu]

The variable out_cons was only used to temporarily hold the consumer
index. Use cons directly to simplify code a bit.

No functional change introduced.

Signed-off-by: Wei Liu 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
---
 hw/display/xenfb.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 7f4fad7..7d50efb 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -770,16 +770,16 @@ static void xenfb_invalidate(void *opaque)
 
 static void xenfb_handle_events(struct XenFB *xenfb)
 {
-uint32_t prod, cons, out_cons;
+uint32_t prod, cons;
 struct xenfb_page *page = xenfb->c.page;
 
 prod = page->out_prod;
-out_cons = page->out_cons;
+cons = page->out_cons;
 xen_rmb();
-if (prod - out_cons > XENFB_OUT_RING_LEN) {
+if (prod - cons > XENFB_OUT_RING_LEN) {
 return;
 }
-for (cons = out_cons; cons != prod; cons++) {
+for ( ; cons != prod; cons++) {
union xenfb_out_event *event = &XENFB_OUT_RING_REF(page, cons);
 uint8_t type = event->type;
int x, y, w, h;
-- 
2.1.4


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

[Xen-devel] [PATCH v2 1/3] xenfb: use the correct condition to avoid excessive looping

[Wei Liu]

In commit ac0487e1 ("xenfb.c: avoid expensive loops when prod <=
out_cons"), ">=" was used. In fact, a full ring is a legit state.
Correct the test to use ">".

Reported-by: "Hao, Xudong" 
Signed-off-by: Wei Liu 
Tested-by: "Hao, Xudong" 
Acked-by: Anthony Perard 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 

Backport candidate to our own tree.
---
 hw/display/xenfb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 40b096a..9866dfd 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -775,7 +775,7 @@ static void xenfb_handle_events(struct XenFB *xenfb)
 
 prod = page->out_prod;
 out_cons = page->out_cons;
-if (prod - out_cons >= XENFB_OUT_RING_LEN) {
+if (prod - out_cons > XENFB_OUT_RING_LEN) {
 return;
 }
 xen_rmb(); /* ensure we see ring contents up to prod */
-- 
2.1.4


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

[Xen-devel] [PATCH v2 2/3] xenfb: move xen_rmb to the correct location

[Wei Liu]

It should be placed before first time producer and consumer are used.

Signed-off-by: Wei Liu 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 

Backport candidate to our own tree.
---
 hw/display/xenfb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 9866dfd..7f4fad7 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -775,10 +775,10 @@ static void xenfb_handle_events(struct XenFB *xenfb)
 
 prod = page->out_prod;
 out_cons = page->out_cons;
+xen_rmb();
 if (prod - out_cons > XENFB_OUT_RING_LEN) {
 return;
 }
-xen_rmb(); /* ensure we see ring contents up to prod */
 for (cons = out_cons; cons != prod; cons++) {
union xenfb_out_event *event = &XENFB_OUT_RING_REF(page, cons);
 uint8_t type = event->type;
-- 
2.1.4


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

[Xen-devel] [PATCH v2 0/3] xenfb bug fixes and cleanup

[Wei Liu]

Wei Liu (3):
  xenfb: use the correct condition to avoid excessive looping
  xenfb: move xen_rmb to the correct location
  xenfb: remove out_cons in xenfb_handle_events

 hw/display/xenfb.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

-- 
2.1.4


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 59254
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail REGR. vs. 59254
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-xl-xsm   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-xl   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
REGR. vs. 59254
 test-amd64-i386-pair   22 guest-migrate/dst_host/src_host fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 59254
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-amd64-amd64-libvirt 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt-xsm 14 guest-saverestorefail blocked in 59254
 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

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

version targeted for testing:
 linuxbf16200689118d19de1b8d2a3c314fc21f5dc7bb
baseline version:
 linux45820c294

[Xen-devel] [linux-3.16 test] 90920: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 
85048

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl  16 guest-start.2  fail in 89328 pass in 90920
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail in 
89328 pass in 90920
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail pass in 
89328

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 89328 blocked in 
85048
 build-i386-rumpuserxen6 xen-buildfail   like 85048
 build-amd64-rumpuserxen   6 xen-buildfail   like 85048
 test-amd64-amd64-xl-credit2  17 guest-localmigrate/x10   fail   like 85048
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 85048
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 85048
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 85048
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 85048
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 85048

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

version targeted for testing:
 linux3a96c6601b6fc47baa6d296f9111ba7be4dad6fc
baseline version:
 linux7f2a8840d127c8d5c59a5d79235e1205aba2e102

Last test of basis85048  2016-03-02 10:56:10 Z   40 days
Testing same since87897  2016-03-29 14:28:05 Z   13 days   12 attempts


People who touched revisions under test:
  Akshay Bhat 
  Al Viro 
  Alex Deucher 
  Alex Williamson 
  Alexander Deuc

Re: [Xen-devel] [PATCH] xen: Filter out MSR write events

[Andrew Cooper]

On 12/04/16 11:17, Razvan Cojocaru wrote:
> On 04/12/2016 12:38 PM, Andrew Cooper wrote:
>> On 12/04/16 05:26, Razvan Cojocaru wrote:
>>> On 04/11/16 22:18, Konrad Rzeszutek Wilk wrote:
 On Mon, Apr 11, 2016 at 07:41:54PM +0300, Razvan Cojocaru wrote:
> This patch only allows introspection-related MSR write events to
> be sent out, improving performance. Should additional events be
> required, they can then simply be added to the list of
> vmx_introspection_force_enabled_msrs[].
>
> Signed-off-by: Razvan Cojocaru 
 Reviewed-by: Konrad Rzeszutek Wilk 

 Thought should there be some .. dynamic mechanism to update
 the MSR list? Or remove entries (or temporarily blacklist
 the built-one ins), etc?
>>> While this should be enough for now (the introspection MSR list is very
>>> small, and we're probably the only consumers), that's indeed the way for
>>> the future, I think. We should have a set-like container of unique
>>> elements that can grow and shrink and can be searched quickly, and add /
>>> remove MSRs we're interested in there.
>>>
>>> The CR write events bitmap approach clearly doesn't work, as there are
>>> too many MSRs to be able to select them all with a bitmap in the future.
>> The current intercept bitmaps have 4x1K bitmaps, a read and a write bit
>> for the low and high MSR indices.
>>
>> For introspection purposes, you will also want a bitmap covering the
>> hypervisor range.  For now, 3x1K bitmaps should be plenty to cover all
>> potentially interesting MSRs.
> I see, so for future reference, add a pointer member allocated with
> alloc_xenheap_page() and memset() to 0 to struct arch_domain, maybe
> named monitor_msrs_bitmap (while removing mov_to_msr_enabled and
> mov_to_msr_extended from struct monitor)? This could get allocated on
> vm_event_init_domain() and de-allocated on vm_event_cleanup_domain().

Looks suitable.

~Andrew

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

Re: [Xen-devel] [PATCH] xen: Filter out MSR write events

[Razvan Cojocaru]

On 04/12/2016 12:38 PM, Andrew Cooper wrote:
> On 12/04/16 05:26, Razvan Cojocaru wrote:
>> On 04/11/16 22:18, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Apr 11, 2016 at 07:41:54PM +0300, Razvan Cojocaru wrote:
 This patch only allows introspection-related MSR write events to
 be sent out, improving performance. Should additional events be
 required, they can then simply be added to the list of
 vmx_introspection_force_enabled_msrs[].

 Signed-off-by: Razvan Cojocaru 
>>> Reviewed-by: Konrad Rzeszutek Wilk 
>>>
>>> Thought should there be some .. dynamic mechanism to update
>>> the MSR list? Or remove entries (or temporarily blacklist
>>> the built-one ins), etc?
>> While this should be enough for now (the introspection MSR list is very
>> small, and we're probably the only consumers), that's indeed the way for
>> the future, I think. We should have a set-like container of unique
>> elements that can grow and shrink and can be searched quickly, and add /
>> remove MSRs we're interested in there.
>>
>> The CR write events bitmap approach clearly doesn't work, as there are
>> too many MSRs to be able to select them all with a bitmap in the future.
> 
> The current intercept bitmaps have 4x1K bitmaps, a read and a write bit
> for the low and high MSR indices.
> 
> For introspection purposes, you will also want a bitmap covering the
> hypervisor range.  For now, 3x1K bitmaps should be plenty to cover all
> potentially interesting MSRs.

I see, so for future reference, add a pointer member allocated with
alloc_xenheap_page() and memset() to 0 to struct arch_domain, maybe
named monitor_msrs_bitmap (while removing mov_to_msr_enabled and
mov_to_msr_extended from struct monitor)? This could get allocated on
vm_event_init_domain() and de-allocated on vm_event_cleanup_domain().


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH 1/2] xenfb: use the correct condition to avoid excessive looping

[Anthony PERARD]

On Tue, Apr 12, 2016 at 10:57:16AM +0100, Wei Liu wrote:
> In commit ac0487e1 ("xenfb.c: avoid expensive loops when prod <=
> out_cons"), ">=" was used. In fact, a full ring is a legit state.
> Correct the test to use ">".
> 
> Reported-by: "Hao, Xudong" 
> Signed-off-by: Wei Liu 
> Tested-by: "Hao, Xudong" 

Acked-by: Anthony PERARD 

> ---
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> 
> Backport candidate to our own tree.
> ---
>  hw/display/xenfb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> index 40b096a..9866dfd 100644
> --- a/hw/display/xenfb.c
> +++ b/hw/display/xenfb.c
> @@ -775,7 +775,7 @@ static void xenfb_handle_events(struct XenFB *xenfb)
>  
>  prod = page->out_prod;
>  out_cons = page->out_cons;
> -if (prod - out_cons >= XENFB_OUT_RING_LEN) {
> +if (prod - out_cons > XENFB_OUT_RING_LEN) {
>  return;
>  }
>  xen_rmb();   /* ensure we see ring contents up to prod */
> -- 
> 2.1.4
> 

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH 2/2] xenfb: remove out_cons in xenfb_handle_events

[Wei Liu]

On Tue, Apr 12, 2016 at 10:59:53AM +0100, Andrew Cooper wrote:
> On 12/04/16 10:57, Wei Liu wrote:
> > The variable out_cons was only used to temporarily hold the consumer
> > index. Use cons directly to simplify code a bit.
> >
> > No functional change introduced.
> >
> > Signed-off-by: Wei Liu 
> > ---
> > Cc: Stefano Stabellini 
> > Cc: Anthony Perard 
> > ---
> >  hw/display/xenfb.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> > index 9866dfd..78a8dcd 100644
> > --- a/hw/display/xenfb.c
> > +++ b/hw/display/xenfb.c
> > @@ -770,16 +770,16 @@ static void xenfb_invalidate(void *opaque)
> >  
> >  static void xenfb_handle_events(struct XenFB *xenfb)
> >  {
> > -uint32_t prod, cons, out_cons;
> > +uint32_t prod, cons;
> >  struct xenfb_page *page = xenfb->c.page;
> >  
> >  prod = page->out_prod;
> > -out_cons = page->out_cons;
> > -if (prod - out_cons > XENFB_OUT_RING_LEN) {
> > +cons = page->out_cons;
> 
> You need the xen_rmb() before the first use of prod or cons.
> 

Good point. I overlooked that.

The change should belong to either previous patch or a new patch though.

Wei.

> ~Andrew
> 
> > +if (prod - cons > XENFB_OUT_RING_LEN) {
> >  return;
> >  }
> >  xen_rmb(); /* ensure we see ring contents up to prod */
> > -for (cons = out_cons; cons != prod; cons++) {
> > +for ( ; cons != prod; cons++) {
> > union xenfb_out_event *event = &XENFB_OUT_RING_REF(page, cons);
> >  uint8_t type = event->type;
> > int x, y, w, h;
> 

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

Re: [Xen-devel] [PATCH 2/2] xenfb: remove out_cons in xenfb_handle_events

[Andrew Cooper]

On 12/04/16 10:57, Wei Liu wrote:
> The variable out_cons was only used to temporarily hold the consumer
> index. Use cons directly to simplify code a bit.
>
> No functional change introduced.
>
> Signed-off-by: Wei Liu 
> ---
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> ---
>  hw/display/xenfb.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> index 9866dfd..78a8dcd 100644
> --- a/hw/display/xenfb.c
> +++ b/hw/display/xenfb.c
> @@ -770,16 +770,16 @@ static void xenfb_invalidate(void *opaque)
>  
>  static void xenfb_handle_events(struct XenFB *xenfb)
>  {
> -uint32_t prod, cons, out_cons;
> +uint32_t prod, cons;
>  struct xenfb_page *page = xenfb->c.page;
>  
>  prod = page->out_prod;
> -out_cons = page->out_cons;
> -if (prod - out_cons > XENFB_OUT_RING_LEN) {
> +cons = page->out_cons;

You need the xen_rmb() before the first use of prod or cons.

~Andrew

> +if (prod - cons > XENFB_OUT_RING_LEN) {
>  return;
>  }
>  xen_rmb();   /* ensure we see ring contents up to prod */
> -for (cons = out_cons; cons != prod; cons++) {
> +for ( ; cons != prod; cons++) {
>   union xenfb_out_event *event = &XENFB_OUT_RING_REF(page, cons);
>  uint8_t type = event->type;
>   int x, y, w, h;


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

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

[George Dunlap]

On Mon, Apr 11, 2016 at 6:46 PM, Jan Beulich  wrote:
[snip]
>> ISTM that the lower duplication (which in principle is an advantage
>> which will be time limited if we are ever able to completely remove
>> teh old hypercall) comes with the cost of (in the long term) increased
>> mess in this particular subop.
>
> We cannot, ever, remove a not toolstack limited hypercall completely
> (or if, then only by Kconfig option so that people knowing none of the
> guests they care about use such deprecated ones).

We need to keep the hypercall around and functioning for ABI
compatibility, but we could at least remove it from the public headers
and point people to using the new one instead.  (Discussion about the
merit of this idea below.)

[snip]
>> ISTM that the lower duplication (which in principle is an advantage
>> which will be time limited if we are ever able to completely remove
>> teh old hypercall) comes with the cost of (in the long term) increased
>> mess in this particular subop.
>>
>> Is that right ?  Obviously this cost is not very significant.  But
>> maybe the duplication isn't that significant either.  I was kind of
>> expecting to find stronger arguments on both sides in this
>> discussion...
>
> If, btw, the cost of having to read the length argument from guest
> memory was deemed undesirable, we'd certainly have the option
> of specifying it to be passed through, say, the high half of the
> current "cmd" parameter.

OK, so here are the options I see:

1. Use the existing hypercall with the existing call semantics for
build-id -- i.e., require the caller to have a large but fixed-length
buffer (maybe 1024 or 2048).

2. Use the existing hypercall but wedge in different calling semantics
for the build-id subop.  We could have just that subop pay attention
to an extra argument as a length, for example, and return an error if
the length is too short.  Or we could make essentially a flag that
asks, "How much space if I were to execute this subop for real?"

3. We could use a new hypercall only for new functionality, with the
proposed new semantics.  This would at minimum be build-id, but
probably also extraversion, compileinfo, changeset, maybe
capabilities_info.

4. Have the new hypercall replace the old hypercall.  The new
hypercall will duplicate all the functionality of the old hypercall.
Deprecate the hypercall for a release or two, then remove it from the
public headers (although keep the code, because we need to maintain
backwards compatibility).

Honestly I still don't quite understand what the problem is with #1 --
if build-id is mainly meant to be a UUID or a hash of the build to
make sure that you're applying the right hotfix (please correct me if
I'm wrong here -- I haven't had time to actually follow the patch
series), 256 bytes should be enough for a properly hashed build, and
2048 should be more than enough.  Requiring the caller to have a
2048-byte buffer before calling doesn't really seem like that much of
a hardship to me.  Basically:

a. It's nicer to have arbitrary-length strings (2-4), but reasonably
large fixed-length ones aren't awful (1)

b. It's nicer for hypercall consumers to have a single hypercall with
consistent semantics (1,4), but having two hypercalls (3) or a single
one with inconsistent semantics (2) aren't that bad either.

c. It's nicer for hypervisor maintainers to have a single place to
support any given bit of functionality (1-3), but having a slightly
duplicated functionality that only has to be supported in an ABI
backwards-compatible manner isn't that bad either (4).

This does seem to me an awful lot like a bike shed. :-)  All of the
options (1-4) seem perfectly fine to me.  FWIW my preferred color
would probably be 1 because it's the easiest and least inconsistent
with the current state of things. My least favorite would be 3,
because although each individual piece of information is only in one
place, the path to get there is duplicated; both the kernel developer
and the hypervisor developer are forced to continue to deal with both.

 -George

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

[Xen-devel] [PATCH 1/2] xenfb: use the correct condition to avoid excessive looping

[Wei Liu]

In commit ac0487e1 ("xenfb.c: avoid expensive loops when prod <=
out_cons"), ">=" was used. In fact, a full ring is a legit state.
Correct the test to use ">".

Reported-by: "Hao, Xudong" 
Signed-off-by: Wei Liu 
Tested-by: "Hao, Xudong" 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 

Backport candidate to our own tree.
---
 hw/display/xenfb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 40b096a..9866dfd 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -775,7 +775,7 @@ static void xenfb_handle_events(struct XenFB *xenfb)
 
 prod = page->out_prod;
 out_cons = page->out_cons;
-if (prod - out_cons >= XENFB_OUT_RING_LEN) {
+if (prod - out_cons > XENFB_OUT_RING_LEN) {
 return;
 }
 xen_rmb(); /* ensure we see ring contents up to prod */
-- 
2.1.4


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

[Xen-devel] [PATCH 2/2] xenfb: remove out_cons in xenfb_handle_events

[Wei Liu]

The variable out_cons was only used to temporarily hold the consumer
index. Use cons directly to simplify code a bit.

No functional change introduced.

Signed-off-by: Wei Liu 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
---
 hw/display/xenfb.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 9866dfd..78a8dcd 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -770,16 +770,16 @@ static void xenfb_invalidate(void *opaque)
 
 static void xenfb_handle_events(struct XenFB *xenfb)
 {
-uint32_t prod, cons, out_cons;
+uint32_t prod, cons;
 struct xenfb_page *page = xenfb->c.page;
 
 prod = page->out_prod;
-out_cons = page->out_cons;
-if (prod - out_cons > XENFB_OUT_RING_LEN) {
+cons = page->out_cons;
+if (prod - cons > XENFB_OUT_RING_LEN) {
 return;
 }
 xen_rmb(); /* ensure we see ring contents up to prod */
-for (cons = out_cons; cons != prod; cons++) {
+for ( ; cons != prod; cons++) {
union xenfb_out_event *event = &XENFB_OUT_RING_REF(page, cons);
 uint8_t type = event->type;
int x, y, w, h;
-- 
2.1.4


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

[Xen-devel] [PATCH 0/2] xenfb bug fix and clean up

[Wei Liu]

Wei Liu (2):
  xenfb: use the correct condition to avoid excessive looping
  xenfb: remove out_cons in xenfb_handle_events

 hw/display/xenfb.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

-- 
2.1.4


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

Re: [Xen-devel] Stub domain crash on Xen v4.6.1

[Wei Liu]

On Tue, Apr 12, 2016 at 11:44:16AM +0200, Fanny Dwargee wrote:
> Wei,
> 
> It works now!
> 

Good to know.

> Many, many thanks for your invaluable time.
> 

You're welcome.

> By the way, Do you know when the patch will be included in the stable-4.6
> branch? Maybe will be on time for the 4.6.2 version?
> 
> IMHO is an important patch because of the added security shielding it
> provides (allowing the use of stub domains on some cases).
> 

Yes, it's on my radar. I hope to get it committed to xen-unstable soon.
And then it will need to wait a bit to land in 4.6.2.

Thanks for testing.

Wei.

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

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

[Yu, Zhang]

On 4/12/2016 12:31 AM, Jan Beulich wrote:

On 11.04.16 at 13:14,  wrote:

On 4/9/2016 6:28 AM, Jan Beulich wrote:

On 31.03.16 at 12:53,  wrote:

@@ -168,13 +226,72 @@ static int hvmemul_do_io(
   break;
   case X86EMUL_UNHANDLEABLE:
   {
-struct hvm_ioreq_server *s =
-hvm_select_ioreq_server(curr->domain, &p);
+struct hvm_ioreq_server *s;
+p2m_type_t p2mt;
+
+if ( is_mmio )
+{
+unsigned long gmfn = paddr_to_pfn(addr);
+
+(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
+
+switch ( p2mt )
+{
+case p2m_ioreq_server:
+{
+unsigned long flags;
+
+p2m_get_ioreq_server(currd, &flags, &s);


As the function apparently returns no value right now, please avoid
the indirection on both values you're after - one of the two
(presumably s) can be the function's return value.


Well, current implementation of p2m_get_ioreq_server() has spin_lock/
spin_unlock surrounding the reading of flags and the s, but I believe
we can also use the s as return value.


The use of a lock inside the function has nothing to do with how it
returns values to the caller.



Agree. I'll use s as return value then.


   /* If there is no suitable backing DM, just ignore accesses */
   if ( !s )
   {
-rc = hvm_process_io_intercept(&null_handler, &p);
+switch ( p2mt )
+{
+case p2m_ioreq_server:
+/*
+ * Race conditions may exist when access to a gfn with
+ * p2m_ioreq_server is intercepted by hypervisor, during
+ * which time p2m type of this gfn is recalculated back
+ * to p2m_ram_rw. mem_handler is used to handle this
+ * corner case.
+ */


Now if there is such a race condition, the race could also be with a
page changing first to ram_rw and then immediately further to e.g.
ram_ro. See the earlier comment about assuming the page to be
writable.



Thanks, Jan. After rechecking the code, I suppose the race condition
will not happen. In hvmemul_do_io(), get_gfn_query_unlocked() is used
to peek the p2mt for the gfn, but get_gfn_type_access() is called inside
hvm_hap_nested_page_fault(), and this will guarantee no p2m change shall
occur during the emulation.
Is this understanding correct?


Ah, yes, I think so. So the comment is misleading.



I'll remove the comment, together with the p2m_ram_rw case. Thanks. :)


+static int hvm_map_mem_type_to_ioreq_server(struct domain *d,
+ioservid_t id,
+hvmmem_type_t type,
+uint32_t flags)
+{
+struct hvm_ioreq_server *s;
+int rc;
+
+/* For now, only HVMMEM_ioreq_server is supported */
+if ( type != HVMMEM_ioreq_server )
+return -EINVAL;
+
+if ( flags & ~(HVMOP_IOREQ_MEM_ACCESS_READ |
+   HVMOP_IOREQ_MEM_ACCESS_WRITE) )
+return -EINVAL;
+
+spin_lock(&d->arch.hvm_domain.ioreq_server.lock);
+
+rc = -ENOENT;
+list_for_each_entry ( s,
+  &d->arch.hvm_domain.ioreq_server.list,
+  list_entry )
+{
+if ( s == d->arch.hvm_domain.default_ioreq_server )
+continue;
+
+if ( s->id == id )
+{
+rc = p2m_set_ioreq_server(d, flags, s);
+if ( rc == 0 )
+gdprintk(XENLOG_DEBUG, "%u %s type HVMMEM_ioreq_server.\n",
+ s->id, (flags != 0) ? "mapped to" : "unmapped from");


Why gdprintk()? I don't think the current domain is of much
interest here. What would be of interest is the subject domain.



s->id is not the domain_id, but id of the ioreq server.


That's understood. But gdprintk() itself logs the current domain,
which isn't as useful as the subject one.



Oh, I see. So the correct routine here should be dprintk(), right?


--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -132,6 +132,19 @@ static void ept_p2m_type_to_flags(struct p2m_domain
*p2m, ept_entry_t *entry,
   entry->r = entry->w = entry->x = 1;
   entry->a = entry->d = !!cpu_has_vmx_ept_ad;
   break;
+case p2m_ioreq_server:
+entry->r = !(p2m->ioreq.flags & P2M_IOREQ_HANDLE_READ_ACCESS);
+   /*
+* write access right is disabled when entry->r is 0, but whether
+* write accesses are emulated by hypervisor or forwarded to an
+* ioreq server depends on the setting of p2m->ioreq.flags.
+*/
+entry->w = (entry->r &&
+!(p2m->ioreq.flags & P2M_IOREQ_HANDLE_WRITE_ACCESS));
+entry->x = entry->r;


Why would we want to allow instruction execution from such pages?
And with all three bits now possibly being clear, aren'

Re: [Xen-devel] Stub domain crash on Xen v4.6.1

[Fanny Dwargee]

Wei,

It works now!

Many, many thanks for your invaluable time.

By the way, Do you know when the patch will be included in the stable-4.6
branch? Maybe will be on time for the 4.6.2 version?

IMHO is an important patch because of the added security shielding it
provides (allowing the use of stub domains on some cases).

Best regards,

Fanny

2016-04-12 10:36 GMT+02:00 Wei Liu :

> On Tue, Apr 05, 2016 at 05:17:00PM +0200, Fanny Dwargee wrote:
>
> (d21) read error -1 on /local/domain/21/device/vbd/768 at offset 0, num
> bytes 512
> (XEN) grant_table.c:525:d0v0 Bad flags (0) or dom (0). (expected dom 0)
> (d21) read error -1 on /local/domain/21/device/vbd/768 at offset 0, num
> bytes 512
> (XEN) grant_table.c:525:d0v0 Bad flags (0) or dom (0). (expected dom 0)
>
> This reminds me of a bug that would cause error in disk:
>
> http://lists.xen.org/archives/html/minios-devel/2016-04/msg0.html
>
> Are you able to apply the patch in that thread and test?
>
> For your convenience I've attached the patch. It needs to be applied to
> xen.git/extras/mini-os.
>
> ---8<---
> From c519e3dfcdbc1edeac994dfa3918c175aae44983 Mon Sep 17 00:00:00 2001
> From: Samuel Thibault 
> Date: Fri, 1 Apr 2016 20:17:01 +0200
> Subject: [PATCH] Mini-OS: netfront: fix off-by-one error introduced in
>  7c8f3483
>
> 7c8f3483 introduced a break within a loop in netfront.c such that
> cons and nr_consumed were no longer always being incremented. The
> offset at cons will be processed multiple times with the break in
> place.
>
> This commit reverts to using the "some" variable in the loop condition,
> but avoids ifdefs for the non-libc case. It also renames it to dobreak
> to make its usage clearer.
>
> Signed-off-by: Samuel Thibault 
> Tested-by: Sarah Newman 
> ---
>  netfront.c | 20 ++--
>  1 file changed, 6 insertions(+), 14 deletions(-)
>
> diff --git a/netfront.c b/netfront.c
> index 0eca5b5..b8fac62 100644
> --- a/netfront.c
> +++ b/netfront.c
> @@ -97,19 +97,15 @@ void network_rx(struct netfront_dev *dev)
>  {
>  RING_IDX rp,cons,req_prod;
>  int nr_consumed, more, i, notify;
> -#ifdef HAVE_LIBC
> -int some;
> -#endif
> +int dobreak;
>
>  nr_consumed = 0;
>  moretodo:
>  rp = dev->rx.sring->rsp_prod;
>  rmb(); /* Ensure we see queued responses up to 'rp'. */
>
> -#ifdef HAVE_LIBC
> -some = 0;
> -#endif
> -for (cons = dev->rx.rsp_cons; cons != rp; nr_consumed++, cons++)
> +dobreak = 0;
> +for (cons = dev->rx.rsp_cons; cons != rp && !dobreak; nr_consumed++,
> cons++)
>  {
>  struct net_buffer* buf;
>  unsigned char* page;
> @@ -134,8 +130,8 @@ moretodo:
> len = dev->len;
> memcpy(dev->data, page+rx->offset, len);
> dev->rlen = len;
> -   some = 1;
> -break;
> +   /* No need to receive the rest for now */
> +   dobreak = 1;
> } else
>  #endif
> dev->netif_rx(page+rx->offset,rx->status);
> @@ -144,11 +140,7 @@ moretodo:
>  dev->rx.rsp_cons=cons;
>
>  RING_FINAL_CHECK_FOR_RESPONSES(&dev->rx,more);
> -#ifdef HAVE_LIBC
> -if(more && !some) goto moretodo;
> -#else
> -if(more) goto moretodo;
> -#endif
> +if(more && !dobreak) goto moretodo;
>
>  req_prod = dev->rx.req_prod_pvt;
>
> --
> 2.1.4
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: Filter out MSR write events

[Andrew Cooper]

On 12/04/16 05:26, Razvan Cojocaru wrote:
> On 04/11/16 22:18, Konrad Rzeszutek Wilk wrote:
>> On Mon, Apr 11, 2016 at 07:41:54PM +0300, Razvan Cojocaru wrote:
>>> This patch only allows introspection-related MSR write events to
>>> be sent out, improving performance. Should additional events be
>>> required, they can then simply be added to the list of
>>> vmx_introspection_force_enabled_msrs[].
>>>
>>> Signed-off-by: Razvan Cojocaru 
>> Reviewed-by: Konrad Rzeszutek Wilk 
>>
>> Thought should there be some .. dynamic mechanism to update
>> the MSR list? Or remove entries (or temporarily blacklist
>> the built-one ins), etc?
> While this should be enough for now (the introspection MSR list is very
> small, and we're probably the only consumers), that's indeed the way for
> the future, I think. We should have a set-like container of unique
> elements that can grow and shrink and can be searched quickly, and add /
> remove MSRs we're interested in there.
>
> The CR write events bitmap approach clearly doesn't work, as there are
> too many MSRs to be able to select them all with a bitmap in the future.

The current intercept bitmaps have 4x1K bitmaps, a read and a write bit
for the low and high MSR indices.

For introspection purposes, you will also want a bitmap covering the
hypervisor range.  For now, 3x1K bitmaps should be plenty to cover all
potentially interesting MSRs.

~Andrew

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

Re: [Xen-devel] [PATCH v7.2 07/24] x86/mm: Introduce modify_xen_mappings()

[Andrew Cooper]

On 11/04/16 18:54, Jan Beulich wrote:
 On 11.04.16 at 19:46,  wrote:
>> To simply change the permissions on existing Xen mappings.  The existing
>> destroy_xen_mappings() is altered to support a change the PTE permissions.
>>
>> A new destroy_xen_mappings() is introduced, as the special case of not 
>> passing
>> _PAGE_PRESENT to modify_xen_mappings().
>>
>> As cleanup (and an ideal functional test), the boot logic which remaps Xen's
>> code and data with reduced permissions is altered to use
>> modify_xen_mappings(), rather than map_pages_to_xen() passing the same mfn's
>> back in.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 
> with one remark:
>
>> -/* If we are done with the L2E, check if it is now empty. */
>> -if ( (v != e) && (l1_table_offset(v) != 0) )
>> +/*
>> + * If we not destroying mappings, or are not done with the L2E,
>> + * skip the empty&free check.
>> + */
>> +if ( (nf & _PAGE_PRESENT) || ((v != e) && (l1_table_offset(v) 
>> != 0)) )
> I guess the missing "are" in the two instances of this comment
> can be folded in while committing.

Oops yes.  I did intend an "are" in there.

~Andrew

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

Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

[Haozhong Zhang]

On 04/08/16 09:52, Jan Beulich wrote:
> >>> On 08.04.16 at 07:02,  wrote:
> > On 03/29/16 04:49, Jan Beulich wrote:
> >> >>> On 29.03.16 at 12:10,  wrote:
> >> > On 03/29/16 03:11, Jan Beulich wrote:
> >> >> >>> On 29.03.16 at 10:47,  wrote:
> > [..]
> >> >> > I still cannot find a neat approach to manage guest permissions for
> >> >> > nvdimm pages. A possible one is to use a per-domain bitmap to track
> >> >> > permissions: each bit corresponding to an nvdimm page. The bitmap can
> >> >> > save lots of spaces and even be stored in the normal ram, but
> >> >> > operating it for a large nvdimm range, especially for a contiguous
> >> >> > one, is slower than rangeset.
> >> >> 
> >> >> I don't follow: What would a single bit in that bitmap mean? Any
> >> >> guest may access the page? That surely wouldn't be what we
> >> >> need.
> >> >>
> >> > 
> >> > For a host having a N pages of nvdimm, each domain will have a N bits
> >> > bitmap. If the m'th bit of a domain's bitmap is set, then that domain
> >> > has the permission to access the m'th host nvdimm page.
> >> 
> >> Which will be more overhead as soon as there are enough such
> >> domains in a system.
> >>
> > 
> > Sorry for the late reply.
> > 
> > I think we can make some optimization to reduce the space consumed by
> > the bitmap.
> > 
> > A per-domain bitmap covering the entire host NVDIMM address range is
> > wasteful especially if the actual used ranges are congregated. We may
> > take following ways to reduce its space.
> > 
> > 1) Split the per-domain bitmap into multiple sub-bitmap and each
> >sub-bitmap covers a smaller and contiguous sub host NVDIMM address
> >range. In the beginning, no sub-bitmap is allocated for the
> >domain. If the access permission to a host NVDIMM page in a sub
> >host address range is added to a domain, only the sub-bitmap for
> >that address range is allocated for the domain. If access
> >permissions to all host NVDIMM pages in a sub range are removed
> >from a domain, the corresponding sub-bitmap can be freed.
> > 
> > 2) If a domain has access permissions to all host NVDIMM pages in a
> >sub range, the corresponding sub-bitmap will be replaced by a range
> >struct. If range structs are used to track adjacent ranges, they
> >will be merged into one range struct. If access permissions to some
> >pages in that sub range are removed from a domain, the range struct
> >should be converted back to bitmap segment(s).
> > 
> > 3) Because there might be lots of above bitmap segments and range
> >structs per-domain, we can organize them in a balanced interval
> >tree to quickly search/add/remove an individual structure.
> > 
> > In the worst case that each sub range has non-contiguous pages
> > assigned to a domain, above solution will use all sub-bitmaps and
> > consume more space than a single bitmap because of the extra space for
> > organization. I assume that the sysadmin should be responsible to
> > ensure the host nvdimm ranges assigned to each domain as contiguous
> > and congregated as possible in order to avoid the worst case. However,
> > if the worst case does happen, xen hypervisor should refuse to assign
> > nvdimm to guest when it runs out of memory.
> 
> To be honest, this all sounds pretty unconvincing wrt not using
> existing code paths - a lot of special treatment, and hence a lot
> of things that can go (slightly) wrong.
> 

Well, using existing range struct to manage guest access permissions
to nvdimm could consume too much space which could not fit in either
memory or nvdimm. If the above solution looks really error-prone,
perhaps we can still come back to the existing one and restrict the
number of range structs each domain could have for nvdimm
(e.g. reserve one 4K-page per-domain for them) to make it work for
nvdimm, though it may reject nvdimm mapping that is terribly
fragmented.

Haozhong

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

Re: [Xen-devel] Stub domain crash on Xen v4.6.1

[Wei Liu]

On Tue, Apr 05, 2016 at 05:17:00PM +0200, Fanny Dwargee wrote:
> Hi,
> 
> after adding the 'device_model_stubdomain_override = 1' to an otherwise
> fine configuration the domain crashes on start.
> 
> Xen is v4.6.1 compiled from source on Debian Jessie 64bits this way:
> 
>- ./configure --enable-stubdom --enable-githttp
>- make dist-xen
>- make dist-tools
>- make dist-stubdom
>- make install-xen
>- make install-tools
>- make install-stubdom
> 
> As pointed out before the same configuration file without the '
> device_model_stubdomain_override' works flawlessly.
> 
> This is the 'xl list' command output while the domain is starting:
> 
> NameID   Mem VCPUs  State   Time(s)
> Domain-0 0  1022 2 r- 318.3
> win7-sp1-x64-2  20  2048 1 r-   5.5
> win7-sp1-x64-2-dm   2144 1 r-   6.0
> 
> 
> As you can see both domains are started (the stub and the original domain)
> 
> Find attached the domain configuration file, 'xl info' output, 'xl create'
> output and the /var/log/xen/console/hypervisor.log file, notice the grant
> table error on console-hypervisor.log
> 
> I'd very grateful for any help finding the cause of this problem.
> 
> Best regards,
> 
> Fanny


(d21) read error -1 on /local/domain/21/device/vbd/768 at offset 0, num bytes 
512
(XEN) grant_table.c:525:d0v0 Bad flags (0) or dom (0). (expected dom 0)
(d21) read error -1 on /local/domain/21/device/vbd/768 at offset 0, num bytes 
512
(XEN) grant_table.c:525:d0v0 Bad flags (0) or dom (0). (expected dom 0)

This reminds me of a bug that would cause error in disk:

http://lists.xen.org/archives/html/minios-devel/2016-04/msg0.html

Are you able to apply the patch in that thread and test?

For your convenience I've attached the patch. It needs to be applied to
xen.git/extras/mini-os.

---8<---
From c519e3dfcdbc1edeac994dfa3918c175aae44983 Mon Sep 17 00:00:00 2001
From: Samuel Thibault 
Date: Fri, 1 Apr 2016 20:17:01 +0200
Subject: [PATCH] Mini-OS: netfront: fix off-by-one error introduced in
 7c8f3483

7c8f3483 introduced a break within a loop in netfront.c such that
cons and nr_consumed were no longer always being incremented. The
offset at cons will be processed multiple times with the break in
place.

This commit reverts to using the "some" variable in the loop condition,
but avoids ifdefs for the non-libc case. It also renames it to dobreak
to make its usage clearer.

Signed-off-by: Samuel Thibault 
Tested-by: Sarah Newman 
---
 netfront.c | 20 ++--
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/netfront.c b/netfront.c
index 0eca5b5..b8fac62 100644
--- a/netfront.c
+++ b/netfront.c
@@ -97,19 +97,15 @@ void network_rx(struct netfront_dev *dev)
 {
 RING_IDX rp,cons,req_prod;
 int nr_consumed, more, i, notify;
-#ifdef HAVE_LIBC
-int some;
-#endif
+int dobreak;
 
 nr_consumed = 0;
 moretodo:
 rp = dev->rx.sring->rsp_prod;
 rmb(); /* Ensure we see queued responses up to 'rp'. */
 
-#ifdef HAVE_LIBC
-some = 0;
-#endif
-for (cons = dev->rx.rsp_cons; cons != rp; nr_consumed++, cons++)
+dobreak = 0;
+for (cons = dev->rx.rsp_cons; cons != rp && !dobreak; nr_consumed++, 
cons++)
 {
 struct net_buffer* buf;
 unsigned char* page;
@@ -134,8 +130,8 @@ moretodo:
len = dev->len;
memcpy(dev->data, page+rx->offset, len);
dev->rlen = len;
-   some = 1;
-break;
+   /* No need to receive the rest for now */
+   dobreak = 1;
} else
 #endif
dev->netif_rx(page+rx->offset,rx->status);
@@ -144,11 +140,7 @@ moretodo:
 dev->rx.rsp_cons=cons;
 
 RING_FINAL_CHECK_FOR_RESPONSES(&dev->rx,more);
-#ifdef HAVE_LIBC
-if(more && !some) goto moretodo;
-#else
-if(more) goto moretodo;
-#endif
+if(more && !dobreak) goto moretodo;
 
 req_prod = dev->rx.req_prod_pvt;
 
-- 
2.1.4


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