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

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

On Tue, Apr 12, 2016 at 5:45 PM, Konrad Rzeszutek Wilk
 wrote:
> 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?
>

I'm not sure if it's reported as a bug somewhere or not.

I've always assumed that INTx is deperecated and vector callbacks are the one
that's supported that's why I never tried to fix it, in addition I never tried
to reproduce it I just looked at the code and it seemed a little bit off as
explained below.

Mainly xenbus_init is called during postcore_initcall which will eventually try
to read a value from XenStore and will get stuck on read_reply at xenbus
forever since the platform driver is not probed yet and its INTx interrupt
handler is not registered yet which basically means that the guest can not be
notified at this moment of any pending event channels and none of the per-event
handlers will ever be invoked (including the XenStore one) and the reply will
never be picked up by the kernel.

The exact stack where things get stuck during xenbus_init:

-xenbus_init
 -xs_init
  -xs_reset_watches
   -xenbus_scanf
-xenbus_read
 -xs_single
  -xs_single
   -xs_talkv

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



-- 
Karim Allah Ahmed.

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

[Xen-devel] [distros-debian-squeeze test] 44327: tolerable trouble: blocked/broken

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-armhf-pvops 3 host-install(3)  broken like 44277
 build-armhf   3 host-install(3)  broken like 44277
 build-i386-pvops  3 host-install(3)  broken like 44277
 build-i3863 host-install(3)  broken like 44277
 build-amd64   3 host-install(3)  broken like 44277
 build-amd64-pvops 3 host-install(3)  broken like 44277

Tests which did not succeed, but are not blocking:
 test-amd64-i386-amd64-squeeze-netboot-pygrub  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-squeeze-netboot-pygrub  1 build-check(1)blocked n/a
 test-amd64-amd64-i386-squeeze-netboot-pygrub  1 build-check(1) blocked n/a
 test-amd64-i386-i386-squeeze-netboot-pygrub  1 build-check(1)  blocked n/a

baseline version:
 flight   44277

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-squeeze-netboot-pygrubblocked 
 test-amd64-i386-amd64-squeeze-netboot-pygrub blocked 
 test-amd64-amd64-i386-squeeze-netboot-pygrub blocked 
 test-amd64-i386-i386-squeeze-netboot-pygrub  blocked 



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

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

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


Push not applicable.


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

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

[Wu, Bob]

From: karim.allah.ah...@gmail.com [mailto:karim.allah.ah...@gmail.com] 
Sent: 2016年4月13日 15:00
To: Konrad Rzeszutek Wilk
Cc: Wu, Bob; xen-de...@lists.xenproject.org
Subject: Re: [Xen-devel] Question about the XEN platform pci

On Tue, Apr 12, 2016 at 5:45 PM, Konrad Rzeszutek Wilk  
wrote:
> 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?
>

I'm not sure if it's reported as a bug somewhere or not.

I've always assumed that INTx is deperecated and vector callbacks are the one 
that's supported that's why I never tried to fix it, in addition I never tried 
to reproduce it I just looked at the code and it seemed a little bit off as 
explained below.

Mainly xenbus_init is called during postcore_initcall which will eventually try 
to read a value from XenStore and will get stuck on read_reply at xenbus 
forever since the platform driver is not probed yet and its INTx interrupt 
handler is not registered yet which basically means that the guest can not be 
notified at this moment of any pending event channels and none of the per-event 
handlers will ever be invoked (including the XenStore one) and the reply will 
never be picked up by the kernel.

The exact stack where things get stuck during xenbus_init:

-xenbus_init
 -xs_init
  -xs_reset_watches
   -xenbus_scanf
-xenbus_read
 -xs_single
  -xs_single
   -xs_talkv

> 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).
>>
>> >>
>> >> -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
>> >> >

Hi, Karim,

I still have one more question, can you share your understanding?
The PCI platform driver just register a pci driver on pci bus, but when the 
real device attaching occur?
I mean who trigger the real device attach behavior? The QEMU or others? I there 
any piece of code can indicate it?

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

[Xen-devel] [linux-mingo-tip-master test] 91071: regressions - FAIL

[osstest service owner]

flight 91071 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/91071/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail REGR. vs. 60684
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 60684
 test-amd64-amd64-libvirt 15 guest-saverestore.2   fail REGR. vs. 60684
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2   fail REGR. vs. 60684
 test-amd64-amd64-pair23 guest-stop/src_host   fail REGR. vs. 60684
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 17 guest-localmigrate/x10fail REGR. vs. 60684
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-xl   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-xl-xsm   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-i386-pair  22 guest-migrate/dst_host/src_host fail blocked in 60684
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 60684
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail like 
60684
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 60684
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 60684
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 60684

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-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 linux50c1b1de3c700ef5ffc84c3bf86feb4df1b7ebc3
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  244 days
Failing since 60712  2015-08-15 18:33:48 Z  241 days  182 attempts
Testing same since91071  2016-04-12 04:32:11 Z1 days1 attempts

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
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  fail
 test-amd64-i386-xl   fail
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm

Re: [Xen-devel] [PATCH v5 01/14] x86/boot: enumerate documentation for the x86 hardware_subarch

[Ingo Molnar]

* Luis R. Rodriguez  wrote:

> Although hardware_subarch has been in place since the x86 boot
> protocol 2.07 it hasn't been used much. Enumerate current possible
> values to avoid misuses and help with semantics later at boot
> time should this be used further.
> 
> These enums should only ever be used by architecture x86 code,
> and all that code should be well contained and compartamentalized,
> clarify that as well.
> 
> v2: updates documentation further -- be a bit more pedantic about
> annotating care and use of these guys.
> v3: Use s/SOC/SoC and also anntoate that both domU and dom0 are
> both currently supported through the PV boot path.
> 
> Cc: Andy Shevchenko 
> Signed-off-by: Luis R. Rodriguez 
> ---
>  arch/x86/include/uapi/asm/bootparam.h | 37 
> ++-
>  1 file changed, 36 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/include/uapi/asm/bootparam.h 
> b/arch/x86/include/uapi/asm/bootparam.h
> index 329254373479..bf9fea2f4591 100644
> --- a/arch/x86/include/uapi/asm/bootparam.h
> +++ b/arch/x86/include/uapi/asm/bootparam.h
> @@ -157,7 +157,42 @@ struct boot_params {
>   __u8  _pad9[276];   /* 0xeec */
>  } __attribute__((packed));
>  
> -enum {
> +/**
> + * enum x86_hardware_subarch - x86 hardware subarchitecture

Could you add some prominent warning here, like:

> + * WARNING: the 'x86 subarch flag' is only used for legacy hacks, for 
> platform
> + *  features that are not easily enumerated or discoverable. You 
> should
> + *  not ever use this for new features.

Thanks,

Ingo

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

Re: [Xen-devel] xenpm and scheduler

[tutu sky]

Dario, let me try it in real hardware and i'll back reporting here. I know that 
there are some distros which are suitable to be dom0:
http://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen
I think i choose my distro correctly (ubuntu 14.04 LTS) and i can see xen 
related configurations in its .config file.

i thought as same as you but after reading devel lists and people's problem 
with this feature, i noticed maybe using xenpm needs make some modification 
about acpi in dom0's .config file, which leads to kernel building again. I'm 
not sure now and after running my setup on a real hardware, i'll back to report 
here.
those people who encountered problems, used real hardware.

Thanks for discussing.
regards.

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

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 mess

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

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

On Wed, Apr 13, 2016 at 9:28 AM, Wu, Bob  wrote:
>
> From: karim.allah.ah...@gmail.com [mailto:karim.allah.ah...@gmail.com]
> Sent: 2016年4月13日 15:00
> To: Konrad Rzeszutek Wilk
> Cc: Wu, Bob; xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] Question about the XEN platform pci
>
> On Tue, Apr 12, 2016 at 5:45 PM, Konrad Rzeszutek Wilk 
>  wrote:
>> 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?
>>
>
> I'm not sure if it's reported as a bug somewhere or not.
>
> I've always assumed that INTx is deperecated and vector callbacks are the one 
> that's supported that's why I never tried to fix it, in addition I never 
> tried to reproduce it I just looked at the code and it seemed a little bit 
> off as explained below.
>
> Mainly xenbus_init is called during postcore_initcall which will eventually 
> try to read a value from XenStore and will get stuck on read_reply at xenbus 
> forever since the platform driver is not probed yet and its INTx interrupt 
> handler is not registered yet which basically means that the guest can not be 
> notified at this moment of any pending event channels and none of the 
> per-event handlers will ever be invoked (including the XenStore one) and the 
> reply will never be picked up by the kernel.
>
> The exact stack where things get stuck during xenbus_init:
>
> -xenbus_init
>  -xs_init
>   -xs_reset_watches
>-xenbus_scanf
> -xenbus_read
>  -xs_single
>   -xs_single
>-xs_talkv
>
>> 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).
>>>
>>> >>
>>> >> -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
>>> >> >
>
> Hi, Karim,
>
> I still have one more question, can you share your understanding?
> The PCI platform driver just register a pci driver on pci bus, but when the 
> real device attaching occur?
> I mean who trigger the real device attach behavior? The QEMU or others? I 
> there any piece of code can indicate it?

This Xen PCI device is a normal PCI device that's emulated by QEMU
and the kernel will just find it while scanning the PCI bus during the
boot process so the driver will just get probed at some point during
boot = It's not hot-plugged.

(Information about PCI devices can be guessed from scanning the
 host bridge or through ACPI tables)

>
> Thanks,
> Bob



-- 
Karim Allah Ahmed.

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

Re: [Xen-devel] [PATCH v5 07/14] tools/lguest: force disable tboot and apm

[Ingo Molnar]

* Luis R. Rodriguez  wrote:

> The paravirt_enabled() check is going away, the area tossed to
> the kernel on lguest is not zerored out, so ensure lguest force
> disables tboot and apm just in case the kernel file being read might
> have this set for whatever reason.
> 
> Signed-off-by: Luis R. Rodriguez 
> ---
>  tools/lguest/lguest.c | 6 ++
>  1 file changed, 6 insertions(+)

Yeah, so the v4 patch was acked by Rusty:

  Acked-by: Rusty Russell 

... but you didn't add his ack to the v5 patch :-(

Please don't do this! Also please double check all past replies to make sure no 
acks got lost. I noticed this one, but there might be more.

Thanks,

Ingo

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

Re: [Xen-devel] [PATCH v5 0/6] Support calling functions on dedicated physical cpu

[Juergen Gross]

On 06/04/16 16:17, Juergen Gross wrote:
> Some hardware (e.g. Dell Studio laptops) require special functions to
> be called on physical cpu 0 in order to avoid occasional hangs. When
> running as dom0 under Xen this could be achieved only via special boot
> parameters (vcpu pinning) limiting the hypervisor in it's scheduling
> decisions.
> 
> This patch series is adding a generic function to be able to temporarily
> pin a (virtual) cpu to a dedicated physical cpu for executing above
> mentioned functions on that specific cpu. The drivers (dcdbas and i8k)
> requiring this functionality are modified accordingly.
> 
> Changes in V5:
> - patch 3: rename and reshuffle parameters of smp_call_on_cpu() as requested
>   by Peter Zijlstra
> - patch 3: test target cpu to be online as requested by Peter Zijlstra
> - patch 4: less wordy messages as requested by David Vrabel
> 
> Changes in V4:
> - move patches 5 and 6 further up in the series
> - patch 2 (was 5): WARN_ONCE in case platform doesn't support pinning
>   as requested by Peter Zijlstra
> - patch 3 (was 2): change return value in case of illegal cpu as
>   requested by Peter Zijlstra
> - patch 3 (was 2): make pinning of vcpu an option as suggested by
>   Peter Zijlstra
> - patches 5 and 6 (were 3 and 4): add call to get_online_cpus()
> 
> Changes in V3:
> - use get_cpu()/put_cpu() as suggested by David Vrabel
> 
> Changes in V2:
> - instead of manipulating the allowed set of cpus use cpu specific
>   workqueue as requested by Peter Zijlstra
> - add include/linux/hypervisor.h to hide architecture specific stuff
>   from generic kernel code
> 
> Juergen Gross (6):
>   xen: sync xen header
>   virt, sched: add generic vcpu pinning support
>   smp: add function to execute a function synchronously on a cpu
>   xen: add xen_pin_vcpu() to support calling functions on a dedicated
> pcpu
>   dcdbas: make use of smp_call_on_cpu()
>   hwmon: use smp_call_on_cpu() for dell-smm i8k
> 
>  MAINTAINERS   |   1 +
>  arch/x86/include/asm/hypervisor.h |   4 ++
>  arch/x86/kernel/cpu/hypervisor.c  |  11 +
>  arch/x86/xen/enlighten.c  |  40 +++
>  drivers/firmware/dcdbas.c |  51 +--
>  drivers/hwmon/dell-smm-hwmon.c|  35 +++--
>  include/linux/hypervisor.h|  17 +++
>  include/linux/smp.h   |   3 ++
>  include/xen/interface/sched.h | 100 
> +++---
>  kernel/smp.c  |  51 +++
>  kernel/up.c   |  18 +++
>  11 files changed, 273 insertions(+), 58 deletions(-)
>  create mode 100644 include/linux/hypervisor.h
> 

So patches 1, 3 and 4 are acked. Any comments regarding patches 2, 5
and 6?


Juergen

___
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 8:24 PM, Tamas K Lengyel wrote:



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"
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 breakpoi

[Xen-devel] [PATCH v12 2/2] Scripts to create and delete xen-scsiback nodes in Linux target framework

[Olaf Hering]

Just to make them public, not meant for merging:
The scripts used during development to create a bunch of SCSI devices in
dom0 using the Linux target framework. targetcli3 and rtslib3 is used.

A patch is required for python-rtslib:
http://article.gmane.org/gmane.linux.scsi.target.devel/8146

These scripts are not use by libxl.
These scripts are meant for testing vscsi= in libxl

Signed-off-by: Olaf Hering 
---
 tools/misc/Makefile  |   4 +
 tools/misc/target-create-xen-scsiback.sh | 135 +++
 tools/misc/target-delete-xen-scsiback.sh |  41 ++
 3 files changed, 180 insertions(+)

diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index a94dad9..035b585 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -36,6 +36,8 @@ INSTALL_SBIN += $(INSTALL_SBIN-y)
 
 # Everything to be installed in a private bin/
 INSTALL_PRIVBIN+= xenpvnetboot
+INSTALL_PRIVBIN+= target-create-xen-scsiback.sh
+INSTALL_PRIVBIN+= target-delete-xen-scsiback.sh
 
 # Everything to be installed
 TARGETS_ALL := $(INSTALL_BIN) $(INSTALL_SBIN) $(INSTALL_PRIVBIN)
@@ -46,6 +48,8 @@ TARGETS_COPY += xen-ringwatch
 TARGETS_COPY += xencons
 TARGETS_COPY += xencov_split
 TARGETS_COPY += xenpvnetboot
+TARGETS_COPY += target-create-xen-scsiback.sh
+TARGETS_COPY += target-delete-xen-scsiback.sh
 
 # Everything which needs to be built
 TARGETS_BUILD := $(filter-out $(TARGETS_COPY),$(TARGETS_ALL))
diff --git a/tools/misc/target-create-xen-scsiback.sh 
b/tools/misc/target-create-xen-scsiback.sh
new file mode 100755
index 000..d014a0a
--- /dev/null
+++ b/tools/misc/target-create-xen-scsiback.sh
@@ -0,0 +1,135 @@
+#!/usr/bin/env bash
+unset LANG
+unset ${!LC_*}
+set -x
+set -e
+
+modprobe --version
+targetcli --version
+udevadm --version
+blockdev --version
+parted --version
+sfdisk --version
+mkswap --version
+
+configfs=/sys/kernel/config
+target_path=$configfs/target
+
+num_luns=4
+num_hosts=4
+
+case "$1" in
+   -p)
+   backend="pvops"
+   ;;
+   -x)
+   backend="xenlinux"
+   ;;
+   *)
+   : "usage: $0 [-p|-x]"
+   if grep -qw xenfs$ /proc/filesystems
+   then
+   backend="pvops"
+   else
+   backend="xenlinux"
+   fi
+   ;;
+esac
+
+get_wwn() {
+   sed '
+   s@-@@g
+   s@^\(.\{16\}\)\(.*\)@\1@
+   ' /proc/sys/kernel/random/uuid
+}
+
+if test ! -d "${target_path}"
+then
+   modprobe -v configfs
+   mount -vt configfs configfs $configfs
+   modprobe -v target_core_mod
+fi
+if test "${backend}" = "pvops"
+then
+   modprobe -v xen-scsiback
+fi
+
+host=0
+while test $host -lt $num_hosts
+do
+   host=$(( $host + 1 ))
+   lun=0
+   loopback_wwn="naa.`get_wwn`"
+   pvscsi_wwn="naa.`get_wwn`"
+   targetcli /loopback create ${loopback_wwn}
+   if test "${backend}" = "pvops"
+   then
+   targetcli /xen-pvscsi create ${pvscsi_wwn}
+   fi
+   while test $lun -lt $num_luns
+   do
+   : h $host l $lun
+   f_file=/dev/shm/Fileio.${host}.${lun}.file
+   f_uuid=/dev/shm/Fileio.${host}.${lun}.uuid
+   f_link=/dev/shm/Fileio.${host}.${lun}.link
+   fileio_name="fio_${host}.${lun}"
+   pscsi_name="ps_${host}.${lun}"
+
+   targetcli /backstores/fileio create name=${fileio_name} 
"file_or_dev=${f_file}" size=$((1024*1024 * 8 )) sparse=true
+   targetcli /loopback/${loopback_wwn}/luns create 
/backstores/fileio/${fileio_name} $lun
+
+   vpd_uuid="`sed -n '/^T10 VPD Unit Serial 
Number:/s@^[^:]\+:[[:blank:]]\+@@p' 
/sys/kernel/config/target/core/fileio_*/${fileio_name}/wwn/vpd_unit_serial`"
+   if test -z "${vpd_uuid}"
+   then
+   exit 1
+   fi
+   echo "${vpd_uuid}" > "${f_uuid}"
+   by_id="`echo ${vpd_uuid} | sed 
's@-@@g;s@^\(.\{25\}\)\(.*\)@scsi-36001405\1@'`"
+   udevadm settle --exit-if-exists="/dev/disk/by-id/${by_id}"
+   ln -sfvbn "/dev/disk/by-id/${by_id}" "${f_link}"
+
+   f_major=$((`stat --dereference --format=0x%t "${f_link}"`))
+   f_minor=$((`stat --dereference --format=0x%T "${f_link}"`))
+   if test -z "${f_major}" || test -z "${f_minor}"
+   then
+   exit 1
+   fi
+   f_alias=`ls -d 
/sys/dev/block/${f_major}:${f_minor}/device/scsi_device/*:*:*:*`
+   if test -z "${f_alias}"
+   then
+   exit 1
+   fi
+   f_alias=${f_alias##*/}
+
+   blockdev --rereadpt "${f_link}"
+   udevadm settle
+   echo 1,96,S | sfdisk "${f_link}"
+   udevadm settle
+   blockdev --rereadpt "${f_link}"
+   udevadm settle
+   parted -s "${f_link}" unit s print
+
+  

[Xen-devel] [PATCH v12 0/2] libxl: add support for pvscsi, iteration 12

[Olaf Hering]

Port vscsi=[] and scsi-{attach,detach,list} commands from xend to libxl.

libvirt uses its existing SCSI support:
http://lists.xenproject.org/archives/html/xen-devel/2015-04/msg02963.html

targetcli/rtslib has to be aware of xen-scsiback (upstream unresponsive):
http://article.gmane.org/gmane.linux.scsi.target.devel/8146

TODO:
 - document pvscsi in xen wiki
 - find a way to carry vscsi devices during live migration to remote host

Changes between v11 and v12:
 - rebase to 'staging' (3dac42f..8b27d2b)
 - rebase to 'staging' (a35dc6c..3dac42f)
 - Rework API of xlu_vscsi_get_ctrl
 - Sanitize input from frontend in vscsi_fill_ctrl
 - Use macro for libxl_ctrl_index

Changes between v10 and v11:
 - rebase to 'staging' (d887c19..a35dc6c)
 - rebase to 'staging' (829e03c..d887c19)
 - Remove evtch and rref from vscsiinfo
 - Remove COMPARE_VSCSI, use COMPARE_DEVID
 - Remove vscsi_wwn_valid helpers, use sscanf instead
http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg01120.html

Changes between v9 and v10:
 - rebase to 'staging' (3b971de..829e03c)
http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg02773.html

Changes between v8 and v9:
 - Mention libxl_ctrl_index in vscsiif.h
 - Rename idx to libxl_ctrl_index
 - Fix device assignment in vscsidev_remove
 - Add vscsictrls to multidev callchain
 - Reorder some functions
 - Move and rename vscsidev_rm
 - Remove libxl prefix from static functions
 - Reorder functions in libxl_vscsi.c
 - Add comment to libxl_vscsidev_aodev_cb
 - Move libxl_device_vscsictrl_remove into libxl_vscsi.c
 - Enclose libxl__device instead of aodev in libxl__vscsidev_rm
 - Update typedef of libxl__vscsidev_rm
 - Assign devid earlier in libxl__device_vscsictrl_add
 - Rework xlu_vscsi_get_ctrl and main_vscsiattach
 - Add config idx also to libxl_vscsiinfo
 - Make libxl__vscsi_collect_ctrls static
 - Implement libxl_device_vscsidev_add
 - Move vscsictrl add from libxl.c to libxl_vscsi.c
 - Export libxl__device_nextid for internal use
 - Remove some checks for empty controllers
 - Introduce an idx file to present the config index in empty vscsictrls
 - Use libxl__ev_devstate_wait in libxl__device_vscsictrl_reconfigure_add
 - Rework error handling in libxl__vscsi_fill_ctrl
 - Remove state checking from libxl__vscsi_fill_dev
 - Wrap long lines in libxl__device_vscsictrl_new_backend
 - Use LIBXL_DESTROY_TIMEOUT in libxl__device_vscsidev_rm
 - Remove tab from libxl__vscsi_collect_ctrls
 - Goto out if libxl__device_vscsidev_backend_set_add fails
 - Add fallthrough to libxl__device_vscsidev_backend_set_add
 - Fix typo in xl.cfg.pod: naa.
 - Wrap long line in xl.cfg.pod.5
 - Use memmove in libxl_device_vscsictrl_remove_vscsidev
 - Adjust code in main_vscsilist to fit in 80 chars
 - Align switch and case to gain 4 columns
 - Wrap long line in libxl__device_vscsi_reconfigure_rm
 - Wrap long line in libxl__device_vscsidev_rm_be
 - Adjust flexarray size in libxl__device_vscsi_reconfigure_rm
 - Rework libxl_device_vscsidev_remove
 - Introduce libxl_device_vscsictrl_remove_vscsidev
 - Use stack variables in xlu_vscsi_get_ctrl
 - Rename function names to refer to vscsictrl
 - Rename local variables to refer to vscsictrl
 - Use generic vscsictrl->devid
http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg03196.html

Changes between v7 and v8:
 - Make be_path const in libxl__device_vscsictrl_add
 - Adjust years in Copyright
 - Whitespace in libxl_device_vscsictrl idl
 - Implement libxl_device_vscsictrl_destroy
 - Set backend_devid
 - Reorder assignments in libxl__device_vscsictrl_add
 - Whitespace changes for libxl__device_vscsi_reconfigure_add
 - Register watch unconditionally in libxl__device_vscsidev_rm
 - Wait for StateClosing for unconnected frontends in detach
 - Adjust logic in libxl__vscsi_fill_dev
 - Rework scsi-detach
 - Increase swap partition from 12 to 96 blocks for mkswap
 - Update MERGE macro for vscsictrls
http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01662.html

Changes between v6 and v7:
 - rebase to 'staging' (3b971de)
 - Introduce libxl_device_vscsictrl_append_vscsidev
 - Add libxl__vscsi_collect_ctrls and used it in libxl_device_vscsictrl_list
 - Convert type of lun from u32 to u64 per SCSI spec
 - Use vscsi_saved in libxl__device_vscsictrl_add
 - Assign unique vscsidev_id per vscsictrl
 - Rename vscsi_dev to vscsidev in function names
 - Rename variables in libxl_vscsiinfo
 - Rename locals to refer to ctrl/dev
 - Rename various strings from host to ctrl
 - Rename local variables vscsi_ctrl to vscsictrl
 - Rename libxl_device_vscsictrl->vscsi_devs to vscsidevs
 - Remove libxl_device_vscsidev->remove, rework detach
 - Rename libxl_device_vscsidev->vscsi_dev_id to vscsidev_id
 - Rename local variables vscsi_host to vscsi_ctrl
 - Rename local variables v_hst to v_ctrl
 - Remove libxl_device_vscsictrl->v_hst
 - Rename libxl_vscsi_dev to libxl_device_vscsidev
 - Rename libxl_device_vscsi to libxl_device_vscsictrl
