>>> On 06.12.16 at 08:43, wrote:
> On 05/12/16 18:17, Jan Beulich wrote:
> On 05.12.16 at 17:34, wrote:
>>> For XENMEM_machine_memory_map the hypervisor returns EINVAL if the
>>> caller's buffer can't hold all entries.
>>>
>>> This is a problem as the caller has normally a static buffer defin
>>> On 05.12.16 at 23:25, wrote:
> There is a problem with place_string() which is used as early memory
> allocator. It gets memory chunks starting from start symbol and goes
> down. Sadly this does not work when Xen is loaded using multiboot2
> protocol because then the start lives on 1 MiB addre
On 06/12/16 09:15, Jan Beulich wrote:
On 06.12.16 at 08:43, wrote:
>> On 05/12/16 18:17, Jan Beulich wrote:
>> On 05.12.16 at 17:34, wrote:
For XENMEM_machine_memory_map the hypervisor returns EINVAL if the
caller's buffer can't hold all entries.
This is a problem as
>>> On 05.12.16 at 22:32, wrote:
> static inline void sync_core(void)
> {
> - int tmp;
> -
> -#ifdef CONFIG_X86_32
> /*
> - * Do a CPUID if available, otherwise do a jump. The jump
> - * can conveniently enough be the jump around CPUID.
> + * There are quite a few ways
>>> On 06.12.16 at 09:33, wrote:
> On 06/12/16 09:15, Jan Beulich wrote:
>> I'd like us to at least consider alternatives:
>>
>> 1) Have a new sub-op behaving BIOS like (one entry at a time).
>
> No objections from me.
>
>> 2) Make the full map available inside the initial mapping, pointed to
>
>>> On 05.12.16 at 19:24, wrote:
> core2_no_vpmu_ops exists solely to work around the default-leaking of
> CPUID/MSR
> values in Xen.
>
> With CPUID handling removed from arch_vpmu_ops, the RDMSR handling is the last
> remaining hook. Since core2_no_vpmu_ops's introduction in c/s 25250ed7 "vpmu
>>> On 05.12.16 at 19:24, wrote:
> This reduces the net complexity of CPUID handling by having all adjustments in
> at the same place. Remove the now-unused hvm_funcs.cpuid_intercept
> infrastructure.
>
> The SYSCALL feature hiding is tweaked when moved. In principle, an
> administrator can cho
>>> On 05.12.16 at 19:24, wrote:
> This reduces the net complexity of CPUID handling by having all adjustments in
> at the same place. Remove the now-unused hvm_funcs.hypervisor_cpuid_leaf()
> infrastructure.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
branch xen-4.5-testing
xenbranch xen-4.5-testing
job test-xtf-amd64-amd64-5
testid leak-check/check
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xen
On Tue, Dec 06, 2016 at 01:46:37AM -0700, Jan Beulich wrote:
> > + asm volatile (
> > + "pushfl\n\t"
> > + "pushl %%cs\n\t"
> > + "pushl $1f\n\t"
> > + "iret\n\t"
> > + "1:"
> > + : "+r" (__sp) : : "cc", "memory");
>
> I don't thing EFL
On Tue, Dec 06, 2016 at 07:41:54AM +0100, Juergen Gross wrote:
> Commit d4016288ab1f ("xenstore: support XS_DIRECTORY_PART in
> libxenstore") introduced a theoretical bug: the generation count of
> the read node is transferred via strncpy without forcing a NUL byte
> at the end. Correct this.
>
>
On 06/12/16 09:51, Jan Beulich wrote:
On 06.12.16 at 09:33, wrote:
>> On 06/12/16 09:15, Jan Beulich wrote:
>>> I'd like us to at least consider alternatives:
>>>
>>> 1) Have a new sub-op behaving BIOS like (one entry at a time).
>>
>> No objections from me.
>>
>>> 2) Make the full map availa
>>> On 06.12.16 at 10:25, wrote:
> On Tue, Dec 06, 2016 at 01:46:37AM -0700, Jan Beulich wrote:
>> > + asm volatile (
>> > + "pushfl\n\t"
>> > + "pushl %%cs\n\t"
>> > + "pushl $1f\n\t"
>> > + "iret\n\t"
>> > + "1:"
>> > + : "+r" (__sp) : : "cc
>>> On 06.12.16 at 10:44, wrote:
> On 06/12/16 09:51, Jan Beulich wrote:
> On 06.12.16 at 09:33, wrote:
>>> On 06/12/16 09:15, Jan Beulich wrote:
I'd like us to at least consider alternatives:
1) Have a new sub-op behaving BIOS like (one entry at a time).
>>>
>>> No objections
Oops. Sorry for the noise.
regards,
dan carpenter
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
As such clearing of flags may have an impact on the selected rendezvous
function, handle such in a central place.
But don't allow such feature flags to be cleared during CPU hotplug:
Platform and local system times may have diverged significantly by
then, potentially causing noticably (even if onl
1: x86/32on64: use generic instruction decoding for call gate emulation
2: x86emul: don't assume a memory operand
3: x86emul: generalize exception handling for rep_* hooks
4: x86emul: make write and cmpxchg hooks optional
5: x86/PV: use generic emulator for privileged instruction handling
Signed-o
... 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
If any of those hooks returns X86EMUL_EXCEPTION, some register state
should still get updated if some iterations have been performed (but
the rIP update will get suppressed if not all of them did get handled).
This updating is done by register_address_increment() and
__put_rep_prefix() (which hence
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
While the read and fetch hooks are basically unavoidable, write and
cmpxchg aren't really needed by that many insns.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1492,6 +1492,8 @@ protmode_load_seg(
{
uint3
There's a new emulator return code being added to allow bypassing
certain operations (see the code comment).
The other small tweak to the emulator is to single iteration handling
of INS and OUTS: Since we don't want to handle any other memory access
instructions, we want these to be handled by the
On 05/12/16 20:59, Boris Ostrovsky wrote:
> On 12/05/2016 01:24 PM, Andrew Cooper wrote:
>> @@ -3516,6 +3516,17 @@ void hvm_cpuid(unsigned int input, unsigned int *eax,
>> unsigned int *ebx,
>> if ( !(hvm_pae_enabled(v) || hvm_long_mode_enabled(v)) )
>> *edx &= ~cpufe
>>> On 06.12.16 at 12:16, wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -459,6 +459,7 @@ static int hvmemul_linear_to_phys(
> {
> if ( pfec & (PFEC_page_paged | PFEC_page_shared) )
> return X86EMUL_RETRY;
> +*reps = 0;
>
In order to pre-determine whether a fault will occur upon software
interrupt injection, it is not sufficient to just check P and DPL. Do
at least all the checks on the IDT entry itself, and in particular do
the #NP check last. The checks for the new CS (and perhaps SS) are left
out for now, though.
flight 102942 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102942/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 102897
test-amd64-i386-xl-qemuu-wi
With suitable canonical address checks added these can also be used in
do_set_segment_base().
Also with a canonical address check now in place, there's no need for
priv_op_write_msr() to use wrmsr_safe() anymore.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@
Their size parameters being "unsigned", there's neither a point for
them returning "unsigned long", nor for any of their (assembly)
arithmetic to involved 64-bit operations on other than addresses.
Take the opportunity and fold __do_clear_user() into its single user
(using qword stores instead of
On 06/12/16 06:30, Juergen Gross wrote:
> On 05/12/16 19:19, Andrew Cooper wrote:
>> On 05/12/16 12:05, Wei Liu wrote:
>>> On Mon, Dec 05, 2016 at 08:48:41AM +0100, Juergen Gross wrote:
>>> [...]
Juergen Gross (12):
xenstore: modify add_change_node() parameter types
xenstore: cal
And with that drop mem_sharing_ prefixes as no longer meaningful. Once
again convert GFN function argument types at once.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -47,7 +47,7 @@ typedef struct pg_lock_data {
unsigned short recurse
1: introduce hvm_get_cpl() and respective hook
2: support (emulate) UMIP
3: prefer structure assignment for seg reg copying
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
... instead of repeating the same code in various places (and getting
it wrong in some of them).
In vmx_inst_check_privilege() also stop open coding vmx_get_x86_mode().
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2744,7 +2744,7 @@ static void hvm_un
There are three noteworthy drawbacks:
1) The intercepts we need to enable here are CPL-independent, i.e. we
now have to emulate certain instructions for ring 0.
2) On VMX there's no intercept for SMSW, so the emulation isn't really
complete there.
3) The CR4 write intercept on SVM is lower pr
1: section index 0 is special
2: use UINT_MAX
3: type adjustments
4: treat phdr and shdr similarly
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 06 December 2016 11:45
> To: xen-devel
> Cc: Suravee Suthikulpanit ; Andrew
> Cooper ; Paul Durrant
> ; George Dunlap ;
> Boris Ostrovsky
> Subject: [PATCH 3/3] x86/HVM: prefer structure assignment for seg reg
> c
This makes things type safe.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1434,7 +1434,8 @@ static int hvmemul_read_segment(
if ( IS_ERR(sreg) )
return -PTR_ERR(sreg);
-memcpy(reg, sreg, sizeof(struct segment_register));
+
When iterating over sections, table entry zero needs to be ignored.
Signed-off-by: Jan Beulich
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -536,7 +536,7 @@ elf_errorstatus elf_xen_parse(struct elf
if ( xen_elfnotes == 0 )
{
count = elf_
While Xen indeed doesn't have limits.h, it still does have UINT_MAX, so
we should avoid open coding it (and perhaps - even if unlikely -
getting it wrong).
Signed-off-by: Jan Beulich
--- a/xen/common/libelf/libelf-private.h
+++ b/xen/common/libelf/libelf-private.h
@@ -43,6 +43,7 @@
#include
#
Don't needlessly use uint64_t when unsigned suffices.
Also don't open code elf_phdr_count() and replace a redundant call to
elf_shdr_count().
Signed-off-by: Jan Beulich
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -36,7 +36,8 @@ struct elf_sym_header {
elf
Just like elf_shdr_count(), elf_phdr_count() better bounds checks the
value.
Add table entry size checks to elf_init().
Also both program and section headers are optional, and hence their
checking better is done conditionally only when any such headers are
present.
Signed-off-by: Jan Beulich
-
On 06/12/16 11:12, Jan Beulich wrote:
> ... 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
> @@ -2
Bump the version number for libxc, lixlu, libxl and libvchan to 4.9.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
List of libraries got from:
$ cd tools && git grep '4\.8'
---
tools/libvchan/Makefile | 2 +-
tools/libxc/Makefile| 2 +-
tools/libxl/Makefile| 4 ++--
3 files changed, 4 ins
On Tue, Dec 06, 2016 at 12:05:46PM +, Wei Liu wrote:
> Bump the version number for libxc, lixlu, libxl and libvchan to 4.9.
>
lixlu should be libxlu.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-9637 / XSA-199
version 3
qemu ioport array overflow
UPDATES IN VERSION 3
Clarify the IMPACT description, by escalating privilege to t
On 12/06/2016 01:43 PM, Jan Beulich wrote:
> ... instead of repeating the same code in various places (and getting
> it wrong in some of them).
>
> In vmx_inst_check_privilege() also stop open coding vmx_get_x86_mode().
>
> Signed-off-by: Jan Beulich
Acked-by: Razvan Cojocaru
May I just say
flight 102994 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102994/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
It was pointlessly non-static, and being static and a simple wrapper it
can as well be folded into its single caller.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1775,12 +1775,6 @@ int hvm_emulate_one(
return _hvm_emulate_one(hvmemul_ctxt
Rather than almost entirely duplicating __hvm_copy(), have __hvm_copy()
clear guest memory if the source pointer is NULL.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3212,7 +3212,10 @@ static enum hvm_copy_result __hvm_copy(
}
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 06 December 2016 12:47
> To: xen-devel
> Cc: Paul Durrant
> Subject: [PATCH] x86/HVM: drop hvm_emulate_one_no_write()
>
> It was pointlessly non-static, and being static and a simple wrapper it
> can as well be f
On Tue, Dec 06, 2016 at 04:52:12AM -0700, Jan Beulich wrote:
> While Xen indeed doesn't have limits.h, it still does have UINT_MAX, so
> we should avoid open coding it (and perhaps - even if unlikely -
> getting it wrong).
>
> Signed-off-by: Jan Beulich
Reviewed-by: Konrad Rzeszutek Wilk
_
On Tue, Dec 06, 2016 at 04:51:39AM -0700, Jan Beulich wrote:
> When iterating over sections, table entry zero needs to be ignored.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Konrad Rzeszutek Wilk
>
> --- a/xen/common/libelf/libelf-dominfo.c
> +++ b/xen/common/libelf/libelf-dominfo.c
> @@ -536
flight 102955 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102955/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2c1cc12931b6c5a85471272799b3d4c249025a60
baseline version:
ovmf 0db4acb61ac4e79a8a95b
On Tue, Dec 06, 2016 at 04:52:42AM -0700, Jan Beulich wrote:
> Don't needlessly use uint64_t when unsigned suffices.
>
> Also don't open code elf_phdr_count() and replace a redundant call to
> elf_shdr_count().
>
> Signed-off-by: Jan Beulich
Reviewed-by: Konrad Rzeszutek Wilk
>>> On 06.12.16 at 12:56, wrote:
> On 06/12/16 11:12, Jan Beulich wrote:
>> +static int gate_op_read(
>> +enum x86_segment seg,
>> +unsigned long offset,
>> +void *p_data,
>> +unsigned int bytes,
>> +struct x86_emulate_ctxt *ctxt)
>> +{
>> +const struct gate_op_ctxt *goc =
Both need to raise #GP(0) when in VM86 mode with IOPL < 3.
Additionally PUSHF is documented to clear VM and RF from the value
placed onto the stack.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3121,13 +3121,20 @@ x86_e
. snip..
All that above makes sense (and please put Reviewed-by from me on it), but this:
> unsigned elf_shdr_count(struct elf_binary *elf)
> {
> unsigned count = elf_uval(elf, elf->ehdr, e_shnum);
> -uint64_t max = elf->size / sizeof(Elf32_Shdr);
> +uint64_t max;
>
> +if ( !c
On 06/12/16 12:48, Jan Beulich wrote:
> Rather than almost entirely duplicating __hvm_copy(), have __hvm_copy()
> clear guest memory if the source pointer is NULL.
>
> Signed-off-by: Jan Beulich
Ooh - thats a nice improvement. I'm sorry I didn't spot it when doing
the API improvements to __hvm_c
1: consolidate loop counter handling
2: correct 64-bit mode repeated string insn handling with zero count
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 06/12/16 11:23, Jan Beulich wrote:
> In order to pre-determine whether a fault will occur upon software
> interrupt injection, it is not sufficient to just check P and DPL. Do
> at least all the checks on the IDT entry itself, and in particular do
> the #NP check last. The checks for the new CS
>>> On 06.12.16 at 14:27, wrote:
>> unsigned elf_shdr_count(struct elf_binary *elf)
>> {
>> unsigned count = elf_uval(elf, elf->ehdr, e_shnum);
>> -uint64_t max = elf->size / sizeof(Elf32_Shdr);
>> +uint64_t max;
>>
>> +if ( !count )
>> +return 0;
>> +max = elf->si
Rename _get_rep_prefix() to make it more visibly fit other use cases
and introduce a companion "put". Use them for repeated string insn
handling as well as LOOP/J?CXZ instead of open coding the same logic a
couple of times.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
When a 32-bit address override is in effect these zero-extend all
registers which would also get updated in case of non-zero repeat
count.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -933,15 +933,24 @@ static inline void
This is to avoid having to duplicate auxiliary definitions in both
source files.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -1,15 +1,9 @@
-#include
#include
#include
-#include
#include
-#include
-#i
>>> On 06.12.16 at 14:36, wrote:
> On 06/12/16 11:23, Jan Beulich wrote:
>> In order to pre-determine whether a fault will occur upon software
>> interrupt injection, it is not sufficient to just check P and DPL. Do
>> at least all the checks on the IDT entry itself, and in particular do
>> the #N
Today there is no way for a domain to obtain the number of entries of
the machine memory map returned by XENMEM_machine_memory_map hypercall.
Modify the interface to return just the needed number of map entries
in case the buffer was specified as NULL.
Signed-off-by: Juergen Gross
---
xen/arch/
Hi all,
Apologies for the late sending. You will find at the end of the mail a summary
of the discussion. Feel free to reply if I missed some parts.
At the end of the call we agreed to have another meeting before the end of the
year. Given that the Christmas is approaching and some people may tak
On 06/12/16 11:43, Jan Beulich wrote:
> @@ -921,6 +921,26 @@ static void vmx_ctxt_switch_to(struct vc
> }
>
>
> +unsigned int vmx_get_cpl(void)
> +{
> +unsigned long attr;
> +
> +__vmread(GUEST_SS_AR_BYTES, &attr);
> +
> +return (attr >> 5) & 3;
> +}
> +
> +static unsigned int _vmx
On Tue, Dec 06, 2016 at 04:52:12AM -0700, Jan Beulich wrote:
> While Xen indeed doesn't have limits.h, it still does have UINT_MAX, so
> we should avoid open coding it (and perhaps - even if unlikely -
> getting it wrong).
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/common/libelf/libelf-private
On Tue, Dec 06, 2016 at 04:51:39AM -0700, Jan Beulich wrote:
> When iterating over sections, table entry zero needs to be ignored.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://
On Tue, Dec 06, 2016 at 06:37:30AM -0700, Jan Beulich wrote:
> >>> On 06.12.16 at 14:27, wrote:
> >> unsigned elf_shdr_count(struct elf_binary *elf)
> >> {
> >> unsigned count = elf_uval(elf, elf->ehdr, e_shnum);
> >> -uint64_t max = elf->size / sizeof(Elf32_Shdr);
> >> +uint64_t ma
On Tue, Dec 06, 2016 at 04:52:42AM -0700, Jan Beulich wrote:
> Don't needlessly use uint64_t when unsigned suffices.
>
> Also don't open code elf_phdr_count() and replace a redundant call to
> elf_shdr_count().
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
__
On 06/12/16 11:45, Jan Beulich wrote:
> This makes things type safe.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Remove unused tnode variables in device tree IRQ map parsing
Coverity-ID 1381866, 1381867
Signed-off-by: Artem Mygaiev
---
xen/common/device_tree.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 1be074b..
Fix misplaced parentheses for PSCI version check
Coverity-ID: 1381830
Signed-off-by: Artem Mygaiev
Reviewed-by: Julien Grall
---
xen/arch/arm/psci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 7966b5e..34ee97e 100644
---
Thanks, resent
On 30.11.16 17:55, Julien Grall wrote:
> Hi Artem,
>
> On 30/11/16 13:53, Artem Mygaiev wrote:
>> Fix misplaced parentheses for PSCI version check
>>
>> Signed-off-by: Artem Mygaiev
>
> Can you please include the coverity ID:
>
> Coverity-ID: 1381830
>
> With that:
>
> Reviewed-by
Hi Artem,
On 06/12/16 13:57, Artem Mygaiev wrote:
Fix misplaced parentheses for PSCI version check
Coverity-ID: 1381830
Signed-off-by: Artem Mygaiev
Reviewed-by: Julien Grall
It looks like that Stefano already queued this patch in xen-arm-next.
Although, the Coverity-ID has not been added
1: extend / amend supported FPU opcodes
2: simplify FPU source operand handling
3: simplify FPU destination operand handling
4: reduce FPU handling code size
5: avoid undefined behavior when dealing with 10-byte FPU operands
6: simplify FPU handling asm() constraints
Signed-off-by: Jan Beulich
>>> On 06.12.16 at 14:49, wrote:
> On 06/12/16 11:43, Jan Beulich wrote:
>> @@ -921,6 +921,26 @@ static void vmx_ctxt_switch_to(struct vc
>> }
>>
>>
>> +unsigned int vmx_get_cpl(void)
>> +{
>> +unsigned long attr;
>> +
>> +__vmread(GUEST_SS_AR_BYTES, &attr);
>> +
>> +return (attr
...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 fo
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 Dur
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
--
Cc: Jan Beulich
Cc: Ian Jackson
Cc: Wei Liu
Cc: Andrew Cooper
Cc: Daniel De Graaf
v2:
- Addressed several commen
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
... 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.
N
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 tr
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
>>> On 06.12.16 at 14:49, wrote:
>> --- a/xen/common/libelf/libelf-tools.c
>> +++ b/xen/common/libelf/libelf-tools.c
>> @@ -131,9 +131,10 @@ unsigned elf_shdr_count(struct elf_binar
>> {
>> unsigned count = elf_uval(elf, elf->ehdr, e_shnum);
>> uint64_t max = elf->size / sizeof(Elf32_Sh
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
---
Cc: Jan Beulich
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:
First of all there are a number of secondary encodings both Intel and
AMD support, but which aren't formally documented.
Next there are a few more no-ops - instructions which served a purpose
only on 8087 or 287.
Further switch from fail_if() to raising of #UD in a couple of places
(as the decodi
Consistently use ea instead of src for passing the memory address to
->read(). This eliminates the need to copy ea to src, resulting in a
couple of hundred bytes smaller binary size.
In addition for opcode DE we can leverage SrcMem16 to eliminate a call
of the ->read() hook. At the same time drop
Consolidate the copying of ea to dst: There's no need to set the type
to OP_MEM, and instead the load cases setting it to OP_NONE allows the
copying to be done just once per major opcode.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_e
Pulling out the {get,put}_fpu() invocations from individual emulation
paths leads to a couple of kb code size reduction in my builds. Note
that this is fine exception-wise:
- #UD and #NM have implementation defined order relative to one
another,
- data read #GP/#SS/#PF now properly are delivered
Accessing an 8-byte (or perhaps just 4-byte in the test harness when
built as 32-bit app) field to read/write 10 bytes (leveraging the
successive field) is a latent bug, as the compiler could copy things
around. Use the 32 bytes large SSE/AVX slot instead.
Signed-off-by: Jan Beulich
---
The prese
On 06/12/16 14:07, Jan Beulich wrote:
On 06.12.16 at 14:49, wrote:
>> On 06/12/16 11:43, Jan Beulich wrote:
>>> @@ -921,6 +921,26 @@ static void vmx_ctxt_switch_to(struct vc
>>> }
>>>
>>>
>>> +unsigned int vmx_get_cpl(void)
>>> +{
>>> +unsigned long attr;
>>> +
>>> +__vmread(GUES
The memory clobber is rather harsh here. However, fic.exn_raised may be
modified as a side effect, so we need to let the compiler know that all
of "fic" may be changed (preventing it from moving around accesses to
the exn_raised field).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x
Fix macro for ARM Jazelle CPU feature identification: value of 0 indicates
that CPU does not support ARM Jazelle (PFR0[11:8])
Coverity-ID: 1381849
Signed-off-by: Artem Mygaiev
---
xen/include/asm-arm/cpufeature.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/a
Hi Artem,
On 06/12/16 13:57, Artem Mygaiev wrote:
Remove unused tnode variables in device tree IRQ map parsing
This description is slightly wrong, the variable are used but not the value.
Coverity-ID 1381866, 1381867
Signed-off-by: Artem Mygaiev
This code is from Linux (see drivers/of/ir
>>> On 06.12.16 at 14:47, wrote:
> Today there is no way for a domain to obtain the number of entries of
> the machine memory map returned by XENMEM_machine_memory_map hypercall.
>
> Modify the interface to return just the needed number of map entries
> in case the buffer was specified as NULL.
>
On Tue, Dec 06, 2016 at 07:19:13AM -0700, Jan Beulich wrote:
> >>> On 06.12.16 at 14:47, wrote:
> > Today there is no way for a domain to obtain the number of entries of
> > the machine memory map returned by XENMEM_machine_memory_map hypercall.
> >
> > Modify the interface to return just the nee
The function is never called under PV guests, and only shows up
when MSI (or MSI-X) cannot be allocated. Convert the message
to include the error value.
Signed-off-by: Konrad Rzeszutek Wilk
---
arch/x86/pci/xen.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/pc
1 - 100 of 194 matches
Mail list logo
