gmane.comp.emulators.xen.devel

Re: [PATCH] Add Xen platform PCI device version 2.

Paul Durrant — 2013-06-19T10:13:17

Why not? The device can be chosen on a per-VM basis.


After many months of worrying about this I had to conclude that there really is no way round this. If we bind newer drivers to the old device id and then hope to push them to Windows Update; much chaos, pain and anguish would occur. The only option is a new device.
Is it such a bad idea to be able to support multiple HVM VM configurations at the same time?

  Paul

Re: [PATCH] Add Xen platform PCI device version 2.

Ian Campbell — 2013-06-19T10:07:32

So what is the point of it?

Changing these IDs won't work for any other existing PV drivers, it will
break the Linux PVHVM ones and the BSD ones etc.

We obviously can't say to users "Are you running Windows and are you
running PV drivers >= X.Y, if so set lever A to position B, otherwise if
you are running some other OS or an earlier version of the Windows PV
driver set it to position A".

It sounds to me as if this is a hack to workaround some shortcoming of
the Windows driver model. If this is the case then I'm afraid you are
going to have to find a way to deal with this from within Windows and/or
your drivers. Failing that then I think you'll just have to document an
upgrade path for the users of your older drivers. Pushing the pain onto
the entire world is just not the right way to go about this.

Ian.

Re: pygrub patch to allow explicit offset to fs

George Dunlap — 2013-06-19T10:06:25

Yeah, I think this will have to wait.  It does also touch a codepath 
used by people not using this feature, and so there is ever so slight a 
chance that there will be breakage.

  -George

[xen-unstable test] 18170: tolerable FAIL

xen.org — 2013-06-19T09:48:27

flight 18170 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/18170/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass

version targeted for testing:
 xen                  8ee5e399c16c3343faed13bdfd4be95c12f429eb
baseline version:
 xen                  8ee5e399c16c3343faed13bdfd4be95c12f429eb

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.

Re: [PATCH] Add Xen platform PCI device version 2.

Paul Durrant — 2013-06-19T09:43:12

As the comment implies, the device_id (2 rather than 1) and the revision (2 rather than 1).

  Paul

Re: [PATCH] Add Xen platform PCI device version 2.

Ian Campbell — 2013-06-19T09:42:25

What is the difference between these two devices?

Ian.

[PATCH] Add Xen platform PCI device version 2.

Paul Durrant — 2013-06-19T09:32:13

The XenServer 6.1+ Citrix Windows PV bus driver binds to a new version
of the Xen platform device (since the newer driver set cannot co-exist
with previous drivers which bind to the existing "xen-platform" type of
device). This patch introduces a new "xen-platform-2" device type with
the appropriate device_id and revision.

Signed-off-by: Paul Durrant <paul.durrant< at >citrix.com>
---
 hw/xen/xen_platform.c    |   75 ++++++++++++++++++++++++++++++++++++++--------
 include/hw/pci/pci_ids.h |    1 +
 2 files changed, 63 insertions(+), 13 deletions(-)

diff --git a/hw/xen/xen_platform.c b/hw/xen/xen_platform.c
index b6c6793..6edb850 100644
--- a/hw/xen/xen_platform.c
+++ b/hw/xen/xen_platform.c
< at >< at > -48,6 +48,20 < at >< at >
 
 #define PFFLAG_ROM_LOCK 1 /* Sets whether ROM memory area is RW or RO */
 
