Skip to contentSkip to conversation

cpuid configuration for PV guest

PATCH In review Jean Guyader 6 participants 11 messages Jun 4, 2008 – Jul 15, 2008

lore
Share & tools
lore

Jean Guyader

author
#0 lore raw

PATCH 1/1 cpuid configuration for PV guest

Hi,

This patch add the pv guest support for the cpuid configuration and checking. That feature only works for cpuid request which are coming from the guest's kernel, a process could still call the cpuid directly.

A new policy for pv guest has been created in libxc. dom0 cpuid emulation is left hardcoded in Xen.

Signed-off-by Jean Guyader <[email protected]>
Signature · 1 line
Jean Guyader
tools/libxc/xc_cpuid_x86.c +81 -8
diff -r 5603534c62f9 tools/libxc/xc_cpuid_x86.c
@@ -140,14 +140,66 @@ static void xc_cpuid_brand_get(char *str
     str[12] = '\0';
 }
 
-static void xc_cpuid_policy(
+static void xc_cpuid_pv_policy(
     int xc, domid_t domid, const unsigned int *input, unsigned int *regs)
 {
-    char brand[13];
-    unsigned long pae;
+    switch ( input[0] )
+    {
+    case 0x00000000:
+        if ( regs[0] > DEF_MAX_BASE )
+            regs[0] = DEF_MAX_BASE;
+        break;
 
-    xc_get_hvm_param(xc, domid, HVM_PARAM_PAE_ENABLED, &pae);
+    case 1:
+        clear_bit(X86_FEATURE_DTES64 % 32, regs[2]);
+        clear_bit(X86_FEATURE_MWAIT % 32, regs[2]);
+        clear_bit(X86_FEATURE_DSCPL % 32, regs[2]);
+        clear_bit(X86_FEATURE_VMXE % 32, regs[2]);
+        clear_bit(X86_FEATURE_SMXE % 32, regs[2]);
+        clear_bit(X86_FEATURE_EST % 32, regs[2]);
+        clear_bit(X86_FEATURE_TM2 % 32, regs[2]);
+        clear_bit(X86_FEATURE_CX16 % 32, regs[2]);
+        clear_bit(X86_FEATURE_XTPR % 32, regs[2]);
+        clear_bit(X86_FEATURE_PDCM % 32, regs[2]);
+        clear_bit(X86_FEATURE_DCA % 32, regs[2]);
+        
+        clear_bit(X86_FEATURE_VME % 32, regs[3]);
+        clear_bit(X86_FEATURE_PSE % 32, regs[3]);
+        clear_bit(X86_FEATURE_PGE % 32, regs[3]);
+        clear_bit(X86_FEATURE_MCE % 32, regs[3]);
+        clear_bit(X86_FEATURE_MCA % 32, regs[3]);
+        clear_bit(X86_FEATURE_MTRR % 32, regs[3]);
+        clear_bit(X86_FEATURE_DS % 32, regs[3]);
+        clear_bit(X86_FEATURE_ACC % 32, regs[3]);
+        clear_bit(X86_FEATURE_PBE % 32, regs[3]);
+        break;
 
+    case 0x80000000:
+        if ( regs[0] > DEF_MAX_EXT )
+            regs[0] = DEF_MAX_EXT;
+        break;
+ 
+    case 0x80000001:
+        clear_bit(X86_FEATURE_NX & 31, regs[3]);
+        break;
+
+    case 0x00000002:
+    case 0x00000004:
+    case 0x80000002:
+    case 0x80000003:
+    case 0x80000004:
+    case 0x80000006:
+        break;
+
+    default:
+        regs[0] = regs[1] = regs[2] = regs[3] = 0;
+    }
+}
+
+static void xc_cpuid_hvm_policy(
+    int xc, domid_t domid, const unsigned int *input, unsigned int *regs,
+    int is_pae)
+{
     switch( input[0] )
     {
     case 0x00000000:

@@ -188,7 +240,7 @@ static void xc_cpuid_policy(
         /* We always support MTRR MSRs. */
         regs[3] |= bitmaskof(X86_FEATURE_MTRR);
 
-        if ( !pae )
+        if ( !is_pae )
             clear_bit(X86_FEATURE_PAE & 31, regs[3]);
         break;
 

@@ -198,7 +250,7 @@ static void xc_cpuid_policy(
         break;
 
     case 0x80000001:
-        if ( !pae )
+        if ( !is_pae )
             clear_bit(X86_FEATURE_NX & 31, regs[3]);
         break;
 

@@ -221,11 +273,32 @@ static void xc_cpuid_policy(
         break;
     }
 
+}
+
+static int xc_cpuid_policy(
+    int xc, domid_t domid, const unsigned int *input, unsigned int *regs)
+{
+    xc_dominfo_t        info;
+    unsigned long       pae = 1;
+    char                brand[13];
+
+    if ( xc_domain_getinfo(xc, domid, 1, &info) == 0 )
+        return -EINVAL;
+    if ( info.hvm )
+    {
+        xc_get_hvm_param(xc, domid, HVM_PARAM_PAE_ENABLED, &pae);
+        xc_cpuid_hvm_policy(xc, domid, input, regs, !!pae);
+    }
+    else
+        xc_cpuid_pv_policy(xc, domid, input, regs);
+
     xc_cpuid_brand_get(brand);
     if ( strstr(brand, "AMD") )
-        amd_xc_cpuid_policy(xc, domid, input, regs, !!pae);
+        amd_xc_cpuid_policy(xc, domid, input, regs, pae);
     else
-        intel_xc_cpuid_policy(xc, domid, input, regs, !!pae);
+        intel_xc_cpuid_policy(xc, domid, input, regs, pae);
+
+    return 0;
 }
 
 static int xc_cpuid_do_domctl(
tools/python/xen/xend/image.py +41 -31

103 lines not on this page · raw message

xen/arch/x86/traps.c +93 -70

180 lines not on this page · raw message

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

#1 lore raw
Quoted 8 lines · Jean Guyader

Hi,

This patch add the pv guest support for the cpuid configuration and checking. That feature only works for cpuid request which are coming from the guest's kernel, a process could still call the cpuid directly.

A new policy for pv guest has been created in libxc. dom0 cpuid emulation is left hardcoded in Xen.

So at the moment my pv guests are getting all zero back from cpuid. I haven't updated their config files at all. Is that the expected behaviour? It seems a bit unfriendly; I would have expected it to default to the old behaviour with no config in place.

Hm, or maybe something else is going wrong?

Thanks,
J

#2 lore raw
Quoted 1 line · Jeremy Fitzhardinge

Hm, or maybe something else is going wrong?

Yep. Turns out a build problem in the new qemu was preventing the rest of the tools from being built, so the python code wasn't being updated. So now cpuid is OK, but other stuff is failing... tapdisk?

J

#3 lore raw
Quoted 1 line · Jeremy Fitzhardinge

but other stuff is failing... tapdisk?

No, pvfb. Hm.

J

#4 lore raw
Quoted 4 lines · Jeremy Fitzhardinge
Quoted 1 line · Jeremy Fitzhardinge

but other stuff is failing... tapdisk?

No, pvfb. Hm.

pvfb is built into qemu now?

-- Keir

#5 lore raw
Quoted 8 lines · Keir Fraser, le Mon 14 Jul 2008 08:12:26 +0100, a écrit :
Quoted 4 lines · Jeremy Fitzhardinge
Quoted 1 line · Jeremy Fitzhardinge

but other stuff is failing... tapdisk?

No, pvfb. Hm.

pvfb is built into qemu now?

The back-end part has been merged into qemu for some time yes.

Samuel

#6 lore raw

qemu-dm without slirp

In reply to Keir Fraser
Quoted 12 lines · Keir Fraser
Quoted 6 lines · Jeremy Fitzhardinge
Quoted 2 lines · Jeremy Fitzhardinge

but other stuff is failing... tapdisk?

No, pvfb. Hm.

pvfb is built into qemu now?

Ah. I compiled qemu with --disable-gcc-check --disable-slirp as had been discussed on the list. But that causes qemu-dm to fail with "Unknown network device: user", because it always uses "user" (slirp) if you don't define any other net conifg.

I did this:

vl.c +4 -3
@@ -8598,9 +8598,10 @@ int main(int argc, char **argv)
    /* init network clients */
    if (nb_net_clients == 0) {
        /* if no clients, we use a default config */
-        net_clients[0] = "nic";
-        net_clients[1] = "user";
-        nb_net_clients = 2;
+        net_clients[nb_net_clients++] = "nic";
+#ifdef CONFIG_SLIRP
+        net_clients[nb_net_clients++] = "user";
+#endif
    }
 
    for(i = 0;i < nb_net_clients; i++) {

to fix it. The old qemu code put that whole default net configuration in #ifndef CONFIG_DM. Ian, did you deliberately not do that in the new code, or is it an oversight?

J

#7 lore raw

PATCH 1/1 xend: PV machines have no ioemu network

Quoted 38 lines · Jeremy Fitzhardinge
Quoted 12 lines · Keir Fraser
Quoted 6 lines · Jeremy Fitzhardinge
Quoted 2 lines · Jeremy Fitzhardinge

but other stuff is failing... tapdisk?

No, pvfb. Hm.

pvfb is built into qemu now?

Ah. I compiled qemu with --disable-gcc-check --disable-slirp as had been discussed on the list. But that causes qemu-dm to fail with "Unknown network device: user", because it always uses "user" (slirp) if you don't define any other net conifg.

I did this:

vl.c +4 -3
@@ -8598,9 +8598,10 @@ int main(int argc, char **argv)
    /* init network clients */
    if (nb_net_clients == 0) {
        /* if no clients, we use a default config */
-        net_clients[0] = "nic";
-        net_clients[1] = "user";
-        nb_net_clients = 2;
+        net_clients[nb_net_clients++] = "nic";
+#ifdef CONFIG_SLIRP
+        net_clients[nb_net_clients++] = "user";
+#endif
    }
 
    for(i = 0;i < nb_net_clients; i++) {
Quoted 3 lines

to fix it. The old qemu code put that whole default net configuration in #ifndef CONFIG_DM. Ian, did you deliberately not do that in the new code, or is it an oversight?

Ians wants to keep changes from upstream qemu as small as possible in those files shared with qemu. I think this is the main reason why he didn't do it, and as long as slirp was compiled it just worked.

Additionally, specifying no -net parameter always meant -net nic -net user for qemu, so we would not only change common code, but also the semantics of the command line parameters. I think this is even worse. The right thing to do is to specify -net none from xend, IMHO.

Kevin

xend: PV machines have no ioemu network

In the command line parameters of qemu-dm, xend should specify -net none for PV machines. qemu-dm will assume -net nic -net user otherwise, which fails now because slirp is no longer compiled in.

Signed-off-by Kevin Wolf <[email protected]>
tools/python/xen/xend/image.py +1 -0
diff -r 54dec90cbea9 tools/python/xen/xend/image.py
@@ -658,6 +658,7 @@
         # Equivalent to old xenconsoled behaviour. Should make
         # it configurable in future
         ret = ret + ["-serial", "pty"]
+        ret = ret + ["-net", "none"]
         return ret
 
     def getDeviceModelArgs(self, restore = False):

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

#8 lore raw

Re: [PATCH] xend: PV machines have no ioemu network

Quoted 8 lines · Kevin Wolf

Ians wants to keep changes from upstream qemu as small as possible in those files shared with qemu. I think this is the main reason why he didn't do it, and as long as slirp was compiled it just worked.

Additionally, specifying no -net parameter always meant -net nic -net user for qemu, so we would not only change common code, but also the semantics of the command line parameters. I think this is even worse.

If you've disabled slirp then "-net user" doesn't work; it would be pretty silly for qemu to default to using "-net user" if it can't possibly work. I think my patch is a bugfix for base qemu.

Quoted 2 lines

The right thing to do is to specify -net none from xend, IMHO.

Yes, that makes sense anyway.

Quoted 11 lines

Kevin

xend: PV machines have no ioemu network

In the command line parameters of qemu-dm, xend should specify -net none for PV machines. qemu-dm will assume -net nic -net user otherwise, which fails now because slirp is no longer compiled in.

Signed-off-by Kevin Wolf <[email protected]>

J

#9 lore raw

Re: [PATCH] xend: PV machines have no ioemu network

Quoted 5 lines · Jeremy Fitzhardinge
Quoted 4 lines · Kevin Wolf

Ians wants to keep changes from upstream qemu as small as possible in those files shared with qemu. I think this is the main reason why he didn't do it, and as long as slirp was compiled it just worked.

Quoted 8 lines
Quoted 4 lines

Additionally, specifying no -net parameter always meant -net nic -net user for qemu, so we would not only change common code, but also the semantics of the command line parameters. I think this is even worse.

If you've disabled slirp then "-net user" doesn't work; it would be pretty silly for qemu to default to using "-net user" if it can't possibly work. I think my patch is a bugfix for base qemu.

Agreed. If you submit it to upstream qemu, it's a proper fix.

Kevin

#10 lore raw

Re: qemu-dm without slirp

In reply to Jeremy Fitzhardinge

Jeremy Fitzhardinge writes ("qemu-dm without slirp"):

vl.c int main(int argc, char **argv) · line 8604

Quoted 3 lines
vl.c +3 -0
+#ifdef CONFIG_SLIRP
+        net_clients[nb_net_clients++] = "user";
+#endif

I agree with this and I think it should go upstream. For now I've applied it to my `qemu' branch (and pulled it into master) and I'll go an d talk to upstream about it.

Ian.