flight 32218 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32218/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303
Regressions which are
On Wed, Dec 10, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 08, 2014 at 11:18:05AM +0100, Olaf Hering wrote:
> > This is a resend of this series, with just the low hanging fruits:
> > http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html
> This looks like it would fix some of th
flight 3 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/3/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 8 guest-start fail REGR. vs. 31241
test-amd64-amd64-rump
Il 26/09/2014 14:02, David Vrabel ha scritto:
On 26/09/14 12:46, Fabio Fantoni wrote:
Il 26/09/2014 12:22, David Vrabel ha scritto:
On 26/09/14 09:54, Fabio Fantoni wrote:
Yesterday I updated wheezy kernel (3.2) to 3.14 from wheezy-backports to
solves one critical network problem with new wind
Hello,
On 11/12/2014 02:39, manish jaggi wrote:
I need your views how PCI passthrough / Non PCI passthrough code can
coexist with the two points mentioned above ?
It' s hard to answer to your question if you don't specify on which
version of the platform device passthrough you are based
Hello,
On 11/12/2014 02:27, manish jaggi wrote:
I am facing this issue when booting Xen Dom0 (OpenSuse Rootfs)
...
[ OK ] Reached target Host and Network Name Lookups.
[ OK ] Started OpenSSH Daemon.
[ TIME ] Timed out waiting for device dev-hvc0.device.
[DEPEND] Dependency failed for Seria
On Wed, 10 Dec 2014, manish jaggi wrote:
> Based on my experience with PCI passthrough code merging, below are
> some comments:
> Both require a change in code
>
> a) The current code which is non-pci passthrough requires a devices'
> device tree node to be associated with smmu node, if that devic
Please use clear subject line in the future. Currently it's not very
descriptive. Something like "Introduction of netsted HVM test case" is
better.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
... for the time being: The mechanism used depends on the domain's use
of the IRET hypercall.
Also drop two bogus code lines spotted while going through the involved
code paths: Addresses of per-CPU variables can't possibly be NULL, and
the setting of st->vcpu in send_guest_trap()'s MCE case is re
On 11/12/14 09:40, Fabio Fantoni wrote:
> Il 26/09/2014 14:02, David Vrabel ha scritto:
>> On 26/09/14 12:46, Fabio Fantoni wrote:
>>> Il 26/09/2014 12:22, David Vrabel ha scritto:
On 26/09/14 09:54, Fabio Fantoni wrote:
> Yesterday I updated wheezy kernel (3.2) to 3.14 from
> wheezy-b
On Wed, Dec 10, 2014 at 04:07:37PM +0800, longtao.pang wrote:
> From: "longtao.pang"
>
> This patch is used for preparing and installing L1 guest VM inside L0 system
> on testhost machine.
>
> ---
> Osstest/Debian.pm | 27 ++-
> Osstest/TestSupport.pm | 31 +
On 10/12/14 23:51, Andy Lutomirski wrote:
> On Wed, Dec 10, 2014 at 3:34 PM, Luis R. Rodriguez
>> --- a/arch/x86/kernel/entry_64.S
>> +++ b/arch/x86/kernel/entry_64.S
>> @@ -1170,7 +1170,23 @@ ENTRY(xen_do_hypervisor_callback) #
>> do_hypervisor_callback(struct *pt_regs)
>> popq %rsp
>>
On Thu, 2014-12-11 at 01:52 +, Mao Mingya wrote:
> >Yes, qemu can be used to provide PV backends for: disk (using qdisk),
> >framebuffer, kbd and mouse.
> Thank you for the detail explanation.
> What is the best pv backend on arch arm? qemu-upstream,
> qemu-xen-traditional, or anything else?
On Thu, 2014-12-11 at 09:27 +0530, Balbir Singh wrote:
Please don't top post.
> Good catch Ian!
>
> You are absolutely right!
Oh good.
> I built everything and it put the tools/etc
> in /usr/local. I did not see a link to xencommons, I missed it
> completely! Is there any thing else I should
On Wed, Dec 10, 2014 at 04:07:38PM +0800, longtao.pang wrote:
> From: "longtao.pang"
>
> This patch is used for building XEN and HVM Dom0 kernel for L1 guest VM,
> and then reboot L1 guest into xen kernel.
>
I think you can just use the L0 Xen and Dom0 kernel, that would save you
lots of time r
flight 32214 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32214/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 3 host-install(3) broken REGR. vs. 321
Co-REST-maintainers,
there are a couple of patches I'd like to ask for feedback on, and I'm
assuming (based on previous replies by him) Konrad is waiting for such
too before considering giving release-acks:
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00667.html
http://lists.xen
On 11/12/14 10:47, Jan Beulich wrote:
> ... for the time being: The mechanism used depends on the domain's use
> of the IRET hypercall.
>
> Also drop two bogus code lines spotted while going through the involved
> code paths: Addresses of per-CPU variables can't possibly be NULL, and
> the setting
On Wed, Dec 10, 2014 at 04:07:39PM +0800, longtao.pang wrote:
> From: "longtao.pang"
>
> This patch is used for installing L2 guest VM inside L1 guest VM.
>
> ---
> sg-run-job|2 +
> ts-debian-install | 166
> +
> 2 files changed
>>> On 10.12.14 at 10:53, wrote:
> On Wed, 2014-12-10 at 08:07 +, Jan Beulich wrote:
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -981,18 +981,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>>
>> case XEN_DOMCTL_irq_permission:
>> {
>> -unsigned int pirq
On Wed, Dec 10, 2014 at 04:07:40PM +0800, longtao.pang wrote:
> From: "longtao.pang"
>
> This patch is used for inserting nested test job name and runvars into
> standalone.db database after execute command './standalone-reset'.
>
> ---
> make-flight | 19 +++
> mfi-common |
On Fri, 2014-12-05 at 11:31 +, Jan Beulich wrote:
> Andrew validly points out that even if these masks aren't a formal part
> of the hypercall interface, we aren't free to change them: A guest
> suspended for migration in the middle of a continuation would fail to
> work if resumed on a hypervi
On Thu, 11 Dec 2014, Olaf Hering wrote:
On Wed, Dec 10, Konrad Rzeszutek Wilk wrote:
On Mon, Dec 08, 2014 at 11:18:05AM +0100, Olaf Hering wrote:
This is a resend of this series, with just the low hanging fruits:
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html
This
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
stable/for-linus-3.19-rc0-tag
xen: features and fixes for 3.19-rc0
- - Fully support non-coherent devices on ARM by introducing the
mechanisms t
On Thu, Dec 11, M A Young wrote:
> Yes, you do need to set explicit selinux permissions when mounting
> /var/lib/xenstored as otherwise it gets a tmpfs selinux context which
> xenstored can't use in enforcing mode.
Is that "enforcing mode" the default? And would it be too cumbersome to
have these
At 11:55 +0800 on 06 Dec (1417863337), Yu Zhang wrote:
> From: Yu Zhang
>
> A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
> the write operations on GPU's page tables. Handling of this new
> p2m type are similar with existing p2m_ram_ro in most condition
> checks, with only diffe
On Thu, Dec 11, Olaf Hering wrote:
> This sounds like xenstored has to parse the possible environment
> variables found in sysconfig.xencommons all by itself? Is there perhaps
> a way out of the SELinux jail?
Does all that work with the sysv runlevel scripts?
Olaf
__
On Fri, 2014-12-05 at 14:51 +, Ian Campbell wrote:
> On Fri, 2014-12-05 at 14:48 +, Jan Beulich wrote:
> > >>> On 05.12.14 at 15:27, wrote:
> > > On Fri, 2014-12-05 at 13:51 +, Jan Beulich wrote:
> > >> #define nr_static_irqs NR_IRQS
> > >> +#define arch_hwdom_irqs(domid) NR_IRQS
> >
On Tue, 2014-12-09 at 17:34 +, Jan Beulich wrote:
> ... when "conring_size=" was specified on the command line. We can't
> really do this as early as we would want to when the option was not
> specified, as the default depends on knowing the system CPU count. Yet
> the parsing of the ACPI table
Hi Samuel,
Comments and updated patch below.
samuel.thiba...@ens-lyon.org said:
> > -if (rx->flags & NETRXF_extra_info)
> > -{
> > -printk("+ we have extras!\n");
> > -continue;
> > -}
> > -
> > -
> > -if (rx->status == N
On Wed, Dec 10, 2014 at 07:09:57PM +0100, Dario Faggioli wrote:
> and store them in $c{Stash}, in a file named according
> to the following convention:
>
> $hostname--$benchname-$benchparams
>
> i.e., something like this:
>
> debian--unixbench-i3-c2
>
> Signed-off-by: Dario Faggioli
> Cc: We
On Wed, Dec 10, 2014 at 07:09:18PM +0100, Dario Faggioli wrote:
> From: Dario Faggioli
>
> the value of which can be retrieved via guest_var('memory');.
>
> This works for both PV and HVM Debian guests.
>
> Signed-off-by: Dario Faggioli
> Cc: Wei Liu
> Cc: Ian Campbell
> Cc: Ian Jackson
> -
On 11/12/14 05:32, Juergen Gross wrote:
> On 12/10/2014 07:07 PM, David Vrabel wrote:
>> On 10/12/14 15:56, Juergen Gross wrote:
>>> With the virtual mapped linear p2m list the post-init mmu operations
>>> must be used for setting up the p2m mappings, as in case of
>>> CONFIG_FLATMEM the init routi
On 11/12/14 05:32, Juergen Gross wrote:
> On 12/10/2014 07:07 PM, David Vrabel wrote:
>> On 10/12/14 15:56, Juergen Gross wrote:
>>> With the virtual mapped linear p2m list the post-init mmu operations
>>> must be used for setting up the p2m mappings, as in case of
>>> CONFIG_FLATMEM the init routi
On Wed, Dec 10, 2014 at 07:10:06PM +0100, Dario Faggioli wrote:
> From: Dario Faggioli
>
> Mangle the results of a run of unixbench a bit, so that
> they can be plotted. This also produces a (gnu)plot script
> and the plot itself. All is saved in $stash, for the
> running flight and job.
>
>
>
At 10:09 +0530 on 09 Dec (1418116195), vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> In pl011.c, when TX interrupt is received
> serial_tx_interrupt() is called to push next
> characters. If TX buffer is empty, serial_tx_interrupt()
> does not disable TX interrupt and hence pl011 UART
On Tue, 2014-12-09 at 10:09 +0530, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> In pl011.c, when TX interrupt is received
> serial_tx_interrupt() is called to push next
> characters. If TX buffer is empty, serial_tx_interrupt()
> does not disable TX interrupt and hence pl011 UART
> ir
On Thu, 11 Dec 2014, Olaf Hering wrote:
On Thu, Dec 11, Olaf Hering wrote:
This sounds like xenstored has to parse the possible environment
variables found in sysconfig.xencommons all by itself? Is there perhaps
a way out of the SELinux jail?
Does all that work with the sysv runlevel scrip
On Wed, Dec 10, 2014 at 07:11:52PM +0100, Dario Faggioli wrote:
[...]
> +
> + logm("Will run the benchmark on host with: $bcpus vcpus and $bmem MB RAM");
> +
> + my $kernver= get_runvar('kernel_ver',$r{'kernbuildjob'});
> + my $kopt= "maxcpus=$bcpus mem=$bmem" . "M";
> +
> + if ($ho->{Flags}{'n
At 11:31 + on 05 Dec (1417775465), Jan Beulich wrote:
> Andrew validly points out that even if these masks aren't a formal part
> of the hypercall interface, we aren't free to change them: A guest
> suspended for migration in the middle of a continuation would fail to
> work if resumed on a hyp
On Thu, 2014-12-11 at 12:05 +, Wei Liu wrote:
> On Wed, Dec 10, 2014 at 07:09:18PM +0100, Dario Faggioli wrote:
> > diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> > index a3b6936..cdff8d5 100644
> > --- a/Osstest/TestSupport.pm
> > +++ b/Osstest/TestSupport.pm
> > @@ -1460,11 +1
On Thu, 2014-12-11 at 12:09 +, Wei Liu wrote:
> On Wed, Dec 10, 2014 at 07:09:57PM +0100, Dario Faggioli wrote:
> > ---
> > ts-unixbench-reslts | 67
> > +++
>
> Typo "reslts" (also in subject line).
>
Yes, it's like that everywhere. In fact,
At 10:47 + on 11 Dec (1418291241), Jan Beulich wrote:
> ... for the time being: The mechanism used depends on the domain's use
> of the IRET hypercall.
Can you elaborate? Looking at the existing code it seems like what it
does is set v->nmi_pending and make sure the vcpu gets scheduled
approp
On Thu, Dec 11, 2014 at 01:57:59PM +0100, Dario Faggioli wrote:
> On Thu, 2014-12-11 at 12:05 +, Wei Liu wrote:
> > On Wed, Dec 10, 2014 at 07:09:18PM +0100, Dario Faggioli wrote:
> > > diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> > > index a3b6936..cdff8d5 100644
> > > --- a/
>>> On 11.12.14 at 14:00, wrote:
> At 10:47 + on 11 Dec (1418291241), Jan Beulich wrote:
>> ... for the time being: The mechanism used depends on the domain's use
>> of the IRET hypercall.
>
> Can you elaborate? Looking at the existing code it seems like what it
> does is set v->nmi_pending
At 02:03 + on 11 Dec (1418259797), Tian, Kevin wrote:
> > From: Tim Deegan [mailto:t...@xen.org]
> > Now since the code's not going to be in 4.5 anyway, it should be
> > possible to _develop_ it in this manner, possibly in a private branch,
> > even if the early stages aren't getting applied im
On Thu, 2014-12-11 at 12:15 +, Wei Liu wrote:
> On Wed, Dec 10, 2014 at 07:10:06PM +0100, Dario Faggioli wrote:
> > This is done in a new Osstest/Benchmarking.pm module, as
> > the functions introduced may turn out useful somewhere else
> > too.
> >
>
> I would suggest using a dedicated comm
On Thu, Dec 11, 2014 at 02:11:44PM +0100, Dario Faggioli wrote:
[...]
> > > +sub unixbench_plot_results ($$$) {
> > > + my ($dataf,$num_cols,$pfile)= @_;
> > > + my $h= new IO::File "> $pfile.gp" or die "$!";
> > > +
> > > + printf $h < > > +set terminal png enhanced font
> > > "/usr/share/font
At 13:09 + on 11 Dec (1418299748), Jan Beulich wrote:
> >>> On 11.12.14 at 14:00, wrote:
> > At 10:47 + on 11 Dec (1418291241), Jan Beulich wrote:
> >> ... for the time being: The mechanism used depends on the domain's use
> >> of the IRET hypercall.
> >
> > Can you elaborate? Looking at
>>> On 11.12.14 at 13:07, wrote:
> On Fri, 2014-12-05 at 14:51 +, Ian Campbell wrote:
>> On Fri, 2014-12-05 at 14:48 +, Jan Beulich wrote:
>> > >>> On 05.12.14 at 15:27, wrote:
>> > > On Fri, 2014-12-05 at 13:51 +, Jan Beulich wrote:
>> > >> #define nr_static_irqs NR_IRQS
>> > >> +#d
On Wed, 2014-12-10 at 19:11 +0100, Dario Faggioli wrote:
> From: Dario Faggioli
>
Mmm... It's quite weird that some of the patches came out with this
'From:' tag with my pvt address. I guess I've messed up something with
the git/stgit configuration on the box from where I sent this.
Will fix, pl
>>> On 11.12.14 at 14:16, wrote:
> At 13:09 + on 11 Dec (1418299748), Jan Beulich wrote:
>> >>> On 11.12.14 at 14:00, wrote:
>> > At 10:47 + on 11 Dec (1418291241), Jan Beulich wrote:
>> >> ... for the time being: The mechanism used depends on the domain's use
>> >> of the IRET hypercall.
On Wed, 2014-12-10 at 19:12 +0100, Dario Faggioli wrote:
> From: Dario Faggioli
>
Somehow, this patch lacks a changelog! :-O
Sorry about this too, I'll write one for next version.
Regards,
Dario
> Signed-off-by: Dario Faggioli
> Cc: Wei Liu
> Cc: Ian Campbell
> Cc: Ian Jackson
> ---
> Oss
On Thu, 2014-12-11 at 12:32 +, Wei Liu wrote:
> On Wed, Dec 10, 2014 at 07:11:52PM +0100, Dario Faggioli wrote:
> > + logm("Will run the benchmark on host with: $bcpus vcpus and $bmem MB
> > RAM");
> > +
> > + my $kernver= get_runvar('kernel_ver',$r{'kernbuildjob'});
> > + my $kopt= "maxcp
flight 32215 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32215/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken REGR. vs. 32126
test
>>> On 11.12.14 at 13:04, wrote:
> At 11:55 +0800 on 06 Dec (1417863337), Yu Zhang wrote:
>> From: Yu Zhang
>>
>> A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
>> the write operations on GPU's page tables. Handling of this new
>> p2m type are similar with existing p2m_ram_ro in
>>> On 11.12.14 at 00:34, wrote:
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4239,6 +4239,16 @@ int __sched _cond_resched(void)
> }
> EXPORT_SYMBOL(_cond_resched);
>
> +int __sched cond_resched_irq(void)
> +{
> + if (should_resched()) {
> + preempt_schedule_ir
Signed-off-by: Vitaly Kuznetsov
---
xen/common/domctl.c | 6 ++
xen/include/xsm/dummy.h | 6 ++
xen/include/xsm/xsm.h | 6 ++
xen/xsm/dummy.c | 1 +
xen/xsm/flask/hooks.c | 17 +
xen/xsm/fl
New dying state is requred to indicate that a particular domain
is dying but cleanup procedure wasn't started. This state can be
set from outside of domain_kill().
Signed-off-by: Vitaly Kuznetsov
---
xen/common/domain.c | 1 +
xen/include/xen/sched.h | 3 ++-
2 files changed, 3 insertions(+)
Add new xc_domain_soft_reset() function which performs so-called 'soft reset'
for an HVM domain. It is being performed in the following way:
- Save HVM context and all HVM params;
- Devour original domain with XEN_DOMCTL_devour;
- Wait till original domain dies or has no pages left;
- Restore HVM c
New operation sets the 'recipient' domain which will receive all
memory pages from a particular domain and kills the original domain.
Signed-off-by: Vitaly Kuznetsov
---
xen/common/domain.c | 3 +++
xen/common/domctl.c | 33 +
xen/common/page_allo
Introduce new xc_domain_devour() function to support XEN_DOMCTL_devour.
Signed-off-by: Vitaly Kuznetsov
---
tools/libxc/include/xenctrl.h | 14 ++
tools/libxc/xc_domain.c | 13 +
2 files changed, 27 insertions(+)
diff --git a/tools/libxc/include/xenctrl.h b/tools/l
New libxl__domain_soft_reset_destroy() is an internal-only
version of libxl_domain_destroy() which follows the same domain
destroy path with the only difference: xc_domain_destroy() is
being avoided so the domain is not actually being destroyed.
Add soft_reset flag to libxl__domain_destroy_state s
Use letter 't' to indicate a domain in such state.
Signed-off-by: Vitaly Kuznetsov
---
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c | 2 +-
tools/python/xen/lowlevel/xl/xl.c | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_types
Signed-off-by: Vitaly Kuznetsov
---
xen/common/shutdown.c | 7 +++
xen/include/public/sched.h | 3 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
index 94d4c53..5c3a158 100644
--- a/xen/common/shutdown.c
+++ b/xen/common/sh
mar...@lucina.net said:
> Rather, shouldn't the final if() in the loop (where data is sent up) be:
>
> if(rx->status > NETIF_RSP_NULL) { ... }
>
> *we can't use NETIF_RSP_OKAY as NETIF_RSP_NULL is defined to be 1 (yuck).
>
> I don't see any value in keeping the printk(), the netfront driver al
On Wed, Dec 03, Vitaly Kuznetsov wrote:
> When a PVHVM linux guest performs kexec there are lots of things which
> require taking care of:
> - shared info, vcpu_info
> - grants
> - event channels
> - ...
> Instead of taking care of all these things we can rebuild the domain
> performing kexec from
This patch series provides x86 PVHVM domains with an ability to perform
kexec/kdump.
Changes from v4:
- "on_soft_reset" option was introduced, now it's possible to specify the
behavior
[Wei Liu]
- renamed libxl__domain_soft_reset_destroy_old to
libxl__domain_soft_reset_destroy
- libxl__domain_
Perform soft reset when a domain did SHUTDOWN_soft_reset. Migrate the
content with xc_domain_soft_reset(), reload dm and toolstack.
Signed-off-by: Vitaly Kuznetsov
---
docs/man/xl.cfg.pod.5| 12 +
tools/libxl/libxl.h | 6 +++
tools/libxl/libxl_create.c | 103 +++
Xen: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114
Dom0: 3.17.4
We recently moved our dom0 from 3.10.x to 3.17.4, in order to avoid a netback
host crash that has been plaguing us. After doing so, the new multi-queue
netback stuff constantly on/offs carrier on the vif, spamming the con
Hi,
This has been fixed by "f48da8: xen-netback: fix unlimited guest Rx
internal queue and carrier flapping", it's already in 3.18, I don't know
if it is going to be backported to 3.17
Zoli
On 11/12/14 14:42, Christopher S. Aker wrote:
Xen: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, x
Xen: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114
Dom0: 3.17.4
Things go badly after a day or four. We've hit this on a number of previously
healthy hosts, since moving from 3.10.x dom0 to 3.17.4:
printk: 5441 messages suppressed.
grant_table.c:567:d0 Failed to obtain maptrack handle
Wei,
> > So instead of a bunch of vifx.y's I would see x.y ?
> Check out
> http://xenbits.xen.org/docs/4.4-testing/misc/xl-network-configuration.html
> vifname
Sorry must have overlooked that, thank you!
-Bjoern
___
Xen-devel mailing list
Xen-devel@li
On December 11, 2014 6:39:07 AM EST, Jan Beulich wrote:
>Co-REST-maintainers,
>
>there are a couple of patches I'd like to ask for feedback on, and I'm
>assuming (based on previous replies by him) Konrad is waiting for such
>too before considering giving release-acks:
>
I believe these two alread
On 11/12/14 14:24, Olaf Hering wrote:
> On Wed, Dec 03, Vitaly Kuznetsov wrote:
>
>> When a PVHVM linux guest performs kexec there are lots of things which
>> require taking care of:
>> - shared info, vcpu_info
>> - grants
>> - event channels
>> - ...
>> Instead of taking care of all these things
On Thu, Dec 11, David Vrabel wrote:
> Nothing special needs to be done with ballooned pages. If frames are
> not populated in the original domain, they will be unpopulated in the
> new domain.
>
> It's the responsibility of the guest to ensure it either doesn't kexec
> when it is ballooned or th
>>> On 11.12.14 at 16:18, wrote:
> On December 11, 2014 6:39:07 AM EST, Jan Beulich wrote:
>>Either
>>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00260.html
>>or (my preference)
>>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01054.html
>>
>
> Daniel's patch
On Tue, Dec 09, 2014 at 03:56:02PM +, Ian Campbell wrote:
> On Tue, 2014-12-09 at 15:39 +, Anthony PERARD wrote:
> > The path to the pty of a Xen PV console is set only in
> > virDomainOpenConsole. But this is done too late. A call to
> > virDomainGetXMLDesc done before OpenConsole will not
On Thu, 2014-12-11 at 16:16 +, Anthony PERARD wrote:
> On Tue, Dec 09, 2014 at 03:56:02PM +, Ian Campbell wrote:
> > On Tue, 2014-12-09 at 15:39 +, Anthony PERARD wrote:
> > > The path to the pty of a Xen PV console is set only in
> > > virDomainOpenConsole. But this is done too late. A
On Mon, Sep 22, 2014 at 6:59 AM, Wen Congyang wrote:
> If we use blktap2, the correct file should be blktap device
> not the pdev_path.
>
> Signed-off-by: Wen Congyang
> Cc: Shriram Rajagopalan
> Acked-by: Ian Campbell
If I'm reading this correctly, this is actually a fairly serious bug
in lib
Hi,
At 01:41 + on 11 Dec (1418258504), Tian, Kevin wrote:
> > From: Tim Deegan [mailto:t...@xen.org]
> > It is Xen's job to isolate VMs from each other. As part of that, Xen
> > uses the MMU, nested paging, and IOMMUs to control access to RAM. Any
> > software component that can pass a raw
On Thu, Dec 11, 2014 at 04:23:15PM +, Ian Campbell wrote:
> On Thu, 2014-12-11 at 16:16 +, Anthony PERARD wrote:
> > On Tue, Dec 09, 2014 at 03:56:02PM +, Ian Campbell wrote:
> > > On Tue, 2014-12-09 at 15:39 +, Anthony PERARD wrote:
> > > > The path to the pty of a Xen PV console i
On 12/11/2014 06:44 AM, Jan Beulich wrote:
On 10.12.14 at 10:53, wrote:
On Wed, 2014-12-10 at 08:07 +, Jan Beulich wrote:
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -981,18 +981,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
case XEN_DOMCTL_irq_permission:
{
-
flight 32227 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32227/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 3 host-install(3) broken in 32162 REGR. vs. 318
On 11 December 2014 at 02:30, Stefano Stabellini
wrote:
> On Wed, 10 Dec 2014, manish jaggi wrote:
>> Based on my experience with PCI passthrough code merging, below are
>> some comments:
>> Both require a change in code
>>
>> a) The current code which is non-pci passthrough requires a devices'
>>
The header include/xen/interface/xen.h doesn't contain all definitions
from Xen's version of that header. Update it accordingly.
Signed-off-by: Juergen Gross
---
arch/x86/xen/trace.c| 2 +-
include/xen/interface/xen.h | 6 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --g
Instead of manually list each hypercall in arch/x86/xen/xen-head.S
use the auto generated symbol list.
This also corrects the wrong address of xen_hypercall_mca which was
located 32 bytes higher than it should.
Symbol addresses have been verified to match the correct ones via
objdump output.
Bas
Today there are several places in the kernel which build tables
containing one entry for each possible Xen hypercall. Create an
infrastructure to be able to generate these tables at build time.
Based-on-patch-by: Jan Beulich
Signed-off-by: Juergen Gross
---
arch/x86/syscalls/Makefile | 9 +
Instead of manually list all hypervisor calls in arch/x86/xen/trace.c
use the auto generated list.
Signed-off-by: Juergen Gross
---
arch/x86/xen/trace.c | 50 --
1 file changed, 4 insertions(+), 46 deletions(-)
diff --git a/arch/x86/xen/trace.c b/
The Xen hypercalls are defined in include/xen/interface/xen.h. There
are some places where for each hypercall a table element is created.
Instead of manually add each hypercall element to these tables use
an auto generated header built during the make process of the kernel.
Juergen Gross (4):
xe
On Wed, Dec 10, 2014 at 10:29:46AM +, Jan Beulich wrote:
> >>> On 10.12.14 at 07:00, wrote:
> > On Thu, Nov 06, 2014 at 09:27:59PM +, Andrew Cooper wrote:
> >> On 06/11/2014 19:32, Konrad Rzeszutek Wilk wrote:
> >> > On Thu, Nov 06, 2014 at 03:07:10PM +, Paul Durrant wrote:
> >> >> To
On Wed, Dec 10, 2014 at 10:36:18AM +, Andrew Cooper wrote:
> On 10/12/14 06:00, Matt Wilson wrote:
> >
> > That's not strictly true. You can use the processor index in ACPI.
>
> The LAPIC objects in the MADT/APIC table? That is still constructed
> with the broken LAPIC_ID = 2 * processor_id l
On 12/10/2014 05:03 PM, Luis R. Rodriguez wrote:
>
> This is an issue onloy for for non*-preemptive kernels.
>
> Some of Xen's hypercalls can take a long time and unfortunately for
> *non*-preemptive kernels this can be quite a bit of an issue.
> We've handled situations like this with cond_resch
On 11/12/14 18:19, Matt Wilson wrote:
> On Wed, Dec 10, 2014 at 10:36:18AM +, Andrew Cooper wrote:
>> On 10/12/14 06:00, Matt Wilson wrote:
>>> That's not strictly true. You can use the processor index in ACPI.
>> The LAPIC objects in the MADT/APIC table? That is still constructed
>> with the
Hello Manish,
On 11/12/14 18:02, manish jaggi wrote:
> On 11 December 2014 at 02:30, Stefano Stabellini
> wrote:
>> On Wed, 10 Dec 2014, manish jaggi wrote:
>>> Based on my experience with PCI passthrough code merging, below are
>>> some comments:
>>> Both require a change in code
>>>
>>> a) The
On Thu, Dec 11, 2014 at 01:04:24PM +0100, Olaf Hering wrote:
> On Thu, Dec 11, M A Young wrote:
>
> > Yes, you do need to set explicit selinux permissions when mounting
> > /var/lib/xenstored as otherwise it gets a tmpfs selinux context which
> > xenstored can't use in enforcing mode.
>
> Is that
flight 32232 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32232/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 5 kernel-build fail REGR. vs. 32194
Regressions which a
On Thu, Dec 11, Konrad Rzeszutek Wilk wrote:
> I wonder if we can detect the context during build-time (an autoconf function
> that checks whether the build is done for Fedora?)
> But what if the version of Fedora is different and the object is called
> something else?
Exactly. The build host is
On Thu, Dec 11, 2014 at 03:38:39PM +, Jan Beulich wrote:
> >>> On 11.12.14 at 16:18, wrote:
> > On December 11, 2014 6:39:07 AM EST, Jan Beulich wrote:
> >>Either
> >>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00260.html
> >>or (my preference)
> >>http://lists.xenproject.
Monday, December 15, will be our last Document Day of the year.
Given the 4.5 RC4 Testing scheduled for Wednesday of next week and the holidays
which occur later in the month, we have scheduled Document Day for Monday.
This is a great time to get our documentation ready for the new
release. Have
1 - 100 of 118 matches
Mail list logo