On Sun, Feb 13, 2011 at 09:08:22AM -0600, Anthony Liguori wrote:
> On 02/13/2011 05:12 AM, David Gibson wrote:
> >On Sun, Feb 13, 2011 at 10:08:23AM +0200, Blue Swirl wrote:
> >>On Sun, Feb 13, 2011 at 1:15 AM, Benjamin Herrenschmidt
[snip]
> In KVM for x86, instead of using a secondary interface (
On Sun, Feb 13, 2011 at 08:29:05PM +0200, Blue Swirl wrote:
> On Sun, Feb 13, 2011 at 5:08 PM, Anthony Liguori
> wrote:
> > On 02/13/2011 05:12 AM, David Gibson wrote:
[snip]
> > The arguments will have to be extracted from the CPU state but I don't think
> > we'll really ever have common hyperca
On 02/13/2011 12:29 PM, Blue Swirl wrote:
On Sun, Feb 13, 2011 at 5:08 PM, Anthony Liguori wrote:
In KVM for x86, instead of using a secondary interface (like
vmmcall/vmcall), we do all of our paravirtualization using native hardware
interfaces that we can trap (PIO/MMIO).
IIUC, on Power,
On Sun, Feb 13, 2011 at 5:08 PM, Anthony Liguori wrote:
> On 02/13/2011 05:12 AM, David Gibson wrote:
>>
>> On Sun, Feb 13, 2011 at 10:08:23AM +0200, Blue Swirl wrote:
>>
>>>
>>> On Sun, Feb 13, 2011 at 1:15 AM, Benjamin Herrenschmidt
>>> wrote:
>>>
On Sun, 2011-02-13 at 00:52 +0200, B
On Sun, 2011-02-13 at 10:52 -0600, Anthony Liguori wrote:
>
> A virtual bus is just an interface. If all virtual devices that
> interact via hcalls would all reside on the same virtual bus, then
> having hypercalls registered through that interface makes sense
> because
> you can associate hyp
On Sun, 2011-02-13 at 10:48 -0600, Anthony Liguori wrote:
>
> We try very, very hard to make our paravirtualization look like real
> hardware.
Sure, that makes sense when you invent new paravirt interfaces, but that
isn't the case. Note also that our current processors do not have the
ability to
On 02/13/2011 10:17 AM, Benjamin Herrenschmidt wrote:
On Sun, 2011-02-13 at 13:40 +0100, Alexander Graf wrote:
We can surely move it to dynamic later on. I think the "proper" way
would be to populate a qdev bus and have the individual hypercall
receivers register themselves through -device c
On 02/13/2011 10:07 AM, Benjamin Herrenschmidt wrote:
On Sun, 2011-02-13 at 10:08 +0200, Blue Swirl wrote:
This is a bit of a special case, much like semihosting modes for m68k
or ARM, or like MOL hacks which were removed recently. From QEMU point
of view, the most natural way of handling th
On 02/13/2011 09:56 AM, Alexander Graf wrote:
This interface could also be used to implement hypercall based interfaces on
s390 and x86.
The arguments will have to be extracted from the CPU state but I don't think
we'll really ever have common hypercall implementations anyway so that's not a
On Sun, 2011-02-13 at 13:40 +0100, Alexander Graf wrote:
>
> We can surely move it to dynamic later on. I think the "proper" way
> would be to populate a qdev bus and have the individual hypercall
> receivers register themselves through -device creations. But Blue
> really is the expert here :).
On Sun, 2011-02-13 at 14:15 +0200, Blue Swirl wrote:
>
> Maybe it would be more complex but also emulation accuracy would be
> increased and the interfaces would be saner. We don't shortcut BIOS
> and implement its services to OS in QEMU for other machines either.
But that is not comparable. BIOS
On Sun, 2011-02-13 at 10:08 +0200, Blue Swirl wrote:
> This is a bit of a special case, much like semihosting modes for m68k
> or ARM, or like MOL hacks which were removed recently. From QEMU point
> of view, the most natural way of handling this would be hypervisor
> implemented in the guest side
On 13.02.2011, at 16:08, Anthony Liguori wrote:
> On 02/13/2011 05:12 AM, David Gibson wrote:
>> On Sun, Feb 13, 2011 at 10:08:23AM +0200, Blue Swirl wrote:
>>
>>> On Sun, Feb 13, 2011 at 1:15 AM, Benjamin Herrenschmidt
>>> wrote:
>>>
On Sun, 2011-02-13 at 00:52 +0200, Blue Swirl w
On 02/13/2011 06:40 AM, Alexander Graf wrote:
Ah, yeah. I'm still not sure what to do about it. I was going to
fold the dynamic hcall registration into the patch set before
upstreaming. But then something paulus said made me rethink whether
the dynamic registration was a good idea. Still ne
On 02/13/2011 05:12 AM, David Gibson wrote:
On Sun, Feb 13, 2011 at 10:08:23AM +0200, Blue Swirl wrote:
On Sun, Feb 13, 2011 at 1:15 AM, Benjamin Herrenschmidt
wrote:
On Sun, 2011-02-13 at 00:52 +0200, Blue Swirl wrote:
On Sat, Feb 12, 2011 at 11:00 PM, Benjamin Herrenschmi
On 13.02.2011, at 13:44, David Gibson wrote:
> On Sun, Feb 13, 2011 at 01:40:14PM +0100, Alexander Graf wrote:
>>
>> On 13.02.2011, at 12:14, David Gibson wrote:
>>
>>> On Sun, Feb 13, 2011 at 10:15:03AM +1100, Benjamin Herrenschmidt wrote:
On Sun, 2011-02-13 at 00:52 +0200, Blue Swirl wro
On Sun, Feb 13, 2011 at 2:31 PM, Alexander Graf wrote:
>
> On 13.02.2011, at 09:08, Blue Swirl wrote:
>
>> On Sun, Feb 13, 2011 at 1:15 AM, Benjamin Herrenschmidt
>> wrote:
>>> On Sun, 2011-02-13 at 00:52 +0200, Blue Swirl wrote:
On Sat, Feb 12, 2011 at 11:00 PM, Benjamin Herrenschmidt
On Sun, Feb 13, 2011 at 01:40:14PM +0100, Alexander Graf wrote:
>
> On 13.02.2011, at 12:14, David Gibson wrote:
>
> > On Sun, Feb 13, 2011 at 10:15:03AM +1100, Benjamin Herrenschmidt wrote:
> >> On Sun, 2011-02-13 at 00:52 +0200, Blue Swirl wrote:
> >>> On Sat, Feb 12, 2011 at 11:00 PM, Benjamin
On 13.02.2011, at 12:14, David Gibson wrote:
> On Sun, Feb 13, 2011 at 10:15:03AM +1100, Benjamin Herrenschmidt wrote:
>> On Sun, 2011-02-13 at 00:52 +0200, Blue Swirl wrote:
>>> On Sat, Feb 12, 2011 at 11:00 PM, Benjamin Herrenschmidt
> [snip]
>> Actually, one thing I noticed is that the current
On 13.02.2011, at 12:09, David Gibson wrote:
> On Sat, Feb 12, 2011 at 05:47:53PM +0100, Alexander Graf wrote:
>> On 12.02.2011, at 15:54, David Gibson wrote:
> [snip]
>>> @@ -267,6 +295,7 @@ static QEMUMachine spapr_machine = {
>>>.desc = "pSeries Logical Partition (PAPR compliant)",
>>>
On 13.02.2011, at 09:08, Blue Swirl wrote:
> On Sun, Feb 13, 2011 at 1:15 AM, Benjamin Herrenschmidt
> wrote:
>> On Sun, 2011-02-13 at 00:52 +0200, Blue Swirl wrote:
>>> On Sat, Feb 12, 2011 at 11:00 PM, Benjamin Herrenschmidt
>>> wrote:
On Sat, 2011-02-12 at 18:59 +0200, Blue Swirl wrote:
On Sun, Feb 13, 2011 at 1:12 PM, David Gibson
wrote:
> On Sun, Feb 13, 2011 at 10:08:23AM +0200, Blue Swirl wrote:
>> On Sun, Feb 13, 2011 at 1:15 AM, Benjamin Herrenschmidt
>> wrote:
>> > On Sun, 2011-02-13 at 00:52 +0200, Blue Swirl wrote:
>> >> On Sat, Feb 12, 2011 at 11:00 PM, Benjamin Herren
On Sat, Feb 12, 2011 at 05:47:53PM +0100, Alexander Graf wrote:
> On 12.02.2011, at 15:54, David Gibson wrote:
[snip]
> > @@ -267,6 +295,7 @@ static QEMUMachine spapr_machine = {
> > .desc = "pSeries Logical Partition (PAPR compliant)",
> > .init = ppc_spapr_init,
> > .max_cpus = 1,
>
On Sun, Feb 13, 2011 at 10:15:03AM +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2011-02-13 at 00:52 +0200, Blue Swirl wrote:
> > On Sat, Feb 12, 2011 at 11:00 PM, Benjamin Herrenschmidt
[snip]
> Actually, one thing I noticed is that the current patches David posted
> still have a single function
On Sun, Feb 13, 2011 at 10:08:23AM +0200, Blue Swirl wrote:
> On Sun, Feb 13, 2011 at 1:15 AM, Benjamin Herrenschmidt
> wrote:
> > On Sun, 2011-02-13 at 00:52 +0200, Blue Swirl wrote:
> >> On Sat, Feb 12, 2011 at 11:00 PM, Benjamin Herrenschmidt
> >> wrote:
> >> > On Sat, 2011-02-12 at 18:59 +020
On Sun, Feb 13, 2011 at 1:15 AM, Benjamin Herrenschmidt
wrote:
> On Sun, 2011-02-13 at 00:52 +0200, Blue Swirl wrote:
>> On Sat, Feb 12, 2011 at 11:00 PM, Benjamin Herrenschmidt
>> wrote:
>> > On Sat, 2011-02-12 at 18:59 +0200, Blue Swirl wrote:
>> >>
>> >> Actually I don't quite understand the n
On Sun, 2011-02-13 at 00:52 +0200, Blue Swirl wrote:
> On Sat, Feb 12, 2011 at 11:00 PM, Benjamin Herrenschmidt
> wrote:
> > On Sat, 2011-02-12 at 18:59 +0200, Blue Swirl wrote:
> >>
> >> Actually I don't quite understand the need for vty layer, why not use
> >> the chardev here directly?
> >
> >
On Sat, Feb 12, 2011 at 11:00 PM, Benjamin Herrenschmidt
wrote:
> On Sat, 2011-02-12 at 18:59 +0200, Blue Swirl wrote:
>>
>> Actually I don't quite understand the need for vty layer, why not use
>> the chardev here directly?
>
> I'm not sure what you mean here...
Maybe it would be reasonable to l
On Sat, 2011-02-12 at 18:59 +0200, Blue Swirl wrote:
>
> Actually I don't quite understand the need for vty layer, why not use
> the chardev here directly?
I'm not sure what you mean here...
Basically, the interface presented to guests is sPAPR compliant, so
virtual devices come with a bunch of
On Sat, Feb 12, 2011 at 6:47 PM, Alexander Graf wrote:
>
> On 12.02.2011, at 15:54, David Gibson wrote:
>
>> This extends the "pseries" (PAPR) machine to include a virtual IO bus
>> supporting the PAPR defined hypercall based virtual IO mechanisms.
>>
>> So far only one VIO device is provided, the
On 12.02.2011, at 15:54, David Gibson wrote:
> This extends the "pseries" (PAPR) machine to include a virtual IO bus
> supporting the PAPR defined hypercall based virtual IO mechanisms.
>
> So far only one VIO device is provided, the vty / vterm, providing
> a full console (polled only, for now)
31 matches
Mail list logo
