On Mon, Aug 29, 2016 at 08:17:21AM +0200, Juergen Gross wrote:
> arch/x86/x86_64.S contains some unnecessary macros. Remove them.
>
> Add a SAVE_PARAVIRT macro for saving %rcx and %r11 on the stack in
> case of CONFIG_PARAVIRT defined.
>
> Remove the parameter from HYPERVISOR_IRET macro as it is
On Mon, Aug 29, 2016 at 08:22:14AM +0200, Juergen Gross wrote:
> On 08/08/16 10:28, Juergen Gross wrote:
> > Support xenstore domain autoballooning by:
> > - adding --maxmem parameter to init-xenstore-domain
> > - build xenstore stubdom with Mini-OS CONFIG_BALLOON set
> > - add XENSTORE_MAX_DOMAIN_
>>> On 29.08.16 at 04:47, wrote:
> On Wed, Aug 24, 2016 at 04:01:53AM -0600, Jan Beulich wrote:
>> >>> On 19.08.16 at 12:20, wrote:
>> > @@ -1403,12 +1437,12 @@ void __init noreturn __start_xen(unsigned long
>> > mbi_p)
>> >
>> > if ( !opt_smep )
>> > setup_clear_cpu_cap(X86_FEAT
flight 100650 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100650/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-rumpuserxen 6 xen-buildfail like 100644
build-i386-rumpuserxen
Wei Liu, on Mon 29 Aug 2016 09:51:52 +0100, wrote:
> On Mon, Aug 29, 2016 at 08:17:21AM +0200, Juergen Gross wrote:
> > arch/x86/x86_64.S contains some unnecessary macros. Remove them.
> >
> > Add a SAVE_PARAVIRT macro for saving %rcx and %r11 on the stack in
> > case of CONFIG_PARAVIRT defined.
>
>>> On 26.08.16 at 17:11, wrote:
> On 08/25/2016 11:06 AM, Jan Beulich wrote:
> On 24.08.16 at 14:43, wrote:
>>> This patch introduces support for using TSC as platform time source
>>> which is the highest resolution time and most performant to get (~20
>>> nsecs).
>>
>> Is this indeed still
>>> On 26.08.16 at 17:13, wrote:
> On 08/25/2016 11:17 AM, Jan Beulich wrote:
> On 24.08.16 at 14:43, wrote:
>>> In the case of clocksource=tsc we will
>>> use it to set tsc_timestamp.
>>
>> I don't see how this relates to the patch here.
>>
>> The change itself looks reasonable assuming it
The 'idx' can equal to the max number of vCPUs, fix it.
Signed-off-by: Feng Wu
---
xen/drivers/passthrough/io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 9e6b46c..66577b6 100644
--- a/xen/drivers/passthro
flight 100653 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100653/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 37136e069dc0a0b8a47098d80d8f6f742db88c04
baseline version:
ovmf 81d9f86f8a7106b59057e
>>> On 26.08.16 at 17:12, wrote:
> On 08/25/2016 11:13 AM, Jan Beulich wrote:
> On 24.08.16 at 14:43, wrote:
>>> And use to initialize platform time solely for clocksource=tsc,
>>> as opposed to initializing platform overflow timer, which would
>>> only fire in ~180 years (on 2.2 Ghz Broadwel
>>> On 26.08.16 at 17:44, wrote:
> On 08/25/2016 11:37 AM, Jan Beulich wrote:
> On 24.08.16 at 14:43, wrote:
>>> This patch proposes relying on host TSC synchronization and
>>> passthrough to the guest, when running on a TSC-safe platform. On
>>> time_calibration we retrieve the platform time
On Mon, Aug 29, 2016 at 08:17:19AM +0200, Juergen Gross wrote:
> Do some cleanups in Mini-OS.
>
> V2: modified patch 2 as suggested by Andrew Cooper
>
> Juergen Gross (3):
> mini-os: cleanup x86_32.S
> mini-os: cleanup x86_64.S
> mini-os: remove unused functions from sched.c
>
> arch/x86/
I have tested it both on
Xen 4.8 and Debian Stretch : Kernel version 4.6
Xen 4.6 and Debian Jessie : Kernel version 3.19
and also Xen 4.6 and 4.7 on ubuntu Kernel 3.16
On Wed, Aug 24, 2016 at 3:38 PM, Roger Pau Monné
wrote:
> On Fri, Aug 19, 2016 at 08:45:49PM +0430, Cendrin Sa wrote:
> > Hi aga
Vitaly Kuznetsov writes:
> David Vrabel writes:
>
>> On 22/08/16 16:42, Vitaly Kuznetsov wrote:
>>>
>>> I see two ways to fix the issue:
>>> - Change the 'wire' protocol between netfront and netback to start keeping
>>> the original SKB structure. We'll have to add a flag indicating the fact
>>> On 27.08.16 at 12:40, wrote:
> I'll test this in more detail next week to make sure things really
> work as expected (atm I'm just testing if dom0 boots properly). And if
> things turn OK and you think this is a proper fix for the issue and
> safe to apply, I can send the patch properly to the
grub-stubdom and ioemu-stubdom rely on Mini-OS exporting the start_info
structure via a global variable. To use this feature in future we must
specify CONFIG_KEEP_STARTINFO in the Mini-OS config file.
Signed-off-by: Juergen Gross
---
stubdom/grub/minios.cfg | 1 +
stubdom/ioemu-minios.cfg | 1 +
get_xenbus() should be called only if CONFIG_XENBUS is set.
Signed-off-by: Juergen Gross
---
include/xenbus.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/xenbus.h b/include/xenbus.h
index 5646a25..c254652 100644
--- a/include/xenbus.h
+++ b/include/xenbus.h
@@
The patch series adding HVMlite support for Mini-OS unfortunately
broke building Xen's stubdoms. This small series repairs the broken
bits again.
Please note that there is still some action required in Xen:
ioemu and grub stubdom minios.cfg files need CONFIG_KEEP_STARTINFO=y
to be added. I'm sendi
grub stubdom needs the start_info structure. Keep a copy of it in
pv mini-os if configured via "CONFIG_KEEP_STARTINFO". This should
default to "n" in order to have it enabled only when really needed.
Signed-off-by: Juergen Gross
---
Config.mk| 2 ++
arch/x86/setup.c | 12 +++
>>> On 29.08.16 at 01:14, wrote:
First of all - please don't cross post.
> Den 17. aug. 2016 21:56, I wrote (to xen-users, as I am no developer):
>> I'm on gentoo, running gentoo-sources kernel for dom0.
>>
>> I am unable to run gentoo-sources-4.7.{0,1}. I'm running under xen,
>> currently at 4.
On Mon, Aug 29, 2016 at 01:01:08PM +0200, Juergen Gross wrote:
> grub stubdom needs the start_info structure. Keep a copy of it in
> pv mini-os if configured via "CONFIG_KEEP_STARTINFO". This should
> default to "n" in order to have it enabled only when really needed.
>
I'm not sure I understand
On Mon, Aug 29, 2016 at 01:01:09PM +0200, Juergen Gross wrote:
> get_xenbus() should be called only if CONFIG_XENBUS is set.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.or
On 29/08/16 13:09, Wei Liu wrote:
> On Mon, Aug 29, 2016 at 01:01:08PM +0200, Juergen Gross wrote:
>> grub stubdom needs the start_info structure. Keep a copy of it in
>> pv mini-os if configured via "CONFIG_KEEP_STARTINFO". This should
>> default to "n" in order to have it enabled only when really
On 29/08/2016 12:17, Juergen Gross wrote:
> On 29/08/16 13:09, Wei Liu wrote:
>> On Mon, Aug 29, 2016 at 01:01:08PM +0200, Juergen Gross wrote:
>>> grub stubdom needs the start_info structure. Keep a copy of it in
>>> pv mini-os if configured via "CONFIG_KEEP_STARTINFO". This should
>>> default to
>>> On 29.08.16 at 11:14, wrote:
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -243,7 +243,7 @@ static struct vcpu *vector_hashing_dest(const struct
> domain *d,
> for ( i = 0; i <= mod; i++ )
> {
> idx = find_next_bit(dest_vcpu_bitm
Hello,
in the context of
https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg03068.html
I once again came across the different behavior our various
implementations of the $subject functions, in particular their varying
handling of the offset argument being greater / greater-or-equal
th
Hi Jan,
> I think this is reasonable, despite it certainly being unexpected for
> the BIOS to turn such on when not putting the system into x2APIC
> mode.
It seems that linux doesn't use x2APIC because the BIOS explicitly
"opts out" of it :
"DMAR-IR: x2apic is disabled because BIOS sets x2apic
The struct hvm_domain.vmx is defined in a union along with the svm.
This can causes issue for SVM since this code is used in the common
scheduling code for x86. The logic must check for cpu_has_vmx before
accessing the hvm_domain.vmx sturcture.
Signed-off-by: Suravee Suthikulpanit
Cc: Wei Liu
Cc
On 29/08/2016 12:59, Jan Beulich wrote:
> Hello,
>
> in the context of
> https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg03068.html
> I once again came across the different behavior our various
> implementations of the $subject functions, in particular their varying
> handling of th
On Mon, Aug 29, 2016 at 01:17:56PM +0200, Juergen Gross wrote:
> On 29/08/16 13:09, Wei Liu wrote:
> > On Mon, Aug 29, 2016 at 01:01:08PM +0200, Juergen Gross wrote:
> >> grub stubdom needs the start_info structure. Keep a copy of it in
> >> pv mini-os if configured via "CONFIG_KEEP_STARTINFO". Thi
On 08/26/2016 10:18 AM, Jan Beulich wrote:
On 26.08.16 at 08:11, wrote:
>> +rc = p2m_set_mem_access(d, _gfn(mao.pfn), arr, mao.nr, start_iter,
>> +MEMOP_CMD_MASK, mao.access, 0);
>
> Please don't pass mao.pfn here when it's meant to be ignore by
> the
On 08/29/2016 03:11 PM, Razvan Cojocaru wrote:
> On 08/26/2016 10:18 AM, Jan Beulich wrote:
> On 26.08.16 at 08:11, wrote:
>>> +rc = p2m_set_mem_access(d, _gfn(mao.pfn), arr, mao.nr, start_iter,
>>> +MEMOP_CMD_MASK, mao.access, 0);
>>
>> Please don't pas
On 29/08/16 13:47, Andrew Cooper wrote:
> On 29/08/2016 12:17, Juergen Gross wrote:
>> On 29/08/16 13:09, Wei Liu wrote:
>>> On Mon, Aug 29, 2016 at 01:01:08PM +0200, Juergen Gross wrote:
grub stubdom needs the start_info structure. Keep a copy of it in
pv mini-os if configured via "CONFI
On 29/08/2016 13:28, Juergen Gross wrote:
> On 29/08/16 13:47, Andrew Cooper wrote:
>> On 29/08/2016 12:17, Juergen Gross wrote:
>>> On 29/08/16 13:09, Wei Liu wrote:
On Mon, Aug 29, 2016 at 01:01:08PM +0200, Juergen Gross wrote:
> grub stubdom needs the start_info structure. Keep a copy o
>>> On 29.08.16 at 14:03, wrote:
> On 29/08/2016 12:59, Jan Beulich wrote:
>> in the context of
>> https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg03068.html
>> I once again came across the different behavior our various
>> implementations of the $subject functions, in particular
>>> On 29.08.16 at 14:00, wrote:
>> I think this is reasonable, despite it certainly being unexpected for
>> the BIOS to turn such on when not putting the system into x2APIC
>> mode.
>
> It seems that linux doesn't use x2APIC because the BIOS explicitly
> "opts out" of it :
>
> "DMAR-IR: x2apic
This run is configured for baseline tests only.
flight 67602 linux-3.10 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67602/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow210 guest-start
There is no SCCS file.
Signed-off-by: Wei Liu
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index b783684..a8ae67c 100644
--- a/Makefile
+++ b/Makefile
@@ -175,7 +175,7 @@ clean: arch_clean
define all_sources
- ( find . -name S
Use GNU Global to generate source code index.
Signed-off-by: Wei Liu
---
Makefile | 4
1 file changed, 4 insertions(+)
diff --git a/Makefile b/Makefile
index a8ae67c..43dcbd6 100644
--- a/Makefile
+++ b/Makefile
@@ -190,3 +190,7 @@ tags:
.PHONY: TAGS
TAGS:
$(all_sources) | xargs
Wei Liu (3):
Makefile: simplify all_sources macro
Makefile: add gtags target
gitignore: ignore files generated by various indexing software
.gitignore | 7 +++
Makefile | 6 +-
2 files changed, 12 insertions(+), 1 deletion(-)
--
2.1.4
__
Signed-off-by: Wei Liu
---
.gitignore | 7 +++
1 file changed, 7 insertions(+)
diff --git a/.gitignore b/.gitignore
index efc193c..e55133d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,6 +2,13 @@
*.o
*.a
*.swp
+cscope.*
+GPATH
+GRTAGS
+GTAGS
+TAGS
+tags
+
arch/x86/minios-x86*.lds
inclu
On 29/08/16 15:01, Wei Liu wrote:
> There is no SCCS file.
>
> Signed-off-by: Wei Liu
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 29/08/16 15:01, Wei Liu wrote:
> Use GNU Global to generate source code index.
>
> Signed-off-by: Wei Liu
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 29/08/16 15:01, Wei Liu wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 29/08/16 14:32, Andrew Cooper wrote:
> On 29/08/2016 13:28, Juergen Gross wrote:
>> On 29/08/16 13:47, Andrew Cooper wrote:
>>> On 29/08/2016 12:17, Juergen Gross wrote:
On 29/08/16 13:09, Wei Liu wrote:
> On Mon, Aug 29, 2016 at 01:01:08PM +0200, Juergen Gross wrote:
>> grub stubdo
Dear Xen-Devel Community:
I’m a grad student working on measuring performance counters at the Xen
domains. I read this
thread(https://wiki.xenproject.org/wiki/Xen_Profiling:_oprofile_and_perf) in
web, and it says using Linux perf command will let us collecting performance
counters in both dom0
This run is configured for baseline tests only.
flight 67604 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67604/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 37136e069dc0a0b8a47098d80d8f6f742db88c04
baseline v
- There's no 32-bit displacement in 16-bit addressing mode.
- It is wrong to ASSERT() anything on parts of an instruction fetched
from guest memory.
- The two scaling bits of a SIB byte don't affect whether there is no
scaled index register.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/trap
There are two cases: The obvious one is that system gates with type 0
shouldn't have what might be their DPL altered - such descriptors can't
be used anyway without incurring a #GP, and hence adjusting its DPL is
only risking to confuse the guest.
The less obvious (and potentially controversial) p
>>> On 09.08.16 at 12:40, wrote:
> This doesn't cover all of them, just the ones that I think would most
> obviously better be -EINVAL or -EOPNOTSUPP.
Ping? There was a little bit of feedback, but non that really resulted in
a need to change something (so far at least).
Jan
> Signed-off-by: Jan
On Tue, 23 Aug 2016 18:31:05 +0200
"Luis R. Rodriguez" wrote:
> On Tue, Aug 23, 2016 at 12:11:40AM +0900, Masami Hiramatsu wrote:
> > On Fri, 19 Aug 2016 14:34:12 -0700
> > mcg...@kernel.org wrote:
> >
> > > From: "Luis R. Rodriguez"
> > >
> > > Often all is needed is these small helpers, inst
flight 67603 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67603/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-amd64-sid-netboot-pygrub 9 debian-di-install fail like 67575
test-amd64-i386-i38
On 29/08/16 13:01, Juergen Gross wrote:
> grub-stubdom and ioemu-stubdom rely on Mini-OS exporting the start_info
> structure via a global variable. To use this feature in future we must
> specify CONFIG_KEEP_STARTINFO in the Mini-OS config file.
>
> Signed-off-by: Juergen Gross
Please ignore: s
Commit e33452c4f5547ed14defe6382b3b53664ac5bd8a ("remove using
start_info in architecture independent code") removed the start_info
variable completely. grub stubdom needs the start_info structure.
Readd the start_info structure, but make it dependent on
CONFIG_PARAVIRT.
Signed-off-by: Juergen Gr
get_xenbus() should be called only if CONFIG_XENBUS is set.
Signed-off-by: Juergen Gross
---
include/xenbus.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/xenbus.h b/include/xenbus.h
index 5646a25..c254652 100644
--- a/include/xenbus.h
+++ b/include/xenbus.h
@@
On Mon, Aug 29, 2016 at 05:04:05AM -0600, Jan Beulich wrote:
> >>> On 29.08.16 at 01:14, wrote:
>
> First of all - please don't cross post.
>
> > Den 17. aug. 2016 21:56, I wrote (to xen-users, as I am no developer):
> >> I'm on gentoo, running gentoo-sources kernel for dom0.
> >>
> >> I am unab
The patch series adding HVMlite support for Mini-OS unfortunately
broke building Xen's stubdoms. This small series repairs the broken
bits again.
V2: patch 1: remove CONFIG_KEEP_STARTINFO
Juergen Gross (2):
mini-os: partially revert "remove using start_info ..."
mini-os: don't get xenbus para
On Mon, Aug 29, 2016 at 07:01:23AM -0500, Suravee Suthikulpanit wrote:
> The struct hvm_domain.vmx is defined in a union along with the svm.
> This can causes issue for SVM since this code is used in the common
You scared me with the 'can causes'!
Digging in the pahole output - it It can't cause
>>> On 29.08.16 at 16:26, wrote:
> On Mon, Aug 29, 2016 at 05:04:05AM -0600, Jan Beulich wrote:
>> >>> On 29.08.16 at 01:14, wrote:
>>
>> First of all - please don't cross post.
>>
>> > Den 17. aug. 2016 21:56, I wrote (to xen-users, as I am no developer):
>> >> I'm on gentoo, running gentoo-so
Mounting proc in user namespace containers fails if the xenbus
filesystem is mounted on /proc/xen because this directory fails
the "permanently empty" test. proc_create_mount_point() exists
specifically to create such mountpoints in proc but is currently
proc-internal. Export this interface to modu
On 08/26/2016 11:14 AM, Jan Beulich wrote:
On 26.08.16 at 09:40, wrote:
>> On 08/26/16 10:18, Jan Beulich wrote:
>> On 26.08.16 at 08:11, wrote:
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -15,7 +15,6 @@ CHECK_TYPE(domid);
#undef compat_domid
Den 29. aug. 2016 13:04, skrev Jan Beulich:
On 29.08.16 at 01:14, wrote:
> Den 17. aug. 2016 21:56, I wrote (to xen-users, as I am no developer):
>>> I'm on gentoo, running gentoo-sources kernel for dom0.
>>>
>>> I am unable to run gentoo-sources-4.7.{0,1}. I'm running under xen,
>>> currentl
So far accesses to Intel MSRs on an AMD system fall through to the
default case, while accesses to AMD MSRs on an Intel system bail (in
the RDMSR case without updating EAX and EDX). Make the "AMD MSRs on
Intel" case match the "Intel MSR on AMD" one.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/
>>> On 29.08.16 at 17:29, wrote:
> On 08/26/2016 11:14 AM, Jan Beulich wrote:
> On 26.08.16 at 09:40, wrote:
>>> On 08/26/16 10:18, Jan Beulich wrote:
>>> On 26.08.16 at 08:11, wrote:
> @@ -76,6 +76,17 @@ int mem_access_memop(unsigned long cmd,
> }
> break;
On 08/29/16 18:42, Jan Beulich wrote:
On 29.08.16 at 17:29, wrote:
>> On 08/26/2016 11:14 AM, Jan Beulich wrote:
>> On 26.08.16 at 09:40, wrote:
On 08/26/16 10:18, Jan Beulich wrote:
On 26.08.16 at 08:11, wrote:
>> @@ -76,6 +76,17 @@ int mem_access_memop(unsigned long
On 08/29/2016 11:37 AM, Jan Beulich wrote:
> So far accesses to Intel MSRs on an AMD system fall through to the
> default case, while accesses to AMD MSRs on an Intel system bail (in
> the RDMSR case without updating EAX and EDX). Make the "AMD MSRs on
> Intel" case match the "Intel MSR on AMD" one
>>> On 29.08.16 at 18:02, wrote:
> On 08/29/16 18:42, Jan Beulich wrote:
> On 29.08.16 at 17:29, wrote:
>>> On 08/26/2016 11:14 AM, Jan Beulich wrote:
>>> On 26.08.16 at 09:40, wrote:
> On 08/26/16 10:18, Jan Beulich wrote:
> On 26.08.16 at 08:11, wrote:
>>> @@ -76,6 +76
On 08/29/2016 09:18 AM, Sanghyun Hong wrote:
> Dear Xen-Devel Community:
>
> I’m a grad student working on measuring performance counters at the
> Xen domains. I read this
> thread(https://wiki.xenproject.org/wiki/Xen_Profiling:_oprofile_and_perf) in
> web, and it says using Linux perf command will
flight 100654 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100654/
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
On 08/29/16 19:20, Jan Beulich wrote:
On 29.08.16 at 18:02, wrote:
>> On 08/29/16 18:42, Jan Beulich wrote:
>> On 29.08.16 at 17:29, wrote:
On 08/26/2016 11:14 AM, Jan Beulich wrote:
On 26.08.16 at 09:40, wrote:
>> On 08/26/16 10:18, Jan Beulich wrote:
>> On 26
On 08/26/2016 05:55 PM, KarimAllah Ahmed wrote:
> Ever since commit 254d1a3f02eb ("xen/pv-on-hvm kexec: shutdown watches
> from old kernel") using the INTx interrupt from Xen PCI platform device for
> event channel notification would just lockup the guest during bootup.
> postcore_initcall now call
Hi Jan
Today I had some free cycles so I spent some time looking at gcov
support in the hypervisor and tried to write a patch to fix the
currently broken gcov build. But my patch alone is not enough to fix
that.
There seems to be a problem with the EFI Makefile. With my patch
applied, efi/boot.in
Juergen Gross, on Mon 29 Aug 2016 15:07:39 +0200, wrote:
> On 29/08/16 15:01, Wei Liu wrote:
> > Use GNU Global to generate source code index.
> >
> > Signed-off-by: Wei Liu
>
> Reviewed-by: Juergen Gross
Acked-by: Samuel Thibault
___
Xen-devel mai
Juergen Gross, on Mon 29 Aug 2016 15:07:55 +0200, wrote:
> On 29/08/16 15:01, Wei Liu wrote:
> > Signed-off-by: Wei Liu
>
> Reviewed-by: Juergen Gross
Acked-by: Samuel Thibault
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org
Juergen Gross, on Mon 29 Aug 2016 15:07:20 +0200, wrote:
> On 29/08/16 15:01, Wei Liu wrote:
> > There is no SCCS file.
> >
> > Signed-off-by: Wei Liu
>
> Reviewed-by: Juergen Gross
Acked-by: Samuel Thibault
___
Xen-devel mailing list
Xen-devel@lis
Wei Liu, on Mon 29 Aug 2016 12:11:21 +0100, wrote:
> On Mon, Aug 29, 2016 at 01:01:09PM +0200, Juergen Gross wrote:
> > get_xenbus() should be called only if CONFIG_XENBUS is set.
> >
> > Signed-off-by: Juergen Gross
>
> Reviewed-by: Wei Liu
Acked-by: Samuel Thibault
Hello,
Juergen Gross, on Mon 29 Aug 2016 16:18:26 +0200, wrote:
> +union start_info_union
> +{
> +start_info_t start_info;
> +char padding[512];
> +};
Why defining a union? 512 is actually not enough for start_info_t.
Samuel
___
Xen-devel mail
Samuel Thibault, on Mon 29 Aug 2016 22:49:07 +0200, wrote:
> Juergen Gross, on Mon 29 Aug 2016 16:18:26 +0200, wrote:
> > +union start_info_union
> > +{
> > +start_info_t start_info;
> > +char padding[512];
> > +};
>
> Why defining a union? 512 is actually not enough for start_info_t.
Ah,
Juergen Gross, on Mon 29 Aug 2016 16:18:26 +0200, wrote:
> Commit e33452c4f5547ed14defe6382b3b53664ac5bd8a ("remove using
> start_info in architecture independent code") removed the start_info
> variable completely. grub stubdom needs the start_info structure.
>
> Readd the start_info structure, b
On 08/29/2016 02:42 PM, Sanghyun Hong wrote:
> Hi Boris,
>
> I’ve found the
> documentations(https://github.com/torvalds/linux/blob/master/Documentation/ABI/testing/sysfs-hypervisor-pmu)
> in the kernel source code, and it seems like if we change the mode
> from *self* to *all* then we can collect
On 08/29/2016 05:08 PM, Sanghyun Hong wrote:
>> Yes, this will allow the hypervisor to collect samples from multiple
>> guests. However, the tool (perf) probably won't be able to properly
>> process these samples. But you can try.
>
> I understand, thus, I applied the patches and set
> the /pmu_mod
On 08/29/2016 05:48 PM, Sanghyun Hong wrote:
> I really appreciate for your answers. Last but not the least, I want to make
> it more clear:
>
>> The hypervisor will provide dom0 with a raw sample (guest's, dom0's or
>> hypervisor's) and then it's the job of dom0 kernel to properly tag and
>> form
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, August 29, 2016 7:51 PM
> To: Wu, Feng
> Cc: xen-devel@lists.xen.org
> Subject: Re: [PATCH] Fix a BUG_ON issue
>
> >>> On 29.08.16 at 11:14, wrote:
> > --- a/xen/drivers/passthrough/io.c
> > +++ b/xen/d
Hi Shannon,
On 16/08/2016 06:25, Shannon Zhao wrote:
From: Shannon Zhao
It uses static DSDT table like the way x86 uses. Currently the DSDT
table only contains processor device objects and it generates the
maximal objects which so far is 128.
Also only check iasl for aarch64 in configure sinc
flight 100655 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100655/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 6 xen-boot fail like 100627
build-amd64-rumpuserxen
Hi Shannon,
On 16/08/2016 06:25, Shannon Zhao wrote:
From: Shannon Zhao
Construct ACPI RSDP table and add a helper to calculate the ACPI table
checksum.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm_acpi.c | 38 ++
1 file changed, 38 insertions(+)
Hi Shannon,
On 16/08/2016 06:25, Shannon Zhao wrote:
From: Shannon Zhao
Construct GTDT table with the interrupt information of timers.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm_acpi.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/tools/libxl/
Hi Shannon,
On 16/08/2016 06:25, Shannon Zhao wrote:
From: Shannon Zhao
Factor MPIDR computing codes out as a helper, so it could be shared
between DT and ACPI.
Signed-off-by: Shannon Zhao
Acked-by: Julien Grall
Regards,
---
tools/libxl/libxl_arm.c | 8 +---
tools/libxl/libxl_arm
Hi Shannon,
On 16/08/2016 06:25, Shannon Zhao wrote:
From: Shannon Zhao
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm_acpi.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 9432e44..
Hi Shannon,
On 16/08/2016 06:25, Shannon Zhao wrote:
From: Shannon Zhao
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm_acpi.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 75dfcc2..cb1c9df
Hi Shannon,
On 16/08/2016 06:25, Shannon Zhao wrote:
From: Shannon Zhao
Add the ARM Multiboot module for ACPI, so UEFI or DomU can get the base
address of ACPI tables from it.
Signed-off-by: Shannon Zhao
Acked-by: Julien Grall
---
docs/misc/arm/device-tree/acpi.txt | 24 +++
Hi Shannon,
On 25/08/2016 04:05, Shannon Zhao wrote:
On 2016/8/24 20:52, Wei Liu wrote:
On Tue, Aug 16, 2016 at 06:25:02PM +0800, Shannon Zhao wrote:
From: Shannon Zhao
Construct ACPI RSDP table and add a helper to calculate the ACPI table
checksum.
Signed-off-by: Shannon Zhao
---
tools
Hi Shannon,
On 16/08/2016 06:25, Shannon Zhao wrote:
From: Shannon Zhao
While it defines the maximum size of guest ACPI tables in guest
memory layout, here it adds the size to set the target maxmem
to avoid providing less available memory for guest.
Signed-off-by: Shannon Zhao
---
tools/lib
Hi Wei,
On 24/08/2016 08:58, Wei Liu wrote:
On Tue, Aug 16, 2016 at 06:24:57PM +0800, Shannon Zhao wrote:
From: Shannon Zhao
The design of this feature is described as below.
Firstly, the toolstack (libxl) generates the ACPI tables according the
number of vcpus and gic controller.
Then, it c
Hi Shannon,
On 16/08/2016 06:25, Shannon Zhao wrote:
From: Shannon Zhao
Add macros for HVM_PARAM_CALLBACK_TYPE_PPI operation values and update
them in evtchn_fixup().
Signed-off-by: Shannon Zhao
---
xen/arch/arm/domain_build.c | 8 +---
xen/include/public/hvm/params.h | 4
2 fi
Hi Shannon,
On 16/08/2016 06:25, Shannon Zhao wrote:
From: Shannon Zhao
Rename finalise_one_memory_node to finalise_one_node and pass the node
name via function parameter.
This is useful for adding ACPI module which will be added by a later
patch.
Signed-off-by: Shannon Zhao
Acked-by: Jul
On 16/08/2016 06:25, Shannon Zhao wrote:
From: Shannon Zhao
According to the GIC version, construct the MADT table.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm_acpi.c | 84
1 file changed, 84 insertions(+)
diff --git a/tools/libxl/lib
On 2016/8/30 2:05, Julien Grall wrote:
> Hi Shannon,
>
> On 25/08/2016 04:05, Shannon Zhao wrote:
>>
>>
>> On 2016/8/24 20:52, Wei Liu wrote:
>>> On Tue, Aug 16, 2016 at 06:25:02PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Construct ACPI RSDP table and add a helper to calc
On 2016/8/30 3:07, Julien Grall wrote:
> Hi Shannon,
>
> On 16/08/2016 06:25, Shannon Zhao wrote:
>> From: Shannon Zhao
>>
>> While it defines the maximum size of guest ACPI tables in guest
>> memory layout, here it adds the size to set the target maxmem
>> to avoid providing less available mem
On 2016/8/30 3:00, Julien Grall wrote:
> Hi Shannon,
>
> On 16/08/2016 06:25, Shannon Zhao wrote:
>> From: Shannon Zhao
>>
>> Add macros for HVM_PARAM_CALLBACK_TYPE_PPI operation values and update
>> them in evtchn_fixup().
>>
>> Signed-off-by: Shannon Zhao
>> ---
>> xen/arch/arm/domain_build
1 - 100 of 110 matches
Mail list logo
