[Xen-devel] [freebsd-master test] 139084: all pass - PUSHED
flight 139084 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/139084/ Perfect :-) All tests in this flight passed as required version targeted for testing: freebsd 6418500c9f9c91a698564bbc264c513461611472 baseline version: freebsd 163feb2e45cd088e65da1ff395dc3293065a4603 Last test of basis 139016 2019-07-15 09:19:57 Z2 days Testing same since 139084 2019-07-17 09:19:38 Z0 days1 attempts People who touched revisions under test: alc avg brooks chuck cy ian imp jhb jhibbits kevlo kib manu markj mckusick olivier oshogbo sbruno tmunro tuexen vangyzen jobs: build-amd64-freebsd-againpass build-amd64-freebsd pass build-amd64-xen-freebsd 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 : To xenbits.xen.org:/home/xen/git/freebsd.git 163feb2e45c..6418500c9f9 6418500c9f9c91a698564bbc264c513461611472 -> tested/master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 139075: regressions - FAIL
flight 139075 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/139075/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail REGR. vs. 138977 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 138977 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 138977 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 138977 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 138977 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 138977 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: qemuu0b18cfb8f1828c905139b54c8644b0d8f4aad879 baseline version: qemuu1316b1ddc8a05e418c8134243f8bff8cccbbccb1 Last test of basis 138977 2019-07-14 03:43:52 Z4 days Failing since139014 2019-07-15 09:06:23 Z2 days3 attempts Testing same since 139075 2019-07-17 04:15:49 Z1 days1 attempts People who touched revisions under test: Aleksandar Markovic Alex Bennée Alex Williamson Andrey Shinkevich Christian Borntraeger Christophe de Dinechin Christophe Lyon Cornelia Huck David Engraf Dr. David Alan Gilbert
Re: [Xen-devel] [PATCH v8 4/5] x86/paravirt: Remove const mark from x86_hyper_xen_hvm variable
On 17.07.19 19:22, Joe Perches wrote:
On Wed, 2019-07-17 at 08:49 +0200, Juergen Gross wrote:
On 17.07.19 08:46, Joe Perches wrote:
On Tue, 2019-07-16 at 12:26 +0800, Zhenzhong Duan wrote:
.. as "nopv" support needs it to be changeable at boot up stage.
Checkpatch reports warning, so move variable declarations from
hypervisor.c to hypervisor.h
[]
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
[]
@@ -259,7 +259,7 @@ static __init void xen_hvm_guest_late_init(void)
#endif
}
-const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = {
+struct hypervisor_x86 x86_hyper_xen_hvm __initdata = {
static?
It is being referenced from arch/x86/kernel/cpu/hypervisor.c
But wasn't it also removed from the list of externs?
Rereading the .h file, no it wasn't. I missed that.
Perhaps the extern list could be reordered to move this
x86_hyper_xen_hvm to be next to x86_hyper_type.
I also suggest that "extern bool nopv" might be a bit
non-specific and could use a longer identifier.
You are a little bit late. It has been this way since V5 of the series
posted on July 3rd.
I have pushed the series to my tree already and I'm about to send the
pull request.
Followup patches welcome. :-)
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 139076: regressions - FAIL
flight 139076 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/139076/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs. 139037 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 139037 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 139037 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass version targeted for testing: libvirt 898821cce881343faea38f37c789a1e8e54494f6 baseline version: libvirt f58bcb80b2ca1791acd5ec0255297a44aa9d4dbe Last test of basis 139037 2019-07-16 04:18:53 Z1 days Testing same since 139076 2019-07-17 04:18:47 Z0 days1 attempts People who touched revisions under test: Ján Tomko Michal Privoznik Peter Krempa jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit 898821cce881343faea38f37c789a1e8e54494f6 Author: Ján Tomko Date: Tue Jul 16 12:31:03 2019
[Xen-devel] [xen-unstable test] 139069: regressions - FAIL
flight 139069 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/139069/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 139032 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 139032 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 139032 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 139032 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 139032 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 139032 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 139032 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 139032 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 139032 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 139032 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 08b084ab48738040e34032ffb42387d88619bf1b baseline version: xen 38eeb3864de40aa568c48f9f26271c141c62b50b Last test of basis 139032 2019-07-16
Re: [Xen-devel] [PATCH v5 6/6] tools/libxc: add wrapper for PHYSDEVOP_msi_control
On Wed, Jul 17, 2019 at 12:21:58PM +0200, Roger Pau Monné wrote: > On Wed, Jul 17, 2019 at 03:00:44AM +0200, Marek Marczykowski-Górecki wrote: > > Add libxc wrapper for PHYSDEVOP_msi_control introduced in previous > > commit. > > > > Signed-off-by: Marek Marczykowski-Górecki > > LGTM, albeit I find the usage of int instead of unsigned int for the > SBDF kind of weird, but it's inline with the other functions, so I > guess there's a reason for it? Yes, it was based on looking at other places. But I don't know if there is any specific reason for it. > I assume this will be used by an upcoming QEMU patch? Yes. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 5/6] xen/x86: add PHYSDEVOP_msi_control
On Wed, Jul 17, 2019 at 12:18:43PM +0200, Roger Pau Monné wrote:
> On Wed, Jul 17, 2019 at 03:00:43AM +0200, Marek Marczykowski-Górecki wrote:
> > Allow device model running in stubdomain to enable/disable MSI(-X),
> > bypassing pciback. While pciback is still used to access config space
> > from within stubdomain, it refuse to write to
> > PCI_MSI_FLAGS_ENABLE/PCI_MSIX_FLAGS_ENABLE in non-permissive mode. Which
> > is the right thing to do for PV domain (the main use case for pciback),
> > as PV domain should use XEN_PCI_OP_* commands for that. Unfortunately
> > those commands are not good for stubdomain use, as they configure MSI in
> > dom0's kernel too, which should not happen for HVM domain.
> >
> > This new physdevop is allowed only for stubdomain controlling the domain
> > which own the device.
>
> I think I'm missing that part, is this maybe done by the XSM stuff?
Yes, specifically xsm_msi_control(XSM_DM_PRIV, pdev->domain, ...) call.
XSM_DM_PRIV allows call if src->is_privileged, or if src->target ==
target. Note the target being owner of the device here.
> >
> > Signed-off-by: Marek Marczykowski-Górecki
> > ---
> > Changes in v3:
> > - new patch
> > Changes in v4:
> > - adjust code style
> > - s/msi_msix/msi/
> > - add msi_set_enable XSM hook
> > - flatten struct physdev_msi_set_enable
> > - add to include/xlat.lst
> > Changes in v5:
> > - rename to PHYSDEVOP_msi_control
> > - combine "mode" and "enable" into "flags"
> > - refuse to enable both MSI and MSI-X, and also to enable MSI(-X) on
> >incapable device
> > - disable/enable INTx when enabling/disabling MSI (?)
>
> You don't enable INTx when MSI is disabled.
Ah, indeed. When I look for similar code in Xen elsewhere, I found
__pci_disable_msi() has extra conditions for pci_intx(dev, true):
if ( entry->irq > 0 && !(irq_to_desc(entry->irq)->status & IRQ_GUEST) )
pci_intx(dev, true);
Should this be mirrored there too? Isn't IRQ_GUEST always set in case of
passthrough to HVM (the case this patch care)?
> > - refuse if !use_msi
> > - adjust flask hook to make more sense (require "setup" access on
> >device, not on domain)
> > - rebase on master
> >
> > I'm not sure if XSM part is correct, compile-tested only, as I'm not
> > sure how to set the policy.
>
> I'm also not familiar with XSM, so I will have to defer to Daniel on
> this one.
>
> > ---
> > xen/arch/x86/msi.c | 42 ++-
> > xen/arch/x86/physdev.c | 25 ++-
> > xen/arch/x86/x86_64/physdev.c | 4 +++-
> > xen/include/asm-x86/msi.h | 1 +-
> > xen/include/public/physdev.h| 16 +++-
> > xen/include/xlat.lst| 1 +-
> > xen/include/xsm/dummy.h | 7 +-
> > xen/include/xsm/xsm.h | 6 -
> > xen/xsm/dummy.c | 1 +-
> > xen/xsm/flask/hooks.c | 24 +-
> > xen/xsm/flask/policy/access_vectors | 1 +-
> > 11 files changed, 128 insertions(+)
> >
> > diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
> > index 89e6116..fca1d04 100644
> > --- a/xen/arch/x86/msi.c
> > +++ b/xen/arch/x86/msi.c
> > @@ -1475,6 +1475,48 @@ int pci_restore_msi_state(struct pci_dev *pdev)
> > return 0;
> > }
> >
> > +int msi_control(struct pci_dev *pdev, bool msix, bool enable)
> > +{
> > +int ret;
> > +struct msi_desc *old_desc;
> > +
> > +if ( !use_msi )
> > +return -EOPNOTSUPP;
> > +
> > +ret = xsm_msi_control(XSM_DM_PRIV, pdev->domain, pdev->sbdf.sbdf,
> > msix, enable);
> > +if ( ret )
> > +return ret;
> > +
> > +if ( msix )
> > +{
> > +if ( !pdev->msix )
> > +return -ENODEV;
> > +old_desc = find_msi_entry(pdev, -1, PCI_CAP_ID_MSI);
> > +if ( old_desc )
> > +return -EBUSY;
> > +if ( enable )
> > +pci_intx(pdev, false);
> > +msix_set_enable(pdev, enable);
> > +}
> > +else
> > +{
> > +if ( !pci_find_cap_offset(pdev->seg,
> > + pdev->bus,
> > + PCI_SLOT(pdev->devfn),
> > + PCI_FUNC(pdev->devfn),
> > + PCI_CAP_ID_MSI) )
> > +return -ENODEV;
> > +old_desc = find_msi_entry(pdev, -1, PCI_CAP_ID_MSIX);
> > +if ( old_desc )
> > +return -EBUSY;
> > +if ( enable )
> > +pci_intx(pdev, false);
> > +msi_set_enable(pdev, enable);
> > +}
>
> I think you could just do:
>
> unsigned int cap = msix ? PCI_CAP_ID_MSIX : PCI_CAP_ID_MSI;
>
> [...]
>
> if ( !pci_find_cap_offset(pdev->seg,
> pdev->bus,
> PCI_SLOT(pdev->devfn),
> PCI_FUNC(pdev->devfn), cap) )
> return -ENODEV;
>
> old_desc = find_msi_entry(pdev, -1, cap);
> if ( old_desc )
> return -EBUSY;
[Xen-devel] [linux-linus test] 139068: regressions - FAIL
flight 139068 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/139068/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-i386-pvgrub 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-libvirt 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-xl-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-examine 8 reboot fail REGR. vs. 133580 test-amd64-amd64-examine 8 reboot fail REGR. vs. 133580 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-qemuu-nested-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-xl 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-amd64-pvgrub 7 xen-bootfail REGR. vs. 133580 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 xen-bootfail REGR. vs. 133580 test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 133580 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-xl-credit2 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 133580 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 133580 test-amd64-amd64-libvirt-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-xl-pvhv2-amd 7 xen-bootfail REGR. vs. 133580 test-amd64-amd64-qemuu-nested-amd 7 xen-bootfail REGR. vs. 133580 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 133580 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 133580 test-amd64-amd64-libvirt-vhd 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-bootfail REGR. vs. 133580 test-amd64-amd64-xl-credit1 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 133580 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 133580
[Xen-devel] [ovmf test] 139072: all pass - PUSHED
flight 139072 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/139072/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 35e242b698cdc6205e99a6d6a188bf27fecf9fb4 baseline version: ovmf 51dd408ae1022e5c9378492451a62b38d5b101c5 Last test of basis 139038 2019-07-16 04:39:06 Z1 days Testing same since 139072 2019-07-17 02:48:38 Z0 days1 attempts People who touched revisions under test: Laszlo Ersek Star Zeng Zhichao Gao jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 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 : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 51dd408ae1..35e242b698 35e242b698cdc6205e99a6d6a188bf27fecf9fb4 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xen/arm: Switch OMAP5 secondary cores into hyp mode
Hi, > > Well, Xen has been supported the omap5 for quite a while. So there are > two possibilities regarding the current SMP code: > 1) It is totally broken and therefore never worked on any omap5 > platform. > 2) It works but with maybe modification in U-boot. > > Looking at the mailing list archive and wiki, I believe 2) is closer to > the current reality. So this raise the question whether your patch will > break any existing setup. > > Don't get me wrong, the code is perfectly fine as, to the best of my > knowledge, it matches what Linux does. However, I would like to see an > analysis written in the commit message regarding what's going to happen > for any existing setup. > > Cheers, > I hoped to hear more opinions because I don't really understand where to start - I don't know much about how xen and Linux worked with omap5. -- Regards, Denis Obrezkov ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 1/5] x86/mem_sharing: reorder when pages are unlocked and released
Calling _put_page_type while also holding the page_lock
for that page can cause a deadlock.
The comment being dropped is incorrect since it's now out-of-date.
Signed-off-by: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Wei Liu
Cc: Roger Pau Monne
---
v6: rebase on staging
v5: BUG_ON early before releasing references
---
xen/arch/x86/mm/mem_sharing.c | 40 +++
1 file changed, 12 insertions(+), 28 deletions(-)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 58d9157fa8..6c033d1488 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -648,10 +648,6 @@ static int page_make_private(struct domain *d, struct
page_info *page)
return -EBUSY;
}
-/* We can only change the type if count is one */
-/* Because we are locking pages individually, we need to drop
- * the lock here, while the page is typed. We cannot risk the
- * race of page_unlock and then put_page_type. */
expected_type = (PGT_shared_page | PGT_validated | PGT_locked | 2);
if ( page->u.inuse.type_info != expected_type )
{
@@ -660,12 +656,11 @@ static int page_make_private(struct domain *d, struct
page_info *page)
return -EEXIST;
}
+mem_sharing_page_unlock(page);
+
/* Drop the final typecount */
put_page_and_type(page);
-/* Now that we've dropped the type, we can unlock */
-mem_sharing_page_unlock(page);
-
/* Change the owner */
ASSERT(page_get_owner(page) == dom_cow);
page_set_owner(page, d);
@@ -900,6 +895,7 @@ static int share_pages(struct domain *sd, gfn_t sgfn,
shr_handle_t sh,
p2m_type_t smfn_type, cmfn_type;
struct two_gfns tg;
struct rmap_iterator ri;
+unsigned long put_count = 0;
get_two_gfns(sd, sgfn, _type, NULL, ,
cd, cgfn, _type, NULL, , 0, );
@@ -964,15 +960,6 @@ static int share_pages(struct domain *sd, gfn_t sgfn,
shr_handle_t sh,
goto err_out;
}
-/* Acquire an extra reference, for the freeing below to be safe. */
-if ( !get_page(cpage, dom_cow) )
-{
-ret = -EOVERFLOW;
-mem_sharing_page_unlock(secondpg);
-mem_sharing_page_unlock(firstpg);
-goto err_out;
-}
-
/* Merge the lists together */
rmap_seed_iterator(cpage, );
while ( (gfn = rmap_iterate(cpage, )) != NULL)
@@ -984,13 +971,14 @@ static int share_pages(struct domain *sd, gfn_t sgfn,
shr_handle_t sh,
* Don't change the type of rmap for the client page. */
rmap_del(gfn, cpage, 0);
rmap_add(gfn, spage);
-put_page_and_type(cpage);
+put_count++;
d = get_domain_by_id(gfn->domain);
BUG_ON(!d);
BUG_ON(set_shared_p2m_entry(d, gfn->gfn, smfn));
put_domain(d);
}
ASSERT(list_empty(>sharing->gfns));
+BUG_ON(!put_count);
/* Clear the rest of the shared state */
page_sharing_dispose(cpage);
@@ -1001,7 +989,9 @@ static int share_pages(struct domain *sd, gfn_t sgfn,
shr_handle_t sh,
/* Free the client page */
put_page_alloc_ref(cpage);
-put_page(cpage);
+
+while ( put_count-- )
+put_page_and_type(cpage);
/* We managed to free a domain page. */
atomic_dec(_shared_mfns);
@@ -1165,19 +1155,13 @@ int __mem_sharing_unshare_page(struct domain *d,
{
if ( !last_gfn )
mem_sharing_gfn_destroy(page, d, gfn_info);
-put_page_and_type(page);
+
mem_sharing_page_unlock(page);
+
if ( last_gfn )
-{
-if ( !get_page(page, dom_cow) )
-{
-put_gfn(d, gfn);
-domain_crash(d);
-return -EOVERFLOW;
-}
put_page_alloc_ref(page);
-put_page(page);
-}
+
+put_page_and_type(page);
put_gfn(d, gfn);
return 0;
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 5/5] x86/mem_sharing: style cleanup
No functional change
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 265 ++
1 file changed, 138 insertions(+), 127 deletions(-)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index a5fe89e339..aaf8c2f2c8 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -42,7 +42,8 @@
static shr_handle_t next_handle = 1;
-typedef struct pg_lock_data {
+typedef struct pg_lock_data
+{
int mm_unlock_level;
unsigned short recurse_count;
} pg_lock_data_t;
@@ -88,8 +89,8 @@ static inline void page_sharing_dispose(struct page_info
*page)
{
/* Unlikely given our thresholds, but we should be careful. */
if ( unlikely(RMAP_USES_HASHTAB(page)) )
-free_xenheap_pages(page->sharing->hash_table.bucket,
-RMAP_HASHTAB_ORDER);
+free_xenheap_pages(page->sharing->hash_table.bucket,
+ RMAP_HASHTAB_ORDER);
spin_lock(_audit_lock);
list_del_rcu(>sharing->entry);
@@ -105,8 +106,8 @@ static inline void page_sharing_dispose(struct page_info
*page)
{
/* Unlikely given our thresholds, but we should be careful. */
if ( unlikely(RMAP_USES_HASHTAB(page)) )
-free_xenheap_pages(page->sharing->hash_table.bucket,
-RMAP_HASHTAB_ORDER);
+free_xenheap_pages(page->sharing->hash_table.bucket,
+ RMAP_HASHTAB_ORDER);
xfree(page->sharing);
}
@@ -136,8 +137,8 @@ static inline bool _page_lock(struct page_info *page)
cpu_relax();
nx = x + (1 | PGT_locked);
if ( !(x & PGT_validated) ||
- !(x & PGT_count_mask) ||
- !(nx & PGT_count_mask) )
+!(x & PGT_count_mask) ||
+!(nx & PGT_count_mask) )
return false;
} while ( cmpxchg(>u.inuse.type_info, x, nx) != x );
@@ -168,7 +169,7 @@ static inline bool mem_sharing_page_lock(struct page_info
*pg)
if ( rc )
{
preempt_disable();
-page_sharing_mm_post_lock(>mm_unlock_level,
+page_sharing_mm_post_lock(>mm_unlock_level,
>recurse_count);
}
return rc;
@@ -178,7 +179,7 @@ static inline void mem_sharing_page_unlock(struct page_info
*pg)
{
pg_lock_data_t *pld = &(this_cpu(__pld));
-page_sharing_mm_unlock(pld->mm_unlock_level,
+page_sharing_mm_unlock(pld->mm_unlock_level,
>recurse_count);
preempt_enable();
_page_unlock(pg);
@@ -186,19 +187,18 @@ static inline void mem_sharing_page_unlock(struct
page_info *pg)
static inline shr_handle_t get_next_handle(void)
{
-/* Get the next handle get_page style */
+/* Get the next handle get_page style */
uint64_t x, y = next_handle;
do {
x = y;
-}
-while ( (y = cmpxchg(_handle, x, x + 1)) != x );
+} while ( (y = cmpxchg(_handle, x, x + 1)) != x );
return x + 1;
}
#define mem_sharing_enabled(d) \
(is_hvm_domain(d) && (d)->arch.hvm.mem_sharing_enabled)
-static atomic_t nr_saved_mfns = ATOMIC_INIT(0);
+static atomic_t nr_saved_mfns = ATOMIC_INIT(0);
static atomic_t nr_shared_mfns = ATOMIC_INIT(0);
/** Reverse map **/
@@ -210,7 +210,7 @@ static atomic_t nr_shared_mfns = ATOMIC_INIT(0);
typedef struct gfn_info
{
unsigned long gfn;
-domid_t domain;
+domid_t domain;
struct list_head list;
} gfn_info_t;
@@ -225,7 +225,7 @@ rmap_init(struct page_info *page)
#define HASH(domain, gfn) \
(((gfn) + (domain)) % RMAP_HASHTAB_SIZE)
-/* Conversions. Tuned by the thresholds. Should only happen twice
+/* Conversions. Tuned by the thresholds. Should only happen twice
* (once each) during the lifetime of a shared page */
static inline int
rmap_list_to_hash_table(struct page_info *page)
@@ -288,13 +288,13 @@ rmap_count(struct page_info *pg)
}
/* The page type count is always decreased after removing from the rmap.
- * Use a convert flag to avoid mutating the rmap if in the middle of an
+ * Use a convert flag to avoid mutating the rmap if in the middle of an
* iterator, or if the page will be soon destroyed anyways. */
static inline void
rmap_del(gfn_info_t *gfn_info, struct page_info *page, int convert)
{
if ( RMAP_USES_HASHTAB(page) && convert &&
- (rmap_count(page) <= RMAP_LIGHT_SHARED_PAGE) )
+(rmap_count(page) <= RMAP_LIGHT_SHARED_PAGE) )
rmap_hash_table_to_list(page);
/* Regardless of rmap type, same removal operation */
@@ -308,30 +308,30 @@ rmap_add(gfn_info_t *gfn_info, struct page_info *page)
struct list_head *head;
if ( !RMAP_USES_HASHTAB(page) &&
- (rmap_count(page) >= RMAP_HEAVY_SHARED_PAGE) )
+(rmap_count(page) >= RMAP_HEAVY_SHARED_PAGE) )
/* The conversion may fail with ENOMEM. We'll be less efficient,
* but no reason to panic. */
[Xen-devel] [PATCH v6 4/5] x86/mem_sharing: compile mem_sharing subsystem only when kconfig is enabled
Disable it by default as it is only an experimental subsystem. Signed-off-by: Tamas K Lengyel Acked-by: Daniel De Graaf Acked-by: Razvan Cojocaru Acked-by: Jan Beulich Cc: Andrew Cooper Cc: Wei Liu Cc: Roger Pau Monne Cc: George Dunlap Cc: Ian Jackson Cc: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: George Dunlap v6: rebase on staging --- xen/arch/x86/Kconfig | 6 +- xen/arch/x86/domain.c | 2 ++ xen/arch/x86/domctl.c | 2 ++ xen/arch/x86/mm/Makefile | 2 +- xen/arch/x86/x86_64/compat/mm.c | 2 ++ xen/arch/x86/x86_64/mm.c | 2 ++ xen/common/Kconfig| 3 --- xen/common/domain.c | 6 +++--- xen/common/grant_table.c | 2 +- xen/common/memory.c | 2 +- xen/common/vm_event.c | 6 +++--- xen/include/asm-x86/mem_sharing.h | 28 xen/include/asm-x86/mm.h | 3 +++ xen/include/xen/mm.h | 2 +- xen/include/xen/sched.h | 2 +- xen/include/xsm/dummy.h | 2 +- xen/include/xsm/xsm.h | 4 ++-- xen/xsm/dummy.c | 2 +- xen/xsm/flask/hooks.c | 4 ++-- 19 files changed, 61 insertions(+), 21 deletions(-) diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index f502d765ba..288dc6c042 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -18,7 +18,6 @@ config X86 select HAS_KEXEC select MEM_ACCESS_ALWAYS_ON select HAS_MEM_PAGING - select HAS_MEM_SHARING select HAS_NS16550 select HAS_PASSTHROUGH select HAS_PCI @@ -199,6 +198,11 @@ config PV_SHIM_EXCLUSIVE firmware, and will not function correctly in other scenarios. If unsure, say N. + +config MEM_SHARING + bool "Xen memory sharing support" if EXPERT = "y" + depends on HVM + endmenu source "common/Kconfig" diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index e791d86892..ea55160887 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -2095,6 +2095,7 @@ int domain_relinquish_resources(struct domain *d) d->arch.auto_unmask = 0; } +#ifdef CONFIG_MEM_SHARING PROGRESS(shared): if ( is_hvm_domain(d) ) @@ -2105,6 +2106,7 @@ int domain_relinquish_resources(struct domain *d) if ( ret ) return ret; } +#endif spin_lock(>page_alloc_lock); page_list_splice(>arch.relmem_list, >page_list); diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c index c827790202..2d45e5b8a8 100644 --- a/xen/arch/x86/domctl.c +++ b/xen/arch/x86/domctl.c @@ -1236,9 +1236,11 @@ long arch_do_domctl( break; } +#ifdef CONFIG_MEM_SHARING case XEN_DOMCTL_mem_sharing_op: ret = mem_sharing_domctl(d, >u.mem_sharing_op); break; +#endif #if P2M_AUDIT && defined(CONFIG_HVM) case XEN_DOMCTL_audit_p2m: diff --git a/xen/arch/x86/mm/Makefile b/xen/arch/x86/mm/Makefile index 5a17646f98..5010a29d6c 100644 --- a/xen/arch/x86/mm/Makefile +++ b/xen/arch/x86/mm/Makefile @@ -6,7 +6,7 @@ obj-$(CONFIG_HVM) += guest_walk_2.o guest_walk_3.o guest_walk_4.o obj-$(CONFIG_SHADOW_PAGING) += guest_walk_2.o guest_walk_3.o guest_walk_4.o obj-$(CONFIG_MEM_ACCESS) += mem_access.o obj-y += mem_paging.o -obj-y += mem_sharing.o +obj-$(CONFIG_MEM_SHARING) += mem_sharing.o obj-y += p2m.o p2m-pt.o obj-$(CONFIG_HVM) += p2m-ept.o p2m-pod.o obj-y += paging.o diff --git a/xen/arch/x86/x86_64/compat/mm.c b/xen/arch/x86/x86_64/compat/mm.c index 32410ed273..d4c6be3032 100644 --- a/xen/arch/x86/x86_64/compat/mm.c +++ b/xen/arch/x86/x86_64/compat/mm.c @@ -152,8 +152,10 @@ int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg) case XENMEM_paging_op: return mem_paging_memop(guest_handle_cast(arg, xen_mem_paging_op_t)); +#ifdef CONFIG_MEM_SHARING case XENMEM_sharing_op: return mem_sharing_memop(guest_handle_cast(arg, xen_mem_sharing_op_t)); +#endif default: rc = -ENOSYS; diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c index 899b883b2d..1919cae18b 100644 --- a/xen/arch/x86/x86_64/mm.c +++ b/xen/arch/x86/x86_64/mm.c @@ -993,8 +993,10 @@ long subarch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg) case XENMEM_paging_op: return mem_paging_memop(guest_handle_cast(arg, xen_mem_paging_op_t)); +#ifdef CONFIG_MEM_SHARING case XENMEM_sharing_op: return mem_sharing_memop(guest_handle_cast(arg, xen_mem_sharing_op_t)); +#endif default: rc = -ENOSYS; diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 912630a4fb..16829f6274 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -48,9 +48,6 @@ config MEM_ACCESS config HAS_MEM_PAGING bool -config HAS_MEM_SHARING - bool - config HAS_PDX bool diff --git
[Xen-devel] [PATCH v6 0/5] x86/mem_sharing: assorted fixes
This is an assorted series of fixes to the memory sharing subsystem. Patch 1-2: fix general brokeness of the system Patch 3-5: nice-to-haves & cleanups, could be applied independently from the rest of the patches in the series Tamas K Lengyel (5): x86/mem_sharing: reorder when pages are unlocked and released x86/mem_sharing: copy a page_lock version to be internal to memshr x86/mem_sharing: enable mem_share audit mode only in debug builds x86/mem_sharing: compile mem_sharing subsystem only when kconfig is enabled x86/mem_sharing: style cleanup xen/arch/x86/Kconfig | 6 +- xen/arch/x86/domain.c | 2 + xen/arch/x86/domctl.c | 2 + xen/arch/x86/mm/Makefile | 2 +- xen/arch/x86/mm/mem_sharing.c | 355 +- xen/arch/x86/x86_64/compat/mm.c | 2 + xen/arch/x86/x86_64/mm.c | 2 + xen/common/Kconfig| 3 - xen/common/domain.c | 6 +- xen/common/grant_table.c | 2 +- xen/common/memory.c | 2 +- xen/common/vm_event.c | 6 +- xen/include/asm-x86/mem_sharing.h | 32 +++ xen/include/asm-x86/mm.h | 18 +- xen/include/xen/mm.h | 2 +- xen/include/xen/sched.h | 2 +- xen/include/xsm/dummy.h | 2 +- xen/include/xsm/xsm.h | 4 +- xen/xsm/dummy.c | 2 +- xen/xsm/flask/hooks.c | 4 +- 20 files changed, 266 insertions(+), 190 deletions(-) -- 2.20.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 3/5] x86/mem_sharing: enable mem_share audit mode only in debug builds
Improves performance for release builds. Signed-off-by: Tamas K Lengyel Cc: Jan Beulich Cc: Andrew Cooper Cc: Wei Liu Cc: Roger Pau Monne --- v6: patch ping --- xen/include/asm-x86/mem_sharing.h | 4 1 file changed, 4 insertions(+) diff --git a/xen/include/asm-x86/mem_sharing.h b/xen/include/asm-x86/mem_sharing.h index 9f9f7e93e3..afd0c17292 100644 --- a/xen/include/asm-x86/mem_sharing.h +++ b/xen/include/asm-x86/mem_sharing.h @@ -25,7 +25,11 @@ #include /* Auditing of memory sharing code? */ +#ifndef NDEBUG #define MEM_SHARING_AUDIT 1 +#else +#define MEM_SHARING_AUDIT 0 +#endif typedef uint64_t shr_handle_t; -- 2.20.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 2/5] x86/mem_sharing: copy a page_lock version to be internal to memshr
Patch cf4b30dca0a "Add debug code to detect illegal page_lock and put_page_type
ordering" added extra sanity checking to page_lock/page_unlock for debug builds
with the assumption that no hypervisor path ever locks two pages at once.
This assumption doesn't hold during memory sharing so we copy a version of
page_lock/unlock to be used exclusively in the memory sharing subsystem
without the sanity checks.
Signed-off-by: Tamas K Lengyel
Acked-by: Jan Beulich
Cc: George Dunlap
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau Monne
---
v6: adjust comment according to Jan's suggestion
---
xen/arch/x86/mm/mem_sharing.c | 54 ---
xen/include/asm-x86/mm.h | 15 ++
2 files changed, 53 insertions(+), 16 deletions(-)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 6c033d1488..a5fe89e339 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -112,13 +112,59 @@ static inline void page_sharing_dispose(struct page_info
*page)
#endif /* MEM_SHARING_AUDIT */
-static inline int mem_sharing_page_lock(struct page_info *pg)
+/*
+ * Private implementations of page_lock/unlock to bypass PV-only
+ * sanity checks not applicable to mem-sharing.
+ *
+ * _page_lock is used in memory sharing to protect addition (share) and removal
+ * (unshare) of (gfn,domain) tupples to a list of gfn's that the shared page is
+ * currently backing.
+ * Nesting may happen when sharing (and locking) two pages.
+ * Deadlock is avoided by locking pages in increasing order.
+ * All memory sharing code paths take the p2m lock of the affected gfn before
+ * taking the lock for the underlying page. We enforce ordering between
page_lock
+ * and p2m_lock using an mm-locks.h construct.
+ *
+ * TODO: Investigate if PGT_validated is necessary.
+ */
+static inline bool _page_lock(struct page_info *page)
{
-int rc;
+unsigned long x, nx;
+
+do {
+while ( (x = page->u.inuse.type_info) & PGT_locked )
+cpu_relax();
+nx = x + (1 | PGT_locked);
+if ( !(x & PGT_validated) ||
+ !(x & PGT_count_mask) ||
+ !(nx & PGT_count_mask) )
+return false;
+} while ( cmpxchg(>u.inuse.type_info, x, nx) != x );
+
+return true;
+}
+
+static inline void _page_unlock(struct page_info *page)
+{
+unsigned long x, nx, y = page->u.inuse.type_info;
+
+do {
+x = y;
+ASSERT((x & PGT_count_mask) && (x & PGT_locked));
+
+nx = x - (1 | PGT_locked);
+/* We must not drop the last reference here. */
+ASSERT(nx & PGT_count_mask);
+} while ( (y = cmpxchg(>u.inuse.type_info, x, nx)) != x );
+}
+
+static inline bool mem_sharing_page_lock(struct page_info *pg)
+{
+bool rc;
pg_lock_data_t *pld = &(this_cpu(__pld));
page_sharing_mm_pre_lock();
-rc = page_lock(pg);
+rc = _page_lock(pg);
if ( rc )
{
preempt_disable();
@@ -135,7 +181,7 @@ static inline void mem_sharing_page_unlock(struct page_info
*pg)
page_sharing_mm_unlock(pld->mm_unlock_level,
>recurse_count);
preempt_enable();
-page_unlock(pg);
+_page_unlock(pg);
}
static inline shr_handle_t get_next_handle(void)
diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
index 6c14635270..087ad97351 100644
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -356,24 +356,15 @@ struct platform_bad_page {
const struct platform_bad_page *get_platform_badpages(unsigned int
*array_size);
/* Per page locks:
- * page_lock() is used for two purposes: pte serialization, and memory sharing.
+ * page_lock() is used for pte serialization.
*
* All users of page lock for pte serialization live in mm.c, use it
* to lock a page table page during pte updates, do not take other locks within
* the critical section delimited by page_lock/unlock, and perform no
* nesting.
*
- * All users of page lock for memory sharing live in mm/mem_sharing.c.
Page_lock
- * is used in memory sharing to protect addition (share) and removal (unshare)
- * of (gfn,domain) tupples to a list of gfn's that the shared page is currently
- * backing. Nesting may happen when sharing (and locking) two pages -- deadlock
- * is avoided by locking pages in increasing order.
- * All memory sharing code paths take the p2m lock of the affected gfn before
- * taking the lock for the underlying page. We enforce ordering between
page_lock
- * and p2m_lock using an mm-locks.h construct.
- *
- * These two users (pte serialization and memory sharing) do not collide, since
- * sharing is only supported for hvm guests, which do not perform pv pte
updates.
+ * The use of PGT_locked in mem_sharing does not collide, since mem_sharing is
+ * only supported for hvm guests, which do not have PV PTEs updated.
*/
int page_lock(struct page_info *page);
void page_unlock(struct page_info *page);
--
2.20.1
Re: [Xen-devel] [PATCH v2 07/10] vm_event: Add vm_event_ng interface
> -Original Message- [snip] > >>> +} > >>> + > >>> +if ( !vm_event_check(ved) ) > >>> +return -EINVAL; > >>> + > >>> +if ( frame != 0 || nr_frames != to_channels(ved)->nr_frames ) > >>> +return -EINVAL; > >> > >> Is there a particular reason for this all-or-nothing model? > > > > I've added this extra check due to the way acquire_resource interface > > is designed. In our case, the memory is allocated from > > XEN_VM_EVENT_ENABLE and the size is known beforehand: the number of > > pages needed to store (vcpus_count * sizeof vm_event_slot) bytes. > > However the acquire_resource needs a "nr_frames" parameter which is > > computed in a similar manner in the libxc wrapper. > > Hmm, maybe I'm not up to date here: Paul, is the general resource > obtaining/mapping logic indeed meant to be an all-or-nothing thing > only? > Not really, no. The intention is that any subsection of the resource space may be mapped, so as frame + nr_frames doesn't exceed the size of the space then there should be no reason to return an error. Paul > Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Design session report: Live-Updating Xen
On 17/07/2019 14:02, Jan Beulich wrote: > On 17.07.2019 13:26, Andrew Cooper wrote: >> On 17/07/2019 08:09, Jan Beulich wrote: >>> On 17.07.2019 01:51, Andrew Cooper wrote: On 15/07/2019 19:57, Foerster, Leonard wrote: > * dom0less: bootstrap domains without the involvement of dom0 > -> this might come in handy to at least setup and continue dom0 > on target xen > -> If we have this this might also enable us to de-serialize > the state for > other guest-domains in xen and not have to wait for > dom0 to do this Reconstruction of dom0 is something which Xen will definitely need to do. With the memory still in place, its just a fairly small of register state which needs restoring. That said, reconstruction of the typerefs will be an issue. Walking over a fully populated L4 tree can (in theory) take minutes, and its not safe to just start executing without reconstruction. Depending on how bad it is in practice, one option might be to do a demand validate of %rip and %rsp, along with a hybrid shadow mode which turns faults into typerefs, which would allow the gross cost of revalidation to be amortised while the vcpus were executing. We would definitely want some kind of logic to aggressively typeref outstanding pagetables so the shadow mode could be turned off. >>> Neither walking the page table trees nor and on-demand re-creation can >>> possibly work, as pointed out during (partly informal) discussion: At >>> the very least the allocated and pinned states of pages can only be >>> transferred. >> Pinned state exists in the current migrate stream. Allocated does not - >> it is an internal detail of how Xen handles the memory. >> >> But yes - this observation means that we can't simply walk the guest >> pagetables. >> >>> Hence we seem to have come to agreement that struct >>> page_info instances have to be transformed (in place if possible, i.e. >>> when the sizes match, otherwise by copying). >> -10 to this idea, if it can possibly be avoided. In this case, it >> definitely can be avoided. >> >> We do not want to be grovelling around in the old Xen's datastructures, >> because that adds a binary A=>B translation which is >> per-old-version-of-xen, meaning that you need a custom build of each >> target Xen which depends on the currently-running Xen, or have to >> maintain a matrix of old versions which will be dependent on the local >> changes, and therefore not suitable for upstream. > Now the question is what alternative you would suggest. By you > saying "the pinned state lives in the migration stream", I assume > you mean to imply that Dom0 state should be handed from old to > new Xen via such a stream (minus raw data page contents)? Yes, and this in explicitly identified in the bullet point saying "We do only rely on domain state and no internal xen state". In practice, it is going to be far more efficient to have Xen serialise/deserialise the domain register state etc, than to bounce it via hypercalls. By the time you're doing that in Xen, adding dom0 as well is trivial. > > -> We might have to go and re-inject certain interrupts What hardware are you targeting here? IvyBridge and later has a posted interrupt descriptor which can accumulate pending interrupts (at least manually), and newer versions (Broadwell?) can accumulate interrupts directly from hardware. >>> For HVM/PVH perhaps that's good enough. What about PV though? >> What about PV? >> >> The in-guest evtchn data structure will accumulate events just like a >> posted interrupt descriptor. Real interrupts will queue in the LAPIC >> during the transition period. > Yes, that'll work as long as interrupts remain active from Xen's POV. > But if there's concern about a blackout period for HVM/PVH, then > surely there would also be such for PV. The only fix for that is to reduce the length of the blackout period. We can't magically inject interrupts half way through the xen-to-xen transition, because we can't run vcpus at that point in time. > > A key cornerstone for Live-update is guest transparent live migration > -> This means we are using a well defined ABI for saving/restoring > domain state > -> We do only rely on domain state and no internal xen state Absolutely. One issue I discussed with David a while ago is that even across an upgrade of Xen, the format of the EPT/NPT pagetables might change, at least in terms of the layout of software bits. (Especially for EPT where we slowly lose software bits to new hardware features we wish to use.) >>> Right, and therefore a similar transformation like for struct page_info >>> may be unavoidable here too. >> None of that lives in the current migrate stream. Again - it is >> internal details, so is not something which is appropriate to be >> inspected by the
Re: [Xen-devel] [PATCH v1 3/5] xen: sched: null: deassign offline vcpus from pcpus
On Wed, 2019-07-17 at 17:04 +0100, George Dunlap wrote:
> On 8/25/18 1:21 AM, Dario Faggioli wrote:
> > If a pCPU has been/is being offlined, we don't want it to be
> > neither
> > assigned to any pCPU, nor in the wait list.
> >
> > Therefore, when we detect that a vcpu is going offline, remove it
> > from
> > both places.
>
> Hmm, this commit message wasn't very informative.
>
Ok, we can certainly improve that. :-)
> It looks like what you really mean to do is:
>
> > @@ -518,6 +521,14 @@ static void null_vcpu_remove(const struct
> > scheduler *ops, struct vcpu *v)
> >
> > lock = vcpu_schedule_lock_irq(v);
> >
> > +/* If offline, the vcpu shouldn't be assigned, nor in the
> > waitqueue */
> > +if ( unlikely(!is_vcpu_online(v)) )
> > +{
> > +ASSERT(per_cpu(npc, v->processor).vcpu != v);
> > +ASSERT(list_empty(>waitq_elem));
> > +goto out;
> > +}
>
> * Handle the case of an offline vcpu being removed (ASSERTing that
> it's
> neither on a processor nor on the waitqueue)
>
So, IIRC (sorry, it's been a while :-D ), this is for dealing with
remove_vcpu() being called on a vcpu which is offline. So, yes,
basically what you said. :-)
Point is the work of removing such vCPU from any CPU and from the wait
list has been done already, in null_vcpu_sleep(), while the vCPU was
going offline. So, here, we only need to make sure that we don't do
anything, i.e., that we don't call _vcpu_remove().
> But wait, isn't this fixing a important regression in patch 2? If
> after
> patch 2 but before patch 3, a VM is created with offline vcpus, and
> then
> destroyed, won't the offline vcpus reach here neither on the waitlist
> nor on a vcpu?
>
I'm not sure I understand the point you're trying to make here, sorry.
In general, considering what we've said in other mails, if you think
that patch 2 and 3 should be merged, we can do that.
My reasoning, when putting together the series, was the one I already
stated: this is broken already, so no big deal breaking it "more", and
I continue to see it that way.
But I appreciate you seeing it differently, while I don't have a too
strong opinion, so I'd be fine merging the patches (or doing other
series rearrangements, if you feel strongly that they're necessary).
Or is it something completely different that you meant?
> > @@ -567,11 +578,31 @@ static void null_vcpu_wake(const struct
> > scheduler *ops, struct vcpu *v)
> >
> > static void null_vcpu_sleep(const struct scheduler *ops, struct
> > vcpu *v)
> > {
> > +struct null_private *prv = null_priv(ops);
> > +unsigned int cpu = v->processor;
> > +bool tickled = false;
> > +
> > ASSERT(!is_idle_vcpu(v));
> >
> > +/* We need to special case the handling of the vcpu being
> > offlined */
> > +if ( unlikely(!is_vcpu_online(v)) )
> > +{
> > +struct null_vcpu *nvc = null_vcpu(v);
> > +
> > +printk("YYY d%dv%d going down?\n", v->domain->domain_id,
> > v->vcpu_id);
> > +if ( unlikely(!list_empty(>waitq_elem)) )
> > +{
> > +spin_lock(>waitq_lock);
> > +list_del_init(>waitq_elem);
> > +spin_unlock(>waitq_lock);
> > +}
> > +else if ( per_cpu(npc, cpu).vcpu == v )
> > +tickled = vcpu_deassign(prv, v);
> > +}
>
> * Handle the unexpected(?) case of a vcpu being put to sleep as(?)
> it's
> offlined
>
Well, that printk, really shouldn't be there! :-(
> If it's not unexpected, then why the printk?
>
Because it was a debugging aid, for while I was working on the series,
and I apparently failed at killing it before sending.
Sorry. :-(
> And if it is unexpected, what is the expected path for a cpu going
> offline to be de-assigned from a vcpu (which is what the title seems
> to
> imply this patch is about)?
>
This is the vCPU going down, when do_vcpu_op(VCPU_down) is invoked on
it, which then calls vcpu_sleep_nosync() with _VPF_down set in
pause_flags (which means vcpu_is_online() would be false.
So it is indeed the _expected_ path, and sorry again if the stray
debugging printk made you think otherwise.
> > @@ -615,12 +646,12 @@ static void null_vcpu_migrate(const struct
> > scheduler *ops, struct vcpu *v,
> > *
> > * In the latter, there is just nothing to do.
> > */
> > -if ( likely(list_empty(>waitq_elem)) )
> > +if ( likely(per_cpu(npc, v->processor).vcpu == v) )
> > {
> > vcpu_deassign(prv, v);
> > SCHED_STAT_CRANK(migrate_running);
> > }
> > -else
> > +else if ( !list_empty(>waitq_elem) )
> > SCHED_STAT_CRANK(migrate_on_runq);
>
> * Teach null_vcpu_migrate() that !on_waitqueue != on_vcpu.
>
> It looks like the comment just above this hunk is now out of date:
>
> "v is either assigned to a pCPU, or in the waitqueue."
>
Yes it does.
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
Re: [Xen-devel] [PATCH v8 4/5] x86/paravirt: Remove const mark from x86_hyper_xen_hvm variable
On Wed, 2019-07-17 at 08:49 +0200, Juergen Gross wrote:
> On 17.07.19 08:46, Joe Perches wrote:
> > On Tue, 2019-07-16 at 12:26 +0800, Zhenzhong Duan wrote:
> > > .. as "nopv" support needs it to be changeable at boot up stage.
> > >
> > > Checkpatch reports warning, so move variable declarations from
> > > hypervisor.c to hypervisor.h
> > []
> > > diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
> > []
> > > @@ -259,7 +259,7 @@ static __init void xen_hvm_guest_late_init(void)
> > > #endif
> > > }
> > >
> > > -const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = {
> > > +struct hypervisor_x86 x86_hyper_xen_hvm __initdata = {
> >
> > static?
>
> It is being referenced from arch/x86/kernel/cpu/hypervisor.c
But wasn't it also removed from the list of externs?
Rereading the .h file, no it wasn't. I missed that.
Perhaps the extern list could be reordered to move this
x86_hyper_xen_hvm to be next to x86_hyper_type.
I also suggest that "extern bool nopv" might be a bit
non-specific and could use a longer identifier.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC] x86emul: unconditionally deliver #UD for LWP insns
On 17/07/2019 14:07, Jan Beulich wrote:
> On 17.07.2019 13:42, Andrew Cooper wrote:
>> On 17/07/2019 07:42, Jan Beulich wrote:
>>> This is to accompany commit ("x86/svm: Drop support for AMD's
>> 91f86f8634
> Hmm, odd - I'm sure I had checked, resulting in the impression that
> this didn't get committed yet.
>
>>> Lightweight Profiling").
>>>
>>> Signed-off-by: Jan Beulich
>> Acked-by: Andrew Cooper
>>
>>> ---
>>> With AMD apparently having abandoned XOP encoded insns, another option
>>> would seem to be to simply wire all unrecognized ones into #UD (rather
>>> then returning UNIMPLEMENTED/UNRECOGNIZED).
>> There are still some XOP instructions which actually work on Fam17h
>> processors, if you ignore CPUID and go blindly executing.
>>
>> Given no official statement that XOP is dead, I'd keep the support we
>> currently have.
> Then my remark wasn't clear enough: I'm not suggesting to rip out
> XOP insn support we have. I'm instead considering whether to wire
> all unsupported XOP encodings into #UD (rather than return
> UNIMPLEMENTED/UNRECOGNIZED for them), not just the LWP ones.
Ah, in which case, no. Turning all unknown instructions into
EXCEPTION/#UD will break introspection, which uses UNRECOGNISED to cover
the gaps in the emulator by single-stepping the vcpu.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] printf formatter for pci_sbdf_t
On 17/07/2019 15:08, Roger Pau Monné wrote: > Hello, > > As part of some PCI related cleanup I'm doing, which includes > expanding the usage of pci_sbdf_t, I'm also planning to add a custom > printf formatter for pci_sbdf_t [0], so that a SBDF can be printed > without having to specify four formatters (and pass four parameters) > each time (%04x:%02x:%02x.%u). > > There's been some debate on the previous version about whether the > formatter should be %pp or %op, and I would like to settle on one of > them before sending a new version: I am firmly opposed to overloading %o. Nothing about PCI coordinates has anything to do with octal representation; its mostly hex. And for the record, I'm firmly opposed to overloading %[xuid] as well. %p is the only formatter which has magic overloading so far, and avoiding gaining a second would be of substantial value when it comes to reading the code. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Design session notes: Build system gripe session
On Mon, Jul 15, 2019 at 02:27:27PM +0100, George Dunlap wrote: > Or use Android's build system? I never worked with AOSP's sources, but after reading https://elinux.org/Android_Build_System the build system seems quite helpful. If we can do the following to build libxl, I think we could live with a similar build system: make libxl or . build/envsetup.sh cd tools/libxl mma Right now, building just libxl is complicated, one needs to figure out all the dependencies or build all tools/. But I don't know how ./configure would work with that, or if it is needed. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xen/arm: Switch OMAP5 secondary cores into hyp mode
Hi Denis, On 17/07/2019 17:32, Denis Obrezkov wrote: I am trying to understand how this ever worked. omap5_smp_init is called by two sets of platforms (based on compatible): - ti,dra7: there were some hacks in U-boot to avoid the SMC. If I am right, then I would not bother to support hacked U-boot. - ti,omap5: [1] suggest that U-boot do the switch for us but it is not clear whether this is upstreamed. @Chen, I know you did the port a long time ago. Do you recall how this worked? Linux seems to use the smc on any dra7 and omap54xx. So maybe we can use safely here. I don't understand your concerns to the full extent. What should be investigated? Well, Xen has been supported the omap5 for quite a while. So there are two possibilities regarding the current SMP code: 1) It is totally broken and therefore never worked on any omap5 platform. 2) It works but with maybe modification in U-boot. Looking at the mailing list archive and wiki, I believe 2) is closer to the current reality. So this raise the question whether your patch will break any existing setup. Don't get me wrong, the code is perfectly fine as, to the best of my knowledge, it matches what Linux does. However, I would like to see an analysis written in the commit message regarding what's going to happen for any existing setup. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Design session report: Xen on Distros
On 17/07/2019 13:37, Jan Beulich wrote: > On 17.07.2019 12:33, George Dunlap wrote: >>> On Jul 16, 2019, at 11:03 PM, Andrew Cooper >>> >>> We could trivially throw the fixes into the branch, tag it, sign it and >>> throw it out into the open, but doing that on the embargo date itself >>> would result in an official release of Xen which has had 0 testing in >>> the incumbent test system. >> The point is that anyone who ships / deploys a fix on the disclosure date >> is pretty much shipping exactly that. If it’s not good enough to sign, >> why is it good enough to deploy? > I think the security fixes themselves are good enough to deploy, perhaps > with the assumption that consumers of our pre-disclosure list have done > some testing on their own. The stable trees, however, contain more than > just security fixes, and can have regressions (most likely due to > backporting mistakes). Right, but e.g. proposed changing the commit/push model whereby all changes must pass CI before they get merged would reduce the likelyhood of bad backports getting into staging-* in the first place. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 139090: tolerable all pass - PUSHED
flight 139090 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/139090/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen c0a0acb7271f822b455be401a37120be61146036 baseline version: xen 08b084ab48738040e34032ffb42387d88619bf1b Last test of basis 139061 2019-07-16 18:04:22 Z0 days Testing same since 139090 2019-07-17 14:01:23 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Andrew Cooper Baodong Chen George Dunlap [tracing] Jan Beulich Julien Grall jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass 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 : To xenbits.xen.org:/home/xen/git/xen.git 08b084ab48..c0a0acb727 c0a0acb7271f822b455be401a37120be61146036 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 07/10] vm_event: Add vm_event_ng interface
On 17.07.2019 16:41, Petre Ovidiu PIRCALABU wrote:
> On Wed, 2019-07-17 at 10:06 +, Jan Beulich wrote:
>> On 16.07.2019 19:06, Petre Pircalabu wrote:
>>> +static void vm_event_channels_free_buffer(struct
>>> vm_event_channels_domain *impl)
>>>{
>>> -vm_event_ring_resume(to_ring(v->domain->vm_event_monitor));
>>> +int i;
>>> +
>>> +vunmap(impl->slots);
>>> +impl->slots = NULL;
>>> +
>>> +for ( i = 0; i < impl->nr_frames; i++ )
>>> +free_domheap_page(mfn_to_page(impl->mfn[i]));
>>>}
>>
>> What guarantees that there are no mappings left of the pages you free
>> here? Sharing pages with guests is (so far) an (almost) irreversible
>> action, i.e. they may generally only be freed upon domain
>> destruction.
>> See gnttab_unpopulate_status_frames() for a case where we actually
>> make an attempt at freeing such pages (but where we fail the request
>> in case references are left in place).
>>
> I've tested manually 2 cases and they both work (no crashes):
> 1: introspected domain starts -> monitor starts -> monitor stops ->
> domain stops
> 2: introspected domain starts -> monitor starts -> domain stops ->
> monitor stops.
Well, testing is important, but doing tests like you describe won't
catch any misbehaving or malicious monitor domain.
> However, I will take a closer look at gnttab_unpopulate_status_frames
> and post a follow up email.
Thanks.
>> Furthermore, is there any guarantee that the pages you free here
>> were actually allocated? ->nr_frames gets set ahead of the actual
>> allocation.
>>
> vm_event_channels_free_buffer is called only from
> vm_event_channels_disable. The latter is called only if vm_event_check
> succeeds ( vm_event_cleanup and vm_event_domctl/VM_EVENT_DISABLE).
> vm_event_check will only return true if vm_event_enable succeeds.
Hmm, looks like I was mislead to believe the freeing function
would be called by vm_event_channels_enable() not itself freeing
what it might have allocated upon error. So perhaps the bug is
there, not where I thought it would be.
>>> +int vm_event_ng_get_frames(struct domain *d, unsigned int id,
>>> + unsigned long frame, unsigned int
>>> nr_frames,
>>> + xen_pfn_t mfn_list[])
>>> +{
>>> +struct vm_event_domain *ved;
>>> +int i;
>>> +
>>> +switch (id )
>>> +{
>>> +case XEN_VM_EVENT_TYPE_MONITOR:
>>> +ved = d->vm_event_monitor;
>>> +break;
>>> +
>>> +default:
>>> +return -ENOSYS;
>>
>> Various other error codes might be fine here, but ENOSYS is not
>> (despite pre-existing misuse elsewhere in the tree).
>
> vm_event_domctl also returns -ENOSYS if the type is neither
> XEN_VM_EVENT_TYPE_PAGING, XEN_VM_EVENT_TYPE_MONITOR, nor
> XEN_VM_EVENT_TYPE_SHARING. I've just followed the existing convention.
Right - that's one of the pre-existing misuses that I was referring
to.
>>> +}
>>> +
>>> +if ( !vm_event_check(ved) )
>>> +return -EINVAL;
>>> +
>>> +if ( frame != 0 || nr_frames != to_channels(ved)->nr_frames )
>>> +return -EINVAL;
>>
>> Is there a particular reason for this all-or-nothing model?
>
> I've added this extra check due to the way acquire_resource interface
> is designed. In our case, the memory is allocated from
> XEN_VM_EVENT_ENABLE and the size is known beforehand: the number of
> pages needed to store (vcpus_count * sizeof vm_event_slot) bytes.
> However the acquire_resource needs a "nr_frames" parameter which is
> computed in a similar manner in the libxc wrapper.
Hmm, maybe I'm not up to date here: Paul, is the general resource
obtaining/mapping logic indeed meant to be an all-or-nothing thing
only?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xen/arm: Switch OMAP5 secondary cores into hyp mode
Hi Julien, > > I am trying to understand how this ever worked. omap5_smp_init is called > by two sets of platforms (based on compatible): > - ti,dra7: there were some hacks in U-boot to avoid the SMC. If I am > right, then I would not bother to support hacked U-boot. > - ti,omap5: [1] suggest that U-boot do the switch for us but it is > not clear whether this is upstreamed. @Chen, I know you did the port a > long time ago. Do you recall how this worked? > > Linux seems to use the smc on any dra7 and omap54xx. So maybe we can use > safely here. > I don't understand your concerns to the full extent. What should be investigated? -- Regards, Denis Obrezkov ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.19 test] 139062: regressions - FAIL
flight 139062 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/139062/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313 build-armhf-pvops 6 kernel-build fail REGR. vs. 129313 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: linux3bd837bfe431839a378e9d421af05b2e22a6d329 baseline version: linux84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d Last test of basis 129313 2018-11-02 05:39:08 Z 257 days Failing since129412 2018-11-04 14:10:15 Z 255 days 161 attempts Testing same since 139004 2019-07-14 23:35:54 Z2 days3 attempts 2271 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf
Re: [Xen-devel] [PATCH v4 13/15] docs: ABI: testing: make the files compatible with ReST output
On Wed, 17 Jul 2019 09:28:17 -0300 Mauro Carvalho Chehab wrote: > Some files over there won't parse well by Sphinx. > > Fix them. > > Signed-off-by: Mauro Carvalho Chehab Hi Mauro, Does feel like this one should perhaps have been broken up a touch! For the IIO ones I've eyeballed it rather than testing the results Acked-by: Jonathan Cameron ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] x86/vLAPIC: avoid speculative out of bounds accesses
Array indexes used in the MSR read/write emulation functions as well as
the direct VMX / APIC-V hook are derived from guest controlled values.
Restrict their ranges to limit the side effects of speculative
execution.
Along these lines also constrain the vlapic_lvt_mask[] access.
Remove the unused vlapic_lvt_{vector,dm}() instead of adjusting them.
This is part of the speculative hardening effort.
Signed-off-by: Jan Beulich
---
v2: Drop changes to vlapic_mmio_{read,write}(). Drop
VLAPIC_OFFSET_MASK(). Also tweak guest_wrmsr_x2apic().
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -65,12 +66,6 @@ static const unsigned int vlapic_lvt_mas
LVT_MASK
};
-#define vlapic_lvt_vector(vlapic, lvt_type) \
-(vlapic_get_reg(vlapic, lvt_type) & APIC_VECTOR_MASK)
-
-#define vlapic_lvt_dm(vlapic, lvt_type) \
-(vlapic_get_reg(vlapic, lvt_type) & APIC_MODE_MASK)
-
#define vlapic_lvtt_period(vlapic) \
((vlapic_get_reg(vlapic, APIC_LVTT) & APIC_TIMER_MODE_MASK) \
== APIC_TIMER_MODE_PERIODIC)
@@ -676,7 +671,7 @@ int guest_rdmsr_x2apic(const struct vcpu
};
const struct vlapic *vlapic = vcpu_vlapic(v);
uint64_t high = 0;
-uint32_t reg = msr - MSR_X2APIC_FIRST, offset = reg << 4;
+uint32_t reg = msr - MSR_X2APIC_FIRST, offset;
/*
* The read side looks as if it might be safe to use outside of current
@@ -686,9 +681,14 @@ int guest_rdmsr_x2apic(const struct vcpu
ASSERT(v == current);
if ( !vlapic_x2apic_mode(vlapic) ||
- (reg >= sizeof(readable) * 8) || !test_bit(reg, readable) )
+ (reg >= sizeof(readable) * 8) )
+return X86EMUL_EXCEPTION;
+
+reg = array_index_nospec(reg, sizeof(readable) * 8);
+if ( !test_bit(reg, readable) )
return X86EMUL_EXCEPTION;
+offset = reg << 4;
if ( offset == APIC_ICR )
high = (uint64_t)vlapic_read_aligned(vlapic, APIC_ICR2) << 32;
@@ -867,7 +867,7 @@ void vlapic_reg_write(struct vcpu *v, un
case APIC_LVTERR: /* LVT Error Reg */
if ( vlapic_sw_disabled(vlapic) )
val |= APIC_LVT_MASKED;
-val &= vlapic_lvt_mask[(reg - APIC_LVTT) >> 4];
+val &= array_access_nospec(vlapic_lvt_mask, (reg - APIC_LVTT) >> 4);
vlapic_set_reg(vlapic, reg, val);
if ( reg == APIC_LVT0 )
{
@@ -957,7 +957,7 @@ static int vlapic_mmio_write(struct vcpu
int vlapic_apicv_write(struct vcpu *v, unsigned int offset)
{
struct vlapic *vlapic = vcpu_vlapic(v);
-uint32_t val = vlapic_get_reg(vlapic, offset);
+uint32_t val = vlapic_get_reg(vlapic, offset & ~0xf);
if ( vlapic_x2apic_mode(vlapic) )
{
@@ -1053,7 +1053,7 @@ int guest_wrmsr_x2apic(struct vcpu *v, u
}
}
-vlapic_reg_write(v, offset, msr_content);
+vlapic_reg_write(v, array_index_nospec(offset, PAGE_SIZE), msr_content);
return X86EMUL_OKAY;
}
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 3/5] xen: sched: null: deassign offline vcpus from pcpus
On 8/25/18 1:21 AM, Dario Faggioli wrote:
> If a pCPU has been/is being offlined, we don't want it to be neither
> assigned to any pCPU, nor in the wait list.
>
> Therefore, when we detect that a vcpu is going offline, remove it from
> both places.
Hmm, this commit message wasn't very informative.
It looks like what you really mean to do is:
> Signed-off-by: Dario Faggioli
> ---
> Cc: George Dunlap
> Cc: Stefano Stabellini
> Cc: Roger Pau Monne
> ---
> xen/common/sched_null.c | 43 +--
> 1 file changed, 37 insertions(+), 6 deletions(-)
>
> diff --git a/xen/common/sched_null.c b/xen/common/sched_null.c
> index 1426124525..6259f4643e 100644
> --- a/xen/common/sched_null.c
> +++ b/xen/common/sched_null.c
> @@ -361,7 +361,8 @@ static void vcpu_assign(struct null_private *prv, struct
> vcpu *v,
> }
> }
>
> -static void vcpu_deassign(struct null_private *prv, struct vcpu *v)
> +/* Returns true if a cpu was tickled */
> +static bool vcpu_deassign(struct null_private *prv, struct vcpu *v)
> {
> unsigned int bs;
> unsigned int cpu = v->processor;
> @@ -406,11 +407,13 @@ static void vcpu_deassign(struct null_private *prv,
> struct vcpu *v)
> vcpu_assign(prv, wvc->vcpu, cpu);
> cpu_raise_softirq(cpu, SCHEDULE_SOFTIRQ);
> spin_unlock(>waitq_lock);
> -return;
> +return true;
> }
> }
> }
> spin_unlock(>waitq_lock);
> +
> +return false;
> }
>
> /* Change the scheduler of cpu to us (null). */
> @@ -518,6 +521,14 @@ static void null_vcpu_remove(const struct scheduler
> *ops, struct vcpu *v)
>
> lock = vcpu_schedule_lock_irq(v);
>
> +/* If offline, the vcpu shouldn't be assigned, nor in the waitqueue */
> +if ( unlikely(!is_vcpu_online(v)) )
> +{
> +ASSERT(per_cpu(npc, v->processor).vcpu != v);
> +ASSERT(list_empty(>waitq_elem));
> +goto out;
> +}
* Handle the case of an offline vcpu being removed (ASSERTing that it's
neither on a processor nor on the waitqueue)
But wait, isn't this fixing a important regression in patch 2? If after
patch 2 but before patch 3, a VM is created with offline vcpus, and then
destroyed, won't the offline vcpus reach here neither on the waitlist
nor on a vcpu?
Offlining/onlining vcpus is one thing; but creating and destroying
guests is something different.
> /* If v is in waitqueue, just get it out of there and bail */
> if ( unlikely(!list_empty(>waitq_elem)) )
> {
> @@ -567,11 +578,31 @@ static void null_vcpu_wake(const struct scheduler *ops,
> struct vcpu *v)
>
> static void null_vcpu_sleep(const struct scheduler *ops, struct vcpu *v)
> {
> +struct null_private *prv = null_priv(ops);
> +unsigned int cpu = v->processor;
> +bool tickled = false;
> +
> ASSERT(!is_idle_vcpu(v));
>
> +/* We need to special case the handling of the vcpu being offlined */
> +if ( unlikely(!is_vcpu_online(v)) )
> +{
> +struct null_vcpu *nvc = null_vcpu(v);
> +
> +printk("YYY d%dv%d going down?\n", v->domain->domain_id, v->vcpu_id);
> +if ( unlikely(!list_empty(>waitq_elem)) )
> +{
> +spin_lock(>waitq_lock);
> +list_del_init(>waitq_elem);
> +spin_unlock(>waitq_lock);
> +}
> +else if ( per_cpu(npc, cpu).vcpu == v )
> +tickled = vcpu_deassign(prv, v);
> +}
* Handle the unexpected(?) case of a vcpu being put to sleep as(?) it's
offlined
If it's not unexpected, then why the printk?
And if it is unexpected, what is the expected path for a cpu going
offline to be de-assigned from a vcpu (which is what the title seems to
imply this patch is about)?
> +
> /* If v is not assigned to a pCPU, or is not running, no need to bother
> */
> -if ( curr_on_cpu(v->processor) == v )
> -cpu_raise_softirq(v->processor, SCHEDULE_SOFTIRQ);
> +if ( likely(!tickled && curr_on_cpu(cpu) == v) )
> +cpu_raise_softirq(cpu, SCHEDULE_SOFTIRQ);
>
> SCHED_STAT_CRANK(vcpu_sleep);
> }
> @@ -615,12 +646,12 @@ static void null_vcpu_migrate(const struct scheduler
> *ops, struct vcpu *v,
> *
> * In the latter, there is just nothing to do.
> */
> -if ( likely(list_empty(>waitq_elem)) )
> +if ( likely(per_cpu(npc, v->processor).vcpu == v) )
> {
> vcpu_deassign(prv, v);
> SCHED_STAT_CRANK(migrate_running);
> }
> -else
> +else if ( !list_empty(>waitq_elem) )
> SCHED_STAT_CRANK(migrate_on_runq);
* Teach null_vcpu_migrate() that !on_waitqueue != on_vcpu.
It looks like the comment just above this hunk is now out of date:
"v is either assigned to a pCPU, or in the waitqueue."
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 4/6] xen/x86: Allow stubdom access to irq created for msi.
On Wed, Jul 17, 2019 at 11:54:35AM +0200, Roger Pau Monné wrote:
> On Wed, Jul 17, 2019 at 03:00:42AM +0200, Marek Marczykowski-Górecki wrote:
> > Stubdomains need to be given sufficient privilege over the guest which it
> > provides emulation for in order for PCI passthrough to work correctly.
> > When a HVM domain try to enable MSI, QEMU in stubdomain calls
> > PHYSDEVOP_map_pirq, but later it needs to call XEN_DOMCTL_bind_pt_irq as
> > part of xc_domain_update_msi_irq. Allow for that as part of
> > PHYSDEVOP_map_pirq.
> >
> > This is not needed for PCI INTx, because IRQ in that case is known
> > beforehand and the stubdomain is given permissions over this IRQ by
> > libxl__device_pci_add (there's a do_pci_add against the stubdomain).
> >
> > create_irq() already grant IRQ access to hardware_domain, with
> > assumption the device model (something managing this IRQ) lives there.
> > Modify create_irq() to take additional parameter pointing at device
> > model domain - which may be dom0 or stubdomain. Save ID of the domain
> > given permission, to revoke it in destroy_irq() - easier and cleaner
> > than replaying logic of create_irq() parameter. Use domid instead of
> > actual reference to the domain, because it might get destroyed before
> > destroying IRQ (stubdomain is destroyed before its target domain). And
> > it is not an issue, because IRQ permissions live within domain
> > structure, so destroying a domain also implicitly revoke the permission.
> > Potential domid reuse is detected by by checking if that domain does
> > have permission over the IRQ being destroyed.
> >
> > Then, adjust all callers to provide the parameter. In case of calls not
> > related to stubdomain-initiated allocations, give it either
> > hardware_domain (so the behavior is unchanged there), or NULL for
> > interrupts used by Xen internally.
> >
> > Inspired by
> > https://github.com/OpenXT/xenclient-oe/blob/5e0e7304a5a3c75ef01240a1e3673665b2aaf05e/recipes-extended/xen/files/stubdomain-msi-irq-access.patch
> > by Eric Chanudet .
> >
> > Signed-off-by: Simon Gaiser
> > Signed-off-by: Marek Marczykowski-Górecki
> > ---
> > Changes in v3:
> > - extend commit message
> > Changes in v4:
> > - add missing destroy_irq on error path
> > Changes in v5:
> > - move irq_{grant,revoke}_access() to {create,destroy}_irq(), which
> >basically make it a different patch
> > - add get_dm_domain() helper
> > - do not give hardware_domain permission over IRQs used in Xen
> >internally
> > - rename create_irq argument to just 'd', to avoid confusion
> >when it's called by hardware domain
> > - verify that device is de-assigned before pci_remove_device call
> > - save ID of domain given permission in create_irq(), to revoke it in
> > destroy_irq()
> > - drop domain parameter from destroy_irq() and msi_free_irq()
> > - do not give hardware domain permission over IRQ created in
> > iommu_set_interrupt()
> > ---
> > xen/arch/x86/hpet.c | 3 +-
> > xen/arch/x86/irq.c | 51 ++---
> > xen/common/irq.c | 1 +-
> > xen/drivers/char/ns16550.c | 2 +-
> > xen/drivers/passthrough/amd/iommu_init.c | 2 +-
> > xen/drivers/passthrough/pci.c| 3 +-
> > xen/drivers/passthrough/vtd/iommu.c | 3 +-
> > xen/include/asm-x86/irq.h| 2 +-
> > xen/include/xen/irq.h| 1 +-
> > 9 files changed, 50 insertions(+), 18 deletions(-)
> >
> > diff --git a/xen/arch/x86/hpet.c b/xen/arch/x86/hpet.c
> > index 4b08488..b4854ff 100644
> > --- a/xen/arch/x86/hpet.c
> > +++ b/xen/arch/x86/hpet.c
> > @@ -11,6 +11,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -368,7 +369,7 @@ static int __init hpet_assign_irq(struct
> > hpet_event_channel *ch)
> > {
> > int irq;
> >
> > -if ( (irq = create_irq(NUMA_NO_NODE)) < 0 )
> > +if ( (irq = create_irq(NUMA_NO_NODE, hardware_domain)) < 0 )
>
> Shouldn't this be NULL? I don't think the hardware domain should be
> allowed to play with the HPET IRQs?
Good point.
> > return irq;
> >
> > ch->msi.irq = irq;
> > diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
> > index 2cac28a..dc5d302 100644
> > --- a/xen/arch/x86/irq.c
> > +++ b/xen/arch/x86/irq.c
> > @@ -164,10 +164,21 @@ int __init bind_irq_vector(int irq, int vector, const
> > cpumask_t *cpu_mask)
> > return ret;
> > }
> >
> > +static struct domain *get_dm_domain(struct domain *d)
>^ const
> > +{
> > +return current->domain->target == d ? current->domain :
> > hardware_domain;
> > +}
> > +
> > /*
> > * Dynamic irq allocate and deallocation for MSI
> > */
> > -int create_irq(nodeid_t node)
> > +
> > +/*
> > + * create_irq - allocate irq for MSI
> > + * @d domain that will get permission over the allocated irq; this
> > permission
> > + *
Re: [Xen-devel] [PATCH v2 07/10] vm_event: Add vm_event_ng interface
On Wed, 2019-07-17 at 16:42 +0300, Alexandru Stefan ISAILA wrote:
> > +
> > +out:
> > +rc2 = xc_domain_unpause(xch, domain_id);
> > +if ( rc1 || rc2 )
> > +{
> > +if ( rc2 )
> > +PERROR("Unable to pause domain\n");
> > +
> > +if ( rc1 == 0 )
> > +rc1 = rc2;
>
> You can use !rc1 here.
>
> > +}
> > +
> > +return rc1;
> > +}
> > +
> > +int xc_vm_event_ng_disable(xc_interface *xch, uint32_t domain_id,
> > int type,
> > + xenforeignmemory_resource_handle
> > **fres)
> > +{
> > +xenforeignmemory_unmap_resource(xch->fmem, *fres);
> > +*fres = NULL;
> > +
> > +return xc_vm_event_control(xch, domain_id,
> > XEN_VM_EVENT_DISABLE,
> > + type, XEN_VM_EVENT_FLAGS_NG_OP,
> > NULL);
> > +}
> > +
>
>
>
> >
> > +static int vm_event_ring_pfn_param(uint32_t type)
> > +{
> > +switch( type )
> > +{
> > +#ifdef CONFIG_HAS_MEM_PAGING
> > +case XEN_VM_EVENT_TYPE_PAGING:
> > +return HVM_PARAM_PAGING_RING_PFN;
> > +#endif
> > +case XEN_VM_EVENT_TYPE_MONITOR:
> > +return HVM_PARAM_MONITOR_RING_PFN;
> > +#ifdef CONFIG_HAS_MEM_SHARING
> > +case XEN_VM_EVENT_TYPE_SHARING:
> > +return HVM_PARAM_SHARING_RING_PFN;
> > +#endif
> > +};
> > +
> > +ASSERT_UNREACHABLE();
> > +return -1;
>
> Blank line before final return...
>
> > +}
> > +
> > +static int vm_event_pause_flag(uint32_t type)
> > +{
> > +switch( type )
> > +{
> > +#ifdef CONFIG_HAS_MEM_PAGING
> > +case XEN_VM_EVENT_TYPE_PAGING:
> > +return _VPF_mem_paging;
> > +#endif
> > +case XEN_VM_EVENT_TYPE_MONITOR:
> > +return _VPF_mem_access;
> > +#ifdef CONFIG_HAS_MEM_SHARING
> > +case XEN_VM_EVENT_TYPE_SHARING:
> > +return _VPF_mem_sharing;
> > +#endif
> > +};
> > +
> > +ASSERT_UNREACHABLE();
> > +return -1;
>
> here
>
> > +}
> > +
> > +#ifdef CONFIG_HAS_MEM_PAGING
> > +static void mem_paging_notification(struct vcpu *v, unsigned int
> > port);
> > +#endif
> > +static void monitor_notification(struct vcpu *v, unsigned int
> > port);
> > +#ifdef CONFIG_HAS_MEM_SHARING
> > +static void mem_sharing_notification(struct vcpu *v, unsigned int
> > port);
> > +#endif
> > +
> > +static xen_event_channel_notification_t
> > vm_event_notification_fn(uint32_t type)
> > +{
> > +switch( type )
> > +{
> > +#ifdef CONFIG_HAS_MEM_PAGING
> > +case XEN_VM_EVENT_TYPE_PAGING:
> > +return mem_paging_notification;
> > +#endif
> > +case XEN_VM_EVENT_TYPE_MONITOR:
> > +return monitor_notification;
> > +#ifdef CONFIG_HAS_MEM_SHARING
> > +case XEN_VM_EVENT_TYPE_SHARING:
> > +return mem_sharing_notification;
> > +#endif
> > +};
> > +
> > +ASSERT_UNREACHABLE();
> > +return NULL;
>
> and here
>
> > +}
> > +
> > +/*
> > + * VM event ring implementation;
> > + */
>
> Alex
Thanks for noticing these. I will fix them in the next patch iteration.
Petre
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 07/10] vm_event: Add vm_event_ng interface
On Wed, 2019-07-17 at 10:06 +, Jan Beulich wrote:
> On 16.07.2019 19:06, Petre Pircalabu wrote:
> > +static void vm_event_channels_free_buffer(struct
> > vm_event_channels_domain *impl)
> > {
> > -vm_event_ring_resume(to_ring(v->domain->vm_event_monitor));
> > +int i;
> > +
> > +vunmap(impl->slots);
> > +impl->slots = NULL;
> > +
> > +for ( i = 0; i < impl->nr_frames; i++ )
> > +free_domheap_page(mfn_to_page(impl->mfn[i]));
> > }
>
> What guarantees that there are no mappings left of the pages you free
> here? Sharing pages with guests is (so far) an (almost) irreversible
> action, i.e. they may generally only be freed upon domain
> destruction.
> See gnttab_unpopulate_status_frames() for a case where we actually
> make an attempt at freeing such pages (but where we fail the request
> in case references are left in place).
>
I've tested manually 2 cases and they both work (no crashes):
1: introspected domain starts -> monitor starts -> monitor stops ->
domain stops
2: introspected domain starts -> monitor starts -> domain stops ->
monitor stops.
However, I will take a closer look at gnttab_unpopulate_status_frames
and post a follow up email.
> Furthermore, is there any guarantee that the pages you free here
> were actually allocated? ->nr_frames gets set ahead of the actual
> allocation.
>
vm_event_channels_free_buffer is called only from
vm_event_channels_disable. The latter is called only if vm_event_check
succeeds ( vm_event_cleanup and vm_event_domctl/VM_EVENT_DISABLE).
vm_event_check will only return true if vm_event_enable succeeds.
> > +int vm_event_ng_get_frames(struct domain *d, unsigned int id,
> > + unsigned long frame, unsigned int
> > nr_frames,
> > + xen_pfn_t mfn_list[])
> > +{
> > +struct vm_event_domain *ved;
> > +int i;
> > +
> > +switch (id )
> > +{
> > +case XEN_VM_EVENT_TYPE_MONITOR:
> > +ved = d->vm_event_monitor;
> > +break;
> > +
> > +default:
> > +return -ENOSYS;
>
> Various other error codes might be fine here, but ENOSYS is not
> (despite pre-existing misuse elsewhere in the tree).
vm_event_domctl also returns -ENOSYS if the type is neither
XEN_VM_EVENT_TYPE_PAGING, XEN_VM_EVENT_TYPE_MONITOR, nor
XEN_VM_EVENT_TYPE_SHARING. I've just followed the existing convention.
>
> > +}
> > +
> > +if ( !vm_event_check(ved) )
> > +return -EINVAL;
> > +
> > +if ( frame != 0 || nr_frames != to_channels(ved)->nr_frames )
> > +return -EINVAL;
>
> Is there a particular reason for this all-or-nothing model?
I've added this extra check due to the way acquire_resource interface
is designed. In our case, the memory is allocated from
XEN_VM_EVENT_ENABLE and the size is known beforehand: the number of
pages needed to store (vcpus_count * sizeof vm_event_slot) bytes.
However the acquire_resource needs a "nr_frames" parameter which is
computed in a similar manner in the libxc wrapper.
This check only verifies that userspace is not sending an invalid
parameter (using an ASSERT in this case would have been overkill
because it would crash the whole hypervisor)
>
> > +spin_lock(>lock);
> > +
> > +for ( i = 0; i < to_channels(ved)->nr_frames; i++ )
> > +mfn_list[i] = mfn_x(to_channels(ved)->mfn[i]);
> > +
> > +spin_unlock(>lock);
>
> What is the locking good for here? You obviously can't be afraid of
> the values becoming stale, as they surely would be by the time the
> caller gets to see them (if they can go stale in the first place).
Thanks for pointing this out. I will remove the lock in the next
patchset iteration.
>
> > --- a/xen/include/public/domctl.h
> > +++ b/xen/include/public/domctl.h
> > @@ -38,7 +38,7 @@
> > #include "hvm/save.h"
> > #include "memory.h"
> >
> > -#define XEN_DOMCTL_INTERFACE_VERSION 0x0011
> > +#define XEN_DOMCTL_INTERFACE_VERSION 0x0012
>
> This looks to be needed only because of ...
>
> > @@ -781,12 +781,20 @@ struct xen_domctl_gdbsx_domstatus {
> > struct xen_domctl_vm_event_op {
> > uint32_t op; /* XEN_VM_EVENT_* */
> > uint32_t type; /* XEN_VM_EVENT_TYPE_* */
> > + /* Use the NG interface */
> > +#define _XEN_VM_EVENT_FLAGS_NG_OP 0
> > +#define XEN_VM_EVENT_FLAGS_NG_OP (1U <<
> > _XEN_VM_EVENT_FLAGS_NG_OP)
> > +uint32_t flags;
>
> ... this addition. Is the new field really warranted here? Can't
> you e.g. simply define a new set of ops (e.g. by setting their
> high bits)?
>
You are right. Actually only a new op is needed (e.g.
XEN_VM_EVENT_NG_ENABLE).
The only needed adition is the vcpu_id for the resume op, in order to
specify the vcpu which will handle the request in case of the
"channels" vm_event transport. However, this will not affect the
domctl's offsets hence the interface version increment is not required.
I will change this in the next patchset iteration.
> I've omitted all style
Re: [Xen-devel] [PATCH v2 3/5] x86/AMD: make C-state handling independent of Dom0
On Wed, Jul 17, 2019 at 12:49:49PM +, Jan Beulich wrote:
> On 17.07.2019 12:26, Roger Pau Monné wrote:
> > On Wed, Jul 17, 2019 at 09:04:55AM +, Jan Beulich wrote:
> >> On 16.07.2019 16:26, Roger Pau Monné wrote:
> >>> On Wed, Jul 03, 2019 at 01:01:48PM +, Jan Beulich wrote:
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -110,6 +110,8 @@ boolean_param("lapic_timer_c2_ok", local
>
> struct acpi_processor_power *__read_mostly processor_powers[NR_CPUS];
>
> +static int8_t __read_mostly vendor_override;
> >>>
> >>> AFAICT from the code below this is a tri-state (-1, 0, 1). Could it
> >>> maybe be turned into an enum with definitions of the different
> >>> states?
> >>>
> >>> I think it would make the usage clearer.
> >>
> >> Well, personally I prefer doing it this way for tristates. I'll
> >> wait to see what others think.
> >
> > Ack, I think the code is correct hence:
> >
> > Reviewed-by: Roger Pau Monné
>
> Thanks.
>
> > But I personally would prefer an enum or at least a description of
> > the meaning of the values vendor_override can take. IMO it would help
> > understanding the code, since it's not obvious to me at first sight.
>
> I've added
Thanks! I'm happy with this.
> /*
> * This field starts out as zero, and can be set to -1 just to signal it has
> * been set (and that vendor specific logic has failed, and shouldn't be
> * tried again), or to +1 to ignore Dom0 side uploads of C-state ACPI data.
^ signal vendor specific setup has
succeed and dom0 side uploads of
C-state ACPI data should be ignored.
I think is even clearer, but might be to verbose? Anyway, I don't
have a strong opinion, and your text is certainly fine.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] printf formatter for pci_sbdf_t
Hello, As part of some PCI related cleanup I'm doing, which includes expanding the usage of pci_sbdf_t, I'm also planning to add a custom printf formatter for pci_sbdf_t [0], so that a SBDF can be printed without having to specify four formatters (and pass four parameters) each time (%04x:%02x:%02x.%u). There's been some debate on the previous version about whether the formatter should be %pp or %op, and I would like to settle on one of them before sending a new version: Using %pp pros: - Xen already overloads p with other custom implementations. Using %pp cons: - Passes a pointer (which is always 64b on x86) to store a 32bit value (SBDF). - Requires a dereference to access the value. Using %op pros: - Can pass a 32bit integer naturally. Using %op cons: - No other overloads of the o specifier exists so far, either in Xen or in Linux AFAIK. My first implementation used %pp because it's inline with the current overloads already present, and printk not being performance critical I don't see much problem in using 64bit to pass a 32bit value, or in requiring a dereference to access it. We could keep using %pp and casting the sbdf value to 'void *' to avoid the dereference, but I don't think there's much value on doing that, the more that call sites would need to use a macro to hide the casting away. Anyway, I would like to get some consensus on which path to follow, either %pp or %op before sending a new version of the series. I'm Ccing both Andrew and Jan as they had strong opinions, and I would personally vote for %pp as I've expressed above, but don't mind implementing something else as long as there's consensus and it's not going to get stuck on an endless argument. Thanks, Roger. [0] https://patchew.org/Xen/20190510161056.48648-1-roger@citrix.com/20190510161056.48648-5-roger@citrix.com/ ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.10-testing test] 139056: regressions - trouble: blocked/fail/pass/starved
flight 139056 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/139056/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 6 xen-buildfail REGR. vs. 138376 build-i386-prev 6 xen-buildfail REGR. vs. 138376 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 15 guest-saverestore.2 fail in 139022 pass in 139056 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail pass in 139022 Tests which did not succeed, but are not blocking: test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 138376 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail like 138376 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-install
Re: [Xen-devel] [PATCH v5 4/4] x86/mem_sharing: compile mem_sharing subsystem only when kconfig is enabled
> Disable it by default as it is only an experimental subsystem. > > Signed-off-by: Tamas K Lengyel This will now need re-basing, as the other change (adding further CONFIG_HAS_MEM_SHARING) has just gone in. I'm sorry for the extra round trip needed. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 07/10] vm_event: Add vm_event_ng interface
> +
> +out:
> +rc2 = xc_domain_unpause(xch, domain_id);
> +if ( rc1 || rc2 )
> +{
> +if ( rc2 )
> +PERROR("Unable to pause domain\n");
> +
> +if ( rc1 == 0 )
> +rc1 = rc2;
You can use !rc1 here.
> +}
> +
> +return rc1;
> +}
> +
> +int xc_vm_event_ng_disable(xc_interface *xch, uint32_t domain_id, int type,
> + xenforeignmemory_resource_handle **fres)
> +{
> +xenforeignmemory_unmap_resource(xch->fmem, *fres);
> +*fres = NULL;
> +
> +return xc_vm_event_control(xch, domain_id, XEN_VM_EVENT_DISABLE,
> + type, XEN_VM_EVENT_FLAGS_NG_OP, NULL);
> +}
> +
>
> +static int vm_event_ring_pfn_param(uint32_t type)
> +{
> +switch( type )
> +{
> +#ifdef CONFIG_HAS_MEM_PAGING
> +case XEN_VM_EVENT_TYPE_PAGING:
> +return HVM_PARAM_PAGING_RING_PFN;
> +#endif
> +case XEN_VM_EVENT_TYPE_MONITOR:
> +return HVM_PARAM_MONITOR_RING_PFN;
> +#ifdef CONFIG_HAS_MEM_SHARING
> +case XEN_VM_EVENT_TYPE_SHARING:
> +return HVM_PARAM_SHARING_RING_PFN;
> +#endif
> +};
> +
> +ASSERT_UNREACHABLE();
> +return -1;
Blank line before final return...
> +}
> +
> +static int vm_event_pause_flag(uint32_t type)
> +{
> +switch( type )
> +{
> +#ifdef CONFIG_HAS_MEM_PAGING
> +case XEN_VM_EVENT_TYPE_PAGING:
> +return _VPF_mem_paging;
> +#endif
> +case XEN_VM_EVENT_TYPE_MONITOR:
> +return _VPF_mem_access;
> +#ifdef CONFIG_HAS_MEM_SHARING
> +case XEN_VM_EVENT_TYPE_SHARING:
> +return _VPF_mem_sharing;
> +#endif
> +};
> +
> +ASSERT_UNREACHABLE();
> +return -1;
here
> +}
> +
> +#ifdef CONFIG_HAS_MEM_PAGING
> +static void mem_paging_notification(struct vcpu *v, unsigned int port);
> +#endif
> +static void monitor_notification(struct vcpu *v, unsigned int port);
> +#ifdef CONFIG_HAS_MEM_SHARING
> +static void mem_sharing_notification(struct vcpu *v, unsigned int port);
> +#endif
> +
> +static xen_event_channel_notification_t vm_event_notification_fn(uint32_t
> type)
> +{
> +switch( type )
> +{
> +#ifdef CONFIG_HAS_MEM_PAGING
> +case XEN_VM_EVENT_TYPE_PAGING:
> +return mem_paging_notification;
> +#endif
> +case XEN_VM_EVENT_TYPE_MONITOR:
> +return monitor_notification;
> +#ifdef CONFIG_HAS_MEM_SHARING
> +case XEN_VM_EVENT_TYPE_SHARING:
> +return mem_sharing_notification;
> +#endif
> +};
> +
> +ASSERT_UNREACHABLE();
> +return NULL;
and here
> +}
> +
> +/*
> + * VM event ring implementation;
> + */
Alex
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 07/10] vm_event: Add vm_event_ng interface
On 17.07.2019 14:38, Tamas K Lengyel wrote: >> I've omitted all style comments (formatting, plain vs unsigned int >> etc) - I'd like to leave that to the VM event maintainers. > > Do we have an automated way to check for style issues, like astyle? We don't; there is some work underway towards that, afaia. But to be honest, people should be looking at their code/patches before submitting. Then it at least would typically only be very few issues for reviewers to point out. But there were quite a few here. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC] x86emul: unconditionally deliver #UD for LWP insns
On 17.07.2019 13:42, Andrew Cooper wrote:
> On 17/07/2019 07:42, Jan Beulich wrote:
>> This is to accompany commit ("x86/svm: Drop support for AMD's
>
> 91f86f8634
Hmm, odd - I'm sure I had checked, resulting in the impression that
this didn't get committed yet.
>> Lightweight Profiling").
>>
>> Signed-off-by: Jan Beulich
> Acked-by: Andrew Cooper
>
>> ---
>> With AMD apparently having abandoned XOP encoded insns, another option
>> would seem to be to simply wire all unrecognized ones into #UD (rather
>> then returning UNIMPLEMENTED/UNRECOGNIZED).
>
> There are still some XOP instructions which actually work on Fam17h
> processors, if you ignore CPUID and go blindly executing.
>
> Given no official statement that XOP is dead, I'd keep the support we
> currently have.
Then my remark wasn't clear enough: I'm not suggesting to rip out
XOP insn support we have. I'm instead considering whether to wire
all unsupported XOP encodings into #UD (rather than return
UNIMPLEMENTED/UNRECOGNIZED for them), not just the LWP ones.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Design session report: Live-Updating Xen
On 17.07.2019 13:26, Andrew Cooper wrote: > On 17/07/2019 08:09, Jan Beulich wrote: >> On 17.07.2019 01:51, Andrew Cooper wrote: >>> On 15/07/2019 19:57, Foerster, Leonard wrote: * dom0less: bootstrap domains without the involvement of dom0 -> this might come in handy to at least setup and continue dom0 on target xen -> If we have this this might also enable us to de-serialize the state for other guest-domains in xen and not have to wait for dom0 to do this >>> Reconstruction of dom0 is something which Xen will definitely need to >>> do. With the memory still in place, its just a fairly small of register >>> state which needs restoring. >>> >>> That said, reconstruction of the typerefs will be an issue. Walking >>> over a fully populated L4 tree can (in theory) take minutes, and its not >>> safe to just start executing without reconstruction. >>> >>> Depending on how bad it is in practice, one option might be to do a >>> demand validate of %rip and %rsp, along with a hybrid shadow mode which >>> turns faults into typerefs, which would allow the gross cost of >>> revalidation to be amortised while the vcpus were executing. We would >>> definitely want some kind of logic to aggressively typeref outstanding >>> pagetables so the shadow mode could be turned off. >> Neither walking the page table trees nor and on-demand re-creation can >> possibly work, as pointed out during (partly informal) discussion: At >> the very least the allocated and pinned states of pages can only be >> transferred. > > Pinned state exists in the current migrate stream. Allocated does not - > it is an internal detail of how Xen handles the memory. > > But yes - this observation means that we can't simply walk the guest > pagetables. > >> Hence we seem to have come to agreement that struct >> page_info instances have to be transformed (in place if possible, i.e. >> when the sizes match, otherwise by copying). > > -10 to this idea, if it can possibly be avoided. In this case, it > definitely can be avoided. > > We do not want to be grovelling around in the old Xen's datastructures, > because that adds a binary A=>B translation which is > per-old-version-of-xen, meaning that you need a custom build of each > target Xen which depends on the currently-running Xen, or have to > maintain a matrix of old versions which will be dependent on the local > changes, and therefore not suitable for upstream. Now the question is what alternative you would suggest. By you saying "the pinned state lives in the migration stream", I assume you mean to imply that Dom0 state should be handed from old to new Xen via such a stream (minus raw data page contents)? -> We might have to go and re-inject certain interrupts >>> What hardware are you targeting here? IvyBridge and later has a posted >>> interrupt descriptor which can accumulate pending interrupts (at least >>> manually), and newer versions (Broadwell?) can accumulate interrupts >>> directly from hardware. >> For HVM/PVH perhaps that's good enough. What about PV though? > > What about PV? > > The in-guest evtchn data structure will accumulate events just like a > posted interrupt descriptor. Real interrupts will queue in the LAPIC > during the transition period. Yes, that'll work as long as interrupts remain active from Xen's POV. But if there's concern about a blackout period for HVM/PVH, then surely there would also be such for PV. A key cornerstone for Live-update is guest transparent live migration -> This means we are using a well defined ABI for saving/restoring domain state -> We do only rely on domain state and no internal xen state >>> Absolutely. One issue I discussed with David a while ago is that even >>> across an upgrade of Xen, the format of the EPT/NPT pagetables might >>> change, at least in terms of the layout of software bits. (Especially >>> for EPT where we slowly lose software bits to new hardware features we >>> wish to use.) >> Right, and therefore a similar transformation like for struct page_info >> may be unavoidable here too. > > None of that lives in the current migrate stream. Again - it is > internal details, so is not something which is appropriate to be > inspected by the target Xen. > >> Re-using large data structures (or arrays thereof) may also turn out >> useful in terms of latency until the new Xen actually becomes ready to >> resume. > > When it comes to optimising the latency, there is a fair amount we might > be able to do ahead of the critical region, but I still think this would > be better done in terms of a "clean start" in the new Xen to reduce > binary dependences. Latency actually is only one aspect (albeit the larger the host, the more relevant it is). Sufficient memory to have both old and new copies of the data structures in place, plus the migration stream, is another. This would especially
Re: [Xen-devel] [PATCH v2 3/5] x86/AMD: make C-state handling independent of Dom0
On 17.07.2019 12:26, Roger Pau Monné wrote:
> On Wed, Jul 17, 2019 at 09:04:55AM +, Jan Beulich wrote:
>> On 16.07.2019 16:26, Roger Pau Monné wrote:
>>> On Wed, Jul 03, 2019 at 01:01:48PM +, Jan Beulich wrote:
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -110,6 +110,8 @@ boolean_param("lapic_timer_c2_ok", local
struct acpi_processor_power *__read_mostly processor_powers[NR_CPUS];
+static int8_t __read_mostly vendor_override;
>>>
>>> AFAICT from the code below this is a tri-state (-1, 0, 1). Could it
>>> maybe be turned into an enum with definitions of the different
>>> states?
>>>
>>> I think it would make the usage clearer.
>>
>> Well, personally I prefer doing it this way for tristates. I'll
>> wait to see what others think.
>
> Ack, I think the code is correct hence:
>
> Reviewed-by: Roger Pau Monné
Thanks.
> But I personally would prefer an enum or at least a description of
> the meaning of the values vendor_override can take. IMO it would help
> understanding the code, since it's not obvious to me at first sight.
I've added
/*
* This field starts out as zero, and can be set to -1 just to signal it has
* been set (and that vendor specific logic has failed, and shouldn't be
* tried again), or to +1 to ignore Dom0 side uploads of C-state ACPI data.
*/
ahead of the definition.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 07/10] vm_event: Add vm_event_ng interface
> I've omitted all style comments (formatting, plain vs unsigned int > etc) - I'd like to leave that to the VM event maintainers. Do we have an automated way to check for style issues, like astyle? In my projects I integrate that into my Travis checks so I don't have to do that manually (see https://github.com/tklengyel/drakvuf/blob/master/.travis.yml#L28). Checking for that kind-of stuff manually is far from ideal. Tamas ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Design session report: Xen on Distros
On 17.07.2019 12:33, George Dunlap wrote: > >> On Jul 16, 2019, at 11:03 PM, Andrew Cooper >> >> We could trivially throw the fixes into the branch, tag it, sign it and >> throw it out into the open, but doing that on the embargo date itself >> would result in an official release of Xen which has had 0 testing in >> the incumbent test system. > > The point is that anyone who ships / deploys a fix on the disclosure date > is pretty much shipping exactly that. If it’s not good enough to sign, > why is it good enough to deploy? I think the security fixes themselves are good enough to deploy, perhaps with the assumption that consumers of our pre-disclosure list have done some testing on their own. The stable trees, however, contain more than just security fixes, and can have regressions (most likely due to backporting mistakes). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 12/15] docs: ABI: stable: make files ReST compatible
Several entries at the stable ABI files won't parse if we pass them directly to the ReST output. Adjust them, in order to allow adding their contents as-is at the stable ABI book. Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/stable/firewire-cdev| 4 + Documentation/ABI/stable/sysfs-acpi-pmprofile | 22 +++-- Documentation/ABI/stable/sysfs-bus-firewire | 3 + Documentation/ABI/stable/sysfs-bus-nvmem | 19 ++-- Documentation/ABI/stable/sysfs-bus-usb| 6 +- .../ABI/stable/sysfs-class-backlight | 1 + .../ABI/stable/sysfs-class-infiniband | 95 +-- Documentation/ABI/stable/sysfs-class-rfkill | 13 ++- Documentation/ABI/stable/sysfs-class-tpm | 90 +- Documentation/ABI/stable/sysfs-devices| 5 +- Documentation/ABI/stable/sysfs-driver-ib_srp | 1 + .../ABI/stable/sysfs-firmware-efi-vars| 4 + .../ABI/stable/sysfs-firmware-opal-dump | 5 + .../ABI/stable/sysfs-firmware-opal-elog | 2 + Documentation/ABI/stable/sysfs-hypervisor-xen | 3 + Documentation/ABI/stable/vdso | 5 +- Documentation/admin-guide/abi-stable.rst | 1 + 17 files changed, 179 insertions(+), 100 deletions(-) diff --git a/Documentation/ABI/stable/firewire-cdev b/Documentation/ABI/stable/firewire-cdev index f72ed653878a..c9e8ff026154 100644 --- a/Documentation/ABI/stable/firewire-cdev +++ b/Documentation/ABI/stable/firewire-cdev @@ -14,12 +14,14 @@ Description: Each /dev/fw* is associated with one IEEE 1394 node, which can be remote or local nodes. Operations on a /dev/fw* file have different scope: + - The 1394 node which is associated with the file: - Asynchronous request transmission - Get the Configuration ROM - Query node ID - Query maximum speed of the path between this node and local node + - The 1394 bus (i.e. "card") to which the node is attached to: - Isochronous stream transmission and reception - Asynchronous stream transmission and reception @@ -31,6 +33,7 @@ Description: manager - Query cycle time - Bus reset initiation, bus reset event reception + - All 1394 buses: - Allocation of IEEE 1212 address ranges on the local link layers, reception of inbound requests to such @@ -43,6 +46,7 @@ Description: userland implement different access permission models, some operations are restricted to /dev/fw* files that are associated with a local node: + - Addition of descriptors or directories to the local nodes' Configuration ROM - PHY packet transmission and reception diff --git a/Documentation/ABI/stable/sysfs-acpi-pmprofile b/Documentation/ABI/stable/sysfs-acpi-pmprofile index 964c7a8afb26..fd97d22b677f 100644 --- a/Documentation/ABI/stable/sysfs-acpi-pmprofile +++ b/Documentation/ABI/stable/sysfs-acpi-pmprofile @@ -6,17 +6,21 @@ Description: The ACPI pm_profile sysfs interface exports the platform power management (and performance) requirement expectations as provided by BIOS. The integer value is directly passed as retrieved from the FADT ACPI table. -Values: For possible values see ACPI specification: + +Values:For possible values see ACPI specification: 5.2.9 Fixed ACPI Description Table (FADT) Field: Preferred_PM_Profile Currently these values are defined by spec: - 0 Unspecified - 1 Desktop - 2 Mobile - 3 Workstation - 4 Enterprise Server - 5 SOHO Server - 6 Appliance PC - 7 Performance Server + + == = + 0 Unspecified + 1 Desktop + 2 Mobile + 3 Workstation + 4 Enterprise Server + 5 SOHO Server + 6 Appliance PC + 7 Performance Server >7 Reserved + == = diff --git a/Documentation/ABI/stable/sysfs-bus-firewire b/Documentation/ABI/stable/sysfs-bus-firewire index 41e5a0cd1e3e..9ac9eddb82ef 100644 --- a/Documentation/ABI/stable/sysfs-bus-firewire +++ b/Documentation/ABI/stable/sysfs-bus-firewire @@ -47,6 +47,7 @@ Description: IEEE 1394 node device attribute. Read-only and immutable. Values:1: The sysfs entry represents a local node (a controller card). +
Re: [Xen-devel] [PATCH v2 05/10] vm_event: Move struct vm_event_domain to vm_event.c
On Wed, 2019-07-17 at 09:31 +, Jan Beulich wrote: > On 16.07.2019 19:06, Petre Pircalabu wrote: > > The vm_event_domain members are not accessed outside vm_event.c so > > it's > > better to hide de implementation details. > > > > Signed-off-by: Petre Pircalabu > > Acked-by: Andrew Cooper > > Acked-by: Tamas K Lengyel > > --- > > xen/common/vm_event.c | 26 ++ > > xen/include/xen/sched.h | 26 +- > > 2 files changed, 27 insertions(+), 25 deletions(-) > > Ah, here it comes. This would better have been ahead of the other > change (where I did comment). > > Jan I will reorder the patches in the next iteration. Many thanks for your comments, Petre ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 07/10] vm_event: Add vm_event_ng interface
On Tue, 2019-07-16 at 15:13 -0600, Tamas K Lengyel wrote: > On Tue, Jul 16, 2019 at 11:06 AM Petre Pircalabu > wrote: > > > > In high throughput introspection scenarios where lots of monitor > > vm_events are generated, the ring buffer can fill up before the > > monitor > > application gets a chance to handle all the requests thus blocking > > other vcpus which will have to wait for a slot to become available. > > > > This patch adds support for a different mechanism to handle > > synchronous > > vm_event requests / responses. As each synchronous request pauses > > the > > vcpu until the corresponding response is handled, it can be stored > > in > > a slotted memory buffer (one per vcpu) shared between the > > hypervisor and > > the controlling domain. > > > > Signed-off-by: Petre Pircalabu > > So this is quite a large patch, perhaps it would be better to split > it > into a hypervisor-side patch and then a toolstack-side one. Also, > would it make sense to keep the two implementations in separate files > within Xen (ie. common/vm_event.c and vm_event_ng.c)? > > Tamas I thought about having 2 separate patches, one for hypervisor and one for libxc, but my main concern was not to break "git bisect"(I'm not sure if there are any tests (other than the build) which need to pass). The "flags" field was added to vm_event_op, and, if it's not manually set by the caller, an invalid value might be passed to XEN (e.g. xc_vm_event_control). Initially the new interface was contained in a separate file (has it's own domctl) but I've copied it to vm_event because I wanted to have all non-interface functions static. (e.g. the "enable" functions for both transports and vm_event_handle_response). However, I will look into this again, and, if I can find a clean way to minimize the dependencies, I will split it again. Many thanks, Petre ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC] x86emul: unconditionally deliver #UD for LWP insns
On 17/07/2019 07:42, Jan Beulich wrote:
> This is to accompany commit ("x86/svm: Drop support for AMD's
91f86f8634
> Lightweight Profiling").
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
> ---
> With AMD apparently having abandoned XOP encoded insns, another option
> would seem to be to simply wire all unrecognized ones into #UD (rather
> then returning UNIMPLEMENTED/UNRECOGNIZED).
There are still some XOP instructions which actually work on Fam17h
processors, if you ignore CPUID and go blindly executing.
Given no official statement that XOP is dead, I'd keep the support we
currently have.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v10 01/13] x86emul: support of AVX512* population count insns
On 17/07/2019 07:33, Jan Beulich wrote: > Plus the only other AVX512_BITALG one. > > As in a few cases before, since the insns here and in particular their > memory access patterns follow the usual scheme, I didn't think it was > necessary to add a contrived test specifically for them, beyond the > Disp8 scaling one. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Ping: [PATCH v2 1/4] x86/PV: tighten page table ownership check in emul-priv-op.c:read_cr()
On 17/07/2019 07:59, Jan Beulich wrote:
On 04.06.19 at 14:41, wrote:
>> Rather than checking that a page table is _not_ "owned" by the fake COW
>> domain, check that it's owned by the domain actually wanting to install
>> it.
>>
>> Switch away from BUG_ON() at the same time.
>>
>> Signed-off-by: Jan Beulich
> I've got Roger's R-b - any chance to get an ack here so it can go in?
I already replied, and while I've got the email in my sent messages, I
can't see any evidence of it being on the list. ISTR we were having
email troubles around that time.
Attached.
--- Begin Message ---
On 04/06/2019 13:41, Jan Beulich wrote:
> Rather than checking that a page table is _not_ "owned" by the fake COW
> domain, check that it's owned by the domain actually wanting to install
> it.
>
> Switch away from BUG_ON() at the same time.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Split out from larger patch to make further adjustments.
> ---
> Thinking about it I wonder why we have such a check here and no-where
> else. An alternative would seem to be to simply drop the BUG_ON().
Looking at the history, af909e7e1 added this BUG_ON() long with a load
of other COW/shared sanity checking, so it is quite possibly here out of
an abundance of paranoia.
I'd be happy taking this out entirely, but if you're going to keep this
patch, then...
>
> --- a/xen/arch/x86/pv/emul-priv-op.c
> +++ b/xen/arch/x86/pv/emul-priv-op.c
> @@ -723,8 +723,14 @@ static int read_cr(unsigned int reg, uns
> unmap_domain_page(pl4e);
> *val = compat_pfn_to_cr3(mfn_to_gmfn(currd, mfn_x(mfn)));
> }
> -/* PTs should not be shared */
> -BUG_ON(page_get_owner(mfn_to_page(mfn)) == dom_cow);
> +
> +/* PTs should be owned by their domains */
> +if ( page_get_owner(mfn_to_page(mfn)) != currd )
> +{
... I need to refresh my patches which disallow the use of
domain_crash() without a printk.
printk(XENLOG_G_ERR "%pv read cr3: mfn %"PRI_mfn" owner %pd != %pd\n" ...
With this printk (or something similar), or with the BUG_ON() removed
entirely, Reviewed-by: Andrew Cooper
~Andrew
--- End Message ---
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Design session report: Live-Updating Xen
On 17/07/2019 08:09, Jan Beulich wrote: > On 17.07.2019 01:51, Andrew Cooper wrote: >> On 15/07/2019 19:57, Foerster, Leonard wrote: >>> * dom0less: bootstrap domains without the involvement of dom0 >>> -> this might come in handy to at least setup and continue dom0 >>> on target xen >>> -> If we have this this might also enable us to de-serialize >>> the state for >>> other guest-domains in xen and not have to wait for >>> dom0 to do this >> Reconstruction of dom0 is something which Xen will definitely need to >> do. With the memory still in place, its just a fairly small of register >> state which needs restoring. >> >> That said, reconstruction of the typerefs will be an issue. Walking >> over a fully populated L4 tree can (in theory) take minutes, and its not >> safe to just start executing without reconstruction. >> >> Depending on how bad it is in practice, one option might be to do a >> demand validate of %rip and %rsp, along with a hybrid shadow mode which >> turns faults into typerefs, which would allow the gross cost of >> revalidation to be amortised while the vcpus were executing. We would >> definitely want some kind of logic to aggressively typeref outstanding >> pagetables so the shadow mode could be turned off. > Neither walking the page table trees nor and on-demand re-creation can > possibly work, as pointed out during (partly informal) discussion: At > the very least the allocated and pinned states of pages can only be > transferred. Pinned state exists in the current migrate stream. Allocated does not - it is an internal detail of how Xen handles the memory. But yes - this observation means that we can't simply walk the guest pagetables. > Hence we seem to have come to agreement that struct > page_info instances have to be transformed (in place if possible, i.e. > when the sizes match, otherwise by copying). -10 to this idea, if it can possibly be avoided. In this case, it definitely can be avoided. We do not want to be grovelling around in the old Xen's datastructures, because that adds a binary A=>B translation which is per-old-version-of-xen, meaning that you need a custom build of each target Xen which depends on the currently-running Xen, or have to maintain a matrix of old versions which will be dependent on the local changes, and therefore not suitable for upstream. >>> -> We might have to go and re-inject certain interrupts >> What hardware are you targeting here? IvyBridge and later has a posted >> interrupt descriptor which can accumulate pending interrupts (at least >> manually), and newer versions (Broadwell?) can accumulate interrupts >> directly from hardware. > For HVM/PVH perhaps that's good enough. What about PV though? What about PV? The in-guest evtchn data structure will accumulate events just like a posted interrupt descriptor. Real interrupts will queue in the LAPIC during the transition period. We obviously can't let interrupts be dropped, but there also shouldn't be any need to re-inject any. >>> A key cornerstone for Live-update is guest transparent live migration >>> -> This means we are using a well defined ABI for saving/restoring >>> domain state >>> -> We do only rely on domain state and no internal xen state >> Absolutely. One issue I discussed with David a while ago is that even >> across an upgrade of Xen, the format of the EPT/NPT pagetables might >> change, at least in terms of the layout of software bits. (Especially >> for EPT where we slowly lose software bits to new hardware features we >> wish to use.) > Right, and therefore a similar transformation like for struct page_info > may be unavoidable here too. None of that lives in the current migrate stream. Again - it is internal details, so is not something which is appropriate to be inspected by the target Xen. > Re-using large data structures (or arrays thereof) may also turn out > useful in terms of latency until the new Xen actually becomes ready to > resume. When it comes to optimising the latency, there is a fair amount we might be able to do ahead of the critical region, but I still think this would be better done in terms of a "clean start" in the new Xen to reduce binary dependences. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 09/10] xen-access: Code cleanup
On 16.07.2019 20:06, Petre Pircalabu wrote: > Cleanup xen-access code in accordance with the XEN style guide. > > Signed-off-by: Petre Pircalabu Reviewed-by: Alexandru Isaila ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 08/10] xen-access: Use getopt_long for cmdline parsing
On 16.07.2019 20:06, Petre Pircalabu wrote: > This simplifies the command line parsing logic and makes it easier to > add new test parameters. > > Signed-off-by: Petre Pircalabu Reviewed-by: Alexandru Isaila ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 04/10] vm_event: Simplify vm_event interface
On 16.07.2019 20:06, Petre Pircalabu wrote: > Remove the domain reference from calls to vm_event interface function > and use the backpointer from vm_event_domain. > > Affected functions: > - __vm_event_claim_slot / vm_event_claim_slot / vm_event_claim_slot_nosleep > - vm_event_cancel_slot > - vm_event_put_request > > Signed-off-by: Petre Pircalabu Reviewed-by: Alexandru Isaila ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 14/20] docs: ABI: stable: make files ReST compatible
Several entries at the stable ABI files won't parse if we pass them directly to the ReST output. Adjust them, in order to allow adding their contents as-is at the stable ABI book. Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/stable/firewire-cdev| 4 + Documentation/ABI/stable/sysfs-acpi-pmprofile | 22 +++-- Documentation/ABI/stable/sysfs-bus-firewire | 3 + Documentation/ABI/stable/sysfs-bus-nvmem | 19 ++-- Documentation/ABI/stable/sysfs-bus-usb| 6 +- .../ABI/stable/sysfs-class-backlight | 1 + .../ABI/stable/sysfs-class-infiniband | 95 +-- Documentation/ABI/stable/sysfs-class-rfkill | 13 ++- Documentation/ABI/stable/sysfs-class-tpm | 90 +- Documentation/ABI/stable/sysfs-devices| 5 +- Documentation/ABI/stable/sysfs-driver-ib_srp | 1 + .../ABI/stable/sysfs-firmware-efi-vars| 4 + .../ABI/stable/sysfs-firmware-opal-dump | 5 + .../ABI/stable/sysfs-firmware-opal-elog | 2 + Documentation/ABI/stable/sysfs-hypervisor-xen | 3 + Documentation/ABI/stable/vdso | 5 +- 16 files changed, 178 insertions(+), 100 deletions(-) diff --git a/Documentation/ABI/stable/firewire-cdev b/Documentation/ABI/stable/firewire-cdev index f72ed653878a..c9e8ff026154 100644 --- a/Documentation/ABI/stable/firewire-cdev +++ b/Documentation/ABI/stable/firewire-cdev @@ -14,12 +14,14 @@ Description: Each /dev/fw* is associated with one IEEE 1394 node, which can be remote or local nodes. Operations on a /dev/fw* file have different scope: + - The 1394 node which is associated with the file: - Asynchronous request transmission - Get the Configuration ROM - Query node ID - Query maximum speed of the path between this node and local node + - The 1394 bus (i.e. "card") to which the node is attached to: - Isochronous stream transmission and reception - Asynchronous stream transmission and reception @@ -31,6 +33,7 @@ Description: manager - Query cycle time - Bus reset initiation, bus reset event reception + - All 1394 buses: - Allocation of IEEE 1212 address ranges on the local link layers, reception of inbound requests to such @@ -43,6 +46,7 @@ Description: userland implement different access permission models, some operations are restricted to /dev/fw* files that are associated with a local node: + - Addition of descriptors or directories to the local nodes' Configuration ROM - PHY packet transmission and reception diff --git a/Documentation/ABI/stable/sysfs-acpi-pmprofile b/Documentation/ABI/stable/sysfs-acpi-pmprofile index 964c7a8afb26..fd97d22b677f 100644 --- a/Documentation/ABI/stable/sysfs-acpi-pmprofile +++ b/Documentation/ABI/stable/sysfs-acpi-pmprofile @@ -6,17 +6,21 @@ Description: The ACPI pm_profile sysfs interface exports the platform power management (and performance) requirement expectations as provided by BIOS. The integer value is directly passed as retrieved from the FADT ACPI table. -Values: For possible values see ACPI specification: + +Values:For possible values see ACPI specification: 5.2.9 Fixed ACPI Description Table (FADT) Field: Preferred_PM_Profile Currently these values are defined by spec: - 0 Unspecified - 1 Desktop - 2 Mobile - 3 Workstation - 4 Enterprise Server - 5 SOHO Server - 6 Appliance PC - 7 Performance Server + + == = + 0 Unspecified + 1 Desktop + 2 Mobile + 3 Workstation + 4 Enterprise Server + 5 SOHO Server + 6 Appliance PC + 7 Performance Server >7 Reserved + == = diff --git a/Documentation/ABI/stable/sysfs-bus-firewire b/Documentation/ABI/stable/sysfs-bus-firewire index 41e5a0cd1e3e..9ac9eddb82ef 100644 --- a/Documentation/ABI/stable/sysfs-bus-firewire +++ b/Documentation/ABI/stable/sysfs-bus-firewire @@ -47,6 +47,7 @@ Description: IEEE 1394 node device attribute. Read-only and immutable. Values:1: The sysfs entry represents a local node (a controller card). + 0: The sysfs entry represents a remote node. @@
Re: [Xen-devel] Design session report: Xen on Distros
> On Jul 16, 2019, at 11:03 PM, Andrew Cooper > > We could trivially throw the fixes into the branch, tag it, sign it and > throw it out into the open, but doing that on the embargo date itself > would result in an official release of Xen which has had 0 testing in > the incumbent test system. The point is that anyone who ships / deploys a fix on the disclosure date is pretty much shipping exactly that. If it’s not good enough to sign, why is it good enough to deploy? Probably the best answer is that it’s _not_ really good enough to deploy; and so it’s worth thinking about how we can improve that, perhaps by having embargoed osstest runs or something. > What a number of people want is for the patches in an XSA advisory to > apply cleanly to whatever random thing they have in their local/distro > patch queue. This is entirely impossible for the security to arrange, > and furthermore, we have exactly one location where the patches we > produce will be committed. I’m not sure people want to apply “wherever”; it’s more that there wasn’t a clear place that they *could* apply. Without any prior knowledge, I think the most natural expectation would be that you could take the most recent point release and just stack on all the outstanding XSAs since then. There are reasons why we don’t do that, but I wouldn’t expect users to guess that. This is the sort of area where maybe a document in your sphinx system would be helpful, just to lay out the issues. > As a personal view here, I don't think blindly taking the latest > staging-$X.$Y is a viable substitute for at least understanding the > patches well enough to work around trivial offsets/fuzz due to minor > variations. I think this is fine for downstreams that have full-fledged hypervisor development teams (like XenServer or Amazon), but is a bit too high a barrier for "mom-and-pop" cloud providers or community-maintained distributions. -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/5] x86/AMD: make C-state handling independent of Dom0
On Wed, Jul 17, 2019 at 09:04:55AM +, Jan Beulich wrote:
> On 16.07.2019 16:26, Roger Pau Monné wrote:
> > On Wed, Jul 03, 2019 at 01:01:48PM +, Jan Beulich wrote:
> >> --- a/xen/arch/x86/acpi/cpu_idle.c
> >> +++ b/xen/arch/x86/acpi/cpu_idle.c
> >> @@ -110,6 +110,8 @@ boolean_param("lapic_timer_c2_ok", local
> >>
> >>struct acpi_processor_power *__read_mostly processor_powers[NR_CPUS];
> >>
> >> +static int8_t __read_mostly vendor_override;
> >
> > AFAICT from the code below this is a tri-state (-1, 0, 1). Could it
> > maybe be turned into an enum with definitions of the different
> > states?
> >
> > I think it would make the usage clearer.
>
> Well, personally I prefer doing it this way for tristates. I'll
> wait to see what others think.
Ack, I think the code is correct hence:
Reviewed-by: Roger Pau Monné
But I personally would prefer an enum or at least a description of
the meaning of the values vendor_override can take. IMO it would help
understanding the code, since it's not obvious to me at first sight.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 6/6] tools/libxc: add wrapper for PHYSDEVOP_msi_control
On Wed, Jul 17, 2019 at 03:00:44AM +0200, Marek Marczykowski-Górecki wrote: > Add libxc wrapper for PHYSDEVOP_msi_control introduced in previous > commit. > > Signed-off-by: Marek Marczykowski-Górecki LGTM, albeit I find the usage of int instead of unsigned int for the SBDF kind of weird, but it's inline with the other functions, so I guess there's a reason for it? I assume this will be used by an upcoming QEMU patch? Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 5/6] xen/x86: add PHYSDEVOP_msi_control
On Wed, Jul 17, 2019 at 03:00:43AM +0200, Marek Marczykowski-Górecki wrote:
> Allow device model running in stubdomain to enable/disable MSI(-X),
> bypassing pciback. While pciback is still used to access config space
> from within stubdomain, it refuse to write to
> PCI_MSI_FLAGS_ENABLE/PCI_MSIX_FLAGS_ENABLE in non-permissive mode. Which
> is the right thing to do for PV domain (the main use case for pciback),
> as PV domain should use XEN_PCI_OP_* commands for that. Unfortunately
> those commands are not good for stubdomain use, as they configure MSI in
> dom0's kernel too, which should not happen for HVM domain.
>
> This new physdevop is allowed only for stubdomain controlling the domain
> which own the device.
I think I'm missing that part, is this maybe done by the XSM stuff?
>
> Signed-off-by: Marek Marczykowski-Górecki
> ---
> Changes in v3:
> - new patch
> Changes in v4:
> - adjust code style
> - s/msi_msix/msi/
> - add msi_set_enable XSM hook
> - flatten struct physdev_msi_set_enable
> - add to include/xlat.lst
> Changes in v5:
> - rename to PHYSDEVOP_msi_control
> - combine "mode" and "enable" into "flags"
> - refuse to enable both MSI and MSI-X, and also to enable MSI(-X) on
>incapable device
> - disable/enable INTx when enabling/disabling MSI (?)
You don't enable INTx when MSI is disabled.
> - refuse if !use_msi
> - adjust flask hook to make more sense (require "setup" access on
>device, not on domain)
> - rebase on master
>
> I'm not sure if XSM part is correct, compile-tested only, as I'm not
> sure how to set the policy.
I'm also not familiar with XSM, so I will have to defer to Daniel on
this one.
> ---
> xen/arch/x86/msi.c | 42 ++-
> xen/arch/x86/physdev.c | 25 ++-
> xen/arch/x86/x86_64/physdev.c | 4 +++-
> xen/include/asm-x86/msi.h | 1 +-
> xen/include/public/physdev.h| 16 +++-
> xen/include/xlat.lst| 1 +-
> xen/include/xsm/dummy.h | 7 +-
> xen/include/xsm/xsm.h | 6 -
> xen/xsm/dummy.c | 1 +-
> xen/xsm/flask/hooks.c | 24 +-
> xen/xsm/flask/policy/access_vectors | 1 +-
> 11 files changed, 128 insertions(+)
>
> diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
> index 89e6116..fca1d04 100644
> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -1475,6 +1475,48 @@ int pci_restore_msi_state(struct pci_dev *pdev)
> return 0;
> }
>
> +int msi_control(struct pci_dev *pdev, bool msix, bool enable)
> +{
> +int ret;
> +struct msi_desc *old_desc;
> +
> +if ( !use_msi )
> +return -EOPNOTSUPP;
> +
> +ret = xsm_msi_control(XSM_DM_PRIV, pdev->domain, pdev->sbdf.sbdf, msix,
> enable);
> +if ( ret )
> +return ret;
> +
> +if ( msix )
> +{
> +if ( !pdev->msix )
> +return -ENODEV;
> +old_desc = find_msi_entry(pdev, -1, PCI_CAP_ID_MSI);
> +if ( old_desc )
> +return -EBUSY;
> +if ( enable )
> +pci_intx(pdev, false);
> +msix_set_enable(pdev, enable);
> +}
> +else
> +{
> +if ( !pci_find_cap_offset(pdev->seg,
> + pdev->bus,
> + PCI_SLOT(pdev->devfn),
> + PCI_FUNC(pdev->devfn),
> + PCI_CAP_ID_MSI) )
> +return -ENODEV;
> +old_desc = find_msi_entry(pdev, -1, PCI_CAP_ID_MSIX);
> +if ( old_desc )
> +return -EBUSY;
> +if ( enable )
> +pci_intx(pdev, false);
> +msi_set_enable(pdev, enable);
> +}
I think you could just do:
unsigned int cap = msix ? PCI_CAP_ID_MSIX : PCI_CAP_ID_MSI;
[...]
if ( !pci_find_cap_offset(pdev->seg,
pdev->bus,
PCI_SLOT(pdev->devfn),
PCI_FUNC(pdev->devfn), cap) )
return -ENODEV;
old_desc = find_msi_entry(pdev, -1, cap);
if ( old_desc )
return -EBUSY;
if ( enable )
{
pci_intx(pdev, false);
if ( msix )
msi_set_enable(pdev, false);
else
msix_set_enable(pdev, false);
}
if ( msix )
msix_set_enable(pdev, enable);
else
msi_set_enable(pdev, enable);
Note that in the same way you make sure INTx is disabled, you should
also make sure MSI and MSI-X are not enabled at the same time.
> +
> +return 0;
> +}
> +
> void __init early_msi_init(void)
> {
> if ( use_msi < 0 )
> diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
> index 3a3c158..5000998 100644
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -662,6 +662,31 @@ ret_t do_physdev_op(int cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> break;
> }
>
> +case PHYSDEVOP_msi_control: {
> +struct physdev_msi_control op;
> +struct pci_dev *pdev;
> +
> +
Re: [Xen-devel] [PATCH] x86/mm: Provide more useful information in diagnostics
On 16.07.2019 19:28, Andrew Cooper wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -1407,7 +1407,8 @@ static int alloc_l1_table(struct page_info *page)
> return 0;
>
>fail:
> -gdprintk(XENLOG_WARNING, "Failure in alloc_l1_table: slot %#x\n", i);
> +gdprintk(XENLOG_WARNING,
> + "Failure in alloc_l1_table: slot %#x, ret %d\n", i, ret);
To make it slightly less output without losing information, in cases
like this I generally prefer "Failure %d in alloc_l1_table: slot %#x\n".
Seeing ...
> @@ -1505,7 +1506,8 @@ static int alloc_l2_table(struct page_info *page,
> unsigned long type)
> }
> else if ( rc < 0 && rc != -EINTR )
> {
> -gdprintk(XENLOG_WARNING, "Failure in alloc_l2_table: slot
> %#x\n", i);
> +gdprintk(XENLOG_WARNING,
> + "Failure in alloc_l2_table: slot %#x, rc %d\n", i, rc);
... this for comparison it is, imo, not relevant to actually have names
of local variables in logged messages.
Preferably with this adjusted
Acked-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 07/10] vm_event: Add vm_event_ng interface
On 16.07.2019 19:06, Petre Pircalabu wrote:
> +static void vm_event_channels_free_buffer(struct vm_event_channels_domain
> *impl)
> {
> -vm_event_ring_resume(to_ring(v->domain->vm_event_monitor));
> +int i;
> +
> +vunmap(impl->slots);
> +impl->slots = NULL;
> +
> +for ( i = 0; i < impl->nr_frames; i++ )
> +free_domheap_page(mfn_to_page(impl->mfn[i]));
> }
What guarantees that there are no mappings left of the pages you free
here? Sharing pages with guests is (so far) an (almost) irreversible
action, i.e. they may generally only be freed upon domain destruction.
See gnttab_unpopulate_status_frames() for a case where we actually
make an attempt at freeing such pages (but where we fail the request
in case references are left in place).
Furthermore, is there any guarantee that the pages you free here
were actually allocated? ->nr_frames gets set ahead of the actual
allocation.
> +int vm_event_ng_get_frames(struct domain *d, unsigned int id,
> + unsigned long frame, unsigned int nr_frames,
> + xen_pfn_t mfn_list[])
> +{
> +struct vm_event_domain *ved;
> +int i;
> +
> +switch (id )
> +{
> +case XEN_VM_EVENT_TYPE_MONITOR:
> +ved = d->vm_event_monitor;
> +break;
> +
> +default:
> +return -ENOSYS;
Various other error codes might be fine here, but ENOSYS is not
(despite pre-existing misuse elsewhere in the tree).
> +}
> +
> +if ( !vm_event_check(ved) )
> +return -EINVAL;
> +
> +if ( frame != 0 || nr_frames != to_channels(ved)->nr_frames )
> +return -EINVAL;
Is there a particular reason for this all-or-nothing model?
> +spin_lock(>lock);
> +
> +for ( i = 0; i < to_channels(ved)->nr_frames; i++ )
> +mfn_list[i] = mfn_x(to_channels(ved)->mfn[i]);
> +
> +spin_unlock(>lock);
What is the locking good for here? You obviously can't be afraid of
the values becoming stale, as they surely would be by the time the
caller gets to see them (if they can go stale in the first place).
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -38,7 +38,7 @@
> #include "hvm/save.h"
> #include "memory.h"
>
> -#define XEN_DOMCTL_INTERFACE_VERSION 0x0011
> +#define XEN_DOMCTL_INTERFACE_VERSION 0x0012
This looks to be needed only because of ...
> @@ -781,12 +781,20 @@ struct xen_domctl_gdbsx_domstatus {
> struct xen_domctl_vm_event_op {
> uint32_t op; /* XEN_VM_EVENT_* */
> uint32_t type; /* XEN_VM_EVENT_TYPE_* */
> + /* Use the NG interface */
> +#define _XEN_VM_EVENT_FLAGS_NG_OP 0
> +#define XEN_VM_EVENT_FLAGS_NG_OP (1U << _XEN_VM_EVENT_FLAGS_NG_OP)
> +uint32_t flags;
... this addition. Is the new field really warranted here? Can't
you e.g. simply define a new set of ops (e.g. by setting their
high bits)?
I've omitted all style comments (formatting, plain vs unsigned int
etc) - I'd like to leave that to the VM event maintainers.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-xsm
branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-xsm testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.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/torvalds/linux-2.6.git Bug introduced: 1d039859330b874d48080885eb31f4f129c246f1 Bug not present: 249155c20f9b0754bc1b932a33344cfb4e0c2101 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/139081/ (Revision log too long, omitted.) For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-amd64-xl-xsm.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-linus/test-amd64-amd64-xl-xsm.xen-boot --summary-out=tmp/139081.bisection-summary --basis-template=133580 --blessings=real,real-bisect linux-linus test-amd64-amd64-xl-xsm xen-boot Searching for failure / basis pass: 139003 fail [host=italia0] / 138849 [host=chardonnay1] 138813 [host=albana0] 138780 [host=italia1] 138754 [host=albana1] 138735 [host=fiano0] 138710 [host=baroque1] 138680 [host=baroque0] 138661 [host=debina1] 138639 [host=godello0] 138612 [host=godello1] 138584 [host=debina0] 138488 ok. Failure / basis pass flights: 139003 / 138488 (tree with no url: minios) Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Latest 1d039859330b874d48080885eb31f4f129c246f1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 55b9bbf40a1cf9788dd6a7b093851076851fc670 d0d8ad39ecb51cd7497cd524484fe09f50876798 9cca02d8ffc23e9688a971d858e4ffdff5389b11 30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 38eeb3864de40aa568c48f9f26271c141c62b50b Basis pass 249155c20f9b0754bc1b932a33344cfb4e0c2101 c530a75c1e6a472b0eb9558310b518f0dfcd8860 719a684d7df1b5b5627f42447be4f12aab038343 d0d8ad39ecb51cd7497cd524484fe09f50876798 9cca02d8ffc23e9688a971d858e4ffdff5389b11 6e56ed129c9782ba050a5fbfbf4ac12335b230f7 f3d8eef9091747e70c505094f63514b43329a922 Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#249155c20f9b0754bc1b932a33344cfb4e0c2101-1d039859330b874d48080885eb31f4f129c246f1 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/osstest/ovmf.git#719a684d7df1b5b5627f42447be4f12aab038343-55b9bbf40a1cf9788dd6a7b093851076851fc670 git://xenbits.xen.org/qemu-xen-traditional.\ git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798 git://xenbits.xen.org/qemu-xen.git#9cca02d8ffc23e9688a971d858e4ffdff5389b11-9cca02d8ffc23e9688a971d858e4ffdff5389b11 git://xenbits.xen.org/osstest/seabios.git#6e56ed129c9782ba050a5fbfbf4ac12335b230f7-30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 git://xenbits.xen.org/xen.git#f3d8eef9091747e70c505094f63514b43329a922-38eeb3864de40aa568c48f9f26271c141c62b50b adhoc-revtuple-generator: tree discontiguous: linux-2.6 From git://cache:9419/git://xenbits.xen.org/xen 38eeb3864d..08b084ab48 coverity-tested/smoke -> origin/coverity-tested/smoke Loaded 3002 nodes in revision graph Searching for test results: 138245 [host=albana1] 138386 [host=albana0] 138488 pass 249155c20f9b0754bc1b932a33344cfb4e0c2101 c530a75c1e6a472b0eb9558310b518f0dfcd8860 719a684d7df1b5b5627f42447be4f12aab038343 d0d8ad39ecb51cd7497cd524484fe09f50876798 9cca02d8ffc23e9688a971d858e4ffdff5389b11 6e56ed129c9782ba050a5fbfbf4ac12335b230f7 f3d8eef9091747e70c505094f63514b43329a922 138584 [host=debina0] 138612 [host=godello1] 138639 [host=godello0] 138661 [host=debina1] 138680 [host=baroque0] 138710 [host=baroque1] 138735 [host=fiano0] 138754 [host=albana1] 138780 [host=italia1] 138813 [host=albana0] 138849 [host=chardonnay1] 138878 fail irrelevant 138902 fail irrelevant 138962 fail irrelevant 139003 fail 1d039859330b874d48080885eb31f4f129c246f1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 55b9bbf40a1cf9788dd6a7b093851076851fc670 d0d8ad39ecb51cd7497cd524484fe09f50876798 9cca02d8ffc23e9688a971d858e4ffdff5389b11 30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 38eeb3864de40aa568c48f9f26271c141c62b50b 139060
Re: [Xen-devel] [PATCH v2 01/10] vm_event: Define VM_EVENT type
On Wed, 2019-07-17 at 11:49 +0300, Alexandru Stefan ISAILA wrote:
>
> On 16.07.2019 20:06, Petre Pircalabu wrote:
> > @@ -1004,7 +942,7 @@ struct xen_domctl_psr_cmt_op {
> >* Enable/disable monitoring various VM events.
> >* This domctl configures what events will be reported to helper
> > apps
> >* via the ring buffer "MONITOR". The ring has to be first
> > enabled
> > - * with the domctl XEN_DOMCTL_VM_EVENT_OP_MONITOR.
> > + * with XEN_VM_EVENT_ENABLE.
>
> The above comment should also be adjusted.
>
> >*
> >* GET_CAPABILITIES can be used to determine which of these
> > features is
> >* available on a given platform.
>
> Alex
Thank for noticing that. I will correct it on the next patchset
iteration.
Petre
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 4/6] xen/x86: Allow stubdom access to irq created for msi.
On Wed, Jul 17, 2019 at 03:00:42AM +0200, Marek Marczykowski-Górecki wrote:
> Stubdomains need to be given sufficient privilege over the guest which it
> provides emulation for in order for PCI passthrough to work correctly.
> When a HVM domain try to enable MSI, QEMU in stubdomain calls
> PHYSDEVOP_map_pirq, but later it needs to call XEN_DOMCTL_bind_pt_irq as
> part of xc_domain_update_msi_irq. Allow for that as part of
> PHYSDEVOP_map_pirq.
>
> This is not needed for PCI INTx, because IRQ in that case is known
> beforehand and the stubdomain is given permissions over this IRQ by
> libxl__device_pci_add (there's a do_pci_add against the stubdomain).
>
> create_irq() already grant IRQ access to hardware_domain, with
> assumption the device model (something managing this IRQ) lives there.
> Modify create_irq() to take additional parameter pointing at device
> model domain - which may be dom0 or stubdomain. Save ID of the domain
> given permission, to revoke it in destroy_irq() - easier and cleaner
> than replaying logic of create_irq() parameter. Use domid instead of
> actual reference to the domain, because it might get destroyed before
> destroying IRQ (stubdomain is destroyed before its target domain). And
> it is not an issue, because IRQ permissions live within domain
> structure, so destroying a domain also implicitly revoke the permission.
> Potential domid reuse is detected by by checking if that domain does
> have permission over the IRQ being destroyed.
>
> Then, adjust all callers to provide the parameter. In case of calls not
> related to stubdomain-initiated allocations, give it either
> hardware_domain (so the behavior is unchanged there), or NULL for
> interrupts used by Xen internally.
>
> Inspired by
> https://github.com/OpenXT/xenclient-oe/blob/5e0e7304a5a3c75ef01240a1e3673665b2aaf05e/recipes-extended/xen/files/stubdomain-msi-irq-access.patch
> by Eric Chanudet .
>
> Signed-off-by: Simon Gaiser
> Signed-off-by: Marek Marczykowski-Górecki
> ---
> Changes in v3:
> - extend commit message
> Changes in v4:
> - add missing destroy_irq on error path
> Changes in v5:
> - move irq_{grant,revoke}_access() to {create,destroy}_irq(), which
>basically make it a different patch
> - add get_dm_domain() helper
> - do not give hardware_domain permission over IRQs used in Xen
>internally
> - rename create_irq argument to just 'd', to avoid confusion
>when it's called by hardware domain
> - verify that device is de-assigned before pci_remove_device call
> - save ID of domain given permission in create_irq(), to revoke it in
> destroy_irq()
> - drop domain parameter from destroy_irq() and msi_free_irq()
> - do not give hardware domain permission over IRQ created in
> iommu_set_interrupt()
> ---
> xen/arch/x86/hpet.c | 3 +-
> xen/arch/x86/irq.c | 51 ++---
> xen/common/irq.c | 1 +-
> xen/drivers/char/ns16550.c | 2 +-
> xen/drivers/passthrough/amd/iommu_init.c | 2 +-
> xen/drivers/passthrough/pci.c| 3 +-
> xen/drivers/passthrough/vtd/iommu.c | 3 +-
> xen/include/asm-x86/irq.h| 2 +-
> xen/include/xen/irq.h| 1 +-
> 9 files changed, 50 insertions(+), 18 deletions(-)
>
> diff --git a/xen/arch/x86/hpet.c b/xen/arch/x86/hpet.c
> index 4b08488..b4854ff 100644
> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -368,7 +369,7 @@ static int __init hpet_assign_irq(struct
> hpet_event_channel *ch)
> {
> int irq;
>
> -if ( (irq = create_irq(NUMA_NO_NODE)) < 0 )
> +if ( (irq = create_irq(NUMA_NO_NODE, hardware_domain)) < 0 )
Shouldn't this be NULL? I don't think the hardware domain should be
allowed to play with the HPET IRQs?
> return irq;
>
> ch->msi.irq = irq;
> diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
> index 2cac28a..dc5d302 100644
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -164,10 +164,21 @@ int __init bind_irq_vector(int irq, int vector, const
> cpumask_t *cpu_mask)
> return ret;
> }
>
> +static struct domain *get_dm_domain(struct domain *d)
^ const
> +{
> +return current->domain->target == d ? current->domain : hardware_domain;
> +}
> +
> /*
> * Dynamic irq allocate and deallocation for MSI
> */
> -int create_irq(nodeid_t node)
> +
> +/*
> + * create_irq - allocate irq for MSI
> + * @d domain that will get permission over the allocated irq; this permission
> + * will automatically be revoked on destroy_irq
> + */
> +int create_irq(nodeid_t node, struct domain *d)
> {
> int irq, ret;
> struct irq_desc *desc;
> @@ -200,18 +211,24 @@ int create_irq(nodeid_t node)
> desc->arch.used = IRQ_UNUSED;
> irq = ret;
> }
I would assert that
[Xen-devel] [xen-unstable-coverity test] 139083: all pass - PUSHED
flight 139083 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/139083/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 08b084ab48738040e34032ffb42387d88619bf1b baseline version: xen 38eeb3864de40aa568c48f9f26271c141c62b50b Last test of basis 138988 2019-07-14 09:18:26 Z3 days Testing same since 139083 2019-07-17 09:19:24 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich Julien Grall Paul Durrant Roger Pau Monné Viktor Mitin Viktor Mitin jobs: coverity-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 38eeb3864d..08b084ab48 08b084ab48738040e34032ffb42387d88619bf1b -> coverity-tested/smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Design session report: Xen on Distros
Hi, On 7/15/19 4:42 PM, George Dunlap wrote: > On 7/15/19 3:23 PM, Jan Beulich wrote: >> On 15.07.2019 16:11, George Dunlap wrote: >>> There was a long discussion about security patches, with the general >>> proposal being that we should cut a point release for every security issue. >> >> Interesting. Looks like in politics that until a decision fits people >> they keep re-raising the point. Iirc on a prior meeting (Budapest?) >> we had settled on continuing with the current scheme. Were there any >> new arguments towards this alternative model? > > Well I don't know if there were any new arguments because I don't > immediately remember the old discussion. Do we have a summary of the > discussion in Budapest, with its conclusions, anywhere? > > The basic idea was that: > > 1. Most distros / packagers are going to want to do an immediate release > anyway. > > 2. Distros generally seemed to be rebasing on top of staging as soon as > the XSA went out anyway (and ISTR this being the recommeneded course of > action) FYI, In Debian, we only ship the stable branch, not the staging branch. Better safe than sorry. And yes, this means there's a delay, and it's not immediate, etc. Well, at least since I have been involved. In the past security update packages were made by applying patches manually on top of older (like, 4.4.1 instead of 4.4.x) frozen versions, but we decided that "trying to assemble our own subset of the patches is riskier than taking upstream's collection". The Debian Release Team allows us to upload newer upstream versions during a security upload for Xen, which is officially not allowed in Debian stable. One of the things that obviously help with being able to keep doing this is the "track record" of the quality (expecially regression testing) of the stable-4.x branches. Currently, our package versions mostly look like e.g. 4.11.1+92-g6c33308a8d-1, instead of a nice simple version number. For me this is fine, but I can understand that for an end user it would just look nicer (and feel better perception-wise) to get a 4.11.x package. So just for that reason I would be all +1 for more tagged releases. > So for all intents and purposes, we have something which is, in fact, a > release; all it's missing is a signed tag and a tarball. > > Obviously there are testing implications that would need to be sorted > out before this could become a reality. > > In any case, the ball is in the court of "VOLUNTEER" to write up a > concrete proposal which could be discussed. You'll be able to raise all > your concerns at that point if you want (although having a sketch would > of course be helpful for whoever is writing such a proposal). Hans ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 05/10] vm_event: Move struct vm_event_domain to vm_event.c
On 16.07.2019 19:06, Petre Pircalabu wrote: > The vm_event_domain members are not accessed outside vm_event.c so it's > better to hide de implementation details. > > Signed-off-by: Petre Pircalabu > Acked-by: Andrew Cooper > Acked-by: Tamas K Lengyel > --- > xen/common/vm_event.c | 26 ++ > xen/include/xen/sched.h | 26 +- > 2 files changed, 27 insertions(+), 25 deletions(-) Ah, here it comes. This would better have been ahead of the other change (where I did comment). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 03/10] vm_event: Add 'struct domain' backpointer to vm_event_domain.
On 16.07.2019 19:06, Petre Pircalabu wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -279,6 +279,8 @@ struct vcpu
> /* VM event */
> struct vm_event_domain
> {
> +/* Domain reference */
> +struct domain *d;
> spinlock_t lock;
> /* The ring has 64 entries */
> unsigned char foreign_producers;
This structure should actually move out of here, now that it
has been only pointers which other structures in this header
use. Doing so would simplify the process of getting acks for
changes like this one.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 00/10] Per vcpu vm_event channels
On Tue, 2019-07-16 at 14:45 -0600, Tamas K Lengyel wrote: > On Tue, Jul 16, 2019 at 11:06 AM Petre Pircalabu > wrote: > > > > This patchset adds a new mechanism of sending synchronous vm_event > > requests and handling vm_event responses without using a ring. > > As each synchronous request pauses the vcpu until the corresponding > > response is handled, it can be stored in a slotted memory buffer > > (one per vcpu) shared between the hypervisor and the controlling > > domain. > > > > The main advantages of this approach are: > > * the ability to dynamicaly allocate the necessary memory used to > > hold > > the requests/responses (the size of > > vm_event_request_t/vm_event_response_t > > can grow unrestricted by the ring's one page limitation) > > * the ring's waitqueue logic is unnecessary in this case because > > the > > vcpu sending the request is blocked until a response is received. > > Could you please push a git branch for this somewhere? > > Thanks, > Tamas I've pushed this changes to my github xen fork: https://github.com/petrepircalabu/xen/tree/vm_event_ng/devel The tag for patchset is per_cpu_vm_event_channels_v2. Many thanks for your support, Petre ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 5/5] tools/libxc: allow controlling the max C-state sub-state
On 16.07.2019 17:06, Roger Pau Monné wrote:
> On Wed, Jul 03, 2019 at 01:04:13PM +, Jan Beulich wrote:
>> --- a/tools/misc/xenpm.c
>> +++ b/tools/misc/xenpm.c
>> @@ -64,7 +64,9 @@ void show_help(void)
>>" set-sched-smt enable|disable enable/disable
>> scheduler smt power saving\n"
>>" set-vcpu-migration-delay set scheduler vcpu
>> migration delay in us\n"
>>" get-vcpu-migration-delayget scheduler vcpu
>> migration delay\n"
>> -" set-max-cstate|'unlimited' set the C-State
>> limitation ( >= 0)\n"
>> +" set-max-cstate
>> |'unlimited'[,|'unlimited']\n"
The comma here is wrong, ...
>> @@ -1120,13 +1130,17 @@ void get_vcpu_migration_delay_func(int a
>>
>>void set_max_cstate_func(int argc, char *argv[])
>>{
>> -int value;
>> +int value, subval = XEN_SYSCTL_CX_UNLIMITED;
>>char buf[12];
>>
>> -if ( argc != 1 ||
>> +if ( argc < 1 || argc > 2 ||
>
> I'm quite sure I'm missing something, but shouldn't argc still be 1
> regardless of whether the max sub-state is set or not?
>
> I would expect to scan for something like: "%d,%d" or some such, but
> maybe there's a step I'm missing that splits the string using the ','
> separator?
... misleading you here.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 02/10] vm_event: Remove "ring" suffix from vm_event_check_ring
On 16.07.2019 20:06, Petre Pircalabu wrote: > Decouple implementation from interface to allow vm_event_check to be > used regardless of the vm_event underlying implementation. > > Signed-off-by: Petre Pircalabu > Acked-by: Andrew Cooper > Acked-by: Tamas K Lengyel Reviewed-by: Alexandru Isaila > --- > xen/arch/arm/mem_access.c | 2 +- > xen/arch/x86/mm/mem_access.c | 4 ++-- > xen/arch/x86/mm/mem_paging.c | 2 +- > xen/common/mem_access.c | 2 +- > xen/common/vm_event.c | 24 > xen/drivers/passthrough/pci.c | 2 +- > xen/include/xen/vm_event.h| 4 ++-- > 7 files changed, 20 insertions(+), 20 deletions(-) > Alex ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 4/5] x86: allow limiting the max C-state sub-state
On 16.07.2019 16:48, Roger Pau Monné wrote:
> On Wed, Jul 03, 2019 at 01:03:02PM +, Jan Beulich wrote:
>> @@ -592,7 +608,13 @@ static void acpi_processor_idle(void)
>>
>>do {
>>cx = >states[next_state];
>> -} while ( cx->type > max_state && --next_state );
>> +} while ( (cx->type > max_state ||
>> + cx->entry_method == ACPI_CSTATE_EM_NONE ||
>> + (cx->entry_method == ACPI_CSTATE_EM_FFH &&
>> +cx->type == max_cstate &&
>> +(cx->address & MWAIT_SUBSTATE_MASK) > max_csubstate)) &&
>> + --next_state );
>> +cx = >states[next_state];
>
> Is the line above a stray addition? It is at least not properly
> aligned AFAICT.
Oh, yes, that's a re-basing mistake. Thanks for spotting.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/5] x86/AMD: make C-state handling independent of Dom0
On 16.07.2019 16:26, Roger Pau Monné wrote:
> On Wed, Jul 03, 2019 at 01:01:48PM +, Jan Beulich wrote:
>> --- a/xen/arch/x86/acpi/cpu_idle.c
>> +++ b/xen/arch/x86/acpi/cpu_idle.c
>> @@ -110,6 +110,8 @@ boolean_param("lapic_timer_c2_ok", local
>>
>>struct acpi_processor_power *__read_mostly processor_powers[NR_CPUS];
>>
>> +static int8_t __read_mostly vendor_override;
>
> AFAICT from the code below this is a tri-state (-1, 0, 1). Could it
> maybe be turned into an enum with definitions of the different
> states?
>
> I think it would make the usage clearer.
Well, personally I prefer doing it this way for tristates. I'll
wait to see what others think.
>> @@ -1286,6 +1291,103 @@ long set_cx_pminfo(uint32_t acpi_id, str
>>return 0;
>>}
>>
>> +static void amd_cpuidle_init(struct acpi_processor_power *power)
>> +{
>> +unsigned int i, nr = 0;
>> +const struct cpuinfo_x86 *c = _cpu_data;
>> +const unsigned int ecx_req = CPUID5_ECX_EXTENSIONS_SUPPORTED |
>> + CPUID5_ECX_INTERRUPT_BREAK;
>> +const struct acpi_processor_cx *cx = NULL;
>> +static const struct acpi_processor_cx fam17[] = {
>> +{
>> +.type = ACPI_STATE_C1,
>> +.entry_method = ACPI_CSTATE_EM_FFH,
>> +.address = 0,
>
> address field will already get set to 0 by default.
Hmm, yes. I'm never really sure whether adding explicit zero
initializers for fields where they aren't don't-cares is better.
Nor (mostly for that reason) am I really consistent in this. I
guess I'll drop the line.
>> +.latency = 1,
>> +},
>> +{
>> +.type = ACPI_STATE_C2,
>> +.entry_method = ACPI_CSTATE_EM_HALT,
>> +.latency = 400,
>
> Maybe the latency values could be added to cpuidle.h as defines?
I'd rather not, as such constants wouldn't be used in more than one
place. See xen/arch/x86/cpu/mwait-idle.c's respective tables.
>> +},
>> +};
>> +
>> +if ( pm_idle_save && pm_idle != acpi_processor_idle )
>> +return;
>> +
>> +if ( vendor_override < 0 )
>> +return;
>> +
>> +switch ( c->x86 )
>> +{
>> +case 0x18:
>> +if ( boot_cpu_data.x86_vendor != X86_VENDOR_HYGON )
>> +{
>> +default:
>> +vendor_override = -1;
>> +return;
>> +}
>> +/* fall through */
>> +case 0x17:
>> +if ( cpu_has_monitor && c->cpuid_level >= CPUID_MWAIT_LEAF &&
>> + (cpuid_ecx(CPUID_MWAIT_LEAF) & ecx_req) == ecx_req )
>> +{
>> +cx = fam17;
>> +nr = ARRAY_SIZE(fam17);
>> +local_apic_timer_c2_ok = true;
>> +break;
>> +}
>> +/* fall through */
>> +case 0x15:
>> +case 0x16:
>> +cx = [1];
>> +nr = ARRAY_SIZE(fam17) - 1;
>> +break;
>> +}
>> +
>> +power->flags.has_cst = true;
>> +
>> +for ( i = 0; i < nr; ++i )
>> +{
>> +if ( cx[i].type > max_cstate )
>> +break;
>> +power->states[i + 1] = cx[i];
>> +power->states[i + 1].idx = i + 1;
>> +power->states[i + 1].target_residency = cx[i].latency *
>> latency_factor;
>
> You could set target_residency as part of the initialization, but I
> guess latency_factor being non-const that would move fam17 outside of
> .rodata?
The static being function local - yes, I could, but besides the array
moving out of .rodata I'd then also need to duplicate the latency
values (and as said above I'd like to avoid introducing #define-s for
them).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.9-testing test] 139047: tolerable trouble: fail/pass/starved - PUSHED
flight 139047 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/139047/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-win7-amd64 13 guest-saverestore fail in 138919 pass in 139047 test-amd64-i386-xl-qemut-win7-amd64 13 guest-saverestore fail in 138919 pass in 139047 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 17 guest-stop fail in 138919 pass in 139047 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail in 138919 pass in 139047 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-saverestore fail in 139019 pass in 139047 test-amd64-i386-freebsd10-amd64 17 guest-localmigrate/x10 fail in 139019 pass in 139047 test-amd64-i386-xl-qemut-ws16-amd64 15 guest-saverestore.2 fail in 139019 pass in 139047 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail in 139019 pass in 139047 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail in 139019 pass in 139047 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 138919 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail pass in 138992 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail pass in 138992 test-amd64-i386-xl-qemuu-ws16-amd64 15 guest-saverestore.2 fail pass in 139019 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail baseline untested test-amd64-i386-xl-qemut-debianhvm-i386-xsm 17 guest-stop fail baseline untested test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 132889 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail blocked in 132889 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail blocked in 132889 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 138919 like 132889 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 138992 like 132889 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail in 138992 like 132889 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail in 139019 blocked in 132889 test-amd64-amd64-xl-qemut-ws16-amd64 18 guest-start/win.repeat fail like 132889 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 132889 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
Re: [Xen-devel] [PATCH v2 01/10] vm_event: Define VM_EVENT type
On 16.07.2019 20:06, Petre Pircalabu wrote:
> @@ -1004,7 +942,7 @@ struct xen_domctl_psr_cmt_op {
>* Enable/disable monitoring various VM events.
>* This domctl configures what events will be reported to helper apps
>* via the ring buffer "MONITOR". The ring has to be first enabled
> - * with the domctl XEN_DOMCTL_VM_EVENT_OP_MONITOR.
> + * with XEN_VM_EVENT_ENABLE.
The above comment should also be adjusted.
>*
>* GET_CAPABILITIES can be used to determine which of these features is
>* available on a given platform.
Alex
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 01/10] vm_event: Define VM_EVENT type
On Tue, 2019-07-16 at 14:59 -0600, Tamas K Lengyel wrote: > > diff --git a/xen/include/public/vm_event.h > > b/xen/include/public/vm_event.h > > index 959083d..c48bc21 100644 > > --- a/xen/include/public/vm_event.h > > +++ b/xen/include/public/vm_event.h > > @@ -36,6 +36,37 @@ > > #include "io/ring.h" > > > > /* > > + * There are currently three types of VM events. > > + */ > > This is a bit misleading and confusing if someone just looks at the > header. Right now we actually have 14 different VM_EVENT_REASONs > defined. What we have 3 of are the different rings where these events > would be delivered, with paging and sharing having their own ring > separate from the events under the "monitor" label. > The reason I replaced "ring" with "type" is because the next patches introduce a new mechanism for handling requests/responses without using a ring. I assumed the following naming convention: Type - the "subsystem" which generates the vm_event request: monitor, paging or sharing. Reason - The reason why the vm_event request was sent (e.g. VM_EVENT_REASON_MEM_ACCESS) However, I do understand that it can be misleading without a proper description so I will update the description. Many thanks, Petre ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Design session report: Live-Updating Xen
On 17.07.2019 01:51, Andrew Cooper wrote: > On 15/07/2019 19:57, Foerster, Leonard wrote: >> * dom0less: bootstrap domains without the involvement of dom0 >> -> this might come in handy to at least setup and continue dom0 >> on target xen >> -> If we have this this might also enable us to de-serialize >> the state for >> other guest-domains in xen and not have to wait for >> dom0 to do this > > Reconstruction of dom0 is something which Xen will definitely need to > do. With the memory still in place, its just a fairly small of register > state which needs restoring. > > That said, reconstruction of the typerefs will be an issue. Walking > over a fully populated L4 tree can (in theory) take minutes, and its not > safe to just start executing without reconstruction. > > Depending on how bad it is in practice, one option might be to do a > demand validate of %rip and %rsp, along with a hybrid shadow mode which > turns faults into typerefs, which would allow the gross cost of > revalidation to be amortised while the vcpus were executing. We would > definitely want some kind of logic to aggressively typeref outstanding > pagetables so the shadow mode could be turned off. Neither walking the page table trees nor and on-demand re-creation can possibly work, as pointed out during (partly informal) discussion: At the very least the allocated and pinned states of pages can only be transferred. Hence we seem to have come to agreement that struct page_info instances have to be transformed (in place if possible, i.e. when the sizes match, otherwise by copying). >> -> We might have to go and re-inject certain interrupts > > What hardware are you targeting here? IvyBridge and later has a posted > interrupt descriptor which can accumulate pending interrupts (at least > manually), and newer versions (Broadwell?) can accumulate interrupts > directly from hardware. For HVM/PVH perhaps that's good enough. What about PV though? >> A key cornerstone for Live-update is guest transparent live migration >> -> This means we are using a well defined ABI for saving/restoring >> domain state >> -> We do only rely on domain state and no internal xen state > > Absolutely. One issue I discussed with David a while ago is that even > across an upgrade of Xen, the format of the EPT/NPT pagetables might > change, at least in terms of the layout of software bits. (Especially > for EPT where we slowly lose software bits to new hardware features we > wish to use.) Right, and therefore a similar transformation like for struct page_info may be unavoidable here too. Re-using large data structures (or arrays thereof) may also turn out useful in terms of latency until the new Xen actually becomes ready to resume. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Ping: [PATCH v2 1/4] x86/PV: tighten page table ownership check in emul-priv-op.c:read_cr()
>>> On 04.06.19 at 14:41, wrote:
> Rather than checking that a page table is _not_ "owned" by the fake COW
> domain, check that it's owned by the domain actually wanting to install
> it.
>
> Switch away from BUG_ON() at the same time.
>
> Signed-off-by: Jan Beulich
I've got Roger's R-b - any chance to get an ack here so it can go in?
> ---
> v2: Split out from larger patch to make further adjustments.
> ---
> Thinking about it I wonder why we have such a check here and no-where
> else. An alternative would seem to be to simply drop the BUG_ON().
Or would you prefer me to go this (or yet another) route?
Jan
> --- a/xen/arch/x86/pv/emul-priv-op.c
> +++ b/xen/arch/x86/pv/emul-priv-op.c
> @@ -706,7 +706,7 @@ static int read_cr(unsigned int reg, uns
>
> case 3: /* Read CR3 */
> {
> -const struct domain *currd = curr->domain;
> +struct domain *currd = curr->domain;
> mfn_t mfn;
>
> if ( !is_pv_32bit_domain(currd) )
> @@ -723,8 +723,14 @@ static int read_cr(unsigned int reg, uns
> unmap_domain_page(pl4e);
> *val = compat_pfn_to_cr3(mfn_to_gmfn(currd, mfn_x(mfn)));
> }
> -/* PTs should not be shared */
> -BUG_ON(page_get_owner(mfn_to_page(mfn)) == dom_cow);
> +
> +/* PTs should be owned by their domains */
> +if ( page_get_owner(mfn_to_page(mfn)) != currd )
> +{
> +ASSERT_UNREACHABLE();
> +domain_crash(currd);
> +}
> +
> return X86EMUL_OKAY;
> }
> }
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 4/5] x86/paravirt: Remove const mark from x86_hyper_xen_hvm variable
On Tue, 2019-07-16 at 12:26 +0800, Zhenzhong Duan wrote:
> .. as "nopv" support needs it to be changeable at boot up stage.
>
> Checkpatch reports warning, so move variable declarations from
> hypervisor.c to hypervisor.h
[]
> diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
[]
> @@ -259,7 +259,7 @@ static __init void xen_hvm_guest_late_init(void)
> #endif
> }
>
> -const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = {
> +struct hypervisor_x86 x86_hyper_xen_hvm __initdata = {
static?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 4/5] x86/paravirt: Remove const mark from x86_hyper_xen_hvm variable
On 17.07.19 08:46, Joe Perches wrote:
On Tue, 2019-07-16 at 12:26 +0800, Zhenzhong Duan wrote:
.. as "nopv" support needs it to be changeable at boot up stage.
Checkpatch reports warning, so move variable declarations from
hypervisor.c to hypervisor.h
[]
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
[]
@@ -259,7 +259,7 @@ static __init void xen_hvm_guest_late_init(void)
#endif
}
-const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = {
+struct hypervisor_x86 x86_hyper_xen_hvm __initdata = {
static?
It is being referenced from arch/x86/kernel/cpu/hypervisor.c
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] dom0-build: fix build with clang5
With non-empty CONFIG_DOM0_MEM clang5 produces
dom0_build.c:344:24: error: use of logical '&&' with constant operand
[-Werror,-Wconstant-logical-operand]
if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
^ ~~
dom0_build.c:344:24: note: use '&' for a bitwise operation
if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
^~
&
dom0_build.c:344:24: note: remove constant to silence this warning
if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
~^
1 error generated.
Obviously neither of the two suggestions are an option here. Oddly
enough swapping the operands of the && helps, while e.g. casting or
parenthesizing doesn't. Another workable variant looks to be the use of
!! on the constant.
Signed-off-by: Jan Beulich
---
v2: Also adjust the Arm incarnation of the same construct.
---
I'm open to going the !! or yet some different route (but not really the
suggested strlen() one). No matter which one we choose, I'm afraid it is
going to remain guesswork what newer (and future) versions of clang will
choke on.
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2125,7 +2125,7 @@ int __init construct_dom0(struct domain
printk("*** LOADING DOMAIN 0 ***\n");
-if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
+if ( CONFIG_DOM0_MEM[0] && !dom0_mem_set )
parse_dom0_mem(CONFIG_DOM0_MEM);
if ( dom0_mem <= 0 )
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -341,7 +341,7 @@ unsigned long __init dom0_compute_nr_pag
unsigned long avail = 0, nr_pages, min_pages, max_pages;
bool need_paging;
-if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
+if ( CONFIG_DOM0_MEM[0] && !dom0_mem_set )
parse_dom0_mem(CONFIG_DOM0_MEM);
for_each_node_mask ( node, dom0_nodes )
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH RFC] x86emul: unconditionally deliver #UD for LWP insns
This is to accompany commit ("x86/svm: Drop support for AMD's
Lightweight Profiling").
Signed-off-by: Jan Beulich
---
With AMD apparently having abandoned XOP encoded insns, another option
would seem to be to simply wire all unrecognized ones into #UD (rather
then returning UNIMPLEMENTED/UNRECOGNIZED).
---
TODO/RFC: Insert commit ID of referenced commit.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -10367,6 +10367,16 @@ x86_emulate(
}
goto unrecognized_insn;
+case X86EMUL_OPC_XOP(09, 0x12): /* XOP Grp3 */
+switch ( modrm_reg & 7 )
+{
+case 0: /* llwpcb r */
+case 1: /* slwpcb r */
+/* LWP is unsupported, so produce #UD unconditionally. */
+generate_exception(EXC_UD);
+}
+goto unrecognized_insn;
+
case X86EMUL_OPC_XOP(09, 0x82): /* vfrczss xmm/m128,xmm */
case X86EMUL_OPC_XOP(09, 0x83): /* vfrczsd xmm/m128,xmm */
generate_exception_if(vex.l, EXC_UD);
@@ -10451,6 +10461,16 @@ x86_emulate(
break;
}
+case X86EMUL_OPC_XOP(0a, 0x12): /* XOP Grp4 */
+switch ( modrm_reg & 7 )
+{
+case 0: /* lwpins $imm32,r/m,r */
+case 1: /* lwpval $imm32,r/m,r */
+/* LWP is unsupported, so produce #UD unconditionally. */
+generate_exception(EXC_UD);
+}
+goto unrecognized_insn;
+
default:
unimplemented_insn:
rc = X86EMUL_UNIMPLEMENTED;
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v10 13/13] x86emul: add a PCLMUL/VPCLMUL test case to the harness
Also use this for AVX512_VBMI2 VPSH{L,R}D{,V}{D,Q,W} testing (only the
quad word right shifts get actually used; the assumption is that their
"left" counterparts as well as the double word and word forms then work
as well).
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v8: New.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -20,9 +20,10 @@ SIMD := 3dnow sse sse2 sse4 avx avx2 xop
FMA := fma4 fma
SG := avx2-sg avx512f-sg avx512vl-sg
AES := ssse3-aes avx-aes avx2-vaes avx512bw-vaes
+CLMUL := ssse3-pclmul avx-pclmul avx2-vpclmulqdq avx512bw-vpclmulqdq
avx512vbmi2-vpclmulqdq
SHA := sse4-sha avx-sha avx512f-sha
GF := sse2-gf avx2-gf avx512bw-gf
-TESTCASES := blowfish $(SIMD) $(FMA) $(SG) $(AES) $(SHA) $(GF)
+TESTCASES := blowfish $(SIMD) $(FMA) $(SG) $(AES) $(CLMUL) $(SHA) $(GF)
OPMASK := avx512f avx512dq avx512bw
@@ -89,6 +90,7 @@ avx512er-flts := 4 8
avx512vbmi-vecs := $(avx512bw-vecs)
avx512vbmi-ints := $(avx512bw-ints)
avx512vbmi-flts := $(avx512bw-flts)
+avx512vbmi2-vecs := $(avx512bw-vecs)
avx512f-opmask-vecs := 2
avx512dq-opmask-vecs := 1 2
@@ -149,6 +151,10 @@ define simd-aes-defs
$(1)-cflags := $(foreach vec,$($(patsubst %-aes,sse,$(1))-vecs) $($(patsubst
%-vaes,%,$(1))-vecs), \
"-D_$(vec) -maes $(addprefix -m,$(subst -,$(space),$(1)))
$(call non-sse,$(1)) -Os -DVEC_SIZE=$(vec)")
endef
+define simd-clmul-defs
+$(1)-cflags := $(foreach vec,$($(patsubst %-pclmul,sse,$(1))-vecs)
$($(patsubst %-vpclmulqdq,%,$(1))-vecs), \
+"-D_$(vec) -mpclmul $(addprefix -m,$(subst -,$(space),$(1)))
$(call non-sse,$(1)) -Os -DVEC_SIZE=$(vec)")
+endef
define simd-sha-defs
$(1)-cflags := $(foreach vec,$(sse-vecs), \
"-D_$(vec) $(addprefix -m,$(subst -,$(space),$(1))) -Os
-DVEC_SIZE=$(vec)")
@@ -164,6 +170,7 @@ endef
$(foreach flavor,$(SIMD) $(FMA),$(eval $(call simd-defs,$(flavor
$(foreach flavor,$(SG),$(eval $(call simd-sg-defs,$(flavor
$(foreach flavor,$(AES),$(eval $(call simd-aes-defs,$(flavor
+$(foreach flavor,$(CLMUL),$(eval $(call simd-clmul-defs,$(flavor
$(foreach flavor,$(SHA),$(eval $(call simd-sha-defs,$(flavor
$(foreach flavor,$(GF),$(eval $(call simd-gf-defs,$(flavor
$(foreach flavor,$(OPMASK),$(eval $(call opmask-defs,$(flavor
@@ -218,13 +225,16 @@ $(addsuffix .c,$(SG)):
$(addsuffix .c,$(AES)):
ln -sf simd-aes.c $@
+$(addsuffix .c,$(CLMUL)):
+ ln -sf simd-clmul.c $@
+
$(addsuffix .c,$(SHA)):
ln -sf simd-sha.c $@
$(addsuffix .c,$(GF)):
ln -sf simd-gf.c $@
-$(addsuffix .h,$(SIMD) $(FMA) $(SG) $(AES) $(SHA) $(GF)): simd.h
+$(addsuffix .h,$(SIMD) $(FMA) $(SG) $(AES) $(CLMUL) $(SHA) $(GF)): simd.h
xop.h avx512f.h: simd-fma.c
--- /dev/null
+++ b/tools/tests/x86_emulator/simd-clmul.c
@@ -0,0 +1,150 @@
+#define UINT_SIZE 8
+
+#include "simd.h"
+ENTRY(clmul_test);
+
+#ifdef __AVX512F__ /* AVX512BW may get enabled only below */
+# define ALL_TRUE (~0ULL >> (64 - ELEM_COUNT))
+# define eq(x, y) (B(pcmpeqq, _mask, (vdi_t)(x), (vdi_t)(y), -1) == ALL_TRUE)
+# define lane_shr_unit(x) \
+((vec_t)B(palignr, _mask, (vdi_t)(x), (vdi_t)(x), 64, (vdi_t){}, \
+ 0x00ff00ff00ff00ffULL & (~0ULL >> (64 - VEC_SIZE
+#else
+# if defined(__AVX2__) && VEC_SIZE == 32
+# define to_bool(cmp) B(ptestc, , cmp, (vdi_t){} == 0)
+# else
+# define to_bool(cmp) (__builtin_ia32_pmovmskb128(cmp) == 0x)
+# endif
+# define eq(x, y) to_bool((x) == (y))
+# define lane_shr_unit(x) ((vec_t)B(palignr, , (vdi_t){}, (vdi_t)(x), 64))
+#endif
+
+#define CLMUL(op, x, y, c) (vec_t)(__builtin_ia32_ ## op((vdi_t)(x),
(vdi_t)(y), c))
+
+#if VEC_SIZE == 16
+# define clmul(x, y, c) CLMUL(pclmulqdq128, x, y, c)
+# define vpshrd __builtin_ia32_vpshrd_v2di
+#elif VEC_SIZE == 32
+# define clmul(x, y, c) CLMUL(vpclmulqdq_v4di, x, y, c)
+# define vpshrd __builtin_ia32_vpshrd_v4di
+#elif VEC_SIZE == 64
+# define clmul(x, y, c) CLMUL(vpclmulqdq_v8di, x, y, c)
+# define vpshrd __builtin_ia32_vpshrd_v8di
+#endif
+
+#define clmul_ll(x, y) clmul(x, y, 0x00)
+#define clmul_hl(x, y) clmul(x, y, 0x01)
+#define clmul_lh(x, y) clmul(x, y, 0x10)
+#define clmul_hh(x, y) clmul(x, y, 0x11)
+
+#if defined(__AVX512VBMI2__)
+# pragma GCC target ( "avx512bw" )
+# define lane_shr_i(x, n) ({ \
+vec_t h_ = lane_shr_unit(x); \
+touch(h_); \
+(n) < 64 ? (vec_t)vpshrd((vdi_t)(x), (vdi_t)(h_), n) : h_ >> ((n) - 64); \
+})
+# define lane_shr_v(x, n) ({ \
+vec_t t_ = (x), h_ = lane_shr_unit(x); \
+typeof(t_[0]) n_ = (n); \
+if ( (n) < 64 ) \
+/* gcc does not support embedded broadcast */ \
+asm ( "vpshrdvq %2%{1to%c3%}, %1, %0" \
+ : "+v" (t_) : "v" (h_), "m" (n_), "i" (ELEM_COUNT) ); \
+else \
+t_ = h_ >> ((n) - 64); \
+t_; \
+})
+#else
+# define lane_shr_i lane_shr_v
+# define lane_shr_v(x, n) ({ \
+vec_t t_ = (n) > 0 ? lane_shr_unit(x) : (x); \
+(n) < 64 ? ((x) >>
[Xen-devel] [PATCH v10 12/13] x86emul: add a SHA test case to the harness
Also use this for AVX512VL VPRO{L,R}{,V}D as well as some further shifts
testing.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v8: New.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -20,8 +20,9 @@ SIMD := 3dnow sse sse2 sse4 avx avx2 xop
FMA := fma4 fma
SG := avx2-sg avx512f-sg avx512vl-sg
AES := ssse3-aes avx-aes avx2-vaes avx512bw-vaes
+SHA := sse4-sha avx-sha avx512f-sha
GF := sse2-gf avx2-gf avx512bw-gf
-TESTCASES := blowfish $(SIMD) $(FMA) $(SG) $(AES) $(GF)
+TESTCASES := blowfish $(SIMD) $(FMA) $(SG) $(AES) $(SHA) $(GF)
OPMASK := avx512f avx512dq avx512bw
@@ -148,6 +149,10 @@ define simd-aes-defs
$(1)-cflags := $(foreach vec,$($(patsubst %-aes,sse,$(1))-vecs) $($(patsubst
%-vaes,%,$(1))-vecs), \
"-D_$(vec) -maes $(addprefix -m,$(subst -,$(space),$(1)))
$(call non-sse,$(1)) -Os -DVEC_SIZE=$(vec)")
endef
+define simd-sha-defs
+$(1)-cflags := $(foreach vec,$(sse-vecs), \
+"-D_$(vec) $(addprefix -m,$(subst -,$(space),$(1))) -Os
-DVEC_SIZE=$(vec)")
+endef
define simd-gf-defs
$(1)-cflags := $(foreach vec,$($(1:-gf=)-vecs), \
"-D_$(vec) -mgfni -m$(1:-gf=) $(call non-sse,$(1)) -Os
-DVEC_SIZE=$(vec)")
@@ -159,6 +164,7 @@ endef
$(foreach flavor,$(SIMD) $(FMA),$(eval $(call simd-defs,$(flavor
$(foreach flavor,$(SG),$(eval $(call simd-sg-defs,$(flavor
$(foreach flavor,$(AES),$(eval $(call simd-aes-defs,$(flavor
+$(foreach flavor,$(SHA),$(eval $(call simd-sha-defs,$(flavor
$(foreach flavor,$(GF),$(eval $(call simd-gf-defs,$(flavor
$(foreach flavor,$(OPMASK),$(eval $(call opmask-defs,$(flavor
@@ -212,10 +218,13 @@ $(addsuffix .c,$(SG)):
$(addsuffix .c,$(AES)):
ln -sf simd-aes.c $@
+$(addsuffix .c,$(SHA)):
+ ln -sf simd-sha.c $@
+
$(addsuffix .c,$(GF)):
ln -sf simd-gf.c $@
-$(addsuffix .h,$(SIMD) $(FMA) $(SG) $(AES) $(GF)): simd.h
+$(addsuffix .h,$(SIMD) $(FMA) $(SG) $(AES) $(SHA) $(GF)): simd.h
xop.h avx512f.h: simd-fma.c
--- /dev/null
+++ b/tools/tests/x86_emulator/simd-sha.c
@@ -0,0 +1,392 @@
+#define INT_SIZE 4
+
+#include "simd.h"
+ENTRY(sha_test);
+
+#define SHA(op, a...) __builtin_ia32_sha ## op(a)
+
+#ifdef __AVX512F__
+# define ALL_TRUE (~0ULL >> (64 - ELEM_COUNT))
+# define eq(x, y) (B(pcmpeqd, _mask, x, y, -1) == ALL_TRUE)
+# define blend(x, y, sel) B(movdqa32_, _mask, y, x, sel)
+# define rot_c(f, r, x, n) B(pro ## f ## d, _mask, x, n, undef(), ~0)
+# define rot_s(f, r, x, n) ({ /* gcc does not support embedded broadcast */ \
+vec_t r_; \
+asm ( "vpro" #f "vd %2%{1to%c3%}, %1, %0" \
+ : "=v" (r_) \
+ : "v" (x), "m" (n), "i" (ELEM_COUNT) ); \
+r_; \
+})
+# define rot_v(d, x, n) B(pro ## d ## vd, _mask, x, n, undef(), ~0)
+# define shift_s(d, x, n) ({ \
+vec_t r_; \
+asm ( "vps" #d "lvd %2%{1to%c3%}, %1, %0" \
+ : "=v" (r_) \
+ : "v" (x), "m" (n), "i" (ELEM_COUNT) ); \
+r_; \
+})
+# define vshift(d, x, n) ({ /* gcc does not allow memory operands */ \
+vec_t r_; \
+asm ( "vps" #d "ldq %2, %1, %0" \
+ : "=v" (r_) : "m" (x), "i" ((n) * ELEM_SIZE) ); \
+r_; \
+})
+#else
+# define to_bool(cmp) (__builtin_ia32_pmovmskb128(cmp) == 0x)
+# define eq(x, y) to_bool((x) == (y))
+# define blend(x, y, sel) \
+((vec_t)__builtin_ia32_pblendw128((vhi_t)(x), (vhi_t)(y), \
+ ((sel) & 1 ? 0x03 : 0) | \
+ ((sel) & 2 ? 0x0c : 0) | \
+ ((sel) & 4 ? 0x30 : 0) | \
+ ((sel) & 8 ? 0xc0 : 0)))
+# define rot_c(f, r, x, n) (sh ## f ## _c(x, n) | sh ## r ## _c(x, 32 - (n)))
+# define rot_s(f, r, x, n) ({ /* gcc does not allow memory operands */ \
+vec_t r_, t_, n_ = (vec_t){ 32 } - (n); \
+asm ( "ps" #f "ld %2, %0; ps" #r "ld %3, %1; por %1, %0" \
+ : "=" (r_), "=" (t_) \
+ : "m" (n), "m" (n_), "0" (x), "1" (x) ); \
+r_; \
+})
+static inline unsigned int rotl(unsigned int x, unsigned int n)
+{
+return (x << (n & 0x1f)) | (x >> ((32 - n) & 0x1f));
+}
+static inline unsigned int rotr(unsigned int x, unsigned int n)
+{
+return (x >> (n & 0x1f)) | (x << ((32 - n) & 0x1f));
+}
+# define rot_v(d, x, n) ({ \
+vec_t t_; \
+unsigned int i_; \
+for ( i_ = 0; i_ < ELEM_COUNT; ++i_ ) \
+t_[i_] = rot ## d((x)[i_], (n)[i_]); \
+t_; \
+})
+# define shift_s(d, x, n) ({ \
+vec_t r_; \
+asm ( "ps" #d "ld %1, %0" : "=" (r_) : "m" (n), "0" (x) ); \
+r_; \
+})
+# define vshift(d, x, n) \
+(vec_t)(__builtin_ia32_ps ## d ## ldqi128((vdi_t)(x), (n) * ELEM_SIZE * 8))
+#endif
+
+#define alignr(x, y, n) ((vec_t)__builtin_ia32_palignr128((vdi_t)(x),
(vdi_t)(y), (n) * 8))
+#define hadd(x, y) __builtin_ia32_phaddd128(x, y)
+#define rol_c(x, n) rot_c(l, r, x, n)
+#define rol_s(x, n) rot_s(l, r, x, n)
+#define rol_v(x, n...) rot_v(l, x, n)
+#define
[Xen-devel] [PATCH v10 11/13] x86emul: add an AES/VAES test case to the harness
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v8: New.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -19,8 +19,9 @@ CFLAGS += $(CFLAGS_xeninclude)
SIMD := 3dnow sse sse2 sse4 avx avx2 xop avx512f avx512bw avx512dq avx512er
avx512vbmi
FMA := fma4 fma
SG := avx2-sg avx512f-sg avx512vl-sg
+AES := ssse3-aes avx-aes avx2-vaes avx512bw-vaes
GF := sse2-gf avx2-gf avx512bw-gf
-TESTCASES := blowfish $(SIMD) $(FMA) $(SG) $(GF)
+TESTCASES := blowfish $(SIMD) $(FMA) $(SG) $(AES) $(GF)
OPMASK := avx512f avx512dq avx512bw
@@ -143,6 +144,10 @@ $(1)-cflags := \
$(foreach flt,$($(1)-flts), \
"-D_$(vec)x$(idx)f$(flt) -m$(1:-sg=) $(call non-sse,$(1)) -Os
-DVEC_MAX=$(vec) -DIDX_SIZE=$(idx) -DFLOAT_SIZE=$(flt)")))
endef
+define simd-aes-defs
+$(1)-cflags := $(foreach vec,$($(patsubst %-aes,sse,$(1))-vecs) $($(patsubst
%-vaes,%,$(1))-vecs), \
+"-D_$(vec) -maes $(addprefix -m,$(subst -,$(space),$(1)))
$(call non-sse,$(1)) -Os -DVEC_SIZE=$(vec)")
+endef
define simd-gf-defs
$(1)-cflags := $(foreach vec,$($(1:-gf=)-vecs), \
"-D_$(vec) -mgfni -m$(1:-gf=) $(call non-sse,$(1)) -Os
-DVEC_SIZE=$(vec)")
@@ -153,6 +158,7 @@ endef
$(foreach flavor,$(SIMD) $(FMA),$(eval $(call simd-defs,$(flavor
$(foreach flavor,$(SG),$(eval $(call simd-sg-defs,$(flavor
+$(foreach flavor,$(AES),$(eval $(call simd-aes-defs,$(flavor
$(foreach flavor,$(GF),$(eval $(call simd-gf-defs,$(flavor
$(foreach flavor,$(OPMASK),$(eval $(call opmask-defs,$(flavor
@@ -203,10 +209,13 @@ $(addsuffix .c,$(FMA)):
$(addsuffix .c,$(SG)):
ln -sf simd-sg.c $@
+$(addsuffix .c,$(AES)):
+ ln -sf simd-aes.c $@
+
$(addsuffix .c,$(GF)):
ln -sf simd-gf.c $@
-$(addsuffix .h,$(SIMD) $(FMA) $(SG) $(GF)): simd.h
+$(addsuffix .h,$(SIMD) $(FMA) $(SG) $(AES) $(GF)): simd.h
xop.h avx512f.h: simd-fma.c
--- /dev/null
+++ b/tools/tests/x86_emulator/simd-aes.c
@@ -0,0 +1,102 @@
+#define UINT_SIZE 1
+
+#include "simd.h"
+ENTRY(aes_test);
+
+#if VEC_SIZE == 16
+# define AES(op, a...) __builtin_ia32_vaes ## op ## _v16qi(a)
+# define imc(x) ((vec_t)__builtin_ia32_aesimc128((vdi_t)(x)))
+#elif VEC_SIZE == 32
+# define AES(op, a...) __builtin_ia32_vaes ## op ## _v32qi(a)
+# define imc(x) ({ \
+vec_t r_; \
+unsigned char __attribute__((vector_size(16))) t_; \
+asm ( "vaesimc (%3), %x0\n\t" \
+ "vaesimc 16(%3), %1\n\t" \
+ "vinserti128 $1, %1, %0, %0" \
+ : "=" (r_), "=" (t_) \
+ : "m" (x), "r" (&(x)) ); \
+r_; \
+})
+#elif VEC_SIZE == 64
+# define AES(op, a...) __builtin_ia32_vaes ## op ## _v64qi(a)
+# define imc(x) ({ \
+vec_t r_; \
+unsigned char __attribute__((vector_size(16))) t_; \
+asm ( "vaesimc (%3), %x0\n\t" \
+ "vaesimc 1*16(%3), %1\n\t" \
+ "vinserti32x4 $1, %1, %0, %0\n\t" \
+ "vaesimc 2*16(%3), %1\n\t" \
+ "vinserti32x4 $2, %1, %0, %0\n\t" \
+ "vaesimc 3*16(%3), %1\n\t" \
+ "vinserti32x4 $3, %1, %0, %0" \
+ : "=" (r_), "=" (t_) \
+ : "m" (x), "r" (&(x)) ); \
+r_; \
+})
+#endif
+
+#ifdef __AVX512BW__
+# define ALL_TRUE (~0ULL >> (64 - ELEM_COUNT))
+# define eq(x, y) (B(pcmpeqb, _mask, (vqi_t)(x), (vqi_t)(y), -1) == ALL_TRUE)
+# define aes(op, x, y) ((vec_t)AES(op, (vqi_t)(x), (vqi_t)(y)))
+#else
+# if defined(__AVX2__) && VEC_SIZE == 32
+# define to_bool(cmp) B(ptestc, , cmp, (vdi_t){} == 0)
+# define aes(op, x, y) ((vec_t)AES(op, (vqi_t)(x), (vqi_t)(y)))
+# else
+# define to_bool(cmp) (__builtin_ia32_pmovmskb128(cmp) == 0x)
+# define aes(op, x, y) ((vec_t)__builtin_ia32_aes ## op ## 128((vdi_t)(x),
(vdi_t)(y)))
+# endif
+# define eq(x, y) to_bool((x) == (y))
+#endif
+
+int aes_test(void)
+{
+unsigned int i;
+vec_t src, zero = {};
+
+for ( i = 0; i < ELEM_COUNT; ++i )
+src[i] = i;
+
+do {
+vec_t x, y;
+
+touch(src);
+x = imc(src);
+touch(src);
+
+touch(zero);
+y = aes(enclast, src, zero);
+touch(zero);
+y = aes(dec, y, zero);
+
+if ( !eq(x, y) ) return __LINE__;
+
+touch(zero);
+x = aes(declast, src, zero);
+touch(zero);
+y = aes(enc, x, zero);
+touch(y);
+x = imc(y);
+
+if ( !eq(x, src) ) return __LINE__;
+
+#if VEC_SIZE == 16
+touch(src);
+x = (vec_t)__builtin_ia32_aeskeygenassist128((vdi_t)src, 0);
+touch(src);
+y = (vec_t)__builtin_ia32_pshufb128((vqi_t)x,
+(vqi_t){ 7, 4, 5, 6,
+ 1, 2, 3, 0,
+ 15, 12, 13, 14,
+ 9, 10, 11, 8 });
+if ( !eq(x, y) ) return __LINE__;
+#endif
+
+src += ELEM_COUNT;
+i += ELEM_COUNT;
+} while ( i <=
[Xen-devel] [PATCH v10 08/13] x86emul: support VAES insns
As to the feature dependency adjustment, just like for VPCLMULQDQ while
strictly speaking AVX is a sufficient prereq (to have YMM registers),
256-bit vectors of integers have got fully introduced with AVX2 only.
A new test case (also covering AESNI) will be added to the harness by a
subsequent patch.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v9: Re-base. Make VAES also depend on AESNI
v8: No need to set fault_suppression to false.
v7: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -591,6 +591,18 @@ static const struct test avx512_vpopcntd
INSN(popcnt, 66, 0f38, 55, vl, dq, vl)
};
+/*
+ * The uses of b in this table are simply (one of) the shortest form(s) of
+ * saying "no broadcast" without introducing a 128-bit granularity enumerator.
+ * Due to all of the insns being WIG, w, d_nb, and q_nb would all also fit.
+ */
+static const struct test vaes_all[] = {
+INSN(aesdec, 66, 0f38, de, vl, b, vl),
+INSN(aesdeclast, 66, 0f38, df, vl, b, vl),
+INSN(aesenc, 66, 0f38, dc, vl, b, vl),
+INSN(aesenclast, 66, 0f38, dd, vl, b, vl),
+};
+
static const struct test vpclmulqdq_all[] = {
INSN(pclmulqdq, 66, 0f3a, 44, vl, q_nb, vl)
};
@@ -975,6 +987,7 @@ void evex_disp8_test(void *instr, struct
if ( cpu_has_avx512f )
{
+RUN(vaes, all);
RUN(vpclmulqdq, all);
}
}
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -144,6 +144,7 @@ static inline bool xcr0_mask(uint64_t ma
#define cpu_has_avx512vl (cp.feat.avx512vl && xcr0_mask(0xe6))
#define cpu_has_avx512_vbmi (cp.feat.avx512_vbmi && xcr0_mask(0xe6))
#define cpu_has_avx512_vbmi2 (cp.feat.avx512_vbmi2 && xcr0_mask(0xe6))
+#define cpu_has_vaes (cp.feat.vaes && xcr0_mask(6))
#define cpu_has_vpclmulqdq (cp.feat.vpclmulqdq && xcr0_mask(6))
#define cpu_has_avx512_vnni (cp.feat.avx512_vnni && xcr0_mask(0xe6))
#define cpu_has_avx512_bitalg (cp.feat.avx512_bitalg && xcr0_mask(0xe6))
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -541,7 +541,7 @@ static const struct ext0f38_table {
[0xcc] = { .simd_size = simd_packed_fp, .two_op = 1, .d8s = d8s_vl },
[0xcd] = { .simd_size = simd_scalar_vexw, .d8s = d8s_dq },
[0xdb] = { .simd_size = simd_packed_int, .two_op = 1 },
-[0xdc ... 0xdf] = { .simd_size = simd_packed_int },
+[0xdc ... 0xdf] = { .simd_size = simd_packed_int, .d8s = d8s_vl },
[0xf0] = { .two_op = 1 },
[0xf1] = { .to_mem = 1, .two_op = 1 },
[0xf2 ... 0xf3] = {},
@@ -1890,6 +1890,7 @@ in_protmode(
#define vcpu_has_avx512vl()(ctxt->cpuid->feat.avx512vl)
#define vcpu_has_avx512_vbmi() (ctxt->cpuid->feat.avx512_vbmi)
#define vcpu_has_avx512_vbmi2() (ctxt->cpuid->feat.avx512_vbmi2)
+#define vcpu_has_vaes()(ctxt->cpuid->feat.vaes)
#define vcpu_has_vpclmulqdq() (ctxt->cpuid->feat.vpclmulqdq)
#define vcpu_has_avx512_vnni() (ctxt->cpuid->feat.avx512_vnni)
#define vcpu_has_avx512_bitalg() (ctxt->cpuid->feat.avx512_bitalg)
@@ -8911,13 +8912,9 @@ x86_emulate(
case X86EMUL_OPC_66(0x0f38, 0xdb): /* aesimc xmm/m128,xmm */
case X86EMUL_OPC_VEX_66(0x0f38, 0xdb): /* vaesimc xmm/m128,xmm */
case X86EMUL_OPC_66(0x0f38, 0xdc): /* aesenc xmm/m128,xmm,xmm */
-case X86EMUL_OPC_VEX_66(0x0f38, 0xdc): /* vaesenc xmm/m128,xmm,xmm */
case X86EMUL_OPC_66(0x0f38, 0xdd): /* aesenclast xmm/m128,xmm,xmm */
-case X86EMUL_OPC_VEX_66(0x0f38, 0xdd): /* vaesenclast xmm/m128,xmm,xmm */
case X86EMUL_OPC_66(0x0f38, 0xde): /* aesdec xmm/m128,xmm,xmm */
-case X86EMUL_OPC_VEX_66(0x0f38, 0xde): /* vaesdec xmm/m128,xmm,xmm */
case X86EMUL_OPC_66(0x0f38, 0xdf): /* aesdeclast xmm/m128,xmm,xmm */
-case X86EMUL_OPC_VEX_66(0x0f38, 0xdf): /* vaesdeclast xmm/m128,xmm,xmm */
host_and_vcpu_must_have(aesni);
if ( vex.opcx == vex_none )
goto simd_0f38_common;
@@ -9643,6 +9640,24 @@ x86_emulate(
host_and_vcpu_must_have(avx512er);
goto simd_zmm_scalar_sae;
+case X86EMUL_OPC_VEX_66(0x0f38, 0xdc): /* vaesenc
{x,y}mm/mem,{x,y}mm,{x,y}mm */
+case X86EMUL_OPC_VEX_66(0x0f38, 0xdd): /* vaesenclast
{x,y}mm/mem,{x,y}mm,{x,y}mm */
+case X86EMUL_OPC_VEX_66(0x0f38, 0xde): /* vaesdec
{x,y}mm/mem,{x,y}mm,{x,y}mm */
+case X86EMUL_OPC_VEX_66(0x0f38, 0xdf): /* vaesdeclast
{x,y}mm/mem,{x,y}mm,{x,y}mm */
+if ( !vex.l )
+host_and_vcpu_must_have(aesni);
+else
+host_and_vcpu_must_have(vaes);
+goto simd_0f_avx;
+
+case X86EMUL_OPC_EVEX_66(0x0f38, 0xdc): /* vaesenc
[xyz]mm/mem,[xyz]mm,[xyz]mm */
+case X86EMUL_OPC_EVEX_66(0x0f38, 0xdd): /* vaesenclast
[xyz]mm/mem,[xyz]mm,[xyz]mm */
+case X86EMUL_OPC_EVEX_66(0x0f38, 0xde): /* vaesdec
[xyz]mm/mem,[xyz]mm,[xyz]mm */
+case X86EMUL_OPC_EVEX_66(0x0f38, 0xdf): /* vaesdeclast
[Xen-devel] [PATCH v10 10/13] x86emul: restore ordering within main switch statement
Incremental additions and/or mistakes have lead to some code blocks
sitting in "unexpected" places. Re-sort the case blocks (opcode space;
major opcode; 66/F3/F2 prefix; legacy/VEX/EVEX encoding).
As an exception the opcode space 0x0f EVEX-encoded VPEXTRW is left at
its current place, to keep it close to the "pextr" label.
Pure code movement.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v7: New.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -7105,15 +7105,6 @@ x86_emulate(
ASSERT(!state->simd_size);
break;
-case X86EMUL_OPC_EVEX_F3(0x0f, 0x7e): /* vmovq xmm/m64,xmm */
-case X86EMUL_OPC_EVEX_66(0x0f, 0xd6): /* vmovq xmm,xmm/m64 */
-generate_exception_if(evex.lr || !evex.w || evex.opmsk || evex.brs,
- EXC_UD);
-host_and_vcpu_must_have(avx512f);
-d |= TwoOp;
-op_bytes = 8;
-goto simd_zmm;
-
case X86EMUL_OPC_66(0x0f, 0xe7): /* movntdq xmm,m128 */
case X86EMUL_OPC_VEX_66(0x0f, 0xe7): /* vmovntdq {x,y}mm,mem */
generate_exception_if(ea.type != OP_MEM, EXC_UD);
@@ -7511,6 +7502,15 @@ x86_emulate(
op_bytes = 8;
goto simd_0f_int;
+case X86EMUL_OPC_EVEX_F3(0x0f, 0x7e): /* vmovq xmm/m64,xmm */
+case X86EMUL_OPC_EVEX_66(0x0f, 0xd6): /* vmovq xmm,xmm/m64 */
+generate_exception_if(evex.lr || !evex.w || evex.opmsk || evex.brs,
+ EXC_UD);
+host_and_vcpu_must_have(avx512f);
+d |= TwoOp;
+op_bytes = 8;
+goto simd_zmm;
+
case X86EMUL_OPC(0x0f, 0x80) ... X86EMUL_OPC(0x0f, 0x8f): /* jcc (near) */
if ( test_cc(b, _regs.eflags) )
jmp_rel((int32_t)src.val);
@@ -8611,63 +8611,6 @@ x86_emulate(
dst.type = OP_NONE;
break;
-case X86EMUL_OPC_EVEX_66(0x0f38, 0x10): /* vpsrlvw
[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
-case X86EMUL_OPC_EVEX_66(0x0f38, 0x11): /* vpsravw
[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
-case X86EMUL_OPC_EVEX_66(0x0f38, 0x12): /* vpsllvw
[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
-host_and_vcpu_must_have(avx512bw);
-generate_exception_if(!evex.w || evex.brs, EXC_UD);
-elem_bytes = 2;
-goto avx512f_no_sae;
-
-case X86EMUL_OPC_EVEX_66(0x0f38, 0x18): /* vbroadcastss xmm/m32,[xyz]mm{k}
*/
-case X86EMUL_OPC_EVEX_66(0x0f38, 0x58): /* vpbroadcastd xmm/m32,[xyz]mm{k}
*/
-op_bytes = elem_bytes;
-generate_exception_if(evex.w || evex.brs, EXC_UD);
-avx512_broadcast:
-/*
- * For the respective code below the main switch() to work we need to
- * fold op_mask here: A source element gets read whenever any of its
- * respective destination elements' mask bits is set.
- */
-if ( fault_suppression )
-{
-n = 1 << ((b & 3) - evex.w);
-EXPECT(elem_bytes > 0);
-ASSERT(op_bytes == n * elem_bytes);
-for ( i = n; i < (16 << evex.lr) / elem_bytes; i += n )
-op_mask |= (op_mask >> i) & ((1 << n) - 1);
-}
-goto avx512f_no_sae;
-
-case X86EMUL_OPC_EVEX_66(0x0f38, 0x1b): /* vbroadcastf32x8 m256,zmm{k} */
-/* vbroadcastf64x4 m256,zmm{k} */
-case X86EMUL_OPC_EVEX_66(0x0f38, 0x5b): /* vbroadcasti32x8 m256,zmm{k} */
-/* vbroadcasti64x4 m256,zmm{k} */
-generate_exception_if(ea.type != OP_MEM || evex.lr != 2, EXC_UD);
-/* fall through */
-case X86EMUL_OPC_EVEX_66(0x0f38, 0x19): /* vbroadcastsd xmm/m64,{y,z}mm{k}
*/
-/* vbroadcastf32x2
xmm/m64,{y,z}mm{k} */
-generate_exception_if(!evex.lr, EXC_UD);
-/* fall through */
-case X86EMUL_OPC_EVEX_66(0x0f38, 0x59): /* vpbroadcastq xmm/m64,[xyz]mm{k}
*/
-/* vbroadcasti32x2
xmm/m64,[xyz]mm{k} */
-if ( b == 0x59 )
-op_bytes = 8;
-generate_exception_if(evex.brs, EXC_UD);
-if ( !evex.w )
-host_and_vcpu_must_have(avx512dq);
-goto avx512_broadcast;
-
-case X86EMUL_OPC_EVEX_66(0x0f38, 0x1a): /* vbroadcastf32x4 m128,{y,z}mm{k}
*/
-/* vbroadcastf64x2 m128,{y,z}mm{k}
*/
-case X86EMUL_OPC_EVEX_66(0x0f38, 0x5a): /* vbroadcasti32x4 m128,{y,z}mm{k}
*/
-/* vbroadcasti64x2 m128,{y,z}mm{k}
*/
-generate_exception_if(ea.type != OP_MEM || !evex.lr || evex.brs,
- EXC_UD);
-if ( evex.w )
-host_and_vcpu_must_have(avx512dq);
-goto avx512_broadcast;
-
case X86EMUL_OPC_66(0x0f38, 0x20): /* pmovsxbw xmm/m64,xmm */
case X86EMUL_OPC_66(0x0f38, 0x21): /* pmovsxbd xmm/m32,xmm */
case X86EMUL_OPC_66(0x0f38, 0x22): /* pmovsxbq xmm/m16,xmm */
@@ -8701,47
[Xen-devel] [PATCH v10 09/13] x86emul: support GFNI insns
As to the feature dependency adjustment, while strictly speaking SSE is
a sufficient prereq (to have XMM registers), vectors of bytes and qwords
have got introduced only with SSE2. gcc, for example, uses a similar
connection in its respective intrinsics header.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v9: Re-base. Drop stale part of description.
v8: Add {evex}-producing vgf2p8mulb alias to simd.h. Add missing simd.h
dependency. Re-base.
v7: New.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -19,7 +19,8 @@ CFLAGS += $(CFLAGS_xeninclude)
SIMD := 3dnow sse sse2 sse4 avx avx2 xop avx512f avx512bw avx512dq avx512er
avx512vbmi
FMA := fma4 fma
SG := avx2-sg avx512f-sg avx512vl-sg
-TESTCASES := blowfish $(SIMD) $(FMA) $(SG)
+GF := sse2-gf avx2-gf avx512bw-gf
+TESTCASES := blowfish $(SIMD) $(FMA) $(SG) $(GF)
OPMASK := avx512f avx512dq avx512bw
@@ -142,12 +143,17 @@ $(1)-cflags := \
$(foreach flt,$($(1)-flts), \
"-D_$(vec)x$(idx)f$(flt) -m$(1:-sg=) $(call non-sse,$(1)) -Os
-DVEC_MAX=$(vec) -DIDX_SIZE=$(idx) -DFLOAT_SIZE=$(flt)")))
endef
+define simd-gf-defs
+$(1)-cflags := $(foreach vec,$($(1:-gf=)-vecs), \
+"-D_$(vec) -mgfni -m$(1:-gf=) $(call non-sse,$(1)) -Os
-DVEC_SIZE=$(vec)")
+endef
define opmask-defs
$(1)-opmask-cflags := $(foreach vec,$($(1)-opmask-vecs), "-D_$(vec) -m$(1)
-Os -DSIZE=$(vec)")
endef
$(foreach flavor,$(SIMD) $(FMA),$(eval $(call simd-defs,$(flavor
$(foreach flavor,$(SG),$(eval $(call simd-sg-defs,$(flavor
+$(foreach flavor,$(GF),$(eval $(call simd-gf-defs,$(flavor
$(foreach flavor,$(OPMASK),$(eval $(call opmask-defs,$(flavor
first-string = $(shell for s in $(1); do echo "$$s"; break; done)
@@ -197,7 +203,10 @@ $(addsuffix .c,$(FMA)):
$(addsuffix .c,$(SG)):
ln -sf simd-sg.c $@
-$(addsuffix .h,$(SIMD) $(FMA) $(SG)): simd.h
+$(addsuffix .c,$(GF)):
+ ln -sf simd-gf.c $@
+
+$(addsuffix .h,$(SIMD) $(FMA) $(SG) $(GF)): simd.h
xop.h avx512f.h: simd-fma.c
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -591,6 +591,12 @@ static const struct test avx512_vpopcntd
INSN(popcnt, 66, 0f38, 55, vl, dq, vl)
};
+static const struct test gfni_all[] = {
+INSN(gf2p8affineinvqb, 66, 0f3a, cf, vl, q, vl),
+INSN(gf2p8affineqb,66, 0f3a, ce, vl, q, vl),
+INSN(gf2p8mulb,66, 0f38, cf, vl, b, vl),
+};
+
/*
* The uses of b in this table are simply (one of) the shortest form(s) of
* saying "no broadcast" without introducing a 128-bit granularity enumerator.
@@ -987,6 +993,7 @@ void evex_disp8_test(void *instr, struct
if ( cpu_has_avx512f )
{
+RUN(gfni, all);
RUN(vaes, all);
RUN(vpclmulqdq, all);
}
--- a/tools/tests/x86_emulator/simd.h
+++ b/tools/tests/x86_emulator/simd.h
@@ -371,6 +371,7 @@ OVR(cvttsd2siq);
OVR(cvttss2si);
OVR(cvttss2sil);
OVR(cvttss2siq);
+OVR(gf2p8mulb);
OVR(movddup);
OVR(movntdq);
OVR(movntdqa);
--- /dev/null
+++ b/tools/tests/x86_emulator/simd-gf.c
@@ -0,0 +1,80 @@
+#define UINT_SIZE 1
+
+#include "simd.h"
+ENTRY(gf_test);
+
+#if VEC_SIZE == 16
+# define GF(op, s, a...) __builtin_ia32_vgf2p8 ## op ## _v16qi ## s(a)
+#elif VEC_SIZE == 32
+# define GF(op, s, a...) __builtin_ia32_vgf2p8 ## op ## _v32qi ## s(a)
+#elif VEC_SIZE == 64
+# define GF(op, s, a...) __builtin_ia32_vgf2p8 ## op ## _v64qi ## s(a)
+#endif
+
+#ifdef __AVX512BW__
+# define ALL_TRUE (~0ULL >> (64 - ELEM_COUNT))
+# define eq(x, y) (B(pcmpeqb, _mask, (vqi_t)(x), (vqi_t)(y), -1) == ALL_TRUE)
+# define mul(x, y) GF(mulb, _mask, (vqi_t)(x), (vqi_t)(y), (vqi_t)undef(), ~0)
+# define transform(m, dir, x, c) ({ \
+vec_t t_; \
+asm ( "vgf2p8affine" #dir "qb %[imm], %[matrix]%{1to%c[n]%}, %[src],
%[dst]" \
+ : [dst] "=v" (t_) \
+ : [matrix] "m" (m), [src] "v" (x), [imm] "i" (c), [n] "i" (VEC_SIZE
/ 8) ); \
+t_; \
+})
+#else
+# if defined(__AVX2__)
+# define bcstq(x) ({ \
+vdi_t t_; \
+asm ( "vpbroadcastq %1, %0" : "=x" (t_) : "m" (x) ); \
+t_; \
+})
+# define to_bool(cmp) B(ptestc, , cmp, (vdi_t){} == 0)
+# else
+# define bcstq(x) ((vdi_t){x, x})
+# define to_bool(cmp) (__builtin_ia32_pmovmskb128(cmp) == 0x)
+# endif
+# define eq(x, y) to_bool((x) == (y))
+# define mul(x, y) GF(mulb, , (vqi_t)(x), (vqi_t)(y))
+# define transform(m, dir, x, c) ({ \
+vdi_t m_ = bcstq(m); \
+touch(m_); \
+((vec_t)GF(affine ## dir ## qb, , (vqi_t)(x), (vqi_t)m_, c)); \
+})
+#endif
+
+const unsigned __attribute__((mode(DI))) ident = 0x0102040810204080ULL;
+
+int gf_test(void)
+{
+unsigned int i;
+vec_t src, one;
+
+for ( i = 0; i < ELEM_COUNT; ++i )
+{
+src[i] = i;
+one[i] = 1;
+}
+
+/* Special case for first iteration. */
+one[0] = 0;
+
+do {
+vec_t inv = transform(ident, inv, src, 0);
+
+touch(src);
+
[Xen-devel] [PATCH v10 07/13] x86emul: support VPCLMULQDQ insns
As to the feature dependency adjustment, while strictly speaking AVX is
a sufficient prereq (to have YMM registers), 256-bit vectors of integers
have got fully introduced with AVX2 only. Sadly gcc can't be used as a
reference here: They don't provide any AVX512-independent built-in at
all.
Along the lines of PCLMULQDQ, since the insns here and in particular
their memory access patterns follow the usual scheme, I didn't think it
was necessary to add a contrived test specifically for them, beyond the
Disp8 scaling one.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v10: Re-base.
v9: Re-base. Make VPCLMULQDQ also depend on PCLMULQDQ.
v8: No need to set fault_suppression to false.
v7: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -591,6 +591,10 @@ static const struct test avx512_vpopcntd
INSN(popcnt, 66, 0f38, 55, vl, dq, vl)
};
+static const struct test vpclmulqdq_all[] = {
+INSN(pclmulqdq, 66, 0f3a, 44, vl, q_nb, vl)
+};
+
static const unsigned char vl_all[] = { VL_512, VL_128, VL_256 };
static const unsigned char vl_128[] = { VL_128 };
static const unsigned char vl_no128[] = { VL_512, VL_256 };
@@ -968,4 +972,9 @@ void evex_disp8_test(void *instr, struct
RUN(avx512_vbmi2, all);
RUN(avx512_vnni, all);
RUN(avx512_vpopcntdq, all);
+
+if ( cpu_has_avx512f )
+{
+RUN(vpclmulqdq, all);
+}
}
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -144,6 +144,7 @@ static inline bool xcr0_mask(uint64_t ma
#define cpu_has_avx512vl (cp.feat.avx512vl && xcr0_mask(0xe6))
#define cpu_has_avx512_vbmi (cp.feat.avx512_vbmi && xcr0_mask(0xe6))
#define cpu_has_avx512_vbmi2 (cp.feat.avx512_vbmi2 && xcr0_mask(0xe6))
+#define cpu_has_vpclmulqdq (cp.feat.vpclmulqdq && xcr0_mask(6))
#define cpu_has_avx512_vnni (cp.feat.avx512_vnni && xcr0_mask(0xe6))
#define cpu_has_avx512_bitalg (cp.feat.avx512_bitalg && xcr0_mask(0xe6))
#define cpu_has_avx512_vpopcntdq (cp.feat.avx512_vpopcntdq && xcr0_mask(0xe6))
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -594,7 +594,7 @@ static const struct ext0f3a_table {
[0x3e ... 0x3f] = { .simd_size = simd_packed_int, .d8s = d8s_vl },
[0x40 ... 0x41] = { .simd_size = simd_packed_fp },
[0x42 ... 0x43] = { .simd_size = simd_packed_int, .d8s = d8s_vl },
-[0x44] = { .simd_size = simd_packed_int },
+[0x44] = { .simd_size = simd_packed_int, .d8s = d8s_vl },
[0x46] = { .simd_size = simd_packed_int },
[0x48 ... 0x49] = { .simd_size = simd_packed_fp, .four_op = 1 },
[0x4a ... 0x4b] = { .simd_size = simd_packed_fp, .four_op = 1 },
@@ -1890,6 +1890,7 @@ in_protmode(
#define vcpu_has_avx512vl()(ctxt->cpuid->feat.avx512vl)
#define vcpu_has_avx512_vbmi() (ctxt->cpuid->feat.avx512_vbmi)
#define vcpu_has_avx512_vbmi2() (ctxt->cpuid->feat.avx512_vbmi2)
+#define vcpu_has_vpclmulqdq() (ctxt->cpuid->feat.vpclmulqdq)
#define vcpu_has_avx512_vnni() (ctxt->cpuid->feat.avx512_vnni)
#define vcpu_has_avx512_bitalg() (ctxt->cpuid->feat.avx512_bitalg)
#define vcpu_has_avx512_vpopcntdq() (ctxt->cpuid->feat.avx512_vpopcntdq)
@@ -10207,13 +10208,19 @@ x86_emulate(
goto opmask_shift_imm;
case X86EMUL_OPC_66(0x0f3a, 0x44): /* pclmulqdq $imm8,xmm/m128,xmm */
-case X86EMUL_OPC_VEX_66(0x0f3a, 0x44): /* vpclmulqdq
$imm8,xmm/m128,xmm,xmm */
+case X86EMUL_OPC_VEX_66(0x0f3a, 0x44): /* vpclmulqdq
$imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
host_and_vcpu_must_have(pclmulqdq);
if ( vex.opcx == vex_none )
goto simd_0f3a_common;
-generate_exception_if(vex.l, EXC_UD);
+if ( vex.l )
+host_and_vcpu_must_have(vpclmulqdq);
goto simd_0f_imm8_avx;
+case X86EMUL_OPC_EVEX_66(0x0f3a, 0x44): /* vpclmulqdq
$imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm */
+host_and_vcpu_must_have(vpclmulqdq);
+generate_exception_if(evex.brs || evex.opmsk, EXC_UD);
+goto avx512f_imm8_no_sae;
+
case X86EMUL_OPC_VEX_66(0x0f3a, 0x4a): /* vblendvps
{x,y}mm,{x,y}mm/mem,{x,y}mm,{x,y}mm */
case X86EMUL_OPC_VEX_66(0x0f3a, 0x4b): /* vblendvpd
{x,y}mm,{x,y}mm/mem,{x,y}mm,{x,y}mm */
generate_exception_if(vex.w, EXC_UD);
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -111,6 +111,7 @@
/* CPUID level 0x0007:0.ecx */
#define cpu_has_avx512_vbmi boot_cpu_has(X86_FEATURE_AVX512_VBMI)
#define cpu_has_avx512_vbmi2boot_cpu_has(X86_FEATURE_AVX512_VBMI2)
+#define cpu_has_vpclmulqdq boot_cpu_has(X86_FEATURE_VPCLMULQDQ)
#define cpu_has_avx512_vnni boot_cpu_has(X86_FEATURE_AVX512_VNNI)
#define cpu_has_avx512_bitalg boot_cpu_has(X86_FEATURE_AVX512_BITALG)
#define cpu_has_avx512_vpopcntdq boot_cpu_has(X86_FEATURE_AVX512_VPOPCNTDQ)
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++
[Xen-devel] [PATCH v10 06/13] x86emul: support AVX512_VNNI insns
Along the lines of the 4FMAPS case, convert the 4VNNIW-based table
entries to a decoder adjustment. Because of the current sharing of table
entries between different (implied) opcode prefixes and with the same
major opcodes being used for vp4dpwssd{,s}, which have a different
memory operand size and different Disp8 scaling, the pre-existing table
entries get converted to a decoder override. The table entries will now
represent the insns here, in line with other table entries preferably
representing the prefix-66 insns.
As in a few cases before, since the insns here and in particular their
memory access patterns follow the usual scheme, I didn't think it was
necessary to add a contrived test specifically for them, beyond the
Disp8 scaling one.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v9: Re-base. Explain need for decoder special case.
v8: Re-base.
v7: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -580,6 +580,13 @@ static const struct test avx512_vbmi2_al
INSN(pshrdw,66, 0f3a, 72, vl, w, vl),
};
+static const struct test avx512_vnni_all[] = {
+INSN(pdpbusd, 66, 0f38, 50, vl, d, vl),
+INSN(pdpbusds, 66, 0f38, 51, vl, d, vl),
+INSN(pdpwssd, 66, 0f38, 52, vl, d, vl),
+INSN(pdpwssds, 66, 0f38, 53, vl, d, vl),
+};
+
static const struct test avx512_vpopcntdq_all[] = {
INSN(popcnt, 66, 0f38, 55, vl, dq, vl)
};
@@ -959,5 +966,6 @@ void evex_disp8_test(void *instr, struct
RUN(avx512_ifma, all);
RUN(avx512_vbmi, all);
RUN(avx512_vbmi2, all);
+RUN(avx512_vnni, all);
RUN(avx512_vpopcntdq, all);
}
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -144,6 +144,7 @@ static inline bool xcr0_mask(uint64_t ma
#define cpu_has_avx512vl (cp.feat.avx512vl && xcr0_mask(0xe6))
#define cpu_has_avx512_vbmi (cp.feat.avx512_vbmi && xcr0_mask(0xe6))
#define cpu_has_avx512_vbmi2 (cp.feat.avx512_vbmi2 && xcr0_mask(0xe6))
+#define cpu_has_avx512_vnni (cp.feat.avx512_vnni && xcr0_mask(0xe6))
#define cpu_has_avx512_bitalg (cp.feat.avx512_bitalg && xcr0_mask(0xe6))
#define cpu_has_avx512_vpopcntdq (cp.feat.avx512_vpopcntdq && xcr0_mask(0xe6))
#define cpu_has_avx512_4vnniw (cp.feat.avx512_4vnniw && xcr0_mask(0xe6))
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -479,7 +479,7 @@ static const struct ext0f38_table {
[0x4d] = { .simd_size = simd_scalar_vexw, .d8s = d8s_dq },
[0x4e] = { .simd_size = simd_packed_fp, .two_op = 1, .d8s = d8s_vl },
[0x4f] = { .simd_size = simd_scalar_vexw, .d8s = d8s_dq },
-[0x52 ... 0x53] = { .simd_size = simd_128, .d8s = 4 },
+[0x50 ... 0x53] = { .simd_size = simd_packed_int, .d8s = d8s_vl },
[0x54 ... 0x55] = { .simd_size = simd_packed_int, .two_op = 1, .d8s =
d8s_vl },
[0x58] = { .simd_size = simd_other, .two_op = 1, .d8s = 2 },
[0x59] = { .simd_size = simd_other, .two_op = 1, .d8s = 3 },
@@ -1890,6 +1890,7 @@ in_protmode(
#define vcpu_has_avx512vl()(ctxt->cpuid->feat.avx512vl)
#define vcpu_has_avx512_vbmi() (ctxt->cpuid->feat.avx512_vbmi)
#define vcpu_has_avx512_vbmi2() (ctxt->cpuid->feat.avx512_vbmi2)
+#define vcpu_has_avx512_vnni() (ctxt->cpuid->feat.avx512_vnni)
#define vcpu_has_avx512_bitalg() (ctxt->cpuid->feat.avx512_bitalg)
#define vcpu_has_avx512_vpopcntdq() (ctxt->cpuid->feat.avx512_vpopcntdq)
#define vcpu_has_rdpid() (ctxt->cpuid->feat.rdpid)
@@ -3179,6 +3180,8 @@ x86_decode(
switch ( b )
{
+/* vp4dpwssd{,s} need special casing */
+case 0x52: case 0x53:
/* v4f{,n}madd{p,s}s need special casing */
case 0x9a: case 0x9b: case 0xaa: case 0xab:
if ( evex.pfx == vex_f2 )
@@ -9394,6 +9397,14 @@ x86_emulate(
avx512_vlen_check(true);
goto simd_zmm;
+case X86EMUL_OPC_EVEX_66(0x0f38, 0x50): /* vpdpbusd
[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+case X86EMUL_OPC_EVEX_66(0x0f38, 0x51): /* vpdpbusds
[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+case X86EMUL_OPC_EVEX_66(0x0f38, 0x52): /* vpdpwssd
[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+case X86EMUL_OPC_EVEX_66(0x0f38, 0x53): /* vpdpwssds
[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+host_and_vcpu_must_have(avx512_vnni);
+generate_exception_if(evex.w, EXC_UD);
+goto avx512f_no_sae;
+
case X86EMUL_OPC_EVEX_F2(0x0f38, 0x9a): /* v4fmaddps m128,zmm+3,zmm{k} */
case X86EMUL_OPC_EVEX_F2(0x0f38, 0xaa): /* v4fnmaddps m128,zmm+3,zmm{k} */
host_and_vcpu_must_have(avx512_4fmaps);
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -111,6 +111,7 @@
/* CPUID level 0x0007:0.ecx */
#define cpu_has_avx512_vbmi boot_cpu_has(X86_FEATURE_AVX512_VBMI)
#define cpu_has_avx512_vbmi2boot_cpu_has(X86_FEATURE_AVX512_VBMI2)
+#define cpu_has_avx512_vnni
[Xen-devel] [PATCH v10 02/13] x86emul: support of AVX512_IFMA insns
Once again take the liberty and also correct the (public interface) name
of the AVX512_IFMA feature flag to match the SDM, on the assumption that
no external consumer has actually been using that flag so far.
As in a few cases before, since the insns here and in particular their
memory access patterns follow the usual scheme, I didn't think it was
necessary to add a contrived test specifically for them, beyond the
Disp8 scaling one.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v9: Re-base.
v7: Reject EVEX.W=0.
v6: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -543,6 +543,11 @@ static const struct test avx512_bitalg_a
INSN(pshufbitqmb, 66, 0f38, 8f, vl, b, vl),
};
+static const struct test avx512_ifma_all[] = {
+INSN(pmadd52huq, 66, 0f38, b5, vl, q, vl),
+INSN(pmadd52luq, 66, 0f38, b4, vl, q, vl),
+};
+
static const struct test avx512_vbmi_all[] = {
INSN(permb, 66, 0f38, 8d, vl, b, vl),
INSN(permi2b, 66, 0f38, 75, vl, b, vl),
@@ -929,6 +934,7 @@ void evex_disp8_test(void *instr, struct
#define cpu_has_avx512pf cpu_has_avx512f
RUN(avx512pf, 512);
RUN(avx512_bitalg, all);
+RUN(avx512_ifma, all);
RUN(avx512_vbmi, all);
RUN(avx512_vbmi2, all);
RUN(avx512_vpopcntdq, all);
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -137,6 +137,7 @@ static inline bool xcr0_mask(uint64_t ma
#define cpu_has_bmi2 cp.feat.bmi2
#define cpu_has_avx512f (cp.feat.avx512f && xcr0_mask(0xe6))
#define cpu_has_avx512dq (cp.feat.avx512dq && xcr0_mask(0xe6))
+#define cpu_has_avx512_ifma (cp.feat.avx512_ifma && xcr0_mask(0xe6))
#define cpu_has_avx512er (cp.feat.avx512er && xcr0_mask(0xe6))
#define cpu_has_avx512cd (cp.feat.avx512cd && xcr0_mask(0xe6))
#define cpu_has_avx512bw (cp.feat.avx512bw && xcr0_mask(0xe6))
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -521,6 +521,7 @@ static const struct ext0f38_table {
[0xad] = { .simd_size = simd_scalar_vexw, .d8s = d8s_dq },
[0xae] = { .simd_size = simd_packed_fp, .d8s = d8s_vl },
[0xaf] = { .simd_size = simd_scalar_vexw, .d8s = d8s_dq },
+[0xb4 ... 0xb5] = { .simd_size = simd_packed_int, .d8s = d8s_vl },
[0xb6 ... 0xb8] = { .simd_size = simd_packed_fp, .d8s = d8s_vl },
[0xb9] = { .simd_size = simd_scalar_vexw, .d8s = d8s_dq },
[0xba] = { .simd_size = simd_packed_fp, .d8s = d8s_vl },
@@ -1875,6 +1876,7 @@ in_protmode(
#define vcpu_has_rdseed() (ctxt->cpuid->feat.rdseed)
#define vcpu_has_adx() (ctxt->cpuid->feat.adx)
#define vcpu_has_smap()(ctxt->cpuid->feat.smap)
+#define vcpu_has_avx512_ifma() (ctxt->cpuid->feat.avx512_ifma)
#define vcpu_has_clflushopt() (ctxt->cpuid->feat.clflushopt)
#define vcpu_has_clwb()(ctxt->cpuid->feat.clwb)
#define vcpu_has_avx512pf()(ctxt->cpuid->feat.avx512pf)
@@ -9455,6 +9457,12 @@ x86_emulate(
break;
}
+case X86EMUL_OPC_EVEX_66(0x0f38, 0xb4): /* vpmadd52luq
[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+case X86EMUL_OPC_EVEX_66(0x0f38, 0xb5): /* vpmadd52huq
[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+host_and_vcpu_must_have(avx512_ifma);
+generate_exception_if(!evex.w, EXC_UD);
+goto avx512f_no_sae;
+
case X86EMUL_OPC_EVEX_66(0x0f38, 0xc6):
case X86EMUL_OPC_EVEX_66(0x0f38, 0xc7):
{
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -101,6 +101,7 @@
#define cpu_has_avx512dqboot_cpu_has(X86_FEATURE_AVX512DQ)
#define cpu_has_rdseed boot_cpu_has(X86_FEATURE_RDSEED)
#define cpu_has_smapboot_cpu_has(X86_FEATURE_SMAP)
+#define cpu_has_avx512_ifma boot_cpu_has(X86_FEATURE_AVX512_IFMA)
#define cpu_has_avx512erboot_cpu_has(X86_FEATURE_AVX512ER)
#define cpu_has_avx512cdboot_cpu_has(X86_FEATURE_AVX512CD)
#define cpu_has_sha boot_cpu_has(X86_FEATURE_SHA)
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -212,7 +212,7 @@ XEN_CPUFEATURE(AVX512DQ, 5*32+17) /
XEN_CPUFEATURE(RDSEED,5*32+18) /*A RDSEED instruction */
XEN_CPUFEATURE(ADX, 5*32+19) /*A ADCX, ADOX instructions */
XEN_CPUFEATURE(SMAP, 5*32+20) /*S Supervisor Mode Access Prevention
*/
-XEN_CPUFEATURE(AVX512IFMA,5*32+21) /*A AVX-512 Integer Fused Multiply Add
*/
+XEN_CPUFEATURE(AVX512_IFMA, 5*32+21) /*A AVX-512 Integer Fused Multiply Add
*/
XEN_CPUFEATURE(CLFLUSHOPT,5*32+23) /*A CLFLUSHOPT instruction */
XEN_CPUFEATURE(CLWB, 5*32+24) /*A CLWB instruction */
XEN_CPUFEATURE(AVX512PF, 5*32+26) /*A AVX-512 Prefetch Instructions */
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -261,7 +261,7 @@ def crunch_numbers(state):
# (which in practice depends on the EVEX prefix to encode) as
[Xen-devel] [PATCH v10 05/13] x86emul: support AVX512_4VNNIW insns
As in a few cases before, since the insns here and in particular their
memory access patterns follow the AVX512_4FMAPS scheme, I didn't think
it was necessary to add contrived tests specifically for them, beyond
the Disp8 scaling ones.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v9: Re-base.
v8: Correct vcpu_has_*() insertion point.
v7: Re-base.
v6: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -545,6 +545,11 @@ static const struct test avx512_4fmaps_5
INSN(4fnmaddss, f2, 0f38, ab, el_4, d, vl),
};
+static const struct test avx512_4vnniw_512[] = {
+INSN(p4dpwssd, f2, 0f38, 52, el_4, d, vl),
+INSN(p4dpwssds, f2, 0f38, 53, el_4, d, vl),
+};
+
static const struct test avx512_bitalg_all[] = {
INSN(popcnt, 66, 0f38, 54, vl, bw, vl),
INSN(pshufbitqmb, 66, 0f38, 8f, vl, b, vl),
@@ -949,6 +954,7 @@ void evex_disp8_test(void *instr, struct
#define cpu_has_avx512pf cpu_has_avx512f
RUN(avx512pf, 512);
RUN(avx512_4fmaps, 512);
+RUN(avx512_4vnniw, 512);
RUN(avx512_bitalg, all);
RUN(avx512_ifma, all);
RUN(avx512_vbmi, all);
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -146,6 +146,7 @@ static inline bool xcr0_mask(uint64_t ma
#define cpu_has_avx512_vbmi2 (cp.feat.avx512_vbmi2 && xcr0_mask(0xe6))
#define cpu_has_avx512_bitalg (cp.feat.avx512_bitalg && xcr0_mask(0xe6))
#define cpu_has_avx512_vpopcntdq (cp.feat.avx512_vpopcntdq && xcr0_mask(0xe6))
+#define cpu_has_avx512_4vnniw (cp.feat.avx512_4vnniw && xcr0_mask(0xe6))
#define cpu_has_avx512_4fmaps (cp.feat.avx512_4fmaps && xcr0_mask(0xe6))
#define cpu_has_xgetbv1 (cpu_has_xsave && cp.xstate.xgetbv1)
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -479,6 +479,7 @@ static const struct ext0f38_table {
[0x4d] = { .simd_size = simd_scalar_vexw, .d8s = d8s_dq },
[0x4e] = { .simd_size = simd_packed_fp, .two_op = 1, .d8s = d8s_vl },
[0x4f] = { .simd_size = simd_scalar_vexw, .d8s = d8s_dq },
+[0x52 ... 0x53] = { .simd_size = simd_128, .d8s = 4 },
[0x54 ... 0x55] = { .simd_size = simd_packed_int, .two_op = 1, .d8s =
d8s_vl },
[0x58] = { .simd_size = simd_other, .two_op = 1, .d8s = 2 },
[0x59] = { .simd_size = simd_other, .two_op = 1, .d8s = 3 },
@@ -1892,6 +1893,7 @@ in_protmode(
#define vcpu_has_avx512_bitalg() (ctxt->cpuid->feat.avx512_bitalg)
#define vcpu_has_avx512_vpopcntdq() (ctxt->cpuid->feat.avx512_vpopcntdq)
#define vcpu_has_rdpid() (ctxt->cpuid->feat.rdpid)
+#define vcpu_has_avx512_4vnniw() (ctxt->cpuid->feat.avx512_4vnniw)
#define vcpu_has_avx512_4fmaps() (ctxt->cpuid->feat.avx512_4fmaps)
#define vcpu_must_have(feat) \
@@ -8920,6 +8922,15 @@ x86_emulate(
generate_exception_if(vex.l, EXC_UD);
goto simd_0f_avx;
+case X86EMUL_OPC_EVEX_F2(0x0f38, 0x52): /* vp4dpwssd m128,zmm+3,zmm{k} */
+case X86EMUL_OPC_EVEX_F2(0x0f38, 0x53): /* vp4dpwssds m128,zmm+3,zmm{k} */
+host_and_vcpu_must_have(avx512_4vnniw);
+generate_exception_if((ea.type != OP_MEM || evex.w || evex.brs ||
+ evex.lr != 2),
+ EXC_UD);
+op_mask = op_mask & 0x ? 0xf : 0;
+goto simd_zmm;
+
case X86EMUL_OPC_EVEX_66(0x0f38, 0x8f): /* vpshufbitqmb
[xyz]mm/mem,[xyz]mm,k{k} */
generate_exception_if(evex.w || !evex.r || !evex.R || evex.z, EXC_UD);
/* fall through */
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -119,6 +119,7 @@
#define cpu_has_itscboot_cpu_has(X86_FEATURE_ITSC)
/* CPUID level 0x0007:0.edx */
+#define cpu_has_avx512_4vnniw boot_cpu_has(X86_FEATURE_AVX512_4VNNIW)
#define cpu_has_avx512_4fmaps boot_cpu_has(X86_FEATURE_AVX512_4FMAPS)
#define cpu_has_tsx_force_abort boot_cpu_has(X86_FEATURE_TSX_FORCE_ABORT)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v10 04/13] x86emul: support AVX512_4FMAPS insns
A decoder adjustment is needed here because of the current sharing of
table entries between different (implied) opcode prefixes: The same
major opcodes are used for vfmsub{132,213}{p,s}{s,d}, which have a
different memory operand size and different Disp8 scaling.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v9: Re-base. Explain need for decoder special case.
v8: Correct vcpu_has_*() insertion point.
v7: Re-base.
v6: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -538,6 +538,13 @@ static const struct test avx512pf_512[]
INSNX(scatterpf1q, 66, 0f38, c7, 6, vl, sd, el),
};
+static const struct test avx512_4fmaps_512[] = {
+INSN(4fmaddps, f2, 0f38, 9a, el_4, d, vl),
+INSN(4fmaddss, f2, 0f38, 9b, el_4, d, vl),
+INSN(4fnmaddps, f2, 0f38, aa, el_4, d, vl),
+INSN(4fnmaddss, f2, 0f38, ab, el_4, d, vl),
+};
+
static const struct test avx512_bitalg_all[] = {
INSN(popcnt, 66, 0f38, 54, vl, bw, vl),
INSN(pshufbitqmb, 66, 0f38, 8f, vl, b, vl),
@@ -941,6 +948,7 @@ void evex_disp8_test(void *instr, struct
RUN(avx512er, 512);
#define cpu_has_avx512pf cpu_has_avx512f
RUN(avx512pf, 512);
+RUN(avx512_4fmaps, 512);
RUN(avx512_bitalg, all);
RUN(avx512_ifma, all);
RUN(avx512_vbmi, all);
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -4274,6 +4274,81 @@ int main(int argc, char **argv)
}
#endif
+printf("%-40s", "Testing v4fmaddps 32(%ecx),%zmm4,%zmm4{%k5}...");
+if ( stack_exec && cpu_has_avx512_4fmaps )
+{
+decl_insn(v4fmaddps);
+static const struct {
+float f[16];
+} in = {{
+1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
+}}, out = {{
+1 + 1 * 9 + 2 * 10 + 3 * 11 + 4 * 12,
+2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
+16 + 16 * 9 + 17 * 10 + 18 * 11 + 19 * 12
+}};
+
+asm volatile ( "vmovups %1, %%zmm4\n\t"
+ "vbroadcastss %%xmm4, %%zmm7\n\t"
+ "vaddps %%zmm4, %%zmm7, %%zmm5\n\t"
+ "vaddps %%zmm5, %%zmm7, %%zmm6\n\t"
+ "vaddps %%zmm6, %%zmm7, %%zmm7\n\t"
+ "kmovw %2, %%k5\n"
+ put_insn(v4fmaddps,
+"v4fmaddps 32(%0), %%zmm4, %%zmm4%{%%k5%}")
+ :: "c" (NULL), "m" (in), "rmk" (0x8001) );
+
+set_insn(v4fmaddps);
+regs.ecx = (unsigned long)
+rc = x86_emulate(, );
+if ( rc != X86EMUL_OKAY || !check_eip(v4fmaddps) )
+goto fail;
+
+asm ( "vcmpeqps %1, %%zmm4, %%k0\n\t"
+ "kmovw %%k0, %0" : "=g" (rc) : "m" (out) );
+if ( rc != 0x )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing v4fnmaddss 16(%edx),%zmm4,%zmm4{%k3}...");
+if ( stack_exec && cpu_has_avx512_4fmaps )
+{
+decl_insn(v4fnmaddss);
+static const struct {
+float f[16];
+} in = {{
+1, 2, 3, 4, 5, 6, 7, 8
+}}, out = {{
+1 - 1 * 5 - 2 * 6 - 3 * 7 - 4 * 8, 2, 3, 4
+}};
+
+asm volatile ( "vmovups %1, %%xmm4\n\t"
+ "vaddss %%xmm4, %%xmm4, %%xmm5\n\t"
+ "vaddss %%xmm5, %%xmm4, %%xmm6\n\t"
+ "vaddss %%xmm6, %%xmm4, %%xmm7\n\t"
+ "kmovw %2, %%k3\n"
+ put_insn(v4fnmaddss,
+"v4fnmaddss 16(%0), %%xmm4, %%xmm4%{%%k3%}")
+ :: "d" (NULL), "m" (in), "rmk" (1) );
+
+set_insn(v4fnmaddss);
+regs.edx = (unsigned long)
+rc = x86_emulate(, );
+if ( rc != X86EMUL_OKAY || !check_eip(v4fnmaddss) )
+goto fail;
+
+asm ( "vcmpeqps %1, %%zmm4, %%k0\n\t"
+ "kmovw %%k0, %0" : "=g" (rc) : "m" (out) );
+if ( rc != 0x )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
#undef decl_insn
#undef put_insn
#undef set_insn
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -146,6 +146,7 @@ static inline bool xcr0_mask(uint64_t ma
#define cpu_has_avx512_vbmi2 (cp.feat.avx512_vbmi2 && xcr0_mask(0xe6))
#define cpu_has_avx512_bitalg (cp.feat.avx512_bitalg && xcr0_mask(0xe6))
#define cpu_has_avx512_vpopcntdq (cp.feat.avx512_vpopcntdq && xcr0_mask(0xe6))
+#define cpu_has_avx512_4fmaps (cp.feat.avx512_4fmaps && xcr0_mask(0xe6))
#define cpu_has_xgetbv1 (cpu_has_xsave && cp.xstate.xgetbv1)
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1892,6 +1892,7 @@ in_protmode(
#define vcpu_has_avx512_bitalg() (ctxt->cpuid->feat.avx512_bitalg)
#define
[Xen-devel] [PATCH v10 03/13] x86emul: support remaining AVX512_VBMI2 insns
As in a few cases before, since the insns here and in particular their
memory access patterns follow the usual scheme, I didn't think it was
necessary to add a contrived test specifically for them, beyond the
Disp8 scaling one.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v7: Re-base over change earlier in the series.
v6: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -558,6 +558,14 @@ static const struct test avx512_vbmi_all
static const struct test avx512_vbmi2_all[] = {
INSN(pcompress, 66, 0f38, 63, vl, bw, el),
INSN(pexpand, 66, 0f38, 62, vl, bw, el),
+INSN(pshld, 66, 0f3a, 71, vl, dq, vl),
+INSN(pshldv,66, 0f38, 71, vl, dq, vl),
+INSN(pshldvw, 66, 0f38, 70, vl, w, vl),
+INSN(pshldw,66, 0f3a, 70, vl, w, vl),
+INSN(pshrd, 66, 0f3a, 73, vl, dq, vl),
+INSN(pshrdv,66, 0f38, 73, vl, dq, vl),
+INSN(pshrdvw, 66, 0f38, 72, vl, w, vl),
+INSN(pshrdw,66, 0f3a, 72, vl, w, vl),
};
static const struct test avx512_vpopcntdq_all[] = {
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -487,6 +487,7 @@ static const struct ext0f38_table {
[0x62] = { .simd_size = simd_packed_int, .two_op = 1, .d8s = d8s_bw },
[0x63] = { .simd_size = simd_packed_int, .to_mem = 1, .two_op = 1, .d8s =
d8s_bw },
[0x64 ... 0x66] = { .simd_size = simd_packed_int, .d8s = d8s_vl },
+[0x70 ... 0x73] = { .simd_size = simd_packed_int, .d8s = d8s_vl },
[0x75 ... 0x76] = { .simd_size = simd_packed_int, .d8s = d8s_vl },
[0x77] = { .simd_size = simd_packed_fp, .d8s = d8s_vl },
[0x78] = { .simd_size = simd_other, .two_op = 1 },
@@ -611,6 +612,7 @@ static const struct ext0f3a_table {
[0x6a ... 0x6b] = { .simd_size = simd_scalar_opc, .four_op = 1 },
[0x6c ... 0x6d] = { .simd_size = simd_packed_fp, .four_op = 1 },
[0x6e ... 0x6f] = { .simd_size = simd_scalar_opc, .four_op = 1 },
+[0x70 ... 0x73] = { .simd_size = simd_packed_int, .d8s = d8s_vl },
[0x78 ... 0x79] = { .simd_size = simd_packed_fp, .four_op = 1 },
[0x7a ... 0x7b] = { .simd_size = simd_scalar_opc, .four_op = 1 },
[0x7c ... 0x7d] = { .simd_size = simd_packed_fp, .four_op = 1 },
@@ -8969,6 +8971,16 @@ x86_emulate(
}
goto simd_zmm;
+case X86EMUL_OPC_EVEX_66(0x0f38, 0x70): /* vpshldvw
[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+case X86EMUL_OPC_EVEX_66(0x0f38, 0x72): /* vpshrdvw
[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+generate_exception_if(!evex.w, EXC_UD);
+elem_bytes = 2;
+/* fall through */
+case X86EMUL_OPC_EVEX_66(0x0f38, 0x71): /* vpshldv{d,q}
[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+case X86EMUL_OPC_EVEX_66(0x0f38, 0x73): /* vpshrdv{d,q}
[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+host_and_vcpu_must_have(avx512_vbmi2);
+goto avx512f_no_sae;
+
case X86EMUL_OPC_EVEX_66(0x0f38, 0x75): /* vpermi2{b,w}
[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
case X86EMUL_OPC_EVEX_66(0x0f38, 0x7d): /* vpermt2{b,w}
[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
case X86EMUL_OPC_EVEX_66(0x0f38, 0x8d): /* vperm{b,w}
[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
@@ -10281,6 +10293,16 @@ x86_emulate(
avx512_vlen_check(true);
goto simd_imm8_zmm;
+case X86EMUL_OPC_EVEX_66(0x0f3a, 0x70): /* vpshldw
$imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+case X86EMUL_OPC_EVEX_66(0x0f3a, 0x72): /* vpshrdw
$imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+generate_exception_if(!evex.w, EXC_UD);
+elem_bytes = 2;
+/* fall through */
+case X86EMUL_OPC_EVEX_66(0x0f3a, 0x71): /* vpshld{d,q}
$imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+case X86EMUL_OPC_EVEX_66(0x0f3a, 0x73): /* vpshrd{d,q}
$imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+host_and_vcpu_must_have(avx512_vbmi2);
+goto avx512f_imm8_no_sae;
+
case X86EMUL_OPC(0x0f3a, 0xcc): /* sha1rnds4 $imm8,xmm/m128,xmm */
host_and_vcpu_must_have(sha);
op_bytes = 16;
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v10 01/13] x86emul: support of AVX512* population count insns
Plus the only other AVX512_BITALG one.
As in a few cases before, since the insns here and in particular their
memory access patterns follow the usual scheme, I didn't think it was
necessary to add a contrived test specifically for them, beyond the
Disp8 scaling one.
Signed-off-by: Jan Beulich
---
v10: Sort AVX512BW deps by number instead of alphabetically.
v9: Re-base.
v7: Re-base.
v6: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -538,6 +538,11 @@ static const struct test avx512pf_512[]
INSNX(scatterpf1q, 66, 0f38, c7, 6, vl, sd, el),
};
+static const struct test avx512_bitalg_all[] = {
+INSN(popcnt, 66, 0f38, 54, vl, bw, vl),
+INSN(pshufbitqmb, 66, 0f38, 8f, vl, b, vl),
+};
+
static const struct test avx512_vbmi_all[] = {
INSN(permb, 66, 0f38, 8d, vl, b, vl),
INSN(permi2b, 66, 0f38, 75, vl, b, vl),
@@ -550,6 +555,10 @@ static const struct test avx512_vbmi2_al
INSN(pexpand, 66, 0f38, 62, vl, bw, el),
};
+static const struct test avx512_vpopcntdq_all[] = {
+INSN(popcnt, 66, 0f38, 55, vl, dq, vl)
+};
+
static const unsigned char vl_all[] = { VL_512, VL_128, VL_256 };
static const unsigned char vl_128[] = { VL_128 };
static const unsigned char vl_no128[] = { VL_512, VL_256 };
@@ -919,6 +928,8 @@ void evex_disp8_test(void *instr, struct
RUN(avx512er, 512);
#define cpu_has_avx512pf cpu_has_avx512f
RUN(avx512pf, 512);
+RUN(avx512_bitalg, all);
RUN(avx512_vbmi, all);
RUN(avx512_vbmi2, all);
+RUN(avx512_vpopcntdq, all);
}
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -143,6 +143,8 @@ static inline bool xcr0_mask(uint64_t ma
#define cpu_has_avx512vl (cp.feat.avx512vl && xcr0_mask(0xe6))
#define cpu_has_avx512_vbmi (cp.feat.avx512_vbmi && xcr0_mask(0xe6))
#define cpu_has_avx512_vbmi2 (cp.feat.avx512_vbmi2 && xcr0_mask(0xe6))
+#define cpu_has_avx512_bitalg (cp.feat.avx512_bitalg && xcr0_mask(0xe6))
+#define cpu_has_avx512_vpopcntdq (cp.feat.avx512_vpopcntdq && xcr0_mask(0xe6))
#define cpu_has_xgetbv1 (cpu_has_xsave && cp.xstate.xgetbv1)
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -479,6 +479,7 @@ static const struct ext0f38_table {
[0x4d] = { .simd_size = simd_scalar_vexw, .d8s = d8s_dq },
[0x4e] = { .simd_size = simd_packed_fp, .two_op = 1, .d8s = d8s_vl },
[0x4f] = { .simd_size = simd_scalar_vexw, .d8s = d8s_dq },
+[0x54 ... 0x55] = { .simd_size = simd_packed_int, .two_op = 1, .d8s =
d8s_vl },
[0x58] = { .simd_size = simd_other, .two_op = 1, .d8s = 2 },
[0x59] = { .simd_size = simd_other, .two_op = 1, .d8s = 3 },
[0x5a] = { .simd_size = simd_128, .two_op = 1, .d8s = 4 },
@@ -501,6 +502,7 @@ static const struct ext0f38_table {
[0x8c] = { .simd_size = simd_packed_int },
[0x8d] = { .simd_size = simd_packed_int, .d8s = d8s_vl },
[0x8e] = { .simd_size = simd_packed_int, .to_mem = 1 },
+[0x8f] = { .simd_size = simd_packed_int, .d8s = d8s_vl },
[0x90 ... 0x93] = { .simd_size = simd_other, .vsib = 1, .d8s = d8s_dq },
[0x96 ... 0x98] = { .simd_size = simd_packed_fp, .d8s = d8s_vl },
[0x99] = { .simd_size = simd_scalar_vexw, .d8s = d8s_dq },
@@ -1883,6 +1885,8 @@ in_protmode(
#define vcpu_has_avx512vl()(ctxt->cpuid->feat.avx512vl)
#define vcpu_has_avx512_vbmi() (ctxt->cpuid->feat.avx512_vbmi)
#define vcpu_has_avx512_vbmi2() (ctxt->cpuid->feat.avx512_vbmi2)
+#define vcpu_has_avx512_bitalg() (ctxt->cpuid->feat.avx512_bitalg)
+#define vcpu_has_avx512_vpopcntdq() (ctxt->cpuid->feat.avx512_vpopcntdq)
#define vcpu_has_rdpid() (ctxt->cpuid->feat.rdpid)
#define vcpu_must_have(feat) \
@@ -8899,6 +8903,19 @@ x86_emulate(
generate_exception_if(vex.l, EXC_UD);
goto simd_0f_avx;
+case X86EMUL_OPC_EVEX_66(0x0f38, 0x8f): /* vpshufbitqmb
[xyz]mm/mem,[xyz]mm,k{k} */
+generate_exception_if(evex.w || !evex.r || !evex.R || evex.z, EXC_UD);
+/* fall through */
+case X86EMUL_OPC_EVEX_66(0x0f38, 0x54): /* vpopcnt{b,w}
[xyz]mm/mem,[xyz]mm{k} */
+host_and_vcpu_must_have(avx512_bitalg);
+generate_exception_if(evex.brs, EXC_UD);
+elem_bytes = 1 << evex.w;
+goto avx512f_no_sae;
+
+case X86EMUL_OPC_EVEX_66(0x0f38, 0x55): /* vpopcnt{d,q}
[xyz]mm/mem,[xyz]mm{k} */
+host_and_vcpu_must_have(avx512_vpopcntdq);
+goto avx512f_no_sae;
+
case X86EMUL_OPC_VEX_66(0x0f38, 0x58): /* vpbroadcastd xmm/m32,{x,y}mm */
case X86EMUL_OPC_VEX_66(0x0f38, 0x59): /* vpbroadcastq xmm/m64,{x,y}mm */
case X86EMUL_OPC_VEX_66(0x0f38, 0x78): /* vpbroadcastb xmm/m8,{x,y}mm */
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -110,6 +110,8 @@
/* CPUID level 0x0007:0.ecx */
#define cpu_has_avx512_vbmi boot_cpu_has(X86_FEATURE_AVX512_VBMI)
#define
[Xen-devel] [PATCH v10 00/13] x86emul: remaining AVX512 support
01: support of AVX512* population count insns 02: support of AVX512_IFMA insns 03: support remaining AVX512_VBMI2 insns 04: support AVX512_4FMAPS insns 05: support AVX512_4VNNIW insns 06: support AVX512_VNNI insns 07: support VPCLMULQDQ insns 08: support VAES insns 09: support GFNI insns 10: restore ordering within main switch statement 11: add an AES/VAES test case to the harness 12: add a SHA test case to the harness 13: add a PCLMUL/VPCLMUL test case to the harness Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 02/14] AMD/IOMMU: use bit field for extended feature register
On 16.07.2019 18:35, Jan Beulich wrote:
> --- a/xen/drivers/passthrough/amd/iommu_detect.c
> +++ b/xen/drivers/passthrough/amd/iommu_detect.c
> @@ -60,49 +60,77 @@ static int __init get_iommu_capabilities
>
>void __init get_iommu_features(struct amd_iommu *iommu)
>{
> -u32 low, high;
> -int i = 0 ;
>const struct amd_iommu *first;
> -static const char *__initdata feature_str[] = {
> -"- Prefetch Pages Command",
> -"- Peripheral Page Service Request",
> -"- X2APIC Supported",
> -"- NX bit Supported",
> -"- Guest Translation",
> -"- Reserved bit [5]",
> -"- Invalidate All Command",
> -"- Guest APIC supported",
> -"- Hardware Error Registers",
> -"- Performance Counters",
> -NULL
> -};
> -
>ASSERT( iommu->mmio_base );
>
>if ( !iommu_has_cap(iommu, PCI_CAP_EFRSUP_SHIFT) )
>{
> -iommu->features = 0;
> +iommu->features.raw = 0;
>return;
>}
>
> -low = readl(iommu->mmio_base + IOMMU_EXT_FEATURE_MMIO_OFFSET);
> -high = readl(iommu->mmio_base + IOMMU_EXT_FEATURE_MMIO_OFFSET + 4);
> -
> -iommu->features = ((u64)high << 32) | low;
> +iommu->features.raw =
> +readq(iommu->mmio_base + IOMMU_EXT_FEATURE_MMIO_OFFSET);
>
>/* Don't log the same set of features over and over. */
>first = list_first_entry(_iommu_head, struct amd_iommu, list);
> -if ( iommu != first && iommu->features == first->features )
> +if ( iommu != first && iommu->features.raw == first->features.raw )
>return;
>
>printk("AMD-Vi: IOMMU Extended Features:\n");
>
> -while ( feature_str[i] )
> +#define FEAT(fld, str) do {\
> +if ( --((union amd_iommu_ext_features){}).flds.fld > 1 ) \
> +printk( "- " str ": %#x\n", iommu->features.flds.fld); \
> +else if ( iommu->features.flds.fld ) \
> +printk( "- " str "\n");\
> +} while ( false )
> +
> +FEAT(pref_sup, "Prefetch Pages Command");
> +FEAT(ppr_sup,"Peripheral Page Service Request");
> +FEAT(xt_sup, "x2APIC");
> +FEAT(nx_sup, "NX bit");
> +FEAT(gappi_sup, "Guest APIC Physical Processor Interrupt");
> +FEAT(ia_sup, "Invalidate All Command");
> +FEAT(ga_sup, "Guest APIC");
> +FEAT(he_sup, "Hardware Error Registers");
> +FEAT(pc_sup, "Performance Counters");
> +FEAT(hats, "Host Address Translation Size");
> +
> +if ( iommu->features.flds.gt_sup )
>{
> -if ( amd_iommu_has_feature(iommu, i) )
> -printk( " %s\n", feature_str[i]);
> -i++;
> +FEAT(gats, "Guest Address Translation Size");
> +FEAT(glx_sup,"Guest CR3 Root Table Level");
> +FEAT(pas_max,"Maximum PASID");
>}
> +
> +FEAT(smif_sup, "SMI Filter Register");
> +FEAT(smif_rc,"SMI Filter Register Count");
> +FEAT(gam_sup,"Guest Virtual APIC Modes");
> +FEAT(dual_ppr_log_sup, "Dual PPR Log");
> +FEAT(dual_event_log_sup, "Dual Event Log");
> +FEAT(sats_sup, "Secure ATS");
> +FEAT(us_sup, "User / Supervisor Page Protection");
> +FEAT(dev_tbl_seg_sup,"Device Table Segmentation");
> +FEAT(ppr_early_of_sup, "PPR Log Overflow Early Warning");
> +FEAT(ppr_auto_rsp_sup, "PPR Automatic Response");
> +FEAT(marc_sup, "Memory Access Routing and Control");
> +FEAT(blk_stop_mrk_sup, "Block StopMark Message");
> +FEAT(perf_opt_sup , "Performance Optimization");
> +FEAT(msi_cap_mmio_sup, "MSI Capability MMIO Access");
> +FEAT(gio_sup,"Guest I/O Protection");
> +FEAT(ha_sup, "Host Access");
> +FEAT(eph_sup,"Enhanced PPR Handling");
> +FEAT(attr_fw_sup,"Attribute Forward");
> +FEAT(hd_sup, "Host Dirty");
> +FEAT(inv_iotlb_type_sup, "Invalidate IOTLB Type");
> +FEAT(viommu_sup, "Virtualized IOMMU");
> +FEAT(vm_guard_io_sup,"VMGuard I/O Support");
> +FEAT(vm_table_size, "VM Table Size");
> +FEAT(ga_update_dis_sup, "Guest Access Bit Update Disable");
> +
> +#undef FEAT
> +#undef MASK
>}
Just realized that I had left in place here a no longer needed #undef.
Now dropped.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
