* xensource (pci) device id's? @ 2007-02-01 13:53 Gerd Hoffmann 2007-02-01 13:58 ` Ian Campbell 0 siblings, 1 reply; 26+ messages in thread From: Gerd Hoffmann @ 2007-02-01 13:53 UTC (permalink / raw) To: Xen devel list [-- Attachment #1: Type: text/plain, Size: 440 bytes --] Hi, Just found this: master-xen root ~# grep -A1 -i xensource /usr/share/pci.ids fffd XenSource, Inc. 0101 PCI Event Channel Controller master-xen root ~# Is this an official vendor id assignment? Anyone at xensource hands out device id's? I'd like give id's to virtual devices (like in the patch attached) to make hardware detection and configuration easier ... cheers, Gerd -- Gerd Hoffmann <kraxel@suse.de> [-- Attachment #2: fix-xenkbd-2.diff --] [-- Type: text/x-patch, Size: 917 bytes --] --- linux-2.6-xen-sparse/drivers/xen/fbfront/xenkbd.c | 6 ++++++ 1 file changed, 6 insertions(+) Index: build-64-unstable-13762/linux-2.6-xen-sparse/drivers/xen/fbfront/xenkbd.c =================================================================== --- build-64-unstable-13762.orig/linux-2.6-xen-sparse/drivers/xen/fbfront/xenkbd.c +++ build-64-unstable-13762/linux-2.6-xen-sparse/drivers/xen/fbfront/xenkbd.c @@ -121,7 +121,13 @@ int __devinit xenkbd_probe(struct xenbus set_bit(i, kbd->keybit); kbd->name = "Xen Virtual Keyboard"; + kbd->id.bustype = BUS_PCI; + kbd->id.vendor = 0xfffd; /* XenSource, Inc. */ + kbd->id.product = 0x0001; ptr->name = "Xen Virtual Touchscreen"; + ptr->id.bustype = BUS_PCI; + ptr->id.vendor = 0xfffd; /* XenSource, Inc. */ + ptr->id.product = 0x0002; input_set_abs_params(ptr, ABS_X, 0, XENFB_WIDTH, 0, 0); input_set_abs_params(ptr, ABS_Y, 0, XENFB_HEIGHT, 0, 0); [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: xensource (pci) device id's? 2007-02-01 13:53 xensource (pci) device id's? Gerd Hoffmann @ 2007-02-01 13:58 ` Ian Campbell 2007-02-01 14:30 ` Gerd Hoffmann 0 siblings, 1 reply; 26+ messages in thread From: Ian Campbell @ 2007-02-01 13:58 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: Xen devel list On Thu, 2007-02-01 at 14:53 +0100, Gerd Hoffmann wrote: > Hi, > > Just found this: > > master-xen root ~# grep -A1 -i xensource /usr/share/pci.ids > fffd XenSource, Inc. > 0101 PCI Event Channel Controller > master-xen root ~# > > Is this an official vendor id assignment? This was the id we used as a placeholder before we got the official assignment. We now have vendor 5853 officially assigned. http://pci-ids.ucw.cz/iii/?i=5853 Ian ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: xensource (pci) device id's? 2007-02-01 13:58 ` Ian Campbell @ 2007-02-01 14:30 ` Gerd Hoffmann 2007-02-01 15:45 ` Gerd Hoffmann 2007-02-01 20:02 ` Zulauf, John 0 siblings, 2 replies; 26+ messages in thread From: Gerd Hoffmann @ 2007-02-01 14:30 UTC (permalink / raw) To: Ian Campbell; +Cc: Xen devel list Ian Campbell wrote: > This was the id we used as a placeholder before we got the official > assignment. > > We now have vendor 5853 officially assigned. > http://pci-ids.ucw.cz/iii/?i=5853 Ok, how device IDs are allocated? I'd like to use them to tag virtual devices ... cheers, Gerd btw: I guess usb and pci vendor ids are not the same namespace? -- Gerd Hoffmann <kraxel@suse.de> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: xensource (pci) device id's? 2007-02-01 14:30 ` Gerd Hoffmann @ 2007-02-01 15:45 ` Gerd Hoffmann 2007-02-02 9:26 ` Ian Campbell ` (2 more replies) 2007-02-01 20:02 ` Zulauf, John 1 sibling, 3 replies; 26+ messages in thread From: Gerd Hoffmann @ 2007-02-01 15:45 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: Xen devel list, Ian Campbell [-- Attachment #1: Type: text/plain, Size: 262 bytes --] Gerd Hoffmann wrote: > Ian Campbell wrote: >> We now have vendor 5853 officially assigned. > > Ok, how device IDs are allocated? I'd like to use them to tag virtual > devices ... ... like this (see attached patch), handing out numbers 2-6 ... cheers, Gerd [-- Attachment #2: add-pci-ids.diff --] [-- Type: text/x-patch, Size: 3226 bytes --] --- linux-2.6-xen-sparse/drivers/xen/fbfront/xenkbd.c | 6 ++++++ tools/ioemu/hw/cirrus_vga.c | 4 ++++ tools/ioemu/hw/ide.c | 4 ++++ tools/ioemu/hw/rtl8139.c | 6 ++++-- 4 files changed, 18 insertions(+), 2 deletions(-) Index: build-64-unstable-13762/linux-2.6-xen-sparse/drivers/xen/fbfront/xenkbd.c =================================================================== --- build-64-unstable-13762.orig/linux-2.6-xen-sparse/drivers/xen/fbfront/xenkbd.c +++ build-64-unstable-13762/linux-2.6-xen-sparse/drivers/xen/fbfront/xenkbd.c @@ -123,7 +123,13 @@ int __devinit xenkbd_probe(struct xenbus set_bit(i, kbd->keybit); kbd->name = "Xen Virtual Keyboard"; + kbd->id.bustype = BUS_PCI; + kbd->id.vendor = 0x5853; /* XenSource, Inc. */ + kbd->id.product = 0x0002; ptr->name = "Xen Virtual Pointer"; + ptr->id.bustype = BUS_PCI; + ptr->id.vendor = 0x5853; /* XenSource, Inc. */ + ptr->id.product = 0x0003; input_set_abs_params(ptr, ABS_X, 0, XENFB_WIDTH, 0, 0); input_set_abs_params(ptr, ABS_Y, 0, XENFB_HEIGHT, 0, 0); Index: build-64-unstable-13762/tools/ioemu/hw/rtl8139.c =================================================================== --- build-64-unstable-13762.orig/tools/ioemu/hw/rtl8139.c +++ build-64-unstable-13762/tools/ioemu/hw/rtl8139.c @@ -3423,8 +3423,10 @@ void pci_rtl8139_init(PCIBus *bus, NICIn pci_conf[0x0e] = 0x00; /* header_type */ pci_conf[0x3d] = 1; /* interrupt pin 0 */ pci_conf[0x34] = 0xdc; - pci_conf[0x2c] = pci_conf[0x00]; // same as Vendor ID - pci_conf[0x2d] = pci_conf[0x01]; + pci_conf[0x2c] = 0x53; /* subsystem vendor: XenSource */ + pci_conf[0x2d] = 0x58; + pci_conf[0x2e] = 0x04; /* subsystem device */ + pci_conf[0x2f] = 0x00; s = &d->rtl8139; Index: build-64-unstable-13762/tools/ioemu/hw/cirrus_vga.c =================================================================== --- build-64-unstable-13762.orig/tools/ioemu/hw/cirrus_vga.c +++ build-64-unstable-13762/tools/ioemu/hw/cirrus_vga.c @@ -3340,6 +3340,10 @@ void pci_cirrus_vga_init(PCIBus *bus, Di pci_conf[0x0a] = PCI_CLASS_SUB_VGA; pci_conf[0x0b] = PCI_CLASS_BASE_DISPLAY; pci_conf[0x0e] = PCI_CLASS_HEADERTYPE_00h; + pci_conf[0x2c] = 0x53; /* subsystem vendor: XenSource */ + pci_conf[0x2d] = 0x58; + pci_conf[0x2e] = 0x05; /* subsystem device */ + pci_conf[0x2f] = 0x00; /* setup VGA */ s = &d->cirrus_vga; Index: build-64-unstable-13762/tools/ioemu/hw/ide.c =================================================================== --- build-64-unstable-13762.orig/tools/ioemu/hw/ide.c +++ build-64-unstable-13762/tools/ioemu/hw/ide.c @@ -2502,6 +2502,10 @@ void pci_piix3_ide_init(PCIBus *bus, Blo pci_conf[0x0a] = 0x01; // class_sub = PCI_IDE pci_conf[0x0b] = 0x01; // class_base = PCI_mass_storage pci_conf[0x0e] = 0x00; // header_type + pci_conf[0x2c] = 0x53; /* subsystem vendor: XenSource */ + pci_conf[0x2d] = 0x58; + pci_conf[0x2e] = 0x06; /* subsystem device */ + pci_conf[0x2f] = 0x00; pci_register_io_region((PCIDevice *)d, 4, 0x10, PCI_ADDRESS_SPACE_IO, bmdma_map); [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: xensource (pci) device id's? 2007-02-01 15:45 ` Gerd Hoffmann @ 2007-02-02 9:26 ` Ian Campbell 2007-02-02 9:47 ` Gerd Hoffmann 2007-02-02 18:25 ` Keir Fraser 2007-02-02 19:03 ` Keir Fraser 2 siblings, 1 reply; 26+ messages in thread From: Ian Campbell @ 2007-02-02 9:26 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: Xen devel list On Thu, 2007-02-01 at 16:45 +0100, Gerd Hoffmann wrote: > kbd->name = "Xen Virtual Keyboard"; > + kbd->id.bustype = BUS_PCI; > + kbd->id.vendor = 0x5853; /* XenSource, Inc. */ > + kbd->id.product = 0x0002; > ptr->name = "Xen Virtual Pointer"; > + ptr->id.bustype = BUS_PCI; > + ptr->id.vendor = 0x5853; /* XenSource, Inc. */ > + ptr->id.product = 0x0003; This isn't strictly true because this isn't really a PCI device. Is BUS_HOST not more appropriate? Possibly we could still use our PCI vendor/product IDs since I guess they are pretty arbitrary with in the BUS_HOST namespace. What does the input layer do with these values anyway? Ian. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: xensource (pci) device id's? 2007-02-02 9:26 ` Ian Campbell @ 2007-02-02 9:47 ` Gerd Hoffmann 0 siblings, 0 replies; 26+ messages in thread From: Gerd Hoffmann @ 2007-02-02 9:47 UTC (permalink / raw) To: Ian Campbell; +Cc: Xen devel list Ian Campbell wrote: > On Thu, 2007-02-01 at 16:45 +0100, Gerd Hoffmann wrote: >> kbd->name = "Xen Virtual Keyboard"; >> + kbd->id.bustype = BUS_PCI; >> + kbd->id.vendor = 0x5853; /* XenSource, Inc. */ >> + kbd->id.product = 0x0002; >> ptr->name = "Xen Virtual Pointer"; >> + ptr->id.bustype = BUS_PCI; >> + ptr->id.vendor = 0x5853; /* XenSource, Inc. */ >> + ptr->id.product = 0x0003; > > This isn't strictly true because this isn't really a PCI device. Is > BUS_HOST not more appropriate? Reason I've picked PCI is simply because they are taken from PCI namespace. > Possibly we could still use our PCI vendor/product IDs since I guess > they are pretty arbitrary with in the BUS_HOST namespace. What does the > input layer do with these values anyway? Nothing. It's for userspace, to make detection and configuration easier. In practice it probably doesn't matter much whenever it is BUS_PCI or BUS_HOST. But we should stick with the one we pick ... cheers, Gerd -- Gerd Hoffmann <kraxel@suse.de> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: xensource (pci) device id's? 2007-02-01 15:45 ` Gerd Hoffmann 2007-02-02 9:26 ` Ian Campbell @ 2007-02-02 18:25 ` Keir Fraser 2007-02-05 8:48 ` Gerd Hoffmann 2007-02-05 14:20 ` Gerd Hoffmann 2007-02-02 19:03 ` Keir Fraser 2 siblings, 2 replies; 26+ messages in thread From: Keir Fraser @ 2007-02-02 18:25 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: Xen devel list, Ian Campbell On 1/2/07 15:45, "Gerd Hoffmann" <kraxel@suse.de> wrote: >> Ok, how device IDs are allocated? I'd like to use them to tag virtual >> devices ... > > ... like this (see attached patch), handing out numbers 2-6 ... Looks okay. The subvendor device id's can all be the same (e.g., 0x1, as I'm not sure about validity of 0x0), since disambiguation amongst device types is already provided by the main vendor/device id's. Then 0x5853/0x0001 becomes our default subvendor 'tag' for identifying Xen-emulated devices, and we can reserve the right to bump the subvendor device id in future (0x2, 0x3, ...) for each device if some useful-for-guest-to-know aspect of the device model changes in future (so we basically reserve the right to treat it as a version number). Sound reasonable? -- Keir ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: xensource (pci) device id's? 2007-02-02 18:25 ` Keir Fraser @ 2007-02-05 8:48 ` Gerd Hoffmann 2007-02-05 14:20 ` Gerd Hoffmann 1 sibling, 0 replies; 26+ messages in thread From: Gerd Hoffmann @ 2007-02-05 8:48 UTC (permalink / raw) To: Keir Fraser; +Cc: Xen devel list, Ian Campbell Keir Fraser wrote: > > > On 1/2/07 15:45, "Gerd Hoffmann" <kraxel@suse.de> wrote: > >>> Ok, how device IDs are allocated? I'd like to use them to tag virtual >>> devices ... >> ... like this (see attached patch), handing out numbers 2-6 ... > > Looks okay. The subvendor device id's can all be the same (e.g., 0x1, as I'm > not sure about validity of 0x0) > Sound reasonable? Yes, 0x01 should be ok, 0x00 isn't valid as far I know. cheers, Gerd -- Gerd Hoffmann <kraxel@suse.de> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: xensource (pci) device id's? 2007-02-02 18:25 ` Keir Fraser 2007-02-05 8:48 ` Gerd Hoffmann @ 2007-02-05 14:20 ` Gerd Hoffmann 1 sibling, 0 replies; 26+ messages in thread From: Gerd Hoffmann @ 2007-02-05 14:20 UTC (permalink / raw) To: Keir Fraser; +Cc: Xen devel list, Ian Campbell [-- Attachment #1: Type: text/plain, Size: 489 bytes --] Keir Fraser wrote: > >>> Ok, how device IDs are allocated? I'd like to use them to tag virtual >>> devices ... >> ... like this (see attached patch), handing out numbers 2-6 ... > > Looks okay. The subvendor device id's can all be the same (e.g., 0x1, as I'm > not sure about validity of 0x0), since disambiguation amongst device types > is already provided by the main vendor/device id's. Then 0x5853/0x0001 Updated patch attached. cheers, Gerd -- Gerd Hoffmann <kraxel@suse.de> [-- Attachment #2: add-pci-ids.diff --] [-- Type: text/x-patch, Size: 2285 bytes --] --- tools/ioemu/hw/cirrus_vga.c | 4 ++++ tools/ioemu/hw/ide.c | 4 ++++ tools/ioemu/hw/rtl8139.c | 6 ++++-- 3 files changed, 12 insertions(+), 2 deletions(-) Index: build-32-unstable-13800/tools/ioemu/hw/rtl8139.c =================================================================== --- build-32-unstable-13800.orig/tools/ioemu/hw/rtl8139.c +++ build-32-unstable-13800/tools/ioemu/hw/rtl8139.c @@ -3423,8 +3423,10 @@ void pci_rtl8139_init(PCIBus *bus, NICIn pci_conf[0x0e] = 0x00; /* header_type */ pci_conf[0x3d] = 1; /* interrupt pin 0 */ pci_conf[0x34] = 0xdc; - pci_conf[0x2c] = pci_conf[0x00]; // same as Vendor ID - pci_conf[0x2d] = pci_conf[0x01]; + pci_conf[0x2c] = 0x53; /* subsystem vendor: XenSource */ + pci_conf[0x2d] = 0x58; + pci_conf[0x2e] = 0x01; /* subsystem device */ + pci_conf[0x2f] = 0x00; s = &d->rtl8139; Index: build-32-unstable-13800/tools/ioemu/hw/cirrus_vga.c =================================================================== --- build-32-unstable-13800.orig/tools/ioemu/hw/cirrus_vga.c +++ build-32-unstable-13800/tools/ioemu/hw/cirrus_vga.c @@ -3340,6 +3340,10 @@ void pci_cirrus_vga_init(PCIBus *bus, Di pci_conf[0x0a] = PCI_CLASS_SUB_VGA; pci_conf[0x0b] = PCI_CLASS_BASE_DISPLAY; pci_conf[0x0e] = PCI_CLASS_HEADERTYPE_00h; + pci_conf[0x2c] = 0x53; /* subsystem vendor: XenSource */ + pci_conf[0x2d] = 0x58; + pci_conf[0x2e] = 0x01; /* subsystem device */ + pci_conf[0x2f] = 0x00; /* setup VGA */ s = &d->cirrus_vga; Index: build-32-unstable-13800/tools/ioemu/hw/ide.c =================================================================== --- build-32-unstable-13800.orig/tools/ioemu/hw/ide.c +++ build-32-unstable-13800/tools/ioemu/hw/ide.c @@ -2502,6 +2502,10 @@ void pci_piix3_ide_init(PCIBus *bus, Blo pci_conf[0x0a] = 0x01; // class_sub = PCI_IDE pci_conf[0x0b] = 0x01; // class_base = PCI_mass_storage pci_conf[0x0e] = 0x00; // header_type + pci_conf[0x2c] = 0x53; /* subsystem vendor: XenSource */ + pci_conf[0x2d] = 0x58; + pci_conf[0x2e] = 0x01; /* subsystem device */ + pci_conf[0x2f] = 0x00; pci_register_io_region((PCIDevice *)d, 4, 0x10, PCI_ADDRESS_SPACE_IO, bmdma_map); [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: xensource (pci) device id's? 2007-02-01 15:45 ` Gerd Hoffmann 2007-02-02 9:26 ` Ian Campbell 2007-02-02 18:25 ` Keir Fraser @ 2007-02-02 19:03 ` Keir Fraser 2007-02-05 2:29 ` EPS Signature Kaushik Barde 2007-02-05 8:55 ` xensource (pci) device id's? Gerd Hoffmann 2 siblings, 2 replies; 26+ messages in thread From: Keir Fraser @ 2007-02-02 19:03 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: Xen devel list, Ian Campbell On 1/2/07 15:45, "Gerd Hoffmann" <kraxel@suse.de> wrote: > kbd->name = "Xen Virtual Keyboard"; > + kbd->id.bustype = BUS_PCI; > + kbd->id.vendor = 0x5853; /* XenSource, Inc. */ > + kbd->id.product = 0x0002; > ptr->name = "Xen Virtual Pointer"; > + ptr->id.bustype = BUS_PCI; > + ptr->id.vendor = 0x5853; /* XenSource, Inc. */ > + ptr->id.product = 0x0003; Instead of faking out PCI device ids, which is kinda bogus, can you match in the X config file based on the string(s) in {kbd,ptr}->{name,phys,uniq}? That'd be nicer than pulling random id numbers out of the air. -- Keir ^ permalink raw reply [flat|nested] 26+ messages in thread
* EPS Signature 2007-02-02 19:03 ` Keir Fraser @ 2007-02-05 2:29 ` Kaushik Barde 2007-02-05 2:52 ` Ian Pratt 2007-02-06 15:43 ` Andrew D. Ball 2007-02-05 8:55 ` xensource (pci) device id's? Gerd Hoffmann 1 sibling, 2 replies; 26+ messages in thread From: Kaushik Barde @ 2007-02-05 2:29 UTC (permalink / raw) To: Xen devel list Hi, We want to access the EBDA Entry Point Signature at 40:0E for our DOM-0 through a driver, We noticed that driver is trying to read from a pseudo physical location and not the physical machine RAM location. Hence it's not getting the proper value. But if we have to read from the machine RAM location we can use ( virt_to_bus or bus_to_virt) per dev_list comments. But this area is under the control of hypervisor. I do not know if we can ioremap these pages ( those which belong to hypervisor). I am trying to see if we can be able to get to the 40:0E address. And get the correct EPS signature -Kaushik ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: EPS Signature 2007-02-05 2:29 ` EPS Signature Kaushik Barde @ 2007-02-05 2:52 ` Ian Pratt 2007-02-10 7:52 ` GDT access from DOM-0 driver Kaushik Barde 2007-02-11 1:33 ` EPS Signature Kaushik Barde 2007-02-06 15:43 ` Andrew D. Ball 1 sibling, 2 replies; 26+ messages in thread From: Ian Pratt @ 2007-02-05 2:52 UTC (permalink / raw) To: Kaushik Barde, Xen devel list > We want to access the EBDA Entry Point Signature at 40:0E for our DOM-0 > through a driver, > We noticed that driver is trying to read from a pseudo physical location > and not the physical machine RAM location. Hence it's not getting the > proper value. But if we have to read from the machine RAM location we can > use ( virt_to_bus or bus_to_virt) per dev_list comments. > > But this area is under the control of hypervisor. I do not know if we can > ioremap these pages ( those which belong to hypervisor). > > I am trying to see if we can be able to get to the 40:0E address. And get > the correct EPS signature Dom0 already has the bottom 1MB of physical ram mapped. You can use the poorly named isa_bus_to_virt() Ian ^ permalink raw reply [flat|nested] 26+ messages in thread
* GDT access from DOM-0 driver 2007-02-05 2:52 ` Ian Pratt @ 2007-02-10 7:52 ` Kaushik Barde 2007-02-11 1:33 ` EPS Signature Kaushik Barde 1 sibling, 0 replies; 26+ messages in thread From: Kaushik Barde @ 2007-02-10 7:52 UTC (permalink / raw) To: Ian Pratt, Xen devel list Now I could get the EPS signature, However, we store some information about disk configuration options (HP/HPA) in unused area of GDT. Driver has physical memory read and write functions. These physical memory read / write functions have following assumptions: - Depending on the source physical address, we either use ioremap to map the page(s) in, or use phys_to_virt. - If the physical address has already been mapped by the kernel we can just use phys_to_virt. - If the address is not mapped, only up to one page size is copied, in an effort to reduce virtual address space usage. In this per your suggestion, because DOM0 RAM is already remapped, The virt_to_bus() or bus_to_virt() are replaced by isa_bus_to_virt()/isa_virt_to_bus() But what about phys_to_virt(), does driver need to change them to pseudo-physical address functions? Thanks. -Kaushik -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Ian Pratt Sent: Sunday, February 04, 2007 6:53 PM To: Kaushik Barde; Xen devel list Subject: RE: [Xen-devel] EPS Signature > We want to access the EBDA Entry Point Signature at 40:0E for our DOM-0 > through a driver, > We noticed that driver is trying to read from a pseudo physical location > and not the physical machine RAM location. Hence it's not getting the > proper value. But if we have to read from the machine RAM location we can > use ( virt_to_bus or bus_to_virt) per dev_list comments. > > But this area is under the control of hypervisor. I do not know if we can > ioremap these pages ( those which belong to hypervisor). > > I am trying to see if we can be able to get to the 40:0E address. And get > the correct EPS signature Dom0 already has the bottom 1MB of physical ram mapped. You can use the poorly named isa_bus_to_virt() Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: EPS Signature 2007-02-05 2:52 ` Ian Pratt 2007-02-10 7:52 ` GDT access from DOM-0 driver Kaushik Barde @ 2007-02-11 1:33 ` Kaushik Barde 2007-02-11 10:09 ` Keir Fraser 1 sibling, 1 reply; 26+ messages in thread From: Kaushik Barde @ 2007-02-11 1:33 UTC (permalink / raw) To: Ian Pratt, Xen devel list I get following Error.. 496: error: `isa_virt_to_bus_is_UNSUPPORTED' undeclared (first use in this function) Is it truely unsupported or I am missing proper includes.. I suspect later but "UNSUPPORTED" makes me uncomfortable. Please advise. -Kaushik -----Original Message----- From: xen-devel-bounces@lists.xensource.com on behalf of Ian Pratt Sent: Sun 2/4/2007 6:52 PM To: Kaushik Barde; Xen devel list Subject: RE: [Xen-devel] EPS Signature > We want to access the EBDA Entry Point Signature at 40:0E for our DOM-0 > through a driver, > We noticed that driver is trying to read from a pseudo physical location > and not the physical machine RAM location. Hence it's not getting the > proper value. But if we have to read from the machine RAM location we can > use ( virt_to_bus or bus_to_virt) per dev_list comments. > > But this area is under the control of hypervisor. I do not know if we can > ioremap these pages ( those which belong to hypervisor). > > I am trying to see if we can be able to get to the 40:0E address. And get > the correct EPS signature Dom0 already has the bottom 1MB of physical ram mapped. You can use the poorly named isa_bus_to_virt() Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: EPS Signature 2007-02-11 1:33 ` EPS Signature Kaushik Barde @ 2007-02-11 10:09 ` Keir Fraser 2007-02-11 23:39 ` Kaushik Barde 0 siblings, 1 reply; 26+ messages in thread From: Keir Fraser @ 2007-02-11 10:09 UTC (permalink / raw) To: Kaushik Barde, Ian Pratt, Xen devel list Isa_bus_to_virt() is available. Isa_virt_to_bus() isn't. Why would you need the latter? -- Keir On 11/2/07 01:33, "Kaushik Barde" <Kaushik_Barde@Phoenix.com> wrote: > > > I get following Error.. > > 496: error: `isa_virt_to_bus_is_UNSUPPORTED' undeclared (first use in this > function) > > Is it truely unsupported or I am missing proper includes.. > > I suspect later but "UNSUPPORTED" makes me uncomfortable. > > Please advise. > > -Kaushik > > > > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com on behalf of Ian Pratt > Sent: Sun 2/4/2007 6:52 PM > To: Kaushik Barde; Xen devel list > Subject: RE: [Xen-devel] EPS Signature > >> We want to access the EBDA Entry Point Signature at 40:0E for our > DOM-0 >> through a driver, >> We noticed that driver is trying to read from a pseudo physical > location >> and not the physical machine RAM location. Hence it's not getting the >> proper value. But if we have to read from the machine RAM location we > can >> use ( virt_to_bus or bus_to_virt) per dev_list comments. >> >> But this area is under the control of hypervisor. I do not know if we > can >> ioremap these pages ( those which belong to hypervisor). >> >> I am trying to see if we can be able to get to the 40:0E address. And > get >> the correct EPS signature > > Dom0 already has the bottom 1MB of physical ram mapped. You can use the > poorly named isa_bus_to_virt() > > Ian > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: EPS Signature 2007-02-11 10:09 ` Keir Fraser @ 2007-02-11 23:39 ` Kaushik Barde 2007-02-12 0:58 ` Keir Fraser 0 siblings, 1 reply; 26+ messages in thread From: Kaushik Barde @ 2007-02-11 23:39 UTC (permalink / raw) To: Keir Fraser, Ian Pratt, Xen devel list Actually, following code snippet where our DOM-0 driver tries to set some data in unused Gdt areas, Its generating Bad EIP errors when we try to access it (by it's physical address). SetGDT Code is something like following: { tGdtRequest l_Request; unsigned char *lp_Data; int cpu; struct desc_struct l_Desc, *gdt_table; u64 l_entry_ma; u64 l_desc_64; /* Get the structure from the user */ copy_from_user(&l_Request, (tGdtRequest *)arg, sizeof(tGdtRequest)); /* Set up a ptr to the kernel's GDT */ copy_from_user(&l_Desc, l_Request.userBuffer, sizeof(struct desc_struct)); cpu = get_cpu(); gdt_table = get_cpu_gdt_table(cpu); l_entry_ma = virt_to_bus(&(gdt_table[l_Request.entryNum])); l_desc_64 = *( (u64 *) &l_Desc); HYPERVISOR_update_descriptor(l_entry_ma, l_desc_64); //l_Desc = gdt_table[l_Request.entryNum] = l_Desc; put_cpu(); } Which has call to virt_to_bus(..), which I thought was a suspect, hence, the usage question.. I also tried using HYPERVISOR_update_descriptor(..) instead..without much luck. I am also little confused, if the memory/io mapping is taken care of by Xen, shouldn't DOM-0 driver calls remain unchanged? Or be compiled with Xen replacement hyper-calls? That is of course, if Xen treats DOM-0 differently (basic mm stand-point). -Kaushik -----Original Message----- From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] Sent: Sunday, February 11, 2007 2:09 AM To: Kaushik Barde; Ian Pratt; Xen devel list Subject: Re: [Xen-devel] EPS Signature Isa_bus_to_virt() is available. Isa_virt_to_bus() isn't. Why would you need the latter? -- Keir On 11/2/07 01:33, "Kaushik Barde" <Kaushik_Barde@Phoenix.com> wrote: > > > I get following Error.. > > 496: error: `isa_virt_to_bus_is_UNSUPPORTED' undeclared (first use in this > function) > > Is it truely unsupported or I am missing proper includes.. > > I suspect later but "UNSUPPORTED" makes me uncomfortable. > > Please advise. > > -Kaushik > > > > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com on behalf of Ian Pratt > Sent: Sun 2/4/2007 6:52 PM > To: Kaushik Barde; Xen devel list > Subject: RE: [Xen-devel] EPS Signature > >> We want to access the EBDA Entry Point Signature at 40:0E for our > DOM-0 >> through a driver, >> We noticed that driver is trying to read from a pseudo physical > location >> and not the physical machine RAM location. Hence it's not getting the >> proper value. But if we have to read from the machine RAM location we > can >> use ( virt_to_bus or bus_to_virt) per dev_list comments. >> >> But this area is under the control of hypervisor. I do not know if we > can >> ioremap these pages ( those which belong to hypervisor). >> >> I am trying to see if we can be able to get to the 40:0E address. And > get >> the correct EPS signature > > Dom0 already has the bottom 1MB of physical ram mapped. You can use the > poorly named isa_bus_to_virt() > > Ian > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: EPS Signature 2007-02-11 23:39 ` Kaushik Barde @ 2007-02-12 0:58 ` Keir Fraser 2007-02-12 2:36 ` Kaushik Barde 0 siblings, 1 reply; 26+ messages in thread From: Keir Fraser @ 2007-02-12 0:58 UTC (permalink / raw) To: Kaushik Barde, Ian Pratt, Xen devel list On 11/2/07 23:39, "Kaushik Barde" <Kaushik_Barde@Phoenix.com> wrote: > gdt_table = get_cpu_gdt_table(cpu); > l_entry_ma = virt_to_bus(&(gdt_table[l_Request.entryNum])); > l_desc_64 = *( (u64 *) &l_Desc); This should be fine, assuming gdt_table is a normal kernel virtual address (e.g., returned by kmalloc()). I/O memory is a different matter in Xen, in that virt_to_bus() won't work. In fact the same restriction holds in native Linux as well (I/O memory shouldn't be virt_to_bus()ed). -- Keir ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: EPS Signature 2007-02-12 0:58 ` Keir Fraser @ 2007-02-12 2:36 ` Kaushik Barde 2007-02-12 7:43 ` Keir Fraser 0 siblings, 1 reply; 26+ messages in thread From: Kaushik Barde @ 2007-02-12 2:36 UTC (permalink / raw) To: Keir Fraser, Ian Pratt, Xen devel list But is the usage HYPERVISOR_update_descriptor(...) appropriate? -Kaushik -----Original Message----- From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] Sent: Sunday, February 11, 2007 4:58 PM To: Kaushik Barde; Ian Pratt; Xen devel list Subject: Re: [Xen-devel] EPS Signature On 11/2/07 23:39, "Kaushik Barde" <Kaushik_Barde@Phoenix.com> wrote: > gdt_table = get_cpu_gdt_table(cpu); > l_entry_ma = virt_to_bus(&(gdt_table[l_Request.entryNum])); > l_desc_64 = *( (u64 *) &l_Desc); This should be fine, assuming gdt_table is a normal kernel virtual address (e.g., returned by kmalloc()). I/O memory is a different matter in Xen, in that virt_to_bus() won't work. In fact the same restriction holds in native Linux as well (I/O memory shouldn't be virt_to_bus()ed). -- Keir ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: EPS Signature 2007-02-12 2:36 ` Kaushik Barde @ 2007-02-12 7:43 ` Keir Fraser 0 siblings, 0 replies; 26+ messages in thread From: Keir Fraser @ 2007-02-12 7:43 UTC (permalink / raw) To: Kaushik Barde, Ian Pratt, Xen devel list It doesn't appear obviously incorrect. K. On 12/2/07 02:36, "Kaushik Barde" <Kaushik_Barde@Phoenix.com> wrote: > > > But is the usage HYPERVISOR_update_descriptor(...) appropriate? > > -Kaushik > > -----Original Message----- > From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] > Sent: Sunday, February 11, 2007 4:58 PM > To: Kaushik Barde; Ian Pratt; Xen devel list > Subject: Re: [Xen-devel] EPS Signature > > On 11/2/07 23:39, "Kaushik Barde" <Kaushik_Barde@Phoenix.com> wrote: > >> gdt_table = get_cpu_gdt_table(cpu); >> l_entry_ma = virt_to_bus(&(gdt_table[l_Request.entryNum])); >> l_desc_64 = *( (u64 *) &l_Desc); > > This should be fine, assuming gdt_table is a normal kernel virtual > address > (e.g., returned by kmalloc()). I/O memory is a different matter in Xen, > in > that virt_to_bus() won't work. In fact the same restriction holds in > native > Linux as well (I/O memory shouldn't be virt_to_bus()ed). > > -- Keir > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: EPS Signature 2007-02-05 2:29 ` EPS Signature Kaushik Barde 2007-02-05 2:52 ` Ian Pratt @ 2007-02-06 15:43 ` Andrew D. Ball 1 sibling, 0 replies; 26+ messages in thread From: Andrew D. Ball @ 2007-02-06 15:43 UTC (permalink / raw) To: Kaushik Barde; +Cc: Xen devel list A long time ago Ian Pratt helped me get the OpenIPMI driver to work when it needed to read SMBIOS data by bus address. I wonder how much has changed since then. You can at least get to the data in user space with mmap() on /dev/mem right? Peace. Andrew On Sun, 2007-02-04 at 18:29 -0800, Kaushik Barde wrote: > Hi, > > We want to access the EBDA Entry Point Signature at 40:0E for our DOM-0 through a driver, > We noticed that driver is trying to read from a pseudo physical location and not the physical machine RAM location. Hence it's not getting the proper value. But if we have to read from the machine RAM location we can use ( virt_to_bus or bus_to_virt) per dev_list comments. > > But this area is under the control of hypervisor. I do not know if we can ioremap these pages ( those which belong to hypervisor). > > I am trying to see if we can be able to get to the 40:0E address. And get the correct EPS signature > > -Kaushik > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: xensource (pci) device id's? 2007-02-02 19:03 ` Keir Fraser 2007-02-05 2:29 ` EPS Signature Kaushik Barde @ 2007-02-05 8:55 ` Gerd Hoffmann 1 sibling, 0 replies; 26+ messages in thread From: Gerd Hoffmann @ 2007-02-05 8:55 UTC (permalink / raw) To: Keir Fraser; +Cc: Xen devel list, Ian Campbell Keir Fraser wrote: > On 1/2/07 15:45, "Gerd Hoffmann" <kraxel@suse.de> wrote: > >> kbd->name = "Xen Virtual Keyboard"; >> + kbd->id.bustype = BUS_PCI; >> + kbd->id.vendor = 0x5853; /* XenSource, Inc. */ >> + kbd->id.product = 0x0002; >> ptr->name = "Xen Virtual Pointer"; >> + ptr->id.bustype = BUS_PCI; >> + ptr->id.vendor = 0x5853; /* XenSource, Inc. */ >> + ptr->id.product = 0x0003; > > Instead of faking out PCI device ids, which is kinda bogus, can you match in > the X config file based on the string(s) in {kbd,ptr}->{name,phys,uniq}? > That'd be nicer than pulling random id numbers out of the air. You can match name, phys, bustype, vendor, product and version. Thus a string in phys should work. "xenbus/" + nodename maybe? Nevertheless I think some vendor and product id would be nice, usb hid devices are usually identified using these two, so having something useful filled in makes things easier ... cheers, Gerd -- Gerd Hoffmann <kraxel@suse.de> ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: xensource (pci) device id's? 2007-02-01 14:30 ` Gerd Hoffmann 2007-02-01 15:45 ` Gerd Hoffmann @ 2007-02-01 20:02 ` Zulauf, John 2007-02-01 20:29 ` Ian Campbell 2007-02-01 23:17 ` Keir Fraser 1 sibling, 2 replies; 26+ messages in thread From: Zulauf, John @ 2007-02-01 20:02 UTC (permalink / raw) To: Xen devel list; +Cc: Gerd Hoffmann, Ian Campbell If we change all the PCI vendor ID's for the virtualized devices, how will the OS find the correct driver in standard HVM systems? John Zulauf * comments do not necessarily reflect the opinion of my employer * -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Gerd Hoffmann Sent: Thursday, February 01, 2007 6:30 AM To: Ian Campbell Cc: Xen devel list Subject: Re: [Xen-devel] xensource (pci) device id's? Ian Campbell wrote: > This was the id we used as a placeholder before we got the official > assignment. > > We now have vendor 5853 officially assigned. > http://pci-ids.ucw.cz/iii/?i=5853 Ok, how device IDs are allocated? I'd like to use them to tag virtual devices ... cheers, Gerd btw: I guess usb and pci vendor ids are not the same namespace? -- Gerd Hoffmann <kraxel@suse.de> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: xensource (pci) device id's? 2007-02-01 20:02 ` Zulauf, John @ 2007-02-01 20:29 ` Ian Campbell 2007-02-01 23:22 ` Keir Fraser 2007-02-02 8:15 ` Gerd Hoffmann 2007-02-01 23:17 ` Keir Fraser 1 sibling, 2 replies; 26+ messages in thread From: Ian Campbell @ 2007-02-01 20:29 UTC (permalink / raw) To: Zulauf, John; +Cc: Gerd Hoffmann, Xen devel list On Thu, 2007-02-01 at 12:02 -0800, Zulauf, John wrote: > If we change all the PCI vendor ID's for the virtualized devices, how > will the OS find the correct driver in standard HVM systems? Gerd is proposing to change the subvendor/subdevice ID's which is different to the regular vendor/device ID. The purpose of the subvendor/subdevice ID is to allow manufacturers to take an existing PCI device chipset (with a given vendor/device ID burnt in) and incorporate it into a card of their own. They can then use their own subvendor/subdevice ID for this card and presumably have their own driver match on these IDs rather than the more generic ones to offer advanced functionality which is dependant on the board not the chipset etc. Linux at least matches primarily on the vendor/device IDs with subvendor/subdevice set to match anything so we would be OK here. From include/linux/pci.h here is the macro typically used by drivers: #define PCI_DEVICE(vend,dev) \ .vendor = (vend), .device = (dev), \ .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID I'd be interested to know if this is true of other OSs such as Windows and what matching procedure (if any) the PCI spec actually specifies. Ian. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: xensource (pci) device id's? 2007-02-01 20:29 ` Ian Campbell @ 2007-02-01 23:22 ` Keir Fraser 2007-02-02 8:15 ` Gerd Hoffmann 1 sibling, 0 replies; 26+ messages in thread From: Keir Fraser @ 2007-02-01 23:22 UTC (permalink / raw) To: Ian Campbell, Zulauf, John; +Cc: Gerd Hoffmann, Xen devel list On 1/2/07 20:29, "Ian Campbell" <Ian.Campbell@XenSource.com> wrote: > I'd be interested to know if this is true of other OSs such as Windows > and what matching procedure (if any) the PCI spec actually specifies. You can get away with a lot. Microsoft WHQL requires that the subvendor ids are non-zero (i.e, you have to define them to *something*) but the OS drivers and PCI subsystem are unlikely to care what the definition is. -- Keir ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: xensource (pci) device id's? 2007-02-01 20:29 ` Ian Campbell 2007-02-01 23:22 ` Keir Fraser @ 2007-02-02 8:15 ` Gerd Hoffmann 1 sibling, 0 replies; 26+ messages in thread From: Gerd Hoffmann @ 2007-02-02 8:15 UTC (permalink / raw) To: Ian Campbell; +Cc: Zulauf, John, Xen devel list Ian Campbell wrote: > On Thu, 2007-02-01 at 12:02 -0800, Zulauf, John wrote: >> If we change all the PCI vendor ID's for the virtualized devices, how >> will the OS find the correct driver in standard HVM systems? > > Gerd is proposing to change the subvendor/subdevice ID's which is > different to the regular vendor/device ID. > > The purpose of the subvendor/subdevice ID is to allow manufacturers to > take an existing PCI device chipset (with a given vendor/device ID burnt > in) and incorporate it into a card of their own. They can then use their > own subvendor/subdevice ID for this card and presumably have their own > driver match on these IDs rather than the more generic ones to offer > advanced functionality which is dependant on the board not the chipset > etc. > > Linux at least matches primarily on the vendor/device IDs with > subvendor/subdevice set to match anything so we would be OK here. No. It fully depends on the driver. > From > include/linux/pci.h here is the macro typically used by drivers: > > #define PCI_DEVICE(vend,dev) \ > .vendor = (vend), .device = (dev), \ > .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID You *can* specify subvendor IDs too. If you do so linux will match only devices where both normal and subsystem ID match. And I think they are even preferred over more generic (without subsystem) matches, at least when it comes to module loading. Adding a subsystem ID makes it possible for the guest OS to use a different driver for the virtual device. Without special hooks needed, the normal device probing works just fine for that purpose then. If no special driver is available the generic chipset driver will be used. cheers, Gerd -- Gerd Hoffmann <kraxel@suse.de> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: xensource (pci) device id's? 2007-02-01 20:02 ` Zulauf, John 2007-02-01 20:29 ` Ian Campbell @ 2007-02-01 23:17 ` Keir Fraser 1 sibling, 0 replies; 26+ messages in thread From: Keir Fraser @ 2007-02-01 23:17 UTC (permalink / raw) To: Zulauf, John, Xen devel list; +Cc: Gerd Hoffmann, Ian Campbell Gerd is suggesting rewriting the subvendor id, which is typically not used as part of the driver match. In fact subvendor info is a bit ad hoc really (although it isn't supposed to be). -- Keir On 1/2/07 20:02, "Zulauf, John" <john.zulauf@intel.com> wrote: > > If we change all the PCI vendor ID's for the virtualized devices, how > will the OS find the correct driver in standard HVM systems? > > John Zulauf > > * comments do not necessarily reflect the opinion of my employer * > > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Gerd > Hoffmann > Sent: Thursday, February 01, 2007 6:30 AM > To: Ian Campbell > Cc: Xen devel list > Subject: Re: [Xen-devel] xensource (pci) device id's? > > Ian Campbell wrote: >> This was the id we used as a placeholder before we got the official >> assignment. >> >> We now have vendor 5853 officially assigned. >> http://pci-ids.ucw.cz/iii/?i=5853 > > Ok, how device IDs are allocated? I'd like to use them to tag virtual > devices ... > > cheers, > Gerd > > btw: I guess usb and pci vendor ids are not the same namespace? ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2007-02-12 7:43 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-02-01 13:53 xensource (pci) device id's? Gerd Hoffmann 2007-02-01 13:58 ` Ian Campbell 2007-02-01 14:30 ` Gerd Hoffmann 2007-02-01 15:45 ` Gerd Hoffmann 2007-02-02 9:26 ` Ian Campbell 2007-02-02 9:47 ` Gerd Hoffmann 2007-02-02 18:25 ` Keir Fraser 2007-02-05 8:48 ` Gerd Hoffmann 2007-02-05 14:20 ` Gerd Hoffmann 2007-02-02 19:03 ` Keir Fraser 2007-02-05 2:29 ` EPS Signature Kaushik Barde 2007-02-05 2:52 ` Ian Pratt 2007-02-10 7:52 ` GDT access from DOM-0 driver Kaushik Barde 2007-02-11 1:33 ` EPS Signature Kaushik Barde 2007-02-11 10:09 ` Keir Fraser 2007-02-11 23:39 ` Kaushik Barde 2007-02-12 0:58 ` Keir Fraser 2007-02-12 2:36 ` Kaushik Barde 2007-02-12 7:43 ` Keir Fraser 2007-02-06 15:43 ` Andrew D. Ball 2007-02-05 8:55 ` xensource (pci) device id's? Gerd Hoffmann 2007-02-01 20:02 ` Zulauf, John 2007-02-01 20:29 ` Ian Campbell 2007-02-01 23:22 ` Keir Fraser 2007-02-02 8:15 ` Gerd Hoffmann 2007-02-01 23:17 ` Keir Fraser
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.