Re: [Xen-devel] [PATCH v2] kexec: implemented XEN KEXEC STATUS to determine if an image is loaded
On Sat, Jan 21, 2017 at 09:43:19AM +0800, Baoquan He wrote: > Hi, > > I don't strongly oppose against this, but could you tell what you have > met makes the kexec_loaded/kexec_crash_loaded checking not convenient to > you? kexec_loaded/kexec_crash_loaded exposes Linux kernel kexec/crash state. It does not say anything about Xen kexec/crash state. So, we need a special approach to get the latter. Though for compatibility we provide similar functionality in kexec-tools for the former. I hope that helps. > On 01/20/17 at 11:03am, Eric DeVolder wrote: > > Instead of the scripts having to poke at various fields we can > > provide that functionality via the -S parameter. > > > > Returns 0 if the payload is loaded. Can be used in combination > > with -l or -p to get the state of the proper kexec image. > > > > Signed-off-by: Konrad Rzeszutek Wilk > > Signed-off-by: Eric DeVolder > > --- > > Note: The corresponding Xen changes have been committed > > to the Xen staging branch. Follow this thread: > > https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg01570.html > > > > CC: Andrew Cooper > > CC: ke...@lists.infradead.org > > CC: xen-de...@lists.xenproject.org > > CC: Daniel Kiper > > > > v0: First version (internal product). > > v1: Posted on kexec mailing list. Changed -s to -S > > v2: Incorporated feedback from kexec mailing list > > --- > > configure.ac | 8 ++- > > kexec/kexec-xen.c | 26 +++ > > kexec/kexec.8 | 6 ++ > > kexec/kexec.c | 62 > > --- > > kexec/kexec.h | 5 - > > 5 files changed, 98 insertions(+), 9 deletions(-) > > > > diff --git a/configure.ac b/configure.ac > > index 3044185..c6e864b 100644 > > --- a/configure.ac > > +++ b/configure.ac > > @@ -165,8 +165,14 @@ fi > > dnl find Xen control stack libraries > > if test "$with_xen" = yes ; then > > AC_CHECK_HEADER(xenctrl.h, > > - [AC_CHECK_LIB(xenctrl, xc_kexec_load, , > > + [AC_CHECK_LIB(xenctrl, xc_kexec_load, [ have_xenctrl_h=yes ], > > AC_MSG_NOTICE([Xen support disabled]))]) > > +if test "$have_xenctrl_h" = yes ; then > > + AC_CHECK_LIB(xenctrl, xc_kexec_status, > > + AC_DEFINE(HAVE_KEXEC_CMD_STATUS, 1, > > + [The kexec_status call is available]), > > + AC_MSG_NOTICE([The kexec_status call is not available])) > > +fi Eric, I have a feeling that you should add en extra indentation for lines starting from "+if test "$have_xenctrl_h"..." and ending at "+fi". Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] kexec: implemented XEN KEXEC STATUS to determine if an image is loaded
On 01/23/17 at 09:34am, Daniel Kiper wrote: > On Sat, Jan 21, 2017 at 09:43:19AM +0800, Baoquan He wrote: > > Hi, > > > > I don't strongly oppose against this, but could you tell what you have > > met makes the kexec_loaded/kexec_crash_loaded checking not convenient to > > you? > > kexec_loaded/kexec_crash_loaded exposes Linux kernel kexec/crash state. > It does not say anything about Xen kexec/crash state. So, we need a special > approach to get the latter. Though for compatibility we provide similar > functionality in kexec-tools for the former. > > I hope that helps. Thanks for telling. Understood. Then it makes sense. Better put above explanation into log. Thanks Baoquan > > > On 01/20/17 at 11:03am, Eric DeVolder wrote: > > > Instead of the scripts having to poke at various fields we can > > > provide that functionality via the -S parameter. > > > > > > Returns 0 if the payload is loaded. Can be used in combination > > > with -l or -p to get the state of the proper kexec image. > > > > > > Signed-off-by: Konrad Rzeszutek Wilk > > > Signed-off-by: Eric DeVolder > > > --- > > > Note: The corresponding Xen changes have been committed > > > to the Xen staging branch. Follow this thread: > > > https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg01570.html > > > > > > CC: Andrew Cooper > > > CC: ke...@lists.infradead.org > > > CC: xen-de...@lists.xenproject.org > > > CC: Daniel Kiper > > > > > > v0: First version (internal product). > > > v1: Posted on kexec mailing list. Changed -s to -S > > > v2: Incorporated feedback from kexec mailing list > > > --- > > > configure.ac | 8 ++- > > > kexec/kexec-xen.c | 26 +++ > > > kexec/kexec.8 | 6 ++ > > > kexec/kexec.c | 62 > > > --- > > > kexec/kexec.h | 5 - > > > 5 files changed, 98 insertions(+), 9 deletions(-) > > > > > > diff --git a/configure.ac b/configure.ac > > > index 3044185..c6e864b 100644 > > > --- a/configure.ac > > > +++ b/configure.ac > > > @@ -165,8 +165,14 @@ fi > > > dnl find Xen control stack libraries > > > if test "$with_xen" = yes ; then > > > AC_CHECK_HEADER(xenctrl.h, > > > - [AC_CHECK_LIB(xenctrl, xc_kexec_load, , > > > + [AC_CHECK_LIB(xenctrl, xc_kexec_load, [ have_xenctrl_h=yes ], > > > AC_MSG_NOTICE([Xen support disabled]))]) > > > +if test "$have_xenctrl_h" = yes ; then > > > + AC_CHECK_LIB(xenctrl, xc_kexec_status, > > > + AC_DEFINE(HAVE_KEXEC_CMD_STATUS, 1, > > > + [The kexec_status call is available]), > > > + AC_MSG_NOTICE([The kexec_status call is not available])) > > > +fi > > Eric, I have a feeling that you should add en extra indentation > for lines starting from "+if test "$have_xenctrl_h"..." and > ending at "+fi". > > Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 7/8] dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi
> -Original Message-
> From: Andrew Cooper
> Sent: 20 January 2017 18:34
> To: Paul Durrant ; xen-de...@lists.xenproject.org
> Cc: Daniel De Graaf ; Ian Jackson
>
> Subject: Re: [PATCH v4 7/8] dm_op: convert HVMOP_inject_trap and
> HVMOP_inject_msi
>
> On 17/01/17 17:29, Paul Durrant wrote:
> > diff --git a/xen/include/public/hvm/dm_op.h
> b/xen/include/public/hvm/dm_op.h
> > index 8e9bef1..abe8bbe 100644
> > --- a/xen/include/public/hvm/dm_op.h
> > +++ b/xen/include/public/hvm/dm_op.h
> > @@ -273,6 +273,52 @@ struct xen_dm_op_set_mem_type {
> > uint64_aligned_t first_pfn;
> > };
> >
> > +/*
> > + * XEN_DMOP_inject_trap: Inject a trap into a VCPU, which will get taken
> up
> > + * when it is next scheduled.
> > + *
> > + * Note that the caller should know enough of the state of the CPU before
> > + * injecting, to know what the effect of injecting the trap will be.
> > + */
> > +#define XEN_DMOP_inject_trap 13
> > +
> > +struct xen_dm_op_inject_trap {
>
> Along with internal fixing of the (mis)use of the term trap inside the
> hypervisor, please s/trap/event/ in this new API.
>
Ok.
> > +/* IN - index of vCPU */
> > +uint32_t vcpuid;
> > +/* IN - interrupt vector */
> > +uint8_t vector;
> > +/* IN - trap type (DMOP_TRAP_* ) */
> > +uint8_t type;
> > +/* NB. This enumeration precisely matches hvm.h:X86_EVENTTYPE_* */
> > +# define XEN_DMOP_TRAP_ext_int0 /* external interrupt */
> > +# define XEN_DMOP_TRAP_nmi2 /* nmi */
> > +# define XEN_DMOP_TRAP_hw_exc 3 /* hardware exception */
> > +# define XEN_DMOP_TRAP_sw_int 4 /* software interrupt (CD nn) */
> > +# define XEN_DMOP_TRAP_pri_sw_exc 5 /* ICEBP (F1) */
> > +# define XEN_DMOP_TRAP_sw_exc 6 /* INT3 (CC), INTO (CE) */
> > +/* IN - enstruction length */
>
> What is an enstruction? :)
>
That would be an historic speeling mistake that I cut'n'pasted :-)
> Otherwise, Reviewed-by: Andrew Cooper
Ta,
Paul
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 6/8] dm_op: convert HVMOP_set_mem_type
> -Original Message-
> From: Andrew Cooper
> Sent: 20 January 2017 18:28
> To: Paul Durrant ; xen-de...@lists.xenproject.org
> Cc: Ian Jackson ; Daniel De Graaf
>
> Subject: Re: [PATCH v4 6/8] dm_op: convert HVMOP_set_mem_type
>
> On 17/01/17 17:29, Paul Durrant wrote:
> > diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
> > index dd81116..b3c91f8 100644
> > --- a/xen/arch/x86/hvm/dm.c
> > +++ b/xen/arch/x86/hvm/dm.c
> > @@ -159,6 +159,82 @@ static int modified_memory(struct domain *d,
> xen_pfn_t *first_pfn,
> > return rc;
> > }
> >
> > +static bool allow_p2m_type_change(p2m_type_t old, p2m_type_t new)
> > +{
> > +return p2m_is_ram(old) ||
> > + (p2m_is_hole(old) && new == p2m_mmio_dm) ||
> > + (old == p2m_ioreq_server && new == p2m_ram_rw);
> > +}
> > +
> > +static int set_mem_type(struct domain *d, hvmmem_type_t mem_type,
> > +xen_pfn_t *first_pfn, unsigned int *nr)
> > +{
>
> Similarly as patch 5, this would be cleaner taking the whole struct
> xen_dm_op_set_mem_type
Ok, maybe. I guess the reduced stack usage may be of benefit but personally I
prefer breaking out the fields as params. I'll modify patch #5 as well.
>
> > +xen_pfn_t last_pfn = *first_pfn + *nr - 1;
> > +unsigned int iter = 0;
> > +int rc = 0;
> > +
> > +/* Interface types to internal p2m types */
> > +static const p2m_type_t memtype[] = {
> > +[HVMMEM_ram_rw] = p2m_ram_rw,
> > +[HVMMEM_ram_ro] = p2m_ram_ro,
> > +[HVMMEM_mmio_dm] = p2m_mmio_dm,
> > +[HVMMEM_unused] = p2m_invalid,
> > +[HVMMEM_ioreq_server] = p2m_ioreq_server
>
> Please introduce a trailing comma here, as you are moving the code.
Ok.
>
> With this done, Reviewed-by: Andrew Cooper
>
>
Thanks,
Paul
> > +};
> > +
> > +if ( (*first_pfn > last_pfn) ||
> > + (last_pfn > domain_get_maximum_gpfn(d)) )
> > +return -EINVAL;
> > +
> > +if ( mem_type >= ARRAY_SIZE(memtype) ||
> > + unlikely(mem_type == HVMMEM_unused) )
> > +return -EINVAL;
> > +
> > +while ( iter < *nr )
> > +{
> > +unsigned long pfn = *first_pfn + iter;
>
> :( I am not going to request that you change it, but this highlights a
> large set of internal functions which could do with moving to using pfn_t.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 1/8] public / x86: Introduce __HYPERCALL_dm_op...
On 20/01/2017 15:02, Paul Durrant wrote: > >>> +if ( !rc && >>> + !copy_buf_to_guest(bufs, nr_bufs, 0, &op, sizeof(op)) ) >> Do all ops need a copyback? If they do, this is fine. If not, it would >> be better to have a copyback boolean which subops set as necessary. > I can restrict copy-back using a boolean set for sub-ops that have 'out' > params, or when there needs to be a continuation but I didn't really think it > was worth the extra complexity. Extraneous writebacks to PV guests are fairly cheep, but is is certainly not the case for HVM guests. A writeback to HVM requires a least one guest pagetable walk (which itself most likely includes an EPT/NPT walk). From a correctness point of view, it is reasonable for an implementation which expects a hypercall datastructure to be read only, to put said structure in read-only memory. The PKRU feature in particular makes it very easy to set something up, then switch it from RW to RO for use. Such an implementation should have the hypercall fail with a spurious -EFAULT after it has otherwise completed successfully. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 1/8] public / x86: Introduce __HYPERCALL_dm_op...
> -Original Message- > From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of > Andrew Cooper > Sent: 23 January 2017 09:15 > To: Paul Durrant ; xen-de...@lists.xenproject.org > Cc: Ian Jackson ; Jennifer Herbert > ; Daniel De Graaf ; > Wei Liu ; Jan Beulich > Subject: Re: [PATCH v4 1/8] public / x86: Introduce __HYPERCALL_dm_op... > > On 20/01/2017 15:02, Paul Durrant wrote: > > > >>> +if ( !rc && > >>> + !copy_buf_to_guest(bufs, nr_bufs, 0, &op, sizeof(op)) ) > >> Do all ops need a copyback? If they do, this is fine. If not, it would > >> be better to have a copyback boolean which subops set as necessary. > > I can restrict copy-back using a boolean set for sub-ops that have 'out' > params, or when there needs to be a continuation but I didn't really think it > was worth the extra complexity. > > Extraneous writebacks to PV guests are fairly cheep, but is is certainly > not the case for HVM guests. A writeback to HVM requires a least one > guest pagetable walk (which itself most likely includes an EPT/NPT walk). > > From a correctness point of view, it is reasonable for an implementation > which expects a hypercall datastructure to be read only, to put said > structure in read-only memory. The PKRU feature in particular makes it > very easy to set something up, then switch it from RW to RO for use. > Such an implementation should have the hypercall fail with a spurious > -EFAULT after it has otherwise completed successfully. Ok, I'll re-work the code yet again. Paul > > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] docs: clarify xl mem-max semantics
The information given in the xl man page for the mem-max command is
rather brief. Expand it in order to let the reader understand what it
is really doing.
As the related libxl function libxl_domain_setmaxmem() isn't much
clearer add a comment to it explaining the desired semantics.
Signed-off-by: Juergen Gross
---
V2: rewording as suggested by Jim Fehlig and Ian Jackson
---
docs/man/xl.pod.1.in | 10 ++
tools/libxl/libxl.c | 6 ++
2 files changed, 16 insertions(+)
diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in
index 09c1faa..7caed08 100644
--- a/docs/man/xl.pod.1.in
+++ b/docs/man/xl.pod.1.in
@@ -401,6 +401,16 @@ for bytes.
The mem-max value may not correspond to the actual memory used in the
domain, as it may balloon down its memory to give more back to the OS.
+The value given just sets the memory amount the domain is allowed to allocate
+in the hypervisor. It can't be set lower than the current reservation, but
+it is allowed to be higher than the configured maximum memory size of the
+domain (B parameter in the domain's configuration). Using B
+to set the maximum memory above the initial B value will not allow the
+additional memory to be used via B. The initial B value is
+still used as an upper limit for B.
+
+The domain is not receiving any signal regarding the changed memory limit.
+
=item B I I
Set the domain's used memory using the balloon driver; append 't' for
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 0622311..ed59510 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4018,6 +4018,12 @@ out:
/**/
+/*
+ * Set the maximum memory size of the domain in the hypervisor. There is no
+ * change of the current memory size involved. The allowed memory size can
+ * even be above the configured maxmem size of the domain, but the related
+ * Xenstore entry memory/static-max isn't modified!
+ */
int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint64_t max_memkb)
{
GC_INIT(ctx);
--
2.10.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3/6] hw: Default -drive to if=none instead of ide when ide cannot work
Block backends defined with -drive if=ide are meant to be picked up by
machine initialization code: a suitable frontend gets created and
wired up automatically.
if=ide drives not picked up that way can still be used with -device as
if they had if=none, but that's unclean and best avoided. Unused ones
produce an "Orphaned drive without device" warning.
-drive parameter "if" is optional, and the default depends on the
machine type. If a machine type doesn't specify a default, the
default is "ide".
Many machine types implicitly default to if=ide that way, even though
they don't actually have an IDE controller. This makes no sense.
Change the implicit default to if=none. Affected machines:
* all targets: none
* aarch64/arm: akita ast2500 canon cheetah collie connex imx25
integratorcp kzm lm3s6965evb lm3s811evb mainstone musicpal n800 n810
netduino2 nuri palmetto realview romulus sabrelite smdkc210 sx1 sx1
verdex z2
* cris: axis-dev88
* i386/x86_64: xenpv
* lm32: lm32-evr lm32-uclinux milkymist
* m68k: an5206 dummy mcf5208evb
* microblaze/microblazeel: petalogix-ml605 petalogix-s3adsp1800
* mips/mips64/mips64el/mipsel: mipssim
* moxie: moxiesim
* or32: or32-sim
* ppc/ppc64/ppcemb: bamboo ref405ep taihu virtex-ml507
* ppc/ppc64: mpc8544ds ppce500
* sh4/sh4eb: shix
* sparc: leon3_generic
* sparc64: niagara
* tricore: tricore_testboard
* unicore32: puv3
* xtensa/xtensaeb: kc705 lx200 lx60 ml605 sim
None of these machines have an IDE controller, let alone code to
honor if=ide.
Cc: Peter Maydell
Cc: qemu-...@nongnu.org
Cc: Edgar E. Iglesias
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: xen-de...@lists.xensource.com
Cc: Michael Walle
Cc: Laurent Vivier
Cc: Anthony Green
Cc: Jia Liu
Cc: Alexander Graf
Cc: qemu-...@nongnu.org
Cc: Magnus Damm
Cc: Fabien Chouteau
Cc: Mark Cave-Ayland
Cc: Artyom Tarasenko
Cc: Bastian Koppelmann
Cc: Guan Xuetao
Cc: Max Filippov
Signed-off-by: Markus Armbruster
---
include/sysemu/blockdev.h | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/include/sysemu/blockdev.h b/include/sysemu/blockdev.h
index 16432f3..351a039 100644
--- a/include/sysemu/blockdev.h
+++ b/include/sysemu/blockdev.h
@@ -19,12 +19,11 @@ void blockdev_auto_del(BlockBackend *blk);
typedef enum {
IF_DEFAULT = -1,/* for use with drive_add() only */
/*
- * IF_IDE must be zero, because we want MachineClass member
- * block_default_type to default-initialize to IF_IDE
+ * IF_NONE must be zero, because we want MachineClass member
+ * block_default_type to default-initialize to IF_NONE
*/
-IF_IDE = 0,
-IF_NONE,
-IF_SCSI, IF_FLOPPY, IF_PFLASH, IF_MTD, IF_SD, IF_VIRTIO, IF_XEN,
+IF_NONE = 0,
+IF_IDE, IF_SCSI, IF_FLOPPY, IF_PFLASH, IF_MTD, IF_SD, IF_VIRTIO, IF_XEN,
IF_COUNT
} BlockInterfaceType;
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 104599: tolerable FAIL
flight 104599 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/104599/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104572 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104572 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 104572 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104572 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104572 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 104572 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 104572 test-amd64-amd64-xl-rtds 9 debian-install fail like 104572 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104572 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: xen e225a1c7c06037e4f938efa43d4407e7abb088c1 baseline version: xen e225a1c7c06037e4f938efa43d4407e7abb088c1 Last test of basis 104599 2017-01-23 01:58:00 Z0 days Testing same since0 1970-01-01 00:00:00 Z 17189 days0 attempts jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumprun pass build-i386
[Xen-devel] [PATCH v6 1/8] public / x86: Introduce __HYPERCALL_dm_op...
...as a set of hypercalls to be used by a device model.
As stated in the new docs/designs/dm_op.markdown:
"The aim of DMOP is to prevent a compromised device model from
compromising domains other then the one it is associated with. (And is
therefore likely already compromised)."
See that file for further information.
This patch simply adds the boilerplate for the hypercall.
Signed-off-by: Paul Durrant
Suggested-by: Ian Jackson
Suggested-by: Jennifer Herbert
Acked-by: Daniel De Graaf
Acked-by: Wei Liu
---
Cc: Ian Jackson
Cc: Jennifer Herbert
Cc: Jan Beulich
Cc: Andrew Cooper
v6:
- Add bool to control copy-back of op structure as requested by Andy
v5:
- Copy functions now use exact sizes.
- Addressed other comments from Jan, Wei and Andrew. However I have
left the code that unconditionally copies back the op structure as
I think it will needlessly complicate the code to make this selective.
v4:
- Change XEN_GUEST_HANDLE_64 to XEN_GUEST_HANDLE in struct xen_dm_op_buf
and add the necessary compat code. Drop Jan's R-b since the patch has
been fundamentally modified.
v3:
- Re-written large portions of dmop.markdown to remove references to
previous proposals and make it a standalone design doc.
v2:
- Addressed several comments from Jan.
- Removed modification of __XEN_LATEST_INTERFACE_VERSION__ as it is not
needed in this patch.
---
docs/designs/dmop.markdown| 165 ++
tools/flask/policy/modules/xen.if | 2 +-
tools/libxc/include/xenctrl.h | 1 +
tools/libxc/xc_private.c | 70
tools/libxc/xc_private.h | 2 +
xen/arch/x86/hvm/Makefile | 1 +
xen/arch/x86/hvm/dm.c | 142
xen/arch/x86/hvm/hvm.c| 1 +
xen/arch/x86/hypercall.c | 2 +
xen/include/Makefile | 1 +
xen/include/public/hvm/dm_op.h| 69
xen/include/public/xen.h | 1 +
xen/include/xen/hypercall.h | 15
xen/include/xlat.lst | 1 +
xen/include/xsm/dummy.h | 6 ++
xen/include/xsm/xsm.h | 6 ++
xen/xsm/flask/hooks.c | 7 ++
17 files changed, 491 insertions(+), 1 deletion(-)
create mode 100644 docs/designs/dmop.markdown
create mode 100644 xen/arch/x86/hvm/dm.c
create mode 100644 xen/include/public/hvm/dm_op.h
diff --git a/docs/designs/dmop.markdown b/docs/designs/dmop.markdown
new file mode 100644
index 000..3c3f3a6
--- /dev/null
+++ b/docs/designs/dmop.markdown
@@ -0,0 +1,165 @@
+DMOP
+
+
+Introduction
+
+
+The aim of DMOP is to prevent a compromised device model from compromising
+domains other than the one it is providing emulation for (which is therefore
+likely already compromised).
+
+The problem occurs when you a device model issues an hypercall that
+includes references to user memory other than the operation structure
+itself, such as with Track dirty VRAM (as used in VGA emulation).
+Is this case, the address of this other user memory needs to be vetted,
+to ensure it is not within restricted address ranges, such as kernel
+memory. The real problem comes down to how you would vet this address -
+the idea place to do this is within the privcmd driver, without privcmd
+having to have specific knowledge of the hypercall's semantics.
+
+The Design
+--
+
+The privcmd driver implements a new restriction ioctl, which takes a domid
+parameter. After that restriction ioctl is issued, all unaudited operations
+on the privcmd driver will cease to function, including regular hypercalls.
+DMOP hypercalls will continue to function as they can be audited.
+
+A DMOP hypercall consists of a domid (which is audited to verify that it
+matches any restriction in place) and an array of buffers and lengths,
+with the first one containing the specific DMOP parameters. These can
+then reference further buffers from within in the array. Since the only
+user buffers passed are that found with that array, they can all can be
+audited by privcmd.
+
+The following code illustrates this idea:
+
+struct xen_dm_op {
+uint32_t op;
+};
+
+struct xen_dm_op_buf {
+XEN_GUEST_HANDLE(void) h;
+unsigned long size;
+};
+typedef struct xen_dm_op_buf xen_dm_op_buf_t;
+
+enum neg_errnoval
+HYPERVISOR_dm_op(domid_t domid,
+ xen_dm_op_buf_t bufs[],
+ unsigned int nr_bufs)
+
+@domid is the domain the hypercall operates on.
+@bufs points to an array of buffers where @bufs[0] contains a struct
+dm_op, describing the specific device model operation and its parameters.
+@bufs[1..] may be referenced in the parameters for the purposes of
+passing extra information to or from the domain.
+@nr_bufs is the number of buffers in the @bufs array.
+
+It is forbidden for the above struct (xen_dm_op) to contain any guest
+handles. If they are needed, they should instead be in
+HYPERVISOR_dm_op->bufs.
+
+Validation by privcmd driv
[Xen-devel] [PATCH v6 4/8] dm_op: convert HVMOP_set_pci_intx_level, HVMOP_set_isa_irq_level, and...
... HVMOP_set_pci_link_route
These HVMOPs were exposed to guests so their definitions need to be
preserved for compatibility. This patch therefore updates
__XEN_LATEST_INTERFACE_VERSION__ to 0x00040900 and makes the HVMOP
defintions conditional on __XEN_INTERFACE_VERSION__ less than that value.
NOTE: This patch also widens the 'domain' parameter of
xc_hvm_set_pci_intx_level() from a uint8_t to a uint16_t.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
Acked-by: Wei Liu
Acked-by: Daniel De Graaf
Reviewed-by: Andrew Cooper
---
Cc: Ian Jackson
v3:
- Remove unnecessary padding.
v2:
- Interface version modification moved to this patch, where it is needed.
- Addressed several comments from Jan.
---
tools/flask/policy/modules/xen.if | 8 +--
tools/libxc/include/xenctrl.h | 2 +-
tools/libxc/xc_misc.c | 83 --
xen/arch/x86/hvm/dm.c | 72 +++
xen/arch/x86/hvm/hvm.c | 136
xen/arch/x86/hvm/irq.c | 7 +-
xen/include/public/hvm/dm_op.h | 42 +++
xen/include/public/hvm/hvm_op.h | 4 ++
xen/include/public/xen-compat.h | 2 +-
xen/include/xen/hvm/irq.h | 2 +-
xen/include/xsm/dummy.h | 18 -
xen/include/xsm/xsm.h | 18 -
xen/xsm/dummy.c | 3 -
xen/xsm/flask/hooks.c | 15
xen/xsm/flask/policy/access_vectors | 6 --
15 files changed, 158 insertions(+), 260 deletions(-)
diff --git a/tools/flask/policy/modules/xen.if
b/tools/flask/policy/modules/xen.if
index 45e5b5f..092a6c5 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -57,8 +57,8 @@ define(`create_domain_common', `
allow $1 $2:shadow enable;
allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage
mmuext_op updatemp };
allow $1 $2:grant setup;
- allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
- setparam pcilevel nested altp2mhvm altp2mhvm_op
send_irq };
+ allow $1 $2:hvm { cacheattr getparam hvmctl sethvmc
+ setparam nested altp2mhvm altp2mhvm_op send_irq };
')
# create_domain(priv, target)
@@ -93,7 +93,7 @@ define(`manage_domain', `
# (inbound migration is the same as domain creation)
define(`migrate_domain_out', `
allow $1 domxen_t:mmu map_read;
- allow $1 $2:hvm { gethvmc getparam irqlevel };
+ allow $1 $2:hvm { gethvmc getparam };
allow $1 $2:mmu { stat pageinfo map_read };
allow $1 $2:domain { getaddrsize getvcpucontext pause destroy };
allow $1 $2:domain2 gettsc;
@@ -151,7 +151,7 @@ define(`device_model', `
allow $1 $2_target:domain { getdomaininfo shutdown };
allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack
};
- allow $1 $2_target:hvm { getparam setparam hvmctl irqlevel pciroute
pcilevel cacheattr send_irq dm };
+ allow $1 $2_target:hvm { getparam setparam hvmctl cacheattr send_irq dm
};
')
# make_device_model(priv, dm_dom, hvm_dom)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c7ee412..f819bf2 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1594,7 +1594,7 @@ int xc_physdev_unmap_pirq(xc_interface *xch,
int xc_hvm_set_pci_intx_level(
xc_interface *xch, domid_t dom,
-uint8_t domain, uint8_t bus, uint8_t device, uint8_t intx,
+uint16_t domain, uint8_t bus, uint8_t device, uint8_t intx,
unsigned int level);
int xc_hvm_set_isa_irq_level(
xc_interface *xch, domid_t dom,
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 4c41d41..ddea2bb 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -470,33 +470,24 @@ int xc_getcpuinfo(xc_interface *xch, int max_cpus,
int xc_hvm_set_pci_intx_level(
xc_interface *xch, domid_t dom,
-uint8_t domain, uint8_t bus, uint8_t device, uint8_t intx,
+uint16_t domain, uint8_t bus, uint8_t device, uint8_t intx,
unsigned int level)
{
-DECLARE_HYPERCALL_BUFFER(struct xen_hvm_set_pci_intx_level, arg);
-int rc;
-
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-{
-PERROR("Could not allocate memory for xc_hvm_set_pci_intx_level
hypercall");
-return -1;
-}
+struct xen_dm_op op;
+struct xen_dm_op_set_pci_intx_level *data;
-arg->domid = dom;
-arg->domain = domain;
-arg->bus= bus;
-arg->device = device;
-arg->intx = intx;
-arg->level = level;
+memset(&op, 0, sizeof(op));
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
- HVMOP_set_pci_intx_level,
- HYPERCALL_BUFFER_AS_ARG(arg));
+op.op = XEN_DMOP_set_pci_intx_level;
+data = &op.u.set_pci_intx_level;
-xc_hypercall_buffe
[Xen-devel] [PATCH v6 6/8] dm_op: convert HVMOP_set_mem_type
This patch removes the need for handling HVMOP restarts, so that
infrastructure is removed.
NOTE: This patch also modifies the type of the 'nr' argument of
xc_hvm_set_mem_type() from uint64_t to uint32_t. In practice the
value passed was always truncated to 32 bits.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
Acked-by: Wei Liu
Acked-by: Daniel De Graaf
Reviewed-by: Andrew Cooper
---
Cc: Ian Jackson
v6:
- Pass by reference as requested by Andy.
- Modify const_op appropriately.
v4:
- Added initializers as requested by Jan.
v3:
- Addressed more comments from Jan.
v2:
- Addressed several comments from Jan.
---
tools/libxc/include/xenctrl.h | 2 +-
tools/libxc/xc_misc.c | 29 +++-
xen/arch/x86/hvm/dm.c | 91
xen/arch/x86/hvm/hvm.c | 136 +---
xen/include/public/hvm/dm_op.h | 22 ++
xen/include/public/hvm/hvm_op.h | 20 --
xen/xsm/flask/policy/access_vectors | 2 +-
7 files changed, 126 insertions(+), 176 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index a5c234f..13431bb 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1634,7 +1634,7 @@ int xc_hvm_modified_memory(
* Allowed types are HVMMEM_ram_rw, HVMMEM_ram_ro, HVMMEM_mmio_dm
*/
int xc_hvm_set_mem_type(
-xc_interface *xch, domid_t dom, hvmmem_type_t memtype, uint64_t first_pfn,
uint64_t nr);
+xc_interface *xch, domid_t dom, hvmmem_type_t memtype, uint64_t first_pfn,
uint32_t nr);
/*
* Injects a hardware/software CPU trap, to take effect the next time the HVM
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 597df99..5b06d6b 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -590,30 +590,21 @@ int xc_hvm_modified_memory(
}
int xc_hvm_set_mem_type(
-xc_interface *xch, domid_t dom, hvmmem_type_t mem_type, uint64_t
first_pfn, uint64_t nr)
+xc_interface *xch, domid_t dom, hvmmem_type_t mem_type, uint64_t
first_pfn, uint32_t nr)
{
-DECLARE_HYPERCALL_BUFFER(struct xen_hvm_set_mem_type, arg);
-int rc;
-
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-{
-PERROR("Could not allocate memory for xc_hvm_set_mem_type hypercall");
-return -1;
-}
+struct xen_dm_op op;
+struct xen_dm_op_set_mem_type *data;
-arg->domid= dom;
-arg->hvmmem_type = mem_type;
-arg->first_pfn= first_pfn;
-arg->nr = nr;
+memset(&op, 0, sizeof(op));
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
- HVMOP_set_mem_type,
- HYPERCALL_BUFFER_AS_ARG(arg));
+op.op = XEN_DMOP_set_mem_type;
+data = &op.u.set_mem_type;
-xc_hypercall_buffer_free(xch, arg);
+data->mem_type = mem_type;
+data->first_pfn = first_pfn;
+data->nr = nr;
-return rc;
+return do_dm_op(xch, dom, 1, &op, sizeof(op));
}
int xc_hvm_inject_trap(
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index e28bda4..cc68ba9 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -161,6 +161,82 @@ static int modified_memory(struct domain *d,
return rc;
}
+static bool allow_p2m_type_change(p2m_type_t old, p2m_type_t new)
+{
+return p2m_is_ram(old) ||
+ (p2m_is_hole(old) && new == p2m_mmio_dm) ||
+ (old == p2m_ioreq_server && new == p2m_ram_rw);
+}
+
+static int set_mem_type(struct domain *d,
+struct xen_dm_op_set_mem_type *data)
+{
+xen_pfn_t last_pfn = data->first_pfn + data->nr - 1;
+unsigned int iter = 0;
+int rc = 0;
+
+/* Interface types to internal p2m types */
+static const p2m_type_t memtype[] = {
+[HVMMEM_ram_rw] = p2m_ram_rw,
+[HVMMEM_ram_ro] = p2m_ram_ro,
+[HVMMEM_mmio_dm] = p2m_mmio_dm,
+[HVMMEM_unused] = p2m_invalid,
+[HVMMEM_ioreq_server] = p2m_ioreq_server,
+};
+
+if ( (data->first_pfn > last_pfn) ||
+ (last_pfn > domain_get_maximum_gpfn(d)) )
+return -EINVAL;
+
+if ( data->mem_type >= ARRAY_SIZE(memtype) ||
+ unlikely(data->mem_type == HVMMEM_unused) )
+return -EINVAL;
+
+while ( iter < data->nr )
+{
+unsigned long pfn = data->first_pfn + iter;
+p2m_type_t t;
+
+get_gfn_unshare(d, pfn, &t);
+if ( p2m_is_paging(t) )
+{
+put_gfn(d, pfn);
+p2m_mem_paging_populate(d, pfn);
+return -EAGAIN;
+}
+
+if ( p2m_is_shared(t) )
+rc = -EAGAIN;
+else if ( !allow_p2m_type_change(t, memtype[data->mem_type]) )
+rc = -EINVAL;
+else
+rc = p2m_change_type_one(d, pfn, t, memtype[data->mem_type]);
+
+put_gfn(d, pfn);
+
+if ( rc )
+break;
+
+iter++;
+
+/*
+
[Xen-devel] [PATCH v6 7/8] dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi
NOTE: This patch also modifies the types of the 'vector', 'type' and
'insn_len' arguments of xc_hvm_inject_trap() from uint32_t to
uint8_t. In practice the values passed were always truncated to
8 bits.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
Acked-by: Wei Liu
Acked-by: Daniel De Graaf
Reviewed-by: Andrew Cooper
---
Cc: Ian Jackson
v6:
- s/trap/event as requested by Andy (and adjust struct hvm_vcpu
accordingly).
v3:
- Fixed prefixing and padding.
v2:
- Addressed several comments from Jan.
---
tools/flask/policy/modules/xen.if | 2 +-
tools/libxc/include/xenctrl.h | 4 +-
tools/libxc/xc_misc.c | 64 ++--
xen/arch/x86/hvm/dm.c | 45
xen/arch/x86/hvm/hvm.c | 84 ++---
xen/include/asm-x86/hvm/vcpu.h | 2 +-
xen/include/public/hvm/dm_op.h | 48 +
xen/include/public/hvm/hvm_op.h | 45
xen/include/xsm/dummy.h | 6 ---
xen/include/xsm/xsm.h | 6 ---
xen/xsm/dummy.c | 1 -
xen/xsm/flask/hooks.c | 6 ---
xen/xsm/flask/policy/access_vectors | 5 +--
13 files changed, 125 insertions(+), 193 deletions(-)
diff --git a/tools/flask/policy/modules/xen.if
b/tools/flask/policy/modules/xen.if
index 092a6c5..45e5cea 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -151,7 +151,7 @@ define(`device_model', `
allow $1 $2_target:domain { getdomaininfo shutdown };
allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack
};
- allow $1 $2_target:hvm { getparam setparam hvmctl cacheattr send_irq dm
};
+ allow $1 $2_target:hvm { getparam setparam hvmctl cacheattr dm };
')
# make_device_model(priv, dm_dom, hvm_dom)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 13431bb..539cc69 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1641,8 +1641,8 @@ int xc_hvm_set_mem_type(
* resumes.
*/
int xc_hvm_inject_trap(
-xc_interface *xch, domid_t dom, int vcpu, uint32_t vector,
-uint32_t type, uint32_t error_code, uint32_t insn_len,
+xc_interface *xch, domid_t dom, int vcpu, uint8_t vector,
+uint8_t type, uint32_t error_code, uint8_t insn_len,
uint64_t cr2);
/*
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 5b06d6b..98ab826 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -527,29 +527,20 @@ int xc_hvm_set_pci_link_route(
}
int xc_hvm_inject_msi(
-xc_interface *xch, domid_t dom, uint64_t addr, uint32_t data)
+xc_interface *xch, domid_t dom, uint64_t msi_addr, uint32_t msi_data)
{
-DECLARE_HYPERCALL_BUFFER(struct xen_hvm_inject_msi, arg);
-int rc;
-
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-{
-PERROR("Could not allocate memory for xc_hvm_inject_msi hypercall");
-return -1;
-}
+struct xen_dm_op op;
+struct xen_dm_op_inject_msi *data;
-arg->domid = dom;
-arg->addr = addr;
-arg->data = data;
+memset(&op, 0, sizeof(op));
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
- HVMOP_inject_msi,
- HYPERCALL_BUFFER_AS_ARG(arg));
+op.op = XEN_DMOP_inject_msi;
+data = &op.u.inject_msi;
-xc_hypercall_buffer_free(xch, arg);
+data->addr = msi_addr;
+data->data = msi_data;
-return rc;
+return do_dm_op(xch, dom, 1, &op, sizeof(op));
}
int xc_hvm_track_dirty_vram(
@@ -608,35 +599,26 @@ int xc_hvm_set_mem_type(
}
int xc_hvm_inject_trap(
-xc_interface *xch, domid_t dom, int vcpu, uint32_t vector,
-uint32_t type, uint32_t error_code, uint32_t insn_len,
+xc_interface *xch, domid_t dom, int vcpu, uint8_t vector,
+uint8_t type, uint32_t error_code, uint8_t insn_len,
uint64_t cr2)
{
-DECLARE_HYPERCALL_BUFFER(struct xen_hvm_inject_trap, arg);
-int rc;
-
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-{
-PERROR("Could not allocate memory for xc_hvm_inject_trap hypercall");
-return -1;
-}
+struct xen_dm_op op;
+struct xen_dm_op_inject_trap *data;
-arg->domid = dom;
-arg->vcpuid = vcpu;
-arg->vector = vector;
-arg->type= type;
-arg->error_code = error_code;
-arg->insn_len= insn_len;
-arg->cr2 = cr2;
+memset(&op, 0, sizeof(op));
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
- HVMOP_inject_trap,
- HYPERCALL_BUFFER_AS_ARG(arg));
+op.op = XEN_DMOP_inject_trap;
+data = &op.u.inject_trap;
-xc_hypercall_buffer_free(xch, arg);
+data->vcpuid = vcpu;
+data->vector = vector;
+data->type = type;
+data->error_code = error_code;
[Xen-devel] [PATCH v6 5/8] dm_op: convert HVMOP_modified_memory
This patch introduces code to handle DMOP continuations.
NOTE: This patch also modifies the type of the 'nr' argument of
xc_hvm_modified_memory() from uint64_t to uint32_t. In practice the
value passed was always truncated to 32 bits.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
Acked-by: Wei Liu
Acked-by: Daniel De Graaf
Reviewed-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
Cc: Ian Jackson
v6:
- Pass by pointer as requested by Andy.
- Modify const_op appropriately.
v4:
- Continuation code in dm.c modified as knock-on from compat code. Not
adding Jan's R-b since patch has fundamentally changed.
v3:
- Addressed more comments from Jan.
v2:
- Addressed several comments from Jan, including...
- Added explanatory note on continuation handling
---
tools/libxc/include/xenctrl.h | 2 +-
tools/libxc/xc_misc.c | 27 ---
xen/arch/x86/hvm/dm.c | 89 +++--
xen/arch/x86/hvm/hvm.c | 60 -
xen/include/public/hvm/dm_op.h | 19
xen/include/public/hvm/hvm_op.h | 13 --
xen/xsm/flask/policy/access_vectors | 2 +-
7 files changed, 116 insertions(+), 96 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index f819bf2..a5c234f 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1627,7 +1627,7 @@ int xc_hvm_track_dirty_vram(
* Notify that some pages got modified by the Device Model
*/
int xc_hvm_modified_memory(
-xc_interface *xch, domid_t dom, uint64_t first_pfn, uint64_t nr);
+xc_interface *xch, domid_t dom, uint64_t first_pfn, uint32_t nr);
/*
* Set a range of memory to a specific type.
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index ddea2bb..597df99 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -573,29 +573,20 @@ int xc_hvm_track_dirty_vram(
}
int xc_hvm_modified_memory(
-xc_interface *xch, domid_t dom, uint64_t first_pfn, uint64_t nr)
+xc_interface *xch, domid_t dom, uint64_t first_pfn, uint32_t nr)
{
-DECLARE_HYPERCALL_BUFFER(struct xen_hvm_modified_memory, arg);
-int rc;
-
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-{
-PERROR("Could not allocate memory for xc_hvm_modified_memory
hypercall");
-return -1;
-}
+struct xen_dm_op op;
+struct xen_dm_op_modified_memory *data;
-arg->domid = dom;
-arg->first_pfn = first_pfn;
-arg->nr= nr;
+memset(&op, 0, sizeof(op));
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
- HVMOP_modified_memory,
- HYPERCALL_BUFFER_AS_ARG(arg));
+op.op = XEN_DMOP_modified_memory;
+data = &op.u.modified_memory;
-xc_hypercall_buffer_free(xch, arg);
+data->first_pfn = first_pfn;
+data->nr = nr;
-return rc;
+return do_dm_op(xch, dom, 1, &op, sizeof(op));
}
int xc_hvm_set_mem_type(
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index d847892..e28bda4 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -14,6 +14,7 @@
* this program; If not, see
[Xen-devel] [PATCH v6 3/8] dm_op: convert HVMOP_track_dirty_vram
The handle type passed to the underlying shadow and hap functions is
changed for compatibility with the new hypercall buffer.
NOTE: This patch also modifies the type of the 'nr' parameter of
xc_hvm_track_dirty_vram() from uint64_t to uint32_t. In practice
the value passed was always truncated to 32 bits.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
Acked-by: Wei Liu
Acked-by: George Dunlap
Acked-by: Tim Deegan
Acked-by: Daniel De Graaf
Reviewed-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
Cc: Ian Jackson
v4:
- Knock-on changes from compat code in dm.c. Not adding Jan's R-b since
the patch has fundamentally changed.
v3:
- Check d->max_vcpus rather than d->vcpu, as requested by Jan.
- The handle type changes (from uint8 to void) are still necessary, hence
omitting Jan's R-b until this is confirmed to be acceptable.
v2:
- Addressed several comments from Jan.
---
tools/flask/policy/modules/xen.if | 4 ++--
tools/libxc/include/xenctrl.h | 2 +-
tools/libxc/xc_misc.c | 32 +
xen/arch/x86/hvm/dm.c | 40 +++-
xen/arch/x86/hvm/hvm.c | 41 -
xen/arch/x86/mm/hap/hap.c | 2 +-
xen/arch/x86/mm/shadow/common.c | 2 +-
xen/include/asm-x86/hap.h | 2 +-
xen/include/asm-x86/shadow.h| 2 +-
xen/include/public/hvm/dm_op.h | 18
xen/include/public/hvm/hvm_op.h | 16 ---
xen/xsm/flask/hooks.c | 3 ---
xen/xsm/flask/policy/access_vectors | 2 --
13 files changed, 74 insertions(+), 92 deletions(-)
diff --git a/tools/flask/policy/modules/xen.if
b/tools/flask/policy/modules/xen.if
index f9254c2..45e5b5f 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -58,7 +58,7 @@ define(`create_domain_common', `
allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage
mmuext_op updatemp };
allow $1 $2:grant setup;
allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
- setparam pcilevel trackdirtyvram nested altp2mhvm
altp2mhvm_op send_irq };
+ setparam pcilevel nested altp2mhvm altp2mhvm_op
send_irq };
')
# create_domain(priv, target)
@@ -151,7 +151,7 @@ define(`device_model', `
allow $1 $2_target:domain { getdomaininfo shutdown };
allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack
};
- allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl
irqlevel pciroute pcilevel cacheattr send_irq dm };
+ allow $1 $2_target:hvm { getparam setparam hvmctl irqlevel pciroute
pcilevel cacheattr send_irq dm };
')
# make_device_model(priv, dm_dom, hvm_dom)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 2ba46d7..c7ee412 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1620,7 +1620,7 @@ int xc_hvm_inject_msi(
*/
int xc_hvm_track_dirty_vram(
xc_interface *xch, domid_t dom,
-uint64_t first_pfn, uint64_t nr,
+uint64_t first_pfn, uint32_t nr,
unsigned long *bitmap);
/*
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 06e90de..4c41d41 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -581,34 +581,22 @@ int xc_hvm_inject_msi(
int xc_hvm_track_dirty_vram(
xc_interface *xch, domid_t dom,
-uint64_t first_pfn, uint64_t nr,
+uint64_t first_pfn, uint32_t nr,
unsigned long *dirty_bitmap)
{
-DECLARE_HYPERCALL_BOUNCE(dirty_bitmap, (nr+7) / 8,
XC_HYPERCALL_BUFFER_BOUNCE_OUT);
-DECLARE_HYPERCALL_BUFFER(struct xen_hvm_track_dirty_vram, arg);
-int rc;
+struct xen_dm_op op;
+struct xen_dm_op_track_dirty_vram *data;
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL || xc_hypercall_bounce_pre(xch, dirty_bitmap) )
-{
-PERROR("Could not bounce memory for xc_hvm_track_dirty_vram
hypercall");
-rc = -1;
-goto out;
-}
+memset(&op, 0, sizeof(op));
-arg->domid = dom;
-arg->first_pfn = first_pfn;
-arg->nr= nr;
-set_xen_guest_handle(arg->dirty_bitmap, dirty_bitmap);
+op.op = XEN_DMOP_track_dirty_vram;
+data = &op.u.track_dirty_vram;
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
- HVMOP_track_dirty_vram,
- HYPERCALL_BUFFER_AS_ARG(arg));
+data->first_pfn = first_pfn;
+data->nr = nr;
-out:
-xc_hypercall_buffer_free(xch, arg);
-xc_hypercall_bounce_post(xch, dirty_bitmap);
-return rc;
+return do_dm_op(xch, dom, 2, &op, sizeof(op),
+dirty_bitmap, (nr + 7) / 8);
}
int xc_hvm_modified_memory(
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index 72cb33a..b0908f4 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -18,7 +18,9 @@
#i
[Xen-devel] [PATCH v6 2/8] dm_op: convert HVMOP_*ioreq_server*
The definitions of HVM_IOREQSRV_BUFIOREQ_* have to persist as they are
already in use by callers of the libxc interface.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
Acked-by: Wei Liu
Acked-by: Daniel De Graaf
Reviewed-by: Andrew Cooper
--
Cc: Ian Jackson
v6:
- Modify const_op as appropriate.
v4:
- #define uint64_aligned_t if necessary to handle compat code generation.
v3:
- Fix pad check.
v2:
- Addressed several comments from Jan.
---
tools/libxc/xc_domain.c | 212 -
xen/arch/x86/hvm/dm.c| 93 +
xen/arch/x86/hvm/hvm.c | 219 ---
xen/arch/x86/hvm/ioreq.c | 36 +++
xen/include/asm-x86/hvm/domain.h | 3 +-
xen/include/public/hvm/dm_op.h | 157
xen/include/public/hvm/hvm_op.h | 132 +--
xen/include/xsm/dummy.h | 6 --
xen/include/xsm/xsm.h| 6 --
xen/xsm/dummy.c | 1 -
xen/xsm/flask/hooks.c| 6 --
11 files changed, 364 insertions(+), 507 deletions(-)
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 296b852..419a897 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1417,24 +1417,24 @@ int xc_hvm_create_ioreq_server(xc_interface *xch,
int handle_bufioreq,
ioservid_t *id)
{
-DECLARE_HYPERCALL_BUFFER(xen_hvm_create_ioreq_server_t, arg);
+struct xen_dm_op op;
+struct xen_dm_op_create_ioreq_server *data;
int rc;
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-return -1;
+memset(&op, 0, sizeof(op));
-arg->domid = domid;
-arg->handle_bufioreq = handle_bufioreq;
+op.op = XEN_DMOP_create_ioreq_server;
+data = &op.u.create_ioreq_server;
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
- HVMOP_create_ioreq_server,
- HYPERCALL_BUFFER_AS_ARG(arg));
+data->handle_bufioreq = handle_bufioreq;
+
+rc = do_dm_op(xch, domid, 1, &op, sizeof(op));
+if ( rc )
+return rc;
-*id = arg->id;
+*id = data->id;
-xc_hypercall_buffer_free(xch, arg);
-return rc;
+return 0;
}
int xc_hvm_get_ioreq_server_info(xc_interface *xch,
@@ -1444,84 +1444,71 @@ int xc_hvm_get_ioreq_server_info(xc_interface *xch,
xen_pfn_t *bufioreq_pfn,
evtchn_port_t *bufioreq_port)
{
-DECLARE_HYPERCALL_BUFFER(xen_hvm_get_ioreq_server_info_t, arg);
+struct xen_dm_op op;
+struct xen_dm_op_get_ioreq_server_info *data;
int rc;
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-return -1;
+memset(&op, 0, sizeof(op));
-arg->domid = domid;
-arg->id = id;
+op.op = XEN_DMOP_get_ioreq_server_info;
+data = &op.u.get_ioreq_server_info;
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
- HVMOP_get_ioreq_server_info,
- HYPERCALL_BUFFER_AS_ARG(arg));
-if ( rc != 0 )
-goto done;
+data->id = id;
+
+rc = do_dm_op(xch, domid, 1, &op, sizeof(op));
+if ( rc )
+return rc;
if ( ioreq_pfn )
-*ioreq_pfn = arg->ioreq_pfn;
+*ioreq_pfn = data->ioreq_pfn;
if ( bufioreq_pfn )
-*bufioreq_pfn = arg->bufioreq_pfn;
+*bufioreq_pfn = data->bufioreq_pfn;
if ( bufioreq_port )
-*bufioreq_port = arg->bufioreq_port;
+*bufioreq_port = data->bufioreq_port;
-done:
-xc_hypercall_buffer_free(xch, arg);
-return rc;
+return 0;
}
int xc_hvm_map_io_range_to_ioreq_server(xc_interface *xch, domid_t domid,
ioservid_t id, int is_mmio,
uint64_t start, uint64_t end)
{
-DECLARE_HYPERCALL_BUFFER(xen_hvm_io_range_t, arg);
-int rc;
+struct xen_dm_op op;
+struct xen_dm_op_ioreq_server_range *data;
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-return -1;
+memset(&op, 0, sizeof(op));
-arg->domid = domid;
-arg->id = id;
-arg->type = is_mmio ? HVMOP_IO_RANGE_MEMORY : HVMOP_IO_RANGE_PORT;
-arg->start = start;
-arg->end = end;
+op.op = XEN_DMOP_map_io_range_to_ioreq_server;
+data = &op.u.map_io_range_to_ioreq_server;
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
- HVMOP_map_io_range_to_ioreq_server,
- HYPERCALL_BUFFER_AS_ARG(arg));
+data->id = id;
+data->type = is_mmio ? XEN_DMOP_IO_RANGE_MEMORY : XEN_DMOP_IO_RANGE_PORT;
+data->start = start;
+data->end = end;
-xc_hypercall_buffer_free(xch, arg);
-return rc;
+return do_dm_op(xch, domid, 1, &op, sizeof(op));
}
int xc_hvm_unmap_io_range_from_ioreq_server(xc_interfac
[Xen-devel] [PATCH v6 8/8] x86/hvm: serialize trap injecting producer and consumer
Since injection works on a remote vCPU, and since there's no
enforcement of the subject vCPU being paused, there's a potential race
between the producing and consuming sides. Fix this by leveraging the
vector field as synchronization variable.
Signed-off-by: Jan Beulich
[re-based]
Signed-off-by: Paul Durrant
Reviewed-by: Andrew Cooper
---
v6:
- Adjust naming as required by previous patch.
v3:
- Re-re-re-based after more changes.
v2:
- Re-re-based after Andrew's recent changes.
---
xen/arch/x86/hvm/dm.c | 5 -
xen/arch/x86/hvm/hvm.c| 10 ++
xen/include/asm-x86/hvm/hvm.h | 3 +++
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index ba88766..60cd602 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -245,13 +245,16 @@ static int inject_event(struct domain *d,
if ( data->vcpuid >= d->max_vcpus || !(v = d->vcpu[data->vcpuid]) )
return -EINVAL;
-if ( v->arch.hvm_vcpu.inject_event.vector != -1 )
+if ( cmpxchg(&v->arch.hvm_vcpu.inject_event.vector,
+ HVM_EVENT_VECTOR_UNSET, HVM_EVENT_VECTOR_UPDATING) !=
+ HVM_EVENT_VECTOR_UNSET )
return -EBUSY;
v->arch.hvm_vcpu.inject_event.type = data->type;
v->arch.hvm_vcpu.inject_event.insn_len = data->insn_len;
v->arch.hvm_vcpu.inject_event.error_code = data->error_code;
v->arch.hvm_vcpu.inject_event.cr2 = data->cr2;
+smp_wmb();
v->arch.hvm_vcpu.inject_event.vector = data->vector;
return 0;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 6c823de..c2349bc 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -538,13 +538,15 @@ void hvm_do_resume(struct vcpu *v)
}
}
-/* Inject pending hw/sw trap */
-if ( v->arch.hvm_vcpu.inject_event.vector != -1 )
+/* Inject pending hw/sw event */
+if ( v->arch.hvm_vcpu.inject_event.vector >= 0 )
{
+smp_rmb();
+
if ( !hvm_event_pending(v) )
hvm_inject_event(&v->arch.hvm_vcpu.inject_event);
-v->arch.hvm_vcpu.inject_event.vector = -1;
+v->arch.hvm_vcpu.inject_event.vector = HVM_EVENT_VECTOR_UNSET;
}
if ( unlikely(v->arch.vm_event) && v->arch.monitor.next_interrupt_enabled )
@@ -1515,7 +1517,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
(void(*)(unsigned long))hvm_assert_evtchn_irq,
(unsigned long)v);
-v->arch.hvm_vcpu.inject_event.vector = -1;
+v->arch.hvm_vcpu.inject_event.vector = HVM_EVENT_VECTOR_UNSET;
if ( is_pvh_domain(d) )
{
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 04e67fe..f88ff2e 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -77,6 +77,9 @@ enum hvm_intblk {
#define HVM_HAP_SUPERPAGE_2MB 0x0001
#define HVM_HAP_SUPERPAGE_1GB 0x0002
+#define HVM_EVENT_VECTOR_UNSET(-1)
+#define HVM_EVENT_VECTOR_UPDATING (-2)
+
/*
* The hardware virtual machine (HVM) interface abstracts away from the
* x86/x86_64 CPU virtualization assist specifics. Currently this interface
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 0/8] New hypercall for device models
Following on from the design submitted by Jennifer Herbert to the list [1] this series provides an implementation of __HYPERCALL_dm_op followed by patches based on Jan Beulich's previous HVMCTL series [2] to convert tools-only HVMOPs used by device models to DMOPs. [1] https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01052.html [2] https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg02433.html Paul Durrant (8): public / x86: Introduce __HYPERCALL_dm_op... dm_op: convert HVMOP_*ioreq_server* dm_op: convert HVMOP_track_dirty_vram dm_op: convert HVMOP_set_pci_intx_level, HVMOP_set_isa_irq_level, and... dm_op: convert HVMOP_modified_memory dm_op: convert HVMOP_set_mem_type dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi x86/hvm: serialize trap injecting producer and consumer docs/designs/dmop.markdown | 163 + tools/flask/policy/modules/xen.if | 8 +- tools/libxc/include/xenctrl.h | 13 +- tools/libxc/xc_domain.c | 212 +-- tools/libxc/xc_misc.c | 235 + tools/libxc/xc_private.c| 70 tools/libxc/xc_private.h| 2 + xen/arch/x86/hvm/Makefile | 1 + xen/arch/x86/hvm/dm.c | 567 ++ xen/arch/x86/hvm/hvm.c | 681 +--- xen/arch/x86/hvm/ioreq.c| 36 +- xen/arch/x86/hvm/irq.c | 7 +- xen/arch/x86/hypercall.c| 2 + xen/arch/x86/mm/hap/hap.c | 2 +- xen/arch/x86/mm/shadow/common.c | 2 +- xen/include/Makefile| 1 + xen/include/asm-x86/hap.h | 2 +- xen/include/asm-x86/hvm/domain.h| 3 +- xen/include/asm-x86/hvm/hvm.h | 3 + xen/include/asm-x86/hvm/vcpu.h | 2 +- xen/include/asm-x86/shadow.h| 2 +- xen/include/public/hvm/dm_op.h | 375 xen/include/public/hvm/hvm_op.h | 230 +--- xen/include/public/xen-compat.h | 2 +- xen/include/public/xen.h| 1 + xen/include/xen/hvm/irq.h | 2 +- xen/include/xen/hypercall.h | 15 + xen/include/xlat.lst| 1 + xen/include/xsm/dummy.h | 36 +- xen/include/xsm/xsm.h | 36 +- xen/xsm/dummy.c | 5 - xen/xsm/flask/hooks.c | 37 +- xen/xsm/flask/policy/access_vectors | 15 +- 33 files changed, 1452 insertions(+), 1317 deletions(-) create mode 100644 docs/designs/dmop.markdown create mode 100644 xen/arch/x86/hvm/dm.c create mode 100644 xen/include/public/hvm/dm_op.h -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 2/3] xen: modify xenstore watch event interface
Today a Xenstore watch event is delivered via a callback function
declared as:
void (*callback)(struct xenbus_watch *,
const char **vec, unsigned int len);
As all watch events only ever come with two parameters (path and token)
changing the prototype to:
void (*callback)(struct xenbus_watch *,
const char *path, const char *token);
is the natural thing to do.
Apply this change and adapt all users.
Cc: konrad.w...@oracle.com
Cc: roger@citrix.com
Cc: wei.l...@citrix.com
Cc: paul.durr...@citrix.com
Cc: net...@vger.kernel.org
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Reviewed-by: Wei Liu
Reviewed-by: Roger Pau Monné
Reviewed-by: Boris Ostrovsky
---
drivers/block/xen-blkback/xenbus.c | 6 +++---
drivers/net/xen-netback/xenbus.c | 8
drivers/xen/cpu_hotplug.c | 5 ++---
drivers/xen/manage.c | 6 +++---
drivers/xen/xen-balloon.c | 2 +-
drivers/xen/xen-pciback/xenbus.c | 2 +-
drivers/xen/xenbus/xenbus.h| 6 +++---
drivers/xen/xenbus/xenbus_client.c | 4 ++--
drivers/xen/xenbus/xenbus_dev_frontend.c | 21 -
drivers/xen/xenbus/xenbus_probe.c | 11 ---
drivers/xen/xenbus/xenbus_probe_backend.c | 8
drivers/xen/xenbus/xenbus_probe_frontend.c | 14 +++---
drivers/xen/xenbus/xenbus_xs.c | 29 ++---
include/xen/xenbus.h | 6 +++---
14 files changed, 59 insertions(+), 69 deletions(-)
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkback/xenbus.c
index 415e79b..8fe61b5 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -38,8 +38,8 @@ struct backend_info {
static struct kmem_cache *xen_blkif_cachep;
static void connect(struct backend_info *);
static int connect_ring(struct backend_info *);
-static void backend_changed(struct xenbus_watch *, const char **,
- unsigned int);
+static void backend_changed(struct xenbus_watch *, const char *,
+ const char *);
static void xen_blkif_free(struct xen_blkif *blkif);
static void xen_vbd_free(struct xen_vbd *vbd);
@@ -661,7 +661,7 @@ static int xen_blkbk_probe(struct xenbus_device *dev,
* ready, connect.
*/
static void backend_changed(struct xenbus_watch *watch,
- const char **vec, unsigned int len)
+ const char *path, const char *token)
{
int err;
unsigned major;
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 3124eae..d8a40fa 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -723,7 +723,7 @@ static int xen_net_read_mac(struct xenbus_device *dev, u8
mac[])
}
static void xen_net_rate_changed(struct xenbus_watch *watch,
- const char **vec, unsigned int len)
+const char *path, const char *token)
{
struct xenvif *vif = container_of(watch, struct xenvif, credit_watch);
struct xenbus_device *dev = xenvif_to_xenbus_device(vif);
@@ -780,7 +780,7 @@ static void xen_unregister_credit_watch(struct xenvif *vif)
}
static void xen_mcast_ctrl_changed(struct xenbus_watch *watch,
- const char **vec, unsigned int len)
+ const char *path, const char *token)
{
struct xenvif *vif = container_of(watch, struct xenvif,
mcast_ctrl_watch);
@@ -855,8 +855,8 @@ static void unregister_hotplug_status_watch(struct
backend_info *be)
}
static void hotplug_status_changed(struct xenbus_watch *watch,
- const char **vec,
- unsigned int vec_size)
+ const char *path,
+ const char *token)
{
struct backend_info *be = container_of(watch,
struct backend_info,
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 5676aef..7a4daa2 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -68,13 +68,12 @@ static void vcpu_hotplug(unsigned int cpu)
}
static void handle_vcpu_hotplug_event(struct xenbus_watch *watch,
- const char **vec, unsigned int len)
+ const char *path, const char *token)
{
unsigned int cpu;
char *cpustr;
- const char *node = vec[XS_WATCH_PATH];
- cpustr = strstr(node, "cpu/");
+ cpustr = strstr(path, "cpu/");
if (cpustr != NULL) {
sscanf(cpustr, "cpu/%u", &cpu);
vcpu_hotplug(cpu);
diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index 26e5e85..ca62c09 10064
[Xen-devel] [PATCH v3 1/3] xen: clean up xenbus internal headers
The xenbus driver has an awful mixture of internally and globally
visible headers: some of the internally used only stuff is defined in
the global header include/xen/xenbus.h while some stuff defined in
internal headers is used by other drivers, too.
Clean this up by moving the externally used symbols to
include/xen/xenbus.h and the symbols used internally only to a new
header drivers/xen/xenbus/xenbus.h replacing xenbus_comms.h and
xenbus_probe.h
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
---
v2: update commit message, re-add lost copyright
---
drivers/xen/xenbus/{xenbus_probe.h => xenbus.h} | 63 ++---
drivers/xen/xenbus/xenbus_client.c | 2 +-
drivers/xen/xenbus/xenbus_comms.c | 2 +-
drivers/xen/xenbus/xenbus_comms.h | 51
drivers/xen/xenbus/xenbus_dev_backend.c | 2 +-
drivers/xen/xenbus/xenbus_dev_frontend.c| 4 +-
drivers/xen/xenbus/xenbus_probe.c | 3 +-
drivers/xen/xenbus/xenbus_probe_backend.c | 3 +-
drivers/xen/xenbus/xenbus_probe_frontend.c | 3 +-
drivers/xen/xenbus/xenbus_xs.c | 3 +-
drivers/xen/xenfs/super.c | 2 +-
drivers/xen/xenfs/xenstored.c | 2 +-
include/xen/xenbus.h| 12 ++---
13 files changed, 52 insertions(+), 100 deletions(-)
rename drivers/xen/xenbus/{xenbus_probe.h => xenbus.h} (59%)
delete mode 100644 drivers/xen/xenbus/xenbus_comms.h
diff --git a/drivers/xen/xenbus/xenbus_probe.h b/drivers/xen/xenbus/xenbus.h
similarity index 59%
rename from drivers/xen/xenbus/xenbus_probe.h
rename to drivers/xen/xenbus/xenbus.h
index c9ec7ca..a6b007d 100644
--- a/drivers/xen/xenbus/xenbus_probe.h
+++ b/drivers/xen/xenbus/xenbus.h
@@ -1,7 +1,5 @@
-/**
- * xenbus_probe.h
- *
- * Talks to Xen Store to figure out what devices we have.
+/*
+ * Private include for xenbus communications.
*
* Copyright (C) 2005 Rusty Russell, IBM Corporation
* Copyright (C) 2005 XenSource Ltd.
@@ -31,8 +29,8 @@
* IN THE SOFTWARE.
*/
-#ifndef _XENBUS_PROBE_H
-#define _XENBUS_PROBE_H
+#ifndef _XENBUS_XENBUS_H
+#define _XENBUS_XENBUS_H
#define XEN_BUS_ID_SIZE20
@@ -54,35 +52,46 @@ enum xenstore_init {
XS_LOCAL,
};
+extern enum xenstore_init xen_store_domain_type;
extern const struct attribute_group *xenbus_dev_groups[];
-extern int xenbus_match(struct device *_dev, struct device_driver *_drv);
-extern int xenbus_dev_probe(struct device *_dev);
-extern int xenbus_dev_remove(struct device *_dev);
-extern int xenbus_register_driver_common(struct xenbus_driver *drv,
-struct xen_bus_type *bus,
-struct module *owner,
-const char *mod_name);
-extern int xenbus_probe_node(struct xen_bus_type *bus,
-const char *type,
-const char *nodename);
-extern int xenbus_probe_devices(struct xen_bus_type *bus);
+int xs_init(void);
+int xb_init_comms(void);
+void xb_deinit_comms(void);
+int xb_write(const void *data, unsigned int len);
+int xb_read(void *data, unsigned int len);
+int xb_data_to_read(void);
+int xb_wait_for_data_to_read(void);
-extern void xenbus_dev_changed(const char *node, struct xen_bus_type *bus);
+int xenbus_match(struct device *_dev, struct device_driver *_drv);
+int xenbus_dev_probe(struct device *_dev);
+int xenbus_dev_remove(struct device *_dev);
+int xenbus_register_driver_common(struct xenbus_driver *drv,
+ struct xen_bus_type *bus,
+ struct module *owner,
+ const char *mod_name);
+int xenbus_probe_node(struct xen_bus_type *bus,
+ const char *type,
+ const char *nodename);
+int xenbus_probe_devices(struct xen_bus_type *bus);
-extern void xenbus_dev_shutdown(struct device *_dev);
+void xenbus_dev_changed(const char *node, struct xen_bus_type *bus);
-extern int xenbus_dev_suspend(struct device *dev);
-extern int xenbus_dev_resume(struct device *dev);
-extern int xenbus_dev_cancel(struct device *dev);
+void xenbus_dev_shutdown(struct device *_dev);
-extern void xenbus_otherend_changed(struct xenbus_watch *watch,
- const char **vec, unsigned int len,
- int ignore_on_shutdown);
+int xenbus_dev_suspend(struct device *dev);
+int xenbus_dev_resume(struct device *dev);
+int xenbus_dev_cancel(struct device *dev);
-extern int xenbus_read_otherend_details(struct xenbus_device *xendev,
- char *id_node, char *path_node);
+void xenbus_otherend_changed(struct xenbus_watch *watch,
+const char **vec, unsigned int len,
[Xen-devel] [PATCH v3 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses
Handling of multiple concurrent Xenstore accesses through xenbus driver
either from the kernel or user land is rather lame today: xenbus is
capable to have one access active only at one point of time.
Rewrite xenbus to handle multiple requests concurrently by making use
of the request id of the Xenstore protocol. This requires to:
- Instead of blocking inside xb_read() when trying to read data from
the xenstore ring buffer do so only in the main loop of
xenbus_thread().
- Instead of doing writes to the xenstore ring buffer in the context of
the caller just queue the request and do the write in the dedicated
xenbus thread.
- Instead of just forwarding the request id specified by the caller of
xenbus to xenstore use a xenbus internal unique request id. This will
allow multiple outstanding requests.
- Modify the locking scheme in order to allow multiple requests being
active in parallel.
- Instead of waiting for the reply of a user's xenstore request after
writing the request to the xenstore ring buffer return directly to
the caller and do the waiting in the read path.
Additionally signal handling was optimized by avoiding waking up the
xenbus thread or sending an event to Xenstore in case the addressed
entity is known to be running already.
As a result communication with Xenstore is sped up by a factor of up
to 5: depending on the request type (read or write) and the amount of
data transferred the gain was at least 20% (small reads) and went up to
a factor of 5 for large writes.
In the end some more rough edges of xenbus have been smoothed:
- Handling of memory shortage when reading from xenstore ring buffer in
the xenbus driver was not optimal: it was busy looping and issuing a
warning in each loop.
- In case of xenstore not running in dom0 but in a stubdom we end up
with two xenbus threads running as the initialization of xenbus in
dom0 expecting a local xenstored will be redone later when connecting
to the xenstore domain. Up to now this was no problem as locking
would prevent the two xenbus threads interfering with each other, but
this was just a waste of kernel resources.
- An out of memory situation while writing to or reading from the
xenstore ring buffer no longer will lead to a possible loss of
synchronization with xenstore.
- The user read and write part are now interruptible by signals.
Signed-off-by: Juergen Gross
---
V3: - simplify xs_request_enter() as requested by Boris Ostrovsky
V2: address comments of Boris Ostrovsky:
- guard xs_request_id by lock
- move state struct definitions to the place where they are being
used
- rate limit some warnings
- use barrier() instead of cpu_relax()
- add/remove some comments
- minor changes like naming of variables
---
drivers/xen/xenbus/xenbus.h | 48 ++-
drivers/xen/xenbus/xenbus_comms.c| 313 --
drivers/xen/xenbus/xenbus_dev_frontend.c | 188 +++
drivers/xen/xenbus/xenbus_xs.c | 538 ++-
4 files changed, 684 insertions(+), 403 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus.h b/drivers/xen/xenbus/xenbus.h
index 5199527..149c5e7 100644
--- a/drivers/xen/xenbus/xenbus.h
+++ b/drivers/xen/xenbus/xenbus.h
@@ -32,6 +32,10 @@
#ifndef _XENBUS_XENBUS_H
#define _XENBUS_XENBUS_H
+#include
+#include
+#include
+
#define XEN_BUS_ID_SIZE20
struct xen_bus_type {
@@ -52,16 +56,49 @@ enum xenstore_init {
XS_LOCAL,
};
+struct xs_watch_event {
+ struct list_head list;
+ unsigned int len;
+ struct xenbus_watch *handle;
+ const char *path;
+ const char *token;
+ char body[];
+};
+
+enum xb_req_state {
+ xb_req_state_queued,
+ xb_req_state_wait_reply,
+ xb_req_state_got_reply,
+ xb_req_state_aborted
+};
+
+struct xb_req_data {
+ struct list_head list;
+ wait_queue_head_t wq;
+ struct xsd_sockmsg msg;
+ enum xsd_sockmsg_type type;
+ char *body;
+ const struct kvec *vec;
+ int num_vecs;
+ int err;
+ enum xb_req_state state;
+ void (*cb)(struct xb_req_data *);
+ void *par;
+};
+
extern enum xenstore_init xen_store_domain_type;
extern const struct attribute_group *xenbus_dev_groups[];
+extern struct mutex xs_response_mutex;
+extern struct list_head xs_reply_list;
+extern struct list_head xb_write_list;
+extern wait_queue_head_t xb_waitq;
+extern struct mutex xb_write_mutex;
int xs_init(void);
int xb_init_comms(void);
void xb_deinit_comms(void);
-int xb_write(const void *data, unsigned int len);
-int xb_read(void *data, unsigned int len);
-int xb_data_to_read(void);
-int xb_wait_for_data_to_read(void);
+int xs_watch_msg(struct xs_watch_event *event);
+void xs_request_exit(struct xb_req_data *req);
int xenbus_match(struct device *_dev, struct device_driver *_drv);
int xenbus_dev_probe(struct device *_dev);
@@ -92,6 +129,7 @@ int xenbu
[Xen-devel] [PATCH v3 0/3] xen: optimize xenbus performance
The xenbus driver used for communication with Xenstore (all kernel accesses to Xenstore and in case of Xenstore living in another domain all accesses of the local domain to Xenstore) is rather simple especially regarding multiple concurrent accesses: they are just being serialized in spite of Xenstore being capable to handle multiple parallel accesses. Clean up the external interface(s) of xenbus and optimize its performance by allowing multiple concurrent accesses to Xenstore. V3: - patch 3: simplify coding as requested by Boris Ostrovsky V2: - patch 1: update commit message, re-add lost copyright - patch 3: address comments of Boris Ostrovsky: - guard xs_request_id by lock - move state struct definitions to the place where they are being used - rate limit some warnings - use barrier() instead of cpu_relax() - add/remove some comments - minor changes like naming of variables Juergen Gross (3): xen: clean up xenbus internal headers xen: modify xenstore watch event interface xen: optimize xenbus driver for multiple concurrent xenstore accesses drivers/block/xen-blkback/xenbus.c | 6 +- drivers/net/xen-netback/xenbus.c | 8 +- drivers/xen/cpu_hotplug.c | 5 +- drivers/xen/manage.c | 6 +- drivers/xen/xen-balloon.c | 2 +- drivers/xen/xen-pciback/xenbus.c | 2 +- drivers/xen/xenbus/xenbus.h| 135 +++ drivers/xen/xenbus/xenbus_client.c | 6 +- drivers/xen/xenbus/xenbus_comms.c | 315 +++-- drivers/xen/xenbus/xenbus_comms.h | 51 --- drivers/xen/xenbus/xenbus_dev_backend.c| 2 +- drivers/xen/xenbus/xenbus_dev_frontend.c | 213 ++- drivers/xen/xenbus/xenbus_probe.c | 14 +- drivers/xen/xenbus/xenbus_probe.h | 88 - drivers/xen/xenbus/xenbus_probe_backend.c | 11 +- drivers/xen/xenbus/xenbus_probe_frontend.c | 17 +- drivers/xen/xenbus/xenbus_xs.c | 544 + drivers/xen/xenfs/super.c | 2 +- drivers/xen/xenfs/xenstored.c | 2 +- include/xen/xenbus.h | 18 +- 20 files changed, 835 insertions(+), 612 deletions(-) create mode 100644 drivers/xen/xenbus/xenbus.h delete mode 100644 drivers/xen/xenbus/xenbus_comms.h delete mode 100644 drivers/xen/xenbus/xenbus_probe.h Cc: konrad.w...@oracle.com Cc: roger@citrix.com Cc: wei.l...@citrix.com Cc: paul.durr...@citrix.com Cc: net...@vger.kernel.org -- 2.10.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.5-testing baseline-only test] 68419: trouble: blocked/broken
This run is configured for baseline tests only. flight 68419 xen-4.5-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68419/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 3 host-install(3) broken REGR. vs. 68264 build-armhf 3 host-install(3) broken REGR. vs. 68264 build-amd64 3 host-install(3) broken REGR. vs. 68264 build-amd64-pvops 3 host-install(3) broken REGR. vs. 68264 build-i386-prev 3 host-install(3) broken REGR. vs. 68264 build-i3863 host-install(3) broken REGR. vs. 68264 build-i386-pvops 3 host-install(3) broken REGR. vs. 68264 build-amd64-xtf 3 host-install(3) broken REGR. vs. 68264 build-amd64-prev 3 host-install(3) broken REGR. vs. 68264 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-xtf-amd64-amd64-11 build-check(1) blocked n/a test-armhf-armhf-xl-midway1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a build-i386-rumprun1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-xtf-amd64-amd64-21 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a build-amd64-rumprun 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-xtf-amd64-amd64-41 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-31 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-xtf-amd64-amd64-51 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build
[Xen-devel] [PATCH] x86emul: correct FPU stub asm() constraints
Properly inform the compiler about fic's role as both an input (its
insn_bytes field) and output (its exn_raised field).
Take the opportunity and bring emulate_fpu_insn_stub() more in line
with emulate_fpu_insn_stub_eflags().
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -924,13 +924,13 @@ static inline bool fpu_check_write(void)
: "=m" (fic.insn_bytes) \
: "m" (_arg) : "memory" )
-#define emulate_fpu_insn_stub(_bytes...)\
+#define emulate_fpu_insn_stub(bytes...) \
do {\
-uint8_t *buf = get_stub(stub); \
-unsigned int _nr = sizeof((uint8_t[]){ _bytes }); \
-fic.insn_bytes = _nr; \
-memcpy(buf, ((uint8_t[]){ _bytes, 0xc3 }), _nr + 1);\
-stub.func();\
+unsigned int nr_ = sizeof((uint8_t[]){ bytes });\
+fic.insn_bytes = nr_; \
+memcpy(get_stub(stub), ((uint8_t[]){ bytes, 0xc3 }), nr_ + 1); \
+asm volatile ( "call *%[stub]" : "+m" (fic) : \
+ [stub] "rm" (stub.func) ); \
put_stub(stub); \
} while (0)
@@ -944,7 +944,7 @@ do {
"call *%[func];" \
_POST_EFLAGS("[eflags]", "[mask]", "[tmp]") \
: [eflags] "+g" (_regs._eflags), \
- [tmp] "=&r" (tmp_) \
+ [tmp] "=&r" (tmp_), "+m" (fic) \
: [func] "rm" (stub.func), \
[mask] "i" (EFLG_ZF|EFLG_PF|EFLG_CF) );\
put_stub(stub); \
x86emul: correct FPU stub asm() constraints
Properly inform the compiler about fic's role as both an input (its
insn_bytes field) and output (its exn_raised field).
Take the opportunity and bring emulate_fpu_insn_stub() more in line
with emulate_fpu_insn_stub_eflags().
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -924,13 +924,13 @@ static inline bool fpu_check_write(void)
: "=m" (fic.insn_bytes) \
: "m" (_arg) : "memory" )
-#define emulate_fpu_insn_stub(_bytes...)\
+#define emulate_fpu_insn_stub(bytes...) \
do {\
-uint8_t *buf = get_stub(stub); \
-unsigned int _nr = sizeof((uint8_t[]){ _bytes }); \
-fic.insn_bytes = _nr; \
-memcpy(buf, ((uint8_t[]){ _bytes, 0xc3 }), _nr + 1);\
-stub.func();\
+unsigned int nr_ = sizeof((uint8_t[]){ bytes });\
+fic.insn_bytes = nr_; \
+memcpy(get_stub(stub), ((uint8_t[]){ bytes, 0xc3 }), nr_ + 1); \
+asm volatile ( "call *%[stub]" : "+m" (fic) : \
+ [stub] "rm" (stub.func) ); \
put_stub(stub); \
} while (0)
@@ -944,7 +944,7 @@ do {
"call *%[func];" \
_POST_EFLAGS("[eflags]", "[mask]", "[tmp]") \
: [eflags] "+g" (_regs._eflags), \
- [tmp] "=&r" (tmp_) \
+ [tmp] "=&r" (tmp_), "+m" (fic) \
: [func] "rm" (stub.func), \
[mask] "i" (EFLG_ZF|EFLG_PF|EFLG_CF) );\
put_stub(stub); \
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH XTF] don't overrun memory object
Using MOVUPS on an 8-byte quantity is wrong. There's no need for memory
accesses in any of the probe_*() functions anyway - switch them all to
insns without any operands or with register ones.
Signed-off-by: Jan Beulich
--- a/tests/fpu-exception-emulation/main.c
+++ b/tests/fpu-exception-emulation/main.c
@@ -52,7 +52,6 @@ struct test_cfg
exinfo_t fault;
};
-static unsigned long zero;
static unsigned long default_cr0;
/**
@@ -78,11 +77,10 @@ exinfo_t probe_x87(bool force)
asm volatile ("test %[fep], %[fep];"
"jz 1f;"
_ASM_XEN_FEP
- "1: fildq %[ptr]; 2:"
+ "1: fnop; 2:"
_ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_eax)
: "+a" (fault)
- : [ptr] "m" (zero),
-[fep] "q" (force));
+ : [fep] "q" (force));
return fault;
}
@@ -142,11 +140,10 @@ exinfo_t probe_mmx(bool force)
asm volatile ("test %[fep], %[fep];"
"jz 1f;"
_ASM_XEN_FEP
- "1: movq %[ptr], %%mm0; 2:"
+ "1: pxor %%mm0, %%mm0; 2:"
_ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_eax)
: "+a" (fault)
- : [ptr] "m" (zero),
-[fep] "q" (force));
+ : [fep] "q" (force));
return fault;
}
@@ -158,11 +155,10 @@ exinfo_t probe_sse(bool force)
asm volatile ("test %[fep], %[fep];"
"jz 1f;"
_ASM_XEN_FEP
- "1: movups %[ptr], %%xmm0; 2:"
+ "1: movups %%xmm0, %%xmm0; 2:"
_ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_eax)
: "+a" (fault)
- : [ptr] "m" (zero),
-[fep] "q" (force));
+ : [fep] "q" (force));
return fault;
}
don't overrun memory object
Using MOVUPS on an 8-byte quantity is wrong. There's no need for memory
accesses in any of the probe_*() functions anyway - switch them all to
insns without any operands or with register ones.
Signed-off-by: Jan Beulich
--- a/tests/fpu-exception-emulation/main.c
+++ b/tests/fpu-exception-emulation/main.c
@@ -52,7 +52,6 @@ struct test_cfg
exinfo_t fault;
};
-static unsigned long zero;
static unsigned long default_cr0;
/**
@@ -78,11 +77,10 @@ exinfo_t probe_x87(bool force)
asm volatile ("test %[fep], %[fep];"
"jz 1f;"
_ASM_XEN_FEP
- "1: fildq %[ptr]; 2:"
+ "1: fnop; 2:"
_ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_eax)
: "+a" (fault)
- : [ptr] "m" (zero),
-[fep] "q" (force));
+ : [fep] "q" (force));
return fault;
}
@@ -142,11 +140,10 @@ exinfo_t probe_mmx(bool force)
asm volatile ("test %[fep], %[fep];"
"jz 1f;"
_ASM_XEN_FEP
- "1: movq %[ptr], %%mm0; 2:"
+ "1: pxor %%mm0, %%mm0; 2:"
_ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_eax)
: "+a" (fault)
- : [ptr] "m" (zero),
-[fep] "q" (force));
+ : [fep] "q" (force));
return fault;
}
@@ -158,11 +155,10 @@ exinfo_t probe_sse(bool force)
asm volatile ("test %[fep], %[fep];"
"jz 1f;"
_ASM_XEN_FEP
- "1: movups %[ptr], %%xmm0; 2:"
+ "1: movups %%xmm0, %%xmm0; 2:"
_ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_eax)
: "+a" (fault)
- : [ptr] "m" (zero),
-[fep] "q" (force));
+ : [fep] "q" (force));
return fault;
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL
>>> On 22.01.17 at 05:35, wrote: > Yes, I asked Chao to add some debug info in that case. The problem now > is when we will reproduce the bug to see meaningful hint... If written reasonably, feel free to submit the patch for considering to put it into staging for a while. The bigger problem is that we'd then need to constantly scan logs for incidents. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] PVH CPU hotplug design document
>>> On 22.01.17 at 19:39, wrote: > On 01/18/2017 08:25 AM, Jan Beulich wrote: > On 18.01.17 at 12:54, wrote: >>> So, would it be fine to start a PVH Dom0 with as many vCPUs as what's >>> returned >>> from dom0_max_vcpus, and mark them as enabled in the MADT. That's basically >>> all >>> we need in order to match current PV Dom0 functionality? >> Yes, I think so. > > > Have we then decided that we are not supporting ACPI hotplug for both > dom0 and domU? I don't think anything has been decided yet, it's just that the road to (consistent) ACPI hotplug support still seems somewhat cloudy, so getting there (if we're convinced this is a worthwhile goal) may still take some time. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] Device memory mappings for Dom0 on ARM64 ACPI systems
On Fri, Jan 20, 2017 at 02:53:34PM -0800, Stefano Stabellini wrote: > On Fri, 20 Jan 2017, Roger Pau Monné wrote: > > > > > So you need DOM0 to tell the list of regions. > > > > > > > > Yes, I agree that we need such hypercall ATM, although I think that we > > > > might be > > > > able to get rid of it in the long term if we are able to parse the AML > > > > tables > > > > from Xen. > > > > > > Are you suggesting to bring a full AML parser in Xen? If so, it will be > > > much > > > bigger than Xen ARM itself. I would need a strong use case to accept a > > > such > > > thing. > > > > It could be placed in the init section, and get rid of it after boot. Also, > > I > > find it hard to believe that an AML parser is bigger than the whole Xen on > > ARM. > > The OpenBSD folks have a DSDT parser in ~4000 lines of code [0], and that's > > probably way more than what Xen actually needs. > > Even if it were actually possible, 4 KLOC is a significant increase in > code size, given that last time I counted Xen on ARM was under 90 KLOC. > Regardless, some AML methods have side effects. I don't know if the plan > of accessing some AML in Xen, then remapping tables and accessing them > again in Dom0 is actually sound. I don't think the spec supports it. Sure, Xen wouldn't be allowed to execute any AML method (so it's probably even less than 4KLOC, if the code is ripped). But Xen would be able to discover OperationRegions. In any case this is future work, and the hypercall route seems the most sensible one right now, we could always return -EEXIST if Xen starts mapping all this on behalf of the hardware domain at some point. I just wanted to point this out because I think the claims that have been made about AML parsers being bigger than Xen itself are not true, and discarding them based on size only is not reasonable. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH XTF] don't overrun memory object
On 23/01/17 10:30, Jan Beulich wrote: > Using MOVUPS on an 8-byte quantity is wrong. There's no need for memory > accesses in any of the probe_*() functions anyway - switch them all to > insns without any operands or with register ones. > > Signed-off-by: Jan Beulich So it is. The memory pointers were a leftover from trying to make this test not use FEP (and therefore suitable for testing older Xen). IIRC, the problem was that even with a memory operand, hardware took care of EM/MP/TS handling before taking a vmexit for MMIO emulation. Reviewed-by: Andrew Cooper and committed. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH XTF] don't overrun memory object
On 23/01/17 10:45, Andrew Cooper wrote: > On 23/01/17 10:30, Jan Beulich wrote: >> Using MOVUPS on an 8-byte quantity is wrong. There's no need for memory >> accesses in any of the probe_*() functions anyway - switch them all to >> insns without any operands or with register ones. >> >> Signed-off-by: Jan Beulich > So it is. > > The memory pointers were a leftover from trying to make this test not > use FEP (and therefore suitable for testing older Xen). > > IIRC, the problem was that even with a memory operand, hardware took > care of EM/MP/TS handling before taking a vmexit for MMIO emulation. > > Reviewed-by: Andrew Cooper and committed. Having said that, this currently regresses the test: --- Xen Test Framework --- Environment: HVM 64bit (Long mode 4 levels) FPU Exception Emulation Testing x87 Testing x87 wait Testing MMX Testing SSE Testing SSE (CR4.OSFXSR) Testing emulated x87 Testing emulated x87 wait Testing emulated MMX Expected nothing, got #UD (cr0: - ) Expected #NM, got #UD (cr0: TS) Expected nothing, got #UD (cr0: MP) Expected #NM, got #UD (cr0: MP TS) Testing emulated SSE Testing emulated SSE (CR4.OSFXSR) Test result: FAILURE A secondary requirement (to not regress) is that the test only uses instructions present in the emulator in the past, which I chose as being the point when FEP got added (seeing as that is a hard dependency). Would you be happy if I dropped all but the final hunk, i.e. retaining the use of fildq and movq ? ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL
On January 20, 2017 5:09 PM, Quan Xu wrote:
>btw, for PIR.. I find that there might be a bug in
>__vmx_deliver_posted_interrupt()...
>why test_and_set_bit(VCPU_KICK_SOFTIRQ, &softirq_pending(cpu)) ??
>
>static void __vmx_deliver_posted_interrupt(struct vcpu *v) { ...
>if ( !test_and_set_bit(VCPU_KICK_SOFTIRQ,
>&softirq_pending(cpu)) ...
>}
>
>Suppose that vCPUx is in guest mode, there are two (even more) interrupts
>to vCPUx..
>As the bit is set when delivers the first interrupt... the second interrupt is
>pending until next VM entry -- by PIR to vIRR..
>
Jan , Kevin
Correct me if I am wrong...
Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 1/8] public / x86: Introduce __HYPERCALL_dm_op...
On 23/01/17 10:00, Paul Durrant wrote:
> diff --git a/xen/include/public/hvm/dm_op.h b/xen/include/public/hvm/dm_op.h
> new file mode 100644
> index 000..9f3e9ee
> --- /dev/null
> +++ b/xen/include/public/hvm/dm_op.h
> @@ -0,0 +1,69 @@
> +/*
> + * Copyright (c) 2016, Citrix Systems Inc
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense,
> and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + */
> +
> +#ifndef __XEN_PUBLIC_HVM_DM_OP_H__
> +#define __XEN_PUBLIC_HVM_DM_OP_H__
> +
> +#if defined(__XEN__) || defined(__XEN_TOOLS__)
> +
> +#include "../xen.h"
> +
> +struct xen_dm_op {
> +uint32_t op;
> +};
> +
> +struct xen_dm_op_buf {
> +XEN_GUEST_HANDLE(void) h;
> +xen_ulong_t size;
> +};
> +typedef struct xen_dm_op_buf xen_dm_op_buf_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_dm_op_buf_t);
> +
> +/* ` enum neg_errnoval
> + * ` HYPERVISOR_dm_op(domid_t domid,
> + * ` xen_dm_op_buf_t bufs[],
> + * ` unsigned int nr_bufs)
> + * `
> + *
> + * @domid is the domain the hypercall operates on.
> + * @bufs points to an array of buffers where @bufs[0] contains a struct
> + * xen_dm_op, describing the specific device model operation and its
> + * parameters.
> + * @bufs[1..] may be referenced in the parameters for the purposes of
> + * passing extra information to or from the domain.
> + * @nr_bufs is the number of buffers in the @bufs array.
> + */
Sorry. One last issue. xen_dm_op_buf and the hypercall documentation
need to be outside the __XEN_TOOL__ define, as they to be used by the
kernel.
xen_dm_op can stay restricted to tools, as it is only needed by a device
model.
With this fixed, Reviewed-by: Andrew Cooper
. This can be fixed on commit if there are
no issues from others.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH XTF] don't overrun memory object
>>> On 23.01.17 at 11:51, wrote: > On 23/01/17 10:45, Andrew Cooper wrote: >> On 23/01/17 10:30, Jan Beulich wrote: >>> Using MOVUPS on an 8-byte quantity is wrong. There's no need for memory >>> accesses in any of the probe_*() functions anyway - switch them all to >>> insns without any operands or with register ones. >>> >>> Signed-off-by: Jan Beulich >> So it is. >> >> The memory pointers were a leftover from trying to make this test not >> use FEP (and therefore suitable for testing older Xen). >> >> IIRC, the problem was that even with a memory operand, hardware took >> care of EM/MP/TS handling before taking a vmexit for MMIO emulation. >> >> Reviewed-by: Andrew Cooper and committed. > Having said that, this currently regresses the test: > > --- Xen Test Framework --- > Environment: HVM 64bit (Long mode 4 levels) > FPU Exception Emulation > Testing x87 > Testing x87 wait > Testing MMX > Testing SSE > Testing SSE (CR4.OSFXSR) > Testing emulated x87 > Testing emulated x87 wait > Testing emulated MMX > Expected nothing, got #UD (cr0: - ) > Expected #NM, got #UD (cr0: TS) > Expected nothing, got #UD (cr0: MP) > Expected #NM, got #UD (cr0: MP TS) > Testing emulated SSE > Testing emulated SSE (CR4.OSFXSR) > Test result: FAILURE > > A secondary requirement (to not regress) is that the test only uses > instructions present in the emulator in the past, which I chose as being > the point when FEP got added (seeing as that is a hard dependency). Ah, it didn't regress for me because I ran it on top of the SSE/AVX emulation series. > Would you be happy if I dropped all but the final hunk, i.e. retaining > the use of fildq and movq ? Well, FNOP has always been supported, so I see no reason to drop that. How about replacing PXOR by MOVQ (but retaining the register operands)? (And I not that I left MOVUPS in place in error - I had really meant to make it XORPS, but this now means one less think for you to adjust.) Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map
>>> On 20.01.17 at 20:41, wrote:
> On 19/01/17 17:29, Roger Pau Monne wrote:
>> +tss = map_domain_gfn(p2m_get_hostp2m(d), _gfn(PFN_DOWN(gaddr)),
>> + &mfn, &p2mt, 0, &rc);
>> +if ( tss == NULL )
>> +{
>> +printk("Unable to map VM86 TSS area\n");
>> +return 0;
>> +}
>> +
>> +memset(tss, 0, HVM_VM86_TSS_SIZE);
>
> Do we actually need to 0 this? Don't we guarantee to hand out zero'd
> pages during construction? (I can't actually recall. Perhaps it is
> better to explicitly clear it.)
No, we don't zero before handing out, we zero after a reclaiming
memory from a dying guest or from the hypervisor.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Adding a section to the Xen security policy about what constitutes a vulnerability
On Wed, Jan 4, 2017 at 2:48 PM, George Dunlap wrote: > On Wed, Jan 4, 2017 at 1:16 PM, Jan Beulich wrote: > On 04.01.17 at 13:36, wrote: >>> 4. The security team will only issue an advisory if there is a known >>> combination of software in which the vulnerability can be exploited. >>> >>> In most cases, the software which contains the bug is also the target >>> of the attack: that is, a bug in Xen allows an unprivileged user to >>> crash Xen, a bug in QEMU allows an unprivileged user to escalate its >>> privileges to that of the QEMU process. In these cases "using Xen" or >>> "using QEMU" imples "being vulnerable". >>> >>> But this is not always so: for instance, a bug in the Xen instruction >>> emulator might allow a guest user to attack the guest kernel, *if* the >>> guest kernel behaves in a certain way, but not if it behaves in other >>> ways. In such a case, a bug will only be considered a vulnerability >>> if there are known operating systems on which the attack can be >>> executed. If no operating system can be found which allows such an >>> attack, no advisory will be issued. >> >> Both positively identifying an OS and proving a particular OS is >> unaffected will be kind of hard for closed source OSes. Hence I >> think ... >> >>> If a bug requires a vulnerable operating system to be exploitable, the >>> Xen Security Team will pro-actively investigate the vulnerability of >>> the following open-source operating systems: Linux, OpenBSD, FreeBSD, >>> and NetBSD. The security team may also test or otherwise investigate >>> the vulnerability of some proprietary operating systems. >> >> ... that for a bug to not be a vulnerability, at the very least >> Windows would need to be proven to be unaffected. If in >> doubt, an advisory should be issued. > > Quite a bit about Windows' internals are understood, by people who > write drivers, by people who have access to the source code, by people > who observe Windows' behavior as a guest, and so on. So I expect that > with the expertise of the organizations in the security team at the > moment, in practice we would have a pretty good idea whether Windows > would be vulnerable or not. I just didn't want to make any promises, > since (as you say) we can't look at the source code ourselves. I > think we should make a reasonable effort to ascertain whether Windows > is vulnerable; but I think we only need to be "reasonably certain" > that Windows is not vulnerable. I think so far the only concern raised. I mainly worded it the way that I did to "balance what we can promise and what we would like to deliver" -- that is, it promises that we will look at open-source operating systems, and implies that we will make a best-effort to look at Windows as well. Jan, are you happy with the wording the way it is? If not, could you make some concrete suggestions for how you think it could be improved? Thanks, -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Possible improvement to Xen Security Response Process
>>> On 20.01.17 at 20:21, wrote:
> James Bulpin writes ("Re: [Xen-devel] Possible improvement to Xen Security
> Response Process"):
>> , and the issue is considered to be of significant urgency due
>> to its severity, then the fourth Tuesday in the month should be
>> considered so long as this allows for a 14 day pre-disclosure
>> period" (or something like that).
>
> I agree with Jan that this fuzziness is undesirable. Also, more
> severe vulnerabilities are both more urgent to fix, and also have
> worse impact if released before people are ready, so severity is the
> wrong measure. If there is any kind of measure that is relevant it is
> difficulty.
>
> I'm writing here mostly with my personal hat, but my security team hat
> really dislikes ambiguity like this. It leads to unclear
> decisionmaking and side discussions.
>
> I would like the policy to specify a clear cutoff. Jan, are you
> comfortable with a "default" of between 2 and 4 weeks' embargo,
> depending on the timing of the discovery etc. ? Personally I think a
> 4 week maximum seems rather long, but with a 2 week cadence that can't
> be reduced without also shortening the 2 week minimum. The range 2-4
> weeks seems like a plausible compromise.
Well, 4 weeks seems pretty much to me too. Especially during calm
periods I wonder if it wasn't better to limit the embargo period by
simply promising to have a minimum distance of two weeks between
public disclosures.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 104601: regressions - FAIL
flight 104601 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/104601/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 5 kernel-build fail REGR. vs. 59254 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 59254 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linux7a308bb3016f57e5be11a677d15b821536419d36 baseline version: linux45820c294fe1b1a9df495d57f40585ef2d069a39 Last test of basis59254 2015-07-09 04:20:48 Z 564 days Failing since 59348 2015-07-10 04:24:05 Z 563 days 222 attempts Testing same since 104601 2017-01-23 04:22:59 Z0 days1 attempts 7515 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopsfail build-i386-pvops pass build-amd64-rumprun pass build-i386-rumprun pass test-amd64-amd64-xl pass test-armhf-armhf-xl blocked test-amd64-i386-xl pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm blocked test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm
[Xen-devel] [PATCH v2] xenstore: remove XS_RESTRICT support
XS_RESTRICT and the xenstore library function xs_restrict() have never been usable in all configurations and there are no known users. This functionality was thought to limit access rights of device models to xenstore in order to avoid affecting other domains in case of a security breech. Unfortunately XS_RESTRICT won't help as current qemu is requiring access to dom0 only accessible xenstore paths to work correctly. So this command is useless and should be removed. In order to avoid problems in the future remove all support for XS_RESTRICT from xenstore. Signed-off-by: Juergen Gross --- I'm rather sure I didn't delete anything from oxenstored not related to XS_RESTRICT, but I could have missed something. I'd appreciate a thorough review of the ocaml changes I did as my knowledge is rather limited here. V2: don't replace XS_RESTRICT enum member with a dummy one as suggested by Andrew Cooper --- tools/ocaml/libs/xb/op.ml | 5 ++--- tools/ocaml/libs/xb/xb.mli| 1 - tools/ocaml/xenstored/logging.ml | 1 - tools/ocaml/xenstored/process.ml | 16 tools/xenstore/include/xenstore.h | 9 - tools/xenstore/xenstored_core.c | 1 - tools/xenstore/xs.c | 8 xen/include/public/io/xs_wire.h | 4 ++-- 8 files changed, 4 insertions(+), 41 deletions(-) diff --git a/tools/ocaml/libs/xb/op.ml b/tools/ocaml/libs/xb/op.ml index 69346d8..d4f1f08 100644 --- a/tools/ocaml/libs/xb/op.ml +++ b/tools/ocaml/libs/xb/op.ml @@ -19,7 +19,7 @@ type operation = Debug | Directory | Read | Getperms | Transaction_end | Introduce | Release | Getdomainpath | Write | Mkdir | Rm | Setperms | Watchevent | Error | Isintroduced | - Resume | Set_target | Restrict | Reset_watches | + Resume | Set_target | Reset_watches | Invalid let operation_c_mapping = @@ -28,7 +28,7 @@ let operation_c_mapping = Transaction_end; Introduce; Release; Getdomainpath; Write; Mkdir; Rm; Setperms; Watchevent; Error; Isintroduced; - Resume; Set_target; Restrict; Reset_watches |] + Resume; Set_target; Reset_watches |] let size = Array.length operation_c_mapping let array_search el a = @@ -68,6 +68,5 @@ let to_string ty = | Isintroduced -> "IS_INTRODUCED" | Resume-> "RESUME" | Set_target-> "SET_TARGET" - | Restrict -> "RESTRICT" | Reset_watches -> "RESET_WATCHES" | Invalid -> "INVALID" diff --git a/tools/ocaml/libs/xb/xb.mli b/tools/ocaml/libs/xb/xb.mli index 6c242da..b4d7052 100644 --- a/tools/ocaml/libs/xb/xb.mli +++ b/tools/ocaml/libs/xb/xb.mli @@ -22,7 +22,6 @@ module Op : | Isintroduced | Resume | Set_target - | Restrict | Reset_watches | Invalid val operation_c_mapping : operation array diff --git a/tools/ocaml/xenstored/logging.ml b/tools/ocaml/xenstored/logging.ml index c52f03d..0c0d03d 100644 --- a/tools/ocaml/xenstored/logging.ml +++ b/tools/ocaml/xenstored/logging.ml @@ -241,7 +241,6 @@ let string_of_access_type = function | Xenbus.Xb.Op.Mkdir -> "mkdir" | Xenbus.Xb.Op.Rm-> "rm " | Xenbus.Xb.Op.Setperms -> "setperms " - | Xenbus.Xb.Op.Restrict -> "restrict " | Xenbus.Xb.Op.Reset_watches -> "reset watches" | Xenbus.Xb.Op.Set_target-> "settarget" diff --git a/tools/ocaml/xenstored/process.ml b/tools/ocaml/xenstored/process.ml index 7b60376..963549d 100644 --- a/tools/ocaml/xenstored/process.ml +++ b/tools/ocaml/xenstored/process.ml @@ -172,30 +172,16 @@ let do_isintroduced con t domains cons data = in if domid = Define.domid_self || Domains.exist domains domid then "T\000" else "F\000" -(* [restrict] is in the patch queue since xen3.2 *) -let do_restrict con t domains cons data = - if not (Connection.is_dom0 con) - then raise Define.Permission_denied; - let domid = - match (split None '\000' data) with - | [ domid; "" ] -> c_int_of_string domid - | _ -> raise Invalid_Cmd_Args - in - Connection.restrict con domid - (* only in xen >= 4.2 *) let do_reset_watches con t domains cons data = Connection.del_watches con; Connection.del_transactions con (* only in >= xen3.3 *) -(* we ensure backward compatibility with restrict by counting the number of argument of set_target ... *) -(* This is not very elegant, but it is safe as 'restrict' only restricts permission of dom0 connections *) let do_set_target con t domains cons data = if not (Connection.is_dom0 con) then raise Define.Permission_denied; match split None '\000' data w
Re: [Xen-devel] [PATCH XTF] don't overrun memory object
On 23/01/17 11:09, Jan Beulich wrote: On 23.01.17 at 11:51, wrote: >> On 23/01/17 10:45, Andrew Cooper wrote: >>> On 23/01/17 10:30, Jan Beulich wrote: Using MOVUPS on an 8-byte quantity is wrong. There's no need for memory accesses in any of the probe_*() functions anyway - switch them all to insns without any operands or with register ones. Signed-off-by: Jan Beulich >>> So it is. >>> >>> The memory pointers were a leftover from trying to make this test not >>> use FEP (and therefore suitable for testing older Xen). >>> >>> IIRC, the problem was that even with a memory operand, hardware took >>> care of EM/MP/TS handling before taking a vmexit for MMIO emulation. >>> >>> Reviewed-by: Andrew Cooper and committed. >> Having said that, this currently regresses the test: >> >> --- Xen Test Framework --- >> Environment: HVM 64bit (Long mode 4 levels) >> FPU Exception Emulation >> Testing x87 >> Testing x87 wait >> Testing MMX >> Testing SSE >> Testing SSE (CR4.OSFXSR) >> Testing emulated x87 >> Testing emulated x87 wait >> Testing emulated MMX >> Expected nothing, got #UD (cr0: - ) >> Expected #NM, got #UD (cr0: TS) >> Expected nothing, got #UD (cr0: MP) >> Expected #NM, got #UD (cr0: MP TS) >> Testing emulated SSE >> Testing emulated SSE (CR4.OSFXSR) >> Test result: FAILURE >> >> A secondary requirement (to not regress) is that the test only uses >> instructions present in the emulator in the past, which I chose as being >> the point when FEP got added (seeing as that is a hard dependency). > Ah, it didn't regress for me because I ran it on top of the SSE/AVX > emulation series. > >> Would you be happy if I dropped all but the final hunk, i.e. retaining >> the use of fildq and movq ? > Well, FNOP has always been supported, so I see no reason to drop > that. How about replacing PXOR by MOVQ (but retaining the register > operands)? (And I not that I left MOVUPS in place in error - I had > really meant to make it XORPS, but this now means one less think for > you to adjust.) Using mmx movq reg/reg does work. Fixed up and pushed. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Adding a section to the Xen security policy about what constitutes a vulnerability
>>> On 23.01.17 at 12:27, wrote: > On Wed, Jan 4, 2017 at 2:48 PM, George Dunlap > wrote: >> On Wed, Jan 4, 2017 at 1:16 PM, Jan Beulich wrote: >> On 04.01.17 at 13:36, wrote: 4. The security team will only issue an advisory if there is a known combination of software in which the vulnerability can be exploited. In most cases, the software which contains the bug is also the target of the attack: that is, a bug in Xen allows an unprivileged user to crash Xen, a bug in QEMU allows an unprivileged user to escalate its privileges to that of the QEMU process. In these cases "using Xen" or "using QEMU" imples "being vulnerable". But this is not always so: for instance, a bug in the Xen instruction emulator might allow a guest user to attack the guest kernel, *if* the guest kernel behaves in a certain way, but not if it behaves in other ways. In such a case, a bug will only be considered a vulnerability if there are known operating systems on which the attack can be executed. If no operating system can be found which allows such an attack, no advisory will be issued. >>> >>> Both positively identifying an OS and proving a particular OS is >>> unaffected will be kind of hard for closed source OSes. Hence I >>> think ... >>> If a bug requires a vulnerable operating system to be exploitable, the Xen Security Team will pro-actively investigate the vulnerability of the following open-source operating systems: Linux, OpenBSD, FreeBSD, and NetBSD. The security team may also test or otherwise investigate the vulnerability of some proprietary operating systems. >>> >>> ... that for a bug to not be a vulnerability, at the very least >>> Windows would need to be proven to be unaffected. If in >>> doubt, an advisory should be issued. >> >> Quite a bit about Windows' internals are understood, by people who >> write drivers, by people who have access to the source code, by people >> who observe Windows' behavior as a guest, and so on. So I expect that >> with the expertise of the organizations in the security team at the >> moment, in practice we would have a pretty good idea whether Windows >> would be vulnerable or not. I just didn't want to make any promises, >> since (as you say) we can't look at the source code ourselves. I >> think we should make a reasonable effort to ascertain whether Windows >> is vulnerable; but I think we only need to be "reasonably certain" >> that Windows is not vulnerable. > > I think so far the only concern raised. I mainly worded it the way > that I did to "balance what we can promise and what we would like to > deliver" -- that is, it promises that we will look at open-source > operating systems, and implies that we will make a best-effort to look > at Windows as well. > > Jan, are you happy with the wording the way it is? If not, could you > make some concrete suggestions for how you think it could be improved? "If a bug requires a vulnerable operating system to be exploitable, the Xen Security Team will pro-actively investigate the vulnerability of the following open-source operating systems: Linux, OpenBSD, FreeBSD, and NetBSD. The security team will also test or otherwise investigate the vulnerability of supported Windows versions, and it may also do so for some other proprietary operating systems." Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86emul: correct FPU stub asm() constraints
On 23/01/17 10:28, Jan Beulich wrote: > Properly inform the compiler about fic's role as both an input (its > insn_bytes field) and output (its exn_raised field). > > Take the opportunity and bring emulate_fpu_insn_stub() more in line > with emulate_fpu_insn_stub_eflags(). > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 1/8] public / x86: Introduce __HYPERCALL_dm_op...
> -Original Message-
> From: Andrew Cooper
> Sent: 23 January 2017 11:06
> To: Paul Durrant ; xen-de...@lists.xenproject.org
> Cc: Ian Jackson ; Jennifer Herbert
> ; Jan Beulich
> Subject: Re: [PATCH v6 1/8] public / x86: Introduce __HYPERCALL_dm_op...
>
> On 23/01/17 10:00, Paul Durrant wrote:
> > diff --git a/xen/include/public/hvm/dm_op.h
> b/xen/include/public/hvm/dm_op.h
> > new file mode 100644
> > index 000..9f3e9ee
> > --- /dev/null
> > +++ b/xen/include/public/hvm/dm_op.h
> > @@ -0,0 +1,69 @@
> > +/*
> > + * Copyright (c) 2016, Citrix Systems Inc
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> > + * of this software and associated documentation files (the "Software"),
> to
> > + * deal in the Software without restriction, including without limitation
> > the
> > + * rights to use, copy, modify, merge, publish, distribute, sublicense,
> and/or
> > + * sell copies of the Software, and to permit persons to whom the
> Software is
> > + * furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be included
> in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> KIND, EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
> EVENT SHALL THE
> > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> DAMAGES OR OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
> OR OTHER
> > + * DEALINGS IN THE SOFTWARE.
> > + *
> > + */
> > +
> > +#ifndef __XEN_PUBLIC_HVM_DM_OP_H__
> > +#define __XEN_PUBLIC_HVM_DM_OP_H__
> > +
> > +#if defined(__XEN__) || defined(__XEN_TOOLS__)
> > +
> > +#include "../xen.h"
> > +
> > +struct xen_dm_op {
> > +uint32_t op;
> > +};
> > +
> > +struct xen_dm_op_buf {
> > +XEN_GUEST_HANDLE(void) h;
> > +xen_ulong_t size;
> > +};
> > +typedef struct xen_dm_op_buf xen_dm_op_buf_t;
> > +DEFINE_XEN_GUEST_HANDLE(xen_dm_op_buf_t);
> > +
> > +/* ` enum neg_errnoval
> > + * ` HYPERVISOR_dm_op(domid_t domid,
> > + * ` xen_dm_op_buf_t bufs[],
> > + * ` unsigned int nr_bufs)
> > + * `
> > + *
> > + * @domid is the domain the hypercall operates on.
> > + * @bufs points to an array of buffers where @bufs[0] contains a struct
> > + * xen_dm_op, describing the specific device model operation and its
> > + * parameters.
> > + * @bufs[1..] may be referenced in the parameters for the purposes of
> > + * passing extra information to or from the domain.
> > + * @nr_bufs is the number of buffers in the @bufs array.
> > + */
>
> Sorry. One last issue. xen_dm_op_buf and the hypercall documentation
> need to be outside the __XEN_TOOL__ define, as they to be used by the
> kernel.
>
> xen_dm_op can stay restricted to tools, as it is only needed by a device
> model.
>
> With this fixed, Reviewed-by: Andrew Cooper
> . This can be fixed on commit if there are
> no issues from others.
>
I'm going to need to send v7. The name change in patch #7 broke the user-space
parts so I need to fix.
Paul
> ~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xenstore: remove XS_RESTRICT support
On Mon, Jan 23, 2017 at 12:32:55PM +0100, Juergen Gross wrote: > XS_RESTRICT and the xenstore library function xs_restrict() have never > been usable in all configurations and there are no known users. > > This functionality was thought to limit access rights of device models > to xenstore in order to avoid affecting other domains in case of a > security breech. Unfortunately XS_RESTRICT won't help as current > qemu is requiring access to dom0 only accessible xenstore paths to > work correctly. So this command is useless and should be removed. > > In order to avoid problems in the future remove all support for > XS_RESTRICT from xenstore. > > Signed-off-by: Juergen Gross > --- > I'm rather sure I didn't delete anything from oxenstored not related > to XS_RESTRICT, but I could have missed something. I'd appreciate a > thorough review of the ocaml changes I did as my knowledge is rather > limited here. [...] > in > if domid = Define.domid_self || Domains.exist domains domid then > "T\000" else "F\000" > > -(* [restrict] is in the patch queue since xen3.2 *) > -let do_restrict con t domains cons data = > - if not (Connection.is_dom0 con) > - then raise Define.Permission_denied; > - let domid = > - match (split None '\000' data) with > - | [ domid; "" ] -> c_int_of_string domid > - | _ -> raise Invalid_Cmd_Args > - in > - Connection.restrict con domid You haven't removed the restrict function in connection.ml and perms.ml. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [linux-linus test] 104237: regressions - FAIL
Ian Jackson writes ("Re: [Xen-devel] [linux-linus test] 104237: regressions -
FAIL"):
> I'm inclined to increasing the timeout, although this slowness does
> mean that our tests may be blocked more than we would like.
I have set the host property which I think will cause the timeout to
be increased. This should take effect for the next run of
linux-linus.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 1/9] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests
On Fri, Jan 20, 2017 at 06:41:21PM +, Andrew Cooper wrote: > On 19/01/17 17:29, Roger Pau Monne wrote: > > @@ -3768,7 +3770,9 @@ static long hvm_physdev_op(int cmd, > > XEN_GUEST_HANDLE_PARAM(void) arg) > > case PHYSDEVOP_eoi: > > case PHYSDEVOP_irq_status_query: > > case PHYSDEVOP_get_free_pirq: > > -return do_physdev_op(cmd, arg); > > +return ((currd->arch.emulation_flags & XEN_X86_EMU_USE_PIRQ) || > > How about: > > #define uses_pirqs(d) (!!((d)->arch.emulation_flags & > XEN_X86_EMU_USE_PIRQ)) I've named it "has_pirq" in order to match with the other options, that all use the has_ prefix (has_use_pirq sounds too strange IMHO). > to match the other emulation flags predicates (or some suitable naming)? > > Otherwise, Reviewed-by: Andrew Cooper Thanks. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xenstore: remove XS_RESTRICT support
On 23/01/17 13:14, Wei Liu wrote: > On Mon, Jan 23, 2017 at 12:32:55PM +0100, Juergen Gross wrote: >> XS_RESTRICT and the xenstore library function xs_restrict() have never >> been usable in all configurations and there are no known users. >> >> This functionality was thought to limit access rights of device models >> to xenstore in order to avoid affecting other domains in case of a >> security breech. Unfortunately XS_RESTRICT won't help as current >> qemu is requiring access to dom0 only accessible xenstore paths to >> work correctly. So this command is useless and should be removed. >> >> In order to avoid problems in the future remove all support for >> XS_RESTRICT from xenstore. >> >> Signed-off-by: Juergen Gross >> --- >> I'm rather sure I didn't delete anything from oxenstored not related >> to XS_RESTRICT, but I could have missed something. I'd appreciate a >> thorough review of the ocaml changes I did as my knowledge is rather >> limited here. > [...] >> in >> if domid = Define.domid_self || Domains.exist domains domid then >> "T\000" else "F\000" >> >> -(* [restrict] is in the patch queue since xen3.2 *) >> -let do_restrict con t domains cons data = >> -if not (Connection.is_dom0 con) >> -then raise Define.Permission_denied; >> -let domid = >> -match (split None '\000' data) with >> -| [ domid; "" ] -> c_int_of_string domid >> -| _ -> raise Invalid_Cmd_Args >> -in >> -Connection.restrict con domid > > You haven't removed the restrict function in connection.ml and perms.ml. I wasn't sure whether they are needed for "normal" permission checks. Will remove them in V3. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xenstore: remove XS_RESTRICT support
On Mon, Jan 23, 2017 at 01:34:21PM +0100, Juergen Gross wrote: > On 23/01/17 13:14, Wei Liu wrote: > > On Mon, Jan 23, 2017 at 12:32:55PM +0100, Juergen Gross wrote: > >> XS_RESTRICT and the xenstore library function xs_restrict() have never > >> been usable in all configurations and there are no known users. > >> > >> This functionality was thought to limit access rights of device models > >> to xenstore in order to avoid affecting other domains in case of a > >> security breech. Unfortunately XS_RESTRICT won't help as current > >> qemu is requiring access to dom0 only accessible xenstore paths to > >> work correctly. So this command is useless and should be removed. > >> > >> In order to avoid problems in the future remove all support for > >> XS_RESTRICT from xenstore. > >> > >> Signed-off-by: Juergen Gross > >> --- > >> I'm rather sure I didn't delete anything from oxenstored not related > >> to XS_RESTRICT, but I could have missed something. I'd appreciate a > >> thorough review of the ocaml changes I did as my knowledge is rather > >> limited here. > > [...] > >>in > >>if domid = Define.domid_self || Domains.exist domains domid then > >> "T\000" else "F\000" > >> > >> -(* [restrict] is in the patch queue since xen3.2 *) > >> -let do_restrict con t domains cons data = > >> - if not (Connection.is_dom0 con) > >> - then raise Define.Permission_denied; > >> - let domid = > >> - match (split None '\000' data) with > >> - | [ domid; "" ] -> c_int_of_string domid > >> - | _ -> raise Invalid_Cmd_Args > >> - in > >> - Connection.restrict con domid > > > > You haven't removed the restrict function in connection.ml and perms.ml. > > I wasn't sure whether they are needed for "normal" permission checks. > > Will remove them in V3. > Yeah, try to remove them and see if oxenstored still compiles. ;-) > > Juergen > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 104603: all pass - PUSHED
flight 104603 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104603/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7cf59c854f35c9680965fe83e9cfd863079ddd73
baseline version:
ovmf f3fa35a00233b6f2e7653b3b8c3e2b28b8ecbe7f
Last test of basis 104600 2017-01-23 02:45:18 Z0 days
Testing same since 104603 2017-01-23 07:45:18 Z0 days1 attempts
People who touched revisions under test:
Zhang Lubo
Zhang, Lubo
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=7cf59c854f35c9680965fe83e9cfd863079ddd73
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
7cf59c854f35c9680965fe83e9cfd863079ddd73
+ branch=ovmf
+ revision=7cf59c854f35c9680965fe83e9cfd863079ddd73
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x7cf59c854f35c9680965fe83e9cfd863079ddd73 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/gi
Re: [Xen-devel] [PATCH v5 3/9] xen/x86: split Dom0 build into PV and PVHv2
On Fri, Jan 20, 2017 at 07:03:10PM +, Andrew Cooper wrote:
> On 19/01/17 17:29, Roger Pau Monne wrote:
> > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> > index 0ccef1d..f52f269 100644
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -1545,6 +1545,15 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> > if ( opt_dom0pvh )
> > domcr_flags |= DOMCRF_pvh | DOMCRF_hap;
> >
> > +if ( dom0_pvh )
> > +{
> > +panic("Building a PVHv2 Dom0 is not yet supported.");
>
> This would be cleaner immediately before the return 0 of
> construct_dom0_pvh(), would it not?
>
> Otherwise, Reviewed-by: Andrew Cooper
I've moved the panic to the end of construct_dom0_pvh, and marked dom0_shadow
as deprecated in the document, would you like me to keep the R-B?
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/9] xen/x86: split Dom0 build into PV and PVHv2
On 23/01/17 12:58, Roger Pau Monne wrote:
> On Fri, Jan 20, 2017 at 07:03:10PM +, Andrew Cooper wrote:
>> On 19/01/17 17:29, Roger Pau Monne wrote:
>>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>>> index 0ccef1d..f52f269 100644
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -1545,6 +1545,15 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>> if ( opt_dom0pvh )
>>> domcr_flags |= DOMCRF_pvh | DOMCRF_hap;
>>>
>>> +if ( dom0_pvh )
>>> +{
>>> +panic("Building a PVHv2 Dom0 is not yet supported.");
>> This would be cleaner immediately before the return 0 of
>> construct_dom0_pvh(), would it not?
>>
>> Otherwise, Reviewed-by: Andrew Cooper
> I've moved the panic to the end of construct_dom0_pvh, and marked dom0_shadow
> as deprecated in the document, would you like me to keep the R-B?
Yeah - sounds fine.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support
On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote: > On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote: > > On 1/19/17 8:34 PM, Daniel Kiper wrote: > > > Hi, > > > > > > I am sending twelfth version of multiboot2 protocol support for > > > legacy BIOS and EFI platforms. This patch series release contains > > > fixes for all known/confirmed issues. > > > > With my fix to efi_multiboot2() in 5/10 and the entire series applied, I > > get the following on some of the systems I have access to: > > > > (XEN) [2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB > > (XEN) [7.012109] Stuck ?? > > (XEN) [7.012129] Failed to bring up CPU 1 (error -5) > > (XEN) [ 12.023606] Stuck ?? > > (XEN) [ 12.023622] Failed to bring up CPU 2 (error -5) > > (XEN) [ 17.035099] Stuck ?? > > (XEN) [ 17.035115] Failed to bring up CPU 3 (error -5) > > (XEN) [ 17.035116] Brought up 1 CPUs > > > > On other machines they reset when setting PAGING into cr0 (actually the > > jmp following it) on line 124 of trampoline.S > > Thanks! I will take a look. > > > If I drop the series to just 2-5 against staging (since patch 1 has > > already gone in) and apply the fix to efi_multiboot2() then all the > > machines I presently have access to boot. > > Great! > > > Effectively the fix to efi_multiboot2() gets us back to the same level > > of hardware support that v11 + my v5 was at for 1-5. So I will extend my: > > > > Reviewed-by: Doug Goldstein > > Tested-by: Doug Goldstein > > Thanks! > > > on the condition that the fix is applied to 5/10 prior to commit. > > Will do. > > By the way, I have asked my team colleagues to do more tests of this series. > I will come back to you if I have something in hand. Once you told me that you applied some patches on top of my patch series to get it working. Is it still true? If you still use some extra patches could you send me them? What about ExitBootServices() call? Did you disabled it? If yes on which machines it have to be disabled? Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 5/9] x86/hvm: add vcpu parameter to guest memory copy function
On Fri, Jan 20, 2017 at 07:45:35PM +, Andrew Cooper wrote:
> On 19/01/17 17:29, Roger Pau Monne wrote:
> > @@ -3172,9 +3173,9 @@ static enum hvm_copy_result __hvm_copy(
> > {
> > static unsigned long lastpage;
> > if ( xchg(&lastpage, gfn) != gfn )
> > -gdprintk(XENLOG_DEBUG, "guest attempted write to
> > read-only"
> > +printk(XENLOG_DEBUG, "%pv guest attempted write to
> > read-only"
> > " memory page. gfn=%#lx, mfn=%#lx\n",
> > - gfn, page_to_mfn(page));
> > + vcpu->domain, gfn, page_to_mfn(page));
>
> Just vcpu here, or hitting this printk() will try to follow
> d->shared_info as if it were v->domain.
>
> With this fixed, Reviewed-by: Andrew Cooper
Thanks, not sure why I've used domain here instead of vcpu.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH XTF] also test AVX exceptions
... as they're different from SSE and FPU ones.
Signed-off-by: Jan Beulich
--- a/include/arch/x86/cpuid.h
+++ b/include/arch/x86/cpuid.h
@@ -75,6 +75,7 @@ static inline bool cpu_has(unsigned int
#define cpu_has_smx cpu_has(X86_FEATURE_SMX)
#define cpu_has_pcidcpu_has(X86_FEATURE_PCID)
#define cpu_has_xsave cpu_has(X86_FEATURE_XSAVE)
+#define cpu_has_avx cpu_has(X86_FEATURE_AVX)
#define cpu_has_syscall cpu_has(X86_FEATURE_SYSCALL)
#define cpu_has_nx cpu_has(X86_FEATURE_NX)
--- a/include/arch/x86/lib.h
+++ b/include/arch/x86/lib.h
@@ -396,6 +396,33 @@ static inline unsigned int str(void)
return sel;
}
+static inline uint64_t xgetbv(uint32_t index)
+{
+uint32_t feat_lo;
+uint64_t feat_hi;
+
+asm volatile ("xgetbv" : "=a" (feat_lo), "=d" (feat_hi)
+ : "c" (index) );
+
+return feat_lo | (feat_hi << 32);
+}
+
+static inline void xsetbv(uint32_t index, uint64_t value)
+{
+asm volatile ("xsetbv" :: "a" ((uint32_t)value), "d" (value >> 32),
+ "c" (index) );
+}
+
+static inline uint64_t read_xcr0(void)
+{
+return xgetbv(0);
+}
+
+static inline void write_xcr0(uint64_t xcr0)
+{
+xsetbv(0, xcr0);
+}
+
#endif /* XTF_X86_LIB_H */
/*
--- a/include/arch/x86/processor.h
+++ b/include/arch/x86/processor.h
@@ -72,6 +72,30 @@
#define X86_DR6_BT (1u << 15) /* Task switch */
/*
+ * CPU features in XCR0.
+ */
+#define _XSTATE_FP0
+#define XSTATE_FP (1ULL << _XSTATE_FP)
+#define _XSTATE_SSE 1
+#define XSTATE_SSE(1ULL << _XSTATE_SSE)
+#define _XSTATE_YMM 2
+#define XSTATE_YMM(1ULL << _XSTATE_YMM)
+#define _XSTATE_BNDREGS 3
+#define XSTATE_BNDREGS(1ULL << _XSTATE_BNDREGS)
+#define _XSTATE_BNDCSR4
+#define XSTATE_BNDCSR (1ULL << _XSTATE_BNDCSR)
+#define _XSTATE_OPMASK5
+#define XSTATE_OPMASK (1ULL << _XSTATE_OPMASK)
+#define _XSTATE_ZMM 6
+#define XSTATE_ZMM(1ULL << _XSTATE_ZMM)
+#define _XSTATE_HI_ZMM7
+#define XSTATE_HI_ZMM (1ULL << _XSTATE_HI_ZMM)
+#define _XSTATE_PKRU 9
+#define XSTATE_PKRU (1ULL << _XSTATE_PKRU)
+#define _XSTATE_LWP 62
+#define XSTATE_LWP(1ULL << _XSTATE_LWP)
+
+/*
* Exception mnemonics.
*/
#define X86_EXC_DE 0 /* Divide Error. */
--- a/tests/fpu-exception-emulation/main.c
+++ b/tests/fpu-exception-emulation/main.c
@@ -163,6 +163,37 @@ exinfo_t probe_sse(bool force)
return fault;
}
+/**
+ * AVX instructions. The emulation flag is meaningless,
+ * but @#NM should be raised if the task has been switched.
+ */
+static const struct test_cfg avx[] =
+{
+{ CR0_SYM( ), 0 },
+{ CR0_SYM(TS), EXINFO_SYM(NM, 0) },
+{ CR0_SYM(MP), 0 },
+{ CR0_SYM(MP, TS), EXINFO_SYM(NM, 0) },
+{ CR0_SYM(EM), 0 },
+{ CR0_SYM(EM, TS), EXINFO_SYM(NM, 0) },
+{ CR0_SYM(EM, MP), 0 },
+{ CR0_SYM(EM, MP, TS), EXINFO_SYM(NM, 0) },
+};
+
+static exinfo_t probe_avx(bool force)
+{
+exinfo_t fault = 0;
+
+asm volatile ("test %[fep], %[fep];"
+ "jz 1f;"
+ _ASM_XEN_FEP
+ "1: vmovups %%xmm0, %%xmm0; 2:"
+ _ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_eax)
+ : "+a" (fault)
+ : [fep] "q" (force));
+
+return fault;
+}
+
void run_sequence(const struct test_cfg *seq, unsigned int nr,
unsigned int (*fn)(bool), bool force, exinfo_t override)
{
@@ -226,6 +257,31 @@ void run_tests(bool force)
write_cr4(cr4);
}
+
+if ( cpu_has_avx )
+{
+unsigned long cr4 = read_cr4();
+unsigned long xcr0;
+
+printk("Testing%s AVX\n", force ? " emulated" : "");
+write_cr4(cr4 & ~X86_CR4_OSXSAVE);
+run_sequence(avx, ARRAY_SIZE(avx), probe_avx, force,
+ EXINFO_SYM(UD, 0));
+
+printk("Testing%s AVX (CR4.OSXSAVE)\n", force ? " emulated" : "");
+write_cr4(cr4 | X86_CR4_OSXSAVE);
+xcr0 = read_xcr0();
+write_xcr0(xcr0 & ~XSTATE_YMM);
+run_sequence(avx, ARRAY_SIZE(avx), probe_avx, force,
+ EXINFO_SYM(UD, 0));
+
+printk("Testing%s AVX (CR4.OSXSAVE+XCR0.YMM)\n", force ? " emulated" :
"");
+write_xcr0(xcr0 | XSTATE_SSE | XSTATE_YMM);
+run_sequence(avx, ARRAY_SIZE(avx), probe_avx, force, 0);
+
+write_xcr0(xcr0);
+write_cr4(cr4);
+}
}
void test_main(void)
also test AVX exceptions
... as they're different from SSE and FPU ones.
Signed-off-by: Jan Beulich
--- a/include/arch/x86/cpuid.h
+++ b/include/arch/x86/cpuid.h
@@ -75,6 +75,7 @@ static inline bool cpu_has(unsigned int
#define cpu_has_smx
[Xen-devel] [PATCH v7 0/8] New hypercall for device models
Following on from the design submitted by Jennifer Herbert to the list [1] this series provides an implementation of __HYPERCALL_dm_op followed by patches based on Jan Beulich's previous HVMCTL series [2] to convert tools-only HVMOPs used by device models to DMOPs. [1] https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01052.html [2] https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg02433.html Paul Durrant (8): public / x86: Introduce __HYPERCALL_dm_op... dm_op: convert HVMOP_*ioreq_server* dm_op: convert HVMOP_track_dirty_vram dm_op: convert HVMOP_set_pci_intx_level, HVMOP_set_isa_irq_level, and... dm_op: convert HVMOP_modified_memory dm_op: convert HVMOP_set_mem_type dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi x86/hvm: serialize trap injecting producer and consumer docs/designs/dmop.markdown | 163 + tools/flask/policy/modules/xen.if | 8 +- tools/libxc/include/xenctrl.h | 13 +- tools/libxc/xc_domain.c | 212 +-- tools/libxc/xc_misc.c | 235 + tools/libxc/xc_private.c| 70 tools/libxc/xc_private.h| 2 + xen/arch/x86/hvm/Makefile | 1 + xen/arch/x86/hvm/dm.c | 567 ++ xen/arch/x86/hvm/hvm.c | 681 +--- xen/arch/x86/hvm/ioreq.c| 36 +- xen/arch/x86/hvm/irq.c | 7 +- xen/arch/x86/hypercall.c| 2 + xen/arch/x86/mm/hap/hap.c | 2 +- xen/arch/x86/mm/shadow/common.c | 2 +- xen/include/Makefile| 1 + xen/include/asm-x86/hap.h | 2 +- xen/include/asm-x86/hvm/domain.h| 3 +- xen/include/asm-x86/hvm/hvm.h | 3 + xen/include/asm-x86/hvm/vcpu.h | 2 +- xen/include/asm-x86/shadow.h| 2 +- xen/include/public/hvm/dm_op.h | 375 xen/include/public/hvm/hvm_op.h | 230 +--- xen/include/public/xen-compat.h | 2 +- xen/include/public/xen.h| 1 + xen/include/xen/hvm/irq.h | 2 +- xen/include/xen/hypercall.h | 15 + xen/include/xlat.lst| 1 + xen/include/xsm/dummy.h | 36 +- xen/include/xsm/xsm.h | 36 +- xen/xsm/dummy.c | 5 - xen/xsm/flask/hooks.c | 37 +- xen/xsm/flask/policy/access_vectors | 15 +- 33 files changed, 1452 insertions(+), 1317 deletions(-) create mode 100644 docs/designs/dmop.markdown create mode 100644 xen/arch/x86/hvm/dm.c create mode 100644 xen/include/public/hvm/dm_op.h -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 8/8] x86/hvm: serialize trap injecting producer and consumer
Since injection works on a remote vCPU, and since there's no
enforcement of the subject vCPU being paused, there's a potential race
between the producing and consuming sides. Fix this by leveraging the
vector field as synchronization variable.
Signed-off-by: Jan Beulich
[re-based]
Signed-off-by: Paul Durrant
Reviewed-by: Andrew Cooper
---
v6:
- Adjust naming as required by previous patch.
v3:
- Re-re-re-based after more changes.
v2:
- Re-re-based after Andrew's recent changes.
---
xen/arch/x86/hvm/dm.c | 5 -
xen/arch/x86/hvm/hvm.c| 10 ++
xen/include/asm-x86/hvm/hvm.h | 3 +++
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index ba88766..60cd602 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -245,13 +245,16 @@ static int inject_event(struct domain *d,
if ( data->vcpuid >= d->max_vcpus || !(v = d->vcpu[data->vcpuid]) )
return -EINVAL;
-if ( v->arch.hvm_vcpu.inject_event.vector != -1 )
+if ( cmpxchg(&v->arch.hvm_vcpu.inject_event.vector,
+ HVM_EVENT_VECTOR_UNSET, HVM_EVENT_VECTOR_UPDATING) !=
+ HVM_EVENT_VECTOR_UNSET )
return -EBUSY;
v->arch.hvm_vcpu.inject_event.type = data->type;
v->arch.hvm_vcpu.inject_event.insn_len = data->insn_len;
v->arch.hvm_vcpu.inject_event.error_code = data->error_code;
v->arch.hvm_vcpu.inject_event.cr2 = data->cr2;
+smp_wmb();
v->arch.hvm_vcpu.inject_event.vector = data->vector;
return 0;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index dc8af05..0ff81d7 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -538,13 +538,15 @@ void hvm_do_resume(struct vcpu *v)
}
}
-/* Inject pending hw/sw trap */
-if ( v->arch.hvm_vcpu.inject_event.vector != -1 )
+/* Inject pending hw/sw event */
+if ( v->arch.hvm_vcpu.inject_event.vector >= 0 )
{
+smp_rmb();
+
if ( !hvm_event_pending(v) )
hvm_inject_event(&v->arch.hvm_vcpu.inject_event);
-v->arch.hvm_vcpu.inject_event.vector = -1;
+v->arch.hvm_vcpu.inject_event.vector = HVM_EVENT_VECTOR_UNSET;
}
if ( unlikely(v->arch.vm_event) && v->arch.monitor.next_interrupt_enabled )
@@ -1515,7 +1517,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
(void(*)(unsigned long))hvm_assert_evtchn_irq,
(unsigned long)v);
-v->arch.hvm_vcpu.inject_event.vector = -1;
+v->arch.hvm_vcpu.inject_event.vector = HVM_EVENT_VECTOR_UNSET;
if ( is_pvh_domain(d) )
{
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 04e67fe..f88ff2e 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -77,6 +77,9 @@ enum hvm_intblk {
#define HVM_HAP_SUPERPAGE_2MB 0x0001
#define HVM_HAP_SUPERPAGE_1GB 0x0002
+#define HVM_EVENT_VECTOR_UNSET(-1)
+#define HVM_EVENT_VECTOR_UPDATING (-2)
+
/*
* The hardware virtual machine (HVM) interface abstracts away from the
* x86/x86_64 CPU virtualization assist specifics. Currently this interface
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 7/8] dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi
NOTE: This patch also modifies the types of the 'vector', 'type' and
'insn_len' arguments of xc_hvm_inject_trap() from uint32_t to
uint8_t. In practice the values passed were always truncated to
8 bits.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
Acked-by: Wei Liu
Acked-by: Daniel De Graaf
Reviewed-by: Andrew Cooper
---
Cc: Ian Jackson
v7:
- Fix libxc code broken in v6.
v6:
- s/trap/event as requested by Andy (and adjust struct hvm_vcpu
accordingly).
v3:
- Fixed prefixing and padding.
v2:
- Addressed several comments from Jan.
---
tools/flask/policy/modules/xen.if | 2 +-
tools/libxc/include/xenctrl.h | 4 +-
tools/libxc/xc_misc.c | 64 ++--
xen/arch/x86/hvm/dm.c | 45
xen/arch/x86/hvm/hvm.c | 84 ++---
xen/include/asm-x86/hvm/vcpu.h | 2 +-
xen/include/public/hvm/dm_op.h | 48 +
xen/include/public/hvm/hvm_op.h | 45
xen/include/xsm/dummy.h | 6 ---
xen/include/xsm/xsm.h | 6 ---
xen/xsm/dummy.c | 1 -
xen/xsm/flask/hooks.c | 6 ---
xen/xsm/flask/policy/access_vectors | 5 +--
13 files changed, 125 insertions(+), 193 deletions(-)
diff --git a/tools/flask/policy/modules/xen.if
b/tools/flask/policy/modules/xen.if
index 092a6c5..45e5cea 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -151,7 +151,7 @@ define(`device_model', `
allow $1 $2_target:domain { getdomaininfo shutdown };
allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack
};
- allow $1 $2_target:hvm { getparam setparam hvmctl cacheattr send_irq dm
};
+ allow $1 $2_target:hvm { getparam setparam hvmctl cacheattr dm };
')
# make_device_model(priv, dm_dom, hvm_dom)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 6648679..aba69c4 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1641,8 +1641,8 @@ int xc_hvm_set_mem_type(
* resumes.
*/
int xc_hvm_inject_trap(
-xc_interface *xch, domid_t dom, int vcpu, uint32_t vector,
-uint32_t type, uint32_t error_code, uint32_t insn_len,
+xc_interface *xch, domid_t dom, int vcpu, uint8_t vector,
+uint8_t type, uint32_t error_code, uint8_t insn_len,
uint64_t cr2);
/*
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 5b06d6b..0fc6c22 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -527,29 +527,20 @@ int xc_hvm_set_pci_link_route(
}
int xc_hvm_inject_msi(
-xc_interface *xch, domid_t dom, uint64_t addr, uint32_t data)
+xc_interface *xch, domid_t dom, uint64_t msi_addr, uint32_t msi_data)
{
-DECLARE_HYPERCALL_BUFFER(struct xen_hvm_inject_msi, arg);
-int rc;
-
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-{
-PERROR("Could not allocate memory for xc_hvm_inject_msi hypercall");
-return -1;
-}
+struct xen_dm_op op;
+struct xen_dm_op_inject_msi *data;
-arg->domid = dom;
-arg->addr = addr;
-arg->data = data;
+memset(&op, 0, sizeof(op));
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
- HVMOP_inject_msi,
- HYPERCALL_BUFFER_AS_ARG(arg));
+op.op = XEN_DMOP_inject_msi;
+data = &op.u.inject_msi;
-xc_hypercall_buffer_free(xch, arg);
+data->addr = msi_addr;
+data->data = msi_data;
-return rc;
+return do_dm_op(xch, dom, 1, &op, sizeof(op));
}
int xc_hvm_track_dirty_vram(
@@ -608,35 +599,26 @@ int xc_hvm_set_mem_type(
}
int xc_hvm_inject_trap(
-xc_interface *xch, domid_t dom, int vcpu, uint32_t vector,
-uint32_t type, uint32_t error_code, uint32_t insn_len,
+xc_interface *xch, domid_t dom, int vcpu, uint8_t vector,
+uint8_t type, uint32_t error_code, uint8_t insn_len,
uint64_t cr2)
{
-DECLARE_HYPERCALL_BUFFER(struct xen_hvm_inject_trap, arg);
-int rc;
-
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-{
-PERROR("Could not allocate memory for xc_hvm_inject_trap hypercall");
-return -1;
-}
+struct xen_dm_op op;
+struct xen_dm_op_inject_event *data;
-arg->domid = dom;
-arg->vcpuid = vcpu;
-arg->vector = vector;
-arg->type= type;
-arg->error_code = error_code;
-arg->insn_len= insn_len;
-arg->cr2 = cr2;
+memset(&op, 0, sizeof(op));
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
- HVMOP_inject_trap,
- HYPERCALL_BUFFER_AS_ARG(arg));
+op.op = XEN_DMOP_inject_event;
+data = &op.u.inject_event;
-xc_hypercall_buffer_free(xch, arg);
+data->vcpuid = vcpu;
+data->vector = vector;
+data->type = typ
[Xen-devel] [PATCH v7 4/8] dm_op: convert HVMOP_set_pci_intx_level, HVMOP_set_isa_irq_level, and...
... HVMOP_set_pci_link_route
These HVMOPs were exposed to guests so their definitions need to be
preserved for compatibility. This patch therefore updates
__XEN_LATEST_INTERFACE_VERSION__ to 0x00040900 and makes the HVMOP
defintions conditional on __XEN_INTERFACE_VERSION__ less than that value.
NOTE: This patch also widens the 'domain' parameter of
xc_hvm_set_pci_intx_level() from a uint8_t to a uint16_t.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
Acked-by: Wei Liu
Acked-by: Daniel De Graaf
Reviewed-by: Andrew Cooper
---
Cc: Ian Jackson
v3:
- Remove unnecessary padding.
v2:
- Interface version modification moved to this patch, where it is needed.
- Addressed several comments from Jan.
---
tools/flask/policy/modules/xen.if | 8 +--
tools/libxc/include/xenctrl.h | 2 +-
tools/libxc/xc_misc.c | 83 --
xen/arch/x86/hvm/dm.c | 72 +++
xen/arch/x86/hvm/hvm.c | 136
xen/arch/x86/hvm/irq.c | 7 +-
xen/include/public/hvm/dm_op.h | 42 +++
xen/include/public/hvm/hvm_op.h | 4 ++
xen/include/public/xen-compat.h | 2 +-
xen/include/xen/hvm/irq.h | 2 +-
xen/include/xsm/dummy.h | 18 -
xen/include/xsm/xsm.h | 18 -
xen/xsm/dummy.c | 3 -
xen/xsm/flask/hooks.c | 15
xen/xsm/flask/policy/access_vectors | 6 --
15 files changed, 158 insertions(+), 260 deletions(-)
diff --git a/tools/flask/policy/modules/xen.if
b/tools/flask/policy/modules/xen.if
index 45e5b5f..092a6c5 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -57,8 +57,8 @@ define(`create_domain_common', `
allow $1 $2:shadow enable;
allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage
mmuext_op updatemp };
allow $1 $2:grant setup;
- allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
- setparam pcilevel nested altp2mhvm altp2mhvm_op
send_irq };
+ allow $1 $2:hvm { cacheattr getparam hvmctl sethvmc
+ setparam nested altp2mhvm altp2mhvm_op send_irq };
')
# create_domain(priv, target)
@@ -93,7 +93,7 @@ define(`manage_domain', `
# (inbound migration is the same as domain creation)
define(`migrate_domain_out', `
allow $1 domxen_t:mmu map_read;
- allow $1 $2:hvm { gethvmc getparam irqlevel };
+ allow $1 $2:hvm { gethvmc getparam };
allow $1 $2:mmu { stat pageinfo map_read };
allow $1 $2:domain { getaddrsize getvcpucontext pause destroy };
allow $1 $2:domain2 gettsc;
@@ -151,7 +151,7 @@ define(`device_model', `
allow $1 $2_target:domain { getdomaininfo shutdown };
allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack
};
- allow $1 $2_target:hvm { getparam setparam hvmctl irqlevel pciroute
pcilevel cacheattr send_irq dm };
+ allow $1 $2_target:hvm { getparam setparam hvmctl cacheattr send_irq dm
};
')
# make_device_model(priv, dm_dom, hvm_dom)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 0cf1b48..6ab7e20 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1594,7 +1594,7 @@ int xc_physdev_unmap_pirq(xc_interface *xch,
int xc_hvm_set_pci_intx_level(
xc_interface *xch, domid_t dom,
-uint8_t domain, uint8_t bus, uint8_t device, uint8_t intx,
+uint16_t domain, uint8_t bus, uint8_t device, uint8_t intx,
unsigned int level);
int xc_hvm_set_isa_irq_level(
xc_interface *xch, domid_t dom,
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 4c41d41..ddea2bb 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -470,33 +470,24 @@ int xc_getcpuinfo(xc_interface *xch, int max_cpus,
int xc_hvm_set_pci_intx_level(
xc_interface *xch, domid_t dom,
-uint8_t domain, uint8_t bus, uint8_t device, uint8_t intx,
+uint16_t domain, uint8_t bus, uint8_t device, uint8_t intx,
unsigned int level)
{
-DECLARE_HYPERCALL_BUFFER(struct xen_hvm_set_pci_intx_level, arg);
-int rc;
-
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-{
-PERROR("Could not allocate memory for xc_hvm_set_pci_intx_level
hypercall");
-return -1;
-}
+struct xen_dm_op op;
+struct xen_dm_op_set_pci_intx_level *data;
-arg->domid = dom;
-arg->domain = domain;
-arg->bus= bus;
-arg->device = device;
-arg->intx = intx;
-arg->level = level;
+memset(&op, 0, sizeof(op));
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
- HVMOP_set_pci_intx_level,
- HYPERCALL_BUFFER_AS_ARG(arg));
+op.op = XEN_DMOP_set_pci_intx_level;
+data = &op.u.set_pci_intx_level;
-xc_hypercall_buffe
[Xen-devel] [PATCH v7 2/8] dm_op: convert HVMOP_*ioreq_server*
The definitions of HVM_IOREQSRV_BUFIOREQ_* have to persist as they are
already in use by callers of the libxc interface.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
Acked-by: Wei Liu
Acked-by: Daniel De Graaf
Reviewed-by: Andrew Cooper
--
Cc: Ian Jackson
v6:
- Modify const_op as appropriate.
v4:
- #define uint64_aligned_t if necessary to handle compat code generation.
v3:
- Fix pad check.
v2:
- Addressed several comments from Jan.
---
tools/libxc/xc_domain.c | 212 -
xen/arch/x86/hvm/dm.c| 93 +
xen/arch/x86/hvm/hvm.c | 219 ---
xen/arch/x86/hvm/ioreq.c | 36 +++
xen/include/asm-x86/hvm/domain.h | 3 +-
xen/include/public/hvm/dm_op.h | 158
xen/include/public/hvm/hvm_op.h | 132 +--
xen/include/xsm/dummy.h | 6 --
xen/include/xsm/xsm.h| 6 --
xen/xsm/dummy.c | 1 -
xen/xsm/flask/hooks.c| 6 --
11 files changed, 365 insertions(+), 507 deletions(-)
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 296b852..419a897 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1417,24 +1417,24 @@ int xc_hvm_create_ioreq_server(xc_interface *xch,
int handle_bufioreq,
ioservid_t *id)
{
-DECLARE_HYPERCALL_BUFFER(xen_hvm_create_ioreq_server_t, arg);
+struct xen_dm_op op;
+struct xen_dm_op_create_ioreq_server *data;
int rc;
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-return -1;
+memset(&op, 0, sizeof(op));
-arg->domid = domid;
-arg->handle_bufioreq = handle_bufioreq;
+op.op = XEN_DMOP_create_ioreq_server;
+data = &op.u.create_ioreq_server;
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
- HVMOP_create_ioreq_server,
- HYPERCALL_BUFFER_AS_ARG(arg));
+data->handle_bufioreq = handle_bufioreq;
+
+rc = do_dm_op(xch, domid, 1, &op, sizeof(op));
+if ( rc )
+return rc;
-*id = arg->id;
+*id = data->id;
-xc_hypercall_buffer_free(xch, arg);
-return rc;
+return 0;
}
int xc_hvm_get_ioreq_server_info(xc_interface *xch,
@@ -1444,84 +1444,71 @@ int xc_hvm_get_ioreq_server_info(xc_interface *xch,
xen_pfn_t *bufioreq_pfn,
evtchn_port_t *bufioreq_port)
{
-DECLARE_HYPERCALL_BUFFER(xen_hvm_get_ioreq_server_info_t, arg);
+struct xen_dm_op op;
+struct xen_dm_op_get_ioreq_server_info *data;
int rc;
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-return -1;
+memset(&op, 0, sizeof(op));
-arg->domid = domid;
-arg->id = id;
+op.op = XEN_DMOP_get_ioreq_server_info;
+data = &op.u.get_ioreq_server_info;
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
- HVMOP_get_ioreq_server_info,
- HYPERCALL_BUFFER_AS_ARG(arg));
-if ( rc != 0 )
-goto done;
+data->id = id;
+
+rc = do_dm_op(xch, domid, 1, &op, sizeof(op));
+if ( rc )
+return rc;
if ( ioreq_pfn )
-*ioreq_pfn = arg->ioreq_pfn;
+*ioreq_pfn = data->ioreq_pfn;
if ( bufioreq_pfn )
-*bufioreq_pfn = arg->bufioreq_pfn;
+*bufioreq_pfn = data->bufioreq_pfn;
if ( bufioreq_port )
-*bufioreq_port = arg->bufioreq_port;
+*bufioreq_port = data->bufioreq_port;
-done:
-xc_hypercall_buffer_free(xch, arg);
-return rc;
+return 0;
}
int xc_hvm_map_io_range_to_ioreq_server(xc_interface *xch, domid_t domid,
ioservid_t id, int is_mmio,
uint64_t start, uint64_t end)
{
-DECLARE_HYPERCALL_BUFFER(xen_hvm_io_range_t, arg);
-int rc;
+struct xen_dm_op op;
+struct xen_dm_op_ioreq_server_range *data;
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-return -1;
+memset(&op, 0, sizeof(op));
-arg->domid = domid;
-arg->id = id;
-arg->type = is_mmio ? HVMOP_IO_RANGE_MEMORY : HVMOP_IO_RANGE_PORT;
-arg->start = start;
-arg->end = end;
+op.op = XEN_DMOP_map_io_range_to_ioreq_server;
+data = &op.u.map_io_range_to_ioreq_server;
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
- HVMOP_map_io_range_to_ioreq_server,
- HYPERCALL_BUFFER_AS_ARG(arg));
+data->id = id;
+data->type = is_mmio ? XEN_DMOP_IO_RANGE_MEMORY : XEN_DMOP_IO_RANGE_PORT;
+data->start = start;
+data->end = end;
-xc_hypercall_buffer_free(xch, arg);
-return rc;
+return do_dm_op(xch, domid, 1, &op, sizeof(op));
}
int xc_hvm_unmap_io_range_from_ioreq_server(xc_interfac
[Xen-devel] [PATCH v7 3/8] dm_op: convert HVMOP_track_dirty_vram
The handle type passed to the underlying shadow and hap functions is
changed for compatibility with the new hypercall buffer.
NOTE: This patch also modifies the type of the 'nr' parameter of
xc_hvm_track_dirty_vram() from uint64_t to uint32_t. In practice
the value passed was always truncated to 32 bits.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
Acked-by: Wei Liu
Acked-by: George Dunlap
Acked-by: Tim Deegan
Acked-by: Daniel De Graaf
Reviewed-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
Cc: Ian Jackson
v4:
- Knock-on changes from compat code in dm.c. Not adding Jan's R-b since
the patch has fundamentally changed.
v3:
- Check d->max_vcpus rather than d->vcpu, as requested by Jan.
- The handle type changes (from uint8 to void) are still necessary, hence
omitting Jan's R-b until this is confirmed to be acceptable.
v2:
- Addressed several comments from Jan.
---
tools/flask/policy/modules/xen.if | 4 ++--
tools/libxc/include/xenctrl.h | 2 +-
tools/libxc/xc_misc.c | 32 +
xen/arch/x86/hvm/dm.c | 40 +++-
xen/arch/x86/hvm/hvm.c | 41 -
xen/arch/x86/mm/hap/hap.c | 2 +-
xen/arch/x86/mm/shadow/common.c | 2 +-
xen/include/asm-x86/hap.h | 2 +-
xen/include/asm-x86/shadow.h| 2 +-
xen/include/public/hvm/dm_op.h | 18
xen/include/public/hvm/hvm_op.h | 16 ---
xen/xsm/flask/hooks.c | 3 ---
xen/xsm/flask/policy/access_vectors | 2 --
13 files changed, 74 insertions(+), 92 deletions(-)
diff --git a/tools/flask/policy/modules/xen.if
b/tools/flask/policy/modules/xen.if
index f9254c2..45e5b5f 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -58,7 +58,7 @@ define(`create_domain_common', `
allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage
mmuext_op updatemp };
allow $1 $2:grant setup;
allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
- setparam pcilevel trackdirtyvram nested altp2mhvm
altp2mhvm_op send_irq };
+ setparam pcilevel nested altp2mhvm altp2mhvm_op
send_irq };
')
# create_domain(priv, target)
@@ -151,7 +151,7 @@ define(`device_model', `
allow $1 $2_target:domain { getdomaininfo shutdown };
allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack
};
- allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl
irqlevel pciroute pcilevel cacheattr send_irq dm };
+ allow $1 $2_target:hvm { getparam setparam hvmctl irqlevel pciroute
pcilevel cacheattr send_irq dm };
')
# make_device_model(priv, dm_dom, hvm_dom)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index cf36521..0cf1b48 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1620,7 +1620,7 @@ int xc_hvm_inject_msi(
*/
int xc_hvm_track_dirty_vram(
xc_interface *xch, domid_t dom,
-uint64_t first_pfn, uint64_t nr,
+uint64_t first_pfn, uint32_t nr,
unsigned long *bitmap);
/*
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 06e90de..4c41d41 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -581,34 +581,22 @@ int xc_hvm_inject_msi(
int xc_hvm_track_dirty_vram(
xc_interface *xch, domid_t dom,
-uint64_t first_pfn, uint64_t nr,
+uint64_t first_pfn, uint32_t nr,
unsigned long *dirty_bitmap)
{
-DECLARE_HYPERCALL_BOUNCE(dirty_bitmap, (nr+7) / 8,
XC_HYPERCALL_BUFFER_BOUNCE_OUT);
-DECLARE_HYPERCALL_BUFFER(struct xen_hvm_track_dirty_vram, arg);
-int rc;
+struct xen_dm_op op;
+struct xen_dm_op_track_dirty_vram *data;
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL || xc_hypercall_bounce_pre(xch, dirty_bitmap) )
-{
-PERROR("Could not bounce memory for xc_hvm_track_dirty_vram
hypercall");
-rc = -1;
-goto out;
-}
+memset(&op, 0, sizeof(op));
-arg->domid = dom;
-arg->first_pfn = first_pfn;
-arg->nr= nr;
-set_xen_guest_handle(arg->dirty_bitmap, dirty_bitmap);
+op.op = XEN_DMOP_track_dirty_vram;
+data = &op.u.track_dirty_vram;
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
- HVMOP_track_dirty_vram,
- HYPERCALL_BUFFER_AS_ARG(arg));
+data->first_pfn = first_pfn;
+data->nr = nr;
-out:
-xc_hypercall_buffer_free(xch, arg);
-xc_hypercall_bounce_post(xch, dirty_bitmap);
-return rc;
+return do_dm_op(xch, dom, 2, &op, sizeof(op),
+dirty_bitmap, (nr + 7) / 8);
}
int xc_hvm_modified_memory(
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index 72cb33a..b0908f4 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -18,7 +18,9 @@
#i
[Xen-devel] [PATCH v7 6/8] dm_op: convert HVMOP_set_mem_type
This patch removes the need for handling HVMOP restarts, so that
infrastructure is removed.
NOTE: This patch also modifies the type of the 'nr' argument of
xc_hvm_set_mem_type() from uint64_t to uint32_t. In practice the
value passed was always truncated to 32 bits.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
Acked-by: Wei Liu
Acked-by: Daniel De Graaf
Reviewed-by: Andrew Cooper
---
Cc: Ian Jackson
v6:
- Pass by reference as requested by Andy.
- Modify const_op appropriately.
v4:
- Added initializers as requested by Jan.
v3:
- Addressed more comments from Jan.
v2:
- Addressed several comments from Jan.
---
tools/libxc/include/xenctrl.h | 2 +-
tools/libxc/xc_misc.c | 29 +++-
xen/arch/x86/hvm/dm.c | 91
xen/arch/x86/hvm/hvm.c | 136 +---
xen/include/public/hvm/dm_op.h | 22 ++
xen/include/public/hvm/hvm_op.h | 20 --
xen/xsm/flask/policy/access_vectors | 2 +-
7 files changed, 126 insertions(+), 176 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 5ff53ed..6648679 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1634,7 +1634,7 @@ int xc_hvm_modified_memory(
* Allowed types are HVMMEM_ram_rw, HVMMEM_ram_ro, HVMMEM_mmio_dm
*/
int xc_hvm_set_mem_type(
-xc_interface *xch, domid_t dom, hvmmem_type_t memtype, uint64_t first_pfn,
uint64_t nr);
+xc_interface *xch, domid_t dom, hvmmem_type_t memtype, uint64_t first_pfn,
uint32_t nr);
/*
* Injects a hardware/software CPU trap, to take effect the next time the HVM
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 597df99..5b06d6b 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -590,30 +590,21 @@ int xc_hvm_modified_memory(
}
int xc_hvm_set_mem_type(
-xc_interface *xch, domid_t dom, hvmmem_type_t mem_type, uint64_t
first_pfn, uint64_t nr)
+xc_interface *xch, domid_t dom, hvmmem_type_t mem_type, uint64_t
first_pfn, uint32_t nr)
{
-DECLARE_HYPERCALL_BUFFER(struct xen_hvm_set_mem_type, arg);
-int rc;
-
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-{
-PERROR("Could not allocate memory for xc_hvm_set_mem_type hypercall");
-return -1;
-}
+struct xen_dm_op op;
+struct xen_dm_op_set_mem_type *data;
-arg->domid= dom;
-arg->hvmmem_type = mem_type;
-arg->first_pfn= first_pfn;
-arg->nr = nr;
+memset(&op, 0, sizeof(op));
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
- HVMOP_set_mem_type,
- HYPERCALL_BUFFER_AS_ARG(arg));
+op.op = XEN_DMOP_set_mem_type;
+data = &op.u.set_mem_type;
-xc_hypercall_buffer_free(xch, arg);
+data->mem_type = mem_type;
+data->first_pfn = first_pfn;
+data->nr = nr;
-return rc;
+return do_dm_op(xch, dom, 1, &op, sizeof(op));
}
int xc_hvm_inject_trap(
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index e28bda4..cc68ba9 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -161,6 +161,82 @@ static int modified_memory(struct domain *d,
return rc;
}
+static bool allow_p2m_type_change(p2m_type_t old, p2m_type_t new)
+{
+return p2m_is_ram(old) ||
+ (p2m_is_hole(old) && new == p2m_mmio_dm) ||
+ (old == p2m_ioreq_server && new == p2m_ram_rw);
+}
+
+static int set_mem_type(struct domain *d,
+struct xen_dm_op_set_mem_type *data)
+{
+xen_pfn_t last_pfn = data->first_pfn + data->nr - 1;
+unsigned int iter = 0;
+int rc = 0;
+
+/* Interface types to internal p2m types */
+static const p2m_type_t memtype[] = {
+[HVMMEM_ram_rw] = p2m_ram_rw,
+[HVMMEM_ram_ro] = p2m_ram_ro,
+[HVMMEM_mmio_dm] = p2m_mmio_dm,
+[HVMMEM_unused] = p2m_invalid,
+[HVMMEM_ioreq_server] = p2m_ioreq_server,
+};
+
+if ( (data->first_pfn > last_pfn) ||
+ (last_pfn > domain_get_maximum_gpfn(d)) )
+return -EINVAL;
+
+if ( data->mem_type >= ARRAY_SIZE(memtype) ||
+ unlikely(data->mem_type == HVMMEM_unused) )
+return -EINVAL;
+
+while ( iter < data->nr )
+{
+unsigned long pfn = data->first_pfn + iter;
+p2m_type_t t;
+
+get_gfn_unshare(d, pfn, &t);
+if ( p2m_is_paging(t) )
+{
+put_gfn(d, pfn);
+p2m_mem_paging_populate(d, pfn);
+return -EAGAIN;
+}
+
+if ( p2m_is_shared(t) )
+rc = -EAGAIN;
+else if ( !allow_p2m_type_change(t, memtype[data->mem_type]) )
+rc = -EINVAL;
+else
+rc = p2m_change_type_one(d, pfn, t, memtype[data->mem_type]);
+
+put_gfn(d, pfn);
+
+if ( rc )
+break;
+
+iter++;
+
+/*
+
[Xen-devel] [PATCH v7 1/8] public / x86: Introduce __HYPERCALL_dm_op...
...as a set of hypercalls to be used by a device model.
As stated in the new docs/designs/dm_op.markdown:
"The aim of DMOP is to prevent a compromised device model from
compromising domains other then the one it is associated with. (And is
therefore likely already compromised)."
See that file for further information.
This patch simply adds the boilerplate for the hypercall.
Signed-off-by: Paul Durrant
Suggested-by: Ian Jackson
Suggested-by: Jennifer Herbert
Acked-by: Daniel De Graaf
Acked-by: Wei Liu
Reviewed-by: Andrew Cooper
---
Cc: Ian Jackson
Cc: Jennifer Herbert
Cc: Jan Beulich
v7:
- Move the hypercall and xen_dm_op_buf definition outside __XEN_TOOLS__
v6:
- Add bool to control copy-back of op structure as requested by Andy
v5:
- Copy functions now use exact sizes.
- Addressed other comments from Jan, Wei and Andrew. However I have
left the code that unconditionally copies back the op structure as
I think it will needlessly complicate the code to make this selective.
v4:
- Change XEN_GUEST_HANDLE_64 to XEN_GUEST_HANDLE in struct xen_dm_op_buf
and add the necessary compat code. Drop Jan's R-b since the patch has
been fundamentally modified.
v3:
- Re-written large portions of dmop.markdown to remove references to
previous proposals and make it a standalone design doc.
v2:
- Addressed several comments from Jan.
- Removed modification of __XEN_LATEST_INTERFACE_VERSION__ as it is not
needed in this patch.
---
docs/designs/dmop.markdown| 165 ++
tools/flask/policy/modules/xen.if | 2 +-
tools/libxc/include/xenctrl.h | 1 +
tools/libxc/xc_private.c | 70
tools/libxc/xc_private.h | 2 +
xen/arch/x86/hvm/Makefile | 1 +
xen/arch/x86/hvm/dm.c | 142
xen/arch/x86/hvm/hvm.c| 1 +
xen/arch/x86/hypercall.c | 2 +
xen/include/Makefile | 1 +
xen/include/public/hvm/dm_op.h| 69
xen/include/public/xen.h | 1 +
xen/include/xen/hypercall.h | 15
xen/include/xlat.lst | 1 +
xen/include/xsm/dummy.h | 6 ++
xen/include/xsm/xsm.h | 6 ++
xen/xsm/flask/hooks.c | 7 ++
17 files changed, 491 insertions(+), 1 deletion(-)
create mode 100644 docs/designs/dmop.markdown
create mode 100644 xen/arch/x86/hvm/dm.c
create mode 100644 xen/include/public/hvm/dm_op.h
diff --git a/docs/designs/dmop.markdown b/docs/designs/dmop.markdown
new file mode 100644
index 000..3c3f3a6
--- /dev/null
+++ b/docs/designs/dmop.markdown
@@ -0,0 +1,165 @@
+DMOP
+
+
+Introduction
+
+
+The aim of DMOP is to prevent a compromised device model from compromising
+domains other than the one it is providing emulation for (which is therefore
+likely already compromised).
+
+The problem occurs when you a device model issues an hypercall that
+includes references to user memory other than the operation structure
+itself, such as with Track dirty VRAM (as used in VGA emulation).
+Is this case, the address of this other user memory needs to be vetted,
+to ensure it is not within restricted address ranges, such as kernel
+memory. The real problem comes down to how you would vet this address -
+the idea place to do this is within the privcmd driver, without privcmd
+having to have specific knowledge of the hypercall's semantics.
+
+The Design
+--
+
+The privcmd driver implements a new restriction ioctl, which takes a domid
+parameter. After that restriction ioctl is issued, all unaudited operations
+on the privcmd driver will cease to function, including regular hypercalls.
+DMOP hypercalls will continue to function as they can be audited.
+
+A DMOP hypercall consists of a domid (which is audited to verify that it
+matches any restriction in place) and an array of buffers and lengths,
+with the first one containing the specific DMOP parameters. These can
+then reference further buffers from within in the array. Since the only
+user buffers passed are that found with that array, they can all can be
+audited by privcmd.
+
+The following code illustrates this idea:
+
+struct xen_dm_op {
+uint32_t op;
+};
+
+struct xen_dm_op_buf {
+XEN_GUEST_HANDLE(void) h;
+unsigned long size;
+};
+typedef struct xen_dm_op_buf xen_dm_op_buf_t;
+
+enum neg_errnoval
+HYPERVISOR_dm_op(domid_t domid,
+ xen_dm_op_buf_t bufs[],
+ unsigned int nr_bufs)
+
+@domid is the domain the hypercall operates on.
+@bufs points to an array of buffers where @bufs[0] contains a struct
+dm_op, describing the specific device model operation and its parameters.
+@bufs[1..] may be referenced in the parameters for the purposes of
+passing extra information to or from the domain.
+@nr_bufs is the number of buffers in the @bufs array.
+
+It is forbidden for the above struct (xen_dm_op) to contain any guest
+handles. If they are ne
[Xen-devel] [PATCH v7 5/8] dm_op: convert HVMOP_modified_memory
This patch introduces code to handle DMOP continuations.
NOTE: This patch also modifies the type of the 'nr' argument of
xc_hvm_modified_memory() from uint64_t to uint32_t. In practice the
value passed was always truncated to 32 bits.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
Acked-by: Wei Liu
Acked-by: Daniel De Graaf
Reviewed-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
Cc: Ian Jackson
v6:
- Pass by pointer as requested by Andy.
- Modify const_op appropriately.
v4:
- Continuation code in dm.c modified as knock-on from compat code. Not
adding Jan's R-b since patch has fundamentally changed.
v3:
- Addressed more comments from Jan.
v2:
- Addressed several comments from Jan, including...
- Added explanatory note on continuation handling
---
tools/libxc/include/xenctrl.h | 2 +-
tools/libxc/xc_misc.c | 27 ---
xen/arch/x86/hvm/dm.c | 89 +++--
xen/arch/x86/hvm/hvm.c | 60 -
xen/include/public/hvm/dm_op.h | 19
xen/include/public/hvm/hvm_op.h | 13 --
xen/xsm/flask/policy/access_vectors | 2 +-
7 files changed, 116 insertions(+), 96 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 6ab7e20..5ff53ed 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1627,7 +1627,7 @@ int xc_hvm_track_dirty_vram(
* Notify that some pages got modified by the Device Model
*/
int xc_hvm_modified_memory(
-xc_interface *xch, domid_t dom, uint64_t first_pfn, uint64_t nr);
+xc_interface *xch, domid_t dom, uint64_t first_pfn, uint32_t nr);
/*
* Set a range of memory to a specific type.
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index ddea2bb..597df99 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -573,29 +573,20 @@ int xc_hvm_track_dirty_vram(
}
int xc_hvm_modified_memory(
-xc_interface *xch, domid_t dom, uint64_t first_pfn, uint64_t nr)
+xc_interface *xch, domid_t dom, uint64_t first_pfn, uint32_t nr)
{
-DECLARE_HYPERCALL_BUFFER(struct xen_hvm_modified_memory, arg);
-int rc;
-
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-{
-PERROR("Could not allocate memory for xc_hvm_modified_memory
hypercall");
-return -1;
-}
+struct xen_dm_op op;
+struct xen_dm_op_modified_memory *data;
-arg->domid = dom;
-arg->first_pfn = first_pfn;
-arg->nr= nr;
+memset(&op, 0, sizeof(op));
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
- HVMOP_modified_memory,
- HYPERCALL_BUFFER_AS_ARG(arg));
+op.op = XEN_DMOP_modified_memory;
+data = &op.u.modified_memory;
-xc_hypercall_buffer_free(xch, arg);
+data->first_pfn = first_pfn;
+data->nr = nr;
-return rc;
+return do_dm_op(xch, dom, 1, &op, sizeof(op));
}
int xc_hvm_set_mem_type(
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index d847892..e28bda4 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -14,6 +14,7 @@
* this program; If not, see
[Xen-devel] [xtf test] 104606: all pass - PUSHED
flight 104606 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104606/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 7e1bc8009286dcf505a1be3587d8d8388d8ab95d
baseline version:
xtf ee3e2656886a3bfdee19c73d3ab9e8589c05af12
Last test of basis 103758 2016-12-19 18:49:12 Z 34 days
Testing same since 104606 2017-01-23 11:46:13 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Jan Beulich
jobs:
build-amd64-xtf pass
build-amd64 pass
build-amd64-pvopspass
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xtf
+ revision=7e1bc8009286dcf505a1be3587d8d8388d8ab95d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xtf
7e1bc8009286dcf505a1be3587d8d8388d8ab95d
+ branch=xtf
+ revision=7e1bc8009286dcf505a1be3587d8d8388d8ab95d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xtf
+ xenbranch=xen-unstable
+ '[' xxtf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x7e1bc8009286dcf505a1be3587d8d8388d8ab95d = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux
Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map
>
> +static int __init modify_identity_mmio(struct domain *d, unsigned long pfn,
> + unsigned long nr_pages, bool map)
> +{
> +int rc;
> +
> +for ( ; ; )
> +{
> +rc = (map ? map_mmio_regions : unmap_mmio_regions)
This can be taken outside the loop.
-boris
> + (d, _gfn(pfn), nr_pages, _mfn(pfn));
> +if ( rc == 0 )
> +break;
> +if ( rc < 0 )
> +{
> +printk(XENLOG_WARNING
> + "Failed to identity %smap [%#lx,%#lx) for d%d: %d\n",
> + map ? "" : "un", pfn, pfn + nr_pages, d->domain_id, rc);
> +break;
> +}
> +nr_pages -= rc;
> +pfn += rc;
> +process_pending_softirqs();
> +}
> +
> +return rc;
> +}
> +
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] PVH CPU hotplug design document
On 01/23/2017 05:35 AM, Jan Beulich wrote: On 22.01.17 at 19:39, wrote: >> On 01/18/2017 08:25 AM, Jan Beulich wrote: >> On 18.01.17 at 12:54, wrote: So, would it be fine to start a PVH Dom0 with as many vCPUs as what's returned from dom0_max_vcpus, and mark them as enabled in the MADT. That's basically all we need in order to match current PV Dom0 functionality? >>> Yes, I think so. >> >> Have we then decided that we are not supporting ACPI hotplug for both >> dom0 and domU? > I don't think anything has been decided yet, it's just that the road to > (consistent) ACPI hotplug support still seems somewhat cloudy, so > getting there (if we're convinced this is a worthwhile goal) may still > take some time. I am mostly interested in domU support at this point. This is the only feature that I can think of right now that blocks domU support in Linux. As I said in an earlier message I don't think dom0 needs ACPI hotplug (or hotplug at all) while domU would benefit from it. But perhaps by "consistent" you meant that you prefer both to behave in the same manner. From Linux perspective one option could be to have domU with PV-style vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when it becomes available. This, however, will need an indication from the hypervisor. We could, for example, set ACPI_FADT_HW_REDUCED, as we discussed earlier. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support
On Mon, Jan 23, 2017 at 02:08:58PM +0100, Daniel Kiper wrote: > On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote: > > On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote: > > > On 1/19/17 8:34 PM, Daniel Kiper wrote: > > > > Hi, > > > > > > > > I am sending twelfth version of multiboot2 protocol support for > > > > legacy BIOS and EFI platforms. This patch series release contains > > > > fixes for all known/confirmed issues. > > > > > > With my fix to efi_multiboot2() in 5/10 and the entire series applied, I > > > get the following on some of the systems I have access to: Both me and Daniel seem to have test machines with EFI that are not soo .. defective. Could you mention which boxes have these kinds of trouble so we can get to the bottom of this? [Is it by any chance a T420 or x230 laptop - I am using legacy BIOS on them as I couldn't even get them to suspend properly] And would it be possible to get serial/power access to this box (Intel NUC?) to figure out what is going on? Thanks! .. snip.. > Once you told me that you applied some patches on top of my patch series to > get > it working. Is it still true? If you still use some extra patches could you > send > me them? What about ExitBootServices() call? Did you disabled it? If yes on > which > machines it have to be disabled? > > Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [linux-linus test] 104237: regressions - FAIL
On 01/23/2017 07:16 AM, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [linux-linus test] 104237: regressions -
> FAIL"):
>> I'm inclined to increasing the timeout, although this slowness does
>> mean that our tests may be blocked more than we would like.
> I have set the host property which I think will cause the timeout to
> be increased. This should take effect for the next run of
> linux-linus.
Thanks.
And it looks like x86 tests passed this morning so presumably the SCSI
patch indeed fixed the problems.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 05/14] x86/cpuid: Handle leaf 0x80000001 in guest_cpuid()
Intel reserve eax and ebx, while AMD duplicates eax from the low
family/model/stepping leaf. For AMD, ebx contains further brand/package
information which is left as the toolstack chooses (other than bits 27:16
which are reserved).
While moving the dynamic adjustments from the legacy path, simplify the shadow
PSE36 adjustment. PAE paging is a prerequisite for enabling long mode, making
the long mode check redundant; the case where it doesn't get short circuited
is the case where it is architecturally 0. Make the same adjustment to the
leaf 1 legacy path.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* New
---
xen/arch/x86/cpuid.c| 107 ++--
xen/include/asm-x86/cpuid.h | 2 +-
2 files changed, 55 insertions(+), 54 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 7af5900..c06b5a6 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -177,6 +177,8 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.vendor_ebx = 0;
p->extd.vendor_ecx = 0;
p->extd.vendor_edx = 0;
+
+p->extd.raw[0x1].a = p->extd.raw[0x1].b = 0;
break;
case X86_VENDOR_AMD:
@@ -187,6 +189,8 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.vendor_ecx = p->basic.vendor_ecx;
p->extd.vendor_edx = p->basic.vendor_edx;
+p->extd.raw_fms = p->basic.raw_fms;
+p->extd.raw[0x1].b &= 0xff00;
p->extd.e1d |= p->basic._1d & CPUID_COMMON_1D_FEATURES;
break;
}
@@ -672,24 +676,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
res->a = (res->a & ~0xff) | 3;
break;
-case 0x8001:
-res->c = p->extd.e1c;
-res->d = p->extd.e1d;
-
-/*
- * MTRR used to unconditionally leak into PV guests. They cannot MTRR
- * infrastructure at all, and shouldn't be able to see the feature.
- *
- * Modern PVOPS Linux self-clobbers the MTRR feature, to avoid trying
- * to use the associated MSRs. Xenolinux-based PV dom0's however use
- * the MTRR feature as an indication of the presence of the
- * XENPF_{add,del,read}_memtype hypercalls.
- */
-if ( is_hardware_domain(currd) && cpu_has_mtrr &&
- guest_kernel_mode(curr, guest_cpu_user_regs()) )
-res->d |= cpufeat_mask(X86_FEATURE_MTRR);
-break;
-
case 0x8007:
res->d = p->extd.e7d;
break;
@@ -712,7 +698,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
-case 0x8000:
+case 0x8000 ... 0x8001:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -760,7 +746,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
* a 32bit guest doesn't get the impression that it could try to use
* PSE36 paging.
*/
-if ( !hap_enabled(d) && !(hvm_pae_enabled(v) ||
hvm_long_mode_enabled(v)) )
+if ( !hap_enabled(d) && !hvm_pae_enabled(v) )
res->d &= ~cpufeat_mask(X86_FEATURE_PSE36);
if ( vpmu_enabled(v) &&
@@ -792,37 +778,6 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
res->a = (res->a & ~0xff) | 3;
break;
-case 0x8001:
-res->c = p->extd.e1c;
-res->d = p->extd.e1d;
-
-/* fast-forward MSR_APIC_BASE.EN if it hasn't already been clobbered.
*/
-if ( vlapic_hw_disabled(vcpu_vlapic(v)) )
-res->d &= ~cpufeat_bit(X86_FEATURE_APIC);
-
-/*
- * PSE36 is not supported in shadow mode. This bit should be
- * unilaterally cleared.
- *
- * However, an unspecified version of Hyper-V from 2011 refuses
- * to start as the "cpu does not provide required hw features" if
- * it can't see PSE36.
- *
- * As a workaround, leak the toolstack-provided PSE36 value into a
- * shadow guest if the guest is already using PAE paging (and won't
- * care about reverting back to PSE paging). Otherwise, knoble it, so
- * a 32bit guest doesn't get the impression that it could try to use
- * PSE36 paging.
- */
-if ( !hap_enabled(d) && !(hvm_pae_enabled(v) ||
hvm_long_mode_enabled(v)) )
-res->d &= ~cpufeat_mask(X86_FEATURE_PSE36);
-
-/* SYSCALL is hidden outside of long mode on Intel. */
-if ( p->x86_vendor == X86_VENDOR_INTEL && !hvm_long_mode_enabled(v) )
-res->d &= ~cpufeat_mask(X86_FEATURE_SYSCALL);
-
-break;
-
case 0x8007:
res->d = p->extd.e7d;
break;
@@ -860,7 +815,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
case 0x2 ... 0x3:
[Xen-devel] [PATCH v2 03/14] x86/cpuid: Only recalculate the shared feature bits once
With accurate vendor information available, the shared bits can be sorted out
during recalculation, rather than at query time in the legacy cpuid path.
This means that:
* Duplication can be dropped from the automatically generated cpuid data.
* The toolstack need not worry about setting them appropriately.
* They can be dropped from the system maximum featuresets.
While editing gen-cpuid.py, reflow some comments which exceeded the expected
line length.
Signed-off-by: Andrew Cooper
Reviewed-by: Doug Goldstein
Acked-by: Wei Liu
Reviewed-by: Jan Beulich
---
tools/libxc/xc_cpuid_x86.c | 19 ---
xen/arch/x86/cpuid.c | 25 +
xen/tools/gen-cpuid.py | 29 ++---
3 files changed, 15 insertions(+), 58 deletions(-)
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 96d6025..918590f 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -41,7 +41,6 @@ enum {
#define DEF_MAX_BASE 0x000du
#define DEF_MAX_INTELEXT 0x8008u
#define DEF_MAX_AMDEXT0x801cu
-#define COMMON_1D CPUID_COMMON_1D_FEATURES
int xc_get_cpu_levelling_caps(xc_interface *xch, uint32_t *caps)
{
@@ -712,24 +711,6 @@ static void sanitise_featureset(struct cpuid_domain_info
*info)
disabled_features[i] &= ~dfs[i];
}
}
-
-switch ( info->vendor )
-{
-case VENDOR_INTEL:
-/* Intel clears the common bits in e1d. */
-info->featureset[featureword_of(X86_FEATURE_SYSCALL)] &= ~COMMON_1D;
-break;
-
-case VENDOR_AMD:
-/* AMD duplicates the common bits between 1d and e1d. */
-info->featureset[featureword_of(X86_FEATURE_SYSCALL)] =
-((info->featureset[featureword_of(X86_FEATURE_FPU)] & COMMON_1D) |
- (info->featureset[featureword_of(X86_FEATURE_SYSCALL)] &
~COMMON_1D));
-break;
-
-default:
-break;
-}
}
int xc_cpuid_apply_policy(xc_interface *xch, domid_t domid,
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 3f398b5..87ec02f 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -67,18 +67,6 @@ static void sanitise_featureset(uint32_t *fs)
disabled_features[j] &= ~dfs[j];
}
}
-
-/*
- * Sort out shared bits. We are constructing a featureset which needs to
- * be applicable to a cross-vendor case. Intel strictly clears the common
- * bits in e1d, while AMD strictly duplicates them.
- *
- * We duplicate them here to be compatible with AMD while on Intel, and
- * rely on logic closer to the guest to make the featureset stricter if
- * emulating Intel.
- */
-fs[FEATURESET_e1d] = ((fs[FEATURESET_1d] & CPUID_COMMON_1D_FEATURES) |
- (fs[FEATURESET_e1d] & ~CPUID_COMMON_1D_FEATURES));
}
static void recalculate_xstate(struct cpuid_policy *p)
@@ -169,6 +157,8 @@ static void recalculate_xstate(struct cpuid_policy *p)
*/
static void recalculate_misc(struct cpuid_policy *p)
{
+p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
+
switch ( p->x86_vendor )
{
case X86_VENDOR_INTEL:
@@ -181,6 +171,8 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.vendor_ebx = p->basic.vendor_ebx;
p->extd.vendor_ecx = p->basic.vendor_ecx;
p->extd.vendor_edx = p->basic.vendor_edx;
+
+p->extd.e1d |= p->basic._1d & CPUID_COMMON_1D_FEATURES;
break;
}
}
@@ -669,10 +661,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
res->c = p->extd.e1c;
res->d = p->extd.e1d;
-/* If not emulating AMD, clear the duplicated features in e1d. */
-if ( p->x86_vendor != X86_VENDOR_AMD )
-res->d &= ~CPUID_COMMON_1D_FEATURES;
-
/*
* MTRR used to unconditionally leak into PV guests. They cannot MTRR
* infrastructure at all, and shouldn't be able to see the feature.
@@ -792,11 +780,8 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
res->c = p->extd.e1c;
res->d = p->extd.e1d;
-/* If not emulating AMD, clear the duplicated features in e1d. */
-if ( p->x86_vendor != X86_VENDOR_AMD )
-res->d &= ~CPUID_COMMON_1D_FEATURES;
/* fast-forward MSR_APIC_BASE.EN if it hasn't already been clobbered.
*/
-else if ( vlapic_hw_disabled(vcpu_vlapic(v)) )
+if ( vlapic_hw_disabled(vcpu_vlapic(v)) )
res->d &= ~cpufeat_bit(X86_FEATURE_APIC);
/*
diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
index 6212e4f..5cab6db 100755
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -129,16 +129,7 @@ def crunch_numbers(state):
common_1d = (FPU, VME, DE, PSE, TSC, MSR, PAE, MCE, CX8, APIC,
MTRR, PGE, MCA, CMOV, PAT, PSE36, MMX, FXSR)
-# All known features. Duplicate the common features in e1d
-
[Xen-devel] [PATCH v2 09/14] x86/cpuid: Handle leaf 0x80000009 in guest_cpuid()
Leaf 0x8009 is reserved. Signed-off-by: Andrew Cooper --- CC: Jan Beulich v2: * New --- xen/arch/x86/cpuid.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c index 4d48552..a8dce40 100644 --- a/xen/arch/x86/cpuid.c +++ b/xen/arch/x86/cpuid.c @@ -206,6 +206,8 @@ static void recalculate_misc(struct cpuid_policy *p) p->extd.raw[0x8].a &= 0x00ff; p->extd.raw[0x8].c &= 0x0003f0ff; + +p->extd.raw[0x9] = EMPTY_LEAF; break; } } @@ -712,7 +714,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res) case 0x2 ... 0x3: case 0x7 ... 0x9: case 0xc ... XSTATE_CPUID: -case 0x8000 ... 0x8008: +case 0x8000 ... 0x8009: ASSERT_UNREACHABLE(); /* Now handled in guest_cpuid(). */ } @@ -808,7 +810,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res) case 0x2 ... 0x3: case 0x7 ... 0x9: case 0xc ... XSTATE_CPUID: -case 0x8000 ... 0x8008: +case 0x8000 ... 0x8009: ASSERT_UNREACHABLE(); /* Now handled in guest_cpuid(). */ } @@ -891,7 +893,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf, default: goto legacy; -case 0x8000 ... 0x8008: +case 0x8000 ... 0x8009: *res = p->extd.raw[leaf & 0x]; break; } -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 08/14] x86/cpuid: Handle leaf 0x80000008 in guest_cpuid()
The entirety of edx is reserved.
Intel only defines the lower 16 bits of eax, although ebx is covered by the
featureset ABI, so left unclobbered.
AMD uses 24 bits in eax, although nothing thus far has ever exposed a non-zero
guest maxphysaddr to HVM guests. ecx contains some reserved bits, and several
pieces of static topology information, which are left as the toolstack
chooses.
A side effect of the common recalculation of maxlinaddr is that 32bit PV
guests see a maximum linear address of 32, which is consistent with the hiding
of other long mode information from them.
Finally, the call to guest_cpuid() in mtrr_var_range_msr_set() (introduced in
c/s fff8160a) can be dropped, now that maxphysaddr can be read straight out of
the cpuid_policy block.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* New
---
xen/arch/x86/cpuid.c| 45 -
xen/arch/x86/hvm/mtrr.c | 7 +--
xen/include/asm-x86/cpuid.h | 2 +-
3 files changed, 22 insertions(+), 32 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 3338045..4d48552 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -170,6 +170,8 @@ static void recalculate_misc(struct cpuid_policy *p)
/* Most of Power/RAS hidden from guests. */
p->extd.raw[0x7].a = p->extd.raw[0x7].b = p->extd.raw[0x7].c = 0;
+p->extd.raw[0x8].d = 0;
+
switch ( p->x86_vendor )
{
case X86_VENDOR_INTEL:
@@ -185,6 +187,9 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.raw[0x5] = EMPTY_LEAF;
p->extd.raw[0x6].a = p->extd.raw[0x6].b = p->extd.raw[0x6].d = 0;
+
+p->extd.raw[0x8].a &= 0x;
+p->extd.raw[0x8].c = 0;
break;
case X86_VENDOR_AMD:
@@ -198,6 +203,9 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.raw_fms = p->basic.raw_fms;
p->extd.raw[0x1].b &= 0xff00;
p->extd.e1d |= p->basic._1d & CPUID_COMMON_1D_FEATURES;
+
+p->extd.raw[0x8].a &= 0x00ff;
+p->extd.raw[0x8].c &= 0x0003f0ff;
break;
}
}
@@ -469,6 +477,15 @@ void recalculate_cpuid_policy(struct domain *d)
special_features[FEATURESET_7b0]);
cpuid_featureset_to_policy(fs, p);
+
+p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
+p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
+d->arch.paging.gfn_bits + PAGE_SHIFT);
+p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr,
+(p->basic.pae || p->basic.pse36) ? 36 : 32);
+
+p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
+
recalculate_xstate(p);
recalculate_misc(p);
}
@@ -682,11 +699,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
res->a = (res->a & ~0xff) | 3;
break;
-case 0x8008:
-res->a = paddr_bits | (vaddr_bits << 8);
-res->b = p->extd.e8b;
-break;
-
case 0x0005: /* MONITOR/MWAIT */
case 0x000b: /* Extended Topology Enumeration */
case 0x800a: /* SVM revision and features */
@@ -700,7 +712,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x8007:
+case 0x8000 ... 0x8008:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -716,8 +728,6 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
switch ( leaf )
{
-unsigned int tmp;
-
case 0x1:
/* Fix up VLAPIC details. */
res->b &= 0x00FFu;
@@ -780,21 +790,6 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
res->a = (res->a & ~0xff) | 3;
break;
-case 0x8008:
-res->a &= 0xff;
-tmp = d->arch.paging.gfn_bits + PAGE_SHIFT;
-if ( res->a > tmp )
-res->a = tmp;
-
-tmp = (p->basic.pae || p->basic.pse36) ? 36 : 32;
-if ( res->a < tmp )
-res->a = tmp;
-
-res->a |= (p->extd.lm ? vaddr_bits : 32) << 8;
-
-res->b = p->extd.e8b;
-break;
-
case 0x801c:
if ( !cpu_has_svm )
{
@@ -813,7 +808,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x8007:
+case 0x8000 ... 0x8008:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -896,7 +891,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
default:
goto legacy;
-case 0x8000 ... 0x8007:
+case 0x8000 ... 0x8008:
*res = p->extd.raw[leaf & 0x];
break;
[Xen-devel] [PATCH v2 07/14] x86/cpuid: Handle leaves 0x80000005-7 in guest_cpuid()
Leaf 0x8005 contains L1 cache/TLB information, 0x8006 L2 & L3
cache/TLB information, and 0x8007 Power management information.
Intel reserves all of this information other than the L2 cache information,
and the ITSC bit from the power management leaf.
AMD passes all of the cache/TLB information through to the guest, while most
of of the power management information is explicitly clobbered by the
toolstack.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* New
---
xen/arch/x86/cpuid.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 9cea13c..3338045 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -167,6 +167,9 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
+/* Most of Power/RAS hidden from guests. */
+p->extd.raw[0x7].a = p->extd.raw[0x7].b = p->extd.raw[0x7].c = 0;
+
switch ( p->x86_vendor )
{
case X86_VENDOR_INTEL:
@@ -179,6 +182,9 @@ static void recalculate_misc(struct cpuid_policy *p)
p->extd.vendor_edx = 0;
p->extd.raw[0x1].a = p->extd.raw[0x1].b = 0;
+
+p->extd.raw[0x5] = EMPTY_LEAF;
+p->extd.raw[0x6].a = p->extd.raw[0x6].b = p->extd.raw[0x6].d = 0;
break;
case X86_VENDOR_AMD:
@@ -676,10 +682,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
res->a = (res->a & ~0xff) | 3;
break;
-case 0x8007:
-res->d = p->extd.e7d;
-break;
-
case 0x8008:
res->a = paddr_bits | (vaddr_bits << 8);
res->b = p->extd.e8b;
@@ -698,7 +700,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x8004:
+case 0x8000 ... 0x8007:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -778,10 +780,6 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
res->a = (res->a & ~0xff) | 3;
break;
-case 0x8007:
-res->d = p->extd.e7d;
-break;
-
case 0x8008:
res->a &= 0xff;
tmp = d->arch.paging.gfn_bits + PAGE_SHIFT;
@@ -815,7 +813,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x8004:
+case 0x8000 ... 0x8007:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -898,7 +896,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
default:
goto legacy;
-case 0x8000 ... 0x8004:
+case 0x8000 ... 0x8007:
*res = p->extd.raw[leaf & 0x];
break;
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 00/14] x86/cpuid: Handling of simple leaves in guest_cpuid()
The series has been extended substantially, and now handles the entire extd union in the guest_cpuid() path. Andrew Cooper (14): x86/cpufeatures: Expose self-snoop to all guests x86/cpuid: Handle leaf 0x8000 in guest_cpuid() x86/cpuid: Only recalculate the shared feature bits once x86/cpuid: Handle more simple Intel leaves in guest_cpuid() x86/cpuid: Handle leaf 0x8001 in guest_cpuid() x86/cpuid: Handle the long vendor string in guest_cpuid() x86/cpuid: Handle leaves 0x8005-7 in guest_cpuid() x86/cpuid: Handle leaf 0x8008 in guest_cpuid() x86/cpuid: Handle leaf 0x8009 in guest_cpuid() x86/cpuid: Handle leaf 0x800a in guest_cpuid() x86/cpuid: Handle leaves 0x800b-1a in guest_cpuid() x86/cpufeatures: Hide Instruction Based Sampling from guests x86/cpuid: Handle leaf 0x801c in guest_cpuid() x86/cpuid: Remove the legacy path handling extd leaves tools/libxc/xc_cpuid_x86.c | 21 +- xen/arch/x86/cpuid.c| 307 xen/arch/x86/hvm/mtrr.c | 7 +- xen/arch/x86/hvm/svm/svm.c | 5 +- xen/include/asm-x86/cpuid.h | 17 +- xen/include/public/arch-x86/cpufeatureset.h | 3 +- xen/tools/gen-cpuid.py | 29 +-- 7 files changed, 205 insertions(+), 184 deletions(-) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 01/14] x86/cpufeatures: Expose self-snoop to all guests
Self-snoop describes a property of the CPU cache behaviour, which FreeBSD uses to optimise its cache flushing algorithm. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné v2: * New --- xen/include/public/arch-x86/cpufeatureset.h | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h index 306200b..70f1e30 100644 --- a/xen/include/public/arch-x86/cpufeatureset.h +++ b/xen/include/public/arch-x86/cpufeatureset.h @@ -114,6 +114,7 @@ XEN_CPUFEATURE(MMX, 0*32+23) /*A Multimedia Extensions */ XEN_CPUFEATURE(FXSR, 0*32+24) /*A FXSAVE and FXRSTOR instructions */ XEN_CPUFEATURE(SSE, 0*32+25) /*A Streaming SIMD Extensions */ XEN_CPUFEATURE(SSE2, 0*32+26) /*A Streaming SIMD Extensions-2 */ +XEN_CPUFEATURE(SS,0*32+27) /*A CPU self snoop */ XEN_CPUFEATURE(HTT, 0*32+28) /*!A Hyper-Threading Technology */ XEN_CPUFEATURE(TM1, 0*32+29) /* Thermal Monitor 1 */ XEN_CPUFEATURE(PBE, 0*32+31) /* Pending Break Enable */ -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 04/14] x86/cpuid: Handle more simple Intel leaves in guest_cpuid()
Intel now document leaf 2 as a plain leaf, with %al always containing the
value 0x01. Collect this leaf normally in calculate_raw_policy() and expose
it to guests. The leaf is reserved by AMD.
Intel leaves 3 and 9 (PSN and DCA respectively) are not exposed to guests at
all. They are reserved by AMD.
Leaves 8 and 0xc are reserved by both vendors.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* New
---
xen/arch/x86/cpuid.c| 32 ++--
xen/include/asm-x86/cpuid.h | 3 +++
2 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 87ec02f..7af5900 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -17,6 +17,11 @@ static const uint32_t hvm_hap_featuremask[] =
INIT_HVM_HAP_FEATURES;
static const uint32_t deep_features[] = INIT_DEEP_FEATURES;
#define EMPTY_LEAF ((struct cpuid_leaf){})
+static void zero_leaves(struct cpuid_leaf *l,
+unsigned int first, unsigned int last)
+{
+memset(&l[first], 0, sizeof(*l) * (last - first + 1));
+}
struct cpuid_policy __read_mostly raw_policy,
__read_mostly host_policy,
@@ -153,21 +158,31 @@ static void recalculate_xstate(struct cpuid_policy *p)
/*
* Misc adjustments to the policy. Mostly clobbering reserved fields and
- * duplicating shared fields.
+ * duplicating shared fields. Intentionally hidden fields are annotated.
*/
static void recalculate_misc(struct cpuid_policy *p)
{
+p->basic.raw[0x8] = EMPTY_LEAF;
+p->basic.raw[0xc] = EMPTY_LEAF;
+
p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
switch ( p->x86_vendor )
{
case X86_VENDOR_INTEL:
+p->basic.l2_nr_queries = 1; /* Fixed to 1 query. */
+p->basic.raw[0x3] = EMPTY_LEAF; /* PSN - always hidden. */
+p->basic.raw[0x9] = EMPTY_LEAF; /* DCA - always hidden. */
+
p->extd.vendor_ebx = 0;
p->extd.vendor_ecx = 0;
p->extd.vendor_edx = 0;
break;
case X86_VENDOR_AMD:
+zero_leaves(p->basic.raw, 0x2, 0x3);
+p->basic.raw[0x9] = EMPTY_LEAF;
+
p->extd.vendor_ebx = p->basic.vendor_ebx;
p->extd.vendor_ecx = p->basic.vendor_ecx;
p->extd.vendor_edx = p->basic.vendor_edx;
@@ -188,7 +203,7 @@ static void __init calculate_raw_policy(void)
{
switch ( i )
{
-case 0x2: case 0x4: case 0x7: case 0xd:
+case 0x4: case 0x7: case 0xd:
/* Multi-invocation leaves. Deferred. */
continue;
}
@@ -694,8 +709,9 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
break;
case 0x0:
-case 0x7:
-case XSTATE_CPUID:
+case 0x2 ... 0x3:
+case 0x7 ... 0x9:
+case 0xc ... XSTATE_CPUID:
case 0x8000:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
@@ -841,8 +857,9 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
break;
case 0x0:
-case 0x7:
-case XSTATE_CPUID:
+case 0x2 ... 0x3:
+case 0x7 ... 0x9:
+case 0xc ... XSTATE_CPUID:
case 0x8000:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
@@ -894,6 +911,9 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
goto legacy;
case 0x0:
+case 0x2 ... 0x3:
+case 0x8 ... 0x9:
+case 0xc:
*res = p->basic.raw[leaf];
break;
}
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index 4712b73..a15270a 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -115,6 +115,9 @@ struct cpuid_policy
uint32_t _1d;
struct { DECL_BITFIELD(1d); };
};
+
+/* Leaf 0x2 - TLB/Cache/Prefetch. */
+uint8_t l2_nr_queries; /* Documented as fixed to 1. */
};
} basic;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 06/14] x86/cpuid: Handle the long vendor string in guest_cpuid()
Leaves 0x8002 through 0x8004 are plain ASCII text, and are left exactly as the toolstack chooses. Signed-off-by: Andrew Cooper Reviewed-by: Doug Goldstein Reviewed-by: Jan Beulich --- v2: * Rebased, but no significant changes --- xen/arch/x86/cpuid.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c index c06b5a6..9cea13c 100644 --- a/xen/arch/x86/cpuid.c +++ b/xen/arch/x86/cpuid.c @@ -698,7 +698,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res) case 0x2 ... 0x3: case 0x7 ... 0x9: case 0xc ... XSTATE_CPUID: -case 0x8000 ... 0x8001: +case 0x8000 ... 0x8004: ASSERT_UNREACHABLE(); /* Now handled in guest_cpuid(). */ } @@ -815,7 +815,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res) case 0x2 ... 0x3: case 0x7 ... 0x9: case 0xc ... XSTATE_CPUID: -case 0x8000 ... 0x8001: +case 0x8000 ... 0x8004: ASSERT_UNREACHABLE(); /* Now handled in guest_cpuid(). */ } @@ -898,7 +898,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf, default: goto legacy; -case 0x8000 ... 0x8001: +case 0x8000 ... 0x8004: *res = p->extd.raw[leaf & 0x]; break; } -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 02/14] x86/cpuid: Handle leaf 0x80000000 in guest_cpuid()
The calculations for p->extd.max_leaf are reworked to force a value of at
least 0x8000, and to take the domains chosen vendor into account when
clamping maximum value.
The high short vendor information is clobbered or duplicated according to the
chosen vendor.
As a side effect of handing out an audited max_leaf value, the 0x801e case
can be dropped from pv_cpuid(), as it outside of the visible range.
Signed-off-by: Andrew Cooper
Reviewed-by: Doug Goldstein
Reviewed-by: Jan Beulich
---
v2:
* Drop 0x801e from pv_cpuid()
* s/recalculate_common/recalculate_misc/
---
xen/arch/x86/cpuid.c| 53 +++--
xen/include/asm-x86/cpuid.h | 6 ++---
2 files changed, 49 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 85c829d..3f398b5 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -163,6 +163,28 @@ static void recalculate_xstate(struct cpuid_policy *p)
}
}
+/*
+ * Misc adjustments to the policy. Mostly clobbering reserved fields and
+ * duplicating shared fields.
+ */
+static void recalculate_misc(struct cpuid_policy *p)
+{
+switch ( p->x86_vendor )
+{
+case X86_VENDOR_INTEL:
+p->extd.vendor_ebx = 0;
+p->extd.vendor_ecx = 0;
+p->extd.vendor_edx = 0;
+break;
+
+case X86_VENDOR_AMD:
+p->extd.vendor_ebx = p->basic.vendor_ebx;
+p->extd.vendor_ecx = p->basic.vendor_ecx;
+p->extd.vendor_edx = p->basic.vendor_edx;
+break;
+}
+}
+
static void __init calculate_raw_policy(void)
{
struct cpuid_policy *p = &raw_policy;
@@ -227,12 +249,12 @@ static void __init calculate_host_policy(void)
min_t(uint32_t, p->basic.max_leaf, ARRAY_SIZE(p->basic.raw) - 1);
p->feat.max_subleaf =
min_t(uint32_t, p->feat.max_subleaf, ARRAY_SIZE(p->feat.raw) - 1);
-p->extd.max_leaf =
-min_t(uint32_t, p->extd.max_leaf,
- 0x8000u + ARRAY_SIZE(p->extd.raw) - 1);
+p->extd.max_leaf = 0x8000 | min_t(uint32_t, p->extd.max_leaf & 0x,
+ ARRAY_SIZE(p->extd.raw) - 1);
cpuid_featureset_to_policy(boot_cpu_data.x86_capability, p);
recalculate_xstate(p);
+recalculate_misc(p);
}
static void __init calculate_pv_max_policy(void)
@@ -360,7 +382,10 @@ void recalculate_cpuid_policy(struct domain *d)
p->basic.max_leaf = min(p->basic.max_leaf, max->basic.max_leaf);
p->feat.max_subleaf = min(p->feat.max_subleaf, max->feat.max_subleaf);
-p->extd.max_leaf= min(p->extd.max_leaf,max->extd.max_leaf);
+p->extd.max_leaf= 0x8000 | min(p->extd.max_leaf & 0x,
+ (p->x86_vendor == X86_VENDOR_AMD
+? CPUID_GUEST_NR_EXTD_AMD
+: CPUID_GUEST_NR_EXTD_INTEL) - 1);
cpuid_policy_to_featureset(p, fs);
cpuid_policy_to_featureset(max, max_fs);
@@ -428,6 +453,7 @@ void recalculate_cpuid_policy(struct domain *d)
cpuid_featureset_to_policy(fs, p);
recalculate_xstate(p);
+recalculate_misc(p);
}
int init_domain_cpuid_policy(struct domain *d)
@@ -675,7 +701,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
case 0x800a: /* SVM revision and features */
case 0x801b: /* Instruction Based Sampling */
case 0x801c: /* Light Weight Profiling */
-case 0x801e: /* Extended topology reporting */
unsupported:
*res = EMPTY_LEAF;
break;
@@ -683,6 +708,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
case 0x0:
case 0x7:
case XSTATE_CPUID:
+case 0x8000:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -832,6 +858,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
case 0x0:
case 0x7:
case XSTATE_CPUID:
+case 0x8000:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -901,9 +928,21 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
return cpuid_hypervisor_leaves(v, leaf, subleaf, res);
case 0x8000 ... 0x8000 + CPUID_GUEST_NR_EXTD - 1:
-if ( leaf > p->extd.max_leaf )
+ASSERT((p->extd.max_leaf & 0x) < ARRAY_SIZE(p->extd.raw));
+if ( (leaf & 0x) > min_t(uint32_t, p->extd.max_leaf & 0x,
+ ARRAY_SIZE(p->extd.raw) - 1) )
return;
-goto legacy;
+
+switch ( leaf )
+{
+default:
+goto legacy;
+
+case 0x8000:
+*res = p->extd.raw[leaf & 0x];
+break;
+}
+break;
default:
return;
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index 299a026..4712b73 100644
--- a/xen/inclu
Re: [Xen-devel] [PATCH 2/5] xen: credit2: never consider CPUs outside of our cpupool.
On Thu, Jan 19, 2017 at 8:08 AM, Juergen Gross wrote: > On 17/01/17 18:26, Dario Faggioli wrote: >> In fact, relying on the mask of what pCPUs belong to >> which Credit2 runqueue is not enough. If we only do that, >> when Credit2 is the boot scheduler, we may ASSERT() or >> panic when moving a pCPU from Pool-0 to another cpupool. >> >> This is because pCPUs outside of any pool are considered >> part of cpupool0. This puts us at risk of crash when those >> same pCPUs are added to another pool and something >> different than the idle domain is found to be running >> on them. >> >> Note that, even if we prevent the above to happen (which >> is the purpose of this patch), this is still pretty bad, >> in fact, when we remove a pCPU from Pool-0: >> - in Credit1, as we do *not* update prv->ncpus and >> prv->credit, which means we're considering the wrong >> total credits when doing accounting; >> - in Credit2, the pCPU remains part of one runqueue, >> and is hence at least considered during load balancing, >> even if no vCPU should really run there. >> >> In Credit1, this "only" causes skewed accounting and >> no crashes because there is a lot of `cpumask_and`ing >> going on with the cpumask of the domains' cpupool >> (which, BTW, comes at a price). >> >> A quick and not to involved (and easily backportable) >> solution for Credit2, is to do exactly the same. >> >> Signed-off-by: Dario Faggioli > --- >> Cc: George Dunlap >> Cc: Juergen Gross >> Cc: Jan Beulich >> --- >> This is a bugfix, and should be backported to 4.8. >> --- >> The proper solution would mean calling deinit_pdata() when removing a pCPU >> from >> cpupool0, as well as a bit more of code reshuffling. >> >> And, although worth doing, it certainly will take more work, more time, and >> will probably be hard (well, surely harder than this) to backport. >> >> Therefore, I'd argue in favor of both taking and backporting this change, >> which >> at least enables using Credit2 as default scheduler without risking a crash >> when creating a second cpupool. >> >> Afterwards, a proper solution would be proposed for Xen 4.9. >> >> Finally, given the wide number of issues similar to this that I've found and >> fixed in the last release cycle, I think it would be good to take a stab at >> whether the interface between cpupools and the schedulers could not be >> simplified. :-O > > The first patch version for support of cpupools I sent used an own > scheduler instance for the free cpus. Keir merged this instance with > the one for Pool-0. You mean he just made the change unilaterally without posting it to the list? I just went back and skimmed through the old cpupools threads and didn't see this discussed. Having a "cpupool-remove" operation that doesn't actually remove the cpu from the pool is a bit mad... -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/hvm: Conditionally leave CPUID Faulting active in HVM context
On 16/01/17 11:17, Andrew Cooper wrote:
> If the hardware supports faulting, and the guest has chosen to use it, leave
> faulting active in HVM context.
>
> It is more efficient to have hardware convert CPUID to a #GP fault (which we
> don't intercept), than to take a VMExit and have Xen re-inject a #GP fault.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Jun Nakajima
> CC: Kevin Tian
Ping VT-x ?
> ---
> xen/arch/x86/cpu/intel.c | 5 +++--
> xen/arch/x86/hvm/vmx/vmx.c | 12 ++--
> 2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
> index 2e11662..d0e380c 100644
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -175,8 +175,9 @@ static void intel_ctxt_switch_levelling(const struct vcpu
> *next)
>* generating the maximum full cpuid policy into Xen, at which
>* this problem will disappear.
>*/
> - set_cpuid_faulting(nextd && is_pv_domain(nextd) &&
> -!is_control_domain(nextd));
> + set_cpuid_faulting(nextd && !is_control_domain(nextd) &&
> +(is_pv_domain(nextd) ||
> + next->arch.cpuid_faulting));
> return;
> }
>
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 61925cf..19294cb 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2866,11 +2866,19 @@ static int vmx_msr_write_intercept(unsigned int msr,
> uint64_t msr_content)
> break;
>
> case MSR_INTEL_MISC_FEATURES_ENABLES:
> +{
> +bool old_cpuid_faulting = v->arch.cpuid_faulting;
> +
> if ( msr_content & ~MSR_MISC_FEATURES_CPUID_FAULTING )
> goto gp_fault;
> -v->arch.cpuid_faulting =
> -!!(msr_content & MSR_MISC_FEATURES_CPUID_FAULTING);
> +
> +v->arch.cpuid_faulting = msr_content &
> MSR_MISC_FEATURES_CPUID_FAULTING;
> +
> +if ( cpu_has_cpuid_faulting &&
> + (old_cpuid_faulting ^ v->arch.cpuid_faulting) )
> +ctxt_switch_levelling(v);
> break;
> +}
>
> default:
> if ( passive_domain_do_wrmsr(msr, msr_content) )
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [linux-next test] 104604: tolerable FAIL
flight 104604 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/104604/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: 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-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 17 guest-localmigrate/x10 fail baseline untested test-amd64-amd64-libvirt 15 guest-saverestore.2 fail baseline untested test-amd64-i386-libvirt-xsm 15 guest-saverestore.2 fail baseline untested test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10 fail baseline untested test-amd64-amd64-xl 17 guest-localmigrate/x10 fail baseline untested test-amd64-amd64-pair 22 guest-migrate/dst_host/src_host fail baseline untested test-amd64-i386-xl 17 guest-localmigrate/x10 fail baseline untested test-amd64-i386-xl-xsm 15 guest-localmigrate fail baseline untested test-amd64-i386-pair 22 guest-migrate/dst_host/src_host fail baseline untested test-amd64-amd64-xl-rtds 15 guest-localmigrate fail baseline untested test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail baseline untested build-armhf-pvops 5 kernel-buildfail baseline untested test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linuxf9dd6f6cc63cda037c932c5bfcc159343ae33120 jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopsfail build-i386-pvops pass build-amd64-rumprun pass build-i386-rumprun pass test-amd64-amd64-xl fail test-armhf-armhf-xl blocked test-amd64-i386-xl fail test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm blocked test-amd64-i386-libvirt-xsm fail test-amd64-amd64-x
Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map
On Mon, Jan 23, 2017 at 09:11:06AM -0500, Boris Ostrovsky wrote:
>
> >
> > +static int __init modify_identity_mmio(struct domain *d, unsigned long pfn,
> > + unsigned long nr_pages, bool map)
> > +{
> > +int rc;
> > +
> > +for ( ; ; )
> > +{
> > +rc = (map ? map_mmio_regions : unmap_mmio_regions)
>
> This can be taken outside the loop.
Maybe I can instead make map const, and the compiler should optimize this
itself?
I find it a little cumbersome to store function pointers, ie:
int (*mapf)(struct domain *, gfn_t, unsigned long, mfn_t) = ...;
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 10/14] x86/cpuid: Handle leaf 0x8000000a in guest_cpuid()
Leaf 0x800a contains SVM information. The feature choices are borrowed
straight from the libxc policy code.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* New
---
xen/arch/x86/cpuid.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index a8dce40..17738c8 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -282,6 +283,19 @@ static void __init calculate_host_policy(void)
cpuid_featureset_to_policy(boot_cpu_data.x86_capability, p);
recalculate_xstate(p);
recalculate_misc(p);
+
+if ( p->extd.svm )
+{
+/* Clamp to implemented features which require hardware support. */
+p->extd.raw[0xa].d &= ((1u << SVM_FEATURE_NPT) |
+ (1u << SVM_FEATURE_LBRV) |
+ (1u << SVM_FEATURE_NRIPS) |
+ (1u << SVM_FEATURE_PAUSEFILTER) |
+ (1u << SVM_FEATURE_DECODEASSISTS));
+/* Enable features which are always emulated. */
+p->extd.raw[0xa].d |= ((1u << SVM_FEATURE_VMCBCLEAN) |
+ (1u << SVM_FEATURE_TSCRATEMSR));
+}
}
static void __init calculate_pv_max_policy(void)
@@ -302,6 +316,8 @@ static void __init calculate_pv_max_policy(void)
sanitise_featureset(pv_featureset);
cpuid_featureset_to_policy(pv_featureset, p);
recalculate_xstate(p);
+
+p->extd.raw[0xa] = EMPTY_LEAF; /* No SVM for PV guests. */
}
static void __init calculate_hvm_max_policy(void)
@@ -490,6 +506,9 @@ void recalculate_cpuid_policy(struct domain *d)
recalculate_xstate(p);
recalculate_misc(p);
+
+if ( !p->extd.svm )
+p->extd.raw[0xa] = EMPTY_LEAF;
}
int init_domain_cpuid_policy(struct domain *d)
@@ -703,7 +722,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
case 0x0005: /* MONITOR/MWAIT */
case 0x000b: /* Extended Topology Enumeration */
-case 0x800a: /* SVM revision and features */
case 0x801b: /* Instruction Based Sampling */
case 0x801c: /* Light Weight Profiling */
unsupported:
@@ -714,7 +732,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x8009:
+case 0x8000 ... 0x800a:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -810,7 +828,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x8009:
+case 0x8000 ... 0x800a:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -893,7 +911,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
default:
goto legacy;
-case 0x8000 ... 0x8009:
+case 0x8000 ... 0x800a:
*res = p->extd.raw[leaf & 0x];
break;
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 11/14] x86/cpuid: Handle leaves 0x8000000b-1a in guest_cpuid()
Leaves 800b-18 are reserved. Leaf 8019 is 1G TLB information and leaf 0x801a is performance hints. These leaves have previously been hidden from guests, but are perfectly safe to expose. Update libxc to also expose these leaves. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Ian Jackson CC: Wei Liu v2: * New --- tools/libxc/xc_cpuid_x86.c | 2 ++ xen/arch/x86/cpuid.c | 8 +--- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c index 918590f..73a2ded 100644 --- a/tools/libxc/xc_cpuid_x86.c +++ b/tools/libxc/xc_cpuid_x86.c @@ -479,6 +479,8 @@ static void xc_cpuid_hvm_policy(xc_interface *xch, case 0x8005: /* AMD L1 cache/TLB info (dumped by Intel policy) */ case 0x8006: /* AMD L2/3 cache/TLB info ; Intel L2 cache features */ case 0x800a: /* AMD SVM feature bits */ +case 0x8019: /* AMD 1G TLB */ +case 0x801a: /* AMD perf hints */ case 0x801c: /* AMD lightweight profiling */ break; diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c index 17738c8..c75ba31 100644 --- a/xen/arch/x86/cpuid.c +++ b/xen/arch/x86/cpuid.c @@ -209,6 +209,8 @@ static void recalculate_misc(struct cpuid_policy *p) p->extd.raw[0x8].c &= 0x0003f0ff; p->extd.raw[0x9] = EMPTY_LEAF; + +zero_leaves(p->extd.raw, 0xb, 0x18); break; } } @@ -732,7 +734,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res) case 0x2 ... 0x3: case 0x7 ... 0x9: case 0xc ... XSTATE_CPUID: -case 0x8000 ... 0x800a: +case 0x8000 ... 0x801a: ASSERT_UNREACHABLE(); /* Now handled in guest_cpuid(). */ } @@ -828,7 +830,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res) case 0x2 ... 0x3: case 0x7 ... 0x9: case 0xc ... XSTATE_CPUID: -case 0x8000 ... 0x800a: +case 0x8000 ... 0x801a: ASSERT_UNREACHABLE(); /* Now handled in guest_cpuid(). */ } @@ -911,7 +913,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf, default: goto legacy; -case 0x8000 ... 0x800a: +case 0x8000 ... 0x801a: *res = p->extd.raw[leaf & 0x]; break; } -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 13/14] x86/cpuid: Handle leaf 0x8000001c in guest_cpuid()
Leaf 0x801c contains LWP information. edx contains hardware supported
features (and is clamped against the maximum), while ecx and ebx contain
various properties of the implementation. eax is entirely dynamic, depending
on xcr0 and MSR_LWP_CFG.
The call to guest_cpuid() in svm_update_lwp_cfg() can now be replaced by
reading the data straight out of the cpuid_policy block.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
---
xen/arch/x86/cpuid.c | 34 --
xen/arch/x86/hvm/svm/svm.c | 5 +
2 files changed, 17 insertions(+), 22 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index b9dcc71..78cd287 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -213,6 +213,8 @@ static void recalculate_misc(struct cpuid_policy *p)
zero_leaves(p->extd.raw, 0xb, 0x18);
p->extd.raw[0x1b] = EMPTY_LEAF; /* IBS - not supported. */
+
+p->extd.raw[0x1c].a = 0; /* LWP.a entirely dynamic. */
break;
}
}
@@ -513,6 +515,11 @@ void recalculate_cpuid_policy(struct domain *d)
if ( !p->extd.svm )
p->extd.raw[0xa] = EMPTY_LEAF;
+
+if ( p->extd.lwp )
+p->extd.raw[0x1c].d &= max->extd.raw[0x1c].d;
+else
+p->extd.raw[0x1c] = EMPTY_LEAF;
}
int init_domain_cpuid_policy(struct domain *d)
@@ -726,7 +733,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
case 0x0005: /* MONITOR/MWAIT */
case 0x000b: /* Extended Topology Enumeration */
-case 0x801c: /* Light Weight Profiling */
unsupported:
*res = EMPTY_LEAF;
break;
@@ -735,7 +741,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x801b:
+case 0x8000 ... 0x801c:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -813,25 +819,11 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
res->a = (res->a & ~0xff) | 3;
break;
-case 0x801c:
-if ( !cpu_has_svm )
-{
-*res = EMPTY_LEAF;
-break;
-}
-
-if ( cpu_has_lwp && (v->arch.xcr0 & XSTATE_LWP) )
-/* Turn on available bit and other features specified in lwp_cfg.
*/
-res->a = (res->d & v->arch.hvm_svm.guest_lwp_cfg) | 1;
-else
-res->a = 0;
-break;
-
case 0x0:
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x801b:
+case 0x8000 ... 0x801c:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -914,7 +906,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
default:
goto legacy;
-case 0x8000 ... 0x801b:
+case 0x8000 ... 0x801c:
*res = p->extd.raw[leaf & 0x];
break;
}
@@ -1024,6 +1016,12 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
res->d |= cpufeat_mask(X86_FEATURE_MTRR);
}
break;
+
+case 0x801c:
+if ( (v->arch.xcr0 & XSTATE_LWP) && cpu_has_svm )
+/* Turn on available bit and other features specified in lwp_cfg.
*/
+res->a = (res->d & v->arch.hvm_svm.guest_lwp_cfg) | 1;
+break;
}
/* Done. */
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index e8ef88d..01c7b58 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -931,13 +931,10 @@ static int svm_update_lwp_cfg(struct vcpu *v, uint64_t
msr_content)
if ( xsave_enabled(v) && cpu_has_lwp )
{
-struct cpuid_leaf res;
-
-guest_cpuid(v, 0x801c, 0, &res);
msr_low = (uint32_t)msr_content;
/* generate #GP if guest tries to turn on unsupported features. */
-if ( msr_low & ~res.d)
+if ( msr_low & ~v->domain->arch.cpuid->extd.raw[0x1c].d )
return -1;
v->arch.hvm_svm.guest_lwp_cfg = msr_content;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 12/14] x86/cpufeatures: Hide Instruction Based Sampling from guests
Xen advertises the IBS feature flag to guests on capable AMD hardware. However, the PV path in Xen, and both the PV and HVM paths in libxc deliberately clobber the IBS CPUID leaf. Furthermore, Xen has nothing providing an implementation of the IBS MSRs, so guests can't actually use the feature at all. Signed-off-by: Andrew Cooper --- CC: Jan Beulich v2: * New --- xen/arch/x86/cpuid.c| 9 + xen/include/public/arch-x86/cpufeatureset.h | 2 +- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c index c75ba31..b9dcc71 100644 --- a/xen/arch/x86/cpuid.c +++ b/xen/arch/x86/cpuid.c @@ -211,6 +211,8 @@ static void recalculate_misc(struct cpuid_policy *p) p->extd.raw[0x9] = EMPTY_LEAF; zero_leaves(p->extd.raw, 0xb, 0x18); + +p->extd.raw[0x1b] = EMPTY_LEAF; /* IBS - not supported. */ break; } } @@ -724,7 +726,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res) case 0x0005: /* MONITOR/MWAIT */ case 0x000b: /* Extended Topology Enumeration */ -case 0x801b: /* Instruction Based Sampling */ case 0x801c: /* Light Weight Profiling */ unsupported: *res = EMPTY_LEAF; @@ -734,7 +735,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res) case 0x2 ... 0x3: case 0x7 ... 0x9: case 0xc ... XSTATE_CPUID: -case 0x8000 ... 0x801a: +case 0x8000 ... 0x801b: ASSERT_UNREACHABLE(); /* Now handled in guest_cpuid(). */ } @@ -830,7 +831,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, struct cpuid_leaf *res) case 0x2 ... 0x3: case 0x7 ... 0x9: case 0xc ... XSTATE_CPUID: -case 0x8000 ... 0x801a: +case 0x8000 ... 0x801b: ASSERT_UNREACHABLE(); /* Now handled in guest_cpuid(). */ } @@ -913,7 +914,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf, default: goto legacy; -case 0x8000 ... 0x801a: +case 0x8000 ... 0x801b: *res = p->extd.raw[leaf & 0x]; break; } diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h index 70f1e30..97dd353 100644 --- a/xen/include/public/arch-x86/cpufeatureset.h +++ b/xen/include/public/arch-x86/cpufeatureset.h @@ -172,7 +172,7 @@ XEN_CPUFEATURE(SSE4A, 3*32+ 6) /*A SSE-4A */ XEN_CPUFEATURE(MISALIGNSSE, 3*32+ 7) /*A Misaligned SSE mode */ XEN_CPUFEATURE(3DNOWPREFETCH, 3*32+ 8) /*A 3DNow prefetch instructions */ XEN_CPUFEATURE(OSVW, 3*32+ 9) /* OS Visible Workaround */ -XEN_CPUFEATURE(IBS, 3*32+10) /*S Instruction Based Sampling */ +XEN_CPUFEATURE(IBS, 3*32+10) /* Instruction Based Sampling */ XEN_CPUFEATURE(XOP, 3*32+11) /*A extended AVX instructions */ XEN_CPUFEATURE(SKINIT,3*32+12) /* SKINIT/STGI instructions */ XEN_CPUFEATURE(WDT, 3*32+13) /* Watchdog timer */ -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 14/14] x86/cpuid: Remove the legacy path handling extd leaves
All leaves in the extd union are handled in guest_cpuid() now, so remove
legacy handling.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/cpuid.c| 14 +++---
xen/include/asm-x86/cpuid.h | 4 ++--
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 78cd287..d28735a 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -741,7 +741,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x801c:
+case 0x8000 ... 0x:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -823,7 +823,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf,
struct cpuid_leaf *res)
case 0x2 ... 0x3:
case 0x7 ... 0x9:
case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x801c:
+case 0x8000 ... 0x:
ASSERT_UNREACHABLE();
/* Now handled in guest_cpuid(). */
}
@@ -901,15 +901,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
ARRAY_SIZE(p->extd.raw) - 1) )
return;
-switch ( leaf )
-{
-default:
-goto legacy;
-
-case 0x8000 ... 0x801c:
-*res = p->extd.raw[leaf & 0x];
-break;
-}
+*res = p->extd.raw[leaf & 0x];
break;
default:
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index 6cc23aa..bc3fc7c 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -78,7 +78,7 @@ struct cpuid_policy
* Global *_policy objects:
*
* - Guest accurate:
- * - All of the feat and xstate unions
+ * - All of the feat, xstate and extd unions
* - max_{,sub}leaf
* - All FEATURESET_* words
* - Short vendor infomation
@@ -86,7 +86,7 @@ struct cpuid_policy
* Per-domain objects:
*
* - Guest accurate:
- * - All of the feat and xstate unions
+ * - All of the feat, xstate and extd unions
* - max_{,sub}leaf
* - All FEATURESET_* words
* - Short vendor infomation
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 11/14] x86/cpuid: Handle leaves 0x8000000b-1a in guest_cpuid()
On Mon, Jan 23, 2017 at 02:39:14PM +, Andrew Cooper wrote: > Leaves 800b-18 are reserved. Leaf 8019 is 1G TLB information and leaf > 0x801a is performance hints. These leaves have previously been hidden > from guests, but are perfectly safe to expose. > > Update libxc to also expose these leaves. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Ian Jackson > CC: Wei Liu > > v2: > * New > --- > tools/libxc/xc_cpuid_x86.c | 2 ++ > xen/arch/x86/cpuid.c | 8 +--- > 2 files changed, 7 insertions(+), 3 deletions(-) > > diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c > index 918590f..73a2ded 100644 > --- a/tools/libxc/xc_cpuid_x86.c > +++ b/tools/libxc/xc_cpuid_x86.c > @@ -479,6 +479,8 @@ static void xc_cpuid_hvm_policy(xc_interface *xch, > case 0x8005: /* AMD L1 cache/TLB info (dumped by Intel policy) */ > case 0x8006: /* AMD L2/3 cache/TLB info ; Intel L2 cache features */ > case 0x800a: /* AMD SVM feature bits */ > +case 0x8019: /* AMD 1G TLB */ > +case 0x801a: /* AMD perf hints */ Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf baseline-only test] 68421: tolerable trouble: blocked/broken
This run is configured for baseline tests only. flight 68421 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68421/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-i3863 host-install(3) broken baseline untested build-amd64 3 host-install(3) broken baseline untested build-i386-pvops 3 host-install(3) broken baseline untested build-i386-xsm3 host-install(3) broken baseline untested build-amd64-pvops 3 host-install(3) broken baseline untested build-amd64-xsm 3 host-install(3) broken baseline untested Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a version targeted for testing: ovmf f3fa35a00233b6f2e7653b3b8c3e2b28b8ecbe7f baseline version: ovmf 70420e31a04b56f99c1306e281434532a86bde70 Last test of basis68418 2017-01-22 17:46:43 Z0 days Testing same since68421 2017-01-23 07:19:58 Z0 days1 attempts People who touched revisions under test: Gary Lin Jiaxin Wu Thomas Huth Wu Jiaxin jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary broken-step build-i386 host-install(3) broken-step build-amd64 host-install(3) broken-step build-i386-pvops host-install(3) broken-step build-i386-xsm host-install(3) broken-step build-amd64-pvops host-install(3) broken-step build-amd64-xsm host-install(3) Push not applicable. commit f3fa35a00233b6f2e7653b3b8c3e2b28b8ecbe7f Author: Thomas Huth Date: Thu Jan 19 17:37:31 2017 +0800 NetworkPkg: Remove superfluous return statement. If the code eventually returns "Status" anyway, it does not make sense to explicitely return "Status" in case of an error, too. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Thomas Huth Reviewed-by: Wu Jiaxin commit 4b2fb7986d571827a6e4885377e531002d806681 Author: Jiaxin Wu Date: Thu Jan 19 11:53:08 2017 +0800 OvmfPkg: Allow HTTP connections if HTTP Boot enabled v2 * Move the setting above the "!ifndef $(USE_OLD_SHELL)" part. * Un-indent the setting to column zero. (Comments from Laszlo) Overwrite the value of PcdAllowHttpConnections to allow HTTP connections if HTTP Boot enabled (-D HTTP_BOOT_ENABLE). Cc: Laszlo Ersek Cc: Justen Jordan L Cc: Ye Ting Cc: Fu Siyuan Cc: Kinney Michael D Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin Reviewed-by: Ye Ting Reviewed-by: Fu Siyuan Reviewed-by: Gary Lin Tested-by: Gary Lin commit 7c3c53e5e8ee066904e56d9e6dd85dad4933f29e Author: Jiaxin Wu Date: Fri Jan 6 11:55:47 2017 +0800 Nt32Pkg.dsc: Add flag to control HTTP connections v3: * Correct the commits grammar v2: * Rename the flag. This flag is to overwrite the value of PcdAllowHttpConnections, then the platform can make a decision whether to allow HTTP connections or not. Cc: Ye Ting Cc: Fu Siyuan Cc: Ruiyu Ni Cc: Laszlo Ersek Cc: Kinney Michael D Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin Reviewed-by: Ye Ting Reviewed-by: Fu Siyuan Reviewed-by: Gary Lin commit 221463c2b337072532ed4ab8ffe3b566574724d8 Author: Jiaxin Wu Date: Fri Jan 6 11:53:57 2017 +0800 NetworkPkg: Add PCD to enable the HTTP connections switch
[Xen-devel] [ovmf test] 104607: all pass - PUSHED
flight 104607 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104607/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 223a99e524679a7f811755442897bfad7cf49830
baseline version:
ovmf 7cf59c854f35c9680965fe83e9cfd863079ddd73
Last test of basis 104603 2017-01-23 07:45:18 Z0 days
Testing same since 104607 2017-01-23 13:17:08 Z0 days1 attempts
People who touched revisions under test:
Nikolai SAOUKH
Nikolai SAOUKH
Yonghong Zhu
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=223a99e524679a7f811755442897bfad7cf49830
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
223a99e524679a7f811755442897bfad7cf49830
+ branch=ovmf
+ revision=223a99e524679a7f811755442897bfad7cf49830
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x223a99e524679a7f811755442897bfad7cf49830 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenb
[Xen-devel] [PATCH] xen-blkfront: feature flags handling adjustments
Don't truncate the "feature-persistent" value read from xenstore: Any non-zero value is supposed to enable the feature, just like is already being done for feature_secdiscard. Just like the other feature_* fields, feature_flush and feature_fua are boolean flags, and hence fit well into a single bit. Keep all bit fields together to limit gaps. Signed-off-by: Jan Beulich --- drivers/block/xen-blkfront.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) --- 4.10-rc5/drivers/block/xen-blkfront.c +++ 4.10-rc5-xen-blkfront-feature-flags/drivers/block/xen-blkfront.c @@ -197,13 +197,13 @@ struct blkfront_info /* Number of pages per ring buffer. */ unsigned int nr_ring_pages; struct request_queue *rq; - unsigned int feature_flush; - unsigned int feature_fua; + unsigned int feature_flush:1; + unsigned int feature_fua:1; unsigned int feature_discard:1; unsigned int feature_secdiscard:1; + unsigned int feature_persistent:1; unsigned int discard_granularity; unsigned int discard_alignment; - unsigned int feature_persistent:1; /* Number of 4KB segments handled */ unsigned int max_indirect_segments; int is_ready; @@ -2323,8 +2323,8 @@ static void blkfront_gather_backend_feat blkfront_setup_discard(info); info->feature_persistent = - xenbus_read_unsigned(info->xbdev->otherend, -"feature-persistent", 0); + !!xenbus_read_unsigned(info->xbdev->otherend, + "feature-persistent", 0); indirect_segments = xenbus_read_unsigned(info->xbdev->otherend, "feature-max-indirect-segments", 0); ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] PVH CPU hotplug design document
>>> On 23.01.17 at 15:28, wrote: > On 01/23/2017 05:35 AM, Jan Beulich wrote: > On 22.01.17 at 19:39, wrote: >>> On 01/18/2017 08:25 AM, Jan Beulich wrote: >>> On 18.01.17 at 12:54, wrote: > So, would it be fine to start a PVH Dom0 with as many vCPUs as what's > returned > from dom0_max_vcpus, and mark them as enabled in the MADT. That's > basically all > we need in order to match current PV Dom0 functionality? Yes, I think so. >>> >>> Have we then decided that we are not supporting ACPI hotplug for both >>> dom0 and domU? >> I don't think anything has been decided yet, it's just that the road to >> (consistent) ACPI hotplug support still seems somewhat cloudy, so >> getting there (if we're convinced this is a worthwhile goal) may still >> take some time. > > > I am mostly interested in domU support at this point. This is the only > feature that I can think of right now that blocks domU support in Linux. > > As I said in an earlier message I don't think dom0 needs ACPI hotplug > (or hotplug at all) while domU would benefit from it. But perhaps by > "consistent" you meant that you prefer both to behave in the same manner. Yes. > From Linux perspective one option could be to have domU with PV-style > vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when > it becomes available. This, however, will need an indication from the > hypervisor. We could, for example, set ACPI_FADT_HW_REDUCED, as we > discussed earlier. I think we shouldn't overload that flag. Didn't we settle already on using two CPUID flags (of for PV-style onlining/offlining, the other for ACPI hot(un)plug)? With that I think I could then be talked into accepting the existence of two different models (and kernels could pick which one(s) they would like to support). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen-blkfront: correct maximum segment accounting
Making use of "max_indirect_segments=" has issues:
- blkfront_setup_indirect() may end up with zero psegs when PAGE_SIZE
is sufficiently much larger than XEN_PAGE_SIZE
- the variable driven by the command line option
(xen_blkif_max_segments) has a somewhat different purpose, and hence
should namely never end up being zero
- as long as the specified value is lower than the legacy default,
we better don't use indirect segments at all (or we'd in fact lower
throughput)
Signed-off-by: Jan Beulich
---
drivers/block/xen-blkfront.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
--- 4.10-rc5/drivers/block/xen-blkfront.c
+++ 4.10-rc5-xen-blkfront-seg-accounting/drivers/block/xen-blkfront.c
@@ -2223,7 +2223,7 @@ static int blkfront_setup_indirect(struc
}
else
grants = info->max_indirect_segments;
- psegs = grants / GRANTS_PER_PSEG;
+ psegs = DIV_ROUND_UP(grants, GRANTS_PER_PSEG);
err = fill_grant_buffer(rinfo,
(grants + INDIRECT_GREFS(grants)) *
BLK_RING_SIZE(info));
@@ -2328,8 +2328,11 @@ static void blkfront_gather_backend_feat
indirect_segments = xenbus_read_unsigned(info->xbdev->otherend,
"feature-max-indirect-segments", 0);
- info->max_indirect_segments = min(indirect_segments,
- xen_blkif_max_segments);
+ if (indirect_segments > xen_blkif_max_segments)
+ indirect_segments = xen_blkif_max_segments;
+ if (indirect_segments <= BLKIF_MAX_SEGMENTS_PER_REQUEST)
+ indirect_segments = 0;
+ info->max_indirect_segments = indirect_segments;
}
/*
@@ -2652,6 +2655,9 @@ static int __init xlblk_init(void)
if (!xen_domain())
return -ENODEV;
+ if (xen_blkif_max_segments < BLKIF_MAX_SEGMENTS_PER_REQUEST)
+ xen_blkif_max_segments = BLKIF_MAX_SEGMENTS_PER_REQUEST;
+
if (xen_blkif_max_ring_order > XENBUS_MAX_RING_GRANT_ORDER) {
pr_info("Invalid max_ring_order (%d), will use default max:
%d.\n",
xen_blkif_max_ring_order, XENBUS_MAX_RING_GRANT_ORDER);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/5] xen: credit2: never consider CPUs outside of our cpupool.
On Tue, Jan 17, 2017 at 5:26 PM, Dario Faggioli
wrote:
> In fact, relying on the mask of what pCPUs belong to
> which Credit2 runqueue is not enough. If we only do that,
> when Credit2 is the boot scheduler, we may ASSERT() or
> panic when moving a pCPU from Pool-0 to another cpupool.
>
> This is because pCPUs outside of any pool are considered
> part of cpupool0. This puts us at risk of crash when those
> same pCPUs are added to another pool and something
> different than the idle domain is found to be running
> on them.
>
> Note that, even if we prevent the above to happen (which
> is the purpose of this patch), this is still pretty bad,
> in fact, when we remove a pCPU from Pool-0:
> - in Credit1, as we do *not* update prv->ncpus and
> prv->credit, which means we're considering the wrong
> total credits when doing accounting;
> - in Credit2, the pCPU remains part of one runqueue,
> and is hence at least considered during load balancing,
> even if no vCPU should really run there.
>
> In Credit1, this "only" causes skewed accounting and
> no crashes because there is a lot of `cpumask_and`ing
> going on with the cpumask of the domains' cpupool
> (which, BTW, comes at a price).
>
> A quick and not to involved (and easily backportable)
> solution for Credit2, is to do exactly the same.
>
> Signed-off-by: Dario Faggioli
> ---
> Cc: George Dunlap
> Cc: Juergen Gross
> Cc: Jan Beulich
> ---
> This is a bugfix, and should be backported to 4.8.
> ---
> The proper solution would mean calling deinit_pdata() when removing a pCPU
> from
> cpupool0, as well as a bit more of code reshuffling.
>
> And, although worth doing, it certainly will take more work, more time, and
> will probably be hard (well, surely harder than this) to backport.
>
> Therefore, I'd argue in favor of both taking and backporting this change,
> which
> at least enables using Credit2 as default scheduler without risking a crash
> when creating a second cpupool.
>
> Afterwards, a proper solution would be proposed for Xen 4.9.
>
> Finally, given the wide number of issues similar to this that I've found and
> fixed in the last release cycle, I think it would be good to take a stab at
> whether the interface between cpupools and the schedulers could not be
> simplified. :-O
>
> Regards,
> Dario
> ---
> xen/common/sched_credit2.c | 59
>
> 1 file changed, 38 insertions(+), 21 deletions(-)
>
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index 523922e..ce0e146 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -510,19 +510,22 @@ void smt_idle_mask_clear(unsigned int cpu, cpumask_t
> *mask)
> */
> static int get_fallback_cpu(struct csched2_vcpu *svc)
> {
> -int fallback_cpu, cpu = svc->vcpu->processor;
> +struct vcpu *v = svc->vcpu;
> +int cpu = v->processor;
>
> -if ( likely(cpumask_test_cpu(cpu, svc->vcpu->cpu_hard_affinity)) )
> -return cpu;
> +cpumask_and(cpumask_scratch_cpu(cpu), v->cpu_hard_affinity,
> +cpupool_domain_cpumask(v->domain));
>
> -cpumask_and(cpumask_scratch_cpu(cpu), svc->vcpu->cpu_hard_affinity,
> -&svc->rqd->active);
> -fallback_cpu = cpumask_first(cpumask_scratch_cpu(cpu));
> -if ( likely(fallback_cpu < nr_cpu_ids) )
> -return fallback_cpu;
> +if ( likely(cpumask_test_cpu(cpu, cpumask_scratch_cpu(cpu))) )
> +return cpu;
>
> -cpumask_and(cpumask_scratch, svc->vcpu->cpu_hard_affinity,
> -cpupool_domain_cpumask(svc->vcpu->domain));
> +if ( likely(cpumask_intersects(cpumask_scratch_cpu(cpu),
> + &svc->rqd->active)) )
> +{
> +cpumask_and(cpumask_scratch_cpu(cpu), &svc->rqd->active,
> +cpumask_scratch_cpu(cpu));
> +return cpumask_first(cpumask_scratch_cpu(cpu));
> +}
>
> ASSERT(!cpumask_empty(cpumask_scratch_cpu(cpu)));
>
> @@ -940,6 +943,9 @@ runq_tickle(const struct scheduler *ops, struct
> csched2_vcpu *new, s_time_t now)
> (unsigned char *)&d);
> }
>
> +cpumask_and(cpumask_scratch_cpu(cpu), new->vcpu->cpu_hard_affinity,
> +cpupool_domain_cpumask(new->vcpu->domain));
> +
> /*
> * First of all, consider idle cpus, checking if we can just
> * re-use the pcpu where we were running before.
> @@ -952,7 +958,7 @@ runq_tickle(const struct scheduler *ops, struct
> csched2_vcpu *new, s_time_t now)
> cpumask_andnot(&mask, &rqd->idle, &rqd->smt_idle);
> else
> cpumask_copy(&mask, &rqd->smt_idle);
> -cpumask_and(&mask, &mask, new->vcpu->cpu_hard_affinity);
> +cpumask_and(&mask, &mask, cpumask_scratch_cpu(cpu));
> i = cpumask_test_or_cycle(cpu, &mask);
> if ( i < nr_cpu_ids )
> {
> @@ -967,7 +973,7 @@ runq_tickle(const struct scheduler *ops, struct
> csched2_vcpu *new, s_time_t now)
> * gone through the schedule
Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support
On 1/23/17 7:08 AM, Daniel Kiper wrote: > On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote: >> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote: >>> On 1/19/17 8:34 PM, Daniel Kiper wrote: Hi, I am sending twelfth version of multiboot2 protocol support for legacy BIOS and EFI platforms. This patch series release contains fixes for all known/confirmed issues. >>> >>> With my fix to efi_multiboot2() in 5/10 and the entire series applied, I >>> get the following on some of the systems I have access to: >>> >>> (XEN) [2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB >>> (XEN) [7.012109] Stuck ?? >>> (XEN) [7.012129] Failed to bring up CPU 1 (error -5) >>> (XEN) [ 12.023606] Stuck ?? >>> (XEN) [ 12.023622] Failed to bring up CPU 2 (error -5) >>> (XEN) [ 17.035099] Stuck ?? >>> (XEN) [ 17.035115] Failed to bring up CPU 3 (error -5) >>> (XEN) [ 17.035116] Brought up 1 CPUs >>> >>> On other machines they reset when setting PAGING into cr0 (actually the >>> jmp following it) on line 124 of trampoline.S >> >> Thanks! I will take a look. >> >>> If I drop the series to just 2-5 against staging (since patch 1 has >>> already gone in) and apply the fix to efi_multiboot2() then all the >>> machines I presently have access to boot. >> >> Great! >> >>> Effectively the fix to efi_multiboot2() gets us back to the same level >>> of hardware support that v11 + my v5 was at for 1-5. So I will extend my: >>> >>> Reviewed-by: Doug Goldstein >>> Tested-by: Doug Goldstein >> >> Thanks! >> >>> on the condition that the fix is applied to 5/10 prior to commit. >> >> Will do. >> >> By the way, I have asked my team colleagues to do more tests of this series. >> I will come back to you if I have something in hand. > > Once you told me that you applied some patches on top of my patch series to > get > it working. Is it still true? If you still use some extra patches could you > send > me them? What about ExitBootServices() call? Did you disabled it? If yes on > which > machines it have to be disabled? > > Daniel > I previously used the patch that I linked to you authored by Konrad. I have since switched to the patches that XenServer uses to no-op efi_get_time() and to map additional ranges of reserved memory to make EBS() work. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] PVH CPU hotplug design document
>> From Linux perspective one option could be to have domU with PV-style >> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when >> it becomes available. This, however, will need an indication from the >> hypervisor. We could, for example, set ACPI_FADT_HW_REDUCED, as we >> discussed earlier. > I think we shouldn't overload that flag. Didn't we settle already on using > two CPUID flags (of for PV-style onlining/offlining, the other for ACPI > hot(un)plug)? With that I think I could then be talked into accepting the > existence of two different models (and kernels could pick which one(s) > they would like to support). I forgot about existence of ACPI_FADT_HW_REDUCED until this morning, which is why I mentioned it now. We can go with CPUID flags although I am not sure why we'd need two. I'd think that OS can be expected to always support PV-style so the flag would indicate support for ACPI-based hotplug. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support
On Mon, Jan 23, 2017 at 09:35:55AM -0600, Doug Goldstein wrote: > On 1/23/17 7:08 AM, Daniel Kiper wrote: > > On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote: > >> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote: > >>> On 1/19/17 8:34 PM, Daniel Kiper wrote: > Hi, > > I am sending twelfth version of multiboot2 protocol support for > legacy BIOS and EFI platforms. This patch series release contains > fixes for all known/confirmed issues. > >>> > >>> With my fix to efi_multiboot2() in 5/10 and the entire series applied, I > >>> get the following on some of the systems I have access to: > >>> > >>> (XEN) [2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB > >>> (XEN) [7.012109] Stuck ?? > >>> (XEN) [7.012129] Failed to bring up CPU 1 (error -5) > >>> (XEN) [ 12.023606] Stuck ?? > >>> (XEN) [ 12.023622] Failed to bring up CPU 2 (error -5) > >>> (XEN) [ 17.035099] Stuck ?? > >>> (XEN) [ 17.035115] Failed to bring up CPU 3 (error -5) > >>> (XEN) [ 17.035116] Brought up 1 CPUs > >>> > >>> On other machines they reset when setting PAGING into cr0 (actually the > >>> jmp following it) on line 124 of trampoline.S > >> > >> Thanks! I will take a look. > >> > >>> If I drop the series to just 2-5 against staging (since patch 1 has > >>> already gone in) and apply the fix to efi_multiboot2() then all the > >>> machines I presently have access to boot. > >> > >> Great! > >> > >>> Effectively the fix to efi_multiboot2() gets us back to the same level > >>> of hardware support that v11 + my v5 was at for 1-5. So I will extend my: > >>> > >>> Reviewed-by: Doug Goldstein > >>> Tested-by: Doug Goldstein > >> > >> Thanks! > >> > >>> on the condition that the fix is applied to 5/10 prior to commit. > >> > >> Will do. > >> > >> By the way, I have asked my team colleagues to do more tests of this > >> series. > >> I will come back to you if I have something in hand. > > > > Once you told me that you applied some patches on top of my patch series to > > get > > it working. Is it still true? If you still use some extra patches could you > > send > > me them? What about ExitBootServices() call? Did you disabled it? If yes on > > which > > machines it have to be disabled? > > > > Daniel > > > > I previously used the patch that I linked to you authored by Konrad. I > have since switched to the patches that XenServer uses to no-op > efi_get_time() and to map additional ranges of reserved memory to make > EBS() work. Could you send me them? Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/5] xen: credit2: fix shutdown/suspend when playing with cpupools.
On Tue, Jan 17, 2017 at 5:26 PM, Dario Faggioli wrote: > In fact, during shutdown/suspend, we temporarily move all > the vCPUs to the BSP (i.e., pCPU 0, as of now). For Credit2 > domains, we call csched2_vcpu_migrate(), expects to find the > target pCPU in the domain's pool > > Therefore, if Credit2 is the default scheduler and we have > removed pCPU 0 from cpupool0, shutdown/suspend fails like > this: > > RIP:e008:[] sched_credit2.c#migrate+0x274/0x2d1 > Xen call trace: > [] sched_credit2.c#migrate+0x274/0x2d1 > [] sched_credit2.c#csched2_vcpu_migrate+0x6e/0x86 > [] schedule.c#vcpu_move_locked+0x69/0x6f > [] cpu_disable_scheduler+0x3d7/0x430 > [] __cpu_disable+0x299/0x2b0 > [] cpu.c#take_cpu_down+0x2f/0x38 > [] stop_machine.c#stopmachine_action+0x7f/0x8d > [] tasklet.c#do_tasklet_work+0x74/0xab > [] do_tasklet+0x66/0x8b > [] domain.c#idle_loop+0x3b/0x5e > > > Panic on CPU 8: > Assertion 'svc->vcpu->processor < nr_cpu_ids' failed at sched_credit2.c:1729 > > > On the other hand, if Credit2 is the scheduler of another > pool, when trying (still during shutdown/suspend) to move > the vCPUs of the Credit2 domains to pCPU 0, it figures > out that pCPU 0 is not a Credit2 pCPU, and fails like this: > > RIP:e008:[] > sched_credit2.c#csched2_vcpu_migrate+0xa1/0x107 > Xen call trace: > [] sched_credit2.c#csched2_vcpu_migrate+0xa1/0x107 > [] schedule.c#vcpu_move_locked+0x69/0x6f > [] cpu_disable_scheduler+0x3d7/0x430 > [] __cpu_disable+0x299/0x2b0 > [] cpu.c#take_cpu_down+0x2f/0x38 > [] stop_machine.c#stopmachine_action+0x7f/0x8d > [] tasklet.c#do_tasklet_work+0x74/0xab > [] do_tasklet+0x66/0x8b > [] domain.c#idle_loop+0x3b/0x5e > > The solution is to recognise the specific situation, inside > csched2_vcpu_migrate() and, considering it is something temporary, > which only happens during shutdown/suspend, quickly deal with it. > > Then, in the resume path, in restore_vcpu_affinity(), things > are set back to normal, and a new v->processor is chosen, for > each vCPU, from the proper set of pCPUs (i.e., the ones of > the proper cpupool). > > Signed-off-by: Dario Faggioli Acked-by: George Dunlap ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] PVH CPU hotplug design document
On 01/23/2017 10:43 AM, Boris Ostrovsky wrote: >>> From Linux perspective one option could be to have domU with PV-style >>> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when >>> it becomes available. This, however, will need an indication from the >>> hypervisor. We could, for example, set ACPI_FADT_HW_REDUCED, as we >>> discussed earlier. >> I think we shouldn't overload that flag. Didn't we settle already on using >> two CPUID flags (of for PV-style onlining/offlining, the other for ACPI >> hot(un)plug)? With that I think I could then be talked into accepting the >> existence of two different models (and kernels could pick which one(s) >> they would like to support). > I forgot about existence of ACPI_FADT_HW_REDUCED until this morning, > which is why I mentioned it now. > > We can go with CPUID flags although I am not sure why we'd need two. I'd > think that OS can be expected to always support PV-style so the flag > would indicate support for ACPI-based hotplug. In fact, it doesn't matter whether OS supports PV-style hotplug. It's that Xen will always set appropriate xenstore entry. It's up to the OS whether to watch it and act upon this. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] PVH CPU hotplug design document
>>> On 23.01.17 at 16:43, wrote: >>> From Linux perspective one option could be to have domU with PV-style >>> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when >>> it becomes available. This, however, will need an indication from the >>> hypervisor. We could, for example, set ACPI_FADT_HW_REDUCED, as we >>> discussed earlier. >> I think we shouldn't overload that flag. Didn't we settle already on using >> two CPUID flags (of for PV-style onlining/offlining, the other for ACPI >> hot(un)plug)? With that I think I could then be talked into accepting the >> existence of two different models (and kernels could pick which one(s) >> they would like to support). > > I forgot about existence of ACPI_FADT_HW_REDUCED until this morning, > which is why I mentioned it now. > > We can go with CPUID flags although I am not sure why we'd need two. I'd > think that OS can be expected to always support PV-style so the flag > would indicate support for ACPI-based hotplug. Well, to date PV style wasn't meant to be supported, was it? In which case it would be legitimate to put it behind a feature flag. That would then also pave a road towards removing the support for this (and simply no longer setting that flag). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 5/5] xen: sched: simplify ACPI S3 resume path.
On Tue, Jan 17, 2017 at 5:27 PM, Dario Faggioli
wrote:
> In fact, when domains are being unpaused:
> - it's not necessary to put the vcpu to sleep, as
>they are all already paused;
> - it is not necessary to call vcpu_migrate(), as
>the vcpus are still paused, and therefore won't
>wakeup anyway.
>
> Basically, the only important thing is to call
> pick_cpu, to let the scheduler run and figure out
> what would be the best initial placement (i.e., the
> value stored in v->processor), for the vcpus, as
> they come back up, one after another.
>
> Note that this is consistent with what was happening
> before this change, as vcpu_migrate() calls pick_cpu.
> But much simpler and quicker.
>
> Signed-off-by: Dario Faggioli
Reviewed-by: George Dunlap
> ---
> Cc: George Dunlap
> ---
> xen/common/schedule.c | 22 ++
> 1 file changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index bee5d1f..43b5b99 100644
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -635,7 +635,11 @@ void restore_vcpu_affinity(struct domain *d)
>
> for_each_vcpu ( d, v )
> {
> -spinlock_t *lock = vcpu_schedule_lock_irq(v);
> +spinlock_t *lock;
> +
> +ASSERT(!vcpu_runnable(v));
> +
> +lock = vcpu_schedule_lock_irq(v);
>
> if ( v->affinity_broken )
> {
> @@ -659,17 +663,11 @@ void restore_vcpu_affinity(struct domain *d)
> cpupool_domain_cpumask(v->domain));
> v->processor = cpumask_any(cpumask_scratch_cpu(cpu));
>
> -if ( v->processor == cpu )
> -{
> -set_bit(_VPF_migrating, &v->pause_flags);
> -spin_unlock_irq(lock);;
> -vcpu_sleep_nosync(v);
> -vcpu_migrate(v);
> -}
> -else
> -{
> -spin_unlock_irq(lock);
> -}
> +spin_unlock_irq(lock);;
> +
> +lock = vcpu_schedule_lock_irq(v);
> +v->processor = SCHED_OP(VCPU2OP(v), pick_cpu, v);
> +spin_unlock_irq(lock);
> }
>
> domain_update_node_affinity(d);
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
