silicon was altered slightly to reflect this.
We've seen isolated cases where apparently unrelated yet
slightly incoherent CPUID data has caused problems, most
notably during guest boot. Providing Westmere as a
model separate fro Nehalem allows us to more easily address
such quirks.
Signed-off-by:
llowing combinations:
[Conroe, Penryn, Nehalem] x [F12-64, win64, win32] -- Intel host
[Opteron_G1, Opteron_G2, Opteron_G3] x [F12-64, win64, win32] -- AMD host
Yielding successful boots in all cases.
Signed-off-by: john cooper
---
diff --git a/sysconfigs/target/target-x86_64.conf
b/sysconfigs/
solution which minimally
impacts the user is ultimately required.
Signed-off-by: john cooper
---
diff --git a/qemu-config.c b/qemu-config.c
index 5d7ffa2..b39b8fe 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -666,21 +666,29 @@ out:
return res;
}
-int qemu_read_config_file(const
[0x0040]
Unable to support requested x86 CPU definition
etc.. allowing both the ability here to "check|enforce" the default
model, as well as accepting arbitrary feature flags due to fan into the
existing flag parsing. The resulting patch, which also indicates the CPU
model in us
Add kvm emulated x2apic flag to config defined cpu models
and general support for such hypervisor emulated flags.
In addition to checking user request flags against the host
we also selectively check against kvm for emulated flags.
Signed-off-by: john cooper
---
diff --git a/hw/pc.c b/hw/pc.c
Allow an optional qemu_early_init_vcpu() such that
kvm_arch_get_supported_cpuid() can be used from
cpu_x86_register(). Without this minimal setup
kvm_arch_get_supported_cpuid() gags kvm_ioctl() via
passing a NULL initialized KVMState *.
Signed-off-by: john cooper
---
diff --git a/cpus.c b
3.
After consulting with Intel the following recommendations were
received which more accurately represent shipped silicon.
Signed-off-by: john cooper
---
diff --git a/sysconfigs/target/target-x86_64.conf
b/sysconfigs/target/target-x86_64.conf
index 43ad282..0613870 100644
--- a/sysconfigs/
This series is a resend of several pending patches which
have been brought up-to-date. All address problems we have
found and corrected in our codebase in the process of test
and deploy of cpu model support.
A few have been modified slightly to address minor whitespace
issues and 4/7 reverts the
requested flag 'sse4a' [0x0040]
Unable to find x86 CPU definition
etc.. allowing both the ability here to "check|enforce" the default
model, as well as accepting arbitrary feature flags due to fan into the
existing flag parsing. The resulting patch, which also indicates t
oaded "-readconfig ?"
to enable verbose handling. Here we add a global "-config"
flag which takes [verbose][,nodefault] as options modifying
config file handling. Note "-nodefconfig" has been removed
and functionally replaced here by the "nodefault" flag option.
Allow an optional qemu_early_init_vcpu() such that
kvm_arch_get_supported_cpuid() can be used from
cpu_x86_register(). Without this minimal setup
kvm_arch_get_supported_cpuid() gags kvm_ioctl() via
passing a NULL initialized KVMState *.
Signed-off-by: john cooper
---
diff --git a/cpus.c b
Add kvm emulated x2apic flag to config defined cpu models
and general support for such hypervisor emulated flags.
In addition to checking user request flags against the host
we also selectively check against kvm for emulated flags.
Signed-off-by: john cooper
---
diff --git a/hw/pc.c b/hw/pc.c
< 13.
After consulting with Intel the following recommendations were
received which more accurately represent shipped silicon.
Signed-off-by: john cooper
---
diff --git a/sysconfigs/target/target-x86_64.conf
b/sysconfigs/target/target-x86_64.conf
index 43ad282..0613870 100644
--- a/sysco
[Resend of series which has been updated to apply to the
current tree. Associated discussion may be found in the
mail list archives.]
This series is a synopsis of several patches correcting
problems found during use and test of the cpu model config
definitions and usability in general.
Please re
Any idea where in the queue this patch set may be?
-john
john cooper wrote:
> This series is a synopsis of several patches correcting
> problems found during use and test of the cpu model config
> definitions, and usability in general.
>
> Please review and apply.
>
> -j
oaded "-readconfig ?"
to enable verbose handling. Here we add a global "-config"
flag which takes [verbose][,nodefault] as options modifying
config file handling. Note "-nodefconfig" has been removed
and functionally replaced here by the "nodefault" flag option.
Blue Swirl wrote:
> On Thu, Sep 9, 2010 at 3:48 AM, john cooper wrote:
>>
>>> I think '?' is not very good name.
>> I agree, a shell meta char wasn't my first choice. However
>> it follows the precedent of '?' used in similar query operati
Blue Swirl wrote:
> On Tue, Sep 7, 2010 at 12:31 PM, john cooper wrote:
>> Failure by qemu to open a default config file isn't cause to
>> error exit -- it just quietly continues on. After puzzling
>> issues with otherwise opaque config file locations and
>>
This series is a synopsis of several patches correcting
problems found during use and test of the cpu model config
definitions, and usability in general.
Please review and apply.
-john
--
john.coo...@redhat.com
Add kvm emulated x2apic flag to config defined cpu models
and general support for such hypervisor emulated flags.
In addition to checking user request flags against the host
we also selectively check against kvm for emulated flags.
Signed-off-by: john cooper
---
diff --git a/hw/pc.c b/hw/pc.c
Allow an optional qemu_early_init_vcpu() such that
kvm_arch_get_supported_cpuid() can be used from
cpu_x86_register(). Without this minimal setup
kvm_arch_get_supported_cpuid() gags kvm_ioctl() via
passing a NULL initialized KVMState *.
Signed-off-by: john cooper
---
diff --git a/cpus.c b
filename arg to -readconfig,
verbose open of all config files will be enabled. Normal
handling of config files is otherwise unaffected by this
option.
Signed-off-by: john cooper
---
diff --git a/qemu-config.c b/qemu-config.c
index 1efdbec..805fcc6 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@
< 13.
After consulting with Intel the following recommendations were
received which more accurately represent shipped silicon.
Signed-off-by: john cooper
---
diff --git a/sysconfigs/target/target-x86_64.conf
b/sysconfigs/target/target-x86_64.conf
index 43ad282..0613870 100644
--- a/sysco
Jes Sorensen wrote:
> On 08/22/10 20:35, malc wrote:
>> On Sun, 22 Aug 2010, Blue Swirl wrote:
>>> What's the ultimate editor? I'd love to drop Emacs, which is annoying
>>> but does its job better than the others that I've tried.
>>>
>> ed
>
> ed is for sissies, real developers use cat, echo
Jes Sorensen wrote:
> On 08/22/10 20:39, malc wrote:
>
>> Disregarding my own stance on the braces, braces around single statement
>> is actually helpful w.r.t. debugging imaging trying to set a break point
>> on said singlesttement, plain impossible in following case:
>>
>> if (a) b;
>>
>
Markus Armbruster wrote:
> Subject is confusing: suggests a series of four parts.
Sorry. My bad for recycling old mail.
> Looks like this conflicts with my "PATCH v3 00/13] More block-related
> fixes and cleanups".
>
> Perhaps the easiest way to get this in would be to rebase to Kevin's
> block
: john cooper
---
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 0bf929a..bd6b896 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -26,6 +26,7 @@ typedef struct VirtIOBlock
QEMUBH *bh;
BlockConf *conf;
unsigned short sector_mask;
+char sn[BLOCK_SERIAL_STRLEN
Marc Haber wrote:
I could have swore I sent out a guest-driver-app-interface-less
version of the patch using virtio to pass the S/N but didn't find it in
the archives. I did however locate it and can bring it forward as a
reference for the above if interest exists.
>>> If it b
Rusty Russell wrote:
> On Tue, 22 Jun 2010 02:13:21 am Ryan Harper wrote:
>> * john cooper [2010-06-21 01:11]:
>>> Rusty Russell wrote:
>>>>/* id_str is not necessarily nul-terminated! */
>>>>buf[VIRTIO_BLK_ID_BYTES] = '\0';
>>&g
Ryan Harper wrote:
> * john cooper [2010-06-21 01:11]:
>> Rusty Russell wrote:
>>> On Sat, 19 Jun 2010 04:08:02 am Ryan Harper wrote:
>>>> Create a new attribute for virtio-blk devices that will fetch the serial
>>>> number
>>>> of the block
or less that we get a NULL terminated
>> string. When copying this value into a string buffer, we must be careful to
>> copy up to the NULL (if it present) and only 20 if it is longer and not to
>> attempt to NULL terminate; this isn't needed.
>>
>> S
't have any users to worry about.
>
> If John Cooper acks this, I'll push it to Linus immediately.
Actually I'm the one who suggested removing it.
The code in question was only intended as example
usage of accessing the s/n data in the driver, for
the /sys interface under discu
Anthony Liguori wrote:
> On 06/09/2010 03:05 AM, john cooper wrote:
>> This patch adds the ability to determine the build-configured
>> runtime "config file" paths from the command line. After
>> support for cpu model definitions were added to the default
>> r
mode is optional, otherwise the existing startup behavior
is identical.
Signed-off-by: john cooper
---
diff --git a/qemu-config.c b/qemu-config.c
index 5a4e61b..a490603 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -518,21 +518,29 @@ out:
return res;
}
-int qemu_read_config_file(const
Ryan Harper wrote:
> * Kay Sievers [2010-06-03 15:06]:
>> On Thu, Jun 3, 2010 at 22:01, Ryan Harper wrote:
>>> * Kay Sievers [2010-06-03 14:53]:
On Thu, Jun 3, 2010 at 21:07, Ryan Harper wrote:
> Use the 'VBID' virtio-blk ioctl to extract drive serial numbers
> to be used for build
Anthony Liguori wrote:
> On 03/25/2010 12:33 AM, john cooper wrote:
>> Fix bug which truncated serial string to 8 bytes, nul terminate.
>>
>> Signed-off-by: john cooper
>> ---
>>
>> diff --git a/vl.c b/vl.c
>> index d69250c..b74cbba 100644
>
Anthony Liguori wrote:
> On 03/25/2010 12:32 AM, john cooper wrote:
>> Add virtio-blk device id (s/n) support via virtio request.
>> Remove artifacts of pci and ATA_IDENTIFY implementation
>> relative to prior versions.
>>
>> Signed-off-by: john cooper
>> -
john cooper wrote:
> I'm all for putting this issue to rest, but if we're
> going to live with an ioctl interface retrieving the
> id string, let's make it a little more friendly from
> the user's perspective.
The qemu side of the patch is ok as-is. The guest-user
Ryan Harper wrote:
> I've applied the qemu and kernel side of this patch series and tested
> this out using the sample code below. I've also reworked this example
> into a virtioblk_id tool to work with udev to generate /dev/disk/by-id
> links; I'll be submitting a patch set to linux-hotplug with
Marc Haber wrote:
> Hi,
>
> On Mon, Mar 22, 2010 at 10:22:14AM -0400, john cooper wrote:
>> Marc Haber wrote:
>>> It the serial "number" can be alphanumeric, that would be great to have.
>> It is simply a string of 20 characters, which AFAICT has
>>
Rusty Russell wrote:
> On Thu, 25 Mar 2010 04:04:02 pm john cooper wrote:
>> Return serial string to the guest application via
>> ioctl driver call.
>
> This is quite nice. Minor nits:
>
>> +if (cmd == 'VBID') {
>> +void *us
Return serial string to the guest application via
ioctl driver call.
Note this form of interface to the guest userland
was the consensus when the prior version using
the ATA_IDENTIFY came under dispute.
Signed-off-by: john cooper
---
diff --git a/drivers/block/virtio_blk.c b/drivers/block
Add virtio-blk device id (s/n) support via virtio request.
Signed-off-by: john cooper
---
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 3c64af0..cd66806 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -69,6 +69,8 @@ static void blk_done
Fix bug which truncated serial string to 8 bytes, nul terminate.
Signed-off-by: john cooper
---
diff --git a/vl.c b/vl.c
index d69250c..b74cbba 100644
--- a/vl.c
+++ b/vl.c
@@ -1162,7 +1162,7 @@ DriveInfo *drive_init(QemuOpts *opts, void *opaque,
dinfo->on_write_error = on_write_er
Add virtio-blk device id (s/n) support via virtio request.
Remove artifacts of pci and ATA_IDENTIFY implementation
relative to prior versions.
Signed-off-by: john cooper
---
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 9915840..358b0af 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
This series adds the minimal support to qemu and virtio_blk
to support passing of a virtio_blk serial id string from qemu
through the guest driver and to the guest userland.
This is derived in part from a patch set posted by Rusty some
time ago, but has been minimized to remove support for prior
v
john cooper wrote:
> Marc Haber wrote:
>> Hi,
>>
>> On Mon, Mar 22, 2010 at 02:26:11AM -0400, john cooper wrote:
>>> I could have swore I sent out a guest-driver-app-interface-less
>>> version of the patch using virtio to pass the S/N but didn't find i
Jamie Lokier wrote:
> john cooper wrote:
>> All that said, I like the alternate choice of adding a
>> special virtio request far better. It is actually simpler
>> (and more maintainable IMO) than going through the
>> gyrations of stuffing the S/N data through PCI c
Marc Haber wrote:
Hi,
On Mon, Mar 22, 2010 at 02:26:11AM -0400, john cooper wrote:
This is a tad ironic as that is how this saga begun. Namely stuffing
20 bytes of serial number string into the virtio-blk PCI config space
on qemu's side and pushing it over to the guest driver. I exposed
Marc Haber wrote:
> Hi,
>
> On Tue, Mar 09, 2010 at 03:34:07PM -0600, Anthony Liguori wrote:
>> On 03/06/2010 04:42 PM, Marc Haber wrote:
>>> My goal is to have a possibility to give a "speaking" name to any
>>> block device handed into a guest instance by the host. That name
>>> should be visible
Jamie Lokier wrote:
Anthony Liguori wrote:
On 03/06/2010 04:42 PM, Marc Haber wrote:
Hi,
I am looking to get in touch with somebody who knows more about the
connection between host configuration, qemu, kvm, and the virtio block
device driver guest side than I know.
My goal is to have a possib
fs.
Encoding of cpuid flags names now allows aliases for both the
configuration file and the command line which reconciles some
Intel/AMD/Linux/Qemu naming differences.
This patch was tested relative to qemu.git.
Signed-off-by: john cooper
---
diff --git a/Makefile b/Makefile
index c72a059.
Anthony Liguori wrote:
> On 02/01/2010 01:02 PM, john cooper wrote:
>> [target-x86_64.conf was unintentionally omitted from the earlier patch]
>>
>> This is a reimplementation of prior versions which adds
>> the ability to define cpu models for contemporary processo
Gerd Hoffmann wrote:
> On 02/07/10 17:24, Anthony Liguori wrote:
>> On 02/06/2010 12:59 PM, john cooper wrote:
>>> This patch reworks support for both assignment and
>>> append in the config file parser. It was motivated
>>> by comments received on
ability to append to an
option (however now via "+="), reverts "=" to its
previous behavior, and allows both to interoperate.
Signed-off-by: john cooper
---
diff --git a/qemu-config.c b/qemu-config.c
index 246fae6..4e53250 100644
--- a/qemu-config.c
+++ b/qemu-co
Andre Przywara wrote:
>> +[cpudef]
>> + name = "Conroe"
>> + level = "2"
>> + vendor = "GenuineIntel"
>> + family = "6"
>> + model = "2"
>> + stepping = "3"
>> + feature_edx = "sse2 sse fxsr mmx pat cmov pge sep apic cx8 mce pae
>> msr tsc pse de fpumtrr clflush mca pse36"
>> +
six models and essentially mimics
the structure of the static x86_def_t x86_defs.
Encoding of cpuid flags names now allows aliases for both the
configuration file and the command line which reconciles some
Intel/AMD/Linux/Qemu naming differences.
This patch was tested relative to qemu.git.
6_def_t x86_defs.
Encoding of cpuid flags names now allows aliases for both the
configuration file and the command line which reconciles some
Intel/AMD/Linux/Qemu naming differences.
This patch was tested relative to qemu.git.
Signed-off-by: john cooper
---
diff --git a/Makefile b/Makefile
index
Christoph Hellwig wrote:
> Back iSeptember 2007 Michael made the serial number support in qemu
> optional and off by default, and in October 2009 Rusty reverted the
> Linux virtio-blk support for it. Given that I can't find support in
> any other virtio implementation that makes the feature look e
Jamie Lokier wrote:
> I think we can all agree that there is no point looking for a familiar
> -cpu naming scheme because there aren't any familiar and meaningful names
> these days.
Even if we dismiss the Intel coined names as internal
code names, there is still VMW's use of them in this
space w
Jamie Lokier wrote:
> Do you mean that more powerful management tools to support safe
> migration will maintain _their own_ processor model tables, and
> perform their calculations using their own tables instead of querying
> qemu, and therefore not have any need of qemu's built in table?
I would
Anthony Liguori wrote:
> On 01/20/2010 07:18 PM, john cooper wrote:
>> I can appreciate the concern of wanting to get this
>> as "correct" as possible.
>>
>
> This is the root of the trouble. At the qemu layer, we try to focus on
> being correct.
Chris Wright wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
>> To be honest all possible naming schemes for '-cpu ' are just as
>> unfriendly as each other. The only user friendly option is '-cpu host'.
>>
>> IMHO, we should just pick a concise naming scheme & document it. Given
>> the
Jamie Lokier wrote:
> john cooper wrote:
>> As before a cpu feature 'check' option is added which warns when
>> feature flags (either implicit in a cpu model or explicit on the
>> command line) would have otherwise been quietly unavailable to a
>> guest:
&g
Anthony Liguori wrote:
> On 01/19/2010 02:03 PM, Chris Wright wrote:
>> * Anthony Liguori (anth...@codemonkey.ws) wrote:
>>
>>> I'm very much against having -cpu Nehalem. The whole point of this is
>>> to make things easier for a user and for most of the users I've
>>> encountered, -cpu Nehalem
Jamie Lokier wrote:
> Anthony Liguori wrote:
>> On 01/18/2010 10:45 AM, john cooper wrote:
>>> x86 Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2)
>>> x86 Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2)
>>> x86
ietly unavailable to a
guest:
# qemu-system-x86_64 ... -cpu Nehalem,check
warning: host cpuid _0001 lacks requested flag 'sse4.2' [0x0010]
warning: host cpuid _0001 lacks requested flag 'popcnt' [0x0080]
This patch was tested relative to qemu.git.
Signed-o
Anthony Liguori wrote:
> On 12/21/2009 02:28 AM, Dor Laor wrote:
>> John's new cpu definitions are the exact solution for this issue - all
>> users, whether using mgmt app or direct qemu (this is no user, this is
>> a developer/hacker/other, let's do not optimize this case) should use
>> the variou
Marcelo Tosatti wrote:
> On Mon, Dec 21, 2009 at 01:46:36AM -0500, john cooper wrote:
>> +{
>> +.name = "Opteron_G2",
>> +.level = 5,
>> +.vendor1 = CPUID_VENDOR_INTEL_1,
>> +.vendor2 = CPUID_VENDOR_INTEL_2,
Dor Laor wrote:
> On 12/22/2009 12:51 AM, john cooper wrote:
>> Dor Laor wrote:
>>
>>> Qemu will check the required cpuid of the cpu model on the host and
>>> refuse to load otherwise. When moving to this model, migration can be
>>> simplified too sinc
Dor Laor wrote:
Qemu will check the required cpuid of the cpu model on the host and
refuse to load otherwise. When moving to this model, migration can be
simplified too since there are fewer combination, and one can choose
performance over migration flexibility and wise versa.
Due to the above
y disabled for a guest.
This patch was tested relative to qemu-kvm.git.
Signed-off-by: john cooper
---
diff --git a/target-i386/helper.c b/target-i386/helper.c
index 9a50da6..a706cae 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -44,7 +44,7 @@ static const char *feature_name[] =
72 matches
Mail list logo
