On Wed, Feb 24, 2016 at 5:38 PM, Ian Campbell
wrote:
> On Wed, 2016-02-24 at 16:35 +0530, Sanjeev Pandita wrote:
> > Hi Ian/All,
>
> Please don't top post.
>
> > If I run the command manually it says OSError: no such file or directory
> > .
> >
> > [root@localhost ~]# /usr/local/lib/xen/bin/pygru
> On February 17, 2016 10:23pm, wrote:
> >>> On 05.02.16 at 11:18, wrote:
> > to pass down a flag indicating whether the lock is being held, and
> > check the way up the call trees.
>
> Same comments as on the previous patch; most of the changes outside of
> xen/drivers/passthrough/ seem to be
Hi Andrei.
On 25 February 2016 at 02:12, Andrei Borzenkov wrote:
> 24.02.2016 21:01, fu@linaro.org пишет:
>> From: Fu Wei
>>
>> Signed-off-by: Fu Wei
>> ---
>> grub-core/loader/arm64/xen_boot.c | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/grub-core/loader/arm64/xen_b
> 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)virtual_vmcs_enter
> > (XEN)_map_msr_bitmap
> > (XEN)virtual_vmcs_enter
> > (XEN)nvmx_set_vmcs_poin
From: Fu Wei
This patchset add xen_boot support into grup-mkconfig for
generating xen boot entrances automatically
Also update the docs/grub.texi for new xen_boot commands.
This patchset has been tested on Foudation model with a bug fix:
http://lists.gnu.org/archive/html/grub-devel/2016-02/msg0
From: Fu Wei
This patch adds the support of xen_boot command:
xen_hypervisor
xen_module
Also add a new "feature_xen_boot" to indicate this grub support
xen_boot command.
Signed-off-by: Fu Wei
---
grub-core/normal/main.c | 2 +-
util/grub.d/20_linux_xen.in | 13 ++---
2 fi
From: Fu Wei
delete: xen_linux, xen_initrd, xen_xsm
add: xen_module
This update bases on
commit 0edd750e50698854068358ea53528100a9192902
Author: Vladimir Serbinenko
Date: Fri Jan 22 10:18:47 2016 +0100
xen_boot: Remove obsolete module type distinctions.
Signed-off-by: Fu
From: Fu Wei
This patch adds "--nounzip" option support in order to
be compatible with the module command of i386, then we can
simplify grub-mkconfig support code.
Signed-off-by: Fu Wei
---
grub-core/loader/arm64/xen_boot.c | 17 +
1 file changed, 17 insertions(+)
diff --git a
From: Fu Wei
Signed-off-by: Fu Wei
---
grub-core/loader/i386/xen.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader/i386/xen.c
index c4d9689..15b0727 100644
--- a/grub-core/loader/i386/xen.c
+++ b/grub-core/loader/i386/xen.c
@@ -689,6 +68
On 2/24/2016 9:02 PM, Dario Faggioli wrote:
Hey,
Here I am, sorry for the delay. :-(
No problem, I think we are almost there.
On Mon, 2016-02-08 at 23:33 -0500, Tianyang Chen wrote:
Changes since v4:
removed unnecessary replenishment queue checks in vcpu_wake()
extended replq_rem
flight 83835 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/83835/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399
build-i386-rumpuserxen
Hi,
I am trying to set up COLO by following this
http://wiki.xenproject.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
I was able to follow the step up to
$git am ~/ColoPatchForQemu/*.patch
When I try to run the above command, I got the following error:
error: patch failed: include/hw/xen/xen_comm
flight 83844 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/83844/
Perfect :-)
All tests in this flight passed
version targeted for testing:
xen 2066ddd2327daeb2d92687ea2a88383f0b57a56c
baseline version:
xen 3fba5f5ec6bd2c9375
flight 83847 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/83847/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 guest-saverestorefail never pass
test-armhf-armhf-libvirt 12 migrate-sup
> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: Wednesday, February 24, 2016 8:09 PM
> To: Wu, Feng ; Doug Goldstein ;
> Jan Beulich
> Cc: Tian, Kevin ; Keir Fraser ; George
> Dunlap ; Andrew Cooper
> ; Dario Faggioli ; xen-
> de...@lists.xen.org
> Su
flight 83810 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/83810/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
build-amd64-rumpuserx
flight 83833 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/83833/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail
REGR. vs. 65543
test-amd64-i386-
Hey,
Here I am, sorry for the delay. :-(
On Mon, 2016-02-08 at 23:33 -0500, Tianyang Chen wrote:
> Changes since v4:
> removed unnecessary replenishment queue checks in vcpu_wake()
> extended replq_remove() to all cases in vcpu_sleep()
> used _deadline_queue_insert() helper function f
On Wed, Feb 24, 2016 at 5:18 PM, Luis R. Rodriguez wrote:
>
> On Feb 24, 2016 8:40 AM, "Andy Lutomirski" wrote:
>>
>> 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
On Feb 24, 2016 8:40 AM, "Andy Lutomirski" wrote:
>
> 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;
> >
flight 83820 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/83820/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail
in 83674 pass in 83820
test-am
On 24/02/2016 23:03, Doug Goldstein wrote:
> Remove duplicate definition.
>
> Signed-off-by: Doug Goldstein
> ---
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Remove duplicate definition.
Signed-off-by: Doug Goldstein
---
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
---
xen/include/asm-x86/config.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index 07f3c1f..ee26ab9 100644
---
On Wed, Feb 17, 2016 at 04:10:12AM -0700, Jan Beulich wrote:
> >>> On 16.02.16 at 21:20, wrote:
> > On 12/02/16 18:05, Konrad Rzeszutek Wilk wrote:
> >> +static void xsplice_print_build_id(char *id, unsigned int len)
> >> +{
> >> +unsigned int i;
> >> +
> >> +if ( !len )
> >> +retu
On Wed, Feb 24, 2016 at 07:13:11PM +, Andrew Cooper wrote:
> On 24/02/16 18:52, Konrad Rzeszutek Wilk wrote:
> >>> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> >>> index f501a2f..5cf180f 100644
> >>> --- a/xen/arch/arm/xen.lds.S
> >>> +++ b/xen/arch/arm/xen.lds.S
> >>> @@ -22,
On Wed, Feb 24, 2016 at 10:19 AM, 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 guar
On 24/02/16 18:52, Konrad Rzeszutek Wilk wrote:
>>> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
>>> index f501a2f..5cf180f 100644
>>> --- a/xen/arch/arm/xen.lds.S
>>> +++ b/xen/arch/arm/xen.lds.S
>>> @@ -22,6 +22,9 @@ OUTPUT_ARCH(FORMAT)
>>> PHDRS
>>> {
>>>text PT_LOAD /* XXX
Because of the new 2M alignment of .init and .bss, the existing memory
guarding infrastructure causes a shattered 2M superpage with non-present
entries for .init, and present entries for the alignment space.
Do away with the difference in behaviour between debug and non-debug builds;
always destro
In preparation for using superpage mappings, .data and .bss will both want to
be mapped as read-write. By making them adjacent, they can share the same
superpage and will not require superpage alignment between themselves.
While making this change, fix a latent alignment bug whereby the alignment
In preparation for marking .text as read-only, care needs to be taken not to
fault while applying alternatives.
Swapping back to RW mappings is a possibility, but would require additional
TLB management. A temporary disabling of CR0.WP is cleaner.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulic
This balloons the size of Xen in memory from 4.4MB to 8MB, because of the
required alignment adjustments.
However
* All mappings are 2M superpages.
* .text (and .init at boot) are the only sections marked executable.
* .text and .rodata are marked read-only.
Signed-off-by: Andrew Cooper
---
C
... rather than at runtime.
The bootmaps are discarded in zap_low_mappings(), so the tables themselves can
live in .init.data and be reclaimed after boot.
Hooking the l1_identmap into l2_xenmap stays for safety, along with a longer
comment explaining why.
This does not change the EFI constructio
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() for creating holes).
Signed-off-by: Andre
The entire contents of .lockprofile.data are unchanging pointers to
lock_profile structure in .data. Annotate the type as such, and link the
section in .rodata. As these are just pointers, 32byte alignment is
unnecessary.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Ian Campbell
CC: S
And make use of NX and RO attributes wherever possible.
After this series, the pagetable layout looks like:
(XEN) *** Dumping Xen text/data/bss mappings from 82d08000
(XEN) l2_xenmap: 82d080814000, pa ac014000
(XEN) L4[261] = ac017063 X S RW P
(XEN) L3[322] = 00
* Additional comments, including size and runtime use.
* Consistent use of .quad, rather than a mix including .long.
No change in runtime behaviour.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* New
v3:
* Drop the use of _PAGE_GLOBAL for intermediate levels. While it is safe
(
> > diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> > index f501a2f..5cf180f 100644
> > --- a/xen/arch/arm/xen.lds.S
> > +++ b/xen/arch/arm/xen.lds.S
> > @@ -22,6 +22,9 @@ OUTPUT_ARCH(FORMAT)
> > PHDRS
> > {
> >text PT_LOAD /* XXX should be AT ( XEN_PHYS_START ) */ ;
> > +#if d
Dear Community members,
I wanted to inform you that both Keir Fraser and Tim Deegan, have
formally stepped down in their roles as committers from the Hypervisor
team. In addition, you may have seen that Ian Campbell recently
transferred maintainer-ship for many components to other community
me
flight 83864 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/83864/
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
24.02.2016 21:01, fu@linaro.org пишет:
> From: Fu Wei
>
> Signed-off-by: Fu Wei
> ---
> grub-core/loader/arm64/xen_boot.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/grub-core/loader/arm64/xen_boot.c
> b/grub-core/loader/arm64/xen_boot.c
> index 8ae43d7..ef03111 10064
24.02.2016 21:01, fu@linaro.org пишет:
> From: Fu Wei
>
> This patch adds the support of xen_boot command:
> xen_hypervisor
> xen_module
>
> Signed-off-by: Fu Wei
> ---
> util/grub.d/20_linux_xen.in | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> di
On Wed, Feb 10, 2016 at 10:33 AM, Malcolm Crossley
wrote:
> This RFC series implements the PV-IOMMU interface according to the PV-IOMMU
> design draft D.
>
> The PV-IOMMU interface is currently restricted to being used by the hardware
> domain only as non hardware domain callers have not been full
From: Fu Wei
Signed-off-by: Fu Wei
---
grub-core/loader/i386/xen.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader/i386/xen.c
index c4d9689..15b0727 100644
--- a/grub-core/loader/i386/xen.c
+++ b/grub-core/loader/i386/xen.c
@@ -689,6 +68
From: Fu Wei
This patchset add xen_boot support into grup-mkconfig for
generating xen boot entrances automatically
ChangeLog:
v1 :first upstream patchset.
Fu Wei (3):
arm64: add grub_xen_boot env to indicate that we have xen_* commands
* util/grub.d/20_linux_xen.in: Add support of the xen_b
From: Fu Wei
This patch adds the support of xen_boot command:
xen_hypervisor
xen_module
Signed-off-by: Fu Wei
---
util/grub.d/20_linux_xen.in | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.i
From: Fu Wei
Signed-off-by: Fu Wei
---
grub-core/loader/arm64/xen_boot.c | 8
1 file changed, 8 insertions(+)
diff --git a/grub-core/loader/arm64/xen_boot.c
b/grub-core/loader/arm64/xen_boot.c
index 8ae43d7..ef03111 100644
--- a/grub-core/loader/arm64/xen_boot.c
+++ b/grub-core/loade
> You mean, you have local patches you haven't upstreamed? Or they're
> already upstream? (If the latter, I don't see the trace definitions in
> xen/include/public/trace.h...)
Yep, local patches. Some of them still look like a dirty hacks which is why
they've been used internally for a while but
On Wed, 2016-02-24 at 16:37 +0530, Harmandeep Kaur wrote:
> Check the return value of xc_version() and return NULL if it
> fails. libxl_get_version_info() can also return NULL now.
>
> Callers of the function libxl_get_version_info() are already
> prepared to deal with a NULL return value.
>
> Co
On 02/24/2016 11:42 AM, Haozhong Zhang wrote:
> 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 tim
On 02/24/2016 12:26 PM, Andrew Cooper wrote:
On 24/02/16 15:19, Boris Ostrovsky wrote:
+ /* Clear .bss */
+ xor REG(ax),REG(ax)
If we are nitpicking,
This should be xor %eax, %eax even in 64bit. Functionally identical,
and shorter to encode.
Right, Brian Gerst pointed this out t
On Wed, 2016-02-24 at 11:14 +, George Dunlap wrote:
> On 24/02/16 11:12, Dario Faggioli wrote:
> >
> > No, I'll resend... If I make (only) this change, can I resend
> > directly
> > with your Acked-by?
>
> Well I won't know what it looks like until I see it, will I? :-)
> I prioritize recentl
Moving a vCPU to a different pCPU means offlining it and
then waking it up, on the new pCPU. Credit1 grants BOOST
priority to vCPUs that wakes up, with the aim of improving
I/O latency. The net effect of this all is that vCPUs get
boosted when migrating, which shouldn't happen.
For instance, this
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
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 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
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
> 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:
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
>>> 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 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 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 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 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 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 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 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 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 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 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 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 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 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,%
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
> 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
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
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 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 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, 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 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 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
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: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
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
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
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
> 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
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
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
>> +
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 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 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 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 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 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
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, 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
1 - 100 of 193 matches
Mail list logo
