Hi Ian,
On Mon, 2016-12-12 at 17:36 +, Ian Jackson wrote:
> Cédric Bosdonnat writes ("[PATCH v3] libxl: QED disks support"):
> > Qdisk supports qcow and qcow2, extend it to also support qed disk
> > format.
>
> The patch is good.
>
> I have a qualm, though. I think this would increase our s
>>> On 13.12.16 at 04:57, wrote:
> 1. Should we enable 5 level paging for PV guest ? (You are discussing)
Personally I think we should, but as you say - we haven't settled on
this yet.
> 2. Should we make the 5 level paging and 4 level paging supported with one
> binary?
May I suggest to mak
>>> On 12.12.16 at 19:29, wrote:
> c/s e7dabe5 "x86/hvm: don't unconditionally create a default ioreq server"
> added a break statement, but the logic previously depended on falling through
> into the default case to fill in the value the caller asked for.
>
> This causes the sending migration co
>>> On 12.12.16 at 19:29, wrote:
> d->creation_finished is used in several places alter behaviour depending on
> whether the domain is being created, or is already running.
>
> However, there is a latent bug if a toolstack component makes a pair of
> pause/unpause calls, where creation will be co
>>> On 12.12.16 at 18:39, wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -433,6 +433,7 @@ typedef union {
> #define CR4_OSXMMEXCPT (1<<10)
> #define CR4_UMIP (1<<11)
> #define CR4_OSXSAVE(1<<18)
> +#define CR4_SMAP (1<<2
>>> On 12.12.16 at 20:18, wrote:
> flight 103162 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/103162/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-i386-xsm5 xen-build
>>> On 12.12.16 at 18:11, wrote:
> I'll join in the bunfight with a stronger proposal (noting in passing
> that according to https://xenbits.xen.org/xsa/ we are now expecting 5
> consecutive weeks of XSA announcements):
> 1) Where practical, XSA public disclosures will be batched and announced
> o
>>> On 06.12.16 at 12:43, wrote:
> --- a/xen/arch/x86/mm/guest_walk.c
> +++ b/xen/arch/x86/mm/guest_walk.c
> @@ -174,7 +174,6 @@ guest_walk_tables(struct vcpu *v, struct
>
> if ( is_hvm_domain(d) && !(pfec & PFEC_user_mode) )
> {
> -struct segment_register seg;
> const
On 11/17/2016 07:11 AM, Tian, Kevin wrote:
>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
>> Sent: Wednesday, November 16, 2016 3:49 PM
>>
>> On 11/16/2016 09:22 AM, Tian, Kevin wrote:
>>> Looks not working with APICv virtual interrupt delivery...
>>
>> It's only meant to work with "re
>>> On 12.12.16 at 17:04, wrote:
> Update the structure of the FADT table to version 5, and use that version for
> PVHv2 guests. Note that HVM guests will continue to use FADT 4. In order to do
> this, add a new field to acpi_config that contains the ACPI revision to use by
> libacpi. Note that cu
>>> On 12.12.16 at 17:04, wrote:
> At the moment this flag is unconditionally set for PVHv2 domains. Note that
> using this boot flag requires that the FADT table revision is at least 5 (or
> any
> later version), so bump the current FADT version from 4 to 5 and add two new
> fields that will be
>>> On 13.12.16 at 09:50, wrote:
> On 11/17/2016 07:11 AM, Tian, Kevin wrote:
>>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
>>> Sent: Wednesday, November 16, 2016 3:49 PM
>>>
>>> On 11/16/2016 09:22 AM, Tian, Kevin wrote:
Looks not working with APICv virtual interrupt delivery.
On 12/13/2016 11:09 AM, Jan Beulich wrote:
On 13.12.16 at 09:50, wrote:
>> On 11/17/2016 07:11 AM, Tian, Kevin wrote:
From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
Sent: Wednesday, November 16, 2016 3:49 PM
On 11/16/2016 09:22 AM, Tian, Kevin wrote:
> Looks
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 12 December 2016 18:30
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant ; Boris
> Ostrovsky
> Subject: [PATCH 2/2] xen: Fix determining when domain creation is complete
>
> d->creation
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 12 December 2016 18:30
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant ; Boris
> Ostrovsky
> Subject: [PATCH 1/2] x86/hvm: Fix HVMOP_get_param when skipping
> creating the default iore
At 01:45 -0700 on 13 Dec (1481593536), Jan Beulich wrote:
> > --- a/xen/arch/x86/mm/shadow/common.c
> > +++ b/xen/arch/x86/mm/shadow/common.c
> > @@ -1779,7 +1779,7 @@ void *sh_emulate_map_dest(struct vcpu *v
> > #ifndef NDEBUG
> > /* We don't emulate user-mode writes to page tables. */
> >
>>> On 12.12.16 at 19:29, wrote:
> d->creation_finished is used in several places alter behaviour depending on
> whether the domain is being created, or is already running.
>
> However, there is a latent bug if a toolstack component makes a pair of
> pause/unpause calls, where creation will be co
> On Dec 9, 2016, at 6:57 AM, Tamas K Lengyel
> wrote:
>
> This patch relocates mem_access components that are currently mixed with p2m
> code into separate files. This better aligns the code with similar subsystems,
> such as mem_sharing and mem_paging, which are already in separate files. The
On 12/13/2016 04:09 PM, Jan Beulich wrote:
On 13.12.16 at 09:50, wrote:
On 11/17/2016 07:11 AM, Tian, Kevin wrote:
From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
Sent: Wednesday, November 16, 2016 3:49 PM
On 11/16/2016 09:22 AM, Tian, Kevin wrote:
Looks not working with APICv vir
On Tue, Dec 13, 2016 at 01:37:46AM -0700, Jan Beulich wrote:
> >>> On 12.12.16 at 20:18, wrote:
> > flight 103162 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/103162/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tes
This involves protmode_load_seg() accepting x86_seg_none as input, with
the meaning to
- suppress any exceptions other than #PF,
- not commit any state.
Signed-off-by: Jan Beulich
---
v2: Extend commit message and add a respective code comment. Add
ASSERT()s to ensure/document that only #PF c
1: x86/32on64: use generic instruction decoding for call gate emulation
2: x86emul: generalize exception handling for rep_* hooks
3: x86emul: make write and cmpxchg hooks optional
4: x86/PV: use generic emulator for privileged instruction handling
5: x86/PV: prefer pv_inject_hw_exception()
Signed-
Commit-ID: 9d85eb9119f4eeeb48e87adfcd71f752655700e9
Gitweb: http://git.kernel.org/tip/9d85eb9119f4eeeb48e87adfcd71f752655700e9
Author: Thomas Gleixner
AuthorDate: Mon, 12 Dec 2016 11:04:53 +0100
Committer: Thomas Gleixner
CommitDate: Tue, 13 Dec 2016 10:22:39 +0100
x86/smpboot: Make lo
... 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
---
v4: Drop a redundant conditional and the then pointless __addr_ok()
check. Deliver exceptions when getting
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
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
---
v4: Don't open-code fail_if(). Add ASSERT()s for fetch and read hooks.
Move a write hook check closer to its use, and add ASSERT()s and
comme
There's a new emulator return code being added to allow bypassing
certain operations (see the code comment).
Another 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 r
... over editing the error code and calling do_guest_trap().
Signed-off-by: Jan Beulich
---
v4: New.
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3565,20 +3565,17 @@ static void emulate_gate_op(struct cpu_u
((ar >> 13) & 3) > (regs->cs & 3) :
((ar >> 13) & 3) !
Thanks to everyone for your attention.
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation"):
> On Mon, Dec 12, 2016 at 8:45 AM, Ian Jackson
> wrote:
> > AIUI the documented behavour is that "every set of successful
> > transactions is seriali
On 13/12/16 11:43, Wei Liu wrote:
> On Tue, Dec 13, 2016 at 01:37:46AM -0700, Jan Beulich wrote:
> On 12.12.16 at 20:18, wrote:
>>> flight 103162 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/103162/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed a
On Tue, Dec 13, 2016 at 02:03:06AM -0700, Jan Beulich wrote:
> >>> On 12.12.16 at 17:04, wrote:
> > Update the structure of the FADT table to version 5, and use that version
> > for
> > PVHv2 guests. Note that HVM guests will continue to use FADT 4. In order to
> > do
> > this, add a new field t
On Tue, Dec 13, 2016 at 12:35:13PM +0100, Juergen Gross wrote:
> On 13/12/16 11:43, Wei Liu wrote:
> > On Tue, Dec 13, 2016 at 01:37:46AM -0700, Jan Beulich wrote:
> > On 12.12.16 at 20:18, wrote:
> >>> flight 103162 xen-unstable real [real]
> >>> http://logs.test-lab.xenproject.org/osstest/lo
Hello,
I bring this query up now as I realise it will influence how I proceed
with the MSR and CPUID faulting improvements.
During the most recent Cambridge Hackathon (April 2016), there was a
suggestion made (sorry - I don't recall from whom) to feed the the
SVM/VMX intercept information into a
flight 103190 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103190/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 9 debian-di-installfail REGR. vs. 103065
Regressions which are r
This patchset fixes bugs and adds missing checks in nvmx_handle_vmxon(),
in order to make it more consistent to Intel SDM (section "VMXON - Enter
VMX Operation" in Vol 3).
Haozhong Zhang (3):
vvmx: set vmxon_region_pa of vcpu out of VMX operation to an invalid address
vvmx: return VMfail to L1
Check whether the operand of L1 vmxon is a valid VMXON region address
and whether the VMXON region at that address contains a valid revision
ID.
Signed-off-by: Haozhong Zhang
---
xen/arch/x86/hvm/vmx/vvmx.c | 16
1 file changed, 16 insertions(+)
diff --git a/xen/arch/x86/hvm/vm
nvmx_handle_vmxon() previously checks whether a vcpu is in VMX
operation by comparing its vmxon_region_pa with GPA 0. However, 0 is
also a valid VMXON region address. If L1 hypervisor had set the VMXON
region address to 0, the check in nvmx_handle_vmxon() will be skipped.
Fix this problem by using
According to Intel SDM, section "VMXON - Enter VMX Operation", a
VMfail should be returned to L1 hypervisor if L1 vmxon is executed in
VMX operation, rather than just print a warning message.
Signed-off-by: Haozhong Zhang
---
xen/arch/x86/hvm/vmx/vvmx.c | 9 ++---
1 file changed, 6 insertion
flight 103165 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103165/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 101737
test-amd64-amd64-xl
Hello Tamas,
On 12/12/16 23:47, Tamas K Lengyel wrote:
On Mon, Dec 12, 2016 at 2:28 PM, Julien Grall wrote:
On 12/12/2016 19:41, Tamas K Lengyel wrote:
On Mon, Dec 12, 2016 at 12:11 PM, Julien Grall
wrote:
On 12/12/16 18:42, Tamas K Lengyel wrote:
On Mon, Dec 12, 2016 at 4:46 AM, Julien Gr
flight 103254 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103254/
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
Hi Razvan,
On 13/12/16 09:14, Razvan Cojocaru wrote:
On 12/13/2016 11:09 AM, Jan Beulich wrote:
On 13.12.16 at 09:50, wrote:
On 11/17/2016 07:11 AM, Tian, Kevin wrote:
From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
Sent: Wednesday, November 16, 2016 3:49 PM
On 11/16/2016 09:22 AM,
>>> On 13.12.16 at 13:00, wrote:
> During the most recent Cambridge Hackathon (April 2016), there was a
> suggestion made (sorry - I don't recall from whom) to feed the the
> SVM/VMX intercept information into a slightly more general emulate
> framework, rather than to try to implement common func
Hi Boris,
On 12/12/16 16:11, Boris Ostrovsky wrote:
On 12/12/2016 08:28 AM, Julien Grall wrote:
Hi Boris,
On 29/11/16 15:33, Boris Ostrovsky wrote:
This domctl will allow toolstack to read and write some
ACPI registers. It will be available to both x86 and ARM
but will be implemented first on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-9932 / XSA-200
version 3
x86 CMPXCHG8B emulation fails to ignore operand size override
UPDATES IN VERSION 3
CVE assigned.
Public release.
ISSUE DESC
>>> On 13.12.16 at 09:50, wrote:
> On 11/17/2016 07:11 AM, Tian, Kevin wrote:
>>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
>>> Sent: Wednesday, November 16, 2016 3:49 PM
>>>
>>> On 11/16/2016 09:22 AM, Tian, Kevin wrote:
Looks not working with APICv virtual interrupt delivery.
On 12/13/2016 03:18 PM, Jan Beulich wrote:
On 13.12.16 at 09:50, wrote:
>> On 11/17/2016 07:11 AM, Tian, Kevin wrote:
From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
Sent: Wednesday, November 16, 2016 3:49 PM
On 11/16/2016 09:22 AM, Tian, Kevin wrote:
> Looks
Especially some of the later patches are only loosely coupled to that
XSA, but they all needed to be withheld because of it.
1: CMPXCHG{8,16}B ignore prefixes
2: reduce CMPXCHG{8,16}B footprint
3: check for CMPXCHG8B availability
4: check for CLFLUSH{,OPT} availability
5: check for LAHF_LM availab
On Tue, Dec 06, 2016 at 03:50:46PM -0800, Laura Abbott wrote:
> Hi,
>
> This is v5 of the series to add CONFIG_DEBUG_VIRTUAL for arm64. This mostly
> contains minor fixups including adding a few extra headers around and
> splitting
> things out into a few more sub-patches.
>
> With a few more ac
Several stubdom libraries are being rebuilt each time a top level make
is called as they depend on stubdom/ioemu/linkfarm.stamp which is
depending on tools/qemu-xen-traditional-dir. Unfortunately this
directory is modified by each "make tools" call.
This can be avoided by writing stubdom/ioemu/lin
Hi Stefano,
On 10/12/16 01:31, Stefano Stabellini wrote:
The rt variable can only be 0 or 7, no need to check if it's 15.
Be careful, Coverity may point to dead code but it does not mean that
deleting it is the right thing to do. The code which lead to this
conclusion may be invalid. In this
This removes 0F C7 from the list of two-byte opcodes treating prefixes
66, F3, and F2 as opcode extensions. We better manually handle this in
the opcode specific code:
- CMPXCHG8B ignores all these prefixes (its handling is being adjusted
accordingly, with a respective test case added as well, to
Re-use an existing stack variable (reducing stack footprint, which also
results in smaller code due to some stack accesses no longer needing a
32-bit displacement), at once using a union instead of casts. Also
switch to rex_prefix based conditionals instead of op_bytes ones.
Signed-off-by: Jan Beu
We can't exclude someone wanting to hide the instruction from guests.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1285,6 +1285,7 @@ static bool vcpu_has(
}
#define vcpu_has_fpu() vcpu_has( 1, EDX, 0
We can't exclude someone wanting to hide either of the instructions
from guests.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1296,6 +1296,7 @@ static bool vcpu_has(
#define vcpu_has_hle() vcpu_has( 7, E
We can't exclude someone wanting to hide the instructions from guests.
Signed-off-by: Jan Beulich
---
Looks like I can't count - I've mistakenly omitted this patch from
the overview mail, so there'll be a total of 7.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86
Hi Bhupinder,
On 12/12/16 07:26, Bhupinder Thakur wrote:
Since VMIDs are related to 2nd stage address translation, it makes more sense
to move the call to p2m_vmid_allocator_init(), which initializes the vmid
allocation bitmap, inside setup_virt_paging(), where 2nd stage address
translation
is
We can't exclude someone wanting to hide LAHF/SAHF from 64-bit guests.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1291,6 +1291,7 @@ static bool vcpu_has(
#define vcpu_has_sse4_2() vcpu_has( 1, ECX, 20, ct
On 13/12/16 14:06, Julien Grall wrote:
Hi Bhupinder,
On 12/12/16 07:26, Bhupinder Thakur wrote:
Since VMIDs are related to 2nd stage address translation, it makes
more sense
to move the call to p2m_vmid_allocator_init(), which initializes the vmid
allocation bitmap, inside setup_virt_paging()
Just like 66, prefixes F3 and F2 cause #UD.
Also adjust a related comment, which in its previous wording was
misleading (as in 16-bit mode there would nothing be undone when
adjusting operand size from 2 to 4).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/ar
Hi Bhupinder,
On 12/12/16 07:26, Bhupinder Thakur wrote:
[...]
-void p2m_vmid_allocator_init(void)
+int p2m_vmid_allocator_init(void)
{
-set_bit(INVALID_VMID, vmid_mask);
+int ret = 0;
+
+/*
+ * allocate space for vmid_mask based on MAX_VMID
+ */
+vmid_mask = xzalloc_a
Hi Stefano,
On 12/12/16 19:22, Stefano Stabellini wrote:
pa_range_info has only 8 elements and is accessed using pa_range as
index. pa_range is initialized to 16, potentially causing out of bound
access errors. Fix the issue by checking that pa_range is not greater
than the size of the array. Re
On 13/12/16 14:01, Jan Beulich wrote:
> This removes 0F C7 from the list of two-byte opcodes treating prefixes
> 66, F3, and F2 as opcode extensions. We better manually handle this in
> the opcode specific code:
> - CMPXCHG8B ignores all these prefixes (its handling is being adjusted
> accordingl
On Tue, Dec 13, 2016 at 5:30 AM, Ian Jackson wrote:
> I am concerned that there are other possible bugs of this form.
> In earlier messages on this topic, it has been suggested that the
> "impossible" unique constraint violation is only one example of a
> possible "leakage".
As I see it, the mai
On 12/13/2016 03:18 PM, Jan Beulich wrote:
On 13.12.16 at 09:50, wrote:
>> On 11/17/2016 07:11 AM, Tian, Kevin wrote:
From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
Sent: Wednesday, November 16, 2016 3:49 PM
On 11/16/2016 09:22 AM, Tian, Kevin wrote:
> Looks
On 13/12/16 14:02, Jan Beulich wrote:
> Re-use an existing stack variable (reducing stack footprint, which also
> results in smaller code due to some stack accesses no longer needing a
> 32-bit displacement), at once using a union instead of casts. Also
> switch to rex_prefix based conditionals ins
On 13/12/16 14:03, Jan Beulich wrote:
> We can't exclude someone wanting to hide the instruction from guests.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Tue, Dec 13, 2016 at 10:58:53AM +0530, George John wrote:
> no, I meant some embedded platform like say for example minnowboard. Any
> other boards like minnowboard?
Based n
https://ark.intel.com/products/78477/Intel-Atom-Processor-E3826-1M-Cache-1_46-GHz
It has 64-bit support so you are all
On 13/12/16 14:03, Jan Beulich wrote:
> We can't exclude someone wanting to hide either of the instructions
> from guests.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.o
On 13/12/16 14:06, Jan Beulich wrote:
> We can't exclude someone wanting to hide the instructions from guests.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 13/12/16 14:07, Jan Beulich wrote:
> We can't exclude someone wanting to hide LAHF/SAHF from 64-bit guests.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 13/12/16 14:11, Jan Beulich wrote:
> Just like 66, prefixes F3 and F2 cause #UD.
>
> Also adjust a related comment, which in its previous wording was
> misleading (as in 16-bit mode there would nothing be undone when
> adjusting operand size from 2 to 4).
>
> Signed-off-by: Jan Beulich
Reviewe
On 13/12/16 12:16, Haozhong Zhang wrote:
> nvmx_handle_vmxon() previously checks whether a vcpu is in VMX
> operation by comparing its vmxon_region_pa with GPA 0. However, 0 is
> also a valid VMXON region address. If L1 hypervisor had set the VMXON
> region address to 0, the check in nvmx_handle_vm
On 13/12/16 12:16, Haozhong Zhang wrote:
> According to Intel SDM, section "VMXON - Enter VMX Operation", a
> VMfail should be returned to L1 hypervisor if L1 vmxon is executed in
> VMX operation, rather than just print a warning message.
>
> Signed-off-by: Haozhong Zhang
Reviewed-by: Andrew Coop
Added support for a new event type, VM_EVENT_REASON_INTERRUPT,
which is now fired in a one-shot manner when enabled via the new
VM_EVENT_FLAG_GET_NEXT_INTERRUPT vm_event response flag.
The patch also fixes the behaviour of the xc_hvm_inject_trap()
hypercall, which would lead to non-architectural in
On 13/12/16 12:16, Haozhong Zhang wrote:
> Check whether the operand of L1 vmxon is a valid VMXON region address
> and whether the VMXON region at that address contains a valid revision
> ID.
>
> Signed-off-by: Haozhong Zhang
Reviewed-by: Andrew Cooper
__
>>> On 13.12.16 at 15:17, wrote:
> While re-basing the patch on staging, I've got this (unrelated) error
> while doing 'make dist':
>
> make[9]: Entering directory `~/work/xen.git/tools/firmware/rombios/32bit'
> gcc -m32 -march=i686 -DBUILD_ID -g -fno-strict-aliasing -std=gnu99
> -Wall -Wstrict
On Tue, Dec 13, 2016 at 02:35:33PM +, Andrew Cooper wrote:
> On 13/12/16 12:16, Haozhong Zhang wrote:
> > nvmx_handle_vmxon() previously checks whether a vcpu is in VMX
> > operation by comparing its vmxon_region_pa with GPA 0. However, 0 is
> > also a valid VMXON region address. If L1 hypervis
>>> On 13.12.16 at 15:26, wrote:
> On 13/12/16 14:02, Jan Beulich wrote:
>> --- a/tools/tests/x86_emulator/x86_emulate.h
>> +++ b/tools/tests/x86_emulator/x86_emulate.h
>> @@ -31,6 +31,11 @@
>> #define likely(x) __builtin_expect(!!(x), true)
>> #define unlikely(x) __builtin_expect(!!(x), false
After 5623e2d2 ("x86: use unified linker script") the linker script for
x86 build is generated. But the special rule to generate linker script
doesn't have OBJ_DIR prepended so in parallel build the same file is
written multiple times. This is racy and would cause parallel build to
fail.
Fix this
On Tue, Dec 13, 2016 at 02:58:27PM +0100, Juergen Gross wrote:
> Several stubdom libraries are being rebuilt each time a top level make
> is called as they depend on stubdom/ioemu/linkfarm.stamp which is
> depending on tools/qemu-xen-traditional-dir. Unfortunately this
> directory is modified by ea
On Tue, Dec 13, 2016 at 08:16:19PM +0800, Haozhong Zhang wrote:
> According to Intel SDM, section "VMXON - Enter VMX Operation", a
> VMfail should be returned to L1 hypervisor if L1 vmxon is executed in
> VMX operation, rather than just print a warning message.
The spec also says to return value 1
On Tue, Dec 13, 2016 at 03:02:02PM +, Wei Liu wrote:
> After 5623e2d2 ("x86: use unified linker script") the linker script for
> x86 build is generated. But the special rule to generate linker script
> doesn't have OBJ_DIR prepended so in parallel build the same file is
> written multiple times
On 13/12/16 16:02, Wei Liu wrote:
> After 5623e2d2 ("x86: use unified linker script") the linker script for
> x86 build is generated. But the special rule to generate linker script
> doesn't have OBJ_DIR prepended so in parallel build the same file is
> written multiple times. This is racy and woul
On Tue, Dec 13, 2016 at 08:16:20PM +0800, Haozhong Zhang wrote:
> Check whether the operand of L1 vmxon is a valid VMXON region address
> and whether the VMXON region at that address contains a valid revision
> ID.
>
> Signed-off-by: Haozhong Zhang
Reviewed-by: Konrad Rzeszutek Wilk
Thank you
>>> On 13.12.16 at 13:16, wrote:
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -32,6 +32,18 @@ static DEFINE_PER_CPU(u64 *, vvmcs_buf);
>
> static void nvmx_purge_vvmcs(struct vcpu *v);
>
> +/*
> + * When a vcpu is out of VMXON region, set its vmxon_region_pa to
>>> On 13.12.16 at 13:16, wrote:
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -32,6 +32,18 @@ static DEFINE_PER_CPU(u64 *, vvmcs_buf);
>
> static void nvmx_purge_vvmcs(struct vcpu *v);
>
> +/*
> + * When a vcpu is out of VMXON region, set its vmxon_region_pa to
On 13/12/16 16:15, Wei Liu wrote:
> On Tue, Dec 13, 2016 at 02:58:27PM +0100, Juergen Gross wrote:
>> Several stubdom libraries are being rebuilt each time a top level make
>> is called as they depend on stubdom/ioemu/linkfarm.stamp which is
>> depending on tools/qemu-xen-traditional-dir. Unfortuna
On Tue, Dec 13, 2016 at 04:24:01PM +0100, Juergen Gross wrote:
> On 13/12/16 16:15, Wei Liu wrote:
> > On Tue, Dec 13, 2016 at 02:58:27PM +0100, Juergen Gross wrote:
> >> Several stubdom libraries are being rebuilt each time a top level make
> >> is called as they depend on stubdom/ioemu/linkfarm.s
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 13 December 2016 11:28
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
>
> Subject: [PATCH v4 2/5] x86emul: generalize exception handling for rep_*
> hooks
>
> If any of those hooks returns X86EMUL_EXCEPTION,
Several stubdom libraries are being rebuilt each time a top level make
is called as they depend on stubdom/ioemu/linkfarm.stamp which is
depending on tools/qemu-xen-traditional-dir. Unfortunately this
directory is modified by each "make tools" call.
This can be avoided by writing stubdom/ioemu/lin
On 13/12/16 12:55, Jan Beulich wrote:
On 13.12.16 at 13:00, wrote:
>> During the most recent Cambridge Hackathon (April 2016), there was a
>> suggestion made (sorry - I don't recall from whom) to feed the the
>> SVM/VMX intercept information into a slightly more general emulate
>> framework,
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation [and 2 more messages]"):
> On Tue, Dec 13, 2016 at 5:30 AM, Ian Jackson
> wrote:
> > Are all of these cases fixed by fcff8a57519847 "Detect SSI conflicts
> > before reporting constraint violati
flight 103265 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103265/
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
Hello, and first of all thanks for the discussion!
> Think of it a bit more like introducing a new action emulator (name
> definitely subject to improvement), which implements things such as
> wrmsr, cpuid, pagewalk, task_switch, etc.
>
> The vmexit helpers, given decode assistance from hardware,
On 13/12/16 11:26, 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
Reviewed-by: Andrew Cooper
_
On 13/12/16 11:28, Jan Beulich wrote:
> 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
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-dev
Jan Beulich writes ("Re: [PATCH 1/8] libelf: loop safety: Introduce elf_iter_ok
and elf_strcmp_safe"):
> On 12.12.16 at 17:56, wrote:
> > I have replaced the limit with a comment. Now I have:
> >
> > elf->iteration_deaccumulator =
> > 1024*1024 + size * ELF_MAX_ITERATION_FACTOR;
branch xen-4.4-testing
xenbranch xen-4.4-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 13/12/16 11:29, Jan Beulich wrote:
> ... over editing the error code and calling do_guest_trap().
>
> Signed-off-by: Jan Beulich
Thanks for doing this. It was somewhere on my TODO list. I'd like to
drop do_guest_trap() entirely, eventually.
Reviewed-by: Andrew Cooper
_
1 - 100 of 205 matches
Mail list logo
