On Wed, May 8, 2013 at 3:17 PM, Catalin Marinas wrote:
> On Tue, May 07, 2013 at 04:58:23PM +0100, Peter Maydell wrote:
>> On 7 May 2013 16:52, Christopher Covington wrote:
>> This mixes up "information that the user provides to the
>> kernel" (ie configuration) with "information that QEMU or
>>
On Tue, May 07, 2013 at 04:58:23PM +0100, Peter Maydell wrote:
> On 7 May 2013 16:52, Christopher Covington wrote:
> > On 05/07/2013 08:19 AM, Peter Maydell wrote:
> >> Well, at the moment EARLY_PRINTK is hardcoded to
> >> "use some specific UART or equivalent selected at
> >> compile time". So th
On 7 May 2013 16:52, Christopher Covington wrote:
> On 05/07/2013 08:19 AM, Peter Maydell wrote:
>> Well, at the moment EARLY_PRINTK is hardcoded to
>> "use some specific UART or equivalent selected at
>> compile time". So the equivalent presumably would
>> be to hard-compile "use virtio-console",
On 05/07/2013 08:19 AM, Peter Maydell wrote:
> On 7 May 2013 05:46, Rusty Russell wrote:
>> Peter Maydell writes:
>>> That all looks like sensible QEMU implementation possibilities
>>> but it seems to be a bit of a non-sequitur from "how do we
>>> tell the kernel to actually use this?"
>>
>> You
On 7 May 2013 05:46, Rusty Russell wrote:
> Peter Maydell writes:
>> That all looks like sensible QEMU implementation possibilities
>> but it seems to be a bit of a non-sequitur from "how do we
>> tell the kernel to actually use this?"
>
> You enable the feature in the virtio console device, and
Peter Maydell writes:
> On 6 May 2013 06:11, Rusty Russell wrote:
>> Peter Maydell writes:
>>> To be actually useful we need to also specify something in
>>> the device tree to say "here is where you will find your
>>> emergency output and what it is".
>>
>> Hmm, I'm not sure that's true. It lo
Hi Rusty,
On 6 May 2013 10:41, Rusty Russell wrote:
> Peter Maydell writes:
>> On 1 May 2013 03:07, Rusty Russell wrote:
>>> An emergency output is a reasonable idea, and this is a reasonable
>>> implementation. The question is practical: will it be used? Because we
>>> don't implement reason
On 6 May 2013 06:11, Rusty Russell wrote:
> Peter Maydell writes:
>> To be actually useful we need to also specify something in
>> the device tree to say "here is where you will find your
>> emergency output and what it is".
>
> Hmm, I'm not sure that's true. It looks like it needs:
>
> 1) An en
Peter Maydell writes:
> On 1 May 2013 03:07, Rusty Russell wrote:
>> An emergency output is a reasonable idea, and this is a reasonable
>> implementation. The question is practical: will it be used? Because we
>> don't implement reasonable ideas which aren't going to be used.
>
> If you think i
On 1 May 2013 03:07, Rusty Russell wrote:
> An emergency output is a reasonable idea, and this is a reasonable
> implementation. The question is practical: will it be used? Because we
> don't implement reasonable ideas which aren't going to be used.
If you think it fits reasonably into the virt
On Wed, May 01, 2013 at 07:53:49AM +0100, Anup Patel wrote:
> On Wed, May 1, 2013 at 7:37 AM, Rusty Russell wrote:
> > Alexander Graf writes:
> >> There are not device specific registers in
> >> virtio-console. Virtio-console lives behind a virtio bus which doesn't
> >> know what these registers
On Wed, May 1, 2013 at 7:37 AM, Rusty Russell wrote:
> Alexander Graf writes:
>> There are not device specific registers in
>> virtio-console. Virtio-console lives behind a virtio bus which doesn't
>> know what these registers are.
>
> You're not going to make coherent arguments without reading t
Alexander Graf writes:
> There are not device specific registers in
> virtio-console. Virtio-console lives behind a virtio bus which doesn't
> know what these registers are.
You're not going to make coherent arguments without reading that actual
patch we're discussing. And you're going to just w
On Wed, May 1, 2013 at 5:56 AM, Alexander Graf wrote:
>
> On 30.04.2013, at 02:32, Rusty Russell wrote:
>
>> Alexander Graf writes:
>>> Am 29.04.2013 um 05:09 schrieb Rusty Russell :
>>>
Alexander Graf writes:
> On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:
>
>> This
On 30.04.2013, at 02:32, Rusty Russell wrote:
> Alexander Graf writes:
>> Am 29.04.2013 um 05:09 schrieb Rusty Russell :
>>
>>> Alexander Graf writes:
On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:
> This patch-set implements early printk support for virtio console dev
Alexander Graf writes:
> Am 29.04.2013 um 05:09 schrieb Rusty Russell :
>
>> Alexander Graf writes:
>>> On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:
>>>
This patch-set implements early printk support for virtio console devices
without using any hypercalls.
The c
On 29.04.2013, at 14:50, Peter Maydell wrote:
> On 29 April 2013 13:22, Alexander Graf wrote:
>> Oh, and it should default to off.
>
> That would be a pretty unhelpful default. We should default
> things so that console output from the kernel is available
> as early as reasonably possible by de
On 29.04.2013, at 14:48, Pranavkumar Sawargaonkar wrote:
> On 29 April 2013 17:52, Alexander Graf wrote:
>>
>>
>> Am 29.04.2013 um 05:09 schrieb Rusty Russell :
>>
>>> Alexander Graf writes:
On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:
> This patch-set implements e
On 29 April 2013 13:22, Alexander Graf wrote:
> Oh, and it should default to off.
That would be a pretty unhelpful default. We should default
things so that console output from the kernel is available
as early as reasonably possible by default IMHO -- this
reduces the number of "nothing happens"
On 29 April 2013 17:52, Alexander Graf wrote:
>
>
> Am 29.04.2013 um 05:09 schrieb Rusty Russell :
>
>> Alexander Graf writes:
>>> On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:
>>>
This patch-set implements early printk support for virtio console devices
without using any hy
Am 29.04.2013 um 05:09 schrieb Rusty Russell :
> Alexander Graf writes:
>> On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:
>>
>>> This patch-set implements early printk support for virtio console devices
>>> without using any hypercalls.
>>>
>>> The current virtio early printk code
Alexander Graf writes:
> On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:
>
>> This patch-set implements early printk support for virtio console devices
>> without using any hypercalls.
>>
>> The current virtio early printk code in kernel expects that hypervisor will
>> provide some mec
On 26/04/13 16:03, Arnd Bergmann wrote:
> On Friday 26 April 2013, Anup Patel wrote:
>> I am curious about how smh-based or hypercall-based early prints would
>> be handled in following scenario:
>>
>> "A board is running KVM ARM enabled kernel and linux console on serial
>> port. Now a user remote
On 26 April 2013 13:33, Arnd Bergmann wrote:
> Couldn't kvmtool implement the interface used by smh_printch()
> for early output instead?
>
> Or if that's not a fitting inteface, maybe a psci call for writing
> a character to the console?
I suggested that earlier:
https://lists.cs.columbia.edu/pi
On Friday 26 April 2013, Anup Patel wrote:
> I am curious about how smh-based or hypercall-based early prints would
> be handled in following scenario:
>
> "A board is running KVM ARM enabled kernel and linux console on serial
> port. Now a user remotely connects to the board via telnet/ssh and
>
On 26 April 2013 18:03, Arnd Bergmann wrote:
> On Friday 26 April 2013 17:36:16 Anup Patel wrote:
>> On 26 April 2013 17:03, Peter Maydell wrote:
>> > On 26 April 2013 12:19, Alexander Graf wrote:
>> >> MMIO registers are handled by a different layer than the virtio
>> >> console itself. After t
On Friday 26 April 2013 17:36:16 Anup Patel wrote:
> On 26 April 2013 17:03, Peter Maydell wrote:
> > On 26 April 2013 12:19, Alexander Graf wrote:
> >> MMIO registers are handled by a different layer than the virtio
> >> console itself. After the virtio refactoring in QEMU, they will
> >> be com
On 26 April 2013 17:03, Peter Maydell wrote:
> On 26 April 2013 12:19, Alexander Graf wrote:
>> MMIO registers are handled by a different layer than the virtio
>> console itself. After the virtio refactoring in QEMU, they will
>> be completely separate drivers.
>
> Good point -- we don't really w
On 26 April 2013 12:19, Alexander Graf wrote:
> MMIO registers are handled by a different layer than the virtio
> console itself. After the virtio refactoring in QEMU, they will
> be completely separate drivers.
Good point -- we don't really want to be mixing up the
transport and the backend. You
On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:
> This patch-set implements early printk support for virtio console devices
> without using any hypercalls.
>
> The current virtio early printk code in kernel expects that hypervisor will
> provide some mechanism generally a hypercall to
30 matches
Mail list logo
