On Thu, Apr 7, 2011 at 12:21, Anthony Liguori wrote:
> QEMU does the leg work already to support SMM. It doesn't work with KVM
> because we treat SMM as ROM memory and trap read/write access.
>
> To make it work with KVM, you'd have to hack things around to switch the VGA
> space to RAM in order
On Thu, Apr 7, 2011 at 11:44, Gleb Natapov wrote:
> On Thu, Apr 07, 2011 at 01:37:14PM -0500, Anthony Liguori wrote:
>> The CS base starts out at 0xf and IP is 0xfff0. That gives a
>> real address of 0x0. This is usually a trampoline to somewhere
>> else in the space.
>> >>>C
On Thu, Apr 7, 2011 at 09:08, Anthony Liguori wrote:
> On 04/07/2011 10:51 AM, Gleb Natapov wrote:
>> That may seams to be impossible but it is how HW works. And this is how
>> QEMU emulates it. Look at target-i386/helper.c:cpu_reset()
>>
>> cpu_x86_load_seg_cache(env, R_CS, 0xf000, 0x
This initial version covers the generic portions of fw_cfg and
the x86/x86-64 architecture specific portions of fw_cfg.
Signed-off-by: Jordan Justen
---
docs/specs/fw_cfg.txt | 168 +
1 files changed, 168 insertions(+), 0 deletions(-)
create
When checking pfl->rom_mode for when to lazily reenter ROMD mode,
the value was check was the opposite of what it should have been.
This prevent the part from returning to ROMD mode after a write
was made to the CFI rom region.
Signed-off-by: Jordan Justen
---
hw/pflash_cfi02.c |2 +-
just below
4GB in place of the normal rom image.
Signed-off-by: Jordan Justen
---
default-configs/i386-softmmu.mak |1 +
default-configs/x86_64-softmmu.mak |1 +
hw/pc.c| 161 +++-
3 files changed, 125 insertions(+), 38 deletion
2011/3/24 Gleb Natapov :
> On Wed, Mar 23, 2011 at 03:32:41PM -0700, Jordan Justen wrote:
>> By the way, today OVMF attempts to store NV-Var data in a file on the
>> disk, but this cannot support variables at runtime. (This is why I
>> sent in the patch for using -pflash on
2011/3/23 Gleb Natapov :
> On Tue, Mar 22, 2011 at 02:53:16PM -0700, Jordan Justen wrote:
>> To support a boot override for UEFI, this full path would be needed.
>> For the purposes of a UEFI boot override, could the user could provide
>> the partition & path info?
>&g
2011/3/22 Gleb Natapov :
> On Tue, Mar 22, 2011 at 12:28:51PM -0700, Jordan Justen wrote:
>> Can this cover a full path like this?
>> /pci@i0cf8/ide@1,1/drive@1/disk@0 => partition0 => /path/abc.efi
>>
> Open Firmware have syntax for that.
> /pci@i0cf8/ide@1,1/dri
2011/3/22 Gleb Natapov :
> On Mon, Mar 21, 2011 at 02:23:31PM -0700, Jordan Justen wrote:
>> There is one big difference here between how VM's generally specify
>> the boot disk vs. a UEFI system. In a UEFI system, normally the boot
>> path is not known during the firs
On Mon, Mar 21, 2011 at 14:17, Michael Brown wrote:
> On Monday 21 Mar 2011 21:06:24 Stefan Hajnoczi wrote:
>> On Mon, Mar 21, 2011 at 6:27 PM, Anthony Liguori
>> > Is there gPXE for UEFI yet?
>>
>> I have never tried it myself, but I think it should work. CCed
>> Michael Brown to check.
>
> Yes
On Mon, Mar 21, 2011 at 11:27, Anthony Liguori wrote:
> On 03/21/2011 01:14 PM, Jordan Justen wrote:
>>
>> This weekend I spent some time working on loading SeaBIOS from OVMF to
>> start a legacy boot. I was able to get x86& x86-64 Linux to legacy
>> boot using t
This weekend I spent some time working on loading SeaBIOS from OVMF to
start a legacy boot. I was able to get x86 & x86-64 Linux to legacy
boot using this method.
Unfortunately, (I think) it is not nearly as nice a having a true CSM.
Basically, you have to decide at some point in the OVMF boot t
On Sat, Mar 19, 2011 at 08:36, Bei Guan wrote:
> Does QEMU have the plan to ship with EFI firmware?
Hi. I work on the OVMF project which Stefan mentioned. I definitely
can't speak for the qemu/kvm project, but I'll give my impressions
from my OVMF perspective.
I think qemu/kvm has some interes
Thanks to everyone's feedback on my previous proposal (in particular
Jan Kiszka for pointing out hw/pflash_cfi*), I now have a second, much
simpler proposal.
http://wiki.qemu.org/Features/PC_System_Flash
One area where this deviates from some of the previous feedback is in
the command line parame
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 wi
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
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
On Thu, Mar 10, 2011 at 14: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:
>>> Is there any reason why you chose to invent an interface for the flash
>>> chip w
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 anyw
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
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 be
>> useful for qemu/kvm in some cases. (Particularly for allowing
>> persistent UEFI n
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 cou
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 thi
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 any suggestions or concerns.
Thanks for your tim
On Wed, Mar 9, 2011 at 05:43, Natalia Portillo wrote:
> This may come late in the discussion, but, has OVMF been tested with Mac OS X?
No.
I don't think Apple considers VMs an acceptable usage environment for
OS X. Please correct me if I am mistaken.
Thanks,
-Jordan
2011/3/9 Gleb Natapov :
> On Tue, Mar 08, 2011 at 09:13:38AM -0800, Jordan Justen wrote:
>> Regarding UEFI non-volatile variables on real HW:
>> Most systems today have at least 1MB of flash storage located just
>> below 4GB. The entire contents can be modified, which is ho
On Tue, Mar 8, 2011 at 18:23, Kevin O'Connor wrote:
> On Tue, Mar 08, 2011 at 09:00:05AM -0800, Jordan Justen wrote:
>> Yes, the UEFI system is still in place. The UEFI part still handles
>> the majority of platform init, and calls into the CSM at various
>> points. Th
2011/3/8 Gleb Natapov :
> On Tue, Mar 08, 2011 at 07:18:09AM +, Stefan Hajnoczi wrote:
>> > Regarding the non-volatile variables issue, I have been trying to
>> > develop a proposal for addressing this with a change to QEMU's
>> > hardware support of bios.bin. But, I don't have the suggestion
On Mon, Mar 7, 2011 at 23:18, Stefan Hajnoczi wrote:
> On Tue, Mar 8, 2011 at 12:54 AM, Jordan Justen wrote:
>> The biggest issue that you guys care about for OVMF is a lack of
>> legacy bios compatibility (CSM). There has been no progress in this
>> area. (However, it h
On Mon, Mar 7, 2011 at 01:48, Stefan Hajnoczi wrote:
> Jordan, UEFI guest firmware comes up periodically. It seems to be a
> feature that will be required in the future but as of today I don't
> know of QEMU developers who are working on or using it.
>
> Maybe you can start by giving an update on
On Sun, Mar 6, 2011 at 13:26, vagran wrote:
> > Can you try disabling KVM?
>
> Yes, it helped. Problem exists only when using KVM. Thanks.
One thing I suspect is that the kernel side of kvm had an issue around
this time (Ubuntu 9.10) with a bios.bin larger than 256kb.
With qemu 0.14.0, you could
On Sun, Mar 6, 2011 at 07:29, Michal Suchanek wrote:
> On 6 March 2011 05:12, Jordan Justen wrote:
>> I know you already have your own ideas to think of. :)
>> http://wiki.qemu.org/Google_Summer_of_Code_2011
>>
>> But, I am wondering if any of you might have som
I know you already have your own ideas to think of. :)
http://wiki.qemu.org/Google_Summer_of_Code_2011
But, I am wondering if any of you might have some UEFI or OVMF ideas for us:
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=GSOC2011
Thanks,
-Jordan
On Thu, Mar 3, 2011 at 10:02, vagran wrote:
> I have taken EFI BIOS image from
> http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF
> 32-bit version works perfectly. However 64-bit version for some reason
> doesn't work on
> qemu-system-x86_64.
Hi. I was wondering if you could
Hi all,
Would it be possible to add a link to OVMF:
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF
on the qemu links page:
http://wiki.qemu.org/Links
for UEFI support on x86 & x86-64 guests?
Thanks,
-Jordan
201 - 241 of 241 matches
Mail list logo
