Well, thank you all for the discussions, we achieved some agreement,
and there are still things for further review.
The v3 patch has been sent out, we can move there and review/discuss
the updated patch now.
Thanks.
On 5 September 2018 at 23:00, Andrew Jones wrote:
> On Wed, Sep 05, 2018 at
On Wed, Sep 05, 2018 at 10:09:46PM +0800, Hongbo Zhang wrote:
> On 5 September 2018 at 20:02, Andrew Jones wrote:
> > On Wed, Sep 05, 2018 at 06:08:57PM +0800, Hongbo Zhang wrote:
> >> On 30 August 2018 at 21:29, Ard Biesheuvel
> >> wrote:
> >> > On 30 August 2018 at 12:02, Leif Lindholm
> >>
On 5 September 2018 at 20:02, Andrew Jones wrote:
> On Wed, Sep 05, 2018 at 06:08:57PM +0800, Hongbo Zhang wrote:
>> On 30 August 2018 at 21:29, Ard Biesheuvel wrote:
>> > On 30 August 2018 at 12:02, Leif Lindholm wrote:
>> >> On Thu, Aug 30, 2018 at 09:39:33AM +0100, Peter Maydell wrote:
>>
On Wed, Sep 05, 2018 at 06:08:57PM +0800, Hongbo Zhang wrote:
> On 30 August 2018 at 21:29, Ard Biesheuvel wrote:
> > On 30 August 2018 at 12:02, Leif Lindholm wrote:
> >> On Thu, Aug 30, 2018 at 09:39:33AM +0100, Peter Maydell wrote:
> >>> On 30 August 2018 at 09:31, Leif Lindholm
> >>>
On 30 August 2018 at 21:29, Ard Biesheuvel wrote:
> On 30 August 2018 at 12:02, Leif Lindholm wrote:
>> On Thu, Aug 30, 2018 at 09:39:33AM +0100, Peter Maydell wrote:
>>> On 30 August 2018 at 09:31, Leif Lindholm wrote:
>>> > On Thu, Aug 30, 2018 at 03:07:29PM +0800, Hongbo Zhang wrote:
>>> >>
On 31 August 2018 at 16:42, Andrew Jones wrote:
> On Fri, Aug 31, 2018 at 03:20:45PM +0800, Hongbo Zhang wrote:
>> If no DT in SBSA machine, then the code had much more difference with
>> virt, so there is possibility to make it a simple separate file;
>> If keep same DT as virt, then there are
On Fri, Aug 31, 2018 at 03:20:45PM +0800, Hongbo Zhang wrote:
> If no DT in SBSA machine, then the code had much more difference with
> virt, so there is possibility to make it a simple separate file;
> If keep same DT as virt, then there are more overlap with virt codes,
> so I am not sure how
On 30 August 2018 at 21:29, Ard Biesheuvel wrote:
> On 30 August 2018 at 12:02, Leif Lindholm wrote:
>> On Thu, Aug 30, 2018 at 09:39:33AM +0100, Peter Maydell wrote:
>>> On 30 August 2018 at 09:31, Leif Lindholm wrote:
>>> > On Thu, Aug 30, 2018 at 03:07:29PM +0800, Hongbo Zhang wrote:
>>> >>
On 30 August 2018 at 14:29, Ard Biesheuvel wrote:
> How exactly the firmware figures out how many CPUs and how much memory
> we are running with is out of scope for this, and so I don't think
> there is a need to build something from scratch here: DT will do just
> fine, given that both EDK2 and
On 30 August 2018 at 18:36, Peter Maydell wrote:
> On 30 August 2018 at 14:29, Ard Biesheuvel wrote:
>> How exactly the firmware figures out how many CPUs and how much memory
>> we are running with is out of scope for this, and so I don't think
>> there is a need to build something from scratch
On Thu, Aug 30, 2018 at 03:29:02PM +0200, Ard Biesheuvel wrote:
> On 30 August 2018 at 12:02, Leif Lindholm wrote:
> > On Thu, Aug 30, 2018 at 09:39:33AM +0100, Peter Maydell wrote:
> >> On 30 August 2018 at 09:31, Leif Lindholm wrote:
> >> > On Thu, Aug 30, 2018 at 03:07:29PM +0800, Hongbo
On 30 August 2018 at 12:02, Leif Lindholm wrote:
> On Thu, Aug 30, 2018 at 09:39:33AM +0100, Peter Maydell wrote:
>> On 30 August 2018 at 09:31, Leif Lindholm wrote:
>> > On Thu, Aug 30, 2018 at 03:07:29PM +0800, Hongbo Zhang wrote:
>> >> @Ard, @Leif, is there any possibility to remove all the
On Thu, Aug 30, 2018 at 09:39:33AM +0100, Peter Maydell wrote:
> On 30 August 2018 at 09:31, Leif Lindholm wrote:
> > On Thu, Aug 30, 2018 at 03:07:29PM +0800, Hongbo Zhang wrote:
> >> @Ard, @Leif, is there any possibility to remove all the DT nodes?
> >> On real hardware, how does UEFI find the
On 30 August 2018 at 09:31, Leif Lindholm wrote:
> On Thu, Aug 30, 2018 at 03:07:29PM +0800, Hongbo Zhang wrote:
>> @Ard, @Leif, is there any possibility to remove all the DT nodes?
>> On real hardware, how does UEFI find the memory size and CPU number?
>
> Usually by asking some form of SCP/PMU.
On Thu, Aug 30, 2018 at 03:07:29PM +0800, Hongbo Zhang wrote:
> >> Yes, I am working on the v3, with main changes:
> >> - machine name "sbsa-ref" (good name?)
> >> - a separate file sbsa-ref.c
> >> - don't touch the acpi c file, acpi will be supplied by uefi
> >
> > I agree with the above three
On 29 August 2018 at 21:42, Andrew Jones wrote:
> On Wed, Aug 29, 2018 at 05:17:20PM +0800, Hongbo Zhang wrote:
>> On 17 August 2018 at 21:37, Peter Maydell wrote:
>> > On 25 July 2018 at 06:30, Hongbo Zhang wrote:
>> >> For the Aarch64, there is one machine 'virt', it is primarily meant to
>>
On Wed, Aug 29, 2018 at 05:17:20PM +0800, Hongbo Zhang wrote:
> On 17 August 2018 at 21:37, Peter Maydell wrote:
> > On 25 July 2018 at 06:30, Hongbo Zhang wrote:
> >> For the Aarch64, there is one machine 'virt', it is primarily meant to
> >> run on KVM and execute virtualization workloads, but
On 17 August 2018 at 21:37, Peter Maydell wrote:
> On 25 July 2018 at 06:30, Hongbo Zhang wrote:
>> For the Aarch64, there is one machine 'virt', it is primarily meant to
>> run on KVM and execute virtualization workloads, but we need an
>> environment as faithful as possible to physical
On 25 July 2018 at 06:30, Hongbo Zhang wrote:
> For the Aarch64, there is one machine 'virt', it is primarily meant to
> run on KVM and execute virtualization workloads, but we need an
> environment as faithful as possible to physical hardware, for supporting
> firmware and OS development for
On 08/03/18 16:39, Andrew Jones wrote:
> On Fri, Aug 03, 2018 at 03:44:21PM +0200, Laszlo Ersek wrote:
>> In my earlier email
>>
>> dynamic DRAM base for ArmVirtQemu
>> http://mid.mail-archive.com/4cce2b8b-a411-bd5d-a06f-b0b80a5fb2f1@redhat.com
>>
>> I investigated what it would take to adapt
On Fri, Aug 03, 2018 at 03:44:21PM +0200, Laszlo Ersek wrote:
> Hi Drew,
>
> On 08/03/18 11:37, Andrew Jones wrote:
> > On Fri, Aug 03, 2018 at 11:26:41AM +0200, Ard Biesheuvel wrote:
> >> On 3 August 2018 at 11:23, Peter Maydell
> >> wrote:
> >>> On 3 August 2018 at 10:21, Hongbo Zhang
> >>>
Hi Drew,
On 08/03/18 11:37, Andrew Jones wrote:
> On Fri, Aug 03, 2018 at 11:26:41AM +0200, Ard Biesheuvel wrote:
>> On 3 August 2018 at 11:23, Peter Maydell
>> wrote:
>>> On 3 August 2018 at 10:21, Hongbo Zhang
>>> wrote:
The 'sbsa' machine won't consume QEMU generated ACPI, so it won't
On 3 August 2018 at 17:39, Peter Maydell wrote:
> On 3 August 2018 at 10:26, Ard Biesheuvel wrote:
>> On 3 August 2018 at 11:23, Peter Maydell wrote:
>>> Would the real hardware you are trying to be an example
>>> for use DT for this? It seems a bit unlikely to me.
>>>
>>
>> Yes, as a matter of
On 3 August 2018 at 10:26, Ard Biesheuvel wrote:
> On 3 August 2018 at 11:23, Peter Maydell wrote:
>> Would the real hardware you are trying to be an example
>> for use DT for this? It seems a bit unlikely to me.
>>
>
> Yes, as a matter of fact. There is work underway both on the EDK2 and
> the
On Fri, Aug 03, 2018 at 11:26:41AM +0200, Ard Biesheuvel wrote:
> On 3 August 2018 at 11:23, Peter Maydell wrote:
> > On 3 August 2018 at 10:21, Hongbo Zhang wrote:
> >> The 'sbsa' machine won't consume QEMU generated ACPI, so it won't
> >> touch or add new ACPI tables.
> >>
> >> UEFI relies on
On 3 August 2018 at 11:23, Peter Maydell wrote:
> On 3 August 2018 at 10:21, Hongbo Zhang wrote:
>> The 'sbsa' machine won't consume QEMU generated ACPI, so it won't
>> touch or add new ACPI tables.
>>
>> UEFI relies on its ACPI to load OS, but currently it still needs DT
>> from QEMU to pass
On 3 August 2018 at 10:21, Hongbo Zhang wrote:
> The 'sbsa' machine won't consume QEMU generated ACPI, so it won't
> touch or add new ACPI tables.
>
> UEFI relies on its ACPI to load OS, but currently it still needs DT
> from QEMU to pass some info, one example is CPU number.
>
> So, the 'sbsa'
On 26 July 2018 at 20:43, Peter Maydell wrote:
> On 26 July 2018 at 13:35, Andrew Jones wrote:
>> On Thu, Jul 26, 2018 at 01:10:34PM +0100, Peter Maydell wrote:
>>> On 26 July 2018 at 12:41, Andrew Jones wrote:
>>> > The patch guards the generation. It'll only modify DT and ACPI for the
>>> >
On 26 July 2018 at 20:49, Daniel P. Berrangé wrote:
> On Thu, Jul 26, 2018 at 02:23:46PM +0200, Laszlo Ersek wrote:
>> On 07/26/18 13:13, Andrew Jones wrote:
>> > On Thu, Jul 26, 2018 at 12:56:22PM +0200, Ard Biesheuvel wrote:
>> >> On 26 July 2018 at 12:52, Peter Maydell wrote:
>> >>> On 26
On 26 July 2018 at 20:43, Peter Maydell wrote:
> On 26 July 2018 at 13:35, Andrew Jones wrote:
>> On Thu, Jul 26, 2018 at 01:10:34PM +0100, Peter Maydell wrote:
>>> On 26 July 2018 at 12:41, Andrew Jones wrote:
>>> > The patch guards the generation. It'll only modify DT and ACPI for the
>>> >
On Thu, Jul 26, 2018 at 02:23:46PM +0200, Laszlo Ersek wrote:
> On 07/26/18 13:13, Andrew Jones wrote:
> > On Thu, Jul 26, 2018 at 12:56:22PM +0200, Ard Biesheuvel wrote:
> >> On 26 July 2018 at 12:52, Peter Maydell wrote:
> >>> On 26 July 2018 at 11:46, Andrew Jones wrote:
> i440fx and q35
On 26 July 2018 at 13:35, Andrew Jones wrote:
> On Thu, Jul 26, 2018 at 01:10:34PM +0100, Peter Maydell wrote:
>> On 26 July 2018 at 12:41, Andrew Jones wrote:
>> > The patch guards the generation. It'll only modify DT and ACPI for the
>> > new machine type. But, while modifying the DT makes
On Thu, Jul 26, 2018 at 01:10:34PM +0100, Peter Maydell wrote:
> On 26 July 2018 at 12:41, Andrew Jones wrote:
> > The patch guards the generation. It'll only modify DT and ACPI for the
> > new machine type. But, while modifying the DT makes sense, as that
> > generated DT will get consumed
>
>
On 07/26/18 13:13, Andrew Jones wrote:
> On Thu, Jul 26, 2018 at 12:56:22PM +0200, Ard Biesheuvel wrote:
>> On 26 July 2018 at 12:52, Peter Maydell wrote:
>>> On 26 July 2018 at 11:46, Andrew Jones wrote:
i440fx and q35 are specific machine types. 'sbsa' is a generic machine
type that
On 26 July 2018 at 12:41, Andrew Jones wrote:
> The patch guards the generation. It'll only modify DT and ACPI for the
> new machine type. But, while modifying the DT makes sense, as that
> generated DT will get consumed
...will it? Why would we want the firmware to read the
QEMU-generated DT?
On Thu, Jul 26, 2018 at 01:15:15PM +0200, Ard Biesheuvel wrote:
> That may be true. But we'll still end up with a UEFI build that has
> OVMF virtio bus drivers and device drivers included, blurring the line
> between emulation and virtualization.
The UEFI build can drop the virtio-mmio support,
On 26 July 2018 at 13:11, Andrew Jones wrote:
> On Thu, Jul 26, 2018 at 12:35:08PM +0200, Ard Biesheuvel wrote:
>> On 26 July 2018 at 12:28, Andrew Jones wrote:
>> > On Thu, Jul 26, 2018 at 05:22:14PM +0800, Hongbo Zhang wrote:
>> >> On 25 July 2018 at 19:26, Andrew Jones wrote:
>> >> > On Wed,
On Thu, Jul 26, 2018 at 12:56:22PM +0200, Ard Biesheuvel wrote:
> On 26 July 2018 at 12:52, Peter Maydell wrote:
> > On 26 July 2018 at 11:46, Andrew Jones wrote:
> >> i440fx and q35 are specific machine types. 'sbsa' is a generic machine
> >> type that conforms to the SBSA specification. If you
On Thu, Jul 26, 2018 at 12:35:08PM +0200, Ard Biesheuvel wrote:
> On 26 July 2018 at 12:28, Andrew Jones wrote:
> > On Thu, Jul 26, 2018 at 05:22:14PM +0800, Hongbo Zhang wrote:
> >> On 25 July 2018 at 19:26, Andrew Jones wrote:
> >> > On Wed, Jul 25, 2018 at 06:22:17PM +0800, Hongbo Zhang
On Thu, Jul 26, 2018 at 05:55:54PM +0800, Hongbo Zhang wrote:
> On 26 July 2018 at 00:15, Igor Mammedov wrote:
> > On Wed, 25 Jul 2018 13:36:45 +0200
> > Andrew Jones wrote:
> >
> >> On Wed, Jul 25, 2018 at 11:50:41AM +0100, Dr. David Alan Gilbert wrote:
> >> > * Andrew Jones
On 26 July 2018 at 12:52, Peter Maydell wrote:
> On 26 July 2018 at 11:46, Andrew Jones wrote:
>> i440fx and q35 are specific machine types. 'sbsa' is a generic machine
>> type that conforms to the SBSA specification. If you weren't trying to
>> memory map AHCI and EHCI controllers, or if memory
On 26 July 2018 at 11:46, Andrew Jones wrote:
> i440fx and q35 are specific machine types. 'sbsa' is a generic machine
> type that conforms to the SBSA specification. If you weren't trying to
> memory map AHCI and EHCI controllers, or if memory mapped AHCI and EHCI
> controllers were mandated in
On Thu, Jul 26, 2018 at 06:17:36PM +0800, Hongbo Zhang wrote:
> On 25 July 2018 at 19:44, Andrew Jones wrote:
> > On Wed, Jul 25, 2018 at 06:46:59PM +0800, Hongbo Zhang wrote:
> >> On 25 July 2018 at 17:54, Andrew Jones wrote:
> >> > On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
On 26 July 2018 at 12:28, Andrew Jones wrote:
> On Thu, Jul 26, 2018 at 05:22:14PM +0800, Hongbo Zhang wrote:
>> On 25 July 2018 at 19:26, Andrew Jones wrote:
>> > On Wed, Jul 25, 2018 at 06:22:17PM +0800, Hongbo Zhang wrote:
>> >> On 25 July 2018 at 17:54, Andrew Jones wrote:
>> >> > On Wed,
On Thu, Jul 26, 2018 at 05:46:23PM +0800, Hongbo Zhang wrote:
> On 25 July 2018 at 22:08, Andrew Jones wrote:
> > On Wed, Jul 25, 2018 at 03:46:01PM +0200, Ard Biesheuvel wrote:
> >> On 25 July 2018 at 15:38, Andrew Jones wrote:
> >> > On Wed, Jul 25, 2018 at 03:03:40PM +0200, Ard Biesheuvel
On Thu, Jul 26, 2018 at 05:22:14PM +0800, Hongbo Zhang wrote:
> On 25 July 2018 at 19:26, Andrew Jones wrote:
> > On Wed, Jul 25, 2018 at 06:22:17PM +0800, Hongbo Zhang wrote:
> >> On 25 July 2018 at 17:54, Andrew Jones wrote:
> >> > On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
On 25 July 2018 at 20:19, Peter Maydell wrote:
> On 25 July 2018 at 12:44, Andrew Jones wrote:
>> On Wed, Jul 25, 2018 at 06:46:59PM +0800, Hongbo Zhang wrote:
>>> For Armv7, there is one typical platform 'vexpress', but for Armv8, no
>>
>> Wasn't the vexpress model designed for a specific
On 25 July 2018 at 19:44, Andrew Jones wrote:
> On Wed, Jul 25, 2018 at 06:46:59PM +0800, Hongbo Zhang wrote:
>> On 25 July 2018 at 17:54, Andrew Jones wrote:
>> > On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
>> >> For the Aarch64, there is one machine 'virt', it is primarily
On 26 July 2018 at 00:15, Igor Mammedov wrote:
> On Wed, 25 Jul 2018 13:36:45 +0200
> Andrew Jones wrote:
>
>> On Wed, Jul 25, 2018 at 11:50:41AM +0100, Dr. David Alan Gilbert wrote:
>> > * Andrew Jones (drjo...@redhat.com) wrote:
>> > > On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang
On 25 July 2018 at 22:08, Andrew Jones wrote:
> On Wed, Jul 25, 2018 at 03:46:01PM +0200, Ard Biesheuvel wrote:
>> On 25 July 2018 at 15:38, Andrew Jones wrote:
>> > On Wed, Jul 25, 2018 at 03:03:40PM +0200, Ard Biesheuvel wrote:
>> >> On 25 July 2018 at 14:59, Andrew Jones wrote:
>> >> > On
On 25 July 2018 at 19:26, Andrew Jones wrote:
> On Wed, Jul 25, 2018 at 06:22:17PM +0800, Hongbo Zhang wrote:
>> On 25 July 2018 at 17:54, Andrew Jones wrote:
>> > On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
>> >> For the Aarch64, there is one machine 'virt', it is primarily
On 26 July 2018 at 08:44, Ard Biesheuvel wrote:
> Does that really matter? As I pointed out before, we are not
> interested in running the firmware on actual bare metal. What we do
> care about is not having code in the reference firmware stack that was
> added specifically to deal with the
On 26 July 2018 at 09:35, Hongbo Zhang wrote:
> On 25 July 2018 at 18:53, Dr. David Alan Gilbert wrote:
>> * Hongbo Zhang (hongbo.zh...@linaro.org) wrote:
>>> On 25 July 2018 at 17:54, Andrew Jones wrote:
>>> > On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
>>> >> For the
On 25 July 2018 at 18:53, Dr. David Alan Gilbert wrote:
> * Hongbo Zhang (hongbo.zh...@linaro.org) wrote:
>> On 25 July 2018 at 17:54, Andrew Jones wrote:
>> > On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
>> >> For the Aarch64, there is one machine 'virt', it is primarily meant
On Wed, 25 Jul 2018 13:36:45 +0200
Andrew Jones wrote:
> On Wed, Jul 25, 2018 at 11:50:41AM +0100, Dr. David Alan Gilbert wrote:
> > * Andrew Jones (drjo...@redhat.com) wrote:
> > > On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
> > > > For the Aarch64, there is one machine
On Wed, Jul 25, 2018 at 03:46:01PM +0200, Ard Biesheuvel wrote:
> On 25 July 2018 at 15:38, Andrew Jones wrote:
> > On Wed, Jul 25, 2018 at 03:03:40PM +0200, Ard Biesheuvel wrote:
> >> On 25 July 2018 at 14:59, Andrew Jones wrote:
> >> > On Wed, Jul 25, 2018 at 01:47:00PM +0100, Daniel P.
On 25 July 2018 at 15:38, Andrew Jones wrote:
> On Wed, Jul 25, 2018 at 03:03:40PM +0200, Ard Biesheuvel wrote:
>> On 25 July 2018 at 14:59, Andrew Jones wrote:
>> > On Wed, Jul 25, 2018 at 01:47:00PM +0100, Daniel P. Berrangé wrote:
>> >> Would iut make any sense to call the machine
On Wed, Jul 25, 2018 at 03:03:40PM +0200, Ard Biesheuvel wrote:
> On 25 July 2018 at 14:59, Andrew Jones wrote:
> > On Wed, Jul 25, 2018 at 01:47:00PM +0100, Daniel P. Berrangé wrote:
> >> Would iut make any sense to call the machine "refplatform" or "refboard"
> >> to indicate it is a generic
On 25 July 2018 at 14:59, Andrew Jones wrote:
> On Wed, Jul 25, 2018 at 01:47:00PM +0100, Daniel P. Berrangé wrote:
>> Would iut make any sense to call the machine "refplatform" or "refboard"
>> to indicate it is a generic reference platform, not specifically following
>> any particular real
On Wed, Jul 25, 2018 at 01:47:00PM +0100, Daniel P. Berrangé wrote:
> Would iut make any sense to call the machine "refplatform" or "refboard"
> to indicate it is a generic reference platform, not specifically following
> any particular real impl, albeit influence by the sbsa spec.
>
That would
On Wed, Jul 25, 2018 at 02:29:09PM +0200, Ard Biesheuvel wrote:
> To prevent spending a disproportionate amount of time on inventing
> ways to parameterize these 'models', which includes interfaces not
> only between UEFI and QEMU but also between ARM-TF and QEMU (and
> potentially between UEFI
On 25 July 2018 at 13:29, Ard Biesheuvel wrote:
> To prevent spending a disproportionate amount of time on inventing
> ways to parameterize these 'models', which includes interfaces not
> only between UEFI and QEMU but also between ARM-TF and QEMU (and
> potentially between UEFI and ARM-TF as
On Wed, Jul 25, 2018 at 01:19:09PM +0100, Peter Maydell wrote:
> On 25 July 2018 at 12:44, Andrew Jones wrote:
> > On Wed, Jul 25, 2018 at 06:46:59PM +0800, Hongbo Zhang wrote:
> >> For Armv7, there is one typical platform 'vexpress', but for Armv8, no
> >
> > Wasn't the vexpress model designed
On 25 July 2018 at 14:19, Peter Maydell wrote:
> On 25 July 2018 at 12:44, Andrew Jones wrote:
>> On Wed, Jul 25, 2018 at 06:46:59PM +0800, Hongbo Zhang wrote:
>>> For Armv7, there is one typical platform 'vexpress', but for Armv8, no
>>
>> Wasn't the vexpress model designed for a specific
On 25 July 2018 at 12:44, Andrew Jones wrote:
> On Wed, Jul 25, 2018 at 06:46:59PM +0800, Hongbo Zhang wrote:
>> For Armv7, there is one typical platform 'vexpress', but for Armv8, no
>
> Wasn't the vexpress model designed for a specific machine?
Yes.
> Namely for
> Arm's simulator?
No.
> Is
On Wed, Jul 25, 2018 at 06:46:59PM +0800, Hongbo Zhang wrote:
> On 25 July 2018 at 17:54, Andrew Jones wrote:
> > On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
> >> For the Aarch64, there is one machine 'virt', it is primarily meant to
> >> run on KVM and execute virtualization
On Wed, Jul 25, 2018 at 11:50:41AM +0100, Dr. David Alan Gilbert wrote:
> * Andrew Jones (drjo...@redhat.com) wrote:
> > On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
> > > For the Aarch64, there is one machine 'virt', it is primarily meant to
> > > run on KVM and execute
On Wed, Jul 25, 2018 at 06:22:17PM +0800, Hongbo Zhang wrote:
> On 25 July 2018 at 17:54, Andrew Jones wrote:
> > On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
> >> For the Aarch64, there is one machine 'virt', it is primarily meant to
> >> run on KVM and execute virtualization
On Wed, Jul 25, 2018 at 06:33:01PM +0800, Hongbo Zhang wrote:
> On 25 July 2018 at 17:40, Andrew Jones wrote:
> > On Wed, Jul 25, 2018 at 11:20:03AM +0200, Ard Biesheuvel wrote:
> >> On 25 July 2018 at 11:17, Hongbo Zhang wrote:
> >> > On 25 July 2018 at 17:13, Ard Biesheuvel
> >> > wrote:
>
* Hongbo Zhang (hongbo.zh...@linaro.org) wrote:
> On 25 July 2018 at 17:54, Andrew Jones wrote:
> > On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
> >> For the Aarch64, there is one machine 'virt', it is primarily meant to
> >> run on KVM and execute virtualization workloads, but
* Andrew Jones (drjo...@redhat.com) wrote:
> On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
> > For the Aarch64, there is one machine 'virt', it is primarily meant to
> > run on KVM and execute virtualization workloads, but we need an
> > environment as faithful as possible to
On 25 July 2018 at 17:54, Andrew Jones wrote:
> On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
>> For the Aarch64, there is one machine 'virt', it is primarily meant to
>> run on KVM and execute virtualization workloads, but we need an
>> environment as faithful as possible to
On 25 July 2018 at 17:40, Andrew Jones wrote:
> On Wed, Jul 25, 2018 at 11:20:03AM +0200, Ard Biesheuvel wrote:
>> On 25 July 2018 at 11:17, Hongbo Zhang wrote:
>> > On 25 July 2018 at 17:13, Ard Biesheuvel wrote:
>> >> On 25 July 2018 at 11:09, Hongbo Zhang wrote:
>> >>> On 25 July 2018 at
On 25 July 2018 at 17:54, Andrew Jones wrote:
> On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
>> For the Aarch64, there is one machine 'virt', it is primarily meant to
>> run on KVM and execute virtualization workloads, but we need an
>> environment as faithful as possible to
On Wed, Jul 25, 2018 at 11:47:39AM +0200, Ard Biesheuvel wrote:
> On 25 July 2018 at 11:40, Andrew Jones wrote:
> > On Wed, Jul 25, 2018 at 11:20:03AM +0200, Ard Biesheuvel wrote:
> >> On 25 July 2018 at 11:17, Hongbo Zhang wrote:
> >> > On 25 July 2018 at 17:13, Ard Biesheuvel
> >> > wrote:
>
On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
> For the Aarch64, there is one machine 'virt', it is primarily meant to
> run on KVM and execute virtualization workloads, but we need an
> environment as faithful as possible to physical hardware, for supporting
> firmware and OS
On 25 July 2018 at 11:40, Andrew Jones wrote:
> On Wed, Jul 25, 2018 at 11:20:03AM +0200, Ard Biesheuvel wrote:
>> On 25 July 2018 at 11:17, Hongbo Zhang wrote:
>> > On 25 July 2018 at 17:13, Ard Biesheuvel wrote:
>> >> On 25 July 2018 at 11:09, Hongbo Zhang wrote:
>> >>> On 25 July 2018 at
On 25 July 2018 at 17:18, Daniel P. Berrangé wrote:
> On Wed, Jul 25, 2018 at 05:05:06PM +0800, Hongbo Zhang wrote:
>> On 25 July 2018 at 16:48, Daniel P. Berrangé wrote:
>> > On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
>> >> For the Aarch64, there is one machine 'virt', it is
On Wed, Jul 25, 2018 at 11:20:03AM +0200, Ard Biesheuvel wrote:
> On 25 July 2018 at 11:17, Hongbo Zhang wrote:
> > On 25 July 2018 at 17:13, Ard Biesheuvel wrote:
> >> On 25 July 2018 at 11:09, Hongbo Zhang wrote:
> >>> On 25 July 2018 at 17:01, Ard Biesheuvel
> >>> wrote:
> On 25 July
On 25 July 2018 at 11:17, Hongbo Zhang wrote:
> On 25 July 2018 at 17:13, Ard Biesheuvel wrote:
>> On 25 July 2018 at 11:09, Hongbo Zhang wrote:
>>> On 25 July 2018 at 17:01, Ard Biesheuvel wrote:
On 25 July 2018 at 10:48, Daniel P. Berrangé wrote:
> On Wed, Jul 25, 2018 at
On Wed, Jul 25, 2018 at 05:05:06PM +0800, Hongbo Zhang wrote:
> On 25 July 2018 at 16:48, Daniel P. Berrangé wrote:
> > On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
> >> For the Aarch64, there is one machine 'virt', it is primarily meant to
> >> run on KVM and execute
On 25 July 2018 at 17:13, Ard Biesheuvel wrote:
> On 25 July 2018 at 11:09, Hongbo Zhang wrote:
>> On 25 July 2018 at 17:01, Ard Biesheuvel wrote:
>>> On 25 July 2018 at 10:48, Daniel P. Berrangé wrote:
On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
> For the Aarch64,
On 25 July 2018 at 11:09, Hongbo Zhang wrote:
> On 25 July 2018 at 17:01, Ard Biesheuvel wrote:
>> On 25 July 2018 at 10:48, Daniel P. Berrangé wrote:
>>> On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
For the Aarch64, there is one machine 'virt', it is primarily meant to
On 25 July 2018 at 17:01, Ard Biesheuvel wrote:
> On 25 July 2018 at 10:48, Daniel P. Berrangé wrote:
>> On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
>>> For the Aarch64, there is one machine 'virt', it is primarily meant to
>>> run on KVM and execute virtualization workloads,
On 25 July 2018 at 10:48, Daniel P. Berrangé wrote:
> On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
>> For the Aarch64, there is one machine 'virt', it is primarily meant to
>> run on KVM and execute virtualization workloads, but we need an
>> environment as faithful as possible
On 25 July 2018 at 16:48, Daniel P. Berrangé wrote:
> On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
>> For the Aarch64, there is one machine 'virt', it is primarily meant to
>> run on KVM and execute virtualization workloads, but we need an
>> environment as faithful as possible
On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
> For the Aarch64, there is one machine 'virt', it is primarily meant to
> run on KVM and execute virtualization workloads, but we need an
> environment as faithful as possible to physical hardware, for supporting
> firmware and OS
On 25 July 2018 at 15:20, Shannon Zhao wrote:
> Hi Hongbo,
>
Hi Shannon,
> On 2018/7/25 13:30, Hongbo Zhang wrote:
>> For the Aarch64, there is one machine 'virt', it is primarily meant to
>> run on KVM and execute virtualization workloads, but we need an
>> environment as faithful as possible
Hi Hongbo,
On 2018/7/25 13:30, Hongbo Zhang wrote:
> For the Aarch64, there is one machine 'virt', it is primarily meant to
> run on KVM and execute virtualization workloads, but we need an
> environment as faithful as possible to physical hardware, for supporting
> firmware and OS development
For the Aarch64, there is one machine 'virt', it is primarily meant to
run on KVM and execute virtualization workloads, but we need an
environment as faithful as possible to physical hardware, for supporting
firmware and OS development for pysical Aarch64 machines.
This patch introduces new
90 matches
Mail list logo
