Patchwork [6/6] pc_sysfw: change rom_only default to 0

login
register
mail settings
Submitter jordan.l.justen@intel.com
Date April 28, 2013, 8:32 a.m.
Message ID <1367137941-4310-7-git-send-email-jordan.l.justen@intel.com>
Download mbox | patch
Permalink /patch/240260/
State New
Headers show

Comments

jordan.l.justen@intel.com - April 28, 2013, 8:32 a.m.
Now KVM can support a flash memory. This feature depends on
KVM_CAP_READONLY_MEM, which was introduced in Linux 3.7.

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
---
 hw/block/pc_sysfw.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Paolo Bonzini - April 29, 2013, 8:20 a.m.
Il 28/04/2013 10:32, Jordan Justen ha scritto:
> Now KVM can support a flash memory. This feature depends on
> KVM_CAP_READONLY_MEM, which was introduced in Linux 3.7.

I don't think we can require such a new kernel to run KVM.  IIUC, an
older kernel would just fail to start, right?

Paolo
Markus Armbruster - April 29, 2013, 2 p.m.
Jordan Justen <jordan.l.justen@intel.com> writes:

> Now KVM can support a flash memory. This feature depends on
> KVM_CAP_READONLY_MEM, which was introduced in Linux 3.7.
>
> Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
> ---
>  hw/block/pc_sysfw.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/block/pc_sysfw.c b/hw/block/pc_sysfw.c
> index e88d67e..c5067c1 100644
> --- a/hw/block/pc_sysfw.c
> +++ b/hw/block/pc_sysfw.c
> @@ -258,7 +258,7 @@ void pc_system_firmware_init(MemoryRegion *rom_memory)
>  }
>  
>  static Property pcsysfw_properties[] = {
> -    DEFINE_PROP_UINT8("rom_only", PcSysFwDevice, rom_only, 1),
> +    DEFINE_PROP_UINT8("rom_only", PcSysFwDevice, rom_only, 0),
>      DEFINE_PROP_END_OF_LIST(),
>  };

Do we still need the pc-sysfw.rom_only entry in include/hw/i386/pc.h
PC_COMPAT_1_4?
Jordan Justen - April 29, 2013, 6:23 p.m.
On Mon, Apr 29, 2013 at 1:20 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 28/04/2013 10:32, Jordan Justen ha scritto:
>> Now KVM can support a flash memory. This feature depends on
>> KVM_CAP_READONLY_MEM, which was introduced in Linux 3.7.
>
> I don't think we can require such a new kernel to run KVM.  IIUC, an
> older kernel would just fail to start, right?

Would it also be unacceptable to alter the behavior based on the kvm
capabilities? So, we can't use rom-mode for old kvm, but flash mode
for new kvm? (In other words, behave similarly to qemu 1.2-1.4 in kvm
vs. non-kvm mode.)

-Jordan
Paolo Bonzini - April 29, 2013, 9:10 p.m.
Il 29/04/2013 20:23, Jordan Justen ha scritto:
> On Mon, Apr 29, 2013 at 1:20 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 28/04/2013 10:32, Jordan Justen ha scritto:
>>> Now KVM can support a flash memory. This feature depends on
>>> KVM_CAP_READONLY_MEM, which was introduced in Linux 3.7.
>>
>> I don't think we can require such a new kernel to run KVM.  IIUC, an
>> older kernel would just fail to start, right?
> 
> Would it also be unacceptable to alter the behavior based on the kvm
> capabilities? So, we can't use rom-mode for old kvm, but flash mode
> for new kvm? (In other words, behave similarly to qemu 1.2-1.4 in kvm
> vs. non-kvm mode.)

No, unfortunately the host versions must not affect the hardware.

Paolo
Jordan Justen - April 30, 2013, 3:51 a.m.
On Mon, Apr 29, 2013 at 2:10 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 29/04/2013 20:23, Jordan Justen ha scritto:
>> On Mon, Apr 29, 2013 at 1:20 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> Il 28/04/2013 10:32, Jordan Justen ha scritto:
>>>> Now KVM can support a flash memory. This feature depends on
>>>> KVM_CAP_READONLY_MEM, which was introduced in Linux 3.7.
>>>
>>> I don't think we can require such a new kernel to run KVM.  IIUC, an
>>> older kernel would just fail to start, right?
>>
>> Would it also be unacceptable to alter the behavior based on the kvm
>> capabilities? So, we can't use rom-mode for old kvm, but flash mode
>> for new kvm? (In other words, behave similarly to qemu 1.2-1.4 in kvm
>> vs. non-kvm mode.)
>
> No, unfortunately the host versions must not affect the hardware.

I don't think this is as black & white as you guys are claiming.

The rom in qemu is read-only. In kvm, it has been read-write. That is
different behavior.

I assume with kvm readonly support, at some point the rom may be
read-only or read/write under kvm depending on the capabilities.

Anyway, would this work:
if (-pflash is not used) {
  qemu and kvm always use a 'rom' mode
} else if (non-kvm or kvm read-only capable) {
  PC flash used
} else {
  die "kvm+pflash requires read-only capability"
}

Someone could create a flash capable VM on qemu or newer kvm, and then
have trouble with it on an older kvm, but the chance of potential
issues seems greatly reduced.

For people using rom firmware, this should have no impact.

-Jordan
Paolo Bonzini - April 30, 2013, 7:24 a.m.
Il 30/04/2013 05:51, Jordan Justen ha scritto:
> The rom in qemu is read-only. In kvm, it has been read-write. That is
> different behavior.

And it was a problem, hence it was reverted.

> I assume with kvm readonly support, at some point the rom may be
> read-only or read/write under kvm depending on the capabilities.

No, this would be bad.

> Anyway, would this work:
> if (-pflash is not used) {
>   qemu and kvm always use a 'rom' mode
> } else if (non-kvm or kvm read-only capable) {
>   PC flash used
> } else {
>   die "kvm+pflash requires read-only capability"
> }
> 
> Someone could create a flash capable VM on qemu or newer kvm, and then
> have trouble with it on an older kvm, but the chance of potential
> issues seems greatly reduced.
> 
> For people using rom firmware, this should have no impact.

Yes, _this_ would work because it requires a special command line, and
it would have never worked before.

Paolo

Patch

diff --git a/hw/block/pc_sysfw.c b/hw/block/pc_sysfw.c
index e88d67e..c5067c1 100644
--- a/hw/block/pc_sysfw.c
+++ b/hw/block/pc_sysfw.c
@@ -258,7 +258,7 @@  void pc_system_firmware_init(MemoryRegion *rom_memory)
 }
 
 static Property pcsysfw_properties[] = {
-    DEFINE_PROP_UINT8("rom_only", PcSysFwDevice, rom_only, 1),
+    DEFINE_PROP_UINT8("rom_only", PcSysFwDevice, rom_only, 0),
     DEFINE_PROP_END_OF_LIST(),
 };