http://lists.xenproject.org/archives/h

[Xen-devel] [PATCH v12 1/2] libxl: add support for vscsi

[Olaf Hering]

Port pvscsi support from xend to libxl:

 vscsi=['pdev,vdev{,options}']
 xl scsi-attach
 xl scsi-detach
 xl scsi-list

Signed-off-by: Olaf Hering 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 docs/man/xl.cfg.pod.5|   56 ++
 docs/man/xl.pod.1|   18 +
 tools/libxl/Makefile |2 +
 tools/libxl/libxl.c  |9 +
 tools/libxl/libxl.h  |   42 ++
 tools/libxl/libxl_create.c   |   41 +-
 tools/libxl/libxl_device.c   |2 +
 tools/libxl/libxl_internal.h |8 +
 tools/libxl/libxl_types.idl  |   53 ++
 tools/libxl/libxl_types_internal.idl |1 +
 tools/libxl/libxl_vscsi.c| 1169 ++
 tools/libxl/libxlu_vscsi.c   |  667 +++
 tools/libxl/libxlutil.h  |   19 +
 tools/libxl/xl.h |3 +
 tools/libxl/xl_cmdimpl.c |  225 ++-
 tools/libxl/xl_cmdtable.c|   15 +
 16 files changed, 2326 insertions(+), 4 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index a4cc1b3..be4546b 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -517,6 +517,62 @@ value is optional if this is a guest domain.
 
 =back
 
+=item B
+
+Specifies the PVSCSI devices to be provided to the guest. PVSCSI passes
+SCSI devices from the backend domain to the guest.
+
+Each VSCSI_SPEC_STRING consists of "pdev,vdev[,options]".
+'pdev' describes the physical device, preferable in a persistent format
+such as /dev/disk/by-*/*.
+'vdev' is the domU device in vHOST:CHANNEL:TARGET:LUN notation, all integers.
+'options' lists additional flags which a backend may recognize.
+
+The supported values for "pdev" and "options" depends on the backend driver 
used:
+
+=over 4
+
+=item B
+
+=over 4
+
+=item C
+
+The backend driver in the pvops kernel is part of the Linux-IO Target framework
+(LIO). As such the SCSI devices have to be configured first with the tools
+provided by this framework, such as a xen-scsiback aware targetcli. The "pdev"
+in domU.cfg has to refer to a config item in that framework instead of the raw
+device. Usually this is a WWN in the form of "naa.WWN:LUN".
+
+=item C
+
+No options recognized.
+
+=back
+
+=item B
+
+=over 4
+
+=item C
+
+The dom0 device in either /dev/scsidev or pHOST:CHANNEL:TARGET:LUN notation.
+
+It's recommended to use persistent names "/dev/disk/by-*/*" to refer to a 
"pdev".
+The toolstack will translate this internally to "h:c:t:l" notation, which is 
how
+the backend driver will access the device. Using the "h:c:t:l" notation for
+"pdev" in domU.cfg is discouraged because this value will change across 
reboots,
+depending on the detection order in the OS.
+
+=item C
+
+Currently only the option value "feature-host" is recognized. SCSI command
+emulation in backend driver is bypassed when "feature-host" is specified.
+
+=back
+
+=back
+
 =item B
 
 Specifies the paravirtual framebuffer devices which should be supplied
diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index e2bd32d..d3a4a5f 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1416,6 +1416,24 @@ List virtual trusted platform modules for a domain.
 
 =back
 
+=head2 PVSCSI DEVICES
+
+=over 4
+
+=item B I I I,I<[feature-host]>
+
+Creates a new vscsi device in the domain specified by I.
+
+=item B I I
+
+Removes the vscsi device from domain specified by I.
+
+=item B I I<[domain-id] ...>
+
+List vscsi devices for the domain specified by I.
+
+=back
+
 =head1 PCI PASS-THROUGH
 
 =over 4
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 4fc264d..660e6f5 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -108,6 +108,7 @@ endif
 LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
+   libxl_vscsi.o \
libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
libxl_internal.o libxl_utils.o libxl_uuid.o \
libxl_json.o libxl_aoutils.o libxl_numa.o libxl_vnuma.o 
\
@@ -151,6 +152,7 @@ AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h 
_paths.h \
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
+   libxlu_vscsi.o \
libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index d232473..4175edc 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4325,6 +4325,7 @@ DEFINE_DEVICE_REMOVE_CUSTOM(usbctrl, destroy, 1)
 /* The following functions are defined:
  * libxl_device_disk_add
  * libxl_device_nic_add
+ * libxl_device_vscsictrl_add
  * libxl_device_vtpm_add
  * libxl_device_usbctrl_add
  * libxl_device_usbdev_add
@@ -4356,6 +4357,9 @@ DE

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

[Roger Pau Monné]

On Tue, Apr 12, 2016 at 02:02:52PM -0700, Andy Lutomirski wrote:
> 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.

I guess this is a pretty minimal EFI implementation, is this something 
standard, or just an EFI implementation tailored to Linux needs? (ie: is 
there any standard EFI flag to signal this kind of minimal EFI environment?)
 
> 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 :)

With my FreeBSD committer hat:

The FreeBSD kernel doesn't contain an EFI entry point, it just contains one 
single entry point that's used for both legacy BIOS and EFI. Then the 
FreeBSD loader is the one that contains the different entry points. I would 
really like to avoid adding an EFI entry point and the PE header to the 
FreeBSD kernel. The current trampoline in FreeBSD to tie the Xen entry point 
into the native path contains 96 lines of assembly (half of them are 
actually comments) and 66 lines of C. I think adding an EFI entry point is 
going to add a lot more of code than this, and we would probably need 
changes to the build system in order to assembly the PE header and the ELF 
headers together.

IMHO, if we want to boot PVH using EFI the right solution is to use OVMF (or 
any other UEFI firmware) and port it so it's able to run as a PVH guest. I 
guess it should even be possible to use it for Dom0, although I think this 
is cumbersome.

Roger.

___
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?

[George Dunlap]

On Tue, Apr 12, 2016 at 10:31 PM, 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.

I think one of us isn't understanding the situation properly. Is it
not the case that currently, all releases of libvirt *will not
compile* against Xen 4.7 once it's released?  So people downloading
and building libvirt will have to either 1) root around and try to
figure out what version of Xen it will build against, 2) manually add
in a #define *with the correct API version* to a header somewhere to
make it build properly, or 3) update to a version of libvirt that
supports the new api (which at the moment hasn't even been released
yet)?

All of those options are completely unacceptable.  Older versions of
libvirt should Just Work when compiled against newer versions of Xen.

I think it does make sense to have the libvirt development branch not
specify an API version; but when it branches for release, it should
set LIBXL_API_VERSION to whatever the current version is at the time
of the branch.

 -George

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

[Xen-devel] [PATCH libvirt v2 1/2] libxl: include a XLU_Config in _libxlDriverConfig

[Olaf Hering]

Upcoming changes for vscsi will use libxlutil.so to prepare the
configuration for libxl. The helpers needs a xlu struct for logging.
Provide one and reuse the existing output as log target.

Signed-off-by: Olaf Hering 
Cc: Jim Fehlig 
---
 src/libxl/libxl_conf.c | 7 +++
 src/libxl/libxl_conf.h | 7 +++
 2 files changed, 14 insertions(+)

diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index d16280d..f5ef50f 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -93,6 +93,7 @@ libxlDriverConfigDispose(void *obj)
 virObjectUnref(cfg->caps);
 libxl_ctx_free(cfg->ctx);
 xtl_logger_destroy(cfg->logger);
+xlu_cfg_destroy(cfg->xlu);
 if (cfg->logger_file)
 VIR_FORCE_FCLOSE(cfg->logger_file);
 
@@ -1738,6 +1739,12 @@ libxlDriverConfigNew(void)
 goto error;
 }
 
+cfg->xlu = xlu_cfg_init(cfg->logger_file, "libvirt");
+if (!cfg->xlu) {
+VIR_ERROR(_("cannot create xlu for libxenlight, disabling driver"));
+goto error;
+}
+
 if (libxl_ctx_alloc(&cfg->ctx, LIBXL_VERSION, 0, cfg->logger)) {
 VIR_ERROR(_("cannot initialize libxenlight context, probably not "
 "running in a Xen Dom0, disabling driver"));
diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
index 3c0eafb..b069e45 100644
--- a/src/libxl/libxl_conf.h
+++ b/src/libxl/libxl_conf.h
@@ -27,6 +27,12 @@
 # define LIBXL_CONF_H
 
 # include 
+# ifdef HAVE_LIBXLUTIL_H
+#  include 
+# else
+typedef struct XLU_Config XLU_Config;
+XLU_Config *xlu_cfg_init(FILE *report, const char *report_filename);
+# endif
 
 # include "internal.h"
 # include "libvirt_internal.h"
@@ -96,6 +102,7 @@ struct _libxlDriverConfig {
 /* log stream for driver-wide libxl ctx */
 FILE *logger_file;
 xentoollog_logger *logger;
+XLU_Config *xlu;
 /* libxl ctx for driver wide ops; getVersion, getNodeInfo, ... */
 libxl_ctx *ctx;
 

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

[Xen-devel] [PATCH libvirt v2 0/2] libxl: support vscsi

[Olaf Hering]

Add support for upcoming vscsi= in libxl.

Changes between v1 and v2:
 - rebase to 'master' (ad584cb)
 - Update API to v12

Olaf Hering (2):
  libxl: include a XLU_Config in _libxlDriverConfig
  libxl: support vscsi

 src/libxl/libxl_conf.c   |  66 +
 src/libxl/libxl_conf.h   |   8 ++
 src/libxl/libxl_domain.c |   2 +-
 src/libxl/libxl_driver.c | 187 +++
 4 files changed, 262 insertions(+), 1 deletion(-)


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

[Xen-devel] [PATCH libvirt v2 2/2] libxl: support vscsi

[Olaf Hering]

This uses the API version of the proposed vscsi support in libxl (v12):
http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg01772.html

Is there anything else that needs to be done in libvirt? Right now libvirt scsi
support is very simple minded, no support at all to describe host devices with
persistant names. Example used during testing:

 
  
   
   
  
  
  
 

Signed-off-by: Olaf Hering 
Cc: Jim Fehlig 
---
 src/libxl/libxl_conf.c   |  59 +++
 src/libxl/libxl_conf.h   |   1 +
 src/libxl/libxl_domain.c |   2 +-
 src/libxl/libxl_driver.c | 187 +++
 4 files changed, 248 insertions(+), 1 deletion(-)

diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index f5ef50f..1e3615e 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -1915,6 +1915,61 @@ libxlMakePCIList(virDomainDefPtr def, 
libxl_domain_config *d_config)
 }
 
 static int
