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 Wed, May 8, 2013 at 3:17 PM, Catalin Marinas catalin.mari...@arm.com wrote:
On Tue, May 07, 2013 at 04:58:23PM +0100, Peter Maydell wrote:
On 7 May 2013 16:52, Christopher Covington c...@codeaurora.org wrote:
This mixes up information that the user provides to the
kernel (ie configuration)
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
On Tue, May 07, 2013 at 04:58:23PM +0100, Peter Maydell wrote:
On 7 May 2013 16:52, Christopher Covington c...@codeaurora.org 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.
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
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
Peter Maydell peter.mayd...@linaro.org writes:
On 6 May 2013 06:11, Rusty Russell ru...@rustcorp.com.au wrote:
Peter Maydell peter.mayd...@linaro.org 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
On 7 May 2013 05:46, Rusty Russell ru...@rustcorp.com.au wrote:
Peter Maydell peter.mayd...@linaro.org 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
On 05/07/2013 08:19 AM, Peter Maydell wrote:
On 7 May 2013 05:46, Rusty Russell ru...@rustcorp.com.au wrote:
Peter Maydell peter.mayd...@linaro.org 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
On 7 May 2013 16:52, Christopher Covington c...@codeaurora.org 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
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
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
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
Peter Maydell peter.mayd...@linaro.org writes:
On 1 May 2013 03:07, Rusty Russell ru...@rustcorp.com.au 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
On 6 May 2013 06:11, Rusty Russell ru...@rustcorp.com.au wrote:
Peter Maydell peter.mayd...@linaro.org 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.
Hi Rusty,
On 6 May 2013 10:41, Rusty Russell ru...@rustcorp.com.au wrote:
Peter Maydell peter.mayd...@linaro.org writes:
On 1 May 2013 03:07, Rusty Russell ru...@rustcorp.com.au wrote:
An emergency output is a reasonable idea, and this is a reasonable
implementation. The question is
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
On 1 May 2013 03:07, Rusty Russell ru...@rustcorp.com.au 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
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
On Wed, May 1, 2013 at 7:37 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Alexander Graf ag...@suse.de 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
On Wed, May 01, 2013 at 07:53:49AM +0100, Anup Patel wrote:
On Wed, May 1, 2013 at 7:37 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Alexander Graf ag...@suse.de writes:
There are not device specific registers in
virtio-console. Virtio-console lives behind a virtio bus which doesn'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
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
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
Alexander Graf ag...@suse.de writes:
Am 29.04.2013 um 05:09 schrieb Rusty Russell ru...@rustcorp.com.au:
Alexander Graf ag...@suse.de writes:
On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:
This patch-set implements early printk support for virtio console devices
without using
On 30.04.2013, at 02:32, Rusty Russell wrote:
Alexander Graf ag...@suse.de writes:
Am 29.04.2013 um 05:09 schrieb Rusty Russell ru...@rustcorp.com.au:
Alexander Graf ag...@suse.de writes:
On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:
This patch-set implements early printk
On Wed, May 1, 2013 at 5:56 AM, Alexander Graf ag...@suse.de wrote:
On 30.04.2013, at 02:32, Rusty Russell wrote:
Alexander Graf ag...@suse.de writes:
Am 29.04.2013 um 05:09 schrieb Rusty Russell ru...@rustcorp.com.au:
Alexander Graf ag...@suse.de writes:
On 26.04.2013, at 13:04,
Alexander Graf ag...@suse.de 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
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
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
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
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
Am 29.04.2013 um 05:09 schrieb Rusty Russell ru...@rustcorp.com.au:
Alexander Graf ag...@suse.de 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
On 29 April 2013 17:52, Alexander Graf ag...@suse.de wrote:
Am 29.04.2013 um 05:09 schrieb Rusty Russell ru...@rustcorp.com.au:
Alexander Graf ag...@suse.de writes:
On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:
This patch-set implements early printk support for virtio console
On 29 April 2013 13:22, Alexander Graf ag...@suse.de 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
On 29.04.2013, at 14:48, Pranavkumar Sawargaonkar wrote:
On 29 April 2013 17:52, Alexander Graf ag...@suse.de wrote:
Am 29.04.2013 um 05:09 schrieb Rusty Russell ru...@rustcorp.com.au:
Alexander Graf ag...@suse.de writes:
On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:
This
On 29.04.2013, at 14:50, Peter Maydell wrote:
On 29 April 2013 13:22, Alexander Graf ag...@suse.de 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
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
Alexander Graf ag...@suse.de 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
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
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:
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
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
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
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.
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
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 support early printk. This
patch-set does not break existing
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 support early printk. This
patch-set does not break existing
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
On 26 April 2013 12:19, Alexander Graf ag...@suse.de 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
On 26 April 2013 17:03, Peter Maydell peter.mayd...@linaro.org wrote:
On 26 April 2013 12:19, Alexander Graf ag...@suse.de 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.
On Friday 26 April 2013 17:36:16 Anup Patel wrote:
On 26 April 2013 17:03, Peter Maydell peter.mayd...@linaro.org wrote:
On 26 April 2013 12:19, Alexander Graf ag...@suse.de wrote:
MMIO registers are handled by a different layer than the virtio
console itself. After the virtio refactoring
On 26 April 2013 18:03, Arnd Bergmann a...@arndb.de wrote:
On Friday 26 April 2013 17:36:16 Anup Patel wrote:
On 26 April 2013 17:03, Peter Maydell peter.mayd...@linaro.org wrote:
On 26 April 2013 12:19, Alexander Graf ag...@suse.de wrote:
MMIO registers are handled by a different layer than
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 13:33, Arnd Bergmann a...@arndb.de 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:
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 remotely connects
62 matches
Mail list logo
