On Mon, Feb 29, 2016 at 05:30:36PM +0100, Andrea Bolognani wrote:
> On Mon, 2016-02-22 at 09:35 +0800, Peter Xu wrote:
> > On Fri, Feb 19, 2016 at 01:33:09PM +0100, Andrea Bolognani wrote:
> > >
> > > I didn't say it would be hard :)
> > >
> > > I just said that such compatibility code would have
On Mon, 2016-02-22 at 09:35 +0800, Peter Xu wrote:
> On Fri, Feb 19, 2016 at 01:33:09PM +0100, Andrea Bolognani wrote:
> >
> > I didn't say it would be hard :)
> >
> > I just said that such compatibility code would have to be kept
> > around forever. We already support lots and lots of similar ca
On Fri, Feb 19, 2016 at 01:33:09PM +0100, Andrea Bolognani wrote:
> I didn't say it would be hard :)
>
> I just said that such compatibility code would have to be kept
> around forever. We already support lots and lots of similar cases
> in libvirt, the difference being that in this case we would
On Fri, 2016-02-19 at 09:55 +0800, Peter Xu wrote:
> > AFAIK, the current situation of libvirt passing the GIC version to
> > QEMU and simply reporting in case of failure is not unprecedented
> > and there are a few cases where probing in advance would simply not
> > be feasible.
> >
> > Any probi
On Thu, Feb 18, 2016 at 06:10:21PM +0100, Andrea Bolognani wrote:
> On Thu, 2016-02-18 at 17:52 +0100, Andrew Jones wrote:
> > > Is this work on any of our todo list (or anyone has started the
> > > prototyping)?
> > >
> > > It seems reasonable to provide such a generic interface, rather than
> >
On Thu, 2016-02-18 at 17:52 +0100, Andrew Jones wrote:
> > Is this work on any of our todo list (or anyone has started the
> > prototyping)?
> >
> > It seems reasonable to provide such a generic interface, rather than
> > adding a "query-gic-capability" for GIC versions only. The problem
> > is th
On Thu, Feb 18, 2016 at 12:40:56PM +0800, Peter Xu wrote:
> On Mon, Feb 15, 2016 at 03:22:05PM +, Daniel P. Berrange wrote:
> > On Mon, Feb 15, 2016 at 04:08:33PM +0100, Markus Armbruster wrote:
> > > Peter Xu writes:
> > >
> > > > On Mon, Feb 15, 2016 at 10:52:01AM +0100, Markus Armbruster w
On Mon, Feb 15, 2016 at 03:22:05PM +, Daniel P. Berrange wrote:
> On Mon, Feb 15, 2016 at 04:08:33PM +0100, Markus Armbruster wrote:
> > Peter Xu writes:
> >
> > > On Mon, Feb 15, 2016 at 10:52:01AM +0100, Markus Armbruster wrote:
> > >> Peter Xu writes:
> > >>
> > >> > For ARM platform, we
On Tue, 2016-02-16 at 12:38 +, Daniel P. Berrange wrote:
> > > Regardless of the way it is exposed in libvirt API, when libvirt probes
> > > for capabilities it will *always* use '-m none'.
> >
> > Domain capabilities are currently derived almost entirely from data
> > taken from virQEMUCaps,
On Tue, Feb 16, 2016 at 01:27:55PM +0100, Andrea Bolognani wrote:
> On Tue, 2016-02-16 at 12:15 +, Daniel P. Berrange wrote:
> > On Tue, Feb 16, 2016 at 01:05:45PM +0100, Andrea Bolognani wrote:
> > > On Tue, 2016-02-16 at 10:15 +, Daniel P. Berrange wrote:
> > > > > Back to GIV. Recognize
On Tue, 2016-02-16 at 12:15 +, Daniel P. Berrange wrote:
> On Tue, Feb 16, 2016 at 01:05:45PM +0100, Andrea Bolognani wrote:
> > On Tue, 2016-02-16 at 10:15 +, Daniel P. Berrange wrote:
> > > > Back to GIV. Recognized values of gic-version are fixed at compile
> > > > time: 2, 3, host. On
On Tue, 2016-02-16 at 12:09 +, Peter Maydell wrote:
> On 16 February 2016 at 12:05, Andrea Bolognani wrote:
> > The idea is to add this information to domain capabilities, which
> > already have virtualization type, architecture and machine type as
> > inputs.
> >
> > Since GIC is only availa
On Tue, Feb 16, 2016 at 01:05:45PM +0100, Andrea Bolognani wrote:
> On Tue, 2016-02-16 at 10:15 +, Daniel P. Berrange wrote:
> > > Back to GIV. Recognized values of gic-version are fixed at compile
> > > time: 2, 3, host. Once again, QOM does things in code rather than data:
> > > the set of
On 16 February 2016 at 12:05, Andrea Bolognani wrote:
> The idea is to add this information to domain capabilities, which
> already have virtualization type, architecture and machine type as
> inputs.
>
> Since GIC is only available for the virt machine type on ARM hosts,
> and the GIC versions mi
On Tue, 2016-02-16 at 10:15 +, Daniel P. Berrange wrote:
> > Back to GIV. Recognized values of gic-version are fixed at compile
> > time: 2, 3, host. Once again, QOM does things in code rather than data:
> > the set of values is defined in the setter function
> > virt_set_gic_version().
> >
On Tue, Feb 16, 2016 at 11:10:55AM +0100, Markus Armbruster wrote:
> Peter Maydell writes:
>
> > On 15 February 2016 at 20:18, Andrew Jones wrote:
> >> On Mon, Feb 15, 2016 at 08:40:54PM +0100, Markus Armbruster wrote:
> >>> How would the command line look like?
> >>>
> >>
> >> Here is what is a
Peter Maydell writes:
> On 15 February 2016 at 20:18, Andrew Jones wrote:
>> On Mon, Feb 15, 2016 at 08:40:54PM +0100, Markus Armbruster wrote:
>>> How would the command line look like?
>>>
>>
>> Here is what is available today
>>
>> # select gicv2 (this work with and without KVM)
>> qemu-system
On 15 February 2016 at 20:18, Andrew Jones wrote:
> On Mon, Feb 15, 2016 at 08:40:54PM +0100, Markus Armbruster wrote:
>> How would the command line look like?
>>
>
> Here is what is available today
>
> # select gicv2 (this work with and without KVM)
> qemu-system-aarch64 -M virt
On Mon, Feb 15, 2016 at 08:40:54PM +0100, Markus Armbruster wrote:
> Peter Maydell writes:
>
> > On 15 February 2016 at 15:08, Markus Armbruster wrote:
> >> Peter Xu writes:
> >>> On Mon, Feb 15, 2016 at 10:52:01AM +0100, Markus Armbruster wrote:
> Peter Xu writes:
> Adding ad hoc qu
Peter Maydell writes:
> On 15 February 2016 at 15:08, Markus Armbruster wrote:
>> Peter Xu writes:
>>> On Mon, Feb 15, 2016 at 10:52:01AM +0100, Markus Armbruster wrote:
Peter Xu writes:
Adding ad hoc queries as we go won't scale. Is there really no generic
way to get this info
On Mon, Feb 15, 2016 at 04:08:33PM +0100, Markus Armbruster wrote:
> Peter Xu writes:
>
> > On Mon, Feb 15, 2016 at 10:52:01AM +0100, Markus Armbruster wrote:
> >> Peter Xu writes:
> >>
> >> > For ARM platform, we still do not have any interface to query
> >> > whether current QEMU/host support
On 15 February 2016 at 15:08, Markus Armbruster wrote:
> Peter Xu writes:
>> On Mon, Feb 15, 2016 at 10:52:01AM +0100, Markus Armbruster wrote:
>>> Peter Xu writes:
>>> Adding ad hoc queries as we go won't scale. Is there really no generic
>>> way to get this information, e.g. with qom-get?
>>
Peter Xu writes:
> On Mon, Feb 15, 2016 at 10:52:01AM +0100, Markus Armbruster wrote:
>> Peter Xu writes:
>>
>> > For ARM platform, we still do not have any interface to query
>> > whether current QEMU/host support specific GIC version. This
>> > patchset is trying to add one QMP interface for
Hello!
> I know Pavel Fedin was trying to revive kernel_irqchip=off once,
> but I don't know if that effort was abandoned or not.
It should work with the latest kernel, at least i posted patches and all of
them were applied. If nothing got broken during later
rewrites.
The only missing part i
On Mon, Feb 15, 2016 at 09:41:57AM +, Peter Maydell wrote:
> On 15 February 2016 at 09:35, Martin Kletzander wrote:
> > So hardware itself supports some GIC version, let's say 3 for our case.
> > Does that mean it can be triggered to do v2 as well? I mean is it
> > possible that HW supports m
On Mon, Feb 15, 2016 at 10:52:01AM +0100, Markus Armbruster wrote:
> Peter Xu writes:
>
> > For ARM platform, we still do not have any interface to query
> > whether current QEMU/host support specific GIC version. This
> > patchset is trying to add one QMP interface for that. By querying
> > the
Peter Xu writes:
> For ARM platform, we still do not have any interface to query
> whether current QEMU/host support specific GIC version. This
> patchset is trying to add one QMP interface for that. By querying
> the GIC capability using the new interface, one should know exactly
> what GIC vers
On 15 February 2016 at 09:35, Martin Kletzander wrote:
> So hardware itself supports some GIC version, let's say 3 for our case.
> Does that mean it can be triggered to do v2 as well? I mean is it
> possible that HW supports multiple versions? If yes, then I suspect
> there is (will be) HW that
On Mon, 02/15 15:34, Peter Xu wrote:
> On Mon, Feb 15, 2016 at 12:54:57AM -0600, Wei Huang wrote:
> > On 2/13/16 23:41, Peter Xu wrote:
> > > One question: how should I make this command "ARM only"? I see that
> > > in qmp-commands.hx, I can use something like "#if defined
> > > TARGET_ARM" to bloc
29 matches
Mail list logo
