xensource (pci) device id's?

xensource (pci) device id's?

[Gerd Hoffmann]

[-- 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

Re: xensource (pci) device id's?

[Ian Campbell]

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

Re: xensource (pci) device id's?

[Gerd Hoffmann]

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>

Re: xensource (pci) device id's?

[Gerd Hoffmann]

[-- 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

Re: xensource (pci) device id's?

[Ian Campbell]

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.

Re: xensource (pci) device id's?

[Gerd Hoffmann]

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>

Re: xensource (pci) device id's?

[Keir Fraser]

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

Re: xensource (pci) device id's?

[Gerd Hoffmann]

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>

Re: xensource (pci) device id's?

[Gerd Hoffmann]

[-- 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

Re: xensource (pci) device id's?

[Keir Fraser]

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

EPS Signature

[Kaushik Barde]

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

RE: EPS Signature

[Ian Pratt]

> 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

GDT access from DOM-0 driver

[Kaushik Barde]

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

RE: EPS Signature

[Kaushik Barde]

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

Re: EPS Signature

[Keir Fraser]

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

RE: EPS Signature

[Kaushik Barde]

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

Re: EPS Signature

[Keir Fraser]

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

RE: EPS Signature

[Kaushik Barde]

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

Re: EPS Signature

[Keir Fraser]

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
> 
> 

Re: EPS Signature

[Andrew D. Ball]

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

Re: xensource (pci) device id's?

[Gerd Hoffmann]

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>

RE: xensource (pci) device id's?

[Zulauf, John]

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

RE: xensource (pci) device id's?

[Ian Campbell]

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.

Re: xensource (pci) device id's?

[Keir Fraser]

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

Re: xensource (pci) device id's?

[Gerd Hoffmann]

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>

Re: xensource (pci) device id's?

[Keir Fraser]

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?