On Wed, Aug 29, 2018 at 09:09:03PM +0300, Razvan Cojocaru wrote:
> On 8/29/18 8:43 PM, Tamas K Lengyel wrote:
> > On Wed, Aug 29, 2018 at 10:42 AM Wei Liu wrote:
> >>
> >> On Mon, Aug 27, 2018 at 09:18:29AM -0600, Jan Beulich wrote:
> >> On 26.08.18 at 14:19, wrote:
> There has been plan
Added Dario as the scheduler's maintainer (he is on vacation this and
the next week, so don't expect a fast answer).
Juergen
On 30/08/18 06:01, Steven Haigh wrote:
> On 2018-08-29 15:49, Juergen Gross wrote:
>> On 29/08/18 07:33, Steven Haigh wrote:
>>> When playing with NUMA support recently, I
>>> On 29.08.18 at 18:01, wrote:
> On 29/08/18 15:02, Jan Beulich wrote:
>> @@ -235,13 +243,58 @@ void init_or_livepatch apply_alternative
>> continue;
>> }
>>
>> -base->priv = 1;
>> -
>> memcpy(buf, repl, a->repl_len);
>>
>> /* 0xe8/0xe9 are rel
On Wed, Aug 29, 2018 at 09:06:02PM -0700, Zhenzhong Duan wrote:
> Move reference of ol1e ahead or else we see below warning.
>
> cc1: warnings being treated as errors
> grant_table.c: In function 'replace_grant_pv_mapping':
> grant_table.c:142: warning: 'ol1e.l1' may be used uninitialized in this
>>> On 29.08.18 at 19:01, wrote:
> On 29/08/18 08:08, Jan Beulich wrote:
> On 01.08.18 at 16:22, wrote:
>>> When putting CPUs to sleep permanently, we should try to put them into
>>> the most power conserving state possible. For now it is unclear whether,
>>> especially in a deep C-state, the
>>> On 29.08.18 at 19:15, wrote:
> On 26/07/18 14:07, Jan Beulich wrote:
>> Don't chance having Spectre v1 (including BCBS) gadgets. In some of the
>> cases the insertions are more of precautionary nature rather than there
>> provably being a gadget, but I think we should err on the safe (secure)
On Tue, Aug 28, 2018 at 04:50:21AM -0600, Jan Beulich wrote:
> >>> On 26.08.18 at 14:19, wrote:
> > --- a/xen/arch/x86/mm/paging.c
> > +++ b/xen/arch/x86/mm/paging.c
> > @@ -919,6 +919,7 @@ const struct paging_mode *paging_get_mode(struct vcpu
> > *v)
> > return paging_get_nestedmode(v);
> >
>>> On 30.08.18 at 02:49, wrote:
> May I ask if this patch will be merged upstream or not? Our customer
> is pushing us urgently with timeline for errata release and we are waiting
> for official version from upstream.
Would you mind checking what has gone in before sending such inquiries?
Or was
On Wed, Aug 29, 2018 at 08:23:01PM +0200, Juergen Gross wrote:
> With not all physical cpus online (i.e. with smt=0) the output of hte
> vcpu affinities is wrong, as the affinity bitmaps are capped after
> nr_cpus bits, instead of using max_cpu_id.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei
On Wed, Aug 29, 2018 at 08:23:02PM +0200, Juergen Gross wrote:
> The topology information obtainable via XEN_SYSCTL_cputopoinfo is
> filled rather weird: the size of the array is derived from the highest
> online cpu number, while the data is set to "invalid" for not present
> cpus only.
>
> With
>>> On 30.08.18 at 06:42, wrote:
> flight 126907 xen-4.7-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/126907/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-libvirt-pair 22 guest-migrat
On Thu, Aug 30, 2018 at 08:48:40AM +0100, Wei Liu wrote:
> On Wed, Aug 29, 2018 at 08:23:02PM +0200, Juergen Gross wrote:
> > The topology information obtainable via XEN_SYSCTL_cputopoinfo is
> > filled rather weird: the size of the array is derived from the highest
> > online cpu number, while the
The per-cpu buffers for Xentrace are addressed by cpu-id, but the info
array for the buffers is sized only by number of online cpus. This
might lead to crashes when using Xentrace with smt=0.
The t_info structure has to be sized based on nr_cpu_ids.
Signed-off-by: Juergen Gross
---
tools/xentra
>>> On 29.08.18 at 19:09, wrote:
> On 29/08/18 18:01, Volodymyr Babchuk wrote:
>> Hi Andrew,
>>
>> On 29.08.18 19:22, Andrew Cooper wrote:
>>> On 29/08/18 17:11, Volodymyr Babchuk wrote:
Hello all,
During xen hacking I often encounter white spaces at EOLs. It is quite
annoying
>>> On 30.08.18 at 06:06, wrote:
> Move reference of ol1e ahead or else we see below warning.
>
> cc1: warnings being treated as errors
> grant_table.c: In function 'replace_grant_pv_mapping':
> grant_table.c:142: warning: 'ol1e.l1' may be used uninitialized in this
> function
>
> Signed-off-by
At 19:11 +0100 on 28 Aug (1535483514), Andrew Cooper wrote:
> Unlike the PRINTK/DEBUG wrappers, these go straight out to the console, rather
> than ending up in the debugtrace buffer.
>
> A number of these users are followed by domain_crash(), and future changes
> will want to combine the printk()
On 30/08/18 05:06, Zhenzhong Duan wrote:
> Move reference of ol1e ahead or else we see below warning.
>
> cc1: warnings being treated as errors
> grant_table.c: In function 'replace_grant_pv_mapping':
> grant_table.c:142: warning: 'ol1e.l1' may be used uninitialized in this
> function
>
> Signed-o
>>> On 29.08.18 at 20:23, wrote:
> With not all physical cpus online (i.e. with smt=0) the output of hte
I think you mean "e.g." instead of "i.e." here, as there are other
means to have some CPUs offline.
Jan
> vcpu affinities is wrong, as the affinity bitmaps are capped after
> nr_cpus bits, i
在 2018/8/30 16:04, Jan Beulich 写道:
On 30.08.18 at 06:06, wrote:
Move reference of ol1e ahead or else we see below warning.
cc1: warnings being treated as errors
grant_table.c: In function 'replace_grant_pv_mapping':
grant_table.c:142: warning: 'ol1e.l1' may be used uninitialized in this
functi
On Wed, Aug 29, Olaf Hering wrote:
> On Mon, Aug 13, Jan Beulich wrote:
>
> > And hence the consideration of mapping in an all zeros page
> > instead. This is because of the way __hvmemul_read() /
> > __hvm_copy() work: The latter doesn't tell its caller how many
> > bytes it was able to read, an
On 30/08/18 10:07, Jan Beulich wrote:
On 29.08.18 at 20:23, wrote:
>> With not all physical cpus online (i.e. with smt=0) the output of hte
>
> I think you mean "e.g." instead of "i.e." here, as there are other
> means to have some CPUs offline.
I used it in the meaning of "namely", in orde
On Wed, Aug 29, 2018 at 10:03:01AM -0600, Jan Beulich wrote:
> Eliminates a couple of branches in particular from the context switch
> path.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
>>> On 29.08.18 at 20:23, wrote:
> The topology information obtainable via XEN_SYSCTL_cputopoinfo is
> filled rather weird: the size of the array is derived from the highest
> online cpu number, while the data is set to "invalid" for not present
> cpus only.
>
> With smt=0 the information for par
>>> On 30.08.18 at 10:10, wrote:
> On Wed, Aug 29, Olaf Hering wrote:
>
>> On Mon, Aug 13, Jan Beulich wrote:
>>
>> > And hence the consideration of mapping in an all zeros page
>> > instead. This is because of the way __hvmemul_read() /
>> > __hvm_copy() work: The latter doesn't tell its caller
Also CC George
We had a race -- I commented on your patch on github. I will redo my
review here.
On Wed, Aug 29, 2018 at 04:34:28PM +, Joshua Perrett wrote:
> Uses MD5 on the host mac address, vm name and vif index to generate the last
> three
> bytes of the vm mac address (for each vm).
> I
>>> On 30.08.18 at 09:52, wrote:
> @@ -202,7 +202,7 @@ static int alloc_trace_bufs(unsigned int pages)
> * Allocate buffers for all of the cpus.
> * If any fails, deallocate what you have so far and exit.
> */
> -for_each_online_cpu(cpu)
> +for_each_present_cpu(cpu)
>
On 30/08/18 10:16, Jan Beulich wrote:
On 29.08.18 at 20:23, wrote:
>> The topology information obtainable via XEN_SYSCTL_cputopoinfo is
>> filled rather weird: the size of the array is derived from the highest
>> online cpu number, while the data is set to "invalid" for not present
>> cpus on
>>> On 30.08.18 at 06:01, wrote:
> Managed to get the same crash log when adding CPUs to Pool-1 as follows:
>
> Create the pool:
> (XEN) Initializing Credit2 scheduler
> (XEN) load_precision_shift: 18
> (XEN) load_window_shift: 30
> (XEN) underload_balance_tolerance: 0
> (XEN) overload_balanc
>>> On 30.08.18 at 09:42, wrote:
> On Tue, Aug 28, 2018 at 04:50:21AM -0600, Jan Beulich wrote:
>> >>> On 26.08.18 at 14:19, wrote:
>> > --- a/xen/arch/x86/mm/paging.c
>> > +++ b/xen/arch/x86/mm/paging.c
>> > @@ -919,6 +919,7 @@ const struct paging_mode *paging_get_mode(struct vcpu
> *v)
>> >
On Thu, Aug 30, 2018 at 10:31:16AM +0200, Juergen Gross wrote:
> On 30/08/18 10:16, Jan Beulich wrote:
> On 29.08.18 at 20:23, wrote:
> >> The topology information obtainable via XEN_SYSCTL_cputopoinfo is
> >> filled rather weird: the size of the array is derived from the highest
> >> online
>>> On 30.08.18 at 10:11, wrote:
> On 30/08/18 10:07, Jan Beulich wrote:
> On 29.08.18 at 20:23, wrote:
>>> With not all physical cpus online (i.e. with smt=0) the output of hte
>>
>> I think you mean "e.g." instead of "i.e." here, as there are other
>> means to have some CPUs offline.
>
>
>>> On 30.08.18 at 10:31, wrote:
> On 30/08/18 10:16, Jan Beulich wrote:
> On 29.08.18 at 20:23, wrote:
>>> The topology information obtainable via XEN_SYSCTL_cputopoinfo is
>>> filled rather weird: the size of the array is derived from the highest
>>> online cpu number, while the data is set
>>> On 30.08.18 at 10:37, wrote:
> On Thu, Aug 30, 2018 at 10:31:16AM +0200, Juergen Gross wrote:
>> On 30/08/18 10:16, Jan Beulich wrote:
>> On 29.08.18 at 20:23, wrote:
>> >> The topology information obtainable via XEN_SYSCTL_cputopoinfo is
>> >> filled rather weird: the size of the array
On 30/08/18 10:43, Jan Beulich wrote:
On 30.08.18 at 10:31, wrote:
>> On 30/08/18 10:16, Jan Beulich wrote:
>> On 29.08.18 at 20:23, wrote:
The topology information obtainable via XEN_SYSCTL_cputopoinfo is
filled rather weird: the size of the array is derived from the highest
>
On 30/08/18 10:44, Jan Beulich wrote:
On 30.08.18 at 10:37, wrote:
>> On Thu, Aug 30, 2018 at 10:31:16AM +0200, Juergen Gross wrote:
>>> On 30/08/18 10:16, Jan Beulich wrote:
>>> On 29.08.18 at 20:23, wrote:
> The topology information obtainable via XEN_SYSCTL_cputopoinfo is
> fi
On 2018-08-30 18:33, Jan Beulich wrote:
On 30.08.18 at 06:01, wrote:
Managed to get the same crash log when adding CPUs to Pool-1 as
follows:
Create the pool:
(XEN) Initializing Credit2 scheduler
(XEN) load_precision_shift: 18
(XEN) load_window_shift: 30
(XEN) underload_balance_tolerance:
On Thu, Aug 30, 2018 at 01:49:44AM -0600, Jan Beulich wrote:
> >>> On 30.08.18 at 06:42, wrote:
> > flight 126907 xen-4.7-testing real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/126907/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including
flight 126959 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126959/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 497a5fb1d8f834e1bc84d3496d7f2228bf99f7df
baseline version:
ovmf 0fa0e56ee002cf369f7f4
>>> On 30.08.18 at 10:51, wrote:
> On Thu, Aug 30, 2018 at 01:49:44AM -0600, Jan Beulich wrote:
>> >>> On 30.08.18 at 06:42, wrote:
>> > flight 126907 xen-4.7-testing real [real]
>> > http://logs.test-lab.xenproject.org/osstest/logs/126907/
>> >
>> > Regressions :-(
>> >
>> > Tests which did n
On 30/08/18 10:26, Jan Beulich wrote:
On 30.08.18 at 09:52, wrote:
>> @@ -202,7 +202,7 @@ static int alloc_trace_bufs(unsigned int pages)
>> * Allocate buffers for all of the cpus.
>> * If any fails, deallocate what you have so far and exit.
>> */
>> -for_each_online_cpu
This code is believed to be vestigial remnant of the PV Windows XP port. It
is not used by Linux, NetBSD, Solaris or MiniOS. Furthermore the
implementation is incomplete; it only functions for a present => not-present
transition, rather than a present => read/write transition.
The for_each_vcpu(
rpmbuild -bb spents alot of time in compressing the binaries. Reduce the
turnaround time of 'make rpmball' by using gzip as compression tool.
This reduces the buildtime from 'w9.xzdio'/138 seconds to 'w1.gzdio'/88
seconds in my environment.
The downside is an increased filesize of xen.rpm, 19MB vs.
On Thu, Aug 30, 2018 at 03:12:25AM -0600, Jan Beulich wrote:
> >>> On 30.08.18 at 10:51, wrote:
> > On Thu, Aug 30, 2018 at 01:49:44AM -0600, Jan Beulich wrote:
> >> >>> On 30.08.18 at 06:42, wrote:
> >> > flight 126907 xen-4.7-testing real [real]
> >> > http://logs.test-lab.xenproject.org/osstes
On Thu, Aug 30, 2018 at 12:05:11PM +0200, Olaf Hering wrote:
> rpmbuild -bb spents alot of time in compressing the binaries. Reduce the
> turnaround time of 'make rpmball' by using gzip as compression tool.
> This reduces the buildtime from 'w9.xzdio'/138 seconds to 'w1.gzdio'/88
> seconds in my en
On Thu, Aug 30, Jan Beulich wrote:
> approach): One is Paul's idea of making null_handler actually retrieve
> RAM contents when (part of) the access touches RAM. Another might
This works for me:
static int null_read(const struct hvm_io_handler *io_handler,
uint64_t addr,
flight 126985 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126985/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Fri, Aug 24, 2018 at 09:58:02AM +0100, Wei Liu wrote:
> On Wed, Aug 22, 2018 at 04:52:27PM -0600, Jim Fehlig wrote:
> > On 08/21/2018 05:14 AM, Jan Beulich wrote:
> > > > > > On 21.08.18 at 03:11, wrote:
> > > > flight 126201 xen-4.9-testing real [real]
> > > > http://logs.test-lab.xenproject.o
1: drop hvm_fetch_from_guest_linear()
2: split page straddling emulated accesses in more cases
Patch 2 is incomplete at this time, and hence only RFC.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/
It can easily be expressed through hvm_copy_from_guest_linear(), and in
two cases this even simplifies callers.
Suggested-by: Paul Durrant
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1060,6 +1060,8 @@ static int __hvmemul_read(
Assuming consecutive linear addresses map to all RAM or all MMIO is not
correct. Nor is assuming that a page straddling MMIO access will access
the same emulating component for both parts of the access. If a guest
RAM read fails with HVMTRANS_bad_gfn_to_mfn and if the access straddles
a page bounda
On 30/08/18 12:09, Jan Beulich wrote:
> It can easily be expressed through hvm_copy_from_guest_linear(), and in
> two cases this even simplifies callers.
>
> Suggested-by: Paul Durrant
> Signed-off-by: Jan Beulich
I really like this piece of cleanup, but...
> ---
> v2: New.
>
> --- a/xen/arch/x
On 30/08/18 12:09, Jan Beulich wrote:
> @@ -3758,8 +3749,9 @@ void hvm_ud_intercept(struct cpu_user_re
> if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip,
> sizeof(sig), hvm_access_insn_fetch,
> cs,
>>> On 30.08.18 at 13:18, wrote:
> On 30/08/18 12:09, Jan Beulich wrote:
>> @@ -2512,9 +2512,10 @@ void hvm_emulate_init_per_insn(
>> hvm_access_insn_fetch,
>> &hvmemul_ctxt->seg_reg[x86_seg_cs],
>>
On 30/08/18 13:02, Jan Beulich wrote:
On 30.08.18 at 13:18, wrote:
>> On 30/08/18 12:09, Jan Beulich wrote:
>>> @@ -2512,9 +2512,10 @@ void hvm_emulate_init_per_insn(
>>> hvm_access_insn_fetch,
>>> &hvmemul_ctxt
>>> On 30.08.18 at 11:55, wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -164,3 +164,26 @@ endmenu
> source "common/Kconfig"
>
> source "drivers/Kconfig"
> +
> +menu "Deprecated Functionality"
> +
> +config LEGACY_PV_LDT_PAGING
> + def_bool n
Can this please simply
>>> On 30.08.18 at 14:22, wrote:
> On 30/08/18 13:02, Jan Beulich wrote:
> On 30.08.18 at 13:18, wrote:
>>> On 30/08/18 12:09, Jan Beulich wrote:
@@ -2512,9 +2512,10 @@ void hvm_emulate_init_per_insn(
hvm_access_insn_fetch,
On 30/08/18 13:25, Jan Beulich wrote:
On 30.08.18 at 11:55, wrote:
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -164,3 +164,26 @@ endmenu
>> source "common/Kconfig"
>>
>> source "drivers/Kconfig"
>> +
>> +menu "Deprecated Functionality"
>> +
>> +config LEGACY_PV_LDT_P
>>> On 30.08.18 at 14:27, wrote:
> On 30/08/18 13:25, Jan Beulich wrote:
> On 30.08.18 at 11:55, wrote:
>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -164,3 +164,26 @@ endmenu
>>> source "common/Kconfig"
>>>
>>> source "drivers/Kconfig"
>>> +
>>> +menu "Deprecated F
On 21.08.2018 12:44, David Hildenbrand wrote:
> This is the same approach as in the first RFC, but this time without
> exporting device_hotplug_lock (requested by Greg) and with some more
> details and documentation regarding locking. Tested only on x86 so far.
>
I'll be on vacation for two weeks
Callers are inconsistent with whether they pass a newline to panic(),
including adjacent calls in the same function using different styles.
painc() not expecting a newline is inconsistent with most other printing
functions, which is most likely why we've gained so many inconsistencies.
Switch pan
flight 75142 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/75142/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-i386-wheezy-netboot-pvgrub 10 debian-di-install fail REGR. vs.
75110
test-amd64-
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Stefano Stabellini
CC: Julien Grall
CC: George Dunlap
CC: Dario Faggioli
---
xen/arch/arm/gic-vgic.c | 12 ++--
xen/common/sched_null.c | 15 ++-
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/xe
This allows all system domids to be printed by name, rather than special
casing the idle vcpus alone.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
RFC, because this was propo
>>> On 28.08.18 at 15:12, wrote:
> On 19/07/18 11:49, Jan Beulich wrote:
>> Checking the low 5 bits of CR3 is not the job of vmx_load_pdptrs().
>> Instead it should #GP upon bad PDPTE values, rather than causing a VM
>> entry failure.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/hvm/
>>> On 30.08.18 at 14:31, wrote:
> Callers are inconsistent with whether they pass a newline to panic(),
> including adjacent calls in the same function using different styles.
>
> painc() not expecting a newline is inconsistent with most other printing
> functions, which is most likely why we've
>>> On 30.08.18 at 15:06, wrote:
> This allows all system domids to be printed by name, rather than special
> casing the idle vcpus alone.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: George Dunlap
> CC: Jan Beulich
> CC: Konrad Rzeszutek Wilk
> CC: Stefano Stabellini
> CC: Tim Deegan
> CC:
flight 126991 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126991/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
>>> On 28.08.18 at 19:39, wrote:
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -173,7 +173,7 @@ static DEFINE_RCU_READ_LOCK(msixtbl_rcu_lock);
> */
> static bool msixtbl_initialised(const struct domain *d)
> {
> -return !!d->arch.hvm_domain.msixtbl_list.next;
> +
Hi Julien,
On 22.08.18 19:46, Julien Grall wrote:
[...]
+++ b/xen/arch/arm/arm32/smc.S
@@ -0,0 +1,39 @@
+/*
+ * xen/arch/arm/arm32/smc.S
+ *
+ * Wrapper for Secure Monitors Calls
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Gener
>>> On 28.08.18 at 19:39, wrote:
>>> On 28.08.18 at 19:39, wrote:
> The trailing _vcpu suffix is redundant, but adds to code volume. Drop it.
>
> Reflow lines as appropriate, and switch to using the new XFREE/etc wrappers
> where applicable.
I couldn't find any such conversion, so perhaps bett
>>> On 28.08.18 at 19:39, wrote:
> The suffix and prefix are redundant, and the name is curiously odd. Rename it
> to vmx_vcpu to be consistent with all the other similar structures.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger
>>> On 28.08.18 at 19:39, wrote:
> The suffix and prefix are redundant, and the name is curiously odd. Rename it
> to svm_vcpu to be consistent with all the other similar structures.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger
>>> On 28.08.18 at 19:39, wrote:
> By making {vmx,svm} in hvm_vcpu into an anonymous union (consistent with
> domain side of things), the hvm_{vmx,svm} defines can be dropped, and all code
> refer to the correctly-named fields. This means that the data hierachy is no
> longer obscured from grep/c
flight 126937 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126937/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in
126844 pass in 126937
Just kidding (for now), but according to our agreement it would be
ripe: No adjustments towards the better have been made for more
than a year, i.e. in particular nothing has happened with it for the
entire 4.11 and 4.10 release cycles.
Jan
___
Xen-de
Creating debug info during build is not strictly required at runtime.
Make it optional by reusing the existing 'debug_symbols=n' knob.
This slightly reduces build time and diskusage, if specified.
Signed-off-by: Olaf Hering
---
xen/Rules.mk | 5 -
1 file changed, 4 insertions(+), 1 deletion(
>>> On 28.08.18 at 20:11, wrote:
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -304,10 +304,11 @@ static void hap_free_p2m_page(struct domain *d, struct
> page_info *pg)
> /* Should still have no owner and count zero. */
> if ( owner || (pg->count_info & PGC_c
>>> On 28.08.18 at 20:17, wrote:
> hvm_map_entry() can fail for a number of reasons, including for a misaligned
> LDT/GDT access which crosses a 4K boundary. Architecturally speaking, this
> should be fixed, but Long Mode doesn't support task switches, and no 32bit OS
> is going to misalign its L
Uses MD5 on the host mac address, vm name and vif index to generate the
last three bytes of the vm mac address (for each vm).
It uses the vif index to account for multiple vifs.
MD5 code is originally from the public domain (written by Colin Plumb in
1993), files found in xen/tools/blktap2/driver
On 30/08/18 16:15, Jan Beulich wrote:
On 28.08.18 at 20:11, wrote:
>> --- a/xen/arch/x86/mm/hap/hap.c
>> +++ b/xen/arch/x86/mm/hap/hap.c
>> @@ -304,10 +304,11 @@ static void hap_free_p2m_page(struct domain *d, struct
>> page_info *pg)
>> /* Should still have no owner and count zero. */
>>> On 30.08.18 at 17:10, wrote:
> Creating debug info during build is not strictly required at runtime.
> Make it optional by reusing the existing 'debug_symbols=n' knob.
Reusing? It's been gone since 4.9, and ./INSTALL talks about it as
a tool stack only thing. If we wanted to re-introduce anyt
>>> On 30.08.18 at 17:20, wrote:
> On 30/08/18 16:15, Jan Beulich wrote:
> On 28.08.18 at 20:11, wrote:
>>> @@ -2478,9 +2478,7 @@ sh_map_and_validate_gl4e(struct vcpu *v, mfn_t gl4mfn,
>>> shadow_l4_index,
>>> validate_gl4e);
>
There original reason for this patch was to fix a livepatching problem;
unnecesserily large livepatchs due to the use of __LINE__.
A second problem is one of debugability. A number of domain_crash()
invocations have no logging at all, and number of others only have logging
when compiled with a de
>>> On 27.08.18 at 18:54, wrote:
> Edit the initialization code for AMD's SSBD via the LS_CFG MSR and
> enable it to pass the status to the initial spec-ctrl print_details at
> boot.
>
> Signed-off-by: Brian Woods
> ---
I think I had indicated so before: A brief revision log is expected here,
i
On 30/08/18 15:54, Jan Beulich wrote:
On 28.08.18 at 19:39, wrote:
>> The suffix and prefix are redundant, and the name is curiously odd. Rename
>> it
>> to vmx_vcpu to be consistent with all the other similar structures.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper
>> --
>>> On 27.08.18 at 18:55, wrote:
> Adds support for modifying the LS_CFG MSR to enable SSBD on supporting
> AMD CPUs. There needs to be locking logic for family 17h with SMT
> enabled since both threads share the same MSR. Otherwise, a core just
> needs to write to the LS_CFG MSR. For more info
On 8/30/18 8:31 AM, David Hildenbrand wrote:
> On 21.08.2018 12:44, David Hildenbrand wrote:
>> This is the same approach as in the first RFC, but this time without
>> exporting device_hotplug_lock (requested by Greg) and with some more
>> details and documentation regarding locking. Tested only
Am Thu, 30 Aug 2018 09:23:47 -0600
schrieb "Jan Beulich" :
> Reusing? It's been gone since 4.9, and ./INSTALL talks about it as
> a tool stack only thing.
It does not, it is in the general "make" section.
I do not see any valid reason to diverge further.
Olaf
pgp7_TmCXnfBQ.pgp
Description: Dig
>>> On 23.08.18 at 11:46, wrote:
> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -26,6 +26,11 @@
> * A linear idea of a guest physical address space. For an auto-translated
> * guest, pfn == gfn while for a non-translated guest, pfn != gfn.
> *
> + * bfn: Bus Frame Number
On 8/30/18 6:31 PM, Andrew Cooper wrote:
> There original reason for this patch was to fix a livepatching problem;
> unnecesserily large livepatchs due to the use of __LINE__.
>
> A second problem is one of debugability. A number of domain_crash()
> invocations have no logging at all, and number
On 30/08/18 15:52, Jan Beulich wrote:
On 28.08.18 at 19:39, wrote:
On 28.08.18 at 19:39, wrote:
>> The trailing _vcpu suffix is redundant, but adds to code volume. Drop it.
>>
>> Reflow lines as appropriate, and switch to using the new XFREE/etc wrappers
>> where applicable.
> I couldn
>>> On 30.08.18 at 17:59, wrote:
> Am Thu, 30 Aug 2018 09:23:47 -0600
> schrieb "Jan Beulich" :
>
>> Reusing? It's been gone since 4.9, and ./INSTALL talks about it as
>> a tool stack only thing.
>
> It does not, it is in the general "make" section.
Quote from ./INSTALL in my copy of the master
On 30/08/18 02:39, Tian, Kevin wrote:
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: Wednesday, August 29, 2018 1:39 AM
>>
>> By making {vmx,svm} in hvm_vcpu into an anonymous union (consistent
>> with
>> domain side of things), the hvm_{vmx,svm} defines can be dropped, and all
On 30/08/18 17:01, Razvan Cojocaru wrote:
> On 8/30/18 6:31 PM, Andrew Cooper wrote:
>> There original reason for this patch was to fix a livepatching problem;
>> unnecesserily large livepatchs due to the use of __LINE__.
>>
>> A second problem is one of debugability. A number of domain_crash()
>>
Hi Julien,
On 24.08.18 19:58, Julien Grall wrote:
Hi all,
This patch series contains fixup and improvement for the SMCCC subsystem.
Patch #1 - #2 are candidates for backporting.
I tested this patches together with my TEE patch series and all is
working fine both with SMCCC 1.0 and SMCCC 1.1
On 30/08/18 15:48, Volodymyr Babchuk wrote:
Hi Julien,
Hi,
On 22.08.18 19:46, Julien Grall wrote:
[...]
+++ b/xen/arch/arm/arm32/smc.S
@@ -0,0 +1,39 @@
+/*
+ * xen/arch/arm/arm32/smc.S
+ *
+ * Wrapper for Secure Monitors Calls
+ *
+ * This program is free software; you can redistribute i
flight 126932 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126932/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR.
vs. 126781
test-amd64-
On 30/08/18 15:07, Jan Beulich wrote:
On 30.08.18 at 14:31, wrote:
>> Callers are inconsistent with whether they pass a newline to panic(),
>> including adjacent calls in the same function using different styles.
>>
>> painc() not expecting a newline is inconsistent with most other printing
>
flight 126926 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126926/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 12 guest-start fail REGR. vs. 126042
test-amd64-i386-qemu
flight 126996 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126996/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
1 - 100 of 133 matches
Mail list logo