+typedef struct {
+    const char *name;
+    const char *desc;
+    uint16_t device_id;
+    uint8_t revision;
+    uint16_t subsystem_vendor_id;
+    uint16_t subsystem_id;
+} PCIXenPlatformDeviceInfo;
+
+typedef struct PCIXenPlatformDeviceClass {
+    PCIDeviceClass              parent_class;
+    PCIXenPlatformDeviceInfo    info;
+} PCIXenPlatformDeviceClass;
+
 typedef struct PCIXenPlatformState {
     PCIDevice  pci_dev;
     MemoryRegion fixed_io;
< at >< at > -372,8 +386,13 < at >< at > static const VMStateDescription vmstate_xen_platform = {
 static int xen_platform_initfn(PCIDevice *dev)
 {
     PCIXenPlatformState *d = DO_UPCAST(PCIXenPlatformState, pci_dev, dev);
+    PCIDeviceClass *k = PCI_DEVICE_GET_CLASS(dev);
+    __attribute__((unused)) PCIXenPlatformDeviceClass *u;
     uint8_t *pci_conf;
 
+    u = container_of(k, PCIXenPlatformDeviceClass, parent_class);
+    DPRINTF("initializing %s\n", u->info.name);
+
     pci_conf = d->pci_dev.config;
 
     pci_set_word(pci_conf + PCI_COMMAND, PCI_COMMAND_IO | PCI_COMMAND_MEMORY);
< at >< at > -402,33 +421,63 < at >< at > static void platform_reset(DeviceState *dev)
     platform_fixed_ioport_reset(s);
 }
 
+static PCIXenPlatformDeviceInfo platform_devices[] = {
+    {
+        .name = "xen-platform",
+        .desc = "XEN platform pci device (version 1)",
+        .device_id = PCI_DEVICE_ID_XEN_PLATFORM,
+        .revision = 1,
+        .subsystem_vendor_id = PCI_VENDOR_ID_XEN,
+        .subsystem_id = PCI_DEVICE_ID_XEN_PLATFORM,
+    }, {
+        .name = "xen-platform-2",
+        .desc = "XEN platform pci device (version 2)",
+        .device_id = PCI_DEVICE_ID_XEN_PLATFORM_V2,
+        .revision = 2,
+        .subsystem_vendor_id = PCI_VENDOR_ID_XEN,
+        .subsystem_id = PCI_DEVICE_ID_XEN_PLATFORM_V2,
+    }
+};
+
 static void xen_platform_class_init(ObjectClass *klass, void *data)
 {
     DeviceClass *dc = DEVICE_CLASS(klass);
     PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+    PCIXenPlatformDeviceInfo *info = data;
+    PCIXenPlatformDeviceClass *u;
+
+    u = container_of(k, PCIXenPlatformDeviceClass, parent_class);
 
     k->init = xen_platform_initfn;
     k->vendor_id = PCI_VENDOR_ID_XEN;
-    k->device_id = PCI_DEVICE_ID_XEN_PLATFORM;
+    k->device_id = info->device_id;
     k->class_id = PCI_CLASS_OTHERS << 8 | 0x80;
-    k->subsystem_vendor_id = PCI_VENDOR_ID_XEN;
-    k->subsystem_id = PCI_DEVICE_ID_XEN_PLATFORM;
-    k->revision = 1;
-    dc->desc = "XEN platform pci device";
+    k->subsystem_vendor_id = info->subsystem_vendor_id;
+    k->subsystem_id = info->subsystem_id;
+    k->revision = info->revision;
+    dc->desc = info->desc;
     dc->reset = platform_reset;
     dc->vmsd = &vmstate_xen_platform;
+    u->info = *info;
 }
 
-static const TypeInfo xen_platform_info = {
-    .name          = "xen-platform",
-    .parent        = TYPE_PCI_DEVICE,
-    .instance_size = sizeof(PCIXenPlatformState),
-    .class_init    = xen_platform_class_init,
-};
-
 static void xen_platform_register_types(void)
 {
-    type_register_static(&xen_platform_info);
+    TypeInfo type_info = {
+        .parent        = TYPE_PCI_DEVICE,
+        .instance_size = sizeof(PCIXenPlatformState),
+        .class_size    = sizeof(PCIXenPlatformDeviceClass),
+        .class_init    = xen_platform_class_init,
+    };
+    int i;
+    for (i = 0; i < ARRAY_SIZE(platform_devices); i++) {
+        PCIXenPlatformDeviceInfo *info = &platform_devices[i];
+
+        type_info.name = info->name;
+        type_info.class_data = info;
+        
+        type_register(&type_info);
+    }
 }
 
 type_init(xen_platform_register_types)
diff --git a/include/hw/pci/pci_ids.h b/include/hw/pci/pci_ids.h
index d8dc2f1..2039fba 100644
--- a/include/hw/pci/pci_ids.h
+++ b/include/hw/pci/pci_ids.h
< at >< at > -144,6 +144,7 < at >< at >
 
 #define PCI_VENDOR_ID_XEN               0x5853
 #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
+#define PCI_DEVICE_ID_XEN_PLATFORM_V2   0x0002
 
 #define PCI_VENDOR_ID_NEC                0x1033
 #define PCI_DEVICE_ID_NEC_UPD720200      0x0194

Re: [Qemu-devel] [PATCH] Remove hardcoded xen-platform device initialization

Paul Durrant — 2013-06-19T09:11:28

...in which case can we agree to accept an undocumented override ability in the cfg file. If we're going to introduce some form of auto-selection then we should at least allow developers to bypass it if they need to. I'm happy to get rid the the enumeration, and go for a freeform string which gets passed as the -machine optval if it's specified.

  Paul
_______________________________________________
Xen-devel mailing list
Xen-devel< at >lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH] Add a device_model_machine option for HVM domains to libxl.

Ian Campbell — 2013-06-19T09:10:03

Ah, I think what is supposed to happen is:
libxl_domain_build_info_init: memsets the whole thing to zero and then
explicitly initialises any non-zero defaults

libxl_domain_build_info_init_type: initialises any additional non-zero
defaults based on having determined the type for the union.

Since your enum defaults to zero I think it is therefore expected that
it isn't explicitly initialised, although it doesn't explain why the
field isn't caught by the memset.


Good idea to be safe.

If that doesn't help then my guess would be that something is
overwriting the field (e.g. via an erroneous use of u.pv outside a
switch/if). In that case could you try bisecting with printf between the
call to libxl_domain_build_info_init and the point where you needed to
initialise.

some problems to start vTPM vtpm-stubdom

Xu, Quan — 2013-06-19T09:02:48

Hi community,
   there are some problems to start vTPM vtpm-stubdom following docs/misc/vtpm.txt. When I start vtpm-stbdom, the vtpmmgr-stubdom will print out:
===
ERROR[VTPM]: LoadKey failure: Unrecognized uuid! 69743ae0-9d4a-4ad6-9819-e602085b6792
ERROR[VTPM]: Failed to load key
ERROR in vtpmmgr_LoadHashKey at vtpm_cmd_handler.c:78 code: TPM_BAD_PARAMETER.
===

 I start vtpmmgr-stubdom with vtpmmgr.cfg as below:
==== 
kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
memory=16
disk=["file:/var/vtpmmgr-stubdom.img,hda,w"]
name="vtpmmgr"
iomem=["fed40,1"]
==== 
It prints out with below:
=======
Parsing config from vtpmmgr.cfg
Daemon running with PID 2406
Xen Minimal OS!
  start_info: 0xa2000(VA)
    nr_pages: 0x1000
  shared_inf: 0xcd7b0000(MA)
     pt_base: 0xa5000(VA)
nr_pt_frames: 0x5
    mfn_list: 0x9a000(VA)
   mod_start: 0x0(VA)
     mod_len: 0
       flags: 0x0
    cmd_line:
  stack:      0x597e0-0x797e0
MM: Init
      _text: 0x0(VA)
     _etext: 0x39357(VA)
   _erodata: 0x45000(VA)
     _edata: 0x47c40(VA)
stack start: 0x597e0(VA)
       _end: 0x99e00(VA)
  start_pfn: ad
    max_pfn: 1000
Mapping memory range 0x400000 - 0x1000000
setting 0x0-0x45000 readonly
skipped 0x1000
MM: Initialise page allocator for b3000(b3000)-1000000(1000000)
MM: done
Demand map pfns at 1001000-2001001000.
Heap resides at 2001002000-4001002000.
Initialising timer interface
Initialising console ... done.
gnttab_table mapped at 0x1001000.
Initialising scheduler
Thread "Idle": pointer: 0x2001002050, stack: 0xd0000
Thread "xenstore": pointer: 0x2001002800, stack: 0xe0000
xenbus initialised on irq 1 mfn 0x1f1c9d
Thread "shutdown": pointer: 0x2001002fb0, stack: 0xf0000
Dummy main: start_info=0x798e0
Thread "main": pointer: 0x2001003760, stack: 0x100000
"main"
Shutting down ()
Shutdown requested: 3
Thread "shutdown" exited.
INFO[VTPM]: Starting vTPM manager domain
INFO[VTPM]: Option: Using tpm_tis driver
******************* BLKFRONT for device/vbd/768 **********


backend at /local/domain/0/backend/qdisk/1/768
Failed to read /local/domain/0/backend/qdisk/1/768/feature-barrier.
32768 sectors of 512 bytes
**************************
blk_open(device/vbd/768) -> 3
============= Init TPM BACK ================
Thread "tpmback-listener": pointer: 0x20010043f0, stack: 0xf0000
============= Init TPM TIS Driver ==============
IOMEM Machine Base Address: FED40000
Enabled Localities: 0
1.2 TPM (device-id=0xB vendor-id = 15D1 rev-id = 10)
TPM interface capabilities (0x800000ff):
        Command Ready Int Support
        Interrupt Edge Falling
        Interrupt Edge Rising
        Interrupt Level Low
        Interrupt Level High
        Locality Change Int Support
        Sts Valid Int Support
        Data Avail Int Support
tpm_tis_open() -> 4
INFO[TPM]: TPM_GetCapability
INFO[VTPM]: Hardware TPM:
INFO[VTPM]:  version: 1 2 3 17
INFO[VTPM]:  specLevel: 2
INFO[VTPM]:  errataRev: 2
INFO[VTPM]:  vendorID: IFX
INFO[VTPM]:  vendorSpecificSize: 5
INFO[VTPM]:  vendorSpecific: 0311000800
INFO[TPM]: TPM_GetCapability
INFO[TPM]: TPM_GetCapability
INFO[TPM]: TPM_GetCapability
INFO[TPM]: TPM_GetCapability
INFO[TPM]: TPM_GetCapability
INFO[TPM]: TPM_GetCapability
INFO[TPM]: TPM_GetRandom
INFO[TPM]: TPM_GetRandom
INFO[TPM]: TPM_OIAP
INFO[TPM]: Auth Session: 0x995ab1 opened by TPM_OIAP.
INFO[VTPM]: Loading disk image header
INFO[VTPM]: Unpacking storage key
INFO[TPM]: TPM_LoadKey
INFO[TPM]: Key Handle: 0x5ec1f7e opened by TPM_LoadKey
INFO[VTPM]: Unbinding uuid table symmetric key
INFO[TPM]: TPM_UnBind
INFO[VTPM]: Waiting for commands from vTPM's:
====== 

I start vtpm-stbdom with below:
kernel="/usr/lib/xen/boot/vtpm-stubdom.gz"
memory=8
disk=["file:/root/img/vtpm.img,hda,w"]
name="domu-vtpm"
vtpm=["backend=vtpmmgr,uuid=69743ae0-9d4a-4ad6-9819-e602085b6792"]

and print out:
======
Parsing config from vtpm.cfg
Daemon running with PID 2618
Xen Minimal OS!
  start_info: 0xf0000(VA)
    nr_pages: 0x800
  shared_inf: 0xdc0e4000(MA)
     pt_base: 0xf3000(VA)
nr_pt_frames: 0x5
    mfn_list: 0xec000(VA)
   mod_start: 0x0(VA)
     mod_len: 0
       flags: 0x0
    cmd_line:
  stack:      0xab1e0-0xcb1e0
MM: Init
      _text: 0x0(VA)
     _etext: 0x7e647(VA)
   _erodata: 0x93000(VA)
     _edata: 0x95a80(VA)
stack start: 0xab1e0(VA)
       _end: 0xeb800(VA)
  start_pfn: fb
    max_pfn: 800
Mapping memory range 0x400000 - 0x800000
setting 0x0-0x93000 readonly
skipped 0x1000
MM: Initialise page allocator for fd000(fd000)-800000(800000)
MM: done
Demand map pfns at 801000-2000801000.
Heap resides at 2000802000-4000802000.
Initialising timer interface
Initialising console ... done.
gnttab_table mapped at 0x801000.
Initialising scheduler
Thread "Idle": pointer: 0x2000802050, stack: 0x110000
Thread "xenstore": pointer: 0x2000802800, stack: 0x120000
xenbus initialised on irq 1 mfn 0x185e7d
Thread "shutdown": pointer: 0x2000802fb0, stack: 0x130000
Dummy main: start_info=0xcb2e0
Thread "main": pointer: 0x2000803760, stack: 0x140000
"main"
Shutting down ()
Shutdown requested: 3
Thread "shutdown" exited.
vtpm.c:425: Info: starting TPM Emulator (1.2.0.7-475)
vtpm.c:357: Info: Startup mode is `clear'
vtpm.c:387: Info: All PCRs initialized to default values
vtpm.c:391: Info: TPM Maintenance Commands disabled
vtpm.c:401: Info: Log level set to (null)
============= Init TPM BACK ================
Thread "tpmback-listener": pointer: 0x2000802fb0, stack: 0x130000
============= Init TPM Front ================
Tpmfront:Info Waiting for backend connection..
Tpmfront:Info Backend Connected
Tpmfront:Info Initialization Completed successfully
vtpmblk.c:34: Info: Initializing persistent NVM storage

******************* BLKFRONT for device/vbd/768 **********


backend at /local/domain/0/backend/qdisk/2/768
Failed to read /local/domain/0/backend/qdisk/2/768/feature-barrier.
16384 sectors of 512 bytes
**************************
blk_open(device/vbd/768) -> 3
vtpm.c:175: Info: VTPM Initializing

tpm_cmd_handler.c:4113: Debug: tpm_emulator_init(1, 0x00000007)
vtpm_cmd.c:155: Info: Requesting Encryption key from backend
vtpm_cmd.c:164: Error: VTPM_LoadHashKey() failed with error code (3)
vtpm_cmd.c:175: Error: VTPM_LoadHashKey failed
tpm_data.c:120: Info: initializing TPM data to default values
tpm_startup.c:29: Info: TPM_Init()
tpm_testing.c:243: Info: TPM_SelfTestFull()
tpm_testing.c:39: Debug: tpm_test_prng()
tpm_testing.c:69: Debug: Monobit: 9922
tpm_testing.c:70: Debug: Poker:   17.6
tpm_testing.c:71: Debug: run_1:   2471, 2582
tpm_testing.c:72: Debug: run_2:   1364, 1259
tpm_testing.c:73: Debug: run_3:   616, 588
tpm_testing.c:74: Debug: run_4:   298, 331
tpm_testing.c:75: Debug: run_5:   139, 155
tpm_testing.c:76: Debug: run_6+:  163, 137
tpm_testing.c:77: Debug: run_34:  0
tpm_testing.c:111: Debug: tpm_test_sha1()
tpm_testing.c:157: Debug: tpm_test_hmac()
tpm_testing.c:184: Debug: tpm_test_rsa_EK()
tpm_testing.c:186: Debug: tpm_rsa_generate_key()
tpm_testing.c:191: Debug: testing endorsement key
tpm_testing.c:197: Debug: tpm_rsa_sign(RSA_SSA_PKCS1_SHA1)
tpm_testing.c:200: Debug: tpm_rsa_verify(RSA_SSA_PKCS1_SHA1)
tpm_testing.c:203: Debug: tpm_rsa_sign(RSA_SSA_PKCS1_DER)
tpm_testing.c:206: Debug: tpm_rsa_verify(RSA_SSA_PKCS1_DER)
tpm_testing.c:210: Debug: tpm_rsa_encrypt(RSA_ES_PKCSV15)
tpm_testing.c:214: Debug: tpm_rsa_decrypt(RSA_ES_PKCSV15)
tpm_testing.c:218: Debug: verify plain text
tpm_testing.c:221: Debug: tpm_rsa_encrypt(RSA_ES_OAEP_SHA1)
tpm_testing.c:225: Debug: tpm_rsa_decrypt(RSA_ES_OAEP_SHA1)
tpm_testing.c:229: Debug: verify plain text
tpm_testing.c:261: Info: Self-Test succeeded
tpm_startup.c:43: Info: TPM_Startup(1)
################## 


Actually XSM is enabled, 'xl dmesg' can get below info:

(XEN) XSM Framework v1.0.0 initialized
(XEN) Policy len  0x25bf, start at ffff83021dffd000.
(XEN) Flask:  Initializing.
(XEN) AVC INITIALIZED
(XEN) Flask: 128 avtab hash slots, 276 rules.
(XEN) Flask: 128 avtab hash slots, 276 rules.
(XEN) Flask:  3 users, 3 roles, 39 types, 1 bools
(XEN) Flask:  11 classes, 276 rules
(XEN) Flask:  Starting in permissive mode.

Could you help me to fix it. Thanks in advance.



Quan,Xu
Intel

Re: [PATCH] Add a device_model_machine option for HVM domains to libxl.

Paul Durrant — 2013-06-19T09:00:16

No sign of initialization here... Perhaps I needed to delete the fail to cause re-generation, or maybe running 'make tools' is not enough?

void libxl_domain_build_info_init_type(libxl_domain_build_info *p, libxl_domain_type type)
{
    assert(p->type == LIBXL_DOMAIN_TYPE_INVALID);
    p->type = type;
    switch (p->type) {
    case LIBXL_DOMAIN_TYPE_HVM:
        p->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
        libxl_vga_interface_info_init(&p->u.hvm.vga);
        libxl_vnc_info_init(&p->u.hvm.vnc);
        libxl_sdl_info_init(&p->u.hvm.sdl);
        libxl_spice_info_init(&p->u.hvm.spice);
        break;
    case LIBXL_DOMAIN_TYPE_PV:
        p->u.pv.slack_memkb = LIBXL_MEMKB_DEFAULT;
        break;
    case LIBXL_DOMAIN_TYPE_INVALID:
        break;
    }
}

Re: [Qemu-devel] [PATCH] Remove hardcoded xen-platform device initialization

Ian Campbell — 2013-06-19T08:56:09

I had a grep around libvirt wondering how it handled this and didn't
find it. The approach you describe makes perfect sense when you have a
persistent config. The case with xl is more like your example 5:


For something like xapi we'd likely want to support some sort of model
similar to libvirt, so whatever we do at the libxl layer needs to
consider both approaches.


Not to mention that on a system already running a domain or two there is
a good chance that at least the relevant bits of QEMU are already in
RAM.

In fact, I wonder if we could just query the qemu which is running to
provide dom0 itself with qdisk services, at least in the case where the
guest is configured to use the same version of qemu.

Ian.

Re: [PATCH] Add a device_model_machine option for HVM domains to libxl.

Ian Campbell — 2013-06-19T08:47:57

Weird. The autogenerated function "libxl_domain_build_info_init_type"
should have coped with this, can you post its content?

Ian.

Re: pygrub patch to allow explicit offset to fs

Ian Campbell — 2013-06-19T08:44:46

Yes, and the original had this problem too now you mention it.


I claim pseudo-code ;-)

Re: [Qemu-devel] [PATCH] Remove hardcoded xen-platform device initialization

Paolo Bonzini — 2013-06-19T08:41:25

Il 19/06/2013 10:29, Ian Campbell ha scritto:

Usually it represents adding _features_ to the emulation.  There are
some cases where the set of emulated peripherals change (e.g. pvpanic
added in 1.5), but it's the exception rather than the rule.  There are
also some cases of bug-compatibility, but again they're not the most
common use of versioned machine types.

You do not know how older guests react to those new features, and you
want to prevent moving guests to older versions that lack some features.
 For these reasons, libvirt always sticks to the alias target that was
found at creation time.

Example 1: you defined a machine last year with machine type "pc".
libvirt actually stored it with machine type "pc-1.2".  Today you run it
and hardware/features do not change.

Example 2: you defined a machine today with machine type "pc".  libvirt
actually stored it with machine type "pc-1.6".  You run it on a machine
with an old QEMU, the machine doesn't start.

Example 3: you ask libvirt to edit the definition of the machine of
example 1.  You change the machine type back to "pc".  libvirt stores it
with machine type "pc-1.6".  Hardware may change compared to the
previous runs of the VM, but it will otherwise remain stable.

Example 4: you use vi to edit the definition of the machine of example
1/3.  You change the machine type to "pc".  You lose any guarantee that
hardware does not change.  You should not do this.

Example 5: you use "virsh create" to start a VM based on an XML file,
rather than "virsh define"+"virsh start" as in examples 1-2.  You lose
any guarantee that hardware does not change.  Not frowned upon as much
as example 4, since the VM is supposed to be transient.


That can be a good idea, since Xen support is a bit less tested than KVM
with bleeding-edge QEMU.  You can query the machine types from the Xen
toolchain, and auto-remap "pc" to a machine type that is never newer
than what you consider to be well-tested.

It would require two QEMU invocations per "xl create".  However, most of
the startup time of QEMU is loading dynamic libraries.  A good deal of
that time amortizes well over two invocations of QEMU.  Hence, you can
use the first invocation to query the machine type (using "-nodefaults
-nographic" etc. and a QMP connection), and the second to actually start
the VM.

Paolo

Re: pygrub patch to allow explicit offset to fs

Wei Liu — 2013-06-19T08:39:54

Need to take care of exception in this conversion.


You do know you missed a "=" here, right? :-)


Wei.

Re: [Qemu-devel] [PATCH] Remove hardcoded xen-platform device initialization

Paul Durrant — 2013-06-19T08:37:39

If that is the case then the xenfv code is also incorrect, since it does not call through to a specific version of 'pc'.

  Paul
_______________________________________________
Xen-devel mailing list
Xen-devel< at >lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH] Add a device_model_machine option for HVM domains to libxl.

Paul Durrant — 2013-06-19T08:33:13

Ok, but what is the *right* one? Would you accept this patch without the manpage tweak? Xenfv's hardcoded platform device creation is completely stalling my attempts to get Citrix Windows PV drivers running on upstream. Having this option and defaulting it to xenfv seems like a fairly pragmatic approach to me.

  Paul

Re: evtchn_bind_interdomain() { struct domain *ld= current->domain } but why it is always current->domain ?

Ian Campbell — 2013-06-19T08:30:24

Which other domain would you expect it to be?

xen/incude/public/event_channel.h says:
 * EVTCHNOP_bind_interdomain: Construct an interdomain event channel between
 * the calling domain and <remote_dom>. <remote_dom,remote_port> must identify
 * a port that is unbound and marked as accepting bindings from the calling
 * domain. A fresh port is allocated in the calling domain and returned as
 * <local_port>.

The important part being "between the calling domain".

Ian.

Re: [PATCH] Add a device_model_machine option for HVM domains to libxl.

Paul Durrant — 2013-06-19T08:29:40

That's what I thought. But without that line I seem to get some random value.

  Paul

Re: [Qemu-devel] [PATCH] Remove hardcoded xen-platform device initialization

Ian Campbell — 2013-06-19T08:29:03

Actually, this raises an interesting point. AIUI "pc" is simply and
alias for the most recent "pc-X.Y" and "pc-X.Y" is present to allow for
qemu "upgrading" the set of emulated hardware, as in it represents
changing the set of emulated peripherals, not just fixing bugs in the
emulation etc, is that right?

I think it would be preferable for us to request a specific platform
(pc-i440fx-1.6 if that's the one) and a conscious decision to support
newer platforms (and can test it etc).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel< at >lists.xen.org
http://lists.xen.org/xen-devel