| Message ID | 1241040038-17183-15-git-send-email-aliguori@us.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Anthony Liguori wrote: > This isn't in upstream QEMU and is of little utility to KVM. It's unlikely > to appear in upstream QEMU either. > Since we allow overriding cpuid flags, why not the vendor string? It's necessary for cpu passthrough.
Avi Kivity wrote: > Anthony Liguori wrote: >> This isn't in upstream QEMU and is of little utility to KVM. It's >> unlikely >> to appear in upstream QEMU either. >> > > Since we allow overriding cpuid flags, why not the vendor string? > It's necessary for cpu passthrough. > But we don't allow explicit override of cpuid flags today. We support choosing CPU models which include vendor id and cpuid flags. Introducing a host CPU model would be acceptable and would more accurately achieve cpu passthrough.
Anthony Liguori wrote: >>> This isn't in upstream QEMU and is of little utility to KVM. It's >>> unlikely >>> to appear in upstream QEMU either. >>> >> >> Since we allow overriding cpuid flags, why not the vendor string? >> It's necessary for cpu passthrough. >> > But we don't allow explicit override of cpuid flags today. We support > choosing CPU models which include vendor id and cpuid flags. I think we allow "-cpu qemu64,-nx" for example. > > Introducing a host CPU model would be acceptable and would more > accurately achieve cpu passthrough. > I agree that "-cpu host[,modifiers]" is desirable. But I don't see why we shouldn't support finegrained control. It's probably better done through a "-cpu blah,-nx,vendorid=foobar" rather than a separate option.
Avi Kivity wrote: > Anthony Liguori wrote: >>>> This isn't in upstream QEMU and is of little utility to KVM. It's >>>> unlikely >>>> to appear in upstream QEMU either. >>>> >>> >>> Since we allow overriding cpuid flags, why not the vendor string? >>> It's necessary for cpu passthrough. >>> >> But we don't allow explicit override of cpuid flags today. We >> support choosing CPU models which include vendor id and cpuid flags. > > I think we allow "-cpu qemu64,-nx" for example. Funny enough, -cpu qemu64,vendor="AuthenticAMD" already works today. So yeah, there's no reason to carry -cpu-vendor-string anymore.
Anthony Liguori wrote: >>>>> This isn't in upstream QEMU and is of little utility to KVM. It's >>>>> unlikely >>>>> to appear in upstream QEMU either. >>>>> >>>> >>>> Since we allow overriding cpuid flags, why not the vendor string? >>>> It's necessary for cpu passthrough. >>>> >>> But we don't allow explicit override of cpuid flags today. We >>> support choosing CPU models which include vendor id and cpuid flags. >> >> I think we allow "-cpu qemu64,-nx" for example. > > Funny enough, -cpu qemu64,vendor="AuthenticAMD" already works today. > So yeah, there's no reason to carry -cpu-vendor-string anymore. > Applied, but had to reverse the sense of the commit log :)
diff --git a/linux-user/main.c b/linux-user/main.c index 5967fa3..dc39b05 100644 --- a/linux-user/main.c +++ b/linux-user/main.c @@ -43,7 +43,6 @@ int singlestep; static const char *interp_prefix = CONFIG_QEMU_PREFIX; const char *qemu_uname_release = CONFIG_UNAME_RELEASE; -const char *cpu_vendor_string = NULL; #if defined(__i386__) && !defined(CONFIG_STATIC) /* Force usage of an ELF interpreter even if it is an ELF shared diff --git a/qemu-options.hx b/qemu-options.hx index a11ead9..f7d83c9 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -1545,8 +1545,6 @@ DEF("pcidevice", HAS_ARG, QEMU_OPTION_pcidevice, #endif DEF("enable-nesting", 0, QEMU_OPTION_enable_nesting, "-enable-nesting enable support for running a VM inside the VM (AMD only)\n") -DEF("cpu-vendor", HAS_ARG, QEMU_OPTION_cpu_vendor, - "-cpu-vendor STRING override the cpuid vendor string\n") DEF("nvram", HAS_ARG, QEMU_OPTION_nvram, "-nvram FILE provide ia64 nvram contents\n") DEF("tdf", 0, QEMU_OPTION_tdf, diff --git a/target-i386/helper.c b/target-i386/helper.c index 24fcea8..7440983 100644 --- a/target-i386/helper.c +++ b/target-i386/helper.c @@ -91,8 +91,6 @@ static void add_flagname_to_bitmaps(char *flagname, uint32_t *features, fprintf(stderr, "CPU feature %s not found\n", flagname); } -extern const char *cpu_vendor_string; - typedef struct x86_def_t { const char *name; uint32_t level; @@ -431,9 +429,6 @@ static int cpu_x86_register (CPUX86State *env, const char *cpu_model) { const char *model_id = def->model_id; int c, len, i; - - if (cpu_vendor_string != NULL) - model_id = cpu_vendor_string; if (!model_id) model_id = ""; len = strlen(model_id); diff --git a/vl.c b/vl.c index 15f85e2..3b0e3dc 100644 --- a/vl.c +++ b/vl.c @@ -268,7 +268,6 @@ const char *mem_path = NULL; int mem_prealloc = 1; /* force preallocation of physical target memory */ #endif long hpagesize = 0; -const char *cpu_vendor_string; #ifdef TARGET_ARM int old_param = 0; #endif @@ -5228,9 +5227,6 @@ int main(int argc, char **argv, char **envp) nb_prom_envs++; break; #endif - case QEMU_OPTION_cpu_vendor: - cpu_vendor_string = optarg; - break; #ifdef TARGET_ARM case QEMU_OPTION_old_param: old_param = 1;
This isn't in upstream QEMU and is of little utility to KVM. It's unlikely to appear in upstream QEMU either. Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- linux-user/main.c | 1 - qemu-options.hx | 2 -- target-i386/helper.c | 5 ----- vl.c | 4 ---- 4 files changed, 0 insertions(+), 12 deletions(-)