flight 103755 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103755/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 3 host-install(3) broken REGR. vs
>>> On 19.12.16 at 17:37, wrote:
> Having the instruction emulator fill in all #UDs when using FEP is unhelpful
> when trying to test emulation behaviour against hardware.
>
> Restrict emulation from the #UD intercept to the cross-vendor case, and when a
> postive Forced Emulation Prefix has been
AMD explicitly documents that namely FS and GS don't have their bases
cleared in that case, and I see no reason why guests may not rely on
that behavior. To facilitate this a new input field (the CPU vendor) is
being added.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emula
>>> On 19.12.16 at 17:37, wrote:
> Introduce vendor_is() to allow emulation to have vendor-specific
> behaviour. Adjust the SYSCALL behaviour on Intel to raise #UD when
> executed outside of 64bit mode.
I'd rather not see us go this route. I've been carrying a patch
making the vendor an input (n
>>> On 20.12.16 at 06:54, wrote:
> On December 20, 2016 1:37 PM, Tian, Kevin wrote:
>>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>>> Sent: Friday, December 16, 2016 5:40 PM
>>>
>>> From 89fffdd6b563b2723e24d17231715bb8c9f24f90 Mon Sep 17 00:00:00
>>2001
>>> From: Quan Xu
>>> Date: Fri,
>>> On 20.12.16 at 06:37, wrote:
>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>> Sent: Friday, December 16, 2016 5:40 PM
>> -if (pt_vector != -1)
>> -vmx_set_eoi_exit_bitmap(v, pt_vector);
>> +if ( pt_vector != -1 ) {
>> +if ( intack.vector > pt_ve
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, December 20, 2016 4:35 PM
>
> >>> On 20.12.16 at 06:37, wrote:
> >> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
> >> Sent: Friday, December 16, 2016 5:40 PM
> >> -if (pt_vector != -1)
> >> -vmx_set_eoi_exi
>>> On 20.12.16 at 09:53, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, December 20, 2016 4:35 PM
>>
>> >>> On 20.12.16 at 06:37, wrote:
>> >> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>> >> Sent: Friday, December 16, 2016 5:40 PM
>> >> -if (pt_vecto
>>> On 12.12.16 at 10:38, wrote:
> These patches are grouped together merely because of contextual
> dependencies.
>
> 1: correct EFLAGS.TF handling
> 2: conditionally clear BNDn for branches
> 3: some REX related polishing
>
> Signed-off-by: Jan Beulich
Any word on these? I realize patch 1 wi
Hi Dario,
I tried with 'git am' to apply the patch after downloading the mbox file,
that worked fine. Do let me know if that is ok.
Regards,
~Praveen.
On Sat, Dec 17, 2016 at 1:44 PM, Praveen Kumar
wrote:
> Hi,
>
> On Sat, Dec 17, 2016 at 7:16 AM, Dario Faggioli > wrote:
>
>> On Sat, 2016-12
On 20/12/2016 04:03, Doug Goldstein wrote:
On 12/19/16 10:02 AM, Doug Goldstein wrote:
On 12/14/16 3:09 PM, Daniel De Graaf wrote:
On 12/12/2016 09:00 AM, Anshul Makkar wrote:
During guest migrate allow permission to prevent
spurious page faults.
Prevents these errors:
d73: Non-privileged (73)
On December 20, 2016 4:32 PM, Jan Beulich wrote:
On 20.12.16 at 06:54, wrote:
>> On December 20, 2016 1:37 PM, Tian, Kevin wrote:
From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
Sent: Friday, December 16, 2016 5:40 PM
From 89fffdd6b563b2723e24d17231715bb8c9f24f90 Mon Se
flight 103756 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103756/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xend 3 host-install(3)broken REGR. vs. 10
Hi Stefano,
Thanks for a detailed explanation. I have some queries.
>
> Let me explain how the PV console protocol and drivers work, because
> they are a bit unusual. The first PV console is advertised via
> hvm_params. The guest calls:
>
> hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
> h
This is a first (of three, as far as current plans go) steps to do away
with misleading register names (eax instead of rax).
01: x86/MSR: introduce MSR access split/fold helpers
02: x86/guest-walk: use unambiguous register names
03: x86/shadow: use unambiguous register names
04: x86/oprofile: use
On 20/12/16 06:02, Jiandi An wrote:
> On 12/19/16 12:49, Stefano Stabellini wrote:
>> On Mon, 19 Dec 2016, Juergen Gross wrote:
>>> On 19/12/16 03:56, Jiandi An wrote:
Ensure all reserved fields of xatp are zero before making hypervisor
call to XEN in xen_map_device_mmio(). xenmem_add_to
>>> On 20.12.16 at 10:38, wrote:
> On December 20, 2016 4:32 PM, Jan Beulich wrote:
> On 20.12.16 at 06:54, wrote:
>>> On December 20, 2016 1:37 PM, Tian, Kevin wrote:
> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
> Sent: Friday, December 16, 2016 5:40 PM
>
> From 89fff
On December 20, 2016 4:54 PM, Tian, Kevin wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, December 20, 2016 4:35 PM
>>
>> >>> On 20.12.16 at 06:37, wrote:
>> >> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>> >> Sent: Friday, December 16, 2016 5:40 PM
>> >> -
flight 103771 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103771/
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 Jiandi,
Please respect the netiquette and wrap line to 70-75 characters.
On 20/12/2016 06:02, Jiandi An wrote:
On 12/19/16 12:49, Stefano Stabellini wrote:
On Mon, 19 Dec 2016, Juergen Gross wrote:
On 19/12/16 03:56, Jiandi An wrote:
Thanks for you comments. xatp is passed to XEN via t
This is in preparation of eliminating the mis-naming of 64-bit fields
with 32-bit register names (eflags instead of rflags etc). Use the
guaranteed 32-bit underscore prefixed names for now where appropriate.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@
This is in preparation of eliminating the mis-naming of 64-bit fields
with 32-bit register names (eflags instead of rflags etc). Use the
guaranteed 32-bit underscore prefixed names for now where appropriate.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/gues
This is in preparation of eliminating the mis-naming of 64-bit fields
with 32-bit register names (eflags instead of rflags etc).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -348,10 +348,10 @@ const struct x86_emulate_ops *shadow_ini
This is in preparation of eliminating the mis-naming of 64-bit fields
with 32-bit register names (eflags instead of rflags etc).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/oprofile/backtrace.c
+++ b/xen/arch/x86/oprofile/backtrace.c
@@ -150,7 +150,7 @@ static int valid_hypervisor_stack(const
This is in preparation of eliminating the mis-naming of 64-bit fields
with 32-bit register names (eflags instead of rflags etc). Use the
guaranteed 32-bit underscore prefixed names for now where appropriate.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@
This is in preparation of eliminating the mis-naming of 64-bit fields
with 32-bit register names (eflags instead of rflags etc). Use the
guaranteed 32-bit underscore prefixed names for now where appropriate.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emula
This is in preparation of eliminating the mis-naming of 64-bit fields
with 32-bit register names (eflags instead of rflags etc). Use the
guaranteed 32-bit underscore prefixed names for now where appropriate.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm
This is in preparation of eliminating the mis-naming of 64-bit fields
with 32-bit register names (eflags instead of rflags etc).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -112,14 +112,14 @@ void vm_event_set_registers(struct vcpu
{
ASSERT(ato
This is in preparation of eliminating the mis-naming of 64-bit fields
with 32-bit register names (eflags instead of rflags etc). Use the
guaranteed 32-bit underscore prefixed names for now where appropriate.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -202
This is in preparation of eliminating the mis-naming of 64-bit fields
with 32-bit register names (eflags instead of rflags etc). Use the
guaranteed 32-bit underscore prefixed names for now where appropriate.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@
At 03:38 -0700 on 20 Dec (1482205097), Jan Beulich wrote:
> This is in preparation of eliminating the mis-naming of 64-bit fields
> with 32-bit register names (eflags instead of rflags etc).
>
> Signed-off-by: Jan Beulich
Acked-by: Tim Deegan
___
Xen
>>> On 17.12.16 at 00:18, wrote:
> --- a/xen/include/public/arch-x86/hvm/save.h
> +++ b/xen/include/public/arch-x86/hvm/save.h
> @@ -527,7 +527,37 @@ DECLARE_HVM_SAVE_TYPE(HPET, 12, struct hvm_hw_hpet);
> /*
> * PM timer
> */
> +#if __XEN_INTERFACE_VERSION__ >= 0x00040800
> +struct hvm_hw_pmt
Hi Stefano,
On 20/12/2016 00:22, Stefano Stabellini wrote:
On Mon, 19 Dec 2016, Julien Grall wrote:
Hi Stefano,
On 19/12/2016 23:30, Stefano Stabellini wrote:
On Mon, 19 Dec 2016, Julien Grall wrote:
2) We run gic_update_one_lr and vgic_store_itargetsr in parallel
safely
and locklessly. Ther
On 20/12/2016 09:04, Jan Beulich wrote:
On 12.12.16 at 10:38, wrote:
>> These patches are grouped together merely because of contextual
>> dependencies.
>>
>> 1: correct EFLAGS.TF handling
>> 2: conditionally clear BNDn for branches
>> 3: some REX related polishing
>>
>> Signed-off-by: Jan Be
On 12/12/2016 10:00, Jan Beulich wrote:
> While there are a few cases where it seems better to open-code REX_*
> values, there's one where this clearly is a bad idea. And the SYSEXIT
> emulation has no need to look at REX at all, it can simply use op_bytes
> instead.
>
> Signed-off-by: Jan Beulich
flight 103763 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103763/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 83c6c3bfe293cd0a5983375dfbf46d4f364b38aa
baseline version:
ovmf 15dae68589243726f0374
Hi Jiandi,
On 20/12/2016 07:31, Jiandi An wrote:
On 12/19/16 07:11, Julien Grall wrote:
On 19/12/2016 13:20, Jaggi, Manish wrote:
On 16/12/2016 15:49, Julien Grall wrote:
On 14/12/16 08:00, Jiandi An wrote:
Xen currently doesn't map ECAM space specified in static ACPI table.
Seeking opinio
>>> On 17.12.16 at 00:18, wrote:
> +static int acpi_cpumap_access_common(struct domain *d,
> + int dir, unsigned int port,
> + unsigned int bytes, uint32_t *val)
> +{
> +unsigned int first_byte = port - XEN_ACPI_CPU_MAP;
>
>>> On 20.12.16 at 12:30, wrote:
> On 20/12/2016 09:04, Jan Beulich wrote:
> On 12.12.16 at 10:38, wrote:
>>> These patches are grouped together merely because of contextual
>>> dependencies.
>>>
>>> 1: correct EFLAGS.TF handling
>>> 2: conditionally clear BNDn for branches
>>> 3: some REX re
On 20/12/2016 08:18, Jan Beulich wrote:
> AMD explicitly documents that namely FS and GS don't have their bases
> cleared in that case, and I see no reason why guests may not rely on
> that behavior. To facilitate this a new input field (the CPU vendor) is
> being added.
>
> Signed-off-by: Jan Beul
osstest service owner writes ("[xen-4.4-testing test] 103756: trouble:
blocked/broken/fail/pass"):
> flight 103756 xen-4.4-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/103756/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking,
> i
Hi Stefano,
On 20/12/2016 00:54, Stefano Stabellini wrote:
On Mon, 19 Dec 2016, Julien Grall wrote:
On 16/12/2016 15:49, Julien Grall wrote:
On 14/12/16 08:00, Jiandi An wrote:
Xen currently doesn't map ECAM space specified in static ACPI table.
Seeking opinion on how this should be handled p
On 20/12/2016 08:22, Jan Beulich wrote:
On 19.12.16 at 17:37, wrote:
>> Introduce vendor_is() to allow emulation to have vendor-specific
>> behaviour. Adjust the SYSCALL behaviour on Intel to raise #UD when
>> executed outside of 64bit mode.
> I'd rather not see us go this route. I've been c
On 20/12/2016 07:25, Jan Beulich wrote:
On 19.12.16 at 17:58, wrote:
>> On 19/12/16 16:51, Jan Beulich wrote:
>> On 19.12.16 at 17:38, wrote:
There is no need for the volatile cast in the timer interrupt. pit0_ticks
has
external linkage, preventing the compiler from elid
On 20/12/2016 07:48, Jan Beulich wrote:
>
>> @@ -398,10 +400,11 @@ static void
>> hypercall_page_initialise_ring1_kernel(void *hypercall_page)
>> * calling it.
>> */
>> p = (char *)(hypercall_page + (__HYPERVISOR_iret * 32));
>> -*(u8 *)(p+ 0) = 0x50;/* push %eax */
>> -
Hi Stefano,
On 19/12/2016 21:24, Stefano Stabellini wrote:
On Mon, 19 Dec 2016, Christoffer Dall wrote:
On Fri, Dec 16, 2016 at 05:03:13PM +, Julien Grall wrote:
(CC rest maintainers for event channel questions)
On 16/12/16 10:06, Bhupinder Thakur wrote:
Hi,
Hi Bhupinder,
The idea is
On 15/12/2016 15:09, Jan Beulich wrote:
On 15.12.16 at 12:04, wrote:
>> On 15/12/16 09:49, Jan Beulich wrote:
>> On 06.12.16 at 11:51, wrote:
As such clearing of flags may have an impact on the selected rendezvous
function, handle such in a central place.
But don't al
From: "Edgar E. Iglesias"
This patch changes the mapping from non-cached to cached
for mmio-sram nodes that do not have the no-memory-wc property.
This is a hang-over from 4.8 since the mmio-sram patches went
in late in the cycle.
I've explained the rationale in the commit message:
Although
From: "Edgar E. Iglesias"
Relax the mapping of mmio-sram nodes that do not set the
no-memory-wc property to cached normal memory.
Rationale:
Although on chip memories are relatively fast compared to
off-chip memories, large on chip memories are still
significantly slower than L1 caches. Dependin
Hi Stefano,
On Mon, Dec 19, 2016 at 12:24:18PM -0800, Stefano Stabellini wrote:
> On Mon, 19 Dec 2016, Christoffer Dall wrote:
> > On Fri, Dec 16, 2016 at 05:03:13PM +, Julien Grall wrote:
> > > (CC rest maintainers for event channel questions)
> > >
> > > On 16/12/16 10:06, Bhupinder Thakur
On Mon, Dec 19, 2016 at 04:01:00PM -0800, Stefano Stabellini wrote:
> On Mon, 19 Dec 2016, Julien Grall wrote:
> > Hi Edgar,
> >
> > On 16/12/2016 18:04, Edgar E. Iglesias wrote:
> > > On Fri, Dec 16, 2016 at 04:12:00PM +, Julien Grall wrote:
> > > > On 15/12/16 11:26, Edgar E. Iglesias wrote:
>>> On 20.12.16 at 13:17, wrote:
> On 20/12/2016 07:25, Jan Beulich wrote:
> On 19.12.16 at 17:58, wrote:
>>> On 19/12/16 16:51, Jan Beulich wrote:
>>> On 19.12.16 at 17:38, wrote:
> There is no need for the volatile cast in the timer interrupt.
> pit0_ticks has
> external
>>> On 20.12.16 at 13:21, wrote:
> On 20/12/2016 07:48, Jan Beulich wrote:
>>
>>> @@ -398,10 +400,11 @@ static void
>>> hypercall_page_initialise_ring1_kernel(void
> *hypercall_page)
>>> * calling it.
>>> */
>>> p = (char *)(hypercall_page + (__HYPERVISOR_iret * 32));
>>> -*
>>> On 20.12.16 at 13:14, wrote:
> On 20/12/2016 08:22, Jan Beulich wrote:
> On 19.12.16 at 17:37, wrote:
>> What I've been thinking the other day though is: Why
>> don't we put the whole SYSCALL emulation into a __XEN__
>> conditional (implying __x86_64__, i.e. allowing the inner ones
>> to
>>> On 20.12.16 at 12:59, wrote:
> osstest service owner writes ("[xen-4.4-testing test] 103756: trouble:
> blocked/broken/fail/pass"):
>> flight 103756 xen-4.4-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/103756/
>>
>> Failures and problems with tests :-(
>>
>> Test
On December 20, 2016 1:37 PM, Tian, Kevin wrote:
>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>> Sent: Friday, December 16, 2016 5:40 PM
>I suppose you've verified this new version, but still would like get your
>explicit confirmation - did you still see time accuracy issue in your side?
>
On Tue, 2016-12-20 at 14:34 +0530, Praveen Kumar wrote:
> Hi Dario,
>
> I tried with 'git am' to apply the patch after downloading the mbox
> file, that worked fine. Do let me know if that is ok.
>
Well, if you tried and it works, I'm sure it is. I don't really use
`git am` as part of my workload
>>> On 17.12.16 at 00:18, wrote:
> @@ -32,14 +34,15 @@ static int acpi_cpumap_access_common(struct domain *d,
> memcpy(val, (uint8_t *)d->avail_vcpus + first_byte,
> min(bytes, ((d->max_vcpus + 7) / 8) - first_byte));
> }
> -else
> +else if ( !is_guest
>>> On 17.12.16 at 00:18, wrote:
> @@ -128,6 +130,13 @@ static int acpi_access_common(struct domain *d, bool
> is_guest_access,
> *en = (((v & 0xff) << 8) | (*en & 0xff)) & *mask_en;
> break;
> }
> +
> +/*
> + * If a new bit has been set in statu
>>> On 17.12.16 at 00:18, wrote:
> --- a/xen/arch/x86/hvm/pmtimer.c
> +++ b/xen/arch/x86/hvm/pmtimer.c
> @@ -257,7 +257,11 @@ static int acpi_save(struct domain *d,
> hvm_domain_context_t *h)
> int rc;
>
> if ( !has_vpm(d) )
> +{
> +if ( !has_acpi_dm_ff(d) )
> +
To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang
---
drivers/block/xen-blkback/blkback.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
b/drivers/block/xen-blkback
To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang
---
drivers/xen/evtchn.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index e8c7f09..6890897 100644
--- a/dri
On 12/20/2016 06:24 AM, Jan Beulich wrote:
On 17.12.16 at 00:18, wrote:
>> --- a/xen/include/public/arch-x86/hvm/save.h
>> +++ b/xen/include/public/arch-x86/hvm/save.h
>> @@ -527,7 +527,37 @@ DECLARE_HVM_SAVE_TYPE(HPET, 12, struct hvm_hw_hpet);
>> /*
>> * PM timer
>> */
>> +#if __XEN_INT
>>> On 20.12.16 at 15:03, wrote:
> On 12/20/2016 06:24 AM, Jan Beulich wrote:
> On 17.12.16 at 00:18, wrote:
>>> --- a/xen/include/public/arch-x86/hvm/save.h
>>> +++ b/xen/include/public/arch-x86/hvm/save.h
>>> @@ -527,7 +527,37 @@ DECLARE_HVM_SAVE_TYPE(HPET, 12, struct hvm_hw_hpet);
>>> /*
On 12/20/2016 09:10 AM, Jan Beulich wrote:
On 20.12.16 at 15:03, wrote:
>> On 12/20/2016 06:24 AM, Jan Beulich wrote:
>> On 17.12.16 at 00:18, wrote:
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -527,7 +527,37 @@ DECLARE_HVM_
On 12/20/2016 06:50 AM, Jan Beulich wrote:
>
>> +
>> +if ( dir == XEN_DOMCTL_ACPI_READ )
>> +{
>> +uint32_t mask = (bytes < 4) ? ~0U << (bytes * 8) : 0;
>> +uint32_t data = (((uint32_t)*en) << 16) | *sts;
> There's one pair of pointless parentheses around the cast
> expressi
On 12/20/2016 08:24 AM, Jan Beulich wrote:
>
>> -static int acpi_access_common(struct domain *d,
>> +static int acpi_access_common(struct domain *d, bool is_guest_access,
> Why? I thought the domctl is needed only for updating the CPU
> map? Or maybe it would help if the patch had a non-empty
> des
>>> On 20.12.16 at 15:16, wrote:
> On 12/20/2016 09:10 AM, Jan Beulich wrote:
> On 20.12.16 at 15:03, wrote:
>>> On 12/20/2016 06:24 AM, Jan Beulich wrote:
>>> On 17.12.16 at 00:18, wrote:
> --- a/xen/include/public/arch-x86/hvm/save.h
> +++ b/xen/include/public/arch-x86/hvm/save
>>> On 20.12.16 at 15:35, wrote:
> On 12/20/2016 06:50 AM, Jan Beulich wrote:
>>> +else
>>> +{
>>> +uint32_t v = *val;
>>> +
>>> +/* Status register is write-1-to-clear by guests */
>>> +switch ( port & 3 )
>>> +{
>>> +case 0:
>>> +*sts &
>>> On 20.12.16 at 15:45, wrote:
> On 12/20/2016 08:24 AM, Jan Beulich wrote:
>>
>>> -static int acpi_access_common(struct domain *d,
>>> +static int acpi_access_common(struct domain *d, bool is_guest_access,
>> Why? I thought the domctl is needed only for updating the CPU
>> map? Or maybe it woul
On 20/12/2016 14:45, Jan Beulich wrote:
On 20.12.16 at 15:16, wrote:
>> On 12/20/2016 09:10 AM, Jan Beulich wrote:
>> On 20.12.16 at 15:03, wrote:
On 12/20/2016 06:24 AM, Jan Beulich wrote:
On 17.12.16 at 00:18, wrote:
>> --- a/xen/include/public/arch-x86/hvm/save.h
>>
On 12/20/2016 08:37 AM, Jan Beulich wrote:
On 17.12.16 at 00:18, wrote:
>> @@ -128,6 +130,13 @@ static int acpi_access_common(struct domain *d, bool
>> is_guest_access,
>> *en = (((v & 0xff) << 8) | (*en & 0xff)) & *mask_en;
>> break;
>> }
>> +
>> +
On 12/20/2016 08:57 AM, Jan Beulich wrote:
On 17.12.16 at 00:18, wrote:
>> --- a/xen/arch/x86/hvm/pmtimer.c
>> +++ b/xen/arch/x86/hvm/pmtimer.c
>> @@ -257,7 +257,11 @@ static int acpi_save(struct domain *d,
>> hvm_domain_context_t *h)
>> int rc;
>>
>> if ( !has_vpm(d) )
>> +{
On 12/20/2016 09:47 AM, Jan Beulich wrote:
On 20.12.16 at 15:35, wrote:
>> On 12/20/2016 06:50 AM, Jan Beulich wrote:
+else
+{
+uint32_t v = *val;
+
+/* Status register is write-1-to-clear by guests */
+switch ( port & 3 )
+
On 12/20/2016 09:55 AM, Andrew Cooper wrote:
>>> Is this file is not supposed to be used by anyone outside of the Xen tree?
>> I don't think so, no. In any event - prior additions did not do
>> any precautions to guard possible foreign consumers. Maybe
>> Andrew has an opinion here ...
> Our polici
>>> On 20.12.16 at 16:09, wrote:
> On 12/20/2016 08:57 AM, Jan Beulich wrote:
> On 17.12.16 at 00:18, wrote:
>>> --- a/xen/arch/x86/hvm/pmtimer.c
>>> +++ b/xen/arch/x86/hvm/pmtimer.c
>>> @@ -257,7 +257,11 @@ static int acpi_save(struct domain *d,
>>> hvm_domain_context_t *h)
>>> int rc;
>>> On 20.12.16 at 16:29, wrote:
> On 12/20/2016 09:47 AM, Jan Beulich wrote:
> On 20.12.16 at 15:35, wrote:
>>> On 12/20/2016 06:50 AM, Jan Beulich wrote:
> +else
> +{
> +uint32_t v = *val;
> +
> +/* Status register is write-1-to-clear by guests */
flight 103774 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103774/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt17 guest-start/debian.repeat fail REGR. vs. 103771
Tests which
On Mon, Dec 19, 2016 at 09:53:02PM -0600, Doug Goldstein wrote:
> On 12/17/16 9:51 AM, Konrad Rzeszutek Wilk wrote:
> > On Fri, Dec 16, 2016 at 02:56:01PM -0800, Alistair Francis wrote:
> >> Signed-off-by: Alistair Francis
> >
> >
> > Why?
>
> *adjusts his distro maintainer hat* It's considered
On 20/12/16 15:02, Geliang Tang wrote:
> To make the code clearer, use rb_entry() instead of container_of() to
> deal with rbtree.
>
> Signed-off-by: Geliang Tang
Reviewed-by: Juergen Gross
> ---
> drivers/xen/evtchn.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --gi
On 20/12/2016 15:41, Jan Beulich wrote:
On 20.12.16 at 16:29, wrote:
>> On 12/20/2016 09:47 AM, Jan Beulich wrote:
>> On 20.12.16 at 15:35, wrote:
On 12/20/2016 06:50 AM, Jan Beulich wrote:
>> +else
>> +{
>> +uint32_t v = *val;
>> +
>> +/*
On Tue, Dec 20, 2016 at 10:02:19PM +0800, Geliang Tang wrote:
> To make the code clearer, use rb_entry() instead of container_of() to
> deal with rbtree.
That is OK but I think 'container_of' is more clear.
Roger, thoughts?
>
> Signed-off-by: Geliang Tang
> ---
> drivers/block/xen-blkback/blk
On 12/20/2016 11:46 AM, Andrew Cooper wrote:
> On 20/12/2016 15:41, Jan Beulich wrote:
> On 20.12.16 at 16:29, wrote:
>>> On 12/20/2016 09:47 AM, Jan Beulich wrote:
>>> On 20.12.16 at 15:35, wrote:
> On 12/20/2016 06:50 AM, Jan Beulich wrote:
>>> +else
>>> +{
>>> +
Jan Beulich writes ("[Xen-devel] merlot0 and merlot1 (was Re: [xen-4.4-testing
test] 103756: trouble: blocked/broken/fail/pass)"):
> I consider this difficult to imagine, but it's also not entirely
> impossible. Since this appears to recur, are there perhaps logs
> (ideally more than one instance,
On 12/20/16 10:05 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 19, 2016 at 09:53:02PM -0600, Doug Goldstein wrote:
>> On 12/17/16 9:51 AM, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Dec 16, 2016 at 02:56:01PM -0800, Alistair Francis wrote:
Signed-off-by: Alistair Francis
>>>
>>>
>>> Why?
>>
>
flight 103762 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103762/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-33 host-install(3)broken REGR. vs. 103466
test-xtf-amd64-amd
On Tue, Dec 20, 2016 at 11:02:15AM -0600, Doug Goldstein wrote:
> On 12/20/16 10:05 AM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Dec 19, 2016 at 09:53:02PM -0600, Doug Goldstein wrote:
> >> On 12/17/16 9:51 AM, Konrad Rzeszutek Wilk wrote:
> >>> On Fri, Dec 16, 2016 at 02:56:01PM -0800, Alistair Fr
2016-12-20 3:42 GMT-07:00 Jan Beulich :
> This is in preparation of eliminating the mis-naming of 64-bit fields
> with 32-bit register names (eflags instead of rflags etc).
>
> Signed-off-by: Jan Beulich
>
Acked-by: Tamas K Lengyel
___
Xen-devel mail
On Fri, Dec 09, 2016 at 10:05:18AM -0700, Jan Beulich wrote:
> >>> On 30.11.16 at 17:49, wrote:
> > @@ -1930,12 +1931,148 @@ static int __init hvm_setup_p2m(struct domain *d)
> > #undef MB1_PAGES
> > }
> >
> > +static int __init hvm_copy_to_phys(struct domain *d, paddr_t paddr, void
> > *buf,
On 20/12/2016 09:55, Jan Beulich wrote:
> This is a first (of three, as far as current plans go) steps to do away
> with misleading register names (eax instead of rax).
>
> 01: x86/MSR: introduce MSR access split/fold helpers
> 02: x86/guest-walk: use unambiguous register names
> 03: x86/shadow: us
On 20/12/2016 10:39, Jan Beulich wrote:
> @@ -3032,16 +3032,16 @@ void hvm_task_switch(
> if ( hvm_set_cr3(tss.cr3, 1) )
> goto out;
>
> -regs->eip= tss.eip;
> -regs->eflags = tss.eflags | 2;
> -regs->eax= tss.eax;
> -regs->ecx= tss.ecx;
> -regs->edx
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: xen-de...@lists.xensource.com
Signed-off-by: Eduardo Habkost
---
Makefile.target| 4 +---
xen-common.c => accel/xen-common.c | 0
xen-hvm.c => accel/xen-hvm.c | 0
xen-mapcache.c => accel/xen-mapcache.c | 0
MAI
This moves the KVM and Xen files to the an accel/ subdir.
Instead of moving the *-stubs.c file to accel/ as-is, I tried to
move most of the stub code to libqemustub.a. This way the obj-y
logic for accel/ is simpler: obj-y includes accel/ only if
CONFIG_SOFTMMU is set.
The Xen stubs could be moved
On Tue, Dec 20, 2016 at 11:47:03AM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 20, 2016 at 10:02:19PM +0800, Geliang Tang wrote:
> > To make the code clearer, use rb_entry() instead of container_of() to
> > deal with rbtree.
>
> That is OK but I think 'container_of' is more clear.
>
> Roger
Julien, Stefano,
Are there any updates about:
ACTION: Bosch to send a bug report regarding xen-swiotlb
Edgar: IOMMU could not be used by the guest (Stage-1). This would be useful
to implement driver in userspace.
Julien: When will it be required?
Edgar: It is a trend
Any mailing th
Move xen stubs to stubs/ so they are handled automatically by
libqemustub.a.
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: xen-de...@lists.xensource.com
Cc: Paolo Bonzini
Signed-off-by: Eduardo Habkost
---
Makefile.target | 2 --
xen-hvm-stub.c => stubs/xen-hvm.c | 0
xen-co
On Mon, Dec 19, 2016 at 8:00 PM, Doug Goldstein wrote:
> On 12/19/16 12:01 PM, Alistair Francis wrote:
>> On Sat, Dec 17, 2016 at 7:55 AM, Konrad Rzeszutek Wilk
>> wrote:
>>> On Fri, Dec 16, 2016 at 02:56:04PM -0800, Alistair Francis wrote:
To avoid this build error with newer build systems:
On Tue, Dec 20, 2016 at 05:44:06PM +, Roger Pau Monné wrote:
> On Tue, Dec 20, 2016 at 11:47:03AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Dec 20, 2016 at 10:02:19PM +0800, Geliang Tang wrote:
> > > To make the code clearer, use rb_entry() instead of container_of() to
> > > deal with rbt
On Tue, Dec 20, 2016 at 9:21 AM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Dec 20, 2016 at 11:02:15AM -0600, Doug Goldstein wrote:
>> On 12/20/16 10:05 AM, Konrad Rzeszutek Wilk wrote:
>> > On Mon, Dec 19, 2016 at 09:53:02PM -0600, Doug Goldstein wrote:
>> >> On 12/17/16 9:51 AM, Konrad Rzeszutek Wil
On Mon, Dec 19, 2016 at 7:53 PM, Doug Goldstein wrote:
> On 12/17/16 9:51 AM, Konrad Rzeszutek Wilk wrote:
>> On Fri, Dec 16, 2016 at 02:56:01PM -0800, Alistair Francis wrote:
>>> Signed-off-by: Alistair Francis
>>
>>
>> Why?
>
> *adjusts his distro maintainer hat* It's considered really bad form
1 - 100 of 158 matches
Mail list logo
