Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen
>>> On 11.10.16 at 17:53, wrote: > On Tue, Oct 11, 2016 at 6:08 AM, Jan Beulich wrote: > Andrew Cooper 10/10/16 6:44 PM >>> >>>On 10/10/16 01:35, Haozhong Zhang wrote: Xen hypervisor needs assistance from Dom0 Linux kernel for following tasks: 1) Reserve an area on NVDIMM devices for Xen hypervisor to place memory management data structures, i.e. frame table and M2P table. 2) Report SPA ranges of NVDIMM devices and the reserved area to Xen hypervisor. >>> >>>However, I can't see any justification for 1). Dom0 should not be >>>involved in Xen's management of its own frame table and m2p. The mfns >>>making up the pmem/pblk regions should be treated just like any other >>>MMIO regions, and be handed wholesale to dom0 by default. >> >> That precludes the use as RAM extension, and I thought earlier rounds of >> discussion had got everyone in agreement that at least for the pmem case >> we will need some control data in Xen. > > The missing piece for me is why this reservation for control data > needs to be done in the libnvdimm core? I would expect that any dax > capable file could be mapped and made available to a guest. This > includes /dev/ramX devices that are dax capable, but are external to > the libnvdimm sub-system. Despite me being the only one on the To list, I don't think the question was really meant to be directed to me. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit
>>> On 11.10.16 at 16:27, wrote:
> On 10/11/2016 09:32 AM, Ian Jackson wrote:
>> Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to
> newer commit"):
>>> On 10/11/2016 05:52 AM, Ian Jackson wrote:
Maybe we could consider these as backports to earlier releases.
However, I looked at the patch and it mostly seems to be removing null
pointer checks. I find this ... surprising.
>>> That's because routines have __nonnull attribute (which tells compiler
>>> that arguments are never NULL) and new gcc warns on non-NULL checks for
>>> these arguments.
>> *sigh* Why don't we just disable that warning ?
>
> We could but what if an old compiler doesn't support that option?
> Although it looks like -Wno-, which is what we'd use, may be OK:
>
> ostr@workbase> gcc foo.c
> ostr@workbase> gcc -Wfoo foo.c
> gcc: error: unrecognized command line option ‘-Wfoo’; did you mean ‘-Wno-’?
> ostr@workbase> gcc -Wno-foo foo.c
> ostr@workbase>
Just fyi I have run into an issue with -Wno-override-init use in Linux
4.8 on gcc 4.1.x, so what you say doesn't appear to hold for all gcc
versions we permit to be used.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit
>>> On 11.10.16 at 23:11, wrote:
> On 11/10/2016 14:32, Ian Jackson wrote:
>> Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to
>> newer commit"):
>>> BTW, another option for backporting may be removing -Werror. If we know
>>> we are not changing sources then we might consider this.
>> Perhaps we could disable warnings more selectively.
>
> This code hasn't changed in ages. Irrespective of what newer compilers
> think, it won't start working differently,
I'm afraid this is not a good position to take: Newer gcc may also be
more aggressive in terms of eliminating code with undefined behavior,
and warnings for such cases are a useful (pre)indicator.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 0/2] Xen: Fix Xen hypervisor panic during dumping timer info on huge machine.
This patchset is to fix triggering NMI watchdog during dump timer info on the huge machine with a mount of physical cpus. Detail please see change log of Patch 1. Previous discussion: https://patchwork.kernel.org/patch/9328449/ Change since V1: Add "async" param for handle_keypress() to identify whether run nonirq keyhandler in tasklet or not. This is to avoid processing debugkey sysctl asynchronously. Lan Tianyu (2): Xen/Keyhandler: Rework process of nonirq keyhandler Xen/timer: Process softirq during dumping timer info xen/common/keyhandler.c |8 +--- xen/common/sysctl.c |2 +- xen/common/timer.c |1 + xen/drivers/char/console.c |2 +- xen/include/xen/keyhandler.h |4 +++- 5 files changed, 11 insertions(+), 6 deletions(-) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 1/2] Xen/Keyhandler: Rework process of nonirq keyhandler
Keyhandler may run for a long time in serial port driver's
timer handler on the large machine with a lot of physical
cpus(e,g dump_timerq()) when serial port driver works in
the poll mode(via the exception mechanism).
If a timer handler runs a long time, it will block nmi_timer_fn()
to feed NMI watchdog and cause Xen hypervisor panic. Inserting
process_pending_softirqs() in timer handler will not help. when timer
interrupt arrives, timer subsystem calls all expired timer handlers
before programming next timer interrupt. There is no timer interrupt
arriving to trigger timer softirq during run a timer handler.
This patch is to fix the issue to make nonirq keyhandler run in
tasklet when receive debug key from serial port.
Signed-off-by: Lan Tianyu
---
xen/common/keyhandler.c |8 +---
xen/common/sysctl.c |2 +-
xen/drivers/char/console.c |2 +-
xen/include/xen/keyhandler.h |4 +++-
4 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 16de6e8..3d50041 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -75,19 +75,21 @@ static struct keyhandler {
static void keypress_action(unsigned long unused)
{
-handle_keypress(keypress_key, NULL);
+console_start_log_everything();
+key_table[keypress_key].fn(keypress_key);
+console_end_log_everything();
}
static DECLARE_TASKLET(keypress_tasklet, keypress_action, 0);
-void handle_keypress(unsigned char key, struct cpu_user_regs *regs)
+void handle_keypress(unsigned char key, struct cpu_user_regs *regs, bool async)
{
struct keyhandler *h;
if ( key >= ARRAY_SIZE(key_table) || !(h = &key_table[key])->fn )
return;
-if ( !in_irq() || h->irq_callback )
+if ( h->irq_callback || !async )
{
console_start_log_everything();
h->irq_callback ? h->irq_fn(key, regs) : h->fn(key);
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 8aea6ef..1eb7bad 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -136,7 +136,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
u_sysctl)
{
if ( copy_from_guest_offset(&c, op->u.debug_keys.keys, i, 1) )
goto out;
-handle_keypress(c, guest_cpu_user_regs());
+handle_keypress(c, guest_cpu_user_regs(), false);
}
ret = 0;
copyback = 0;
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 55ae31a..184b523 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -347,7 +347,7 @@ static void switch_serial_input(void)
static void __serial_rx(char c, struct cpu_user_regs *regs)
{
if ( xen_rx )
-return handle_keypress(c, regs);
+return handle_keypress(c, regs, true);
/* Deliver input to guest buffer, unless it is already full. */
if ( (serial_rx_prod-serial_rx_cons) != SERIAL_RX_SIZE )
diff --git a/xen/include/xen/keyhandler.h b/xen/include/xen/keyhandler.h
index 06c05c8..e9595bd 100644
--- a/xen/include/xen/keyhandler.h
+++ b/xen/include/xen/keyhandler.h
@@ -46,7 +46,9 @@ void register_irq_keyhandler(unsigned char key,
bool_t diagnostic);
/* Inject a keypress into the key-handling subsystem. */
-extern void handle_keypress(unsigned char key, struct cpu_user_regs *regs);
+extern void handle_keypress(unsigned char key,
+ struct cpu_user_regs *regs,
+ bool async);
/* Scratch space is available for use of any keyhandler. */
extern char keyhandler_scratch[1024];
--
1.7.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/2] Xen/timer: Process softirq during dumping timer info
Dumping timer info may run for a long time on the huge machine with
a lot of physical cpus. To avoid triggering NMI watchdog, add
process_pending_softirqs() in the loop of dumping timer info.
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Lan Tianyu
---
xen/common/timer.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/xen/common/timer.c b/xen/common/timer.c
index 29a60a9..ab6bca0 100644
--- a/xen/common/timer.c
+++ b/xen/common/timer.c
@@ -530,6 +530,7 @@ static void dump_timerq(unsigned char key)
{
ts = &per_cpu(timers, i);
+process_pending_softirqs();
printk("CPU%02d:\n", i);
spin_lock_irqsave(&ts->lock, flags);
for ( j = 1; j <= GET_HEAP_SIZE(ts->heap); j++ )
--
1.7.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 0/2] Xen: Fix Xen hypervisor panic during dumping timer info on huge machine.
>>> On 12.10.16 at 17:44, wrote: > This patchset is to fix triggering NMI watchdog during dump timer info > on the huge machine with a mount of physical cpus. Detail please see > change log of Patch 1. > > Previous discussion: > https://patchwork.kernel.org/patch/9328449/ > > Change since V1: > Add "async" param for handle_keypress() to identify > whether run nonirq keyhandler in tasklet or not. This is to > avoid processing debugkey sysctl asynchronously. > > > Lan Tianyu (2): > Xen/Keyhandler: Rework process of nonirq keyhandler > Xen/timer: Process softirq during dumping timer info This second patch went in already a few days ago. Also, any reason you send to the list twice (once @lists.xen.org, and another time to @lists.xenproject.org)? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 101384: all pass - PUSHED
flight 101384 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101384/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 46cd2cb6a7ba5b1fdaff1eb18a13dc399d6a7fe2
baseline version:
ovmf 4b8234d05400a852a42688fea14acc7ddeeebad4
Last test of basis 101381 2016-10-11 23:45:34 Z0 days
Testing same since 101384 2016-10-12 02:17:41 Z0 days1 attempts
People who touched revisions under test:
Jiewen Yao
Michael D Kinney
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=46cd2cb6a7ba5b1fdaff1eb18a13dc399d6a7fe2
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
46cd2cb6a7ba5b1fdaff1eb18a13dc399d6a7fe2
+ branch=ovmf
+ revision=46cd2cb6a7ba5b1fdaff1eb18a13dc399d6a7fe2
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x46cd2cb6a7ba5b1fdaff1eb18a13dc399d6a7fe2 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/x
Re: [Xen-devel] [PATCH v2 0/2] Xen: Fix Xen hypervisor panic during dumping timer info on huge machine.
On 2016年10月12日 16:09, Jan Beulich wrote: On 12.10.16 at 17:44, wrote: >> This patchset is to fix triggering NMI watchdog during dump timer info >> on the huge machine with a mount of physical cpus. Detail please see >> change log of Patch 1. >> >> Previous discussion: >> https://patchwork.kernel.org/patch/9328449/ >> >> Change since V1: >> Add "async" param for handle_keypress() to identify >> whether run nonirq keyhandler in tasklet or not. This is to >> avoid processing debugkey sysctl asynchronously. >> >> >> Lan Tianyu (2): >> Xen/Keyhandler: Rework process of nonirq keyhandler >> Xen/timer: Process softirq during dumping timer info > > This second patch went in already a few days ago. > Oh. Sorry for noise. I didn't notice that. > Also, any reason you send to the list twice (once @lists.xen.org, > and another time to @lists.xenproject.org)? Sometime I found my patches wasn't able to arrive xen-devel and so send to both xen.org and xenproject.org maillist. I will double check. > > Jan > -- Best regards Tianyu Lan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 for-4.8] libelf: fix symtab/strtab loading for 32bit domains
>>> On 10.10.16 at 18:00, wrote:
> --- a/xen/common/libelf/libelf-loader.c
> +++ b/xen/common/libelf/libelf-loader.c
> @@ -174,8 +174,8 @@ void elf_parse_bsdsyms(struct elf_binary *elf, uint64_t
> pstart)
> /* Space to store the size of the elf image */
> sz = sizeof(uint32_t);
>
> -/* Space for the elf and elf section headers */
> -sz += elf_uval(elf, elf->ehdr, e_ehsize) +
> +/* Space for the elf header and elf section headers */
> +sz += sizeof(elf_ehdr) +
>ELF_BSDSYM_SECTIONS * elf_uval(elf, elf->ehdr, e_shentsize);
This really should remain consistent: Either you allocate (and later
copy) as much as the respective input fields say, or you use sizeof()
(and then update both e_ehsize and e_shentsize accordingly in the
loaded image). In particular ...
> +/*
> + * Load the section headers.
> + *
> + * NB: this _must_ be done one by one, and taking the bitness into
> account,
> + * so that the guest can treat this as an array of type Elf{32/64}_Shdr.
> + */
> +for ( i = 0; i < ELF_BSDSYM_SECTIONS; i++ )
> +{
> +rc = elf_load_image(elf, header_base + ehdr_size + shdr_size * i,
> +
> ELF_REALPTR2PTRVAL(&header.elf_header.section[i]),
> +shdr_size, shdr_size);
... here you may copy more data than there actually is at the source
pointer (which has only sizeof(elf_shdr) bytes).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [distros-debian-squeeze test] 67865: tolerable FAIL
flight 67865 distros-debian-squeeze real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67865/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-i386-squeeze-netboot-pygrub 9 debian-di-install fail like 67795 test-amd64-i386-i386-squeeze-netboot-pygrub 9 debian-di-install fail like 67795 test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 67795 test-amd64-i386-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 67795 baseline version: flight 67795 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-squeeze-netboot-pygrubfail test-amd64-i386-amd64-squeeze-netboot-pygrub fail test-amd64-amd64-i386-squeeze-netboot-pygrub fail test-amd64-i386-i386-squeeze-netboot-pygrub fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 101386: tolerable FAIL - PUSHED
flight 101386 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101386/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass
test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass
test-amd64-i386-libvirt 12 migrate-support-checkfail never pass
test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass
test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt 14 guest-saverestorefail never pass
version targeted for testing:
libvirt 043ba4a40a4ae26cf616146d0d1c129d65b156b8
baseline version:
libvirt 6aba53468a4c6c2e86212933311e6e156ce4b38a
Last test of basis 101368 2016-10-11 04:22:05 Z1 days
Testing same since 101386 2016-10-12 04:22:05 Z0 days1 attempts
People who touched revisions under test:
Peter Krempa
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-armhf-pvopspass
build-i386-pvops pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm fail
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt pass
test-amd64-amd64-libvirt-pairpass
test-amd64-i386-libvirt-pair pass
test-armhf-armhf-libvirt-qcow2 fail
test-armhf-armhf-libvirt-raw fail
test-amd64-amd64-libvirt-vhd pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=libvirt
+ revision=043ba4a40a4ae26cf616146d0d1c129d65b156b8
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push libvirt
043ba4a40a4ae26cf616146d0d1c129d65b156b8
+ branch=libvirt
+ revision=043ba4a40a4ae26cf616146d0d1c129d6
Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit
On Tue, Oct 11, 2016 at 08:31:31PM +0100, Juergen Schinker wrote: > > > > > > We're going to tag rc2 some time this week. Thanks for help testing Xen! > > > > Wei. > > > >> J > >> > >> - On 11 Oct, 2016, at 09:37, Wei Liu wei.l...@citrix.com wrote: > >> > >> > No, you can try to work around this issue by appending --disable-rombios > >> > to your ./configure invocation. You can test major functionalities of > >> > Xen just fine without rombios. > >> > > > > > Wei. > > Now for the fun of it I tried the RELEASE-4.7 > > and it turns out it has no support for xz-decompression > That's probably because you don't have libzx development package installed when building Xen. > so it can't decompress the kernel via pygrub > > what ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/Intel: virtualize support for cpuid faulting
On 12/10/16 05:07, Kyle Huey wrote:
> rr (http://rr-project.org/), a Linux userspace record-and-replay reverse-
> execution debugger, would like to trap and emulate the CPUID instruction.
> This would allow us to a) mask away certain hardware features that rr does
> not support (e.g. RDRAND) and b) enable trace portability across machines
> by providing constant results. Patches for support in the Linux kernel are in
> flight, and we'd like to be able to use this feature on virtualized Linux
> instances as well.
>
> On HVM guests, the cpuid triggers a vm exit, so we can check the emulated
> faulting state in vmx_do_cpuid and inject a GP(0) if CPL > 0. Notably no
> hardware support for faulting on cpuid is necessary to emulate support with an
> HVM guest.
>
> On PV guests, hardware support is required so that userspace cpuid will trap
> to xen. Xen already enables cpuid faulting on supported CPUs for pv guests
> (that
> aren't the control domain, see the comment in intel_ctxt_switch_levelling).
> Every guest cpuid will trap via a GP(0) to emulate_privileged_op (via
> do_general_protection). Once there we can simply decline to emulate the cpuid,
> if it comes from the guest's userspace, and instead pass the GP(0) along to
> the
> guest kernel, thus emulating the cpuid faulting behavior.
>
> Signed-off-by: Kyle Huey
> ---
> xen/arch/x86/hvm/vmx/vmx.c | 21 ++---
> xen/arch/x86/traps.c | 31 ++-
> xen/include/asm-x86/domain.h | 3 +++
> 3 files changed, 51 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 50cbfed..be45f74 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2434,6 +2434,14 @@ static int vmx_do_cpuid(struct cpu_user_regs *regs)
> {
> unsigned int eax, ebx, ecx, edx;
> unsigned int leaf, subleaf;
> +struct segment_register sreg;
> +struct vcpu *v = current;
> +
> +hvm_get_segment_register(v, x86_seg_ss, &sreg);
> +if ( v->arch.cpuid_fault && sreg.attr.fields.dpl > 0 ) {
Newline for brace. This file is sadly inconsistent with its style, but
we insist that all new code is correct.
> +hvm_inject_hw_exception(TRAP_gp_fault, 0);
> +return 0;
> +}
>
> eax = regs->eax;
> ebx = regs->ebx;
> @@ -2701,9 +2709,11 @@ static int vmx_msr_read_intercept(unsigned int msr,
> uint64_t *msr_content)
> break;
>
> case MSR_INTEL_PLATFORM_INFO:
> -if ( rdmsr_safe(MSR_INTEL_PLATFORM_INFO, *msr_content) )
> -goto gp_fault;
> -*msr_content = 0;
> +*msr_content = MSR_PLATFORM_INFO_CPUID_FAULTING;
> +break;
> +
> +case MSR_INTEL_MISC_FEATURES_ENABLES:
> +*msr_content = current->arch.cpuid_fault ?
> MSR_MISC_FEATURES_CPUID_FAULTING : 0;
> break;
>
> default:
> @@ -2931,6 +2941,11 @@ static int vmx_msr_write_intercept(unsigned int msr,
> uint64_t msr_content)
> rdmsr_safe(MSR_INTEL_PLATFORM_INFO, msr_content) )
> goto gp_fault;
> break;
> +case MSR_INTEL_MISC_FEATURES_ENABLES:
> +if ( msr_content & ~MSR_MISC_FEATURES_CPUID_FAULTING )
> +goto gp_fault;
> +v->arch.cpuid_fault = msr_content;
= !!msr_content;
Some compilers complain when assigning a non-binary value into a bool.
> +break;
>
> default:
> if ( passive_domain_do_wrmsr(msr, msr_content) )
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index 24d173f..2783822 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2945,6 +2945,16 @@ static int emulate_privileged_op(struct cpu_user_regs
> *regs)
> rdmsr_safe(MSR_INTEL_PLATFORM_INFO, msr_content) )
> goto fail;
> break;
> +case MSR_INTEL_MISC_FEATURES_ENABLES:
> +if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
> + rdmsr_safe(MSR_INTEL_MISC_FEATURES_ENABLES, val) ||
> + msr_content & ~MSR_MISC_FEATURES_CPUID_FAULTING )
> +goto fail;
> +if ( msr_content == MSR_MISC_FEATURES_CPUID_FAULTING &&
> + (!cpu_has_cpuid_faulting || is_control_domain(v->domain)) )
> +goto fail;
> +v->arch.cpuid_fault = msr_content;
!!msr_content again.
> +break;
>
> case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
> case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(3):
> @@ -3079,7 +3089,22 @@ static int emulate_privileged_op(struct cpu_user_regs
> *regs)
> if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
> rdmsr_safe(MSR_INTEL_PLATFORM_INFO, val) )
> goto fail;
> -regs->eax = regs->edx = 0;
> +/*
> + * See the comment in intel_ctxt_switch_levelling about cpuid
> + * faulting in the control domain.
> + */
All of these routi
Re: [Xen-devel] [PATCH v2 0/2] Xen: Fix Xen hypervisor panic during dumping timer info on huge machine.
On Wed, Oct 12, 2016 at 04:20:02PM +0800, Lan Tianyu wrote: > On 2016年10月12日 16:09, Jan Beulich wrote: > On 12.10.16 at 17:44, wrote: > >> This patchset is to fix triggering NMI watchdog during dump timer info > >> on the huge machine with a mount of physical cpus. Detail please see > >> change log of Patch 1. > >> > >> Previous discussion: > >> https://patchwork.kernel.org/patch/9328449/ > >> > >> Change since V1: > >> Add "async" param for handle_keypress() to identify > >> whether run nonirq keyhandler in tasklet or not. This is to > >> avoid processing debugkey sysctl asynchronously. > >> > >> > >> Lan Tianyu (2): > >> Xen/Keyhandler: Rework process of nonirq keyhandler > >> Xen/timer: Process softirq during dumping timer info > > > > This second patch went in already a few days ago. > > > > Oh. Sorry for noise. I didn't notice that. > It is always good practice to rebase your patch series on top of staging, FWIW. > > Also, any reason you send to the list twice (once @lists.xen.org, > > and another time to @lists.xenproject.org)? > > Sometime I found my patches wasn't able to arrive xen-devel and so > send to both xen.org and xenproject.org maillist. I will double check. > Both addresses should work. There are glitches from time to time though. So do report to us if this happens again. Wei. > > > > Jan > > > > > -- > Best regards > Tianyu Lan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen
On 10/11/16 13:17 -0700, Dan Williams wrote: On Tue, Oct 11, 2016 at 12:48 PM, Konrad Rzeszutek Wilk wrote: On Tue, Oct 11, 2016 at 12:28:56PM -0700, Dan Williams wrote: On Tue, Oct 11, 2016 at 11:33 AM, Konrad Rzeszutek Wilk wrote: > On Tue, Oct 11, 2016 at 10:51:19AM -0700, Dan Williams wrote: [..] >> Right, but why does the libnvdimm core need to know about this >> specific Xen reservation? For example, if Xen wants some in-kernel > > Let me turn this around - why does the libnvdimm core need to know about > Linux specific parts? Shouldn't this be OS agnostic, so that FreeBSD > for example can also poke a hole in this and fill it with its > OS-management meta-data? Specifically the core needs to know so that it can answer the Linux specific question of whether the pfn returned by ->direct_access() has a corresponding struct page or not. It's tied to the lifetime of the device and the usage of the reservation needs to be coordinated against the references of those pages. If FreeBSD decides it needs to reserve "struct page" capacity at the start of the device, I would hope that it reuses the same on-device info block that Linux is using and not create a new "FreeBSD-mode" device type. The issue here (as I understand, I may be missing something new) is that the size of this special namespace may be different. That is the 'struct page' on FreeBSD could be 256 bytes while on Linux it is 64 bytes (numbers pulled out of the sky). Hence one would have to expand or such to re-use this. Sure, but we could support that today. If FreeBSD lays down the info block it is free to make a bigger reservation and Linux would be happy to use a smaller subset. If we, as an industry, want this "struct page" reservation to be common we can take it to a standards body to make as a cross-OS guarantee... but I think this is separate from the Xen reservation. To be honest I do not yet understand what metadata Xen wants to store in the device, but it seems the producer and consumer of that metadata is Xen itself and not the wider Linux kernel as is the case with struct page. Can you fill me in on what problem Xen solves with this Exactly! reservation? The same as Linux - its variant of 'struct page'. Which I think is smaller than the Linux one, but perhaps it is not? If the hypervisor needs to know where it can store some metadata, can that be satisfied with userspace tooling in Dom0? Something like, "/dev/pmem0p1 == Xen metadata" and "/dev/pmem0p2 == DAX filesystem with files to hand to guests". So my question is not about the rationale for having metadata, it's why does the Linux kernel need to know about the Xen reservation? As far as I can see it is independent / opaque to the kernel. Thank everyone for all these comments! How about doing the reservation in the following way: 1. Create partition(s) on /dev/pmemX and make sure space besides the partition table and potential padding before the first partition is large enough to hold Xen's management structures and a super block introduced in step 2. The space besides the partition table, padding and the super block will be used as the reserved area. 2. Write a super block before above reserved area. The super block records the base address and the size of the reserved area. It also contains a signature and a checksum to identify itself. The layout is shown as the following diagram. +---+---+---+--+--+ | whatever used | Partition | Super | Reserved | /dev/pmem0p1 | | by kernel| Table | Block | for Xen | | +---+---+---+--+--+ \_ ___/ V /dev/pmem0 Above two steps can be done via a userspace program and do not need Xen hypervisor running. The partitions on the device can be used regardless of the existence of Xen hypervisor. 3. When Xen is running, implement a function in Dom0 Linux xen driver (drivers/xen/) to response to udevd events that notify the detection of the pmem regions. This function searches on the pmem region for the super block created in step 2. If one is found, it will know this pmem region has been prepared for Xen usage. Then it gets the base address and size of the reserved area (from super block) and the entire address ranges of the pmem region (from pmem driver), and reports them to Xen hypervisor. The implementation of this step can be completely included in the kernel Xen driver. (It may also be implemented as a udevd service in userspace, if it's not considered as unsafe) Thanks, Haozhong ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Proposed plan and URL name for new VM to download xen tarballs (ftp.xenproject.org)
Ian Jackson writes ("Re: Proposed plan and URL name for new VM to download xen
tarballs (ftp.xenproject.org)"):
> Sure, I don't have an opinion. I have changed this, so it's now
> under:
> https://downloads.xenproject.org/release/xen/
No-one has objected, so we are now committing to this. The new URLs
will be primary for the forthcoming RC (Wei will send an announcement
when it's ready).
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-coverity test] 101393: regressions - ALL FAIL
flight 101393 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101393/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
coverity-amd646 coverity-upload fail REGR. vs. 101279
version targeted for testing:
xen 71b8b46111219a2f83f4f9ae06ac5409744ea86e
baseline version:
xen b7dd797c7fe4cd849018f78f6c7b9eb3d33b89d8
Last test of basis 101279 2016-10-05 09:19:19 Z7 days
Failing since101343 2016-10-09 09:18:41 Z3 days2 attempts
Testing same since 101393 2016-10-12 09:19:33 Z0 days1 attempts
People who touched revisions under test:
George Dunlap
Igor Druzhinin
Jan Beulich
Konrad Rzeszutek Wilk
Lan Tianyu
Razvan Cojocaru
Stefano Stabellini
Wei Liu
jobs:
coverity-amd64 fail
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
commit 71b8b46111219a2f83f4f9ae06ac5409744ea86e
Author: George Dunlap
Date: Fri Sep 30 15:42:56 2016 +0100
xen/trace: Fix trace metadata page count calculation (revert fbf96e6)
Changeset fbf96e6, "xentrace: correct formula to calculate
t_info_pages", broke the trace metadata page count calculation, by
mistaking t_info_first_offset as denominated in bytes, when in fact it
is denominated in words (uint32_t).
Effectively revert that change, and put a comment there to reduce the
chance that someone will make that mistake in the future.
Reviewed-by: Igor Druzhinin
Tested-by: Igor Druzhinin
Signed-off-by: George Dunlap
commit 68dc7185cbffab34211c77339874f2ea517990fd
Author: Konrad Rzeszutek Wilk
Date: Mon Oct 10 11:10:56 2016 -0700
Makefile: fix (again) EFI part of "symbols: Generate an xen-sym.map
This is a follow-up to commit d14fffcc6a7c054db9e337026a3c850152244ac4
"fix EFI part of "symbols: Generate an xen-sym.map" which fixed most of
the issues.
However we still have an issue - The file being installed (xen.efi.map)
does not exist in an ARM64 build (the xen.efi is linked againts xen).
The fix can be done two ways:
a) See if xen.efi.map exists and then copy it
b) Or link xen.efi.map to xen-syms.map (similar to how xen.efi is linked
against xen).
The patch chooses the former.
Reported-by: Jan Beulich
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Stefano Stabellini
Acked-by: Stefano Stabellini
commit 0a9d8a57e1f9024459e613e831905d28ef72051a
Author: Wei Liu
Date: Mon Oct 10 10:40:30 2016 +0100
Kconfig: use tab instead of space
Previously in d6be2cfc ("xen: make clear gcov support limitation in
Kconfig") and db6c2264 ("xen: add a gcov Kconfig option"), space was
used to indent Kconfig text. Change that to use tab instead.
No functional change.
Signed-off-by: Wei Liu
Reviewed-by: Jan Beulich
commit 78ff18c905318a9b1e5dd32662986f03b10a4e56
Author: Jan Beulich
Date: Mon Oct 10 12:16:49 2016 +0200
x86: defer not-present segment checks
Following on from commits 5602e74c60 ("x86emul: correct loading of
%ss") and bdb860d01c ("x86/HVM: correct segment register loading during
task switch") the point of the non-.present checks needs to be refined:
#NP (and its #SS companion), other than suggested by the various
instruction pages in Intel's SDM, gets checked for only after all type
and permission checks. The only checks getting done even later are the
long mode specific ones for system descriptors (which we don't support
yet) and 64-bit code segments (i.e. anything touching other than the
attribute byte).
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
commit 62c12fa3b15caf54cb8436458a86a1acf42170fd
Author: Jan Beulich
Date: Mon Oct 10 12:16:06 2016 +0200
x86: replace redundant MTRR MSR definitions
We really should have only one set of #define-s for them.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
commit 84c1e7d8017c773c41d6e8b79384f37a67be1479
Author: Razvan Cojocaru
Date: Fri Oct 7 11:35:58 2016 +0200
x86/hvm: remove emulation context setting from hvmemul_cmpxchg()
Re: [Xen-devel] Proposed plan and URL name for new VM to download xen tarballs (ftp.xenproject.org)
> On 12 Oct 2016, at 11:38, Ian Jackson wrote:
>
> Ian Jackson writes ("Re: Proposed plan and URL name for new VM to download
> xen tarballs (ftp.xenproject.org)"):
>> Sure, I don't have an opinion. I have changed this, so it's now
>> under:
>> https://downloads.xenproject.org/release/xen/
>
> No-one has objected, so we are now committing to this. The new URLs
> will be primary for the forthcoming RC (Wei will send an announcement
> when it's ready).
>
> Ian.
Wei, I will update the Test Day wiki and blog post
Lars
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [ANNOUNCEMENT] Xen 4.8 RC2
Hi all Xen 4.8 RC2 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.8.0-rc2 For you convenience, please find tarball and signature at: https://downloads.xenproject.org/release/xen/4.8.0-rc2/ Please send bug reports and test reports to xen-de...@lists.xenproject.org. When sending reports, please CC relevant maintainers and me (wei.l...@citrix.com). Thanks Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 15/15] xen: Rename xen_be_frontend_changed
On 09/10/2016 21:50, Emil Condrea wrote:
> On Tue, Oct 4, 2016 at 11:06 AM, Paolo Bonzini wrote:
>>
>>
>> On 04/10/2016 08:43, Emil Condrea wrote:
>>> xen_be_frontend_changed -> xen_fe_frontend_changed
>>
>> This is not correct. The front-end is implemented in the guest domain,
>> while the back-end is implemented in the dom0 or stubdom.
>>
>
> You are right, thanks for the feedback! I will drop this patch
> together with the hunk
> from 04/15 patch which moves this function to xen_frontend.c
Actually all of your new xen_frontend.c seems to be reading frontend
information from XenStore, which is typically something that the backend
does. So I suggest dropping the patch altogether.
Thanks,
Paolo
>> This function processes *in the backed* a notification that the frontend
>> state changed, hence the name should be xen_be_frontend_changed.
>>
>> Paolo
>>
>>> Signed-off-by: Emil Condrea
>>> ---
>>> hw/xen/xen_backend.c | 2 +-
>>> hw/xen/xen_frontend.c | 4 ++--
>>> include/hw/xen/xen_frontend.h | 2 +-
>>> 3 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
>>> index 30d3aaa..b79e83e 100644
>>> --- a/hw/xen/xen_backend.c
>>> +++ b/hw/xen/xen_backend.c
>>> @@ -213,7 +213,7 @@ static int xen_be_try_setup(struct XenDevice *xendev)
>>> xen_be_set_state(xendev, XenbusStateInitialising);
>>>
>>> xen_be_backend_changed(xendev, NULL);
>>> -xen_be_frontend_changed(xendev, NULL);
>>> +xen_fe_frontend_changed(xendev, NULL);
>>> return 0;
>>> }
>>>
>>> diff --git a/hw/xen/xen_frontend.c b/hw/xen/xen_frontend.c
>>> index 1407f5f..761688b 100644
>>> --- a/hw/xen/xen_frontend.c
>>> +++ b/hw/xen/xen_frontend.c
>>> @@ -39,7 +39,7 @@ int xenstore_read_fe_uint64(struct XenDevice *xendev,
>>> const char *node,
>>> return xenstore_read_uint64(xendev->fe, node, uval);
>>> }
>>>
>>> -void xen_be_frontend_changed(struct XenDevice *xendev, const char *node)
>>> +void xen_fe_frontend_changed(struct XenDevice *xendev, const char *node)
>>> {
>>> int fe_state;
>>>
>>> @@ -85,6 +85,6 @@ void xenstore_update_fe(char *watch, struct XenDevice
>>> *xendev)
>>> }
>>> node = watch + len + 1;
>>>
>>> -xen_be_frontend_changed(xendev, node);
>>> +xen_fe_frontend_changed(xendev, node);
>>> xen_be_check_state(xendev);
>>> }
>>> diff --git a/include/hw/xen/xen_frontend.h b/include/hw/xen/xen_frontend.h
>>> index bb0bc23..2a5f03f 100644
>>> --- a/include/hw/xen/xen_frontend.h
>>> +++ b/include/hw/xen/xen_frontend.h
>>> @@ -9,6 +9,6 @@ int xenstore_read_fe_uint64(struct XenDevice *xendev, const
>>> char *node,
>>> uint64_t *uval);
>>> void xenstore_update_fe(char *watch, struct XenDevice *xendev);
>>>
>>> -void xen_be_frontend_changed(struct XenDevice *xendev, const char *node);
>>> +void xen_fe_frontend_changed(struct XenDevice *xendev, const char *node);
>>>
>>> #endif /* QEMU_HW_XEN_FRONTEND_H */
>>>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit [and 1 more messages]
Ian Jackson writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer
commit"):
> That was eventually done. I'm not sure exactly when the change was
> made. Does gcc -Wno-foo work properly on all the gcc's we care about ?
Jan Beulich writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer
commit"):
> Just fyi I have run into an issue with -Wno-override-init use in Linux
> 4.8 on gcc 4.1.x, so what you say doesn't appear to hold for all gcc
> versions we permit to be used.
Well, that answers my question above.
I think the right approach is to:
* Test -Wno-this-is-not-a-warning-option. If gcc accepts it,
add -Wno-something to disable the nonnull check·
* Review the misleading indentations and if there are only a few, fix
them in a downstream patch. Or, if there are many, decide to
tolerate them.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 101383: tolerable FAIL - PUSHED
flight 101383 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/101383/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101372 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101372 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101372 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101372 test-amd64-amd64-xl-rtds 9 debian-install fail like 101372 Tests which did not succeed, but are not blocking: test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a build-amd64-rumprun 5 rumprun-buildfail never pass build-i386-rumprun5 rumprun-buildfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 71b8b46111219a2f83f4f9ae06ac5409744ea86e baseline version: xen 68dc7185cbffab34211c77339874f2ea517990fd Last test of basis 101372 2016-10-11 09:51:27 Z1 days Testing same since 101379 2016-10-11 19:14:39 Z0 days2 attempts People who touched revisions under test: George Dunlap Igor Druzhinin jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern
Re: [Xen-devel] [PATCH v2 17/30] xen/x86: setup PVHv2 Dom0 CPUs
On Thu, Oct 06, 2016 at 09:20:07AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:57, wrote:
> > The logic used to setup the CPUID leaves is extremely simplistic (and
> > probably wrong for hardware different than mine). I'm not sure what's the
> > best way to deal with this, the code that currently sets the CPUID leaves
> > for HVM guests lives in libxc, maybe moving it xen/common would be better?
>
> Yeah, a pre-populated array of leaves certainly won't do.
This is what current HVM guests use, and TBH, I would prefer to don't
diverge from HVM. Would it make sense to leave this as-is, until all this
cpuid stuff is fixed? (IIRC Andrew is still working on this).
> > +rc = arch_set_info_hvm_guest(v, &cpu_ctx);
> > +if ( rc )
> > +{
> > +printk("Unable to setup Dom0 BSP context: %d\n", rc);
> > +return rc;
> > +}
> > +clear_bit(_VPF_down, &v->pause_flags);
>
> Even if it may not matter right away, I think you want to clear this
> flag later, after having completed all setup.
Right, I've now moved the clear_bit to the end of construct_dom0_hvm.
> > +for ( i = 0; i < ARRAY_SIZE(cpuid_leaves); i++ )
> > +{
> > +d->arch.cpuids[i].input[0] = cpuid_leaves[i].index;
> > +d->arch.cpuids[i].input[1] = cpuid_leaves[i].count;
> > +if ( d->arch.cpuids[i].input[1] == XEN_CPUID_INPUT_UNUSED )
> > +cpuid(d->arch.cpuids[i].input[0], &d->arch.cpuids[i].eax,
> > + &d->arch.cpuids[i].ebx, &d->arch.cpuids[i].ecx,
> > + &d->arch.cpuids[i].edx);
> > +else
> > +cpuid_count(d->arch.cpuids[i].input[0],
> > d->arch.cpuids[i].input[1],
> > +&d->arch.cpuids[i].eax, &d->arch.cpuids[i].ebx,
> > +&d->arch.cpuids[i].ecx, &d->arch.cpuids[i].edx);
>
> Why this if/else? It is always fine to use cpuid_count().
Done, now it's cpuid_count.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Proposed plan and URL name for new VM to download xen tarballs (ftp.xenproject.org)
On 12/10/16 21:38, Ian Jackson wrote:
> Ian Jackson writes ("Re: Proposed plan and URL name for new VM to download
> xen tarballs (ftp.xenproject.org)"):
>> Sure, I don't have an opinion. I have changed this, so it's now
>> under:
>> https://downloads.xenproject.org/release/xen/
>
> No-one has objected, so we are now committing to this. The new URLs
> will be primary for the forthcoming RC (Wei will send an announcement
> when it's ready).
I missed this previously in the rest of the list happenings.
I'm actually glad this is happening. Having predictable naming / pathing
of the xen tarballs is fantastic.
I lothe going via the web site to download the file.html which ends up
being the filename on the system. Would be much nicer to have a direct
download link automatically generated that works.
As such, +1 from me :)
--
Steven Haigh
Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 0/2] Xen: Fix Xen hypervisor panic during dumping timer info on huge machine.
Wei Liu writes ("Re: [PATCH v2 0/2] Xen: Fix Xen hypervisor panic during
dumping timer info on huge machine."):
> On Wed, Oct 12, 2016 at 04:20:02PM +0800, Lan Tianyu wrote:
> > On 2016年10月12日 16:09, Jan Beulich wrote:
> > > Also, any reason you send to the list twice (once @lists.xen.org,
> > > and another time to @lists.xenproject.org)?
> >
> > Sometime I found my patches wasn't able to arrive xen-devel and so
> > send to both xen.org and xenproject.org maillist. I will double check.
>
> Both addresses should work. There are glitches from time to time though.
> So do report to us if this happens again.
I don't think either address is likely to work differently or
separately to the other. So please just send to one, and if it
doesn't work, please report it and we will try to fix it.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] acpi: don't register acpi_pad driver if running as xen dom0
When running as Xen dom0 a special processor_aggregator driver is
needed. Don't register the standard driver in this case.
Without that check an error message:
"Error: Driver 'processor_aggregator' is already registered,
aborting..."
will be displayed.
Signed-off-by: Juergen Gross
---
drivers/acpi/acpi_pad.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index 8ea8211..1c3be12 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#define ACPI_PROCESSOR_AGGREGATOR_CLASS"acpi_pad"
#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor Aggregator"
@@ -477,6 +478,10 @@ static struct acpi_driver acpi_pad_driver = {
static int __init acpi_pad_init(void)
{
+ /* Xen acpi pad is responsible when running as Xen Dom0. */
+ if (xen_initial_domain())
+ return -ENODEV;
+
power_saving_mwait_init();
if (power_saving_mwait_eax == 0)
return -EINVAL;
--
2.6.6
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 17/30] xen/x86: setup PVHv2 Dom0 CPUs
On 12/10/16 12:06, Roger Pau Monne wrote: > On Thu, Oct 06, 2016 at 09:20:07AM -0600, Jan Beulich wrote: > On 27.09.16 at 17:57, wrote: >>> The logic used to setup the CPUID leaves is extremely simplistic (and >>> probably wrong for hardware different than mine). I'm not sure what's the >>> best way to deal with this, the code that currently sets the CPUID leaves >>> for HVM guests lives in libxc, maybe moving it xen/common would be better? >> Yeah, a pre-populated array of leaves certainly won't do. > This is what current HVM guests use, and TBH, I would prefer to don't > diverge from HVM. Would it make sense to leave this as-is, until all this > cpuid stuff is fixed? (IIRC Andrew is still working on this). My CPUID work will remove the need for any of this, (and indeed, is a prerequisite for an HVM Control domain to build further HVM domains). At boot, where we currently calculate the featuresets, we will also calculate maximum full policies. domain_create() will clone the appropriate default policy (pv or hvm) as a starting point. A regular domU will have the toolstack optionally reduce the policy via the domctl interface, but in the absence of any changes, the domain will get the maximum supported featureset available on the hardware. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen
>>> On 12.10.16 at 12:33, wrote: > The layout is shown as the following diagram. > > +---+---+---+--+--+ > | whatever used | Partition | Super | Reserved | /dev/pmem0p1 | > | by kernel| Table | Block | for Xen | | > +---+---+---+--+--+ > \_ ___/ > V >/dev/pmem0 I have to admit that I dislike this, for not being OS-agnostic. Neither should there be any Xen-specific region, nor should the "whatever used by kernel" one be restricted to just Linux. What I could see is an OS-reserved area ahead of the partition table, the exact usage of which depends on which OS is currently running (and in the Xen case this might be both Xen _and_ the Dom0 kernel, arbitrated by a tbd protocol). After all, when running under Xen, the Dom0 may not have a need for as much control data as it has when running on bare hardware, for it controlling less (if any) of the actual memory ranges when Xen is present. The assumption of course is that the reserved area holds no persistent data. If that assumption didn't hold, you'd have to have per-OS reserved areas anyway (as many of them as there might be OSes [planned to get] installed on a particular system). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 06/13] efi: create new early memory allocator
>>> On 11.10.16 at 15:39, wrote:
> Hello Jan,
>
> On 06/10/16 13:21, Jan Beulich wrote:
> On 05.10.16 at 20:30, wrote:
>>> On 30/09/2016 02:46, Jan Beulich wrote:
>>> On 29.09.16 at 23:42, wrote:
> +#else
> +static void __init free_ebmalloc_unused_mem(void)
> +{
> +}
> +#endif
Did you build test this for ARM? The function ought to be unused,
as ...
> @@ -1251,6 +1301,8 @@ void __init efi_init_memory(void)
> } *extra, *extra_head = NULL;
> #endif
>
> +free_ebmalloc_unused_mem();
... the whole function here doesn't get built on ARM.
Julien - we're still awaiting your input on general aspects here.
>>>
>>> efi_init_memory would need to be called during Xen boot on ARM. I am not
>>> sure where as I we don't yet have runtime support on ARM.
>>>
>>> Other than that, the patch looks good to me.
>>
>> But that wasn't the question. My goal is to have as little code
>> inside #ifndef CONFIG_ARM as possible, and hence I'd like to have
>> as much of this new code as possible outside of such conditionals.
>> So the question really is whether that alternative approach would
>> be fine with you, or what problems you might see.
>
> I am not sure to get it. The current approach looks good to me, however,
> the implementation should not be exposed to ARM until all the TODOs
> mentioned by Daniel are fixed.
Which is precisely the opposite of what I'm aiming at. Once again:
Don't you think it is desirable to keep the #ifndef CONFIG_ARM
instances to cover as little code as possible? Not all of the named
TODOs really need to be addressed in order to compile most of
what comprises this new allocator; in fact none of them really
needs addressing:
- if the size estimation turns out to low once ARM starts actually
using this, let's just bump it (perhaps by making it a per-arch
constant),
- if the section chosen needs to be different (which it really
shouldn't be), let's simply adjust it,
- as we've already figured there's no need for the stub
free_ebmalloc_unused_mem() right now anyway.
And then (as another alternative) we have the option of ARM
simply defining EBMALLOC_SIZE to zero for the time being. That
would eliminate the need to actually call free_ebmalloc_unused_mem()
and turn the other two items into non-issues.
> I would be happy to review any patches addressing the TODOs.
This, I'm sorry, gets me to raise another question: When is this
finally going to happen? Shared EFI code was introduced for 4.5,
and we're now looking to release 4.8 still with runtime support
unimplemented on ARM. How much longer is this going to take?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [linux-3.18 test] 101389: regressions - FAIL
flight 101389 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/101389/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-multivcpu 14 guest-saverestore fail REGR. vs. 101000 test-amd64-i386-pair 9 xen-boot/src_hostfail REGR. vs. 101000 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101000 test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail REGR. vs. 101000 test-amd64-i386-freebsd10-i386 6 xen-boot fail REGR. vs. 101000 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail REGR. vs. 101000 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail REGR. vs. 101000 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101000 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 101000 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 101000 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101000 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101000 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101000 Tests which did not succeed, but are not blocking: test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a build-i386-rumprun5 rumprun-buildfail never pass build-amd64-rumprun 5 rumprun-buildfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass version targeted for testing: linux3cab355c2ff3a781b6ebe9d1a25bd4ebc1207430 baseline version: linuxa8e202812b52b88e2a33d52687b3b0260706231a Last test of basis 101000 2016-09-18 07:47:20 Z 24 days Testing same since 101389 2016-10-12 06:50:56 Z0 days1 attempts People who touched revisions under test: Acked-by: Arnd Bergmann Akshay Bhat Al Viro Alan Stern Andrew Morton Anson Huang Ard Biesheuvel Ashish Samant Balbir Singh Benjamin Herrenschmidt Boris Brezillon Catalin Marinas Chris Mason Christoffer Dall Daniele Pal
[Xen-devel] Outreachy golang bindings planning
Hey Ronald,
My ultimate vision for the libxl golang project is to have the following:
- Golang bindings for all core libxl functionality
- A test program which exersises as much of that functionality as is
reasonable
The C libxl library has two components: parts that are written by hand
(such as libxl.h and libxl_*.c), and parts that are generated
programmatically by the IDL compiler (such as _libxl_types.h and
_libxl_types.c). I think the end goal should be to extend the IDL to
generate at least the Golang types, and probably a lot of the "helper"
methods as well (such as ${TYPE}.String() or ${TYPE}.FromString()).
But before diving into the I think it makes sense to first implement a
core set of functionality by hand, to see what the shape of the library
looks like, then implement the type-generation part of the IDL. Other
things we might do with the IDL, such as generation of utility methods,
we can add in at later points as well.
At the bottom of this mail, I've got all the libxl functions from
libxl.h sorted into what seems to me a useful order to start working on
things.
I list here the "headers". This is a *lot* of functionality; I very
greatly doubt that it will be possible to get all of it implemented and
tested during the internship. I'd much rather have a decent core set of
functionality with a really good testing than attempt to get all the
functions "implemented" in a way which nobody knows if it works.
If we can get the basic IDL working, and stuff implemented and
well-tested through "Secondary host operations", I think the internship
will have been a solid success. If we get through "Devices: PCI", I
think it will have been a wild success. :-)
Thanks,
-George
---
(Headers only)
# Libxl and host-related functionality
# Primary domain operations: Create / shutdown / destroy
(This will probably take a fairly large chunk of time to, as we run
across most of the design / architectural decisions with the bindings.
And at the end you'll only be able to start VMs with no devices!)
# Devices: Disk
# Devices: Network
(At this point, we have the core VM functionality.)
# Secondary domain operations: manipulate, suspend / resume / reset
# Secondary host operations
# More domain operations
# Advanced host config
# Devices: USB
# Devices: PCI
# Devices: VFB
# Devices: Channels
# Advanced domain config
# Devices: VKB
# Devices: VTPM
# PSR
# Flask
# Domain operations: Exec helper functions
# Miscellanious behavior
---
(Headers and functions)
# Libxl and host-related functionality
const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx);
int libxl_get_max_cpus(libxl_ctx *ctx);
int libxl_get_online_cpus(libxl_ctx *ctx);
int libxl_get_max_nodes(libxl_ctx *ctx);
int libxl_get_free_memory(libxl_ctx *ctx, uint64_t *memkb);
int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo);
# Primary domain operations: Create (with disk / network), shutdown /
destroy
int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
uint32_t *domid,
const libxl_asyncop_how *ao_how,
const libxl_asyncprogress_how *aop_console_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid);
int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_domain_info(libxl_ctx*, libxl_dominfo *info_r,
uint32_t domid);
libxl_dominfo * libxl_list_domain(libxl_ctx*, int *nb_domain_out);
libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
int *nb_vcpu, int *nr_cpus_out);
int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num,
libxl_console_type type, char **path);
int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm,
char **path);
# Devices: Disk
int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
libxl_device_disk *disk,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
libxl_device_disk *disk,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
libxl_device_disk *disk,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t
domid, int *num);
int
Re: [Xen-devel] [PATCH v2 15/30] xen/x86: populate PVHv2 Dom0 physical memory map
>>> On 11.10.16 at 16:01, wrote:
> On Tue, Oct 04, 2016 at 05:16:09AM -0600, Jan Beulich wrote:
>> >>> On 04.10.16 at 11:12, wrote:
>> > On Fri, Sep 30, 2016 at 09:52:56AM -0600, Jan Beulich wrote:
>> >> >>> On 27.09.16 at 17:57, wrote:
>> >> > @@ -336,7 +343,8 @@ static unsigned long __init compute_dom0_nr_pages(
>> >> > avail -= dom0_paging_pages(d, nr_pages);
>> >> > }
>> >> >
>> >> > -if ( (parms->p2m_base == UNSET_ADDR) && (dom0_nrpages <= 0) &&
>> >> > +if ( is_pv_domain(d) &&
>> >> > + (parms->p2m_base == UNSET_ADDR) && (dom0_nrpages <= 0) &&
>> >>
>> >> Perhaps better to simply force parms->p2m_base to UNSET_ADDR
>> >> earlier on?
>> >
>> > p2m_base is already unconditionally set to UNSET_ADDR for PVHv2 domains,
>> > hence the added is_pv_domain check in order to make sure that PVHv2 guests
>> > don't get into that branch, which AFAICT is only relevant to PV guests.
>>
>> This reads contradictory: If it's set to UNSET_ADDR, why the extra
>> check?
>
> On PVHv2 p2m_base == UNSET_ADDR already, so the extra check is to make sure
> PVHv2 guests don't execute the code inside of the if condition, which is
> for classic PV guests (note that the check is not against != UNSET_ADDR). Or
> maybe I'm missing something?
No, I have to apologize - I read things the wrong way round.
Thanks for bearing with me.
>> >> > @@ -1657,15 +1679,238 @@ out:
>> >> > return rc;
>> >> > }
>> >> >
>> >> > +/* Populate an HVM memory range using the biggest possible order. */
>> >> > +static void __init hvm_populate_memory_range(struct domain *d,
>> >> > uint64_t start,
>> >> > + uint64_t size)
>> >> > +{
>> >> > +static unsigned int __initdata memflags =
>> >> > MEMF_no_dma|MEMF_exact_node;
>> >> > +unsigned int order;
>> >> > +struct page_info *page;
>> >> > +int rc;
>> >> > +
>> >> > +ASSERT(IS_ALIGNED(size, PAGE_SIZE) && IS_ALIGNED(start,
>> >> > PAGE_SIZE));
>> >> > +
>> >> > +order = MAX_ORDER;
>> >> > +while ( size != 0 )
>> >> > +{
>> >> > +order = min(get_order_from_bytes_floor(size), order);
>> >> > +page = alloc_domheap_pages(d, order, memflags);
>> >> > +if ( page == NULL )
>> >> > +{
>> >> > +if ( order == 0 && memflags )
>> >> > +{
>> >> > +/* Try again without any memflags. */
>> >> > +memflags = 0;
>> >> > +order = MAX_ORDER;
>> >> > +continue;
>> >> > +}
>> >> > +if ( order == 0 )
>> >> > +panic("Unable to allocate memory with order 0!\n");
>> >> > +order--;
>> >> > +continue;
>> >> > +}
>> >>
>> >> Is it not possible to utilize alloc_chunk() here?
>> >
>> > Not really, alloc_chunk will do a ceil calculation of the number of needed
>> > pages, which means we end up allocating bigger chunks than needed and then
>> > free them. I prefer this approach, since we always request the exact
>> > memory
>> > that's required, so there's no need to free leftover pages.
>>
>> Hmm, in that case at least some of the shared logic would be nice to
>> get abstracted out.
>
> TBH, I don't see much benefit in that, alloc_chunk works fine for PV guests
> because Xen ends up walking the list of returned pages and mapping them one
> to one. This is IMHO not what should be done for PVH guests, and instead the
> caller needs to know the actual order of the allocated chunk, so it can pass
> it to guest_physmap_add_page. ATM it's a very simple function that's clear,
> if I start mixing up bits of alloc_chunk it's going to get more complex, and
> I would like to avoid that, so that PVH Dom0 build doesn't end up like
> current PV Dom0 build.
Hmm - I did say "abstract out", not "re-use". The way how memflags
get set and decreasing orders get tried in your code looks suspiciously
similar to what alloc_chunk() does.
>> > In the RFC series we also spoke about placing the MADT in a different
>> > position that the native one, which would mean that we would end up
>> > stealing
>> > some space from a RAM region in order to place it, so that we wouldn't
>> > have
>> > to do this accounting.
>>
>> Putting the new MADT at the same address as the old one won't work
>> anyway, again because possibly vCPU-s > pCPU-s.
>
> Yes, although from my tests doing CPU over-allocation on HVM guests works
> very badly.
Interesting. I didn't try recently, but I recall having tried a longer
while ago without seeing severe issues.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 15/30] xen/x86: populate PVHv2 Dom0 physical memory map
>>> On 11.10.16 at 16:06, wrote:
> On Fri, Sep 30, 2016 at 09:52:56AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:57, wrote:
>> > + * VM86 TSS. Note that after this not all e820 regions will be aligned
>> > + * to PAGE_SIZE.
>> > + */
>> > +for ( i = 1; i <= d->arch.nr_e820; i++ )
>> > +{
>> > +entry = &d->arch.e820[d->arch.nr_e820 - i];
>> > +if ( entry->type != E820_RAM ||
>> > + entry->size < PAGE_SIZE + HVM_VM86_TSS_SIZE )
>> > +continue;
>> > +
>> > +entry->size -= PAGE_SIZE + HVM_VM86_TSS_SIZE;
>> > +gaddr = entry->addr + entry->size;
>> > +break;
>> > +}
>> > +
>> > +if ( gaddr == 0 || gaddr < MB(1) )
>> > +{
>> > +printk("Unable to find memory to stash the identity map and
>> > TSS\n");
>> > +return -ENOMEM;
>>
>> One function up you panic() on error - please be consistent. Also for
>> one of the other patches I think we figured that the TSS isn't really
>> required, so please only warn in that case.
>
> The allocation is done together for the ident PT and the TSS, and while
> the TSS is not mandatory the identity page-table is (or else Dom0 kernel
> won't boot at all on this kind of systems). In any case, it's almost
> impossible for this allocation to fail (because Xen is not actually
> allocating memory, just stealing a part of a RAM region that has already
> been populated).
All fine, but I continue to think errors should be dealt with in a
consistent manner (no matter how [un]likely they are), and
warnings better get issued when there's any meaningful impact
due to whatever triggers the warning. Albeit - having looked at
the full patch again - it looks like I was wrong with naming this
"warning": Both here and further down you return an error if any
of the steps failed. The allocation being done in one go is fine to
be an error; failure of the mapping of the non-required TSS, otoh,
shouldn't cause the loading of Dom0 to fail (and I think that is
where I've been unsure the printk() is warranted).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 17/30] xen/x86: setup PVHv2 Dom0 CPUs
>>> On 12.10.16 at 13:06, wrote: > On Thu, Oct 06, 2016 at 09:20:07AM -0600, Jan Beulich wrote: >> >>> On 27.09.16 at 17:57, wrote: >> > The logic used to setup the CPUID leaves is extremely simplistic (and >> > probably wrong for hardware different than mine). I'm not sure what's the >> > best way to deal with this, the code that currently sets the CPUID leaves >> > for HVM guests lives in libxc, maybe moving it xen/common would be better? >> >> Yeah, a pre-populated array of leaves certainly won't do. > > This is what current HVM guests use, and TBH, I would prefer to don't > diverge from HVM. Would it make sense to leave this as-is, until all this > cpuid stuff is fixed? (IIRC Andrew is still working on this). Leaving it as is makes little sense to me. What would make sense is to make Andrew's work a prereq for this patch. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
>>> On 11.10.16 at 12:31, wrote:
> --- /dev/null
> +++ b/xen/common/gcov/gcc_4_7.c
> @@ -0,0 +1,205 @@
> +/*
> + * This code provides functions to handle gcc's profiling data format
> + * introduced with gcc 4.7.
> + *
> + * This file is based heavily on gcc_3_4.c file.
> + *
> + * For a better understanding, refer to gcc source:
> + * gcc/gcov-io.h
> + * libgcc/libgcov.c
> + *
> + * Uses gcc-internal data definitions.
> + *
> + * Imported from Linux and modified for Xen by
> + *Wei Liu
> + */
> +
> +#include
> +
> +#include "gcov.h"
> +
> +#if GCC_VERSION < 40700
> +#error "Wrong version of GCC used to compile gcov"
> +#endif
> +
> +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
> +#define GCOV_COUNTERS 10
> +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
> +#define GCOV_COUNTERS 9
> +#else
> +#define GCOV_COUNTERS 8
> +#endif
I'm sorry for not having pointed this out on v2 (I had noticed it,
but then didn't finish analyzing the situation), but I'm afraid this
together with ...
> +struct gcov_info {
> +unsigned int version;
> +struct gcov_info *next;
> +unsigned int stamp;
> +const char *filename;
> +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
> +unsigned int n_functions;
> +struct gcov_fn_info **functions;
> +};
... this structure's trailing fields actually getting used by the code
won't work well when changing compiler versions without cleaning
the tree. I think instead you need thin gcc_5.c and gcc_4_9.c
#define-ing their GCOV_COUNTERS and then #include-ing this
shared source file. Plus btw, I don't think gcc 5.0.x (the
development variant of 5.x) would use anything different from
5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
normally be necessary anymore with gcc 5+.
And then - how is all of this supposed to be working in conjucntion
with live patching, where the patch may have been created by yet
another compiler version?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 06/13] efi: create new early memory allocator
Hello Jan,
On 12/10/2016 12:45, Jan Beulich wrote:
On 11.10.16 at 15:39, wrote:
On 06/10/16 13:21, Jan Beulich wrote:
On 05.10.16 at 20:30, wrote:
On 30/09/2016 02:46, Jan Beulich wrote:
On 29.09.16 at 23:42, wrote:
+#else
+static void __init free_ebmalloc_unused_mem(void)
+{
+}
+#endif
Did you build test this for ARM? The function ought to be unused,
as ...
@@ -1251,6 +1301,8 @@ void __init efi_init_memory(void)
} *extra, *extra_head = NULL;
#endif
+free_ebmalloc_unused_mem();
... the whole function here doesn't get built on ARM.
Julien - we're still awaiting your input on general aspects here.
efi_init_memory would need to be called during Xen boot on ARM. I am not
sure where as I we don't yet have runtime support on ARM.
Other than that, the patch looks good to me.
But that wasn't the question. My goal is to have as little code
inside #ifndef CONFIG_ARM as possible, and hence I'd like to have
as much of this new code as possible outside of such conditionals.
So the question really is whether that alternative approach would
be fine with you, or what problems you might see.
I am not sure to get it. The current approach looks good to me, however,
the implementation should not be exposed to ARM until all the TODOs
mentioned by Daniel are fixed.
Which is precisely the opposite of what I'm aiming at. Once again:
Don't you think it is desirable to keep the #ifndef CONFIG_ARM
instances to cover as little code as possible? Not all of the named
TODOs really need to be addressed in order to compile most of
what comprises this new allocator; in fact none of them really
needs addressing:
- if the size estimation turns out to low once ARM starts actually
using this, let's just bump it (perhaps by making it a per-arch
constant),
- if the section chosen needs to be different (which it really
shouldn't be), let's simply adjust it,
If we keep the section in BSS, then we really need to move the
initialization of BSS earlier.
This TODO really needs to be fixed now otherwise it will be a nightmare
to debug later on.
- as we've already figured there's no need for the stub
free_ebmalloc_unused_mem() right now anyway.
But we would need to call free_ebmalloc_unused_mem from somewhere. The
idea to not expose the early memory allocator on ARM is avoid to have an
implementation with may not fully work on ARM because of known missing
pieces.
And then (as another alternative) we have the option of ARM
simply defining EBMALLOC_SIZE to zero for the time being. That
would eliminate the need to actually call free_ebmalloc_unused_mem()
and turn the other two items into non-issues.
I would be happy to review any patches addressing the TODOs.
This, I'm sorry, gets me to raise another question: When is this
finally going to happen? Shared EFI code was introduced for 4.5,
and we're now looking to release 4.8 still with runtime support
unimplemented on ARM. How much longer is this going to take?
Xen is a community project, features are added by contributors when they
need it. I personally don't have any bandwidth to work on EFI runtimes
services at the moment (note that the item is in my TODO list as a low
priority).
I welcome any contribution on EFI runtime support for ARM and will be
happy to review any series.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 06/13] efi: create new early memory allocator
>>> On 12.10.16 at 14:51, wrote:
> Hello Jan,
>
> On 12/10/2016 12:45, Jan Beulich wrote:
> On 11.10.16 at 15:39, wrote:
>>> On 06/10/16 13:21, Jan Beulich wrote:
>>> On 05.10.16 at 20:30, wrote:
> On 30/09/2016 02:46, Jan Beulich wrote:
> On 29.09.16 at 23:42, wrote:
>>> +#else
>>> +static void __init free_ebmalloc_unused_mem(void)
>>> +{
>>> +}
>>> +#endif
>>
>> Did you build test this for ARM? The function ought to be unused,
>> as ...
>>
>>> @@ -1251,6 +1301,8 @@ void __init efi_init_memory(void)
>>> } *extra, *extra_head = NULL;
>>> #endif
>>>
>>> +free_ebmalloc_unused_mem();
>>
>> ... the whole function here doesn't get built on ARM.
>>
>> Julien - we're still awaiting your input on general aspects here.
>
> efi_init_memory would need to be called during Xen boot on ARM. I am not
> sure where as I we don't yet have runtime support on ARM.
>
> Other than that, the patch looks good to me.
But that wasn't the question. My goal is to have as little code
inside #ifndef CONFIG_ARM as possible, and hence I'd like to have
as much of this new code as possible outside of such conditionals.
So the question really is whether that alternative approach would
be fine with you, or what problems you might see.
>>>
>>> I am not sure to get it. The current approach looks good to me, however,
>>> the implementation should not be exposed to ARM until all the TODOs
>>> mentioned by Daniel are fixed.
>>
>> Which is precisely the opposite of what I'm aiming at. Once again:
>> Don't you think it is desirable to keep the #ifndef CONFIG_ARM
>> instances to cover as little code as possible? Not all of the named
>> TODOs really need to be addressed in order to compile most of
>> what comprises this new allocator; in fact none of them really
>> needs addressing:
>> - if the size estimation turns out to low once ARM starts actually
>> using this, let's just bump it (perhaps by making it a per-arch
>> constant),
>> - if the section chosen needs to be different (which it really
>> shouldn't be), let's simply adjust it,
>
> If we keep the section in BSS, then we really need to move the
> initialization of BSS earlier.
Right, but that should be simple enough. Or we do ...
> This TODO really needs to be fixed now otherwise it will be a nightmare
> to debug later on.
>
>> - as we've already figured there's no need for the stub
>> free_ebmalloc_unused_mem() right now anyway.
>
> But we would need to call free_ebmalloc_unused_mem from somewhere. The
> idea to not expose the early memory allocator on ARM is avoid to have an
> implementation with may not fully work on ARM because of known missing
> pieces.
>
>> And then (as another alternative) we have the option of ARM
>> simply defining EBMALLOC_SIZE to zero for the time being. That
>> would eliminate the need to actually call free_ebmalloc_unused_mem()
>> and turn the other two items into non-issues.
... this, which you didn't comment on at all.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> >>> On 11.10.16 at 12:31, wrote:
> > --- /dev/null
> > +++ b/xen/common/gcov/gcc_4_7.c
> > @@ -0,0 +1,205 @@
> > +/*
> > + * This code provides functions to handle gcc's profiling data format
> > + * introduced with gcc 4.7.
> > + *
> > + * This file is based heavily on gcc_3_4.c file.
> > + *
> > + * For a better understanding, refer to gcc source:
> > + * gcc/gcov-io.h
> > + * libgcc/libgcov.c
> > + *
> > + * Uses gcc-internal data definitions.
> > + *
> > + * Imported from Linux and modified for Xen by
> > + *Wei Liu
> > + */
> > +
> > +#include
> > +
> > +#include "gcov.h"
> > +
> > +#if GCC_VERSION < 40700
> > +#error "Wrong version of GCC used to compile gcov"
> > +#endif
> > +
> > +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
> > +#define GCOV_COUNTERS 10
> > +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
> > +#define GCOV_COUNTERS 9
> > +#else
> > +#define GCOV_COUNTERS 8
> > +#endif
>
> I'm sorry for not having pointed this out on v2 (I had noticed it,
> but then didn't finish analyzing the situation), but I'm afraid this
> together with ...
>
> > +struct gcov_info {
> > +unsigned int version;
> > +struct gcov_info *next;
> > +unsigned int stamp;
> > +const char *filename;
> > +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
> > +unsigned int n_functions;
> > +struct gcov_fn_info **functions;
> > +};
>
> ... this structure's trailing fields actually getting used by the code
> won't work well when changing compiler versions without cleaning
> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c
> #define-ing their GCOV_COUNTERS and then #include-ing this
> shared source file. Plus btw, I don't think gcc 5.0.x (the
> development variant of 5.x) would use anything different from
> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
> normally be necessary anymore with gcc 5+.
>
Right. I will do something about this. Thanks for catching this.
> And then - how is all of this supposed to be working in conjucntion
> with live patching, where the patch may have been created by yet
> another compiler version?
>
There is a version field in gcov_info, so we can compare that and reject
incompatible version.
We need to use hooks in livepatching to call the constructor /
destructor when applying / reverting a live-patch. We might need to be
cautious about locks or whatever, but I'm sure it can be figured out.
But I have no idea how useful it would be to use gcov and livepatching
together. For now the easiest thing to do is to
depends on !LIVEPATCH
in Kconfig.
Wei.
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/Intel: virtualize support for cpuid faulting
>>> On 12.10.16 at 06:07, wrote: > --- In addition to what Andrew said: Please version your patch, and please add a short summary of what changed compared to the previous version here. > @@ -2931,6 +2941,11 @@ static int vmx_msr_write_intercept(unsigned int msr, > uint64_t msr_content) > rdmsr_safe(MSR_INTEL_PLATFORM_INFO, msr_content) ) > goto gp_fault; > break; > +case MSR_INTEL_MISC_FEATURES_ENABLES: Blank line ahead of this one please. > --- a/xen/arch/x86/traps.c > +++ b/xen/arch/x86/traps.c > @@ -2945,6 +2945,16 @@ static int emulate_privileged_op(struct cpu_user_regs > *regs) > rdmsr_safe(MSR_INTEL_PLATFORM_INFO, msr_content) ) > goto fail; > break; > +case MSR_INTEL_MISC_FEATURES_ENABLES: Same here. Plus you need to re-base. The code you modify has changed quite a bit. > +if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL || > + rdmsr_safe(MSR_INTEL_MISC_FEATURES_ENABLES, val) || > + msr_content & ~MSR_MISC_FEATURES_CPUID_FAULTING ) Please parenthesize the operands of &. Also I think the msr_content check would better go ahead of the rdmsr_safe(). > +goto fail; > +if ( msr_content == MSR_MISC_FEATURES_CPUID_FAULTING && Please use & instead of ==, so the line won't need to change once further bits here get emulated. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
>>> On 12.10.16 at 15:06, wrote: > But I have no idea how useful it would be to use gcov and livepatching > together. For now the easiest thing to do is to > >depends on !LIVEPATCH > > in Kconfig. I agree. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] ANNOUNCEMENT] Xen 4.8 RC2
I use systemd and openvswitch release: 4.7.0-1-amd64 version: #1 SMP Debian 4.7.5-1 (2016-09-26) machine: x86_64 nr_cpus: 4 max_cpu_id : 3 nr_nodes : 1 cores_per_socket : 2 threads_per_core : 2 cpu_mhz: 2312 hw_caps: bfebfbff:28100800::7f00:77bae3ff::0001:0281 virt_caps : hvm hvm_directio total_memory : 32711 free_memory: 0 sharing_freed_memory : 0 sharing_used_memory: 0 outstanding_claims : 0 free_cpus : 0 ii gcc-6 6.2.0-5 booting hypervizor pass creating VM fail version for 4.8 toolkit hasn't been found amd hangs booting VM fail hangs ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] ANNOUNCEMENT] Xen 4.8 RC2
On Wed, Oct 12, 2016 at 02:13:57PM +0100, Juergen Schinker wrote: > I use systemd and openvswitch > > > release: 4.7.0-1-amd64 But this shows 4.7.0-1. Maybe you didn't install Xen properly? Please make sure all residuals from previous releases are gone. Also please start a new thread when reporting issues. We have a template for that in https://wiki.xenproject.org/wiki/Xen_4.8_RC_test_instructions Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] Xen/Keyhandler: Rework process of nonirq keyhandler
>>> On 12.10.16 at 09:58, wrote:
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -347,7 +347,7 @@ static void switch_serial_input(void)
> static void __serial_rx(char c, struct cpu_user_regs *regs)
> {
> if ( xen_rx )
> -return handle_keypress(c, regs);
> +return handle_keypress(c, regs, true);
I think it would be nice to pass true here only when in polling mode,
unless you know or can deduce that the a similar problem also exists
in IRQ mode. Perhaps you could simply move the !in_irq() here? (Of
course the new function parameter would then want to be renamed.)
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
> And then - how is all of this supposed to be working in conjucntion > with live patching, where the patch may have been created by yet > another compiler version? Uh, I hope one does not create a livepatch patch with another compiler version! Let me put on the TODO to make livepatch-build-tools check gcc against compile.h so that one does not try this. > > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 1/1] xen/arm: Disable the Cortex-a53-edac
On Fri, Oct 07, 2016 at 07:22:33PM +0100, Wei Liu wrote: > On Fri, Oct 07, 2016 at 10:34:15AM -0700, Stefano Stabellini wrote: > > On Fri, 7 Oct 2016, Alistair Francis wrote: > > > On Thu, Oct 6, 2016 at 9:36 AM, Edgar E. Iglesias > > > wrote: > > > > From: "Edgar E. Iglesias" > > > > > > > > Disable the Cortex-a53-edac. Xen currently does not yet > > > > handle reads/writes to the implementation defined CPUMERRSR > > > > register. > > > > > > > > Signed-off-by: Edgar E. Iglesias > > > > > > This solution looks fine to me and everything boots on ZynqMP as > > > expected with this patch. > > > > > > Acked-by: Alistair Francis > > > > Reviewed-by: Stefano Stabellini > > > > Wei, can we have this in 4.8? See the 0/1 email for an explanation of > > why this change is needed. The patch just adds the troublesome > > cortex-a15-pmu to the "skip_matches" array to remove it from dom0's > > device tree. > > > > Sure. Hi Wei, Just a friendly reminder: This is still missing from master, staging and 4.8.0-rc2. Best regards, Edgar ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 1/7] VMX: Statically assign two PI hooks
>>> On 11.10.16 at 02:57, wrote: > +/* > + * In fact, we can remove this hooks inside itself if no new device is in the > + * process of getting assigned and "from" hook is NULL. However, it is not > + * straightforward to find a clear solution, so just leave it here. > + */ > static void vmx_pi_switch_to(struct vcpu *v) I think this comment would better go next to where the NULL assignment is (to be). > @@ -221,9 +226,8 @@ void vmx_pi_hooks_deassign(struct domain *d) > ASSERT(d->arch.hvm_domain.vmx.vcpu_block); > > d->arch.hvm_domain.vmx.vcpu_block = NULL; > -d->arch.hvm_domain.vmx.pi_switch_from = NULL; > -d->arch.hvm_domain.vmx.pi_switch_to = NULL; > d->arch.hvm_domain.vmx.pi_do_resume = NULL; > +d->arch.hvm_domain.vmx.pi_switch_from = NULL; > } Besides the discrepancy of description and implementation which Kevin has already pointed out, I'd also like to ask to replace the "statically" in title and description. "Statically" would mean the hooks get installed unconditionally at domain creation time (or even at build time). Instead I think you mean "keep two PI hooks assigned" or "permanently assign two PI hooks". Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
On 12/10/16 14:06, Wei Liu wrote:
> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> On 11.10.16 at 12:31, wrote:
>>> --- /dev/null
>>> +++ b/xen/common/gcov/gcc_4_7.c
>>> @@ -0,0 +1,205 @@
>>> +/*
>>> + * This code provides functions to handle gcc's profiling data format
>>> + * introduced with gcc 4.7.
>>> + *
>>> + * This file is based heavily on gcc_3_4.c file.
>>> + *
>>> + * For a better understanding, refer to gcc source:
>>> + * gcc/gcov-io.h
>>> + * libgcc/libgcov.c
>>> + *
>>> + * Uses gcc-internal data definitions.
>>> + *
>>> + * Imported from Linux and modified for Xen by
>>> + *Wei Liu
>>> + */
>>> +
>>> +#include
>>> +
>>> +#include "gcov.h"
>>> +
>>> +#if GCC_VERSION < 40700
>>> +#error "Wrong version of GCC used to compile gcov"
>>> +#endif
>>> +
>>> +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
>>> +#define GCOV_COUNTERS 10
>>> +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
>>> +#define GCOV_COUNTERS 9
>>> +#else
>>> +#define GCOV_COUNTERS 8
>>> +#endif
>>
>> I'm sorry for not having pointed this out on v2 (I had noticed it,
>> but then didn't finish analyzing the situation), but I'm afraid this
>> together with ...
>>
>>> +struct gcov_info {
>>> +unsigned int version;
>>> +struct gcov_info *next;
>>> +unsigned int stamp;
>>> +const char *filename;
>>> +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
>>> +unsigned int n_functions;
>>> +struct gcov_fn_info **functions;
>>> +};
>>
>> ... this structure's trailing fields actually getting used by the code
>> won't work well when changing compiler versions without cleaning
>> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c
>> #define-ing their GCOV_COUNTERS and then #include-ing this
>> shared source file. Plus btw, I don't think gcc 5.0.x (the
>> development variant of 5.x) would use anything different from
>> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
>> normally be necessary anymore with gcc 5+.
>>
>
> Right. I will do something about this. Thanks for catching this.
>
>> And then - how is all of this supposed to be working in conjucntion
>> with live patching, where the patch may have been created by yet
>> another compiler version?
>>
>
> There is a version field in gcov_info, so we can compare that and reject
> incompatible version.
>
> We need to use hooks in livepatching to call the constructor /
> destructor when applying / reverting a live-patch. We might need to be
> cautious about locks or whatever, but I'm sure it can be figured out.
>
> But I have no idea how useful it would be to use gcov and livepatching
> together. For now the easiest thing to do is to
>
>depends on !LIVEPATCH
>
> in Kconfig.
Wouldn't it be just as easy, and more useful, to set a "has been
livepatched" flag, and return errors for all gcov hypercalls if its' set?
I would expect most users to want to build a single hypervisor that can
be used for both gcov testing and live patching (under different
circumstances).
-George
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
On 12/10/16 14:24, George Dunlap wrote:
> On 12/10/16 14:06, Wei Liu wrote:
>> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
>> On 11.10.16 at 12:31, wrote:
--- /dev/null
+++ b/xen/common/gcov/gcc_4_7.c
@@ -0,0 +1,205 @@
+/*
+ * This code provides functions to handle gcc's profiling data format
+ * introduced with gcc 4.7.
+ *
+ * This file is based heavily on gcc_3_4.c file.
+ *
+ * For a better understanding, refer to gcc source:
+ * gcc/gcov-io.h
+ * libgcc/libgcov.c
+ *
+ * Uses gcc-internal data definitions.
+ *
+ * Imported from Linux and modified for Xen by
+ *Wei Liu
+ */
+
+#include
+
+#include "gcov.h"
+
+#if GCC_VERSION < 40700
+#error "Wrong version of GCC used to compile gcov"
+#endif
+
+#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
+#define GCOV_COUNTERS 10
+#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
+#define GCOV_COUNTERS 9
+#else
+#define GCOV_COUNTERS 8
+#endif
>>>
>>> I'm sorry for not having pointed this out on v2 (I had noticed it,
>>> but then didn't finish analyzing the situation), but I'm afraid this
>>> together with ...
>>>
+struct gcov_info {
+unsigned int version;
+struct gcov_info *next;
+unsigned int stamp;
+const char *filename;
+void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
+unsigned int n_functions;
+struct gcov_fn_info **functions;
+};
>>>
>>> ... this structure's trailing fields actually getting used by the code
>>> won't work well when changing compiler versions without cleaning
>>> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c
>>> #define-ing their GCOV_COUNTERS and then #include-ing this
>>> shared source file. Plus btw, I don't think gcc 5.0.x (the
>>> development variant of 5.x) would use anything different from
>>> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
>>> normally be necessary anymore with gcc 5+.
>>>
>>
>> Right. I will do something about this. Thanks for catching this.
>>
>>> And then - how is all of this supposed to be working in conjucntion
>>> with live patching, where the patch may have been created by yet
>>> another compiler version?
>>>
>>
>> There is a version field in gcov_info, so we can compare that and reject
>> incompatible version.
>>
>> We need to use hooks in livepatching to call the constructor /
>> destructor when applying / reverting a live-patch. We might need to be
>> cautious about locks or whatever, but I'm sure it can be figured out.
>>
>> But I have no idea how useful it would be to use gcov and livepatching
>> together. For now the easiest thing to do is to
>>
>>depends on !LIVEPATCH
>>
>> in Kconfig.
>
> Wouldn't it be just as easy, and more useful, to set a "has been
> livepatched" flag, and return errors for all gcov hypercalls if its' set?
>
> I would expect most users to want to build a single hypervisor that can
> be used for both gcov testing and live patching (under different
> circumstances).
I mean software provider, not user, of course. That's what I would want
for CentOS, and I'm sure that's what the XenServer (and probably Oracle)
guys want as well.
-George
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
On Wed, Oct 12, 2016 at 02:24:51PM +0100, George Dunlap wrote:
> On 12/10/16 14:06, Wei Liu wrote:
> > On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> > On 11.10.16 at 12:31, wrote:
> >>> --- /dev/null
> >>> +++ b/xen/common/gcov/gcc_4_7.c
> >>> @@ -0,0 +1,205 @@
> >>> +/*
> >>> + * This code provides functions to handle gcc's profiling data format
> >>> + * introduced with gcc 4.7.
> >>> + *
> >>> + * This file is based heavily on gcc_3_4.c file.
> >>> + *
> >>> + * For a better understanding, refer to gcc source:
> >>> + * gcc/gcov-io.h
> >>> + * libgcc/libgcov.c
> >>> + *
> >>> + * Uses gcc-internal data definitions.
> >>> + *
> >>> + * Imported from Linux and modified for Xen by
> >>> + *Wei Liu
> >>> + */
> >>> +
> >>> +#include
> >>> +
> >>> +#include "gcov.h"
> >>> +
> >>> +#if GCC_VERSION < 40700
> >>> +#error "Wrong version of GCC used to compile gcov"
> >>> +#endif
> >>> +
> >>> +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
> >>> +#define GCOV_COUNTERS 10
> >>> +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
> >>> +#define GCOV_COUNTERS 9
> >>> +#else
> >>> +#define GCOV_COUNTERS 8
> >>> +#endif
> >>
> >> I'm sorry for not having pointed this out on v2 (I had noticed it,
> >> but then didn't finish analyzing the situation), but I'm afraid this
> >> together with ...
> >>
> >>> +struct gcov_info {
> >>> +unsigned int version;
> >>> +struct gcov_info *next;
> >>> +unsigned int stamp;
> >>> +const char *filename;
> >>> +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
> >>> +unsigned int n_functions;
> >>> +struct gcov_fn_info **functions;
> >>> +};
> >>
> >> ... this structure's trailing fields actually getting used by the code
> >> won't work well when changing compiler versions without cleaning
> >> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c
> >> #define-ing their GCOV_COUNTERS and then #include-ing this
> >> shared source file. Plus btw, I don't think gcc 5.0.x (the
> >> development variant of 5.x) would use anything different from
> >> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
> >> normally be necessary anymore with gcc 5+.
> >>
> >
> > Right. I will do something about this. Thanks for catching this.
> >
> >> And then - how is all of this supposed to be working in conjucntion
> >> with live patching, where the patch may have been created by yet
> >> another compiler version?
> >>
> >
> > There is a version field in gcov_info, so we can compare that and reject
> > incompatible version.
> >
> > We need to use hooks in livepatching to call the constructor /
> > destructor when applying / reverting a live-patch. We might need to be
> > cautious about locks or whatever, but I'm sure it can be figured out.
> >
> > But I have no idea how useful it would be to use gcov and livepatching
> > together. For now the easiest thing to do is to
> >
> >depends on !LIVEPATCH
> >
> > in Kconfig.
>
> Wouldn't it be just as easy, and more useful, to set a "has been
> livepatched" flag, and return errors for all gcov hypercalls if its' set?
>
> I would expect most users to want to build a single hypervisor that can
> be used for both gcov testing and live patching (under different
> circumstances).
I actually would welcome livepatching and gcov to see if the test-cases I wrote
cover most of the code.
Adding in checking livepatch (common/livepatch.c: prepare_payload) to examine
the .gcov_info and see if it matches the hypervisor one, is fine too.
>
> -George
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] ANNOUNCEMENT] Xen 4.8 RC2
that is the live kernel Linux xen 4.7.0-1-amd64 #1 SMP Debian 4.7.5-1 (2016-09-26) x86_64 GNU/Linux I have to boot a stable xen version to use my machine again which is 4.6 I only use one machine - that's why i use Virtualization I start every major app with its own ded VM and have Xorg on the host and redirect ssh from the VM J - On 12 Oct, 2016, at 13:17, Wei Liu wei.l...@citrix.com wrote: > But this shows 4.7.0-1. Maybe you didn't install Xen properly? Please > make sure all residuals from previous releases are gone. > > Also please start a new thread when reporting issues. We have a template > for that in > > https://wiki.xenproject.org/wiki/Xen_4.8_RC_test_instructions > > Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 04/15] xen: Create a new file xen_frontend.c
On Tue, Oct 04, 2016 at 09:43:33AM +0300, Emil Condrea wrote: > Its purpose is to store frontend related functions. > > Signed-off-by: Quan Xu > Signed-off-by: Emil Condrea Looks good, once the comments on the previous patches are addressed, same comments for patch 5, 6 and 7. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 08/15] xen: Move xenstore cleanup and mkdir functions
On Tue, Oct 04, 2016 at 09:43:37AM +0300, Emil Condrea wrote: > The name of the functions moved to xen_pvdev.c: > * xenstore_cleanup_dir > * xen_config_cleanup > * xenstore_mkdir > > Signed-off-by: Emil Condrea Acked-by: Anthony PERARD -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 09/15] xen: Rename xen_be_printf to xen_pv_printf
On Tue, Oct 04, 2016 at 09:43:38AM +0300, Emil Condrea wrote: > Prepare xen_be_printf to be used by both backend and frontends: > * xen_be_printf -> xen_pv_printf > > Signed-off-by: Emil Condrea Acked-by: Anthony PERARD -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
On Wed, Oct 12, 2016 at 02:26:26PM +0100, George Dunlap wrote: [...] > >> > >> There is a version field in gcov_info, so we can compare that and reject > >> incompatible version. > >> > >> We need to use hooks in livepatching to call the constructor / > >> destructor when applying / reverting a live-patch. We might need to be > >> cautious about locks or whatever, but I'm sure it can be figured out. > >> > >> But I have no idea how useful it would be to use gcov and livepatching > >> together. For now the easiest thing to do is to > >> > >>depends on !LIVEPATCH > >> > >> in Kconfig. > > > > Wouldn't it be just as easy, and more useful, to set a "has been > > livepatched" flag, and return errors for all gcov hypercalls if its' set? > > > > I would expect most users to want to build a single hypervisor that can > > be used for both gcov testing and live patching (under different > > circumstances). > > I mean software provider, not user, of course. That's what I would want > for CentOS, and I'm sure that's what the XenServer (and probably Oracle) > guys want as well. > The usefulness of such build is not as big as you might think I'm afraid -- it wouldn't be useful until we figure out how to apply a livepatch generated with gcov support built in. Wei. > -George > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
>>> On 12.10.16 at 15:23, wrote: >> And then - how is all of this supposed to be working in conjucntion >> with live patching, where the patch may have been created by yet >> another compiler version? > > Uh, I hope one does not create a livepatch patch with another compiler > version! > > Let me put on the TODO to make livepatch-build-tools check gcc against > compile.h so that one does not try this. What's wrong with mixing compiler versions in general? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
>>> On 12.10.16 at 15:26, wrote: > On 12/10/16 14:24, George Dunlap wrote: >> I would expect most users to want to build a single hypervisor that can >> be used for both gcov testing and live patching (under different >> circumstances). > > I mean software provider, not user, of course. That's what I would want > for CentOS, and I'm sure that's what the XenServer (and probably Oracle) > guys want as well. But gcov is explicitly a non-production feature, iirc. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
On 12/10/16 14:26, George Dunlap wrote:
> On 12/10/16 14:24, George Dunlap wrote:
>> On 12/10/16 14:06, Wei Liu wrote:
>>> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
>>> On 11.10.16 at 12:31, wrote:
> --- /dev/null
> +++ b/xen/common/gcov/gcc_4_7.c
> @@ -0,0 +1,205 @@
> +/*
> + * This code provides functions to handle gcc's profiling data format
> + * introduced with gcc 4.7.
> + *
> + * This file is based heavily on gcc_3_4.c file.
> + *
> + * For a better understanding, refer to gcc source:
> + * gcc/gcov-io.h
> + * libgcc/libgcov.c
> + *
> + * Uses gcc-internal data definitions.
> + *
> + * Imported from Linux and modified for Xen by
> + *Wei Liu
> + */
> +
> +#include
> +
> +#include "gcov.h"
> +
> +#if GCC_VERSION < 40700
> +#error "Wrong version of GCC used to compile gcov"
> +#endif
> +
> +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
> +#define GCOV_COUNTERS 10
> +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
> +#define GCOV_COUNTERS 9
> +#else
> +#define GCOV_COUNTERS 8
> +#endif
I'm sorry for not having pointed this out on v2 (I had noticed it,
but then didn't finish analyzing the situation), but I'm afraid this
together with ...
> +struct gcov_info {
> +unsigned int version;
> +struct gcov_info *next;
> +unsigned int stamp;
> +const char *filename;
> +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
> +unsigned int n_functions;
> +struct gcov_fn_info **functions;
> +};
... this structure's trailing fields actually getting used by the code
won't work well when changing compiler versions without cleaning
the tree. I think instead you need thin gcc_5.c and gcc_4_9.c
#define-ing their GCOV_COUNTERS and then #include-ing this
shared source file. Plus btw, I don't think gcc 5.0.x (the
development variant of 5.x) would use anything different from
5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
normally be necessary anymore with gcc 5+.
>>> Right. I will do something about this. Thanks for catching this.
>>>
And then - how is all of this supposed to be working in conjucntion
with live patching, where the patch may have been created by yet
another compiler version?
>>> There is a version field in gcov_info, so we can compare that and reject
>>> incompatible version.
>>>
>>> We need to use hooks in livepatching to call the constructor /
>>> destructor when applying / reverting a live-patch. We might need to be
>>> cautious about locks or whatever, but I'm sure it can be figured out.
>>>
>>> But I have no idea how useful it would be to use gcov and livepatching
>>> together. For now the easiest thing to do is to
>>>
>>>depends on !LIVEPATCH
>>>
>>> in Kconfig.
>> Wouldn't it be just as easy, and more useful, to set a "has been
>> livepatched" flag, and return errors for all gcov hypercalls if its' set?
>>
>> I would expect most users to want to build a single hypervisor that can
>> be used for both gcov testing and live patching (under different
>> circumstances).
> I mean software provider, not user, of course. That's what I would want
> for CentOS, and I'm sure that's what the XenServer (and probably Oracle)
> guys want as well.
GCOV is majority invasive, both in terms of performance (every basic
block needs to do a locked increment of a counter) and data size
(metadata for all basic blocks).
No software vendor is ever going to have it enabled in a production
scenario.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 10/15] xen: Rename xen_be_unbind_evtchn
On Tue, Oct 04, 2016 at 09:43:39AM +0300, Emil Condrea wrote: > Prepare xen_be_unbind_evtchn to be shared with frontends: > * xen_be_unbind_evtchn -> xen_pv_unbind_evtchn > > Signed-off-by: Emil Condrea Acked-by: Anthony PERARD -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
On Wed, Oct 12, 2016 at 09:29:04AM -0400, Konrad Rzeszutek Wilk wrote: [...] > > > > Wouldn't it be just as easy, and more useful, to set a "has been > > livepatched" flag, and return errors for all gcov hypercalls if its' set? > > > > I would expect most users to want to build a single hypervisor that can > > be used for both gcov testing and live patching (under different > > circumstances). > > I actually would welcome livepatching and gcov to see if the test-cases I > wrote > cover most of the code. > I don't follow. Gcov doesn't give you a call graph -- if that's what you're after. > Adding in checking livepatch (common/livepatch.c: prepare_payload) to examine > the .gcov_info and see if it matches the hypervisor one, is fine too. > This then involves a non-trivial amount of work to figure out all the corner cases. It's better to defer that to a later stage. Wei. > > > > -George > > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 11/15] xen: Rename xen_be_send_notify
On Tue, Oct 04, 2016 at 09:43:40AM +0300, Emil Condrea wrote: > Prepare xen_be_send_notify to be shared with frontends: > * xen_be_send_notify -> xen_pv_send_notify > > Signed-off-by: Emil Condrea Acked-by: Anthony PERARD -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 13/15] xen: Rename xen_be_find_xendev
On Tue, Oct 04, 2016 at 09:43:42AM +0300, Emil Condrea wrote: > Prepare xen_be_find_xendev to be shared with frontends: > * xen_be_find_xendev -> xen_pv_find_xendev > > Signed-off-by: Emil Condrea Acked-by: Anthony PERARD -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
On 12/10/16 14:41, George Dunlap wrote:
> On 12/10/16 14:34, Andrew Cooper wrote:
>> On 12/10/16 14:26, George Dunlap wrote:
>>> On 12/10/16 14:24, George Dunlap wrote:
On 12/10/16 14:06, Wei Liu wrote:
> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> On 11.10.16 at 12:31, wrote:
>>> --- /dev/null
>>> +++ b/xen/common/gcov/gcc_4_7.c
>>> @@ -0,0 +1,205 @@
>>> +/*
>>> + * This code provides functions to handle gcc's profiling data format
>>> + * introduced with gcc 4.7.
>>> + *
>>> + * This file is based heavily on gcc_3_4.c file.
>>> + *
>>> + * For a better understanding, refer to gcc source:
>>> + * gcc/gcov-io.h
>>> + * libgcc/libgcov.c
>>> + *
>>> + * Uses gcc-internal data definitions.
>>> + *
>>> + * Imported from Linux and modified for Xen by
>>> + *Wei Liu
>>> + */
>>> +
>>> +#include
>>> +
>>> +#include "gcov.h"
>>> +
>>> +#if GCC_VERSION < 40700
>>> +#error "Wrong version of GCC used to compile gcov"
>>> +#endif
>>> +
>>> +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
>>> +#define GCOV_COUNTERS 10
>>> +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
>>> +#define GCOV_COUNTERS 9
>>> +#else
>>> +#define GCOV_COUNTERS 8
>>> +#endif
>> I'm sorry for not having pointed this out on v2 (I had noticed it,
>> but then didn't finish analyzing the situation), but I'm afraid this
>> together with ...
>>
>>> +struct gcov_info {
>>> +unsigned int version;
>>> +struct gcov_info *next;
>>> +unsigned int stamp;
>>> +const char *filename;
>>> +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
>>> +unsigned int n_functions;
>>> +struct gcov_fn_info **functions;
>>> +};
>> ... this structure's trailing fields actually getting used by the code
>> won't work well when changing compiler versions without cleaning
>> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c
>> #define-ing their GCOV_COUNTERS and then #include-ing this
>> shared source file. Plus btw, I don't think gcc 5.0.x (the
>> development variant of 5.x) would use anything different from
>> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
>> normally be necessary anymore with gcc 5+.
>>
> Right. I will do something about this. Thanks for catching this.
>
>> And then - how is all of this supposed to be working in conjucntion
>> with live patching, where the patch may have been created by yet
>> another compiler version?
>>
> There is a version field in gcov_info, so we can compare that and reject
> incompatible version.
>
> We need to use hooks in livepatching to call the constructor /
> destructor when applying / reverting a live-patch. We might need to be
> cautious about locks or whatever, but I'm sure it can be figured out.
>
> But I have no idea how useful it would be to use gcov and livepatching
> together. For now the easiest thing to do is to
>
>depends on !LIVEPATCH
>
> in Kconfig.
Wouldn't it be just as easy, and more useful, to set a "has been
livepatched" flag, and return errors for all gcov hypercalls if its' set?
I would expect most users to want to build a single hypervisor that can
be used for both gcov testing and live patching (under different
circumstances).
>>> I mean software provider, not user, of course. That's what I would want
>>> for CentOS, and I'm sure that's what the XenServer (and probably Oracle)
>>> guys want as well.
>> GCOV is majority invasive, both in terms of performance (every basic
>> block needs to do a locked increment of a counter) and data size
>> (metadata for all basic blocks).
>>
>> No software vendor is ever going to have it enabled in a production
>> scenario.
> You're right, I wasn't thinking.
>
> But also presumably you'd like to be able to minimize the difference
> between the thing you're testing and the thing you ship; having to
> disable LivePatch increases the delta slightly.
>
> Anyway, I still think having them both Kconfig-ured is a good idea, but
> not so much that I'd spend any more time arguing for it.
It is a testing feature. It would certainly be nice to get code
coverage of the livepatching parts, but that absolutely shouldn't block
making gcov usable in the first place.
It might be worth sticking a #TODO make GCOV worth with Livepatching in
the kconfig file (for anyone who stumbles across this dependency).
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote: > >>> On 12.10.16 at 15:23, wrote: > >> And then - how is all of this supposed to be working in conjucntion > >> with live patching, where the patch may have been created by yet > >> another compiler version? > > > > Uh, I hope one does not create a livepatch patch with another compiler > > version! > > > > Let me put on the TODO to make livepatch-build-tools check gcc against > > compile.h so that one does not try this. > > What's wrong with mixing compiler versions in general? Besides scaring me? The one issue we had encountered was with compilers generating random named symbols for the switch tables. Those end up being called "CSWTCH.XYZ" where the XYZ depends on the position of the moon along with how many goats you have sacrificied to the altar of GCC gods. Older compilers don't neccessarily do it, newer ones do, and every time you build an livepatch the naming is different. Frustrating. It maybe that newer versions of GCC are more predictable about this naming. Maybe Martin can share some of his experience? CC-ing him. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 4/7] VMX: Make sure PI is in proper state before install the hooks
>>> On 11.10.16 at 02:57, wrote:
> static void pi_desc_init(struct vcpu *v)
> {
> -uint32_t dest;
> -
> v->arch.hvm_vmx.pi_desc.nv = posted_intr_vector;
>
> -dest = cpu_physical_id(v->processor);
> -
> -if ( x2apic_enabled )
> -v->arch.hvm_vmx.pi_desc.ndst = dest;
> -else
> -v->arch.hvm_vmx.pi_desc.ndst = MASK_INSR(dest, PI_xAPIC_NDST_MASK);
> +/*
> + * Mark NDST as invalid, then we can use this invalid value as a
> + * marker to whether update NDST or not in vmx_pi_hooks_assign().
> + */
> +v->arch.hvm_vmx.pi_desc.ndst = 0x;
I think I had at the same time asked to make this a #define, so the
two (currently) instance can be connected together.
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -211,14 +211,39 @@ static void vmx_pi_do_resume(struct vcpu *v)
> /* This function is called when pcidevs_lock is held */
> void vmx_pi_hooks_assign(struct domain *d)
> {
> +struct vcpu *v;
> +
> if ( !iommu_intpost || !has_hvm_container_domain(d) )
> return;
>
> ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
>
> -d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
> +/*
> + * We carefully handle the timing here:
> + * - Install the context switch first
> + * - Then set the NDST field
> + * - Install the block and resume hooks in the end
> + *
> + * This can make sure the PI (especially the NDST feild) is
> + * in proper state when we call vmx_vcpu_block().
> + */
> d->arch.hvm_domain.vmx.pi_switch_from = vmx_pi_switch_from;
> d->arch.hvm_domain.vmx.pi_switch_to = vmx_pi_switch_to;
> +
> +for_each_vcpu ( d, v )
> +{
> +unsigned int dest = cpu_physical_id(v->processor);
> +struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
> +
> +/*
> + * We don't need to update NDST if 'arch.hvm_domain.vmx.pi_switch_to'
> + * already gets called
I think you mean "got" or "has got". Also I think you'd better refer to
the actual VMX function instead of the hook pointer field.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 14/15] xen: Rename xen_be_del_xendev
On Tue, Oct 04, 2016 at 09:43:43AM +0300, Emil Condrea wrote: > Prepare xen_be_del_xendev to be shared with frontends: > * xen_be_del_xendev -> xen_pv_del_xendev > > Signed-off-by: Emil Condrea Acked-by: Anthony PERARD -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] ANNOUNCEMENT] Xen 4.8 RC2
On Wed, Oct 12, 2016 at 02:29:51PM +0100, Juergen Schinker wrote: > > that is the live kernel > Linux xen 4.7.0-1-amd64 #1 SMP Debian 4.7.5-1 (2016-09-26) x86_64 GNU/Linux > Oh, right. Sorry I missed that. > > I have to boot a stable xen version to use my machine again which is 4.6 > Then there is probably a version mismatch between your tools and hypervisor. You can boot into the new hypervsior, use LD_PRELOAD and / or LD_PATH to specify the new libraries and invoke the new xl via absolute path. LD_PRELOAD=/path/to/libraries /path/to/xl But if you haven't tried this before, the easiest thing to do is to uninstall 4.6 and install 4.8. But I understand that might not be feasible for you. Wei. > I only use one machine - that's why i use Virtualization > > I start every major app with its own ded VM and have Xorg on the host and > redirect ssh from the VM > > J > > > - On 12 Oct, 2016, at 13:17, Wei Liu wei.l...@citrix.com wrote: > > > But this shows 4.7.0-1. Maybe you didn't install Xen properly? Please > > make sure all residuals from previous releases are gone. > > > > Also please start a new thread when reporting issues. We have a template > > for that in > > > > https://wiki.xenproject.org/wiki/Xen_4.8_RC_test_instructions > > > > Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 1/1] xen/arm: Disable the Cortex-a53-edac
On Wed, Oct 12, 2016 at 03:23:43PM +0200, Edgar E. Iglesias wrote: > On Fri, Oct 07, 2016 at 07:22:33PM +0100, Wei Liu wrote: > > On Fri, Oct 07, 2016 at 10:34:15AM -0700, Stefano Stabellini wrote: > > > On Fri, 7 Oct 2016, Alistair Francis wrote: > > > > On Thu, Oct 6, 2016 at 9:36 AM, Edgar E. Iglesias > > > > wrote: > > > > > From: "Edgar E. Iglesias" > > > > > > > > > > Disable the Cortex-a53-edac. Xen currently does not yet > > > > > handle reads/writes to the implementation defined CPUMERRSR > > > > > register. > > > > > > > > > > Signed-off-by: Edgar E. Iglesias > > > > > > > > This solution looks fine to me and everything boots on ZynqMP as > > > > expected with this patch. > > > > > > > > Acked-by: Alistair Francis > > > > > > Reviewed-by: Stefano Stabellini > > > > > > Wei, can we have this in 4.8? See the 0/1 email for an explanation of > > > why this change is needed. The patch just adds the troublesome > > > cortex-a15-pmu to the "skip_matches" array to remove it from dom0's > > > device tree. > > > > > > > Sure. > > > Hi Wei, > > Just a friendly reminder: > This is still missing from master, staging and 4.8.0-rc2. > I thought Stefano would do it. I will apply this shortly. Thanks for the heads-up. Wei. > Best regards, > Edgar ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
On Wed, Oct 12, 2016 at 02:40:08PM +0100, Wei Liu wrote: > On Wed, Oct 12, 2016 at 09:29:04AM -0400, Konrad Rzeszutek Wilk wrote: > [...] > > > > > > Wouldn't it be just as easy, and more useful, to set a "has been > > > livepatched" flag, and return errors for all gcov hypercalls if its' set? > > > > > > I would expect most users to want to build a single hypervisor that can > > > be used for both gcov testing and live patching (under different > > > circumstances). > > > > I actually would welcome livepatching and gcov to see if the test-cases I > > wrote > > cover most of the code. > > > > I don't follow. Gcov doesn't give you a call graph -- if that's what > you're after. It gives me an idea which functions/branches have run (not the livepatch itself - just the infrastructure around adding a livepatch, doing ELF checks, etc). And more importantly - which ones haven't run and need some more test-cases. > > > Adding in checking livepatch (common/livepatch.c: prepare_payload) to > > examine > > the .gcov_info and see if it matches the hypervisor one, is fine too. > > > > This then involves a non-trivial amount of work to figure out all the > corner cases. It's better to defer that to a later stage. Sure thing. And the !LIVEPATCH is fine for now. I just need to get an idea of what this would entail so it can get done. > > Wei. > > > > > > > -George > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
On Wed, Oct 12, 2016 at 09:46:51AM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Oct 12, 2016 at 02:40:08PM +0100, Wei Liu wrote: > > On Wed, Oct 12, 2016 at 09:29:04AM -0400, Konrad Rzeszutek Wilk wrote: > > [...] > > > > > > > > Wouldn't it be just as easy, and more useful, to set a "has been > > > > livepatched" flag, and return errors for all gcov hypercalls if its' > > > > set? > > > > > > > > I would expect most users to want to build a single hypervisor that can > > > > be used for both gcov testing and live patching (under different > > > > circumstances). > > > > > > I actually would welcome livepatching and gcov to see if the test-cases I > > > wrote > > > cover most of the code. > > > > > > > I don't follow. Gcov doesn't give you a call graph -- if that's what > > you're after. > > It gives me an idea which functions/branches have run (not the livepatch > itself - just the infrastructure around adding a livepatch, doing ELF checks, > etc). > > And more importantly - which ones haven't run and need some more test-cases. > Right. Thanks for the explanation. That would indeed be useful. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 12/15] xen: Rename xen_be_evtchn_event
On Tue, Oct 04, 2016 at 09:43:41AM +0300, Emil Condrea wrote: > Prepare xen_be_evtchn_event to be shared with frontends: > * xen_be_evtchn_event -> xen_pv_evtchn_event > > Signed-off-by: Emil Condrea Acked-by: Anthony PERARD -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
On 12/10/16 14:34, Andrew Cooper wrote:
> On 12/10/16 14:26, George Dunlap wrote:
>> On 12/10/16 14:24, George Dunlap wrote:
>>> On 12/10/16 14:06, Wei Liu wrote:
On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
On 11.10.16 at 12:31, wrote:
>> --- /dev/null
>> +++ b/xen/common/gcov/gcc_4_7.c
>> @@ -0,0 +1,205 @@
>> +/*
>> + * This code provides functions to handle gcc's profiling data format
>> + * introduced with gcc 4.7.
>> + *
>> + * This file is based heavily on gcc_3_4.c file.
>> + *
>> + * For a better understanding, refer to gcc source:
>> + * gcc/gcov-io.h
>> + * libgcc/libgcov.c
>> + *
>> + * Uses gcc-internal data definitions.
>> + *
>> + * Imported from Linux and modified for Xen by
>> + *Wei Liu
>> + */
>> +
>> +#include
>> +
>> +#include "gcov.h"
>> +
>> +#if GCC_VERSION < 40700
>> +#error "Wrong version of GCC used to compile gcov"
>> +#endif
>> +
>> +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
>> +#define GCOV_COUNTERS 10
>> +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
>> +#define GCOV_COUNTERS 9
>> +#else
>> +#define GCOV_COUNTERS 8
>> +#endif
> I'm sorry for not having pointed this out on v2 (I had noticed it,
> but then didn't finish analyzing the situation), but I'm afraid this
> together with ...
>
>> +struct gcov_info {
>> +unsigned int version;
>> +struct gcov_info *next;
>> +unsigned int stamp;
>> +const char *filename;
>> +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
>> +unsigned int n_functions;
>> +struct gcov_fn_info **functions;
>> +};
> ... this structure's trailing fields actually getting used by the code
> won't work well when changing compiler versions without cleaning
> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c
> #define-ing their GCOV_COUNTERS and then #include-ing this
> shared source file. Plus btw, I don't think gcc 5.0.x (the
> development variant of 5.x) would use anything different from
> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
> normally be necessary anymore with gcc 5+.
>
Right. I will do something about this. Thanks for catching this.
> And then - how is all of this supposed to be working in conjucntion
> with live patching, where the patch may have been created by yet
> another compiler version?
>
There is a version field in gcov_info, so we can compare that and reject
incompatible version.
We need to use hooks in livepatching to call the constructor /
destructor when applying / reverting a live-patch. We might need to be
cautious about locks or whatever, but I'm sure it can be figured out.
But I have no idea how useful it would be to use gcov and livepatching
together. For now the easiest thing to do is to
depends on !LIVEPATCH
in Kconfig.
>>> Wouldn't it be just as easy, and more useful, to set a "has been
>>> livepatched" flag, and return errors for all gcov hypercalls if its' set?
>>>
>>> I would expect most users to want to build a single hypervisor that can
>>> be used for both gcov testing and live patching (under different
>>> circumstances).
>> I mean software provider, not user, of course. That's what I would want
>> for CentOS, and I'm sure that's what the XenServer (and probably Oracle)
>> guys want as well.
>
> GCOV is majority invasive, both in terms of performance (every basic
> block needs to do a locked increment of a counter) and data size
> (metadata for all basic blocks).
>
> No software vendor is ever going to have it enabled in a production
> scenario.
You're right, I wasn't thinking.
But also presumably you'd like to be able to minimize the difference
between the thing you're testing and the thing you ship; having to
disable LivePatch increases the delta slightly.
Anyway, I still think having them both Kconfig-ured is a good idea, but
not so much that I'd spend any more time arguing for it.
-George
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 5/7] VT-d: No need to set irq affinity for posted format IRTE
>>> On 11.10.16 at 02:57, wrote:
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -547,6 +547,49 @@ static int remap_entry_to_msi_msg(
> return 0;
> }
>
> +static bool_t pi_can_suppress_irte_update(struct iremap_entry *new,
bool (and true/false respectively) please.
And then the function name suggests that no modification gets done
here (and hence the first parameter could be const too), yet the
implementation does otherwise (and I don't understand why).
> +const struct iremap_entry *old)
> +{
> +bool_t ret = 1;
> +u16 fpd, sid, sq, svt;
> +
> +if ( !old->remap.p || !old->remap.im )
> +return 0;
> +
> +fpd = new->post.fpd;
> +sid = new->post.sid;
> +sq = new->post.sq;
> +svt = new->post.svt;
> +
> +*new = *old;
> +
> +if ( fpd != old->post.fpd )
> +{
> +new->post.fpd = fpd;
> +ret = 0;
> +}
> +
> +if ( sid != old->post.sid )
> +{
> +new->post.sid = sid;
> +ret = 0;
> +}
> +
> +if ( sq != old->post.sq )
> +{
> +new->post.sq = sq;
> +ret = 0;
> +}
> +
> +if ( svt != old->post.svt )
> +{
> +new->post.svt = svt;
> +ret = 0;
> +}
What's the selection of the fields based on? Namely, what about
vector, pda_l, and pda_h?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 6/7] VT-d: Some cleanups
>>> On 11.10.16 at 02:57, wrote: > @@ -638,7 +638,8 @@ static int msi_msg_to_remap_entry( > GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, index, > iremap_entries, iremap_entry); > > -memcpy(&new_ire, iremap_entry, sizeof(struct iremap_entry)); > +if ( iremap_entry->remap.p ) > +new_ire.remap.im = iremap_entry->remap.im; This is certainly more of a change than what title and description suggest. If you really mean it to be this way, it needs to be explained in the description. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 1/1] xen/arm: Disable the Cortex-a53-edac
On Wed, Oct 12, 2016 at 02:47:18PM +0100, Wei Liu wrote: > On Wed, Oct 12, 2016 at 03:23:43PM +0200, Edgar E. Iglesias wrote: > > On Fri, Oct 07, 2016 at 07:22:33PM +0100, Wei Liu wrote: > > > On Fri, Oct 07, 2016 at 10:34:15AM -0700, Stefano Stabellini wrote: > > > > On Fri, 7 Oct 2016, Alistair Francis wrote: > > > > > On Thu, Oct 6, 2016 at 9:36 AM, Edgar E. Iglesias > > > > > wrote: > > > > > > From: "Edgar E. Iglesias" > > > > > > > > > > > > Disable the Cortex-a53-edac. Xen currently does not yet > > > > > > handle reads/writes to the implementation defined CPUMERRSR > > > > > > register. > > > > > > > > > > > > Signed-off-by: Edgar E. Iglesias > > > > > > > > > > This solution looks fine to me and everything boots on ZynqMP as > > > > > expected with this patch. > > > > > > > > > > Acked-by: Alistair Francis > > > > > > > > Reviewed-by: Stefano Stabellini > > > > > > > > Wei, can we have this in 4.8? See the 0/1 email for an explanation of > > > > why this change is needed. The patch just adds the troublesome > > > > cortex-a15-pmu to the "skip_matches" array to remove it from dom0's > > > > device tree. > > > > > > > > > > Sure. > > > > > > Hi Wei, > > > > Just a friendly reminder: > > This is still missing from master, staging and 4.8.0-rc2. > > > > I thought Stefano would do it. > > I will apply this shortly. Thanks for the heads-up. > Now applied. Wei. > Wei. > > > Best regards, > > Edgar ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit [and 1 more messages]
On 10/12/2016 07:00 AM, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer
> commit"):
>> That was eventually done. I'm not sure exactly when the change was
>> made. Does gcc -Wno-foo work properly on all the gcc's we care about ?
> Jan Beulich writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer
> commit"):
>> Just fyi I have run into an issue with -Wno-override-init use in Linux
>> 4.8 on gcc 4.1.x, so what you say doesn't appear to hold for all gcc
>> versions we permit to be used.
> Well, that answers my question above.
>
> I think the right approach is to:
>
> * Test -Wno-this-is-not-a-warning-option. If gcc accepts it,
>add -Wno-something to disable the nonnull check·
Back compatibility is in fact not a problem. These options would only be
passed on when gcc6+ is used
>
> * Review the misleading indentations and if there are only a few, fix
>them in a downstream patch. Or, if there are many, decide to
>tolerate them.
There are more warnings than just indentation and nonnull checks:
-Wno-nonnull-compare
-Wno-unused-const-variable
-Wno-misleading-indentation
-Wno-shift-negative-value
-Wno-array-bounds
(The last two flagged actual bugs that have been fixed upstream).
Some of the warnings can be addressed by backporting upstream patches
but there are a few for which backporting will involve much more code
movement than fixing the code ourselves.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
>>> On 12.10.16 at 15:44, wrote: > On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote: >> >>> On 12.10.16 at 15:23, wrote: >> >> And then - how is all of this supposed to be working in conjucntion >> >> with live patching, where the patch may have been created by yet >> >> another compiler version? >> > >> > Uh, I hope one does not create a livepatch patch with another compiler >> > version! >> > >> > Let me put on the TODO to make livepatch-build-tools check gcc against >> > compile.h so that one does not try this. >> >> What's wrong with mixing compiler versions in general? > > Besides scaring me? What is it that scares you? > The one issue we had encountered was with compilers generating random named > symbols for the switch tables. Those end up being called "CSWTCH.XYZ" > where the XYZ depends on the position of the moon along with how many > goats you have sacrificied to the altar of GCC gods. > > Older compilers don't neccessarily do it, newer ones do, and every time > you build an livepatch the naming is different. Frustrating. But this would mean you don't just depend on gcc version, but even on the specific build (as the numbering you refer to may change with whatever patches a distro applies on top of the upstream tarball, as well as perhaps with configure and build options). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit [and 1 more messages]
On Wed, Oct 12, 2016 at 12:00:56PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer
> commit"):
> > That was eventually done. I'm not sure exactly when the change was
> > made. Does gcc -Wno-foo work properly on all the gcc's we care about ?
>
> Jan Beulich writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer
> commit"):
> > Just fyi I have run into an issue with -Wno-override-init use in Linux
> > 4.8 on gcc 4.1.x, so what you say doesn't appear to hold for all gcc
> > versions we permit to be used.
>
> Well, that answers my question above.
>
> I think the right approach is to:
>
> * Test -Wno-this-is-not-a-warning-option. If gcc accepts it,
>add -Wno-something to disable the nonnull check·
>
> * Review the misleading indentations and if there are only a few, fix
>them in a downstream patch. Or, if there are many, decide to
>tolerate them.
>
FAOD, I consider this sub-thread for "what should we do for stable
versions of Xen". This is orthogonal to whether we should upgrade our
in-tree ipxe version. In other words, I plan to commence with the
upgrade if there is no major issue is found next week.
Wei.
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit [and 1 more messages]
Wei Liu writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit
[and 1 more messages]"):
> FAOD, I consider this sub-thread for "what should we do for stable
> versions of Xen". This is orthogonal to whether we should upgrade our
> in-tree ipxe version. In other words, I plan to commence with the
> upgrade if there is no major issue is found next week.
Yes.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
On 12.10.2016 15:44, Konrad Rzeszutek Wilk wrote: On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote: On 12.10.16 at 15:23, wrote: And then - how is all of this supposed to be working in conjucntion with live patching, where the patch may have been created by yet another compiler version? Uh, I hope one does not create a livepatch patch with another compiler version! Let me put on the TODO to make livepatch-build-tools check gcc against compile.h so that one does not try this. What's wrong with mixing compiler versions in general? Besides scaring me? The one issue we had encountered was with compilers generating random named symbols for the switch tables. Those end up being called "CSWTCH.XYZ" where the XYZ depends on the position of the moon along with how many goats you have sacrificied to the altar of GCC gods. Older compilers don't neccessarily do it, newer ones do, and every time you build an livepatch the naming is different. Frustrating. It maybe that newer versions of GCC are more predictable about this naming. Maybe Martin can share some of his experience? CC-ing him. There are a couple of naming conventions for internal symbols and also static symbols where you basically have to pray that gcc implementation does not change. Interestingly, icc has some conventions that make those symbol names a bit more stable. The tricky thing is matchmaking between the existing build and the new build to construct the binary diff and to match up symbols for which you want to provide replacement code. We use a reproducible build environment to construct hotpatches for an existing build in the absolutely same environment (gcc version, lib versions, gas version, binutils etc.). This sidesteps most of the problems. Martin Amazon Development Center Germany GmbH Berlin - Dresden - Aachen main office: Krausenstr. 38, 10117 Berlin Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger Ust-ID: DE289237879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] Xen/Keyhandler: Rework process of nonirq keyhandler
On 10/12/2016 9:19 PM, Jan Beulich wrote:
On 12.10.16 at 09:58, wrote:
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -347,7 +347,7 @@ static void switch_serial_input(void)
static void __serial_rx(char c, struct cpu_user_regs *regs)
{
if ( xen_rx )
-return handle_keypress(c, regs);
+return handle_keypress(c, regs, true);
I think it would be nice to pass true here only when in polling mode,
unless you know or can deduce that the a similar problem also exists
in IRQ mode. Perhaps you could simply move the !in_irq() here?
That's a good idea. Thanks.
(Of course the new function parameter would then want to be renamed.)
Since the issue happens when handle_keypress() runs in a timer handler,
how about to name new parameter "intimer"? __serial_rx() is called in a
timer handler or interrupt handler. Or do you have other suggestion?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 0/2] Xen: Fix Xen hypervisor panic during dumping timer info on huge machine.
On 10/12/2016 7:08 PM, Ian Jackson wrote:
Wei Liu writes ("Re: [PATCH v2 0/2] Xen: Fix Xen hypervisor panic during dumping
timer info on huge machine."):
On Wed, Oct 12, 2016 at 04:20:02PM +0800, Lan Tianyu wrote:
On 2016年10月12日 16:09, Jan Beulich wrote:
Also, any reason you send to the list twice (once @lists.xen.org,
and another time to @lists.xenproject.org)?
Sometime I found my patches wasn't able to arrive xen-devel and so
send to both xen.org and xenproject.org maillist. I will double check.
Both addresses should work. There are glitches from time to time though.
So do report to us if this happens again.
I don't think either address is likely to work differently or
separately to the other. So please just send to one, and if it
doesn't work, please report it and we will try to fix it.
Ok. I get it.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [linux-4.1 test] 101390: trouble: blocked/broken/fail/pass
flight 101390 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/101390/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-xsm 3 host-install(3)broken REGR. vs. 101004 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-credit2 15 guest-start/debian.repeatfail like 101004 test-armhf-armhf-xl 15 guest-start/debian.repeatfail like 101004 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail like 101004 test-armhf-armhf-xl-vhd 9 debian-di-installfail like 101004 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 101004 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101004 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101004 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101004 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101004 Tests which did not succeed, but are not blocking: test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a build-amd64-rumprun 5 rumprun-buildfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass build-i386-rumprun5 rumprun-buildfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass version targeted for testing: linux91473db3a3257eacead8f4d84cf4bc96c447193f baseline version: linux04cb720142764ebf3786eba1feb8fc4b6ef87fcf Last test of basis 101004 2016-09-18 15:44:49 Z 23 days Testing same since 101390 2016-10-12 06:51:19 Z0 days1 attempts People who touched revisions under test: Akshay Bhat Al Viro Alan Stern Andrew Morton Anson Huang Ard Biesheuvel Ashish Samant Balbir Singh Benjamin Herrenschmidt Boris Brezillon Catalin Marinas Chris Mason Christoffer Dall Clemens Gruber Daniele Palmas Dave Airlie David S. Miller Eric Biggers Fabio Estevam Felipe Balbi Felix Fietkau Greg Kroah-Hartman Gregory CLEMENT Guenter Roeck Hans-Christian Noren Egtvedt Havard Skinnemoen Herbert Xu Huacai Chen Ian Kent Ingo Molnar Itaru Kitayama Jaegeuk Kim James Hogan Jan Kara Jan Leupold Jan Stancek Jeff Mahoney Jesper Nilsson Johan Hovold Johannes Berg Jonathan Cameron Joseph Qi Jun Piao Justin Chen Kai-Heng Feng Kalle Valo Ken Lin Kristian H. Kriste
[Xen-devel] [ovmf test] 101392: all pass - PUSHED
flight 101392 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101392/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 50d4be4f4e3d5beb2c1aa58853b92e3cc1f4cb9a
baseline version:
ovmf 46cd2cb6a7ba5b1fdaff1eb18a13dc399d6a7fe2
Last test of basis 101384 2016-10-12 02:17:41 Z0 days
Testing same since 101392 2016-10-12 08:46:21 Z0 days1 attempts
People who touched revisions under test:
Bruce Cran
Daniil Egranov
Eric Dong
Laszlo Ersek
Laszlo Ersek
Ruiyu Ni
Ryan Harkin
Yonghong Zhu
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=50d4be4f4e3d5beb2c1aa58853b92e3cc1f4cb9a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
50d4be4f4e3d5beb2c1aa58853b92e3cc1f4cb9a
+ branch=ovmf
+ revision=50d4be4f4e3d5beb2c1aa58853b92e3cc1f4cb9a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x50d4be4f4e3d5beb2c1aa58853b92e3cc1f4cb9a = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub
[Xen-devel] [PATCH] xen-netback: fix type mismatch warning
Wiht the latest rework of the xen-netback driver, we get a warning
on ARM about the types passed into min():
drivers/net/xen-netback/rx.c: In function 'xenvif_rx_next_chunk':
include/linux/kernel.h:739:16: error: comparison of distinct pointer types
lacks a cast [-Werror]
The reason is that XEN_PAGE_SIZE is not size_t here. There
is no actual bug, and we can easily avoid the warning using the
min_t() macro instead of min().
Fixes: eb1723a29b9a ("xen-netback: refactor guest rx")
Signed-off-by: Arnd Bergmann
---
drivers/net/xen-netback/rx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
index 8e9ade6ccf18..aeb150258c6c 100644
--- a/drivers/net/xen-netback/rx.c
+++ b/drivers/net/xen-netback/rx.c
@@ -337,9 +337,9 @@ static void xenvif_rx_next_chunk(struct xenvif_queue *queue,
frag_data += pkt->frag_offset;
frag_len -= pkt->frag_offset;
- chunk_len = min(frag_len, XEN_PAGE_SIZE - offset);
- chunk_len = min(chunk_len,
- XEN_PAGE_SIZE - xen_offset_in_page(frag_data));
+ chunk_len = min_t(size_t, frag_len, XEN_PAGE_SIZE - offset);
+ chunk_len = min_t(size_t, chunk_len, XEN_PAGE_SIZE -
+xen_offset_in_page(frag_data));
pkt->frag_offset += chunk_len;
--
2.9.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen
On 10/12/16 05:32 -0600, Jan Beulich wrote:
On 12.10.16 at 12:33, wrote:
The layout is shown as the following diagram.
+---+---+---+--+--+
| whatever used | Partition | Super | Reserved | /dev/pmem0p1 |
| by kernel| Table | Block | for Xen | |
+---+---+---+--+--+
\_ ___/
V
/dev/pmem0
I have to admit that I dislike this, for not being OS-agnostic.
Neither should there be any Xen-specific region, nor should the
"whatever used by kernel" one be restricted to just Linux. What
I could see is an OS-reserved area ahead of the partition table,
the exact usage of which depends on which OS is currently
running (and in the Xen case this might be both Xen _and_ the
Dom0 kernel, arbitrated by a tbd protocol). After all, when
running under Xen, the Dom0 may not have a need for as much
control data as it has when running on bare hardware, for it
controlling less (if any) of the actual memory ranges when Xen
is present.
Isn't this OS-reserved area still not OS-agnostic, as it requires OS
to know where the reserved area is? Or do you mean it's not if it's
defined by a protocol that is accepted by all OSes?
Let me list another two methods just coming to my mind.
1. The first method extends the usage of the super block used by
current Linux kernel to reserve space on pmem.
Current Linux kernel places a super block of the following
structure near the beginning of a pmem namespace.
struct nd_pfn_sb {
u8 signature[PFN_SIG_LEN];
u8 uuid[16];
u8 parent_uuid[16];
__le32 flags;
__le16 version_major;
__le16 version_minor;
__le64 dataoff; /* relative to namespace_base + start_pad */
__le64 npfns;
__le32 mode;
/* minor-version-1 additions for section alignment */
__le32 start_pad;
__le32 end_trunc;
/* minor-version-2 record the base alignment of the mapping */
__le32 align;
u8 padding[4000];
__le64 checksum;
}
Two interesting fields here are 'dataoff' and 'mode':
- 'dataoff' indicates the offset where the data area starts,
ie. IIUC, the part that can be accessed via /dev/pmemN or
/dev/daxN.
- 'mode' indicates whether Linux puts struct page for this
namespace in the ram (= PFN_MODE_RAM) or on the device (=
PFN_MODE_PMEM).
Currently for Linux, only 'mode' is customizable, while 'dataoff'
is not. If mode == PFN_MODE_RAM, no reservation for struct page is
made on the device, and dataoff starts almost immediately after
the super block except a small reserved area in between for other
structures and alignment. If mode == PFN_MODE_PMEM, the size of
the reservation is decided by kernel, i.e. 64 bytes per struct
page.
I propose to make the size of the reserved area customizable,
e.g. via ioctl and ndctl.
- If mode == PFN_MODE_PMEM and
* if the given reserved size is large enough to hold what an OS
(not limited to Linux) wants to put in, then the OS just
starts use it as desired;
* if the given reserved size is not enough, then the OS reports
error and may take other fallback actions.
- If mode == PFN_MODE_RAM and
* if the reserved size is zero, then it's the current way that
Linux uses the device;
* if the reserved size is non-zero, I would like to reserve this
case for hypervisor (right now, namely Xen hypervisor)
usage. That is, the OS should not use the reserved area. For
Xen, we could add a function in xen driver in kernel to report
the reserved area to hypervisor.
I guess this might be the OS-agnostic way Jan expects, but Dan may
object to.
2. Lay another pseudo device on the block device (e.g. /dev/pmemN)
provided by the NVDIMM driver.
This pseudo device can reserve the size according to user's
requirement. The reservation information can be persistently
recorded in a super block before the reserved area.
This pseudo device also implements another pseudo block device to
allow the non-reserved area be accessed as a block device (we can
even implement it as DAX-capable).
pseudo block device
/-^---\
+--+---+---+---+
| whatever used | Super | reserved by | |
| by NVDIMM driver | Block | pseudo device | |
+--+---+---+---+
\_ ___/
V
/dev/pmem0
[Xen-devel] [PATCH] x86: xen: move cpu_up functions out of ifdef
Three newly introduced functions are not defined when CONFIG_XEN_PVHVM is
disabled, but are still being used:
arch/x86/xen/enlighten.c:141:12: warning: ‘xen_cpu_up_prepare’ used but never
defined
arch/x86/xen/enlighten.c:142:12: warning: ‘xen_cpu_up_online’ used but never
defined
arch/x86/xen/enlighten.c:143:12: warning: ‘xen_cpu_dead’ used but never defined
Fixes: 4d737042d6c4 ("xen/x86: Convert to hotplug state machine")
Signed-off-by: Arnd Bergmann
---
arch/x86/xen/enlighten.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index c0fdd57da7aa..bdd855685403 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1837,6 +1837,7 @@ static void __init init_hvm_pv_info(void)
xen_domain_type = XEN_HVM_DOMAIN;
}
+#endif
static int xen_cpu_up_prepare(unsigned int cpu)
{
@@ -1887,6 +1888,7 @@ static int xen_cpu_up_online(unsigned int cpu)
return 0;
}
+#ifdef CONFIG_XEN_PVHVM
#ifdef CONFIG_KEXEC_CORE
static void xen_hvm_shutdown(void)
{
--
2.9.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86: xen: move cpu_up functions out of ifdef
On 10/12/2016 11:20 AM, Arnd Bergmann wrote:
> Three newly introduced functions are not defined when CONFIG_XEN_PVHVM is
> disabled, but are still being used:
>
> arch/x86/xen/enlighten.c:141:12: warning: ‘xen_cpu_up_prepare’ used but never
> defined
> arch/x86/xen/enlighten.c:142:12: warning: ‘xen_cpu_up_online’ used but never
> defined
> arch/x86/xen/enlighten.c:143:12: warning: ‘xen_cpu_dead’ used but never
> defined
>
> Fixes: 4d737042d6c4 ("xen/x86: Convert to hotplug state machine")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> >>> On 11.10.16 at 12:31, wrote:
> > --- /dev/null
> > +++ b/xen/common/gcov/gcc_4_7.c
> > @@ -0,0 +1,205 @@
> > +/*
> > + * This code provides functions to handle gcc's profiling data format
> > + * introduced with gcc 4.7.
> > + *
> > + * This file is based heavily on gcc_3_4.c file.
> > + *
> > + * For a better understanding, refer to gcc source:
> > + * gcc/gcov-io.h
> > + * libgcc/libgcov.c
> > + *
> > + * Uses gcc-internal data definitions.
> > + *
> > + * Imported from Linux and modified for Xen by
> > + *Wei Liu
> > + */
> > +
> > +#include
> > +
> > +#include "gcov.h"
> > +
> > +#if GCC_VERSION < 40700
> > +#error "Wrong version of GCC used to compile gcov"
> > +#endif
> > +
> > +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
> > +#define GCOV_COUNTERS 10
> > +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
> > +#define GCOV_COUNTERS 9
> > +#else
> > +#define GCOV_COUNTERS 8
> > +#endif
>
> I'm sorry for not having pointed this out on v2 (I had noticed it,
> but then didn't finish analyzing the situation), but I'm afraid this
> together with ...
>
> > +struct gcov_info {
> > +unsigned int version;
> > +struct gcov_info *next;
> > +unsigned int stamp;
> > +const char *filename;
> > +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
> > +unsigned int n_functions;
> > +struct gcov_fn_info **functions;
> > +};
>
> ... this structure's trailing fields actually getting used by the code
> won't work well when changing compiler versions without cleaning
> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c
> #define-ing their GCOV_COUNTERS and then #include-ing this
> shared source file. Plus btw, I don't think gcc 5.0.x (the
> development variant of 5.x) would use anything different from
> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
> normally be necessary anymore with gcc 5+.
>
I think you misread here: __GNUC_MINOR__ is the "x" part of 5.x.y, the
"y" part is __GNUC_PATCHLEVEL__.
I've broken down things into several files as well as provided
corresponding Kconfig options:
gcc_4_7_base.c: the body of what is now gcc_4_7.c, better name is
welcome
gcc_4_7.c: gcov format in gcc version [4.7, 4,9), nr counters 8
gcc_4_9.c: gcov format in gcc version [4.9, 5.1), nr counters 9
gcc_5_1.c: gcov format in gcc version [5.1, ...), nr counters 10
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [ovmf baseline-only test] 67867: all pass
This run is configured for baseline tests only. flight 67867 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67867/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 46cd2cb6a7ba5b1fdaff1eb18a13dc399d6a7fe2 baseline version: ovmf 4b8234d05400a852a42688fea14acc7ddeeebad4 Last test of basis67864 2016-10-12 02:19:44 Z0 days Testing same since67867 2016-10-12 08:19:10 Z0 days1 attempts People who touched revisions under test: Jiewen Yao Michael D Kinney jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 46cd2cb6a7ba5b1fdaff1eb18a13dc399d6a7fe2 Author: Jiewen Yao Date: Sat Oct 8 09:55:59 2016 +0800 FatPkg/FatPei: Use PcdRecoveryFileName PCD. This PCD is used to indicated the recovery file name. The previous name - FvMain.Fv is hardcoded in FatPei. It does not make sense to force the name. Now a platform may use any recovery file name. Tested-by: Michael D Kinney Cc: Ruiyu Ni Cc: Feng Tian Cc: Star Zeng Cc: Liming Gao Cc: Eric Dong Cc: Michael D Kinney Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao Reviewed-by: Feng Tian Reviewed-by: Ruiyu Ni Reviewed-by: Michael D Kinney commit 9753360756bc9d28f3b1cc59624e0b4fe3618870 Author: Jiewen Yao Date: Sat Oct 8 09:55:20 2016 +0800 MdeModulePkg/CdExpressPei: Use PcdRecoveryFileName PCD. This PCD is used to indicated the recovery file name. The previous name - FvMain.Fv is hardcoded in CdExpressPei. It does not make sense to force the name. Now a platform may use any recovery file name. Cc: Feng Tian Cc: Star Zeng Cc: Liming Gao Cc: Eric Dong Cc: Ruiyu Ni Cc: Michael D Kinney Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao Reviewed-by: Feng Tian Reviewed-by: Ruiyu Ni Reviewed-by: Michael D Kinney commit 08bec91eba7cc8c8a831592137503f23e7fb8f7a Author: Jiewen Yao Date: Sat Oct 8 09:54:33 2016 +0800 MdeModulePkg/dec: Add PcdRecoveryFileName PCD. This PCD is used to indicated the recovery file name. The previous name - FvMain.Fv is hardcoded in FatPei and CdExpressPei. It does not make sense to force the name. Now a platform may use any recovery file name. Tested-by: Michael D Kinney Cc: Feng Tian Cc: Star Zeng Cc: Liming Gao Cc: Eric Dong Cc: Ruiyu Ni Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao Reviewed-by: Feng Tian Reviewed-by: Ruiyu Ni Reviewed-by: Michael D Kinney ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen
>>> On 12.10.16 at 16:58, wrote: > On 10/12/16 05:32 -0600, Jan Beulich wrote: > On 12.10.16 at 12:33, wrote: >>> The layout is shown as the following diagram. >>> >>> +---+---+---+--+--+ >>> | whatever used | Partition | Super | Reserved | /dev/pmem0p1 | >>> | by kernel| Table | Block | for Xen | | >>> +---+---+---+--+--+ >>> \_ ___/ >>> V >>> /dev/pmem0 >> >>I have to admit that I dislike this, for not being OS-agnostic. >>Neither should there be any Xen-specific region, nor should the >>"whatever used by kernel" one be restricted to just Linux. What >>I could see is an OS-reserved area ahead of the partition table, >>the exact usage of which depends on which OS is currently >>running (and in the Xen case this might be both Xen _and_ the >>Dom0 kernel, arbitrated by a tbd protocol). After all, when >>running under Xen, the Dom0 may not have a need for as much >>control data as it has when running on bare hardware, for it >>controlling less (if any) of the actual memory ranges when Xen >>is present. >> > > Isn't this OS-reserved area still not OS-agnostic, as it requires OS > to know where the reserved area is? Or do you mean it's not if it's > defined by a protocol that is accepted by all OSes? The latter - we clearly won't get away without some agreement on where to retrieve position and size of this area. I was simply assuming that such a protocol already exists. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen
On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich wrote: On 12.10.16 at 16:58, wrote: >> On 10/12/16 05:32 -0600, Jan Beulich wrote: >> On 12.10.16 at 12:33, wrote: The layout is shown as the following diagram. +---+---+---+--+--+ | whatever used | Partition | Super | Reserved | /dev/pmem0p1 | | by kernel| Table | Block | for Xen | | +---+---+---+--+--+ \_ ___/ V /dev/pmem0 >>> >>>I have to admit that I dislike this, for not being OS-agnostic. >>>Neither should there be any Xen-specific region, nor should the >>>"whatever used by kernel" one be restricted to just Linux. What >>>I could see is an OS-reserved area ahead of the partition table, >>>the exact usage of which depends on which OS is currently >>>running (and in the Xen case this might be both Xen _and_ the >>>Dom0 kernel, arbitrated by a tbd protocol). After all, when >>>running under Xen, the Dom0 may not have a need for as much >>>control data as it has when running on bare hardware, for it >>>controlling less (if any) of the actual memory ranges when Xen >>>is present. >>> >> >> Isn't this OS-reserved area still not OS-agnostic, as it requires OS >> to know where the reserved area is? Or do you mean it's not if it's >> defined by a protocol that is accepted by all OSes? > > The latter - we clearly won't get away without some agreement on > where to retrieve position and size of this area. I was simply > assuming that such a protocol already exists. > No, we should not mix the struct page reservation that the Dom0 kernel may actively use with the Xen reservation that the Dom0 kernel does not consume. Explain again what is wrong with the partition approach? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
>>> On 12.10.16 at 17:33, wrote:
> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
>> >>> On 11.10.16 at 12:31, wrote:
>> > --- /dev/null
>> > +++ b/xen/common/gcov/gcc_4_7.c
>> > @@ -0,0 +1,205 @@
>> > +/*
>> > + * This code provides functions to handle gcc's profiling data format
>> > + * introduced with gcc 4.7.
>> > + *
>> > + * This file is based heavily on gcc_3_4.c file.
>> > + *
>> > + * For a better understanding, refer to gcc source:
>> > + * gcc/gcov-io.h
>> > + * libgcc/libgcov.c
>> > + *
>> > + * Uses gcc-internal data definitions.
>> > + *
>> > + * Imported from Linux and modified for Xen by
>> > + *Wei Liu
>> > + */
>> > +
>> > +#include
>> > +
>> > +#include "gcov.h"
>> > +
>> > +#if GCC_VERSION < 40700
>> > +#error "Wrong version of GCC used to compile gcov"
>> > +#endif
>> > +
>> > +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
>> > +#define GCOV_COUNTERS 10
>> > +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
>> > +#define GCOV_COUNTERS 9
>> > +#else
>> > +#define GCOV_COUNTERS 8
>> > +#endif
>>
>> I'm sorry for not having pointed this out on v2 (I had noticed it,
>> but then didn't finish analyzing the situation), but I'm afraid this
>> together with ...
>>
>> > +struct gcov_info {
>> > +unsigned int version;
>> > +struct gcov_info *next;
>> > +unsigned int stamp;
>> > +const char *filename;
>> > +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
>> > +unsigned int n_functions;
>> > +struct gcov_fn_info **functions;
>> > +};
>>
>> ... this structure's trailing fields actually getting used by the code
>> won't work well when changing compiler versions without cleaning
>> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c
>> #define-ing their GCOV_COUNTERS and then #include-ing this
>> shared source file. Plus btw, I don't think gcc 5.0.x (the
>> development variant of 5.x) would use anything different from
>> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
>> normally be necessary anymore with gcc 5+.
>>
>
> I think you misread here: __GNUC_MINOR__ is the "x" part of 5.x.y, the
> "y" part is __GNUC_PATCHLEVEL__.
No, I didn't. From 5.x onwards the information previously carried in
__GNUC_PATCHLEVEL__ is now in __GNUC_MINOR__. And as much
as previously you would not normally need to look at the former,
with newer gcc you shouldn't need to look at the latter.
> I've broken down things into several files as well as provided
> corresponding Kconfig options:
>
> gcc_4_7_base.c: the body of what is now gcc_4_7.c, better name is
> welcome
Why don't you keep it gcc_4_7.c, with its counter definition being
conditional upon the symbol not already being defined?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 18/30] xen/x86: setup PVHv2 Dom0 ACPI tables
On Thu, Oct 06, 2016 at 09:40:50AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:57, wrote:
> > FWIW, I think that the current approach that I've used in order to craft the
> > MADT is not the best one, IMHO it would be better to place the MADT at the
> > end of the E820_ACPI region (expanding it's size one page), and modify the
> > XSDT/RSDT in order to point to it, that way we avoid shadowing any other
> > ACPI data that might be at the same page as the native MADT (and that needs
> > to be modified by Dom0).
>
> I agree with the idea of placing MADT elsewhere, but I don't think you
> can rely on E820_ACPI to have room to grow into right after its end.
Right, I think picking some memory from a RAM region and marking it as
E820_ACPI is the best approach.
> > @@ -50,6 +53,8 @@ static long __initdata dom0_max_nrpages = LONG_MAX;
> > #define HVM_VM86_TSS_SIZE 128
> >
> > static unsigned int __initdata hvm_mem_stats[MAX_ORDER + 1];
> > +static unsigned int __initdata acpi_intr_overrrides = 0;
> > +static struct acpi_madt_interrupt_override __initdata *intsrcovr = NULL;
>
> Pointless initializers.
Removed.
> > +static void __init acpi_zap_table_signature(char *name)
> > +{
> > +struct acpi_table_header *table;
> > +acpi_status status;
> > +union {
> > +char str[ACPI_NAME_SIZE];
> > +uint32_t bits;
> > +} signature;
> > +char tmp;
> > +int i;
> > +
> > +status = acpi_get_table(name, 0, &table);
> > +if ( ACPI_SUCCESS(status) )
> > +{
> > +memcpy(&signature.str[0], &table->signature[0], ACPI_NAME_SIZE);
> > +for ( i = 0; i < ACPI_NAME_SIZE / 2; i++ )
> > +{
> > +tmp = signature.str[ACPI_NAME_SIZE - i - 1];
> > +signature.str[ACPI_NAME_SIZE - i - 1] = signature.str[i];
> > +signature.str[i] = tmp;
> > +}
> > +write_atomic((uint32_t*)&table->signature[0], signature.bits);
> > +}
> > +}
>
> Together with moving MADT elsewhere we should also move
> XSDT/RSDT, at which point we can simply avoid copying the
> pointers for tables we don't want Dom0 to see (and down the
> road we also have the option of adding tables).
>
> The downside to both approaches is that this once again is a
> black-listing model, i.e. new structure types we may need to
> also suppress will remain visible to Dom0 until a patched
> hypervisor would become available.
Maybe we could do whitelisting instead? I can see that at least the
following tables should be available to Dom0 if present, but TBH, it's hard
to tell:
MADT, DSDT, FADT, SSDT, FACS, SBST, NFIT, MCFG, TCPA. Then ECDT, CPEP and
RASF also seem fine to make available to Dom0, but I'm dubious.
But I agree that crafting a custom XSDT/RSDT is the best option here.
> > + pfn, pfn + nr_pages);
> > +return rc;
> > +}
> > +}
> > +/*
> > + * Since most memory maps provided by hardware are wrong, make sure
> > each
> > + * top-level table is properly mapped into Dom0.
> > + */
>
> Please be more specific here - wrong in which way? Not all ACPI tables
> living in one of the two E820 type regions? But see also below.
>
> In any event you need to be more careful here: Mapping ordinary RAM
> 1:1 into Dom0 can't end well. Also, once working with a cloned XSDT you
> won't need to cover tables here which have got hidden from Dom0.
I've found systems where some ACPI tables reside in memory holes or reserved
regions. I don't think I've found a system where an ACPI table would reside
in a RAM region, but I agree that it's worth adding a check here to make
sure.
> > +for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
> > +{
> > +pfn = PFN_DOWN(acpi_gbl_root_table_list.tables[i].address);
> > +nr_pages = DIV_ROUND_UP(acpi_gbl_root_table_list.tables[i].length,
> > +PAGE_SIZE);
> > +rc = modify_mmio_11(d, pfn, nr_pages, true);
> > +if ( rc )
> > +{
> > +printk(
> > +"Failed to map ACPI region %#lx - %#lx into Dom0 memory
> > map\n",
> > + pfn, pfn + nr_pages);
> > +return rc;
> > +}
> > +}
> > +
> > +/*
> > + * Special treatment for memory < 1MB:
> > + * - Copy the data in e820 regions marked as RAM (BDA, EBDA...).
>
> Copy? What if some of it needs to get modified to interact with
> firmware? I think you'd be better off mapping everything Xen
> doesn't use into Dom0, and only mapping fresh RAM pages
> over regions Xen does use (namely the trampoline).
Hm, that was my first approach (mapping the whole first MB into Dom0), but
sadly it doesn't seem to work because FreeBSD at least places the AP boot
trampoline there, and since APs are launched in 16b mode, the emulator
cannot handle executing memory from MMIO regions and crashes the domain.
That's why I had to map and copy data from RAM regions below 1MB. The BDA
it's
Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen
>>> On 12.10.16 at 17:42, wrote: > On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich wrote: > On 12.10.16 at 16:58, wrote: >>> On 10/12/16 05:32 -0600, Jan Beulich wrote: >>> On 12.10.16 at 12:33, wrote: > The layout is shown as the following diagram. > > +---+---+---+--+--+ > | whatever used | Partition | Super | Reserved | /dev/pmem0p1 | > | by kernel| Table | Block | for Xen | | > +---+---+---+--+--+ > \_ ___/ > V > /dev/pmem0 I have to admit that I dislike this, for not being OS-agnostic. Neither should there be any Xen-specific region, nor should the "whatever used by kernel" one be restricted to just Linux. What I could see is an OS-reserved area ahead of the partition table, the exact usage of which depends on which OS is currently running (and in the Xen case this might be both Xen _and_ the Dom0 kernel, arbitrated by a tbd protocol). After all, when running under Xen, the Dom0 may not have a need for as much control data as it has when running on bare hardware, for it controlling less (if any) of the actual memory ranges when Xen is present. >>> >>> Isn't this OS-reserved area still not OS-agnostic, as it requires OS >>> to know where the reserved area is? Or do you mean it's not if it's >>> defined by a protocol that is accepted by all OSes? >> >> The latter - we clearly won't get away without some agreement on >> where to retrieve position and size of this area. I was simply >> assuming that such a protocol already exists. >> > > No, we should not mix the struct page reservation that the Dom0 kernel > may actively use with the Xen reservation that the Dom0 kernel does > not consume. Explain again what is wrong with the partition approach? Not sure what was unclear in my previous reply. I don't think there should be apriori knowledge of whether Xen is (going to be) used on a system, and even if it gets used, but just occasionally, it would (apart from the abstract considerations already given) be a waste of resources to set something aside that could be used for other purposes while Xen is not running. Static partitioning should only be needed for persistent data. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] Xen/Keyhandler: Rework process of nonirq keyhandler
>>> On 12.10.16 at 16:30, wrote:
>
> On 10/12/2016 9:19 PM, Jan Beulich wrote:
> On 12.10.16 at 09:58, wrote:
>>> --- a/xen/drivers/char/console.c
>>> +++ b/xen/drivers/char/console.c
>>> @@ -347,7 +347,7 @@ static void switch_serial_input(void)
>>> static void __serial_rx(char c, struct cpu_user_regs *regs)
>>> {
>>> if ( xen_rx )
>>> -return handle_keypress(c, regs);
>>> +return handle_keypress(c, regs, true);
>>
>> I think it would be nice to pass true here only when in polling mode,
>> unless you know or can deduce that the a similar problem also exists
>> in IRQ mode. Perhaps you could simply move the !in_irq() here?
>
> That's a good idea. Thanks.
>
>>(Of course the new function parameter would then want to be renamed.)
>
> Since the issue happens when handle_keypress() runs in a timer handler,
> how about to name new parameter "intimer"? __serial_rx() is called in a
> timer handler or interrupt handler. Or do you have other suggestion?
I think "intimer" can be confusing (to be mixed up with timer interrupt).
How about "force_tasklet"?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 18/30] xen/x86: setup PVHv2 Dom0 ACPI tables
>>> On 12.10.16 at 17:35, wrote:
> On Thu, Oct 06, 2016 at 09:40:50AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:57, wrote:
>> > +static void __init acpi_zap_table_signature(char *name)
>> > +{
>> > +struct acpi_table_header *table;
>> > +acpi_status status;
>> > +union {
>> > +char str[ACPI_NAME_SIZE];
>> > +uint32_t bits;
>> > +} signature;
>> > +char tmp;
>> > +int i;
>> > +
>> > +status = acpi_get_table(name, 0, &table);
>> > +if ( ACPI_SUCCESS(status) )
>> > +{
>> > +memcpy(&signature.str[0], &table->signature[0], ACPI_NAME_SIZE);
>> > +for ( i = 0; i < ACPI_NAME_SIZE / 2; i++ )
>> > +{
>> > +tmp = signature.str[ACPI_NAME_SIZE - i - 1];
>> > +signature.str[ACPI_NAME_SIZE - i - 1] = signature.str[i];
>> > +signature.str[i] = tmp;
>> > +}
>> > +write_atomic((uint32_t*)&table->signature[0], signature.bits);
>> > +}
>> > +}
>>
>> Together with moving MADT elsewhere we should also move
>> XSDT/RSDT, at which point we can simply avoid copying the
>> pointers for tables we don't want Dom0 to see (and down the
>> road we also have the option of adding tables).
>>
>> The downside to both approaches is that this once again is a
>> black-listing model, i.e. new structure types we may need to
>> also suppress will remain visible to Dom0 until a patched
>> hypervisor would become available.
>
> Maybe we could do whitelisting instead? I can see that at least the
> following tables should be available to Dom0 if present, but TBH, it's hard
> to tell:
Taking an abstract perspective I agree with Andrew that we should
be whitelisting here. However, as you already see from the list you
provided (which afaict is far from complete wrt ACPI 6.1), this may
become cumbersome already initially, not to speak of down the road.
>> > +for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
>> > +{
>> > +pfn = PFN_DOWN(acpi_gbl_root_table_list.tables[i].address);
>> > +nr_pages = DIV_ROUND_UP(acpi_gbl_root_table_list.tables[i].length,
>> > +PAGE_SIZE);
>> > +rc = modify_mmio_11(d, pfn, nr_pages, true);
>> > +if ( rc )
>> > +{
>> > +printk(
>> > +"Failed to map ACPI region %#lx - %#lx into Dom0 memory
>> > map\n",
>> > + pfn, pfn + nr_pages);
>> > +return rc;
>> > +}
>> > +}
>> > +
>> > +/*
>> > + * Special treatment for memory < 1MB:
>> > + * - Copy the data in e820 regions marked as RAM (BDA, EBDA...).
>>
>> Copy? What if some of it needs to get modified to interact with
>> firmware? I think you'd be better off mapping everything Xen
>> doesn't use into Dom0, and only mapping fresh RAM pages
>> over regions Xen does use (namely the trampoline).
>
> Hm, that was my first approach (mapping the whole first MB into Dom0), but
> sadly it doesn't seem to work because FreeBSD at least places the AP boot
> trampoline there, and since APs are launched in 16b mode, the emulator
> cannot handle executing memory from MMIO regions and crashes the domain.
> That's why I had to map and copy data from RAM regions below 1MB. The BDA
> it's all static data AFAICT, and the EBDA should reside in a reserved
> region (or at least does on my systems).
I'm afraid there are systems where the EBDA is not marked reserved.
But maybe there are no current (64-bit capable) ones of that sort.
> Might it be possible to solve this by identity mapping the first 1MB, and
> marking the RAM regions there as p2m_ram_rw? Or would that create even
> further problems?
Hmm, not sure - the range below 1Mb is marked as MMIO in
frame_table[], so there would be a (benign?) conflict at least there.
>> > +io_apic = (struct acpi_madt_io_apic *)(madt + 1);
>> > +io_apic->header.type = ACPI_MADT_TYPE_IO_APIC;
>> > +io_apic->header.length = sizeof(*io_apic);
>> > +io_apic->id = 1;
>> > +io_apic->address = VIOAPIC_DEFAULT_BASE_ADDRESS;
>>
>> I think you need to make as many IO-APICs available to Dom0 as
>> there are hardware ones.
>
> Right, I've been wondering about this, and then I need to expand the IO APIC
> emulation code so that Xen is able to emulate two IO-APICs.
>
> Can I ask why do you think this is needed? If the number of pins in the
> multiple IO APIC case doesn't exceed 48 (which is what the emulated IO APIC
> provides), shouldn't this be enough?
The number of pins easily can be larger. And I think the mapping
code would end up simpler if there was a 1:1 relationship between
physical and virtual IO-APICs. I've just not checked one of my
larger (but older) systems - it has 5 IO-APICs with a total of 120 pins.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [DOC v6] PV Calls protocol design
> > > ### Data ring
> > >
> > > Data rings are used for sending and receiving data over a connected
> > > socket. They
> > > are created upon a successful **accept** or **connect** command.
> > >
> > > A data ring is composed of two pieces: the interface and the **in** and
> > > **out**
> > > buffers. The interface, represented by `struct pvcalls_ring_intf` is
> > > shared
> > > first and resides on the page whose grant reference is passed by
> > > **accept** and
> > > **connect** as parameter. `struct pvcalls_ring_intf` contains the list of
> > > grant
> > > references which constitute the **in** and **out** data buffers.
> > >
> > > Data ring interface
> > >
> > > struct pvcalls_data_intf {
> > > PVCALLS_RING_IDX in_cons, in_prod;
> >
> > Do you want to add some spacing between them so that you don't
> > use the same cacheline?
>
> Let me get this straight. in_cons and in_prod should be on the same
> cacheline. Similarly out_cons and out_prod should be on the same
> cacheline, but on a different cacheline compared to in_cons and in_prod.
>
> So I should add padding between the two pairs of indices. Something
> like:
> uint8_t pad[cache_line_size - 8];
>
> Where cache_line_size is usually 64 bytes. So this would be:
>
> uint8_t pad[56];
>
> Is that right?
Sounds right. But pahole will for sure confirm :-) I was too lazy to copy this
in code and see
what it gives you.
>
>
> > > PVCALLS_RING_IDX out_cons, out_prod;
> > > int32_t in_error, out_error;
> > >
> > > uint32_t ring_order;
> > > grant_ref_t ref[];
> > > };
> >
> > That does not look like it would be to the power of two? Perhaps
> > some padding?
>
> I don't understand the suggestion about the padding here.
You pad[56] takes care of the issue I had.
..snipp.
> > > The binary layout of `struct pvcalls_data_intf` follows:
> > >
> > > 0 4 8 12162024
> > > 28
> > >
> > > +-+-+-+-+-+-+--+
> > > | in_cons | in_prod |out_cons |out_prod |in_error
> > > |out_error|ring_order|
> > >
> > > +-+-+-+-+-+-+--+
> > >
> > > 283236404092 4096
> > > +-+-+-+//---+-+
> > > | ref[0] | ref[1] | ref[2] | | ref[N] |
> > > +-+-+-+//---+-+
> >
> > Perhaps you can say:
> >
> > **N.B** For one page, the N would be 2034.
>
> I can do that but actually N would be (4096-28)/4 = 1017. Ring refs are
> 4 bytes each.
I somehow had uint16_t on my mind! Thanks for checking me!
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen
On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich wrote: On 12.10.16 at 17:42, wrote: >> On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich wrote: >> On 12.10.16 at 16:58, wrote: On 10/12/16 05:32 -0600, Jan Beulich wrote: On 12.10.16 at 12:33, wrote: >> The layout is shown as the following diagram. >> >> +---+---+---+--+--+ >> | whatever used | Partition | Super | Reserved | /dev/pmem0p1 | >> | by kernel| Table | Block | for Xen | | >> +---+---+---+--+--+ >> \_ ___/ >> V >> /dev/pmem0 > >I have to admit that I dislike this, for not being OS-agnostic. >Neither should there be any Xen-specific region, nor should the >"whatever used by kernel" one be restricted to just Linux. What >I could see is an OS-reserved area ahead of the partition table, >the exact usage of which depends on which OS is currently >running (and in the Xen case this might be both Xen _and_ the >Dom0 kernel, arbitrated by a tbd protocol). After all, when >running under Xen, the Dom0 may not have a need for as much >control data as it has when running on bare hardware, for it >controlling less (if any) of the actual memory ranges when Xen >is present. > Isn't this OS-reserved area still not OS-agnostic, as it requires OS to know where the reserved area is? Or do you mean it's not if it's defined by a protocol that is accepted by all OSes? >>> >>> The latter - we clearly won't get away without some agreement on >>> where to retrieve position and size of this area. I was simply >>> assuming that such a protocol already exists. >>> >> >> No, we should not mix the struct page reservation that the Dom0 kernel >> may actively use with the Xen reservation that the Dom0 kernel does >> not consume. Explain again what is wrong with the partition approach? > > Not sure what was unclear in my previous reply. I don't think there > should be apriori knowledge of whether Xen is (going to be) used on > a system, and even if it gets used, but just occasionally, it would > (apart from the abstract considerations already given) be a waste > of resources to set something aside that could be used for other > purposes while Xen is not running. Static partitioning should only be > needed for persistent data. > The reservation needs to be persistent / static even if the data is volatile, as is the case with struct page, because we can't have the size of the device change depending on use. So, from the aspect of wasting space while Xen is not in use, both partitions and the intrinsic reservation approach suffer the same problem. Setting that aside I don't want to mix 2 different use cases into the same reservation. The kernel needs to know about the struct page reservation because it needs to manage the lifetime of page references vs the lifetime of the device. It does not have the same relationship with a Xen reservation which is why I'm proposing they be managed separately. Note that Toshi and Mike added DM for DAX. This enabling ends up writing DM metadata on the device without adding new reservation mechanisms to the nvdimm core. I'm struggling to see how the Xen use case is materially different DM. In the end it's an application specific metadata space. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
On Wed, Oct 12, 2016 at 04:17:57PM +0200, Martin Pohlack wrote: > On 12.10.2016 15:44, Konrad Rzeszutek Wilk wrote: > > On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote: > > > > > > On 12.10.16 at 15:23, wrote: > > > > > And then - how is all of this supposed to be working in conjucntion > > > > > with live patching, where the patch may have been created by yet > > > > > another compiler version? > > > > > > > > Uh, I hope one does not create a livepatch patch with another compiler > > > > version! > > > > > > > > Let me put on the TODO to make livepatch-build-tools check gcc against > > > > compile.h so that one does not try this. > > > > > > What's wrong with mixing compiler versions in general? > > > > Besides scaring me? > > > > The one issue we had encountered was with compilers generating random named > > symbols for the switch tables. Those end up being called "CSWTCH.XYZ" > > where the XYZ depends on the position of the moon along with how many > > goats you have sacrificied to the altar of GCC gods. > > > > Older compilers don't neccessarily do it, newer ones do, and every time > > you build an livepatch the naming is different. Frustrating. > > > > It maybe that newer versions of GCC are more predictable about this > > naming. > > > > Maybe Martin can share some of his experience? CC-ing him. > > There are a couple of naming conventions for internal symbols and also > static symbols where you basically have to pray that gcc implementation does > not change. Interestingly, icc has some conventions that make those symbol > names a bit more stable. > > The tricky thing is matchmaking between the existing build and the new build > to construct the binary diff and to match up symbols for which you want to > provide replacement code. > > We use a reproducible build environment to construct hotpatches for an > existing build in the absolutely same environment (gcc version, lib > versions, gas version, binutils etc.). This sidesteps most of the problems. I think the matchmaking process does not solve per say some tricky CSWTCH issues. If a patch mucks with a switch statement (e.g. add a new case) we are pretty much guaranteed to get in trouble. And really a change in any control structure may cause gcc to take different code path, causing it to renumber CSWTCH. Or worst, renumber it to the one that the hypervisor is using for some other switch statements. I think the size of the symbol vs the one in the hypervisor is different so one can check for this. Bad things happen if it is the same size, but bcmp can come in handy there. Are there any ways to make GCC be predictable or some patches to make GCC be less random. Perhaps instead of XYZ it would use the function name.. P.S. GCC scares me because the code comes in these big patches with not much explanation on how it suppose to work. It probably is a piece of cake for folks who have been marinating in compilers but for a newbie like me it is hardcore black magic. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
