On Mon, 2014-03-24 at 05:13 -0700, Grant Likely wrote:
> yes
> yes
> yes
Great, thanks. I think this sounds reasonable.
Ian.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majo
On Mon, Mar 24, 2014 at 2:03 AM, Ian Campbell wrote:
> On Sat, 2014-03-22 at 12:23 +, Grant Likely wrote:
>> That isn't actually my position. I absolutely think that VMs /should/
>> implement persistent variables, but the variables are a property of a VM
>> instance, not of the disk image. As
On Mon, 2014-03-24 at 11:41 +0100, Paolo Bonzini wrote:
> Il 24/03/2014 10:03, Ian Campbell ha scritto:
> >> > That isn't actually my position. I absolutely think that VMs /should/
> >> > implement persistent variables, but the variables are a property of a VM
> >> > instance, not of the disk image
Il 24/03/2014 10:57, Robie Basak ha scritto:
> After thinking about this a bit more, I think I see what we're actually
> discussing. It's obvious that if software in a VM makes changes to UEFI
> variables that are required to be persistent for that VM image to boot
> again, then the VM image is
Il 24/03/2014 10:03, Ian Campbell ha scritto:
> That isn't actually my position. I absolutely think that VMs /should/
> implement persistent variables, but the variables are a property of a VM
> instance, not of the disk image. As far as this spec is concerned, I
> think portable disk images shou
Thank you all for considering this case in more detail.
On Sat, Mar 22, 2014 at 08:29:39PM -0700, Christoffer Dall wrote:
> After thinking about this a bit more, I think I see what we're actually
> discussing. It's obvious that if software in a VM makes changes to UEFI
> variables that are requir
On Sat, 2014-03-22 at 12:23 +, Grant Likely wrote:
> That isn't actually my position. I absolutely think that VMs /should/
> implement persistent variables, but the variables are a property of a VM
> instance, not of the disk image. As far as this spec is concerned, I
> think portable disk imag
On Sat, Mar 22, 2014 at 08:19:52PM -0700, Christoffer Dall wrote:
> On Sat, Mar 22, 2014 at 09:08:37AM +0100, Paolo Bonzini wrote:
> > Il 22/03/2014 03:29, Christoffer Dall ha scritto:
> > >1. Simply mandate that VM implementations support persistent variables
> > > for their UEFI implementation
On Sat, Mar 22, 2014 at 12:23:54PM +, Grant Likely wrote:
> On Fri, 21 Mar 2014 19:29:50 -0700, Christoffer Dall
> wrote:
> > On Fri, Mar 07, 2014 at 08:24:18PM +0800, Grant Likely wrote:
> > > On Thu, 6 Mar 2014 12:04:50 +, Robie Basak
> > > wrote:
> > > > On Thu, Mar 06, 2014 at 12:44
On Sat, Mar 22, 2014 at 09:08:37AM +0100, Paolo Bonzini wrote:
> Il 22/03/2014 03:29, Christoffer Dall ha scritto:
> >1. Simply mandate that VM implementations support persistent variables
> > for their UEFI implementation - with whatever constraints that may
> > put on higher level tools.
> >
On 03/23/14 00:38, Michael Casadevall wrote:
> On 03/22/2014 03:57 PM, Paolo Bonzini wrote:
>> Il 22/03/2014 13:23, Grant Likely ha scritto:
>>> VM implementations SHOULD to implement persistent variables for
>>> their UEFI implementation - with whatever constraints that may be
>>> put on higher l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/22/2014 03:57 PM, Paolo Bonzini wrote:
> Il 22/03/2014 13:23, Grant Likely ha scritto:
>> VM implementations SHOULD to implement persistent variables for
>> their UEFI implementation - with whatever constraints that may be
>> put on higher lev
On Sat, 22 Mar 2014 20:57:58 +0100, Paolo Bonzini wrote:
> Il 22/03/2014 13:23, Grant Likely ha scritto:
> > VM implementations SHOULD to implement persistent variables for
> > their UEFI implementation - with whatever constraints that may be put on
> > higher level tools. Variable storage SHALL b
Il 22/03/2014 13:23, Grant Likely ha scritto:
VM implementations SHOULD to implement persistent variables for
their UEFI implementation - with whatever constraints that may be put on
higher level tools. Variable storage SHALL be a property of a VM
instance, but SHALL NOT be stored as part of a po
On Fri, 21 Mar 2014 19:29:50 -0700, Christoffer Dall
wrote:
> On Fri, Mar 07, 2014 at 08:24:18PM +0800, Grant Likely wrote:
> > On Thu, 6 Mar 2014 12:04:50 +, Robie Basak
> > wrote:
> > > On Thu, Mar 06, 2014 at 12:44:57PM +0100, Laszlo Ersek wrote:
> > > > If I understand correctly, the qu
Il 22/03/2014 03:29, Christoffer Dall ha scritto:
1. Simply mandate that VM implementations support persistent variables
for their UEFI implementation - with whatever constraints that may
put on higher level tools.
2. Require that OSes shipped as part of compliant VM images make no
assu
On Fri, Mar 07, 2014 at 08:24:18PM +0800, Grant Likely wrote:
> On Thu, 6 Mar 2014 12:04:50 +, Robie Basak
> wrote:
> > On Thu, Mar 06, 2014 at 12:44:57PM +0100, Laszlo Ersek wrote:
> > > If I understand correctly, the question is this:
> > >
> > > Given a hypervisor that doesn't support n
On 03/08/14 12:41, Michael Casadevall wrote:
>
> On 03/06/2014 05:46 PM, Paolo Bonzini wrote:
>> Il 06/03/2014 09:52, Robie Basak ha scritto:
>>> On Sat, Mar 01, 2014 at 03:27:56PM +, Grant Likely wrote:
I would also reference section 3.3 (Boot Option Variables Default Boot
Behavior)
On 03/06/2014 05:46 PM, Paolo Bonzini wrote:
Il 06/03/2014 09:52, Robie Basak ha scritto:
On Sat, Mar 01, 2014 at 03:27:56PM +, Grant Likely wrote:
I would also reference section 3.3 (Boot Option Variables Default Boot
Behavior) and 3.4.1.1 (Removable Media Boot Behavior) here. It's
fine
On Thu, 6 Mar 2014 08:52:13 +, Robie Basak
wrote:
> On Sat, Mar 01, 2014 at 03:27:56PM +, Grant Likely wrote:
> > I would also reference section 3.3 (Boot Option Variables Default Boot
> > Behavior) and 3.4.1.1 (Removable Media Boot Behavior) here. It's fine to
> > restate the meaning of
On Thu, 06 Mar 2014 10:46:22 +0100, Paolo Bonzini wrote:
> Il 06/03/2014 09:52, Robie Basak ha scritto:
> > On Sat, Mar 01, 2014 at 03:27:56PM +, Grant Likely wrote:
> >> I would also reference section 3.3 (Boot Option Variables Default Boot
> >> Behavior) and 3.4.1.1 (Removable Media Boot Beh
On Thu, 6 Mar 2014 12:04:50 +, Robie Basak
wrote:
> On Thu, Mar 06, 2014 at 12:44:57PM +0100, Laszlo Ersek wrote:
> > If I understand correctly, the question is this:
> >
> > Given a hypervisor that doesn't support non-volatile UEFI variables
> > (including BootOrder and Boot), is it
Il 06/03/2014 13:04, Robie Basak ha scritto:
So, for example, the guest OS might, on bootloader or kernel upgrade,
completely replace the boot mechanism, dropping the removable path and
replacing it with a fixed disk arrangement, setting boot variables
appropriately, and assume that it can reboot
On Thu, Mar 06, 2014 at 12:44:57PM +0100, Laszlo Ersek wrote:
> If I understand correctly, the question is this:
>
> Given a hypervisor that doesn't support non-volatile UEFI variables
> (including BootOrder and Boot), is it possible to automatically
> boot a carefully prepared VM image,
On 03/06/14 10:46, Paolo Bonzini wrote:
> Il 06/03/2014 09:52, Robie Basak ha scritto:
>> On Sat, Mar 01, 2014 at 03:27:56PM +, Grant Likely wrote:
>>> I would also reference section 3.3 (Boot Option Variables Default Boot
>>> Behavior) and 3.4.1.1 (Removable Media Boot Behavior) here. It's fin
Il 06/03/2014 09:52, Robie Basak ha scritto:
On Sat, Mar 01, 2014 at 03:27:56PM +, Grant Likely wrote:
I would also reference section 3.3 (Boot Option Variables Default Boot
Behavior) and 3.4.1.1 (Removable Media Boot Behavior) here. It's fine to
restate the meaning of the requirement in thi
On Sat, Mar 01, 2014 at 03:27:56PM +, Grant Likely wrote:
> I would also reference section 3.3 (Boot Option Variables Default Boot
> Behavior) and 3.4.1.1 (Removable Media Boot Behavior) here. It's fine to
> restate the meaning of the requirement in this spec, but the UEFI spec
> is the authori
On Sat, Mar 01, 2014 at 03:27:56PM +, Grant Likely wrote:
> Hi Christoffer. I've got another comment on the text, this time about the
> format of the ESP:
>
> On Wed, 26 Feb 2014 10:34:54 -0800, Christoffer Dall
> wrote:
> [...]
> > Image format
> >
> > The image format, as pre
On 1 March 2014 19:54, Grant Likely wrote:
> Allow me to elaborate. I'm not trying to punish Xen here, but I'm
> deliberately pushing back against "either/or" options in the spec. In
> this case the spec says the VM must implement one of pl011 *or* virtio
> *or* xenpv. That gives lots of implement
On Wed, 26 Feb 2014 14:25:53 -0800, Christoffer Dall
wrote:
> On Wed, Feb 26, 2014 at 09:48:43PM +, Leif Lindholm wrote:
> > On Wed, Feb 26, 2014 at 08:55:58PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 26 February 2014 10:34:54 Christoffer Dall wrote:
> > > > ARM VM System Specification
On Wed, 26 Feb 2014 14:21:47 -0800, Christoffer Dall
wrote:
> On Wed, Feb 26, 2014 at 03:56:02PM -0600, Rob Herring wrote:
> > On Wed, Feb 26, 2014 at 2:22 PM, Arnd Bergmann wrote:
> > > On Wednesday 26 February 2014 12:05:37 Christoffer Dall wrote:
> > >> On Wed, Feb 26, 2014 at 08:55:58PM +010
On Thu, 27 Feb 2014 12:27:58 +, Stefano Stabellini
wrote:
> On Wed, 26 Feb 2014, Grant Likely wrote:
> > > VM Platform
> > > ---
> > > The specification does not mandate any specific memory map. Â The guest
> > > OS must be able to enumerate all processing elements, devices, and
> > >
On Thu, 27 Feb 2014 08:12:35 -0500, Christopher Covington
wrote:
> Hi Christoffer,
>
> On 02/26/2014 02:51 PM, Christoffer Dall wrote:
> > On Wed, Feb 26, 2014 at 02:27:40PM -0500, Christopher Covington wrote:
>
> >>> Image format
> >>>
> >>> The image format, as presented to the V
Hi Christoffer. I've got another comment on the text, this time about the
format of the ESP:
On Wed, 26 Feb 2014 10:34:54 -0800, Christoffer Dall
wrote:
[...]
> Image format
>
> The image format, as presented to the VM, needs to be well-defined in
> order for prepared disk images t
On Thu, 27 Feb 2014 15:00:44 +0100, Arnd Bergmann wrote:
> On Thursday 27 February 2014 12:31:55 Stefano Stabellini wrote:
> > On Wed, 26 Feb 2014, Leif Lindholm wrote:
> > > > > no FDT. In this case, the VM implementation must provide ACPI, and
> > > > > the OS must be able to locate the ACP
On Fri, 28 Feb 2014, Alexander Graf wrote:
> > We will however want to boot all sorts of guests in a standardized
> > virtual environment:
> >
> > * 32 bit Linux (since some distros don't support biarch or multiarch
> > on arm64) for running applications that are either binary-only
> > or not 64
On Friday 28 February 2014 08:05:15 Alexander Graf wrote:
> > Am 28.02.2014 um 03:56 schrieb Arnd Bergmann :
> >> On Thursday 27 February 2014 22:24:13 Alexander Graf wrote:
>
> > When you have that, why do you still care about a
> > system specification?
>
> Because I don't want to go back to t
> Am 28.02.2014 um 03:56 schrieb Arnd Bergmann :
>
>> On Thursday 27 February 2014 22:24:13 Alexander Graf wrote:
>>
>> If you want to assign a platform device, you need to generate a respective
>> hardware description (fdt/dsdt) chunk in the hypervisor. You can't take
>> the host's description
On Thursday 27 February 2014 22:24:13 Alexander Graf wrote:
>
> If you want to assign a platform device, you need to generate a respective
> hardware description (fdt/dsdt) chunk in the hypervisor. You can't take
> the host's description - it's too tightly coupled to the overall host layout.
But
On Wed, Feb 26, 2014 at 9:15 PM, Dennis Gilmore wrote:
> On Wed, 26 Feb 2014 11:56:53 -0800
> Christoffer Dall wrote:
>
>> [why did you drop everyone from cc here?]
>
> standard reply to list behavior, I would appreciate if you followed it.
Not on the Linaro, infradead or vger lists. We preserve
On Thu, Feb 27, 2014 at 08:12:35AM -0500, Christopher Covington wrote:
> Hi Christoffer,
>
> On 02/26/2014 02:51 PM, Christoffer Dall wrote:
> > On Wed, Feb 26, 2014 at 02:27:40PM -0500, Christopher Covington wrote:
>
[...]
> >>>
> >>> The virtual hardware platform must provide a number of mand
> Am 27.02.2014 um 22:00 schrieb Arnd Bergmann :
>
>> On Thursday 27 February 2014 12:31:55 Stefano Stabellini wrote:
>> On Wed, 26 Feb 2014, Leif Lindholm wrote:
> no FDT. In this case, the VM implementation must provide ACPI, and
> the OS must be able to locate the ACPI root pointer
On Thursday 27 February 2014 12:31:55 Stefano Stabellini wrote:
> On Wed, 26 Feb 2014, Leif Lindholm wrote:
> > > > no FDT. In this case, the VM implementation must provide ACPI, and
> > > > the OS must be able to locate the ACPI root pointer through the UEFI
> > > > system table.
> > > >
>
Hi Christoffer,
On 02/26/2014 02:51 PM, Christoffer Dall wrote:
> On Wed, Feb 26, 2014 at 02:27:40PM -0500, Christopher Covington wrote:
>>> Image format
>>>
>>> The image format, as presented to the VM, needs to be well-defined in
>>> order for prepared disk images to be bootable ac
On 26 February 2014 22:35, Grant Likely wrote:
> On 26 Feb 2014 18:35, "Christoffer Dall"
> wrote:
>> Serial console: The platform should provide a console,
>> based on an emulated pl011, a virtio-console, or a Xen PV console.
>
> For portable disk image, can Xen PV be dropped from the list?
On Wed, 26 Feb 2014, Leif Lindholm wrote:
> > > no FDT. In this case, the VM implementation must provide ACPI, and
> > > the OS must be able to locate the ACPI root pointer through the UEFI
> > > system table.
> > >
> > > For more information about the arm and arm64 boot conventions, see
>
On Wed, 26 Feb 2014, Grant Likely wrote:
> > VM Platform
> > ---
> > The specification does not mandate any specific memory map. The guest
> > OS must be able to enumerate all processing elements, devices, and
> > memory through HW description data (FDT, ACPI) or a bus-specific
> > mechani
On Wed, Feb 26, 2014 at 05:08:38PM -0600, Rob Herring wrote:
> > What does the 8250 have to recommend it over just providing
> > the PL011?
>
> As I mentioned, it will just work for anything that expects the serial
> port to be ttyS0 as on x86 rather than ttyAMA0. Really, I'd like to
> see ttyAMA
Il 27/02/2014 08:30, Arnd Bergmann ha scritto:
I guess the real question is whether we are interested in running Windows RT
in VM guests. I don't personally expect MS to come out with a port for
this spec, no matter what we do, but some of you may have information I don't.
Given enough firmware
On 26 February 2014 20:05, Christoffer Dall wrote:
> On Wed, Feb 26, 2014 at 08:55:58PM +0100, Arnd Bergmann wrote:
>> On Wednesday 26 February 2014 10:34:54 Christoffer Dall wrote:
>> > For more information about UEFI and ACPI booting, see [4] and [5].
>>
>> What's the point of having ACPI in a v
On Wednesday 26 February 2014, Christoffer Dall wrote:
> Personally I'm all for simplicity so I don't want to push any agenda for
> ACPI in VMs.
>
> Note that the spec does not mandate the use of ACPI, it just tells you
> how to do it if you wish to.
>
> But, we can change the spec to require ful
On Wed, 26 Feb 2014, Peter Maydell wrote:
> On 26 February 2014 23:08, Rob Herring wrote:
> > On Wed, Feb 26, 2014 at 4:54 PM, Peter Maydell
> > wrote:
> >> What does the 8250 have to recommend it over just providing
> >> the PL011?
> >
> > As I mentioned, it will just work for anything that ex
On 2/26/14 10:34 AM, Christoffer Dall wrote:
ARM VM System Specification
===
See also the thread forked off to the EFI dev list, about using existing
EFI ByteCode (EBC) for this new purpose, especially the informative
reply from Andrew Fish of Apple.com:
http://sourc
On 26 February 2014 23:08, Rob Herring wrote:
> On Wed, Feb 26, 2014 at 4:54 PM, Peter Maydell
> wrote:
>> What does the 8250 have to recommend it over just providing
>> the PL011?
>
> As I mentioned, it will just work for anything that expects the serial
> port to be ttyS0 as on x86 rather than
On 02/26/2014 05:49 PM, Rob Herring wrote:
> On Wed, Feb 26, 2014 at 1:55 PM, Arnd Bergmann wrote:
>> On Wednesday 26 February 2014 10:34:54 Christoffer Dall wrote:
>>> ARM VM System Specification
>>> ===
>>>
>>> Goal
>>>
>>> The goal of this spec is to allow suitably-
On Wed, Feb 26, 2014 at 4:54 PM, Peter Maydell wrote:
> On 26 February 2014 22:49, Rob Herring wrote
>> The SBSA only spec's a very minimal pl011 subset which is only
>> suitable for early serial output. Not only is there no DMA, but there
>> are no interrupts and maybe no input.
>
> No interrupt
On 26 February 2014 22:49, Rob Herring wrote
> The SBSA only spec's a very minimal pl011 subset which is only
> suitable for early serial output. Not only is there no DMA, but there
> are no interrupts and maybe no input.
No interrupts on a UART in a VM (especially an emulated one)
is a good way
On Wed, Feb 26, 2014 at 1:55 PM, Arnd Bergmann wrote:
> On Wednesday 26 February 2014 10:34:54 Christoffer Dall wrote:
>> ARM VM System Specification
>> ===
>>
>> Goal
>>
>> The goal of this spec is to allow suitably-built OS images to run on
>> all ARM virtualization
Hi Grant,
Thanks for comments,
On Wed, Feb 26, 2014 at 10:35:54PM +, Grant Likely wrote:
>
> On 26 Feb 2014 18:35, "Christoffer Dall"
> wrote:
> >
> > ARM VM System Specification
> > ===
> >
> > Goal
> >
> > The goal of this spec is to allow suitably-built OS im
On Wed, Feb 26, 2014 at 09:48:43PM +, Leif Lindholm wrote:
> On Wed, Feb 26, 2014 at 08:55:58PM +0100, Arnd Bergmann wrote:
> > On Wednesday 26 February 2014 10:34:54 Christoffer Dall wrote:
> > > ARM VM System Specification
> > > ===
> > >
> > > Goal
> > >
> > > T
On Wed, Feb 26, 2014 at 03:56:02PM -0600, Rob Herring wrote:
> On Wed, Feb 26, 2014 at 2:22 PM, Arnd Bergmann wrote:
> > On Wednesday 26 February 2014 12:05:37 Christoffer Dall wrote:
> >> On Wed, Feb 26, 2014 at 08:55:58PM +0100, Arnd Bergmann wrote:
> >> > On Wednesday 26 February 2014 10:34:54
On Wed, Feb 26, 2014 at 2:22 PM, Arnd Bergmann wrote:
> On Wednesday 26 February 2014 12:05:37 Christoffer Dall wrote:
>> On Wed, Feb 26, 2014 at 08:55:58PM +0100, Arnd Bergmann wrote:
>> > On Wednesday 26 February 2014 10:34:54 Christoffer Dall wrote:
>>
>> The most common response I've been gett
On Wed, Feb 26, 2014 at 08:55:58PM +0100, Arnd Bergmann wrote:
> On Wednesday 26 February 2014 10:34:54 Christoffer Dall wrote:
> > ARM VM System Specification
> > ===
> >
> > Goal
> >
> > The goal of this spec is to allow suitably-built OS images to run on
> > all ARM
On Thu, Feb 27, 2014 at 10:05:05AM +1300, Michael Hudson-Doyle wrote:
> Christoffer Dall writes:
>
> > Hardware Description
> >
> > The Linux kernel's proper entry point always takes a pointer to an FDT,
> > regardless of the boot mechanism, firmware, and hardware description
Christoffer Dall writes:
> Hardware Description
>
> The Linux kernel's proper entry point always takes a pointer to an FDT,
> regardless of the boot mechanism, firmware, and hardware description
> method. Even on real hardware which only supports ACPI and UEFI, the kernel
>
On Wednesday 26 February 2014 12:05:37 Christoffer Dall wrote:
> On Wed, Feb 26, 2014 at 08:55:58PM +0100, Arnd Bergmann wrote:
> > On Wednesday 26 February 2014 10:34:54 Christoffer Dall wrote:
>
> The most common response I've been getting so far is that people
> generally want their VMs to look
On 26 February 2014 20:19, Paolo Bonzini wrote:
> Il 26/02/2014 20:55, Arnd Bergmann ha scritto:
>> Did you notice we are removing mach-virt now? Probably no point
>> mentioning it here.
>
>
> Peter, do we still want mach-virt support in QEMU then?
Yes, it will be about the only thing that suppor
Il 26/02/2014 20:55, Arnd Bergmann ha scritto:
> For more information about UEFI and ACPI booting, see [4] and [5].
What's the point of having ACPI in a virtual machine? You wouldn't
need to abstract any of the hardware in AML since you already know
what the virtual hardware is, so I can't see h
On Wed, Feb 26, 2014 at 08:55:58PM +0100, Arnd Bergmann wrote:
> On Wednesday 26 February 2014 10:34:54 Christoffer Dall wrote:
> > ARM VM System Specification
> > ===
> >
> > Goal
> >
> > The goal of this spec is to allow suitably-built OS images to run on
> > all ARM
On Wednesday 26 February 2014 10:34:54 Christoffer Dall wrote:
> ARM VM System Specification
> ===
>
> Goal
>
> The goal of this spec is to allow suitably-built OS images to run on
> all ARM virtualization solutions, such as KVM or Xen.
>
> Recommendations in this spe
On Wed, Feb 26, 2014 at 02:27:40PM -0500, Christopher Covington wrote:
> Hi Christoffer,
>
> On 02/26/2014 01:34 PM, Christoffer Dall wrote:
> > ARM VM System Specification
> > ===
> >
> > Goal
> >
> > The goal of this spec is to allow suitably-built OS images to run
Hi Christoffer,
On 02/26/2014 01:34 PM, Christoffer Dall wrote:
> ARM VM System Specification
> ===
>
> Goal
>
> The goal of this spec is to allow suitably-built OS images to run on
> all ARM virtualization solutions, such as KVM or Xen.
Would you consider including
ARM VM System Specification
===
Goal
The goal of this spec is to allow suitably-built OS images to run on
all ARM virtualization solutions, such as KVM or Xen.
Recommendations in this spec are valid for aarch32 and aarch64 alike, and
they aim to be hypervisor agnostic
73 matches
Mail list logo
