Add the capability to pass USB devices to HVM domains by using the
emulation of USB controllers of qemu.
The user interface via xl is the same as for pvusb passthrough, only
the type of the usbctrl is different: instead of "qusb" (qemu-based
pvusb backend) or "vusb" (kernel-based pvusb backend) th
Add HVM usb passthrough support to libxl by using qemu's capability
to emulate standard USB controllers.
A USB controller is added via qmp command to the emulated hardware
when a usbctrl device of type DEVICEMODEL is requested. Depending on
the requested speed the appropriate hardware type is sele
Rename libcl_pvusb.c to libxl_usb.c in order to reflect future support
of USB passthrough via qemu emulated USB controllers.
Signed-off-by: Juergen Gross
---
tools/libxl/Makefile | 2 +-
tools/libxl/{libxl_pvusb.c => libxl_usb.c} | 0
2 files changed, 1 insertion(+), 1 dele
With the planned support of HVM USB passthrough via the USB emulation
capabilities of qemu libxl has to support guest devices which have no
back- and frontend. Information about those devices will live in the
libxl part of Xenstore only.
Add some basic support to libxl to be able to cope with this
Add a function libxl__qmp_run_command_flexarray() to run a qmp command
with an array of arguments. The arguments are name-value pairs stored
in a flexarray.
Signed-off-by: Juergen Gross
---
tools/libxl/libxl_internal.h | 3 +++
tools/libxl/libxl_qmp.c | 16
2 files changed
Update the man page regarding passthrough of USB devices to HVM
domains via qemu USB emulation.
Signed-off-by: Juergen Gross
---
docs/man/xl.cfg.pod.5.in | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 77a
Instead of passing the array size as an argument when calling
libxl__xs_kvs_of_flexarray() let the function get the size from the
array instead.
Signed-off-by: Juergen Gross
---
tools/libxl/libxl.c | 22 +++---
tools/libxl/libxl_internal.h | 2 +-
tools/libxl/libxl_nic.
On Thu, 2016-09-08 at 13:30 +0800, Dongli Zhang wrote:
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index f34dd56..3641469 100644
> @@ -150,6 +152,12 @@ static void populate_physmap(struct memop_args
> *a)
> max_order(curr_d)) )
> return;
>
> +
On 31/08/16 10:30, Wei Liu wrote:
> This email only tracks big items for xen.git tree. Please reply for items you
> woulk like to see in 4.8 so that people have an idea what is going on and
> prioritise accordingly.
>
> You're welcome to provide description and use cases of the feature you're
> wo
On 2016-09-07 13:19:00 [-0400], Boris Ostrovsky wrote:
> * Be more careful with return value of cpuhp_setup_state_nocalls()
> as it may return a positive (non-error) number. (Which suggests
> that comment on top of __cpuhp_setup_state() is probably incorrect)
Yes, we need to update that one.
T
On 16-09-07 03:01:34, Jan Beulich wrote:
> >> >>> On 25.08.16 at 07:22, wrote:
> >> > + struct psr_socket_alloc_info *info);
> >> > +/*
> >> > + * get_old_set_new is used in set value process to get all features'
> >> > + * COS registers values according to orig
On 16-09-07 03:03:12, Jan Beulich wrote:
> >>> On 07.09.16 at 09:13, wrote:
> > On 16-09-06 01:43:22, Jan Beulich wrote:
> >> >>> On 25.08.16 at 07:22, wrote:
> >>
> >> Please extend the comments given for patch 1 to this one. Just one
> >> extra thing:
> >>
> >> > @@ -743,7 +744,7 @@ struct xe
flight 100802 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100802/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass
test-amd64-amd64-libvirt 12 migrate-s
On Wed, Sep 07, 2016 at 08:01:31AM -0600, Jan Beulich wrote:
> >>> On 07.09.16 at 14:05, wrote:
> > On Mon, Sep 05, 2016 at 06:33:57AM -0600, Jan Beulich wrote:
> >> >>> On 20.08.16 at 00:43, wrote:
> >> > +static char __initdata *ebmalloc_free = NULL;
> >> > +
> >> > +/* EFI boot allocator. */
>
On Wed, Sep 07, 2016 at 02:10:43AM -0600, Jan Beulich wrote:
> >>> On 06.09.16 at 21:56, wrote:
> > On Wed, Aug 24, 2016 at 03:08:01AM -0600, Jan Beulich wrote:
> >> >>> On 24.08.16 at 04:22, wrote:
> >> > --- a/xen/common/livepatch.c
> >> > +++ b/xen/common/livepatch.c
> >> > @@ -237,13 +237,34
On Wed, Sep 07, 2016 at 02:02:44AM -0600, Jan Beulich wrote:
> >>> On 06.09.16 at 18:47, wrote:
> > On Wed, Aug 24, 2016 at 02:55:21AM -0600, Jan Beulich wrote:
> >> >>> On 24.08.16 at 04:22, wrote:
> >> > --- a/xen/common/livepatch.c
> >> > +++ b/xen/common/livepatch.c
> >> > @@ -70,6 +70,9 @@ s
On 07/09/16 22:02, Stefano Stabellini wrote:
> On Wed, 7 Sep 2016, Meng Xu wrote:
>> On Wed, Sep 7, 2016 at 3:08 PM, Stefano Stabellini
>> wrote:
>>>
>>> On Wed, 7 Sep 2016, Ian Jackson wrote:
> Technical
> =
> On the technical front, it would be good to understand whether
Hello,
We are introducing a new virtualisation mode in Xen called PVHv2 (also
called hvmlite in the past). We would like to have a UEFI firmware
running on it to make it easier to start a guest. (Right now, I think it
involves supplying the guest kernel to the guest config, like a PV
guest.)
I'm
On Thu, Sep 08, 2016 at 05:32:00AM +, osstest service owner wrote:
> flight 100789 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/100789/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-
On 08/09/16 10:43, Wei Liu wrote:
> On Thu, Sep 08, 2016 at 05:32:00AM +, osstest service owner wrote:
>> flight 100789 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/100789/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tes
Commit 88e957d6e47f ("xen: introduce xen_vcpu_id mapping") broke SMP ARM
guests on Xen. When FIFO-based event channels are in use (this is the
default), evtchn_fifo_alloc_control_block() is called on CPU_UP_PREPARE
event and this happens before we set up xen_vcpu_id mapping in
xen_starting_cpu. Tem
>>> On 08.09.16 at 09:28, wrote:
> On 16-09-07 03:01:34, Jan Beulich wrote:
>> >> >>> On 25.08.16 at 07:22, wrote:
>> >> > +unsigned int (*exceed_range)(uint64_t *mask, struct feat_list
>> >> > *pFeat,
>> >> > + unsigned int cos);
>> >>
>> >> According to the
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: George Dunlap
---
xen/include/asm-x86/paging.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h
index a1401ab..56eef6b 100644
---
>>> On 08.09.16 at 10:29, wrote:
> On Wed, Sep 07, 2016 at 08:01:31AM -0600, Jan Beulich wrote:
>> >>> On 07.09.16 at 14:05, wrote:
>> > On Mon, Sep 05, 2016 at 06:33:57AM -0600, Jan Beulich wrote:
>> >> >>> On 20.08.16 at 00:43, wrote:
>> >> > +if ( ebmalloc_free == NULL )
>> >> > +
flight 100805 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100805/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4ac14ceae076439dcea926bc47cda4e1d2779cae
baseline version:
ovmf ad8a2f5e68fd9850c1074
At 10:55 +0100 on 08 Sep (1473332146), Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
s/predecates/predicates/, and Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 08/09/16 11:00, Tim Deegan wrote:
> At 10:55 +0100 on 08 Sep (1473332146), Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper
> s/predecates/predicates/, and Acked-by: Tim Deegan
Ah - so it is. Will fix.
Thanks.
~Andrew
___
Xen-devel mailing l
>>> On 08.09.16 at 11:22, wrote:
> On Wed, Sep 07, 2016 at 02:10:43AM -0600, Jan Beulich wrote:
>> >>> On 06.09.16 at 21:56, wrote:
>> > On Wed, Aug 24, 2016 at 03:08:01AM -0600, Jan Beulich wrote:
>> >> Overall - are you sure you want to disallow symbol names containing
>> >> + characters? I.e.
On 08/09/16 10:55, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
In case it needs it:
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
This run is configured for baseline tests only.
flight 67670 qemu-upstream-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67670/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 14 guest
On 09/08/16 11:38, Anthony PERARD wrote:
> Hello,
>
> We are introducing a new virtualisation mode in Xen called PVHv2 (also
> called hvmlite in the past). We would like to have a UEFI firmware
> running on it to make it easier to start a guest. (Right now, I think it
> involves supplying the gues
>>> On 08.09.16 at 00:04, wrote:
> From: Jan Beulich
>
> Consistently consult hvm_cpuid(). With that, BNDCFGS gets better
> handled outside of VMX specific code, just like XSS. Don't needlessly
> check for MTRR support when the MSR being accessed clearly is not an
> MTRR one.
>
> Signed-off-by:
On Thu, Aug 25, 2016 at 09:37:35AM -0400, Konrad Rzeszutek Wilk wrote:
> The patch piggybacks on: livepatch: Initial ARM64 support, which
> brings up all of the neccessary livepatch infrastructure pieces in.
>
> This patch adds three major pieces:
>
> 1) ELF relocations. ARM32 uses SHT_REL inste
On Thu, Sep 08, 2016 at 01:30:03PM +0800, Dongli Zhang wrote:
> This patch implemented parts of TODO left in commit id
> a902c12ee45fc9389eb8fe54eeddaf267a555c58. It moved TLB-flush filtering out
> into populate_physmap. Because of TLB-flush in alloc_heap_pages, it's very
> slow to create a guest w
On Thu, 2016-09-08 at 11:50 +0100, Wei Liu wrote:
> On Thu, Sep 08, 2016 at 01:30:03PM +0800, Dongli Zhang wrote:
> >
> > diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> > index 32a300f..593541a 100644
> > --- a/xen/common/schedule.c
> > +++ b/xen/common/schedule.c
> > @@ -1376,6 +137
On Thu, Sep 08, 2016 at 01:01:40PM +0200, Dario Faggioli wrote:
> On Thu, 2016-09-08 at 11:50 +0100, Wei Liu wrote:
> > On Thu, Sep 08, 2016 at 01:30:03PM +0800, Dongli Zhang wrote:
> > >
> > > diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> > > index 32a300f..593541a 100644
> > > ---
George Dunlap writes ("Re: Impact of HW vulnerabilities & Implications on
Security Vulnerability Process"):
> What's the conclusion here -- are you inclined to say that we shouldn't
> issue an XSA, but perhaps do some other sort of announcement?
I would like us to _either_ issue an XSA or some ot
On 08/09/16 13:11, Wei Liu wrote:
> On Thu, Sep 08, 2016 at 01:01:40PM +0200, Dario Faggioli wrote:
>> On Thu, 2016-09-08 at 11:50 +0100, Wei Liu wrote:
>>> On Thu, Sep 08, 2016 at 01:30:03PM +0800, Dongli Zhang wrote:
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
inde
On Thu, Sep 08, 2016 at 12:12:22PM +0100, Ian Jackson wrote:
> George Dunlap writes ("Re: Impact of HW vulnerabilities & Implications on
> Security Vulnerability Process"):
> > What's the conclusion here -- are you inclined to say that we shouldn't
> > issue an XSA, but perhaps do some other sort
flight 67673 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67673/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 67618
jobs:
build-amd64 pass
build-armh
> On 8 Sep 2016, at 12:12, Ian Jackson wrote:
>
> George Dunlap writes ("Re: Impact of HW vulnerabilities & Implications on
> Security Vulnerability Process"):
>> What's the conclusion here -- are you inclined to say that we shouldn't
>> issue an XSA, but perhaps do some other sort of announcem
This run is configured for baseline tests only.
flight 67671 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67671/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 14 guest-saveresto
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-7093 / XSA-186
version 4
x86: Mishandling of instruction pointer truncation during emulation
UPDATES IN VERSION 4
Public release.
ISSUE DESCRIPTION
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-7092 / XSA-185
version 3
x86: Disallow L3 recursive pagetable for 32-bit PV guests
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-7154 / XSA-188
version 3
use after free in FIFO event channel code
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-7094 / XSA-187
version 3
x86 HVM: Overflow of sh_ctxt->seg_reg[]
UPDATES IN VERSION 3
Fix the backports xsa187-4.6-0002-*.patch and xsa187-
Commit 6ea24e53f1 introduced two problems: It left out a semicolon and
typo-ed the source file name of the EFI map file install command.
Signed-off-by: Jan Beulich
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -67,7 +67,7 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_
if [ -r $(TARGET).efi -a -n
flight 100812 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100812/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 4 host-build-prep fail REGR. vs. 100800
Tests which
On Thu, Sep 08, 2016 at 06:45:36AM -0600, Jan Beulich wrote:
> Commit 6ea24e53f1 introduced two problems: It left out a semicolon and
> typo-ed the source file name of the EFI map file install command.
>
> Signed-off-by: Jan Beulich
>
Acked-by: Wei Liu
> --- a/xen/Makefile
> +++ b/xen/Makefil
..., complete the decoder, leverage decoding for SVM instruction
sizing and PV 32-bit call gate emulation, and use the emulator for
PV priv-op handling.
01: x86emul: split instruction decoding from execution
02: x86emul: fetch all insn bytes during the decode phase
03: x86emul: track only rIP in e
On Thu, Sep 08, 2016 at 10:43:59AM +0100, Wei Liu wrote:
> On Thu, Sep 08, 2016 at 05:32:00AM +, osstest service owner wrote:
> > flight 100789 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/100789/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and
flight 100803 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100803/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 9 debian-di-installfail REGR. vs. 100773
test-armhf-armhf-x
This is only the mechanical part, a subsequent patch will make non-
mechanical adjustments to actually do all decoding in this new
function.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -48,7 +48,9 @@
/* All operands are
This way we can offer to callers the service of just sizing
instructions, and we also can better guarantee not to raise the wrong
fault due to not having read all relevant bytes.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
Now that all decoding happens in x86_decode() there's no need to keep
the local registers copy in struct x86_emulate_state. Only rIP gets
updated in the decode phase, so only that register needs tracking
there. All other (read-only) registers can be read from the original
structure (but sadly, due
Now that all decoding happens in x86_decode() there's no need to keep
the local registers copy in struct x86_emulate_state. Only rIP gets
updated in the decode phase, so only that register needs tracking
there. All other (read-only) registers can be read from the original
structure (but sadly, due
This way we can at least size (and e.g. skip) them if needed, and we
also won't raise the wrong fault due to not having read all relevant
bytes.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -279,6 +279,12 @@ static const
This way we can at least size (and e.g. skip) them if needed, and we
also won't raise the wrong fault due to not having read all relevant
bytes.
This at once adds correct raising of #UD for the three "ud" flavors
(Intel names only "ud2", but AMD names all three of them in their
opcode maps), as th
This way we can at least size (and e.g. skip) them if needed, and we
also won't raise the wrong fault due to not having read all relevant
bytes.
Signed-off-by: Jan Beulich
---
TBD: I'm kind of undecided whether to right away propagate evex.R into
modrm_reg (and then also deal with the new me
Only code movement, no functional change.
Signed-off-by: Jan Beulich
---
This is just to ease review of a later patch.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4111,56 +4111,7 @@ x86_emulate(
default:
goto cannot_emulate;
}
This representation is then being made available to interested callers,
to facilitate replacing their custom decoding.
This entails combining the three main switch statements into one.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/x86_emulate.c
+++ b/tools/tests/x86_emulator/x86_emu
... instead of custom handling. To facilitate this break out init code
from _hvm_emulate_one() into the new hvm_emulate_init(), and make
hvmemul_insn_fetch( globally available.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -835,7 +835,7 @@ static
... instead of custom handling. Note that we can't use generic
emulation, as the emulator's far branch support is rather rudimentary
at this point in time.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#includ
This is in preparation for using the generic emulator here.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2242,6 +2242,107 @@ unsigned long guest_to_host_gpr_switch(u
void (*pv_post_outb_hook)(unsigned int port, u8 value);
+static int priv_op_read_cr(u
This is in preparation for using the generic emulator here.
Some care is needed temporarily to not unduly alter guest register
state: The local variable "res" can only go away once this code got
fully switched over to using x86_emulate().
Also switch to IS_ERR_VALUE() instead of (incorrectly) ope
This is in preparation for using the generic emulator here.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2373,6 +2373,332 @@ static inline uint64_t guest_misc_enable
return val;
}
+static inline bool is_cpufreq_controller(const struct domain *d)
+{
This is a prereq for switching PV privileged op emulation to the
generic instruction emulator. Since handle_xsetbv() is already capable
of dealing with all guest kinds, avoid introducing another hook here.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86
>>> On 08.09.16 at 15:08, wrote:
Please disregard this one - it got sent out with the wrong number in the
subject.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Sort the special case opcode 0f01 entries numerically, insert blank
lines between each of the cases, and properly place opening braces.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4192,6 +4192,14 @@ x86_emulate(
There's a new emulator return code being added to allow bypassing
certain operations (see the code comment). Its handling in the epilogue
code involves moving the raising of the single step trap until after
registers were updated. This should probably have been that way from
the beginning, to allow
Especially for x86_insn_operand_ea() to return dependable segment
information even when the caller didn't consider applicability we
shouldn't have ea.type start out as OP_MEM. Make it OP_NONE instead,
and set it to OP_MEM when we actually encounter memory like operands.
This requires to eliminate
>>> On 08.09.16 at 15:13, wrote:
> Only code movement, no functional change.
>
> Signed-off-by: Jan Beulich
Just noticed the title was left stale - should really be "x86emul:
move x86_emulate() common epilogue code".
Jan
___
Xen-devel mailing list
flight 100810 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100810/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d74135cd0f8d00d2126df0b4db54938c96456db6
baseline version:
ovmf 4ac14ceae076439dcea92
These are really independent of
and I prefer them to be a separate series, but won't apply without that
one in place. The final two I decided to pick up from Mihai, as it seemed
natural for me to do the rebasing on top of the major earlier changes,
and as I'd like to get the original issue (certai
>>> On 07.09.16 at 20:59, wrote:
> Changes in v3:
> * Constified acpi_numa's pointers
> * Constified acpi_config call parameter where possible
Thanks, but how about ...
> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/build.c
> @@ -70,18 +70,20 @@ static void s
To make this complete, also add support for SLDT and STR. Note that by
just looking at the guest CR4 bit, this is independent of actually
making available the UMIP feature to guests.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulat
Use a single set of variables throughout the huge switch() statement,
allowing to funnel SLDT/STR into the mov-from-sreg code path.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2494,7 +2494,8 @@ x86_emulate(
switc
Minimal emulation: XBEGIN aborts right away, hence
- XABORT is just a no-op,
- XEND always raises #GP,
- XTEST always signals neither RTM nor HLE are active.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1172,6 +1172,8 @@
From: Zhi Wang
Found that Windows driver was using a SSE2 instruction MOVD.
Signed-off-by: Zhi Wang
Signed-off-by: Mihai Donțu
Signed-off-by: Jan Beulich
---
v4: Re-base on decoding changes. Address Andrew's and my own review
comments (where still applicable). #UD when vex.l is set. Vario
From: Mihai Donțu
Signed-off-by: Mihai Donțu
Signed-off-by: Jan Beulich
---
v4: Re-base on decoding changes. Address my own review comments (where
still applicable). #UD when vex.l is set. Various adjustments to
the test tool change.
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+
>>> On 07.09.16 at 20:59, wrote:
> Components that wish to use ACPI builder will need to provide their own
> mem_alloc() and virt_to_phys() routines. Pointers to these routines will
> be passed to the builder as memory ops.
>
> Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
Albeit I'd p
On Thursday 08 September 2016 07:45:19 Jan Beulich wrote:
> From: Mihai Donțu
>
> Signed-off-by: Mihai Donțu
> Signed-off-by: Jan Beulich
> ---
> v4: Re-base on decoding changes. Address my own review comments (where
> still applicable). #UD when vex.l is set. Various adjustments to
> t
>>> On 07.09.16 at 20:59, wrote:
> ACPI sources will be available to various component which will build
> them according to their own rules. ACPI's Makefile will only generate
> necessary source files.
>
> Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
_
>>> On 07.09.16 at 20:59, wrote:
> In prepearation to moving acpi sources into generally available
> libacpi:
>
> 1. Pass IOAPIC/LAPIC/PCI mask values via struct acpi_config
> 2. Modify include files search paths to point to acpi directory
> 3. Macro-ise include file for build.c that defines vari
On 09/02/2016 08:30 AM, Juergen Gross wrote:
> Support the driver_override scheme introduced with commit 782a985d7af2
> ("PCI: Introduce new device binding path using pci_dev.driver_override")
>
> As pcistub_probe() is called for all devices (it has to check for a
> match based on the slot address
>>> On 07.09.16 at 20:59, wrote:
> Intermediate stages of building a target should be made with
> temporary files that are copied to final target in the end.
>
> Signed-off-by: Boris Ostrovsky
> ---
> New in v3
Ah, here we go.
> --- a/tools/libacpi/Makefile
> +++ b/tools/libacpi/Makefile
> @@
Wei Liu writes ("Re: [Xen-devel] [xen-unstable test] 100789: regressions -
FAIL"):
> I see three ways to move this forward.
>
> 3. Retire these two tests.
Do we expect users still to want VHD support ? We still allegedly
support VHD for guests. So we shouldn't retire these tests unless we
are d
HVM HAP codepaths have space for all segment registers in the seg_reg[]
cache (with x86_seg_none still risking an array overrun), while the shadow
codepaths only have space for the user segments.
Range check the input segment of *_get_seg_reg() against the size of the array
used to cache the resul
The Force Emulation Prefix is named to follow its PV counterpart for cpuid or
rdtsc, but isn't really an instruction prefix. It behaves as a break-out into
Xen, with the purpose of emulating the next instruction in the current state.
It is important to be able to test legal situations which occur
>>> On 07.09.16 at 20:59, wrote:
> Signed-off-by: Boris Ostrovsky
> ---
> Changes in v3:
> * Some constification of call parameters
> * Format adjustments
> * New acpi_mem_free hook (a nop)
> * Changes in init_acpi_config() to deal with constified acpi_numa's
> pointers (initialize pointers as
There is no need to read the segment information from VMCS/VMCB and cache it,
just to clobber the cached content immediately afterwards.
Write straight into the cache and set the accessed/dirty bits.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Paul Durrant
---
xen/arch/x86/hvm/emulat
This matches hardware behaviour, and prevents erroneous failures when a guest
has SMEP/SMAP active and issues a FEP from userspace.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
xen/arch/x86/hvm/hvm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x8
>>> On 07.09.16 at 20:59, wrote:
> @@ -32,15 +32,22 @@ $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
> $(MK_DSDT): mk_dsdt.c
> $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
>
> -$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl $(MK_DSDT)
> +$(ACPI_BUILD_DIR)/dsdt_anycpu_q
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 08 September 2016 15:12
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant
> Subject: [PATCH 3/4] x86/hvm: Optimise segment accesses in
> hvmemul_write_segment()
>
> There is no need to
Wei Liu writes ("Re: [PATCH v3 1/1] xen: move TLB-flush filtering out into
populate_physmap during vm creation"):
> On Thu, Sep 08, 2016 at 01:01:40PM +0200, Dario Faggioli wrote:
> > On Thu, 2016-09-08 at 11:50 +0100, Wei Liu wrote:
> > > On Thu, Sep 08, 2016 at 01:30:03PM +0800, Dongli Zhang wro
>>> On 08.09.16 at 16:11, wrote:
> The Force Emulation Prefix is named to follow its PV counterpart for cpuid or
> rdtsc, but isn't really an instruction prefix. It behaves as a break-out into
> Xen, with the purpose of emulating the next instruction in the current state.
>
> It is important to
>>> On 08.09.16 at 16:11, wrote:
> There is no need to read the segment information from VMCS/VMCB and cache it,
> just to clobber the cached content immediately afterwards.
>
> Write straight into the cache and set the accessed/dirty bits.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beu
> On 16 Aug 2016, at 09:19, George Dunlap wrote:
>
> On Mon, Aug 15, 2016 at 11:24 AM, Andrew Cooper
> wrote:
>> On 12/08/16 10:37, Lars Kurth wrote:
>>> COPYING file:
>>> The motivation of this change is to make it easier for new
>>> contributors to conduct a license and patent review, WITHOUT
This is a follow on to a message I sent to xen-users:
https://lists.xen.org/archives/html/xen-devel/2015-08/msg01924.html
I am trying to compile Xen 4.7.0 with gcc 6.1.1, but I get an error
related to etherboot. It was suggested to update the etherboot
Makefile to the head of the etherboot reposit
On 08/09/16 15:28, Jan Beulich wrote:
On 08.09.16 at 16:11, wrote:
>> The Force Emulation Prefix is named to follow its PV counterpart for cpuid or
>> rdtsc, but isn't really an instruction prefix. It behaves as a break-out
>> into
>> Xen, with the purpose of emulating the next instruction
1 - 100 of 150 matches
Mail list logo