+libxlMakeVscsiList(libxl_ctx *ctx,
+   XLU_Config *xlu,
+   virDomainDefPtr def,
+   libxl_domain_config *d_config)
+{
+virDomainHostdevDefPtr *l_hostdevs = def->hostdevs;
+size_t i, nhostdevs = def->nhostdevs;
+virDomainHostdevDefPtr hostdev;
+virDomainHostdevSubsysSCSIPtr scsisrc;
+char *str;
+int rc = 0;
+
+if (nhostdevs == 0)
+return 0;
+
+for (i = 0; i < nhostdevs; i++) {
+hostdev = l_hostdevs[i];
+if (hostdev->mode != VIR_DOMAIN_HOSTDEV_MODE_SUBSYS)
+continue;
+if (hostdev->source.subsys.type != VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_SCSI)
+continue;
+scsisrc = &hostdev->source.subsys.u.scsi;
+if (scsisrc->protocol == VIR_DOMAIN_HOSTDEV_SCSI_PROTOCOL_TYPE_ISCSI)
+continue;
+#if defined(LIBXL_HAVE_VSCSI)
+if (virAsprintf(&str, "%s:%u:%u:%u,%u:%u:%u:%llu%s",
+ scsisrc->u.host.adapter + strlen("scsi_host"),
+ scsisrc->u.host.bus,
+ scsisrc->u.host.target,
+ scsisrc->u.host.unit,
+ hostdev->info->addr.drive.controller,
+ hostdev->info->addr.drive.bus,
+ hostdev->info->addr.drive.target,
+ hostdev->info->addr.drive.unit,
+ scsisrc->rawio == VIR_TRISTATE_BOOL_YES ? ",feature-host" 
: "") < 0) {
+goto error;
+};
+rc = xlu_vscsi_config_add(xlu, ctx, str, &d_config->num_vscsictrls, 
&d_config->vscsictrls);
+VIR_FREE(str);
+if (rc)
+goto error;
+#else
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+   _("This version of libxenlight does not support 
vscsi"));
+goto error;
+#endif
+}
+
+return 0;
+
+ error:
+return -1;
+}
+
+static int
 libxlMakeVideo(virDomainDefPtr def, libxl_domain_config *d_config)
 
 {
@@ -2059,6 +2114,7 @@ int
 libxlBuildDomainConfig(virPortAllocatorPtr graphicsports,
virDomainDefPtr def,
libxl_ctx *ctx,
+   XLU_Config *xlu,
libxl_domain_config *d_config)
 {
 libxl_domain_config_init(d_config);
@@ -2084,6 +2140,9 @@ libxlBuildDomainConfig(virPortAllocatorPtr graphicsports,
 if (libxlMakePCIList(def, d_config) < 0)
 return -1;
 
+if (libxlMakeVscsiList(ctx, xlu, def, d_config) < 0)
+return -1;
+
 /*
  * Now that any potential VFBs are defined, update the build info with
  * the data of the primary display. Some day libxl might implicitely do
diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
index b069e45..422c1d6 100644
--- a/src/libxl/libxl_conf.h
+++ b/src/libxl/libxl_conf.h
@@ -218,6 +218,7 @@ int
 libxlBuildDomainConfig(virPortAllocatorPtr graphicsports,
virDomainDefPtr def,
libxl_ctx *ctx,
+   XLU_Config *xlu,
libxl_domain_config *d_config);
 
 static inline void
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index aed904b..02379c9 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -1051,7 +1051,7 @@ libxlDomainStart(libxlDriverPrivatePtr driver, 
virDomainObjPtr vm,
 VIR_FREE(priv->lockState);
 
 if (libxlBuildDomainConfig(driver->reservedGraphicsPorts, vm->def,
-   cfg->ctx, &d_config) < 0)
+   cfg->ctx, cfg->xlu, &d_config) < 0)
 goto cleanup_dom;
 
 if (cfg->autoballoon && libxlDomainFreeMem(cfg->ctx, &d_config) < 0)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index bf97c9c..186f9d4 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -3024,6 +3024,117 @@ libxlDomainAttachHostPCIDevice(libxlDriverPrivatePtr 
driver,
 }
 
 static int
+libxlDomainAttachHostSCSIDevice(libxlDriverPrivatePtr driver,
+   virDomainObj

Re: [Xen-devel] [PATCH libvirt v2 2/2] libxl: support vscsi

[Olaf Hering]

On Wed, Apr 13, Olaf Hering wrote:

>   rawio='yes'>
>   
>
>
>   
>   
>   
>  

What is the virsh equivalent of the following command?

xl scsi-attach domU [5:0:1:0|/dev/sdd|naa.23fd7b9cc41c4934.0] 0:0:0:0


Olaf

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

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

[Daniel P. Berrange]

On Wed, Apr 13, 2016 at 10:09:16AM +0100, George Dunlap wrote:
> On Tue, Apr 12, 2016 at 10:31 PM, 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.
> 
> I think one of us isn't understanding the situation properly. Is it
> not the case that currently, all releases of libvirt *will not
> compile* against Xen 4.7 once it's released?  So people downloading
> and building libvirt will have to either 1) root around and try to
> figure out what version of Xen it will build against, 2) manually add
> in a #define *with the correct API version* to a header somewhere to
> make it build properly, or 3) update to a version of libvirt that
> supports the new api (which at the moment hasn't even been released
> yet)?
> 
> All of those options are completely unacceptable.  Older versions of
> libvirt should Just Work when compiled against newer versions of Xen.
> 
> I think it does make sense to have the libvirt development branch not
> specify an API version; but when it branches for release, it should
> set LIBXL_API_VERSION to whatever the current version is at the time
> of the branch.

FYI, libvirt doesn't do branching for releases - we always just cut the
release straight from the master branch. We only actually create branches
on demand, when we find we want to backport fixes to a previous release.

Does libvirt master really need to always use the latest API version ?

It feels like libvirt could just set LIBXL_API_VERSION to the lowest
version it requires in order to get the functionality we know we are
able to currently build against. IOW, we'd only need to update the
define for LIBXL_API_VERSION when we merge patches that actually need
the newer functionality.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [Xen-devel] [PATCH v2] x86/mm/pat: Fix BUG_ON in mmap_mem on QEMU/i386

[Ingo Molnar]

* Toshi Kani  wrote:

> The following BUG_ON error was reported on QEMU/i386:
> 
>   kernel BUG at arch/x86/mm/physaddr.c:79!
>   Call Trace:
>   phys_mem_access_prot_allowed
>   mmap_mem
>   ? mmap_region
>   mmap_region
>   do_mmap
>   vm_mmap_pgoff
>   SyS_mmap_pgoff
>   do_int80_syscall_32
>   entry_INT80_32
> 
> after commit edfe63ec97ed ("x86/mtrr: Fix Xorg crashes in
> Qemu sessions").
> 
> PAT is now set to disabled state when MTRRs are disabled.
> Thus, reactivating the __pa(high_memory) check in
> phys_mem_access_prot_allowed().
> 
> When CONFIG_DEBUG_VIRTUAL is set, __pa() calls __phys_addr(),
> which in turn calls slow_virt_to_phys() for 'high_memory'.
> Because 'high_memory' is set to (the max direct mapped virt
> addr + 1), it is not a valid virtual address.  Hence,
> slow_virt_to_phys() returns 0 and hit the BUG_ON.  Using
> __pa_nodebug() instead of __pa() will fix this BUG_ON.
> 
> However, this code block, originally written for Pentiums and
> earlier, is no longer adequate since a 32-bit Xen guest has
> MTRRs disabled and supports ZONE_HIGHMEM.  In this setup,
> this code sets UC attribute for accessing RAM in high memory
> range.
> 
> Delete this code block as it has been unused for a long time.
> 
> Reported-by: kernel test robot 
> Link: https://lkml.org/lkml/2016/4/1/608
> Signed-off-by: Toshi Kani 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: H. Peter Anvin 
> Cc: Borislav Petkov 
> Cc: David Vrabel 

So you missed the Reviewed-by tag from Boris ...

I've added it, but please try to propagate tags!

Thanks,

Ingo

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

Re: [Xen-devel] [PATCH v5] xen/arm64: check XSM Magic from the second unknown module.

[Fu Wei]

Hi Julien,

On 8 April 2016 at 22:51, Julien Grall  wrote:
> Hi Fu Wei,
>
> On 05/04/16 17:46, fu@linaro.org wrote:
>>
>> From: Fu Wei 
>>
>> This patch adds a has_xsm_magic helper function for detecting XSM
>> from the second unknown module.
>>
>> If Xen can't get the kind of module from compatible, we guess the kind of
>> these unknowns respectively:
>>  (1) The first unknown must be kernel.
>>  (2) Detect the XSM Magic from the 2nd unknown:
>>  a. If it's XSM, set the kind as XSM, and that also means we
>> won't load ramdisk;
>> b. if it's not XSM, set the kind as ramdisk.
>> So if user want to load ramdisk, it must be the 2nd unknown.
>
>
> The documentation in docs/misc/arm/device-tree/booting.txt needs to be
> update.

Yes, I may forgot this part, but I will make a new doc patch.
Thanks for reminding me

>
> Otherwise, the rest of the patch looks good to me.

Great thanks for your help

>
> Regards,
>
> --
> Julien Grall



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021

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

Re: [Xen-devel] [PATCH v5] xen/arm64: check XSM Magic from the second unknown module.

[Fu Wei]

Hi Julien,

On 8 April 2016 at 23:19, Julien Grall  wrote:
> Hi Wei,
>
> On 08/04/16 15:58, Wei Liu wrote:
>>
>> On Fri, Apr 08, 2016 at 03:51:22PM +0100, Julien Grall wrote:
>>>
>>> Hi Fu Wei,
>>>
>>> On 05/04/16 17:46, fu@linaro.org wrote:

 From: Fu Wei 

 This patch adds a has_xsm_magic helper function for detecting XSM
>>>
>>> >from the second unknown module.


 If Xen can't get the kind of module from compatible, we guess the kind
 of
 these unknowns respectively:
  (1) The first unknown must be kernel.
  (2) Detect the XSM Magic from the 2nd unknown:
  a. If it's XSM, set the kind as XSM, and that also means we
 won't load ramdisk;
 b. if it's not XSM, set the kind as ramdisk.
 So if user want to load ramdisk, it must be the 2nd unknown.
>>>
>>>
>>> The documentation in docs/misc/arm/device-tree/booting.txt needs to be
>>> update.
>>>
>>> Otherwise, the rest of the patch looks good to me.
>>>
>>> Regards,
>>>
>>
>> Is this targeting 4.7? Today is the last day for committing stuff. The
>> doc can come in later.
>
>
> Yes, it's targeting 4.7. Fu Wei, can you send a follow-up for the doc?
>

yes, of course, I will do ASAP.


>>
>> Julien and Daniel's acks are needed here.
>
>
> Acked-by: Julien Grall 
>
> Regards,
>
> --
> Julien Grall



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021

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

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

[Konrad Rzeszutek Wilk]

> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
> index 1fec412..4c96968 100644
> --- a/xen/arch/x86/monitor.c
> +++ b/xen/arch/x86/monitor.c
> @@ -22,6 +22,58 @@
>  #include 
>  #include 
>  
> +static int arch_monitor_enable_msr(struct domain *d, u32 msr)
> +{
> +if ( !d->arch.monitor_msr_bitmap )
> +return -EINVAL;

I this was not set wouldn't we fail in vm_event_enable with -ENOMEM?

I presume the user can still make this hypercall..  Ah yes.

Perhaps -ENXIO?
> +
> +if ( msr <= 0x1fff )
> +set_bit(msr, d->arch.monitor_msr_bitmap + 0x000/BYTES_PER_LONG);

The 0x000/BYTER_PER_LONG looks odd. Is it even needed?

> +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);

And for MSRs above 0xc0001fff it is OK to enable the interception?
Or between 0x1fff and 0xc000?

No need to filter them out? Or error on them?
> +
> +return 0;
> +}
> +
> +static int arch_monitor_disable_msr(struct domain *d, u32 msr)
> +{
> +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 arch_monitor_is_msr_enabled(const struct domain *d, u32 msr)
> +{
> +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);
> +}

And what if msr requested is above 0xc0001fff ? What then?

> +
> +return rc;
> +}
> +
>  int arch_monitor_domctl_event(struct domain *d,
>struct xen_domctl_monitor_op *mop)
>  {
> @@ -77,25 +129,28 @@ int arch_monitor_domctl_event(struct domain *d,
>  
>  case XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR:

Should this be renamed?
>  {
> -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 = arch_monitor_is_msr_enabled(d, msr);
>  
> -domain_pause(d);
> +if ( unlikely(old_status == requested_status) )
> +{
> +domain_unpause(d);
> +return -EEXIST;
> +}
>  
> -if ( requested_status && mop->u.mov_to_msr.extended_capture )
> -ad->monitor.mov_to_msr_extended = 1;
> +if ( requested_status )
> +rc = arch_monitor_enable_msr(d, msr);
>  else
> -ad->monitor.mov_to_msr_extended = 0;
> +rc = arch_monitor_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..9b4267e 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();

How about using vzalloc?
> +
> +if ( !d->arch.monitor_msr_bitmap )
> +return -ENOMEM;
> +
> +memset(d->arch.monitor_msr_bitmap, 0, PAGE_SIZE);

Then you don't have to do that.

> +
>  for_each_vcpu ( d, v )
>  {
>  if ( v->arch.vm_event )
> @@ -55,6 +62,9 @@ void vm_event_cleanup_domain(struct domain *d)
>  v->arch.vm_event = NULL;
>  }
>  
> +free_xenheap_page(d->arch.monitor_msr_bitmap);

And this would be vfree.

> +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));
> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
> index d393ed2..d8d91c2 100644
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -398,12 +398,12 @@ struct arch_domain
>  unsigned int write_ctrlreg_enabled   : 4;
>  unsigned int write_ctrlreg_sync  : 4;
>  unsigned int write_ctrlreg_onchangeonly  : 4;
> - 

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

[George Dunlap]

On 13/04/16 10:26, Daniel P. Berrange wrote:
> On Wed, Apr 13, 2016 at 10:09:16AM +0100, George Dunlap wrote:
>> On Tue, Apr 12, 2016 at 10:31 PM, 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.
>>
>> I think one of us isn't understanding the situation properly. Is it
>> not the case that currently, all releases of libvirt *will not
>> compile* against Xen 4.7 once it's released?  So people downloading
>> and building libvirt will have to either 1) root around and try to
>> figure out what version of Xen it will build against, 2) manually add
>> in a #define *with the correct API version* to a header somewhere to
>> make it build properly, or 3) update to a version of libvirt that
>> supports the new api (which at the moment hasn't even been released
>> yet)?
>>
>> All of those options are completely unacceptable.  Older versions of
>> libvirt should Just Work when compiled against newer versions of Xen.
>>
>> I think it does make sense to have the libvirt development branch not
>> specify an API version; but when it branches for release, it should
>> set LIBXL_API_VERSION to whatever the current version is at the time
>> of the branch.
> 
> FYI, libvirt doesn't do branching for releases - we always just cut the
> release straight from the master branch. We only actually create branches
> on demand, when we find we want to backport fixes to a previous release.
> 
> Does libvirt master really need to always use the latest API version ?
> 
> It feels like libvirt could just set LIBXL_API_VERSION to the lowest
> version it requires in order to get the functionality we know we are
> able to currently build against. IOW, we'd only need to update the
> define for LIBXL_API_VERSION when we merge patches that actually need
> the newer functionality.

Oh, right -- yes, if that's the libvirt development model then it makes
more sense to do what works best with that model to make sure each
release has an appropriate LIBXL_API_VERSION.

On reflection, it's probably a better idea even from a Xen development
perspective.  I was originally thinking that it would be nice to have
the testing automatically flag up an update in libxl that could use a
corresponding update in libvirt.  But in practice, since we use these
tests as a push-gate, having changesets in the xen development branch
which break against libvirt master but require changes in libvirt master
to fix is actually causes a fair amount of hassle.

It might be useful for the XenProject to have a non-pushgate test which
tests libvirt without a LIBXL_API_VERSION, just to flag things up, but
that's something we can sort out on our side with a sed script.

Thanks,
 -George




___
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 Wed, Apr 13, 2016 at 08:21:46AM +, tutu sky wrote:
> Dario, let me try it in real hardware and i'll back reporting here. I know 
> that there are some distros which are suitable to be dom0:
> http://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen
> I think i choose my distro correctly (ubuntu 14.04 LTS) and i can see xen 
> related configurations in its .config file.
> 
> i thought as same as you but after reading devel lists and people's problem 
> with this feature, i noticed maybe using xenpm needs make some modification 
> about acpi in dom0's .config file, which leads to kernel building again. I'm 
> not sure now and after running my setup on a real hardware, i'll back to 
> report here.
> those people who encountered problems, used real hardware.

Right, you may just want to use the distro supplied version of Xen
first.

___
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

[Roger Pau Monné]

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

I'm not following here. What does it mean to fold legacy support under 
HVMlite? HVMlite doesn't have any legacy hardware, and that's the issue when 
it comes to using native Linux entry points. Linux might expect some legacy 
PC hardware to be always present, which is not true for HVMlite.

Could you please clarify this point?

>   * 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).

Classic PV guests don't have legacy hardware at all, they just have PV 
interfaces, so I'm even less sure of what this means.

Roger.

___
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 Wed, Apr 13, 2016 at 09:00:18AM +0200, karim.allah.ah...@gmail.com wrote:
> On Tue, Apr 12, 2016 at 5:45 PM, Konrad Rzeszutek Wilk
>  wrote:
> > 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?
> >
> 
> I'm not sure if it's reported as a bug somewhere or not.
> 
> I've always assumed that INTx is deperecated and vector callbacks are the one
> that's supported that's why I never tried to fix it, in addition I never tried
> to reproduce it I just looked at the code and it seemed a little bit off as
> explained below.
> 
> Mainly xenbus_init is called during postcore_initcall which will eventually 
> try
> to read a value from XenStore and will get stuck on read_reply at xenbus
> forever since the platform driver is not probed yet and its INTx interrupt
> handler is not registered yet which basically means that the guest can not be
> notified at this moment of any pending event channels and none of the 
> per-event
> handlers will ever be invoked (including the XenStore one) and the reply will
> never be picked up by the kernel.

Argh, well that is not good. Also - thanks for reporting this.

No simple ideas come to my mind on how this can be fixed - unless we
move the xenbus_init and its driver past the platform-pci init?

Or if platform-pci init code ends up being called earlier?

> 
> The exact stack where things get stuck during xenbus_init:
> 
> -xenbus_init
>  -xs_init
>   -xs_reset_watches
>-xenbus_scanf
> -xenbus_read
>  -xs_single
>   -xs_single
>-xs_talkv
> 
> > 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
> >>
> >>
>

Re: [Xen-devel] [PATCH v3 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi

[Fu Wei]

Hi all

On 18 March 2016 at 15:53, Fu Wei  wrote:
> Hi all,
>
> On 9 March 2016 at 16:22, Fu Wei  wrote:
>> Hi Julien,
>>
>> On 9 March 2016 at 15:10, Julien Grall  wrote:
>>> Hi,
>>>
>>> On 08/03/2016 23:37, Fu Wei wrote:

 On 8 March 2016 at 14:54, Andrei Borzenkov  wrote:
 So speaking of loading additional modules/lack of initrd on ARM, I thinks
 that
 will (only) affect loading XSM.
 For this, I have discussed of that with Julien, I think :
 (1) the first module must be kernel
 (2) the second module must be initrd, if we have initrd
 (3) Start from the 2nd module, XEN will detect that if the module is a XSM
 by
 the XSM binary signature. if we get XSM as the second module, that
 means we have not initrd.
>>>
>>>
>>> We need to update Xen for point (3). Fu Wei, could you send a patch for
>>> this?
>>
>> Yes, I think I can do that.
>
> I have posted the patch for this:
>
> http://lists.xen.org/archives/html/xen-devel/2016-03/msg02430.html

git log ca32012341f3de7d3975407fb963e6028f0d0c8b
commit ca32012341f3de7d3975407fb963e6028f0d0c8b
Author: Fu Wei 
Date:   Wed Apr 6 00:46:36 2016 +0800

xen/arm64: check XSM Magic from the second unknown module.

This patch adds a has_xsm_magic helper function for detecting XSM
from the second unknown module.

If Xen can't get the kind of module from compatible, we guess the kind of
these unknowns respectively:
(1) The first unknown must be kernel.
(2) Detect the XSM Magic from the 2nd unknown:
a. If it's XSM, set the kind as XSM, and that also means we
won't load ramdisk;
b. if it's not XSM, set the kind as ramdisk.
So if user want to load ramdisk, it must be the 2nd unknown.
We also detect the XSM Magic for the following unknowns, then set its kind
according to the return value of has_xsm_magic.

By this way, arm64 behavior can be compatible to x86 and can simplify
multi-arch bootloader such as GRUB.

Signed-off-by: Fu Wei 
Acked-by: Daniel De Graaf 
Acked-by: Julien Grall 


Since the patch for this has been merged into the staging branch of xen,
Could some one help to review this patch or maybe merge this patchset
into GRUB if that is OK for all of you :-)

>
>>
>>>
 please correct me if I misunderstand it
>>>
>>>
>>> I'm fine with this plan, it matches the x86 behavior.
>>>
>>
>> Great thanks for your review :-)
>>
>>
>>> Cheers,
>>>
>>> --
>>> Julien Grall
>>
>>
>>
>> --
>> Best regards,
>>
>> Fu Wei
>> Software Engineer
>> Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
>> Ph: +86 21 61221326(direct)
>> Ph: +86 186 2020 4684 (mobile)
>> Room 1512, Regus One Corporate Avenue,Level 15,
>> One Corporate Avenue,222 Hubin Road,Huangpu District,
>> Shanghai,China 200021
>
>
>
> --
> Best regards,
>
> Fu Wei
> Software Engineer
> Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
> Ph: +86 21 61221326(direct)
> Ph: +86 186 2020 4684 (mobile)
> Room 1512, Regus One Corporate Avenue,Level 15,
> One Corporate Avenue,222 Hubin Road,Huangpu District,
> Shanghai,China 200021



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021

___
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

[Roger Pau Monné]

On Wed, Apr 06, 2016 at 04:02:40PM +0100, Matt Fleming wrote:
[...]
> One place that struck me as suitable for this "hypercall in an EFI
> service stub" approach is the trouble with doing ACPI reboot as
> documented here,
> 
>   http://lists.xen.org/archives/html/xen-devel/2016-02/msg01609.html
> 
> Performing the reset hypercall from within HVMlite's custom EfiReset()
> service would avoid having to touch ACPICA at all, and would be
> indistinguishable from bare metal.

I don't get this, the "reset/shutdown" hypercall requires the following 
steps from Dom0 (it's not as simple as calling a hypercall):

The way to perform a full system power off from Dom0 is different than 
what's done in a DomU guest. In order to perform a power off from Dom0 the 
native ACPI path should be followed, but the guest should not write the 
`SLP_EN` bit to the Pm1Control register. Instead the 
`XENPF_enter_acpi_sleep` hypercall should be used, filling the following 
data in the `xen_platform_op` struct:

cmd = XENPF_enter_acpi_sleep
interface_version = XENPF_INTERFACE_VERSION
u.enter_acpi_sleep.pm1a_cnt_val = Pm1aControlValue
u.enter_acpi_sleep.pm1b_cnt_val = Pm1bControlValue

At which point it means that we are either going to duplicate ACPICA code 
into the HVMlite's custom EfiReset() service, or we are going to call into 
ACPICA, which is what we already do now.

Roger.

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

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

[Andrew Cooper]

On 13/04/16 10:47, Konrad Rzeszutek Wilk wrote:
>> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
>> index 1fec412..4c96968 100644
>> --- a/xen/arch/x86/monitor.c
>> +++ b/xen/arch/x86/monitor.c
>> @@ -22,6 +22,58 @@
>>  #include 
>>  #include 
>>  
>> +static int arch_monitor_enable_msr(struct domain *d, u32 msr)
>> +{
>> +if ( !d->arch.monitor_msr_bitmap )
>> +return -EINVAL;
> I this was not set wouldn't we fail in vm_event_enable with -ENOMEM?
>
> I presume the user can still make this hypercall..  Ah yes.
>
> Perhaps -ENXIO?
>> +
>> +if ( msr <= 0x1fff )
>> +set_bit(msr, d->arch.monitor_msr_bitmap + 0x000/BYTES_PER_LONG);

(It might help to read the following review before coming back here...)

It might be clearer to express monitor_msr_bitmap as a pointer to

struct monitor_msr_bitmap {
uint8_t low[1024];
uint8_t hypervisor[1024];
uint8_t high[1024];
};

which avoids the odd pointer arithmetic.

> The 0x000/BYTER_PER_LONG looks odd. Is it even needed?
>
>> +else if ( (msr >= 0xc000) && (msr <= 0xc0001fff) )
>> +{
>> +msr &= 0x1fff;
>> +set_bit(msr, d->arch.monitor_msr_bitmap + 0x400/BYTES_PER_LONG);

__set_bit().  I don't think you need a LOCK here.

>> +}
>> +
>> +hvm_enable_msr_interception(d, msr);
> And for MSRs above 0xc0001fff it is OK to enable the interception?
> Or between 0x1fff and 0xc000?

No real MSRs exist outside the [0..1fff] and [0xc000..0xc0001fff]
ranges, so will suffer a #GP.  This is even reflected in how both VT-x
and SVM do their MSR interception bitmap, which is why I specifically
suggested using the same here.

However, this case wants a range between [0x4000..0x40001fff]

>
> No need to filter them out? Or error on them?
>> +
>> +return 0;
>> +}
>> +
>> +static int arch_monitor_disable_msr(struct domain *d, u32 msr)
>> +{
>> +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 arch_monitor_is_msr_enabled(const struct domain *d, u32 msr)
>> +{
>> +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);
>> +}
> And what if msr requested is above 0xc0001fff ? What then?
>
>> +
>> +return rc;
>> +}
>> +
>>  int arch_monitor_domctl_event(struct domain *d,
>>struct xen_domctl_monitor_op *mop)
>>  {
>> @@ -77,25 +129,28 @@ int arch_monitor_domctl_event(struct domain *d,
>>  
>>  case XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR:
> Should this be renamed?
>>  {
>> -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 = arch_monitor_is_msr_enabled(d, msr);
>>  
>> -domain_pause(d);
>> +if ( unlikely(old_status == requested_status) )
>> +{
>> +domain_unpause(d);
>> +return -EEXIST;
>> +}
>>  
>> -if ( requested_status && mop->u.mov_to_msr.extended_capture )
>> -ad->monitor.mov_to_msr_extended = 1;
>> +if ( requested_status )
>> +rc = arch_monitor_enable_msr(d, msr);
>>  else
>> -ad->monitor.mov_to_msr_extended = 0;
>> +rc = arch_monitor_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..9b4267e 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();
> How about using vzalloc?

vmap space is far more limited than general xenheap space.  vmap()
should only be used when you need >4K allocations contiguously in
virtual address space.

>> +
>> +if ( !d->arch.monitor_msr_bitmap )
>> + 

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

[George Dunlap]

On Tue, Apr 12, 2016 at 11:12 PM, Luis R. Rodriguez  wrote:
> 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.

I'm not sure how this is relevant to anything.

What we're talking about is how to get from Xen to a point in the
Linux kernel where everything can Just Work.  The proposed feature is
a mini trampoline that (as I understand it):
1. Tells Xen where to jump to (via ELF note)
2. Sets up some basic modes and pagetables and then jumps to the zero
page so Linux can just carry on.

 -George

___
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

[Matt Fleming]

On Wed, 13 Apr, at 11:02:02AM, Roger Pau Monné wrote:
> 
> With my FreeBSD committer hat:
> 
> The FreeBSD kernel doesn't contain an EFI entry point, it just contains one 
> single entry point that's used for both legacy BIOS and EFI. Then the 
> FreeBSD loader is the one that contains the different entry points. I would 
> really like to avoid adding an EFI entry point and the PE header to the 
> FreeBSD kernel. The current trampoline in FreeBSD to tie the Xen entry point 
> into the native path contains 96 lines of assembly (half of them are 
> actually comments) and 66 lines of C. I think adding an EFI entry point is 
> going to add a lot more of code than this, and we would probably need 
> changes to the build system in order to assembly the PE header and the ELF 
> headers together.
 
What does the boot flow look like for PVH2 on FreeBSD today?
Presumably it doesn't have the same entry point that Boris proposed
for Linux?

Does it go, Hypervisor -> FreeBSD loader -> FreeBSD kernel? Or are you
able to directly boot the kernel from the hypervisor and skip the
middle part by having secondary entry point for Xen marked by the ELF
note?

> IMHO, if we want to boot PVH using EFI the right solution is to use OVMF (or 
> any other UEFI firmware) and port it so it's able to run as a PVH guest. I 
> guess it should even be possible to use it for Dom0, although I think this 
> is cumbersome.

There are two levels of EFI boot entry features being discussed,

 1. Make the OS kernel a PE/COFF executable
 2. Provide some level of EFI service functionality

You can adopt 1. without 2, i.e. without actually providing any EFI
services at all, as long as the Xen hypervisor grows a PE/COFF loader
(since EFI firmware has to provide you one, for EFI platforms you
could use the LoadImage() service in the firmware, but for BIOS
platforms you'd need your own in Xen).

On Linux, this has the advantage of deferring the decompression of the
bzImage (x86 Linux kernel file format) to the stub on the front of the
bzImage. And while I realise that the toolstack already has support
for decompressing bzImages, given what Andrew has said about reducing
attack surface, having the guest perform the decompression should be a
win.

Of course, this is offset somewhat by the fact that you need to audit
the PE/COFF loader ;) But decompression in general is notoriously
vulnerable to security issues.

Using the in-kernel decompressor is how most (all?) Linux boot loaders
work today, so there's the added benefit of reducing the differences
between booting on Xen and booting bare metal. For example, you'd
probably be able to use CONFIG_RANDOMIZE_BASE (ASLR for kernel image)
for Xen if you use the kernel's decompressor. Xen would also get
future features in this area for free, and there is a tendency to push
boot features into the early stub.

For 1. we'd basically be using the PE/COFF file format with the EFI
ABI as an OS agnostic boot protocol, but not as a full firmware
runtime environment.

2. is also interesting, though I think less so than 1. I agree that
making OVMF work as a PVH guest is probably the right way to go, even
for Dom0, not least because you'd have a much cleaner/less buggy
implementation than what we see in the real world ;)

___
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

[Andrew Cooper]

On 13/04/16 09:55, Corneliu ZUZU wrote:
>
>
>>
>>
>> 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 looked at carefully.
>
> That seems to apply to single-stepping only, which would be a
> different matter. As for stealthiness or not limiting the guest, IMO
> that shouldn't be a problem with BKPT/BRK, since I believe you can
> inject the breakpoint exception into the guest as if no hypervisor
> trap occured in between (of course, once you decide whether that
> breakpoint is Xen's or guest-internal). But what about X86? How is
> stealthiness achieved there? Is INT3 entirely not available for the
> guest anymore when guest-debugging is enabled or are ALL INT3's
> reported by Xen as software breakpoint vm-events?

In x86, attaching a debugger to the domain causes #DB and #BP exceptions
to be intercepted by Xen, rather than handled directly by the domain
(actually, since XSA-156, #DB is intercepted under all circumstances, to
avoid security issues).  The debugger receives all debug events, and
should filer the ones it has introduced vs the ones present from
in-guest activities.

~Andrew

(Whether this works or not is a separate matter, and largely depends on
the debugger.)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

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

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 91107
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail in 
89328 pass in 91107
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail pass in 
89328
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat   fail pass in 90920

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 85048
 test-armhf-armhf-xl-rtds 11 guest-start   fail in 90920 like 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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-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-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  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-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-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-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   41 days
Testing same since87897  2016-03-29 14:28:05 Z   14 days   13 attempts


People who touched revisions under test:
  Ak

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

[Matt Fleming]

On Wed, 13 Apr, at 12:03:12PM, Roger Pau Monné wrote:
> 
> I don't get this, the "reset/shutdown" hypercall requires the following 
> steps from Dom0 (it's not as simple as calling a hypercall):
> 
> The way to perform a full system power off from Dom0 is different than 
> what's done in a DomU guest. In order to perform a power off from Dom0 the 
> native ACPI path should be followed, but the guest should not write the 
> `SLP_EN` bit to the Pm1Control register. Instead the 
> `XENPF_enter_acpi_sleep` hypercall should be used, filling the following 
> data in the `xen_platform_op` struct:
> 
> cmd = XENPF_enter_acpi_sleep
> interface_version = XENPF_INTERFACE_VERSION
> u.enter_acpi_sleep.pm1a_cnt_val = Pm1aControlValue
> u.enter_acpi_sleep.pm1b_cnt_val = Pm1bControlValue
> 
> At which point it means that we are either going to duplicate ACPICA code 
> into the HVMlite's custom EfiReset() service, or we are going to call into 
> ACPICA, which is what we already do now.

Fair enough, I wasn't aware that you needed to call into ACPI to
perform the reset.

___
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

[Roger Pau Monné]

On Wed, Apr 13, 2016 at 12:12:25AM +0200, Luis R. Rodriguez wrote:
[...]
> 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.

I don't see how this is relevant to the conversation that's going on:

How many x86 hardware provide DT? I bet this is 0%.

How many OSes can boot on x86 using DT? Linux maybe, certainly FreeBSD, 
Windows or OpenBSD won't be able to boot at all when provided a DT on x86.

Is Xen going to craft a DT for x86 based on ACPI? No, because it can't parse 
the DSDT or other dynamic tables that contain the information about 
the devices in the system.

I would also like to point out that DT or not DT is not really the problem 
here, the issue that George was trying to point out is that on x86 there's 
some legacy hardware that's considered to be always there, so it's presence 
is not signaled by ACPI, and HVMlite is _not_ emulating this hardware. It 
doesn't matter if the hardware description comes from ACPI or DT, this 
hardware is considered to be always present on PC compatible hardware.

Roger.

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

Re: [Xen-devel] xenpm and scheduler

[Dario Faggioli]

On Wed, 2016-04-13 at 08:21 +, tutu sky wrote:
> Dario, let me try it in real hardware and i'll back reporting here. I
> know that there are some distros which are suitable to be dom0:
> http://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen
> I think i choose my distro correctly (ubuntu 14.04 LTS) and i can see
> xen related configurations in its .config file.
> 
I think Ubuntu 14.04 would be fine. If I'd have to choose, I'd use an
even more recent one.

> i thought as same as you but after reading devel lists and people's
> problem with this feature, i noticed maybe using xenpm needs make
> some modification about acpi in dom0's .config file, which leads to
> kernel building again. I'm not sure now and after running my setup on
> a real hardware, i'll back to report here.
> those people who encountered problems, used real hardware.
> 
I don't know what issues you are talking about, and whether they may be
related to Ubuntu 14.04, and/or to the dom0 kernel version shipped with
it.

Again, I'd suggest just going for something "current", no big deal if
it's not LTS. Fedora 23, or a recent OpenSUSE, or Ubuntu 15.10... I'm
pretty sure you'll be able to get a setup on which you can try to use
xenpm quite quickly with any of them.

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



signature.asc
Description: This is a digitally signed message part
___
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

[Matt Fleming]

On Wed, 13 Apr, at 11:15:15AM, Matt Fleming wrote:
> 
> For 1. we'd basically be using the PE/COFF file format with the EFI
> ABI as an OS agnostic boot protocol, but not as a full firmware
> runtime environment.

To add some balance to this proposal (since there's no such thing as a
free lunch) some of the disadvantages are,

The PE/COFF stub in Linux does assume that it is executing in native
cpu mode and does not perform any mode switching, i.e. from 32-bit
protected to long mode. This is due to the way that EFI works - by the
time the OS image entry point is jumped to on a 64-bit cpu we're
running in long mode with identity mapped page tables. To be fair,
when running Xen on EFI (bare metal) this would save you one cpu mode
switch when compared with the current HVMLite proposal.

I'm not aware of a direct equivalent for ELF notes in the PE/COFF
format. I'm still re-reading the spec to find something suitable.

___
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 Corneliu,

On 13/04/16 09:55, Corneliu ZUZU wrote:

On 4/12/2016 8:24 PM, Tamas K Lengyel wrote:
Another issue came to my mind: "HVC #imm", if handled through the
hvm-ops code, currently requires setting other registers to predefined
values before the HVC is actually issued. That would imply additional
effort to save/restore those registers if an external privileged domain
would want to set guest breakpoints. Given that, if we were to use HVC
for sw-bkpts, IMO it would be nice if the hvm-ops code architecture
would be slightly changed such that -lone- "HVM #imm" calls would be
achievable for some use cases, such as this.


That is not true. All the hypercalls are using the same #imm 
(XEN_HYPERCALL_TAG = 0xEA1), which indeed requires specific value in 
various registers to differentiate the HVM-ops.


It's up to us to define the requirements for the other #imm. For 
instance there are some #imm allocated for debugging (see do_debug_trap) 
that will dump the content of the registers.






So what I will do instead of issuing a software_breakpoint vm_event
for SMCs, I'll introduce a new type, say
VM_EVENT_REASON_PRIVILEGED_CALL, that can be used to forward both
hypercalls and SMCs to a monitoring guest. This would also allow us to
use the software_breakpoint type for the actual software breakpoint
events in the future.

Tamas


Isn't the HVC-part already achieved by guest-request vm-events? Maybe
tying this vm-event specifically to SMC (in which case the name could be
something like VM_EVENT_REASON_SECURE_CALL) and thus making it
ARM-specific would avoid that redundancy?


I would create 2 distinct events for HVC and SMC. It would make easier 
to differentiate them in userspace.


Regards,

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

[Corneliu ZUZU]

On 4/13/2016 1:17 PM, Andrew Cooper wrote:

On 13/04/16 09:55, Corneliu ZUZU wrote:






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 looked at carefully.


That seems to apply to single-stepping only, which would be a 
different matter. As for stealthiness or not limiting the guest, IMO 
that shouldn't be a problem with BKPT/BRK, since I believe you can 
inject the breakpoint exception into the guest as if no hypervisor 
trap occured in between (of course, once you decide whether that 
breakpoint is Xen's or guest-internal). But what about X86? How is 
stealthiness achieved there? Is INT3 entirely not available for the 
guest anymore when guest-debugging is enabled or are ALL INT3's 
reported by Xen as software breakpoint vm-events?


In x86, attaching a debugger to the domain causes #DB and #BP 
exceptions to be intercepted by Xen, rather than handled directly by 
the domain (actually, since XSA-156, #DB is intercepted under all 
circumstances, to avoid security issues).  The debugger receives all 
debug events, and should filer the ones it has introduced vs the ones 
present from in-guest activities.


~Andrew

(Whether this works or not is a separate matter, and largely depends 
on the debugger.) 


And after this filtering, I guess if the debug event proves to be 
introduced by in-guest activities, the exception is reintroduced to 
preserve transparency, correct?
I'm curious if behind the scenes Xen also write-protects that page such 
that the guest does not overwrite the INT3.
This approach, I think, could be used w/ BKPT/BRK instructions on ARM as 
well. After all, BKPT/BRK functionality is precisely that of INT3's with 
the slight enhancement of having an #imm attached.
But, as I said, I anticipate that the actual implementation differences 
for this vm-event on ARM, if using BKPT/BRK (compared to X86) will 
emerge due to the fact that on X86 INT3 can be trapped all by itself, 
whereas on ARM such granularity is not available for BKPT/BRK. Also, 
working with the debug architecture might prove to be a little bit 
elaborate. So I guess this is a question of balancing conceptual 
correctness vs being practical for the short run with far less effort. :-)


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

[Xen-devel] [xen-unstable-coverity test] 91245: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 xen  ac703c285a4fbfcb85c19364ea0c67780bf16c2d
baseline version:
 xen  96ae556569b8eaedc0bb242932842c3277b515d8

Last test of basis88514  2016-04-03 09:36:25 Z   10 days
Testing same since91245  2016-04-13 09:56:13 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Changlong Xie 
  Chong Li 
  Chong Li 
  Chunyan Liu 
  Daniel De Graaf 
  Dario Fagggioli 
  Dario Faggioli 
  Dasaratharaman Chandramouli 
  David Scott 
  Fu Wei 
  George Dunlap 
  George Dunlap 
  Harmandeep Kaur 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Joao Martins 
  Juergen Gross 
  Julien Grall 
  Justin Weaver 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Len Brown 
  Meng Xu 
  Micah Barany 
  Mike Meyer 
  Olaf Hering 
  Paul Durrant 
  Robert VanVossen 
  Roger Pau Monne 
  Roger Pau Monné 
  Ross Philipson 
  Ross Philipson 
  Shanker Donthineni 
  Shannon Zhao 
  Shuai Ruan 
  Shuai Ruan 
  Sisu Xi 
  Uma Sharma 
  Vikram Sethi 
  Wei Liu 
  Wen Congyang 
  Yang Hongyang 

jobs:
 coverity-amd64   pass



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

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

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

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


Pushing revision :

+ branch=xen-unstable-coverity
+ 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-coverity ac703c285a4fbfcb85c19364ea0c67780bf16c2d
+ branch=xen-unstable-coverity
+ 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-coverity
+ qemuubranch=qemu-upstream-unstable-coverity
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-coverity
+ 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{"G

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

[Corneliu ZUZU]

On 4/13/2016 1:52 PM, Julien Grall wrote:

Hello Corneliu,

On 13/04/16 09:55, Corneliu ZUZU wrote:

On 4/12/2016 8:24 PM, Tamas K Lengyel wrote:
Another issue came to my mind: "HVC #imm", if handled through the
hvm-ops code, currently requires setting other registers to predefined
values before the HVC is actually issued. That would imply additional
effort to save/restore those registers if an external privileged domain
would want to set guest breakpoints. Given that, if we were to use HVC
for sw-bkpts, IMO it would be nice if the hvm-ops code architecture
would be slightly changed such that -lone- "HVM #imm" calls would be
achievable for some use cases, such as this.


That is not true. All the hypercalls are using the same #imm 
(XEN_HYPERCALL_TAG = 0xEA1), which indeed requires specific value in 
various registers to differentiate the HVM-ops.


It's up to us to define the requirements for the other #imm. For 
instance there are some #imm allocated for debugging (see 
do_debug_trap) that will dump the content of the registers.




That's nice, I wonder why we didn't do that for guest-request vm-events...





So what I will do instead of issuing a software_breakpoint vm_event
for SMCs, I'll introduce a new type, say
VM_EVENT_REASON_PRIVILEGED_CALL, that can be used to forward both
hypercalls and SMCs to a monitoring guest. This would also allow us to
use the software_breakpoint type for the actual software breakpoint
events in the future.

Tamas


Isn't the HVC-part already achieved by guest-request vm-events? Maybe
tying this vm-event specifically to SMC (in which case the name could be
something like VM_EVENT_REASON_SECURE_CALL) and thus making it
ARM-specific would avoid that redundancy?


I would create 2 distinct events for HVC and SMC. It would make easier 
to differentiate them in userspace.


Regards,



As stated, HVC events are already implemented as guest-request vm-events 
(hence the redundancy that a VM_EVENT_REASON_PRIVILEGED_CALL would add).
So indeed, that would leave us with the option of simply creating 
another event for SMC.


Corneliu.

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

Re: [Xen-devel] [linux-4.1 test] 88721: regressions - FAIL

[Ian Jackson]

osstest service owner writes ("[linux-4.1 test] 88721: regressions - FAIL"):
> version targeted for testing:
>  linux7f30737678023b5becaf0e2e012665f71b886a7d
> baseline version:
>  linux07cc49f66973f49a391c91bf4b158fa0f2562ca8

I have forced pushed this because 

> flight 88721 linux-4.1 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/88721/
...
> 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

These are the expected rump failures.

More recent flights show other problems.

Ian.

___
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

[George Dunlap]

On Wed, Apr 13, 2016 at 11:15 AM, Matt Fleming  wrote:
> For 1. we'd basically be using the PE/COFF file format with the EFI
> ABI as an OS agnostic boot protocol, but not as a full firmware
> runtime environment.

But we still have the issue here that the now the EFI entry point in
Linux has to figure out, "Am I running in a full firmware runtime
environment, or am I running under Xen?", and then change behavior
appropriately.  Then we get back to Juergen's comment:  "[The EFI
proposal] 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?"

> 2. is also interesting, though I think less so than 1. I agree that
> making OVMF work as a PVH guest is probably the right way to go, even
> for Dom0, not least because you'd have a much cleaner/less buggy
> implementation than what we see in the real world ;)

So rather than just add an extra entry point and a Xen-to-zero-page
stub, you're going to ask Xen on dom0 to import a full OVMF binary?
Or have the bootloader entries include xen, linux, the initrd, *and*
ovmf?  That seems a bit extreme. :-)

Keep in mind also that PVH needs to support not only the traditional
VM use-case (e.g., booting a full distro), but the small service VM
usecase (a la unikernels).  Booting a traditional distro as a domU via
OVMF -> EFI Linux makes sense; it reduces the distro's test burden,
and the OVMF doesn't add a lot to the memory or boot time compared to
the size and boot time of a full distro.  But booting tiny service
VMs, sometimes with not even any disk of their own (other than a
ramdisk), the extra cost of including OVMF in the guest address space
can be a non-negligible addition to the memory requirements and
boot-up time.

One of the reasons Xen on ARM prioritized getting EFI working for
domUs was that a representative from a certain distro vendor made it
absolutely clear that *their* distro would *only* support booting via
EFI on ARM.  But you can still, as I understand it, use uBoot with DT
to boot a lightweight domU if you want.

 -George

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

[Xen-devel] [tip:x86/asm] x86/traps: Enable all exception handler callbacks early

[tip-bot for Andy Lutomirski]

Commit-ID:  ae7ef45e12354a1e2f6013b46df0c9f5bbb6ffbe
Gitweb: http://git.kernel.org/tip/ae7ef45e12354a1e2f6013b46df0c9f5bbb6ffbe
Author: Andy Lutomirski 
AuthorDate: Sat, 2 Apr 2016 07:01:35 -0700
Committer:  Ingo Molnar 
CommitDate: Wed, 13 Apr 2016 11:37:45 +0200

x86/traps: Enable all exception handler callbacks early

Now that early_fixup_exception() has pt_regs, we can just call
fixup_exception() from it.  This will make fancy exception handlers
work early.

Tested-by: Boris Ostrovsky 
Signed-off-by: Andy Lutomirski 
Acked-by: Linus Torvalds 
Cc: Andrew Morton 
Cc: Arjan van de Ven 
Cc: Borislav Petkov 
Cc: KVM list 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: xen-devel 
Link: 
http://lkml.kernel.org/r/20fc047d926150cb08cb9b9f2923519b07ec1a15.1459605520.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/mm/extable.c | 19 ++-
 1 file changed, 2 insertions(+), 17 deletions(-)

diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
index da442f3..061a237 100644
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -88,10 +88,6 @@ extern unsigned int early_recursion_flag;
 /* Restricted version used during very early boot */
 void __init early_fixup_exception(struct pt_regs *regs, int trapnr)
 {
-   const struct exception_table_entry *e;
-   unsigned long new_ip;
-   ex_handler_t handler;
-
/* Ignore early NMIs. */
if (trapnr == X86_TRAP_NMI)
return;
@@ -102,19 +98,8 @@ void __init early_fixup_exception(struct pt_regs *regs, int 
trapnr)
if (regs->cs != __KERNEL_CS)
goto fail;
 
-   e = search_exception_tables(regs->ip);
-   if (!e)
-   goto fail;
-
-   new_ip  = ex_fixup_addr(e);
-   handler = ex_fixup_handler(e);
-
-   /* special handling not supported during early boot */
-   if (handler != ex_handler_default)
-   goto fail;
-
-   regs->ip = new_ip;
-   return;
+   if (fixup_exception(regs, trapnr))
+   return;
 
 fail:
early_printk("PANIC: early exception 0x%02x IP %lx:%lx error %lx cr2 
0x%lx\n",

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

[Xen-devel] [tip:x86/asm] x86/head: Move early exception panic code into early_fixup_exception()

[tip-bot for Andy Lutomirski]

Commit-ID:  0e861fbb5bda79b871341ef2a9a8059765cbe8a4
Gitweb: http://git.kernel.org/tip/0e861fbb5bda79b871341ef2a9a8059765cbe8a4
Author: Andy Lutomirski 
AuthorDate: Sat, 2 Apr 2016 07:01:34 -0700
Committer:  Ingo Molnar 
CommitDate: Wed, 13 Apr 2016 11:37:44 +0200

x86/head: Move early exception panic code into early_fixup_exception()

This removes a bunch of assembly and adds some C code instead.  It
changes the actual printouts on both 32-bit and 64-bit kernels, but
they still seem okay.

Tested-by: Boris Ostrovsky 
Signed-off-by: Andy Lutomirski 
Acked-by: Linus Torvalds 
Cc: Andrew Morton 
Cc: Arjan van de Ven 
Cc: Borislav Petkov 
Cc: KVM list 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: xen-devel 
Link: 
http://lkml.kernel.org/r/4085070316fc3ab29538d3fcfe282648d1d4ee2e.1459605520.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/uaccess.h |  2 +-
 arch/x86/kernel/head_32.S  | 49 +-
 arch/x86/kernel/head_64.S  | 45 ++
 arch/x86/mm/extable.c  | 29 -
 4 files changed, 32 insertions(+), 93 deletions(-)

diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index b6fb311..d794fd1 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -110,7 +110,7 @@ struct exception_table_entry {
 
 extern int fixup_exception(struct pt_regs *regs, int trapnr);
 extern bool ex_has_fault_handler(unsigned long ip);
-extern int early_fixup_exception(struct pt_regs *regs, int trapnr);
+extern void early_fixup_exception(struct pt_regs *regs, int trapnr);
 
 /*
  * These are the main single-value transfer routines.  They automatically
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index 184291c..6770865 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -561,8 +561,6 @@ early_idt_handler_common:
 */
cld
 
-   cmpl $2,%ss:early_recursion_flag
-   je hlt_loop
incl %ss:early_recursion_flag
 
/* The vector number is in pt_regs->gs */
@@ -594,13 +592,8 @@ early_idt_handler_common:
movw%gs, PT_GS(%esp)
movw$0, PT_GS+2(%esp)
 
-   cmpl $(__KERNEL_CS),PT_CS(%esp)
-   jne 10f
-
movl%esp, %eax  /* args are pt_regs (EAX), trapnr (EDX) */
callearly_fixup_exception
-   andl%eax,%eax
-   jz  10f /* Exception wasn't fixed up */
 
popl%ebx/* pt_regs->bx */
popl%ecx/* pt_regs->cx */
@@ -616,29 +609,6 @@ early_idt_handler_common:
decl%ss:early_recursion_flag
addl$4, %esp/* pop pt_regs->orig_ax */
iret
-
-10:
-#ifdef CONFIG_PRINTK
-   xorl %eax,%eax
-   movw %ax,PT_FS+2(%esp)  /* clean up the segment values on some cpus */
-   movw %ax,PT_DS+2(%esp)
-   movw %ax,PT_ES+2(%esp)
-   leal  40(%esp),%eax
-   pushl %eax  /* %esp before the exception */
-   pushl %ebx
-   pushl %ebp
-   pushl %esi
-   pushl %edi
-   movl %cr2,%eax
-   pushl %eax
-   pushl (20+6*4)(%esp)/* trapno */
-   pushl $fault_msg
-   call printk
-#endif
-   call dump_stack
-hlt_loop:
-   hlt
-   jmp hlt_loop
 ENDPROC(early_idt_handler_common)
 
 /* This is the default interrupt "handler" :-) */
@@ -674,10 +644,14 @@ ignore_int:
popl %eax
 #endif
iret
+
+hlt_loop:
+   hlt
+   jmp hlt_loop
 ENDPROC(ignore_int)
 __INITDATA
.align 4
-early_recursion_flag:
+GLOBAL(early_recursion_flag)
.long 0
 
 __REFDATA
@@ -742,19 +716,6 @@ __INITRODATA
 int_msg:
.asciz "Unknown interrupt or fault at: %p %p %p\n"
 
-fault_msg:
-/* fault info: */
-   .ascii "BUG: Int %d: CR2 %p\n"
-/* regs pushed in early_idt_handler: */
-   .ascii " EDI %p  ESI %p  EBP %p  EBX %p\n"
-   .ascii " ESP %p   ES %p   DS %p\n"
-   .ascii " EDX %p  ECX %p  EAX %p\n"
-/* fault frame: */
-   .ascii " vec %p  err %p  EIP %p   CS %p  flg %p\n"
-   .ascii "Stack: %p %p %p %p %p %p %p %p\n"
-   .ascii "   %p %p %p %p %p %p %p %p\n"
-   .asciz "   %p %p %p %p %p %p %p %p\n"
-
 #include "../../x86/xen/xen-head.S"
 
 /*
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 2308437..3de91a7 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -351,8 +351,6 @@ early_idt_handler_common:
 */
cld
 
-   cmpl $2,early_recursion_flag(%rip)
-   jz  1f
incl early_recursion_flag(%rip)
 
/* The vector number is currently in the pt_regs->di slot. */
@@ -373,9 +371,6 @@ early_idt_handler_common:
pushq %r14  /* pt_regs->r14 */
pushq %r15  /* pt_regs->r15 */
 
-   cmpl $__KERNEL_CS,CS(%rsp)
-   jne 11f
-
cmpq $14,%rsi   

[Xen-devel] [tip:x86/asm] x86/head: Move the early NMI fixup into C

[tip-bot for Andy Lutomirski]

Commit-ID:  0d0efc07f3df677d7622bb760f8e2920b5e33f42
Gitweb: http://git.kernel.org/tip/0d0efc07f3df677d7622bb760f8e2920b5e33f42
Author: Andy Lutomirski 
AuthorDate: Sat, 2 Apr 2016 07:01:33 -0700
Committer:  Ingo Molnar 
CommitDate: Wed, 13 Apr 2016 11:37:44 +0200

x86/head: Move the early NMI fixup into C

C is nicer than asm.

Tested-by: Boris Ostrovsky 
Signed-off-by: Andy Lutomirski 
Acked-by: Linus Torvalds 
Cc: Andrew Morton 
Cc: Arjan van de Ven 
Cc: Borislav Petkov 
Cc: KVM list 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: xen-devel 
Link: 
http://lkml.kernel.org/r/dd068269f8d59fe44e9e43a50d0efd67da65c2b5.1459605520.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/head_32.S | 7 ---
 arch/x86/kernel/head_64.S | 6 --
 arch/x86/mm/extable.c | 5 +
 3 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index 0904536..184291c 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -561,9 +561,6 @@ early_idt_handler_common:
 */
cld
 
-   cmpl $2,(%esp)  # X86_TRAP_NMI
-   je .Lis_nmi # Ignore NMI
-
cmpl $2,%ss:early_recursion_flag
je hlt_loop
incl %ss:early_recursion_flag
@@ -642,10 +639,6 @@ early_idt_handler_common:
 hlt_loop:
hlt
jmp hlt_loop
-
-.Lis_nmi:
-   addl $8,%esp/* drop vector number and error code */
-   iret
 ENDPROC(early_idt_handler_common)
 
 /* This is the default interrupt "handler" :-) */
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 9e8636d..2308437 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -351,9 +351,6 @@ early_idt_handler_common:
 */
cld
 
-   cmpl $2,(%rsp)  # X86_TRAP_NMI
-   je .Lis_nmi # Ignore NMI
-
cmpl $2,early_recursion_flag(%rip)
jz  1f
incl early_recursion_flag(%rip)
@@ -422,9 +419,6 @@ early_idt_handler_common:
 20:/* Exception table entry found or page table generated */
decl early_recursion_flag(%rip)
jmp restore_regs_and_iret
-.Lis_nmi:
-   addq $16,%rsp   # drop vector number and error code
-   INTERRUPT_RETURN
 ENDPROC(early_idt_handler_common)
 
__INITDATA
diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
index 1366e06..4be0419 100644
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 
 typedef bool (*ex_handler_t)(const struct exception_table_entry *,
struct pt_regs *, int);
@@ -89,6 +90,10 @@ int __init early_fixup_exception(struct pt_regs *regs, int 
trapnr)
unsigned long new_ip;
ex_handler_t handler;
 
+   /* Ignore early NMIs. */
+   if (trapnr == X86_TRAP_NMI)
+   return 1;
+
e = search_exception_tables(regs->ip);
if (!e)
return 0;

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

[Xen-devel] [tip:x86/asm] x86/head: Pass a real pt_regs and trapnr to early_fixup_exception()

[tip-bot for Andy Lutomirski]

Commit-ID:  7bbcdb1ca4d2fd69094ee89c18601b396531ca9f
Gitweb: http://git.kernel.org/tip/7bbcdb1ca4d2fd69094ee89c18601b396531ca9f
Author: Andy Lutomirski 
AuthorDate: Sat, 2 Apr 2016 07:01:32 -0700
Committer:  Ingo Molnar 
CommitDate: Wed, 13 Apr 2016 11:37:44 +0200

x86/head: Pass a real pt_regs and trapnr to early_fixup_exception()

early_fixup_exception() is limited by the fact that it doesn't have a
real struct pt_regs.  Change both the 32-bit and 64-bit asm and the
C code to pass and accept a real pt_regs.

Tested-by: Boris Ostrovsky 
Signed-off-by: Andy Lutomirski 
Acked-by: Linus Torvalds 
Cc: Andrew Morton 
Cc: Arjan van de Ven 
Cc: Borislav Petkov 
Cc: KVM list 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: xen-devel 
Link: 
http://lkml.kernel.org/r/e3fb680fcfd5e23e38237e8328b64a25cc121d37.1459605520.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/uaccess.h |  2 +-
 arch/x86/kernel/head_32.S  | 74 +-
 arch/x86/kernel/head_64.S  | 68 --
 arch/x86/mm/extable.c  |  6 ++--
 4 files changed, 92 insertions(+), 58 deletions(-)

diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index a969ae6..b6fb311 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -110,7 +110,7 @@ struct exception_table_entry {
 
 extern int fixup_exception(struct pt_regs *regs, int trapnr);
 extern bool ex_has_fault_handler(unsigned long ip);
-extern int early_fixup_exception(unsigned long *ip);
+extern int early_fixup_exception(struct pt_regs *regs, int trapnr);
 
 /*
  * These are the main single-value transfer routines.  They automatically
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index 54cdbd2..0904536 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -568,29 +568,64 @@ early_idt_handler_common:
je hlt_loop
incl %ss:early_recursion_flag
 
-   push %eax   # 16(%esp)
-   push %ecx   # 12(%esp)
-   push %edx   #  8(%esp)
-   push %ds#  4(%esp)
-   push %es#  0(%esp)
-   movl $(__KERNEL_DS),%eax
-   movl %eax,%ds
-   movl %eax,%es
+   /* The vector number is in pt_regs->gs */
 
-   cmpl $(__KERNEL_CS),32(%esp)
+   cld
+   pushl   %fs /* pt_regs->fs */
+   movw$0, 2(%esp) /* clear high bits (some CPUs leave garbage) */
+   pushl   %es /* pt_regs->es */
+   movw$0, 2(%esp) /* clear high bits (some CPUs leave garbage) */
+   pushl   %ds /* pt_regs->ds */
+   movw$0, 2(%esp) /* clear high bits (some CPUs leave garbage) */
+   pushl   %eax/* pt_regs->ax */
+   pushl   %ebp/* pt_regs->bp */
+   pushl   %edi/* pt_regs->di */
+   pushl   %esi/* pt_regs->si */
+   pushl   %edx/* pt_regs->dx */
+   pushl   %ecx/* pt_regs->cx */
+   pushl   %ebx/* pt_regs->bx */
+
+   /* Fix up DS and ES */
+   movl$(__KERNEL_DS), %ecx
+   movl%ecx, %ds
+   movl%ecx, %es
+
+   /* Load the vector number into EDX */
+   movlPT_GS(%esp), %edx
+
+   /* Load GS into pt_regs->gs and clear high bits */
+   movw%gs, PT_GS(%esp)
+   movw$0, PT_GS+2(%esp)
+
+   cmpl $(__KERNEL_CS),PT_CS(%esp)
jne 10f
 
-   leal 28(%esp),%eax  # Pointer to %eip
-   call early_fixup_exception
-   andl %eax,%eax
-   jnz ex_entry/* found an exception entry */
+   movl%esp, %eax  /* args are pt_regs (EAX), trapnr (EDX) */
+   callearly_fixup_exception
+   andl%eax,%eax
+   jz  10f /* Exception wasn't fixed up */
+
+   popl%ebx/* pt_regs->bx */
+   popl%ecx/* pt_regs->cx */
+   popl%edx/* pt_regs->dx */
+   popl%esi/* pt_regs->si */
+   popl%edi/* pt_regs->di */
+   popl%ebp/* pt_regs->bp */
+   popl%eax/* pt_regs->ax */
+   popl%ds /* pt_regs->ds */
+   popl%es /* pt_regs->es */
+   popl%fs /* pt_regs->fs */
+   popl%gs /* pt_regs->gs */
+   decl%ss:early_recursion_flag
+   addl$4, %esp/* pop pt_regs->orig_ax */
+   iret
 
 10:
 #ifdef CONFIG_PRINTK
xorl %eax,%eax
-   movw %ax,2(%esp)/* clean up the segment values on some cpus */
-   movw %ax,6(%esp)
-   movw %ax,34(%esp)
+   movw %ax,PT_FS+2(%esp)  /* clean up the segment values on some cpus */
+   movw %ax,PT_DS+2(%esp)
+   movw %ax,PT_ES+2(%esp)
leal  40(%esp),%eax
pushl %eax  /* %esp before the exception */
p

[Xen-devel] [tip:x86/asm] x86/paravirt: Add _safe to the read_ms()r and write_msr() PV callbacks

[tip-bot for Andy Lutomirski]

Commit-ID:  c2ee03b2a94d7ba692cf6206bbe069d5bfcc20ed
Gitweb: http://git.kernel.org/tip/c2ee03b2a94d7ba692cf6206bbe069d5bfcc20ed
Author: Andy Lutomirski 
AuthorDate: Sat, 2 Apr 2016 07:01:36 -0700
Committer:  Ingo Molnar 
CommitDate: Wed, 13 Apr 2016 11:37:45 +0200

x86/paravirt: Add _safe to the read_ms()r and write_msr() PV callbacks

These callbacks match the _safe variants, so name them accordingly.
This will make room for unsafe PV callbacks.

Tested-by: Boris Ostrovsky 
Signed-off-by: Andy Lutomirski 
Acked-by: Linus Torvalds 
Cc: Andrew Morton 
Cc: Arjan van de Ven 
Cc: Borislav Petkov 
Cc: KVM list 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: xen-devel 
Link: 
http://lkml.kernel.org/r/9ee3fb6a196a514c93325bdfa15594beecf04876.1459605520.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/paravirt.h   | 33 +
 arch/x86/include/asm/paravirt_types.h |  8 
 arch/x86/kernel/paravirt.c|  4 ++--
 arch/x86/xen/enlighten.c  |  4 ++--
 4 files changed, 25 insertions(+), 24 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 601f1b8..81ef2d5 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -130,34 +130,35 @@ static inline void wbinvd(void)
 
 #define get_kernel_rpl()  (pv_info.kernel_rpl)
 
-static inline u64 paravirt_read_msr(unsigned msr, int *err)
+static inline u64 paravirt_read_msr_safe(unsigned msr, int *err)
 {
-   return PVOP_CALL2(u64, pv_cpu_ops.read_msr, msr, err);
+   return PVOP_CALL2(u64, pv_cpu_ops.read_msr_safe, msr, err);
 }
 
-static inline int paravirt_write_msr(unsigned msr, unsigned low, unsigned high)
+static inline int paravirt_write_msr_safe(unsigned msr,
+ unsigned low, unsigned high)
 {
-   return PVOP_CALL3(int, pv_cpu_ops.write_msr, msr, low, high);
+   return PVOP_CALL3(int, pv_cpu_ops.write_msr_safe, msr, low, high);
 }
 
 /* These should all do BUG_ON(_err), but our headers are too tangled. */
 #define rdmsr(msr, val1, val2) \
 do {   \
int _err;   \
-   u64 _l = paravirt_read_msr(msr, &_err); \
+   u64 _l = paravirt_read_msr_safe(msr, &_err);\
val1 = (u32)_l; \
val2 = _l >> 32;\
 } while (0)
 
 #define wrmsr(msr, val1, val2) \
 do {   \
-   paravirt_write_msr(msr, val1, val2);\
+   paravirt_write_msr_safe(msr, val1, val2);   \
 } while (0)
 
 #define rdmsrl(msr, val)   \
 do {   \
int _err;   \
-   val = paravirt_read_msr(msr, &_err);\
+   val = paravirt_read_msr_safe(msr, &_err);   \
 } while (0)
 
 static inline void wrmsrl(unsigned msr, u64 val)
@@ -165,23 +166,23 @@ static inline void wrmsrl(unsigned msr, u64 val)
wrmsr(msr, (u32)val, (u32)(val>>32));
 }
 
-#define wrmsr_safe(msr, a, b)  paravirt_write_msr(msr, a, b)
+#define wrmsr_safe(msr, a, b)  paravirt_write_msr_safe(msr, a, b)
 
 /* rdmsr with exception handling */
-#define rdmsr_safe(msr, a, b)  \
-({ \
-   int _err;   \
-   u64 _l = paravirt_read_msr(msr, &_err); \
-   (*a) = (u32)_l; \
-   (*b) = _l >> 32;\
-   _err;   \
+#define rdmsr_safe(msr, a, b)  \
+({ \
+   int _err;   \
+   u64 _l = paravirt_read_msr_safe(msr, &_err);\
+   (*a) = (u32)_l; \
+   (*b) = _l >> 32;\
+   _err;   \
 })
 
 static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
 {
int err;
 
-   *p = paravirt_read_msr(msr, &err);
+   *p = paravirt_read_msr_safe(msr, &err);
return err;
 }
 
diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index e8c2326..09c9e1d 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -155,10 +155,10 @@ struct pv_cpu_ops {
void (*cpuid)(unsigned int *eax, unsigned int *ebx,
  unsigned int *ecx, unsigned int *edx);
 
-   /* MSR, PMC and TSR operations.
-  err = 0/-EFAULT.  wrmsr returns 0/-EFAULT. */
-   u64 (*read_msr)(unsigned int msr, int *err);
-   int (*write_msr)(unsigned int msr, unsigned low, unsigned high);
+   /* MSR operations.
+  err = 0/-EIO.  wrmsr returns 0/-EIO. */
+   u64 (*read_msr_safe)(unsigned 

[Xen-devel] [tip:x86/asm] x86/msr: Carry on after a non-"safe" MSR access fails

[tip-bot for Andy Lutomirski]

Commit-ID:  fbd704374d111bed16a19261176fa30e2379c87c
Gitweb: http://git.kernel.org/tip/fbd704374d111bed16a19261176fa30e2379c87c
Author: Andy Lutomirski 
AuthorDate: Sat, 2 Apr 2016 07:01:37 -0700
Committer:  Ingo Molnar 
CommitDate: Wed, 13 Apr 2016 11:37:45 +0200

x86/msr: Carry on after a non-"safe" MSR access fails

This demotes an OOPS and likely panic due to a failed non-"safe" MSR
access to a WARN_ONCE() and, for RDMSR, a return value of zero.

To be clear, this type of failure should *not* happen.  This patch
exists to minimize the chance of nasty undebuggable failures
happening when a CONFIG_PARAVIRT=y bug in the non-"safe" MSR helpers
gets fixed.

Tested-by: Boris Ostrovsky 
Signed-off-by: Andy Lutomirski 
Acked-by: Linus Torvalds 
Cc: Andrew Morton 
Cc: Arjan van de Ven 
Cc: Borislav Petkov 
Cc: KVM list 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: xen-devel 
Link: 
http://lkml.kernel.org/r/26567b216aae70e795938f4b567eace5a0eb90ba.1459605520.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/msr.h | 10 --
 arch/x86/mm/extable.c  | 27 +++
 2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 7a79ee2..25f169c 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -84,7 +84,10 @@ static inline unsigned long long native_read_msr(unsigned 
int msr)
 {
DECLARE_ARGS(val, low, high);
 
-   asm volatile("rdmsr" : EAX_EDX_RET(val, low, high) : "c" (msr));
+   asm volatile("1: rdmsr\n"
+"2:\n"
+_ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_rdmsr_unsafe)
+: EAX_EDX_RET(val, low, high) : "c" (msr));
if (msr_tracepoint_active(__tracepoint_read_msr))
do_trace_read_msr(msr, EAX_EDX_VAL(val, low, high), 0);
return EAX_EDX_VAL(val, low, high);
@@ -111,7 +114,10 @@ static inline unsigned long long 
native_read_msr_safe(unsigned int msr,
 static inline void native_write_msr(unsigned int msr,
unsigned low, unsigned high)
 {
-   asm volatile("wrmsr" : : "c" (msr), "a"(low), "d" (high) : "memory");
+   asm volatile("1: wrmsr\n"
+"2:\n"
+_ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_wrmsr_unsafe)
+: : "c" (msr), "a"(low), "d" (high) : "memory");
if (msr_tracepoint_active(__tracepoint_read_msr))
do_trace_write_msr(msr, ((u64)high << 32 | low), 0);
 }
diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
index 061a237..fd9eb98 100644
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -43,6 +43,33 @@ bool ex_handler_ext(const struct exception_table_entry 
*fixup,
 }
 EXPORT_SYMBOL(ex_handler_ext);
 
+bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup,
+struct pt_regs *regs, int trapnr)
+{
+   WARN_ONCE(1, "unchecked MSR access error: RDMSR from 0x%x\n",
+ (unsigned int)regs->cx);
+
+   /* Pretend that the read succeeded and returned 0. */
+   regs->ip = ex_fixup_addr(fixup);
+   regs->ax = 0;
+   regs->dx = 0;
+   return true;
+}
+EXPORT_SYMBOL(ex_handler_rdmsr_unsafe);
+
+bool ex_handler_wrmsr_unsafe(const struct exception_table_entry *fixup,
+struct pt_regs *regs, int trapnr)
+{
+   WARN_ONCE(1, "unchecked MSR access error: WRMSR to 0x%x (tried to write 
0x%08x%08x)\n",
+ (unsigned int)regs->cx,
+ (unsigned int)regs->dx, (unsigned int)regs->ax);
+
+   /* Pretend that the write succeeded. */
+   regs->ip = ex_fixup_addr(fixup);
+   return true;
+}
+EXPORT_SYMBOL(ex_handler_wrmsr_unsafe);
+
 bool ex_has_fault_handler(unsigned long ip)
 {
const struct exception_table_entry *e;

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

[Xen-devel] [tip:x86/asm] x86/paravirt: Make "unsafe" MSR accesses unsafe even if PARAVIRT=y

[tip-bot for Andy Lutomirski]

Commit-ID:  4985ce15a397e9b6541548efe3b9ffac2dda9127
Gitweb: http://git.kernel.org/tip/4985ce15a397e9b6541548efe3b9ffac2dda9127
Author: Andy Lutomirski 
AuthorDate: Sat, 2 Apr 2016 07:01:39 -0700
Committer:  Ingo Molnar 
CommitDate: Wed, 13 Apr 2016 11:37:46 +0200

x86/paravirt: Make "unsafe" MSR accesses unsafe even if PARAVIRT=y

Enabling CONFIG_PARAVIRT had an unintended side effect: rdmsr() turned
into rdmsr_safe() and wrmsr() turned into wrmsr_safe(), even on bare
metal.  Undo that by using the new unsafe paravirt MSR callbacks.

Tested-by: Boris Ostrovsky 
Signed-off-by: Andy Lutomirski 
Acked-by: Linus Torvalds 
Cc: Andrew Morton 
Cc: Arjan van de Ven 
Cc: Borislav Petkov 
Cc: KVM list 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: xen-devel 
Link: 
http://lkml.kernel.org/r/414fabd6d3527703077c6c2a797223d0a9c3b081.1459605520.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/paravirt.h | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 97839fa..3c73141 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -152,24 +152,21 @@ static inline int paravirt_write_msr_safe(unsigned msr,
return PVOP_CALL3(int, pv_cpu_ops.write_msr_safe, msr, low, high);
 }
 
-/* These should all do BUG_ON(_err), but our headers are too tangled. */
 #define rdmsr(msr, val1, val2) \
 do {   \
-   int _err;   \
-   u64 _l = paravirt_read_msr_safe(msr, &_err);\
+   u64 _l = paravirt_read_msr(msr);\
val1 = (u32)_l; \
val2 = _l >> 32;\
 } while (0)
 
 #define wrmsr(msr, val1, val2) \
 do {   \
-   paravirt_write_msr_safe(msr, val1, val2);   \
+   paravirt_write_msr(msr, val1, val2);\
 } while (0)
 
 #define rdmsrl(msr, val)   \
 do {   \
-   int _err;   \
-   val = paravirt_read_msr_safe(msr, &_err);   \
+   val = paravirt_read_msr(msr);   \
 } while (0)
 
 static inline void wrmsrl(unsigned msr, u64 val)

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

[Xen-devel] [tip:x86/asm] x86/msr: Set the return value to zero when native_rdmsr_safe() fails

[tip-bot for Andy Lutomirski]

Commit-ID:  b828b79fcced0e66492590707649dbfaea6435e6
Gitweb: http://git.kernel.org/tip/b828b79fcced0e66492590707649dbfaea6435e6
Author: Andy Lutomirski 
AuthorDate: Sat, 2 Apr 2016 07:01:40 -0700
Committer:  Ingo Molnar 
CommitDate: Wed, 13 Apr 2016 11:37:46 +0200

x86/msr: Set the return value to zero when native_rdmsr_safe() fails

This will cause unchecked native_rdmsr_safe() failures to return
deterministic results.

Tested-by: Boris Ostrovsky 
Signed-off-by: Andy Lutomirski 
Acked-by: Linus Torvalds 
Cc: Andrew Morton 
Cc: Arjan van de Ven 
Cc: Borislav Petkov 
Cc: KVM list 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: xen-devel 
Link: 
http://lkml.kernel.org/r/515fb611449a755312a476cfe11675906e7ddf6c.1459605520.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/msr.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 00050c0..7dc1d8f 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -101,7 +101,10 @@ static inline unsigned long long 
native_read_msr_safe(unsigned int msr,
asm volatile("2: rdmsr ; xor %[err],%[err]\n"
 "1:\n\t"
 ".section .fixup,\"ax\"\n\t"
-"3:  mov %[fault],%[err] ; jmp 1b\n\t"
+"3: mov %[fault],%[err]\n\t"
+"xorl %%eax, %%eax\n\t"
+"xorl %%edx, %%edx\n\t"
+"jmp 1b\n\t"
 ".previous\n\t"
 _ASM_EXTABLE(2b, 3b)
 : [err] "=r" (*err), EAX_EDX_RET(val, low, high)

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

[Xen-devel] [tip:x86/asm] x86/paravirt: Add paravirt_{read, write}_msr()

[tip-bot for Andy Lutomirski]

Commit-ID:  dd2f4a004b016bbfb64f1de49cb45e66232e40a6
Gitweb: http://git.kernel.org/tip/dd2f4a004b016bbfb64f1de49cb45e66232e40a6
Author: Andy Lutomirski 
AuthorDate: Sat, 2 Apr 2016 07:01:38 -0700
Committer:  Ingo Molnar 
CommitDate: Wed, 13 Apr 2016 11:37:46 +0200

x86/paravirt: Add paravirt_{read,write}_msr()

This adds paravirt callbacks for unsafe MSR access.  On native, they
call native_{read,write}_msr().  On Xen, they use xen_{read,write}_msr_safe().

Nothing uses them yet for ease of bisection.  The next patch will
use them in rdmsrl(), wrmsrl(), etc.

I intentionally didn't make them warn on #GP on Xen.  I think that
should be done separately by the Xen maintainers.

Tested-by: Boris Ostrovsky 
Signed-off-by: Andy Lutomirski 
Acked-by: Linus Torvalds 
Cc: Andrew Morton 
Cc: Arjan van de Ven 
Cc: Borislav Petkov 
Cc: KVM list 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: xen-devel 
Link: 
http://lkml.kernel.org/r/880eebc5dcd2ad9f310d41345f82061ea500e9fa.1459605520.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/msr.h|  5 +++--
 arch/x86/include/asm/paravirt.h   | 11 +++
 arch/x86/include/asm/paravirt_types.h | 10 --
 arch/x86/kernel/paravirt.c|  2 ++
 arch/x86/xen/enlighten.c  | 23 +++
 5 files changed, 47 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 25f169c..00050c0 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -111,8 +111,9 @@ static inline unsigned long long 
native_read_msr_safe(unsigned int msr,
return EAX_EDX_VAL(val, low, high);
 }
 
-static inline void native_write_msr(unsigned int msr,
-   unsigned low, unsigned high)
+/* Can be uninlined because referenced by paravirt */
+notrace static inline void native_write_msr(unsigned int msr,
+   unsigned low, unsigned high)
 {
asm volatile("1: wrmsr\n"
 "2:\n"
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 81ef2d5..97839fa 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -130,6 +130,17 @@ static inline void wbinvd(void)
 
 #define get_kernel_rpl()  (pv_info.kernel_rpl)
 
+static inline u64 paravirt_read_msr(unsigned msr)
+{
+   return PVOP_CALL1(u64, pv_cpu_ops.read_msr, msr);
+}
+
+static inline void paravirt_write_msr(unsigned msr,
+ unsigned low, unsigned high)
+{
+   return PVOP_VCALL3(pv_cpu_ops.write_msr, msr, low, high);
+}
+
 static inline u64 paravirt_read_msr_safe(unsigned msr, int *err)
 {
return PVOP_CALL2(u64, pv_cpu_ops.read_msr_safe, msr, err);
diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 09c9e1d..b4a23ea 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -155,8 +155,14 @@ struct pv_cpu_ops {
void (*cpuid)(unsigned int *eax, unsigned int *ebx,
  unsigned int *ecx, unsigned int *edx);
 
-   /* MSR operations.
-  err = 0/-EIO.  wrmsr returns 0/-EIO. */
+   /* Unsafe MSR operations.  These will warn or panic on failure. */
+   u64 (*read_msr)(unsigned int msr);
+   void (*write_msr)(unsigned int msr, unsigned low, unsigned high);
+
+   /*
+* Safe MSR operations.
+* read sets err to 0 or -EIO.  write returns 0 or -EIO.
+*/
u64 (*read_msr_safe)(unsigned int msr, int *err);
int (*write_msr_safe)(unsigned int msr, unsigned low, unsigned high);
 
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 8aad954..f958391 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -339,6 +339,8 @@ __visible struct pv_cpu_ops pv_cpu_ops = {
.write_cr8 = native_write_cr8,
 #endif
.wbinvd = native_wbinvd,
+   .read_msr = native_read_msr,
+   .write_msr = native_write_msr,
.read_msr_safe = native_read_msr_safe,
.write_msr_safe = native_write_msr_safe,
.read_pmc = native_read_pmc,
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 13f756f..6ab6722 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1092,6 +1092,26 @@ static int xen_write_msr_safe(unsigned int msr, unsigned 
low, unsigned high)
return ret;
 }
 
+static u64 xen_read_msr(unsigned int msr)
+{
+   /*
+* This will silently swallow a #GP from RDMSR.  It may be worth
+* changing that.
+*/
+   int err;
+
+   return xen_read_msr_safe(msr, &err);
+}
+
+static void xen_write_msr(unsigned int msr, unsigned low, unsigned high)
+{
+   /*
+* This will silently swallow a #GP from WRMSR.  It may be worth
+* changing that.
+*/
+   xen_write_msr_safe(msr, low, high);
+

[Xen-devel] [tip:x86/asm] x86/extable: Add a comment about early exception handlers

[tip-bot for Andy Lutomirski]

Commit-ID:  60a0e2039e3df6c0a2b896bd78af36ff36fb629c
Gitweb: http://git.kernel.org/tip/60a0e2039e3df6c0a2b896bd78af36ff36fb629c
Author: Andy Lutomirski 
AuthorDate: Mon, 4 Apr 2016 08:46:22 -0700
Committer:  Ingo Molnar 
CommitDate: Wed, 13 Apr 2016 11:37:47 +0200

x86/extable: Add a comment about early exception handlers

Borislav asked for a comment explaining why all exception handlers are
allowed early.

Signed-off-by: Andy Lutomirski 
Reviewed-by: Borislav Petkov 
Acked-by: Linus Torvalds 
Cc: Andrew Morton 
Cc: Arjan van de Ven 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: KVM list 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: xen-devel 
Link: 
http://lkml.kernel.org/r/5f1dcd6919f4a5923959a8065cb2c04d9dac1412.1459784772.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/mm/extable.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
index fd9eb98..aaeda3f 100644
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -125,6 +125,20 @@ void __init early_fixup_exception(struct pt_regs *regs, 
int trapnr)
if (regs->cs != __KERNEL_CS)
goto fail;
 
+   /*
+* The full exception fixup machinery is available as soon as
+* the early IDT is loaded.  This means that it is the
+* responsibility of extable users to either function correctly
+* when handlers are invoked early or to simply avoid causing
+* exceptions before they're ready to handle them.
+*
+* This is better than filtering which handlers can be used,
+* because refusing to call a handler here is guaranteed to
+* result in a hard-to-debug panic.
+*
+* Keep in mind that not all vectors actually get here.  Early
+* fage faults, for example, are special.
+*/
if (fixup_exception(regs, trapnr))
return;
 

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

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

[Razvan Cojocaru]

On 04/13/2016 12:47 PM, Konrad Rzeszutek Wilk wrote:
>> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
>> index 1fec412..4c96968 100644
>> --- a/xen/arch/x86/monitor.c
>> +++ b/xen/arch/x86/monitor.c
>> @@ -22,6 +22,58 @@
>>  #include 
>>  #include 
>>  
>> +static int arch_monitor_enable_msr(struct domain *d, u32 msr)
>> +{
>> +if ( !d->arch.monitor_msr_bitmap )
>> +return -EINVAL;
> 
> I this was not set wouldn't we fail in vm_event_enable with -ENOMEM?
> 
> I presume the user can still make this hypercall..  Ah yes.
> 
> Perhaps -ENXIO?

Sure, I can return -ENXIO. I just thought -EINVAL reflects the case
well: it's not right to call this hypercall if you haven't subscribed
for vm_events beforehand (in which case d->arch.monitor_msr_bitmap is
NULL, because it's only allocated then, and de-allocated again when the
subscriber unsubscribes).

>> +
>> +if ( msr <= 0x1fff )
>> +set_bit(msr, d->arch.monitor_msr_bitmap + 0x000/BYTES_PER_LONG);
> 
> The 0x000/BYTER_PER_LONG looks odd. Is it even needed?

I've pretty much copied the code from the enabled msrs bitmap, so I
assume it was, but I'll change the code to follow Andrew Cooper's
suggestion which should make this go away.

>> +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);
> 
> And for MSRs above 0xc0001fff it is OK to enable the interception?
> Or between 0x1fff and 0xc000?
> 
> No need to filter them out? Or error on them?
>> +
>> +return 0;
>> +}
>> +
>> +static int arch_monitor_disable_msr(struct domain *d, u32 msr)
>> +{
>> +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 arch_monitor_is_msr_enabled(const struct domain *d, u32 msr)
>> +{
>> +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);
>> +}
> 
> And what if msr requested is above 0xc0001fff ? What then?

I think the questions above have been answered by Andrew Cooper.

>> +
>> +return rc;
>> +}
>> +
>>  int arch_monitor_domctl_event(struct domain *d,
>>struct xen_domctl_monitor_op *mop)
>>  {
>> @@ -77,25 +129,28 @@ int arch_monitor_domctl_event(struct domain *d,
>>  
>>  case XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR:
> 
> Should this be renamed?

I'm happy to rename it, but I don't think it should - it has the exact
same semantics as before: monitor a MSR write.

>>  {
>> -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 = arch_monitor_is_msr_enabled(d, msr);
>>  
>> -domain_pause(d);
>> +if ( unlikely(old_status == requested_status) )
>> +{
>> +domain_unpause(d);
>> +return -EEXIST;
>> +}
>>  
>> -if ( requested_status && mop->u.mov_to_msr.extended_capture )
>> -ad->monitor.mov_to_msr_extended = 1;
>> +if ( requested_status )
>> +rc = arch_monitor_enable_msr(d, msr);
>>  else
>> -ad->monitor.mov_to_msr_extended = 0;
>> +rc = arch_monitor_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..9b4267e 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();
> 
> How about using vzalloc?
>> +
>> +if ( !d->arch.monitor_msr_bitmap )
>> +return -ENOMEM;
>> +
>> +memset(d->arch.monitor_msr_bitmap, 0, PAGE_SIZE);
> 
> Then you don't have to do 

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

[Roger Pau Monné]

On Wed, Apr 13, 2016 at 11:15:15AM +0100, Matt Fleming wrote:
> On Wed, 13 Apr, at 11:02:02AM, Roger Pau Monné wrote:
> > 
> > With my FreeBSD committer hat:
> > 
> > The FreeBSD kernel doesn't contain an EFI entry point, it just contains one 
> > single entry point that's used for both legacy BIOS and EFI. Then the 
> > FreeBSD loader is the one that contains the different entry points. I would 
> > really like to avoid adding an EFI entry point and the PE header to the 
> > FreeBSD kernel. The current trampoline in FreeBSD to tie the Xen entry 
> > point 
> > into the native path contains 96 lines of assembly (half of them are 
> > actually comments) and 66 lines of C. I think adding an EFI entry point is 
> > going to add a lot more of code than this, and we would probably need 
> > changes to the build system in order to assembly the PE header and the ELF 
> > headers together.
>  
> What does the boot flow look like for PVH2 on FreeBSD today?
> Presumably it doesn't have the same entry point that Boris proposed
> for Linux?

Yes it does have something quite similar to the entry point that Boris 
proposed for Linux.
 
> Does it go, Hypervisor -> FreeBSD loader -> FreeBSD kernel? Or are you
> able to directly boot the kernel from the hypervisor and skip the
> middle part by having secondary entry point for Xen marked by the ELF
> note?

We skip the bootloader and Xen loads the FreeBSD kernel directly using the 
ELF note that contains the PVH entry point.

I certainly want to be able to run the FreeBSD loader inside of a PVH guest, 
but I plan to simply chainload it from OVMF, so it would look like:

Hypervisor -> OVMF -> FreeBSD EFI loader -> FreeBSD kernel

> > IMHO, if we want to boot PVH using EFI the right solution is to use OVMF 
> > (or 
> > any other UEFI firmware) and port it so it's able to run as a PVH guest. I 
> > guess it should even be possible to use it for Dom0, although I think this 
> > is cumbersome.
> 
> There are two levels of EFI boot entry features being discussed,
> 
>  1. Make the OS kernel a PE/COFF executable
>  2. Provide some level of EFI service functionality
> 
> You can adopt 1. without 2, i.e. without actually providing any EFI
> services at all, as long as the Xen hypervisor grows a PE/COFF loader
> (since EFI firmware has to provide you one, for EFI platforms you
> could use the LoadImage() service in the firmware, but for BIOS
> platforms you'd need your own in Xen).

We could use native LoadImage for Dom0 maybe if we are booted on an EFI 
platform, but for DomUs we certainly need to implement our own inside of 
Xen, at which point we could do the same and always use the one inside of 
Xen in order to avoid diverging paths.

TBH, I don't think this is the right solution. We would force every OS 
kernel that wants to be loaded using Xen to become a PE/COFF executable. 
This also includes unikernels like MirageOS, which will be forced to become 
a PE/COFF executable.

Is this header compatible with the ELF header? Con both co-exist in the 
same binary without issues?

> On Linux, this has the advantage of deferring the decompression of the
> bzImage (x86 Linux kernel file format) to the stub on the front of the
> bzImage. And while I realise that the toolstack already has support
> for decompressing bzImages, given what Andrew has said about reducing
> attack surface, having the guest perform the decompression should be a
> win.
> 
> Of course, this is offset somewhat by the fact that you need to audit
> the PE/COFF loader ;) But decompression in general is notoriously
> vulnerable to security issues.
> 
> Using the in-kernel decompressor is how most (all?) Linux boot loaders
> work today, so there's the added benefit of reducing the differences
> between booting on Xen and booting bare metal. For example, you'd
> probably be able to use CONFIG_RANDOMIZE_BASE (ASLR for kernel image)
> for Xen if you use the kernel's decompressor. Xen would also get
> future features in this area for free, and there is a tendency to push
> boot features into the early stub.

All the issues that you mention above are also solved by chainloading OVMF 
instead of directly loading the guest kernel, and it avoids adding a PE/COFF 
loader into Xen.

> For 1. we'd basically be using the PE/COFF file format with the EFI
> ABI as an OS agnostic boot protocol, but not as a full firmware
> runtime environment.

This also means that we will be adding PE/COFF headers to (uni)kernels, but 
we won't still implement full EFI support inside of them, so although it 
would seem like they are capable of being loaded by a native EFI loader, 
they would not.

This seems misleading, and I think it's going to cause grief amongst OS 
developers in general. The current proposed entry point is unique to Xen 
(it's only mentioned in Xen ELF notes), and is certainly not going to cause 
confusion at all.

Also, doesn't this (the fact that Xen will use the EFI entry point 
without a runtime environment) mean that ther

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

[Dario Faggioli]

On Tue, 2016-04-12 at 15:55 +0200, Olaf Hering wrote:
> 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 
>
Reviewed-by: Dario Faggioli 

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



signature.asc
Description: This is a digitally signed message part
___
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

[Andrew Cooper]

On 13/04/16 11:53, Corneliu ZUZU wrote:
> On 4/13/2016 1:17 PM, Andrew Cooper wrote:
>> On 13/04/16 09:55, Corneliu ZUZU wrote:
>>>
>>>


 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 looked at carefully.
>>>
>>> That seems to apply to single-stepping only, which would be a
>>> different matter. As for stealthiness or not limiting the guest, IMO
>>> that shouldn't be a problem with BKPT/BRK, since I believe you can
>>> inject the breakpoint exception into the guest as if no hypervisor
>>> trap occured in between (of course, once you decide whether that
>>> breakpoint is Xen's or guest-internal). But what about X86? How is
>>> stealthiness achieved there? Is INT3 entirely not available for the
>>> guest anymore when guest-debugging is enabled or are ALL INT3's
>>> reported by Xen as software breakpoint vm-events?
>>
>> In x86, attaching a debugger to the domain causes #DB and #BP
>> exceptions to be intercepted by Xen, rather than handled directly by
>> the domain (actually, since XSA-156, #DB is intercepted under all
>> circumstances, to avoid security issues).  The debugger receives all
>> debug events, and should filer the ones it has introduced vs the ones
>> present from in-guest activities.
>>
>> ~Andrew
>>
>> (Whether this works or not is a separate matter, and largely depends
>> on the debugger.) 
>
> And after this filtering, I guess if the debug event proves to be
> introduced by in-guest activities, the exception is reintroduced to
> preserve transparency, correct?

That is certainly the idea.

> I'm curious if behind the scenes Xen also write-protects that page
> such that the guest does not overwrite the INT3.

Haha.  I refer to my "Whether this works or not is a separate matter"
statement.

No-one has made a product feature out of external debugging of a guest,
which means there are almost certainly logic holes and bugs.  This
write-protection looks like a prime issue which hasn't been considered.

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

Re: [Xen-devel] [RFC PATCH] Data integrity extension support for xen-block

[Bob Liu]

On 04/07/2016 06:00 PM, Bob Liu wrote:
> * What's data integrity extension and why?
> Modern filesystems feature checksumming of data and metadata to protect 
> against
> data corruption.  However, the detection of the corruption is done at read 
> time
> which could potentially be months after the data was written.  At that point 
> the
> original data that the application tried to write is most likely lost.
> 
> The solution in Linux is the data integrity framework which enables protection
> information to be pinned to I/Os and sent to/received from controllers that
> support it. struct bio has been extended with a pointer to a struct bip which
> in turn contains the integrity metadata. The bip is essentially a trimmed down
> bio with a bio_vec and some housekeeping.
> 
> * Issues when xen-block get involved.
> xen-blkfront only transmits the normal data of struct bio while the integrity
> metadata buffer(struct bio_integrity_payload in each bio) is ignored.
> 
> * Proposal of transmitting bio integrity payload.
> Adding an extra request following the normal data request, this extra request
> contains the integrity payload.
> The xen-blkback will reconstruct an new bio with both received normal data and
> integrity metadata.
> 
> Welcome any better ideas, thank you!
> 

A simpler possible solution:

bob@boliuliu:~/xen$ git diff xen/include/public/io/blkif.h
diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
index 3d8d39f..34581a5 100644
--- a/xen/include/public/io/blkif.h
+++ b/xen/include/public/io/blkif.h
@@ -689,6 +689,11 @@ struct blkif_request_segment {
 struct blkif_request {
 uint8_toperation;/* BLKIF_OP_??? */
 uint8_tnr_segments;  /* number of segments   */
+/*
+ * Recording how many segments are data integrity segments.
+ * raw data_segments + dix_segments = nr_segments
+ */
+uint8_t   dix_segments;
 blkif_vdev_t   handle;   /* only for read/write requests */
 uint64_t   id;   /* private guest value, echoed in resp  */
 blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
@@ -715,6 +720,11 @@ struct blkif_request_indirect {
 uint8_toperation;/* BLKIF_OP_INDIRECT*/
 uint8_tindirect_op;  /* BLKIF_OP_{READ/WRITE}*/
 uint16_t   nr_segments;  /* number of segments   */
+/*
+ * Recording how many segments are data integrity segments.
+ * raw data_segments + dix_segments = nr_segments
+ */
+uint16_t   dix_segments;
 uint64_t   id;   /* private guest value, echoed in resp  */
 blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
 blkif_vdev_t   handle;   /* same as for read/write requests  */

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

[Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

[Razvan Cojocaru]

LOCK-prefixed instructions are currenly allowed to run in parallel
in x86_emulate(), which can lead the guest into an undefined state.
This patch fixes the issue.

Signed-off-by: Razvan Cojocaru 
---
 tools/tests/x86_emulator/test_x86_emulator.c | 12 
 xen/arch/x86/hvm/emulate.c   | 26 ++
 xen/arch/x86/mm.c|  3 +++
 xen/arch/x86/mm/shadow/common.c  |  4 
 xen/arch/x86/x86_emulate/x86_emulate.c   | 23 ++-
 xen/arch/x86/x86_emulate/x86_emulate.h   |  8 
 xen/common/domain.c  |  2 ++
 xen/include/asm-x86/domain.h |  4 
 xen/include/asm-x86/hvm/emulate.h|  3 +++
 9 files changed, 84 insertions(+), 1 deletion(-)

diff --git a/tools/tests/x86_emulator/test_x86_emulator.c 
b/tools/tests/x86_emulator/test_x86_emulator.c
index 86e298f..22e963b 100644
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -9,6 +9,8 @@
 
 #define __packed __attribute__((packed))
 
+typedef bool bool_t;
+
 #include "x86_emulate/x86_emulate.h"
 #include "blowfish.h"
 
@@ -160,6 +162,14 @@ int get_fpu(
 return X86EMUL_OKAY;
 }
 
+static void smp_lock(bool_t locked)
+{
+}
+
+static void smp_unlock(bool_t locked)
+{
+}
+
 static struct x86_emulate_ops emulops = {
 .read   = read,
 .insn_fetch = fetch,
@@ -167,6 +177,8 @@ static struct x86_emulate_ops emulops = {
 .cmpxchg= cmpxchg,
 .cpuid  = cpuid,
 .get_fpu= get_fpu,
+.smp_lock   = smp_lock,
+.smp_unlock = smp_unlock,
 };
 
 int main(int argc, char **argv)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index cc0b841..02096d5 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 
+DEFINE_PERCPU_RWLOCK_GLOBAL(emulate_locked_rwlock);
+
 static void hvmtrace_io_assist(const ioreq_t *p)
 {
 unsigned int size, event;
@@ -1616,6 +1618,26 @@ static int hvmemul_vmfunc(
 return rc;
 }
 
+void emulate_smp_lock(bool_t locked)
+{
+struct domain *d = current->domain;
+
+if ( locked )
+percpu_write_lock(emulate_locked_rwlock, &d->arch.emulate_lock);
+else
+percpu_read_lock(emulate_locked_rwlock, &d->arch.emulate_lock);
+}
+
+void emulate_smp_unlock(bool_t locked)
+{
+struct domain *d = current->domain;
+
+if ( locked )
+percpu_write_unlock(emulate_locked_rwlock, &d->arch.emulate_lock);
+else
+percpu_read_unlock(emulate_locked_rwlock, &d->arch.emulate_lock);
+}
+
 static const struct x86_emulate_ops hvm_emulate_ops = {
 .read  = hvmemul_read,
 .insn_fetch= hvmemul_insn_fetch,
@@ -1641,6 +1663,8 @@ static const struct x86_emulate_ops hvm_emulate_ops = {
 .put_fpu   = hvmemul_put_fpu,
 .invlpg= hvmemul_invlpg,
 .vmfunc= hvmemul_vmfunc,
+.smp_lock  = emulate_smp_lock,
+.smp_unlock= emulate_smp_unlock,
 };
 
 static const struct x86_emulate_ops hvm_emulate_ops_no_write = {
@@ -1668,6 +1692,8 @@ static const struct x86_emulate_ops 
hvm_emulate_ops_no_write = {
 .put_fpu   = hvmemul_put_fpu,
 .invlpg= hvmemul_invlpg,
 .vmfunc= hvmemul_vmfunc,
+.smp_lock  = emulate_smp_lock,
+.smp_unlock= emulate_smp_unlock,
 };
 
 static int _hvm_emulate_one(struct hvm_emulate_ctxt *hvmemul_ctxt,
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index bca7532..52a3c5d 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -112,6 +112,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -5319,6 +5320,8 @@ static const struct x86_emulate_ops ptwr_emulate_ops = {
 .insn_fetch = ptwr_emulated_read,
 .write  = ptwr_emulated_write,
 .cmpxchg= ptwr_emulated_cmpxchg,
+.smp_lock   = emulate_smp_lock,
+.smp_unlock = emulate_smp_unlock,
 };
 
 /* Write page fault handler: check if guest is trying to modify a PTE. */
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index ec87fb4..6d18430 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -283,6 +283,8 @@ static const struct x86_emulate_ops hvm_shadow_emulator_ops 
= {
 .insn_fetch = hvm_emulate_insn_fetch,
 .write  = hvm_emulate_write,
 .cmpxchg= hvm_emulate_cmpxchg,
+.smp_lock   = emulate_smp_lock,
+.smp_unlock = emulate_smp_unlock,
 };
 
 static int
@@ -351,6 +353,8 @@ static const struct x86_emulate_ops pv_shadow_emulator_ops 
= {
 .insn_fetch = pv_emulate_read,
 .write  = pv_emulate_write,
 .cmpxchg= pv_emulate_cmpxchg,
+.smp_lock   = emulate_smp_lock,
+.smp_unlock = emulate_smp_unlock,
 };
 
 const struct x86_emulate_ops *shadow_init_emulation(
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index 10a2959..aab934f 100

Re: [Xen-devel] [PATCH v2] x86/mm/pat: Fix BUG_ON in mmap_mem on QEMU/i386

[Toshi Kani]

On Wed, 2016-04-13 at 11:35 +0200, Ingo Molnar wrote:
> * Toshi Kani  wrote:
 :
> > 
> > However, this code block, originally written for Pentiums and
> > earlier, is no longer adequate since a 32-bit Xen guest has
> > MTRRs disabled and supports ZONE_HIGHMEM.  In this setup,
> > this code sets UC attribute for accessing RAM in high memory
> > range.
> > 
> > Delete this code block as it has been unused for a long time.
> > 
> > Reported-by: kernel test robot 
> > Link: https://lkml.org/lkml/2016/4/1/608
> > Signed-off-by: Toshi Kani 
> > Cc: Thomas Gleixner 
> > Cc: Ingo Molnar 
> > Cc: H. Peter Anvin 
> > Cc: Borislav Petkov 
> > Cc: David Vrabel 
>
> So you missed the Reviewed-by tag from Boris ...
>
> I've added it, but please try to propagate tags!

Thanks Ingo!

I decided to drop the Reviewed-by tag for v1 since v2 has a different
approach.

-Toshi

___
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 13, 2016 6:06 AM, "Andrew Cooper"  wrote:
>
> On 13/04/16 11:53, Corneliu ZUZU wrote:
>>
>> On 4/13/2016 1:17 PM, Andrew Cooper wrote:
>>>
>>> On 13/04/16 09:55, Corneliu ZUZU wrote:



>>>

 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 looked at carefully.


 That seems to apply to single-stepping only, which would be a
different matter. As for stealthiness or not limiting the guest, IMO that
shouldn't be a problem with BKPT/BRK, since I believe you can inject the
breakpoint exception into the guest as if no hypervisor trap occured in
between (of course, once you decide whether that breakpoint is Xen's or
guest-internal). But what about X86? How is stealthiness achieved there? Is
INT3 entirely not available for the guest anymore when guest-debugging is
enabled or are ALL INT3's reported by Xen as software breakpoint vm-events?
>>>
>>>
>>> In x86, attaching a debugger to the domain causes #DB and #BP
exceptions to be intercepted by Xen, rather than handled directly by the
domain (actually, since XSA-156, #DB is intercepted under all
circumstances, to avoid security issues).  The debugger receives all debug
events, and should filer the ones it has introduced vs the ones present
from in-guest activities.
>>>
>>> ~Andrew
>>>
>>> (Whether this works or not is a separate matter, and largely depends on
the debugger.)
>>
>>
>> And after this filtering, I guess if the debug event proves to be
introduced by in-guest activities, the exception is reintroduced to
preserve transparency, correct?
>
>
> That is certainly the idea.
>
>
>> I'm curious if behind the scenes Xen also write-protects that page such
that the guest does not overwrite the INT3.
>
>
> Haha.  I refer to my "Whether this works or not is a separate matter"
statement.
>
> No-one has made a product feature out of external debugging of a guest,
which means there are almost certainly logic holes and bugs.  This
write-protection looks like a prime issue which hasn't been considered.
>

In the DRAKVUF system that's exactly what I do, I mark the page execute
only so that the guest is unable to locate/overwrite injected breakpoints
without notice. If it were to overwrite injected breakpoints with its own,
then we would be able to tell that the trap is both for external and
internal use. So there isn't much of an issue there. The main issue is with
the racecondition in multi-vCPU guests when the purely external-use
breakpoint has to be removed to allow the guest to continue. It can be
solved nicely though with altp2m. I did a write-up for the Xen blog about
it a couple months ago and sent it to publicity but has not appeared yet.
Lars?

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

Re: [Xen-devel] [RFC PATCH] Data integrity extension support for xen-block

[Ian Jackson]

Bob Liu writes ("Re: [RFC PATCH] Data integrity extension support for 
xen-block"):
> A simpler possible solution:

As a syntax this is certainly simpler and quite probably preferable.

But NB that I regard your email as simply a sketch of the syntax.  We
also need (as discussed) a statement of the semantics.

Ian.

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

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

[Wei Liu]

On Wed, Apr 13, 2016 at 10:26:54AM +0100, Daniel P. Berrange wrote:
> On Wed, Apr 13, 2016 at 10:09:16AM +0100, George Dunlap wrote:
> > On Tue, Apr 12, 2016 at 10:31 PM, 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.
> > 
> > I think one of us isn't understanding the situation properly. Is it
> > not the case that currently, all releases of libvirt *will not
> > compile* against Xen 4.7 once it's released?  So people downloading
> > and building libvirt will have to either 1) root around and try to
> > figure out what version of Xen it will build against, 2) manually add
> > in a #define *with the correct API version* to a header somewhere to
> > make it build properly, or 3) update to a version of libvirt that
> > supports the new api (which at the moment hasn't even been released
> > yet)?
> > 
> > All of those options are completely unacceptable.  Older versions of
> > libvirt should Just Work when compiled against newer versions of Xen.
> > 
> > I think it does make sense to have the libvirt development branch not
> > specify an API version; but when it branches for release, it should
> > set LIBXL_API_VERSION to whatever the current version is at the time
> > of the branch.
> 
> FYI, libvirt doesn't do branching for releases - we always just cut the
> release straight from the master branch. We only actually create branches
> on demand, when we find we want to backport fixes to a previous release.
> 
> Does libvirt master really need to always use the latest API version ?
> 

No, it doesn't.

> It feels like libvirt could just set LIBXL_API_VERSION to the lowest
> version it requires in order to get the functionality we know we are
> able to currently build against. IOW, we'd only need to update the
> define for LIBXL_API_VERSION when we merge patches that actually need
> the newer functionality.
> 

That's sensible.

Wei.

> Regards,
> Daniel
> -- 
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o- http://virt-manager.org :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

[Xen-devel] [linux-linus test] 91109: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken REGR. 
vs. 59254
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 59254
 test-amd64-amd64-xl-credit2  14 guest-saverestore fail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail REGR. vs. 59254
 test-amd64-amd64-xl  17 guest-localmigrate/x10fail 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-i386-pair   22 guest-migrate/dst_host/src_host fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat 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 17 guest-localmigrate/x10fail 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  14 guest-saverestorefail blocked in 59254
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2  fail 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-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 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-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-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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 

Re: [Xen-devel] [RFC PATCH] Data integrity extension support for xen-block

[Juergen Gross]

On 13/04/16 14:22, Bob Liu wrote:
> 
> On 04/07/2016 06:00 PM, Bob Liu wrote:
>> * What's data integrity extension and why?
>> Modern filesystems feature checksumming of data and metadata to protect 
>> against
>> data corruption.  However, the detection of the corruption is done at read 
>> time
>> which could potentially be months after the data was written.  At that point 
>> the
>> original data that the application tried to write is most likely lost.
>>
>> The solution in Linux is the data integrity framework which enables 
>> protection
>> information to be pinned to I/Os and sent to/received from controllers that
>> support it. struct bio has been extended with a pointer to a struct bip which
>> in turn contains the integrity metadata. The bip is essentially a trimmed 
>> down
>> bio with a bio_vec and some housekeeping.
>>
>> * Issues when xen-block get involved.
>> xen-blkfront only transmits the normal data of struct bio while the integrity
>> metadata buffer(struct bio_integrity_payload in each bio) is ignored.
>>
>> * Proposal of transmitting bio integrity payload.
>> Adding an extra request following the normal data request, this extra request
>> contains the integrity payload.
>> The xen-blkback will reconstruct an new bio with both received normal data 
>> and
>> integrity metadata.
>>
>> Welcome any better ideas, thank you!
>>
> 
> A simpler possible solution:
> 
> bob@boliuliu:~/xen$ git diff xen/include/public/io/blkif.h
> diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
> index 3d8d39f..34581a5 100644
> --- a/xen/include/public/io/blkif.h
> +++ b/xen/include/public/io/blkif.h
> @@ -689,6 +689,11 @@ struct blkif_request_segment {
>  struct blkif_request {
>  uint8_toperation;/* BLKIF_OP_??? */
>  uint8_tnr_segments;  /* number of segments   */
> +/*
> + * Recording how many segments are data integrity segments.
> + * raw data_segments + dix_segments = nr_segments
> + */
> +uint8_t   dix_segments;
>  blkif_vdev_t   handle;   /* only for read/write requests */
>  uint64_t   id;   /* private guest value, echoed in resp  */
>  blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
> @@ -715,6 +720,11 @@ struct blkif_request_indirect {
>  uint8_toperation;/* BLKIF_OP_INDIRECT*/
>  uint8_tindirect_op;  /* BLKIF_OP_{READ/WRITE}*/
>  uint16_t   nr_segments;  /* number of segments   */
> +/*
> + * Recording how many segments are data integrity segments.
> + * raw data_segments + dix_segments = nr_segments
> + */
> +uint16_t   dix_segments;
>  uint64_t   id;   /* private guest value, echoed in resp  */
>  blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
>  blkif_vdev_t   handle;   /* same as for read/write requests  */
> 

Without having checked whether there were padding holes where you
introduced the new elements: this looks much better. As Ian already
pointed out: you should mention somewhere what the new segments are
containing (data layout description, possibly just a reference to a
hardware spec?).

Juergen

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

Re: [Xen-devel] [PATCH V2] 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..4c96968 100644
> --- a/xen/arch/x86/monitor.c
> +++ b/xen/arch/x86/monitor.c
> @@ -22,6 +22,58 @@
>  #include 
>  #include 
>
> +static int arch_monitor_enable_msr(struct domain *d, u32 msr)
>

IMHO there is no need to prepend the function names here with arch_ as
these are x86 specific so there never will be ARM equivalent.


> +{
> +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;
> +}
> +
> +static int arch_monitor_disable_msr(struct domain *d, u32 msr)
> +{
> +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 arch_monitor_is_msr_enabled(const struct domain *d, u32 msr)
> +{
> +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;
> +}
> +
>  int arch_monitor_domctl_event(struct domain *d,
>struct xen_domctl_monitor_op *mop)
>  {
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Razvan Cojocaru]

On 04/13/2016 05:50 PM, Tamas K Lengyel wrote:
> 
> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
> index 1fec412..4c96968 100644
> --- a/xen/arch/x86/monitor.c
> +++ b/xen/arch/x86/monitor.c
> @@ -22,6 +22,58 @@
>  #include 
>  #include 
> 
> +static int arch_monitor_enable_msr(struct domain *d, u32 msr)
> 
> 
> IMHO there is no need to prepend the function names here with arch_ as
> these are x86 specific so there never will be ARM equivalent.

That's true. I'll remove the prefix.


Thanks,
Razvan

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

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

[Tamas K Lengyel]

> >> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> >> index 2457698..875c09a 100644
> >> --- a/xen/include/public/domctl.h
> >> +++ b/xen/include/public/domctl.h
> >> @@ -1107,8 +1107,7 @@ struct xen_domctl_monitor_op {
> >>  } mov_to_cr;
> >>
> >>  struct {
> >> -/* Enable the capture of an extended set of MSRs */
> >> -uint8_t extended_capture;
> >> +uint32_t msr;
> >
> > Whoa there. Isn't it expanding the structure? Will this be backwards
> > compatible? What if somebody is using an older version of xen-access
> > against this hypervisor? Will they work?
> >
> > Perhaps this should have a new struct / sub-ops? And the old
> > 'mov_to_msr' will just re-use this new fangled code?
>
> In addition to Andrew's comments, I think simply changing
> VM_EVENT_INTERFACE_VERSION should be enough for xen-access-like clients
> to figure out the incompatibility.
>


This is an independent system from VM_EVENT, so IMHO the two shouldn't be
mixed. The union size right now is 24-bits so if a uint16_t is enough for
the bitmask that should be used instead. That way we don't end up growing
the struct size.

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

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

[Razvan Cojocaru]

On 04/13/2016 05:52 PM, Tamas K Lengyel wrote:
> 
> >> diff --git a/xen/include/public/domctl.h
> b/xen/include/public/domctl.h
> >> index 2457698..875c09a 100644
> >> --- a/xen/include/public/domctl.h
> >> +++ b/xen/include/public/domctl.h
> >> @@ -1107,8 +1107,7 @@ struct xen_domctl_monitor_op {
> >>  } mov_to_cr;
> >>
> >>  struct {
> >> -/* Enable the capture of an extended set of MSRs */
> >> -uint8_t extended_capture;
> >> +uint32_t msr;
> >
> > Whoa there. Isn't it expanding the structure? Will this be backwards
> > compatible? What if somebody is using an older version of xen-access
> > against this hypervisor? Will they work?
> >
> > Perhaps this should have a new struct / sub-ops? And the old
> > 'mov_to_msr' will just re-use this new fangled code?
> 
> In addition to Andrew's comments, I think simply changing
> VM_EVENT_INTERFACE_VERSION should be enough for xen-access-like clients
> to figure out the incompatibility.
> 
> 
> 
> This is an independent system from VM_EVENT, so IMHO the two shouldn't
> be mixed. The union size right now is 24-bits so if a uint16_t is enough
> for the bitmask that should be used instead. That way we don't end up
> growing the struct size.

Right. Well, MSR-s seem to be passed around as 32-bit unsigned integers
everywhere in the Xen source code, so unless that also needs correcting
then unfortunately it'll have to grow.


Thanks,
Razvan

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

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

[Andrew Cooper]

On 13/04/16 15:56, Razvan Cojocaru wrote:
> On 04/13/2016 05:52 PM, Tamas K Lengyel wrote:
>> >> diff --git a/xen/include/public/domctl.h
>> b/xen/include/public/domctl.h
>> >> index 2457698..875c09a 100644
>> >> --- a/xen/include/public/domctl.h
>> >> +++ b/xen/include/public/domctl.h
>> >> @@ -1107,8 +1107,7 @@ struct xen_domctl_monitor_op {
>> >>  } mov_to_cr;
>> >>
>> >>  struct {
>> >> -/* Enable the capture of an extended set of MSRs */
>> >> -uint8_t extended_capture;
>> >> +uint32_t msr;
>> >
>> > Whoa there. Isn't it expanding the structure? Will this be backwards
>> > compatible? What if somebody is using an older version of xen-access
>> > against this hypervisor? Will they work?
>> >
>> > Perhaps this should have a new struct / sub-ops? And the old
>> > 'mov_to_msr' will just re-use this new fangled code?
>>
>> In addition to Andrew's comments, I think simply changing
>> VM_EVENT_INTERFACE_VERSION should be enough for xen-access-like clients
>> to figure out the incompatibility.
>>
>>
>>
>> This is an independent system from VM_EVENT, so IMHO the two shouldn't
>> be mixed. The union size right now is 24-bits so if a uint16_t is enough
>> for the bitmask that should be used instead. That way we don't end up
>> growing the struct size.
> Right. Well, MSR-s seem to be passed around as 32-bit unsigned integers
> everywhere in the Xen source code, so unless that also needs correcting
> then unfortunately it'll have to grow.

MSR indices are always 32bits wide, as they live specifically in %ecx
when encoded for instructions.

Only 2K MSRs are currently specified in hardware, with some extra ones
in the hypervisor range, but this doesn't mean that list won't grow in
the future.

~Andrew

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

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

[Tamas K Lengyel]

On Wed, Apr 13, 2016 at 9:01 AM, Andrew Cooper 
wrote:

> On 13/04/16 15:56, Razvan Cojocaru wrote:
> > On 04/13/2016 05:52 PM, Tamas K Lengyel wrote:
> >> >> diff --git a/xen/include/public/domctl.h
> >> b/xen/include/public/domctl.h
> >> >> index 2457698..875c09a 100644
> >> >> --- a/xen/include/public/domctl.h
> >> >> +++ b/xen/include/public/domctl.h
> >> >> @@ -1107,8 +1107,7 @@ struct xen_domctl_monitor_op {
> >> >>  } mov_to_cr;
> >> >>
> >> >>  struct {
> >> >> -/* Enable the capture of an extended set of MSRs */
> >> >> -uint8_t extended_capture;
> >> >> +uint32_t msr;
> >> >
> >> > Whoa there. Isn't it expanding the structure? Will this be
> backwards
> >> > compatible? What if somebody is using an older version of
> xen-access
> >> > against this hypervisor? Will they work?
> >> >
> >> > Perhaps this should have a new struct / sub-ops? And the old
> >> > 'mov_to_msr' will just re-use this new fangled code?
> >>
> >> In addition to Andrew's comments, I think simply changing
> >> VM_EVENT_INTERFACE_VERSION should be enough for xen-access-like
> clients
> >> to figure out the incompatibility.
> >>
> >>
> >>
> >> This is an independent system from VM_EVENT, so IMHO the two shouldn't
> >> be mixed. The union size right now is 24-bits so if a uint16_t is enough
> >> for the bitmask that should be used instead. That way we don't end up
> >> growing the struct size.
> > Right. Well, MSR-s seem to be passed around as 32-bit unsigned integers
> > everywhere in the Xen source code, so unless that also needs correcting
> > then unfortunately it'll have to grow.
>
> MSR indices are always 32bits wide, as they live specifically in %ecx
> when encoded for instructions.
>
> Only 2K MSRs are currently specified in hardware, with some extra ones
> in the hypervisor range, but this doesn't mean that list won't grow in
> the future.
>

Yea, well then we need to introduce a new struct with a new subop to pass
the bitmask. I guess its a lesson in ABI design to leave some wiggle room
for future-proofing it (my bad). So I guess we can introduce
XEN_DOMCTL_MONITOR_OP_ENABLE_V2 and struct xen_domctl_monitor_op_v2 where
say expand the union to uint64_t just in case?

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

[Lars Kurth]

> On 13 Apr 2016, at 14:25, Tamas K Lengyel  wrote:
> In the DRAKVUF system that's exactly what I do, I mark the page execute only 
> so that the guest is unable to locate/overwrite injected breakpoints without 
> notice. If it were to overwrite injected breakpoints with its own, then we 
> would be able to tell that the trap is both for external and internal use. So 
> there isn't much of an issue there. The main issue is with the racecondition 
> in multi-vCPU guests when the purely external-use breakpoint has to be 
> removed to allow the guest to continue. It can be solved nicely though with 
> altp2m. I did a write-up for the Xen blog about it a couple months ago and 
> sent it to publicity but has not appeared yet. Lars?
> 
Tamas,

it hasn't because I was under the impression that Razvan and you disagreed on 
some aspects of the article. And then I forgot to chase either of you. I am 
happy with the article: feel free to upload it to the blog (or let me know, if 
I should) and press the button. Apologies

I think there are a couple of minor knit-picks, such as replace "In the latest 
release of Xen last summer several new features have been introduced" In "Xen 
4.6 several new features have been introduced" ... assuming 4.6 is correct

I will reply to publicity

Regards
Lars

___
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 Wed, Apr 13, 2016 at 9:06 AM, Lars Kurth 
wrote:

>
> On 13 Apr 2016, at 14:25, Tamas K Lengyel 
> wrote:
>
> In the DRAKVUF system that's exactly what I do, I mark the page execute
> only so that the guest is unable to locate/overwrite injected breakpoints
> without notice. If it were to overwrite injected breakpoints with its own,
> then we would be able to tell that the trap is both for external and
> internal use. So there isn't much of an issue there. The main issue is with
> the racecondition in multi-vCPU guests when the purely external-use
> breakpoint has to be removed to allow the guest to continue. It can be
> solved nicely though with altp2m. I did a write-up for the Xen blog about
> it a couple months ago and sent it to publicity but has not appeared yet.
> Lars?
>
> Tamas,
>
> it hasn't because I was under the impression that Razvan and you disagreed
> on some aspects of the article. And then I forgot to chase either of you. I
> am happy with the article: feel free to upload it to the blog (or let me
> know, if I should) and press the button. Apologies
>
> I think there are a couple of minor knit-picks, such as replace "In the
> latest release of Xen last summer several new features have been
> introduced" In "Xen 4.6 several new features have been introduced" ...
> assuming 4.6 is correct
>
> I will reply to publicity
>
> Regards
> Lars
>

Hey Lars,
I think the discussion with Razvan was mostly just around the difference of
our perception of how emulation based solutions fare compared to altp2m. I
think it's a discussion that actually could continue on the blogpost
comment wall, or if Razvan feel like it in a follow-up blogpost ;) So feel
free to make any changes to the article you see fit and hit release
whenever you feel like.

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

Re: [Xen-devel] [PATCH v5 01/14] x86/boot: enumerate documentation for the x86 hardware_subarch

[Luis R. Rodriguez]

On Wed, Apr 13, 2016 at 10:01:32AM +0200, Ingo Molnar wrote:
> > diff --git a/arch/x86/include/uapi/asm/bootparam.h 
> > b/arch/x86/include/uapi/asm/bootparam.h
> > index 329254373479..bf9fea2f4591 100644
> > --- a/arch/x86/include/uapi/asm/bootparam.h
> > +++ b/arch/x86/include/uapi/asm/bootparam.h
> > @@ -157,7 +157,42 @@ struct boot_params {
> > __u8  _pad9[276];   /* 0xeec */
> >  } __attribute__((packed));
> >  
> > -enum {
> > +/**
> > + * enum x86_hardware_subarch - x86 hardware subarchitecture
> 
> Could you add some prominent warning here, like:
> 
> > + * WARNING: the 'x86 subarch flag' is only used for legacy hacks, for 
> > platform
> > + *  features that are not easily enumerated or discoverable. You 
> > should
> > + *  not ever use this for new features.

With pleasure, added.

  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]

>
>
>
>>>
 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 looked at carefully.
>
>
> That seems to apply to single-stepping only, which would be a different
> matter.
>

If you read the commit message on the previous patch in that thread that
actually enables TDE trapping (
https://lists.cs.columbia.edu/pipermail/kvmarm/2015-May/014621.html) it
says: "Any other guest software debug exception (e.g. single step or HW
assisted breakpoints) will cause an error and the VM to be killed." So it
sounds to me singlestep on ARM is also routed as a software debug exception
and thus would be trapped (again, I would need to double-check the manual).
The follow up patch I linked earlier implements handling it but requires
the supression of the guest being able to singlestep itself. We might be
able to work around that if we can reinject the singlestep exception to the
guest. So all I'm saying is that this needs to be looked at carefully as
there may be issues there, especially for the use-case I have in mind.

And while having singlestepping trap to the hypervisor is very handy I
actually have a better method to hide the presence of say injected SMCs,
albeit it requires altp2m. Fortunately we have some students who proposed
implementing it this summer through the Honeynet Project's Google Summer of
Code ;)

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

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

[osstest service owner]

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

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 in 90979 REGR. 
vs. 86513
 test-amd64-amd64-xl-qemuu-win7-amd64 20 leak-check/check fail in 90979 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 
91130
 test-amd64-amd64-i386-pvgrub  9 debian-di-install  fail in 90846 pass in 91130
 test-armhf-armhf-xl-arndale   6 xen-boot   fail in 90979 pass in 91130
 test-armhf-armhf-xl-vhd   9 debian-di-install  fail in 90979 pass in 91130
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail pass in 
90846
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
pass in 90979
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat   fail pass in 90979
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop   fail pass in 90979
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail pass in 90979

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-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 86513
 test-amd64-amd64-xl-qemut-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-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-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 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-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
 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:
 linuxb36eba9b4dd4344ed51b8f644049aeac606ccff2
baseline version:
 linuxd439e869d612dd7a338ac75a4afc3646a5e67370

Last test of basis86513  2016-03-17 21:21:40 Z   26 days
Testing same since89247  2016-04-06 22:15:59 Z6 days5 attempts


People who touc

Re: [Xen-devel] [PATCH v5 07/14] tools/lguest: force disable tboot and apm

[Luis R. Rodriguez]

On Wed, Apr 13, 2016 at 10:44:46AM +0200, Ingo Molnar wrote:
> 
> * Luis R. Rodriguez  wrote:
> 
> > The paravirt_enabled() check is going away, the area tossed to
> > the kernel on lguest is not zerored out, so ensure lguest force
> > disables tboot and apm just in case the kernel file being read might
> > have this set for whatever reason.
> > 
> > Signed-off-by: Luis R. Rodriguez 
> > ---
> >  tools/lguest/lguest.c | 6 ++
> >  1 file changed, 6 insertions(+)
> 
> Yeah, so the v4 patch was acked by Rusty:
> 
>   Acked-by: Rusty Russell 
> 
> ... but you didn't add his ack to the v5 patch :-(

Sorry about that. Added.

> Please don't do this! Also please double check all past replies to make sure 
> no 
> acks got lost. I noticed this one, but there might be more.

I thought I had only left out the Acks for patches I later modified
significantly. Sorry. Will revise.

  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

[George Dunlap]

On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez  wrote:
> So more to it, if the EFI entry already provides a way into Linux
> in a more streamlined fashion bringing it closer to the bare metal
> boot entry, why *would* we add another boot entry to x86, even if
> its small and self contained ?

We would avoid using EFI if:

* Being called both on real hardware and under Xen would make the EFI
entry point more complicated

* Adding the necessary EFI support into Xen would be a significant
chunk of extra work

* Requiring PVH mode to implement EFI would make it more difficult for
other kernes (NetBSD, FreeBSD) to act as dom0s.

* Requiring PVH mode to use EFI would make it more difficult to
support unikernel-style workloads for domUs.

Now as has been pointed out, we don't know for a lot of the above
things for certain, because nobody has posted any code.  None of us
really want to post any code because:

* Reading and understanding the EFI spec, the Linux EFI path, and
implementing all that on both the Xen and the Linux side is a lot of
work

* It looks pretty likely that many of the above things will be true

* The only real objection to the currently proposed solution is really weak.

If you want to post some code I'm sure we could give you feedback on it.

> Another position against small stubs which I listed myself is that we may need
> more semantics for early boot even if the new HVMLite small stub is added. 
> This
> remains to be seen. If we are going to add new semantics, it would seem best 
> to
> use something more standard like EFI configuration tables rather than hack on
> to x86 further custom semantics. Custom sloppy semantics have proven to be
> misused, and were ultimately a sloppy mess.
[snip]
>> That sounds like it's going to make the EFI path just as unmanageable as the
>> current PV path.
>
> Can you describe how?
>
>> Using the EFI entry point would certainly make sense if it was
>> actually simpler than the proposed extra entry point.  But it sounds
>> like it's going to be more complicated, not only for Xen, but also for
>> Linux.
>
> How so? Please provide specifics.

Here is the juxtaposition that confuses me.  The problem with a lot of
the current code is that you have virtualization-specific hacks all
over the place making things complicated.  And in the first quote
above, you seem afraid that the extra entry point with stub code will
somehow be misused and end up in a similar "sloppy mess", even though
it's not at all clear how *having a stub entry point* could be
"abused" by anyone.  But then when I suggest that sharing a codepath
between systems that have actual EFI firmware, with platform hardware,
and a system that has no EFI firmware and no similar concept of the
hardware, might end up a sloppy mess of Xen-specific if clauses and
maintenance headaches due to broken assumptions, it doesn't even
register with you as a reasonable concern?

As Matt said, nobody will be able to provide specifics until someone
tries to code it up.  But coding things up is not free.

 -George

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

[Xen-devel] [for-4.7 0/2] xen/arm: traps: Correctly interpret the content of the register HPFAR_EL2

[Julien Grall]

Hello,

This small patch series is a bug fix for Xen 4.7 and should also be backported
to Xen 4.6.

Without it, the faulting IPA reported to memaccess may be wrong.

Regards,

Cc: wei.l...@citrix.com

Julien Grall (2):
  xen/bitops: Introduce macros to generate mask
  xen/arm: traps: Correctly interpret the content of the register
HPFAR_EL2

 xen/arch/arm/traps.c| 11 +--
 xen/include/asm-arm/processor.h |  7 +++
 xen/include/xen/bitops.h| 11 +++
 3 files changed, 27 insertions(+), 2 deletions(-)

-- 
1.9.1


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

[Xen-devel] [for-4.7 2/2] xen/arm: traps: Correctly interpret the content of the register HPFAR_EL2

[Julien Grall]

The register HPFAR_EL2 (resp. HPFAR on arm32) contains the bits [47:12]
(resp. [39:12]) of the faulting IPA. Unlike other registers that represent
an address, the upper bits of the IPA are stored in the register bits
[4:39] (resp. [4:21]).

However, Xen assumes that the register contains the faulting IPA correctly
offsetted. This will result to get a wrong IPA when the fault is happening
during a translation table walk. Note this is only affecting  memaccess.

Introduce a new helper to get the faulting IPA from HPFAR_EL2 and
replace direct read from the register by the helper.

Signed-off-by: Julien Grall 

---
Cc: ta...@tklengyel.com

This is a bug fix for Xen 4.7 and should also be backported to Xen 4.6.
Without this patch, the faulting IPA reported to memaccess may be wrong.

---
 xen/arch/arm/traps.c| 11 +--
 xen/include/asm-arm/processor.h |  7 +++
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 1516abd..5e865cf 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2363,6 +2363,13 @@ done:
 if (first) unmap_domain_page(first);
 }
 
+static inline paddr_t get_faulting_ipa(void)
+{
+register_t hpfar = READ_SYSREG(HPFAR_EL2);
+
+return ((paddr_t)(hpfar & HPFAR_MASK) << (12 - 4));
+}
+
 static void do_trap_instr_abort_guest(struct cpu_user_regs *regs,
   const union hsr hsr)
 {
@@ -2381,7 +2388,7 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 };
 
 if ( hsr.iabt.s1ptw )
-gpa = READ_SYSREG(HPFAR_EL2);
+gpa = get_faulting_ipa();
 else
 {
 /*
@@ -2431,7 +2438,7 @@ static void do_trap_data_abort_guest(struct cpu_user_regs 
*regs,
 #endif
 
 if ( dabt.s1ptw )
-info.gpa = READ_SYSREG(HPFAR_EL2);
+info.gpa = get_faulting_ipa();
 else
 {
 rc = gva_to_ipa(info.gva, &info.gpa, GV2M_READ);
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 7e6eb66..6789cd0 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -565,6 +565,13 @@ union hsr {
 
 #define FSC_LL_MASK(_AC(0x03,U)<<0)
 
+/* HPFAR_EL2: Hypervisor IPA Fault Address Register */
+#ifdef CONFIG_ARM_64
+#define HPFAR_MASK GENMASK(39, 4)
+#else
+#define HPFAR_MASK GENMASK(31, 4)
+#endif
+
 /* Time counter hypervisor control register */
 #define CNTHCTL_EL2_EL1PCTEN (1u<<0) /* Kernel/user access to physical counter 
*/
 #define CNTHCTL_EL2_EL1PCEN  (1u<<1) /* Kernel/user access to CNTP timer regs 
*/
-- 
1.9.1


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

[Xen-devel] [for-4.7 1/2] xen/bitops: Introduce macros to generate mask

[Julien Grall]

The code has been imported from the header include/linux/bitops.h in
Linux v4.6-rc3.

Signed-off-by: Julien Grall 

---
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
---
 xen/include/xen/bitops.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index cb56f24..e1a4d93 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -3,6 +3,17 @@
 #include 
 
 /*
+ * Create a contiguous bitmask starting at bit position @l and ending at
+ * position @h. For example
+ * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0.
+ */
+#define GENMASK(h, l) \
+   (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h
+
+#define GENMASK_ULL(h, l) \
+   (((~0ULL) << (l)) & (~0ULL >> (BITS_PER_LONG_LONG - 1 - (h
+
+/*
  * ffs: find first bit set. This is defined the same way as
  * the libc and compiler builtin ffs routines, therefore
  * differs in spirit from the above ffz (man ffs).
-- 
1.9.1


___
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.

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested 
Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ 
but sane."):
> George Dunlap  04/12/16 11:58 AM >>>
> >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.

Earlier I wrote:

  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.

So as I see it we have two options actually seriously proposed:
Andrew's new hypercall, and Jan's additional argument (in the struct,
seems to be what Jan is mainly suggesting).

The new hypercall is neater but more new code - and involves a
deprecation plan; the additional argument is more messy but less
duplication.

I think either of these options is tolerable.  I don't see the need to
look further.

Frankly, I find the choice difficult.  But the bikeshed has to be
painted /some/ colour and we should make these decisions in a sensible
way and that means I and George (who've been called on to help decide)
need to put forward an opinion.

On balance I think I prefer Jan's suggestion, mostly on the grounds
that in case of dispute, disagreement, or uncertainty, it is (all
other things being equal) better to make smaller changes.  And if this
hypercall becomes _too_ much of a mess we can always replace it later
along the lines that Andrew suggests.

I look forward to hearing from George.

Thanks,
Ian.

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

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

[osstest service owner]

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

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 ba83f7e397f99d96cf145cf6698c1853558532d9
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  127 days
Failing since 65593  2015-12-08 23:44:51 Z  126 days  143 attempts
Testing same since91143  2016-04-12 16:01:10 Z1 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 18946 lines long.)

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

Re: [Xen-devel] Regarding Outreachy project on Improving CR Dashboard

[Priya]

Hello,

Forgot to CC the Xen-devel mailing list.

I have changed the code to add the tests, and now it is like you need to
provide the whole link of the mbox file rather than just the file name.

So,  $python3 createjson.py --mbox
http://lists.xenproject.org/archives/html/mbox/advisory-board-2013-05-2014-02--output
new.json should work instead of

 $ python3 createjson.py --mbox advisory-board-2014-02 --output new.json

I forgot to update the README file, and I have done that now. I will
try k['data']['Message-ID'] instead, and I would update soon. I'm working
on the testing part and I'll complete it soon.



*Priya V*
Amrita University
LinkedIn

| GitHub  | Bitbucket



On Mon, Apr 11, 2016 at 1:23 PM, Jesus M. Gonzalez-Barahona <
j...@bitergia.com> wrote:

> On Fri, 2016-04-08 at 19:33 +0530, Priya wrote:
> > Hello,
> >
> > I tried running the same command in new version of perceval.  I found
> > the following missing message id errors in perceval_mbox_parse.log
> > file. I am working on the testing part and I will be able to finish
> > it in one or two days.
> >
> > You can see the errors here [1]
> >
> > [1]:http://imgur.com/yVsIoCT
>
> Hi, Priya. I'm not sure about what exactly is causing your messages,
> since I cannot reproduce them (see below). But I still suspect that
> they may happen because in current versions of Perceval the data parsed
> from an mbox is no longer stored as first level key/data in the
> dictionary returned by Perceval for each message, but in data for key
> "data", which is itself a dictionary.
>
> In particular, in the code:
>
> -
>   for k in msg_json:
> try:
> if key == k['Message-ID'].strip('<>'):
> k['property'] = key
> -
>
> probably you should be checking for k['data']['Message-ID'] instead of
> just k['Message-ID'].
>
> Please, have a look at how recent versions of Perceval produce the
> dictionaries for each message...
>
> But as I said, I cannot reproduce your error. When running your most
> recent code right now (9a5abc47bbab3b06550) with the most recent
> Perceval/master code (53efc14001c806f0452) I get:
>
> 
> (perceval)jgb@expisito:~/src/outreachy/Dashboard/dashboard$ python3
> createjson.py --mbox advisory-board-2014-02 --output new.json
> Traceback (most recent call last):
>   File "createjson.py", line 96, in 
> main()
>   File "createjson.py", line 92, in main
> mparser.create_json(args.mbox,args.output)
>   File "createjson.py", line 59, in create_json
> messages = th.message_details(mbox_files)
>   File "/home/jgb/src/outreachy/Dashboard/dashboard/jwzthreading_r.py",
> line 338, in message_details
> urllib.request.urlretrieve(filename, 'mbox')
>   File "/usr/lib/python3.4/urllib/request.py", line 186, in urlretrieve
> with contextlib.closing(urlopen(url, data)) as fp:
>   File "/usr/lib/python3.4/urllib/request.py", line 161, in urlopen
> return opener.open(url, data, timeout)
>   File "/usr/lib/python3.4/urllib/request.py", line 449, in open
> req = Request(fullurl, data)
>   File "/usr/lib/python3.4/urllib/request.py", line 267, in __init__
> self.full_url = url
>   File "/usr/lib/python3.4/urllib/request.py", line 293, in full_url
> self._parse()
>   File "/usr/lib/python3.4/urllib/request.py", line 322, in _parse
> raise ValueError("unknown url type: %r" % self.full_url)
> ValueError: unknown url type: 'advisory-board-2014-02'
> -
>
> Could you please try to checkout and install exactly the same version
> of Perceval I'm using, and see if you get the same error? And if the
> above problem with the format returned by Perceval persists, maybe you
> can fix that too.
>
> Saludos,
>
> Jesus.
>
> --
> Bitergia: http://bitergia.com
> /me at Twitter: https://twitter.com/jgbarah
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH for-4.7] hotplug/Linux: fix same_vm check in block script

[Wei Liu]

The original same_vm check has two bugs. When stubdom is in use because
it relies on numeric domid to check if two domains are in fact the same
one.  Another one is that the check would fail when two stubdoms are
checked against each other.

The first bug is fixed by using uuid to identify a domain. The second
bug is fixed by comparing the domains two stubdoms serve.

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

This should fix osstest stubdom local migration test. Local migration
without stubdom is also tested and passed.
---
 tools/hotplug/Linux/block-common.sh | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/hotplug/Linux/block-common.sh 
b/tools/hotplug/Linux/block-common.sh
index 35110b4..f86a88c 100644
--- a/tools/hotplug/Linux/block-common.sh
+++ b/tools/hotplug/Linux/block-common.sh
@@ -112,14 +112,17 @@ same_vm()
   "$FRONTEND_UUID")
   local target=$(xenstore_read_default  "/local/domain/$FRONTEND_ID/target"   \
  "-1")
+  local targetvm=$(xenstore_read_default "/local/domain/$target/vm" "-1")
   local otarget=$(xenstore_read_default  "/local/domain/$otherdom/target"   \
  "-1")
   local otvm=$(xenstore_read_default  "/local/domain/$otarget/vm"   \
  "-1")
   otvm=${otvm%-1}
   othervm=${othervm%-1}
+  targetvm=${targetvm%-1}
   local frontend_uuid=${FRONTEND_UUID%-1}
   
-  [ "$frontend_uuid" = "$othervm" -o "$target" = "$otherdom" -o 
"$frontend_uuid" = "$otvm" ]
+  [ "$frontend_uuid" = "$othervm" -o "$targetvm" = "$othervm" -o \
+"$frontend_uuid" = "$otvm" -o "$targetvm" = "$otvm" ]
 }
 
-- 
2.1.4


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

Re: [Xen-devel] [for-4.7 1/2] xen/bitops: Introduce macros to generate mask

[Stefano Stabellini]

On Wed, 13 Apr 2016, Julien Grall wrote:
> The code has been imported from the header include/linux/bitops.h in
> Linux v4.6-rc3.
> 
> Signed-off-by: Julien Grall 

Acked-by: Stefano Stabellini 


> ---
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Keir Fraser 
> Cc: Tim Deegan 
>  xen/include/xen/bitops.h | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
> index cb56f24..e1a4d93 100644
> --- a/xen/include/xen/bitops.h
> +++ b/xen/include/xen/bitops.h
> @@ -3,6 +3,17 @@
>  #include 
>  
>  /*
> + * Create a contiguous bitmask starting at bit position @l and ending at
> + * position @h. For example
> + * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0.
> + */
> +#define GENMASK(h, l) \
> + (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h
> +
> +#define GENMASK_ULL(h, l) \
> + (((~0ULL) << (l)) & (~0ULL >> (BITS_PER_LONG_LONG - 1 - (h
> +
> +/*
>   * ffs: find first bit set. This is defined the same way as
>   * the libc and compiler builtin ffs routines, therefore
>   * differs in spirit from the above ffz (man ffs).
> -- 
> 1.9.1
> 

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

[Xen-devel] [linux-4.1 baseline-only test] 44328: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

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. 38526
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 38526
 test-amd64-i386-xl-qemuu-debianhvm-amd64 14 guest-saverestore.2 fail REGR. vs. 
38526

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 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-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 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-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   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-midway   12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 20 leak-check/checkfail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 linux7f30737678023b5becaf0e2e012665f71b886a7d
baseline version:
 linux07cc49f66973f49a391c91bf4b158fa0f2562ca8

Last test of basis38526  2015-12-16 16:53:24 Z  119 days
Testing same since44328  2016-04-13 11:24:00 Z0 days1 attempts


494 people touched revisions under test,
not listing them all

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
 build-amd64-rumpuserxen  fail
 build-i386-rumpuser

Re: [Xen-devel] [for-4.7 1/2] xen/bitops: Introduce macros to generate mask

[Andrew Cooper]

On 13/04/16 16:55, Julien Grall wrote:
> The code has been imported from the header include/linux/bitops.h in
> Linux v4.6-rc3.
>
> Signed-off-by: Julien Grall 
>
> ---
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Keir Fraser 
> Cc: Tim Deegan 
> ---
>  xen/include/xen/bitops.h | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
> index cb56f24..e1a4d93 100644
> --- a/xen/include/xen/bitops.h
> +++ b/xen/include/xen/bitops.h
> @@ -3,6 +3,17 @@
>  #include 
>  
>  /*
> + * Create a contiguous bitmask starting at bit position @l and ending at
> + * position @h. For example
> + * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0.
> + */
> +#define GENMASK(h, l) \
> + (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h
> +
> +#define GENMASK_ULL(h, l) \
> + (((~0ULL) << (l)) & (~0ULL >> (BITS_PER_LONG_LONG - 1 - (h

You should have just a single GENMASK() which works in terms of LL.

Masks must be signed to work correctly when implicitly extended.

~Andrew

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

Re: [Xen-devel] [for-4.7 2/2] xen/arm: traps: Correctly interpret the content of the register HPFAR_EL2

[Stefano Stabellini]

On Wed, 13 Apr 2016, Julien Grall wrote:
> The register HPFAR_EL2 (resp. HPFAR on arm32) contains the bits [47:12]
> (resp. [39:12]) of the faulting IPA. Unlike other registers that represent
> an address, the upper bits of the IPA are stored in the register bits
> [4:39] (resp. [4:21]).
> 
> However, Xen assumes that the register contains the faulting IPA correctly
> offsetted. This will result to get a wrong IPA when the fault is happening
> during a translation table walk. Note this is only affecting  memaccess.
> 
> Introduce a new helper to get the faulting IPA from HPFAR_EL2 and
> replace direct read from the register by the helper.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
> Cc: ta...@tklengyel.com
> 
> This is a bug fix for Xen 4.7 and should also be backported to Xen 4.6.
> Without this patch, the faulting IPA reported to memaccess may be wrong.
> 
> ---
>  xen/arch/arm/traps.c| 11 +--
>  xen/include/asm-arm/processor.h |  7 +++
>  2 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 1516abd..5e865cf 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2363,6 +2363,13 @@ done:
>  if (first) unmap_domain_page(first);
>  }
>  
> +static inline paddr_t get_faulting_ipa(void)
> +{
> +register_t hpfar = READ_SYSREG(HPFAR_EL2);
> +
> +return ((paddr_t)(hpfar & HPFAR_MASK) << (12 - 4));
> +}
> +
>  static void do_trap_instr_abort_guest(struct cpu_user_regs *regs,
>const union hsr hsr)
>  {
> @@ -2381,7 +2388,7 @@ static void do_trap_instr_abort_guest(struct 
> cpu_user_regs *regs,
>  };
>  
>  if ( hsr.iabt.s1ptw )
> -gpa = READ_SYSREG(HPFAR_EL2);
> +gpa = get_faulting_ipa();
>  else
>  {
>  /*
> @@ -2431,7 +2438,7 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  #endif
>  
>  if ( dabt.s1ptw )
> -info.gpa = READ_SYSREG(HPFAR_EL2);
> +info.gpa = get_faulting_ipa();
>  else
>  {
>  rc = gva_to_ipa(info.gva, &info.gpa, GV2M_READ);
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index 7e6eb66..6789cd0 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -565,6 +565,13 @@ union hsr {
>  
>  #define FSC_LL_MASK(_AC(0x03,U)<<0)
>  
> +/* HPFAR_EL2: Hypervisor IPA Fault Address Register */
> +#ifdef CONFIG_ARM_64
> +#define HPFAR_MASK   GENMASK(39, 4)
> +#else
> +#define HPFAR_MASK   GENMASK(31, 4)
> +#endif
> +
>  /* Time counter hypervisor control register */
>  #define CNTHCTL_EL2_EL1PCTEN (1u<<0) /* Kernel/user access to physical 
> counter */
>  #define CNTHCTL_EL2_EL1PCEN  (1u<<1) /* Kernel/user access to CNTP timer 
> regs */
> -- 
> 1.9.1
> 

___
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 Mon, Apr 11, 2016 at 07:12:08AM +0200, 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.

Sure.

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

Understood. George noted that on ARM dom0 still uses the ARM native entry
point, it seems to accomplish this as it uses a device tree node. I'll
chime in on that in another thread.

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

We also have other asm code which can be shared. I'll reply to Boris'
original e-mail with what I can identify as perhaps sharable. There is
obviously more as you allude.

> What would be gained by using the same entry but having two different boot
> paths after it?

Its a good question. In summary for me it would be the push for sharing more
code and the push for semantics on early boot to address differences
proactively, and ultimately it may enable us to help bring closer the old PV
boot path closer.

I'll elaborate on this but first let's clarify why a new entry is used for
HVMlite to start of with:

  1) Xen ABI has historically not wanted to set up the boot params for Linux
 guests, instead it insists on letting the Linux kernel Xen boot stubs fill
 that out for it. This sticking point means it has implicated a boot stub.
 The HVMLite boot entry tries to bring the boot entries paths closer as it
 leverages more of the HVM boot path philosophy to mimic the regular PC boot
 path.

 Is HVMLite supposed to support legacy PV guests as well BTW ?

 Reason I'm highlighting Xen ABI as a *reason* alone is that even with
 today's large discrepancy on the old PV boot path I believe we can
 bring together the boot paths closer together if the Xen ABI was slightly
 flexible about this, I've highlighted how I believe that is possible 
before,
 *iff* the Xen ABI would at the very least set 2 things only:

 a) Hypervisor type
 b) A custom data pointer

 This would enable a single boot entry on the guest to handle then:

Pseudo code:

startup_32() startup_64()
   |  |
   |  |
   V  V
pre_hypervisor_stub_32()pre_hypervisor_stub_64()
   |  |
   |  |
   V  V
 [existing startup_32()]   [existing startup_64()]
   |  |
   |  |
   V  V
post_hypervisor_stub_32()   post_hypervisor_stub_64()

 
 If the Xen ABI was flexible about setting a hypervisor type and custom
 data pointer then we would haven handlers for it, and in it, it can
 do w

[Xen-devel] [linux-3.14 test] 91148: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 linux55d37e17318fd5cf40b62fd02ce6ff75e422d862
baseline version:
 linuxdfbed80c63bb8d965067da3a6dbcc4682edcce0c

Last test of basis86411  2016-03-16 16:25:22 Z   28 days
Testing same since91148  2016-04-12 16:55:45 Z1 days1 attempts


People who touched revisions under test:
  Aaro Koskinen 
  Al Viro 
  Alex Deucher 
  Alexandre Bounine 
  Andi Kleen 
  Andrew Morton 
  Andy Lutomirski 
  Anton Staaf 
  Artem Bityutskiy 
  Aurelien Jacquiot 
  Bjorn Helgaas 
  Bjørn Mork 
  Borislav Petkov 
  Brian King 
  Brian Norris 
  Dan Carpenter 
  Dave Chinner 
  Dave Jones 
  Dmitry Torokhov 
  Dmitry Tunin 
  Douglas Gilbert 
  Eric Wheeler 
  Eric Wheeler 
  Gabriel Krisman Bertazi 
  Grazvydas Ignotas 
  Greg Kroah-Hartman 
  Guenter Roeck 
  Hans de Goede 
  Hans Verkuil 
  Hans Verkuil 
  Herbert Xu 
  Himanshu Madhani 
  Ingo Molnar 
  Insu Yun 
  Jann Horn 
  Jes Sorensen 
  Jiri Kosina 
  Jiri Olsa 
  Jiri Olsa 
  Johan Hovold 
  Joseph Qi 
  Josh Boyer 
  Julia Lawall 
  Kees Cook 
  Linus Torvalds 
  Marcel Holtmann 
  Mario Kleiner 
  Martin K. Petersen 
  Martyn Welch 
  Mateusz Guzik 
  Maurizio Lombardi 
  Mauro Carvalho Chehab 
  Max Filippov 
  Michael S. Tsirkin 
  Michal Marek 
  Ming Lei 
  Nicholas Bellinger 
  Nishanth Menon 
  OGAWA Hirofumi 
  Oliver Neukum 
  Paolo Bonzini 
  Peter Hurley 
  Peter Zijlstra (Intel) 
  Rabin Vincent 
  Radim Krčmář 
  Raghava Aditya Renukunta 
  Rik van Riel 
  Sebastian Frias 
  Shaohua Li 
  Steven Rostedt (Red Hat) 
  Steven Rostedt 
  Takashi Iwai 
  Theodore Ts'o 
  Thomas Gleixner 
  Tiffany Lin 
  Tom Lendacky 
  Vittorio Gambaletta (VittGam) 
  Vittorio Gambaletta 
  Vladis Dronov 
  Wim Van Sebroeck 

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
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm 

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

[Luis R. Rodriguez]

On Wed, Apr 13, 2016 at 11:54:29AM +0200, Roger Pau Monné wrote:
> On Fri, Apr 08, 2016 at 11:58:54PM +0200, Luis R. Rodriguez wrote:
> > 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
> 
> I'm not following here. What does it mean to fold legacy support under 
> HVMlite? HVMlite doesn't have any legacy hardware, and that's the issue when 
> it comes to using native Linux entry points. Linux might expect some legacy 
> PC hardware to be always present, which is not true for HVMlite.
> 
> Could you please clarify this point?

It seems there is a confusion on terms used. By folding legacy support under
HVMLite I meant folding legacy PV path (classic PV with PV interfaces) under
HVMlite.

I got the impression that if we wanted to remove the old PV path we had to see
if we can address old classic PV x86 guests through HVMlite, otherwise we'd
have to live with the old PV path for the long term.

> >   * 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).
> 
> Classic PV guests don't have legacy hardware at all, they just have PV 
> interfaces, so I'm even less sure of what this means.

Using the terms you use by "Leave legacy stuff on the old PV path" I meant 
not having to address classic PV guest support through HVMLite.

  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 Wed, Apr 13, 2016 at 11:05:00AM +0100, George Dunlap wrote:
> On Tue, Apr 12, 2016 at 11:12 PM, Luis R. Rodriguez  wrote:
> > 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.
> 
> I'm not sure how this is relevant to anything.

You brought DT as a reason why ARM was able to use the native point.
I'm clarifying DT has nothing to do as a restriction on x86.

> What we're talking about is how to get from Xen to a point in the
> Linux kernel where everything can Just Work.  The proposed feature is
> a mini trampoline that (as I understand it):
> 1. Tells Xen where to jump to (via ELF note)
> 2. Sets up some basic modes and pagetables and then jumps to the zero
> page so Linux can just carry on.

Right, and the my goal is to see to it we do enough homework to
ensure we reviewed all possibilities to share as much code as possible
already and looked at all options before saying we certainly need yet
another entry point. I am not convinced yet this has been done.

  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

[Konrad Rzeszutek Wilk]

On Wed, Apr 13, 2016 at 08:29:51PM +0200, Luis R. Rodriguez wrote:
> On Mon, Apr 11, 2016 at 07:12:08AM +0200, 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.
> 
> Sure.
> 
> > > 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.
> 
> Understood. George noted that on ARM dom0 still uses the ARM native entry
> point, it seems to accomplish this as it uses a device tree node. I'll
> chime in on that in another thread.
> 
> > > 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.
> 
> We also have other asm code which can be shared. I'll reply to Boris'
> original e-mail with what I can identify as perhaps sharable. There is
> obviously more as you allude.
> 
> > What would be gained by using the same entry but having two different boot
> > paths after it?
> 
> Its a good question. In summary for me it would be the push for sharing more
> code and the push for semantics on early boot to address differences
> proactively, and ultimately it may enable us to help bring closer the old PV
> boot path closer.

But why? We want to kill PV (eventually).
> 
> I'll elaborate on this but first let's clarify why a new entry is used for
> HVMlite to start of with:
> 
>   1) Xen ABI has historically not wanted to set up the boot params for Linux
>  guests, instead it insists on letting the Linux kernel Xen boot stubs 
> fill
>  that out for it. This sticking point means it has implicated a boot stub.


Which is b/c it has to be OS agnostic. It has nothing to do 'not wanting'.

>  The HVMLite boot entry tries to bring the boot entries paths closer as it
>  leverages more of the HVM boot path philosophy to mimic the regular PC 
> boot
>  path.
> 
>  Is HVMLite supposed to support legacy PV guests as well BTW ?

Gosh no.
> 
>  Reason I'm highlighting Xen ABI as a *reason* alone is that even with
>  today's large discrepancy on the old PV boot path I believe we can
>  bring together the boot paths closer together if the Xen ABI was slightly
>  flexible about this, I've highlighted how I believe that is possible 
> before,



>  *iff* the Xen ABI would at the very least set 2 things only:
> 
>  a) Hypervisor type
>  b) A custom data pointer
> 
>  This would enable a single boot entry on the guest to handle then:
> 
>   Pseudo code:
> 
>   startup_32() startup_64()
>  |  |
>  |  |
>  V  V
>   pre_hypervisor_stub_32()pre_hypervisor_stub_64()
>  |  |
>  |  |
>  V  V
>[existing startup_32()]   [existing startup_64

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

[Konrad Rzeszutek Wilk]

On Wed, Apr 13, 2016 at 08:50:10PM +0200, Luis R. Rodriguez wrote:
> On Wed, Apr 13, 2016 at 11:54:29AM +0200, Roger Pau Monné wrote:
> > On Fri, Apr 08, 2016 at 11:58:54PM +0200, Luis R. Rodriguez wrote:
> > > 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
> > 
> > I'm not following here. What does it mean to fold legacy support under 
> > HVMlite? HVMlite doesn't have any legacy hardware, and that's the issue 
> > when 
> > it comes to using native Linux entry points. Linux might expect some legacy 
> > PC hardware to be always present, which is not true for HVMlite.
> > 
> > Could you please clarify this point?
> 
> It seems there is a confusion on terms used. By folding legacy support under
> HVMLite I meant folding legacy PV path (classic PV with PV interfaces) under
> HVMlite.

Ewww.
> 
> I got the impression that if we wanted to remove the old PV path we had to see
> if we can address old classic PV x86 guests through HVMlite, otherwise we'd
> have to live with the old PV path for the long term.

No. We need to deprecate the PV paths - and the agreement we hammered out
with the x86 maintainers was that once PVH/HVMLite is stable the clock
would start ticking on PV (pvops) life. All the big users of PV Linux
were told in persons to prep them for this.

Keep in mind that this is not for deleting of support in hypervisor for
PV hypercalls - meaning you would still be able to run say 2.6.18 RHEL5
in years to come. It is just that Linux v6.1 won't have any more PV paths
and can only run in HVM or PVH/HVMLite mode under Xen.

> 
> > >   * 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).
> > 
> > Classic PV guests don't have legacy hardware at all, they just have PV 
> > interfaces, so I'm even less sure of what this means.
> 
> Using the terms you use by "Leave legacy stuff on the old PV path" I meant 
> not having to address classic PV guest support through HVMLite.
> 
>   Luis
> 
> ___
> 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] HVMLite / PVHv2 - using x86 EFI boot entry

[Luis R. Rodriguez]

On Wed, Apr 13, 2016 at 12:25:03PM +0200, Roger Pau Monné wrote:
> On Wed, Apr 13, 2016 at 12:12:25AM +0200, Luis R. Rodriguez wrote:
> [...]
> > 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.
> 
> I don't see how this is relevant to the conversation that's going on:

Its relevant as George brought up DT as a *reason* why ARM was able
to cope with no custom entry point...

> How many x86 hardware provide DT?


One. CE4100.

arch/x86/platform/ce4100/falconfalls.dt

> I bet this is 0%.

That's slightly more than 0%.

> How many OSes can boot on x86 using DT? Linux maybe, certainly FreeBSD, 
> Windows or OpenBSD won't be able to boot at all when provided a DT on x86.

You guys seem to be taking these things too personal. 

Let me repeat, my goal is to ensure we review things without a bias. The points
you make here *now* are things I welcome to the discussion as reasons for
ruling out DT as ways to fine tune further semantics, its however by no means
something we should have discarded.

> Is Xen going to craft a DT for x86 based on ACPI?  No, because it can't parse
> the DSDT or other dynamic tables that contain the information about the
> devices in the system.

Again, DT was brought up by George as reason why ARM was able to cope
with no custom entry point. That's all. What you raise is a good point
to highlight but it does not mean we can't use it if we wanted to for
other things, for instance as an alternative to extending the x86 boot
protocol with custom things which we may need to enhance semantics
early in boot. If that is a stupid prospect lets highlight that and
rule it out.

> I would also like to point out that DT or not DT is not really the problem 
> here, the issue that George was trying to point out is that on x86 there's 
> some legacy hardware that's considered to be always there, so it's presence 
> is not signaled by ACPI, and HVMlite is _not_ emulating this hardware. It 
> doesn't matter if the hardware description comes from ACPI or DT, this 
> hardware is considered to be always present on PC compatible hardware.

x86 Xen PV guests are not alone.  I'm adding quirks we can use to address this
in a clean way now which turns out to be very useful for other custom x86
platforms.

  Luis

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

Re: [Xen-devel] [for-4.7 2/2] xen/arm: traps: Correctly interpret the content of the register HPFAR_EL2

[Tamas K Lengyel]

On Wed, Apr 13, 2016 at 9:55 AM, Julien Grall  wrote:

> The register HPFAR_EL2 (resp. HPFAR on arm32) contains the bits [47:12]
> (resp. [39:12]) of the faulting IPA. Unlike other registers that represent
> an address, the upper bits of the IPA are stored in the register bits
> [4:39] (resp. [4:21]).
>
> However, Xen assumes that the register contains the faulting IPA correctly
> offsetted. This will result to get a wrong IPA when the fault is happening
> during a translation table walk. Note this is only affecting  memaccess.
>
> Introduce a new helper to get the faulting IPA from HPFAR_EL2 and
> replace direct read from the register by the helper.
>
> Signed-off-by: Julien Grall 
>

Thanks for the fix, I totally missed that. I did notice not getting any
events for translation table-walks so at least now I know why.

Tamas
___
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 Wed, Apr 13, 2016 at 03:02:26PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Apr 13, 2016 at 08:50:10PM +0200, Luis R. Rodriguez wrote:
> > On Wed, Apr 13, 2016 at 11:54:29AM +0200, Roger Pau Monné wrote:
> > > On Fri, Apr 08, 2016 at 11:58:54PM +0200, Luis R. Rodriguez wrote:
> > > > 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
> > > 
> > > I'm not following here. What does it mean to fold legacy support under 
> > > HVMlite? HVMlite doesn't have any legacy hardware, and that's the issue 
> > > when 
> > > it comes to using native Linux entry points. Linux might expect some 
> > > legacy 
> > > PC hardware to be always present, which is not true for HVMlite.
> > > 
> > > Could you please clarify this point?
> > 
> > It seems there is a confusion on terms used. By folding legacy support under
> > HVMLite I meant folding legacy PV path (classic PV with PV interfaces) under
> > HVMlite.
> 
> Ewww.

Probably a confusion again on terms, by the above I meant to say what you seem
to be indicating below, which is to keep old PV guest support with PV interfaces
using a new shiny entry.

Or are we really going to nuke full support for old PV guests ?

> > I got the impression that if we wanted to remove the old PV path we had to 
> > see
> > if we can address old classic PV x86 guests through HVMlite, otherwise we'd
> > have to live with the old PV path for the long term.
> 
> No. We need to deprecate the PV paths - and the agreement we hammered out
> with the x86 maintainers was that once PVH/HVMLite is stable the clock
> would start ticking on PV (pvops) life. All the big users of PV Linux
> were told in persons to prep them for this.

That's nice. *How* that is done is what we are determining here.

> Keep in mind that this is not for deleting of support in hypervisor for
> PV hypercalls - meaning you would still be able to run say 2.6.18 RHEL5
> in years to come. It is just that Linux v6.1 won't have any more PV paths
> and can only run in HVM or PVH/HVMLite mode under Xen.

Sure.

  Luis

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