On 01/11/2013 01:08 PM, Vivek Goyal wrote:
A signed /sbin/kexec would realistically have to be statically linked,
at least in the short term; otherwise the libraries and ld.so would need
verification as well.
Yes. That's the expectation. Sign only statically linked exeutables which
don't do
On Fri, Jan 11, 2013 at 01:03:41PM -0800, H. Peter Anvin wrote:
> On 01/11/2013 12:52 PM, Vivek Goyal wrote:
> >
> > Eric,
> >
> > In a private conversation, David Howells suggested why not pass kernel
> > signature in a segment to kernel and kernel can do the verification.
> >
> > /sbin/kexec
On 01/11/2013 12:52 PM, Vivek Goyal wrote:
>
> Eric,
>
> In a private conversation, David Howells suggested why not pass kernel
> signature in a segment to kernel and kernel can do the verification.
>
> /sbin/kexec signature is verified by kernel at exec() time. Then
> /sbin/kexec just passes
On Fri, Jan 11, 2013 at 12:26:56PM -0800, Eric W. Biederman wrote:
[..]
> Recently there is a desire to figure out how to /sbin/kexec support
> signed kernel images. What will probably happen is to have a specially
> trusted userspace application perform the verification. Sort of like
> dom0
On Fri, Jan 11, 2013 at 12:26:48PM -0800, H. Peter Anvin wrote:
> >
> >And there is nothing fancy to be done for EFI and SecureBoot? Or is
> >that something that the kernel has to handle on its own (so somehow
> >passing some certificates to somewhere).
> >
>
> For EFI, no... other than passing
And there is nothing fancy to be done for EFI and SecureBoot? Or is
that something that the kernel has to handle on its own (so somehow
passing some certificates to somewhere).
For EFI, no... other than passing the EFI parameters, which apparently
is *not* currently done (David Woodhouse is
Konrad Rzeszutek Wilk writes:
> On Thu, Jan 10, 2013 at 08:16:48PM -0800, Eric W. Biederman wrote:
>> The basic kexec interface is.
>>
>> load ranges of virtual addresses physical addresses.
>> jump to the physical address with identity mapped page tables.
>>
>> There are a few flags to
David Vrabel writes:
> On 11/01/13 13:22, Daniel Kiper wrote:
>> On Thu, Jan 10, 2013 at 02:19:55PM +, David Vrabel wrote:
>>> On 04/01/13 17:01, Daniel Kiper wrote:
My .5 cents:
- We should focus on KEXEC_CMD_kexec_load and KEXEC_CMD_kexec_unload;
probably we should
On Fri, Jan 11, 2013 at 03:22:35PM +, David Vrabel wrote:
> On 11/01/13 13:22, Daniel Kiper wrote:
> > On Thu, Jan 10, 2013 at 02:19:55PM +, David Vrabel wrote:
> >> On 04/01/13 17:01, Daniel Kiper wrote:
> >>> My .5 cents:
> >>> - We should focus on KEXEC_CMD_kexec_load and
On Thu, Jan 10, 2013 at 08:16:48PM -0800, Eric W. Biederman wrote:
> Konrad Rzeszutek Wilk writes:
>
> > On Mon, Jan 07, 2013 at 01:34:04PM +0100, Daniel Kiper wrote:
> >> I think that new kexec hypercall function should mimics kexec syscall.
> >> It means that all arguments passed to hypercall
On 11/01/13 13:22, Daniel Kiper wrote:
> On Thu, Jan 10, 2013 at 02:19:55PM +, David Vrabel wrote:
>> On 04/01/13 17:01, Daniel Kiper wrote:
>>> My .5 cents:
>>> - We should focus on KEXEC_CMD_kexec_load and KEXEC_CMD_kexec_unload;
>>> probably we should introduce KEXEC_CMD_kexec_load2
On Mon, Jan 07, 2013 at 01:49:44PM +, Ian Campbell wrote:
> On Mon, 2013-01-07 at 12:34 +, Daniel Kiper wrote:
> > I think that new kexec hypercall function should mimics kexec syscall.
>
> We want to have an interface can be used by non-Linux domains (both dom0
> and domU) as well
On Thu, Jan 10, 2013 at 02:19:55PM +, David Vrabel wrote:
> On 04/01/13 17:01, Daniel Kiper wrote:
> > On Fri, Jan 04, 2013 at 02:38:44PM +, David Vrabel wrote:
> >> On 04/01/13 14:22, Daniel Kiper wrote:
> >>> On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
> On
On Thu, Jan 10, 2013 at 02:19:55PM +, David Vrabel wrote:
On 04/01/13 17:01, Daniel Kiper wrote:
On Fri, Jan 04, 2013 at 02:38:44PM +, David Vrabel wrote:
On 04/01/13 14:22, Daniel Kiper wrote:
On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
On 27/12/12 18:02, Eric
On Mon, Jan 07, 2013 at 01:49:44PM +, Ian Campbell wrote:
On Mon, 2013-01-07 at 12:34 +, Daniel Kiper wrote:
I think that new kexec hypercall function should mimics kexec syscall.
We want to have an interface can be used by non-Linux domains (both dom0
and domU) as well though, so
On 11/01/13 13:22, Daniel Kiper wrote:
On Thu, Jan 10, 2013 at 02:19:55PM +, David Vrabel wrote:
On 04/01/13 17:01, Daniel Kiper wrote:
My .5 cents:
- We should focus on KEXEC_CMD_kexec_load and KEXEC_CMD_kexec_unload;
probably we should introduce KEXEC_CMD_kexec_load2 and
On Thu, Jan 10, 2013 at 08:16:48PM -0800, Eric W. Biederman wrote:
Konrad Rzeszutek Wilk konrad.w...@oracle.com writes:
On Mon, Jan 07, 2013 at 01:34:04PM +0100, Daniel Kiper wrote:
I think that new kexec hypercall function should mimics kexec syscall.
It means that all arguments passed
On Fri, Jan 11, 2013 at 03:22:35PM +, David Vrabel wrote:
On 11/01/13 13:22, Daniel Kiper wrote:
On Thu, Jan 10, 2013 at 02:19:55PM +, David Vrabel wrote:
On 04/01/13 17:01, Daniel Kiper wrote:
My .5 cents:
- We should focus on KEXEC_CMD_kexec_load and KEXEC_CMD_kexec_unload;
David Vrabel david.vra...@citrix.com writes:
On 11/01/13 13:22, Daniel Kiper wrote:
On Thu, Jan 10, 2013 at 02:19:55PM +, David Vrabel wrote:
On 04/01/13 17:01, Daniel Kiper wrote:
My .5 cents:
- We should focus on KEXEC_CMD_kexec_load and KEXEC_CMD_kexec_unload;
probably we
Konrad Rzeszutek Wilk konrad.w...@oracle.com writes:
On Thu, Jan 10, 2013 at 08:16:48PM -0800, Eric W. Biederman wrote:
The basic kexec interface is.
load ranges of virtual addresses physical addresses.
jump to the physical address with identity mapped page tables.
There are a few
And there is nothing fancy to be done for EFI and SecureBoot? Or is
that something that the kernel has to handle on its own (so somehow
passing some certificates to somewhere).
For EFI, no... other than passing the EFI parameters, which apparently
is *not* currently done (David Woodhouse is
On Fri, Jan 11, 2013 at 12:26:48PM -0800, H. Peter Anvin wrote:
And there is nothing fancy to be done for EFI and SecureBoot? Or is
that something that the kernel has to handle on its own (so somehow
passing some certificates to somewhere).
For EFI, no... other than passing the EFI
On Fri, Jan 11, 2013 at 12:26:56PM -0800, Eric W. Biederman wrote:
[..]
Recently there is a desire to figure out how to /sbin/kexec support
signed kernel images. What will probably happen is to have a specially
trusted userspace application perform the verification. Sort of like
dom0 for
On 01/11/2013 12:52 PM, Vivek Goyal wrote:
Eric,
In a private conversation, David Howells suggested why not pass kernel
signature in a segment to kernel and kernel can do the verification.
/sbin/kexec signature is verified by kernel at exec() time. Then
/sbin/kexec just passes one
On Fri, Jan 11, 2013 at 01:03:41PM -0800, H. Peter Anvin wrote:
On 01/11/2013 12:52 PM, Vivek Goyal wrote:
Eric,
In a private conversation, David Howells suggested why not pass kernel
signature in a segment to kernel and kernel can do the verification.
/sbin/kexec signature is
On 01/11/2013 01:08 PM, Vivek Goyal wrote:
A signed /sbin/kexec would realistically have to be statically linked,
at least in the short term; otherwise the libraries and ld.so would need
verification as well.
Yes. That's the expectation. Sign only statically linked exeutables which
don't do
Konrad Rzeszutek Wilk writes:
> On Mon, Jan 07, 2013 at 01:34:04PM +0100, Daniel Kiper wrote:
>> I think that new kexec hypercall function should mimics kexec syscall.
>> It means that all arguments passed to hypercall should have same types
>> if it is possible or if it is not possible then
On 04/01/13 17:01, Daniel Kiper wrote:
> On Fri, Jan 04, 2013 at 02:38:44PM +, David Vrabel wrote:
>> On 04/01/13 14:22, Daniel Kiper wrote:
>>> On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
On 27/12/12 18:02, Eric W. Biederman wrote:
> Andrew Cooper writes:
>
Konrad Rzeszutek Wilk konrad.w...@oracle.com writes:
On Mon, Jan 07, 2013 at 01:34:04PM +0100, Daniel Kiper wrote:
I think that new kexec hypercall function should mimics kexec syscall.
It means that all arguments passed to hypercall should have same types
if it is possible or if it is not
On 04/01/13 17:01, Daniel Kiper wrote:
On Fri, Jan 04, 2013 at 02:38:44PM +, David Vrabel wrote:
On 04/01/13 14:22, Daniel Kiper wrote:
On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
On 27/12/12 18:02, Eric W. Biederman wrote:
Andrew Cooperandrew.coop...@citrix.com
On Mon, Jan 07, 2013 at 01:34:04PM +0100, Daniel Kiper wrote:
> On Fri, Jan 04, 2013 at 02:11:46PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
> > > On Fri, Jan 04, 2013 at 02:41:17PM +, Jan Beulich wrote:
> > > > >>> On 04.01.13 at
On Mon, 2013-01-07 at 12:34 +, Daniel Kiper wrote:
> I think that new kexec hypercall function should mimics kexec syscall.
We want to have an interface can be used by non-Linux domains (both dom0
and domU) as well though, so please bear this in mind.
Historically we've not always been good
On Fri, Jan 04, 2013 at 02:11:46PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
> > On Fri, Jan 04, 2013 at 02:41:17PM +, Jan Beulich wrote:
> > > >>> On 04.01.13 at 15:22, Daniel Kiper wrote:
> > > > On Wed, Jan 02, 2013 at 11:26:43AM
On Mon, 2013-01-07 at 10:46 +, Andrew Cooper wrote:
> Given that /sbin/kexec creates a binary blob in memory, surely the most
> simple thing is to get it to suitably mlock() the region and give a list
> of VAs to the hypervisor.
More than likely. The DOMID_KEXEC thing was just a radon
On 07/01/13 10:25, Ian Campbell wrote:
On Fri, 2013-01-04 at 19:11 +, Konrad Rzeszutek Wilk wrote:
On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
Because current KEXEC_CMD_kexec_load does not load kernel
image and other things into Xen memory. It means that it
should live
On Fri, 2013-01-04 at 19:11 +, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
> > On Fri, Jan 04, 2013 at 02:41:17PM +, Jan Beulich wrote:
> > > >>> On 04.01.13 at 15:22, Daniel Kiper wrote:
> > > > On Wed, Jan 02, 2013 at 11:26:43AM +,
On Fri, 2013-01-04 at 19:11 +, Konrad Rzeszutek Wilk wrote:
On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
On Fri, Jan 04, 2013 at 02:41:17PM +, Jan Beulich wrote:
On 04.01.13 at 15:22, Daniel Kiper daniel.ki...@oracle.com wrote:
On Wed, Jan 02, 2013 at 11:26:43AM
On 07/01/13 10:25, Ian Campbell wrote:
On Fri, 2013-01-04 at 19:11 +, Konrad Rzeszutek Wilk wrote:
On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
Because current KEXEC_CMD_kexec_load does not load kernel
image and other things into Xen memory. It means that it
should live
On Mon, 2013-01-07 at 10:46 +, Andrew Cooper wrote:
Given that /sbin/kexec creates a binary blob in memory, surely the most
simple thing is to get it to suitably mlock() the region and give a list
of VAs to the hypervisor.
More than likely. The DOMID_KEXEC thing was just a radon musing
On Fri, Jan 04, 2013 at 02:11:46PM -0500, Konrad Rzeszutek Wilk wrote:
On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
On Fri, Jan 04, 2013 at 02:41:17PM +, Jan Beulich wrote:
On 04.01.13 at 15:22, Daniel Kiper daniel.ki...@oracle.com wrote:
On Wed, Jan 02, 2013 at
On Mon, 2013-01-07 at 12:34 +, Daniel Kiper wrote:
I think that new kexec hypercall function should mimics kexec syscall.
We want to have an interface can be used by non-Linux domains (both dom0
and domU) as well though, so please bear this in mind.
Historically we've not always been good
On Mon, Jan 07, 2013 at 01:34:04PM +0100, Daniel Kiper wrote:
On Fri, Jan 04, 2013 at 02:11:46PM -0500, Konrad Rzeszutek Wilk wrote:
On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
On Fri, Jan 04, 2013 at 02:41:17PM +, Jan Beulich wrote:
On 04.01.13 at 15:22, Daniel
On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
> On Fri, Jan 04, 2013 at 02:41:17PM +, Jan Beulich wrote:
> > >>> On 04.01.13 at 15:22, Daniel Kiper wrote:
> > > On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
> > >> /sbin/kexec can load the "Xen" crash kernel
On Fri, Jan 04, 2013 at 02:41:17PM +, Jan Beulich wrote:
> >>> On 04.01.13 at 15:22, Daniel Kiper wrote:
> > On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
> >> /sbin/kexec can load the "Xen" crash kernel itself by issuing
> >> hypercalls using /dev/xen/privcmd. This would
On Fri, Jan 04, 2013 at 02:38:44PM +, David Vrabel wrote:
> On 04/01/13 14:22, Daniel Kiper wrote:
> > On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
> >> On 27/12/12 18:02, Eric W. Biederman wrote:
> >>> Andrew Cooper writes:
> >>>
> On 27/12/2012 07:53, Eric W.
>>> On 04.01.13 at 15:22, Daniel Kiper wrote:
> On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
>> /sbin/kexec can load the "Xen" crash kernel itself by issuing
>> hypercalls using /dev/xen/privcmd. This would remove the need for
>> the dom0 kernel to distinguish between loading a
On 04/01/13 14:22, Daniel Kiper wrote:
> On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
>> On 27/12/12 18:02, Eric W. Biederman wrote:
>>> Andrew Cooper writes:
>>>
On 27/12/2012 07:53, Eric W. Biederman wrote:
> The syscall ABI still has the wrong semantics.
>
>
On Fri, Jan 04, 2013 at 03:22:57PM +0100, Daniel Kiper wrote:
> On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
> > On 27/12/12 18:02, Eric W. Biederman wrote:
> > >Andrew Cooper writes:
> > >
> > >>On 27/12/2012 07:53, Eric W. Biederman wrote:
> > >>>The syscall ABI still has the
On Fri, 2013-01-04 at 14:22 +, Daniel Kiper wrote:
> On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
> > On 27/12/12 18:02, Eric W. Biederman wrote:
> > >Andrew Cooper writes:
> > >
> > >>On 27/12/2012 07:53, Eric W. Biederman wrote:
> > >>>The syscall ABI still has the wrong
On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
> On 27/12/12 18:02, Eric W. Biederman wrote:
> >Andrew Cooper writes:
> >
> >>On 27/12/2012 07:53, Eric W. Biederman wrote:
> >>>The syscall ABI still has the wrong semantics.
> >>>
> >>>Aka totally unmaintainable and umergeable.
>
On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
On 27/12/12 18:02, Eric W. Biederman wrote:
Andrew Cooperandrew.coop...@citrix.com writes:
On 27/12/2012 07:53, Eric W. Biederman wrote:
The syscall ABI still has the wrong semantics.
Aka totally unmaintainable and
On Fri, 2013-01-04 at 14:22 +, Daniel Kiper wrote:
On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
On 27/12/12 18:02, Eric W. Biederman wrote:
Andrew Cooperandrew.coop...@citrix.com writes:
On 27/12/2012 07:53, Eric W. Biederman wrote:
The syscall ABI still has the
On Fri, Jan 04, 2013 at 03:22:57PM +0100, Daniel Kiper wrote:
On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
On 27/12/12 18:02, Eric W. Biederman wrote:
Andrew Cooperandrew.coop...@citrix.com writes:
On 27/12/2012 07:53, Eric W. Biederman wrote:
The syscall ABI still
On 04/01/13 14:22, Daniel Kiper wrote:
On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
On 27/12/12 18:02, Eric W. Biederman wrote:
Andrew Cooperandrew.coop...@citrix.com writes:
On 27/12/2012 07:53, Eric W. Biederman wrote:
The syscall ABI still has the wrong semantics.
Aka
On 04.01.13 at 15:22, Daniel Kiper daniel.ki...@oracle.com wrote:
On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
/sbin/kexec can load the Xen crash kernel itself by issuing
hypercalls using /dev/xen/privcmd. This would remove the need for
the dom0 kernel to distinguish
On Fri, Jan 04, 2013 at 02:38:44PM +, David Vrabel wrote:
On 04/01/13 14:22, Daniel Kiper wrote:
On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
On 27/12/12 18:02, Eric W. Biederman wrote:
Andrew Cooperandrew.coop...@citrix.com writes:
On 27/12/2012 07:53, Eric W.
On Fri, Jan 04, 2013 at 02:41:17PM +, Jan Beulich wrote:
On 04.01.13 at 15:22, Daniel Kiper daniel.ki...@oracle.com wrote:
On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
/sbin/kexec can load the Xen crash kernel itself by issuing
hypercalls using /dev/xen/privcmd. This
On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
On Fri, Jan 04, 2013 at 02:41:17PM +, Jan Beulich wrote:
On 04.01.13 at 15:22, Daniel Kiper daniel.ki...@oracle.com wrote:
On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote:
/sbin/kexec can load the Xen crash
>>> On 02.01.13 at 12:26, Andrew Cooper wrote:
> On 27/12/12 18:02, Eric W. Biederman wrote:
>> It probably make sense to split them apart a little even.
>
> Thinking about this split, there might be a way to simply it even more.
>
> /sbin/kexec can load the "Xen" crash kernel itself by issuing
On 02.01.13 at 12:26, Andrew Cooper andrew.coop...@citrix.com wrote:
On 27/12/12 18:02, Eric W. Biederman wrote:
It probably make sense to split them apart a little even.
Thinking about this split, there might be a way to simply it even more.
/sbin/kexec can load the Xen crash kernel
On Thu, 2012-12-27 at 14:18 +, Andrew Cooper wrote:
> Many cloud customers and service providers want the ability for a VM
> administrator to be able to load a kdump/kexec kernel within a
> domain[1]. This allows the VM administrator to take more proactive
> steps to isolate the cause of a
Andrew Cooper writes:
> On 27/12/12 18:02, Eric W. Biederman wrote:
>> Andrew Cooper writes:
>>
>>> On 27/12/2012 07:53, Eric W. Biederman wrote:
The syscall ABI still has the wrong semantics.
Aka totally unmaintainable and umergeable.
The concept of domU support is
On 27/12/12 18:02, Eric W. Biederman wrote:
Andrew Cooper writes:
On 27/12/2012 07:53, Eric W. Biederman wrote:
The syscall ABI still has the wrong semantics.
Aka totally unmaintainable and umergeable.
The concept of domU support is also strange. What does domU support even mean,
when
On 27/12/12 18:02, Eric W. Biederman wrote:
Andrew Cooperandrew.coop...@citrix.com writes:
On 27/12/2012 07:53, Eric W. Biederman wrote:
The syscall ABI still has the wrong semantics.
Aka totally unmaintainable and umergeable.
The concept of domU support is also strange. What does domU
Andrew Cooper andrew.coop...@citrix.com writes:
On 27/12/12 18:02, Eric W. Biederman wrote:
Andrew Cooperandrew.coop...@citrix.com writes:
On 27/12/2012 07:53, Eric W. Biederman wrote:
The syscall ABI still has the wrong semantics.
Aka totally unmaintainable and umergeable.
The concept
On Thu, 2012-12-27 at 14:18 +, Andrew Cooper wrote:
Many cloud customers and service providers want the ability for a VM
administrator to be able to load a kdump/kexec kernel within a
domain[1]. This allows the VM administrator to take more proactive
steps to isolate the cause of a crash,
> Andrew Cooper writes:
>
> > On 27/12/2012 07:53, Eric W. Biederman wrote:
> >> The syscall ABI still has the wrong semantics.
> >>
> >> Aka totally unmaintainable and umergeable.
> >>
> >> The concept of domU support is also strange. What does domU support even
> >> mean, when the dom0 >
> On 12/26/2012 06:18 PM, Daniel Kiper wrote:
> > Hi,
> >
> > This set of patches contains initial kexec/kdump implementation for Xen v3.
> > Currently only dom0 is supported, however, almost all infrustructure
> > required for domU support is ready.
> >
> > Jan Beulich suggested to merge Xen x86
Andrew Cooper writes:
> On 27/12/2012 07:53, Eric W. Biederman wrote:
>> The syscall ABI still has the wrong semantics.
>>
>> Aka totally unmaintainable and umergeable.
>>
>> The concept of domU support is also strange. What does domU support even
>> mean, when the dom0 support is loading a
On 27/12/2012 07:53, Eric W. Biederman wrote:
> The syscall ABI still has the wrong semantics.
>
> Aka totally unmaintainable and umergeable.
>
> The concept of domU support is also strange. What does domU support even
> mean, when the dom0 support is loading a kernel to pick up Xen when Xen
On 27/12/2012 07:53, Eric W. Biederman wrote:
The syscall ABI still has the wrong semantics.
Aka totally unmaintainable and umergeable.
The concept of domU support is also strange. What does domU support even
mean, when the dom0 support is loading a kernel to pick up Xen when Xen falls
Andrew Cooper andrew.coop...@citrix.com writes:
On 27/12/2012 07:53, Eric W. Biederman wrote:
The syscall ABI still has the wrong semantics.
Aka totally unmaintainable and umergeable.
The concept of domU support is also strange. What does domU support even
mean, when the dom0 support is
On 12/26/2012 06:18 PM, Daniel Kiper wrote:
Hi,
This set of patches contains initial kexec/kdump implementation for Xen v3.
Currently only dom0 is supported, however, almost all infrustructure
required for domU support is ready.
Jan Beulich suggested to merge Xen x86 assembler code
Andrew Cooper andrew.coop...@citrix.com writes:
On 27/12/2012 07:53, Eric W. Biederman wrote:
The syscall ABI still has the wrong semantics.
Aka totally unmaintainable and umergeable.
The concept of domU support is also strange. What does domU support even
mean, when the dom0
The syscall ABI still has the wrong semantics.
Aka totally unmaintainable and umergeable.
The concept of domU support is also strange. What does domU support even mean,
when the dom0 support is loading a kernel to pick up Xen when Xen falls over.
I expect a lot of decisions about what code
On 12/26/2012 06:18 PM, Daniel Kiper wrote:
Hi,
This set of patches contains initial kexec/kdump implementation for Xen v3.
Currently only dom0 is supported, however, almost all infrustructure
required for domU support is ready.
Jan Beulich suggested to merge Xen x86 assembler code with
Hi,
This set of patches contains initial kexec/kdump implementation for Xen v3.
Currently only dom0 is supported, however, almost all infrustructure
required for domU support is ready.
Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code.
This could simplify and reduce
Hi,
This set of patches contains initial kexec/kdump implementation for Xen v3.
Currently only dom0 is supported, however, almost all infrustructure
required for domU support is ready.
Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code.
This could simplify and reduce
On 12/26/2012 06:18 PM, Daniel Kiper wrote:
Hi,
This set of patches contains initial kexec/kdump implementation for Xen v3.
Currently only dom0 is supported, however, almost all infrustructure
required for domU support is ready.
Jan Beulich suggested to merge Xen x86 assembler code with
The syscall ABI still has the wrong semantics.
Aka totally unmaintainable and umergeable.
The concept of domU support is also strange. What does domU support even mean,
when the dom0 support is loading a kernel to pick up Xen when Xen falls over.
I expect a lot of decisions about what code
80 matches
Mail list logo
