On Fri, Mar 11, 2011 at 01:41:17PM -0800, Jordan Justen wrote:
> On Thu, Mar 10, 2011 at 12:21, Gleb Natapov wrote:
> > On Thu, Mar 10, 2011 at 11:50:42AM -0800, Jordan Justen wrote:
> >>
> >> So, perhaps this feature should build upon the other feature you and
> >> Jan are discussing. When will
On 2011-03-11 20:09, Jordan Justen wrote:
> On Thu, Mar 10, 2011 at 16:27, Carl-Daniel Hailfinger
> wrote:
>> Auf 11.03.2011 01:19, Jan Kiszka schrieb:
>>> At least it's an in-band interface, which is the better choice as we
>>> currently only have a PIIX3 southbridge for x86, predating even FWHs.
Hello,
On 11 March 2011 20:09, Jordan Justen wrote:
> On Thu, Mar 10, 2011 at 16:27, Carl-Daniel Hailfinger
> wrote:
>> Auf 11.03.2011 01:19, Jan Kiszka schrieb:
>>> At least it's an in-band interface, which is the better choice as we
>>> currently only have a PIIX3 southbridge for x86, predatin
On Thu, Mar 10, 2011 at 12:21, Gleb Natapov wrote:
> On Thu, Mar 10, 2011 at 11:50:42AM -0800, Jordan Justen wrote:
>>
>> So, perhaps this feature should build upon the other feature you and
>> Jan are discussing. When will it become available?
>>
> When somebody will be motivated enough to send
On Thu, Mar 10, 2011 at 16:27, Carl-Daniel Hailfinger
wrote:
> Auf 11.03.2011 01:19, Jan Kiszka schrieb:
>> At least it's an in-band interface, which is the better choice as we
>> currently only have a PIIX3 southbridge for x86, predating even FWHs.
>>
>
> Right, that pretty much kills the option
On Thu, Mar 10, 2011 at 15:41, Carl-Daniel Hailfinger
wrote:
> Auf 10.03.2011 23:58, Jordan Justen schrieb:
>> Would the firmware
>> be able to depend on having control of the device at OS runtime? This
>> would be needed for UEFI non-volatile variables to make sure they can
>> always be written.
Auf 11.03.2011 01:19, Jan Kiszka schrieb:
> On 2011-03-10 23:10, Carl-Daniel Hailfinger wrote:
>
>> Auf 10.03.2011 22:55, Jordan Justen schrieb:
>>
>>> On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger
>>> wrote:
>>>
>>>
Auf 10.03.2011 05:51, Jordan Justen schrieb:
On 2011-03-10 23:10, Carl-Daniel Hailfinger wrote:
> Auf 10.03.2011 22:55, Jordan Justen schrieb:
>> On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger
>> wrote:
>>
>>> Auf 10.03.2011 05:51, Jordan Justen schrieb:
>>>
I have documented a simple flash-like device which I think could
Auf 10.03.2011 23:58, Jordan Justen schrieb:
> On Thu, Mar 10, 2011 at 14:31, Carl-Daniel Hailfinger
> wrote:
>
>> Right, the constant size argument is definitely a point we need to talk
>> about.
>>
>> We could sidestep the issue by always using a 16 MByte flash device
>> which gets filled fro
On Thu, Mar 10, 2011 at 14:31, Carl-Daniel Hailfinger
wrote:
> Right, the constant size argument is definitely a point we need to talk
> about.
>
> We could sidestep the issue by always using a 16 MByte flash device
> which gets filled from the top with the firmware image, but I'm not sure
> if th
Auf 10.03.2011 23:14, Jordan Justen schrieb:
> On Thu, Mar 10, 2011 at 13:52, Carl-Daniel Hailfinger
> wrote:
>
>> Auf 10.03.2011 19:43, Jordan Justen schrieb:
>>
>>> I thought this might be a case where deviation from real hardware
>>> emulation could better serve the VM's needs.
>>>
On Thu, Mar 10, 2011 at 13:52, Carl-Daniel Hailfinger
wrote:
> Auf 10.03.2011 19:43, Jordan Justen schrieb:
>> I thought this might be a case where deviation from real hardware
>> emulation could better serve the VM's needs.
>>
>
> If we have to write the code anyway, and if it can work just fine
On Thu, 10 Mar 2011 22:46:34 +0100
Carl-Daniel Hailfinger wrote:
> Auf 10.03.2011 13:06, Jan Kiszka schrieb:
> > I'm thinking beyond this use case, beyond firmware flashes, beyond x86.
> >
>
> If you're thinking beyond x86, most flash is probably using SPI nowadays
> because the reduced PCB f
On Thu, Mar 10, 2011 at 13:41, Carl-Daniel Hailfinger
wrote:
> Auf 10.03.2011 12:48, Gleb Natapov schrieb:
>> Yes we can make memory slot that will be treated as memory on read and
>> IO on write, but first relying on that will prevent using flash interface
>> on older kernels and second it is not
Auf 10.03.2011 19:43, Jordan Justen schrieb:
> On Thu, Mar 10, 2011 at 01:10, Avi Kivity wrote:
>
>> On 03/10/2011 06:51 AM, Jordan Justen wrote:
>>
>>> http://wiki.qemu.org/Features/System_Flash
>>>
>>>
>> - make the programming interface the same as an existing device
>>
> Ho
Auf 10.03.2011 13:06, Jan Kiszka schrieb:
> BTW, the programming granularity is not bytes but chips with common CFI.
> But that's still tricky if you want to run code from the same chip while
> updating parts of it. The easiest workaround would be handling the
> overlay regions as ROM all the time.
Auf 10.03.2011 12:48, Gleb Natapov schrieb:
> On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote:
>
>> On 2011-03-10 10:47, Gleb Natapov wrote:
>>
>>> Second. I asked how flash is programmed because interfaces like CFI
>>> where you write into flash memory address range to issue com
On Thu, Mar 10, 2011 at 11:50:42AM -0800, Jordan Justen wrote:
> > It is not even about performance (which will be very bad for 1MB). KVM
> > can't run code from MMIO region, so the part that contains firmware
> > has to be memory.
>
> Hmm. That's good to know. :)
>
> So, perhaps this feature sh
As I'm working on bootrom loading support for omap/arm platform, I'm
have suggestion about something more universal than -bios (and even
-flash) option. Because Flash can be NOR, can be NAND, but on-chip
memory is not flash memory. So may be something like -rom option?
Best regards,
Anton Kochkov.
On Thu, Mar 10, 2011 at 11:23, Anthony Liguori wrote:
> If you implement a CSM for Tiano Core, then you won't need to use any
> special parameters because we can just use OVMF by default ;-)
Sorry, but I can't do this. This is unlikely to change anytime soon.
But, if someone seeks to put forth
On Thu, Mar 10, 2011 at 11:12, Gleb Natapov wrote:
> On Thu, Mar 10, 2011 at 10:59:07AM -0800, Jordan Justen wrote:
>> Yes, this definitely could add firmware upgrade issues, but I thought
>> this could be the responsibility of the firmware itself. For example,
>> OVMF could have an outside of VM
On 03/10/2011 01:03 PM, Jordan Justen wrote:
On Thu, Mar 10, 2011 at 03:46, Jan Kiszka wrote:
On 2011-03-10 12:27, Jan Kiszka wrote:
On 2011-03-10 10:47, Gleb Natapov wrote:
My suggestion is to extend
-bios option like this:
-bios bios.bin,flash=flash.bin,flash_base=addr
flash.bin will be m
On Thu, Mar 10, 2011 at 11:08:32AM -0800, Jordan Justen wrote:
> On Thu, Mar 10, 2011 at 04:27, Jan Kiszka wrote:
> > On 2011-03-10 13:17, Gleb Natapov wrote:
> >> So flash will be always IO and overlay will be always ROM. This will
> >
> > Yes, and once we have KVM support for read-RAM/write-IO s
On Thu, Mar 10, 2011 at 10:59:07AM -0800, Jordan Justen wrote:
> On Thu, Mar 10, 2011 at 01:47, Gleb Natapov wrote:
> > Two things. First You suggest to replace -bios with -flash. This will
> > make firmware upgrade painful process that will have to be performed
> > from inside the guest since the
On Thu, Mar 10, 2011 at 04:27, Jan Kiszka wrote:
> On 2011-03-10 13:17, Gleb Natapov wrote:
>> So flash will be always IO and overlay will be always ROM. This will
>
> Yes, and once we have KVM support for read-RAM/write-IO slots, flash
> will be able to switch between ROM and IO mode just like it
On Thu, Mar 10, 2011 at 03:46, Jan Kiszka wrote:
> On 2011-03-10 12:27, Jan Kiszka wrote:
>> On 2011-03-10 10:47, Gleb Natapov wrote:
>>> My suggestion is to extend
>>> -bios option like this:
>>>
>>> -bios bios.bin,flash=flash.bin,flash_base=addr
>>>
>>> flash.bin will be mapped at address flash_
On Thu, Mar 10, 2011 at 01:47, Gleb Natapov wrote:
> Two things. First You suggest to replace -bios with -flash. This will
> make firmware upgrade painful process that will have to be performed
> from inside the guest since the same flash image will contain both
> firmware and whatever data was st
On Thu, Mar 10, 2011 at 01:10, Avi Kivity wrote:
> On 03/10/2011 06:51 AM, Jordan Justen wrote:
>>
>> http://wiki.qemu.org/Features/System_Flash
>>
>
> - make the programming interface the same as an existing device
How strongly do you feel about this?
For one thing, real devices are not as flex
On 2011-03-10 12:53, Paolo Bonzini wrote:
> On 03/10/2011 12:46 PM, Jan Kiszka wrote:
>> Better define flash chips as qdev devices and make the attributes qdev
>> properties:
>>
>> -device flash,image=...,base=...,overlay=...,overlay_start=...
>>
>> Images should be addressed by block device I
On 2011-03-10 13:17, Gleb Natapov wrote:
> On Thu, Mar 10, 2011 at 01:06:14PM +0100, Jan Kiszka wrote:
>> On 2011-03-10 12:48, Gleb Natapov wrote:
>>> On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote:
On 2011-03-10 10:47, Gleb Natapov wrote:
> On Wed, Mar 09, 2011 at 08:51:23PM -
On Thu, Mar 10, 2011 at 01:06:14PM +0100, Jan Kiszka wrote:
> On 2011-03-10 12:48, Gleb Natapov wrote:
> > On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote:
> >> On 2011-03-10 10:47, Gleb Natapov wrote:
> >>> On Wed, Mar 09, 2011 at 08:51:23PM -0800, Jordan Justen wrote:
> Hi all,
>
On 2011-03-10 12:48, Gleb Natapov wrote:
> On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote:
>> On 2011-03-10 10:47, Gleb Natapov wrote:
>>> On Wed, Mar 09, 2011 at 08:51:23PM -0800, Jordan Justen wrote:
Hi all,
I have documented a simple flash-like device which I think cou
On 03/10/2011 12:46 PM, Jan Kiszka wrote:
Better define flash chips as qdev devices and make the attributes qdev
properties:
-device flash,image=...,base=...,overlay=...,overlay_start=...
Images should be addressed by block device IDs and created via '-drive'
(likely requires a new interfa
On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote:
> On 2011-03-10 10:47, Gleb Natapov wrote:
> > On Wed, Mar 09, 2011 at 08:51:23PM -0800, Jordan Justen wrote:
> >> Hi all,
> >>
> >> I have documented a simple flash-like device which I think could be
> >> useful for qemu/kvm in some cases
On 2011-03-10 12:27, Jan Kiszka wrote:
> On 2011-03-10 10:47, Gleb Natapov wrote:
>> On Wed, Mar 09, 2011 at 08:51:23PM -0800, Jordan Justen wrote:
>>> Hi all,
>>>
>>> I have documented a simple flash-like device which I think could be
>>> useful for qemu/kvm in some cases. (Particularly for allow
On 2011-03-10 10:47, Gleb Natapov wrote:
> On Wed, Mar 09, 2011 at 08:51:23PM -0800, Jordan Justen wrote:
>> Hi all,
>>
>> I have documented a simple flash-like device which I think could be
>> useful for qemu/kvm in some cases. (Particularly for allowing
>> persistent UEFI non-volatile variables.
On Wed, Mar 09, 2011 at 08:51:23PM -0800, Jordan Justen wrote:
> Hi all,
>
> I have documented a simple flash-like device which I think could be
> useful for qemu/kvm in some cases. (Particularly for allowing
> persistent UEFI non-volatile variables.)
>
> http://wiki.qemu.org/Features/System_Fla
On 03/10/2011 06:51 AM, Jordan Justen wrote:
Hi all,
I have documented a simple flash-like device which I think could be
useful for qemu/kvm in some cases. (Particularly for allowing
persistent UEFI non-volatile variables.)
http://wiki.qemu.org/Features/System_Flash
Let me know if you have an
38 matches
Mail list logo
