On Tue, Feb 16, 2016 at 06:37:47PM +0100, Roger Pau Monne wrote:
> And use it as the default value for the VGA kind. This allows libxl to set
> it to the default value later on when the domain type is known. For HVM
> guests the default value is LIBXL_VGA_INTERFACE_TYPE_CIRRUS while for
> HVMlite t
On 24/02/16 03:09, Wu, Feng wrote:
>
>
>> -Original Message-
>> From: Doug Goldstein [mailto:car...@cardoe.com]
>> Sent: Wednesday, February 24, 2016 11:02 AM
>> To: Jan Beulich ; Wu, Feng
>> Cc: Tian, Kevin ; Keir Fraser ; George
>> Dunlap ; Andrew Cooper
>> ; Dario Faggioli ; xen-
>> d
Hi all,
this series includes a patch to export xenboot on ARM and ARM64 as
earlycon, and another patch to get xenboot fully working again for PV
DomUs on x86 (currently the xenboot output only goes to the hypervisor
via hypercall and not to the DomU console).
Cheers,
Stefano
Stefano Stabellini
Introduce EARLYCON support in hvc_xen, useful for early debugging on arm
and arm64, where xen early_printk is not available. Differently from
xenboot_write_console on x86, we won't just return if !xen_pv_domain(),
because arm and arm64 guests are actually xen_hvm_domain() from linux
pov, and also b
The xenboot early console has been partially broken for DomU for a long
time: the output would only go to the hypervisor via hypercall
(HYPERVISOR_console_io), while it wouldn't actually go to the DomU
console. The reason is that domU_write_console would return early as no
xencons structs are confi
A sample looks like:
(XEN) d1v0 Triple fault - invoking HVM shutdown action 1
(XEN) *** Dumping Dom1 vcpu#0 state: ***
(XEN) [ Xen-4.7-unstable x86_64 debug=y Not tainted ]
(XEN) CPU:2
(XEN) RIP::[<0015>]
(XEN) RFLAGS: 00010002 CONTEXT: hvm guest (d1v0)
>>> On 24.02.16 at 13:09, wrote:
> Another reason for such a comment is that it actually raises awareness
> that the hook isn't properly structured: if you get such a compile
> error, then it's either not defined in the right place, or it's not
> using the right calling convention.
Well, why I ge
On Wed, Feb 24, Wei Liu wrote:
> Say, if you only add a controller, you just print the ctrl JSON. If you
> add a controller and a bunch of devices, you print all of them. Does
> this sound plausible?
Yes.
Olaf
___
Xen-devel mailing list
Xen-devel@list
*main_foo() is treated somewhat as a regular main(), it is changed to
return EXIT_SUCCESS or EXIT_FAILURE.
*Functions that are not main_foo(), are changed to do 'return 0' or
'return 1', and then 0/1 is taken care in the main_foo() functions
that calls them.
*Functions in xl_cmdimpl.c related to
Signed-off-by: Harmandeep Kaur
---
tools/libxl/xl_cmdimpl.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 9e0a467..234977c 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -6320,12
Signed-off-by: Harmandeep Kaur
---
tools/libxl/xl_cmdimpl.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2092c80..e1b4286 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3421,7 +
Signed-off-by: Harmandeep Kaur
---
tools/libxl/xl_cmdimpl.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 116363d..8f5a2f4 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -172,7 +1
Signed-off-by: Harmandeep Kaur
---
tools/libxl/xl_cmdimpl.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 9d95b50..f7f7d7f 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/lib
Signed-off-by: Harmandeep Kaur
---
tools/libxl/xl_cmdimpl.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index e1b4286..b4920ff 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimp
Signed-off-by: Harmandeep Kaur
---
tools/libxl/xl_cmdimpl.c | 56
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index e5bb41f..2092c80 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b
Signed-off-by: Harmandeep Kaur
---
tools/libxl/xl_cmdimpl.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index b4920ff..9d95b50 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@
Signed-off-by: Harmandeep Kaur
---
tools/libxl/xl_cmdimpl.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 8f5a2f4..e5bb41f 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/l
Signed-off-by: Harmandeep Kaur
---
tools/libxl/xl_cmdimpl.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f7f7d7f..9e0a467 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -374,
-earlycon-support/20160224-203006
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
tty-testing
config: x86_64-randconfig-x009-201608 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed
flight 83726 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/83726/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail
REGR. vs. 83609
Regres
>>> On 23.02.16 at 19:36, wrote:
> Clang-3.8 generates several .data.rel.ro sections when compiling Xen. As
> these contain no global symbols, they should be .data.rel.ro.local. This
> breaks the SPECIAL_DATA_SECTIONS check when converting the transition units
> to
> being init-only.
>
> For a
>>> On 23.02.16 at 17:31, wrote:
> This balloons the size of Xen in memory from 4.4MB to 8MB, because of the
> required alignment adjustments.
Interesting - on v1 it was 12Mb iirc, and aiui you folded just one
pair of 2M pages, which would yield 10M now; did you perhaps
not account for .text span
On Wed, 2016-02-24 at 04:52 -0700, Jan Beulich wrote:
> > > > On 24.02.16 at 12:21, wrote:
> > On Thu, 2016-02-18 at 11:04 +, George Dunlap wrote:
> > > On 16/02/16 18:11, Dario Faggioli wrote:
> > > > by doing the following two things:
> > > >
> > > > - move TRC_SCHED_DOM_{ADD,REM}, into th
On 24/02/16 13:17, Jan Beulich wrote:
On 23.02.16 at 17:31, wrote:
>> This balloons the size of Xen in memory from 4.4MB to 8MB, because of the
>> required alignment adjustments.
> Interesting - on v1 it was 12Mb iirc, and aiui you folded just one
> pair of 2M pages, which would yield 10M now
On 24/02/16 13:21, Andrew Cooper wrote:
> On 24/02/16 13:17, Jan Beulich wrote:
> On 23.02.16 at 17:31, wrote:
>>> This balloons the size of Xen in memory from 4.4MB to 8MB, because of the
>>> required alignment adjustments.
>> Interesting - on v1 it was 12Mb iirc, and aiui you folded just one
>>> On 23.02.16 at 17:31, wrote:
> The use of MAP_SMALL_PAGES causes shattering of the superpages making up the
> Xen virtual region, and is counter to the purpose of this series.
> Furthermore, it is not required for the memguard infrastructure to function
> (which itself uses map_pages_to_xen()
On 02/18/16 10:17, Jan Beulich wrote:
> >>> On 01.02.16 at 06:44, wrote:
> > This design treats host NVDIMM devices as ordinary MMIO devices:
>
> Wrt the cachability note earlier on, I assume you're aware that with
> the XSA-154 changes we disallow any cachable mappings of MMIO
> by default.
>
On 02/24/2016 04:31 AM, Jim Fehlig wrote:
> On 02/22/2016 04:15 PM, Joao Martins wrote:
>>
>> On 12/08/2015 04:06 PM, Jim Fehlig wrote:
>>> Daniel P. Berrange wrote:
On Mon, Dec 07, 2015 at 10:59:32PM -0700, Jim Fehlig wrote:
> On 12/07/2015 11:52 AM, Daniel P. Berrange wrote:
>> On
Hi,
I'm from GlobalLogic team that uses Xen as a base for an automative
platform. Got few questions regarding Xen tracing and it seems that
existing documentation is rather limited.
At the previous Xen Hackathon I was talking about shared (mediated
pass-through) GPU concept for ARM; it's working
flight 83851 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/83851/
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 12
On Wed, Feb 24, Harmandeep Kaur wrote:
> -exit(2);
> +exit(EXIT_FAILURE);
The commit message should state why changing the value is fine.
I dont know if anyone actually cares about the exact value.
Olaf
___
Xen-devel mailing list
Xen-d
On 24/02/16 11:24, Jan Beulich wrote:
> >>> On 23.02.16 at 17:31, wrote:
>> * Additional comments, including size and runtime use.
>> * Consistent use of idx, rather than a mix including pfn.
> I don't see anything wrong with this - when we have a PFN why
> should we not call it a PFN? As oppose
On 02/24/2016 08:28 AM, Haozhong Zhang wrote:
> On 02/18/16 10:17, Jan Beulich wrote:
> On 01.02.16 at 06:44, wrote:
>>> This design treats host NVDIMM devices as ordinary MMIO devices:
>>
>> Wrt the cachability note earlier on, I assume you're aware that with
>> the XSA-154 changes we disall
Sorry, forgot sending the last reply to Boris.
On 02/24/16 14:00, Haozhong Zhang wrote:
> On 02/23/16 08:37, Jan Beulich wrote:
> > >>> On 23.02.16 at 15:16, wrote:
> > > On 02/23/2016 09:10 AM, Jan Beulich wrote:
> > > On 23.02.16 at 15:00, wrote:
> > >>> On 02/22/2016 09:04 PM, Haozhong Zh
On 22/02/16 22:06, Boris Ostrovsky wrote:
> Baremetal kernels clear .bss early in the boot. Since Xen PV guests don't
> excecute that early code they should do it too.
>
> (Since we introduce macros for specifying 32- and 64-bit registers we
> can get rid of ifdefs in startup_xen())
.bss must hav
>>> On 24.02.16 at 14:57, wrote:
> On 24/02/16 11:24, Jan Beulich wrote:
>> >>> On 23.02.16 at 17:31, wrote:
>>> GLOBAL(l1_identmap)
>>> -pfn = 0
>>> +idx = 0
>>> .rept L1_PAGETABLE_ENTRIES
>>> /* VGA hole (0xa-0xc) should be mapped UC. */
>>> -
On 24/02/16 14:12, David Vrabel wrote:
> On 22/02/16 22:06, Boris Ostrovsky wrote:
>> Baremetal kernels clear .bss early in the boot. Since Xen PV guests don't
>> excecute that early code they should do it too.
>>
>> (Since we introduce macros for specifying 32- and 64-bit registers we
>> can get r
>>> On 24.02.16 at 14:28, wrote:
> On 02/18/16 10:17, Jan Beulich wrote:
>> >>> On 01.02.16 at 06:44, wrote:
>> > This design treats host NVDIMM devices as ordinary MMIO devices:
>>
>> Wrt the cachability note earlier on, I assume you're aware that with
>> the XSA-154 changes we disallow any ca
On Wed, 2016-02-24 at 14:55 +0100, Olaf Hering wrote:
> On Wed, Feb 24, Harmandeep Kaur wrote:
>
> > -exit(2);
> > +exit(EXIT_FAILURE);
>
> The commit message should state why changing the value is fine.
> I dont know if anyone actually cares about the exact value.
>
This has bee
On 2/16/16 7:52 AM, Wei Liu wrote:
> On Tue, Feb 16, 2016 at 01:43:26PM +, Ian Campbell wrote:
>> On Mon, 2016-02-15 at 16:13 +, Wei Liu wrote:
>>> On Mon, Feb 15, 2016 at 08:38:02AM -0600, Doug Goldstein wrote:
Switch from tracking a commit post 1.9.0 to the 1.9.1 release.
>>>
>>
>>> On 23.02.16 at 03:04, wrote:
> Both VMX TSC scaling and SVM TSC ratio use the 64-bit TSC scaling ratio,
> but the number of fractional bits of the ratio is different between VMX
> and SVM. This patch adds the architecture code to collect the number of
> fractional bits and other related inform
On 24/02/16 13:21, Paul Sujkov wrote:
> Hi,
>
> I'm from GlobalLogic team that uses Xen as a base for an automative
> platform. Got few questions regarding Xen tracing and it seems that
> existing documentation is rather limited.
>
> At the previous Xen Hackathon I was talking about shared (media
On Wed, Feb 24, 2016 at 08:34:31AM -0600, Doug Goldstein wrote:
> On 2/16/16 7:52 AM, Wei Liu wrote:
> > On Tue, Feb 16, 2016 at 01:43:26PM +, Ian Campbell wrote:
> >> On Mon, 2016-02-15 at 16:13 +, Wei Liu wrote:
> >>> On Mon, Feb 15, 2016 at 08:38:02AM -0600, Doug Goldstein wrote:
>
On 02/24/2016 07:23 AM, Stefano Stabellini wrote:
Introduce EARLYCON support in hvc_xen, useful for early debugging on arm
and arm64, where xen early_printk is not available. Differently from
xenboot_write_console on x86, we won't just return if !xen_pv_domain(),
because arm and arm64 guests are
On Wed, 2016-02-24 at 15:21 +0200, Paul Sujkov wrote:
> Hi,
>
Hi,
> I'm from GlobalLogic team that uses Xen as a base for an automative
> platform. Got few questions regarding Xen tracing and it seems that
> existing documentation is rather limited.
>
It is...
> At the previous Xen Hackathon I
On 02/24/2016 09:15 AM, Andrew Cooper wrote:
On 24/02/16 14:12, David Vrabel wrote:
On 22/02/16 22:06, Boris Ostrovsky wrote:
Baremetal kernels clear .bss early in the boot. Since Xen PV guests don't
excecute that early code they should do it too.
(Since we introduce macros for specifying 32-
On 02/24/2016 08:46 AM, Haozhong Zhang wrote:
Sorry, forgot sending the last reply to Boris.
On 02/24/16 14:00, Haozhong Zhang wrote:
On 02/23/16 08:37, Jan Beulich wrote:
On 23.02.16 at 15:16, wrote:
On 02/23/2016 09:10 AM, Jan Beulich wrote:
On 23.02.16 at 15:00, wrote:
On 02/22/2016 09
On 24/02/16 14:15, Jan Beulich wrote:
On 24.02.16 at 14:57, wrote:
>> On 24/02/16 11:24, Jan Beulich wrote:
>>> >>> On 23.02.16 at 17:31, wrote:
GLOBAL(l1_identmap)
-pfn = 0
+idx = 0
.rept L1_PAGETABLE_ENTRIES
/* VGA hole (0xa-
On 24/02/16 14:52, Boris Ostrovsky wrote:
> On 02/24/2016 09:15 AM, Andrew Cooper wrote:
>> On 24/02/16 14:12, David Vrabel wrote:
>>> On 22/02/16 22:06, Boris Ostrovsky wrote:
Baremetal kernels clear .bss early in the boot. Since Xen PV guests
don't
excecute that early code they sho
On Wed, 24 Feb 2016, Jan Beulich wrote:
> >>> On 23.02.16 at 19:36, wrote:
> > Clang-3.8 generates several .data.rel.ro sections when compiling Xen. As
> > these contain no global symbols, they should be .data.rel.ro.local. This
> > breaks the SPECIAL_DATA_SECTIONS check when converting the tran
On Tue, Feb 23, 2016 at 5:13 AM, Shannon Zhao wrote:
>
>
> On 2016/2/9 13:04, Rob Herring wrote:
>> On Thu, Feb 4, 2016 at 9:05 PM, Shannon Zhao
>> wrote:
>>> From: Shannon Zhao
>>>
>>> Sometimes it needs to check if there is a node in FDT by full path.
>>
>> I'm confused. Are you searching by
>>> On 23.02.16 at 03:05, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -298,6 +298,29 @@ int hvm_set_guest_pat(struct vcpu *v, u64 guest_pat)
> return 1;
> }
>
> +/*
> + * Get the ratio to scale host TSC frequency to gtsc_khz. zero will be
> + * returned if TSC
On Wed, 24 Feb 2016, Jan Beulich wrote:
> >>> On 23.02.16 at 17:31, wrote:
> > The use of MAP_SMALL_PAGES causes shattering of the superpages making up the
> > Xen virtual region, and is counter to the purpose of this series.
> > Furthermore, it is not required for the memguard infrastructure to f
bcc/ld86/as86 are necessary when we build ROMBIOS. However if we do not
build it (and are not building qemu-trad), the build requirements are
overly strict and can lead to failures.
Signed-off-by: Doug Goldstein
Reviewed-by: Konrad Rzeszutek Wilk
---
CC: Ian Jackson
CC: Stefano Stabellini
CC:
On Wed, Feb 17, 2016 at 8:22 PM, Konrad Rzeszutek Wilk
wrote:
>> +{
>> +*gfn = bfn;
>> +return 0;
>> +}
>> +
>> +if ( !iommu_enabled || !hd->platform_ops ||
>> +!hd->platform_ops->lookup_page )
>> +return -ENOMEM;
>
> -ENOMEM ? ENXIO ? Or maybe -ENOS
>>> On 23.02.16 at 03:05, wrote:
> This patch adds the initialization and setup code for VMX TSC scaling.
>
> Signed-off-by: Haozhong Zhang
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 24/02/16 15:08, George Dunlap wrote:
> On Wed, Feb 17, 2016 at 8:22 PM, Konrad Rzeszutek Wilk
> wrote:
>>> +{
>>> +*gfn = bfn;
>>> +return 0;
>>> +}
>>> +
>>> +if ( !iommu_enabled || !hd->platform_ops ||
>>> +!hd->platform_ops->lookup_page )
>>> +
>>> On 24.02.16 at 15:41, wrote:
> On Wed, Feb 24, 2016 at 08:34:31AM -0600, Doug Goldstein wrote:
>> On 2/16/16 7:52 AM, Wei Liu wrote:
>> > On Tue, Feb 16, 2016 at 01:43:26PM +, Ian Campbell wrote:
>> >> On Mon, 2016-02-15 at 16:13 +, Wei Liu wrote:
>> >>> On Mon, Feb 15, 2016 at 08:38:0
>>> On 23.02.16 at 03:05, wrote:
> This patch implements a common function hvm_scale_tsc() to scale TSC by
> using TSC scaling information collected by architecture code.
>
> Signed-off-by: Haozhong Zhang
Reviewed-by: Jan Beulich
Also I note that
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b
On Wed, Feb 24, 2016 at 08:14:09AM -0700, Jan Beulich wrote:
> >>> On 24.02.16 at 15:41, wrote:
> > On Wed, Feb 24, 2016 at 08:34:31AM -0600, Doug Goldstein wrote:
> >> On 2/16/16 7:52 AM, Wei Liu wrote:
> >> > On Tue, Feb 16, 2016 at 01:43:26PM +, Ian Campbell wrote:
> >> >> On Mon, 2016-02-1
>>> On 24.02.16 at 15:58, wrote:
> On 24/02/16 14:15, Jan Beulich wrote:
> On 24.02.16 at 14:57, wrote:
>>> On 24/02/16 11:24, Jan Beulich wrote:
>>> On 23.02.16 at 17:31, wrote:
> GLOBAL(l1_identmap)
> -pfn = 0
> +idx = 0
> .rept L1_PAGETABLE_
On 24/02/16 15:18, Jan Beulich wrote:
On 24.02.16 at 15:58, wrote:
>> On 24/02/16 14:15, Jan Beulich wrote:
>> On 24.02.16 at 14:57, wrote:
On 24/02/16 11:24, Jan Beulich wrote:
> >>> On 23.02.16 at 17:31, wrote:
>> GLOBAL(l1_identmap)
>> -pfn = 0
>> +
Hey Dario: We are aiming for the next release and would appreciate it if
you can leave some comments on this version. Thanks.
Tianyang
On 2/8/2016 11:33 PM, Tianyang Chen wrote:
Changes since v4:
removed unnecessary replenishment queue checks in vcpu_wake()
extended replq_remove() t
> I think actually the first thing you might need to do is to get the xentrace
infrastructure working on ARM
Already done that. It requires some patches to memory manager, timer and
policies. I guess I should upstream them, though.
> After that, the next thing would be to add the equivalent of VM
Baremetal kernels clear .bss early in the boot but Xen PV guests don't
execute that code. They have been able to run without problems because
Xen domain builder happens to give out zeroed pages. However, since this
is not really guaranteed, .bss should be explicitly cleared.
(Since we introduce ma
Today I was trying a newer version of qxl driver on windows 10 domU (on
dom0 with xen 4.6) and I got a windows blue screen about the updated driver.
On latest xl dmesg line I found this error which I suppose is related:
(XEN) memory.c:161:d0v0 Could not allocate order=18 extent: id=53
memflags=0
On 02/24/16 08:01, Jan Beulich wrote:
> >>> On 23.02.16 at 03:05, wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -298,6 +298,29 @@ int hvm_set_guest_pat(struct vcpu *v, u64 guest_pat)
> > return 1;
> > }
> >
> > +/*
> > + * Get the ratio to scale host TSC f
>>> On 24.02.16 at 16:18, wrote:
> On Wed, Feb 24, 2016 at 08:14:09AM -0700, Jan Beulich wrote:
>> >>> On 24.02.16 at 15:41, wrote:
>> > On Wed, Feb 24, 2016 at 08:34:31AM -0600, Doug Goldstein wrote:
>> >> On 2/16/16 7:52 AM, Wei Liu wrote:
>> >> > On Tue, Feb 16, 2016 at 01:43:26PM +, Ian C
patch is applied to the wrong git tree, please drop us a note to
> help improving the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Stefano-Stabellini/hvc_xen-add-earlycon-support/20160224-203006
> base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.
>>> On 24.02.16 at 16:22, wrote:
> On 24/02/16 15:18, Jan Beulich wrote:
> On 24.02.16 at 15:58, wrote:
>>> On 24/02/16 14:15, Jan Beulich wrote:
>>> On 24.02.16 at 14:57, wrote:
> On 24/02/16 11:24, Jan Beulich wrote:
>> >>> On 23.02.16 at 17:31, wrote:
>>> GLOBAL(l1_iden
On 02/24/16 07:24, Jan Beulich wrote:
> >>> On 24.02.16 at 14:28, wrote:
> > On 02/18/16 10:17, Jan Beulich wrote:
> >> >>> On 01.02.16 at 06:44, wrote:
> >> > This design treats host NVDIMM devices as ordinary MMIO devices:
> >>
> >> Wrt the cachability note earlier on, I assume you're aware t
On Wed, Feb 24, 2016 at 08:44:44AM -0700, Jan Beulich wrote:
> >>> On 24.02.16 at 16:18, wrote:
> > On Wed, Feb 24, 2016 at 08:14:09AM -0700, Jan Beulich wrote:
> >> >>> On 24.02.16 at 15:41, wrote:
> >> > On Wed, Feb 24, 2016 at 08:34:31AM -0600, Doug Goldstein wrote:
> >> >> On 2/16/16 7:52 AM,
>>> On 24.02.16 at 16:42, wrote:
> On 02/24/16 08:01, Jan Beulich wrote:
>> >>> On 23.02.16 at 03:05, wrote:
>> > +/* ratio = (gtsc_khz << hvm_funcs.tsc_scaling.ratio_frac_bits) /
>> > cpu_khz */
>> > +asm (
>> > +"shldq %2,%1,%0; salq %2,%1; divq %3"
>> > +: "+&d" (dummy
On Wed, 2016-02-24 at 17:24 +0200, Paul Sujkov wrote:
> > I think actually the first thing you might need to do is to get
> the xentrace infrastructure working on ARM
>
> Already done that. It requires some patches to memory manager, timer
> and policies.
>
Really? Cool!
> I guess I should upstr
On Wed, 24 Feb 2016, Boris Ostrovsky wrote:
> On 02/24/2016 07:23 AM, Stefano Stabellini wrote:
> > Introduce EARLYCON support in hvc_xen, useful for early debugging on arm
> > and arm64, where xen early_printk is not available. Differently from
> > xenboot_write_console on x86, we won't just retur
On 24/02/16 15:24, Paul Sujkov wrote:
>> I think actually the first thing you might need to do is to get the xentrace
> infrastructure working on ARM
>
> Already done that. It requires some patches to memory manager, timer and
> policies. I guess I should upstream them, though.
>
>> After that, t
> Have a look at this series:
> http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg02233.html
Thanks a lot! Looking through it at the moment, looks very promising.
> And I've got another one that I'll send out asap (and I can Cc you).
Thanks in advance :)
> I usually enable a subset
flight 83784 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/83784/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
build-amd6
On 02/24/16 08:51, Jan Beulich wrote:
> >>> On 24.02.16 at 16:42, wrote:
> > On 02/24/16 08:01, Jan Beulich wrote:
> >> >>> On 23.02.16 at 03:05, wrote:
> >> > +/* ratio = (gtsc_khz << hvm_funcs.tsc_scaling.ratio_frac_bits) /
> >> > cpu_khz */
> >> > +asm (
> >> > +"shldq %2,%1,%
On 24/02/16 15:48, Jan Beulich wrote:
On 24.02.16 at 16:22, wrote:
>> On 24/02/16 15:18, Jan Beulich wrote:
>> On 24.02.16 at 15:58, wrote:
On 24/02/16 14:15, Jan Beulich wrote:
On 24.02.16 at 14:57, wrote:
>> On 24/02/16 11:24, Jan Beulich wrote:
>>> >>> On 23.02
On 24/02/16 16:00, Paul Sujkov wrote:
>> Have a look at this series:
>> http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg02233.html
>
> Thanks a lot! Looking through it at the moment, looks very promising.
>
>> And I've got another one that I'll send out asap (and I can Cc you).
>
On Wed, Feb 24, 2016 at 6:58 AM, David Vrabel wrote:
> Yes. Can you respin with a commit message explaining? (Or just provide
> the message here and I'll fix it up).
Is there no way to re-use somehow the clear_bss() from bare metal?
This uses a section range:
/* Don't add a printk in there. pr
. snip..
> There is a neater way of doing this, which doesn't involve having "if (
> regular ) else if ( xsplice )" logic chains through the code.
s/chains/chain/
There is only one that uses the 'xsplice' name in it:-)
The other two are wrapped with the 'is_patch'.
>
> Given a
>
> struct virtu
On Tue, Feb 16, 2016 at 07:35:32PM +, Andrew Cooper wrote:
> On 12/02/16 18:05, Konrad Rzeszutek Wilk wrote:
> > diff --git a/xen/common/symbols.c b/xen/common/symbols.c
> > index a59c59d..bf5623f 100644
> > --- a/xen/common/symbols.c
> > +++ b/xen/common/symbols.c
> > @@ -17,6 +17,7 @@
> > #i
On 24/02/16 16:22, Konrad Rzeszutek Wilk wrote:
> . snip..
>> There is a neater way of doing this, which doesn't involve having "if (
>> regular ) else if ( xsplice )" logic chains through the code.
> s/chains/chain/
>
> There is only one that uses the 'xsplice' name in it:-)
>
> The other two are
On 02/24/2016 11:05 AM, Brian Gerst wrote:
Use the macros in instead of defining your own. Also,
xorl %eax,%eax is good for 64-bit too, since the upper bits are
cleared.
I suspected this would have to be defined somewhere but couldn't find
it. Thanks!
-boris
On 02/24/16 07:36, Jan Beulich wrote:
> >>> On 23.02.16 at 03:04, wrote:
> > Both VMX TSC scaling and SVM TSC ratio use the 64-bit TSC scaling ratio,
> > but the number of fractional bits of the ratio is different between VMX
> > and SVM. This patch adds the architecture code to collect the number
> >>> On 24.02.16 at 08:04, wrote:
> > I found the code path when creating the L2 guest:
>
> thanks for the analysis!
>
> > (XEN)nvmx_handle_vmclear
> > (XEN)nvmx_handle_vmptrld
> > (XEN)map_io_bitmap_all
> > (XEN)_map_io_bitmap
> > (XEN)virtual_vmcs_enter
> > (XEN)_map_io_bitmap
> > (XEN)virtu
On Feb 24, 2016 12:33 AM, "Ingo Molnar" wrote:
>
> For hard coded platform quirks I'd suggest we add x86_platform.quirks flags.
> For
> example the F00F hack for Xen could be done via:
>
> x86_platform.quirks.idt_remap = 0;
>
Don't we unconditionally remap the IDT? I think Kees did it f
On 02/24/16 09:00, Ross Philipson wrote:
[...]
> > For each NVDIMM device defined in NFIT, there is a ACPI namespace device
> > (e.g. NVD0, NVD1) under the root NVDIMM device (NVDR). Because the
> > number of vNVDIMM devices are unknown at build time, we can not
> > determine whether and how many N
On 02/24/2016 11:22 AM, Luis R. Rodriguez wrote:
On Wed, Feb 24, 2016 at 6:58 AM, David Vrabel wrote:
Yes. Can you respin with a commit message explaining? (Or just provide
the message here and I'll fix it up).
Is there no way to re-use somehow the clear_bss() from bare metal?
xen_start_in
>>> On 24.02.16 at 16:48, wrote:
> On 02/24/16 07:24, Jan Beulich wrote:
>> >>> On 24.02.16 at 14:28, wrote:
>> > On 02/18/16 10:17, Jan Beulich wrote:
>> >> >>> On 01.02.16 at 06:44, wrote:
>> >> > 3.3 Guest ACPI Emulation
>> >> >
>> >> > 3.3.1 My Design
>> >> >
>> >> > Guest ACPI emulation
flight 83745 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/83745/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 83611
Tests which did not succeed, but a
>>> On 24.02.16 at 17:14, wrote:
> On 24/02/16 15:48, Jan Beulich wrote:
> On 24.02.16 at 16:22, wrote:
>>> On 24/02/16 15:18, Jan Beulich wrote:
>>> On 24.02.16 at 15:58, wrote:
> On 24/02/16 14:15, Jan Beulich wrote:
> On 24.02.16 at 14:57, wrote:
>>> On 24/02/16 11:24
On Wed, Feb 10, 2016 at 10:10 AM, Malcolm Crossley
wrote:
> Add a pointer to the page struct which refers to the head of
> m2b tracking structure for that page.
>
> Atomically add a PGC bit to the page struct when setting the pointer to
> the m2b tracking structure.
>
> Adding elements to the per
> I could do the same here by dropping the if (!xen_pv_domain()) check
> above, but then if somebody specifies earlyprintk=xenboot on a non-Xen
> environment, I expect Linux would crash.
Nah, you made it "Work" with:
commit eb5ef07151ba3c3cb4bcef0c8f146ff1115eaa55
Author: Stefano Stabellini
Date:
If grep 2.23 is installed, build fails like this:
...
mkdir -p compat
grep -v 'DEFINE_XEN_GUEST_HANDLE(long)' public/grant_table.h | \
python /home/SOURCES/xen/xen/xen.git/xen/tools/compat-build-source.py
>compat/grant_table.c.new
mv -f compat/grant_table.c.new compat/grant_table.c
gcc ... -o com
On 24/02/16 17:18, Konrad Rzeszutek Wilk wrote:
>> I could do the same here by dropping the if (!xen_pv_domain()) check
>> above, but then if somebody specifies earlyprintk=xenboot on a non-Xen
>> environment, I expect Linux would crash.
> Nah, you made it "Work" with:
> commit eb5ef07151ba3c3cb4bc
On 24/02/16 15:19, Boris Ostrovsky wrote:
> Baremetal kernels clear .bss early in the boot but Xen PV guests don't
> execute that code. They have been able to run without problems because
> Xen domain builder happens to give out zeroed pages. However, since this
> is not really guaranteed, .bss sho
On 24/02/16 16:59, Jan Beulich wrote:
On 24.02.16 at 17:14, wrote:
>> On 24/02/16 15:48, Jan Beulich wrote:
>> On 24.02.16 at 16:22, wrote:
On 24/02/16 15:18, Jan Beulich wrote:
On 24.02.16 at 15:58, wrote:
>> On 24/02/16 14:15, Jan Beulich wrote:
>> On 24.02.1
1 - 100 of 193 matches
Mail list logo
