Re: [Xen-devel] [PATCH 2/3] x86/HVM: support (emulate) UMIP
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Thursday, December 08, 2016 12:07 AM > > On 07/12/16 15:39, Jan Beulich wrote: > On 07.12.16 at 16:31, wrote: > >> On 12/07/2016 10:14 AM, Jan Beulich wrote: > >> On 07.12.16 at 16:10, wrote: > On 12/07/2016 06:29 AM, Jan Beulich wrote: > On 06.12.16 at 17:23, wrote: > >> On 12/06/2016 06:44 AM, Jan Beulich wrote: > >>> --- a/xen/arch/x86/cpuid.c > >>> +++ b/xen/arch/x86/cpuid.c > >>> @@ -154,6 +154,13 @@ static void __init calculate_hvm_feature > >>> __set_bit(X86_FEATURE_APIC, hvm_featureset); > >>> > >>> /* > >>> + * Xen can often provide UMIP emulation to HVM guests even if > >>> the host > >>> + * doesn't have such functionality. > >>> + */ > >>> +if ( cpu_has_vmx_dt_exiting || cpu_has_svm ) > >>> +__set_bit(X86_FEATURE_UMIP, hvm_featureset); > >> I don't think I understand how this is going to work for processors > >> that > >> don't support UMIP. > >> > >> How, for example, can guest_cr[4] have X86_CR4_UMIP set on these > >> processors when CPUID will not show the feature being there? > > What we allow the guest to see and what we store into hardware > > registers are two different things: Note how svm_update_guest_cr() > > masks off X86_CR4_UMIP from the vale to be put into the VMCB. > So that was kind of my question --- why would a guest ever try to set > this bit? As far as it is concerned, UMIP is not available and the guest > is then trying to set an unsupported bit in cr4. And that should result > in a #GP. > >>> But the code fragment above adds the respective CPUID bit to the > >>> permitted features. Believe me, I've tried this with a UMIP-enabled > >>> Linux (including proper CPUID based detection). > >> Are you referring to these patches: https://lkml.org/lkml/2016/11/8/68 ? > >> If yes then they look to be Intel-specific. > > No, I had written my own before these had been posted. I did > > actually post mine too, but that was a week or so after theirs, > > and theirs appears to be more complete. > > > >> If AMD decides to use CPUID0x7.ecx[2] for something else --- won't this > >> be a problem for this patch? > > I think the two vendors meanwhile do a good job not interfering with > > one another's CPUID bits. We'd have ugly problems elsewhere if any > > new dual purpose CPUID bit appeared. > > [root@minuet-1 ~]# head /proc/cpuinfo > processor: 0 > vendor_id: AuthenticAMD > cpu family: 21 > model: 96 > > [root@minuet-1 ~]# xen-cpuid > nr_features: 10 > KEY 1d 1c e1d e1c Da1 > 7b0 7c0 e7d e8b 7d0 > > Static sets: > Known > b7ebfbff:fffef3ff:efd3fbff:2469bfff:000f:fdbf:001b:0500:0001: > 000c > Special > 1200:8820::0002::2040:0010::000 > 0: > PV Mask > 17c9cbf5:f6f83203:e2500800:042109e3:0007:fdaf0b39:0003:: > 0001:000c > HVM Shadow Mask > 17cbfbff:f7f83223:ea500800:04218df7:000f:fdbf4bbb:0003::0 > 001:000c > HVM Hap Mask > 17cbfbff:f7fa3223:ee500800:04218df7:000f:fdbf4fbb:000b::0 > 001:000c > > Dynamic sets: > Raw > 178bfbff:fed8320b:2fd3fbff:2febbfff:0001:01a9::37d9:00 > 00: > Host > 178bf3ff:f6d8320b:2fd3fbff:2469bfff:0001:01a9::0500:0 > 000: > PV > 1789c3f5:f6f83203:23d1cbf5:042109e3:0001:0129::: > : > HVM > 178bfbff:f6f83203:2fd3fbff:04218df7:0001:01a9:::0 > 000: > > > This processor already implements some of Intel's features from > 0x7[0].ebx, including SMEP. According to marketing, AMD Zen processors > will add the ADX, RDSEED, SHA, CLFLUSHOPT and SMAP features > > I can't reasonably see them using a different feature word. > > ~Andrew There is agreement that common features will use the same fields. Thanks Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-3.18 test] 103008: regressions - trouble: broken/fail/pass
flight 103008 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/103008/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101675 test-amd64-i386-libvirt-pair 9 xen-boot/src_hostfail REGR. vs. 101675 test-amd64-i386-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 101675 test-amd64-amd64-amd64-pvgrub 6 xen-bootfail REGR. vs. 101675 test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-bootfail REGR. vs. 101675 test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101675 test-amd64-i386-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-libvirt-xsm 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-libvirt-pair 9 xen-boot/src_host fail REGR. vs. 101675 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail REGR. vs. 101675 test-amd64-amd64-qemuu-nested-intel 6 xen-boot fail REGR. vs. 101675 test-amd64-amd64-xl-multivcpu 6 xen-bootfail REGR. vs. 101675 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101675 test-amd64-i386-pair 9 xen-boot/src_hostfail REGR. vs. 101675 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101675 build-i386-pvops 5 kernel-build fail in 102732 REGR. vs. 101675 build-armhf-libvirt 4 host-build-prep fail in 102875 REGR. vs. 101675 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-xsm3 host-install(3) broken pass in 102974 test-amd64-i386-libvirt-xsm 3 host-install(3) broken pass in 102974 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken pass in 102974 test-amd64-amd64-pair 9 xen-boot/src_host fail pass in 102732 test-amd64-amd64-pair10 xen-boot/dst_host fail pass in 102732 test-amd64-amd64-xl-xsm 6 xen-boot fail pass in 102732 test-amd64-amd64-i386-pvgrub 6 xen-boot fail pass in 102754 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 102823 test-amd64-amd64-libvirt 6 xen-boot fail pass in 102823 test-amd64-i386-xl-raw6 xen-boot fail pass in 102875 test-amd64-amd64-xl-credit2 6 xen-boot fail pass in 102875 test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail pass in 102974 test-armhf-armhf-libvirt-raw 5 xen-installfail pass in 102974 test-armhf-armhf-xl-credit2 14 guest-stop fail pass in 102974 Regressions which are regarded as allowable (not blocking): test-amd64-i386-rumprun-i386 3 host-install(3) broken blocked in 101675 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail in 102974 like 101675 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 101662 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 101675 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101675 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 101675 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 101675 test-amd64-amd64-xl-rtds 9 debian-install fail like 101675 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101675 Tests which did not succeed, but are not blocking: test-amd64-i386-freebsd10-i386 1 build-check(1) blocked in 102732 n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked in 102732 n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl-qemut-winxpsp3 1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 102732 n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked in 102732 n/a test-amd64-i386-freebsd10-amd64 1 build-check(1)blocked in 102732 n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl1 build-check(1) blocked in 102732 n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl-xsm1 build-check(1) blocked in 102732 n/a test-amd64-i386-xl-q
Re: [Xen-devel] [PATCH] xen/physmap: Propagate error rc from xenmem_add_to_physmap_one
>>> On 07.12.16 at 18:09, wrote:
> On 07/12/16 11:43, Jan Beulich wrote:
> On 07.12.16 at 02:07, wrote:
>>> On 07/12/2016 01:00, Jiandi An wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -762,6 +762,8 @@ static int xenmem_add_to_physmap_batch(struct domain
*d,
rc = xenmem_add_to_physmap_one(d, xatpb->space,
xatpb->u,
idx, _gfn(gpfn));
+if ( rc < 0 )
+goto out;
if ( unlikely(__copy_to_guest_offset(xatpb->errs, 0, &rc, 1)) )
{
>>> This can't be correct. You now skip writing rc into the errs[] array on
>>> a failure, which means that userspace will get an overall failure but an
>>> errs[] array which said that nothing went wrong.
>>>
>>> This code addition looks like it wants to be an "else if" on the end of
>>> this if() in context.
>> Why would this go elsewhere? It's unneeded - it's a property of the
>> hypercall that when seeing overall success you still need to look at
>> errs[].
>
> Looking at the public header files, the error behaviour isn't even
> documented. (I'm going to try and remember to pick up on bugs like this
> more closely during future review.)
I agree it would be nice for behavior to be spelled out if it's
possibly unexpected, but ...
> Similar batch hypercalls return the index of the first failing
> operation, which is a far more helpful behaviour for the caller.
... this is not really an option here. It would make sense if the
operation stopped at that slot, but that's not the case. errs[]
needs to be scanned in full anyway to find all (and not just
the first) error slots. Furthermore positive return values are
used by the function to indicate the need for a continuation
to be invoked.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: QED disks support
On Wed, Dec 07, 2016 at 02:04:27PM +0100, Cedric Bosdonnat wrote: > On Wed, 2016-12-07 at 11:25 +, Wei Liu wrote: > > On Mon, Nov 14, 2016 at 03:57:00PM +0100, Cédric Bosdonnat wrote: > > > Qdisk supports qcow and qcow2, extend it to also support qed disk > > > format. > > > > > > Signed-off-by: Cédric Bosdonnat > > > --- > > > tools/libxl/libxl_device.c |1 + > > > tools/libxl/libxl_dm.c |1 + > > > tools/libxl/libxl_types.idl |1 + > > > tools/libxl/libxl_utils.c |2 + > > > tools/libxl/libxlu_disk_l.c | 1018 > > > ++- > > > tools/libxl/libxlu_disk_l.h | 53 +-- > > > tools/libxl/libxlu_disk_l.l |3 +- > > > > You would also need to patch docs/misc/xl-disk-configuration.txt and > > possibly xl manpage. > > Oh indeed, I forgot about those. > > > You would also need to add a LIBXL_HAVE macro in libxl.h -- there are > > quite a lot of examples there. > > I pondered this too, but I managed to write a configure detection code > detecting > if the format is managed without it (just by trying to build a small sample > of code > using the new enum value). Do we really want to have a LIBXL_HAVE macro for > every > single disk format support we add? > The new macro is to mark the change in LIBXL public APIs, so that user can rely on the macro to do it, which seems to be a bit easier than requiring everyone to write a small program to test if the enum exists. The macro just needs to carry a certain semantics. It doesn't have to be one macro per enum or thing. For example, you can add a batch of new formats but only have one macro. But in this particular patch, it is going to be one macro for this format. > > Other than the things mentioned above, most code changes look rather > > mechanical to me. > > > > But what is not very satisfying (not your fault) is that we seem to need > > to add every single disk format we want to support by hand. That's > > rather repetitive. I wonder if there should be some sort of notation in > > libxl for "all formats that QEMU supports". > > Should I then check the docs for such a statement? Or should I try adding more > qemu-supported disk formats? > Neither. I was vaguely thinking about some sort of mechanism to automatically detect what QEMU supports and plumb relevant arguments to QEMU. But that doesn't seem to be easy and doesn't fit into our existing model. I think there will be security concern as well. We would need to think more about this. At the moment I think your approach is fine. We just add new formats as they come along. So, please update your patch to patch documents / libxl.h and resend. Wei. > -- > Cedric > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: QED disks support
On 08/12/16 10:28, Wei Liu wrote: > On Wed, Dec 07, 2016 at 02:04:27PM +0100, Cedric Bosdonnat wrote: >> On Wed, 2016-12-07 at 11:25 +, Wei Liu wrote: >>> On Mon, Nov 14, 2016 at 03:57:00PM +0100, Cédric Bosdonnat wrote: Qdisk supports qcow and qcow2, extend it to also support qed disk format. Signed-off-by: Cédric Bosdonnat --- tools/libxl/libxl_device.c |1 + tools/libxl/libxl_dm.c |1 + tools/libxl/libxl_types.idl |1 + tools/libxl/libxl_utils.c |2 + tools/libxl/libxlu_disk_l.c | 1018 ++- tools/libxl/libxlu_disk_l.h | 53 +-- tools/libxl/libxlu_disk_l.l |3 +- >>> >>> You would also need to patch docs/misc/xl-disk-configuration.txt and >>> possibly xl manpage. >> >> Oh indeed, I forgot about those. >> >>> You would also need to add a LIBXL_HAVE macro in libxl.h -- there are >>> quite a lot of examples there. >> >> I pondered this too, but I managed to write a configure detection code >> detecting >> if the format is managed without it (just by trying to build a small sample >> of code >> using the new enum value). Do we really want to have a LIBXL_HAVE macro for >> every >> single disk format support we add? >> > > The new macro is to mark the change in LIBXL public APIs, so that user > can rely on the macro to do it, which seems to be a bit easier than > requiring everyone to write a small program to test if the enum exists. > > The macro just needs to carry a certain semantics. It doesn't have to be > one macro per enum or thing. For example, you can add a batch of new > formats but only have one macro. But in this particular patch, it is > going to be one macro for this format. > >>> Other than the things mentioned above, most code changes look rather >>> mechanical to me. >>> >>> But what is not very satisfying (not your fault) is that we seem to need >>> to add every single disk format we want to support by hand. That's >>> rather repetitive. I wonder if there should be some sort of notation in >>> libxl for "all formats that QEMU supports". >> >> Should I then check the docs for such a statement? Or should I try adding >> more >> qemu-supported disk formats? >> > > Neither. > > I was vaguely thinking about some sort of mechanism to automatically > detect what QEMU supports and plumb relevant arguments to QEMU. But that > doesn't seem to be easy and doesn't fit into our existing model. I think > there will be security concern as well. We would need to think more > about this. Well, I've added indication of backend support of qemu via Xenstore. For each supported backend type a Xenstore entry is being written. Adding the supported formats under such a node seems to be a natural extension. Juergen > > At the moment I think your approach is fine. We just add new formats as > they come along. > > So, please update your patch to patch documents / libxl.h and resend. > > Wei. > >> -- >> Cedric >> >> ___ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> https://lists.xen.org/xen-devel > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] PV Autotranslate guests (are they used at all?)
At 20:37 + on 07 Dec (1481143049), Andrew Cooper wrote: > Given that it hasn't booted on the past two releases of Xen, and doesn't > appear to have ever worked in one common case, does anyone have any > objection if I remove all vestigial pieces and permanently lay the > feature to rest in SCM history? No objection from me! Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [DOC RFC] Heterogeneous Multi Processing Support in Xen
>>> On 07.12.16 at 19:29, wrote: > ### x86 > > There is no HMP platform of relevance, for now, in x86 world. Therefore, > only one class will exist, and all the CPUs will be set to belong to it. > **TODO X86:** is this correct? What about the original Xeon Phi (on a PCIe card)? > ## Hypervisor > > The hypervisor needs to know within which class each of the present CPUs > falls. At boot (or, in general, CPU bringup) time, while identifying the CPU, > a list of classes is constructed, and the mapping between each CPU and the > class it is determined it should belong, established. > > The list of classes is kept ordered from the more powerful to the less > powerful. > **TODO:** this has been [proposed by > George](https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg02212.html). > I like the idea, what do others think? If we agree on that, note that there > has been no discussion on defining what "more powerful" means, neither on > x86 (although, not really that interesting, for now, I'd say), nor on ARM. Indeed I think there should be no assumption about the ability to order things here: Even if for some initial set of hardware it may be possible to clearly tell which one's more powerful and which one's more weak, already the moment you extend this from compute power to different ISA extensions you'll immediately end up with the possibility of two CPUs have a distinct extra feature compared to one another (say one a crypto extension and the other a wider vector compute engine). It may be possible to establish partial ordering though, but it's not really clear to me what such ordering would be used for. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [DOC RFC] Heterogeneous Multi Processing Support in Xen
On Thu, 2016-12-08 at 03:14 -0700, Jan Beulich wrote: > > > > On 07.12.16 at 19:29, wrote: > > ### x86 > > > > There is no HMP platform of relevance, for now, in x86 world. > > Therefore, > > only one class will exist, and all the CPUs will be set to belong > > to it. > > **TODO X86:** is this correct? > > What about the original Xeon Phi (on a PCIe card)? > Well, what I'd say about it is that I did not know about its existence. :-) Anyway, if we have HMP on x86 already, and we want to support them, we'll have to define criteria for building classes there too. Once that is done, the rest of this document should be general enough (or at least that was the intent). About defining those criteria, I'd appreciate whatever input you x86 experts will be able to share. :-) 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 https://lists.xen.org/xen-devel
Re: [Xen-devel] [DOC RFC] Heterogeneous Multi Processing Support in Xen
On Thu, 2016-12-08 at 07:12 +0100, Juergen Gross wrote: > On 07/12/16 19:29, Dario Faggioli wrote: > > > > Setting and getting the CPU class of a vCPU will happen via two new > > hypercalls: > > > > * `XEN_DOMCTL_setvcpuclass` > > * `XEN_DOMCTL_setvcpuclass` > > XEN_DOMCTL_getvcpuclass > Oops, thanks. > > ### Phase 2 > > > > Inside Xen, the various schedulers will be modified to deal > > internally with > > the fact that vCPUs can only run on pCPUs from the class(es) they > > are > > associated with. This allows for more efficient implementation, and > > paves > > the way for enabling more intelligent logic (e.g., for minimizing > > power > > consumption) in *phase 3*. > > > Any idea how to avoid problems in the schedulers related to vcpus > with > different weights? > Sure: use Credit2! :-P And I'm not joking (not entirely, at least), as the alternative is to re-engineer significantly the algorithm inside Credit, which I'm not sure is doable or worthwhile, especially considering we have alternatives. > Remember, weights and pinning don't go well together, > that was the main reason for inventing cpupools. You should at least > name that problem. > Yes, that's true. I will add a paragraph about it. Thanks and 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 https://lists.xen.org/xen-devel
Re: [Xen-devel] [DOC RFC] Heterogeneous Multi Processing Support in Xen
On 08/12/16 11:27, Dario Faggioli wrote: > On Thu, 2016-12-08 at 07:12 +0100, Juergen Gross wrote: >> On 07/12/16 19:29, Dario Faggioli wrote: >>> ### Phase 2 >>> >>> Inside Xen, the various schedulers will be modified to deal >>> internally with >>> the fact that vCPUs can only run on pCPUs from the class(es) they >>> are >>> associated with. This allows for more efficient implementation, and >>> paves >>> the way for enabling more intelligent logic (e.g., for minimizing >>> power >>> consumption) in *phase 3*. >>> >> Any idea how to avoid problems in the schedulers related to vcpus >> with >> different weights? >> > Sure: use Credit2! :-P > > And I'm not joking (not entirely, at least), as the alternative is to > re-engineer significantly the algorithm inside Credit, which I'm not > sure is doable or worthwhile, especially considering we have > alternatives. So you really solved the following problem in credit2? You have three domains with 2 vcpus each and different weights. Run them on 3 physical cpus with following pinning: dom1: pcpu 1 and 2 dom2: pcpu 2 and 3 dom3: pcpu 1 and 3 How do you decide which vcpu to run on which pcpu for how long? Juergen > >> Remember, weights and pinning don't go well together, >> that was the main reason for inventing cpupools. You should at least >> name that problem. >> > Yes, that's true. I will add a paragraph about it. > > Thanks and Regards, > Dario > -- <> (Raistlin Majere) > - Dario > Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, > Citrix Systems R&D Ltd., Cambridge (UK) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [DOC RFC] Heterogeneous Multi Processing Support in Xen
>>> On 08.12.16 at 11:23, wrote: > On Thu, 2016-12-08 at 03:14 -0700, Jan Beulich wrote: >> > > > On 07.12.16 at 19:29, wrote: >> > ### x86 >> > >> > There is no HMP platform of relevance, for now, in x86 world. >> > Therefore, >> > only one class will exist, and all the CPUs will be set to belong >> > to it. >> > **TODO X86:** is this correct? >> >> What about the original Xeon Phi (on a PCIe card)? >> > Well, what I'd say about it is that I did not know about its existence. > :-) > > Anyway, if we have HMP on x86 already, and we want to support them, > we'll have to define criteria for building classes there too. Once that > is done, the rest of this document should be general enough (or at > least that was the intent). > > About defining those criteria, I'd appreciate whatever input you x86 > experts will be able to share. :-) Well, the obvious part of the classification would be differences in CPUID output - vendor, family, model, stepping, feature flags. I'm not currently aware of ways to identify differing performance, but I'm also unaware of systems built with CPUs varying in e.g. clock speeds. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 00/13] xen/arm: Allow AArch32 guest to boot with GICv3
Hi Stefano, On 07/12/16 22:51, Stefano Stabellini wrote: On Wed, 7 Dec 2016, Julien Grall wrote: Hi all, Currently, it is only possible to start AArch32 guest with GICv2. This means that if the host interrupt controller is not compatible with GICv2, it will not be possible to boot AArch32 guest. The vGICv3 code is nearly fully compatible with AArch32 guest except that co-processor access to ICC_SGI1R_EL1 is not emulated. The first part (#1 - #11) of the series contains clean-up, only patch #12 and #13 contains the meat. Note this is only allowing AArch32 guest to use GICv3 on AArch64 host. This series does not add support for GICv3 on AArch32 host. A branch with all the patches can be found on xenbits: git://xenbits.xen.org/people/julieng/xen-unstable.git branch gicv3-32bit-v1 Nice and clean series. Only a couple of minor issues, I fixed them as I applied the patches. Thank you! Good catch for the missing 0 to false change. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 0/6] x86emul: FPU handling improvements
1: extend / amend supported FPU opcodes 2: simplify FPU source operand handling 3: simplify FPU destination operand handling 4: reduce FPU handling code size 5: avoid undefined behavior when dealing with 10-byte FPU operands 6: simplify FPU handling asm() constraints Signed-off-by: Jan Beulich --- v2: Only patch 1 really changed (see there), some others just needed re-basing. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 1/6] x86emul: extend / amend supported FPU opcodes
First of all there are a number of secondary encodings both Intel and
AMD support, but which aren't formally documented. See e.g.
www.sandpile.org/x86/opc_fpu.htm for inofficial documentation.
Next there are a few more no-ops - instructions which served a purpose
only on 8087 or 287.
Further switch from fail_if() to raising of #UD in a couple of places
(as the decoding of FPU opcodes should now be complete except where
explicitly marked as todo).
Also adjust a few comments.
Signed-off-by: Jan Beulich
---
v2: Correct placement of ffreep case. Use generate_exception(...) in
favor of generate_exception_if(true, ...). Add sandpile.org
reference.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3577,18 +3577,18 @@ x86_emulate(
host_and_vcpu_must_have(fpu);
switch ( modrm )
{
-case 0xc0 ... 0xc7: /* fadd %stN,%stN */
-case 0xc8 ... 0xcf: /* fmul %stN,%stN */
-case 0xd0 ... 0xd7: /* fcom %stN,%stN */
-case 0xd8 ... 0xdf: /* fcomp %stN,%stN */
-case 0xe0 ... 0xe7: /* fsub %stN,%stN */
-case 0xe8 ... 0xef: /* fsubr %stN,%stN */
-case 0xf0 ... 0xf7: /* fdiv %stN,%stN */
-case 0xf8 ... 0xff: /* fdivr %stN,%stN */
+case 0xc0 ... 0xc7: /* fadd %stN,%st */
+case 0xc8 ... 0xcf: /* fmul %stN,%st */
+case 0xd0 ... 0xd7: /* fcom %stN,%st */
+case 0xd8 ... 0xdf: /* fcomp %stN,%st */
+case 0xe0 ... 0xe7: /* fsub %stN,%st */
+case 0xe8 ... 0xef: /* fsubr %stN,%st */
+case 0xf0 ... 0xf7: /* fdiv %stN,%st */
+case 0xf8 ... 0xff: /* fdivr %stN,%st */
emulate_fpu_insn_stub(0xd8, modrm);
break;
default:
-fail_if(modrm >= 0xc0);
+ASSERT(ea.type == OP_MEM);
ea.bytes = 4;
src = ea;
if ( (rc = ops->read(src.mem.seg, src.mem.off, &src.val,
@@ -3634,6 +3634,7 @@ x86_emulate(
case 0xc0 ... 0xc7: /* fld %stN */
case 0xc8 ... 0xcf: /* fxch %stN */
case 0xd0: /* fnop */
+case 0xd8 ... 0xdf: /* fstp %stN (alternative encoding) */
case 0xe0: /* fchs */
case 0xe1: /* fabs */
case 0xe4: /* ftst */
@@ -3663,7 +3664,7 @@ x86_emulate(
emulate_fpu_insn_stub(0xd9, modrm);
break;
default:
-fail_if(modrm >= 0xc0);
+generate_exception_if(ea.type != OP_MEM, EXC_UD);
switch ( modrm_reg & 7 )
{
case 0: /* fld m32fp */
@@ -3686,7 +3687,8 @@ x86_emulate(
dst.type = OP_MEM;
emulate_fpu_insn_memdst("fstps", dst.val);
break;
-/* case 4: fldenv - TODO */
+case 4: /* fldenv - TODO */
+goto cannot_emulate;
case 5: /* fldcw m2byte */
ea.bytes = 2;
src = ea;
@@ -3695,7 +3697,8 @@ x86_emulate(
goto done;
emulate_fpu_insn_memsrc("fldcw", src.val);
break;
-/* case 6: fstenv - TODO */
+case 6: /* fnstenv - TODO */
+goto cannot_emulate;
case 7: /* fnstcw m2byte */
ea.bytes = 2;
dst = ea;
@@ -3703,7 +3706,7 @@ x86_emulate(
emulate_fpu_insn_memdst("fnstcw", dst.val);
break;
default:
-goto cannot_emulate;
+generate_exception(EXC_UD);
}
}
break;
@@ -3723,7 +3726,7 @@ x86_emulate(
emulate_fpu_insn_stub(0xda, modrm);
break;
default:
-fail_if(modrm >= 0xc0);
+generate_exception_if(ea.type != OP_MEM, EXC_UD);
ea.bytes = 4;
src = ea;
if ( (rc = ops->read(src.mem.seg, src.mem.off, &src.val,
@@ -3772,16 +3775,16 @@ x86_emulate(
vcpu_must_have_cmov();
emulate_fpu_insn_stub_eflags(0xdb, modrm);
break;
+case 0xe0: /* fneni - 8087 only, ignored by 287 */
+case 0xe1: /* fndisi - 8087 only, ignored by 287 */
case 0xe2: /* fnclex */
-emulate_fpu_insn("fnclex");
-break;
case 0xe3: /* fninit */
-emulate_fpu_insn("fninit");
-break;
-case 0xe4: /* fsetpm - 287 only, ignored by 387 */
+case 0xe4: /* fnsetpm - 287 only, ignored by 387 */
+/* case 0xe5: frstpm - 287 only, #UD on 387 */
+emulate_fpu_insn_stub(0xdb, modrm);
break;
default:
-fail_if(modrm >= 0xc0);
+generate_exception_if(ea.type != OP_MEM, EXC_UD);
switch ( modrm_reg & 7 )
{
case 0: /* fild m32i */
@@ -3826,7 +3829,7 @@ x86_emulate(
emulate_fpu_insn_memdst("fstpt", dst.val);
break;
default:
-
[Xen-devel] [PATCH v2 2/6] x86emul: simplify FPU source operand handling
Consistently use ea instead of src for passing the memory address to
->read(). This eliminates the need to copy ea to src, resulting in a
couple of hundred bytes smaller binary size.
In addition for opcode DE we can leverage SrcMem16 to eliminate a call
of the ->read() hook. At the same time drop the stray Mov attributes
from D8, DA, DC, and DE: They're meaningful for memory writes only.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -159,10 +159,10 @@ static const opcode_desc_t opcode_table[
ByteOp|DstMem|SrcImplicit|ModRM, DstMem|SrcImplicit|ModRM,
DstImplicit|SrcImmByte, DstImplicit|SrcImmByte, ImplicitOps, ImplicitOps,
/* 0xD8 - 0xDF */
-ImplicitOps|ModRM|Mov, ImplicitOps|ModRM|Mov,
-ImplicitOps|ModRM|Mov, ImplicitOps|ModRM|Mov,
-ImplicitOps|ModRM|Mov, ImplicitOps|ModRM|Mov,
-ImplicitOps|ModRM|Mov, ImplicitOps|ModRM|Mov,
+ImplicitOps|ModRM, ImplicitOps|ModRM|Mov,
+ImplicitOps|ModRM, ImplicitOps|ModRM|Mov,
+ImplicitOps|ModRM, ImplicitOps|ModRM|Mov,
+DstImplicit|SrcMem16|ModRM, ImplicitOps|ModRM|Mov,
/* 0xE0 - 0xE7 */
DstImplicit|SrcImmByte, DstImplicit|SrcImmByte,
DstImplicit|SrcImmByte, DstImplicit|SrcImmByte,
@@ -3589,10 +3589,8 @@ x86_emulate(
break;
default:
ASSERT(ea.type == OP_MEM);
-ea.bytes = 4;
-src = ea;
-if ( (rc = ops->read(src.mem.seg, src.mem.off, &src.val,
- src.bytes, ctxt)) != 0 )
+if ( (rc = ops->read(ea.mem.seg, ea.mem.off, &src.val,
+ 4, ctxt)) != X86EMUL_OKAY )
goto done;
switch ( modrm_reg & 7 )
{
@@ -3668,10 +3666,8 @@ x86_emulate(
switch ( modrm_reg & 7 )
{
case 0: /* fld m32fp */
-ea.bytes = 4;
-src = ea;
if ( (rc = ops->read(ea.mem.seg, ea.mem.off, &src.val,
- src.bytes, ctxt)) != 0 )
+ 4, ctxt)) != X86EMUL_OKAY )
goto done;
emulate_fpu_insn_memsrc("flds", src.val);
break;
@@ -3690,10 +3686,8 @@ x86_emulate(
case 4: /* fldenv - TODO */
goto cannot_emulate;
case 5: /* fldcw m2byte */
-ea.bytes = 2;
-src = ea;
-if ( (rc = ops->read(src.mem.seg, src.mem.off, &src.val,
- src.bytes, ctxt)) != 0 )
+if ( (rc = ops->read(ea.mem.seg, ea.mem.off, &src.val,
+ 2, ctxt)) != X86EMUL_OKAY )
goto done;
emulate_fpu_insn_memsrc("fldcw", src.val);
break;
@@ -3727,10 +3721,8 @@ x86_emulate(
break;
default:
generate_exception_if(ea.type != OP_MEM, EXC_UD);
-ea.bytes = 4;
-src = ea;
-if ( (rc = ops->read(src.mem.seg, src.mem.off, &src.val,
- src.bytes, ctxt)) != 0 )
+if ( (rc = ops->read(ea.mem.seg, ea.mem.off, &src.val,
+ 4, ctxt)) != X86EMUL_OKAY )
goto done;
switch ( modrm_reg & 7 )
{
@@ -3788,10 +3780,8 @@ x86_emulate(
switch ( modrm_reg & 7 )
{
case 0: /* fild m32i */
-ea.bytes = 4;
-src = ea;
-if ( (rc = ops->read(src.mem.seg, src.mem.off, &src.val,
- src.bytes, ctxt)) != 0 )
+if ( (rc = ops->read(ea.mem.seg, ea.mem.off, &src.val,
+ 4, ctxt)) != X86EMUL_OKAY )
goto done;
emulate_fpu_insn_memsrc("fildl", src.val);
break;
@@ -3815,10 +3805,8 @@ x86_emulate(
emulate_fpu_insn_memdst("fistpl", dst.val);
break;
case 5: /* fld m80fp */
-ea.bytes = 10;
-src = ea;
-if ( (rc = ops->read(src.mem.seg, src.mem.off,
- &src.val, src.bytes, ctxt)) != 0 )
+if ( (rc = ops->read(ea.mem.seg, ea.mem.off, &src.val,
+ 10, ctxt)) != X86EMUL_OKAY )
goto done;
emulate_fpu_insn_memsrc("fldt", src.val);
break;
@@ -3850,10 +3838,8 @@ x86_emulate(
break;
default:
ASSERT(ea.type == OP_MEM);
-ea.bytes = 8;
-src = ea;
-if ( (rc = ops->read(src.mem.seg, src.mem.off, &src.val,
- src.bytes, ctxt)) != 0 )
+if ( (rc = ops->read(ea.mem.seg, ea.mem.off, &src.val,
+
[Xen-devel] [PATCH v2 4/6] x86emul: reduce FPU handling code size
Pulling out the {get,put}_fpu() invocations from individual emulation
paths leads to a couple of kb code size reduction in my builds. Note
that this is fine exception-wise:
- #UD and #NM have implementation defined order relative to one
another,
- data read #GP/#SS/#PF now properly are delivered after #NM/#UD.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
v2: Re-base over changes to patch 1.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -849,59 +849,44 @@ do {
} while (0)
#define emulate_fpu_insn(_op) \
-do{ struct fpu_insn_ctxt fic; \
-get_fpu(X86EMUL_FPU_fpu, &fic); \
asm volatile ( \
"movb $2f-1f,%0 \n" \
"1: " _op " \n" \
"2: \n" \
-: "=m" (fic.insn_bytes) : : "memory" ); \
-put_fpu(&fic); \
-} while (0)
+: "=m" (fic.insn_bytes) : : "memory" )
#define emulate_fpu_insn_memdst(_op, _arg) \
-do{ struct fpu_insn_ctxt fic; \
-get_fpu(X86EMUL_FPU_fpu, &fic); \
asm volatile ( \
"movb $2f-1f,%0 \n" \
"1: " _op " %1 \n" \
"2: \n" \
: "=m" (fic.insn_bytes), "=m" (_arg)\
-: : "memory" ); \
-put_fpu(&fic); \
-} while (0)
+: : "memory" )
#define emulate_fpu_insn_memsrc(_op, _arg) \
-do{ struct fpu_insn_ctxt fic; \
-get_fpu(X86EMUL_FPU_fpu, &fic); \
asm volatile ( \
"movb $2f-1f,%0 \n" \
"1: " _op " %1 \n" \
"2: \n" \
: "=m" (fic.insn_bytes) \
-: "m" (_arg) : "memory" ); \
-put_fpu(&fic); \
-} while (0)
+: "m" (_arg) : "memory" )
#define emulate_fpu_insn_stub(_bytes...)\
do {\
uint8_t *buf = get_stub(stub); \
unsigned int _nr = sizeof((uint8_t[]){ _bytes }); \
-struct fpu_insn_ctxt fic = { .insn_bytes = _nr }; \
+fic.insn_bytes = _nr; \
memcpy(buf, ((uint8_t[]){ _bytes, 0xc3 }), _nr + 1);\
-get_fpu(X86EMUL_FPU_fpu, &fic); \
stub.func();\
-put_fpu(&fic); \
put_stub(stub); \
} while (0)
#define emulate_fpu_insn_stub_eflags(bytes...) \
do {\
unsigned int nr_ = sizeof((uint8_t[]){ bytes });\
-struct fpu_insn_ctxt fic_ = { .insn_bytes = nr_ }; \
unsigned long tmp_; \
+fic.insn_bytes = nr_; \
memcpy(get_stub(stub), ((uint8_t[]){ bytes, 0xc3 }), nr_ + 1); \
-get_fpu(X86EMUL_FPU_fpu, &fic_);\
asm volatile ( _PRE_EFLAGS("[eflags]", "[mask]", "[tmp]") \
"call *%[func];" \
_POST_EFLAGS("[eflags]", "[mask]", "[tmp]") \
@@ -909,7 +894,6 @@ do {
[tmp] "=&r" (tmp_) \
: [func] "rm" (stub.func), \
[mask] "i" (EFLG_ZF|EFLG_PF|EFLG_CF) );\
-put_fpu(&fic_); \
put_stub(stub); \
} while (0)
@@ -2492,6 +2476,7 @@ x86_emulate(
struct operand src = { .reg = PTR_POISON };
struct operand dst = { .reg = PTR_POISON };
enum x86_swint_type swint_type;
+struct fpu_insn_ctxt fic;
struct x86_emulate_stub stub = {};
DECLARE_ALIGNED(mmval_t, mmval);
@@ -3188,15 +3173,12 @@ x86_emulate(
break;
case 0x9b: /* wait/fwait */
-{
-struct fpu_insn_ctxt fic = { .insn_bytes = 1 };
-
+fic.insn_bytes = 1;
host_and_vcpu_must_have(fpu);
[Xen-devel] [PATCH v2 5/6] x86emul: avoid undefined behavior when dealing with 10-byte FPU operands
Accessing an 8-byte (or perhaps just 4-byte in the test harness when
built as 32-bit app) field to read/write 10 bytes (leveraging the
successive field) is a latent bug, as the compiler could copy things
around. Use the 32 bytes large SSE/AVX slot instead.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
v2: Re-base over changes to patch 1.
---
The presence of the !op->write checks implies a logical (but not
functional) dependency on the patch making ops->write (and ->cmpxchg)
optional. Without that patch they're just dead code.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3787,15 +3787,19 @@ x86_emulate(
dst.bytes = 4;
break;
case 5: /* fld m80fp */
-if ( (rc = ops->read(ea.mem.seg, ea.mem.off, &src.val,
+if ( (rc = ops->read(ea.mem.seg, ea.mem.off, mmvalp,
10, ctxt)) != X86EMUL_OKAY )
goto done;
-emulate_fpu_insn_memsrc("fldt", src.val);
+emulate_fpu_insn_memsrc("fldt", *mmvalp);
dst.type = OP_NONE;
break;
case 7: /* fstp m80fp */
-emulate_fpu_insn_memdst("fstpt", dst.val);
-dst.bytes = 10;
+fail_if(!ops->write);
+emulate_fpu_insn_memdst("fstpt", *mmvalp);
+if ( (rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
+ 10, ctxt)) != X86EMUL_OKAY )
+goto done;
+dst.type = OP_NONE;
break;
default:
generate_exception(EXC_UD);
@@ -4004,10 +4008,10 @@ x86_emulate(
dst.bytes = 2;
break;
case 4: /* fbld m80dec */
-if ( (rc = ops->read(ea.mem.seg, ea.mem.off, &src.val,
+if ( (rc = ops->read(ea.mem.seg, ea.mem.off, mmvalp,
10, ctxt)) != X86EMUL_OKAY )
goto done;
-emulate_fpu_insn_memsrc("fbld", src.val);
+emulate_fpu_insn_memsrc("fbld", *mmvalp);
dst.type = OP_NONE;
break;
case 5: /* fild m64i */
@@ -4018,8 +4022,12 @@ x86_emulate(
dst.type = OP_NONE;
break;
case 6: /* fbstp packed bcd */
-emulate_fpu_insn_memdst("fbstp", dst.val);
-dst.bytes = 10;
+fail_if(!ops->write);
+emulate_fpu_insn_memdst("fbstp", *mmvalp);
+if ( (rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
+ 10, ctxt)) != X86EMUL_OKAY )
+goto done;
+dst.type = OP_NONE;
break;
case 7: /* fistp m64i */
emulate_fpu_insn_memdst("fistpll", dst.val);
x86emul: avoid undefined behavior when dealing with 10-byte FPU operands
Accessing an 8-byte (or perhaps just 4-byte in the test harness when
built as 32-bit app) field to read/write 10 bytes (leveraging the
successive field) is a latent bug, as the compiler could copy things
around. Use the 32 bytes large SSE/AVX slot instead.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
v2: Re-base over changes to patch 1.
---
The presence of the !op->write checks implies a logical (but not
functional) dependency on the patch making ops->write (and ->cmpxchg)
optional. Without that patch they're just dead code.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3787,15 +3787,19 @@ x86_emulate(
dst.bytes = 4;
break;
case 5: /* fld m80fp */
-if ( (rc = ops->read(ea.mem.seg, ea.mem.off, &src.val,
+if ( (rc = ops->read(ea.mem.seg, ea.mem.off, mmvalp,
10, ctxt)) != X86EMUL_OKAY )
goto done;
-emulate_fpu_insn_memsrc("fldt", src.val);
+emulate_fpu_insn_memsrc("fldt", *mmvalp);
dst.type = OP_NONE;
break;
case 7: /* fstp m80fp */
-emulate_fpu_insn_memdst("fstpt", dst.val);
-dst.bytes = 10;
+fail_if(!ops->write);
+emulate_fpu_insn_memdst("fstpt", *mmvalp);
+if ( (rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
+ 10, ctxt)) != X86EMUL_OKAY )
+goto done;
+dst.type = OP_NONE;
break;
default:
generate_exception(EXC_UD);
@@ -4004,10 +4008,10 @@ x86_emulate(
dst.bytes = 2;
break;
case 4: /* fbld m80dec */
-if ( (rc = ops->read(ea.mem.seg, ea.mem.off, &src.val,
+if ( (rc = op
[Xen-devel] [PATCH v2 6/6] x86emul: simplify FPU handling asm() constraints
The memory clobber is rather harsh here. However, fic.exn_raised may be
modified as a side effect, so we need to let the compiler know that all
of "fic" may be changed (preventing it from moving around accesses to
the exn_raised field).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -759,7 +759,7 @@ do {
})
struct fpu_insn_ctxt {
-uint8_t insn_bytes;
+uint8_t insn_bytes; /* Must be first! */
int8_t exn_raised;
};
@@ -853,23 +853,21 @@ do {
"movb $2f-1f,%0 \n" \
"1: " _op " \n" \
"2: \n" \
-: "=m" (fic.insn_bytes) : : "memory" )
+: "+m" (fic) )
#define emulate_fpu_insn_memdst(_op, _arg) \
asm volatile ( \
"movb $2f-1f,%0 \n" \
"1: " _op " %1 \n" \
"2: \n" \
-: "=m" (fic.insn_bytes), "=m" (_arg)\
-: : "memory" )
+: "+m" (fic), "=m" (_arg) )
#define emulate_fpu_insn_memsrc(_op, _arg) \
asm volatile ( \
"movb $2f-1f,%0 \n" \
"1: " _op " %1 \n" \
"2: \n" \
-: "=m" (fic.insn_bytes) \
-: "m" (_arg) : "memory" )
+: "+m" (fic) : "m" (_arg) )
#define emulate_fpu_insn_stub(_bytes...)\
do {\
x86emul: simplify FPU handling asm() constraints
The memory clobber is rather harsh here. However, fic.exn_raised may be
modified as a side effect, so we need to let the compiler know that all
of "fic" may be changed (preventing it from moving around accesses to
the exn_raised field).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -759,7 +759,7 @@ do {
})
struct fpu_insn_ctxt {
-uint8_t insn_bytes;
+uint8_t insn_bytes; /* Must be first! */
int8_t exn_raised;
};
@@ -853,23 +853,21 @@ do {
"movb $2f-1f,%0 \n" \
"1: " _op " \n" \
"2: \n" \
-: "=m" (fic.insn_bytes) : : "memory" )
+: "+m" (fic) )
#define emulate_fpu_insn_memdst(_op, _arg) \
asm volatile ( \
"movb $2f-1f,%0 \n" \
"1: " _op " %1 \n" \
"2: \n" \
-: "=m" (fic.insn_bytes), "=m" (_arg)\
-: : "memory" )
+: "+m" (fic), "=m" (_arg) )
#define emulate_fpu_insn_memsrc(_op, _arg) \
asm volatile ( \
"movb $2f-1f,%0 \n" \
"1: " _op " %1 \n" \
"2: \n" \
-: "=m" (fic.insn_bytes) \
-: "m" (_arg) : "memory" )
+: "+m" (fic) : "m" (_arg) )
#define emulate_fpu_insn_stub(_bytes...)\
do {\
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 3/6] x86emul: simplify FPU destination operand handling
Consolidate the copying of ea to dst: There's no need to set the type
to OP_MEM, and instead the load cases setting it to OP_NONE allows the
copying to be done just once per major opcode.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
v2: Re-base over changes to patch 1.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3663,6 +3663,7 @@ x86_emulate(
break;
default:
generate_exception_if(ea.type != OP_MEM, EXC_UD);
+dst = ea;
switch ( modrm_reg & 7 )
{
case 0: /* fld m32fp */
@@ -3670,18 +3671,15 @@ x86_emulate(
4, ctxt)) != X86EMUL_OKAY )
goto done;
emulate_fpu_insn_memsrc("flds", src.val);
+dst.type = OP_NONE;
break;
case 2: /* fstp m32fp */
-ea.bytes = 4;
-dst = ea;
-dst.type = OP_MEM;
emulate_fpu_insn_memdst("fsts", dst.val);
+dst.bytes = 4;
break;
case 3: /* fstp m32fp */
-ea.bytes = 4;
-dst = ea;
-dst.type = OP_MEM;
emulate_fpu_insn_memdst("fstps", dst.val);
+dst.bytes = 4;
break;
case 4: /* fldenv - TODO */
goto cannot_emulate;
@@ -3690,14 +3688,13 @@ x86_emulate(
2, ctxt)) != X86EMUL_OKAY )
goto done;
emulate_fpu_insn_memsrc("fldcw", src.val);
+dst.type = OP_NONE;
break;
case 6: /* fnstenv - TODO */
goto cannot_emulate;
case 7: /* fnstcw m2byte */
-ea.bytes = 2;
-dst = ea;
-dst.type = OP_MEM;
emulate_fpu_insn_memdst("fnstcw", dst.val);
+dst.bytes = 2;
break;
default:
generate_exception(EXC_UD);
@@ -3777,6 +3774,7 @@ x86_emulate(
break;
default:
generate_exception_if(ea.type != OP_MEM, EXC_UD);
+dst = ea;
switch ( modrm_reg & 7 )
{
case 0: /* fild m32i */
@@ -3784,37 +3782,31 @@ x86_emulate(
4, ctxt)) != X86EMUL_OKAY )
goto done;
emulate_fpu_insn_memsrc("fildl", src.val);
+dst.type = OP_NONE;
break;
case 1: /* fisttp m32i */
host_and_vcpu_must_have(sse3);
-ea.bytes = 4;
-dst = ea;
-dst.type = OP_MEM;
emulate_fpu_insn_memdst("fisttpl", dst.val);
+dst.bytes = 4;
break;
case 2: /* fist m32i */
-ea.bytes = 4;
-dst = ea;
-dst.type = OP_MEM;
emulate_fpu_insn_memdst("fistl", dst.val);
+dst.bytes = 4;
break;
case 3: /* fistp m32i */
-ea.bytes = 4;
-dst = ea;
-dst.type = OP_MEM;
emulate_fpu_insn_memdst("fistpl", dst.val);
+dst.bytes = 4;
break;
case 5: /* fld m80fp */
if ( (rc = ops->read(ea.mem.seg, ea.mem.off, &src.val,
10, ctxt)) != X86EMUL_OKAY )
goto done;
emulate_fpu_insn_memsrc("fldt", src.val);
+dst.type = OP_NONE;
break;
case 7: /* fstp m80fp */
-ea.bytes = 10;
-dst.type = OP_MEM;
-dst = ea;
emulate_fpu_insn_memdst("fstpt", dst.val);
+dst.bytes = 10;
break;
default:
generate_exception(EXC_UD);
@@ -3885,6 +3877,7 @@ x86_emulate(
break;
default:
generate_exception_if(ea.type != OP_MEM, EXC_UD);
+dst = ea;
switch ( modrm_reg & 7 )
{
case 0: /* fld m64fp */;
@@ -3892,34 +3885,27 @@ x86_emulate(
8, ctxt)) != X86EMUL_OKAY )
goto done;
emulate_fpu_insn_memsrc("fldl", src.val);
+dst.type = OP_NONE;
break;
case 1: /* fisttp m64i */
host_and_vcpu_must_have(sse3);
-ea.bytes = 8;
-dst = ea;
-dst.type = OP_MEM;
emulate_fpu_insn_memdst("fisttpll", dst.val);
+dst.bytes = 8;
break;
case 2: /* fst m64fp */
-ea.bytes = 8;
-dst = ea;
-dst.type = OP_MEM;
[Xen-devel] [PATCH v2] x86emul: fold SReg PUSH/POP cases
Now that segment registers are numbered naturally this can be easily
done to achieve some code size reduction.
Also consistently use X86EMUL_OKAY in the code being touched.
Signed-off-by: Jan Beulich
---
v2: Set retire.mov_ss for "pop %ss" instead of "pop %es".
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2731,51 +2731,40 @@ x86_emulate(
break;
case 0x06: /* push %%es */
-src.val = x86_seg_es;
-push_seg:
-generate_exception_if(mode_64bit() && !ext, EXC_UD);
+case 0x0e: /* push %%cs */
+case 0x16: /* push %%ss */
+case 0x1e: /* push %%ds */
+generate_exception_if(mode_64bit(), EXC_UD);
+/* fall through */
+case X86EMUL_OPC(0x0f, 0xa0): /* push %%fs */
+case X86EMUL_OPC(0x0f, 0xa8): /* push %%gs */
fail_if(ops->read_segment == NULL);
-if ( (rc = ops->read_segment(src.val, &sreg, ctxt)) != 0 )
+if ( (rc = ops->read_segment((b >> 3) & 7, &sreg,
+ ctxt)) != X86EMUL_OKAY )
goto done;
src.val = sreg.sel;
goto push;
case 0x07: /* pop %%es */
-src.val = x86_seg_es;
-pop_seg:
-generate_exception_if(mode_64bit() && !ext, EXC_UD);
+case 0x17: /* pop %%ss */
+case 0x1f: /* pop %%ds */
+generate_exception_if(mode_64bit(), EXC_UD);
+/* fall through */
+case X86EMUL_OPC(0x0f, 0xa1): /* pop %%fs */
+case X86EMUL_OPC(0x0f, 0xa9): /* pop %%gs */
fail_if(ops->write_segment == NULL);
/* 64-bit mode: POP defaults to a 64-bit operand. */
if ( mode_64bit() && (op_bytes == 4) )
op_bytes = 8;
-if ( (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes),
- &dst.val, op_bytes, ctxt, ops)) != 0 ||
- (rc = load_seg(src.val, dst.val, 0, NULL, ctxt, ops)) != 0 )
+seg = (b >> 3) & 7;
+if ( (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes), &dst.val,
+ op_bytes, ctxt, ops)) != X86EMUL_OKAY ||
+ (rc = load_seg(seg, dst.val, 0, NULL, ctxt, ops)) != X86EMUL_OKAY
)
goto done;
-if ( src.val == x86_seg_ss )
+if ( seg == x86_seg_ss )
ctxt->retire.mov_ss = true;
break;
-case 0x0e: /* push %%cs */
-src.val = x86_seg_cs;
-goto push_seg;
-
-case 0x16: /* push %%ss */
-src.val = x86_seg_ss;
-goto push_seg;
-
-case 0x17: /* pop %%ss */
-src.val = x86_seg_ss;
-goto pop_seg;
-
-case 0x1e: /* push %%ds */
-src.val = x86_seg_ds;
-goto push_seg;
-
-case 0x1f: /* pop %%ds */
-src.val = x86_seg_ds;
-goto pop_seg;
-
case 0x27: /* daa */
case 0x2f: /* das */ {
uint8_t al = _regs.eax;
@@ -5137,14 +5126,6 @@ x86_emulate(
dst.val = test_cc(b, _regs.eflags);
break;
-case X86EMUL_OPC(0x0f, 0xa0): /* push %%fs */
-src.val = x86_seg_fs;
-goto push_seg;
-
-case X86EMUL_OPC(0x0f, 0xa1): /* pop %%fs */
-src.val = x86_seg_fs;
-goto pop_seg;
-
case X86EMUL_OPC(0x0f, 0xa2): /* cpuid */ {
unsigned int eax = _regs.eax, ebx = _regs.ebx;
unsigned int ecx = _regs.ecx, edx = _regs.edx;
@@ -5202,14 +5183,6 @@ x86_emulate(
break;
}
-case X86EMUL_OPC(0x0f, 0xa8): /* push %%gs */
-src.val = x86_seg_gs;
-goto push_seg;
-
-case X86EMUL_OPC(0x0f, 0xa9): /* pop %%gs */
-src.val = x86_seg_gs;
-goto pop_seg;
-
case X86EMUL_OPC(0x0f, 0xab): bts: /* bts */
emulate_2op_SrcV_nobyte("bts", src, dst, _regs.eflags);
break;
x86emul: fold SReg PUSH/POP cases
Now that segment registers are numbered naturally this can be easily
done to achieve some code size reduction.
Also consistently use X86EMUL_OKAY in the code being touched.
Signed-off-by: Jan Beulich
---
v2: Set retire.mov_ss for "pop %ss" instead of "pop %es".
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2731,51 +2731,40 @@ x86_emulate(
break;
case 0x06: /* push %%es */
-src.val = x86_seg_es;
-push_seg:
-generate_exception_if(mode_64bit() && !ext, EXC_UD);
+case 0x0e: /* push %%cs */
+case 0x16: /* push %%ss */
+case 0x1e: /* push %%ds */
+generate_exception_if(mode_64bit(), EXC_UD);
+/* fall through */
+case X86EMUL_OPC(0x0f, 0xa0): /* push %%fs */
+case X86EMUL_OPC(0x0f, 0xa8): /* push %%gs */
fail_if(ops->read_segment == NULL);
-if ( (rc = ops->read_segment(src.val, &sreg, ctxt)) != 0 )
+if ( (rc = ops->read_segment((b >> 3) & 7, &sreg,
+ ctxt)) != X86EMUL_OKAY )
goto done;
src.val = sreg.sel;
goto push;
case 0x07: /* pop %%es */
-src.val = x86_seg_es;
-pop_seg:
-
Re: [Xen-devel] [PATCH v2 1/6] x86emul: extend / amend supported FPU opcodes
On 08/12/16 11:35, Jan Beulich wrote: > First of all there are a number of secondary encodings both Intel and > AMD support, but which aren't formally documented. See e.g. > www.sandpile.org/x86/opc_fpu.htm for inofficial documentation. > > Next there are a few more no-ops - instructions which served a purpose > only on 8087 or 287. > > Further switch from fail_if() to raising of #UD in a couple of places > (as the decoding of FPU opcodes should now be complete except where > explicitly marked as todo). > > Also adjust a few comments. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/2] x86emul: segment handling additions
1: support 64-bit segment descriptor types 2: support LAR/LSL/VERR/VERW Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] x86emul: defer rIP-relative address calculation
By putting it after all instruction fetching has been done, we can both
simplify the existing handling of immediate operands and take care of
any future instructions allowing rIP-relative operands and getting
additional bytes fetched in x86_decode_*() (the current cases of extra
bytes getting fetched there are only for operands without ModR/M bytes,
or with them only allowing their register forms).
Similarly the new placement of truncate_ea() will take care of any
future cases of non-standard memory operands (the one existing case -
opcodes A0...A3 - are fine with and without this, as they fetch an
ad_bytes sized unsigned address anyway).
Signed-off-by: Jan Beulich
---
v2: Use pc_rel instead of ip_rel as variable name.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1963,6 +1963,7 @@ x86_decode(
uint8_t b, d, sib, sib_index, sib_base;
unsigned int def_op_bytes, def_ad_bytes, opcode;
enum x86_segment override_seg = x86_seg_none;
+bool pc_rel = false;
int rc = X86EMUL_OKAY;
memset(state, 0, sizeof(*state));
@@ -2330,7 +2331,6 @@ x86_decode(
ea.mem.off += insn_fetch_type(int16_t);
break;
}
-ea.mem.off = truncate_ea(ea.mem.off);
}
else
{
@@ -2379,15 +2379,7 @@ x86_decode(
if ( (modrm_rm & 7) != 5 )
break;
ea.mem.off = insn_fetch_type(int32_t);
-if ( !mode_64bit() )
-break;
-/* Relative to RIP of next instruction. Argh! */
-ea.mem.off += state->eip;
-if ( (d & SrcMask) == SrcImm )
-ea.mem.off += (d & ByteOp) ? 1 :
-((op_bytes == 8) ? 4 : op_bytes);
-else if ( (d & SrcMask) == SrcImmByte )
-ea.mem.off += 1;
+pc_rel = mode_64bit();
break;
case 1:
ea.mem.off += insn_fetch_type(int8_t);
@@ -2396,7 +2388,6 @@ x86_decode(
ea.mem.off += insn_fetch_type(int32_t);
break;
}
-ea.mem.off = truncate_ea(ea.mem.off);
}
}
@@ -2461,6 +2452,14 @@ x86_decode(
return X86EMUL_UNHANDLEABLE;
}
+if ( ea.type == OP_MEM )
+{
+if ( pc_rel )
+ea.mem.off += state->eip;
+
+ea.mem.off = truncate_ea(ea.mem.off);
+}
+
/*
* Undo the operand-size override effect of prefix 66 when it was
* determined to have another meaning.
x86emul: defer rIP-relative address calculation
By putting it after all instruction fetching has been done, we can both
simplify the existing handling of immediate operands and take care of
any future instructions allowing rIP-relative operands and getting
additional bytes fetched in x86_decode_*() (the current cases of extra
bytes getting fetched there are only for operands without ModR/M bytes,
or with them only allowing their register forms).
Similarly the new placement of truncate_ea() will take care of any
future cases of non-standard memory operands (the one existing case -
opcodes A0...A3 - are fine with and without this, as they fetch an
ad_bytes sized unsigned address anyway).
Signed-off-by: Jan Beulich
---
v2: Use pc_rel instead of ip_rel as variable name.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1963,6 +1963,7 @@ x86_decode(
uint8_t b, d, sib, sib_index, sib_base;
unsigned int def_op_bytes, def_ad_bytes, opcode;
enum x86_segment override_seg = x86_seg_none;
+bool pc_rel = false;
int rc = X86EMUL_OKAY;
memset(state, 0, sizeof(*state));
@@ -2330,7 +2331,6 @@ x86_decode(
ea.mem.off += insn_fetch_type(int16_t);
break;
}
-ea.mem.off = truncate_ea(ea.mem.off);
}
else
{
@@ -2379,15 +2379,7 @@ x86_decode(
if ( (modrm_rm & 7) != 5 )
break;
ea.mem.off = insn_fetch_type(int32_t);
-if ( !mode_64bit() )
-break;
-/* Relative to RIP of next instruction. Argh! */
-ea.mem.off += state->eip;
-if ( (d & SrcMask) == SrcImm )
-ea.mem.off += (d & ByteOp) ? 1 :
-((op_bytes == 8) ? 4 : op_bytes);
-else if ( (d & SrcMask) == SrcImmByte )
-ea.mem.off += 1;
+pc_rel = mode_64bit();
break;
case 1:
ea.mem.off += insn_fetch_type(int8_t);
@@ -2396,7 +2388,6 @@ x86_decode(
ea.mem.off += insn_fetch_type(int32_t);
break;
}
-ea.mem.off = truncate_ea(ea.mem.off);
}
}
@@ -2461,6 +2452,14 @@ x86_decode(
return X86EMUL_UNHANDLEABLE;
[Xen-devel] [qemu-mainline test] 103009: trouble: broken/fail/pass
flight 103009 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/103009/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken REGR. vs. 102835 test-amd64-amd64-xl-credit2 3 host-install(3)broken REGR. vs. 102835 test-amd64-amd64-qemuu-nested-amd 3 host-install(3) broken REGR. vs. 102835 test-amd64-amd64-xl-multivcpu 3 host-install(3) broken REGR. vs. 102835 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 102835 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 102835 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 102835 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 102835 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 102835 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 102835 test-amd64-amd64-xl-rtds 9 debian-install fail like 102835 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-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-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass version targeted for testing: qemuua92f7fe5a82ac9e8d127e92c5dce1a84064126da baseline version: qemuubd8ef5060dd2124a54578241da9a572faf7658dd Last test of basis 102835 2016-12-03 06:42:24 Z5 days Failing since102957 2016-12-05 17:17:29 Z2 days2 attempts Testing same since 103009 2016-12-07 08:09:57 Z1 days1 attempts People who touched revisions under test: Alex Bennée Andrey Smirnov Changlong Xie Christophe Fergeau Eric Blake Fuxin Zhang Gerd Hoffmann Heiher Jason Wang Jeff Cody Kevin Wolf Li Qiang Marc-André Lureau Markus Armbruster Peter Maydell Prasad J Pandit Prasanna Kumar Kalever Richard Henderson Stefan Hajnoczi Yongbok Kim 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-pvops
Re: [Xen-devel] [PATCH v2] x86emul: fold SReg PUSH/POP cases
On 08/12/16 11:40, Jan Beulich wrote: > Now that segment registers are numbered naturally this can be easily > done to achieve some code size reduction. > > Also consistently use X86EMUL_OKAY in the code being touched. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86emul: defer rIP-relative address calculation
On 08/12/16 11:40, Jan Beulich wrote: > By putting it after all instruction fetching has been done, we can both > simplify the existing handling of immediate operands and take care of > any future instructions allowing rIP-relative operands and getting > additional bytes fetched in x86_decode_*() (the current cases of extra > bytes getting fetched there are only for operands without ModR/M bytes, > or with them only allowing their register forms). > > Similarly the new placement of truncate_ea() will take care of any > future cases of non-standard memory operands (the one existing case - > opcodes A0...A3 - are fine with and without this, as they fetch an > ad_bytes sized unsigned address anyway). > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] x86emul: support 64-bit segment descriptor types
This is a prereq particularly to eventually supporting UMIP emulation,
but also for LAR/LSL/VERR/VERW.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1355,7 +1355,7 @@ protmode_load_seg(
const struct x86_emulate_ops *ops)
{
enum x86_segment sel_seg = (sel & 4) ? x86_seg_ldtr : x86_seg_gdtr;
-struct { uint32_t a, b; } desc;
+struct { uint32_t a, b; } desc, desc_hi = {};
uint8_t dpl, rpl;
int cpl = get_cpl(ctxt, ops);
uint32_t a_flag = 0x100;
@@ -1406,9 +1406,6 @@ protmode_load_seg(
/* System segments must have S flag == 0. */
if ( desc.b & (1u << 12) )
goto raise_exn;
-/* We do not support 64-bit descriptor types. */
-if ( in_longmode(ctxt, ops) )
-return X86EMUL_UNHANDLEABLE;
}
/* User segments must have S flag == 1. */
else if ( !(desc.b & (1u << 12)) )
@@ -1482,6 +1479,33 @@ protmode_load_seg(
goto raise_exn;
}
+if ( !is_x86_user_segment(seg) )
+{
+int lm = in_longmode(ctxt, ops);
+
+if ( lm < 0 )
+return X86EMUL_UNHANDLEABLE;
+if ( lm )
+{
+switch ( rc = ops->read(sel_seg, (sel & 0xfff8) + 8,
+&desc_hi, sizeof(desc_hi), ctxt) )
+{
+case X86EMUL_OKAY:
+break;
+
+case X86EMUL_EXCEPTION:
+if ( !ctxt->event_pending )
+goto raise_exn;
+/* fall through */
+default:
+return rc;
+}
+if ( (desc_hi.b & 0x1f00) ||
+ !is_canonical_address((uint64_t)desc_hi.a << 32) )
+goto raise_exn;
+}
+}
+
/* Ensure Accessed flag is set. */
if ( a_flag && !(desc.b & a_flag) )
{
@@ -1507,7 +1531,8 @@ protmode_load_seg(
desc.b = new_desc_b;
}
-sreg->base = (((desc.b << 0) & 0xff00u) |
+sreg->base = (((uint64_t)desc_hi.a << 32) |
+ ((desc.b << 0) & 0xff00u) |
((desc.b << 16) & 0x00ffu) |
((desc.a >> 16) & 0xu));
sreg->attr.bytes = (((desc.b >> 8) & 0x00ffu) |
x86emul: support 64-bit segment descriptor types
This is a prereq particularly to eventually supporting UMIP emulation,
but also for LAR/LSL/VERR/VERW.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1355,7 +1355,7 @@ protmode_load_seg(
const struct x86_emulate_ops *ops)
{
enum x86_segment sel_seg = (sel & 4) ? x86_seg_ldtr : x86_seg_gdtr;
-struct { uint32_t a, b; } desc;
+struct { uint32_t a, b; } desc, desc_hi = {};
uint8_t dpl, rpl;
int cpl = get_cpl(ctxt, ops);
uint32_t a_flag = 0x100;
@@ -1406,9 +1406,6 @@ protmode_load_seg(
/* System segments must have S flag == 0. */
if ( desc.b & (1u << 12) )
goto raise_exn;
-/* We do not support 64-bit descriptor types. */
-if ( in_longmode(ctxt, ops) )
-return X86EMUL_UNHANDLEABLE;
}
/* User segments must have S flag == 1. */
else if ( !(desc.b & (1u << 12)) )
@@ -1482,6 +1479,33 @@ protmode_load_seg(
goto raise_exn;
}
+if ( !is_x86_user_segment(seg) )
+{
+int lm = in_longmode(ctxt, ops);
+
+if ( lm < 0 )
+return X86EMUL_UNHANDLEABLE;
+if ( lm )
+{
+switch ( rc = ops->read(sel_seg, (sel & 0xfff8) + 8,
+&desc_hi, sizeof(desc_hi), ctxt) )
+{
+case X86EMUL_OKAY:
+break;
+
+case X86EMUL_EXCEPTION:
+if ( !ctxt->event_pending )
+goto raise_exn;
+/* fall through */
+default:
+return rc;
+}
+if ( (desc_hi.b & 0x1f00) ||
+ !is_canonical_address((uint64_t)desc_hi.a << 32) )
+goto raise_exn;
+}
+}
+
/* Ensure Accessed flag is set. */
if ( a_flag && !(desc.b & a_flag) )
{
@@ -1507,7 +1531,8 @@ protmode_load_seg(
desc.b = new_desc_b;
}
-sreg->base = (((desc.b << 0) & 0xff00u) |
+sreg->base = (((uint64_t)desc_hi.a << 32) |
+ ((desc.b << 0) & 0xff00u) |
((desc.b << 16) & 0x00ffu) |
((desc.a >> 16) & 0xu));
sreg->attr.bytes = (((desc.b >> 8) & 0x00ffu) |
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] x86emul: support LAR/LSL/VERR/VERW
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -46,7 +46,47 @@ static int read(
if ( verbose )
printf("** %s(%u, %p,, %u,)\n", __func__, seg, (void *)offset, bytes);
-bytes_read += bytes;
+switch ( seg )
+{
+uint64_t value;
+
+case x86_seg_gdtr:
+/* Fake system segment type matching table index. */
+if ( (offset & 7) || (bytes > 8) )
+return X86EMUL_UNHANDLEABLE;
+#ifdef __x86_64__
+if ( !(offset & 8) )
+{
+memset(p_data, 0, bytes);
+return X86EMUL_OKAY;
+}
+value = (offset - 8) >> 4;
+#else
+value = (offset - 8) >> 3;
+#endif
+if ( value >= 0x10 )
+return X86EMUL_UNHANDLEABLE;
+value |= value << 40;
+memcpy(p_data, &value, bytes);
+return X86EMUL_OKAY;
+
+case x86_seg_ldtr:
+/* Fake user segment type matching table index. */
+if ( (offset & 7) || (bytes > 8) )
+return X86EMUL_UNHANDLEABLE;
+value = offset >> 3;
+if ( value >= 0x10 )
+return X86EMUL_UNHANDLEABLE;
+value |= (value | 0x10) << 40;
+memcpy(p_data, &value, bytes);
+return X86EMUL_OKAY;
+
+default:
+if ( !is_x86_user_segment(seg) )
+return X86EMUL_UNHANDLEABLE;
+bytes_read += bytes;
+break;
+}
memcpy(p_data, (void *)offset, bytes);
return X86EMUL_OKAY;
}
@@ -75,6 +115,8 @@ static int write(
if ( verbose )
printf("** %s(%u, %p,, %u,)\n", __func__, seg, (void *)offset, bytes);
+if ( !is_x86_user_segment(seg) )
+return X86EMUL_UNHANDLEABLE;
memcpy((void *)offset, p_data, bytes);
return X86EMUL_OKAY;
}
@@ -90,10 +132,24 @@ static int cmpxchg(
if ( verbose )
printf("** %s(%u, %p,, %u,)\n", __func__, seg, (void *)offset, bytes);
+if ( !is_x86_user_segment(seg) )
+return X86EMUL_UNHANDLEABLE;
memcpy((void *)offset, new, bytes);
return X86EMUL_OKAY;
}
+static int read_segment(
+enum x86_segment seg,
+struct segment_register *reg,
+struct x86_emulate_ctxt *ctxt)
+{
+if ( !is_x86_user_segment(seg) )
+return X86EMUL_UNHANDLEABLE;
+memset(reg, 0, sizeof(*reg));
+reg->attr.fields.p = 1;
+return X86EMUL_OKAY;
+}
+
static int cpuid(
unsigned int *eax,
unsigned int *ebx,
@@ -193,6 +249,21 @@ static int read_cr(
return X86EMUL_UNHANDLEABLE;
}
+static int read_msr(
+unsigned int reg,
+uint64_t *val,
+struct x86_emulate_ctxt *ctxt)
+{
+switch ( reg )
+{
+case 0xc080: /* EFER */
+*val = ctxt->addr_size > 32 ? 0x500 /* LME|LMA */ : 0;
+return X86EMUL_OKAY;
+}
+
+return X86EMUL_UNHANDLEABLE;
+}
+
int get_fpu(
void (*exception_callback)(void *, struct cpu_user_regs *),
void *exception_callback_arg,
@@ -223,8 +294,10 @@ static struct x86_emulate_ops emulops =
.insn_fetch = fetch,
.write = write,
.cmpxchg= cmpxchg,
+.read_segment = read_segment,
.cpuid = cpuid,
.read_cr= read_cr,
+.read_msr = read_msr,
.get_fpu= get_fpu,
};
@@ -726,6 +799,156 @@ int main(int argc, char **argv)
goto fail;
printf("okay\n");
+printf("%-40s", "Testing lar (null selector)...");
+instr[0] = 0x0f; instr[1] = 0x02; instr[2] = 0xc1;
+regs.eflags = 0x240;
+regs.eip= (unsigned long)&instr[0];
+regs.ecx= 0;
+regs.eax= 0x;
+rc = x86_emulate(&ctxt, &emulops);
+if ( (rc != X86EMUL_OKAY) ||
+ (regs.eax != 0x) ||
+ (regs.eflags != 0x200) ||
+ (regs.eip != (unsigned long)&instr[3]) )
+goto fail;
+printf("okay\n");
+
+printf("%-40s", "Testing lsl (null selector)...");
+instr[0] = 0x0f; instr[1] = 0x03; instr[2] = 0xca;
+regs.eflags = 0x240;
+regs.eip= (unsigned long)&instr[0];
+regs.edx= 0;
+regs.ecx= 0x;
+rc = x86_emulate(&ctxt, &emulops);
+if ( (rc != X86EMUL_OKAY) ||
+ (regs.ecx != 0x) ||
+ (regs.eflags != 0x200) ||
+ (regs.eip != (unsigned long)&instr[3]) )
+goto fail;
+printf("okay\n");
+
+printf("%-40s", "Testing verr (null selector)...");
+instr[0] = 0x0f; instr[1] = 0x00; instr[2] = 0x21;
+regs.eflags = 0x240;
+regs.eip= (unsigned long)&instr[0];
+regs.ecx= (unsigned long)res;
+*res= 0;
+rc = x86_emulate(&ctxt, &emulops);
+if ( (rc != X86EMUL_OKAY) ||
+ (regs.eflags != 0x200) ||
+ (regs.eip != (unsigned long)&instr[3]) )
+goto fail;
+printf("okay\n");
+
+printf("%-40s", "Testing verw (null selector)...");
+instr[0] = 0x0f; instr[1] = 0x00; instr[2] = 0x2a;
+regs.eflags = 0x240;
+regs.eip= (unsigned long)&instr[0];
+regs.ecx= 0;
+regs.e
Re: [Xen-devel] [PATCH 1/2] x86emul: support 64-bit segment descriptor types
On 08/12/16 11:51, Jan Beulich wrote: > This is a prereq particularly to eventually supporting UMIP emulation, > but also for LAR/LSL/VERR/VERW. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86emul: constify write_segment() register pointer
Since I stumbled across this while looking for further constification
opportunities, also correct the insn_fetch() related comment.
Signed-off-by: Jan Beulich
---
I would have wanted to also constify the pointers passed to .write(),
.cmpxchg(), and .rep_stos(), but that doesn't work (not only) because
of hvmemul_do_mmio_buffer() being used for both directions.
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1439,7 +1439,7 @@ static int hvmemul_read_segment(
static int hvmemul_write_segment(
enum x86_segment seg,
-struct segment_register *reg,
+const struct segment_register *reg,
struct x86_emulate_ctxt *ctxt)
{
struct hvm_emulate_ctxt *hvmemul_ctxt =
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -200,7 +200,10 @@ struct x86_emulate_ops
/*
* insn_fetch: Emulate fetch from instruction byte stream.
- * Parameters are same as for 'read'. @seg is always x86_seg_cs.
+ * Except for @bytes parameters are same as for 'read'.
+ * @bytes: Access length (0 <= @bytes < 16, with zero meaning
+ * "validate address only").
+ * @seg is always x86_seg_cs.
*/
int (*insn_fetch)(
enum x86_segment seg,
@@ -306,7 +309,7 @@ struct x86_emulate_ops
*/
int (*write_segment)(
enum x86_segment seg,
-struct segment_register *reg,
+const struct segment_register *reg,
struct x86_emulate_ctxt *ctxt);
/*
x86emul: constify write_segment() register pointer
Since I stumbled across this while looking for further constification
opportunities, also correct the insn_fetch() related comment.
Signed-off-by: Jan Beulich
---
I would have wanted to also constify the pointers passed to .write(),
.cmpxchg(), and .rep_stos(), but that doesn't work (not only) because
of hvmemul_do_mmio_buffer() being used for both directions.
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1439,7 +1439,7 @@ static int hvmemul_read_segment(
static int hvmemul_write_segment(
enum x86_segment seg,
-struct segment_register *reg,
+const struct segment_register *reg,
struct x86_emulate_ctxt *ctxt)
{
struct hvm_emulate_ctxt *hvmemul_ctxt =
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -200,7 +200,10 @@ struct x86_emulate_ops
/*
* insn_fetch: Emulate fetch from instruction byte stream.
- * Parameters are same as for 'read'. @seg is always x86_seg_cs.
+ * Except for @bytes parameters are same as for 'read'.
+ * @bytes: Access length (0 <= @bytes < 16, with zero meaning
+ * "validate address only").
+ * @seg is always x86_seg_cs.
*/
int (*insn_fetch)(
enum x86_segment seg,
@@ -306,7 +309,7 @@ struct x86_emulate_ops
*/
int (*write_segment)(
enum x86_segment seg,
-struct segment_register *reg,
+const struct segment_register *reg,
struct x86_emulate_ctxt *ctxt);
/*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86emul/test: avoid meaningless output
Unconditionally reporting a skipped test in 64-bit builds is not very
useful, especially when quite a few more tests are about to be added.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -613,8 +613,8 @@ int main(int argc, char **argv)
goto fail;
printf("okay\n");
-printf("%-40s", "Testing daa/das (all inputs)...");
#ifndef __x86_64__
+printf("%-40s", "Testing daa/das (all inputs)...");
/* Bits 0-7: AL; Bit 8: EFLG_AF; Bit 9: EFLG_CF; Bit 10: DAA vs. DAS. */
for ( i = 0; i < 0x800; i++ )
{
@@ -679,9 +679,7 @@ int main(int argc, char **argv)
}
}
printf("okay\n");
-#else
-printf("skipped\n");
-
+#else /* x86-64 */
printf("%-40s", "Testing cmovz %ecx,%eax...");
instr[0] = 0x0f; instr[1] = 0x44; instr[2] = 0xc1;
regs.eflags = 0x200;
x86emul/test: avoid meaningless output
Unconditionally reporting a skipped test in 64-bit builds is not very
useful, especially when quite a few more tests are about to be added.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -613,8 +613,8 @@ int main(int argc, char **argv)
goto fail;
printf("okay\n");
-printf("%-40s", "Testing daa/das (all inputs)...");
#ifndef __x86_64__
+printf("%-40s", "Testing daa/das (all inputs)...");
/* Bits 0-7: AL; Bit 8: EFLG_AF; Bit 9: EFLG_CF; Bit 10: DAA vs. DAS. */
for ( i = 0; i < 0x800; i++ )
{
@@ -679,9 +679,7 @@ int main(int argc, char **argv)
}
}
printf("okay\n");
-#else
-printf("skipped\n");
-
+#else /* x86-64 */
printf("%-40s", "Testing cmovz %ecx,%eax...");
instr[0] = 0x0f; instr[1] = 0x44; instr[2] = 0xc1;
regs.eflags = 0x200;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86emul/test: don't log double % characters
They're useless and at best confusing.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -342,7 +342,7 @@ int main(int argc, char **argv)
if ( !stack_exec )
printf("Warning: Stack could not be made executable (%d).\n", errno);
-printf("%-40s", "Testing addl %%ecx,(%%eax)...");
+printf("%-40s", "Testing addl %ecx,(%eax)...");
instr[0] = 0x01; instr[1] = 0x08;
regs.eflags = 0x200;
regs.eip= (unsigned long)&instr[0];
@@ -357,7 +357,7 @@ int main(int argc, char **argv)
goto fail;
printf("okay\n");
-printf("%-40s", "Testing addl %%ecx,%%eax...");
+printf("%-40s", "Testing addl %ecx,%eax...");
instr[0] = 0x01; instr[1] = 0xc8;
regs.eflags = 0x200;
regs.eip= (unsigned long)&instr[0];
@@ -372,7 +372,7 @@ int main(int argc, char **argv)
goto fail;
printf("okay\n");
-printf("%-40s", "Testing xorl (%%eax),%%ecx...");
+printf("%-40s", "Testing xorl (%eax),%ecx...");
instr[0] = 0x33; instr[1] = 0x08;
regs.eflags = 0x200;
regs.eip= (unsigned long)&instr[0];
@@ -390,7 +390,7 @@ int main(int argc, char **argv)
goto fail;
printf("okay\n");
-printf("%-40s", "Testing movl (%%eax),%%ecx...");
+printf("%-40s", "Testing movl (%eax),%ecx...");
instr[0] = 0x8b; instr[1] = 0x08;
regs.eflags = 0x200;
regs.eip= (unsigned long)&instr[0];
@@ -404,7 +404,7 @@ int main(int argc, char **argv)
goto fail;
printf("okay\n");
-printf("%-40s", "Testing lock cmpxchgb %%cl,(%%ebx)...");
+printf("%-40s", "Testing lock cmpxchgb %cl,(%ebx)...");
instr[0] = 0xf0; instr[1] = 0x0f; instr[2] = 0xb0; instr[3] = 0x0b;
regs.eflags = 0x200;
regs.eip= (unsigned long)&instr[0];
@@ -420,7 +420,7 @@ int main(int argc, char **argv)
goto fail;
printf("okay\n");
-printf("%-40s", "Testing lock cmpxchgb %%cl,(%%ebx)...");
+printf("%-40s", "Testing lock cmpxchgb %cl,(%ebx)...");
instr[0] = 0xf0; instr[1] = 0x0f; instr[2] = 0xb0; instr[3] = 0x0b;
regs.eflags = 0x200;
regs.eip= (unsigned long)&instr[0];
@@ -437,7 +437,7 @@ int main(int argc, char **argv)
goto fail;
printf("okay\n");
-printf("%-40s", "Testing xchgl %%ecx,(%%eax)...");
+printf("%-40s", "Testing xchgl %ecx,(%eax)...");
instr[0] = 0x87; instr[1] = 0x08;
regs.eflags = 0x200;
regs.eip= (unsigned long)&instr[0];
@@ -452,7 +452,7 @@ int main(int argc, char **argv)
goto fail;
printf("okay\n");
-printf("%-40s", "Testing lock cmpxchgl %%ecx,(%%ebx)...");
+printf("%-40s", "Testing lock cmpxchgl %ecx,(%ebx)...");
instr[0] = 0xf0; instr[1] = 0x0f; instr[2] = 0xb1; instr[3] = 0x0b;
regs.eflags = 0x200;
*res= 0x923456AA;
@@ -570,7 +570,7 @@ int main(int argc, char **argv)
goto fail;
printf("okay\n");
-printf("%-40s", "Testing movsxbd (%%eax),%%ecx...");
+printf("%-40s", "Testing movsxbd (%eax),%ecx...");
instr[0] = 0x0f; instr[1] = 0xbe; instr[2] = 0x08;
regs.eflags = 0x200;
regs.eip= (unsigned long)&instr[0];
@@ -586,7 +586,7 @@ int main(int argc, char **argv)
goto fail;
printf("okay\n");
-printf("%-40s", "Testing movzxwd (%%eax),%%ecx...");
+printf("%-40s", "Testing movzxwd (%eax),%ecx...");
instr[0] = 0x0f; instr[1] = 0xb7; instr[2] = 0x08;
regs.eflags = 0x200;
regs.eip= (unsigned long)&instr[0];
@@ -603,7 +603,7 @@ int main(int argc, char **argv)
printf("okay\n");
#ifndef __x86_64__
-printf("%-40s", "Testing arpl %cx,(%%eax)...");
+printf("%-40s", "Testing arpl %cx,(%eax)...");
instr[0] = 0x63; instr[1] = 0x08;
regs.eflags = 0x200;
regs.eip= (unsigned long)&instr[0];
@@ -619,7 +619,7 @@ int main(int argc, char **argv)
(regs.eip != (unsigned long)&instr[2]) )
goto fail;
#else
-printf("%-40s", "Testing movsxd (%%rax),%%rcx...");
+printf("%-40s", "Testing movsxd (%rax),%rcx...");
instr[0] = 0x48; instr[1] = 0x63; instr[2] = 0x08;
regs.eip= (unsigned long)&instr[0];
regs.ecx= 0x123456789abcdef;
@@ -640,7 +640,7 @@ int main(int argc, char **argv)
#endif
printf("okay\n");
-printf("%-40s", "Testing xadd %%ax,(%%ecx)...");
+printf("%-40s", "Testing xadd %ax,(%ecx)...");
instr[0] = 0x66; instr[1] = 0x0f; instr[2] = 0xc1; instr[3] = 0x01;
regs.eflags = 0x200;
regs.eip= (unsigned long)&instr[0];
@@ -656,7 +656,7 @@ int main(int argc, char **argv)
goto fail;
printf("okay\n");
-printf("%-40s", "Testing dec %%ax...");
+printf("%-40s", "Testing dec %ax...");
#ifndef __x86_64__
instr[0] = 0x66; instr[1] = 0x48;
#else
@@ -673,7 +673,7 @@ int main(int argc, char **argv)
goto fail;
printf("okay\n");
-printf("%-40s", "Testing lea 8(%%ebp),%%eax...");
+
Re: [Xen-devel] [PATCH 2/3] x86/HVM: support (emulate) UMIP
>>> On 06.12.16 at 15:47, wrote: > As for UMIP itself, there are a number of issues which we should > consider here. > > First, this adds quite a lot of emulation and extra handling in security > sensitive areas. That isn't a problem per say, but given concerns with > emulation in general (and indeed the efforts to remove all emulation > from some usecases), making it unilaterally enabled is a problem. As mentioned in the commit description. > As such, I think emulated-UMIP is an option which the user must > explicitly opt-in to. The easiest option might be to defer adding > emulated-UMIP until I have split the default and max featureset options > in the CPUID policy ABI (which is the task I am currently working ok). Makes sense. > However, it would also require only enabling the SVM GP intercept in the > hvm_update_guest_vendor() path (which should be renamed to something > slightly more generic like hvm_cpuid_policy_updated()). Why that? We always need it intercepted as long as the guest wants UMIP, but the hardware doesn't offer it. The feature isn't tied to the vendor being Intel or some such. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86emul: constify write_segment() register pointer
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 08 December 2016 11:53
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
>
> Subject: [PATCH] x86emul: constify write_segment() register pointer
>
> Since I stumbled across this while looking for further constification
> opportunities, also correct the insn_fetch() related comment.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
> ---
> I would have wanted to also constify the pointers passed to .write(),
> .cmpxchg(), and .rep_stos(), but that doesn't work (not only) because
> of hvmemul_do_mmio_buffer() being used for both directions.
>
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1439,7 +1439,7 @@ static int hvmemul_read_segment(
>
> static int hvmemul_write_segment(
> enum x86_segment seg,
> -struct segment_register *reg,
> +const struct segment_register *reg,
> struct x86_emulate_ctxt *ctxt)
> {
> struct hvm_emulate_ctxt *hvmemul_ctxt =
> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
> @@ -200,7 +200,10 @@ struct x86_emulate_ops
>
> /*
> * insn_fetch: Emulate fetch from instruction byte stream.
> - * Parameters are same as for 'read'. @seg is always x86_seg_cs.
> + * Except for @bytes parameters are same as for 'read'.
> + * @bytes: Access length (0 <= @bytes < 16, with zero meaning
> + * "validate address only").
> + * @seg is always x86_seg_cs.
> */
> int (*insn_fetch)(
> enum x86_segment seg,
> @@ -306,7 +309,7 @@ struct x86_emulate_ops
> */
> int (*write_segment)(
> enum x86_segment seg,
> -struct segment_register *reg,
> +const struct segment_register *reg,
> struct x86_emulate_ctxt *ctxt);
>
> /*
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 103013: all pass - PUSHED
flight 103013 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103013/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 854c6b80dc3f1d4a151322b21c5fb6952b159ca9
baseline version:
ovmf 2c1cc12931b6c5a85471272799b3d4c249025a60
Last test of basis 102955 2016-12-05 17:01:18 Z2 days
Testing same since 103013 2016-12-07 08:13:06 Z1 days1 attempts
People who touched revisions under test:
Anthony PERARD
Dandan Bi
Jiaxin Wu
Jiewen Yao
Laszlo Ersek
Leif Lindholm
Michael Kinney
Ruiyu Ni
Zhang Lubo
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=854c6b80dc3f1d4a151322b21c5fb6952b159ca9
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
854c6b80dc3f1d4a151322b21c5fb6952b159ca9
+ branch=ovmf
+ revision=854c6b80dc3f1d4a151322b21c5fb6952b159ca9
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x854c6b80dc3f1d4a151322b21c5fb6952b159ca9 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git
[Xen-devel] [xen-unstable-smoke test] 103082: tolerable all pass - PUSHED
flight 103082 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103082/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen f5b9217531dac37451845cd83dfd30e4cc1053b4
baseline version:
xen 3651d9e5c0f90e94d41187a69f04df3647c61a82
Last test of basis 103062 2016-12-08 03:02:50 Z0 days
Testing same since 103082 2016-12-08 12:01:37 Z0 days1 attempts
People who touched revisions under test:
Jan Beulich
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=f5b9217531dac37451845cd83dfd30e4cc1053b4
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
f5b9217531dac37451845cd83dfd30e4cc1053b4
+ branch=xen-unstable-smoke
+ revision=f5b9217531dac37451845cd83dfd30e4cc1053b4
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' xf5b9217531dac37451845cd83dfd30e4cc1053b4 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/
[Xen-devel] [PATCH VERY RFC 5/5] tools/fuzz: add README
Signed-off-by: Wei Liu --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu --- tools/fuzz/README | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 tools/fuzz/README diff --git a/tools/fuzz/README b/tools/fuzz/README new file mode 100644 index 000..6e4d4bb --- /dev/null +++ b/tools/fuzz/README @@ -0,0 +1,7 @@ +This directory provides fuzzing targets to be run inside Google +oss-fuzz infrastructure. + +See also https://github.com/google/oss-fuzz. + +To run each fuzzing target in standalone mode, please refer to +oss-fuzz documents. -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH VERY RFC 1/5] libelf: don't always include libxc headers
Introduce FUZZ_NO_LIBXC in libelf-private.h. That macro will be set when compiling libelf fuzzer target because libxc is not required in libelf fuzzing. Signed-off-by: Wei Liu --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu --- xen/common/libelf/libelf-private.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/common/libelf/libelf-private.h b/xen/common/libelf/libelf-private.h index 388c3da..47db679 100644 --- a/xen/common/libelf/libelf-private.h +++ b/xen/common/libelf/libelf-private.h @@ -72,8 +72,10 @@ #include #include +#ifndef FUZZ_NO_LIBXC #include "xenctrl.h" #include "xc_private.h" +#endif #define elf_msg(elf, fmt, args ... )\ elf_call_log_callback(elf, 0, fmt , ## args ); -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH VERY RFC 0/5] Fuzzing targets for oss-fuzz
Hi all This series adds two fuzzing targets to run in Google's oss-fuzz infrastructure. There will be some other patches on the oss-fuzz side. Their recommendation is to have all the fuzzing targets committed in our tree so that they can be kept up to date. The fuzzing targets aren't very sophiscated at the moment. The purpose of this series is to gather feedback at this early stage. We can always improve the fuzzing code in the future. Wei. Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu Wei Liu (5): libelf: don't always include libxc headers tools/fuzz: introduce libelf target tools/fuzz: introduce x86 instruction emulator target tools: hook up fuzz directory tools/fuzz: add README .gitignore | 1 + tools/Makefile | 1 + tools/fuzz/Makefile| 11 + tools/fuzz/README | 7 + tools/fuzz/libelf/Makefile | 31 ++ tools/fuzz/libelf/libelf-fuzzer.c | 32 ++ tools/fuzz/x86_instruction_emulator/Makefile | 33 ++ .../x86-insn-emulator-fuzzer.c | 335 + xen/common/libelf/libelf-private.h | 2 + 9 files changed, 453 insertions(+) create mode 100644 tools/fuzz/Makefile create mode 100644 tools/fuzz/README create mode 100644 tools/fuzz/libelf/Makefile create mode 100644 tools/fuzz/libelf/libelf-fuzzer.c create mode 100644 tools/fuzz/x86_instruction_emulator/Makefile create mode 100644 tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH VERY RFC 4/5] tools: hook up fuzz directory
This will make all fuzzing targets get build every time tools directory is built. This serves as basic regression test. Signed-off-by: Wei Liu --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu --- tools/Makefile | 1 + tools/fuzz/Makefile | 11 +++ 2 files changed, 12 insertions(+) create mode 100644 tools/fuzz/Makefile diff --git a/tools/Makefile b/tools/Makefile index 71515b4..77e0723 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -6,6 +6,7 @@ SUBDIRS-y += include SUBDIRS-y += libs SUBDIRS-y += libxc SUBDIRS-y += flask +SUBDIRS-y += fuzz SUBDIRS-y += xenstore SUBDIRS-y += misc SUBDIRS-y += examples diff --git a/tools/fuzz/Makefile b/tools/fuzz/Makefile new file mode 100644 index 000..ce00b82 --- /dev/null +++ b/tools/fuzz/Makefile @@ -0,0 +1,11 @@ +XEN_ROOT = $(CURDIR)/../.. +include $(XEN_ROOT)/tools/Rules.mk + +SUBDIRS-y := +SUBDIRS-y += libelf +SUBDIRS-y += x86_instruction_emulator + +.PHONY: all clean distclean +all clean distclean: %: subdirs-% + +install: -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH VERY RFC 3/5] tools/fuzz: introduce x86 instruction emulator target
Instruction emulator fuzzing code is from code previous written by
Andrew and George. Adapted to llvm fuzzer and hook up the build system.
Signed-off-by: Andrew Cooper
Signed-off-by: George Dunlap
Signed-off-by: Wei Liu
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
.gitignore | 1 +
tools/fuzz/x86_instruction_emulator/Makefile | 33 ++
.../x86-insn-emulator-fuzzer.c | 335 +
3 files changed, 369 insertions(+)
create mode 100644 tools/fuzz/x86_instruction_emulator/Makefile
create mode 100644
tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c
diff --git a/.gitignore b/.gitignore
index a2f34a1..d507243 100644
--- a/.gitignore
+++ b/.gitignore
@@ -145,6 +145,7 @@ tools/flask/utils/flask-loadpolicy
tools/flask/utils/flask-setenforce
tools/flask/utils/flask-set-bool
tools/flask/utils/flask-label-pci
+tools/fuzz/x86_instruction_emulator/x86_emulate*
tools/helpers/_paths.h
tools/helpers/init-xenstore-domain
tools/helpers/xen-init-dom0
diff --git a/tools/fuzz/x86_instruction_emulator/Makefile
b/tools/fuzz/x86_instruction_emulator/Makefile
new file mode 100644
index 000..374c84a
--- /dev/null
+++ b/tools/fuzz/x86_instruction_emulator/Makefile
@@ -0,0 +1,33 @@
+XEN_ROOT=$(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+x86-instruction-emulator-fuzzer-all: x86-insn-emulator.a
x86-insn-emulator-fuzzer.o
+
+x86_emulate/x86_emulate.c x86_emulate/x86_emulate.h:
+ [ -L x86_emulate ] || ln -sf $(XEN_ROOT)/xen/arch/x86/x86_emulate .
+
+x86_emulate.c:
+ [ -L x86_emulate.c ] || ln -sf
$(XEN_ROOT)/tools/tests/x86_emulator/x86_emulate.c
+
+x86_emulate.h:
+ [ -L x86_emulate.h ] || ln -sf
$(XEN_ROOT)/tools/tests/x86_emulator/x86_emulate.h
+
+CFLAGS += $(CFLAGS_xeninclude)
+
+x86_emulate.o: x86_emulate.c x86_emulate.h x86_emulate/x86_emulate.c
x86_emulate/x86_emulate.h
+
+x86-insn-emulator.a: x86_emulate.o
+ $(AR) rc $@ $^
+
+x86-insn-emulator-fuzzer.o: x86-insn-emulator-fuzzer.c
+
+# Common targets
+.PHONY: all
+all: x86-instruction-emulator-fuzzer-all
+
+.PHONY: distclean
+distclean: clean
+
+.PHONY: clean
+clean:
+ rm -f *.a *.o
diff --git a/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c
b/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c
new file mode 100644
index 000..01ee7a4
--- /dev/null
+++ b/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c
@@ -0,0 +1,335 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define __packed __attribute__((packed))
+#define ASSERT assert
+
+#include "x86_emulate/x86_emulate.h"
+
+/* EFLAGS bit definitions. */
+#define EFLG_OF (1<<11)
+#define EFLG_DF (1<<10)
+#define EFLG_SF (1<<7)
+#define EFLG_ZF (1<<6)
+#define EFLG_AF (1<<4)
+#define EFLG_PF (1<<2)
+#define EFLG_CF (1<<0)
+
+static unsigned char data[4096];
+static unsigned int data_index = 0;
+static unsigned int data_max;
+
+int data_read(const char *why, void *dst, unsigned int bytes) {
+
+if ( data_index + bytes > data_max )
+return X86EMUL_EXCEPTION;
+
+memcpy(dst, data+data_index, bytes);
+data_index += bytes;
+
+return X86EMUL_OKAY;
+}
+
+static int emul_read(
+unsigned int seg,
+unsigned long offset,
+void *p_data,
+unsigned int bytes,
+struct x86_emulate_ctxt *ctxt)
+{
+return data_read("read", p_data, bytes);
+}
+
+static int emul_fetch(
+unsigned int seg,
+unsigned long offset,
+void *p_data,
+unsigned int bytes,
+struct x86_emulate_ctxt *ctxt)
+{
+return data_read("fetch", p_data, bytes);
+}
+
+static int emul_write(
+unsigned int seg,
+unsigned long offset,
+void *p_data,
+unsigned int bytes,
+struct x86_emulate_ctxt *ctxt)
+{
+return X86EMUL_OKAY;
+}
+
+static int emul_cmpxchg(
+unsigned int seg,
+unsigned long offset,
+void *old,
+void *new,
+unsigned int bytes,
+struct x86_emulate_ctxt *ctxt)
+{
+return X86EMUL_OKAY;
+}
+
+static int emul_cpuid(
+unsigned int *eax,
+unsigned int *ebx,
+unsigned int *ecx,
+unsigned int *edx,
+struct x86_emulate_ctxt *ctxt)
+{
+unsigned int leaf = *eax;
+
+asm ("cpuid" : "+a" (*eax), "+c" (*ecx), "=d" (*edx), "=b" (*ebx));
+
+/* The emulator doesn't itself use MOVBE, so we can always run the test. */
+if ( leaf == 1 )
+*ecx |= 1U << 22;
+
+return X86EMUL_OKAY;
+}
+
+#define cache_line_size() ({ \
+unsigned int eax = 1, ebx, ecx = 0, edx; \
+emul_cpuid(&eax, &ebx, &ecx, &edx, NULL); \
+edx & (1U << 19) ? (ebx >> 5) & 0x7f8 : 0; \
+})
+
+#define cpu_has_mmx ({ \
+unsigned int eax = 1, ecx = 0, edx; \
+emul_cpuid(&eax, &ecx, &ecx, &edx, NULL); \
+(edx & (1U << 23))
[Xen-devel] [PATCH v2] libxl: QED disks support
Qdisk supports qcow and qcow2, extend it to also support qed disk
format.
Signed-off-by: Cédric Bosdonnat
---
v2:
* Add qed to the list for possible format values in xl-disk-configuration.txt
* Add LIBXL_HAVE_QED
---
docs/misc/xl-disk-configuration.txt |4 +-
tools/libxl/libxl.h |7 +
tools/libxl/libxl_device.c |1 +
tools/libxl/libxl_dm.c |1 +
tools/libxl/libxl_types.idl |1 +
tools/libxl/libxl_utils.c |2 +
tools/libxl/libxlu_disk_l.c | 1018 ++-
tools/libxl/libxlu_disk_l.h | 53 +-
tools/libxl/libxlu_disk_l.l |3 +-
9 files changed, 548 insertions(+), 542 deletions(-)
diff --git a/docs/misc/xl-disk-configuration.txt
b/docs/misc/xl-disk-configuration.txt
index b3402bc33a..310d2586c0 100644
--- a/docs/misc/xl-disk-configuration.txt
+++ b/docs/misc/xl-disk-configuration.txt
@@ -87,7 +87,7 @@ format
--
Description: Specifies the format of image file.
-Supported values: raw, qcow, qcow2, vhd
+Supported values: raw, qcow, qcow2, vhd, qed
Deprecated values: None
Default value: raw
@@ -311,7 +311,7 @@ are found prepended to the format parameter - eg
"tap:aio:qcow:".
-
Description: Specifies the format (deprecated)
-Supported values: raw: qcow2: vhd:
+Supported values: raw: qcow2: vhd: qed:
In xend and old versions of libxl it was necessary to specify the
format with a prefix. For compatibility, these three prefixes are
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index acbf47690e..3924464588 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1012,6 +1012,13 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst,
const libxl_mac *src);
*/
#define LIBXL_HAVE_MEMKB_64BITS 1
+/*
+ * LIBXL_HAVE_QED
+ *
+ * If this is defined QED disk formats can be used for both HVM and PV guests.
+ */
+#define LIBXL_HAVE_QED 1
+
typedef char **libxl_string_list;
void libxl_string_list_dispose(libxl_string_list *sl);
int libxl_string_list_length(const libxl_string_list *sl);
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 3e7a1026c4..6c34141072 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -411,6 +411,7 @@ char *libxl__device_disk_string_of_format(libxl_disk_format
format)
case LIBXL_DISK_FORMAT_VHD: return "vhd";
case LIBXL_DISK_FORMAT_RAW:
case LIBXL_DISK_FORMAT_EMPTY: return "aio";
+case LIBXL_DISK_FORMAT_QED: return "qed";
default: return NULL;
}
}
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index ad366a8cd3..8b373422f1 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -677,6 +677,7 @@ static const char
*qemu_disk_format_string(libxl_disk_format format)
case LIBXL_DISK_FORMAT_VHD: return "vpc";
case LIBXL_DISK_FORMAT_RAW: return "raw";
case LIBXL_DISK_FORMAT_EMPTY: return NULL;
+case LIBXL_DISK_FORMAT_QED: return "qed";
default: return NULL;
}
}
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index a32c751b0e..a612d1f4ff 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -114,6 +114,7 @@ libxl_disk_format = Enumeration("disk_format", [
(3, "VHD"),
(4, "RAW"),
(5, "EMPTY"),
+(6, "QED"),
])
libxl_disk_backend = Enumeration("disk_backend", [
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 49cbaa5b70..507ee56c7c 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -317,6 +317,8 @@ int libxl_string_to_backend(libxl_ctx *ctx, char *s,
libxl_disk_backend *backend
*backend = LIBXL_DISK_BACKEND_QDISK;
} else if (!strcmp(p, "qcow2")) {
*backend = LIBXL_DISK_BACKEND_QDISK;
+} else if (!strcmp(p, "qed")) {
+*backend = LIBXL_DISK_BACKEND_QDISK;
}
}
out:
diff --git a/tools/libxl/libxlu_disk_l.c b/tools/libxl/libxlu_disk_l.c
index 54160caa66..fa09a69303 100644
--- a/tools/libxl/libxlu_disk_l.c
+++ b/tools/libxl/libxlu_disk_l.c
@@ -1,10 +1,7 @@
#line 2 "libxlu_disk_l.c"
-#line 31 "libxlu_disk_l.l"
#include "libxl_osdeps.h" /* must come before any other headers */
-
-
-#line 8 "libxlu_disk_l.c"
+#line 5 "libxlu_disk_l.c"
#define YY_INT_ALIGNED short int
@@ -12,8 +9,8 @@
#define FLEX_SCANNER
#define YY_FLEX_MAJOR_VERSION 2
-#define YY_FLEX_MINOR_VERSION 5
-#define YY_FLEX_SUBMINOR_VERSION 39
+#define YY_FLEX_MINOR_VERSION 6
+#define YY_FLEX_SUBMINOR_VERSION 1
#if YY_FLEX_SUBMINOR_VERSION > 0
#define FLEX_BETA
#endif
@@ -92,25 +89,13 @@ typedef unsigned int flex_uint32_t;
#endif /* ! FLEXINT_H */
-#ifdef __cplusplus
-
-/* The "const" storage-class-modifier is valid. */
-#define YY_USE_CONST
-
-#else /* ! __cplusplus */
-
-/* C99 requires __STDC__ to be defined as 1. */
-#if defined (__STDC__)
-
-
[Xen-devel] [PATCH VERY RFC 2/5] tools/fuzz: introduce libelf target
A simple program and Makefile to fuzz libelf in Google's oss-fuzz
infrastructure.
Signed-off-by: Wei Liu
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
tools/fuzz/libelf/Makefile| 31 +++
tools/fuzz/libelf/libelf-fuzzer.c | 32
2 files changed, 63 insertions(+)
create mode 100644 tools/fuzz/libelf/Makefile
create mode 100644 tools/fuzz/libelf/libelf-fuzzer.c
diff --git a/tools/fuzz/libelf/Makefile b/tools/fuzz/libelf/Makefile
new file mode 100644
index 000..0e9d40a
--- /dev/null
+++ b/tools/fuzz/libelf/Makefile
@@ -0,0 +1,31 @@
+XEN_ROOT = $(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+# libelf fuzz target
+vpath %.c ../../../xen/common/libelf
+CFLAGS += -I../../../xen/common/libelf
+ELF_SRCS-y += libelf-tools.c libelf-loader.c libelf-dominfo.c
+ELF_LIB_OBJS := $(patsubst %.c,%.o,$(ELF_SRCS-y))
+
+$(patsubst %.c,%.o,$(ELF_SRCS-y)): CFLAGS += -Wno-pointer-sign
+
+$(ELF_LIB_OBJS): CFLAGS += -DFUZZ_NO_LIBXC $(CFLAGS_xeninclude)
+
+libelf-fuzzer.o: CFLAGS += $(CFLAGS_xeninclude)
+
+libelf.a: $(ELF_LIB_OBJS)
+ $(AR) rc $@ $^
+
+.PHONY: libelf-fuzzer-all
+libelf-fuzzer-all: libelf.a libelf-fuzzer.o
+
+# Common targets
+.PHONY: all
+all: libelf-fuzzer-all
+
+.PHONY: distclean
+distclean: clean
+
+.PHONY: clean
+clean:
+ rm -f *.o *.a
diff --git a/tools/fuzz/libelf/libelf-fuzzer.c
b/tools/fuzz/libelf/libelf-fuzzer.c
new file mode 100644
index 000..71561d3
--- /dev/null
+++ b/tools/fuzz/libelf/libelf-fuzzer.c
@@ -0,0 +1,32 @@
+#include
+#include
+#include
+#include
+
+#include
+
+int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size)
+{
+struct elf_binary elf_buf, *elf;
+struct elf_dom_parms parms;
+
+elf = &elf_buf;
+
+memset(elf, 0, sizeof(*elf));
+elf_init(elf, (const char *)data, size);
+elf_parse_binary(elf);
+elf_xen_parse(elf, &parms);
+
+return 0;
+}
+
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86emul: constify write_segment() register pointer
On 08/12/16 11:53, Jan Beulich wrote:
> Since I stumbled across this while looking for further constification
> opportunities, also correct the insn_fetch() related comment.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper , although a
suggestion about the wording.
> ---
> I would have wanted to also constify the pointers passed to .write(),
> .cmpxchg(), and .rep_stos(), but that doesn't work (not only) because
> of hvmemul_do_mmio_buffer() being used for both directions.
>
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1439,7 +1439,7 @@ static int hvmemul_read_segment(
>
> static int hvmemul_write_segment(
> enum x86_segment seg,
> -struct segment_register *reg,
> +const struct segment_register *reg,
> struct x86_emulate_ctxt *ctxt)
> {
> struct hvm_emulate_ctxt *hvmemul_ctxt =
> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
> @@ -200,7 +200,10 @@ struct x86_emulate_ops
>
> /*
> * insn_fetch: Emulate fetch from instruction byte stream.
> - * Parameters are same as for 'read'. @seg is always x86_seg_cs.
> + * Except for @bytes parameters are same as for 'read'.
"Except for @bytes, all parameters are the same..."
> + * @bytes: Access length (0 <= @bytes < 16, with zero meaning
> + * "validate address only").
> + * @seg is always x86_seg_cs.
> */
> int (*insn_fetch)(
> enum x86_segment seg,
> @@ -306,7 +309,7 @@ struct x86_emulate_ops
> */
> int (*write_segment)(
> enum x86_segment seg,
> -struct segment_register *reg,
> +const struct segment_register *reg,
> struct x86_emulate_ctxt *ctxt);
>
> /*
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86emul/test: avoid meaningless output
On 08/12/16 11:53, Jan Beulich wrote: > Unconditionally reporting a skipped test in 64-bit builds is not very > useful, especially when quite a few more tests are about to be added. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86emul/test: don't log double % characters
On 08/12/16 11:54, Jan Beulich wrote: > They're useless and at best confusing. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] libelf: Fix div0 issues in elf_{shdr, phdr}_count()
elf_uval() can return zero either because the field itself is zero, or because
the access is out of bounds.
c/s a01b6d4 "libelf: treat phdr and shdr similarly" introduced two div0 issues
as e_{ph,sh}entsize are not checked for sanity before being used to divide
elf->size.
Spotted by Coverity.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
I experimented with making elf_access_unsigned() __must_check, but this didn't
cause a compiler error. I am not quite sure why.
---
xen/common/libelf/libelf-tools.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/xen/common/libelf/libelf-tools.c b/xen/common/libelf/libelf-tools.c
index bf661e7..f62d9c3 100644
--- a/xen/common/libelf/libelf-tools.c
+++ b/xen/common/libelf/libelf-tools.c
@@ -130,11 +130,17 @@ uint64_t elf_round_up(struct elf_binary *elf, uint64_t
addr)
unsigned elf_shdr_count(struct elf_binary *elf)
{
unsigned count = elf_uval(elf, elf->ehdr, e_shnum);
+unsigned entsize = elf_uval(elf, elf->ehdr, e_shentsize);
uint64_t max;
if ( !count )
return 0;
-max = elf->size / elf_uval(elf, elf->ehdr, e_shentsize);
+if ( !entsize )
+{
+elf_mark_broken(elf, "e_shentsize is zero");
+return 0;
+}
+max = elf->size / entsize;
if ( max > UINT_MAX )
max = UINT_MAX;
if ( count > max )
@@ -148,11 +154,17 @@ unsigned elf_shdr_count(struct elf_binary *elf)
unsigned elf_phdr_count(struct elf_binary *elf)
{
unsigned count = elf_uval(elf, elf->ehdr, e_phnum);
+unsigned entsize = elf_uval(elf, elf->ehdr, e_phentsize);
uint64_t max;
if ( !count )
return 0;
-max = elf->size / elf_uval(elf, elf->ehdr, e_phentsize);
+if ( !entsize )
+{
+elf_mark_broken(elf, "e_phentsize is zero");
+return 0;
+}
+max = elf->size / entsize;
if ( max > UINT_MAX )
max = UINT_MAX;
if ( count > max )
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [linux-4.1 test] 103011: regressions - trouble: broken/fail/pass
flight 103011 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/103011/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 101737 test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 101737 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101737 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101737 test-amd64-amd64-xl-multivcpu 6 xen-bootfail REGR. vs. 101737 test-amd64-i386-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 101737 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101737 test-amd64-i386-pair 9 xen-boot/src_hostfail REGR. vs. 101737 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101737 test-amd64-amd64-qemuu-nested-intel 6 xen-boot fail REGR. vs. 101737 test-amd64-amd64-xl-pvh-intel 6 xen-bootfail REGR. vs. 101737 test-amd64-i386-freebsd10-amd64 6 xen-boot fail REGR. vs. 101737 build-armhf-pvops 5 kernel-build fail in 102733 REGR. vs. 101737 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken pass in 102979 test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken pass in 102979 test-amd64-i386-xl3 host-install(3) broken pass in 102979 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken pass in 102979 test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3) broken pass in 102979 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken pass in 102979 test-amd64-amd64-libvirt-vhd 9 debian-di-install fail in 102733 pass in 102886 test-armhf-armhf-libvirt-xsm 14 guest-stop fail in 102755 pass in 102979 test-amd64-amd64-xl-xsm 19 guest-start/debian.repeat fail in 102755 pass in 103011 test-armhf-armhf-xl-multivcpu 11 guest-start fail in 102829 pass in 103011 test-amd64-i386-xl-xsm6 xen-boot fail in 102886 pass in 103011 test-amd64-amd64-qemuu-nested-amd 9 debian-hvm-install fail in 102886 pass in 103011 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail in 102886 pass in 103011 test-armhf-armhf-xl-rtds 6 xen-boot fail in 102979 pass in 103011 test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail pass in 102733 test-amd64-amd64-libvirt 6 xen-boot fail pass in 102733 test-amd64-i386-xl-raw6 xen-boot fail pass in 102733 test-amd64-i386-libvirt-xsm 6 xen-boot fail pass in 102755 test-amd64-amd64-xl-qemut-winxpsp3 6 xen-boot fail pass in 102755 test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail pass in 102829 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 102886 test-amd64-amd64-libvirt-vhd 6 xen-boot fail pass in 102886 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail pass in 102979 test-armhf-armhf-libvirt-xsm 11 guest-startfail pass in 102979 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 102755 like 101715 test-armhf-armhf-xl-rtds 16 guest-start.2 fail in 102886 blocked in 101737 test-amd64-i386-rumprun-i386 16 rumprun-demo-xenstorels/xenstorels.repeat fail in 102886 blocked in 101737 test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail in 102979 like 101715 test-armhf-armhf-xl-credit2 11 guest-start fail in 102979 like 101737 test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail in 102979 like 101737 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail in 102979 like 101737 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 102979 like 101737 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail in 102979 like 101737 test-armhf-armhf-libvirt 15 guest-start/debian.repeatfail like 101672 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeatfail like 101687 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail like 101715 test-armhf-armhf-xl-xsm 11 guest-start fail like 101737 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 101737 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101737 test-armhf-armhf-xl 15 guest-start/debian.repeatfail like 101737 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeatfail like 101737 test-armhf-armhf-xl-vhd 9 debian-di-installfail like 101737 test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail like 101737 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked i
[Xen-devel] [distros-debian-wheezy test] 68176: all pass
flight 68176 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68176/ Perfect :-) All tests in this flight passed as required baseline version: flight 68133 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass test-amd64-i386-i386-wheezy-netboot-pvgrub pass test-amd64-i386-amd64-wheezy-netboot-pygrub pass test-amd64-amd64-i386-wheezy-netboot-pygrub pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] schedulers' use of cpumask_scratch
Dario, analyzing a stack overflow I've run into the other day I came across credit1's __runq_tickle() not only itself having two cpumask_t variables on the stack, but then also calling cpumask_raise_softirq() (which uses yet one more). I then recalled you have a scratch mask in the scheduler, and I did look at where it's used. While it's already in use in credit1's __runq_tickle(), I then got puzzled by the different ways credit1 and credit2 use the variable: The former always uses scratch_cpumask_cpu() with the subject CPU as argument, while the latter always uses plain scratch_cpumask. What guarantees that these two uses never conflict, if both schedulers are active for some part of the system? Thanks, Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libelf: Fix div0 issues in elf_{shdr, phdr}_count()
>>> On 08.12.16 at 15:18, wrote:
> elf_uval() can return zero either because the field itself is zero, or because
> the access is out of bounds.
>
> c/s a01b6d4 "libelf: treat phdr and shdr similarly" introduced two div0 issues
> as e_{ph,sh}entsize are not checked for sanity before being used to divide
> elf->size.
>
> Spotted by Coverity.
And wrongly so, imo.
> --- a/xen/common/libelf/libelf-tools.c
> +++ b/xen/common/libelf/libelf-tools.c
> @@ -130,11 +130,17 @@ uint64_t elf_round_up(struct elf_binary *elf, uint64_t
> addr)
> unsigned elf_shdr_count(struct elf_binary *elf)
> {
> unsigned count = elf_uval(elf, elf->ehdr, e_shnum);
> +unsigned entsize = elf_uval(elf, elf->ehdr, e_shentsize);
> uint64_t max;
>
> if ( !count )
> return 0;
> -max = elf->size / elf_uval(elf, elf->ehdr, e_shentsize);
> +if ( !entsize )
> +{
> +elf_mark_broken(elf, "e_shentsize is zero");
> +return 0;
> +}
This as well as ...
> @@ -148,11 +154,17 @@ unsigned elf_shdr_count(struct elf_binary *elf)
> unsigned elf_phdr_count(struct elf_binary *elf)
> {
> unsigned count = elf_uval(elf, elf->ehdr, e_phnum);
> +unsigned entsize = elf_uval(elf, elf->ehdr, e_phentsize);
> uint64_t max;
>
> if ( !count )
> return 0;
> -max = elf->size / elf_uval(elf, elf->ehdr, e_phentsize);
> +if ( !entsize )
> +{
> +elf_mark_broken(elf, "e_phentsize is zero");
> +return 0;
> +}
... this would end up being dead code, due to the checks the same
patch you refer to introduced in elf_init().
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH VERY RFC 1/5] libelf: don't always include libxc headers
>>> On 08.12.16 at 14:54, wrote: > --- a/xen/common/libelf/libelf-private.h > +++ b/xen/common/libelf/libelf-private.h > @@ -72,8 +72,10 @@ > #include > #include > > +#ifndef FUZZ_NO_LIBXC > #include "xenctrl.h" > #include "xc_private.h" > +#endif If put in together with patch 2 (which I think it should really be part of) this can have my ack; I don't think it makes sense to put in on its own. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH VERY RFC 2/5] tools/fuzz: introduce libelf target
>>> On 08.12.16 at 14:54, wrote: > A simple program and Makefile to fuzz libelf in Google's oss-fuzz > infrastructure. Mind adding some description here on how this is expected to work / be used? The new Makefile produce an object file and an archive, but no binary, so it's not clear to me what use this is. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libelf: Fix div0 issues in elf_{shdr, phdr}_count()
On 08/12/16 14:41, Jan Beulich wrote:
On 08.12.16 at 15:18, wrote:
>> elf_uval() can return zero either because the field itself is zero, or
>> because
>> the access is out of bounds.
>>
>> c/s a01b6d4 "libelf: treat phdr and shdr similarly" introduced two div0
>> issues
>> as e_{ph,sh}entsize are not checked for sanity before being used to divide
>> elf->size.
>>
>> Spotted by Coverity.
> And wrongly so, imo.
>
>> --- a/xen/common/libelf/libelf-tools.c
>> +++ b/xen/common/libelf/libelf-tools.c
>> @@ -130,11 +130,17 @@ uint64_t elf_round_up(struct elf_binary *elf, uint64_t
>> addr)
>> unsigned elf_shdr_count(struct elf_binary *elf)
>> {
>> unsigned count = elf_uval(elf, elf->ehdr, e_shnum);
>> +unsigned entsize = elf_uval(elf, elf->ehdr, e_shentsize);
>> uint64_t max;
>>
>> if ( !count )
>> return 0;
>> -max = elf->size / elf_uval(elf, elf->ehdr, e_shentsize);
>> +if ( !entsize )
>> +{
>> +elf_mark_broken(elf, "e_shentsize is zero");
>> +return 0;
>> +}
> This as well as ...
>
>> @@ -148,11 +154,17 @@ unsigned elf_shdr_count(struct elf_binary *elf)
>> unsigned elf_phdr_count(struct elf_binary *elf)
>> {
>> unsigned count = elf_uval(elf, elf->ehdr, e_phnum);
>> +unsigned entsize = elf_uval(elf, elf->ehdr, e_phentsize);
>> uint64_t max;
>>
>> if ( !count )
>> return 0;
>> -max = elf->size / elf_uval(elf, elf->ehdr, e_phentsize);
>> +if ( !entsize )
>> +{
>> +elf_mark_broken(elf, "e_phentsize is zero");
>> +return 0;
>> +}
> ... this would end up being dead code, due to the checks the same
> patch you refer to introduced in elf_init().
Are you sure? elf_init() currently looks like this:
/* Sanity check phdr if present. */
count = elf_phdr_count(elf);
if ( count )
{
if ( elf_uval(elf, elf->ehdr, e_phentsize) <
elf_size(elf, ELF_HANDLE_DECL(elf_phdr)) )
{
elf_err(elf, "ELF: phdr too small (%" PRIu64 ")\n",
elf_uval(elf, elf->ehdr, e_phentsize));
return -1;
}
There is no check of e_phentsize before it is used to divide with.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libelf: Fix div0 issues in elf_{shdr, phdr}_count()
Jan Beulich writes ("Re: [PATCH] libelf: Fix div0 issues in
elf_{shdr,phdr}_count()"):
> On 08.12.16 at 15:18, wrote:
> > Spotted by Coverity.
>
> And wrongly so, imo.
...
> > @@ -148,11 +154,17 @@ unsigned elf_shdr_count(struct elf_binary *elf)
> > unsigned elf_phdr_count(struct elf_binary *elf)
> > {
> > unsigned count = elf_uval(elf, elf->ehdr, e_phnum);
> > +unsigned entsize = elf_uval(elf, elf->ehdr, e_phentsize);
...
> ... this would end up being dead code, due to the checks the same
> patch you refer to introduced in elf_init().
I think I would prefer code that is obviously correct from local
inspection. There is no performance implication here.
Maybe what we want is elf_divide() which implments anything/0 as 0.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH VERY RFC 2/5] tools/fuzz: introduce libelf target
On Thu, Dec 08, 2016 at 07:47:22AM -0700, Jan Beulich wrote: > >>> On 08.12.16 at 14:54, wrote: > > A simple program and Makefile to fuzz libelf in Google's oss-fuzz > > infrastructure. > > Mind adding some description here on how this is expected to work / > be used? The new Makefile produce an object file and an archive, > but no binary, so it's not clear to me what use this is. > Sure, I can elaborate more on this in the README file. Wei. > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen/scsifront: don't request a slot on the ring until request is ready
On 12/02/2016 01:15 AM, Juergen Gross wrote: Instead of requesting a new slot on the ring to the backend early, do so only after all has been setup for the request to be sent. This makes error handling easier as we don't need to undo the request id allocation and ring slot allocation. Suggested-by: Jan Beulich Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky (although it would be good to have someone familiar with this code look at this as well). ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH VERY RFC 3/5] tools/fuzz: introduce x86 instruction emulator target
>>> On 08.12.16 at 14:54, wrote:
> Instruction emulator fuzzing code is from code previous written by
> Andrew and George. Adapted to llvm fuzzer and hook up the build system.
With this, how much of the new code could be shared between
Google's fuzzer and AFL, for which George had put this together
originally afaik? Or are we now no longer planning on having an
AFL target?
> --- /dev/null
> +++ b/tools/fuzz/x86_instruction_emulator/Makefile
> @@ -0,0 +1,33 @@
> +XEN_ROOT=$(CURDIR)/../../..
> +include $(XEN_ROOT)/tools/Rules.mk
> +
> +x86-instruction-emulator-fuzzer-all: x86-insn-emulator.a
> x86-insn-emulator-fuzzer.o
> +
> +x86_emulate/x86_emulate.c x86_emulate/x86_emulate.h:
> + [ -L x86_emulate ] || ln -sf $(XEN_ROOT)/xen/arch/x86/x86_emulate .
> +
> +x86_emulate.c:
> + [ -L x86_emulate.c ] || ln -sf
> $(XEN_ROOT)/tools/tests/x86_emulator/x86_emulate.c
> +
> +x86_emulate.h:
> + [ -L x86_emulate.h ] || ln -sf
> $(XEN_ROOT)/tools/tests/x86_emulator/x86_emulate.h
I think these two could easily be a single (pattern) rule, with (slightly
unusually) the file extension being the stem.
> --- /dev/null
> +++ b/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c
> @@ -0,0 +1,335 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define __packed __attribute__((packed))
> +#define ASSERT assert
This should not be needed anymore if you included ...
> +#include "x86_emulate/x86_emulate.h"
"x86_emulate.h" instead. And __packed, if its really needed,
should then also be added to that header.
> +/* EFLAGS bit definitions. */
> +#define EFLG_OF (1<<11)
> +#define EFLG_DF (1<<10)
> +#define EFLG_SF (1<<7)
> +#define EFLG_ZF (1<<6)
> +#define EFLG_AF (1<<4)
> +#define EFLG_PF (1<<2)
> +#define EFLG_CF (1<<0)
These appear to be unused.
> +static unsigned char data[4096];
> +static unsigned int data_index = 0;
> +static unsigned int data_max;
> +
> +int data_read(const char *why, void *dst, unsigned int bytes) {
> +
static? And the brace put on the otherwise stray blank line.
> +static int emul_read(
May I suggest to prefix all of these fuzz_ instead of emul_?
> +#define cpu_has_sse2 ({ \
> +unsigned int eax = 1, ecx = 0, edx; \
> +emul_cpuid(&eax, &ecx, &ecx, &edx, NULL); \
> +(edx & (1U << 26)) != 0; \
> +})
This appears to be unused again.
> +#define cpu_has_avx2 ({ \
> +unsigned int eax = 1, ebx, ecx = 0; \
> +emul_cpuid(&eax, &ebx, &ecx, &eax, NULL); \
> +if ( !(ecx & (1U << 27)) || ((xgetbv(0) & 6) != 6) ) \
> +ebx = 0; \
> +else { \
> +eax = 7, ecx = 0; \
> +cpuid(&eax, &ebx, &ecx, &eax, NULL); \
> +} \
> +(ebx & (1U << 5)) != 0; \
> +})
Same here.
> +static int emul_read_cr(
> +unsigned int reg,
> +unsigned long *val,
> +struct x86_emulate_ctxt *ctxt)
> +{
> +/* Fake just enough state for the emulator's _get_fpu() to be happy. */
> +switch ( reg )
> +{
> +case 0:
> +*val = 0x0001; /* PE */
> +return X86EMUL_OKAY;
> +
> +case 4:
> +/* OSFXSR, OSXMMEXCPT, and maybe OSXSAVE */
> +*val = 0x0600 | (cpu_has_xsave ? 0x0004 : 0);
> +return X86EMUL_OKAY;
> +}
> +
> +return X86EMUL_UNHANDLEABLE;
> +}
Looks suspiciously similar to existing code. We may want to share
such stuff, to avoid having to update it in multiple places.
> +int emul_get_fpu(
static?
> +struct x86_emulate_ops emulops = {
again
> +bool make_stack_executable(void) {
> +unsigned long sp;
> +bool stack_exec;
> +
> +/*
> + * Mark the entire stack executable so that the stub executions
> + * don't fault
> + */
> +#define MMAP_SZ 16384
> +
> +#ifdef __x86_64__
> +asm ("movq %%rsp, %0" : "=g" (sp));
> +#else
> +asm ("movl %%esp, %0" : "=g" (sp));
> +#endif
> +
> +stack_exec = mprotect((void *)(sp & -0x1000L) - (MMAP_SZ - 0x1000),
> + MMAP_SZ, PROT_READ|PROT_WRITE|PROT_EXEC) == 0;
> +if ( !stack_exec )
> +printf("Warning: Stack could not be made executable (%d).\n", errno);
> +
> +return stack_exec;
> +}
This too looks like it would want sharing.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] Xen 4.9 Development Update
This email only tracks big items for xen.git tree. Please reply for items you woulk like to see in 4.9 so that people have an idea what is going on and prioritise accordingly. You're welcome to provide description and use cases of the feature you're working on. = Timeline = We now adopt a fixed cut-off date scheme. We will release twice a year. The upcoming 4.9 timeline are as followed: * Last posting date: March 17th, 2017 * Hard code freeze: March 31th, 2017 * RC1: TBD * Release: June 2, 2017 Note that we don't have freeze exception scheme anymore. All patches that wish to go into 4.9 must be posted no later than the last posting date. All patches posted after that date will be automatically queued into next release. RCs will be arranged immediately after freeze. = Projects = == Hypervisor == * Boot Xen on EFI platforms using GRUB2 (multiboot2 protocol) - Daniel Kiper * Per-cpu tasklet - Konrad Rzeszutek Wilk === x86 === * Allow ioreq server interface to support XenGT - Yu Zhang - Paul Durrant * PVHv2 support - Roger Pau Monne * vNVDIMM support - Haozhong Zhang === ARM === * ITS emulation (Dom0 only) - Andre Przywara * Altp2m for ARM - Sergej Proskurin * Support Tegra SoCs - Kyle Temkin == Toolstack == * Libxl PVSCSI support - Olaf Hering * Libxl depriv QEMU - Ian Jackson * Logging solution for Xen system - Wei Liu * Remove blktap2 - Wei Liu == Mini-OS == == GRUB == * Support booting Xen ARM - Fu Wei == Testing == == Completed == ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v15] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.
I'm just wondering if anybody had a chance to look at the patch... ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libelf: Fix div0 issues in elf_{shdr, phdr}_count()
>>> On 08.12.16 at 15:46, wrote:
> On 08/12/16 14:41, Jan Beulich wrote:
> On 08.12.16 at 15:18, wrote:
>>> elf_uval() can return zero either because the field itself is zero, or
> because
>>> the access is out of bounds.
>>>
>>> c/s a01b6d4 "libelf: treat phdr and shdr similarly" introduced two div0
> issues
>>> as e_{ph,sh}entsize are not checked for sanity before being used to divide
>>> elf->size.
>>>
>>> Spotted by Coverity.
>> And wrongly so, imo.
>>
>>> --- a/xen/common/libelf/libelf-tools.c
>>> +++ b/xen/common/libelf/libelf-tools.c
>>> @@ -130,11 +130,17 @@ uint64_t elf_round_up(struct elf_binary *elf,
>>> uint64_t
> addr)
>>> unsigned elf_shdr_count(struct elf_binary *elf)
>>> {
>>> unsigned count = elf_uval(elf, elf->ehdr, e_shnum);
>>> +unsigned entsize = elf_uval(elf, elf->ehdr, e_shentsize);
>>> uint64_t max;
>>>
>>> if ( !count )
>>> return 0;
>>> -max = elf->size / elf_uval(elf, elf->ehdr, e_shentsize);
>>> +if ( !entsize )
>>> +{
>>> +elf_mark_broken(elf, "e_shentsize is zero");
>>> +return 0;
>>> +}
>> This as well as ...
>>
>>> @@ -148,11 +154,17 @@ unsigned elf_shdr_count(struct elf_binary *elf)
>>> unsigned elf_phdr_count(struct elf_binary *elf)
>>> {
>>> unsigned count = elf_uval(elf, elf->ehdr, e_phnum);
>>> +unsigned entsize = elf_uval(elf, elf->ehdr, e_phentsize);
>>> uint64_t max;
>>>
>>> if ( !count )
>>> return 0;
>>> -max = elf->size / elf_uval(elf, elf->ehdr, e_phentsize);
>>> +if ( !entsize )
>>> +{
>>> +elf_mark_broken(elf, "e_phentsize is zero");
>>> +return 0;
>>> +}
>> ... this would end up being dead code, due to the checks the same
>> patch you refer to introduced in elf_init().
>
> Are you sure? elf_init() currently looks like this:
>
> /* Sanity check phdr if present. */
> count = elf_phdr_count(elf);
> if ( count )
> {
> if ( elf_uval(elf, elf->ehdr, e_phentsize) <
> elf_size(elf, ELF_HANDLE_DECL(elf_phdr)) )
> {
> elf_err(elf, "ELF: phdr too small (%" PRIu64 ")\n",
> elf_uval(elf, elf->ehdr, e_phentsize));
> return -1;
> }
>
> There is no check of e_phentsize before it is used to divide with.
Oh, I see - elf_phdr_count() itself relies on the check that's
about to be done. But I think the correct thing then would be to
not use elf_phdr_count() here, but read the raw field instead.
You patch basically adds a weaker check there which is then
immediately being followed by the stronger check above.
And looking at it from that angle it's then questionable why
elf_{p,s}hdr_count() do any checking at all - this should all be
done once in elf_init(). IOW I did the adjustment in the wrong
way, and I really should have made elf_shdr_count() match
elf_phdr_count() (moving the checks into elf_init()).
And looking at elf_init() again I also realize that I blindly
copied the range checks, calculation of which can overflow.
I think it would be better to do those checks such that
overflow results in an error return.
I wonder if it wouldn't be better to revert that change, for
me to produce a better v2.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.9 Development Update
>>> On 08.12.16 at 16:12, wrote: > = Projects = > > == Hypervisor == > > * Boot Xen on EFI platforms using GRUB2 (multiboot2 protocol) > - Daniel Kiper > > * Per-cpu tasklet > - Konrad Rzeszutek Wilk > > === x86 === > > * Allow ioreq server interface to support XenGT > - Yu Zhang > - Paul Durrant > > * PVHv2 support > - Roger Pau Monne > > * vNVDIMM support > - Haozhong Zhang * Completion of the x86 insn emulator (as far as possible; me) * Getting guest CPUID handling into better shape (Andrew) Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libelf: Fix div0 issues in elf_{shdr, phdr}_count()
On 08/12/16 15:17, Jan Beulich wrote:
On 08.12.16 at 15:46, wrote:
>> On 08/12/16 14:41, Jan Beulich wrote:
>> On 08.12.16 at 15:18, wrote:
elf_uval() can return zero either because the field itself is zero, or
>> because
the access is out of bounds.
c/s a01b6d4 "libelf: treat phdr and shdr similarly" introduced two div0
>> issues
as e_{ph,sh}entsize are not checked for sanity before being used to divide
elf->size.
Spotted by Coverity.
>>> And wrongly so, imo.
>>>
--- a/xen/common/libelf/libelf-tools.c
+++ b/xen/common/libelf/libelf-tools.c
@@ -130,11 +130,17 @@ uint64_t elf_round_up(struct elf_binary *elf,
uint64_t
>> addr)
unsigned elf_shdr_count(struct elf_binary *elf)
{
unsigned count = elf_uval(elf, elf->ehdr, e_shnum);
+unsigned entsize = elf_uval(elf, elf->ehdr, e_shentsize);
uint64_t max;
if ( !count )
return 0;
-max = elf->size / elf_uval(elf, elf->ehdr, e_shentsize);
+if ( !entsize )
+{
+elf_mark_broken(elf, "e_shentsize is zero");
+return 0;
+}
>>> This as well as ...
>>>
@@ -148,11 +154,17 @@ unsigned elf_shdr_count(struct elf_binary *elf)
unsigned elf_phdr_count(struct elf_binary *elf)
{
unsigned count = elf_uval(elf, elf->ehdr, e_phnum);
+unsigned entsize = elf_uval(elf, elf->ehdr, e_phentsize);
uint64_t max;
if ( !count )
return 0;
-max = elf->size / elf_uval(elf, elf->ehdr, e_phentsize);
+if ( !entsize )
+{
+elf_mark_broken(elf, "e_phentsize is zero");
+return 0;
+}
>>> ... this would end up being dead code, due to the checks the same
>>> patch you refer to introduced in elf_init().
>> Are you sure? elf_init() currently looks like this:
>>
>> /* Sanity check phdr if present. */
>> count = elf_phdr_count(elf);
>> if ( count )
>> {
>> if ( elf_uval(elf, elf->ehdr, e_phentsize) <
>> elf_size(elf, ELF_HANDLE_DECL(elf_phdr)) )
>> {
>> elf_err(elf, "ELF: phdr too small (%" PRIu64 ")\n",
>> elf_uval(elf, elf->ehdr, e_phentsize));
>> return -1;
>> }
>>
>> There is no check of e_phentsize before it is used to divide with.
> Oh, I see - elf_phdr_count() itself relies on the check that's
> about to be done. But I think the correct thing then would be to
> not use elf_phdr_count() here, but read the raw field instead.
> You patch basically adds a weaker check there which is then
> immediately being followed by the stronger check above.
>
> And looking at it from that angle it's then questionable why
> elf_{p,s}hdr_count() do any checking at all - this should all be
> done once in elf_init(). IOW I did the adjustment in the wrong
> way, and I really should have made elf_shdr_count() match
> elf_phdr_count() (moving the checks into elf_init()).
>
> And looking at elf_init() again I also realize that I blindly
> copied the range checks, calculation of which can overflow.
> I think it would be better to do those checks such that
> overflow results in an error return.
>
> I wonder if it wouldn't be better to revert that change, for
> me to produce a better v2.
Feel free.
I have to admit that I find it odd that the values aren't sanitised
once, then copied out into local good state. The repeated use of
elf_uval() risks a lot of zeroes because of its range check case.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH VERY RFC 3/5] tools/fuzz: introduce x86 instruction emulator target
On Thu, Dec 08, 2016 at 08:03:04AM -0700, Jan Beulich wrote: > >>> On 08.12.16 at 14:54, wrote: > > Instruction emulator fuzzing code is from code previous written by > > Andrew and George. Adapted to llvm fuzzer and hook up the build system. > > With this, how much of the new code could be shared between > Google's fuzzer and AFL, for which George had put this together > originally afaik? Or are we now no longer planning on having an > AFL target? We could share the majority of the code. I started by stripping unused code in their patch (and as you already saw, not quite complete yet). When Google oss-fuzz supports AFL, we can easily add that support in. Ultimately it is only the entry function is a bit different. All the stub functions should work the same. Regarding all comments below, I will fix them all together in the next round. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 06/14] OvmfPkg/XenPlatformPei: Add xen PVH specific code
- learn about memory size from the E820
- ignore error if host bridge devid is 0x, PVH does not have PCI and
reading from unexisting device return -1.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenPlatformPei/MemDetect.c | 71 ++
OvmfPkg/XenPlatformPei/Platform.c | 5 +++
OvmfPkg/XenPlatformPei/Platform.h | 10 ++
3 files changed, 86 insertions(+)
diff --git a/OvmfPkg/XenPlatformPei/MemDetect.c
b/OvmfPkg/XenPlatformPei/MemDetect.c
index 4ecdf5e..0d80775 100644
--- a/OvmfPkg/XenPlatformPei/MemDetect.c
+++ b/OvmfPkg/XenPlatformPei/MemDetect.c
@@ -42,6 +42,70 @@ UINT8 mPhysMemAddressWidth;
STATIC UINT32 mS3AcpiReservedMemoryBase;
STATIC UINT32 mS3AcpiReservedMemorySize;
+STATIC UINT32 mXenLowerMemorySize = 0;
+STATIC UINT64 mXenHighMemorySize = 0;
+
+VOID
+XenReadMemorySizes (
+ VOID
+ )
+{
+ EFI_E820_ENTRY64 *E820Map;
+ UINT32E820EntriesCount;
+ EFI_STATUS Status;
+
+ Status = XenGetE820Map (&E820Map, &E820EntriesCount);
+ ASSERT_EFI_ERROR (Status);
+
+ mXenLowerMemorySize = 0;
+ mXenHighMemorySize = 0;
+
+ if (E820EntriesCount > 0) {
+EFI_E820_ENTRY64 *Entry;
+UINT32 Loop;
+
+for (Loop = 0; Loop < E820EntriesCount; Loop++) {
+ Entry = E820Map + Loop;
+
+ //
+ // Only care about RAM
+ //
+ if (Entry->Type != EfiAcpiAddressRangeMemory) {
+continue;
+ }
+
+ if ((Entry->BaseAddr + Entry->Length) <= SIZE_16MB) {
+continue;
+ }
+
+ if (Entry->BaseAddr < SIZE_16MB) {
+UINT64 bottom = Entry->BaseAddr;
+UINT64 size = Entry->Length;
+size -= SIZE_16MB - bottom;
+bottom = SIZE_16MB;
+mXenLowerMemorySize += size;
+continue;
+ }
+ if (Entry->BaseAddr <= SIZE_4GB) {
+UINT64 size = Entry->Length;
+mXenLowerMemorySize += size;
+continue;
+ }
+
+ if (Entry->BaseAddr == SIZE_4GB) {
+mXenHighMemorySize = Entry->Length;
+continue;
+ }
+
+ DEBUG ((EFI_D_INFO, "%a: ignored XenE820 entry (0x%llx, 0x%llx)\n",
+ __FUNCTION__,
+ Entry->BaseAddr,
+ Entry->Length));
+}
+mXenLowerMemorySize += SIZE_16MB;
+ }
+}
+
UINT32
GetSystemMemorySizeBelow4gb (
VOID
@@ -50,6 +114,9 @@ GetSystemMemorySizeBelow4gb (
UINT8 Cmos0x34;
UINT8 Cmos0x35;
+ if (mXen && mXenLowerMemorySize)
+return mXenLowerMemorySize;
+
//
// CMOS 0x34/0x35 specifies the system memory above 16 MB.
// * CMOS(0x35) is the high byte
@@ -74,6 +141,10 @@ GetSystemMemorySizeAbove4gb (
UINT32 Size;
UINTN CmosIndex;
+ // if lower memory is specified that way, return also high memory
+ if (mXen && mXenLowerMemorySize)
+return mXenHighMemorySize;
+
//
// CMOS 0x5b-0x5d specifies the system memory above 4GB MB.
// * CMOS(0x5d) is the most significant size byte
diff --git a/OvmfPkg/XenPlatformPei/Platform.c
b/OvmfPkg/XenPlatformPei/Platform.c
index bf78878..9fc713c 100644
--- a/OvmfPkg/XenPlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -362,6 +362,10 @@ MiscInitialization (
AcpiCtlReg = POWER_MGMT_REGISTER_Q35 (ICH9_ACPI_CNTL);
AcpiEnBit = ICH9_ACPI_CNTL_ACPI_EN;
break;
+case 0x:
+ // xen PVH, ignore
+ PcdStatus = PcdSet16S (PcdOvmfHostBridgePciDevId, mHostBridgeDevId);
+ return;
default:
DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
__FUNCTION__, mHostBridgeDevId));
@@ -503,6 +507,7 @@ InitializeXenPlatform (
DebugDumpCmos ();
XenDetect ();
+ XenReadMemorySizes ();
BootModeInitialization ();
AddressWidthInitialization ();
diff --git a/OvmfPkg/XenPlatformPei/Platform.h
b/OvmfPkg/XenPlatformPei/Platform.h
index eda765b..2948853 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -101,4 +101,14 @@ extern BOOLEAN mS3Supported;
extern UINT8 mPhysMemAddressWidth;
+EFI_STATUS
+XenGetE820Map (
+ EFI_E820_ENTRY64 **Entries,
+ UINT32 *Count
+ );
+VOID
+XenReadMemorySizes (
+ VOID
+ );
+
#endif // _PLATFORM_PEI_H_INCLUDED_
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 08/14] OvmfPkg/PlatformBootManagerLib: Workaround missing PCI bus on Xen PVH
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD --- OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c index cc35630..bd64cc3 100644 --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c @@ -1152,6 +1152,8 @@ PciAcpiInitialization ( PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6a), 0x0b); // G PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H break; +case 0x: + return; default: DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n", __FUNCTION__, mHostBridgeDevId)); -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 03/14] OvmfPkg/XenOvmf.dsc: Introduce XenResetVector
Copy of OvmfPkg/ResetVector, with one changes: - default_cr0: enable cache Xen copy the OVMF code to RAM, there is no need for cache. Also, it makes OVMF slow to start on AMD. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD --- OvmfPkg/XenOvmf.dsc| 2 +- OvmfPkg/XenOvmf.fdf| 2 +- OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm | 133 + OvmfPkg/XenResetVector/Ia32/PageTables64.asm | 93 + OvmfPkg/XenResetVector/XenResetVector.inf | 37 +++ OvmfPkg/XenResetVector/XenResetVector.nasmb| 66 6 files changed, 331 insertions(+), 2 deletions(-) create mode 100644 OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm create mode 100644 OvmfPkg/XenResetVector/Ia32/PageTables64.asm create mode 100644 OvmfPkg/XenResetVector/XenResetVector.inf create mode 100644 OvmfPkg/XenResetVector/XenResetVector.nasmb diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc index 5b3550d..0a7ea21 100644 --- a/OvmfPkg/XenOvmf.dsc +++ b/OvmfPkg/XenOvmf.dsc @@ -471,7 +471,7 @@ # [Components] - OvmfPkg/ResetVector/ResetVector.inf + OvmfPkg/XenResetVector/XenResetVector.inf # # SEC Phase modules diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf index d01454e..f4609b0 100644 --- a/OvmfPkg/XenOvmf.fdf +++ b/OvmfPkg/XenOvmf.fdf @@ -123,7 +123,7 @@ READ_LOCK_STATUS = TRUE # INF OvmfPkg/Sec/SecMain.inf -INF RuleOverride=RESET_VECTOR OvmfPkg/ResetVector/ResetVector.inf +INF RuleOverride=RESET_VECTOR OvmfPkg/XenResetVector/XenResetVector.inf [FV.PEIFV] diff --git a/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm new file mode 100644 index 000..d746427 --- /dev/null +++ b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm @@ -0,0 +1,133 @@ +;-- +; @file +; Transition from 16 bit real mode into 32 bit flat protected mode +; +; Copyright (c) 2008 - 2010, Intel Corporation. All rights reserved. +; This program and the accompanying materials +; are licensed and made available under the terms and conditions of the BSD License +; which accompanies this distribution. The full text of the license may be found at +; http://opensource.org/licenses/bsd-license.php +; +; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, +; WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. +; +;-- + +%define SEC_DEFAULT_CR0 0x0023 +%define SEC_DEFAULT_CR4 0x640 + +BITS16 + +; +; Modified: EAX, EBX +; +TransitionFromReal16To32BitFlat: + +debugShowPostCode POSTCODE_16BIT_MODE + +cli + +mov bx, 0xf000 +mov ds, bx + +mov bx, ADDR16_OF(gdtr) + +o32 lgdt[cs:bx] + +mov eax, SEC_DEFAULT_CR0 +mov cr0, eax + +jmp LINEAR_CODE_SEL:dword ADDR_OF(jumpTo32BitAndLandHere) +BITS32 +jumpTo32BitAndLandHere: + +mov eax, SEC_DEFAULT_CR4 +mov cr4, eax + +debugShowPostCode POSTCODE_32BIT_MODE + +mov ax, LINEAR_SEL +mov ds, ax +mov es, ax +mov fs, ax +mov gs, ax +mov ss, ax + +OneTimeCallRet TransitionFromReal16To32BitFlat + +ALIGN 2 + +gdtr: +dw GDT_END - GDT_BASE - 1 ; GDT limit +dd ADDR_OF(GDT_BASE) + +ALIGN 16 + +; +; Macros for GDT entries +; + +%define PRESENT_FLAG(p) (p << 7) +%define DPL(dpl) (dpl << 5) +%define SYSTEM_FLAG(s) (s << 4) +%define DESC_TYPE(t) (t) + +; Type: data, expand-up, writable, accessed +%define DATA32_TYPE 3 + +; Type: execute, readable, expand-up, accessed +%define CODE32_TYPE 0xb + +; Type: execute, readable, expand-up, accessed +%define CODE64_TYPE 0xb + +%define GRANULARITY_FLAG(g) (g << 7) +%define DEFAULT_SIZE32(d) (d << 6) +%define CODE64_FLAG(l) (l << 5) +%define UPPER_LIMIT(l) (l) + +; +; The Global Descriptor Table (GDT) +; + +GDT_BASE: +; null descriptor +NULL_SELequ $-GDT_BASE +DW 0; limit 15:0 +DW 0; base 15:0 +DB 0; base 23:16 +DB 0; sys flag, dpl, type +DB 0; limit 19:16, flags +DB 0; base 31:24 + +; linear data segment descriptor +LINEAR_SEL equ $-GDT_BASE +DW 0x ; limit 15:0 +DW 0; base 15:0 +DB 0; base 23:16 +DB PRESENT_FLAG(1)|DPL(0)|SYSTEM_FLAG(1)|DESC_TYPE(DATA32_TYPE) +DB GRANULARITY_FLAG(1)|DEFAULT_SIZE32(1)|CODE64_FLAG(0)|UPPER_LIMIT(0xf) +DB 0; base 31:24 + +; linear code segment descriptor +LINEAR_CODE_SEL equ
[Xen-devel] [PATCH RFC 07/14] OvmfPkg/XenResetVector: Add new entry point for Xen PVH
This one enter directly in 32bits Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD --- OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm | 79 + OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 23 +++ OvmfPkg/XenResetVector/XenResetVector.nasmb | 1 + 3 files changed, 103 insertions(+) create mode 100644 OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm create mode 100644 OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm diff --git a/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm new file mode 100644 index 000..70436d8 --- /dev/null +++ b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm @@ -0,0 +1,79 @@ +;-- +; @file +; First code executed by processor after resetting. +; +; Copyright (c) 2008 - 2014, Intel Corporation. All rights reserved. +; This program and the accompanying materials +; are licensed and made available under the terms and conditions of the BSD License +; which accompanies this distribution. The full text of the license may be found at +; http://opensource.org/licenses/bsd-license.php +; +; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, +; WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. +; +;-- + +BITS16 + +ALIGN 16 + +; +; Pad the image size to 4k when page tables are in VTF0 +; +; If the VTF0 image has page tables built in, then we need to make +; sure the end of VTF0 is 4k above where the page tables end. +; +; This is required so the page tables will be 4k aligned when VTF0 is +; located just below 0x1 (4GB) in the firmware device. +; +%ifdef ALIGN_TOP_TO_4K_FOR_PAGING +TIMES (0x1000 - ($ - EndOfPageTables) - (fourGigabytes - xenPVHEntryPoint)) DB 0 +%endif + +BITS32 +xenPVHEntryPoint: +; this is probably 0xffd0 + jmp xenPVHMain + +BITS16 +ALIGN 16 + +applicationProcessorEntryPoint: +; +; Application Processors entry point +; +; GenFv generates code aligned on a 4k boundary which will jump to this +; location. (0xffe0) This allows the Local APIC Startup IPI to be +; used to wake up the application processors. +; +jmp EarlyApInitReal16 + +ALIGN 8 + +DD 0 + +; +; The VTF signature +; +; VTF-0 means that the VTF (Volume Top File) code does not require +; any fixups. +; +vtfSignature: +DB 'V', 'T', 'F', 0 + +ALIGN 16 + +resetVector: +; +; Reset Vector +; +; This is where the processor will begin execution +; +nop +nop +jmp EarlyBspInitReal16 + +ALIGN 16 + +fourGigabytes: + diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm new file mode 100644 index 000..eb12f6c --- /dev/null +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm @@ -0,0 +1,23 @@ +BITS 32 + +xenPVHMain: + mov di, 'BP' + + cli + mov ebx, ADDR_OF(gdtr) + lgdt [ebx] + mov eax, SEC_DEFAULT_CR0 + mov cr0, eax + jmp LINEAR_CODE_SEL:ADDR_OF(jmpHerePVH) +jmpHerePVH: + mov eax, SEC_DEFAULT_CR4 + mov cr4, eax + + mov ax, LINEAR_SEL + mov ds, ax + mov es, ax + mov fs, ax + mov gs, ax + mov ss, ax + + OneTimeCallRet TransitionFromReal16To32BitFlat diff --git a/OvmfPkg/XenResetVector/XenResetVector.nasmb b/OvmfPkg/XenResetVector/XenResetVector.nasmb index 31ac06a..f9812fd 100644 --- a/OvmfPkg/XenResetVector/XenResetVector.nasmb +++ b/OvmfPkg/XenResetVector/XenResetVector.nasmb @@ -61,6 +61,7 @@ %include "Ia16/Init16.asm" %include "Main.asm" +%include "Ia32/XenPVHMain.asm" %include "Ia16/ResetVectorVtf0.asm" -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 02/14] OvmfPkg/XenOvmf: Update debug IO port for Xen
This is a debug IO port that will output directly to the Xen Hypervisor
console.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenOvmf.dsc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index e452eb3..5b3550d 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -421,6 +421,9 @@
# Point to the MdeModulePkg/Application/UiApp/UiApp.inf
gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c,
0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
+ ## This flag is used to control the destination port for
PlatformDebugLibIoPort
+ gUefiOvmfPkgTokenSpaceGuid.PcdDebugIoPort|0xe9
+
#
# Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 09/14] OvmfPkg/ResetSystemLib: Add missing dependency on PciLib
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD --- OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf | 1 + 1 file changed, 1 insertion(+) diff --git a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf index ecd462b..2e0ed48 100644 --- a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf +++ b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf @@ -36,4 +36,5 @@ [LibraryClasses] DebugLib IoLib + PciLib TimerLib -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 01/14] OvmfPkg: Create platform XenOvmf
This is a copy of OvmfX64, removing VirtIO and some SMM. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD --- OvmfPkg/XenOvmf.dsc | 793 OvmfPkg/XenOvmf.fdf | 504 + 2 files changed, 1297 insertions(+) create mode 100644 OvmfPkg/XenOvmf.dsc create mode 100644 OvmfPkg/XenOvmf.fdf diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc new file mode 100644 index 000..e452eb3 --- /dev/null +++ b/OvmfPkg/XenOvmf.dsc @@ -0,0 +1,793 @@ +## @file +# EFI/Framework Open Virtual Machine Firmware (OVMF) platform +# +# Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved. +# (C) Copyright 2016 Hewlett Packard Enterprise Development LP +# +# This program and the accompanying materials +# are licensed and made available under the terms and conditions of the BSD License +# which accompanies this distribution. The full text of the license may be found at +# http://opensource.org/licenses/bsd-license.php +# +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, +# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. +# +## + + +# +# Defines Section - statements that will be processed to create a Makefile. +# + +[Defines] + PLATFORM_NAME = Ovmf + PLATFORM_GUID = e3aa4fbe-9459-482d-bd40-d3f3b5f89d6e + PLATFORM_VERSION = 0.1 + DSC_SPECIFICATION = 0x00010005 + OUTPUT_DIRECTORY = Build/XenOvmf + SUPPORTED_ARCHITECTURES= X64 + BUILD_TARGETS = NOOPT|DEBUG|RELEASE + SKUID_IDENTIFIER = DEFAULT + FLASH_DEFINITION = OvmfPkg/XenOvmf.fdf + + # + # Defines for default states. These can be changed on the command line. + # -D FLAG=VALUE + # + DEFINE SECURE_BOOT_ENABLE = FALSE + DEFINE NETWORK_IP6_ENABLE = FALSE + DEFINE HTTP_BOOT_ENABLE= FALSE + DEFINE SMM_REQUIRE = FALSE + +[BuildOptions] + GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG + GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG + INTEL:RELEASE_*_*_CC_FLAGS = /D MDEPKG_NDEBUG + MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG + GCC:*_*_*_CC_FLAGS = -mno-mmx -mno-sse +!ifdef $(SOURCE_DEBUG_ENABLE) + MSFT:*_*_X64_GENFW_FLAGS = --keepexceptiontable + GCC:*_*_X64_GENFW_FLAGS = --keepexceptiontable + INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable +!endif + + # + # Disable deprecated APIs. + # + MSFT:*_*_*_CC_FLAGS = /D DISABLE_NEW_DEPRECATED_INTERFACES + INTEL:*_*_*_CC_FLAGS = /D DISABLE_NEW_DEPRECATED_INTERFACES + GCC:*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES + +[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER] + GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000 + +# Force PE/COFF sections to be aligned at 4KB boundaries to support page level +# protection of DXE_SMM_DRIVER/SMM_CORE modules +[BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE] + GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000 + + +# +# SKU Identification section - list of all SKU IDs supported by this Platform. +# + +[SkuIds] + 0|DEFAULT + + +# +# Library Class section - list of all Library Classes needed by this Platform. +# + +[LibraryClasses] + PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf + TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf + PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf + BaseMemoryLib|MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf + BaseLib|MdePkg/Library/BaseLib/BaseLib.inf + SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf + CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf + PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNull.inf + PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf + CacheMaintenanceLib|MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf + UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.inf + UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf + HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf + SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf + UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf + BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf + FileExplorerLib|MdeModulePkg/Lib
[Xen-devel] [PATCH RFC 04/14] OvmfPkg: Introduce XenPlatformPei
A copy of OvmfPkg/PlatformPei without some of QEMU specific
initialization, Xen does not support QemuFwCfg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenOvmf.dsc | 2 +-
OvmfPkg/XenOvmf.fdf | 2 +-
OvmfPkg/XenPlatformPei/Cmos.c | 64
OvmfPkg/XenPlatformPei/Cmos.h | 56
OvmfPkg/XenPlatformPei/Fv.c | 100 ++
OvmfPkg/XenPlatformPei/MemDetect.c| 449 +
OvmfPkg/XenPlatformPei/Platform.c | 536 ++
OvmfPkg/XenPlatformPei/Platform.h | 104 ++
OvmfPkg/XenPlatformPei/Xen.c | 231 +
OvmfPkg/XenPlatformPei/Xen.h | 45 +++
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 110 ++
11 files changed, 1697 insertions(+), 2 deletions(-)
create mode 100644 OvmfPkg/XenPlatformPei/Cmos.c
create mode 100644 OvmfPkg/XenPlatformPei/Cmos.h
create mode 100644 OvmfPkg/XenPlatformPei/Fv.c
create mode 100644 OvmfPkg/XenPlatformPei/MemDetect.c
create mode 100644 OvmfPkg/XenPlatformPei/Platform.c
create mode 100644 OvmfPkg/XenPlatformPei/Platform.h
create mode 100644 OvmfPkg/XenPlatformPei/Xen.c
create mode 100644 OvmfPkg/XenPlatformPei/Xen.h
create mode 100644 OvmfPkg/XenPlatformPei/XenPlatformPei.inf
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index 0a7ea21..ef32c33 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -496,7 +496,7 @@
PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
}
- OvmfPkg/PlatformPei/PlatformPei.inf {
+ OvmfPkg/XenPlatformPei/XenPlatformPei.inf {
PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
}
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index f4609b0..c211f61 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -157,7 +157,7 @@ INF MdeModulePkg/Core/Pei/PeiMain.inf
INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
INF
MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf
INF MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
-INF OvmfPkg/PlatformPei/PlatformPei.inf
+INF OvmfPkg/XenPlatformPei/XenPlatformPei.inf
INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
INF UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
!if $(SMM_REQUIRE) == TRUE
diff --git a/OvmfPkg/XenPlatformPei/Cmos.c b/OvmfPkg/XenPlatformPei/Cmos.c
new file mode 100644
index 000..48ed2cb
--- /dev/null
+++ b/OvmfPkg/XenPlatformPei/Cmos.c
@@ -0,0 +1,64 @@
+/** @file
+ PC/AT CMOS access routines
+
+ Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD
License
+ which accompanies this distribution. The full text of the license may be
found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+
+#include "Cmos.h"
+#include "Library/IoLib.h"
+
+/**
+ Reads 8-bits of CMOS data.
+
+ Reads the 8-bits of CMOS data at the location specified by Index.
+ The 8-bit read value is returned.
+
+ @param Index The CMOS location to read.
+
+ @return The value read.
+
+**/
+UINT8
+EFIAPI
+CmosRead8 (
+ IN UINTN Index
+ )
+{
+ IoWrite8 (0x70, (UINT8) Index);
+ return IoRead8 (0x71);
+}
+
+
+/**
+ Writes 8-bits of CMOS data.
+
+ Writes 8-bits of CMOS data to the location specified by Index
+ with the value specified by Value and returns Value.
+
+ @param Index The CMOS location to write.
+ @param Value The value to write to CMOS.
+
+ @return The value written to CMOS.
+
+**/
+UINT8
+EFIAPI
+CmosWrite8 (
+ IN UINTN Index,
+ IN UINT8 Value
+ )
+{
+ IoWrite8 (0x70, (UINT8) Index);
+ IoWrite8 (0x71, Value);
+ return Value;
+}
+
diff --git a/OvmfPkg/XenPlatformPei/Cmos.h b/OvmfPkg/XenPlatformPei/Cmos.h
new file mode 100644
index 000..949f884
--- /dev/null
+++ b/OvmfPkg/XenPlatformPei/Cmos.h
@@ -0,0 +1,56 @@
+/** @file
+ PC/AT CMOS access routines
+
+ Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD
License
+ which accompanies this distribution. The full text of the license may be
found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __CMOS_H__
+#define __CMOS_H__
+
+/**
+ Reads 8-bits of CMOS data.
+
+ Reads the 8-bits of CMOS data at the location specified by Index.
+ The 8-bit read value is returned.
+
+ @param Index The CMOS location
[Xen-devel] [PATCH RFC 05/14] OvmfPkg/Library: add XenPciHostBridgeLib
A copy of OvmfPkg/Library/PciHostBridgeLib Removing support for pci bus enumeration, I think, and only use scan of already enumerated pci bus. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD --- .../Library/XenPciHostBridgeLib/XenPciHostBridge.h | 75 .../XenPciHostBridgeLib/XenPciHostBridgeLib.c | 291 + .../XenPciHostBridgeLib/XenPciHostBridgeLib.inf| 58 +++ OvmfPkg/Library/XenPciHostBridgeLib/XenSupport.c | 456 + 4 files changed, 880 insertions(+) create mode 100644 OvmfPkg/Library/XenPciHostBridgeLib/XenPciHostBridge.h create mode 100644 OvmfPkg/Library/XenPciHostBridgeLib/XenPciHostBridgeLib.c create mode 100644 OvmfPkg/Library/XenPciHostBridgeLib/XenPciHostBridgeLib.inf create mode 100644 OvmfPkg/Library/XenPciHostBridgeLib/XenSupport.c diff --git a/OvmfPkg/Library/XenPciHostBridgeLib/XenPciHostBridge.h b/OvmfPkg/Library/XenPciHostBridgeLib/XenPciHostBridge.h new file mode 100644 index 000..c23d40c --- /dev/null +++ b/OvmfPkg/Library/XenPciHostBridgeLib/XenPciHostBridge.h @@ -0,0 +1,75 @@ +/** @file + Header file of OVMF instance of PciHostBridgeLib. + + Copyright (c) 2016, Intel Corporation. All rights reserved. + + This program and the accompanying materials are licensed and made available + under the terms and conditions of the BSD License which accompanies this + distribution. The full text of the license may be found at + http://opensource.org/licenses/bsd-license.php. + + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT + WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. + +**/ + +PCI_ROOT_BRIDGE * +ScanForRootBridges ( + UINTN *NumberOfRootBridges +); + +/** + Initialize a PCI_ROOT_BRIDGE structure. + + @param[in] Supports Supported attributes. + + @param[in] Attributes Initial attributes. + + @param[in] AllocAttributes Allocation attributes. + + @param[in] RootBusNumberThe bus number to store in RootBus. + + @param[in] MaxSubBusNumber The inclusive maximum bus number that can be + assigned to any subordinate bus found behind any + PCI bridge hanging off this root bus. + + The caller is repsonsible for ensuring that + RootBusNumber <= MaxSubBusNumber. If + RootBusNumber equals MaxSubBusNumber, then the + root bus has no room for subordinate buses. + + @param[in] Io IO aperture. + + @param[in] Mem MMIO aperture. + + @param[in] MemAbove4G MMIO aperture above 4G. + + @param[in] PMem Prefetchable MMIO aperture. + + @param[in] PMemAbove4G Prefetchable MMIO aperture above 4G. + + @param[out] RootBus The PCI_ROOT_BRIDGE structure (allocated by the + caller) that should be filled in by this + function. + + @retval EFI_SUCCESS Initialization successful. A device path +consisting of an ACPI device path node, with +UID = RootBusNumber, has been allocated and +linked into RootBus. + + @retval EFI_OUT_OF_RESOURCES Memory allocation failed. +**/ +EFI_STATUS +InitRootBridge ( + IN UINT64 Supports, + IN UINT64 Attributes, + IN UINT64 AllocAttributes, + IN UINT8RootBusNumber, + IN UINT8MaxSubBusNumber, + IN PCI_ROOT_BRIDGE_APERTURE *Io, + IN PCI_ROOT_BRIDGE_APERTURE *Mem, + IN PCI_ROOT_BRIDGE_APERTURE *MemAbove4G, + IN PCI_ROOT_BRIDGE_APERTURE *PMem, + IN PCI_ROOT_BRIDGE_APERTURE *PMemAbove4G, + OUT PCI_ROOT_BRIDGE *RootBus + ); diff --git a/OvmfPkg/Library/XenPciHostBridgeLib/XenPciHostBridgeLib.c b/OvmfPkg/Library/XenPciHostBridgeLib/XenPciHostBridgeLib.c new file mode 100644 index 000..efcd830 --- /dev/null +++ b/OvmfPkg/Library/XenPciHostBridgeLib/XenPciHostBridgeLib.c @@ -0,0 +1,291 @@ +/** @file + OVMF's instance of the PCI Host Bridge Library. + + Copyright (C) 2016, Red Hat, Inc. + Copyright (c) 2016, Intel Corporation. All rights reserved. + + This program and the accompanying materials are licensed and made available + under the terms and conditions of the BSD License which accompanies this + distribution. The full text of the license may be found at + http://opensource.org/licenses/bsd-license.php. + + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT + WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. + +**/ +#include + +#include +#include + +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include "XenPciHostBridge.h" + + +#pragma pack(1) +typedef stru
[Xen-devel] [PATCH RFC 00/14] Specific platform to run OVMF in Xen PVH and HVM guests
Hi, I've started to create a Xen specifig plaform, in OvmfPkg/XenOvmf.dsc with the goal to make it work on both Xen HVM and Xen PVHv2 The first few patches only create the platform and duplicate some code from OvmfPkg and the later patches (from OvmfPkg/XenPlatformPei: Add xen PVH specific code) makes OVMF boot in a Xen PVH guest, and can boot a Linux. == Part 1: XenOvmf.dsc - OvmfPkg: Create platform XenOvmf which for now remove virtio drivers and some SMM - OvmfPkg/XenOvmf: Update debug IO port for Xen - OvmfPkg/XenOvmf.dsc: Introduce XenResetVector Just for one change, enable cache in CR0 as on Xen, OVMF run from RAM, that disabling cache can make OVMF very slow. - OvmfPkg: Introduce XenPlatformPei remove some QEMU/KVM specific code from PlatformPei. - OvmfPkg/Library: add XenPciHostBridgeLib same with PciHostBridgeLib == Part 2: PVH enabled - OvmfPkg/XenPlatformPei: Add xen PVH specific code To figure out the memory size from E820 - OvmfPkg/XenResetVector: Add new entry point for Xen PVH which is in 32bits - OvmfPkg/PlatformBootManagerLib: Workaround missing PCI bus on Xen PVH to avoid the Unknown Host Bridge Device ID error - OvmfPkg/ResetSystemLib: Add missing dependency on PciLib - UefiCpuPkg/BaseXApicX2ApicLib: Fix initialisation on my system and ... - OvmfPkg/XenOvmf: Adding XenTimerLocalApic to replace the ACPI timer - OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn - OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables - XenOvmf: Use a different RTC which does always return the same value == to build and boot To build, simply run OvmfPkg/build.sh -p OvmfPkg/XenOvmf.dsc To run, I currently use a loader, base on hvmloader which does some setup, read the e820 and copy ovmf to the right place to start it. The loader is avaible in branch `ovmf-pvhloader' from https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git And the guest I'm using: builder = 'hvm' memory = 512 name = "pvh-ovmf" kernel = 'pvh-ovmf-loader' ramdisk='OVMF.fd' extra='ovmf=1' disk = [ 'file:iso/archlinux-2016.10.01-dual.iso,hdc:cdrom,r', ] device_model_version = 'none' serial = 'pty' Anthony PERARD (14): OvmfPkg: Create platform XenOvmf OvmfPkg/XenOvmf: Update debug IO port for Xen OvmfPkg/XenOvmf.dsc: Introduce XenResetVector OvmfPkg: Introduce XenPlatformPei OvmfPkg/Library: add XenPciHostBridgeLib OvmfPkg/XenPlatformPei: Add xen PVH specific code OvmfPkg/XenResetVector: Add new entry point for Xen PVH OvmfPkg/PlatformBootManagerLib: Workaround missing PCI bus on Xen PVH OvmfPkg/ResetSystemLib: Add missing dependency on PciLib UefiCpuPkg/BaseXApicX2ApicLib: Fix initialisation on my system and ... OvmfPkg/XenOvmf: Adding XenTimerLocalApic OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables XenOvmf: Use a different RTC .../Library/PlatformBootManagerLib/BdsPlatform.c | 35 + .../PlatformBootManagerLib.inf | 2 + OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf | 1 + .../Library/XenPciHostBridgeLib/XenPciHostBridge.h | 75 ++ .../XenPciHostBridgeLib/XenPciHostBridgeLib.c | 291 .../XenPciHostBridgeLib/XenPciHostBridgeLib.inf| 58 ++ OvmfPkg/Library/XenPciHostBridgeLib/XenSupport.c | 456 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c | 263 +++ OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf| 45 ++ OvmfPkg/XenOvmf.dsc| 809 + OvmfPkg/XenOvmf.fdf| 506 + OvmfPkg/XenPlatformPei/Cmos.c | 64 ++ OvmfPkg/XenPlatformPei/Cmos.h | 56 ++ OvmfPkg/XenPlatformPei/Fv.c| 100 +++ OvmfPkg/XenPlatformPei/MemDetect.c | 520 + OvmfPkg/XenPlatformPei/Platform.c | 541 ++ OvmfPkg/XenPlatformPei/Platform.h | 114 +++ OvmfPkg/XenPlatformPei/Xen.c | 231 ++ OvmfPkg/XenPlatformPei/Xen.h | 45 ++ OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 110 +++ OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm | 133 OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm| 79 ++ OvmfPkg/XenResetVector/Ia32/PageTables64.asm | 93 +++ OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 23 + OvmfPkg/XenResetVector/XenResetVector.inf | 37 + OvmfPkg/XenResetVector/XenResetVector.nasmb| 67 ++ OvmfPkg/XenTimerLocalApic/Timer.h | 191 + OvmfPkg/XenTimerLocalApic/XenTimerLocalApic.c | 386 ++ OvmfPkg/XenTimerLocalApic/XenTimerLocalApic.inf| 51 ++ UefiCpuPkg/Include/Library/LocalApicLib.h | 40 + .../BaseXApicX2ApicLib/BaseXApicX2ApicLib.c| 10 +- 31 files changed, 5427 insertions(+), 5 deletions(-) create mode 100644 OvmfPkg/Library/XenPciHostBridgeLib/XenPciHostBr
[Xen-devel] [PATCH RFC 12/14] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn
and add OvmfPkg/XenConsoleIo/XenConsoleIo to XenOvmf platform.
It actually look for gEfiSerialIoProtocolGuid.
---
.../Library/PlatformBootManagerLib/BdsPlatform.c | 33 ++
.../PlatformBootManagerLib.inf | 2 ++
OvmfPkg/XenOvmf.dsc| 4 +++
OvmfPkg/XenOvmf.fdf| 1 +
4 files changed, 40 insertions(+)
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index bd64cc3..b8972f7 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -904,6 +904,31 @@ DetectAndPreparePlatformPciDevicePaths (
return VisitAllPciInstances (DetectAndPreparePlatformPciDevicePath);
}
+#include
+EFI_STATUS
+EFIAPI
+add_serial (
+ IN EFI_HANDLE DeviceHandle,
+ IN VOID*Instance,
+ IN VOID*Context
+ )
+{
+ EFI_DEVICE_PATH_PROTOCOL *DevicePath = NULL;
+
+ DevicePath = DevicePathFromHandle(DeviceHandle);
+ if (DevicePath == NULL) {
+return EFI_NOT_FOUND;
+ }
+
+ DevicePath = AppendDevicePathNode (DevicePath, (EFI_DEVICE_PATH_PROTOCOL
*)&gTerminalTypeDeviceNode);
+ DEBUG((EFI_D_ERROR, "%a %d: full path: %s\n", __FUNCTION__, __LINE__,
+ ConvertDevicePathToText(DevicePath, TRUE, FALSE)
+ ));
+ EfiBootManagerUpdateConsoleVariable (ConOut, DevicePath, NULL);
+ EfiBootManagerUpdateConsoleVariable (ConIn, DevicePath, NULL);
+ EfiBootManagerUpdateConsoleVariable (ErrOut, DevicePath, NULL);
+ return EFI_SUCCESS;
+}
VOID
PlatformInitializeConsole (
@@ -931,6 +956,14 @@ Arguments:
GetEfiGlobalVariable2 (EFI_CON_OUT_VARIABLE_NAME, (VOID **) &VarConout,
NULL);
GetEfiGlobalVariable2 (EFI_CON_IN_VARIABLE_NAME, (VOID **) &VarConin, NULL);
+ // do xen console
+ //VISIT_PCI_INSTANCE_CALLBACK CallBackFunction
+ VisitAllInstancesOfProtocol (
+ &gEfiSerialIoProtocolGuid,
+ add_serial,
+ (VOID*)NULL
+ );
+
if (VarConout == NULL || VarConin == NULL) {
//
// Do platform specific PCI Device check and add them to ConOut, ConIn,
ErrOut
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index 4a6bece..74ab6b1 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -73,6 +73,8 @@
gEfiLoadedImageProtocolGuid # PROTOCOL SOMETIMES_PRODUCED
gEfiFirmwareVolume2ProtocolGuid # PROTOCOL SOMETIMES_CONSUMED
+ gEfiSerialIoProtocolGuid
+
[Guids]
gEfiXenInfoGuid
gEfiEndOfDxeEventGroupGuid
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index 31a2185..8bce996 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -590,6 +590,10 @@
OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+ OvmfPkg/XenConsoleIo/XenConsoleIo.inf {
+
+
SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf
+ }
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index f6876d7..a40d186 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -223,6 +223,7 @@ INF OvmfPkg/BlockMmioToBlockIoDxe/BlockIo.inf
INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
INF OvmfPkg/XenBusDxe/XenBusDxe.inf
INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+INF OvmfPkg/XenConsoleIo/XenConsoleIo.inf
!if $(SECURE_BOOT_ENABLE) == TRUE
INF
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libelf: Fix div0 issues in elf_{shdr, phdr}_count()
Andrew Cooper writes ("Re: [PATCH] libelf: Fix div0 issues in
elf_{shdr,phdr}_count()"):
> On 08/12/16 15:17, Jan Beulich wrote:
> > Oh, I see - elf_phdr_count() itself relies on the check that's
> > about to be done. But I think the correct thing then would be to
> > not use elf_phdr_count() here, but read the raw field instead.
> > You patch basically adds a weaker check there which is then
> > immediately being followed by the stronger check above.
There must be no "reading of raw fields". You may use
elf_access_unsigned if you really want to.
> > And looking at it from that angle it's then questionable why
> > elf_{p,s}hdr_count() do any checking at all - this should all be
> > done once in elf_init(). IOW I did the adjustment in the wrong
> > way, and I really should have made elf_shdr_count() match
> > elf_phdr_count() (moving the checks into elf_init()).
The point of this checking is not to avoid overflow, but just to
ensure that the loops which rely on elf_*_count do not iterate "far
too much".
> > And looking at elf_init() again I also realize that I blindly
> > copied the range checks, calculation of which can overflow.
These possibly-faulty range checks are harmless because they all
operate on unsigned values.
Frankly I'm not sure what the point of a01b6d46 was ?
> > I think it would be better to do those checks such that
> > overflow results in an error return.
The design principle behind my fixes to XSA-55 is to write the bulk of
libelf in a subset of C which is always safe.
This means:
* Always using unsigned integers (so no signed integer overflow).
* Doing all pointer dereferences into the ELF block using an
access function which does a bounds check. (And this also
means representing all pointers as unsigned offsets, so that we
avoid calculating basilisk pointer values.)
* Explicitly limiting the iteration count of every loop where
necessayr (to avoid DOS attacks from bad images).
* Not using unsafe operations like division by input-controlled
values.
Sticking to these rules is a lot easier than writing explicit checks.
This is because these explicit checks are very easy to omit, or get
wrong. The pointers are all encapsulated in a special type which
prevents uncontrolled dereference.
Admittedly the rule about iteration count is not so easy to remember,
and I had failed to anticipate that someone would introduce division.
But both of those kind of bugs are denial of service, rather than
privilege escalation.
Having stared at the commit message of a01b6d46 and at the
pre-a01b6d46 code, I still don't understand what motivated the
changes.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.9 Development Update
On Thu, Dec 08, 2016 at 03:12:12PM +, Julien Grall wrote: [...] > == Toolstack == > > * Logging solution for Xen system > - Wei Liu > Not enough interest, please drop this for now. > * Remove blktap2 > - Wei Liu > Under discussion with user. > == Mini-OS == > > == GRUB == > > * Support booting Xen ARM > - Fu Wei > > == Testing == > Continuous fuzzing of Xen code using Google oss-fuzz (Wei) > == Completed == > Rework gcov support in hypervisor (Wei) Xenstore XS_DIRECTORY_PART extension (Juergen) > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 14/14] XenOvmf: Use a different RTC
---
OvmfPkg/XenOvmf.dsc | 5 -
OvmfPkg/XenOvmf.fdf | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index a7a884e..345157b 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -567,7 +567,10 @@
}
MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
MdeModulePkg/Universal/Metronome/Metronome.inf
- PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+ EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf {
+
+
RealTimeClockLib|ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
+ }
MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index a500ab6..65db2ba 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -217,7 +217,7 @@ INF
MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
INF MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
INF MdeModulePkg/Universal/Metronome/Metronome.inf
-INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
INF OvmfPkg/BlockMmioToBlockIoDxe/BlockIo.inf
INF OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 13/14] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables
This "device" use XenIoMmioLib to reserve some space to be use by grant
tables. It's use 0xfc00, which might not be a good choice...
There is probably a better way that using a device for this.
---
OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c | 263
OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf | 45 ++
OvmfPkg/XenOvmf.dsc | 2 +
OvmfPkg/XenOvmf.fdf | 1 +
4 files changed, 311 insertions(+)
create mode 100644 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
create mode 100644 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
diff --git a/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
new file mode 100644
index 000..12e076f
--- /dev/null
+++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
@@ -0,0 +1,263 @@
+/** @file
+
+ XXX
+
+ XXX
+
+ This program and the accompanying materials are licensed and made available
+ under the terms and conditions of the BSD License which accompanies this
+ distribution. The full text of the license may be found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+ WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* #include */
+STATIC BOOLEAN mXenIoInitialized = FALSE;
+
+/**
+
+ Device probe function for this driver.
+
+ The DXE core calls this function for any given device in order to see if the
+ driver can drive the device.
+
+ @param[in] ThisThe EFI_DRIVER_BINDING_PROTOCOL object
+ incorporating this driver (independently of
+ any device).
+
+ @param[in] DeviceHandle The device to probe.
+
+ @param[in] RemainingDevicePath Relevant only for bus drivers, ignored.
+
+
+ @retval EFI_SUCCESS The driver supports the device being probed.
+
+ @retval EFI_UNSUPPORTED The driver does not support the device being probed.
+
+ @return Error codes from the OpenProtocol() boot service or
+ the PciIo protocol.
+
+**/
+#if 1
+STATIC
+EFI_STATUS
+EFIAPI
+XenIoPvhDeviceBindingSupported (
+ IN EFI_DRIVER_BINDING_PROTOCOL *This,
+ IN EFI_HANDLE DeviceHandle,
+ IN EFI_DEVICE_PATH_PROTOCOL*RemainingDevicePath
+ )
+{
+
+ // XXX check if running Xen PVH
+ //
+
+ if (mXenIoInitialized) {
+return EFI_ALREADY_STARTED;
+ }
+
+ DEBUG((EFI_D_INFO, "%a %d\n", __FUNCTION__, __LINE__));
+ return EFI_SUCCESS;
+}
+#endif
+
+/**
+
+ After we've pronounced support for a specific device in
+ DriverBindingSupported(), we start managing said device (passed in by the
+ Driver Execution Environment) with the following service.
+
+ See DriverBindingSupported() for specification references.
+
+ @param[in] ThisThe EFI_DRIVER_BINDING_PROTOCOL object
+ incorporating this driver (independently of
+ any device).
+
+ @param[in] DeviceHandle The supported device to drive.
+
+ @param[in] RemainingDevicePath Relevant only for bus drivers, ignored.
+
+
+ @retval EFI_SUCCESS The device was started.
+
+ @retval EFI_OUT_OF_RESOURCES Memory allocation failed.
+
+ @return Error codes from the OpenProtocol() boot
+service, the PciIo protocol or the
+InstallProtocolInterface() boot service.
+
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+XenIoPvhDeviceBindingStart (
+ IN EFI_DRIVER_BINDING_PROTOCOL *This,
+ IN EFI_HANDLE DeviceHandle,
+ IN EFI_DEVICE_PATH_PROTOCOL*RemainingDevicePath
+ )
+{
+ EFI_STATUSStatus;
+ EFI_HANDLE Handle = NULL;
+
+ /* Status = XenIoMmioInstall(&Handle, (UINTN)AllocateReservedPages(4)); */
+ Status = XenIoMmioInstall(&Handle, (UINTN)0xfc00);
+
+ if (!EFI_ERROR (Status)) {
+mXenIoInitialized = TRUE;
+return EFI_SUCCESS;
+ }
+
+ return Status;
+}
+
+#if 1
+/**
+
+ Stop driving the XenIo PCI device
+
+ @param[in] This The EFI_DRIVER_BINDING_PROTOCOL object
+incorporating this driver (independently of any
+device).
+
+ @param[in] DeviceHandle Stop driving this device.
+
+ @param[in] NumberOfChildren Since this function belongs to a device driver
+only (as opposed to a bus driver), the caller
+environment sets NumberOfChildren to zero, and
+we ignore it.
+
+ @param[in] ChildHandleBuffer Ignored (corresponding to NumberOfChildren).
+
+ @retval EFI_SUCCESS Driver instance has been stopped and the PCI
+configuration attributes have been restored.
+
+ @return Error codes from the OpenProtocol()
[Xen-devel] [PATCH RFC 10/14] UefiCpuPkg/BaseXApicX2ApicLib: Fix initialisation on my system and ...
declare more exported function, ReadLocalApicReg and WriteLocalApicReg.
On my system (running OVMF inside a Xen PVH guest), writing the
interrupt information (to XAPIC_LVT_TIMER_OFFSET) would also reset the
init-count register, thus disabling the timer.
---
UefiCpuPkg/Include/Library/LocalApicLib.h | 40 ++
.../BaseXApicX2ApicLib/BaseXApicX2ApicLib.c| 10 +++---
2 files changed, 45 insertions(+), 5 deletions(-)
diff --git a/UefiCpuPkg/Include/Library/LocalApicLib.h
b/UefiCpuPkg/Include/Library/LocalApicLib.h
index fc980bc..ab621f2 100644
--- a/UefiCpuPkg/Include/Library/LocalApicLib.h
+++ b/UefiCpuPkg/Include/Library/LocalApicLib.h
@@ -48,6 +48,46 @@ SetLocalApicBaseAddress (
);
/**
+ Read from a local APIC register.
+
+ This function reads from a local APIC register either in xAPIC or x2APIC
mode.
+ It is required that in xAPIC mode wider registers (64-bit or 256-bit) must be
+ accessed using multiple 32-bit loads or stores, so this function only
performs
+ 32-bit read.
+
+ @param MmioOffset The MMIO offset of the local APIC register in xAPIC mode.
+ It must be 16-byte aligned.
+
+ @return 32-bit Value read from the register.
+**/
+UINT32
+EFIAPI
+ReadLocalApicReg (
+ IN UINTN MmioOffset
+ );
+
+/**
+ Write to a local APIC register.
+
+ This function writes to a local APIC register either in xAPIC or x2APIC mode.
+ It is required that in xAPIC mode wider registers (64-bit or 256-bit) must be
+ accessed using multiple 32-bit loads or stores, so this function only
performs
+ 32-bit write.
+
+ if the register index is invalid or unsupported in current APIC mode, then
ASSERT.
+
+ @param MmioOffset The MMIO offset of the local APIC register in xAPIC mode.
+ It must be 16-byte aligned.
+ @param Value Value to be written to the register.
+**/
+VOID
+EFIAPI
+WriteLocalApicReg (
+ IN UINTN MmioOffset,
+ IN UINT32 Value
+ );
+
+/**
Get the current local APIC mode.
If local APIC is disabled, then ASSERT.
diff --git a/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c
b/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c
index e690d2a..f84a40a 100644
--- a/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c
+++ b/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c
@@ -820,11 +820,6 @@ InitializeApicTimer (
//
InitializeLocalApicSoftwareEnable (TRUE);
- //
- // Program init-count register.
- //
- WriteLocalApicReg (XAPIC_TIMER_INIT_COUNT_OFFSET, InitCount);
-
if (DivideValue != 0) {
ASSERT (DivideValue <= 128);
ASSERT (DivideValue == GetPowerOfTwo32((UINT32)DivideValue));
@@ -848,6 +843,11 @@ InitializeApicTimer (
LvtTimer.Bits.Mask = 0;
LvtTimer.Bits.Vector = Vector;
WriteLocalApicReg (XAPIC_LVT_TIMER_OFFSET, LvtTimer.Uint32);
+
+ //
+ // Program init-count register.
+ //
+ WriteLocalApicReg (XAPIC_TIMER_INIT_COUNT_OFFSET, InitCount);
}
/**
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 11/14] OvmfPkg/XenOvmf: Adding XenTimerLocalApic
And replacing the ACPI Timer by this one based on the local APIC.
ACPI Timer does not work in a PVH guest, but local APIC works on both
PVH and HVM.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD
---
OvmfPkg/XenOvmf.dsc | 18 +-
OvmfPkg/XenOvmf.fdf | 2 +-
OvmfPkg/XenTimerLocalApic/Timer.h | 191
OvmfPkg/XenTimerLocalApic/XenTimerLocalApic.c | 386
OvmfPkg/XenTimerLocalApic/XenTimerLocalApic.inf | 51
5 files changed, 640 insertions(+), 8 deletions(-)
create mode 100644 OvmfPkg/XenTimerLocalApic/Timer.h
create mode 100644 OvmfPkg/XenTimerLocalApic/XenTimerLocalApic.c
create mode 100644 OvmfPkg/XenTimerLocalApic/XenTimerLocalApic.inf
diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index ef32c33..31a2185 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -81,7 +81,7 @@
[LibraryClasses]
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
+ TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
BaseMemoryLib|MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
@@ -175,7 +175,7 @@
!endif
[LibraryClasses.common.SEC]
- TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
+ TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
!ifdef $(DEBUG_ON_SERIAL_PORT)
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
@@ -251,7 +251,7 @@
[LibraryClasses.common.DXE_RUNTIME_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+ TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
@@ -269,7 +269,7 @@
[LibraryClasses.common.UEFI_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+ TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
@@ -284,7 +284,7 @@
[LibraryClasses.common.DXE_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+ TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
@@ -314,7 +314,7 @@
[LibraryClasses.common.UEFI_APPLICATION]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
- TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+ TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
@@ -546,7 +546,11 @@
!endif
MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
- PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
+ OvmfPkg/XenTimerLocalApic/XenTimerLocalApic.inf
+ #{
+ #
+#LocalApicLib|UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf
+ #}
UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
UefiCpuPkg/CpuDxe/CpuDxe.inf
PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index c211f61..f6876d7 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -207,7 +207,7 @@ INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
INF MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
-INF PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
+INF OvmfPkg/XenTimerLocalApic/XenTimerLocalApic.inf
INF UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
INF UefiCpuPkg/CpuDxe/CpuDxe.inf
INF PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
diff --git a/OvmfPkg/XenTimerLocalApic/Timer.h
b/OvmfPkg/XenTimerLocalApic/Timer.h
new file mode 100644
index 000..8d6f37c
--- /dev/null
+++ b/OvmfPkg/XenTimerLocalApic/Timer.h
@@ -0,0 +1,191 @@
+/** @file
+ Private data structures
+
+Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.
+This program
[Xen-devel] [PATCH 0/3] misc cpumask adjustments
1: make tlbflush_filter()'s first parameter a pointer 2: VT-d: correct dma_msi_set_affinity() 3: x86: introduce and use scratch CPU mask Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.9 Development Update
>>> On 08.12.16 at 16:36, wrote: > On Thu, Dec 08, 2016 at 03:12:12PM +, Julien Grall wrote: > [...] >> == Toolstack == >> >> * Logging solution for Xen system >> - Wei Liu >> > > Not enough interest, please drop this for now. Possibly slightly related: What's the situation with the runtime log level adjustments? My old series predating the whole 4.8 cycle I wonder whether I shouldn't strip off the sysctl and tool stack parts and at least try to get the serial console based stuff in. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/3] make tlbflush_filter()'s first parameter a pointer
This brings it in line with most other functions dealing with CPU
masks. Convert both implementations to inline functions at once.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2514,7 +2514,7 @@ static int __get_page_type(struct page_i
cpumask_copy(&mask, d->domain_dirty_cpumask);
/* Don't flush if the timestamp is old enough */
-tlbflush_filter(mask, page->tlbflush_timestamp);
+tlbflush_filter(&mask, page->tlbflush_timestamp);
if ( unlikely(!cpumask_empty(&mask)) &&
/* Shadow mode: track only writable pages. */
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1471,7 +1471,7 @@ mfn_t shadow_alloc(struct domain *d,
/* Before we overwrite the old contents of this page,
* we need to be sure that no TLB holds a pointer to it. */
cpumask_copy(&mask, d->domain_dirty_cpumask);
-tlbflush_filter(mask, sp->tlbflush_timestamp);
+tlbflush_filter(&mask, sp->tlbflush_timestamp);
if ( unlikely(!cpumask_empty(&mask)) )
{
perfc_incr(shadow_alloc_tlbflush);
--- a/xen/include/asm-arm/flushtlb.h
+++ b/xen/include/asm-arm/flushtlb.h
@@ -8,9 +8,7 @@
* TLB since @page_timestamp.
*/
/* XXX lazy implementation just doesn't clear anything */
-#define tlbflush_filter(mask, page_timestamp) \
-do {\
-} while ( 0 )
+static inline void tlbflush_filter(cpumask_t *mask, uint32_t page_timestamp) {}
#define tlbflush_current_time() (0)
--- a/xen/include/asm-x86/flushtlb.h
+++ b/xen/include/asm-x86/flushtlb.h
@@ -50,13 +50,14 @@ static inline int NEED_FLUSH(u32 cpu_sta
* Filter the given set of CPUs, removing those that definitely flushed their
* TLB since @page_timestamp.
*/
-#define tlbflush_filter(mask, page_timestamp) \
-do {\
-unsigned int cpu; \
-for_each_cpu ( cpu, &(mask) ) \
-if ( !NEED_FLUSH(per_cpu(tlbflush_time, cpu), page_timestamp) ) \
-cpumask_clear_cpu(cpu, &(mask));\
-} while ( 0 )
+static inline void tlbflush_filter(cpumask_t *mask, uint32_t page_timestamp)
+{
+unsigned int cpu;
+
+for_each_cpu ( cpu, mask )
+if ( !NEED_FLUSH(per_cpu(tlbflush_time, cpu), page_timestamp) )
+cpumask_clear_cpu(cpu, mask);
+}
void new_tlbflush_clock_period(void);
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -588,9 +588,10 @@ static inline void accumulate_tlbflush(b
static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp)
{
-cpumask_t mask = cpu_online_map;
+cpumask_t mask;
-tlbflush_filter(mask, tlbflush_timestamp);
+cpumask_copy(&mask, &cpu_online_map);
+tlbflush_filter(&mask, tlbflush_timestamp);
if ( !cpumask_empty(&mask) )
{
perfc_incr(need_flush_tlb_flush);
make tlbflush_filter()'s first parameter a pointer
This brings it in line with most other functions dealing with CPU
masks. Convert both implementations to inline functions at once.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2514,7 +2514,7 @@ static int __get_page_type(struct page_i
cpumask_copy(&mask, d->domain_dirty_cpumask);
/* Don't flush if the timestamp is old enough */
-tlbflush_filter(mask, page->tlbflush_timestamp);
+tlbflush_filter(&mask, page->tlbflush_timestamp);
if ( unlikely(!cpumask_empty(&mask)) &&
/* Shadow mode: track only writable pages. */
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1471,7 +1471,7 @@ mfn_t shadow_alloc(struct domain *d,
/* Before we overwrite the old contents of this page,
* we need to be sure that no TLB holds a pointer to it. */
cpumask_copy(&mask, d->domain_dirty_cpumask);
-tlbflush_filter(mask, sp->tlbflush_timestamp);
+tlbflush_filter(&mask, sp->tlbflush_timestamp);
if ( unlikely(!cpumask_empty(&mask)) )
{
perfc_incr(shadow_alloc_tlbflush);
--- a/xen/include/asm-arm/flushtlb.h
+++ b/xen/include/asm-arm/flushtlb.h
@@ -8,9 +8,7 @@
* TLB since @page_timestamp.
*/
/* XXX lazy implementation just doesn't clear anything */
-#define tlbflush_filter(mask, page_timestamp) \
-do {\
-} while ( 0 )
+static inline void tlbflush_filter(cpumask_t *mask, uint32_t page_timestamp) {}
#define tlbflush_current_time() (0)
--- a/xen/include/asm-x86/flushtlb.h
+++ b/xen/include/a
[Xen-devel] [PATCH 2/3] VT-d: correct dma_msi_set_affinity()
That commit ("VT-d: use msi_compose_msg()) together with 15aa6c6748
("amd iommu: use base platform MSI implementation") introducing the use
of a per-CPU scratch CPU mask went too far: dma_msi_set_affinity() may,
at least in theory, be called in interrupt context, and hence the use
of that scratch variable is not correct.
Since the function overwrites the destination information anyway,
allow msi_compose_msg() to be called with a NULL CPU mask, avoiding the
use of that scratch variable.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -160,39 +160,37 @@ static bool_t msix_memory_decoded(const
*/
void msi_compose_msg(unsigned vector, const cpumask_t *cpu_mask, struct
msi_msg *msg)
{
-unsigned dest;
-
memset(msg, 0, sizeof(*msg));
-if ( !cpumask_intersects(cpu_mask, &cpu_online_map) )
+
+if ( vector < FIRST_DYNAMIC_VECTOR )
return;
-if ( vector )
+if ( cpu_mask )
{
cpumask_t *mask = this_cpu(scratch_mask);
-cpumask_and(mask, cpu_mask, &cpu_online_map);
-dest = cpu_mask_to_apicid(mask);
+if ( !cpumask_intersects(cpu_mask, &cpu_online_map) )
+return;
-msg->address_hi = MSI_ADDR_BASE_HI;
-msg->address_lo =
-MSI_ADDR_BASE_LO |
-((INT_DEST_MODE == 0) ?
- MSI_ADDR_DESTMODE_PHYS:
- MSI_ADDR_DESTMODE_LOGIC) |
-((INT_DELIVERY_MODE != dest_LowestPrio) ?
- MSI_ADDR_REDIRECTION_CPU:
- MSI_ADDR_REDIRECTION_LOWPRI) |
-MSI_ADDR_DEST_ID(dest);
-msg->dest32 = dest;
-
-msg->data =
-MSI_DATA_TRIGGER_EDGE |
-MSI_DATA_LEVEL_ASSERT |
-((INT_DELIVERY_MODE != dest_LowestPrio) ?
- MSI_DATA_DELIVERY_FIXED:
- MSI_DATA_DELIVERY_LOWPRI) |
-MSI_DATA_VECTOR(vector);
+cpumask_and(mask, cpu_mask, &cpu_online_map);
+msg->dest32 = cpu_mask_to_apicid(mask);
}
+
+msg->address_hi = MSI_ADDR_BASE_HI;
+msg->address_lo = MSI_ADDR_BASE_LO |
+ (INT_DEST_MODE ? MSI_ADDR_DESTMODE_LOGIC
+ : MSI_ADDR_DESTMODE_PHYS) |
+ ((INT_DELIVERY_MODE != dest_LowestPrio)
+ ? MSI_ADDR_REDIRECTION_CPU
+ : MSI_ADDR_REDIRECTION_LOWPRI) |
+ MSI_ADDR_DEST_ID(msg->dest32);
+
+msg->data = MSI_DATA_TRIGGER_EDGE |
+MSI_DATA_LEVEL_ASSERT |
+((INT_DELIVERY_MODE != dest_LowestPrio)
+ ? MSI_DATA_DELIVERY_FIXED
+ : MSI_DATA_DELIVERY_LOWPRI) |
+MSI_DATA_VECTOR(vector);
}
static bool_t read_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1085,11 +1085,10 @@ static void dma_msi_set_affinity(struct
return;
}
-msi_compose_msg(desc->arch.vector, desc->arch.cpu_mask, &msg);
-/* Are these overrides really needed? */
+msi_compose_msg(desc->arch.vector, NULL, &msg);
if (x2apic_enabled)
msg.address_hi = dest & 0xFF00;
-msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
+ASSERT(!(msg.address_lo & MSI_ADDR_DEST_ID_MASK));
msg.address_lo |= MSI_ADDR_DEST_ID(dest);
iommu->msi.msg = msg;
VT-d: correct dma_msi_set_affinity()
That commit ("VT-d: use msi_compose_msg()) together with 15aa6c6748
("amd iommu: use base platform MSI implementation") introducing the use
of a per-CPU scratch CPU mask went too far: dma_msi_set_affinity() may,
at least in theory, be called in interrupt context, and hence the use
of that scratch variable is not correct.
Since the function overwrites the destination information anyway,
allow msi_compose_msg() to be called with a NULL CPU mask, avoiding the
use of that scratch variable.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -160,39 +160,37 @@ static bool_t msix_memory_decoded(const
*/
void msi_compose_msg(unsigned vector, const cpumask_t *cpu_mask, struct
msi_msg *msg)
{
-unsigned dest;
-
memset(msg, 0, sizeof(*msg));
-if ( !cpumask_intersects(cpu_mask, &cpu_online_map) )
+
+if ( vector < FIRST_DYNAMIC_VECTOR )
return;
-if ( vector )
+if ( cpu_mask )
{
cpumask_t *mask = this_cpu(scratch_mask);
-cpumask_and(mask, cpu_mask, &cpu_online_map);
-dest = cpu_mask_to_apicid(mask);
+if ( !cpumask_intersects(cpu_mask, &cpu_online_map) )
+return;
-msg->address_hi = MSI_ADDR_BASE_HI;
-msg->address_lo =
-MSI_ADDR_BASE_LO |
-((INT_DEST_MODE == 0) ?
- MSI_ADDR_DESTMODE_PHYS:
- MSI_ADDR_DESTMODE_LOGIC) |
-((INT_DELIVERY_MODE != dest_LowestPrio) ?
- MSI_ADDR_REDIRECTION_CPU:
- MSI_ADDR_REDIRECTION_LOWPRI) |
-MSI_ADDR_D
Re: [Xen-devel] Xen 4.9 Development Update
On Thu, Dec 08, 2016 at 08:57:21AM -0700, Jan Beulich wrote: > >>> On 08.12.16 at 16:36, wrote: > > On Thu, Dec 08, 2016 at 03:12:12PM +, Julien Grall wrote: > > [...] > >> == Toolstack == > >> > >> * Logging solution for Xen system > >> - Wei Liu > >> > > > > Not enough interest, please drop this for now. > > Possibly slightly related: What's the situation with the runtime log > level adjustments? My old series predating the whole 4.8 cycle I > wonder whether I shouldn't strip off the sysctl and tool stack > parts and at least try to get the serial console based stuff in. Sure. I think that's a good idea. I won't be working on that any time soon. Wei. > > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3/3] x86: introduce and use scratch CPU mask
__get_page_type(), so far using an on-stack CPU mask variable, is
involved in the recursion when e.g. pinning page tables. This means
there may be up two five instances of the function active at a time,
implying five instances of the (up to 512 bytes large) CPU mask
variable. With an IRQ happening at the deepest point of the stack, and
with send_guest_pirq() being called from there (leading to vcpu_kick()
-> ... -> csched_vcpu_wake() -> __runq_tickle() ->
cpumask_raise_softirq(), the last two of which also have CPU mask
variables on their stacks), this has been observed to cause a stack
overflow with a 4095-pCPU build.
Introduce a per-CPU variable instead, which can then be used by any
code never running in IRQ context.
The mask can then also be used by other MMU code as well as by
msi_compose_msg() (and quite likely we'll find further uses down the
road).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2477,6 +2477,7 @@ static int __get_page_type(struct page_i
int rc = 0, iommu_ret = 0;
ASSERT(!(type & ~(PGT_type_mask | PGT_pae_xen_l2)));
+ASSERT(!in_irq());
for ( ; ; )
{
@@ -2509,20 +2510,21 @@ static int __get_page_type(struct page_i
* may be unnecessary (e.g., page was GDT/LDT) but those
* circumstances should be very rare.
*/
-cpumask_t mask;
+cpumask_t *mask = this_cpu(scratch_cpumask);
-cpumask_copy(&mask, d->domain_dirty_cpumask);
+BUG_ON(in_irq());
+cpumask_copy(mask, d->domain_dirty_cpumask);
/* Don't flush if the timestamp is old enough */
-tlbflush_filter(&mask, page->tlbflush_timestamp);
+tlbflush_filter(mask, page->tlbflush_timestamp);
-if ( unlikely(!cpumask_empty(&mask)) &&
+if ( unlikely(!cpumask_empty(mask)) &&
/* Shadow mode: track only writable pages. */
(!shadow_mode_enabled(page_get_owner(page)) ||
((nx & PGT_type_mask) == PGT_writable_page)) )
{
perfc_incr(need_flush_tlb_flush);
-flush_tlb_mask(&mask);
+flush_tlb_mask(mask);
}
/* We lose existing type and validity. */
@@ -3404,22 +3406,22 @@ long do_mmuext_op(
case MMUEXT_TLB_FLUSH_MULTI:
case MMUEXT_INVLPG_MULTI:
{
-cpumask_t pmask;
+cpumask_t *mask = this_cpu(scratch_cpumask);
if ( unlikely(d != pg_owner) )
rc = -EPERM;
else if ( unlikely(vcpumask_to_pcpumask(d,
guest_handle_to_param(op.arg2.vcpumask,
const_void),
- &pmask)) )
+ mask)) )
rc = -EINVAL;
if ( unlikely(rc) )
break;
if ( op.cmd == MMUEXT_TLB_FLUSH_MULTI )
-flush_tlb_mask(&pmask);
+flush_tlb_mask(mask);
else if ( __addr_ok(op.arg1.linear_addr) )
-flush_tlb_one_mask(&pmask, op.arg1.linear_addr);
+flush_tlb_one_mask(mask, op.arg1.linear_addr);
break;
}
@@ -3457,14 +3459,14 @@ long do_mmuext_op(
else if ( likely(cache_flush_permitted(d)) )
{
unsigned int cpu;
-cpumask_t mask;
+cpumask_t *mask = this_cpu(scratch_cpumask);
-cpumask_clear(&mask);
+cpumask_clear(mask);
for_each_online_cpu(cpu)
-if ( !cpumask_intersects(&mask,
+if ( !cpumask_intersects(mask,
per_cpu(cpu_sibling_mask, cpu)) )
-__cpumask_set_cpu(cpu, &mask);
-flush_mask(&mask, FLUSH_CACHE);
+__cpumask_set_cpu(cpu, mask);
+flush_mask(mask, FLUSH_CACHE);
}
else
{
@@ -4460,7 +4462,7 @@ static int __do_update_va_mapping(
struct page_info *gl1pg;
l1_pgentry_t *pl1e;
unsigned long bmap_ptr, gl1mfn;
-cpumask_t pmask;
+cpumask_t *mask = NULL;
intrc;
perfc_incr(calls_to_update_va);
@@ -4506,15 +4508,17 @@ static int __do_update_va_mapping(
flush_tlb_local();
break;
case UVMF_ALL:
-flush_tlb_mask(d->domain_dirty_cpumask);
+mask = d->domain_dirty_cpumask;
break;
default:
+mask = this_cpu(scratch_cpumask);
rc = vcpumask_to_pcpumask(d, const_guest_handle_from_ptr(bmap_ptr,
void),
-
Re: [Xen-devel] [PATCH] libelf: Fix div0 issues in elf_{shdr, phdr}_count()
>>> On 08.12.16 at 16:47, wrote:
> Andrew Cooper writes ("Re: [PATCH] libelf: Fix div0 issues in
> elf_{shdr,phdr}_count()"):
>> On 08/12/16 15:17, Jan Beulich wrote:
>> > Oh, I see - elf_phdr_count() itself relies on the check that's
>> > about to be done. But I think the correct thing then would be to
>> > not use elf_phdr_count() here, but read the raw field instead.
>> > You patch basically adds a weaker check there which is then
>> > immediately being followed by the stronger check above.
>
> There must be no "reading of raw fields". You may use
> elf_access_unsigned if you really want to.
Oh, by "raw" I meant using elf_uval() rather than elf_phdr_count().
>> > And looking at it from that angle it's then questionable why
>> > elf_{p,s}hdr_count() do any checking at all - this should all be
>> > done once in elf_init(). IOW I did the adjustment in the wrong
>> > way, and I really should have made elf_shdr_count() match
>> > elf_phdr_count() (moving the checks into elf_init()).
>
> The point of this checking is not to avoid overflow, but just to
> ensure that the loops which rely on elf_*_count do not iterate "far
> too much".
>
>> > And looking at elf_init() again I also realize that I blindly
>> > copied the range checks, calculation of which can overflow.
>
> These possibly-faulty range checks are harmless because they all
> operate on unsigned values.
Why does operating on unsigned values make overflow harmless?
> Frankly I'm not sure what the point of a01b6d46 was ?
First of all I'd like to refer you to its description, but see below.
Are you suggesting that all those adjustments appear pointless
to you?
> * Not using unsafe operations like division by input-controlled
>values.
But using a hard coded but possibly wrong value instead isn't
really a solution.
> Having stared at the commit message of a01b6d46 and at the
> pre-a01b6d46 code, I still don't understand what motivated the
> changes.
Hmm, that's interesting. Are you then saying all the changes it
did and described are wrong? Pointless? I could do with some
clarification here, as otherwise it's not clear whether spending
time on producing an improved v2 is actually worth it.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 01/14] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests
>>> On 30.11.16 at 17:49, wrote: > --- a/docs/misc/hvmlite.markdown > +++ b/docs/misc/hvmlite.markdown > @@ -75,3 +75,23 @@ info structure that's passed at boot time (field > rsdp_paddr). > > Description of paravirtualized devices will come from XenStore, just as it's > done for HVM guests. > + > +## Interrupts ## > + > +### Interrupts from physical devices ### > + > +Interrupts from physical devices are delivered using native methods, this is > +done in order to take advantage of new hardware assisted virtualization > +functions, like posted interrupts. This implies that PVHv2 guests with > physical > +devices will also have the necessary interrupt controllers in order to manage > +the delivery of interrupts from those devices, using the same interfaces that > +are available on native hardware. I continue to not really agree with this. For a while you can't assume posted interrupts to be universally available. And iirc we still don't enable their use by default in Xen. Hence I could see this to be the preferred mechanism, but the event channel based mechanism may want to remain an alternative, the more that ... > +### Interrupts from paravirtualized devices ### > + > +Interrupts from paravirtualized devices are delivered using event channels, > see > +[Event Channel Internals][event_channels] for more detailed information about > +event channels. Delivery of those interrupts can be configured in the same > way > +as HVM guests, check xen/include/public/hvm/params.h and > +xen/include/public/hvm/hvm_op.h for more information about available delivery > +methods. ... you still need them anyway. Similarly I continue to be in disagreement with the blanket disabling of all physdev ops. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 07/14] x86/iommu: add IOMMU entries for p2m_mmio_direct pages
>>> On 30.11.16 at 17:49, wrote: > --- a/xen/include/asm-x86/p2m.h > +++ b/xen/include/asm-x86/p2m.h > @@ -834,6 +834,7 @@ static inline unsigned int p2m_get_iommu_flags(p2m_type_t > p2mt) > case p2m_grant_map_rw: > case p2m_ram_logdirty: > case p2m_map_foreign: > +case p2m_mmio_direct: > flags = IOMMUF_readable | IOMMUF_writable; > break; I think you need to take mmio_ro_ranges into account here. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 08/14] xen/x86: allow the emulated APICs to be enabled for the hardware domain
>>> On 30.11.16 at 17:49, wrote:
> Allow the use of both the emulated local APIC and IO APIC for the hardware
> domain.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
albeit I'm not 100% convinced of ...
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -509,6 +509,27 @@ void vcpu_destroy(struct vcpu *v)
> xfree(v->arch.pv_vcpu.trap_ctxt);
> }
>
> +static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
> +{
> +
> +if ( is_hvm_domain(d) )
> +{
> +if ( is_hardware_domain(d) &&
> + emflags != (XEN_X86_EMU_LAPIC|XEN_X86_EMU_IOAPIC) )
... requiring IO-APIC emulation here. But we can adjust that once
we find a legacy free system to test on.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86emul: support LAR/LSL/VERR/VERW
On 08/12/16 11:52, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -182,7 +182,7 @@ static const opcode_desc_t opcode_table[
>
> static const opcode_desc_t twobyte_table[256] = {
> /* 0x00 - 0x07 */
> -ModRM, ImplicitOps|ModRM, ModRM, ModRM,
> +ModRM, ImplicitOps|ModRM, DstReg|SrcMem16|ModRM, DstReg|SrcMem16|ModRM,
> 0, ImplicitOps, ImplicitOps, ImplicitOps,
> /* 0x08 - 0x0F */
> ImplicitOps, ImplicitOps, 0, ImplicitOps,
> @@ -1384,7 +1384,7 @@ protmode_load_seg(
> }
A number of the following changes were very confusing to follow until I
realised that you are introducing a meaning, where
protmode_load_seg(x86_seg_none, ...) means "please do all the checks,
but don't commit any state or raise any exceptions".
It would be helpful to point this out in the commit message and in a
comment at the head of protmode_load_seg().
>
> /* System segment descriptors must reside in the GDT. */
> -if ( !is_x86_user_segment(seg) && (sel & 4) )
> +if ( is_x86_system_segment(seg) && (sel & 4) )
> goto raise_exn;
>
> switch ( rc = ops->read(sel_seg, sel & 0xfff8, &desc, sizeof(desc),
> ctxt) )
> @@ -1401,14 +1401,11 @@ protmode_load_seg(
> return rc;
> }
>
> -if ( !is_x86_user_segment(seg) )
> -{
> -/* System segments must have S flag == 0. */
> -if ( desc.b & (1u << 12) )
> -goto raise_exn;
> -}
> +/* System segments must have S flag == 0. */
> +if ( is_x86_system_segment(seg) && (desc.b & (1u << 12)) )
> +goto raise_exn;
> /* User segments must have S flag == 1. */
> -else if ( !(desc.b & (1u << 12)) )
> +if ( is_x86_user_segment(seg) && !(desc.b & (1u << 12)) )
> goto raise_exn;
This might be clearer as (and is definitely shorter as)
/* Check .S is correct for the type of segment. */
if ( seg != x86_seg_none &&
is_x86_user_segment(seg) != (desc.b & (1u << 12)) )
goto raise_exn;
>
> dpl = (desc.b >> 13) & 3;
> @@ -1470,10 +1467,17 @@ protmode_load_seg(
> ((dpl < cpl) || (dpl < rpl)) )
> goto raise_exn;
> break;
> +case x86_seg_none:
> +/* Non-conforming segment: check DPL against RPL and CPL. */
> +if ( ((desc.b & (0x1c << 8)) != (0x1c << 8)) &&
> + ((dpl < cpl) || (dpl < rpl)) )
> +return X86EMUL_EXCEPTION;
I realise it is no functional change, but it would be cleaner to have
this as a goto raise_exn, to avoid having one spurious early-exit in a
fucntion which otherwise always goes to raise_exn or done.
> +a_flag = 0;
> +break;
> }
>
> /* Segment present in memory? */
> -if ( !(desc.b & (1 << 15)) )
> +if ( !(desc.b & (1 << 15)) && seg != x86_seg_none )
What is the purpose of this change, given that the raise_exn case is
always conditional on seg != x86_seg_none ?
> {
> fault_type = seg != x86_seg_ss ? EXC_NP : EXC_SS;
> goto raise_exn;
> @@ -1481,7 +1485,7 @@ protmode_load_seg(
>
> if ( !is_x86_user_segment(seg) )
> {
> -int lm = in_longmode(ctxt, ops);
> +int lm = (desc.b & (1u << 12)) ? 0 : in_longmode(ctxt, ops);
>
> if ( lm < 0 )
> return X86EMUL_UNHANDLEABLE;
> @@ -1501,7 +1505,8 @@ protmode_load_seg(
> return rc;
> }
> if ( (desc_hi.b & 0x1f00) ||
> - !is_canonical_address((uint64_t)desc_hi.a << 32) )
> + (seg != x86_seg_none &&
> + !is_canonical_address((uint64_t)desc_hi.a << 32)) )
> goto raise_exn;
> }
> }
> @@ -1544,7 +1549,8 @@ protmode_load_seg(
> return X86EMUL_OKAY;
>
> raise_exn:
> -generate_exception(fault_type, sel & 0xfffc);
> +generate_exception_if(seg != x86_seg_none, fault_type, sel & 0xfffc);
> +rc = X86EMUL_EXCEPTION;
> done:
> return rc;
> }
> @@ -4424,6 +4430,28 @@ x86_emulate(
> if ( (rc = load_seg(seg, src.val, 0, NULL, ctxt, ops)) != 0 )
> goto done;
> break;
> +case 4: /* verr / verw */
This looks wrong, but I see it isn't actually. Whether this patch or a
subsequent one, it would be clearer to alter the switch statement not to
mask off the bottom bit, and have individual case labels for the
instructions.
> +_regs.eflags &= ~EFLG_ZF;
> +switch ( rc = protmode_load_seg(x86_seg_none, src.val, false,
> +&sreg, ctxt, ops) )
> +{
> +case X86EMUL_OKAY:
> +if ( sreg.attr.fields.s &&
> + ((modrm_reg & 1) ? ((sreg.attr.fields.type & 0xa) ==
> 0x2)
> + : ((sreg.attr.fields.type & 0xa) !=
> 0x8)) )
> +_regs.eflags |= EFLG_ZF;
> +break;
> +case X86
Re: [Xen-devel] [PATCH 1/3] make tlbflush_filter()'s first parameter a pointer
On 08/12/16 16:00, Jan Beulich wrote: > This brings it in line with most other functions dealing with CPU > masks. Convert both implementations to inline functions at once. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-4.1 bisection] complete test-amd64-amd64-xl
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Bug introduced: 9a9a2373142ac2c6fd9df9d038eb929b919e30d7
Bug not present: 1b15bd7396897e2f8018f863dd18006092a4deb0
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/103091/
commit 9a9a2373142ac2c6fd9df9d038eb929b919e30d7
Author: Kashyap Desai
Date: Fri Oct 21 06:33:32 2016 -0700
scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough)
devices
[ Upstream commit 1e793f6fc0db920400574211c48f9157a37e3945 ]
Commit 02b01e010afe ("megaraid_sas: return sync cache call with
success") modified the driver to successfully complete SYNCHRONIZE_CACHE
commands without passing them to the controller. Disk drive caches are
only explicitly managed by controller firmware when operating in RAID
mode. So this commit effectively disabled writeback cache flushing for
any drives used in JBOD mode, leading to data integrity failures.
[mkp: clarified patch description]
Fixes: 02b01e010afeeb49328d35650d70721d2ca3fd59
CC: sta...@vger.kernel.org
Signed-off-by: Kashyap Desai
Signed-off-by: Sumit Saxena
Reviewed-by: Tomas Henzl
Reviewed-by: Hannes Reinecke
Reviewed-by: Ewan D. Milne
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-4.1/test-amd64-amd64-xl.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.
Running cs-bisection-step
--graph-out=/home/logs/results/bisect/linux-4.1/test-amd64-amd64-xl.xen-boot
--summary-out=tmp/103091.bisection-summary --basis-template=101737
--blessings=real,real-bisect linux-4.1 test-amd64-amd64-xl xen-boot
Searching for failure / basis pass:
102979 fail [host=nobling1] / 101737 [host=italia0] 101715 [host=huxelrebe1]
101687 [host=godello0] 101672 [host=godello1] 101659 [host=pinot1] 101649
[host=baroque0] 101401 [host=godello0] 101004 [host=huxelrebe0] 101001
[host=godello0] 100753 [host=chardonnay1] 100594 [host=baroque0] 100587
[host=italia1] 100383 [host=italia0] 100371 [host=godello0] 99879
[host=baroque1] 99873 [host=godello1] 99847 [host=pinot1] 96211 [host=rimava1]
96183 [host=elbling0] 96160 [host=italia1] 95848 [host=huxelrebe1] 95818
[host=chardonnay0] 95591 [host=fiano1] 95517 [host=godello0] 95455
[host=elbling0] 95408 [host=baroque1] 94729 [host=fiano0] 94034 [host=baroque1]
93220 [host=italia0] 93111 [host=pinot0] 92143 [host=elbling1] 91350
[host=godello0] 91189 [host=fiano1] 91008 [host=fiano0] 90845
[host=chardonnay1] 89382 [host=godello1] 89248 [host=baroque0] 88721
[host=italia1] 88639 [host=chardonnay0] 88510 [host=elbling0] 88390
[host=italia0] 88251 [host=rimava1] 88073 [host=godello0] 87856 [host=merlot1]
87765 [host=baroque1] 87692 [host=pinot0] 87582 [host=chardonnay1] 87465
[host=elbling1] 87295 [host=godello1] 87204 [host=rimava0] 87117
[host=huxelrebe0] 87031 [host=fiano0] 86912 [host=baroque0] 86830
[host=italia1] 86761 [host=pinot1] 86654 [host=italia0] 86587
[host=chardonnay0] 86510 [host=godello0] 86441 [host=huxelrebe1] 86392
[host=fiano1] 86330 [host=rimava1] 86270 [host=merlot0] 86144
[host=chardonnay1] 86070 [host=godello1] 85972 [host=elbling0] 85868
[host=huxelrebe0] 85746 [host=baroque0] 85682 [host=rimava0] 85641
[host=italia1] 85582 [host=pinot1] 85470 [host=godello0] 85331
[host=chardonnay0] 84995 [host=pinot0] 84906 [host=pinot0] 84496 [host=fiano1]
84400 [host=nocera1] 84313 [host=chardonnay1] 84194 [host=godello1] 84050
[host=baroque1] 83835 [host=fiano0] 83683 [host=rimava0] 83520 [host=baroque0]
83210 [host=chardonnay0] 83005 [host=huxelrebe1] 82991 [host=godello0] 82845
[host=pinot0] 82689 [host=pinot1] 82560 [host=rimava1] 82264 [host=godello1]
81641 [host=italia1] 81078 [host=baroque0] 80752 [host=baroque1] 80533
[host=fiano0] 80370 [host=huxelrebe0] 80172 [host=godello0] 79950
[host=huxelrebe1] 79817 [host=rimava0] 79527 [host=italia1] 79430
[host=chardonnay1] 79387 [host=nocera0] 79162 [host=godello1] 79090
[host=rimava1] 79008 [host=godello0] 66399 [host=fiano0] 65781 [host=godello0]
65699 [host=godello1] 63996 [host=rimava0] 63341 [host=chardonnay1] 63223
[host=rimava0] 63067 [host=baroque0] 63030 [host=merlot1] 63013 [host=godello1]
63000 [host=italia0] 62987 [host=chardonnay0] 62976 [host=rimava1] 62963
[hos
[Xen-devel] Future support of 5-level paging in Xen
The first round of (very preliminary) patches for supporting the new 5-level paging of future Intel x86 processors [1] has been posted to lkml: https://lkml.org/lkml/2016/12/8/378 An explicit note has been added: "CONFIG_XEN is broken." and "I would appreciate help with the code." I think we should start a discussion what we want to do in future: - are we going to support 5-level paging for PV guests? - do we limit 5-level paging to PVH and HVM? Juergen [1] https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/head: Refactor 32-bit pgtable setup
The new Xen PVH entry point requires page tables to be setup by the
kernel since it is entered with paging disabled.
Pull the common code out of head_32.S so that mk_early_pgtbl_32 can be
invoked from both the new Xen entry point and the existing startup_32
code.
Convert resulting common code to C.
Signed-off-by: Boris Ostrovsky
---
This is replacement for https://lkml.org/lkml/2016/10/14/434, with
assembly code re-written in C as requested by Ingo.
arch/x86/include/asm/pgtable_32.h | 32 ++
arch/x86/kernel/head32.c | 62 +++
arch/x86/kernel/head_32.S | 122 +++---
3 files changed, 101 insertions(+), 115 deletions(-)
diff --git a/arch/x86/include/asm/pgtable_32.h
b/arch/x86/include/asm/pgtable_32.h
index b6c0b40..fbc7336 100644
--- a/arch/x86/include/asm/pgtable_32.h
+++ b/arch/x86/include/asm/pgtable_32.h
@@ -27,6 +27,7 @@
extern pgd_t swapper_pg_dir[1024];
extern pgd_t initial_page_table[1024];
+extern pmd_t initial_pg_pmd[];
static inline void pgtable_cache_init(void) { }
static inline void check_pgt_cache(void) { }
@@ -75,4 +76,35 @@ static inline void check_pgt_cache(void) { }
#define kern_addr_valid(kaddr) (0)
#endif
+/*
+ * This is how much memory in addition to the memory covered up to
+ * and including _end we need mapped initially.
+ * We need:
+ * (KERNEL_IMAGE_SIZE/4096) / 1024 pages (worst case, non PAE)
+ * (KERNEL_IMAGE_SIZE/4096) / 512 + 4 pages (worst case for PAE)
+ *
+ * Modulo rounding, each megabyte assigned here requires a kilobyte of
+ * memory, which is currently unreclaimed.
+ *
+ * This should be a multiple of a page.
+ *
+ * KERNEL_IMAGE_SIZE should be greater than pa(_end)
+ * and small than max_low_pfn, otherwise will waste some page table entries
+ */
+#if PTRS_PER_PMD > 1
+#define PAGE_TABLE_SIZE(pages) (((pages) / PTRS_PER_PMD) + PTRS_PER_PGD)
+#else
+#define PAGE_TABLE_SIZE(pages) ((pages) / PTRS_PER_PGD)
+#endif
+
+/*
+ * Number of possible pages in the lowmem region.
+ *
+ * We shift 2 by 31 instead of 1 by 32 to the left in order to avoid a
+ * gas warning about overflowing shift count when gas has been compiled
+ * with only a host target support using a 32-bit type for internal
+ * representation.
+ */
+#define LOWMEM_PAGES 2<<31) - __PAGE_OFFSET) >> PAGE_SHIFT))
+
#endif /* _ASM_X86_PGTABLE_32_H */
diff --git a/arch/x86/kernel/head32.c b/arch/x86/kernel/head32.c
index f16c55b..e5fb436 100644
--- a/arch/x86/kernel/head32.c
+++ b/arch/x86/kernel/head32.c
@@ -49,3 +49,65 @@ asmlinkage __visible void __init i386_start_kernel(void)
start_kernel();
}
+
+/*
+ * Initialize page tables. This creates a PDE and a set of page
+ * tables, which are located immediately beyond __brk_base. The variable
+ * _brk_end is set up to point to the first "safe" location.
+ * Mappings are created both at virtual address 0 (identity mapping)
+ * and PAGE_OFFSET for up to _end.
+ *
+ * In PAE mode initial_page_table is statically defined to contain
+ * enough entries to cover the VMSPLIT option (that is the top 1, 2 or 3
+ * entries). The identity mapping is handled by pointing two PGD entries
+ * to the first kernel PMD. Note the upper half of each PMD or PTE are
+ * always zero at this stage.
+ */
+void __init mk_early_pgtbl_32(void)
+{
+#ifdef __pa
+#undef __pa
+#endif
+#define __pa(x) ((unsigned long)(x) - PAGE_OFFSET)
+ pte_t pte, *ptep;
+ int i;
+ unsigned long *ptr;
+ /* Enough space to fit pagetables for the low memory linear map */
+ const unsigned long limit = __pa(_end) +
+ (PAGE_TABLE_SIZE(LOWMEM_PAGES) << PAGE_SHIFT);
+#ifdef CONFIG_X86_PAE
+ pmd_t pl2, *pl2p = (pmd_t *)__pa(initial_pg_pmd);
+#define SET_PL2(pl2, val){ (pl2).pmd = (val); }
+#else
+ pgd_t pl2, *pl2p = (pgd_t *)__pa(initial_page_table);
+#define SET_PL2(pl2, val) { (pl2).pgd = (val); }
+#endif
+
+ ptep = (pte_t *)__pa(__brk_base);
+ pte.pte = PTE_IDENT_ATTR;
+
+ while ((pte.pte & PTE_PFN_MASK) < limit) {
+
+ SET_PL2(pl2, (unsigned long)ptep | PDE_IDENT_ATTR);
+ *pl2p = pl2;
+#ifndef CONFIG_X86_PAE
+ /* Kernel PDE entry */
+ *(pl2p + ((PAGE_OFFSET >> PGDIR_SHIFT))) = pl2;
+#endif
+ for (i = 0; i < PTRS_PER_PTE; i++) {
+ *ptep = pte;
+ pte.pte += PAGE_SIZE;
+ ptep++;
+ }
+
+ pl2p++;
+ }
+
+ ptr = (unsigned long *)__pa(&max_pfn_mapped);
+ /* Can't use pte_pfn() since it's a call with CONFIG_PARAVIRT */
+ *ptr = (pte.pte & PTE_PFN_MASK) >> PAGE_SHIFT;
+
+ ptr = (unsigned long *)__pa(&_brk_end);
+ *ptr = (unsigned long)ptep + PAGE_OFFSET;
+}
+
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index 2dabea4..dc6b030 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -24,6 +24,7 @@
#incl
[Xen-devel] [PATCH] docs: turn links to docs/* into absolute path
From a user point of view, when reading things like "See docs/misc/txt" in a man page, it is not obvious to find the location of that file. Use $docdir to turn these into absolute paths. Signed-off-by: Cédric Bosdonnat --- docs/man/xl.cfg.pod.5.in | 16 docs/man/xl.pod.1.in | 2 +- m4/paths.m4 | 3 +++ 3 files changed, 12 insertions(+), 9 deletions(-) diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in index 21b58bc21e..29a012b794 100644 --- a/docs/man/xl.cfg.pod.5.in +++ b/docs/man/xl.cfg.pod.5.in @@ -185,7 +185,7 @@ host cpus and memory. In that case, the soft affinity of all the vcpus of the domain will be set to the pcpus belonging to the NUMA nodes chosen during placement. -For more details, see F. +For more details, see L. =back @@ -480,18 +480,18 @@ devices which the guest will contain. Specifies the disks (both emulated disks and Xen virtual block devices) which are to be provided to the guest, and what objects on -the host they should map to. See F. +the host they should map to. See L. =item B Specifies the networking provision (both emulated network adapters, and Xen virtual interfaces) to provided to the guest. See -F. +L. =item B Specifies the virtual trusted platform module to be -provided to the guest. Please see F +provided to the guest. Please see L for more details. Each B is a comma-separated list of C @@ -604,7 +604,7 @@ Specifies the virtual channels to be provided to the guest. A channel is a low-bandwidth, bidirectional byte stream, which resembles a serial link. Typical uses for channels include transmitting VM configuration after boot and signalling to in-guest agents. Please see -F for more details. +L for more details. Each B is a comma-separated list of C settings. Leading and trailing whitespace is ignored in both KEY and @@ -1464,7 +1464,7 @@ determined in the similar way to that of B TSC mode. =back -Please see F for more information on this option. +Please see L for more information on this option. =item B @@ -1895,7 +1895,7 @@ specified, enabling the use of XenServer PV drivers in the guest. =back This parameter only takes effect when device_model_version=qemu-xen. -See F for more information. +See L for more information. =back @@ -2034,7 +2034,7 @@ natively or via hardware backwards compatibility support. =item F -=item F +=item L =back diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in index 8e2aa5b5af..22f24607a1 100644 --- a/docs/man/xl.pod.1.in +++ b/docs/man/xl.pod.1.in @@ -1354,7 +1354,7 @@ How the device should be presented to the guest domain; for example "hdc". the target path in the backend domain (usually domain 0) to be exported; Can be a block device or a file etc. See B in -F. +L. =back diff --git a/m4/paths.m4 b/m4/paths.m4 index 722a8aa4a9..9a6ede4a11 100644 --- a/m4/paths.m4 +++ b/m4/paths.m4 @@ -140,4 +140,7 @@ AC_SUBST(XEN_PAGING_DIR) XEN_DUMP_DIR=$xen_dumpdir_path AC_SUBST(XEN_DUMP_DIR) + +XEN_DOC_DIR=$docdir +AC_SUBST(XEN_DOC_DIR) ]) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Future support of 5-level paging in Xen
On 08/12/16 16:46, Juergen Gross wrote: > The first round of (very preliminary) patches for supporting the new > 5-level paging of future Intel x86 processors [1] has been posted to > lkml: > > https://lkml.org/lkml/2016/12/8/378 > > An explicit note has been added: "CONFIG_XEN is broken." and > "I would appreciate help with the code." > > I think we should start a discussion what we want to do in future: > > - are we going to support 5-level paging for PV guests? > - do we limit 5-level paging to PVH and HVM? The 64bit PV ABI has 16TB of virtual address space just above the upper 48-canonical boundary. Were Xen to support 5-level PV guests, we'd either leave the PV guest kernel with exactly the same amount of higher half space as it currently has, or we'd have to recompile Xen as properly position-independent and use a different virtual range in different paging mode. Another pain point is the quantity of virtual address space handed away in the ABI. We currently had 97% of the virtual address space away to 64bit PV guests, and frankly this is too much. This is the wrong way around when Xen has more management to do than the guest. If we were to go along the 5-level PV guests route, I will insist that there is a rather more even split of virtual address space baked into the ABI. However, a big question is whether any of this effort is worth doing, in the light of PVH. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH VERY RFC 3/5] tools/fuzz: introduce x86 instruction emulator target
On Thu, Dec 08, 2016 at 08:03:04AM -0700, Jan Beulich wrote:
[...]
>
> > +static int emul_read_cr(
> > +unsigned int reg,
> > +unsigned long *val,
> > +struct x86_emulate_ctxt *ctxt)
> > +{
> > +/* Fake just enough state for the emulator's _get_fpu() to be happy. */
> > +switch ( reg )
> > +{
> > +case 0:
> > +*val = 0x0001; /* PE */
> > +return X86EMUL_OKAY;
> > +
> > +case 4:
> > +/* OSFXSR, OSXMMEXCPT, and maybe OSXSAVE */
> > +*val = 0x0600 | (cpu_has_xsave ? 0x0004 : 0);
> > +return X86EMUL_OKAY;
> > +}
> > +
> > +return X86EMUL_UNHANDLEABLE;
> > +}
>
> Looks suspiciously similar to existing code. We may want to share
> such stuff, to avoid having to update it in multiple places.
>
Share with what? Do you mean the real emulator code?
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libelf: Fix div0 issues in elf_{shdr, phdr}_count()
Ian Jackson writes ("Re: [PATCH] libelf: Fix div0 issues in
elf_{shdr,phdr}_count()"):
> Admittedly the rule about iteration count is not so easy to remember,
> and I had failed to anticipate that someone would introduce division.
> But both of those kind of bugs are denial of service, rather than
> privilege escalation.
>
> Having stared at the commit message of a01b6d46 and at the
> pre-a01b6d46 code, I still don't understand what motivated the
> changes.
Jan and I had a conversation on irc.
Part of the motivation for a01b6d4 was the anomaly which is the
difference between the implementations of elf_phdr_size and
elf_shdr_size.
This was introduced in 39bf7b9d0ae5 "libelf: check loops for running
away". That was part of the XSA-55 patchset.
Looking at the commit message I was concerned that the phdr and shdr
counts might be excessive, and that libelf might get stuck in a loop
with an unreasonably high iteration count.
I appear to have attempted to mitigate this by:
(a) in the case of shdrs, by using elf_access_ok inside each
loop, on the principle that an out of control loop count
would walk off the end of the image and stop;
(b) in the case of phdrs, making an explicit limit of
(image size) / sizeof(phdr). NB that sizeof(phdr) is not the
actual size of phdrs; for a valid ELF it is a minimum. This
is fine because we're computing a backstop, which does not
have to be entirely accurate.
I now see that (a) is ineffective because the image can specify its
own stride for the iteration (the header size). If it specifies a
stride of zero, the maximum count is unbounded.
However, both count values are actually 16-bit. So there is already a
limit. The extra code in elf_phdr_size is not necessary.
IMO this near-miss demonstrates that a more robust approach is
required to bounding loops in libelf.
A possibility would be to introduce
bool elf_iter_cont(struct elf_binary *elf, size_t copysz);
and using it in every for(;;) in libelf. It would keep a counter (set
to zero in libelf) and abandon the processing if the total of all the
copysz values passed was "too large". (copysz would be bounded below
by 1, so that it is safe to pass a size from the ELF.)
Then
- for ( i = 0; i < elf_shdr_count(elf); i++ )
+ for ( i = 0; elf_iter_cont(elf, e_shentsize)
+ && i < elf_shdr_count(elf); i++ )
An alternative would be to decorate every loop with a comment
explaining why the loop does reasonably-bounded work. I'm not sure
whether this, or my more sophisticated suggestion, will find favour.
In any case, the max calculation in elf_phdr_size is unnecessary for
security, and has no purpose related to functionality, and can be
deleted.
Another part of the motivation for a01b6d4 is to produce better
messages for certain malformed ELFs. There has been no assertion that
any such ELFs (ie ELFs which would fail these new checks) actually
exist or have caused trouble for anyone.
I think that it is a bad idea to add unnecessary checking to libelf.
libelf is a format parser on a security boundary. Despite attempts to
provide a safe dialect to write in, every piece of code in libelf
risks security problems.
If libelf "accepts" some malformed image, and constructs a mess in the
guest memory space, then that is unfortunate. But it is not a big
problem. The guest will probably crash or go wrong, but that is not a
problem for the host.
If someone is faced with fallout from a malformed ELF, they would
hopefully try use an object file inspector like objdump on the loaded
image. That would reveal the problem. (And of course ELFs are mostly
generated by a fairly small ecosystem of toolchain programs.)
Also, this has demonstrated that the design principles underlying the
safety of libelf are not properly understood. IIRC they were
explained in the XSA-55 00/ patch, but that's not sufficient.
So I would prefer to:
Revert all of a01b6d4.
Delete the header count check in elf_phdr_count and replace it with a
compile-time assertion, in elf_phdr_count and in elf_shdr_count, that
sizeof the count field is <= 2. (This may need a new macro
ELF_HANDLE_FIELD_SIZEOF implemented in terms of
ELF__HANDLE_FIELD_TYPE.)
Add a comment near the top of libelf.h explaining the rules for
programming inside libelf, to include:
* Arithmetic on signed values is forbidden
* Use of actual pointers into the ELF is forbidden
* Division by non-constant values is forbidden
* All loops must ensure that they have a reasonably low
iteration count
* Code (including ELF format sanity checks) which is necessary
neither for safety nor for correct processing of correct files
should not be added to libelf. It is not libelf's role to
be an ELF validator.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
