Hongbo,
Take a look at last patch in: ssh://
g...@git.linaro.org/people/radoslaw.biernacki/qemu.git
branch wip_rad_new_memmap
On Wed, 30 Jan 2019 at 09:37, Ard Biesheuvel
wrote:
> On Wed, 30 Jan 2019 at 09:34, Hongbo Zhang
> wrote:
> >
> > On Tue, 29 Jan 2019 at 19:29, Ard Biesheuvel
> wrote:
On Wed, 30 Jan 2019 at 09:34, Hongbo Zhang wrote:
>
> On Tue, 29 Jan 2019 at 19:29, Ard Biesheuvel
> wrote:
> >
> > Responding to an old thread ...
> >
> > On Thu, 15 Nov 2018 at 17:05, Peter Maydell
> > wrote:
> > >
> > > On 19 October 2018 at 09:55, Hongbo Zhang wrote:
> > > > For the Aarch
On Tue, 29 Jan 2019 at 19:29, Ard Biesheuvel wrote:
>
> Responding to an old thread ...
>
> On Thu, 15 Nov 2018 at 17:05, Peter Maydell wrote:
> >
> > On 19 October 2018 at 09:55, Hongbo Zhang wrote:
> > > For the Aarch64, there is one machine 'virt', it is primarily meant to
> > > run on KVM an
Responding to an old thread ...
On Thu, 15 Nov 2018 at 17:05, Peter Maydell wrote:
>
> On 19 October 2018 at 09:55, 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 a
well, checked it again, creating an generic xhci may take much efforts
and it is far beyond than my main task of creating an arm server
platform, so I'll create a generic system ehci, it satisfies our
requirements very well, will send it out separately.
On Wed, 21 Nov 2018 at 16:35, Hongbo Zhang
On Fri, 16 Nov 2018 at 19:29, Peter Maydell wrote:
>
> On 16 November 2018 at 10:46, Hongbo Zhang wrote:
> > On Fri, 16 Nov 2018 at 00:05, Peter Maydell
> > wrote:
> >> If after you've done that this patch is still more than
> >> about 500 lines long, I would recommend that you split it
> >> up
On Wed, 5 Dec 2018 at 18:36, Leif Lindholm wrote:
>
> On Wed, Dec 05, 2018 at 05:50:23PM +0800, Hongbo Zhang wrote:
> > > > +static
> > > > +void sbsa_ref_machine_done(Notifier *notifier, void *data)
> > > > +{
> > > > +VirtMachineState *vms = container_of(notifier, VirtMachineState,
> > > > +
On Wed, Dec 05, 2018 at 05:50:23PM +0800, Hongbo Zhang wrote:
> > > +static
> > > +void sbsa_ref_machine_done(Notifier *notifier, void *data)
> > > +{
> > > +VirtMachineState *vms = container_of(notifier, VirtMachineState,
> > > + machine_done);
> > > +
On Fri, 16 Nov 2018 at 00:05, Peter Maydell wrote:
>
> On 19 October 2018 at 09:55, 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 physica
On Fri, 23 Nov 2018 at 15:14, Hongbo Zhang wrote:
>
> On Fri, 16 Nov 2018 at 00:05, Peter Maydell wrote:
> >
> > On 19 October 2018 at 09:55, Hongbo Zhang wrote:
> > > For the Aarch64, there is one machine 'virt', it is primarily meant to
> > > run on KVM and execute virtualization workloads, bu
On Fri, 16 Nov 2018 at 00:05, Peter Maydell wrote:
>
> On 19 October 2018 at 09:55, 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 physica
Well, considering all the comments/suggestions I received, I'd like to
try to create a generic sysbus xhci.
This would take some time for me, so my plan is to send out a new v5
iteration of this sbsa-ref patch with updates according to Peter's
comments, but without any xhci feature this time, and l
On Tue, 20 Nov 2018 at 09:49, Hongbo Zhang wrote:
>
> On Tue, 20 Nov 2018 at 16:16, Gerd Hoffmann wrote:
> >
> > Hi,
> >
> > > > But I assume you specifically want things that do a lot of DMA, so I
> > > > couldn't get away with asking for keeping it to the SBSA UART(s)? :)
> > >
> > > Ideally,
On Tue, 20 Nov 2018 at 16:16, Gerd Hoffmann wrote:
>
> Hi,
>
> > > But I assume you specifically want things that do a lot of DMA, so I
> > > couldn't get away with asking for keeping it to the SBSA UART(s)? :)
> >
> > Ideally, it would be something that supports platform MSIs as well,
> > but t
Hi,
> > But I assume you specifically want things that do a lot of DMA, so I
> > couldn't get away with asking for keeping it to the SBSA UART(s)? :)
>
> Ideally, it would be something that supports platform MSIs as well,
> but that is unlikely to be a priority for anyone (and i would be very
>
On Mon, 19 Nov 2018 at 08:44, Leif Lindholm wrote:
>
> On Mon, Nov 19, 2018 at 07:51:29AM -0800, Ard Biesheuvel wrote:
> > > > > I think what we *really* want is sysbus-xhci-generic.
> > > > >
> > > > > That'll be a bit more work though as xhci core and xhci pci needs to
> > > > > be
> > > > > sp
On Mon, Nov 19, 2018 at 07:51:29AM -0800, Ard Biesheuvel wrote:
> > > > I think what we *really* want is sysbus-xhci-generic.
> > > >
> > > > That'll be a bit more work though as xhci core and xhci pci needs to be
> > > > splitted, simliar to how it was done for ehci in commit
> > > > 5010d4dc618b6
On Mon, 19 Nov 2018 at 04:44, Leif Lindholm wrote:
>
> On Fri, Nov 16, 2018 at 02:04:07PM -0800, Ard Biesheuvel wrote:
> > > > > What is this using the exynos4210 USB device for? That
> > > > > is definitely not correct for a generic board.
> > > > >
> > > > Checked the code:
> > > > #define TYPE_
On Fri, Nov 16, 2018 at 02:04:07PM -0800, Ard Biesheuvel wrote:
> > > > What is this using the exynos4210 USB device for? That
> > > > is definitely not correct for a generic board.
> > > >
> > > Checked the code:
> > > #define TYPE_SYS_BUS_EHCI "sysbus-ehci-usb"
> > > #define TYPE_EXYNOS4210_EHCI
On Mon, 19 Nov 2018 at 18:49, Hongbo Zhang wrote:
>
> On Fri, 16 Nov 2018 at 19:29, Peter Maydell wrote:
> >
> > On 16 November 2018 at 10:46, Hongbo Zhang wrote:
> > > On Fri, 16 Nov 2018 at 00:05, Peter Maydell
> > > wrote:
> > >> If after you've done that this patch is still more than
> > >
On Fri, 16 Nov 2018 at 19:29, Peter Maydell wrote:
>
> On 16 November 2018 at 10:46, Hongbo Zhang wrote:
> > On Fri, 16 Nov 2018 at 00:05, Peter Maydell
> > wrote:
> >> If after you've done that this patch is still more than
> >> about 500 lines long, I would recommend that you split it
> >> up
On Fri, 16 Nov 2018 at 04:27, Gerd Hoffmann wrote:
>
> Hi,
>
> > > What is this using the exynos4210 USB device for? That
> > > is definitely not correct for a generic board.
> > >
> > Checked the code:
> > #define TYPE_SYS_BUS_EHCI "sysbus-ehci-usb"
> > #define TYPE_EXYNOS4210_EHCI "exynos4210-
Hi,
> > What is this using the exynos4210 USB device for? That
> > is definitely not correct for a generic board.
> >
> Checked the code:
> #define TYPE_SYS_BUS_EHCI "sysbus-ehci-usb"
> #define TYPE_EXYNOS4210_EHCI "exynos4210-ehci-usb"
> #define TYPE_TEGRA2_EHCI "tegra2-ehci-usb"
> #define TYPE
On 16 November 2018 at 10:46, Hongbo Zhang wrote:
> On Fri, 16 Nov 2018 at 00:05, Peter Maydell wrote:
>> If after you've done that this patch is still more than
>> about 500 lines long, I would recommend that you split it
>> up into coherent pieces, to make it easier to review.
> I think howeve
On Fri, 16 Nov 2018 at 00:05, Peter Maydell wrote:
>
> On 19 October 2018 at 09:55, 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 physica
On 19 October 2018 at 09:55, 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 p
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 machin
27 matches
Mail list logo
