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>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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=5853Ok, 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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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=5853Ok, 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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?_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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_IDYou *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> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
> We want to access the EBDA Entry Point Signature at 40:0E for ourDOM-0> through a driver, > We noticed that driver is trying to read from a pseudo physicallocation> 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 wecan> 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 wecan> 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. Andget> the correct EPS signatureDom0 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
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> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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/0x0001Updated patch attached. cheers, Gerd -- Gerd Hoffmann <kraxel@suse.de> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 ourDOM-0> through a driver, > We noticed that driver is trying to read from a pseudo physicallocation> 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 wecan> 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 wecan> 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. Andget> the correct EPS signatureDom0 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
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 ourDOM-0> through a driver, > We noticed that driver is trying to read from a pseudo physicallocation> 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 wecan> 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 wecan> 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. Andget> the correct EPS signatureDom0 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
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel