xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* (no subject)
@ 2016-03-17 12:20 Safa Hamza
  2016-03-18 11:34 ` Safa Hamza
  0 siblings, 1 reply; 147+ messages in thread
From: Safa Hamza @ 2016-03-17 12:20 UTC (permalink / raw)
  To: Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 358 bytes --]

i'm trying to run xen on omap5 and installing some guests ..  it seems it
works and a xen boot dom0 as shown the screen shot
but with this arago project i can't download any package ..all commands
such as apt-get ,update ... are not found
i tried to have another file system but its not working ..
can you help me .. with which file system can i work
thanks

[-- Attachment #1.2: Type: text/html, Size: 437 bytes --]

[-- Attachment #2: dom0-boot.PNG --]
[-- Type: image/png, Size: 39281 bytes --]

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2016-03-17 12:20 (no subject) Safa Hamza
@ 2016-03-18 11:34 ` Safa Hamza
  0 siblings, 0 replies; 147+ messages in thread
From: Safa Hamza @ 2016-03-18 11:34 UTC (permalink / raw)
  To: Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 470 bytes --]

i solve the problem

On Thu, Mar 17, 2016 at 1:20 PM, Safa Hamza <safahamza1@gmail.com> wrote:

> i'm trying to run xen on omap5 and installing some guests ..  it seems it
> works and a xen boot dom0 as shown the screen shot
> but with this arago project i can't download any package ..all commands
> such as apt-get ,update ... are not found
> i tried to have another file system but its not working ..
> can you help me .. with which file system can i work
> thanks
>

[-- Attachment #1.2: Type: text/html, Size: 830 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2018-11-19 17:26 Razvan Cojocaru
@ 2018-11-19 17:34 ` Razvan Cojocaru
  0 siblings, 0 replies; 147+ messages in thread
From: Razvan Cojocaru @ 2018-11-19 17:34 UTC (permalink / raw)
  To: xen-devel

Apologies, the subject should have been, of course, "[PATCH V7 0/5] Fix
VGA logdirty related display freezes with altp2m", which I did paste in,
but ommited to uncomment.


Sorry,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2018-11-19 17:26 Razvan Cojocaru
  2018-11-19 17:34 ` Razvan Cojocaru
  0 siblings, 1 reply; 147+ messages in thread
From: Razvan Cojocaru @ 2018-11-19 17:26 UTC (permalink / raw)
  To: xen-devel

This series aims to prevent the display from freezing when
enabling altp2m and switching to a new view (and assorted problems
when resizing the display).

The first patch introduces p2m_{init,free}_logdirty(), the second
allocates  a new logdirty rangeset for each new altp2m, and the
fourth propagates (under lock) changes to all p2ms.

Since the last version of the series, what has previously been
the first patch is already upstream, and two patches kindly
authored by George Dunlap have been appended. The patches
optimize the way rangeset changes are propagated in
change_type_range().

[PATCH V7 1/5] x86/mm: introduce p2m_{init,free}_logdirty()
[PATCH V7 2/5] x86/mm: allocate logdirty_ranges for altp2ms
[PATCH V7 3/5] x86/altp2m: fix display frozen when switching to a new view early
[PATCH V7 4/5] p2m: Always use hostp2m when clipping rangesets
[PATCH V7 5/5] p2m: change_range_type: Only invalidate mapped gfns


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2017-11-15 15:29 futurelieswithin
  0 siblings, 0 replies; 147+ messages in thread
From: futurelieswithin @ 2017-11-15 15:29 UTC (permalink / raw)
  To: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 299 bytes --]

A story perhaps i remember snapping my fingers and at mr miagi request it actually makes things appear and quantasize then a paculiar planet red and orange appeared outa nowhere it was a Pic of what the earth looked like 13.6 billion years  



Sent from my Samsung Galaxy , an AT&T LTE smartphone

[-- Attachment #1.2: Type: text/html, Size: 577 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2017-08-25  5:16 Chao Gao
  0 siblings, 0 replies; 147+ messages in thread
From: Chao Gao @ 2017-08-25  5:16 UTC (permalink / raw)
  To: xen-devel
  Cc: Kevin Tian, Stefano Stabellini, Wei Liu, George Dunlap,
	Ian Jackson, Tim Deegan, Jan Beulich, Andrew Cooper, Chao Gao,
	Crawford Eric R, Roger Pau Monné

From 3aa2541108f28cfdf0f3bf47ddae9b762b73b532 Mon Sep 17 00:00:00 2001
From: Chao Gao <chao.gao@intel.com>
Date: Mon, 7 Aug 2017 04:50:04 +0800
Subject: [PATCH v9] VT-d: use correct BDF for VF to search VT-d unit

When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' are under
the scope of the same VT-d unit as the 'Physical Function'. A 'Physical
Function' can be a 'Traditional Function' or an ARI 'Extended Function'.
And furthermore, 'Extended Functions' on an endpoint are under the scope of
the same VT-d unit as the 'Traditional Functions' on the endpoint. To search
VT-d unit, the BDF of PF or the BDF of a traditional function may be used. And
it depends on whether the PF is an extended function or not.

Current code uses PCI_SLOT() to recognize an ARI 'Extended Funcion'. But it
is conceptually wrong w/o checking whether PF is an extended function and
would lead to match VFs of a RC endpoint to a wrong VT-d unit.

This patch uses VF's 'is_extfn' field to indicate whether the PF of this VF is
an extended function. The field helps to use correct BDF to search VT-d unit.

Reported-by: Crawford, Eric R <Eric.R.Crawford@intel.com>
Signed-off-by: Chao Gao <chao.gao@intel.com>
---
v9:
 - check 'is_virtfn' first in pci_add_device() to avoid potential error if
 linux side sets VF's 'is_extfn'
 - comments changes to make it clear that we use VF's 'is_extfn' intentionally
 otherwise the patch seems like a workaround.

v8:
 - use "conceptually wrong", instead of "a corner case" in commit message
 - check 'is_virtfn' first in acpi_find_matched_drhd_unit()

v7:
 - Drop Eric's tested-by
 - Change commit message to be clearer
 - Re-use VF's is_extfn field
 - access PF's is_extfn field in locked area

---
 xen/drivers/passthrough/pci.c      | 14 ++++++++++----
 xen/drivers/passthrough/vtd/dmar.c | 12 ++++++------
 xen/include/xen/pci.h              |  1 +
 3 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 27bdb71..0e27e29 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -599,21 +599,24 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
     unsigned int slot = PCI_SLOT(devfn), func = PCI_FUNC(devfn);
     const char *pdev_type;
     int ret;
+    bool pf_is_extfn = false;
 
-    if (!info)
+    if ( !info )
         pdev_type = "device";
-    else if (info->is_extfn)
-        pdev_type = "extended function";
-    else if (info->is_virtfn)
+    else if ( info->is_virtfn )
     {
         pcidevs_lock();
         pdev = pci_get_pdev(seg, info->physfn.bus, info->physfn.devfn);
+        if ( pdev )
+            pf_is_extfn = pdev->info.is_extfn;
         pcidevs_unlock();
         if ( !pdev )
             pci_add_device(seg, info->physfn.bus, info->physfn.devfn,
                            NULL, node);
         pdev_type = "virtual function";
     }
+    else if ( info->is_extfn )
+        pdev_type = "extended function";
     else
     {
         info = NULL;
@@ -707,6 +710,9 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
                    seg, bus, slot, func, ctrl);
     }
 
+    /* VF's 'is_extfn' is used to indicate whether PF is an extended function */
+    if ( pdev->info.is_virtfn )
+        pdev->info.is_extfn = pf_is_extfn;
     check_pdev(pdev);
 
     ret = 0;
diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c
index 82040dd..75c9c92 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -211,15 +211,15 @@ struct acpi_drhd_unit *acpi_find_matched_drhd_unit(const struct pci_dev *pdev)
     if ( pdev == NULL )
         return NULL;
 
-    if ( pdev->info.is_extfn )
+    if ( pdev->info.is_virtfn )
     {
-        bus = pdev->bus;
-        devfn = 0;
+        bus = pdev->info.physfn.bus;
+        devfn = pdev->info.is_extfn ? 0 : pdev->info.physfn.devfn;
     }
-    else if ( pdev->info.is_virtfn )
+    else if ( pdev->info.is_extfn )
     {
-        bus = pdev->info.physfn.bus;
-        devfn = PCI_SLOT(pdev->info.physfn.devfn) ? 0 : pdev->info.physfn.devfn;
+        bus = pdev->bus;
+        devfn = 0;
     }
     else
     {
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 59b6e8a..4dd42ac 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -39,6 +39,7 @@
 #define PCI_SBDF3(s,b,df) ((((s) & 0xffff) << 16) | PCI_BDF2(b, df))
 
 struct pci_dev_info {
+    /* VF's 'is_extfn' is used to show whether its PF an extended function */
     bool_t is_extfn;
     bool_t is_virtfn;
     struct {
-- 
1.8.3.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2017-07-28  5:27 Manonmani
  0 siblings, 0 replies; 147+ messages in thread
From: Manonmani @ 2017-07-28  5:27 UTC (permalink / raw)
  To: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 580 bytes --]

Is it possible to use VFB for paravirtualised Guest? How to display
Domain-U in physical monitor? I have added vfb in my Guest configuration
and it returns the following error :

Parsing config from
/etc/xen/arch_domU_1.cfg
libxl: error: libxl_dm.c:1233:libxl__spawn_local_dm: device model
/usr/lib/xen/b
in/qemu-dm is not executable: No such file or
directory
libxl: error: libxl_dm.c:1371:device_model_spawn_outcome: (null): spawn
failed (
rc=-3)

libxl: error: libxl_create.c:1186:domcreate_devmodel_started: device model
did n
ot start: -3

Thanks in advance.

Regards,
Joker

[-- Attachment #1.2: Type: text/html, Size: 916 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2017-07-26 19:04 Raviprasad Gurikar
  0 siblings, 0 replies; 147+ messages in thread
From: Raviprasad Gurikar @ 2017-07-26 19:04 UTC (permalink / raw)
  To: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 512 bytes --]


Hi .

I am ravi student from Indian I working on the xen arm development . I have plan to run the xen arm on fastmodel. But I am getting problem in the rootfilesystem creation and debootstrap  for this link https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/RootFilesystem. I am not able to entry the chroot ; if give the commands like this 

Sudo chroot /mnt;
Getting error like – error ; no such file or directory /bin/bash.

Please help me . 
Sent from Mail for Windows 10


[-- Attachment #1.2: Type: text/html, Size: 2158 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2017-04-04 11:29 Seraphime Kirkovski
  0 siblings, 0 replies; 147+ messages in thread
From: Seraphime Kirkovski @ 2017-04-04 11:29 UTC (permalink / raw)
  Cc: Wei Liu, IanJackson, xen-devel

<ian.jackson@eu.citrix.com>
Bcc: 
Subject: Re: [PATCH] libxc: fix segfault on uninitialized xch->fmem
Reply-To: 
In-Reply-To: <20170404101507.lohlu5rbx4jq5md2@citrix.com>

On Tue, Apr 04, 2017 at 11:15:07AM +0100, Wei Liu wrote:
> Since there are a few handles in xch, it would be better to initialise
> them all at once by doing:
> 
>     struct xc_interface_core xch_buf = { 0 }
> 
> >      xch->flags = open_flags;
> >      xch->dombuild_logger_file = 0;
> >      xc_clear_last_error(xch);
> > -- 
> > 2.11.0
> > 

Hi, thanks for the reply.

Literally 10 minutes after sending this, I thought that a bzero would
be better. Will send a V2 shortly.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2017-02-27 18:12 Dmitry Rockosov
@ 2017-03-06 10:48 ` George Dunlap
  0 siblings, 0 replies; 147+ messages in thread
From: George Dunlap @ 2017-03-06 10:48 UTC (permalink / raw)
  To: Dmitry Rockosov; +Cc: Tian, Kevin, Xen-devel

On Mon, Feb 27, 2017 at 6:12 PM, Dmitry Rockosov <rockosov@gmail.com> wrote:
> Hi guys,
>
> Do you know when *recognized* Virtual Interrupt on VM-Entry will be
> delivered if Virtual-Interrupt Delivery is enabled and interrupt delivery is
> blocking by STI?
>
> Previously, VMM used Interrupt-Window, but as I see in XEN code,
> Interrupt-Window is not used when Virtual Interrupt Delivery is enabled.
>
> Does it mean, we will get Virtual Interrupt on the next VM-entry?

CC'ing the VMX maintainer.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2017-02-27 18:12 Dmitry Rockosov
  2017-03-06 10:48 ` George Dunlap
  0 siblings, 1 reply; 147+ messages in thread
From: Dmitry Rockosov @ 2017-02-27 18:12 UTC (permalink / raw)
  To: Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 421 bytes --]

Hi guys,

Do you know when *recognized* Virtual Interrupt on VM-Entry will be
delivered if Virtual-Interrupt Delivery is enabled and interrupt delivery
is blocking by STI?

Previously, VMM used Interrupt-Window, but as I see in XEN code,
Interrupt-Window is not used when Virtual Interrupt Delivery is enabled.

Does it mean, we will get Virtual Interrupt on the next VM-entry?

Thank you!

Best Regards,
Rockosov Dmitry

[-- Attachment #1.2: Type: text/html, Size: 676 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2017-02-17 17:17 dhara buch
@ 2017-02-20 17:56 ` Dario Faggioli
  0 siblings, 0 replies; 147+ messages in thread
From: Dario Faggioli @ 2017-02-20 17:56 UTC (permalink / raw)
  To: dhara buch, xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 1927 bytes --]

On Fri, 2017-02-17 at 22:47 +0530, dhara buch wrote:
> Hello,
> 
> I have installed Ubuntu 15.10 in which have installed Xen with
> source.
> 
> Booting is done with Xen as well as commands like xl infor, xl list
> are also working fine.
> 
> For creating Virtual Machine, I have installed Virtual Machine
> Manager, but when I try to run it, it gives error as follows:
> 
> Unable to connect to libvirt.
> 
> internal error: libxenlight state driver is not active
> 
This means you have not installed the libvirt, libxl driver. Or that
you have, but trying to load it is failing.

There should be something in the libvirt logs.

However, since you said you've installed Xen from sources, you probably
need to build and install libvirt from sources too.

In fact, I don't know how exactly it is in Ubuntu, but in all the
distro I've tried, trying to install libvirt-daemon-driver-libxl (or
whatever the package is called), would fail, unless Xen hypervisor,
toolstack and libraries are also installed with the distro package
mamanger.

If that is not the case, install would either fail, or would bring in
those Xen packages, which would then either overrun or conflict with
your source installation.

> Verify that:
>  - A Xen host kernel was booted
>  - The Xen service has been started
> 
> I tried by installing libvirt as
> apt-get install libvirt-bin
> 
> but, still the same problem is found. Libvirtd service is also not
> getting started.
> 
> Where am I lacking?
> 
As said above. In all the distro I tried, when I build Xen from source,
I've always also had to build libvirt from sources.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2017-02-17 17:17 dhara buch
  2017-02-20 17:56 ` Dario Faggioli
  0 siblings, 1 reply; 147+ messages in thread
From: dhara buch @ 2017-02-17 17:17 UTC (permalink / raw)
  To: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 660 bytes --]

Hello,

I have installed Ubuntu 15.10 in which have installed Xen with source.

Booting is done with Xen as well as commands like xl infor, xl list are
also working fine.

For creating Virtual Machine, I have installed Virtual Machine Manager, but
when I try to run it, it gives error as follows:







*Unable to connect to libvirt.internal error: libxenlight state driver is
not activeVerify that: - A Xen host kernel was booted - The Xen service has
been started*

I tried by installing libvirt as
apt-get install libvirt-bin

but, still the same problem is found. Libvirtd service is also not getting
started.

Where am I lacking?

Thank you,

Dhara Buch

[-- Attachment #1.2: Type: text/html, Size: 823 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2017-02-17 10:47 Norbert Manthey
@ 2017-02-17 11:35 ` Andrew Cooper
  0 siblings, 0 replies; 147+ messages in thread
From: Andrew Cooper @ 2017-02-17 11:35 UTC (permalink / raw)
  To: Norbert Manthey, xen-devel

On 17/02/17 10:47, Norbert Manthey wrote:
> Dear Xen developers,
>
> I would like to bring the attached two patches online, as they fix minor defects
> in the upstream code base.

Thankyou for the fixes; they are both good.

For future fixes, please can you CC the appropriate maintainers
(https://wiki.xen.org/wiki/Submitting_Xen_Project_Patches#Cc_the_maintainer_of_the_code_you_are_modifying),
and you probably want to join the xen-devel mailing list to avoid
getting held in moderation.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2017-02-17 10:47 Norbert Manthey
  2017-02-17 11:35 ` Andrew Cooper
  0 siblings, 1 reply; 147+ messages in thread
From: Norbert Manthey @ 2017-02-17 10:47 UTC (permalink / raw)
  To: xen-devel


Dear Xen developers,

I would like to bring the attached two patches online, as they fix minor defects
in the upstream code base.

Best,
Norbert

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
       [not found]   ` <1484304406-10820-1-git-send-email-nicolas.dichtel@6wind.com>
  2017-01-13 15:36     ` David Howells
@ 2017-01-13 15:43     ` David Howells
  1 sibling, 0 replies; 147+ messages in thread
From: David Howells @ 2017-01-13 15:43 UTC (permalink / raw)
  To: Nicolas Dichtel
  Cc: linux-mips, linux-m68k, linux-ia64, linux-doc, alsa-devel,
	dri-devel, dhowells, linux-mtd, sparclinux, linux-arch,
	linux-s390, linux-am33-list, linux-c6x-dev, linux-rdma,
	linux-hexagon, linux-sh, linux, coreteam, fcoe-devel, xen-devel,
	linux-snps-arc, linux-media, uclinux-h8-devel, linux-xtensa,
	arnd, linux-kbuild, adi-buildroot-devel, linux-raid, openrisc,
	linux-fbdev, linux-metag

> -header-y += msr-index.h

I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at
least four years - and as such it's part of the UAPI.  I don't think you can
remove it unless you can guarantee there are no userspace users.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
       [not found]   ` <1484304406-10820-1-git-send-email-nicolas.dichtel@6wind.com>
@ 2017-01-13 15:36     ` David Howells
  2017-01-13 15:43     ` David Howells
  1 sibling, 0 replies; 147+ messages in thread
From: David Howells @ 2017-01-13 15:36 UTC (permalink / raw)
  To: Nicolas Dichtel
  Cc: linux-mips, linux-m68k, linux-ia64, linux-doc, alsa-devel,
	dri-devel, dhowells, linux-mtd, sparclinux, linux-arch,
	linux-s390, linux-am33-list, linux-c6x-dev, linux-rdma,
	linux-hexagon, linux-sh, linux, coreteam, fcoe-devel, xen-devel,
	linux-snps-arc, linux-media, uclinux-h8-devel, linux-xtensa,
	arnd, linux-kbuild, adi-buildroot-devel, linux-raid, openrisc,
	linux-fbdev, linux-metag

Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:

> This header file is exported, thus move it to uapi.

Exported how?

> +#ifdef __INT32_TYPE__
> +#undef __INT32_TYPE__
> +#define __INT32_TYPE__		int
> +#endif
> +
> +#ifdef __UINT32_TYPE__
> +#undef __UINT32_TYPE__
> +#define __UINT32_TYPE__	unsigned int
> +#endif
> +
> +#ifdef __UINTPTR_TYPE__
> +#undef __UINTPTR_TYPE__
> +#define __UINTPTR_TYPE__	unsigned long
> +#endif

These weren't defined by the kernel before, so why do we need to define them
now?

Will defining __UINTPTR_TYPE__ cause problems in compiling libboost by
changing the signature on C++ functions that use uintptr_t?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2016-12-29  0:56 Ronald Rojas
@ 2017-01-04  1:10 ` Stefano Stabellini
  0 siblings, 0 replies; 147+ messages in thread
From: Stefano Stabellini @ 2017-01-04  1:10 UTC (permalink / raw)
  To: Ronald Rojas
  Cc: Ian Jackson, George Dunlap, Wei Liu, George Dunlap, xen-devel

On Wed, 28 Dec 2016, Ronald Rojas wrote:
> The first 57 commits are merged from previous work done by 
> George Dunlap at (https://github.com/gwd/schedbench) and 
> implement manipulating Cpu pool. The last 2 commits merge 
> his work onto the Xen tree and implement finding system 
> information and throwing errors.

You need to add your Signed-off-by to all patches you touched for
copyright reasons. In fact, usually people add their Signed-off-by to
all patches. 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2016-12-29  0:56 Ronald Rojas
  2017-01-04  1:10 ` Stefano Stabellini
  0 siblings, 1 reply; 147+ messages in thread
From: Ronald Rojas @ 2016-12-29  0:56 UTC (permalink / raw)
  Cc: Wei Liu, George Dunlap, Ian Jackson, George Dunlap, xen-devel

The first 57 commits are merged from previous work done by 
George Dunlap at (https://github.com/gwd/schedbench) and 
implement manipulating Cpu pool. The last 2 commits merge 
his work onto the Xen tree and implement finding system 
information and throwing errors.

CC: xen-devel <xen-devel@lists.xen.org>
CC: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: George Dunlap <george.dunlap@citrix.com>
CC: George Dunlap <dunlapg@umich.edu>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2016-11-28 17:18 Ronald Rojas
  0 siblings, 0 replies; 147+ messages in thread
From: Ronald Rojas @ 2016-11-28 17:18 UTC (permalink / raw)
  To: xen-devel, ian.jackson, wei.liu2, george.dunlap, dunlapg

Create a Makefile for the golang xenlight project, which will
allow users to access libxl functionality in Golang. Makefile 
rules were also added to tools/Makefile for the project to be 
built and installed. A template Golang file was also created 
for the project to be properly built. 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2016-07-07 12:48   ` George Dunlap
  2016-07-07 15:42     ` Dario Faggioli
@ 2016-10-31 10:33     ` Ian Jackson
  1 sibling, 0 replies; 147+ messages in thread
From: Ian Jackson @ 2016-10-31 10:33 UTC (permalink / raw)
  To: George Dunlap; +Cc: xen-devel, Dario Faggioli, Wei Liu, Anshul Makkar

George Dunlap writes ("Re:"):
> On 07/07/16 12:03, Dario Faggioli wrote:
> > So, you're saying I should change both Xen, xentrace_format and
> > xenalyze.c all at once, in the same patch, right?
...
> I think it often does make sense to check things out by component.  And
> of course before xenalyze was in tree, it doesn't matter when the change
> was done.  I suppose I've always been prejudiced against
> xentrace_format, which is why I'd never thought about regressions in it
> (although I probably should have).
> 
> But now that xenalyze is in-tree, I think we want to avoid situations
> where the in-tree xenalyze is broken, even just for one changeset, if we
> can avoid it.

This kind of situation is not that uncommon.  For any part of our
system where we don't offer a stable API, or at least one-way
intercompatibility, it is necessary to make incompatible changes both
in the producer and in all consumers.

(Sometimes this can mean a patch to xen.git needs to be combined with
a QEMU_TAG update for qemu-trad, too; in theory trying to decouple the
Xen API for qemu upstream.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2016-07-16 11:51 姚 忠将
  0 siblings, 0 replies; 147+ messages in thread
From: 姚 忠将 @ 2016-07-16 11:51 UTC (permalink / raw)
  To: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 785 bytes --]

   Recently , I made a test to compare the performance of I/O between xen project and xenserver. I found the performance of xenserver is much better than that of xen project .

I want to find the reason why xenserver is better so I search through google.com. On the website www.xenproject.org<http://www.xenproject.org> , I found url http://wiki.xenproject.org/wiki/Tuning_Xen_for_Performance and http://wiki.xenproject.org/wiki/Network_Throughput_and_Performance_Guide .
I set these parameters as the url given. But , it looks doesn’t work. The performance got no obvious improvement.

So , I send this mail to get some advise . will you help me ? if so , I’ll  be much appreciate.


发送自 Windows 10 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>应用


[-- Attachment #1.2: Type: text/html, Size: 3309 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2016-07-07 12:48   ` George Dunlap
@ 2016-07-07 15:42     ` Dario Faggioli
  2016-10-31 10:33     ` Ian Jackson
  1 sibling, 0 replies; 147+ messages in thread
From: Dario Faggioli @ 2016-07-07 15:42 UTC (permalink / raw)
  To: George Dunlap; +Cc: xen-devel, Anshul Makkar, Wei Liu, Ian Jackson


[-- Attachment #1.1: Type: text/plain, Size: 909 bytes --]

On Thu, 2016-07-07 at 13:48 +0100, George Dunlap wrote:
> On 07/07/16 12:03, Dario Faggioli wrote:
> > On Thu, 2016-07-07 at 10:36 +0100, George Dunlap wrote:
> > > Could you re-send this with the trace change moved from the
> > > previous
> > > patch to this patch?
> > > 
> > So, you're saying I should change both Xen, xentrace_format and
> > xenalyze.c all at once, in the same patch, right?
> > 
> But now that xenalyze is in-tree, I think we want to avoid situations
> where the in-tree xenalyze is broken, even just for one changeset, if
> we
> can avoid it.
> 
Ok, this makes sense. Will do.

Thanks and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2016-07-07 11:03 ` Dario Faggioli
@ 2016-07-07 12:48   ` George Dunlap
  2016-07-07 15:42     ` Dario Faggioli
  2016-10-31 10:33     ` Ian Jackson
  0 siblings, 2 replies; 147+ messages in thread
From: George Dunlap @ 2016-07-07 12:48 UTC (permalink / raw)
  To: Dario Faggioli; +Cc: xen-devel, Anshul Makkar, Wei Liu, Ian Jackson

On 07/07/16 12:03, Dario Faggioli wrote:
> On Thu, 2016-07-07 at 10:36 +0100, George Dunlap wrote:
>> On Sat, Jun 18, 2016 at 12:12 AM, Dario Faggioli
>> <dario.faggioli@citrix.com> wrote:
>>>
>>> in both xenalyze and formats (for xentrace_format).
>>>
>>> In particular, in xenalyze, now that we have the precision
>>> of the fixed point load values in the tracepoint, show both
>>> the raw value and the (easier to interpreet) percentage.
>>>
>>> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>> The change looks good in itself; but it makes me realize that
>> technically by changing the trace format, the previous patch
>> introduced a regression which is fixed here.  There's a part of me
>> that's tempted to overlook it because it's minor, but on balance I
>> think we should try to be diligent with this sort of thing.
>>
> Sure!
> 
>> Could you re-send this with the trace change moved from the previous
>> patch to this patch?
>>
> So, you're saying I should change both Xen, xentrace_format and
> xenalyze.c all at once, in the same patch, right?
> 
> I'm asking just to double check, as, although I see your point,
> separating things by component seemed a good thing to do to me, even at
> the price you describe, and I've done it before. :-)
> 
> As said, I'm fine doing that, I just want to be sure this is what you
> are asking.

I think it often does make sense to check things out by component.  And
of course before xenalyze was in tree, it doesn't matter when the change
was done.  I suppose I've always been prejudiced against
xentrace_format, which is why I'd never thought about regressions in it
(although I probably should have).

But now that xenalyze is in-tree, I think we want to avoid situations
where the in-tree xenalyze is broken, even just for one changeset, if we
can avoid it.

Thanks,
 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2016-07-07  9:36 George Dunlap
@ 2016-07-07 11:03 ` Dario Faggioli
  2016-07-07 12:48   ` George Dunlap
  0 siblings, 1 reply; 147+ messages in thread
From: Dario Faggioli @ 2016-07-07 11:03 UTC (permalink / raw)
  To: George Dunlap; +Cc: xen-devel, Anshul Makkar, Wei Liu, Ian Jackson


[-- Attachment #1.1: Type: text/plain, Size: 1801 bytes --]

On Thu, 2016-07-07 at 10:36 +0100, George Dunlap wrote:
> On Sat, Jun 18, 2016 at 12:12 AM, Dario Faggioli
> <dario.faggioli@citrix.com> wrote:
> > 
> > in both xenalyze and formats (for xentrace_format).
> > 
> > In particular, in xenalyze, now that we have the precision
> > of the fixed point load values in the tracepoint, show both
> > the raw value and the (easier to interpreet) percentage.
> > 
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> The change looks good in itself; but it makes me realize that
> technically by changing the trace format, the previous patch
> introduced a regression which is fixed here.  There's a part of me
> that's tempted to overlook it because it's minor, but on balance I
> think we should try to be diligent with this sort of thing.
> 
Sure!

> Could you re-send this with the trace change moved from the previous
> patch to this patch?
> 
So, you're saying I should change both Xen, xentrace_format and
xenalyze.c all at once, in the same patch, right?

I'm asking just to double check, as, although I see your point,
separating things by component seemed a good thing to do to me, even at
the price you describe, and I've done it before. :-)

As said, I'm fine doing that, I just want to be sure this is what you
are asking.

> If you don't make any other changes, you can retain the reviewed-by
> of
> the previous patch, and add this one to this patch:
> 
> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
>
Ok, thanks.

Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2016-07-07  9:36 George Dunlap
  2016-07-07 11:03 ` Dario Faggioli
  0 siblings, 1 reply; 147+ messages in thread
From: George Dunlap @ 2016-07-07  9:36 UTC (permalink / raw)
  To: Dario Faggioli; +Cc: xen-devel, Anshul Makkar, Wei Liu, Ian Jackson

On Sat, Jun 18, 2016 at 12:12 AM, Dario Faggioli
<dario.faggioli@citrix.com> wrote:
> in both xenalyze and formats (for xentrace_format).
>
> In particular, in xenalyze, now that we have the precision
> of the fixed point load values in the tracepoint, show both
> the raw value and the (easier to interpreet) percentage.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

The change looks good in itself; but it makes me realize that
technically by changing the trace format, the previous patch
introduced a regression which is fixed here.  There's a part of me
that's tempted to overlook it because it's minor, but on balance I
think we should try to be diligent with this sort of thing.

Could you re-send this with the trace change moved from the previous
patch to this patch?

If you don't make any other changes, you can retain the reviewed-by of
the previous patch, and add this one to this patch:

Reviewed-by: George Dunlap <george.dunlap@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2016-05-19 14:34 Roger Pau Monné
  0 siblings, 0 replies; 147+ messages in thread
From: Roger Pau Monné @ 2016-05-19 14:34 UTC (permalink / raw)
  To: xen-devel
  Cc: Stefano Stabellini, Wei Liu, George Dunlap, Andrew Cooper,
	Ian Jackson, Tim Deegan, Jan Beulich

<George.Dunlap@eu.citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, Jan 
Beulich <jbeulich@suse.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
Stefano Stabellini <sstabellini@kernel.org>, Tim Deegan <tim@xen.org>, Wei 
Liu <wei.liu2@citrix.com>
Bcc: 
Subject: Bump library names just after branching
Reply-To: 

Hello,

Currently we bump the shared library names just before the release, so ATM 
xen-unstable is still using the library names from the 4.6 release. This is 
an issue if someone wants to install both Xen 4.6 and xen-unstable in the 
same box (unless you use a different prefix/DESTDIR), because libraries from 
xen-unstable will replace the stable ones.

IMHO, it would make more sense to bump the library names just *after* we 
branch and open the tree for development again. We could even have the 
library name versions be set based on XEN_VERSION and XEN_SUBVERSION, so 
that we don't need to go around the different library makefiles bumping the 
versions manually.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2016-02-25 12:38 Ayushi Arora
  0 siblings, 0 replies; 147+ messages in thread
From: Ayushi Arora @ 2016-02-25 12:38 UTC (permalink / raw)
  To: roger.pau; +Cc: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 787 bytes --]

Hello,
As asked of in the previous mail, I tried compiling Xen from source.
I am not sure whether we can ask questions for the task given, but I have
been stuck at it from yesterday.
I followed all the steps, and wherever there was some problem, I looked up
that in wiki of Xen, but after building and installing that with ovmf
enabled in ./configure, I moved on to the network configuration, and on
rebooting after the configuration, it is showing ' ERROR: Can't find
hypervisor information in sysfs!' on xm list and brctl shows no bridge
enabled. On further checking, it showed 'ERROR: Not running inside Xen'.
I have tried finding the problem, and I will check this again but I can't
move forward until the hypervisor runs!
Not sure where to check for the error.

Thank you,

Ayushi.

[-- Attachment #1.2: Type: text/html, Size: 933 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2015-12-07 17:27 Ian Jackson
  0 siblings, 0 replies; 147+ messages in thread
From: Ian Jackson @ 2015-12-07 17:27 UTC (permalink / raw)
  To: xen-devel; +Cc: Ian Campbell

I'm intending to be able to do database schema updates.  But I don't
want to play around with such code on a live database.  So I need a
test database.

Thus, a yak: arrangements to make a test database.

As I say, I have tested this and it now does the right things in,
apparently, the right order, and seems to leave things in a good state
even when it collapses halfway or is ^C'd.

In v2 I have addressed the comments, and added a couple of new safety
catches.  For ease of review these are mostly as followup patches to
the mg-schema-test-database script, rather than folded in.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
  2015-08-05 13:27 [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id Martin Pohlack
@ 2015-08-05 14:06 ` Martin Pohlack
  0 siblings, 0 replies; 147+ messages in thread
From: Martin Pohlack @ 2015-08-05 14:06 UTC (permalink / raw)
  To: Martin Pohlack, Konrad Rzeszutek Wilk, xen-devel, msw, aliguori,
	amesserl, rick.harris, paul.voccio, steven.wilson, major.hayden,
	josh.kearney, jinsong.liu, xiantao.zxt, daniel.kiper,
	elena.ufimtseva, bob.liu, hanweidong, peter.huangpeng,
	fanhenglong, liuyingdong, john.liuqiming, jbeulich, jeremy,
	dslutz, Bjoern Doebel


Sending again without MUA-mangled patch.
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2015-01-06 17:17 Konrad Rzeszutek Wilk
  0 siblings, 0 replies; 147+ messages in thread
From: Konrad Rzeszutek Wilk @ 2015-01-06 17:17 UTC (permalink / raw)
  To: xen-devel

I am proposing to put this in the 'staging-4.5' tree but would
appreciate an English speaker to take a look and make sure it
sounds good.

Thank you.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2014-12-19  9:53 Minalkumar Patel
@ 2014-12-19  9:59 ` Ian Campbell
  0 siblings, 0 replies; 147+ messages in thread
From: Ian Campbell @ 2014-12-19  9:59 UTC (permalink / raw)
  To: Minalkumar Patel; +Cc: xen-devel

On Fri, 2014-12-19 at 17:53 +0800, Minalkumar Patel wrote:
> i got daily patch emails from xen-devel but i don't need on this email
> address so how to deactivate it please tell me

Please visit http://lists.xen.org/cgi-bin/mailman/options/xen-devel

Ian.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2014-12-19  9:53 Minalkumar Patel
  2014-12-19  9:59 ` Ian Campbell
  0 siblings, 1 reply; 147+ messages in thread
From: Minalkumar Patel @ 2014-12-19  9:53 UTC (permalink / raw)
  To: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 117 bytes --]

i got daily patch emails from xen-devel but i don't need on this email address so how to deactivate it please tell me

[-- Attachment #1.2: Type: text/html, Size: 359 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
@ 2014-02-13 23:47 Zir Blazer
  0 siblings, 0 replies; 147+ messages in thread
From: Zir Blazer @ 2014-02-13 23:47 UTC (permalink / raw)
  To: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 1027 bytes --]

>> I can't understand this as disk activity should be running on cores 0,>> 1  and 2, but never on core 3. The only thing running on core 3 should>> by my paravirtual machine and the hypervisor stub.>>>> Any idea what's going on?
Your Core i3 is a Dual Core Processor with Hyper Threading. Hyper Threading allows each Core to run two Threads simultaneously, in what is called physical Core and virtual Core (Or around those lines, but you get the idea). They share resources, and the extra Thread actually gets the free resources/execution time that weren't used by the main Thread. As Core 3 is the virtual core of the physical Core 2 (Assuming that on Linux it sees and numbers them as Physical Core 0, Logical Core 1, Physical Core 2 and Logical Core 3 and so on), you're giving that VM just a spare virtual Core with the free resources that weren't used by the physical Core. You should try with a full physical Core (Core 2 and 3), otherwise whatever runs on Core 2 WILL impact heavily what you see on Core 3. 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 1401 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2014-02-13 16:10 ` Andrew Cooper
@ 2014-02-13 17:27   ` Don Slutz
  0 siblings, 0 replies; 147+ messages in thread
From: Don Slutz @ 2014-02-13 17:27 UTC (permalink / raw)
  To: Andrew Cooper; +Cc: Simon Martin, xen-devel

On 02/13/14 11:10, Andrew Cooper wrote:
> On 13/02/14 16:01, Simon Martin wrote:
>> Hi all,
>>
>> I  am  now successfully running my little operating system inside Xen.
> Congratulations!
>
>> It  is  fully  preemptive and working a treat, but I have just noticed
>> something  I  wasn't expecting, and will really be a problem for me if
>> I can't work around it.
>>
>> My configuration is as follows:
>>
>> 1.- Hardware: Intel i3, 4GB RAM, 64GB SSD.
> Can you be more specific - this covers 4 generations of Intel CPUs.
>

I think most i3's have Intel's hyper-threading. If this is a 2 core/4 
thread chip, I would expect this kind of result. I also know that for 
the "sandy bridge" version I am using:

Intel® Xeon® E3-1260L processors (“Sandy Bridge” microarchitecture)
(2.4/2.5/3.3 GHz, 4 cores/8 threads)

How many instruction per second a thread gets does depend on the 
"idleness" of other threads (no longer just the hyperThread's parther). 
For example running my test code that does:


0x0000000000400ee0 <workerMain+432>: inc %eax
0x0000000000400ee2 <workerMain+434>: cmp $0xffffffffffffffff,%eax
0x0000000000400ee5 <workerMain+437>: jne 0x400ee0 <workerMain+432>

for almost 4GiI in this loop.

On the setup:


[root@dcs-xen-53 ~]# xl cpupool-list
Name CPUs Sched Active Domain count
Pool-0 8 credit y 9
[root@dcs-xen-53 ~]# xl vcpu-list
Name ID VCPU CPU State Time(s) CPU Affinity
Domain-0 0 0 7 r-- 1033.2 any cpu
Domain-0 0 1 3 -b- 255.9 any cpu
Domain-0 0 2 2 -b- 451.7 any cpu
Domain-0 0 3 6 -b- 231.7 any cpu
Domain-0 0 4 3 -b- 197.0 any cpu
Domain-0 0 5 0 -b- 115.1 any cpu
Domain-0 0 6 0 -b- 69.9 any cpu
Domain-0 0 7 5 -b- 214.9 any cpu
P-1-0 2 0 0 -b- 73.6 0
P-1-2 4 0 2 -b- 46.5 2
P-1-3 5 0 3 -b- 44.6 3
P-1-4 6 0 4 -b- 38.1 4
P-1-5 7 0 5 -b- 41.3 5
P-1-6 8 0 6 -b- 38.6 6
P-1-7 9 0 7 -b- 40.6 7
P-1-1 10 0 1 -b- 35.3 1

(They are HVM not PV):



xentop - 17:20:57 Xen 4.3.2-rc1
9 domains: 2 running, 7 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 33544044k total, 30265044k used, 3279000k free CPUs: 8 @ 2400MHz
NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS 
NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR VBD_RSECT VBD_WSECT SSID
Domain-0 -----r 2629 9.4 4194304 12.5 no limit n/a 8 0 0 0 0 0 0 0 0 0 0
P-1-0 --b--- 140 6.3 3145868 9.4 3146752 9.4 1 2 61 8 0 0 0 0 0 0 0
P-1-1 --b--- 101 6.1 3145868 9.4 3146752 9.4 1 2 2 0 0 0 0 0 0 0 0
P-1-2 --b--- 113 6.3 3145868 9.4 3146752 9.4 1 2 96 10 0 0 0 0 0 0 0
P-1-3 --b--- 111 6.3 3145868 9.4 3146752 9.4 1 2 100 12 0 0 0 0 0 0 0
P-1-4 --b--- 61 2.1 3145868 9.4 3146752 9.4 1 2 8 0 0 0 0 0 0 0 0
P-1-5 --b--- 90 4.5 3145868 9.4 3146752 9.4 1 2 5 0 0 0 0 0 0 0 0
P-1-6 --b--- 162 2.7 3145868 9.4 3146752 9.4 1 2 55 20 0 0 0 0 0 0 0
P-1-7 -----r 519 100.0 3145868 9.4 3146752 9.4 1 2 46 21 0 0 0 0 0 0 0


start done
thr 0: 13 Feb 14 12:20:54.201596 13 Feb 14 12:21:22.847245
+28.645649 ~= 28.65 and 4.19 GiI/Sec

And 6&7 at the same time:

xentop - 17:21:58 Xen 4.3.2-rc1
9 domains: 3 running, 6 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 33544044k total, 30265044k used, 3279000k free CPUs: 8 @ 2400MHz
NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS 
NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR VBD_RSECT VBD_WSECT SSID
Domain-0 -----r 2633 6.1 4194304 12.5 no limit n/a 8 0 0 0 0 0 0 0 0 0 0
P-1-0 --b--- 144 6.2 3145868 9.4 3146752 9.4 1 2 63 8 0 0 0 0 0 0 0
P-1-1 --b--- 105 6.2 3145868 9.4 3146752 9.4 1 2 2 0 0 0 0 0 0 0 0
P-1-2 --b--- 117 6.6 3145868 9.4 3146752 9.4 1 2 98 10 0 0 0 0 0 0 0
P-1-3 --b--- 115 6.5 3145868 9.4 3146752 9.4 1 2 103 12 0 0 0 0 0 0 0
P-1-4 --b--- 62 2.1 3145868 9.4 3146752 9.4 1 2 8 0 0 0 0 0 0 0 0
P-1-5 --b--- 93 4.5 3145868 9.4 3146752 9.4 1 2 5 0 0 0 0 0 0 0 0
P-1-6 -----r 168 100.0 3145868 9.4 3146752 9.4 1 2 58 20 0 0 0 0 0 0 0
P-1-7 -----r 550 100.0 3145868 9.4 3146752 9.4 1 2 49 22 0 0 0 0 0 0 0


start done
thr 0: 13 Feb 14 12:21:55.073588 13 Feb 14 12:22:50.905476
+55.831888 ~= 55.83 and 2.15 GiI/Sec

start done
thr 0: 13 Feb 14 12:21:54.847626 13 Feb 14 12:22:49.206362
+54.358736 ~= 54.36 and 2.21 GiI/Sec


(The DomU are all CentOS 5.3, which why Dom0 is spending so much time 
running QEMU.)

I would excpect the same from PV guests.

-Don Slutz
>> 2.- Xen: 4.4 (just pulled from repository)
>>
>> 3.- Dom0: Debian Wheezy (Kernel 3.2)
>>
>> 4.- 2 cpu pools:
>>
>> # xl cpupool-list
>> Name               CPUs   Sched     Active   Domain count
>> Pool-0               3    credit       y          2
>> pv499                1  arinc653       y          1
>>
>> 5.- 2 domU:
>>
>> # xl list
>> Name                                        ID   Mem VCPUs      State   Time(s)
>> Domain-0                                     0   984     3     r-----      39.7
>> win7x64                                      1  2046     3     -b----     143.0
>> pv499                                        3   128     1     -b----      61.2
>>
>> 6.- All VCPUs are pinned:
>>
>> # xl vcpu-list
>> Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
>> Domain-0                             0     0    0   -b-      27.5  0
>> Domain-0                             0     1    1   -b-       7.2  1
>> Domain-0                             0     2    2   r--       5.1  2
>> win7x64                              1     0    0   -b-      71.6  0
>> win7x64                              1     1    1   -b-      37.7  1
>> win7x64                              1     2    2   -b-      34.5  2
>> pv499                                3     0    3   -b-      62.1  3
>>
>> 7.- pv499 is the domU that I am testing. It has no disk or vif devices
>> (yet). I am running a little test program in pv499 and the timing I
>> see is varies depending on disk activity.
>>
>> My test program runs prints up the time taken in milliseconds for a
>> million cycles. With no disk activity I see 940 ms, with disk activity
>> I see 1200 ms.
>>
>> I can't understand this as disk activity should be running on cores 0,
>> 1  and 2, but never on core 3. The only thing running on core 3 should
>> by my paravirtual machine and the hypervisor stub.
>>
>> Any idea what's going on?
> Curious.  Lets try ruling some things out.
>
> How are you measuring time in pv499?
>
> What is your Cstates and Pstates looking like?  If you can, try
> disabling turbo?
>
> ~Andrew
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2014-02-13 16:01 Simon Martin
@ 2014-02-13 16:10 ` Andrew Cooper
  2014-02-13 17:27   ` Don Slutz
  0 siblings, 1 reply; 147+ messages in thread
From: Andrew Cooper @ 2014-02-13 16:10 UTC (permalink / raw)
  To: Simon Martin; +Cc: xen-devel

On 13/02/14 16:01, Simon Martin wrote:
> Hi all,
>
> I  am  now successfully running my little operating system inside Xen.

Congratulations!

> It  is  fully  preemptive and working a treat, but I have just noticed
> something  I  wasn't expecting, and will really be a problem for me if
> I can't work around it.
>
> My configuration is as follows:
>
> 1.- Hardware: Intel i3, 4GB RAM, 64GB SSD.

Can you be more specific - this covers 4 generations of Intel CPUs.

>
> 2.- Xen: 4.4 (just pulled from repository)
>
> 3.- Dom0: Debian Wheezy (Kernel 3.2)
>
> 4.- 2 cpu pools:
>
> # xl cpupool-list
> Name               CPUs   Sched     Active   Domain count
> Pool-0               3    credit       y          2
> pv499                1  arinc653       y          1
>
> 5.- 2 domU:
>
> # xl list
> Name                                        ID   Mem VCPUs      State   Time(s)
> Domain-0                                     0   984     3     r-----      39.7
> win7x64                                      1  2046     3     -b----     143.0
> pv499                                        3   128     1     -b----      61.2
>
> 6.- All VCPUs are pinned:
>
> # xl vcpu-list
> Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
> Domain-0                             0     0    0   -b-      27.5  0
> Domain-0                             0     1    1   -b-       7.2  1
> Domain-0                             0     2    2   r--       5.1  2
> win7x64                              1     0    0   -b-      71.6  0
> win7x64                              1     1    1   -b-      37.7  1
> win7x64                              1     2    2   -b-      34.5  2
> pv499                                3     0    3   -b-      62.1  3
>
> 7.- pv499 is the domU that I am testing. It has no disk or vif devices
> (yet). I am running a little test program in pv499 and the timing I
> see is varies depending on disk activity.
>
> My test program runs prints up the time taken in milliseconds for a
> million cycles. With no disk activity I see 940 ms, with disk activity
> I see 1200 ms.
>
> I can't understand this as disk activity should be running on cores 0,
> 1  and 2, but never on core 3. The only thing running on core 3 should
> by my paravirtual machine and the hypervisor stub.
>
> Any idea what's going on?

Curious.  Lets try ruling some things out.

How are you measuring time in pv499?

What is your Cstates and Pstates looking like?  If you can, try
disabling turbo?

~Andrew

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2014-02-13 16:01 Simon Martin
  2014-02-13 16:10 ` Andrew Cooper
  0 siblings, 1 reply; 147+ messages in thread
From: Simon Martin @ 2014-02-13 16:01 UTC (permalink / raw)
  To: xen-devel

Hi all,

I  am  now successfully running my little operating system inside Xen.
It  is  fully  preemptive and working a treat, but I have just noticed
something  I  wasn't expecting, and will really be a problem for me if
I can't work around it.

My configuration is as follows:

1.- Hardware: Intel i3, 4GB RAM, 64GB SSD.

2.- Xen: 4.4 (just pulled from repository)

3.- Dom0: Debian Wheezy (Kernel 3.2)

4.- 2 cpu pools:

# xl cpupool-list
Name               CPUs   Sched     Active   Domain count
Pool-0               3    credit       y          2
pv499                1  arinc653       y          1

5.- 2 domU:

# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   984     3     r-----      39.7
win7x64                                      1  2046     3     -b----     143.0
pv499                                        3   128     1     -b----      61.2

6.- All VCPUs are pinned:

# xl vcpu-list
Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
Domain-0                             0     0    0   -b-      27.5  0
Domain-0                             0     1    1   -b-       7.2  1
Domain-0                             0     2    2   r--       5.1  2
win7x64                              1     0    0   -b-      71.6  0
win7x64                              1     1    1   -b-      37.7  1
win7x64                              1     2    2   -b-      34.5  2
pv499                                3     0    3   -b-      62.1  3

7.- pv499 is the domU that I am testing. It has no disk or vif devices
(yet). I am running a little test program in pv499 and the timing I
see is varies depending on disk activity.

My test program runs prints up the time taken in milliseconds for a
million cycles. With no disk activity I see 940 ms, with disk activity
I see 1200 ms.

I can't understand this as disk activity should be running on cores 0,
1  and 2, but never on core 3. The only thing running on core 3 should
by my paravirtual machine and the hypervisor stub.

Any idea what's going on?


-- 
Best regards,
 Simon                          mailto:furryfuttock@gmail.com

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2013-12-18 13:35   ` Ian Campbell
@ 2014-01-07 13:55     ` Ian Campbell
  0 siblings, 0 replies; 147+ messages in thread
From: Ian Campbell @ 2014-01-07 13:55 UTC (permalink / raw)
  To: George Dunlap
  Cc: Shriram Rajagopalan, xen-devel, Ian Jackson, Stefano Stabellini

On Wed, 2013-12-18 at 13:35 +0000, Ian Campbell wrote:
> On Wed, 2013-12-18 at 11:19 +0000, George Dunlap wrote:
> > On 12/17/2013 06:35 PM, Ian Jackson wrote:
> > > This series removes the usleeps and waiting loops in libxl_dom.c and
> > > replaces them with event-callback code.
> > >
> > > Firstly, some documentation of things I had to reverse-engineer:
> > >   01/23 xen: Document XEN_DOMCTL_subscribe
> > >   02/23 xen: Document that EVTCHNOP_bind_interdomain signals
> > >   03/23 docs: Document event-channel-based suspend protocol
> > >   04/23 libxc: Document xenctrl.h event channel calls
> > > Arguably these might be 4.4 material (hence the CC to George).
> > 
> > These document pretty important aspects of behavior (fixing what might 
> > be considered documentation bugs), and obviously can have no functional 
> > impact.  I guess the only risk is that they might be wrong and mislead 
> > someone, but I think that's pretty low. :-)
> > 
> > These four:
> > 
> > Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> They look good to me too:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

And I've now applied just those 4 docs changes.

Ian.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2013-12-31 15:15 Konrad Rzeszutek Wilk
  0 siblings, 0 replies; 147+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-12-31 15:15 UTC (permalink / raw)
  To: xen-devel, linux-kernel

This had been posted way way back:  https://lkml.org/lkml/2013/1/16/696

and the discussion about it was:
 - If there are no uses of v2, then why not rip out the support for it.
   [b/c the work for it would be in the networking code and I am still
    hoping that will be done?]
 - Why not do all of this in the toolstack. Enforce that the guest
   can only use v1 ".. if the backend isn't going to make use of them."
   (Matt).
   I am not sure how one would set up the plumbing to properly figure out
   whether the backend (say a driver domain) would communicate to hypervisor
   or XenBus that it is going to use v1 only if it has not yet started.
   (It would not have started b/c the guest hasn't started yet).

   My thinking is that once the frontend and backend start using the
   esoteric features of v2 we can rip this patch out. And also implement
   the proper code for PVHVM/PVH to actually use v2 grants.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2013-12-18 11:19 ` George Dunlap
@ 2013-12-18 13:35   ` Ian Campbell
  2014-01-07 13:55     ` Ian Campbell
  0 siblings, 1 reply; 147+ messages in thread
From: Ian Campbell @ 2013-12-18 13:35 UTC (permalink / raw)
  To: George Dunlap
  Cc: Shriram Rajagopalan, xen-devel, Ian Jackson, Stefano Stabellini

On Wed, 2013-12-18 at 11:19 +0000, George Dunlap wrote:
> On 12/17/2013 06:35 PM, Ian Jackson wrote:
> > This series removes the usleeps and waiting loops in libxl_dom.c and
> > replaces them with event-callback code.
> >
> > Firstly, some documentation of things I had to reverse-engineer:
> >   01/23 xen: Document XEN_DOMCTL_subscribe
> >   02/23 xen: Document that EVTCHNOP_bind_interdomain signals
> >   03/23 docs: Document event-channel-based suspend protocol
> >   04/23 libxc: Document xenctrl.h event channel calls
> > Arguably these might be 4.4 material (hence the CC to George).
> 
> These document pretty important aspects of behavior (fixing what might 
> be considered documentation bugs), and obviously can have no functional 
> impact.  I guess the only risk is that they might be wrong and mislead 
> someone, but I think that's pretty low. :-)
> 
> These four:
> 
> Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>

They look good to me too:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2013-12-17 18:35 Ian Jackson
@ 2013-12-18 11:19 ` George Dunlap
  2013-12-18 13:35   ` Ian Campbell
  0 siblings, 1 reply; 147+ messages in thread
From: George Dunlap @ 2013-12-18 11:19 UTC (permalink / raw)
  To: Ian Jackson, xen-devel
  Cc: Shriram Rajagopalan, Ian Campbell, Stefano Stabellini

On 12/17/2013 06:35 PM, Ian Jackson wrote:
> This series removes the usleeps and waiting loops in libxl_dom.c and
> replaces them with event-callback code.
>
> Firstly, some documentation of things I had to reverse-engineer:
>   01/23 xen: Document XEN_DOMCTL_subscribe
>   02/23 xen: Document that EVTCHNOP_bind_interdomain signals
>   03/23 docs: Document event-channel-based suspend protocol
>   04/23 libxc: Document xenctrl.h event channel calls
> Arguably these might be 4.4 material (hence the CC to George).

These document pretty important aspects of behavior (fixing what might 
be considered documentation bugs), and obviously can have no functional 
impact.  I guess the only risk is that they might be wrong and mislead 
someone, but I think that's pretty low. :-)

These four:

Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2013-12-17 18:35 Ian Jackson
  2013-12-18 11:19 ` George Dunlap
  0 siblings, 1 reply; 147+ messages in thread
From: Ian Jackson @ 2013-12-17 18:35 UTC (permalink / raw)
  To: xen-devel
  Cc: Shriram Rajagopalan, George Dunlap, Ian Campbell, Stefano Stabellini

This series removes the usleeps and waiting loops in libxl_dom.c and
replaces them with event-callback code.

Firstly, some documentation of things I had to reverse-engineer:
 01/23 xen: Document XEN_DOMCTL_subscribe
 02/23 xen: Document that EVTCHNOP_bind_interdomain signals
 03/23 docs: Document event-channel-based suspend protocol
 04/23 libxc: Document xenctrl.h event channel calls
Arguably these might be 4.4 material (hence the CC to George).

We want some additional libxl event facilities:
 05/23 libxl: init: Provide a gc later in libxl_ctx_alloc
 06/23 libxl: init: libxl__poller_init and _get take gc
 07/23 libxl: events: const-correct *_inuse, *_isregistered
 08/23 libxl: events: Provide libxl__xswait_*
 09/23 libxl: events: Use libxl__xswait_* in spawn code
 10/23 libxl: events: Provide libxl__ev_evtchn*

We need to clean up some unfortunate code in libxc:
 11/23 libxc: suspend: Rename, improve xc_suspend_evtchn_init
 12/23 libxc: suspend: Fix suspend event channel locking

We do some shuffling around of the libxl suspend control flow:
 13/23 libxl: suspend: Async libxl__domain_suspend_callback
 14/23 libxl: suspend: Async domain_suspend_callback_common
 15/23 libxl: suspend: Reorg domain_suspend_callback_common
 16/23 libxl: suspend: New libxl__domain_pvcontrol_xspath
 17/23 libxl: suspend: New domain_suspend_pvcontrol_acked
No functional change in those five.  These changes are broken down
just to make the changes reviewable.

Finally, we can start to work on the event code, removing the bugs,
usleeps and loops one at a time:
 18/23 libxl: suspend: domain_suspend_callback_common xs errs
 19/23 libxl: suspend: Async xenstore pvcontrol wait
 20/23 libxl: suspend: Abolish usleeps in domain suspend wait
 21/23 libxl: suspend: Fix suspend wait corner cases
 22/23 libxl: suspend: Async evtchn wait
 23/23 libxl: suspend: Apply guest timeout in evtchn case

I have tested this with a Debian pvops kernel (xenstore pvcontrol
suspend signalling) and OpenSUSE 11 (event channel suspend
signalling).

Shriram: I haven't really touched the Remus-specific code here but
this series ought to be suitable for you to base things on, assuming
my co-maintainers like the general approach.

Thanks,
Ian.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2013-12-15  7:58 Adel Amani
  0 siblings, 0 replies; 147+ messages in thread
From: Adel Amani @ 2013-12-15  7:58 UTC (permalink / raw)
  To: Xen, Dario Faggioli


[-- Attachment #1.1: Type: text/plain, Size: 284 bytes --]

 Hello
I attach tow pic of code and error.
I try to dirty_count in function of csched_credit.c calculate... :-( But I confront to error.
now can you help me?
Thanks.

Adel Amani
M.Sc. Candidate@Computer Engineering Department, University of Isfahan
Email: A.Amani@eng.ui.ac.ir

[-- Attachment #1.2: Type: text/html, Size: 2122 bytes --]

[-- Attachment #2: pic1.png --]
[-- Type: image/png, Size: 104979 bytes --]

[-- Attachment #3: pic2.JPG --]
[-- Type: image/jpeg, Size: 11865 bytes --]

[-- Attachment #4: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2013-11-13 19:02 Jim Durand
@ 2013-11-18 14:17 ` George Dunlap
  0 siblings, 0 replies; 147+ messages in thread
From: George Dunlap @ 2013-11-18 14:17 UTC (permalink / raw)
  To: Jim Durand; +Cc: xen-devel

On Wed, Nov 13, 2013 at 7:02 PM, Jim Durand <jdurand@hrsg.ca> wrote:
> See log errors below, trying to live migrate VM's from Xen 3.1.2 -> Xen
> 4.2.3. Perhaps we cannot live migrate across major revs?

According to http://wiki.xen.org/wiki/Xen_Version_Compatibility :

"Xen supports migration (including live migration and save restore)
both within a stable release branch (e.g. between any versions in the
4.2.x branch) and from one major release to the next (e.g. from
release N to releaseN+1). This allows one to upgrade a pool of Xen
hosts by evacuating and upgrading the hosts one by one.

"Although it is not formally supported skipping a major release (e.g.
migration from release N to release N+2) may often work. "

Unfortunately that would mean 3.1 -> 3.2 -> 3.3 -> 3.4 -> 4.0 -> 4.1
-> 4.2... at that point shutting down the VM and starting it back up
again looks like the more attractive option.

 -George

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2013-11-13 19:02 Jim Durand
  2013-11-18 14:17 ` George Dunlap
  0 siblings, 1 reply; 147+ messages in thread
From: Jim Durand @ 2013-11-13 19:02 UTC (permalink / raw)
  To: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 1189 bytes --]

See log errors below, trying to live migrate VM's from Xen 3.1.2 -> Xen 4.2.3. Perhaps we cannot live migrate across major revs?

[2013-11-13 11:49:00 xend 29149] DEBUG (XendCheckpoint:89) [xc_save]: /usr/lib64/xen/bin/xc_save 4 35 0 0 5
[2013-11-13 11:49:00 xend 29149] INFO (XendCheckpoint:353) Saving memory pages: iter 1   0%ERROR Internal error: Error when writing to state file (5) (errno 104)
[2013-11-13 11:49:00 xend 29149] INFO (XendCheckpoint:353) Save exit rc=1
[2013-11-13 11:49:00 xend 29149] ERROR (XendCheckpoint:133) Save failed on domain Pasiphae2 (35).
Traceback (most recent call last):
  File "/usr/lib64/python2.4/site-packages/xen/xend/XendCheckpoint.py", line 110, in save
    forkHelper(cmd, fd, saveInputHandler, False)
  File "/usr/lib64/python2.4/site-packages/xen/xend/XendCheckpoint.py", line 341, in forkHelper
    raise XendError("%s failed" % string.join(cmd))
XendError: /usr/lib64/xen/bin/xc_save 4 35 0 0 5 failed
[2013-11-13 11:49:00 xend.XendDomainInfo 29149] DEBUG (XendDomainInfo:2206) XendDomainInfo.resumeDomain(35)
[2013-11-13 11:49:00 xend 29149] DEBUG (XendCheckpoint:136) XendCheckpoint.save: resumeDomain



Thank you!
Jim

[-- Attachment #1.2: Type: text/html, Size: 3554 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2013-09-13 16:59 David Vrabel
  0 siblings, 0 replies; 147+ messages in thread
From: David Vrabel @ 2013-09-13 16:59 UTC (permalink / raw)
  To: xen-devel; +Cc: Boris Ostrovsky, David Vrabel, Jan Beulich

This is an RFC of Linux guest-side implementation of the FIFO-based
event channel ABI described in this design document:

http://xenbits.xen.org/people/dvrabel/event-channels-E.pdf

Refer also to the Xen series.

Remaining work:

* Add an function to set a event channel's priority and use this to
  set the VIRQ timer to the highest priority.

Patch 1 is a obvious refactoring of common code.

Patch 2-6 prepare for supporting multiple ABIs.

Patch 7 adds the low-level evtchn_ops hooks.

Patch 8-9 add an additional hook for ABI-specific per-port setup
(used for expanding the event array as more event are bound).

Patch 10 allows many more event channels to be supported by altering
how the event channel to irq map is allocated.  Note that other
factors limit the number of supported IRQs (IRQs is 8192 + 64 *
NR_CPUS).

Patch 11 is some trival refactoring.

Patch 12-13 add the ABI and the implementation.

David

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2013-08-14  2:28 yvxiang
  2013-08-14  2:31 ` yvxiang
@ 2013-08-14  2:57 ` agya naila
  1 sibling, 0 replies; 147+ messages in thread
From: agya naila @ 2013-08-14  2:57 UTC (permalink / raw)
  To: yvxiang; +Cc: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 643 bytes --]

Hi,

In my case I used the live migration for VoIP service. I make a simple
measurement by using wireshark,  I generate the call and then shut down one
of my virtual machine. Then using packet captured via wireshark I generate
the jitter using telephony RTP stream anaysis. If you read the report you
may see the maximum delta that correlated to the downtime in my case for my
voip service.

Best Regards,


Agya


On Wed, Aug 14, 2013 at 9:28 AM, yvxiang <linyvxiang@gmail.com> wrote:

> Hi,Agya,
>
> Now I need to measure the downtime while doing a live migration. I saw
> your mail before about this topic.  How did you measure the time?
>

[-- Attachment #1.2: Type: text/html, Size: 1207 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2013-08-14  2:28 yvxiang
@ 2013-08-14  2:31 ` yvxiang
  2013-08-14  2:57 ` agya naila
  1 sibling, 0 replies; 147+ messages in thread
From: yvxiang @ 2013-08-14  2:31 UTC (permalink / raw)
  To: agya.naila; +Cc: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 370 bytes --]

So sorry,I forgot the subject..


2013/8/14 yvxiang <linyvxiang@gmail.com>

> Hi,Agya,
>
> Now I need to measure the downtime while doing a live migration. I saw
> your mail before about this topic.  How did you measure the time?
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

[-- Attachment #1.2: Type: text/html, Size: 829 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2013-08-14  2:28 yvxiang
  2013-08-14  2:31 ` yvxiang
  2013-08-14  2:57 ` agya naila
  0 siblings, 2 replies; 147+ messages in thread
From: yvxiang @ 2013-08-14  2:28 UTC (permalink / raw)
  To: agya.naila; +Cc: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 147 bytes --]

Hi,Agya,

Now I need to measure the downtime while doing a live migration. I saw your
mail before about this topic.  How did you measure the time?

[-- Attachment #1.2: Type: text/html, Size: 191 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2013-06-28 16:10 ` [PATCH 08/10] xen: arm: add scope to dsb and dmb macros Ian Campbell
@ 2013-07-04 11:44   ` Tim Deegan
  0 siblings, 0 replies; 147+ messages in thread
From: Tim Deegan @ 2013-07-04 11:44 UTC (permalink / raw)
  To: Ian Campbell; +Cc: julien.grall, xen-devel, stefano.stabellini

Oops, a wandering newline seems to have got into the headers here. :)

Tim.

At 12:32 +0100 on 04 Jul (1372941166), Tim Deegan wrote:
> Bcc: Tim Deegan <tjd-xen@phlegethon.org>
> Subject: Re: [Xen-devel] [PATCH 08/10] xen: arm: add scope to dsb and dmb macros
> Reply-To: 
> In-Reply-To: <1372435856-14040-8-git-send-email-ian.campbell@citrix.com>
> 
> At 17:10 +0100 on 28 Jun (1372439454), Ian Campbell wrote:
> > Everywhere currently passes "sy"stem, so no actual change.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Tim Deegan <tim@xen.org>
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2013-07-04 11:32 Tim Deegan
  2013-06-28 16:10 ` [PATCH 08/10] xen: arm: add scope to dsb and dmb macros Ian Campbell
  0 siblings, 1 reply; 147+ messages in thread
From: Tim Deegan @ 2013-07-04 11:32 UTC (permalink / raw)
  To: Ian Campbell; +Cc: julien.grall, stefano.stabellini, xen-devel

Bcc: Tim Deegan <tjd-xen@phlegethon.org>
Subject: Re: [Xen-devel] [PATCH 08/10] xen: arm: add scope to dsb and dmb macros
Reply-To: 
In-Reply-To: <1372435856-14040-8-git-send-email-ian.campbell@citrix.com>

At 17:10 +0100 on 28 Jun (1372439454), Ian Campbell wrote:
> Everywhere currently passes "sy"stem, so no actual change.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2013-06-26 11:42 Divya Kapil
@ 2013-06-26 11:54 ` Ian Campbell
  0 siblings, 0 replies; 147+ messages in thread
From: Ian Campbell @ 2013-06-26 11:54 UTC (permalink / raw)
  To: Divya Kapil; +Cc: xen-devel

On Wed, 2013-06-26 at 17:12 +0530, Divya Kapil wrote:
> How can i change migration code in xen?

I'm sorry but your question is so vague as to be unanswerable with
anything other than a snide remark like "with vi or emacs".

http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions

Ian.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2013-06-26 11:42 Divya Kapil
  2013-06-26 11:54 ` Ian Campbell
  0 siblings, 1 reply; 147+ messages in thread
From: Divya Kapil @ 2013-06-26 11:42 UTC (permalink / raw)
  To: xen-devel

How can i change migration code in xen?

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2013-06-16 13:45 wei.liu2
  0 siblings, 0 replies; 147+ messages in thread
From: wei.liu2 @ 2013-06-16 13:45 UTC (permalink / raw)


We would like you to answer the following questions (feel free to
write up your own report if you're a power user):

* What's the sotware setup?
  * Dom0: e.g. 64 bit CentOS 6.2
  * DomU: e.g. Debian Wheezy
  * Xen: e.g. 4.1 installed with apt-get / 4.2 compiled from tarball
  * toolstack: xl / xm / libvirt ...

* What's the hardware setup?

* What were you trying to achieve?

* What commands did you run?

* What's the expected outcome?

* What's the actual outcome?

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2013-05-14 15:11 Feng Tang
  0 siblings, 0 replies; 147+ messages in thread
From: Feng Tang @ 2013-05-14 15:11 UTC (permalink / raw)
  To: David Vrabel, John Stultz
  Cc: Thomas Gleixner, Konrad Rzeszutek Wilk, linux-kernel, xen-devel

Bcc: 
Subject: Re: [PATCH 2/3] timekeeping: sync persistent clock and RTC on system time step changes
Reply-To: 

Hi David,

> From: David Vrabel <david.vrabel@citrix.com>
> Date: 2013/5/14
> Subject: Re: [PATCH 2/3] timekeeping: sync persistent clock and RTC on
> system time step changes
> To: John Stultz <john.stultz@linaro.org>
> Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Konrad
> Rzeszutek Wilk <konrad.wilk@oracle.com>, Thomas Gleixner
> <tglx@linutronix.de>, "linux-kernel@vger.kernel.org"
> <linux-kernel@vger.kernel.org>
> 
> 
> On 14/05/13 01:40, John Stultz wrote:
> > On 05/13/2013 10:56 AM, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> The persistent clock or the RTC is only synchronized with system time
> >> every 11 minutes if NTP is running.  This gives a window where the
> >> persistent clock may be incorrect after a step change in the time
> >> (such as on first boot).
> >>
> >> This particularly affects Xen guests as until an update to the control
> >> domain's persistent clock, new guests will start with the incorrect
> >> system time.
> >>
> >> When there is a step change in the system time, call
> >> update_persistent_clock or rtc_set_ntp_time() to synchronize the
> >> persistent clock or RTC to the new system time.
> >
> > I'm sorry, this isn't quite making sense to me. Could you further
> > describe the exact problematic behavior you're seeing here, and why its
> > a problem?
> 
> The Xen wallclock is used as the persistent clock for Xen guests.  This
> is initialized (by Xen) with the CMOS RTC at the start of day.  If the
> RTC is incorrect then guests will see an incorrect wallclock time until
> dom0 has corrected it.
> 
> Currently dom0 only updates the Xen wallclock with the 11 min periodic
> work when NTP is synced.  This leaves a window where newly started
> guests will see an incorrect wallclock time.  This can cause guests to
> fail to start correctly if the wallclock is now behind what it was when
> the guest last started. (e.g., fsck of its disk fails as its last mount
> time appears to be far into the future).

Is it possible for Xen to resync its wallclock time from the RTC device
whenever it gets a request of starting a new guest? as usually a new
guest OS needs to get the time base from Xen's wallclock anyway.

Thanks,
Feng

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2013-05-03  8:48 Lars Kurth
  0 siblings, 0 replies; 147+ messages in thread
From: Lars Kurth @ 2013-05-03  8:48 UTC (permalink / raw)
  To: xen-api, xen-users, xen-devel; +Cc: Kimihiko.Kitase


[-- Attachment #1.1: Type: text/plain, Size: 1926 bytes --]

> Subject: Looking for volunteer to help man LinuxCon Japan booth (1-2 hours
> a day)
>
> Dear Community member,
>
> the Xen Project was planning to have a booth at LinuxCon Japan this year
> (for more information, see
> http://events.linuxfoundation.org/events/linuxcon-japan/<https://mail.citrix.com/owa/redir.aspx?C=dnbPGSChGEWoACoWH_QLpH7EveZxG9BIE6cabrXu0jA-wgQqxbnVAgQREizU60s78z6uEa6Tkac.&URL=http%3a%2f%2fevents.linuxfoundation.org%2fevents%2flinuxcon-japan%2f>).
We are
> looking for one or two users (or developers of Xen) to help out a couple
> of hours a day on the Xen Project booth. I am looking for people who know
> Xen, XAPI or XCP, speak Japanese and want to spend an hour or two a day
> on the booth with me and a few other community members. If this is you,
> please get in touch!
>
> I will be able to get you a free conference pass for LinuxCon. If this is
> you and you would like to attend LinuxCon, but cannot afford it, we do
have
> a number of travel stipends available. In that case, please also send me
> an e-mail.
>
> Best Regards
> Lars


-----

みなさま、こんにちは

The Xen Community ManagerのLars Kurthです。



The Xen Projectコミュニティでは、5/29 - 31 椿山荘で開催されるLinuxCon Japan / CloudOpen Japan
にて展示ブースを出す予定です。

https://events.linuxfoundation.jp/events/linuxcon-japan

https://events.linuxfoundation.jp/events/cloudopen-japan



そこで展示ブーススタッフを募集しています。OSS Xenの開発者、ユーザー、

その他関連各位で、半日でも、1日でもお時間が取れる方がいらっしゃれば

ご連絡いただければと思います。



もちろん、ブーススタッフとして協力いただける方には、

LinuxCon Japan / CloudOpen Japan のFree Passチケットをお渡しします。



よろしくお願いいたします。



連絡先

Lars Kurth lars.kurth@citrix.com  (英語)
Kimihiko Kitase Kimihiko.Kitase@citrix.co.jp (日本語)

[-- Attachment #1.2: Type: text/html, Size: 8578 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2013-04-22 21:56 ` Cutter 409
@ 2013-04-23  8:49   ` Tim Deegan
  0 siblings, 0 replies; 147+ messages in thread
From: Tim Deegan @ 2013-04-23  8:49 UTC (permalink / raw)
  To: Cutter 409; +Cc: Aravindh Puthiyaparambil, xen-devel

Hi,

At 17:56 -0400 on 22 Apr (1366653364), Cutter 409 wrote:
> I'm finally to a point where I can start looking at this more closely. I'm
> trying to wrap my head around the shadow code to figure out the right
> course of action.
> 
> I'd want HVMOP_set_mem_access to work with both shadow and EPT, so I'd want
> things to work via p2m somehow. I think I understand this part.
> 
> * HVMOP_set_mem_access is used to change the p2m_access_t for the target
> page(s). This should already be implemented I think?

Yep.  The shadow code uses the same p2m implementataion as NPT, so that
should all be fine. 

> * During propagation, I'll check the p2m map to see if I should mask off
> any permission bits.

Yep.  You'll already be doing a p2m lookup to get the MFN, so you just
need to look at the p2ma as well. 

> * On a shadow paging fault, I'll check if the fault was caused by p2m
> permissions, somehow integrating that with the code for read-only guest
> page tables safely.

Yes.  The common case will be handled in _sh_propagate, which is where
the shadow PTE is constructed.  For the rest you'll need to look at the
places where the shadow fault handler calls the emulator and DTRT
(either before the call or in the callbacks that the emulator uses to
access guest memory).

> Questions:
> 
> * Just for background, am I correct in my understanding that the log_dirty
> code is used to track which gfns have been written to by the guest, in
> order to speed up migration?

That's right.  It's also used to track which parts of an emulated
framebuffer have been updated, to make VNC connections more efficient.

> * Are multiple shadow tables maintained per domain? Is there one per VCPU?
> One shadow table per guest page table? Is it blown away every time the
> guest changes CR3? I'm having some trouble tracking this down.

There's one set of shadows per domain, shared among all VCPUs.  A given
page of memory may have multiple shadows though, e.g. if it's seen both
as a top-level pagetables and a leaf pagetable. 

Shadows are kept around until:
 - it looks like the page is no longer a pagetable;
 - the guest explicitly tells us it's no longer a pagetable; or
 - we need the memory to shadow some other page. 

Mostly, a pages's shadow(s) are kept in sync with any changes the guest
makes to the page, by trapping and emulating all writes.  For
performance, we allow some l1 pagetables to be 'out of sync' ('oos' in
the code), letting the guest write to the page directly.  On guest CR3
writes (and other TLB-flush-related activity) we make sure any OOS
shadows are brought up to date. 

> * How should I clear/update existing shadow entries after changing the
> p2m_access_t? Can I clear the shadow tables somehow and force everything to
> be repopulated? Is that insane?

It depends how often you're changing the access permissions.
sh_remove_all_mappings() and sh_remove_write_access() will try to flush
mappings of a single MFN from the shadows, but they can be expensive
(e.g. involving a brute-force scan of all shadows) so if you're going to
do a lot of them it may be worth considering batching them up and
calling shadow_blow_tables() once instead.

Cheers,

Tim.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2012-11-15 12:08 Tim Deegan
  2012-11-15 23:04 ` Aravindh Puthiyaparambil
@ 2013-04-22 21:56 ` Cutter 409
  2013-04-23  8:49   ` Tim Deegan
  1 sibling, 1 reply; 147+ messages in thread
From: Cutter 409 @ 2013-04-22 21:56 UTC (permalink / raw)
  To: Tim Deegan; +Cc: Aravindh Puthiyaparambil, xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 3206 bytes --]

Hi,

I'm finally to a point where I can start looking at this more closely. I'm
trying to wrap my head around the shadow code to figure out the right
course of action.

I'd want HVMOP_set_mem_access to work with both shadow and EPT, so I'd want
things to work via p2m somehow. I think I understand this part.

* HVMOP_set_mem_access is used to change the p2m_access_t for the target
page(s). This should already be implemented I think?
* During propagation, I'll check the p2m map to see if I should mask off
any permission bits.
* On a shadow paging fault, I'll check if the fault was caused by p2m
permissions, somehow integrating that with the code for read-only guest
page tables safely.

Questions:

* Just for background, am I correct in my understanding that the log_dirty
code is used to track which gfns have been written to by the guest, in
order to speed up migration?
* Are multiple shadow tables maintained per domain? Is there one per VCPU?
One shadow table per guest page table? Is it blown away every time the
guest changes CR3? I'm having some trouble tracking this down.
* How should I clear/update existing shadow entries after changing the
p2m_access_t? Can I clear the shadow tables somehow and force everything to
be repopulated? Is that insane?

Thanks!



On Thu, Nov 15, 2012 at 7:08 AM, Tim Deegan <tim@xen.org> wrote:

> Bcc: Tim Deegan <tjd-xen@phlegethon.org>
> Subject: Re: [Xen-devel] Guest memory access hooking
> Reply-To:
> In-Reply-To: <
> CAG4Ohu_p-vVF9ZS01PeMqHvscCrrO+UDawK-noaaP8k+MuqHrQ@mail.gmail.com>
>
> Hi,
>
> At 10:56 -0500 on 13 Nov (1352804161), Cutter 409 wrote:
> > I'm trying to do some research with malware, and I'm trying to get
> > notifications on arbitrary guest page accesses (similar to what Ether
> > does.) I've noticed the mem-event API and it seems like it might be close
> > to what I need, but I can't find much documentation about how it works or
> > how to use it.
>
> Yes, the mem-event api, and in particular the HVMOP_set_mem_access
> hypercall, looks like what you want.  As you say, there isn't much
> documentation for it, except the xen-access.c client and the mailing
> list archive.
>
> CC'ing Aravindh, who has worked on this code most recently and might be
> able to help with specific questions.
>
> > I know that that mem-event API works only with EPT, but is the code to
> > change permissions modifying the guest page tables, or does it work via
> > EPT? (Can the guest detect it?)
>
> It works by EPT.  The guest can't detect it by looking at its pagetables
> or page fault patterns, though it might be able to detect it by looking
> at timings.
>
> > I'm also interested monitoring arbitrary page access via the shadow page
> > tables. I've been reading through the code, but if anyone has any insight
> > or some kind of push in the right direction, I'd really appreciate it.
>
> Your best bet is to modify _sh_propagate.  Look at how it handles
> shadow_mode_log_dirty() -- any time a writeable mapping is shadowed, the
> shadow PTE is made read-only until the guest is actually doing a write,
> then mark_dirty can be called.  You should be able to do the same thing
> for other kinds of access.
>
> Cheers,
>
> Tim.
>

[-- Attachment #1.2: Type: text/html, Size: 4078 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2013-04-21 22:26 Lonnie Cumberland
  0 siblings, 0 replies; 147+ messages in thread
From: Lonnie Cumberland @ 2013-04-21 22:26 UTC (permalink / raw)
  To: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 1457 bytes --]

Greetings All,

I am very new to Xen but have spent a considerable amount of time
researching various emulators and simulators like QEMU, Virtualbox, Bochs,
etc.... to find out which may be good for a project that I am interested in
moving towards related to the x86_64 platform.

It seems that XEN may be the best solution as I need something that can be
billed as a Type I and also Type II emulator. Xen and HXen meet these goals.

Now I am entering the learning curve to get a feel for the source code but
had a question related to the layout of Xen.

I am trying to understand where the main init functions are in Xen as for
example in QEMU they are in the v1.c file and as to where the mian loops
are for the hypervisor are to loop through the vCPU's.

I am also trying to get a feel for where the memory allocation functions
are in Xen.

Also, in the Xen 4.2.1 distro, is qemu called for each HPV.

Please forgive these questions if they should be obvious to me, but I would
like to get a good feel for the booting sequence and control loops that Xen
has to utilize.

I have read a number of documents on the website that give me briev
overview of how Xen operates with  Dom0 and DomU guests but now it is time
for me to get a feel for the sources so that I might be able to learn and
contribute to the effort of a very wonderful hypervisor.

Any guidance or help would be greatly appreciated.

Kind Regards and have a great day,
Lonnie T. Cumberland

[-- Attachment #1.2: Type: text/html, Size: 1866 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
       [not found]       ` <CAHyyzzQsh30y7-4M1xmJc+8p-EcqS0+jaibpTrXxTQi92iGDgw@mail.gmail.com>
@ 2013-04-10 15:28         ` jacek burghardt
  0 siblings, 0 replies; 147+ messages in thread
From: jacek burghardt @ 2013-04-10 15:28 UTC (permalink / raw)
  To: George Dunlap; +Cc: Stefan, ian.jackson, xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 250 bytes --]

Does xcp supports assignment of USB or xen-api ? I know that spice allows
for USB redirection. Also remote desktop supports redirection of devices. I
like using android devices with xen hosted servers as remote desktop
exports my SD cards to server.

[-- Attachment #1.2: Type: text/html, Size: 258 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2013-04-10  6:57 Mina Jafari
  0 siblings, 0 replies; 147+ messages in thread
From: Mina Jafari @ 2013-04-10  6:57 UTC (permalink / raw)
  To: xen-users, xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 3275 bytes --]

I can't install any guest vm,(I'm trying this on Fedora13 and kernel
3.2.7,compiled as dom0 and xen 4.1.2)
virt-manager connect to xen but when trying to create a new guest it
fails with this error:

Unable to complete install: 'POST operation failed: xend_post: error
from xen daemon: (xend.err 'Device 0 (vif) could not be connected.
Hotplug scripts not working.')'
operation failed: xend_post: error from xen daemon: (xend.err 'Device
0 (vif) could not be connected. Hotplug scripts not working.')
Traceback (most recent call last):
  File "/usr/share/virt-manager/
virtManager/create.py", line 1567, in
do_install
    dom = guest.start_install(False, meter = meter)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line
1023, in start_install
    return self._do_install(consolecb, meter, removeOld, wait)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line
1088, in _do_install
    "install")
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line
1059, in _create_guest
    dom = self.conn.createLinux(start_xml, 0)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1277, in
createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed',
conn=self)
libvirtError: POST operation failed: xend_post: error from xen daemon:
(xend.err 'Device 0 (vif) could not be connected. Hotplug scripts not
working.')

and the same problem when creating by commandline.

I'v set up a bridge:
brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.0024e8e7bd75       no              eth0
virbr0          8000.000000000000       yes


ifcfg-br0  file :
DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
NM_CONTROLLED=yes



ifconfig
br0       Link encap:Ethernet  HWaddr 00:24:E8:E7:BD:75
          inet6 addr: fe80::224:e8ff:fee7:bd75/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:554 (554.0 b)

eth0      Link encap:Ethernet  HWaddr 00:24:E8:E7:BD:75
          UP BROADCAST MULTICAST  MTU:9000  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:36 Base address:0x8000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:131950 errors:0 dropped:0 overruns:0 frame:0
          TX packets:131950 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:15243838 (14.5 MiB)  TX bytes:15243838 (14.5 MiB)

virbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00
          inet addr:#.#.#.#  Bcast:#.#.#.#  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

[-- Attachment #1.2: Type: text/html, Size: 3829 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2013-03-15  7:40 digvijay chauhan
  2013-03-15  9:59 ` Ian Campbell
@ 2013-03-15 11:18 ` Pasi Kärkkäinen
  1 sibling, 0 replies; 147+ messages in thread
From: Pasi Kärkkäinen @ 2013-03-15 11:18 UTC (permalink / raw)
  To: digvijay chauhan
  Cc: xen-users, Christian Limpach, xen-devel, Ian Campbell, xen-devel

On Fri, Mar 15, 2013 at 01:10:02PM +0530, digvijay chauhan wrote:
>    Hello,
>                I am trying to install xen4.2 but when ifire make tools
>    command it gives me,
> 
>    Cloning into 'seabios-dir-remote.tmp'...
>    fatal: unable to connect to [1]xenbits.xen.org:
>    [2]xenbits.xen.org[0: 50.57.170.242]: errno=Connection timed out
> 

So maybe your firewall is blocking the connection? 

-- Pasi

>    make[3]: *** [seabios-dir] Error 128
>    make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/
>    firmware'
>    make[2]: *** [subdir-install-firmware] Error 2
>    make[2]: Leaving directory `/home/ce/xen-4.2.0/tools'
>    make[1]: *** [subdirs-install] Error 2
>    make[1]: Leaving directory `/home/ce/xen-4.2.0/tools'
>    make: *** [install-tools] Error 2
> 
>    so how can i overcome it.
> 
>    regards,
>    DigvijaySingh
> 
> References
> 
>    Visible links
>    1. http://xenbits.xen.org/
>    2. http://xenbits.xen.org/

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

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2013-03-15  7:40 digvijay chauhan
@ 2013-03-15  9:59 ` Ian Campbell
  2013-03-15 11:18 ` Pasi Kärkkäinen
  1 sibling, 0 replies; 147+ messages in thread
From: Ian Campbell @ 2013-03-15  9:59 UTC (permalink / raw)
  To: digvijay chauhan; +Cc: xen-users, Christian Limpach, xen-devel, xen-devel

Digvijay,

You have cross posted this message to multiple lists I have already
asked you not to do this on at least one occasion.

You have also CCd various people, including myself, seemingly at random,
*and* posted the same message three times in quick succession.

Please stop this antisocial behaviour.

Post to a single list (xen-users@ in the common case for the sorts of
questions you are asking) and wait a reasonable amount of time (i.e.
measured in days) for a response before pinging.

Ian.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2013-03-15  7:40 digvijay chauhan
  2013-03-15  9:59 ` Ian Campbell
  2013-03-15 11:18 ` Pasi Kärkkäinen
  0 siblings, 2 replies; 147+ messages in thread
From: digvijay chauhan @ 2013-03-15  7:40 UTC (permalink / raw)
  To: xen-users, xen-devel, xen-devel, Ian Campbell, Christian Limpach


[-- Attachment #1.1: Type: text/plain, Size: 627 bytes --]

Hello,
            I am trying to install xen4.2 but when ifire make tools command
it gives me,

Cloning into 'seabios-dir-remote.tmp'...
fatal: unable to connect to xenbits.xen.org:
xenbits.xen.org[0: 50.57.170.242]: errno=Connection timed out

make[3]: *** [seabios-dir] Error 128
make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/
firmware'
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/home/ce/xen-4.2.0/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/home/ce/xen-4.2.0/tools'
make: *** [install-tools] Error 2


so how can i overcome it.

regards,
DigvijaySingh

[-- Attachment #1.2: Type: text/html, Size: 842 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2013-01-08 21:51 Rushikesh Jadhav
  0 siblings, 0 replies; 147+ messages in thread
From: Rushikesh Jadhav @ 2013-01-08 21:51 UTC (permalink / raw)
  To: xen-api, xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 331 bytes --]

Hello List,

Please help me in diagnosing below error in /var/log/messages

HVM1[16586]:  txftrans.c:4498 -- TXF_HARD_ERROR (0xC01A002B) for RM:
fffff8800d099000

Im unable to find any google reference related to above C file or its
source code. http://lmgtfy.com/?q=txftrans.c

Thanks for reading and helping.

Regards,
Rushikesh

[-- Attachment #1.2: Type: text/html, Size: 484 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2012-11-15 12:08 Tim Deegan
@ 2012-11-15 23:04 ` Aravindh Puthiyaparambil
  2013-04-22 21:56 ` Cutter 409
  1 sibling, 0 replies; 147+ messages in thread
From: Aravindh Puthiyaparambil @ 2012-11-15 23:04 UTC (permalink / raw)
  To: Tim Deegan; +Cc: xen-devel, Cutter 409

On Thu, Nov 15, 2012 at 4:08 AM, Tim Deegan <tim@xen.org> wrote:
>
> Bcc: Tim Deegan <tjd-xen@phlegethon.org>
> Subject: Re: [Xen-devel] Guest memory access hooking
> Reply-To:
> In-Reply-To: <CAG4Ohu_p-vVF9ZS01PeMqHvscCrrO+UDawK-noaaP8k+MuqHrQ@mail.gmail.com>
>
> Hi,
>
> At 10:56 -0500 on 13 Nov (1352804161), Cutter 409 wrote:
> > I'm trying to do some research with malware, and I'm trying to get
> > notifications on arbitrary guest page accesses (similar to what Ether
> > does.) I've noticed the mem-event API and it seems like it might be close
> > to what I need, but I can't find much documentation about how it works or
> > how to use it.
>
> Yes, the mem-event api, and in particular the HVMOP_set_mem_access
> hypercall, looks like what you want.  As you say, there isn't much
> documentation for it, except the xen-access.c client and the mailing
> list archive.
>
> CC'ing Aravindh, who has worked on this code most recently and might be
> able to help with specific questions.

Sure, I can help with the specifics of the API usage.

> > I know that that mem-event API works only with EPT, but is the code to
> > change permissions modifying the guest page tables, or does it work via
> > EPT? (Can the guest detect it?)
>
> It works by EPT.  The guest can't detect it by looking at its pagetables
> or page fault patterns, though it might be able to detect it by looking
> at timings.
>
> > I'm also interested monitoring arbitrary page access via the shadow page
> > tables. I've been reading through the code, but if anyone has any insight
> > or some kind of push in the right direction, I'd really appreciate it.

It might be useful to get mem-event working with shadow by following
Tim's suggestions to achieve what you are after.

Thanks,
Aravindh

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2012-11-15 12:08 Tim Deegan
  2012-11-15 23:04 ` Aravindh Puthiyaparambil
  2013-04-22 21:56 ` Cutter 409
  0 siblings, 2 replies; 147+ messages in thread
From: Tim Deegan @ 2012-11-15 12:08 UTC (permalink / raw)
  To: Cutter 409; +Cc: Aravindh Puthiyaparambil, xen-devel

Bcc: Tim Deegan <tjd-xen@phlegethon.org>
Subject: Re: [Xen-devel] Guest memory access hooking
Reply-To: 
In-Reply-To: <CAG4Ohu_p-vVF9ZS01PeMqHvscCrrO+UDawK-noaaP8k+MuqHrQ@mail.gmail.com>

Hi,

At 10:56 -0500 on 13 Nov (1352804161), Cutter 409 wrote:
> I'm trying to do some research with malware, and I'm trying to get
> notifications on arbitrary guest page accesses (similar to what Ether
> does.) I've noticed the mem-event API and it seems like it might be close
> to what I need, but I can't find much documentation about how it works or
> how to use it.

Yes, the mem-event api, and in particular the HVMOP_set_mem_access
hypercall, looks like what you want.  As you say, there isn't much
documentation for it, except the xen-access.c client and the mailing
list archive. 

CC'ing Aravindh, who has worked on this code most recently and might be
able to help with specific questions.

> I know that that mem-event API works only with EPT, but is the code to
> change permissions modifying the guest page tables, or does it work via
> EPT? (Can the guest detect it?)

It works by EPT.  The guest can't detect it by looking at its pagetables
or page fault patterns, though it might be able to detect it by looking
at timings.

> I'm also interested monitoring arbitrary page access via the shadow page
> tables. I've been reading through the code, but if anyone has any insight
> or some kind of push in the right direction, I'd really appreciate it.

Your best bet is to modify _sh_propagate.  Look at how it handles
shadow_mode_log_dirty() -- any time a writeable mapping is shadowed, the
shadow PTE is made read-only until the guest is actually doing a write,
then mark_dirty can be called.  You should be able to do the same thing
for other kinds of access.

Cheers,

Tim.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2012-07-27 23:02 lmw
  0 siblings, 0 replies; 147+ messages in thread
From: lmw @ 2012-07-27 23:02 UTC (permalink / raw)
  To: xen-devel

What is the easiest way to determine the Dom Id of a unmodified Xen HVM guest from within a daemon process running in the guest?

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2012-07-14  4:16 张智
@ 2012-07-19 10:24 ` Tim Deegan
  0 siblings, 0 replies; 147+ messages in thread
From: Tim Deegan @ 2012-07-19 10:24 UTC (permalink / raw)
  To: ????; +Cc: xen-devel

At 04:16 +0000 on 14 Jul (1342239382), ???? wrote:
> 
> Hi, list,
> Where can I find the "tools/tests/mem-sharing/memshrtool.c" ?I didn't find it in the latest version of xen-4.1.2. Thanks.

You'll find it in the xen-unstable tree.  In general the memory-sharing
code in 4.1.x is not stable enough to use. 

Cheers,

Tim.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2012-07-14  4:16 张智
  2012-07-19 10:24 ` Tim Deegan
  0 siblings, 1 reply; 147+ messages in thread
From: 张智 @ 2012-07-14  4:16 UTC (permalink / raw)
  To: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 168 bytes --]


Hi, list,
Where can I find the "tools/tests/mem-sharing/memshrtool.c" ?I didn't find it in the latest version of xen-4.1.2. Thanks.
All the very best,Henry 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 844 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2012-04-15  6:09 Lin Ming
  0 siblings, 0 replies; 147+ messages in thread
From: Lin Ming @ 2012-04-15  6:09 UTC (permalink / raw)
  To: linux-kernel
  Cc: Jeremy Fitzhardinge, Peter Zijlstra, Konrad Rzeszutek Wilk,
	Steven Noonan, Marcus Granado, xen-devel, Ben Guthro

Hi all,

These 2 patches try to fix the "perf top" soft lockups under Xen
reported by Steven at: https://lkml.org/lkml/2012/2/9/506

I tested it with 3.4-rc2 and "perf top" works well now.

Steven,
Could you please help to test it too?

The soft lockup code path is:

__irq_work_queue
  arch_irq_work_raise
    apic->send_IPI_self(IRQ_WORK_VECTOR);
      apic_send_IPI_self
        __default_send_IPI_shortcut
          __xapic_wait_icr_idle

static inline void __xapic_wait_icr_idle(void)
{
        while (native_apic_mem_read(APIC_ICR) & APIC_ICR_BUSY)
                cpu_relax();
}

The lockup happens at above while looop.
                                                                
The cause is that Xen has not implemented the APIC IPI interface yet.
Xen has IPI interface: xen_send_IPI_one, but it's only used in
xen_smp_send_reschedule, xen_smp_send_call_function_ipi and
xen_smp_send_call_function_single_ipi, etc.

So we need to implement Xen's APIC IPI interface as Ben's patch does.
And implement Xen's IRQ_WORK_VECTOR handler.

Ben Guthro (1):
      xen: implement apic ipi interface

Lin Ming (1):
      xen: implement IRQ_WORK_VECTOR handler

 arch/x86/include/asm/xen/events.h |    1 +
 arch/x86/xen/enlighten.c          |    7 ++
 arch/x86/xen/smp.c                |  111 +++++++++++++++++++++++++++++++++++-
 arch/x86/xen/smp.h                |   12 ++++
 4 files changed, 127 insertions(+), 4 deletions(-)

Any comment is appreciated.
Lin Ming

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2012-04-06 15:14             ` Konrad Rzeszutek Wilk
@ 2012-04-06 16:09               ` Francisco Rocha
  0 siblings, 0 replies; 147+ messages in thread
From: Francisco Rocha @ 2012-04-06 16:09 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk, Wei Huang; +Cc: Andrew Cooper, xen-devel


________________________________________
From: Konrad Rzeszutek Wilk [konrad.wilk@oracle.com]
Sent: 06 April 2012 16:14
To: Wei Huang
Cc: Francisco Rocha; Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On Fri, Apr 06, 2012 at 09:51:52AM -0500, Wei Huang wrote:
> Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with
> xsave/xrstor.

Hm .

.. snip..
> >kernel /boot/xen.gz blah blah xsave=0
> >module blah blah
> >blah
> >
> >Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
> >
> >Thank you for the help.
> >
> >Francisco
> >
> >-Wei
> >
> >>Anyway, shouldn't Xen support it?
> >>
> >>cheers,
> >>Francisco
> >The xsave=0 command line parameter solves the problem.

Francisco,

What version of Xen do you have? Xen 4.1? What is the motherboard/CPU combination.

I downloaded the latest version from xen-unstable.hg yesterday.

My machine is a Toshiba laptop R840-12F. Here is some info:

# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz
stepping	: 7
microcode	: 0x25
cpu MHz		: 800.000
cache size	: 4096 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips	: 5382.80
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

BIOS: TOSHIBA
Version: Version 3.60  
Release Date: 01/24/2012

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2012-04-06 14:51           ` Wei Huang
  2012-04-06 15:02             ` Francisco Rocha
@ 2012-04-06 15:14             ` Konrad Rzeszutek Wilk
  2012-04-06 16:09               ` Francisco Rocha
  1 sibling, 1 reply; 147+ messages in thread
From: Konrad Rzeszutek Wilk @ 2012-04-06 15:14 UTC (permalink / raw)
  To: Wei Huang; +Cc: Francisco Rocha, xen-devel, Andrew Cooper

On Fri, Apr 06, 2012 at 09:51:52AM -0500, Wei Huang wrote:
> Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with
> xsave/xrstor.

Hm .

.. snip..
> >kernel /boot/xen.gz blah blah xsave=0
> >module blah blah
> >blah
> >
> >Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
> >
> >Thank you for the help.
> >
> >Francisco
> >
> >-Wei
> >
> >>Anyway, shouldn't Xen support it?
> >>
> >>cheers,
> >>Francisco
> >The xsave=0 command line parameter solves the problem.

Francisco,

What version of Xen do you have? Xen 4.1? What is the motherboard/CPU combination.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2012-04-06 14:51           ` Wei Huang
@ 2012-04-06 15:02             ` Francisco Rocha
  2012-04-06 15:14             ` Konrad Rzeszutek Wilk
  1 sibling, 0 replies; 147+ messages in thread
From: Francisco Rocha @ 2012-04-06 15:02 UTC (permalink / raw)
  To: wei.huang2; +Cc: Andrew Cooper, xen-devel


________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 06 April 2012 15:51
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with
xsave/xrstor.

-Wei

I didn't change the kernel, it's a fresh install.
I tried the latest for Fedora 16 and Xubuntu 11.10 both 
rebooted the machine.

Cheers,
Francisco

On 04/06/2012 09:53 AM, Francisco Rocha wrote:
> ________________________________________
> From: Francisco Rocha
> Sent: 05 April 2012 21:43
> To: wei.huang2@amd.com
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] (no subject)
>
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 21:27
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 03:17 PM, Francisco Rocha wrote:
>> ________________________________________
>> From: Wei Huang [wei.huang2@amd.com]
>> Sent: 05 April 2012 20:36
>> To: Francisco Rocha
>> Cc: Andrew Cooper; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] (no subject)
>>
>> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>>> To:<xen-devel@lists.xen.org>
>>> Subject: Re: [Xen-devel] lastest xen unstable crash
>>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>>> Content-Type: text/plain; charset="ISO-8859-1"
>>>
>>> On 05/04/12 18:37, Francisco Rocha wrote:
>>>> Hi everyone,
>>>>
>>>> I was trying to build a new machine but the system keeps rebooting.
>>>> I used the lasted unstable version from xen-unstable.hg.
>>>>
>>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>>
>>>> The output to my serial console is attached.
>>>>
>>>> Cheers,
>>>> Francisco
>>> What is your Linux command line? does it include "console=hvc0"?
>>> Perhaps some early_printk settings are required.
>>>
>>> Please include my email in your replies, thank you.
>>>
>>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>>
>>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>>> root         (hd0,0)
>>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>>> module       /initrd-2.6.31.6.img
>>>
>>> Something like this, I am not at the machine anymore.
>>>
>>> Francisco
>>>
>> It looks like xsave/xrstore instructions (xsetbv instruction in
>> xstate_enable() function to be exact) related. You can try to disable
>> xsave to to see if this helps.
>>
>> -Wei
>>
>> Sorry about the untitled message.
>>
>> Should I be the one disabling xsave or is that for Andrew to change something?
>> How can I do that?
> Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
> should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
> line of grub entry and boot again. Something like this:
>
> kernel /boot/xen.gz blah blah xsave=0
> module blah blah
> blah
>
> Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
>
> Thank you for the help.
>
> Francisco
>
> -Wei
>
>> Anyway, shouldn't Xen support it?
>>
>> cheers,
>> Francisco
> The xsave=0 command line parameter solves the problem.
>
> Thank you,
> Francisco
>

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2012-04-05 20:43       ` Francisco Rocha
@ 2012-04-06 14:53         ` Francisco Rocha
  2012-04-06 14:51           ` Wei Huang
  0 siblings, 1 reply; 147+ messages in thread
From: Francisco Rocha @ 2012-04-06 14:53 UTC (permalink / raw)
  To: wei.huang2; +Cc: Andrew Cooper, xen-devel


________________________________________
From: Francisco Rocha
Sent: 05 April 2012 21:43
To: wei.huang2@amd.com
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: RE: [Xen-devel] (no subject)

________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 05 April 2012 21:27
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On 04/05/2012 03:17 PM, Francisco Rocha wrote:
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 20:36
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>> To:<xen-devel@lists.xen.org>
>> Subject: Re: [Xen-devel] lastest xen unstable crash
>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>> Content-Type: text/plain; charset="ISO-8859-1"
>>
>> On 05/04/12 18:37, Francisco Rocha wrote:
>>> Hi everyone,
>>>
>>> I was trying to build a new machine but the system keeps rebooting.
>>> I used the lasted unstable version from xen-unstable.hg.
>>>
>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>
>>> The output to my serial console is attached.
>>>
>>> Cheers,
>>> Francisco
>> What is your Linux command line? does it include "console=hvc0"?
>> Perhaps some early_printk settings are required.
>>
>> Please include my email in your replies, thank you.
>>
>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>
>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>> root         (hd0,0)
>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>> module       /initrd-2.6.31.6.img
>>
>> Something like this, I am not at the machine anymore.
>>
>> Francisco
>>
> It looks like xsave/xrstore instructions (xsetbv instruction in
> xstate_enable() function to be exact) related. You can try to disable
> xsave to to see if this helps.
>
> -Wei
>
> Sorry about the untitled message.
>
> Should I be the one disabling xsave or is that for Andrew to change something?
> How can I do that?
Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
line of grub entry and boot again. Something like this:

kernel /boot/xen.gz blah blah xsave=0
module blah blah
blah

Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.

Thank you for the help.

Francisco

-Wei

>
> Anyway, shouldn't Xen support it?
>
> cheers,
> Francisco

The xsave=0 command line parameter solves the problem.

Thank you,
Francisco

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2012-04-06 14:53         ` Francisco Rocha
@ 2012-04-06 14:51           ` Wei Huang
  2012-04-06 15:02             ` Francisco Rocha
  2012-04-06 15:14             ` Konrad Rzeszutek Wilk
  0 siblings, 2 replies; 147+ messages in thread
From: Wei Huang @ 2012-04-06 14:51 UTC (permalink / raw)
  To: Francisco Rocha; +Cc: Andrew Cooper, xen-devel

Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with 
xsave/xrstor.

-Wei

On 04/06/2012 09:53 AM, Francisco Rocha wrote:
> ________________________________________
> From: Francisco Rocha
> Sent: 05 April 2012 21:43
> To: wei.huang2@amd.com
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] (no subject)
>
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 21:27
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 03:17 PM, Francisco Rocha wrote:
>> ________________________________________
>> From: Wei Huang [wei.huang2@amd.com]
>> Sent: 05 April 2012 20:36
>> To: Francisco Rocha
>> Cc: Andrew Cooper; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] (no subject)
>>
>> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>>> To:<xen-devel@lists.xen.org>
>>> Subject: Re: [Xen-devel] lastest xen unstable crash
>>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>>> Content-Type: text/plain; charset="ISO-8859-1"
>>>
>>> On 05/04/12 18:37, Francisco Rocha wrote:
>>>> Hi everyone,
>>>>
>>>> I was trying to build a new machine but the system keeps rebooting.
>>>> I used the lasted unstable version from xen-unstable.hg.
>>>>
>>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>>
>>>> The output to my serial console is attached.
>>>>
>>>> Cheers,
>>>> Francisco
>>> What is your Linux command line? does it include "console=hvc0"?
>>> Perhaps some early_printk settings are required.
>>>
>>> Please include my email in your replies, thank you.
>>>
>>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>>
>>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>>> root         (hd0,0)
>>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>>> module       /initrd-2.6.31.6.img
>>>
>>> Something like this, I am not at the machine anymore.
>>>
>>> Francisco
>>>
>> It looks like xsave/xrstore instructions (xsetbv instruction in
>> xstate_enable() function to be exact) related. You can try to disable
>> xsave to to see if this helps.
>>
>> -Wei
>>
>> Sorry about the untitled message.
>>
>> Should I be the one disabling xsave or is that for Andrew to change something?
>> How can I do that?
> Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
> should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
> line of grub entry and boot again. Something like this:
>
> kernel /boot/xen.gz blah blah xsave=0
> module blah blah
> blah
>
> Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
>
> Thank you for the help.
>
> Francisco
>
> -Wei
>
>> Anyway, shouldn't Xen support it?
>>
>> cheers,
>> Francisco
> The xsave=0 command line parameter solves the problem.
>
> Thank you,
> Francisco
>

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2012-04-05 20:27     ` Wei Huang
@ 2012-04-05 20:43       ` Francisco Rocha
  2012-04-06 14:53         ` Francisco Rocha
  0 siblings, 1 reply; 147+ messages in thread
From: Francisco Rocha @ 2012-04-05 20:43 UTC (permalink / raw)
  To: wei.huang2; +Cc: Andrew Cooper, xen-devel


________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 05 April 2012 21:27
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On 04/05/2012 03:17 PM, Francisco Rocha wrote:
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 20:36
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>> To:<xen-devel@lists.xen.org>
>> Subject: Re: [Xen-devel] lastest xen unstable crash
>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>> Content-Type: text/plain; charset="ISO-8859-1"
>>
>> On 05/04/12 18:37, Francisco Rocha wrote:
>>> Hi everyone,
>>>
>>> I was trying to build a new machine but the system keeps rebooting.
>>> I used the lasted unstable version from xen-unstable.hg.
>>>
>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>
>>> The output to my serial console is attached.
>>>
>>> Cheers,
>>> Francisco
>> What is your Linux command line? does it include "console=hvc0"?
>> Perhaps some early_printk settings are required.
>>
>> Please include my email in your replies, thank you.
>>
>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>
>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>> root         (hd0,0)
>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>> module       /initrd-2.6.31.6.img
>>
>> Something like this, I am not at the machine anymore.
>>
>> Francisco
>>
> It looks like xsave/xrstore instructions (xsetbv instruction in
> xstate_enable() function to be exact) related. You can try to disable
> xsave to to see if this helps.
>
> -Wei
>
> Sorry about the untitled message.
>
> Should I be the one disabling xsave or is that for Andrew to change something?
> How can I do that?
Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
line of grub entry and boot again. Something like this:

kernel /boot/xen.gz blah blah xsave=0
module blah blah
blah

Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.

Thank you for the help.

Francisco

-Wei

>
> Anyway, shouldn't Xen support it?
>
> cheers,
> Francisco

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2012-04-05 20:17   ` Francisco Rocha
@ 2012-04-05 20:27     ` Wei Huang
  2012-04-05 20:43       ` Francisco Rocha
  0 siblings, 1 reply; 147+ messages in thread
From: Wei Huang @ 2012-04-05 20:27 UTC (permalink / raw)
  To: Francisco Rocha; +Cc: Andrew Cooper, xen-devel

On 04/05/2012 03:17 PM, Francisco Rocha wrote:
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 20:36
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>> To:<xen-devel@lists.xen.org>
>> Subject: Re: [Xen-devel] lastest xen unstable crash
>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>> Content-Type: text/plain; charset="ISO-8859-1"
>>
>> On 05/04/12 18:37, Francisco Rocha wrote:
>>> Hi everyone,
>>>
>>> I was trying to build a new machine but the system keeps rebooting.
>>> I used the lasted unstable version from xen-unstable.hg.
>>>
>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>
>>> The output to my serial console is attached.
>>>
>>> Cheers,
>>> Francisco
>> What is your Linux command line? does it include "console=hvc0"?
>> Perhaps some early_printk settings are required.
>>
>> Please include my email in your replies, thank you.
>>
>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>
>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>> root         (hd0,0)
>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>> module       /initrd-2.6.31.6.img
>>
>> Something like this, I am not at the machine anymore.
>>
>> Francisco
>>
> It looks like xsave/xrstore instructions (xsetbv instruction in
> xstate_enable() function to be exact) related. You can try to disable
> xsave to to see if this helps.
>
> -Wei
>
> Sorry about the untitled message.
>
> Should I be the one disabling xsave or is that for Andrew to change something?
> How can I do that?
Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which 
should support xsave/xrstor too. You can try to set xsave=0 in xen.gz 
line of grub entry and boot again. Something like this:

kernel /boot/xen.gz blah blah xsave=0
module blah blah
blah

-Wei

>
> Anyway, shouldn't Xen support it?
>
> cheers,
> Francisco

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2012-04-05 19:36 ` Wei Huang
@ 2012-04-05 20:17   ` Francisco Rocha
  2012-04-05 20:27     ` Wei Huang
  0 siblings, 1 reply; 147+ messages in thread
From: Francisco Rocha @ 2012-04-05 20:17 UTC (permalink / raw)
  To: wei.huang2; +Cc: Andrew Cooper, xen-devel


________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 05 April 2012 20:36
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On 04/05/2012 01:26 PM, Francisco Rocha wrote:
> Date: Thu, 5 Apr 2012 18:44:14 +0100
> From: Andrew Cooper<andrew.cooper3@citrix.com>
> To:<xen-devel@lists.xen.org>
> Subject: Re: [Xen-devel] lastest xen unstable crash
> Message-ID:<4F7DD9EE.3080404@citrix.com>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> On 05/04/12 18:37, Francisco Rocha wrote:
>> Hi everyone,
>>
>> I was trying to build a new machine but the system keeps rebooting.
>> I used the lasted unstable version from xen-unstable.hg.
>>
>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>
>> The output to my serial console is attached.
>>
>> Cheers,
>> Francisco
> What is your Linux command line? does it include "console=hvc0"?
> Perhaps some early_printk settings are required.
>
> Please include my email in your replies, thank you.
>
> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>
> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
> root         (hd0,0)
> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
> module       /initrd-2.6.31.6.img
>
> Something like this, I am not at the machine anymore.
>
> Francisco
>
It looks like xsave/xrstore instructions (xsetbv instruction in
xstate_enable() function to be exact) related. You can try to disable
xsave to to see if this helps.

-Wei

Sorry about the untitled message. 

Should I be the one disabling xsave or is that for Andrew to change something?
How can I do that?

Anyway, shouldn't Xen support it?

cheers,
Francisco

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2012-04-05 18:26 Francisco Rocha
@ 2012-04-05 19:36 ` Wei Huang
  2012-04-05 20:17   ` Francisco Rocha
  0 siblings, 1 reply; 147+ messages in thread
From: Wei Huang @ 2012-04-05 19:36 UTC (permalink / raw)
  To: Francisco Rocha; +Cc: Andrew Cooper, xen-devel

On 04/05/2012 01:26 PM, Francisco Rocha wrote:
> Date: Thu, 5 Apr 2012 18:44:14 +0100
> From: Andrew Cooper<andrew.cooper3@citrix.com>
> To:<xen-devel@lists.xen.org>
> Subject: Re: [Xen-devel] lastest xen unstable crash
> Message-ID:<4F7DD9EE.3080404@citrix.com>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> On 05/04/12 18:37, Francisco Rocha wrote:
>> Hi everyone,
>>
>> I was trying to build a new machine but the system keeps rebooting.
>> I used the lasted unstable version from xen-unstable.hg.
>>
>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>
>> The output to my serial console is attached.
>>
>> Cheers,
>> Francisco
> What is your Linux command line? does it include "console=hvc0"?
> Perhaps some early_printk settings are required.
>
> Please include my email in your replies, thank you.
>
> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>
> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
> root         (hd0,0)
> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
> module       /initrd-2.6.31.6.img
>
> Something like this, I am not at the machine anymore.
>
> Francisco
>
It looks like xsave/xrstore instructions (xsetbv instruction in 
xstate_enable() function to be exact) related. You can try to disable 
xsave to to see if this helps.

-Wei

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2012-04-05 18:26 Francisco Rocha
  2012-04-05 19:36 ` Wei Huang
  0 siblings, 1 reply; 147+ messages in thread
From: Francisco Rocha @ 2012-04-05 18:26 UTC (permalink / raw)
  To: Andrew Cooper; +Cc: xen-devel

Date: Thu, 5 Apr 2012 18:44:14 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] lastest xen unstable crash
Message-ID: <4F7DD9EE.3080404@citrix.com>
Content-Type: text/plain; charset="ISO-8859-1"

On 05/04/12 18:37, Francisco Rocha wrote:
> Hi everyone,
>
> I was trying to build a new machine but the system keeps rebooting.
> I used the lasted unstable version from xen-unstable.hg.
>
> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>
> The output to my serial console is attached.
>
> Cheers,
> Francisco

What is your Linux command line? does it include "console=hvc0"? 
Perhaps some early_printk settings are required.

Please include my email in your replies, thank you.

Yes, it includes hvc0. I used your tutorial to setup the SOL.

title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
root         (hd0,0)
kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
module       /initrd-2.6.31.6.img

Something like this, I am not at the machine anymore.

Francisco

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2012-02-24 18:54 Ian Jackson
  0 siblings, 0 replies; 147+ messages in thread
From: Ian Jackson @ 2012-02-24 18:54 UTC (permalink / raw)
  To: xen-devel

Once again, I have not executed the code in this series!

These three are intended to be bugfixes to sort out
the deadlock problem that Roger Pau Monne reported:
 01/15 libxl: ao: allow immediate completion
 02/15 libxl: fix hang due to libxl__initiate_device_remove

These are other bugfixes:
 03/15 libxl: Fix eventloop_iteration over-locking
 04/15 libxl: Fix leak of ctx->lock
 05/15 libxl: abolish libxl_ctx_postfork
 06/15 tools: Correct PTHREAD options in config/StdGNU.mk
 07/15 libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
 08/15 libxl: Crash (more sensibly) on malloc failure

These are handy new bits for internal libxl users:
 09/15 libxl: Make libxl__zalloc et al tolerate a NULL gc
 10/15 libxl: Introduce some convenience macros
 11/15 libxl: Protect fds with CLOEXEC even with forking threads
 12/15 libxl: libxl_event.c:beforepoll_internal, REQUIRE_FDS
 14/15 libxl: Provide libxl_string_list_length
 15/15 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds

This is the new child-handling machinery:
 13/15 libxl: event API: new facilities for waiting for subprocesses

There are not any users for much of this code in this series.  I have
a half-written rework of libxl_bootloader.c to make it event-driven,
but it's not suitable for review at this stage.  It doesn't even
compile.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2012-02-17 19:15 Ian Jackson
  0 siblings, 0 replies; 147+ messages in thread
From: Ian Jackson @ 2012-02-17 19:15 UTC (permalink / raw)
  To: xen-devel

>From Ian Jackson <ian.jackson@eu.citrix.com> # This line is ignored.
From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [RFC PATCH 0/6] libxl: New child process handling
In-Reply-To: 

This is the first draft of my new libxl API for child process
handling.

 1/6 libxl: Fix leak of ctx->lock
 2/6 libxl: abolish libxl_ctx_postfork
 3/6 tools: Correct PTHREAD options in config/StdGNU.mk
 4/6 libxl: Protect fds with CLOEXEC even with forking threads
 5/6 libxl: libxl_event.c:beforepoll_internal, REQUIRE_FDS
 6/6 libxl: event API: new facilities for waiting for subprocesses

Please comment.  I'm particularly keen on comments about:

 * The correctness of the pthread_atfork logic in 4/6.
 * The sufficiency for applications of the child handling API in 6/6.
 * The portability of the pthread command line option changes in 3/6.
 * Correctness :-).

If you want to apply it to make sense of, you'll need to know that
this series is on top of my recently-posted 3-patch libxl event fixup
series.

Thanks,
Ian.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2011-10-17 17:05 ` Konrad Rzeszutek Wilk
  2011-10-17 21:02   ` Ian Campbell
@ 2011-10-18  7:13   ` Paolo Bonzini
  1 sibling, 0 replies; 147+ messages in thread
From: Paolo Bonzini @ 2011-10-18  7:13 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk; +Cc: Ian Campbell, xen-devel

On 10/17/2011 07:05 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 17, 2011 at 09:40:49AM +0200, Paolo Bonzini wrote:
>
> Something went wrong with your patchbomb..
>
> anyhow, lets CC Ian here since he is the maintainer.

Already resent, and acked by Jan. :)

Paolo

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2011-10-17 17:05 ` Konrad Rzeszutek Wilk
@ 2011-10-17 21:02   ` Ian Campbell
  2011-10-18  7:13   ` Paolo Bonzini
  1 sibling, 0 replies; 147+ messages in thread
From: Ian Campbell @ 2011-10-17 21:02 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk; +Cc: Paolo Bonzini, xen-devel

On Mon, 2011-10-17 at 18:05 +0100, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 17, 2011 at 09:40:49AM +0200, Paolo Bonzini wrote:
> 
> Something went wrong with your patchbomb..
> 
> anyhow, lets CC Ian here since he is the maintainer.

This is a 2.6.18-xen patch. I'm not especially interested in that tree
-- Jan looks after it though and picked up this patch from the resend.

Ian.

> 
> > 
> > Writing [PATCH] netback: disable features not supported by netfront ...
> > ntent-Transfer-Encoding: 7bit
> > Subject: [PATCH] netback: disable features not supported by netfront
> > X-Mercurial-Node: eb896361fc70b60b9a257d0c82e19633a11b9d41
> > Message-Id: <eb896361fc70b60b9a25.1318837062@yakj.usersys.redhat.com>
> > User-Agent: Mercurial-patchbomb/1.9.1
> > Date: Mon, 17 Oct 2011 09:37:42 +0200
> > From: pbonzini@redhat.com
> > To: pbonzini@redhat.com
> > 
> > # HG changeset patch
> > # User Paolo Bonzini <pbonzini@redhat.com>
> > # Date 1318837036 -7200
> > # Node ID eb896361fc70b60b9a257d0c82e19633a11b9d41
> > # Parent  3c900d6a5f6a51ff1547f21fef30ab8b92feccc9
> > netback: disable features not supported by netfront
> > 
> > Netback works by first setting all possible features, and then
> > resetting some after connection, if the front-end didn't negotiate them.
> > Except that in the old 2.6.18 tree the "resetting" part was missing.
> > In the pvops tree, this should work correctly through the fix_features
> > mechanism.
> > 
> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> > 
> > diff --git a/drivers/xen/netback/interface.c b/drivers/xen/netback/interface.c
> > --- a/drivers/xen/netback/interface.c
> > +++ b/drivers/xen/netback/interface.c
> > @@ -98,8 +98,9 @@ static int netbk_change_mtu(struct net_d
> >  void netif_set_features(netif_t *netif)
> >  {
> >  	struct net_device *dev = netif->dev;
> > -	int features = dev->features;
> > +	int features;
> >  
> > +	features = dev->features & ~(NETIF_F_SG|NETIF_F_TSO|NETIF_F_IP_CSUM);
> >  	if (netif->can_sg)
> >  		features |= NETIF_F_SG;
> >  	if (netif->gso)
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2011-10-17  7:40 Paolo Bonzini
@ 2011-10-17 17:05 ` Konrad Rzeszutek Wilk
  2011-10-17 21:02   ` Ian Campbell
  2011-10-18  7:13   ` Paolo Bonzini
  0 siblings, 2 replies; 147+ messages in thread
From: Konrad Rzeszutek Wilk @ 2011-10-17 17:05 UTC (permalink / raw)
  To: Paolo Bonzini, Ian Campbell; +Cc: xen-devel

On Mon, Oct 17, 2011 at 09:40:49AM +0200, Paolo Bonzini wrote:

Something went wrong with your patchbomb..

anyhow, lets CC Ian here since he is the maintainer.

> 
> Writing [PATCH] netback: disable features not supported by netfront ...
> ntent-Transfer-Encoding: 7bit
> Subject: [PATCH] netback: disable features not supported by netfront
> X-Mercurial-Node: eb896361fc70b60b9a257d0c82e19633a11b9d41
> Message-Id: <eb896361fc70b60b9a25.1318837062@yakj.usersys.redhat.com>
> User-Agent: Mercurial-patchbomb/1.9.1
> Date: Mon, 17 Oct 2011 09:37:42 +0200
> From: pbonzini@redhat.com
> To: pbonzini@redhat.com
> 
> # HG changeset patch
> # User Paolo Bonzini <pbonzini@redhat.com>
> # Date 1318837036 -7200
> # Node ID eb896361fc70b60b9a257d0c82e19633a11b9d41
> # Parent  3c900d6a5f6a51ff1547f21fef30ab8b92feccc9
> netback: disable features not supported by netfront
> 
> Netback works by first setting all possible features, and then
> resetting some after connection, if the front-end didn't negotiate them.
> Except that in the old 2.6.18 tree the "resetting" part was missing.
> In the pvops tree, this should work correctly through the fix_features
> mechanism.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> 
> diff --git a/drivers/xen/netback/interface.c b/drivers/xen/netback/interface.c
> --- a/drivers/xen/netback/interface.c
> +++ b/drivers/xen/netback/interface.c
> @@ -98,8 +98,9 @@ static int netbk_change_mtu(struct net_d
>  void netif_set_features(netif_t *netif)
>  {
>  	struct net_device *dev = netif->dev;
> -	int features = dev->features;
> +	int features;
>  
> +	features = dev->features & ~(NETIF_F_SG|NETIF_F_TSO|NETIF_F_IP_CSUM);
>  	if (netif->can_sg)
>  		features |= NETIF_F_SG;
>  	if (netif->gso)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2011-10-17  7:40 Paolo Bonzini
  2011-10-17 17:05 ` Konrad Rzeszutek Wilk
  0 siblings, 1 reply; 147+ messages in thread
From: Paolo Bonzini @ 2011-10-17  7:40 UTC (permalink / raw)
  To: xen-devel


Writing [PATCH] netback: disable features not supported by netfront ...
ntent-Transfer-Encoding: 7bit
Subject: [PATCH] netback: disable features not supported by netfront
X-Mercurial-Node: eb896361fc70b60b9a257d0c82e19633a11b9d41
Message-Id: <eb896361fc70b60b9a25.1318837062@yakj.usersys.redhat.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Mon, 17 Oct 2011 09:37:42 +0200
From: pbonzini@redhat.com
To: pbonzini@redhat.com

# HG changeset patch
# User Paolo Bonzini <pbonzini@redhat.com>
# Date 1318837036 -7200
# Node ID eb896361fc70b60b9a257d0c82e19633a11b9d41
# Parent  3c900d6a5f6a51ff1547f21fef30ab8b92feccc9
netback: disable features not supported by netfront

Netback works by first setting all possible features, and then
resetting some after connection, if the front-end didn't negotiate them.
Except that in the old 2.6.18 tree the "resetting" part was missing.
In the pvops tree, this should work correctly through the fix_features
mechanism.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

diff --git a/drivers/xen/netback/interface.c b/drivers/xen/netback/interface.c
--- a/drivers/xen/netback/interface.c
+++ b/drivers/xen/netback/interface.c
@@ -98,8 +98,9 @@ static int netbk_change_mtu(struct net_d
 void netif_set_features(netif_t *netif)
 {
 	struct net_device *dev = netif->dev;
-	int features = dev->features;
+	int features;
 
+	features = dev->features & ~(NETIF_F_SG|NETIF_F_TSO|NETIF_F_IP_CSUM);
 	if (netif->can_sg)
 		features |= NETIF_F_SG;
 	if (netif->gso)

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2011-10-06 13:11 Pratik shinde
@ 2011-10-06 13:18 ` Andrew Cooper
  0 siblings, 0 replies; 147+ messages in thread
From: Andrew Cooper @ 2011-10-06 13:18 UTC (permalink / raw)
  To: xen-devel

On 06/10/11 14:11, Pratik shinde wrote:
> why coscheduling is not implemented in xen?

http://wiki.xen.org/xenwiki/AskingXenDevelQuestions

After reading that wiki page, please explain why you think coscheduling
should be implemented on Xen.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2011-10-06 13:11 Pratik shinde
  2011-10-06 13:18 ` Andrew Cooper
  0 siblings, 1 reply; 147+ messages in thread
From: Pratik shinde @ 2011-10-06 13:11 UTC (permalink / raw)
  To: Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 44 bytes --]

why coscheduling is not implemented in xen?

[-- Attachment #1.2: Type: text/html, Size: 48 bytes --]

[-- Attachment #2: 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] 147+ messages in thread

* (no subject)
@ 2011-07-27  8:33 Grant McWilliams
  0 siblings, 0 replies; 147+ messages in thread
From: Grant McWilliams @ 2011-07-27  8:33 UTC (permalink / raw)
  To: afb, linux-poweredge, david.lane, support, BronsonLK, xen-devel,
	arnaud.sumien, LarsonK

http://succeedonpurpose.com/google.php

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2011-06-21  3:39 Attila Jecs
@ 2011-06-21 13:20 ` Konrad Rzeszutek Wilk
  0 siblings, 0 replies; 147+ messages in thread
From: Konrad Rzeszutek Wilk @ 2011-06-21 13:20 UTC (permalink / raw)
  To: Attila Jecs; +Cc: xen-devel

On Tue, Jun 21, 2011 at 05:39:46AM +0200, Attila Jecs wrote:
> Hi!
> 
> well, i got this when booting to gentoo/x64 xen/4.1 kernel/3.0rc3

Thank you.

That is a benign error. Does it continue booting?
> 
> Jun 21 05:18:02 szerver kernel: Initializing cgroup subsys perf_event
> Jun 21 05:18:02 szerver kernel: tseg: 00cfe00000
> Jun 21 05:18:02 szerver kernel: CPU: Physical Processor ID: 0
> Jun 21 05:18:02 szerver kernel: CPU: Processor Core ID: 0
> Jun 21 05:18:02 szerver kernel: ACPI: Core revision 20110413
> Jun 21 05:18:02 szerver kernel: cpu 0 spinlock event irq 273
> Jun 21 05:18:02 szerver kernel: Performance Events: AMD PMU driver.
> Jun 21 05:18:02 szerver kernel: ------------[ cut here ]------------
> Jun 21 05:18:02 szerver kernel: WARNING: at arch/x86/xen/enlighten.c:714
> 0xffffffff815cd65f()
> Jun 21 05:18:02 szerver kernel: Hardware name: GA-890FXA-UD5
> Jun 21 05:18:02 szerver kernel: Modules linked in:
> Jun 21 05:18:02 szerver kernel: Pid: 1, comm: swapper Not tainted 3.0.0-rc3
> #8
> Jun 21 05:18:02 szerver kernel: Call Trace:
> Jun 21 05:18:02 szerver kernel: [<ffffffff8104e3db>] ? 0xffffffff8104e3db
> Jun 21 05:18:02 szerver kernel: [<ffffffff815cd65f>] ? 0xffffffff815cd65f
> Jun 21 05:18:02 szerver kernel: [<ffffffff815cd1cd>] ? 0xffffffff815cd1cd
> Jun 21 05:18:02 szerver kernel: [<ffffffff8100214a>] ? 0xffffffff8100214a
> Jun 21 05:18:02 szerver kernel: [<ffffffff815c4c07>] ? 0xffffffff815c4c07
> Jun 21 05:18:02 szerver kernel: [<ffffffff81463d64>] ? 0xffffffff81463d64
> Jun 21 05:18:02 szerver kernel: [<ffffffff81463176>] ? 0xffffffff81463176
> Jun 21 05:18:02 szerver kernel: [<ffffffff814628e1>] ? 0xffffffff814628e1
> Jun 21 05:18:02 szerver kernel: [<ffffffff81463d60>] ? 0xffffffff81463d60
> Jun 21 05:18:02 szerver kernel: ---[ end trace 4eaa2a86a8e2da22 ]---
> Jun 21 05:18:02 szerver kernel: ... version:                0
> Jun 21 05:18:02 szerver kernel: ... bit width:              48
> Jun 21 05:18:02 szerver kernel: ... generic registers:      4
> Jun 21 05:18:02 szerver kernel: ... value mask:             0000ffffffffffff
> Jun 21 05:18:02 szerver kernel: ... max period:             00007fffffffffff
> Jun 21 05:18:02 szerver kernel: ... fixed-purpose events:   0
> Jun 21 05:18:02 szerver kernel: ... event mask:             000000000000000f
> Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 1
> Jun 21 05:18:02 szerver kernel: cpu 1 spinlock event irq 279
> Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 2
> Jun 21 05:18:02 szerver kernel: cpu 2 spinlock event irq 285
> Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 3
> Jun 21 05:18:02 szerver kernel: cpu 3 spinlock event irq 291
> Jun 21 05:18:02 szerver kernel: Brought up 4 CPUs
> Jun 21 05:18:02 szerver kernel: devtmpfs: initialized
> 
> maybe it helps.
> if u need more info, just tell me
> -- 
> Attila Jecs

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2011-06-21  3:39 Attila Jecs
  2011-06-21 13:20 ` Konrad Rzeszutek Wilk
  0 siblings, 1 reply; 147+ messages in thread
From: Attila Jecs @ 2011-06-21  3:39 UTC (permalink / raw)
  To: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 2657 bytes --]

Hi!

well, i got this when booting to gentoo/x64 xen/4.1 kernel/3.0rc3

Jun 21 05:18:02 szerver kernel: Initializing cgroup subsys perf_event
Jun 21 05:18:02 szerver kernel: tseg: 00cfe00000
Jun 21 05:18:02 szerver kernel: CPU: Physical Processor ID: 0
Jun 21 05:18:02 szerver kernel: CPU: Processor Core ID: 0
Jun 21 05:18:02 szerver kernel: ACPI: Core revision 20110413
Jun 21 05:18:02 szerver kernel: cpu 0 spinlock event irq 273
Jun 21 05:18:02 szerver kernel: Performance Events: AMD PMU driver.
Jun 21 05:18:02 szerver kernel: ------------[ cut here ]------------
Jun 21 05:18:02 szerver kernel: WARNING: at arch/x86/xen/enlighten.c:714
0xffffffff815cd65f()
Jun 21 05:18:02 szerver kernel: Hardware name: GA-890FXA-UD5
Jun 21 05:18:02 szerver kernel: Modules linked in:
Jun 21 05:18:02 szerver kernel: Pid: 1, comm: swapper Not tainted 3.0.0-rc3
#8
Jun 21 05:18:02 szerver kernel: Call Trace:
Jun 21 05:18:02 szerver kernel: [<ffffffff8104e3db>] ? 0xffffffff8104e3db
Jun 21 05:18:02 szerver kernel: [<ffffffff815cd65f>] ? 0xffffffff815cd65f
Jun 21 05:18:02 szerver kernel: [<ffffffff815cd1cd>] ? 0xffffffff815cd1cd
Jun 21 05:18:02 szerver kernel: [<ffffffff8100214a>] ? 0xffffffff8100214a
Jun 21 05:18:02 szerver kernel: [<ffffffff815c4c07>] ? 0xffffffff815c4c07
Jun 21 05:18:02 szerver kernel: [<ffffffff81463d64>] ? 0xffffffff81463d64
Jun 21 05:18:02 szerver kernel: [<ffffffff81463176>] ? 0xffffffff81463176
Jun 21 05:18:02 szerver kernel: [<ffffffff814628e1>] ? 0xffffffff814628e1
Jun 21 05:18:02 szerver kernel: [<ffffffff81463d60>] ? 0xffffffff81463d60
Jun 21 05:18:02 szerver kernel: ---[ end trace 4eaa2a86a8e2da22 ]---
Jun 21 05:18:02 szerver kernel: ... version:                0
Jun 21 05:18:02 szerver kernel: ... bit width:              48
Jun 21 05:18:02 szerver kernel: ... generic registers:      4
Jun 21 05:18:02 szerver kernel: ... value mask:             0000ffffffffffff
Jun 21 05:18:02 szerver kernel: ... max period:             00007fffffffffff
Jun 21 05:18:02 szerver kernel: ... fixed-purpose events:   0
Jun 21 05:18:02 szerver kernel: ... event mask:             000000000000000f
Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 1
Jun 21 05:18:02 szerver kernel: cpu 1 spinlock event irq 279
Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 2
Jun 21 05:18:02 szerver kernel: cpu 2 spinlock event irq 285
Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 3
Jun 21 05:18:02 szerver kernel: cpu 3 spinlock event irq 291
Jun 21 05:18:02 szerver kernel: Brought up 4 CPUs
Jun 21 05:18:02 szerver kernel: devtmpfs: initialized

maybe it helps.
if u need more info, just tell me
-- 
Attila Jecs

[-- Attachment #1.2: Type: text/html, Size: 3237 bytes --]

[-- Attachment #2: 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] 147+ messages in thread

* (no subject)
@ 2011-04-04  6:18 Novik, Alex
  0 siblings, 0 replies; 147+ messages in thread
From: Novik, Alex @ 2011-04-04  6:18 UTC (permalink / raw)
  To: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 503 bytes --]

Hi, all.
 How do I activate the battery management in pass-through mode?  XEN 4.1, platform Lenovo.
 Thanks in advance,
 Alex Novik.
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[-- Attachment #1.2: Type: text/html, Size: 2312 bytes --]

[-- Attachment #2: 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] 147+ messages in thread

* (no subject)
@ 2011-03-20 22:27 Keshav Darak
  0 siblings, 0 replies; 147+ messages in thread
From: Keshav Darak @ 2011-03-20 22:27 UTC (permalink / raw)
  To: xen-devel; +Cc: jeremy, keir


[-- Attachment #1.1: Type: text/plain, Size: 1585 bytes --]

We have implemented hugepage support for guests in following manner

In
 our implementation we added a parameter hugepage_num which is specified
 in the config file of the DomU. It is the number of hugepages that the 
guest is guaranteed to receive whenever the kernel asks for hugepage by 
using its boot time parameter or reserving after booting (eg. Using echo
 XX > /proc/sys/vm/nr_hugepages). During creation of the domain we 
reserve MFN's for these hugepages and store them in the list. The 
listhead of this list is inside the domain structure with name 
"hugepage_list". When the domain is booting, at that time the memory 
seen by the kernel is allocated memory  less the amount required for hugepages. The function 
reserve_hugepage_range is called as a initcall. Before this function the
 xen_extra_mem_start points to this apparent end of the memory. In this 
function we reserve the PFN range for the hugepages which are going to 
be allocated by kernel by incrementing the xen_extra_mem_start. We 
maintain these PFNs as pages in "xen_hugepfn_list" in the kernel. 

Now before the kernel requests for hugepages, it makes a hypercall HYPERVISOR_memory_op  to get count of hugepages allocated to it and accordingly reserves the pfn range.
then whenever kernel requests for hugepages it again make hypercall HYPERVISOR_memory_op to get the preallocated hugepage and according makes the p2m mapping on both sides (xen as well as kernel side)

The approach can be better explained using the presentation attached.

--
Keshav Darak

 




      

[-- Attachment #1.2: Type: text/html, Size: 1742 bytes --]

[-- Attachment #2: xen_patch_210311_0227.patch --]
[-- Type: application/x-download, Size: 18234 bytes --]

[-- Attachment #3: jeremy-kernel.patch --]
[-- Type: application/x-download, Size: 6731 bytes --]

[-- Attachment #4: our_hugepage_approach.ppt --]
[-- Type: application/vnd.ms-powerpoint, Size: 327168 bytes --]

[-- Attachment #5: 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] 147+ messages in thread

* (no subject)
@ 2010-11-16 11:12 Ken Ash
  0 siblings, 0 replies; 147+ messages in thread
From: Ken Ash @ 2010-11-16 11:12 UTC (permalink / raw)
  To: xen-devel

 h

Sent from my iPhone

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2010-10-07 14:21     ` Ian Campbell
@ 2010-10-07 16:54       ` George Shuklin
  0 siblings, 0 replies; 147+ messages in thread
From: George Shuklin @ 2010-10-07 16:54 UTC (permalink / raw)
  To: xen-devel

В Чтв, 07/10/2010 в 15:21 +0100, Ian Campbell пишет:
> On Thu, 2010-10-07 at 14:43 +0100, George Shuklin wrote:
> > Please note this bug:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595711
> > 
> > This behavior confirmed in lenny and squeeze. Kernel is very unstable
> > (compare to centos/suse) and cause OOM killer without any rational
> > reason.
> 
> I wasn't aware that this issue was present on Squeeze as well as Lenny,
> there is no mention of that in the bug.
> 
> The two kernels have practically nothing in common wrt the Xen port
> (Lenny was classic-Xen patch based and Squeeze is pvops based) so if you
> are seeing something similar under Squeeze as well please file a
> separate bug report.

OK, I'll recheck bug in squeeze and report it separately.

Main problem for this bug is very high value of free memory when OOM
killer starts. In my tests it appear when about 300MiB was free. And it
kill not most 'badness' process, but runs repeatedly for few (or even
all) process. 

But, again, I'll recheck it in clean environment with reproducible
behavior and submit it.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2010-10-07 13:43   ` George Shuklin
@ 2010-10-07 14:21     ` Ian Campbell
  2010-10-07 16:54       ` George Shuklin
  0 siblings, 1 reply; 147+ messages in thread
From: Ian Campbell @ 2010-10-07 14:21 UTC (permalink / raw)
  To: George Shuklin; +Cc: xen-devel

On Thu, 2010-10-07 at 14:43 +0100, George Shuklin wrote:
> Please note this bug:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595711
> 
> This behavior confirmed in lenny and squeeze. Kernel is very unstable
> (compare to centos/suse) and cause OOM killer without any rational
> reason.

I wasn't aware that this issue was present on Squeeze as well as Lenny,
there is no mention of that in the bug.

The two kernels have practically nothing in common wrt the Xen port
(Lenny was classic-Xen patch based and Squeeze is pvops based) so if you
are seeing something similar under Squeeze as well please file a
separate bug report.

(Note that only the OS in the specific VM which is exhibiting the
problem is relevant, so even if you are seeing the issue with a Lenny VM
hosted on a Squeeze dom0 that does not imply the bug is present in
Squeeze).

I'm afraid that at this point I do not have cycles to spend on the Lenny
issue. Unfortunately my best recommendation is not to balloon such
systems too aggressively or to use a more recent kernel (e.g. a backport
of the Squeeze kernel).

Ian.

-- 
Ian Campbell
Current Noise: Twisted Sister - Tear It Loose

Other restrictions may apply.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2010-10-07  2:46 Mike Viau
  2010-10-07 10:43 ` Stefano Stabellini
@ 2010-10-07 14:02 ` Ian Campbell
  1 sibling, 0 replies; 147+ messages in thread
From: Ian Campbell @ 2010-10-07 14:02 UTC (permalink / raw)
  To: Mike Viau; +Cc: xen-devel

On Thu, 2010-10-07 at 03:46 +0100, Mike Viau wrote:
> I have search the archives for reference to Ian Campbell's Debian
> binaries found at: http://xenbits.xen.org/people/ianc/

> http://lists.xensource.com/archives/cgi-bin/namazu.cgi?query=http%3A%
> 2F%2Fxenbits.xen.org%2Fpeople%2Fianc%2F&submit=Search!
> &idxname=xen-devel&max=20&result=normal&sort=score

They were posted on my personal website
http://www.hellion.org.uk/debian/test/
and referred to by
http://lists.xensource.com/archives/html/xen-devel/2010-08/msg01912.html
but I moved them to xen.org and just left a pointer on my website, I
didn't bother to announce this.

> I am wondering if the http://xenbits.xen.org/people/ianc/squeeze/ or
> http://xenbits.xen.org/people/ianc/sid/ HTTP folders can in some way
> be added to Debian's apt sources file?

I'm afraid the necessary meta data is not present to allow them to be
used as an apt source so they are download+dpkg only.

Originally they were intended to simply verify that the issues people
were seeing related to changesets which had been excluded from the
Debian kernel.

I haven't decided if these are something I necessarily want to maintain
for the lifetime of Squeeze. For the moment I build them for my own
personal use and so I publish them, since I might as well do so, but
they are not a formal xen.org service or anything like that.

For something provided by xen.org I think we would more likely want to
track the latest xen.git#xen/stable-2.6.x.y branch rather than the
Debian packages.

Ian.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2010-10-07 10:43 ` Stefano Stabellini
@ 2010-10-07 13:43   ` George Shuklin
  2010-10-07 14:21     ` Ian Campbell
  0 siblings, 1 reply; 147+ messages in thread
From: George Shuklin @ 2010-10-07 13:43 UTC (permalink / raw)
  Cc: xen-devel

Please note this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595711

This behavior confirmed in lenny and squeeze. Kernel is very unstable
(compare to centos/suse) and cause OOM killer without any rational
reason.


В Чтв, 07/10/2010 в 11:43 +0100, Stefano Stabellini пишет:
> On Thu, 7 Oct 2010, Mike Viau wrote:
> > 
> > I have search the archives for reference to Ian Campbell's Debian binaries found at: http://xenbits.xen.org/people/ianc/
> > 
> > http://lists.xensource.com/archives/cgi-bin/namazu.cgi?query=http%3A%2F%2Fxenbits.xen.org%2Fpeople%2Fianc%2F&submit=Search!&idxname=xen-devel&max=20&result=normal&sort=score
> > 
> > I am wondering if the http://xenbits.xen.org/people/ianc/squeeze/ or http://xenbits.xen.org/people/ianc/sid/ HTTP folders can in some way be added to Debian's apt sources file?
> > 
> 
> We intend to publish debian and centos packages for the xen hypervisor
> and tools, however the project is stalling a bit recently.
> Hopefully those packages will be published in the next few weeks.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2010-10-07  2:46 Mike Viau
@ 2010-10-07 10:43 ` Stefano Stabellini
  2010-10-07 13:43   ` George Shuklin
  2010-10-07 14:02 ` Ian Campbell
  1 sibling, 1 reply; 147+ messages in thread
From: Stefano Stabellini @ 2010-10-07 10:43 UTC (permalink / raw)
  To: Mike Viau; +Cc: xen-devel

On Thu, 7 Oct 2010, Mike Viau wrote:
> 
> I have search the archives for reference to Ian Campbell's Debian binaries found at: http://xenbits.xen.org/people/ianc/
> 
> http://lists.xensource.com/archives/cgi-bin/namazu.cgi?query=http%3A%2F%2Fxenbits.xen.org%2Fpeople%2Fianc%2F&submit=Search!&idxname=xen-devel&max=20&result=normal&sort=score
> 
> I am wondering if the http://xenbits.xen.org/people/ianc/squeeze/ or http://xenbits.xen.org/people/ianc/sid/ HTTP folders can in some way be added to Debian's apt sources file?
> 

We intend to publish debian and centos packages for the xen hypervisor
and tools, however the project is stalling a bit recently.
Hopefully those packages will be published in the next few weeks.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2010-10-07  2:46 Mike Viau
  2010-10-07 10:43 ` Stefano Stabellini
  2010-10-07 14:02 ` Ian Campbell
  0 siblings, 2 replies; 147+ messages in thread
From: Mike Viau @ 2010-10-07  2:46 UTC (permalink / raw)
  To: xen-devel


I have search the archives for reference to Ian Campbell's Debian binaries found at: http://xenbits.xen.org/people/ianc/


http://lists.xensource.com/archives/cgi-bin/namazu.cgi?query=http%3A%2F%2Fxenbits.xen.org%2Fpeople%2Fianc%2F&submit=Search!&idxname=xen-devel&max=20&result=normal&sort=score


I am wondering if the http://xenbits.xen.org/people/ianc/squeeze/ or http://xenbits.xen.org/people/ianc/sid/ HTTP folders can in some way be added to Debian's apt sources file?


Thanks.



-Mike Viau


 		 	   		  

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2010-04-16 10:59 Jiang, Yunhong
  0 siblings, 0 replies; 147+ messages in thread
From: Jiang, Yunhong @ 2010-04-16 10:59 UTC (permalink / raw)
  To: Keir Fraser, Christoph Egger, Frank.Vanderlinden@Sun.COM
  Cc: xen-devel, Ke, Liping

[-- Attachment #1: Type: text/plain, Size: 10984 bytes --]

Add a x86_mcinfo_reserve() function, to reserve space from mc_info.

With this method, we don't need to collect bank and globalinformation to a
local variable and do x86_mcinfo_add() to copy that information to mc_info.
This avoid copy and also we can be aware earlier if there is enough space
in the mc_info.

Also extract function that get global/bank information to seperated
function mca_init_bank/mca_init_global.

It's meaningless to get the current information in mce context, keep it here
but should be removed in future.

Also a flag added to mc_info, to indicate some information is lost due to OOM.

Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>

diff -r 4e1d1e56e8b9 -r 63632454170a xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Fri Apr 16 18:51:58 2010 +0800
@@ -125,6 +125,88 @@ void mce_need_clearbank_register(mce_nee
     mc_need_clearbank_scan = cbfunc;
 }
 
+static struct mcinfo_bank *mca_init_bank(enum mca_source who,
+                                         struct mc_info *mi, int bank)
+{
+	struct mcinfo_bank *mib;
+	uint64_t addr=0, misc = 0;
+
+	if (!mi)
+		return NULL;
+
+	mib = x86_mcinfo_reserve(mi, sizeof(struct mcinfo_bank));
+	if (!mib)
+	{
+		mi->flags |= MCINFO_FLAGS_UNCOMPLETE;
+		return NULL;
+	}
+
+	memset(mib, 0, sizeof (struct mcinfo_bank));
+	mca_rdmsrl(MSR_IA32_MC0_STATUS + bank * 4, mib->mc_status);
+
+	mib->common.type = MC_TYPE_BANK;
+	mib->common.size = sizeof (struct mcinfo_bank);
+	mib->mc_bank = bank;
+
+	addr = misc = 0;
+	if (mib->mc_status & MCi_STATUS_MISCV)
+		mca_rdmsrl(MSR_IA32_MC0_MISC + 4 * bank, mib->mc_misc);
+
+	if (mib->mc_status & MCi_STATUS_ADDRV)
+	{
+		mca_rdmsrl(MSR_IA32_MC0_ADDR + 4 * bank, mib->mc_addr);
+
+		if (mfn_valid(paddr_to_pfn(mib->mc_addr))) {
+			struct domain *d;
+
+			d = maddr_get_owner(mib->mc_addr);
+			if (d != NULL && (who == MCA_POLLER ||
+				  who == MCA_CMCI_HANDLER))
+				mib->mc_domid = d->domain_id;
+		}
+	}
+
+	if (who == MCA_CMCI_HANDLER) {
+		mca_rdmsrl(MSR_IA32_MC0_CTL2 + bank, mib->mc_ctrl2);
+		rdtscll(mib->mc_tsc);
+	}
+
+	return mib;
+}
+
+static int mca_init_global(uint32_t flags, struct mcinfo_global *mig)
+{
+	uint64_t status;
+	int cpu_nr;
+	struct vcpu *v = current;
+	struct domain *d;
+
+	/* Set global information */
+	memset(mig, 0, sizeof (struct mcinfo_global));
+	mig->common.type = MC_TYPE_GLOBAL;
+	mig->common.size = sizeof (struct mcinfo_global);
+	mca_rdmsrl(MSR_IA32_MCG_STATUS, status);
+	mig->mc_gstatus = status;
+	mig->mc_domid = mig->mc_vcpuid = -1;
+	mig->mc_flags = flags;
+	cpu_nr = smp_processor_id();
+	/* Retrieve detector information */
+	x86_mc_get_cpu_info(cpu_nr, &mig->mc_socketid,
+	  &mig->mc_coreid, &mig->mc_core_threadid,
+	  &mig->mc_apicid, NULL, NULL, NULL);
+
+	/* This is really meaningless */
+	if (v != NULL && ((d = v->domain) != NULL)) {
+		mig->mc_domid = d->domain_id;
+		mig->mc_vcpuid = v->vcpu_id;
+	} else {
+		mig->mc_domid = -1;
+		mig->mc_vcpuid = -1;
+	}
+
+	return 0;
+}
+
 /* Utility function to perform MCA bank telemetry readout and to push that
  * telemetry towards an interested dom0 for logging and diagnosis.
  * The caller - #MC handler or MCA poll function - must arrange that we
@@ -139,64 +221,38 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 mctelem_cookie_t mcheck_mca_logout(enum mca_source who, cpu_banks_t bankmask,
     struct mca_summary *sp, cpu_banks_t* clear_bank)
 {
-	struct vcpu *v = current;
-	struct domain *d;
-	uint64_t gstatus, status, addr, misc;
-	struct mcinfo_global mcg;	/* on stack */
-	struct mcinfo_common *mic;
-	struct mcinfo_global *mig;	/* on stack */
+	uint64_t gstatus, status;
+	struct mcinfo_global *mig = NULL;	/* on stack */
 	mctelem_cookie_t mctc = NULL;
-	uint32_t uc = 0, pcc = 0, recover, need_clear = 1 ;
+	uint32_t uc = 0, pcc = 0, recover, need_clear = 1, mc_flags = 0;
 	struct mc_info *mci = NULL;
 	mctelem_class_t which = MC_URGENT;	/* XXXgcc */
-	unsigned int cpu_nr;
 	int errcnt = 0;
 	int i;
 	enum mca_extinfo cbret = MCA_EXTINFO_IGNORED;
 
-	cpu_nr = smp_processor_id();
-	BUG_ON(cpu_nr != v->processor);
-
 	mca_rdmsrl(MSR_IA32_MCG_STATUS, gstatus);
-
-	memset(&mcg, 0, sizeof (mcg));
-	mcg.common.type = MC_TYPE_GLOBAL;
-	mcg.common.size = sizeof (mcg);
-	if (v != NULL && ((d = v->domain) != NULL)) {
-		mcg.mc_domid = d->domain_id;
-		mcg.mc_vcpuid = v->vcpu_id;
-	} else {
-		mcg.mc_domid = -1;
-		mcg.mc_vcpuid = -1;
-	}
-	mcg.mc_gstatus = gstatus;	/* MCG_STATUS */
-
 	switch (who) {
 	case MCA_MCE_HANDLER:
 	case MCA_MCE_SCAN:
-		mcg.mc_flags = MC_FLAG_MCE;
+		mc_flags = MC_FLAG_MCE;
 		which = MC_URGENT;
 		break;
 
 	case MCA_POLLER:
 	case MCA_RESET:
-		mcg.mc_flags = MC_FLAG_POLLED;
+		mc_flags = MC_FLAG_POLLED;
 		which = MC_NONURGENT;
 		break;
 
 	case MCA_CMCI_HANDLER:
-		mcg.mc_flags = MC_FLAG_CMCI;
+		mc_flags = MC_FLAG_CMCI;
 		which = MC_NONURGENT;
 		break;
 
 	default:
 		BUG();
 	}
-
-	/* Retrieve detector information */
-	x86_mc_get_cpu_info(cpu_nr, &mcg.mc_socketid,
-	    &mcg.mc_coreid, &mcg.mc_core_threadid,
-	    &mcg.mc_apicid, NULL, NULL, NULL);
 
 	/* If no mc_recovery_scan callback handler registered,
 	 * this error is not recoverable
@@ -204,7 +260,7 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 	recover = (mc_recoverable_scan)? 1: 0;
 
 	for (i = 0; i < 32 && i < nr_mce_banks; i++) {
-		struct mcinfo_bank mcb;		/* on stack */
+		struct mcinfo_bank *mib;		/* on stack */
 
 		/* Skip bank if corresponding bit in bankmask is clear */
 		if (!test_bit(i, bankmask))
@@ -227,17 +283,16 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 		 * a poller;  this can fail (for example dom0 may not
 		 * yet have consumed past telemetry). */
 		if (errcnt == 0) {
-			if ((mctc = mctelem_reserve(which)) != NULL) {
+			if ( (mctc = mctelem_reserve(which)) != NULL ) {
 				mci = mctelem_dataptr(mctc);
 				mcinfo_clear(mci);
+				mig = (struct mcinfo_global*)x86_mcinfo_reserve
+				  (mci, sizeof(struct mcinfo_global));
+				/* mc_info should at least hold up the global information */
+				ASSERT(mig);
+				mca_init_global(mc_flags, mig);
 			}
 		}
-
-		memset(&mcb, 0, sizeof (mcb));
-		mcb.common.type = MC_TYPE_BANK;
-		mcb.common.size = sizeof (mcb);
-		mcb.mc_bank = i;
-		mcb.mc_status = status;
 
 		/* form a mask of which banks have logged uncorrected errors */
 		if ((status & MCi_STATUS_UC) != 0)
@@ -252,37 +307,7 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 		  */
 			recover = mc_recoverable_scan(status);
 
-		addr = misc = 0;
-
-		if (status & MCi_STATUS_ADDRV) {
-			mca_rdmsrl(MSR_IA32_MC0_ADDR + 4 * i, addr);
-			if (mfn_valid(paddr_to_pfn(addr))) {
-				d = maddr_get_owner(addr);
-				if (d != NULL && (who == MCA_POLLER ||
-				    who == MCA_CMCI_HANDLER))
-					mcb.mc_domid = d->domain_id;
-			}
-		}
-
-		if (status & MCi_STATUS_MISCV)
-			mca_rdmsrl(MSR_IA32_MC0_MISC + 4 * i, misc);
-
-		mcb.mc_addr = addr;
-		mcb.mc_misc = misc;
-
-		if (who == MCA_CMCI_HANDLER) {
-			mca_rdmsrl(MSR_IA32_MC0_CTL2 + i, mcb.mc_ctrl2);
-			rdtscll(mcb.mc_tsc);
-		}
-
-		/* Increment the error count;  if this is the first bank
-		 * with a valid error then add the global info to the mcinfo. */
-		if (errcnt++ == 0 && mci != NULL)
-			x86_mcinfo_add(mci, &mcg);
-
-		/* Add the bank data */
-		if (mci != NULL)
-			x86_mcinfo_add(mci, &mcb);
+		mib = mca_init_bank(who, mci, i);
 
 		if (mc_callback_bank_extended && cbret != MCA_EXTINFO_GLOBAL) {
 			cbret = mc_callback_bank_extended(mci, i, status);
@@ -298,12 +323,8 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 		wmb();
 	}
 
-	if (mci != NULL && errcnt > 0) {
-		x86_mcinfo_lookup(mic, mci, MC_TYPE_GLOBAL);
-		mig = container_of(mic, struct mcinfo_global, common);
-		if (mic == NULL)
-			;
-		else if (pcc)
+	if (mig && errcnt > 0) {
+		if (pcc)
 			mig->mc_flags |= MC_FLAG_UNCORRECTABLE;
 		else if (uc)
 			mig->mc_flags |= MC_FLAG_RECOVERABLE;
@@ -758,13 +779,12 @@ static void mcinfo_clear(struct mc_info 
 	x86_mcinfo_nentries(mi) = 0;
 }
 
-int x86_mcinfo_add(struct mc_info *mi, void *mcinfo)
+void *x86_mcinfo_reserve(struct mc_info *mi, int size)
 {
 	int i;
 	unsigned long end1, end2;
-	struct mcinfo_common *mic, *mic_base, *mic_index;
-
-	mic = (struct mcinfo_common *)mcinfo;
+	struct mcinfo_common *mic_base, *mic_index;
+
 	mic_index = mic_base = x86_mcinfo_first(mi);
 
 	/* go to first free entry */
@@ -774,16 +794,35 @@ int x86_mcinfo_add(struct mc_info *mi, v
 
 	/* check if there is enough size */
 	end1 = (unsigned long)((uint8_t *)mic_base + sizeof(struct mc_info));
-	end2 = (unsigned long)((uint8_t *)mic_index + mic->size);
+	end2 = (unsigned long)((uint8_t *)mic_index + size);
 
 	if (end1 < end2)
-		return x86_mcerr("mcinfo_add: no more sparc", -ENOSPC);
+	{
+		mce_printk(MCE_CRITICAL,
+			"mcinfo_add: No space left in mc_info\n");
+		return NULL;
+	}
 
 	/* there's enough space. add entry. */
-	memcpy(mic_index, mic, mic->size);
 	x86_mcinfo_nentries(mi)++;
 
-	return 0;
+    return mic_index;
+}
+
+void *x86_mcinfo_add(struct mc_info *mi, void *mcinfo)
+{
+	struct mcinfo_common *mic, *buf;
+
+	mic = (struct mcinfo_common *)mcinfo;
+	buf = x86_mcinfo_reserve(mi, mic->size);
+
+	if ( !buf )
+		mce_printk(MCE_CRITICAL,
+			"mcinfo_add: No space left in mc_info\n");
+	else
+		memcpy(buf, mic, mic->size);
+
+	return buf;
 }
 
 /* Dump machine check information in a format,
diff -r 4e1d1e56e8b9 -r 63632454170a xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Fri Apr 16 18:51:58 2010 +0800
@@ -161,7 +161,8 @@ typedef enum mca_extinfo (*x86_mce_callb
     (struct mc_info *, uint16_t, uint64_t);
 extern void x86_mce_callback_register(x86_mce_callback_t);
 
-int x86_mcinfo_add(struct mc_info *mi, void *mcinfo);
+void *x86_mcinfo_add(struct mc_info *mi, void *mcinfo);
+void *x86_mcinfo_reserve(struct mc_info *mi, int size);
 void x86_mcinfo_dump(struct mc_info *mi);
 
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
diff -r 4e1d1e56e8b9 -r 63632454170a xen/include/public/arch-x86/xen-mca.h
--- a/xen/include/public/arch-x86/xen-mca.h	Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/include/public/arch-x86/xen-mca.h	Fri Apr 16 18:51:58 2010 +0800
@@ -233,10 +233,11 @@ struct mcinfo_recovery
 #define MCINFO_HYPERCALLSIZE	1024
 #define MCINFO_MAXSIZE		768
 
+#define MCINFO_FLAGS_UNCOMPLETE 0x1
 struct mc_info {
     /* Number of mcinfo_* entries in mi_data */
     uint32_t mi_nentries;
-    uint32_t _pad0;
+    uint32_t flags;
     uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
 };
 typedef struct mc_info mc_info_t;



[-- Attachment #2: mcinfo_reserve.patch --]
[-- Type: application/octet-stream, Size: 10822 bytes --]

# HG changeset patch
# User Yunhong Jiang <yunhong.jiang@intel.com>
# Date 1271415118 -28800
# Node ID 63632454170a30f4e0cbffa78be62b33e87605bb
# Parent  4e1d1e56e8b90f8594db6f812b5bd5f35f6e87be
Add a x86_mcinfo_reserve() function, to reserve space from mc_info.

With this method, we don't need to collect bank and globalinformation to a
local variable and do x86_mcinfo_add() to copy that information to mc_info.
This avoid copy and also we can be aware earlier if there is enough space
in the mc_info.

Also extract function that get global/bank information to seperated
function mca_init_bank/mca_init_global.

It's meaningless to get the current information in mce context, keep it here
but should be removed in future.

Also a flag added to mc_info, to indicate some information is lost due to OOM.

Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>

diff -r 4e1d1e56e8b9 -r 63632454170a xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Fri Apr 16 18:51:58 2010 +0800
@@ -125,6 +125,88 @@ void mce_need_clearbank_register(mce_nee
     mc_need_clearbank_scan = cbfunc;
 }
 
+static struct mcinfo_bank *mca_init_bank(enum mca_source who,
+                                         struct mc_info *mi, int bank)
+{
+	struct mcinfo_bank *mib;
+	uint64_t addr=0, misc = 0;
+
+	if (!mi)
+		return NULL;
+
+	mib = x86_mcinfo_reserve(mi, sizeof(struct mcinfo_bank));
+	if (!mib)
+	{
+		mi->flags |= MCINFO_FLAGS_UNCOMPLETE;
+		return NULL;
+	}
+
+	memset(mib, 0, sizeof (struct mcinfo_bank));
+	mca_rdmsrl(MSR_IA32_MC0_STATUS + bank * 4, mib->mc_status);
+
+	mib->common.type = MC_TYPE_BANK;
+	mib->common.size = sizeof (struct mcinfo_bank);
+	mib->mc_bank = bank;
+
+	addr = misc = 0;
+	if (mib->mc_status & MCi_STATUS_MISCV)
+		mca_rdmsrl(MSR_IA32_MC0_MISC + 4 * bank, mib->mc_misc);
+
+	if (mib->mc_status & MCi_STATUS_ADDRV)
+	{
+		mca_rdmsrl(MSR_IA32_MC0_ADDR + 4 * bank, mib->mc_addr);
+
+		if (mfn_valid(paddr_to_pfn(mib->mc_addr))) {
+			struct domain *d;
+
+			d = maddr_get_owner(mib->mc_addr);
+			if (d != NULL && (who == MCA_POLLER ||
+				  who == MCA_CMCI_HANDLER))
+				mib->mc_domid = d->domain_id;
+		}
+	}
+
+	if (who == MCA_CMCI_HANDLER) {
+		mca_rdmsrl(MSR_IA32_MC0_CTL2 + bank, mib->mc_ctrl2);
+		rdtscll(mib->mc_tsc);
+	}
+
+	return mib;
+}
+
+static int mca_init_global(uint32_t flags, struct mcinfo_global *mig)
+{
+	uint64_t status;
+	int cpu_nr;
+	struct vcpu *v = current;
+	struct domain *d;
+
+	/* Set global information */
+	memset(mig, 0, sizeof (struct mcinfo_global));
+	mig->common.type = MC_TYPE_GLOBAL;
+	mig->common.size = sizeof (struct mcinfo_global);
+	mca_rdmsrl(MSR_IA32_MCG_STATUS, status);
+	mig->mc_gstatus = status;
+	mig->mc_domid = mig->mc_vcpuid = -1;
+	mig->mc_flags = flags;
+	cpu_nr = smp_processor_id();
+	/* Retrieve detector information */
+	x86_mc_get_cpu_info(cpu_nr, &mig->mc_socketid,
+	  &mig->mc_coreid, &mig->mc_core_threadid,
+	  &mig->mc_apicid, NULL, NULL, NULL);
+
+	/* This is really meaningless */
+	if (v != NULL && ((d = v->domain) != NULL)) {
+		mig->mc_domid = d->domain_id;
+		mig->mc_vcpuid = v->vcpu_id;
+	} else {
+		mig->mc_domid = -1;
+		mig->mc_vcpuid = -1;
+	}
+
+	return 0;
+}
+
 /* Utility function to perform MCA bank telemetry readout and to push that
  * telemetry towards an interested dom0 for logging and diagnosis.
  * The caller - #MC handler or MCA poll function - must arrange that we
@@ -139,64 +221,38 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 mctelem_cookie_t mcheck_mca_logout(enum mca_source who, cpu_banks_t bankmask,
     struct mca_summary *sp, cpu_banks_t* clear_bank)
 {
-	struct vcpu *v = current;
-	struct domain *d;
-	uint64_t gstatus, status, addr, misc;
-	struct mcinfo_global mcg;	/* on stack */
-	struct mcinfo_common *mic;
-	struct mcinfo_global *mig;	/* on stack */
+	uint64_t gstatus, status;
+	struct mcinfo_global *mig = NULL;	/* on stack */
 	mctelem_cookie_t mctc = NULL;
-	uint32_t uc = 0, pcc = 0, recover, need_clear = 1 ;
+	uint32_t uc = 0, pcc = 0, recover, need_clear = 1, mc_flags = 0;
 	struct mc_info *mci = NULL;
 	mctelem_class_t which = MC_URGENT;	/* XXXgcc */
-	unsigned int cpu_nr;
 	int errcnt = 0;
 	int i;
 	enum mca_extinfo cbret = MCA_EXTINFO_IGNORED;
 
-	cpu_nr = smp_processor_id();
-	BUG_ON(cpu_nr != v->processor);
-
 	mca_rdmsrl(MSR_IA32_MCG_STATUS, gstatus);
-
-	memset(&mcg, 0, sizeof (mcg));
-	mcg.common.type = MC_TYPE_GLOBAL;
-	mcg.common.size = sizeof (mcg);
-	if (v != NULL && ((d = v->domain) != NULL)) {
-		mcg.mc_domid = d->domain_id;
-		mcg.mc_vcpuid = v->vcpu_id;
-	} else {
-		mcg.mc_domid = -1;
-		mcg.mc_vcpuid = -1;
-	}
-	mcg.mc_gstatus = gstatus;	/* MCG_STATUS */
-
 	switch (who) {
 	case MCA_MCE_HANDLER:
 	case MCA_MCE_SCAN:
-		mcg.mc_flags = MC_FLAG_MCE;
+		mc_flags = MC_FLAG_MCE;
 		which = MC_URGENT;
 		break;
 
 	case MCA_POLLER:
 	case MCA_RESET:
-		mcg.mc_flags = MC_FLAG_POLLED;
+		mc_flags = MC_FLAG_POLLED;
 		which = MC_NONURGENT;
 		break;
 
 	case MCA_CMCI_HANDLER:
-		mcg.mc_flags = MC_FLAG_CMCI;
+		mc_flags = MC_FLAG_CMCI;
 		which = MC_NONURGENT;
 		break;
 
 	default:
 		BUG();
 	}
-
-	/* Retrieve detector information */
-	x86_mc_get_cpu_info(cpu_nr, &mcg.mc_socketid,
-	    &mcg.mc_coreid, &mcg.mc_core_threadid,
-	    &mcg.mc_apicid, NULL, NULL, NULL);
 
 	/* If no mc_recovery_scan callback handler registered,
 	 * this error is not recoverable
@@ -204,7 +260,7 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 	recover = (mc_recoverable_scan)? 1: 0;
 
 	for (i = 0; i < 32 && i < nr_mce_banks; i++) {
-		struct mcinfo_bank mcb;		/* on stack */
+		struct mcinfo_bank *mib;		/* on stack */
 
 		/* Skip bank if corresponding bit in bankmask is clear */
 		if (!test_bit(i, bankmask))
@@ -227,17 +283,16 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 		 * a poller;  this can fail (for example dom0 may not
 		 * yet have consumed past telemetry). */
 		if (errcnt == 0) {
-			if ((mctc = mctelem_reserve(which)) != NULL) {
+			if ( (mctc = mctelem_reserve(which)) != NULL ) {
 				mci = mctelem_dataptr(mctc);
 				mcinfo_clear(mci);
+				mig = (struct mcinfo_global*)x86_mcinfo_reserve
+				  (mci, sizeof(struct mcinfo_global));
+				/* mc_info should at least hold up the global information */
+				ASSERT(mig);
+				mca_init_global(mc_flags, mig);
 			}
 		}
-
-		memset(&mcb, 0, sizeof (mcb));
-		mcb.common.type = MC_TYPE_BANK;
-		mcb.common.size = sizeof (mcb);
-		mcb.mc_bank = i;
-		mcb.mc_status = status;
 
 		/* form a mask of which banks have logged uncorrected errors */
 		if ((status & MCi_STATUS_UC) != 0)
@@ -252,37 +307,7 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 		  */
 			recover = mc_recoverable_scan(status);
 
-		addr = misc = 0;
-
-		if (status & MCi_STATUS_ADDRV) {
-			mca_rdmsrl(MSR_IA32_MC0_ADDR + 4 * i, addr);
-			if (mfn_valid(paddr_to_pfn(addr))) {
-				d = maddr_get_owner(addr);
-				if (d != NULL && (who == MCA_POLLER ||
-				    who == MCA_CMCI_HANDLER))
-					mcb.mc_domid = d->domain_id;
-			}
-		}
-
-		if (status & MCi_STATUS_MISCV)
-			mca_rdmsrl(MSR_IA32_MC0_MISC + 4 * i, misc);
-
-		mcb.mc_addr = addr;
-		mcb.mc_misc = misc;
-
-		if (who == MCA_CMCI_HANDLER) {
-			mca_rdmsrl(MSR_IA32_MC0_CTL2 + i, mcb.mc_ctrl2);
-			rdtscll(mcb.mc_tsc);
-		}
-
-		/* Increment the error count;  if this is the first bank
-		 * with a valid error then add the global info to the mcinfo. */
-		if (errcnt++ == 0 && mci != NULL)
-			x86_mcinfo_add(mci, &mcg);
-
-		/* Add the bank data */
-		if (mci != NULL)
-			x86_mcinfo_add(mci, &mcb);
+		mib = mca_init_bank(who, mci, i);
 
 		if (mc_callback_bank_extended && cbret != MCA_EXTINFO_GLOBAL) {
 			cbret = mc_callback_bank_extended(mci, i, status);
@@ -298,12 +323,8 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 		wmb();
 	}
 
-	if (mci != NULL && errcnt > 0) {
-		x86_mcinfo_lookup(mic, mci, MC_TYPE_GLOBAL);
-		mig = container_of(mic, struct mcinfo_global, common);
-		if (mic == NULL)
-			;
-		else if (pcc)
+	if (mig && errcnt > 0) {
+		if (pcc)
 			mig->mc_flags |= MC_FLAG_UNCORRECTABLE;
 		else if (uc)
 			mig->mc_flags |= MC_FLAG_RECOVERABLE;
@@ -758,13 +779,12 @@ static void mcinfo_clear(struct mc_info 
 	x86_mcinfo_nentries(mi) = 0;
 }
 
-int x86_mcinfo_add(struct mc_info *mi, void *mcinfo)
+void *x86_mcinfo_reserve(struct mc_info *mi, int size)
 {
 	int i;
 	unsigned long end1, end2;
-	struct mcinfo_common *mic, *mic_base, *mic_index;
-
-	mic = (struct mcinfo_common *)mcinfo;
+	struct mcinfo_common *mic_base, *mic_index;
+
 	mic_index = mic_base = x86_mcinfo_first(mi);
 
 	/* go to first free entry */
@@ -774,16 +794,35 @@ int x86_mcinfo_add(struct mc_info *mi, v
 
 	/* check if there is enough size */
 	end1 = (unsigned long)((uint8_t *)mic_base + sizeof(struct mc_info));
-	end2 = (unsigned long)((uint8_t *)mic_index + mic->size);
+	end2 = (unsigned long)((uint8_t *)mic_index + size);
 
 	if (end1 < end2)
-		return x86_mcerr("mcinfo_add: no more sparc", -ENOSPC);
+	{
+		mce_printk(MCE_CRITICAL,
+			"mcinfo_add: No space left in mc_info\n");
+		return NULL;
+	}
 
 	/* there's enough space. add entry. */
-	memcpy(mic_index, mic, mic->size);
 	x86_mcinfo_nentries(mi)++;
 
-	return 0;
+    return mic_index;
+}
+
+void *x86_mcinfo_add(struct mc_info *mi, void *mcinfo)
+{
+	struct mcinfo_common *mic, *buf;
+
+	mic = (struct mcinfo_common *)mcinfo;
+	buf = x86_mcinfo_reserve(mi, mic->size);
+
+	if ( !buf )
+		mce_printk(MCE_CRITICAL,
+			"mcinfo_add: No space left in mc_info\n");
+	else
+		memcpy(buf, mic, mic->size);
+
+	return buf;
 }
 
 /* Dump machine check information in a format,
diff -r 4e1d1e56e8b9 -r 63632454170a xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Fri Apr 16 18:51:58 2010 +0800
@@ -161,7 +161,8 @@ typedef enum mca_extinfo (*x86_mce_callb
     (struct mc_info *, uint16_t, uint64_t);
 extern void x86_mce_callback_register(x86_mce_callback_t);
 
-int x86_mcinfo_add(struct mc_info *mi, void *mcinfo);
+void *x86_mcinfo_add(struct mc_info *mi, void *mcinfo);
+void *x86_mcinfo_reserve(struct mc_info *mi, int size);
 void x86_mcinfo_dump(struct mc_info *mi);
 
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
diff -r 4e1d1e56e8b9 -r 63632454170a xen/include/public/arch-x86/xen-mca.h
--- a/xen/include/public/arch-x86/xen-mca.h	Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/include/public/arch-x86/xen-mca.h	Fri Apr 16 18:51:58 2010 +0800
@@ -233,10 +233,11 @@ struct mcinfo_recovery
 #define MCINFO_HYPERCALLSIZE	1024
 #define MCINFO_MAXSIZE		768
 
+#define MCINFO_FLAGS_UNCOMPLETE 0x1
 struct mc_info {
     /* Number of mcinfo_* entries in mi_data */
     uint32_t mi_nentries;
-    uint32_t _pad0;
+    uint32_t flags;
     uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
 };
 typedef struct mc_info mc_info_t;

[-- 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] 147+ messages in thread

* (no subject)
@ 2009-10-09 21:47 Eads, Joshua Michael (S&T-Student)
  0 siblings, 0 replies; 147+ messages in thread
From: Eads, Joshua Michael (S&T-Student) @ 2009-10-09 21:47 UTC (permalink / raw)
  To: xen-devel

I have an HVM guest and I am trying to have a usermode program in Dom0 query the context (CPU registers, specifically) of the guest.  

I first tried using xc_domain_getcontext() in xenctrl.h but I haven't figured out what data structure ctxt_buf is that it returns.  Next, I have tried using xc_vcpu_getcontext() in xenctrl.h but so far it always returns -1 for failure.  For xc_vcpu_getcontext, I am passing in a vcpu number of 1 (I only have a single virtual CPU domU running) along with an unallocated vcpu_guest_context_t pointer.

Is this the right direction to pull guest registers, or is there another method I need to use to get the HVM guest context?

Thanks,
Josh

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2009-01-23  6:45 Alexia Benington
  0 siblings, 0 replies; 147+ messages in thread
From: Alexia Benington @ 2009-01-23  6:45 UTC (permalink / raw)
  To: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 4183 bytes --]

Hi all,

My Dom0 crashed if I use the first grub configuration, but is ok if I use
the following one.

kernel          /boot/xen-3.4-unstable.gz
module          /boot/vmlinuz-2.6.18.8-xen root=/dev/sda2 ro

kernel          /boot/xen-3.4-unstable.gz com1=9600,8n1 console=com1 iommu=1
module          /boot/vmlinuz-2.6.18.8-xen root=/dev/sda2 ro xencons=ttyS
console=tty0 console=ttyS0

I've attached the full boot trace. Below is a snippet of the crash region.
Does anyone have any idea what's going on?

Thanks and have a nice day.


- Alexia

================================================
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1a.0[A] -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1a.0: UHCI Host Controller
uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000e0e0
(XEN) [VT-D]iommu.c:721: iommu_page_fault: iommu->reg = ffff828bfff55000
(XEN) [VT-D]iommu.c:693: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:675: iommu_fault:DMA Read: 0:1a.0 addr bf7ed000 REASON 6
iommu->reg = ffff828bfff55000
(XEN) print_vtd_entries: iommu = ffff8300bfef10f0 bdf = 0:1a:0 gmfn = bf7ed
(XEN)     root_entry = ffff83013bdea000
(XEN)     root_entry[0] = 1374a0001
(XEN)     context = ffff8301374a0000
(XEN)     context[d0] = 101_13bde6001
(XEN)     l3 = ffff83013bde6000
(XEN)     l3_index = 2
(XEN)     l3[2] = 137a83003
(XEN)     l2 = ffff830137a83000
(XEN)     l2_index = 1fb
(XEN)     l2[1fb] = 137887003
(XEN)     l1 = ffff830137887000
(XEN)     l1_index = 1ed
(XEN)     l1[1ed] = 0
(XEN)     l1[1ed] not present
uhci_hcd 0000:00:1a.0: host system error, PCI problems?
uhci_hcd 0000:00:1a.0: host controller halted, very bad!
uhci_hcd 0000:00:1a.0: HC died; cleaning up
usb usb1: configuration #1 chosen from 1 choice
usb usb1: can't set config #1, error -108
uhci_hcd 0000:00:1a.0: HC died; cleaning up
Unable to handle kernel NULL pointer dereference at 0000000000000018 RIP:
 [<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
PGD ef053067 PUD ef051067 PMD 0
Oops: 0000 [1] SMP
CPU 3
Modules linked in: uhci_hcd usbcore thermal processor fan
Pid: 496, comm: insmod Not tainted 2.6.18.8-xen #1
RIP: e030:[<ffffffff88019be9>]  [<ffffffff88019be9>]
:usbcore:usb_kick_khubd+0x7/0x17
RSP: e02b:ffff8800eeb6fc50  EFLAGS: 00010002
RAX: 0000000000000000 RBX: ffff8800eed03c00 RCX: ffffffffff578000
RDX: ffffffffff578000 RSI: 0000000000000001 RDI: ffff8800ef03e000
RBP: 0000000000000000 R08: 000000000000000e R09: 0000000000000001
R10: ffff8800ef052570 R11: ffffffff80300885 R12: ffff8800eecb01c8
R13: 0000000000000000 R14: ffff8800ef03e000 R15: ffff8800eecb0070
FS:  00002ad0ef6c66d0(0000) GS:ffffffff804d9180(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000
Process insmod (pid: 496, threadinfo ffff8800eeb6e000, task
ffff8800eec867a0)
Stack:  ffffffff8801a39b 0000000000000012 ffff8800ef03e000 ffff8800eed03c00
 ffffffff8801ad3c 0000001000000004 ffff8800eecb00e0 ffff8800eed03c00
 ffff8800eecb0000 0000000000000004 ffffffff8803d4a0 0000000000000000
Call Trace:
 [<ffffffff8801a39b>] :usbcore:usb_hc_died+0x5f/0x72
 [<ffffffff8801ad3c>] :usbcore:usb_add_hcd+0x4eb/0x562
 [<ffffffff880230cf>] :usbcore:usb_hcd_pci_probe+0x1e6/0x28f
 [<ffffffff802f4f5e>] pci_device_probe+0x4c/0x75
 [<ffffffff8034f250>] pci_bus_probe_wrapper+0x86/0x92
 [<ffffffff802f4e48>] pci_match_device+0x13/0xbd
 [<ffffffff8803d000>] :uhci_hcd:uhci_start+0x21e/0x3c0
 [<ffffffff802f4f06>] pci_bus_match+0x14/0x20
 [<ffffffff80346048>] driver_probe_device+0x52/0xa8
 [<ffffffff80346177>] __driver_attach+0x6d/0xaa
 [<ffffffff8034610a>] __driver_attach+0x0/0xaa
 [<ffffffff80345a49>] bus_for_each_dev+0x43/0x6e
 [<ffffffff803456a7>] bus_add_driver+0x7e/0x130
 [<ffffffff802f50f9>] __pci_register_driver+0x57/0x7d
 [<ffffffff8804305c>] :uhci_hcd:uhci_hcd_init+0x5c/0x97
 [<ffffffff8024b1f5>] sys_init_module+0x16cc/0x1883
 [<ffffffff8020a518>] system_call+0x68/0x6d
 [<ffffffff8020a4b0>] system_call+0x0/0x6d


Code: 48 8b 40 18 48 8b b8 f0 01 00 00 e9 52 db ff ff 41 56 41 55
RIP  [<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
 RSP <ffff8800eeb6fc50>
CR2: 0000000000000018
 Killed

[-- Attachment #1.2: Type: text/html, Size: 5276 bytes --]

[-- Attachment #2: boottrace.txt --]
[-- Type: text/plain, Size: 16160 bytes --]

 \ \/ /___ _ __   |___ /| || |     _   _ _ __  ___| |_ __ _| |__ | | ___ 
  \  // _ \ '_ \    |_ \| || |_ __| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
  /  \  __/ | | |  ___) |__   _|__| |_| | | | \__ \ || (_| | |_) | |  __/
 /_/\_\___|_| |_| |____(_) |_|     \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
                                                                         
(XEN) Xen version 3.4-unstable (xxx@xxx.xxx.xxx) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) Thu Jan 22 12:06:54 EST 2009
(XEN) Latest ChangeSet: Thu Jan 22 11:07:32 2009 +0000 19067:a92ed09b4032
(XEN) Command line: com1=9600,8n1 console=com1 iommu=1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009e800 (usable)
(XEN)  000000000009e800 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bfae1000 (usable)
(XEN)  00000000bfae1000 - 00000000bfb24000 (ACPI NVS)
(XEN)  00000000bfb24000 - 00000000bfd42000 (reserved)
(XEN)  00000000bfd42000 - 00000000bfd43000 (ACPI NVS)
(XEN)  00000000bfd43000 - 00000000bfd48000 (reserved)
(XEN)  00000000bfd48000 - 00000000bfd50000 (ACPI data)
(XEN)  00000000bfd50000 - 00000000bfd6b000 (ACPI NVS)
(XEN)  00000000bfd6b000 - 00000000bfd8a000 (reserved)
(XEN)  00000000bfd8a000 - 00000000bfd90000 (ACPI NVS)
(XEN)  00000000bfd90000 - 00000000bff00000 (usable)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000013c000000 (usable)
(XEN) System RAM: 4027MB (4124604kB)
(XEN) ACPI: RSDP 000F03C0, 0024 (r2  INTEL)
(XEN) ACPI: XSDT BFD4EE18, 005C (r1 INTEL  DQ45CB         43 MSFT    10013)
(XEN) ACPI: FACP BFD4DD98, 00F4 (r4  INTEL    A M I  6222004 MSFT    10013)
(XEN) ACPI: DSDT BFD48018, 4EFD (r1 INTEL  DQ45CB         43 INTL 20051117)
(XEN) ACPI: FACS BFD56F40, 0040
(XEN) ACPI: APIC BFD4DF18, 006C (r2 INTEL  DQ45CB         43 MSFT    10013)
(XEN) ACPI: MCFG BFD58E18, 003C (r1 INTEL  DQ45CB         43 MSFT       97)
(XEN) ACPI: ASF! BFD57D18, 00A0 (r32 INTEL  DQ45CB         43 TFSM    F4240)
(XEN) ACPI: SPCR BFD58D18, 0050 (r1 INTEL  DQ45CB         43 AMI.        3)
(XEN) ACPI: TCPA BFD58C98, 0032 (r2 INTEL  DQ45CB         43 MSFT  1000013)
(XEN) ACPI: DMAR BFD42F18, 00D8 (r1 INTEL  DQ45CB         43 INTL        1)
(XEN) Domain heap initialised
(XEN) Processor #0 7:7 APIC version 20
(XEN) Processor #1 7:7 APIC version 20
(XEN) Processor #2 7:7 APIC version 20
(XEN) Processor #3 7:7 APIC version 20
(XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) Intel VT-d has been enabled
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2499.770 MHz processor.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN) HVM: VMX enabled
(XEN) CPU0: Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz stepping 07
(XEN) Booting processor 1/1 eip 8c000
(XEN) CPU1: Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz stepping 07
(XEN) Booting processor 2/2 eip 8c000
(XEN) CPU2: Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz stepping 07
(XEN) Booting processor 3/3 eip 8c000
(XEN) CPU3: Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz stepping 07
(XEN) Total of 4 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) checking TSC synchronization across 4 CPUs: passed.
(XEN) Platform timer is 3.579MHz ACPI PM Timer
(XEN) Brought up 4 CPUs
(XEN) I/O virtualisation enabled
(XEN) I/O virtualisation for PV guests disabled
(XEN) mtrr: your CPUs had inconsistent fixed MTRR settings
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, lsb, paddr 0xffffffff80200000 -> 0xffffffff805bf88c
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000134000000->0000000136000000 (970253 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff80200000->ffffffff805bf88c
(XEN)  Init. ramdisk: ffffffff805c0000->ffffffff80956400
(XEN)  Phys-Mach map: ffffffff80957000->ffffffff810ce068
(XEN)  Start info:    ffffffff810cf000->ffffffff810cf4b4
(XEN)  Page tables:   ffffffff810d0000->ffffffff810dd000
(XEN)  Boot stack:    ffffffff810dd000->ffffffff810de000
(XEN)  TOTAL:         ffffffff80000000->ffffffff81400000
(XEN)  ENTRY ADDRESS: ffffffff80200000
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 108kB init memory.
kernel direct mapping tables up to ef60d000 @ 10e0000-1861000
Bootdata ok (command line is root=/dev/sda2 ro xencons=ttyS console=tty0 console=ttyS0)
Linux version 2.6.18.8-xen (root@amber) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Thu Jan 22 12:02:23 EST 2009
BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 00000000ef60d000 (usable)
DMI 2.4 present.
No mptable found.
  >>> ERROR: Invalid checksum
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Setting APIC routing to xen
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at c0000000 (gap: bff00000:3ee1c000)
Built 1 zonelists.  Total pages: 967088
Kernel command line: root=/dev/sda2 ro xencons=ttyS console=tty0 console=ttyS0
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Xen reported: 2499.770 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Software IO TLB enabled: 
 Aperture:     64 megabytes
 Kernel range: ffff880005a7a000 - ffff880009a7a000
 Address size: 27 bits
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
Memory: 3764092k/3921972k available (2027k kernel code, 149244k reserved, 887k data, 180k init)
Calibrating delay using timer specific routine.. 5000.60 BogoMIPS (lpj=25003009)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 256
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
SMP alternatives: switching to UP code
ACPI: Core revision 20060707
SMP alternatives: switching to SMP code
Initializing CPU#1
Initializing CPU#2
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
Brought up 4 CPUs
Initializing CPU#3
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 3
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 2
migration_cost=9
checking if image is initramfs... it is
Freeing initrd memory: 3673k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs *3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 *7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs *3 4 5 6 7 10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
(XEN) ioapic_guest_write: apic=0, pin=4, old_irq=4, new_irq=4
(XEN) ioapic_guest_write: old_entry=000009f1, new_entry=000109f1
(XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
pnp: PnP ACPI: found 10 devices
xen_mem: Initialising balloon driver.
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
pnp: 00:02: ioport range 0xa20-0xa3f has been reserved
pnp: 00:02: ioport range 0xa00-0xa1f has been reserved
pnp: 00:02: ioport range 0xb78-0xb7f has been reserved
pnp: 00:02: ioport range 0xf78-0xf7f has been reserved
pnp: 00:09: ioport range 0x400-0x47f could not be reserved
pnp: 00:09: ioport range 0x1180-0x119f has been reserved
pnp: 00:09: ioport range 0x500-0x57f has been reserved
PCI: Bridge: 0000:00:01.0
  IO window: d000-dfff
  MEM window: c0000000-d00fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
  IO window: disabled.
  MEM window: d0100000-d01fffff
  PREFETCH window: disabled.
GSI 16 sharing vector 0xA8 and IRQ 16
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
NET: Registered protocol family 2
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
IA-32 Microcode Update Driver: v1.14a-xen <tigran@veritas.com>
audit: initializing netlink socket (disabled)
audit(1232672414.325:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
0000:00:1a.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001
0000:00:1d.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
Xen virtual console successfully installed as ttyS0
Event-channel device installed.
netfront: Initialising virtual ethernet driver.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
NET: Registered protocol family 1
NET: Registered protocol family 17
ACPI: (supports S0 S1 S3 S4 S5)
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Freeing unused kernel memory: 180k freed
ACPI (exconfig-0455): Dynamic SSDT Load - OemId [   AMI] OemTableId [     IST] [20060707]
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 0 initialization completed
ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3])
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 1 initialization completed
ACPI: CPU2 (power states: C1[C1] C2[C2] C3[C3])
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 2 initialization completed
ACPI: CPU3 (power states: C1[C1] C2[C2] C3[C3])
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 3 initialization completed
ACPI Exception (acpi_processor-0721): AE_NOT_FOUND, Processor Device is not present [20060707]
ACPI: CPU-1 (power states: C1[C1] C2[C2] C3[C3])
ACPI Exception (acpi_processor-0721): AE_NOT_FOUND, Processor Device is not present [20060707]
ACPI: CPU-1 (power states: C1[C1] C2[C2] C3[C3])
ACPI Exception (acpi_processor-0721): AE_NOT_FOUND, Processor Device is not present [20060707]
ACPI: CPU-1 (power states: C1[C1] C2[C2] C3[C3])
ACPI Exception (acpi_processor-0721): AE_NOT_FOUND, Processor Device is not present [20060707]
ACPI: CPU-1 (power states: C1[C1] C2[C2] C3[C3])
usbcore: registered new driver usbfs
usbcore: registered new driver hub
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1a.0[A] -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1a.0: UHCI Host Controller
uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000e0e0
(XEN) [VT-D]iommu.c:721: iommu_page_fault: iommu->reg = ffff828bfff55000
(XEN) [VT-D]iommu.c:693: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:675: iommu_fault:DMA Read: 0:1a.0 addr bf7ed000 REASON 6 iommu->reg = ffff828bfff55000
(XEN) print_vtd_entries: iommu = ffff8300bfef10f0 bdf = 0:1a:0 gmfn = bf7ed
(XEN)     root_entry = ffff83013bdea000
(XEN)     root_entry[0] = 1374a0001
(XEN)     context = ffff8301374a0000
(XEN)     context[d0] = 101_13bde6001
(XEN)     l3 = ffff83013bde6000
(XEN)     l3_index = 2
(XEN)     l3[2] = 137a83003
(XEN)     l2 = ffff830137a83000
(XEN)     l2_index = 1fb
(XEN)     l2[1fb] = 137887003
(XEN)     l1 = ffff830137887000
(XEN)     l1_index = 1ed
(XEN)     l1[1ed] = 0
(XEN)     l1[1ed] not present
uhci_hcd 0000:00:1a.0: host system error, PCI problems?
uhci_hcd 0000:00:1a.0: host controller halted, very bad!
uhci_hcd 0000:00:1a.0: HC died; cleaning up
usb usb1: configuration #1 chosen from 1 choice
usb usb1: can't set config #1, error -108
uhci_hcd 0000:00:1a.0: HC died; cleaning up
Unable to handle kernel NULL pointer dereference at 0000000000000018 RIP: 
 [<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
PGD ef053067 PUD ef051067 PMD 0 
Oops: 0000 [1] SMP 
CPU 3 
Modules linked in: uhci_hcd usbcore thermal processor fan
Pid: 496, comm: insmod Not tainted 2.6.18.8-xen #1
RIP: e030:[<ffffffff88019be9>]  [<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
RSP: e02b:ffff8800eeb6fc50  EFLAGS: 00010002
RAX: 0000000000000000 RBX: ffff8800eed03c00 RCX: ffffffffff578000
RDX: ffffffffff578000 RSI: 0000000000000001 RDI: ffff8800ef03e000
RBP: 0000000000000000 R08: 000000000000000e R09: 0000000000000001
R10: ffff8800ef052570 R11: ffffffff80300885 R12: ffff8800eecb01c8
R13: 0000000000000000 R14: ffff8800ef03e000 R15: ffff8800eecb0070
FS:  00002ad0ef6c66d0(0000) GS:ffffffff804d9180(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000
Process insmod (pid: 496, threadinfo ffff8800eeb6e000, task ffff8800eec867a0)
Stack:  ffffffff8801a39b 0000000000000012 ffff8800ef03e000 ffff8800eed03c00
 ffffffff8801ad3c 0000001000000004 ffff8800eecb00e0 ffff8800eed03c00
 ffff8800eecb0000 0000000000000004 ffffffff8803d4a0 0000000000000000
Call Trace:
 [<ffffffff8801a39b>] :usbcore:usb_hc_died+0x5f/0x72
 [<ffffffff8801ad3c>] :usbcore:usb_add_hcd+0x4eb/0x562
 [<ffffffff880230cf>] :usbcore:usb_hcd_pci_probe+0x1e6/0x28f
 [<ffffffff802f4f5e>] pci_device_probe+0x4c/0x75
 [<ffffffff8034f250>] pci_bus_probe_wrapper+0x86/0x92
 [<ffffffff802f4e48>] pci_match_device+0x13/0xbd
 [<ffffffff8803d000>] :uhci_hcd:uhci_start+0x21e/0x3c0
 [<ffffffff802f4f06>] pci_bus_match+0x14/0x20
 [<ffffffff80346048>] driver_probe_device+0x52/0xa8
 [<ffffffff80346177>] __driver_attach+0x6d/0xaa
 [<ffffffff8034610a>] __driver_attach+0x0/0xaa
 [<ffffffff80345a49>] bus_for_each_dev+0x43/0x6e
 [<ffffffff803456a7>] bus_add_driver+0x7e/0x130
 [<ffffffff802f50f9>] __pci_register_driver+0x57/0x7d
 [<ffffffff8804305c>] :uhci_hcd:uhci_hcd_init+0x5c/0x97
 [<ffffffff8024b1f5>] sys_init_module+0x16cc/0x1883
 [<ffffffff8020a518>] system_call+0x68/0x6d
 [<ffffffff8020a4b0>] system_call+0x0/0x6d


Code: 48 8b 40 18 48 8b b8 f0 01 00 00 e9 52 db ff ff 41 56 41 55 
RIP  [<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
 RSP <ffff8800eeb6fc50>
CR2: 0000000000000018
 Killed


[-- 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] 147+ messages in thread

* RE: (no subject)
  2008-11-19 22:29 Bowen, Clair
@ 2008-11-19 22:36 ` James Harper
  0 siblings, 0 replies; 147+ messages in thread
From: James Harper @ 2008-11-19 22:36 UTC (permalink / raw)
  To: Bowen, Clair, Xen-devel

> 
> Does anybody know if Storport is supported on XEN?  I only see
references
> to SCSIPORT (i.e xenscsi.sys).
> 

If you are referring to the gplpv drivers, then I have only developed
with scsiport at the moment. Storport is only supported under 2003 and
later and I didn't want to maintain two versions of the same code. I'm
not yet convinced that storport will give any noticeable advantage over
scsiport for what we are doing.

xenvbd (scsi emulation of block device) and xenscsi (pvscsi scsi
passthrough) are both scsiport drivers, but xenscsi doesn't work at the
moment as it only worked with a slightly modified version of the 3.2
version of pvscsi. It will be incompatible with the 3.3 version. I will
update it once I get 3.3 installed on my dev box (waiting for some
Debian packages).

Thanks

James

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2008-11-19 22:29 Bowen, Clair
  2008-11-19 22:36 ` James Harper
  0 siblings, 1 reply; 147+ messages in thread
From: Bowen, Clair @ 2008-11-19 22:29 UTC (permalink / raw)
  To: Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 126 bytes --]

Does anybody know if Storport is supported on XEN?  I only see references to SCSIPORT (i.e xenscsi.sys).

Regards,

CJ


[-- Attachment #1.2: Type: text/html, Size: 4277 bytes --]

[-- Attachment #2: 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] 147+ messages in thread

* (no subject)
@ 2008-10-10 12:27 Swapna Shingre
  0 siblings, 0 replies; 147+ messages in thread
From: Swapna Shingre @ 2008-10-10 12:27 UTC (permalink / raw)
  To: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 167 bytes --]

hi all,
  can anyone tell me what exactly the iret hypercall does?
and, is there any way to disable the fast system call handlers and use
normal system call handling?

[-- Attachment #1.2: Type: text/html, Size: 204 bytes --]

[-- Attachment #2: 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] 147+ messages in thread

* (no subject)
@ 2008-09-18  7:10 James Song
  0 siblings, 0 replies; 147+ messages in thread
From: James Song @ 2008-09-18  7:10 UTC (permalink / raw)
  To: xen-devel

I test stubdom in xen-3.3.1, when I start it,  just see the message bellow using "xm li" . It seems stubdom haven't start. 

Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   964     2     r-----     34.8
hvmachine                                    1  1024     1     ------      0.0

   the two config files : 
#hvmachine
kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory =  256
name = "hvmachine"
vcpus=2
vif = [ 'type=ioemu, bridge=eth0' ]
device_model = '/usr/lib/xen/bin/stubdom-dm'
boot="cd"
sdl=0
opengl=0
vnc=1
vnclisten="172.30.206.1"
stdvga=0
-------------------------------------------------------------------------


#hvmachine-dm
kernel = "/usr/lib/xen/boot/ioemu-stubdom.gz"
vif = [ 'ip=172.30.206.1', 'bridge=eth0,mac=00:16:3e:21:a2:94' ]
disk = [ 'file:/home/images/opensuse11-2/disk0,hda,w' ]



what's wrong I make?


best regards,
-- James

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2007-06-11 10:35 Gautham Kampalapur Shankar, TLS, Chennai
@ 2007-06-11 10:53 ` pradeep singh rautela
  0 siblings, 0 replies; 147+ messages in thread
From: pradeep singh rautela @ 2007-06-11 10:53 UTC (permalink / raw)
  To: Gautham Kampalapur Shankar, TLS, Chennai; +Cc: xen-devel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 6/11/07, Gautham Kampalapur Shankar, TLS, Chennai  wrote:
>
>
>
>
>  How xen bus and xen store works ? How they related to each other ?
Gautham you are supposed to use a proper subject for a prompt reply.

thanks

- --
- ---
pradeep singh rautela

"Genius is 1% inspiration, and 99% perspiration" - not me :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: http://firegpg.tuxfamily.org

iD8DBQFGbSmLky6Gd9lpXlERAu12AJ4kdzmyofihA5fmShaCuNbQv5z+ZQCePElh
JA4gh+llY+9GVInFabWvVHw=
=UC9B
-----END PGP SIGNATURE-----

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2007-06-11 10:35 Gautham Kampalapur Shankar, TLS, Chennai
  2007-06-11 10:53 ` pradeep singh rautela
  0 siblings, 1 reply; 147+ messages in thread
From: Gautham Kampalapur Shankar, TLS, Chennai @ 2007-06-11 10:35 UTC (permalink / raw)
  To: xen-devel

[-- Attachment #1: Type: text/html, Size: 420 bytes --]

[-- Attachment #2: Type: text/plain, Size: 984 bytes --]

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have 
received this email in error please delete it and notify the sender immediately. Before opening any mail and 
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------

[-- 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] 147+ messages in thread

* (no subject)
@ 2006-10-09 11:55 Timo Benk
  0 siblings, 0 replies; 147+ messages in thread
From: Timo Benk @ 2006-10-09 11:55 UTC (permalink / raw)
  To: xen-devel

Hi,

i am using two domains, which are internally connected by one virtual interface.

xendom1: Backend Domain without a physical interface
xendom2: normal Domain-U using xendom1 as a vif-Backend-Domain

 ---------      ---------
| xendom1 |    | xendom2 |
|         |    |         |
|  vif2.0--------eth0    |
|         |    |         |
 ---------      ---------

Then i add another virtual interface to xendom2.

 ---------      ---------
| xendom1 |    | xendom2 |
|         |    |         |
|  vif2.0--------eth0    |
|         |    |         |
|  vif2.1--------eth1    |
|         |    |         |
 ---------      ---------

Domain-0:~ # xm network-attach xendom2 backend=xendom1
                script=vif-nothing

---<snip>---
# /etc/xen/script/vif-nothing in Domain xendom1
dir=$(dirname "$0")
. "$dir/vif-common.sh"

success
---<snap>---

Then i save both domains:

Domain-0:~ # xm save xendom2
Domain-0:~ # xm save xendom1
Error: /usr/lib/xen/bin/xc_save 17 4 0 0 0 failed
Usage: xm save <Domain> <CheckpointFile>

Save a domain state to restore later.

Domain-0:~ # xm list
Name                       ID Mem(MiB) VCPUs State   Time(s)
Domain-0                   0      985     2 r-----     62.5
Zombie-migrating-xendom2   5      512     1 ---s-d     18.0
xendom1                    4      128     1 ---s--     19.6

Both domains are not reachable anymore, i need to destroy xendom1 and xendom2 lives another life as a zombie domain :-(

Greetings,
-timo
-- 
Timo Benk - B1 Systems GmbH (http://www.b1-systems.de)
Jabber ID: fry@jabber.org - ICQ ID: #241877854
PGP Public Key: http://m28s01.vlinux.de/b1_gpg_key.asc

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2006-07-17 14:44 Li, Xin B
  0 siblings, 0 replies; 147+ messages in thread
From: Li, Xin B @ 2006-07-17 14:44 UTC (permalink / raw)
  To: xen-devel

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

on x86_64, when guest has more than 2G memory, "startx" will cause qemu
dm die, this patch fixes it.

Signed-off-by: Xin Li <xin.b.li@intel.com>

diff -r ecb8ff1fcf1f tools/ioemu/hw/vga.c
--- a/tools/ioemu/hw/vga.c  Fri Jul 14 18:53:27 2006 +0100
+++ b/tools/ioemu/hw/vga.c  Mon Jul 17 22:35:54 2006 +0800
@@ -1392,7 +1392,8 @@ static void vga_draw_graphic(VGAState *s
 static void vga_draw_graphic(VGAState *s, int full_update)
 {
     int y1, y, update, page_min, page_max, linesize, y_start,
double_scan, mask;
-    int width, height, shift_control, line_offset, page0, page1,
bwidth;
+    int width, height, shift_control, line_offset, bwidth;
+    ram_addr_t page0, page1;
     int disp_width, multi_scan, multi_run;
     uint8_t *d;
     uint32_t v, addr1, addr;

[-- Attachment #2: vga.patch --]
[-- Type: application/octet-stream, Size: 621 bytes --]

diff -r ecb8ff1fcf1f tools/ioemu/hw/vga.c
--- a/tools/ioemu/hw/vga.c	Fri Jul 14 18:53:27 2006 +0100
+++ b/tools/ioemu/hw/vga.c	Mon Jul 17 22:35:54 2006 +0800
@@ -1392,7 +1392,8 @@ static void vga_draw_graphic(VGAState *s
 static void vga_draw_graphic(VGAState *s, int full_update)
 {
     int y1, y, update, page_min, page_max, linesize, y_start, double_scan, mask;
-    int width, height, shift_control, line_offset, page0, page1, bwidth;
+    int width, height, shift_control, line_offset, bwidth;
+    ram_addr_t page0, page1;
     int disp_width, multi_scan, multi_run;
     uint8_t *d;
     uint32_t v, addr1, addr;

[-- 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] 147+ messages in thread

* (no subject)
@ 2006-06-07 23:48 vineet chadha
  0 siblings, 0 replies; 147+ messages in thread
From: vineet chadha @ 2006-06-07 23:48 UTC (permalink / raw)
  To: xen-devel, xen-users

Hi,

Compiling xen-3.0.2.2 on host redhat 2.4.18 kernel I am getting following error:


make[2]: Entering directory `/root/software/xen-3.0.2-2'
if grep "^CONFIG_MODULES=" linux-2.6.16-xen/.config ; then \
    make -C linux-2.6.16-xen ARCH=i386 modules ; \
    make -C linux-2.6.16-xen ARCH=i386
INSTALL_MOD_PATH=/root/software/xen-3.0.2-2/dist/install
modules_install ; \
fi
CONFIG_MODULES=y
make[3]: Entering directory `/root/software/xen-3.0.2-2/linux-2.6.16-xen'
  CHK     include/linux/version.h
  Building modules, stage 2.
  MODPOST
make[3]: Leaving directory `/root/software/xen-3.0.2-2/linux-2.6.16-xen'
make[3]: Entering directory `/root/software/xen-3.0.2-2/linux-2.6.16-xen'
Warning: you may need to install module-init-tools
See http://www.codemonkey.org.uk/docs/post-halloween-2.6.txt
rm: invalid option -- x
Try `rm --help' for more information.
make[3]: *** [_modinst_] Error 1
make[3]: Leaving directory `/root/software/xen-3.0.2-2/linux-2.6.16-xen'
make[2]: *** [build] Error 2
make[2]: Leaving directory `/root/software/xen-3.0.2-2'
make[1]: *** [linux-2.6-xen-install] Error 2
make[1]: Leaving directory `/root/software/xen-3.0.2-2'
make: *** [install-kernels] Error 1

Please help
-John

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2006-06-02 13:23 Kevin Tronkowski
  0 siblings, 0 replies; 147+ messages in thread
From: Kevin Tronkowski @ 2006-06-02 13:23 UTC (permalink / raw)
  To: xen-devel

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

Attached is a patch which extends vmxassist to handle two cases 
related to mode switching found while experimenting with different 
boot loaders.

The first case is use of the JMP instruction with memory location 
operands to complete a switch to protected mode. This patch adds 
emulation for this form of the JMP instruction to vmxassist.

The second case is where boot loader code does not save/restore a 
non-zero SS register across a protected mode traversal. 
Zeroing the SS register in vmxassist results in all sorts of problems 
in the domU after returning back to real mode. This patch stores 
segment register values before entering protected mode and correctly 
restores the old values (instead of an incorrect zero value) when 
reentering real mode. 

Signed-off-by Kevin Tronkowski <ktronkowski@virtualiron.com>

Kevin


[-- Attachment #2: vm86.patch --]
[-- Type: application/octet-stream, Size: 4282 bytes --]

diff -r 6993a0f91efc tools/firmware/vmxassist/vm86.c
--- a/tools/firmware/vmxassist/vm86.c	Thu Jun  1 18:10:00 2006 +0100
+++ b/tools/firmware/vmxassist/vm86.c	Thu Jun  1 16:40:28 2006 -0400
@@ -36,6 +36,8 @@
 
 static unsigned prev_eip = 0;
 enum vm86_mode mode = 0;
+
+static struct regs saved_rm_regs;
 
 #ifdef DEBUG
 int traceset = 0;
@@ -795,6 +797,8 @@ protected_mode(struct regs *regs)
 	oldctx.esp = regs->uesp;
 	oldctx.eflags = regs->eflags;
 
+	memset(&saved_rm_regs, 0, sizeof(struct regs));
+
 	/* reload all segment registers */
 	if (!load_seg(regs->cs, &oldctx.cs_base,
 				&oldctx.cs_limit, &oldctx.cs_arbytes))
@@ -808,6 +812,7 @@ protected_mode(struct regs *regs)
 		load_seg(0, &oldctx.es_base,
 			    &oldctx.es_limit, &oldctx.es_arbytes);
 		oldctx.es_sel = 0;
+		saved_rm_regs.ves = regs->ves;
 	}
 
 	if (load_seg(regs->uss, &oldctx.ss_base,
@@ -817,6 +822,7 @@ protected_mode(struct regs *regs)
 		load_seg(0, &oldctx.ss_base,
 			    &oldctx.ss_limit, &oldctx.ss_arbytes);
 		oldctx.ss_sel = 0;
+		saved_rm_regs.uss = regs->uss;
 	}
 
 	if (load_seg(regs->vds, &oldctx.ds_base,
@@ -826,6 +832,7 @@ protected_mode(struct regs *regs)
 		load_seg(0, &oldctx.ds_base,
 			    &oldctx.ds_limit, &oldctx.ds_arbytes);
 		oldctx.ds_sel = 0;
+		saved_rm_regs.vds = regs->vds;
 	}
 
 	if (load_seg(regs->vfs, &oldctx.fs_base,
@@ -835,6 +842,7 @@ protected_mode(struct regs *regs)
 		load_seg(0, &oldctx.fs_base,
 			    &oldctx.fs_limit, &oldctx.fs_arbytes);
 		oldctx.fs_sel = 0;
+		saved_rm_regs.vfs = regs->vfs;
 	}
 
 	if (load_seg(regs->vgs, &oldctx.gs_base,
@@ -844,6 +852,7 @@ protected_mode(struct regs *regs)
 		load_seg(0, &oldctx.gs_base,
 			    &oldctx.gs_limit, &oldctx.gs_arbytes);
 		oldctx.gs_sel = 0;
+		saved_rm_regs.vgs = regs->vgs;
 	}
 
 	/* initialize jump environment to warp back to protected mode */
@@ -880,16 +889,22 @@ real_mode(struct regs *regs)
 		if (regs->uss >= HIGHMEM)
 			panic("%%ss 0x%lx higher than 1MB", regs->uss);
 		regs->uss = address(regs, regs->uss, 0) >> 4;
+	} else {
+	  regs->uss = saved_rm_regs.uss;
 	}
 	if (regs->vds != 0) {
 		if (regs->vds >= HIGHMEM)
 			panic("%%ds 0x%lx higher than 1MB", regs->vds);
 		regs->vds = address(regs, regs->vds, 0) >> 4;
+	} else {
+	  regs->vds = saved_rm_regs.vds;
 	}
 	if (regs->ves != 0) {
 		if (regs->ves >= HIGHMEM)
 			panic("%%es 0x%lx higher than 1MB", regs->ves);
 		regs->ves = address(regs, regs->ves, 0) >> 4;
+	} else {
+	  regs->ves = saved_rm_regs.ves;
 	}
 
 	/* this should get us into 16-bit mode */
@@ -971,6 +986,39 @@ jmpl(struct regs *regs, int prefix)
 	} else if (mode == VM86_PROTECTED_TO_REAL) { /* jump to real mode */
 		eip = (prefix & DATA32) ? fetch32(regs) : fetch16(regs);
 		cs = fetch16(regs);
+
+		TRACE((regs, (regs->eip - n) + 1, "jmpl 0x%x:0x%x", cs, eip));
+
+                regs->cs = cs;
+                regs->eip = eip;
+		set_mode(regs, VM86_REAL);
+	} else
+		panic("jmpl");
+}
+
+static void
+jmpl_indirect(struct regs *regs, int prefix, unsigned modrm)
+{
+	unsigned n = regs->eip;
+	unsigned cs, eip;
+	unsigned addr;
+
+	addr  = operand(prefix, regs, modrm);
+
+	if (mode == VM86_REAL_TO_PROTECTED) { /* jump to protected mode */
+		eip = (prefix & DATA32) ? read32(addr) : read16(addr);
+		addr += (prefix & DATA32) ? 4 : 2;
+		cs = read16(addr);
+
+		TRACE((regs, (regs->eip - n) + 1, "jmpl 0x%x:0x%x", cs, eip));
+
+                regs->cs = cs;
+                regs->eip = eip;
+		set_mode(regs, VM86_PROTECTED);
+	} else if (mode == VM86_PROTECTED_TO_REAL) { /* jump to real mode */
+		eip = (prefix & DATA32) ? read32(addr) : read16(addr);
+		addr += (prefix & DATA32) ? 4 : 2;
+		cs = read16(addr);
 
 		TRACE((regs, (regs->eip - n) + 1, "jmpl 0x%x:0x%x", cs, eip));
 
@@ -1306,6 +1354,23 @@ opcode(struct regs *regs)
 			}
 			goto invalid;
 
+		case 0xFF: /* jmpl (indirect) */
+			if ((mode == VM86_REAL_TO_PROTECTED) ||
+			    (mode == VM86_PROTECTED_TO_REAL)) {
+			 	unsigned modrm = fetch8(regs);
+				
+				switch((modrm >> 3) & 7) {
+				case 5:
+				  jmpl_indirect(regs, prefix, modrm);
+				  return OPC_INVALID;
+
+				default:
+				  break;
+				}
+
+			}
+			goto invalid;
+
 		case 0xEB: /* short jump */
 			if ((mode == VM86_REAL_TO_PROTECTED) ||
 			    (mode == VM86_PROTECTED_TO_REAL)) {

[-- 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] 147+ messages in thread

* (no subject)
@ 2006-04-06 22:26 Nivedita Singhvi
  0 siblings, 0 replies; 147+ messages in thread
From: Nivedita Singhvi @ 2006-04-06 22:26 UTC (permalink / raw)
  To: xen-devel, openib-general; +Cc: Jiuxing Liu


[-- Attachment #1.1: Type: text/plain, Size: 913 bytes --]





Hello!

Just wanted to let everyone know Jiuxing  has populated a mercurial
tree (very kindly hosted by XenSource) with his code at the following site:

http://xenbits.xensource.com/ext/xen-smartio.hg

This contains the current source code for a xen infiniband frontend
and backend driver. The source code is in very preliminary stages
of development, just a proof of concept for now (works). We have
a long way to go.  We'd like to invite interested folks to take a look
and get involved in the continuing design and development as an
open-source community.

We will be putting up a Wiki page for this shortly on the Xen Wiki.
Stay tuned...

There is also a mailing list we set up for discussion on
virtualization of smart I/O in Xen at:

http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-smartio

However, at Ian's request we're going to contain most discussion
to xen-devel itself.


thanks,
Nivedita

[-- Attachment #1.2: Type: text/html, Size: 1194 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2006-02-10  8:55 Li, Xin B
  0 siblings, 0 replies; 147+ messages in thread
From: Li, Xin B @ 2006-02-10  8:55 UTC (permalink / raw)
  To: leendert; +Cc: xen-devel

Leendert, when I'm reading the vmxassist code, I think we need this
patch, can you take a look for me?
Thanks
-Xin

diff -r 47013962e411 tools/firmware/vmxassist/setup.c
--- a/tools/firmware/vmxassist/setup.c  Fri Feb 10 02:23:36 2006
+++ b/tools/firmware/vmxassist/setup.c  Fri Feb 10 15:28:17 2006
@@ -363,7 +363,7 @@

        initialize_real_mode = 1;
        cr0 = get_cr0();
-#ifndef TEST
+#ifdef TEST
        set_cr0(cr0 | CR0_PE);
 #endif
        set_cr0(cr0 & ~CR0_PE);

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2005-11-19 22:44 Purav Saraiya
  0 siblings, 0 replies; 147+ messages in thread
From: Purav Saraiya @ 2005-11-19 22:44 UTC (permalink / raw)
  To: xen-devel

I am facing problems with debugging DomU.

I have made changes in the gdt table in the file head.S for Dom U. Because
of that the domain is crashing.

For debugging, I followed the steps mentioned in the file
/xen-unstable/tools/debugger/gdb/README. I also made changes in the
/xen/Rules.mk file and compiled domU with -g C flag.

However, as mentioned in the README file no
/var/xen/dump/<Domain-name>.<DomainID>.core file is generated.

Rules.mk file :
verbose     ?= y
debug       ?= y
perfc       ?= n
perfc_arrays?= n
domu_debug  ?= y
crash_debug ?= y

Am I missing something?

Thanks for replies.
-Purav

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2005-10-02  2:59 Prashanth Radhakrishnan
  0 siblings, 0 replies; 147+ messages in thread
From: Prashanth Radhakrishnan @ 2005-10-02  2:59 UTC (permalink / raw)
  To: mvrable; +Cc: xen-devel

> Yes, I'm still working on it.  The focus of that work was copy-on-write
> sharing of memory for the purposes of building a (virtual) network of
> honeypot systems.  We have a paper in SOSP this year, talking about that
> work and the copy-on-write memory implementation.  See
>     http://www.cs.ucsd.edu/~mvrable/papers/2005-sosp-potemkin.pdf
> for some information.
>
> I'm presently working on updating and cleaning that work up.
>
> --Michael Vrable

Thanks for the info, Michael. Just wondering if this code has been checked 
into the Xen-unstable branch, or around when it would be checked in.
(I din't find any related checkin by searching at 
http://lists.xensource.com/archives/html/xen-changelog/)

thanks again,
prashanth

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2005-09-29  5:55 Li, Chengyuan
  0 siblings, 0 replies; 147+ messages in thread
From: Li, Chengyuan @ 2005-09-29  5:55 UTC (permalink / raw)
  To: xen-devel

[-- Attachment #1: Type: text/plain, Size: 244 bytes --]


Set guest selectors to be null if it's not valid when switch to
protected-mode in the guest firmware.

Signed-off-by: Chengyuan Li <chengyuan.li@intel.com>
Signed-off-by: Asit Mallick <asit.k.mallick@intel.com>


Thanks,
Chengyuan


[-- Attachment #2: vmxassist_selector.patch --]
[-- Type: application/octet-stream, Size: 2097 bytes --]

diff -r f069a06e650f tools/firmware/vmxassist/vm86.c
--- a/tools/firmware/vmxassist/vm86.c	Wed Sep 28 21:18:30 2005
+++ b/tools/firmware/vmxassist/vm86.c	Thu Sep 29 12:59:36 2005
@@ -470,10 +470,21 @@
 	unsigned long long entry;
 
 	/* protected mode: use seg as index into gdt */
-	if (sel == 0 || sel > oldctx.gdtr_limit)
+	if (sel > oldctx.gdtr_limit)
 		return 0;
 
+    if (sel == 0) {
+        arbytes->fields.null_bit = 1;
+        return 1;
+    }
+
 	entry =  ((unsigned long long *) oldctx.gdtr_base)[sel >> 3];
+
+    /* Check the P bit fisrt*/
+    if (!((entry >> (15+32)) & 0x1) && sel != 0) {
+        return 0;
+    }
+
 	*base =  (((entry >> (56-24)) & 0xFF000000) |
 		  ((entry >> (32-16)) & 0x00FF0000) |
 		  ((entry >> (   16)) & 0x0000FFFF));
@@ -519,22 +530,42 @@
 	if (load_seg(regs->ves, &oldctx.es_base,
 				&oldctx.es_limit, &oldctx.es_arbytes))
 		oldctx.es_sel = regs->ves;
+    else {
+        load_seg(0, &oldctx.es_base,&oldctx.es_limit, &oldctx.es_arbytes);
+        oldctx.es_sel = 0;
+    }
 
 	if (load_seg(regs->uss, &oldctx.ss_base,
 				&oldctx.ss_limit, &oldctx.ss_arbytes))
 		oldctx.ss_sel = regs->uss;
+    else {
+        load_seg(0, &oldctx.ss_base, &oldctx.ss_limit, &oldctx.ss_arbytes);
+        oldctx.ss_sel = 0;
+    }
 
 	if (load_seg(regs->vds, &oldctx.ds_base,
 				&oldctx.ds_limit, &oldctx.ds_arbytes))
 		oldctx.ds_sel = regs->vds;
+    else {
+        load_seg(0, &oldctx.ds_base, &oldctx.ds_limit, &oldctx.ds_arbytes);
+        oldctx.ds_sel = 0;
+    }
 
 	if (load_seg(regs->vfs, &oldctx.fs_base,
 				&oldctx.fs_limit, &oldctx.fs_arbytes))
 		oldctx.fs_sel = regs->vfs;
+    else {
+        load_seg(0, &oldctx.fs_base, &oldctx.fs_limit, &oldctx.fs_arbytes);
+        oldctx.fs_sel = 0;
+    }
 
 	if (load_seg(regs->vgs, &oldctx.gs_base,
 				&oldctx.gs_limit, &oldctx.gs_arbytes))
 		oldctx.gs_sel = regs->vgs;
+    else {
+        load_seg(0, &oldctx.gs_base, &oldctx.gs_limit, &oldctx.gs_arbytes);
+        oldctx.gs_sel = 0;
+    }
 
 	/* initialize jump environment to warp back to protected mode */
 	regs->cs = CODE_SELECTOR;

[-- 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] 147+ messages in thread

* Re: (no subject)
  2005-09-23 19:07 Magenheimer, Dan (HP Labs Fort Collins)
@ 2005-09-24  0:28 ` Christian Limpach
  0 siblings, 0 replies; 147+ messages in thread
From: Christian Limpach @ 2005-09-24  0:28 UTC (permalink / raw)
  To: Magenheimer, Dan (HP Labs Fort Collins); +Cc: xen-devel

On 9/23/05, Magenheimer, Dan (HP Labs Fort Collins)
<dan.magenheimer@hp.com> wrote:
> Oops, I tried it only using a cross-compiler.  When I compiled
> natively on ia64, it is still necessary to specify
> LINUX_ARCH=ia64 on the make-line, else I get x86 configs.
>
> I think the fix is to change in buildconfig/Rules.mk from
>
> ifneq ($(ARCH),ia64)
>  to
> ifneq ($(XEN_TARGET_ARCH),ia64)
>
> I'll roll this fix in at the next merge with xen-ia64-unstable.

Yes, thanks!

    christian

^ permalink raw reply	[flat|nested] 147+ messages in thread

* RE: (no subject)
@ 2005-09-23 19:07 Magenheimer, Dan (HP Labs Fort Collins)
  2005-09-24  0:28 ` Christian Limpach
  0 siblings, 1 reply; 147+ messages in thread
From: Magenheimer, Dan (HP Labs Fort Collins) @ 2005-09-23 19:07 UTC (permalink / raw)
  To: Christian Limpach; +Cc: xen-devel

> -----Original Message-----
> From: Magenheimer, Dan (HP Labs Fort Collins) 
> Sent: Wednesday, September 21, 2005 2:50 PM
> To: 'Christian Limpach'
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] (no subject)
> 
> > > I suppose it would be nice if on ia64 just 'make' did the
> > > right thing, e.g. set LINUX_ARCH=ia64 without the need to
> > > specify it on the command line.  In that case, adding it
> > > to all the calls to mkbuildtree is necessary.  How do
> > > I set LINUX_ARCH in Rules.mk so that it is set to 'xen'
> > > if x86 (or x86_64) and the architecture it is running on
> > > (e.g. ia64) otherwise?
> > 
> > I'll check it in tomorrow, and I'll make it set LINUX_ARCH
> > dependent on ARCH, like you did in your original patch...
> 
> Thanks very much!  I tried it and it works great!  Using
> this, I have started committing files into the ia64 subdirs
> of -sparse in xen-ia64-unstable.hg which will be pulled
> into the xen-unstable tree at the next sync.  I have already
> built and tested a "driver-less" domain0 from -sparse.

Oops, I tried it only using a cross-compiler.  When I compiled
natively on ia64, it is still necessary to specify
LINUX_ARCH=ia64 on the make-line, else I get x86 configs.

I think the fix is to change in buildconfig/Rules.mk from

ifneq ($(ARCH),ia64)
  to
ifneq ($(XEN_TARGET_ARCH),ia64)

I'll roll this fix in at the next merge with xen-ia64-unstable.

Thanks,
Dan

^ permalink raw reply	[flat|nested] 147+ messages in thread

* RE: (no subject)
@ 2005-09-21 20:49 Magenheimer, Dan (HP Labs Fort Collins)
  0 siblings, 0 replies; 147+ messages in thread
From: Magenheimer, Dan (HP Labs Fort Collins) @ 2005-09-21 20:49 UTC (permalink / raw)
  To: Christian Limpach; +Cc: xen-devel

> > I suppose it would be nice if on ia64 just 'make' did the
> > right thing, e.g. set LINUX_ARCH=ia64 without the need to
> > specify it on the command line.  In that case, adding it
> > to all the calls to mkbuildtree is necessary.  How do
> > I set LINUX_ARCH in Rules.mk so that it is set to 'xen'
> > if x86 (or x86_64) and the architecture it is running on
> > (e.g. ia64) otherwise?
> 
> I'll check it in tomorrow, and I'll make it set LINUX_ARCH
> dependent on ARCH, like you did in your original patch...

Thanks very much!  I tried it and it works great!  Using
this, I have started committing files into the ia64 subdirs
of -sparse in xen-ia64-unstable.hg which will be pulled
into the xen-unstable tree at the next sync.  I have already
built and tested a "driver-less" domain0 from -sparse.

Dan

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2005-09-19 20:52 Magenheimer, Dan (HP Labs Fort Collins)
@ 2005-09-19 21:18 ` Christian Limpach
  0 siblings, 0 replies; 147+ messages in thread
From: Christian Limpach @ 2005-09-19 21:18 UTC (permalink / raw)
  To: Magenheimer, Dan (HP Labs Fort Collins); +Cc: xen-devel

On Mon, Sep 19, 2005 at 01:52:36PM -0700, Magenheimer, Dan (HP Labs Fort Collins) wrote:
> > Rules.mk is fine.  What I meant is that LINUX_ARCH won't get
> > passed to mkbuildtree unless you add it to its environment.
> > I confirmed this now by adding this to mkbuildtree:
> > echo ${LINUX_ARCH} >>/tmp/xxxxxxxx
> > LINUX_ARCH is empty and thus your hook script won't run.  Maybe
> > you have LINUX_ARCH set in your shell environment where you ran
> > make?  Odd...
> 
> No, it's not in my shell environment.  However, when I run make
> to build for ia64 I run it as: 'make LINUX_ARCH=ia64 ...' and
> I'm guessing make must export it to subshells.  If I add the
> 'echo', I do get ia64 in /tmp/xxxxxx and the ia64 hook scripts
> do get run.

Yes, that explains it.

> I suppose it would be nice if on ia64 just 'make' did the
> right thing, e.g. set LINUX_ARCH=ia64 without the need to
> specify it on the command line.  In that case, adding it
> to all the calls to mkbuildtree is necessary.  How do
> I set LINUX_ARCH in Rules.mk so that it is set to 'xen'
> if x86 (or x86_64) and the architecture it is running on
> (e.g. ia64) otherwise?

I'll check it in tomorrow, and I'll make it set LINUX_ARCH
dependent on ARCH, like you did in your original patch...

Thanks!

    christian

^ permalink raw reply	[flat|nested] 147+ messages in thread

* RE: (no subject)
@ 2005-09-19 20:52 Magenheimer, Dan (HP Labs Fort Collins)
  2005-09-19 21:18 ` Christian Limpach
  0 siblings, 1 reply; 147+ messages in thread
From: Magenheimer, Dan (HP Labs Fort Collins) @ 2005-09-19 20:52 UTC (permalink / raw)
  To: Christian Limpach; +Cc: xen-devel

> > > You have to export LINUX_ARCH to the script.  We don't want to
> > > unconditionally polute the environment of all the commands we
> > > run, so you'll have to add it to all the calls to mkbuildtree.
> > 
> > I'm not sure I follow... I don't know exactly how make or bash
> > work wrt to exporting... I didn't explicitly export LINUX_ARCH
> > but it seems to be known by mkbuildtree and all the mk.linux's
> > anyway.  (I successfully built for x86 and ia64 with the
> > patch.)
> > 
> > Or are you suggesting I *not* define it in buildconfigs/Rules.mk
> > so as to avoid polluting the environment?
> 
> Rules.mk is fine.  What I meant is that LINUX_ARCH won't get
> passed to mkbuildtree unless you add it to its environment.
> I confirmed this now by adding this to mkbuildtree:
> echo ${LINUX_ARCH} >>/tmp/xxxxxxxx
> LINUX_ARCH is empty and thus your hook script won't run.  Maybe
> you have LINUX_ARCH set in your shell environment where you ran
> make?  Odd...

No, it's not in my shell environment.  However, when I run make
to build for ia64 I run it as: 'make LINUX_ARCH=ia64 ...' and
I'm guessing make must export it to subshells.  If I add the
'echo', I do get ia64 in /tmp/xxxxxx and the ia64 hook scripts
do get run.

But if I build (for xen/x86) with just 'make', nothing gets
echoed to the file and, as you pointed out, no hook script
gets run.  But that's the default behavior we want, correct?

I suppose it would be nice if on ia64 just 'make' did the
right thing, e.g. set LINUX_ARCH=ia64 without the need to
specify it on the command line.  In that case, adding it
to all the calls to mkbuildtree is necessary.  How do
I set LINUX_ARCH in Rules.mk so that it is set to 'xen'
if x86 (or x86_64) and the architecture it is running on
(e.g. ia64) otherwise?

So I think the patch is OK as is... I've built successfully
for both x86 and ia64... but I can still change it and
resubmit if you prefer the other way.

Thanks,
Dan

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2005-09-19 19:20 Magenheimer, Dan (HP Labs Fort Collins)
@ 2005-09-19 19:58 ` Christian Limpach
  0 siblings, 0 replies; 147+ messages in thread
From: Christian Limpach @ 2005-09-19 19:58 UTC (permalink / raw)
  To: Magenheimer, Dan (HP Labs Fort Collins); +Cc: xen-devel

On Mon, Sep 19, 2005 at 12:20:41PM -0700, Magenheimer, Dan (HP Labs Fort Collins) wrote:
> > > OK, I see.  This cleans it up nicely. New patch attached.
> > 
> > You have to export LINUX_ARCH to the script.  We don't want to
> > unconditionally polute the environment of all the commands we
> > run, so you'll have to add it to all the calls to mkbuildtree.
> 
> I'm not sure I follow... I don't know exactly how make or bash
> work wrt to exporting... I didn't explicitly export LINUX_ARCH
> but it seems to be known by mkbuildtree and all the mk.linux's
> anyway.  (I successfully built for x86 and ia64 with the
> patch.)
> 
> Or are you suggesting I *not* define it in buildconfigs/Rules.mk
> so as to avoid polluting the environment?

Rules.mk is fine.  What I meant is that LINUX_ARCH won't get
passed to mkbuildtree unless you add it to its environment.
I confirmed this now by adding this to mkbuildtree:
echo ${LINUX_ARCH} >>/tmp/xxxxxxxx
LINUX_ARCH is empty and thus your hook script won't run.  Maybe
you have LINUX_ARCH set in your shell environment where you ran
make?  Odd...

> That's OK with me.  If enlightenment (is that a bad word in
> Xen land now?) from the above requires me to re-generate
> the patch, I will change the names.

Cheers!

   christian

^ permalink raw reply	[flat|nested] 147+ messages in thread

* RE: (no subject)
@ 2005-09-19 19:20 Magenheimer, Dan (HP Labs Fort Collins)
  2005-09-19 19:58 ` Christian Limpach
  0 siblings, 1 reply; 147+ messages in thread
From: Magenheimer, Dan (HP Labs Fort Collins) @ 2005-09-19 19:20 UTC (permalink / raw)
  To: Christian Limpach; +Cc: xen-devel

> > > Please define LINUX_ARCH in buildconfigs/Rules.mk and use 
> that where
> > > we run make ARCH=xen.
> > > If you can name your config file xen0_defconfig_ia64 and use
> > > LINUX_ARCH for the path, then you won't need to duplicate 
> the config
> > > file code.
> > 
> > OK, I see.  This cleans it up nicely. New patch attached.
> 
> You have to export LINUX_ARCH to the script.  We don't want to
> unconditionally polute the environment of all the commands we
> run, so you'll have to add it to all the calls to mkbuildtree.

I'm not sure I follow... I don't know exactly how make or bash
work wrt to exporting... I didn't explicitly export LINUX_ARCH
but it seems to be known by mkbuildtree and all the mk.linux's
anyway.  (I successfully built for x86 and ia64 with the
patch.)

Or are you suggesting I *not* define it in buildconfigs/Rules.mk
so as to avoid polluting the environment?
 
> I think I'd prefer xen-mkbuildtree-{pre,post} as the name of 
> the scripts
> to run, but not too fussed about that...

That's OK with me.  If enlightenment (is that a bad word in
Xen land now?) from the above requires me to re-generate
the patch, I will change the names.

Thanks!
Dan

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2005-09-19 16:49 Magenheimer, Dan (HP Labs Fort Collins)
@ 2005-09-19 17:39 ` Christian Limpach
  0 siblings, 0 replies; 147+ messages in thread
From: Christian Limpach @ 2005-09-19 17:39 UTC (permalink / raw)
  To: Magenheimer, Dan (HP Labs Fort Collins); +Cc: xen-devel

On Mon, Sep 19, 2005 at 09:49:05AM -0700, Magenheimer, Dan (HP Labs Fort Collins) wrote:
> > Please define LINUX_ARCH in buildconfigs/Rules.mk and use that where
> > we run make ARCH=xen.
> > If you can name your config file xen0_defconfig_ia64 and use
> > LINUX_ARCH for the path, then you won't need to duplicate the config
> > file code.
> 
> OK, I see.  This cleans it up nicely. New patch attached.

You have to export LINUX_ARCH to the script.  We don't want to
unconditionally polute the environment of all the commands we
run, so you'll have to add it to all the calls to mkbuildtree.

I think I'd prefer xen-mkbuildtree-{pre,post} as the name of the scripts
to run, but not too fussed about that...

> Do the changes have no impact to non-Xen non-x86 kernels?
> Since xenlinux/ia64 is transparently paravirtualized,
> the changes looked like they might be xen-specific, and
> xenlinux/ia64 has been running out-of-tree without any
> of those changes, the script moves them aside.  If there's
> no impact, I can move them back in (but will probably
> do so slowly for testing purposes).
> 
> In any case, drivers/xen definitely is not yet fully
> archdep, so I need to use the pre- or post-mkbuildtree
> to do some patching in the short term.  Agree in the longer
> term, these files should be empty but if you don't mind
> greatly, having the archdep hooks there will probably
> make things easier for arch's for now.

Ok, let's go with the pre/post link scripts for now, but I think
it would be good to make our changes work when building non-x86/non-xen.

    christian

^ permalink raw reply	[flat|nested] 147+ messages in thread

* RE: (no subject)
@ 2005-09-19 16:57 Magenheimer, Dan (HP Labs Fort Collins)
  0 siblings, 0 replies; 147+ messages in thread
From: Magenheimer, Dan (HP Labs Fort Collins) @ 2005-09-19 16:57 UTC (permalink / raw)
  To: Christian.Limpach; +Cc: Jerone Young, xen-devel

> > > Why are you piping in tons of nothing into Make here 
> using the "yes"
> > > command?
> > 
> > This mechanically does the same as manually hitting
> > "enter" at every prompt from "make oldconfig", thus it
> > applies the default response for every unconfigured
> > option without manual intervention.
> 
> I think it's preferable to have default config files which don't cause
> any prompting.
> 
> Also if people upgrade, they probably want to be prompted on any new
> options.  If not, then let's get the default behaviour for "make
> oldconfig" changed upstream...

I've just used this for convenience.  The defconfigs in
Linux/ia64 cause prompting and the config change required for
Xen/ia64 support (because it is transparently paravirtualized)
is adding "CONFIG_XEN=y".  But I can easily put the output
of make oldconfig in the xen defconfig file if the
preference is to have no prompting (thus the "yes" pipe
is removed from the previously posted patch).

Thanks,
Dan

^ permalink raw reply	[flat|nested] 147+ messages in thread

* RE: (no subject)
@ 2005-09-19 16:49 Magenheimer, Dan (HP Labs Fort Collins)
  2005-09-19 17:39 ` Christian Limpach
  0 siblings, 1 reply; 147+ messages in thread
From: Magenheimer, Dan (HP Labs Fort Collins) @ 2005-09-19 16:49 UTC (permalink / raw)
  To: xen-devel; +Cc: Christian.Limpach

[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]

(Sorry about the "no subject" in the original message...
fat fingers on my part.)

> Please define LINUX_ARCH in buildconfigs/Rules.mk and use that where
> we run make ARCH=xen.
> If you can name your config file xen0_defconfig_ia64 and use
> LINUX_ARCH for the path, then you won't need to duplicate the config
> file code.

OK, I see.  This cleans it up nicely. New patch attached.

> Please also change all mk.linux files.

Done.

> > 2) A sequence of mkbuildtree "massage" commands need to
> >   be executed before mkbuildtree does its linking thing.
> >   Perhaps this could be done as:
> >    if -e mkbuildtree.prelink.$XENARCH
> >        mkbuildtree.prelink.$XENARCH
> >   Though ia64 doesn't need it, maybe also add a "postlink"
> >   equivalent?
> 
> Why do you need to move these out of the way in the first place?  If
> any of the changes we've made break ia64, then we should cleanup our
> changes.

Do the changes have no impact to non-Xen non-x86 kernels?
Since xenlinux/ia64 is transparently paravirtualized,
the changes looked like they might be xen-specific, and
xenlinux/ia64 has been running out-of-tree without any
of those changes, the script moves them aside.  If there's
no impact, I can move them back in (but will probably
do so slowly for testing purposes).

In any case, drivers/xen definitely is not yet fully
archdep, so I need to use the pre- or post-mkbuildtree
to do some patching in the short term.  Agree in the longer
term, these files should be empty but if you don't mind
greatly, having the archdep hooks there will probably
make things easier for arch's for now.

> > Could someone with the necessary build knowledge make
> > the improvements and commit this please? Let me know if/when
> > it goes in and I will populate the ia64 -sparse branches.
> 
> Please give creating a patch another try, taking the suggestions above
> into consideration.  Thanks!

OK, let me know if this is better.

Thanks,
Dan

[-- Attachment #2: xenia64sparse2 --]
[-- Type: application/octet-stream, Size: 7395 bytes --]

diff -r ec01850d0ee9 buildconfigs/Rules.mk
--- a/buildconfigs/Rules.mk	Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/Rules.mk	Mon Sep 19 10:45:52 2005
@@ -14,6 +14,9 @@
 # Setup pristine search path
 PRISTINE_SRC_PATH	?= .:..
 vpath pristine-% $(PRISTINE_SRC_PATH)
+
+# By default, build Linux with ARCH=xen (overridden by some non arch's)
+LINUX_ARCH	?= xen
 
 # Expand Linux series to Linux version
 LINUX_SERIES	?= 2.6
diff -r ec01850d0ee9 buildconfigs/mk.linux-2.4-xenU
--- a/buildconfigs/mk.linux-2.4-xenU	Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/mk.linux-2.4-xenU	Mon Sep 19 10:45:52 2005
@@ -15,10 +15,10 @@
 # The real action starts here!
 build: $(LINUX_DIR)/include/linux/autoconf.h
 	if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) modules ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
 	fi
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_PATH=$(DESTDIR) install
 
 $(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
 	rm -rf $(LINUX_DIR)
@@ -36,16 +36,16 @@
 	( cd $(LINUX_DIR) ; \
 	  sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
 	  rm -f Makefile ; mv Mk.tmp Makefile )
-	make -C $(LINUX_DIR) ARCH=xen oldconfig
-	make -C $(LINUX_DIR) ARCH=xen dep
+	make -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) oldconfig
+	make -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) dep
 
 config: CONFIGMODE = menuconfig
 config: $(LINUX_DIR)/include/linux/autoconf.h
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen dep
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) $(CONFIGMODE)
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) dep
 
 clean::
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) clean
 
 delete: 
 	rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR) 
diff -r ec01850d0ee9 buildconfigs/mk.linux-2.6-xen
--- a/buildconfigs/mk.linux-2.6-xen	Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/mk.linux-2.6-xen	Mon Sep 19 10:45:52 2005
@@ -15,10 +15,10 @@
 # The real action starts here!
 build: $(LINUX_DIR)/include/linux/autoconf.h
 	if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) modules ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
 	fi
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_PATH=$(DESTDIR) install
 
 $(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
 	rm -rf $(LINUX_DIR)
@@ -38,14 +38,14 @@
 	( cd $(LINUX_DIR) ; \
 	  sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
 	  rm -f Makefile ; mv Mk.tmp Makefile )
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen oldconfig
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) oldconfig
 
 config: CONFIGMODE = menuconfig
 config: $(LINUX_DIR)/include/linux/autoconf.h
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) $(CONFIGMODE)
 
 clean::
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) clean
 
 delete: 
 	rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR) 
diff -r ec01850d0ee9 buildconfigs/mk.linux-2.6-xen0
--- a/buildconfigs/mk.linux-2.6-xen0	Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/mk.linux-2.6-xen0	Mon Sep 19 10:45:52 2005
@@ -15,10 +15,10 @@
 # The real action starts here!
 build: $(LINUX_DIR)/include/linux/autoconf.h
 	if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) modules ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
 	fi
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_PATH=$(DESTDIR) install
 
 $(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
 	rm -rf $(LINUX_DIR)
@@ -38,14 +38,14 @@
 	( cd $(LINUX_DIR) ; \
 	  sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
 	  rm -f Makefile ; mv Mk.tmp Makefile )
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen oldconfig
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) oldconfig
 
 config: CONFIGMODE = menuconfig
 config: $(LINUX_DIR)/include/linux/autoconf.h
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) $(CONFIGMODE)
 
 clean::
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) clean
 
 delete: 
 	rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR) 
diff -r ec01850d0ee9 buildconfigs/mk.linux-2.6-xenU
--- a/buildconfigs/mk.linux-2.6-xenU	Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/mk.linux-2.6-xenU	Mon Sep 19 10:45:52 2005
@@ -15,10 +15,10 @@
 # The real action starts here!
 build: $(LINUX_DIR)/include/linux/autoconf.h
 	if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) modules ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
 	fi
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_PATH=$(DESTDIR) install
 
 $(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
 	rm -rf $(LINUX_DIR)
@@ -38,14 +38,14 @@
 	( cd $(LINUX_DIR) ; \
 	  sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
 	  rm -f Makefile ; mv Mk.tmp Makefile )
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen oldconfig
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) oldconfig
 
 config: CONFIGMODE = menuconfig
 config: $(LINUX_DIR)/include/linux/autoconf.h
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) $(CONFIGMODE)
 
 clean::
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) clean
 
 delete: 
 	rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR) 
diff -r ec01850d0ee9 linux-2.6-xen-sparse/mkbuildtree
--- a/linux-2.6-xen-sparse/mkbuildtree	Mon Sep 19 15:21:09 2005
+++ b/linux-2.6-xen-sparse/mkbuildtree	Mon Sep 19 10:45:52 2005
@@ -89,6 +89,11 @@
 abs_to_rel ${AD} ${AS}
 RS=$DESTPATH
 
+# Arch-specific pre-processing
+if [ -x arch/${LINUX_ARCH}/xen-pre-mkbuildtree ]; then
+	arch/${LINUX_ARCH}/xen-pre-mkbuildtree
+fi
+
 # Remove old copies of files and directories at the destination
 for i in `find . -type f -o -type l` ; do rm -f ${AD}/${i#./} ; done
 
@@ -110,3 +115,10 @@
 
 cd ${AD}/include/asm-xen/linux-public
 ln -sf ../../../${RS}/../tools/xenstore/xenstored.h
+
+# Arch-specific post-processing
+cd ${AD}
+if [ -x arch/${LINUX_ARCH}/xen-post-mkbuildtree ]; then
+	arch/${LINUX_ARCH}/xen-post-mkbuildtree
+fi
+

[-- 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] 147+ messages in thread

* Re: (no subject)
  2005-09-19 15:29 Magenheimer, Dan (HP Labs Fort Collins)
@ 2005-09-19 16:09 ` Christian Limpach
  0 siblings, 0 replies; 147+ messages in thread
From: Christian Limpach @ 2005-09-19 16:09 UTC (permalink / raw)
  To: Magenheimer, Dan (HP Labs Fort Collins); +Cc: Jerone Young, xen-devel

On 9/19/05, Magenheimer, Dan (HP Labs Fort Collins)
<dan.magenheimer@hp.com> wrote:
> > On Mon, 2005-09-19 at 06:43 -0700, Magenheimer, Dan (HP Labs Fort
> > Collins) wrote:
> >
> > > +ifeq ($(ARCH),ia64)
> > > +       yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
> > > +else
> >
> > Why are you piping in tons of nothing into Make here using the "yes"
> > command?
> 
> This mechanically does the same as manually hitting
> "enter" at every prompt from "make oldconfig", thus it
> applies the default response for every unconfigured
> option without manual intervention.

I think it's preferable to have default config files which don't cause
any prompting.

Also if people upgrade, they probably want to be prompted on any new
options.  If not, then let's get the default behaviour for "make
oldconfig" changed upstream...

    christian

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2005-09-19 14:30 ` Jerone Young
@ 2005-09-19 15:34   ` Mark Williamson
  0 siblings, 0 replies; 147+ messages in thread
From: Mark Williamson @ 2005-09-19 15:34 UTC (permalink / raw)
  To: xen-devel; +Cc: Magenheimer, Dan (HP Labs Fort Collins), Jerone Young

> Collins) wrote:
> > +ifeq ($(ARCH),ia64)
> > +       yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
> > +else
>
> Why are you piping in tons of nothing into Make here using the "yes"
> command?

I guess, to answer <ret> (choose default) to any questions oldconfig throws 
up.

Cheers,
Mark

^ permalink raw reply	[flat|nested] 147+ messages in thread

* RE: (no subject)
@ 2005-09-19 15:29 Magenheimer, Dan (HP Labs Fort Collins)
  2005-09-19 16:09 ` Christian Limpach
  0 siblings, 1 reply; 147+ messages in thread
From: Magenheimer, Dan (HP Labs Fort Collins) @ 2005-09-19 15:29 UTC (permalink / raw)
  To: Jerone Young; +Cc: xen-devel

> On Mon, 2005-09-19 at 06:43 -0700, Magenheimer, Dan (HP Labs Fort
> Collins) wrote:
> 
> > +ifeq ($(ARCH),ia64)
> > +       yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
> > +else
> 
> Why are you piping in tons of nothing into Make here using the "yes"
> command? 

This mechanically does the same as manually hitting
"enter" at every prompt from "make oldconfig", thus it
applies the default response for every unconfigured
option without manual intervention.

Dan

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2005-09-19 13:43 Magenheimer, Dan (HP Labs Fort Collins)
  2005-09-19 14:18 ` Christian Limpach
@ 2005-09-19 14:30 ` Jerone Young
  2005-09-19 15:34   ` Mark Williamson
  1 sibling, 1 reply; 147+ messages in thread
From: Jerone Young @ 2005-09-19 14:30 UTC (permalink / raw)
  To: Magenheimer, Dan (HP Labs Fort Collins); +Cc: xen-devel

On Mon, 2005-09-19 at 06:43 -0700, Magenheimer, Dan (HP Labs Fort
Collins) wrote:

> +ifeq ($(ARCH),ia64)
> +       yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
> +else

Why are you piping in tons of nothing into Make here using the "yes"
command? 

-- 
Jerone Young
IBM Linux Technology Center
jyoung5@us.ibm.com
512-838-1157 (T/L: 678-1157)

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2005-09-19 13:43 Magenheimer, Dan (HP Labs Fort Collins)
@ 2005-09-19 14:18 ` Christian Limpach
  2005-09-19 14:30 ` Jerone Young
  1 sibling, 0 replies; 147+ messages in thread
From: Christian Limpach @ 2005-09-19 14:18 UTC (permalink / raw)
  To: Magenheimer, Dan (HP Labs Fort Collins); +Cc: xen-devel

On 9/19/05, Magenheimer, Dan (HP Labs Fort Collins)
<dan.magenheimer@hp.com> wrote:
> The primary changes are:
> 1) wherever a make is done with ARCH=xen, this needs
>   to be converted to ARCH=ia64.  (This can probably
>   be done as ARCH=$(XENARCH) or something like that
>   but I'm not sure how to do it without requiring x86
>   and x86_64 builds to specify XENARCH= at build time.)

Please define LINUX_ARCH in buildconfigs/Rules.mk and use that where
we run make ARCH=xen.
If you can name your config file xen0_defconfig_ia64 and use
LINUX_ARCH for the path, then you won't need to duplicate the config
file code.
Please also change all mk.linux files.

> 2) A sequence of mkbuildtree "massage" commands need to
>   be executed before mkbuildtree does its linking thing.
>   Perhaps this could be done as:
>    if -e mkbuildtree.prelink.$XENARCH
>        mkbuildtree.prelink.$XENARCH
>   Though ia64 doesn't need it, maybe also add a "postlink"
>   equivalent?

Why do you need to move these out of the way in the first place?  If
any of the changes we've made break ia64, then we should cleanup our
changes.

> Could someone with the necessary build knowledge make
> the improvements and commit this please? Let me know if/when
> it goes in and I will populate the ia64 -sparse branches.

Please give creating a patch another try, taking the suggestions above
into consideration.  Thanks!

    christian

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2005-09-19 13:43 Magenheimer, Dan (HP Labs Fort Collins)
  2005-09-19 14:18 ` Christian Limpach
  2005-09-19 14:30 ` Jerone Young
  0 siblings, 2 replies; 147+ messages in thread
From: Magenheimer, Dan (HP Labs Fort Collins) @ 2005-09-19 13:43 UTC (permalink / raw)
  To: xen-devel

[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]

Attached is an (ugly but relatively simple) patch that allows
Xenlinux/ia64 to be built using the linux "-sparse" tree
methodology (once I populate some files in the -sparse tree).

The changes are not dramatic and I think they can be done
much more cleanly, but I'm not a build expert so would
appreciate improvements from those more comfortable with
the Xen build environment... and perhaps it can be
made more generic so the ppc guys can benefit too.

The primary changes are:
1) wherever a make is done with ARCH=xen, this needs
   to be converted to ARCH=ia64.  (This can probably
   be done as ARCH=$(XENARCH) or something like that
   but I'm not sure how to do it without requiring x86
   and x86_64 builds to specify XENARCH= at build time.)
2) A sequence of mkbuildtree "massage" commands need to
   be executed before mkbuildtree does its linking thing.
   Perhaps this could be done as:
    if -e mkbuildtree.prelink.$XENARCH
        mkbuildtree.prelink.$XENARCH
   Though ia64 doesn't need it, maybe also add a "postlink"
   equivalent?

There is also one change because the ia64 defconfig filename
is different.  I can change this filename to conform with
the existing convention but perhaps the defconfig pathname
could be set as part of the prelink file?

Could someone with the necessary build knowledge make
the improvements and commit this please? Let me know if/when
it goes in and I will populate the ia64 -sparse branches.

Thanks,
Dan

[-- Attachment #2: xenia64sparse --]
[-- Type: application/octet-stream, Size: 3406 bytes --]

diff -r 8d133d172bfd buildconfigs/mk.linux-2.6-xen0
--- a/buildconfigs/mk.linux-2.6-xen0	Sun Sep 18 18:18:57 2005
+++ b/buildconfigs/mk.linux-2.6-xen0	Sun Sep 18 14:31:47 2005
@@ -14,11 +14,19 @@
 
 # The real action starts here!
 build: $(LINUX_DIR)/include/linux/autoconf.h
+ifeq ($(ARCH),ia64)
+	$(MAKE) -C $(LINUX_DIR) ARCH=ia64 INSTALL_PATH=$(DESTDIR) install
+	if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=ia64 modules ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=ia64 INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+	fi
+else
 	if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
 	    $(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
 	    $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
 	fi
 	$(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+endif
 
 $(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
 	rm -rf $(LINUX_DIR)
@@ -27,25 +35,45 @@
 	( cd linux-$(LINUX_SERIES)-xen-sparse ; \
           ./mkbuildtree ../$(LINUX_DIR) )
 	# Re-use config from install dir if one exits else use default config
+ifeq ($(ARCH),ia64)
+	CONFIG_VERSION=$$(sed -ne 's/^EXTRAVERSION = //p' $(LINUX_DIR)/Makefile); \
+	[ -r $(DESTDIR)/boot/config-$(LINUX_VER)$$CONFIG_VERSION-$(EXTRAVERSION) ] && \
+	  cp $(DESTDIR)/boot/config-$(LINUX_VER)$$CONFIG_VERSION-$(EXTRAVERSION) $(LINUX_DIR)/.config \
+	  || cp $(LINUX_DIR)/arch/ia64/configs/xen_zx1_defconfig \
+		$(LINUX_DIR)/.config
+else
 	CONFIG_VERSION=$$(sed -ne 's/^EXTRAVERSION = //p' $(LINUX_DIR)/Makefile); \
 	[ -r $(DESTDIR)/boot/config-$(LINUX_VER)$$CONFIG_VERSION-$(EXTRAVERSION) ] && \
 	  cp $(DESTDIR)/boot/config-$(LINUX_VER)$$CONFIG_VERSION-$(EXTRAVERSION) $(LINUX_DIR)/.config \
 	  || cp $(LINUX_DIR)/arch/xen/configs/$(EXTRAVERSION)_defconfig_$(XEN_TARGET_ARCH) \
 		$(LINUX_DIR)/.config
+endif
 	# See if we need to munge config to enable PAE
 	$(MAKE) CONFIG_FILE=$(LINUX_DIR)/.config -f buildconfigs/Rules.mk config-update-pae
 	# Patch kernel Makefile to set EXTRAVERSION
 	( cd $(LINUX_DIR) ; \
 	  sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
 	  rm -f Makefile ; mv Mk.tmp Makefile )
+ifeq ($(ARCH),ia64)
+	yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
+else
 	$(MAKE) -C $(LINUX_DIR) ARCH=xen oldconfig
+endif
 
 config: CONFIGMODE = menuconfig
 config: $(LINUX_DIR)/include/linux/autoconf.h
+ifeq ($(ARCH),ia64)
+	$(MAKE) -C $(LINUX_DIR) $(CONFIGMODE)
+else
 	$(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
+endif
 
 clean::
+ifeq ($(ARCH),ia64)
+	$(MAKE) -C $(LINUX_DIR) ARCH=ia64 clean
+else
 	$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+endif
 
 delete: 
 	rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR) 
diff -r 8d133d172bfd linux-2.6-xen-sparse/mkbuildtree
--- a/linux-2.6-xen-sparse/mkbuildtree	Sun Sep 18 18:18:57 2005
+++ b/linux-2.6-xen-sparse/mkbuildtree	Sun Sep 18 14:31:47 2005
@@ -92,6 +92,16 @@
 # Remove old copies of files and directories at the destination
 for i in `find . -type f -o -type l` ; do rm -f ${AD}/${i#./} ; done
 
+if [ "$ARCH" = "ia64" ]; then
+mv arch/xen/kernel drivers/xen/core
+mv mm mm.x86
+mv net net.x86
+mv kernel kernel.x86
+mv arch/xen arch/xen.x86
+mv include/asm-generic include/asm-generic.x86
+mv include/linux include/linux.x86
+fi
+
 # We now work from the destination directory
 cd ${AD} || { echo "cannot cd to ${AD}"; exit 1; }
 

[-- 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] 147+ messages in thread

* (no subject)
@ 2005-07-05 22:54 Igor Feoktistov
  0 siblings, 0 replies; 147+ messages in thread
From: Igor Feoktistov @ 2005-07-05 22:54 UTC (permalink / raw)
  To: xen-devel

Hi,

has anybody tried linux-iscsi-4.0.2 with linux-2.6.11-xen0?
scsi-transport-iscsi failed to compile due to different structure
definitions in scsi_transport_iscsi.h
Using scsi-transport-iscsi from linux-2.6.11-xen0 distro I was able
to open iscsi session. However, there is tons of kernel errors like below.
Any ideas how to cure it?
--
Jul  5 15:18:31 iscsi-rh4u1 kernel: SCSI device sdc: 73400320 512-byte hdwr sectors (375
Jul  5 15:18:31 iscsi-rh4u1 kernel: Badness in local_bh_enable at kernel/softirq.c:140  
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c011e495>] local_bh_enable+0x68/0x89             
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c896a742>] iscsi_queuecommand+0x173/0x1e3 [iscsi_
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c029c2f8>] scsi_dispatch_cmd+0x140/0x22e         
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c029c53a>] scsi_done+0x0/0x26                    
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c029ebdb>] scsi_times_out+0x0/0xa0               
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c02a19de>] scsi_request_fn+0x234/0x452           
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c0227bda>] __elv_add_request+0x84/0xb1           
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c022a708>] blk_insert_request+0xd7/0x104         
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c02a05aa>] scsi_insert_special_req+0x3a/0x40     
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c02a07f2>] scsi_wait_req+0x69/0x9b               
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c02a06ef>] scsi_wait_done+0x0/0x9a               
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c02a1e1d>] __scsi_mode_sense+0xc7/0x286          
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c0119be3>] vprintk+0x140/0x1b7                   
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c030fc98>] sd_read_cache_type+0x5f/0x216         
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c029bce8>] scsi_allocate_request+0x28/0x62       
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c030ff48>] sd_revalidate_disk+0xf9/0x131         
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c030fe4f>] sd_revalidate_disk+0x0/0x131          
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c030ea83>] sd_open+0x0/0xf0                      
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c0185201>] rescan_partitions+0xdd/0x103          
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c030ea83>] sd_open+0x0/0xf0                      
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c015b05c>] do_open+0x2a7/0x390                   
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c015b1c8>] blkdev_get+0x83/0x8e                  

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2005-06-26  3:26 Reiner Sailer
  0 siblings, 0 replies; 147+ messages in thread
From: Reiner Sailer @ 2005-06-26  3:26 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: xen-devel, Stefan Berger

> Message: 4
> Date: Sat, 25 Jun 2005 19:21:21 -0500
> From: Anthony Liguori <aliguori@us.ibm.com>
> Subject: Re: [Xen-devel] [PATCH] 1 of 2: default ssid to 0
> To: Stefan Berger <stefanb@us.ibm.com>
> Cc: xen-devel@lists.xensource.com
> Message-ID: <42BDF501.4090502@us.ibm.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Please make sure to increment the DOM0_INTERFACE_VERSION when this is 
> committed.

Correct. The DOM0 interface treats "non-existing" ssidref configurations 
now
differently (sets them to 0 instead of ffffffff).

> 
> Anthony Liguori
> 
> Stefan Berger wrote:

Thanks
Reiner

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2005-04-28  4:11 田冠华
  0 siblings, 0 replies; 147+ messages in thread
From: 田冠华 @ 2005-04-28  4:11 UTC (permalink / raw)
  To: xen-devel

Hello ,
    I am interested in Xen project,but  I am a stranger .
    I think it is helpful to read  the emails which the other participationers have posted .
    Could you post me some emails in which other people discussed about Xen project



Best wishes
        tianguanhua@ncic.ac.cn
          2005-04-28

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2005-04-28  4:10 田冠华
  0 siblings, 0 replies; 147+ messages in thread
From: 田冠华 @ 2005-04-28  4:10 UTC (permalink / raw)
  To: xen-devel

Hello ,
    I am interested in Xen project,but  I am a stranger .
    I have got the code of Xen project,but there is no explanation in the lines ,I can not understand the code ,

    Could you give me a document about  software construction of Xen project ,including how many modules ,how these modules are organised and etc.

   Who have designed the CPU modules ,can you shou me a light on how you organise the CPU modules?



Best wishes
        tianguanhua@ncic.ac.cn
          2005-04-28

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: (no subject)
  2005-04-18 16:43 tarawa1943
@ 2005-04-18 17:07 ` Keir Fraser
  0 siblings, 0 replies; 147+ messages in thread
From: Keir Fraser @ 2005-04-18 17:07 UTC (permalink / raw)
  To: tarawa1943; +Cc: m+Ian.Pratt, xen-devel, christopher.w.clark


On 18 Apr 2005, at 17:43, tarawa1943@comcast.net wrote:

> Thank you sir, I will check that. I did do another build with 12apr05 
> xen-unstable and it did not have the same symptom/problem, 
> xen-unstable changed around 16-17apr05, to expose this symptom on a 
> thinkpad. Will look deeper.

Not that much has been checked in since then. You could try backing out 
the local APIC code changes (checked in on 16th April) but even that 
seems unlikely to break the floppy driver, I think.

  -- Keir

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2005-04-18 16:43 tarawa1943
  2005-04-18 17:07 ` Keir Fraser
  0 siblings, 1 reply; 147+ messages in thread
From: tarawa1943 @ 2005-04-18 16:43 UTC (permalink / raw)
  To: m+Ian.Pratt; +Cc: xen-devel, christopher.w.clark

Ian

Thank you sir, I will check that. I did do another build with 12apr05 xen-unstable and it did not have the same symptom/problem, xen-unstable changed around 16-17apr05, to expose this symptom on a thinkpad. Will look deeper.

woody
========================================
Date: Mon, 18 Apr 2005 10:26:16 +0100
From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk>
Subject: RE: [Xen-devel] "Floppy drive(s): fd0 is 1.44M" 
To: <tarawa1943@comcast.net>,	<xen-devel@lists.xensource.com>
Cc: christopher.w.clark@gmail.com
Message-ID:
	<A95E2296287EAD4EB592B5DEEFCE0E9D1E3BF4@liverpoolst.ad.cl.cam.ac.uk>
Content-Type: text/plain;	charset="us-ascii"


> Subject: [Xen-devel] "Floppy drive(s): fd0 is 1.44M" 
> 
> Thanks for your response, and how would you suggest that one 
> would fix that?
> It hangs in the boot process!

Have you tried messing with the 'floppy=' parameter on the kernel
command line?
See Documentation/floppy.txt

Alternatively, just config the driver out of your kernel, to confirm
that this is what is causing the hang.

We use the floppy driver in PIO rather than DMA mode, and this is must
be causing the probe code to get confused under some circumstances.
(thinkpad floppy drives are somewhat notorious, and there's lots of work
arounds in the probe code)

Ian

^ permalink raw reply	[flat|nested] 147+ messages in thread

* RE: (no subject)
@ 2005-01-22 16:20 Ian Pratt
  0 siblings, 0 replies; 147+ messages in thread
From: Ian Pratt @ 2005-01-22 16:20 UTC (permalink / raw)
  To: Adam Heath, xen-devel

> ps: I decided to split out these patches, and send upstream, 
> before uploading
>     my deb packages.  If possible, I'd like to have these 
> applied, and a new
>     version rolled based on them.

I like all the patches. Any comments from anyone else?

I guess there's enough fixes in 2.0-testing to warrant a release,  but
I'd like to leave all the patches in testing for a couple of days to get
exercised. 

Ian


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2005-01-21 17:38 Adam Heath
  0 siblings, 0 replies; 147+ messages in thread
From: Adam Heath @ 2005-01-21 17:38 UTC (permalink / raw)
  To: xen-devel

===
Name: proper-depends.patch
Description: Use proper targets in makefiles
 A rule in make should produce only what it's target allows.  When it
 produces side-effects, things like ctrl-c and parallellism break it
 oddly.
DiffStat:
 xen/Makefile              |    9 +++++----
 xen/arch/x86/Makefile     |   14 ++++++++++----
 xen/common/Makefile       |    3 ++-
 xen/drivers/acpi/Makefile |    3 ++-
 xen/drivers/char/Makefile |    3 ++-
 xen/drivers/pci/Makefile  |    3 ++-
 6 files changed, 23 insertions(+), 12 deletions(-)
===
Description: Use proper targets in makefiles
 A rule in make should produce only what it's target allows.  When it
 produces side-effects, things like ctrl-c and parallellism break it
 oddly.

--- xen-2.0.3.orig/xen/arch/x86/Makefile
+++ xen-2.0.3/xen/arch/x86/Makefile
@@ -12,12 +12,18 @@

 OBJS := $(subst $(TARGET_SUBARCH)/asm-offsets.o,,$(OBJS))

-default: boot/$(TARGET_SUBARCH).o $(OBJS) boot/mkelf32
-	$(LD) $(LDFLAGS) -r -o arch.o $(OBJS)
-	$(LD) $(LDFLAGS) -T $(TARGET_SUBARCH)/xen.lds -N \
-	    boot/$(TARGET_SUBARCH).o $(ALL_OBJS) -o $(TARGET)-syms
+default: $(TARGET)
+
+$(TARGET): $(TARGET)-syms boot/mkelf32
 	./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x100000

+$(CURDIR)/arch.o: $(OBJS)
+	$(LD) $(LDFLAGS) -r -o $@ $(OBJS)
+
+$(TARGET)-syms: boot/$(TARGET_SUBARCH).o $(ALL_OBJS) $(TARGET_SUBARCH)/xen.lds
+	$(LD) $(LDFLAGS) -T $(TARGET_SUBARCH)/xen.lds -N \
+	    boot/$(TARGET_SUBARCH).o $(ALL_OBJS) -o $@
+
 asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
 	$(CC) $(CFLAGS) -S -o $@ $<

--- xen-2.0.3.orig/xen/common/Makefile
+++ xen-2.0.3/xen/common/Makefile
@@ -19,7 +19,8 @@
 OBJS := $(subst trace.o,,$(OBJS))
 endif

-default: $(OBJS)
+default: common.o
+common.o: $(OBJS)
 	$(LD) $(LDFLAGS) -r -o common.o $(OBJS)

 clean:
--- xen-2.0.3.orig/xen/drivers/pci/Makefile
+++ xen-2.0.3/xen/drivers/pci/Makefile
@@ -28,7 +28,8 @@
 #obj-y += syscall.o
 #endif

-default: $(OBJS)
+default: driver.o
+driver.o: $(OBJS)
 	$(LD) $(LDFLAGS) -r -o driver.o $(OBJS)

 clean:
--- xen-2.0.3.orig/xen/drivers/char/Makefile
+++ xen-2.0.3/xen/drivers/char/Makefile
@@ -1,7 +1,8 @@

 include $(BASEDIR)/Rules.mk

-default: $(OBJS)
+default: driver.o
+driver.o: $(OBJS)
 	$(LD) $(LDFLAGS) -r -o driver.o $(OBJS)

 clean:
--- xen-2.0.3.orig/xen/drivers/acpi/Makefile
+++ xen-2.0.3/xen/drivers/acpi/Makefile
@@ -6,7 +6,8 @@

 OBJS := acpi_ksyms.o tables.o

-default: $(OBJS)
+default: driver.o
+driver.o: $(OBJS)
 	$(LD) $(LDFLAGS) -r -o driver.o $(OBJS)

 clean:
--- xen-2.0.3.orig/xen/Makefile
+++ xen-2.0.3/xen/Makefile
@@ -9,14 +9,15 @@

 include Rules.mk

-default: $(TARGET)
-	gzip -f -9 < $(TARGET) > $(TARGET).gz
+default: $(TARGET).gz
+$(TARGET).gz: $(TARGET)
+	gzip -f -9 < $< > $@.new
+	mv $@.new $@

 debug:
 	objdump -D -S $(TARGET)-syms > $(TARGET).s

-install: $(TARGET)
-	gzip -f -9 < $(TARGET) > $(TARGET).gz
+install: $(TARGET).gz
 	mkdir -p $(prefix)/boot
 	install -m0644 $(TARGET).gz $(prefix)/boot
 	install -m0644 $(TARGET)-syms $(prefix)/boot




-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2005-01-21 17:35 Adam Heath
  0 siblings, 0 replies; 147+ messages in thread
From: Adam Heath @ 2005-01-21 17:35 UTC (permalink / raw)
  To: xen-devel

I spent last night and this morning splitting the single patch I had, into 13
separate patches.  Most are build system tweaks(DESTDIR, parallel make,
INSTALL, proper target depends).  Also, proper PIC support in the libs, and a
few other things.

Below is the meta-info that my patch oriented build system maintains.  I'll be
sending each patch as a separate mail(I apologize for the mail flood ahead of
time).

ps: I decided to split out these patches, and send upstream, before uploading
    my deb packages.  If possible, I'd like to have these applied, and a new
    version rolled based on them.

pps: These are generated against 2.0.3.

===
Name: proper-depends.patch
Description: Use proper targets in makefiles
 A rule in make should produce only what it's target allows.  When it
 produces side-effects, things like ctrl-c and parallellism break it
 oddly.
DiffStat:
 xen/Makefile              |    9 +++++----
 xen/arch/x86/Makefile     |   14 ++++++++++----
 xen/common/Makefile       |    3 ++-
 xen/drivers/acpi/Makefile |    3 ++-
 xen/drivers/char/Makefile |    3 ++-
 xen/drivers/pci/Makefile  |    3 ++-
 6 files changed, 23 insertions(+), 12 deletions(-)

Name: pic-lib.patch
Description: support PIC code generation
 Libraries have 2 methods of being compiled; a .so must contain non-pic
 objects, while the .a can contain standard objects.
DiffStat:
 tools/libxc/Makefile    |   34 +++++++++++++++++++++-------------
 tools/libxutil/Makefile |   11 ++++++++---
 2 files changed, 29 insertions(+), 16 deletions(-)

Name: doc-make-vars.patch
Description: Use vars for complex programs
 It's generally standard to call complex programs indirectly thru make
 variables.  This allows them to be replaced easily with alternative
 versions, without editting each makefile.
 .
 Additionally, this patch makes use of $(pkgdocdir) in docs/Makefile.
DiffStat:
 docs/Makefile |   53 +++++++++++++++++++++++++++++++++++------------------
 1 files changed, 35 insertions(+), 18 deletions(-)

Name: INSTALL.patch
Depends: proper-depends.patch, pic-lib.patch, doc-make-vars.patch
Description: use INSTALL everywhere
 Use install(by way of INSTALL variables) to create directories, install
 programs, and install data files.
DiffStat:
 Makefile                     |   22 +++++++++++++---------
 docs/Makefile                |   10 ++++++----
 tools/examples/Makefile      |   20 ++++++++++++--------
 tools/libxc/Makefile         |   12 ++++++++----
 tools/libxutil/Makefile      |    9 +++++++--
 tools/misc/Makefile          |   11 +++++++----
 tools/misc/miniterm/Makefile |    7 +++++--
 tools/sv/Makefile            |   18 ++++++++++--------
 tools/xentrace/Makefile      |   16 ++++++++++------
 tools/xfrd/Makefile          |    8 ++++++--
 xen/Makefile                 |   17 ++++++++++-------
 11 files changed, 94 insertions(+), 56 deletions(-)

Name: bash-for-mkbuildtree.patch
Description: mkbuildtree requires bash
DiffStat:
 linux-2.4.28-xen-sparse/mkbuildtree |    2 +-
 linux-2.6.10-xen-sparse/mkbuildtree |    2 +-
 netbsd-2.0-xen-sparse/mkbuildtree   |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

Name: parallel-make.patch
Depends: INSTALL.patch, proper-depends.patch
Description: support parallellism better
 Using shell for loops doesn't allow make to run it the most parallel
 modes.  Use patsubst/addsuffix tricks to make this work.
DiffStat:
 Makefile     |   60 +++++++++++++++++++++++------------------------------------
 xen/Makefile |    9 +++-----
 2 files changed, 28 insertions(+), 41 deletions(-)

Name: init-script-force-reload.patch
Description: add force-reload option
 Debian policy requires init scripts to implement force-reload.  So, alias
 that to restart.
DiffStat:
 tools/examples/init.d/xend |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

Name: fhs-paths.patch
Depends: INSTALL.patch
Description: Use FHS-compatible paths
DiffStat:
 tools/python/xen/sv/params.py     |    4 ++--
 tools/python/xen/xend/XendRoot.py |    2 +-
 tools/sv/Makefile                 |    2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

Name: linux-2.4-modules.patch
Description: conditionally call modules targets for 2.4
 There was a complaint on the mailing list about linux 2.6 not building
 if module support was disabled; a patch was done to fix this.  However,
 the same change was not done to the 2.4 files.
DiffStat:
 buildconfigs/mk.linux-2.4-xen0 |    6 ++++--
 buildconfigs/mk.linux-2.4-xenU |    6 ++++--
 2 files changed, 8 insertions(+), 4 deletions(-)

Name: python-path.patch
Description: fix path to python
 There is no python2 in debian.  Instead, use python.
DiffStat:
 tools/python/xen/xend/server/SrvServer.py |    2 +-
 tools/python/xen/xend/sxp.py              |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Name: prefix-DESTDIR.patch
Depends: INSTALL.patch, doc-make-vars.patch, fhs-paths.patch, linux-2.4-modules.patch, parallel-make.patch, pic-lib.patch, proper-depends.patch
Description: use DESTDIR correctly
 Standard makefiles always attempt to install to the root(/).  Setting
 DESTDIR is the normal way to install to an alternative location.
 .
 Setting prefix has the possibility of breaking programs, as the prefix
 may have been embedded inside a compiled binary.
DiffStat:
 Makefile                       |   11 ++++++-----
 buildconfigs/mk.linux-2.4-xen0 |    4 ++--
 buildconfigs/mk.linux-2.4-xenU |    4 ++--
 buildconfigs/mk.linux-2.6-xen0 |    4 ++--
 buildconfigs/mk.linux-2.6-xenU |    4 ++--
 docs/Makefile                  |   13 +++++++------
 tools/examples/Makefile        |   20 ++++++++++----------
 tools/libxc/Makefile           |   12 ++++++------
 tools/libxutil/Makefile        |    8 ++++----
 tools/misc/Makefile            |    8 ++++----
 tools/misc/miniterm/Makefile   |    4 ++--
 tools/python/Makefile          |    6 ++----
 tools/sv/Makefile              |   14 +++++++-------
 tools/xentrace/Makefile        |   12 ++++++------
 tools/xfrd/Makefile            |    4 ++--
 xen/Makefile                   |   20 ++++++++++----------
 16 files changed, 74 insertions(+), 74 deletions(-)

Name: sane-make-syntax.patch
Depends: INSTALL.patch, parallel-make.patch, prefix-DESTDIR.patch
Description: fix non-standard make/shell syntax
 Fix use of `pwd`, &&, and || true.  Also, remove ().
DiffStat:
 Makefile       |   16 ++++++++--------
 tools/Makefile |    2 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

Name: xen-banner.patch
Depends: INSTALL.patch, parallel-make.patch, prefix-DESTDIR.patch, proper-depends.patch
Description: split banner.h
 Split banner.h, to make it easier to edit, and more properly fit in with
 normal build systems.
 .
 Also, inline the rules to actually build figlet.
DiffStat:
 xen/Makefile                 |   50 +++++++++++++++++++++++--------------------
 xen/include/xen/banner.h     |   12 ++++++++++
 xen/include/xen/compile.h.in |   13 +++++++++++
 3 files changed, 52 insertions(+), 23 deletions(-)


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2004-12-31 15:43 M.A. Williamson
  0 siblings, 0 replies; 147+ messages in thread
From: M.A. Williamson @ 2004-12-31 15:43 UTC (permalink / raw)
  To: amitabh_2k; +Cc: xen-devel

All these problems are to be expected - the guest can't make privileged 
access to the machine's hardware so updating microcode, clock, etc won't 
work. I'm not actually sure what "keytable" does but it doesn't look like 
it's needed ;-), gpm is definitely not needed.

It's nothing to worry about - you should just disable these services so 
that they don't get run. e.g. on Redhat something like

# chkconfig --del servicename

for each service.  Or use you favourite console / GUI admin tool.

As mentioned in another post, the microcode update seems to be trying to 
load the module for the wrong kernel version (which is odd). Even if it 
were the right version, it still wouldn't work...

Cheers,
Mark

> 1) Applying Intel IA32 Microcode update: insmod: 
> /lib/modules/2.6.5-7.97-smp/kernel/arch/i386/kernel/microcode.o: insmod 
> char-major-10-184 failed
> 
> 2) Starting keytable:  Loading keymap: /etc/rc5.d/S17keytable: line 26: 
> /dev/tty0: No such device
> [FAILED]
> 
> 3) Starting console mouse services: gpm: oops() invoked from gpn.c(132) 
> loadlut: is your kernel compiled with CONFIG_SELECTION on?: Invalid 
> argument [FAILED] (This is probably because the initial OS installation 
> was configured to have a graphical interface)
> 
> During Halt:
> 1) Sending all processes the KILL signal...
> Syncing hardware clock to system time modprobe: modprobe: Can't locate 
> module char-major-10-135
> hwclock is unable to get I/O port access:  the iopl(3) call failed.
> 
> Guest OS boots-up and halts fine. (except for the above errors)
> 
> Any suggesstions??
> 
> Thanks,
> 
> Amitabh
> 
> 
> From: "M.A. Williamson" <maw48@cam.ac.uk>
> Reply-To: maw48@cantab.net
> To: "Fajar A. Nugraha" <fajar@telkom.co.id>
> CC: Amitabh Tamhane <amitabh_2k@hotmail.com>, 
> xen-devel@lists.sourceforge.net
> Subject: Re: [Xen-devel] Porting of Guest OS
> Date: 30 Dec 2004 14:50:25 +0000
> 
> > > The exact error I am getting is: Could not find LABLE=/ and boots in 
> > > >
> >the "repair filesystem" mode.
> >
> > that's /etc/fstab allright. Change the line that says LABEL=/ to 
> > /dev/sda1. You might also need to remove the line that mounts /boot For 
> > kernel-2.6-based or nptl-enabled distro, you also need to remove 
> > /lib/tls and /usr/lib/tls on the domain root file system (Xen will tell 
> > you to do this when it boots).
> 
> Using LABEL=blah requires a) you to set the label on the disk file you 
> created b) you to boot with a suitable initrd (e.g. one that came with 
> your distro) to perform the lookup of filesystem labels.
> 
> You will find it easier to get stuff working if you just specify 
> /dev/whatever explicitly in the config file and edit the guest fstab to 
> match.
> 
> > > The guest OS could talk with the outside world but `xm list` command 
> > > >
> >shows state as -b--- (blocked) for the domain I am trying to boot.
> > >
> >Is that what "-b---" means? All my virtual domains shows that, and yet 
> >they're working perfectly.
> 
> If they're not doing work on the CPU at this instant then they're 
> probably blocked - unless they're doing something CPU intensive they'll 
> be in that state a lot.
> 
> If you've only got one CPU then you'll never see another domain in the 
> running state - the fact that dom0 is running at this instant implies 
> that the other domains aren't :-)
> 
> HTH,
> Mark
> 
> 
> 



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2004-08-20 12:09 James Harper
  0 siblings, 0 replies; 147+ messages in thread
From: James Harper @ 2004-08-20 12:09 UTC (permalink / raw)
  To: xen-devel

[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

  
It's actually xenU I want to test it in (but compiling under xen0), and a make says this:

Note: using kernel source from /lib/modules/2.6.7-xen0/build containing
kernel version 2.6.7

Note: using kernel config from /boot/config-2.6.7-xen0

So i set TOPDIR too, and also had to patch iscsi-id.c to fix these two errors:

iscsi-id.c:90: error: too few arguments to function `sysfs_open_class_device'
iscsi-id.c:94: error: too few arguments to function `sysfs_open_class_device'

by changing the calls to sysfs_open_class_device_path. hope that's the right thing to do. I must have a different version of sysfs (debian version is 1.1.0-1)

'make ARCH=xen' seems to do the right thing, but 'make ARCH=xen install' says:

Installing iSCSI driver for Linux 2.6.7-xen0

doh!

then I replaced all occurences of 'shell uname -r' in the makefile with 'shell echo 2.6.7-xenU'

and it compiles finally. The only problem is that I just did a bk pull and enabled SCSI in xenU, and now the kernel won't compile. i've attached the output of 'make linux26' (but it got rejected so i'm posting it without), the errors are to do with undefined references to 'direct_remap_area_pages'. Do you think that it is to do with the latest bk pull or to do with me enabling device drivers in an unprivileged kernel?

i'll get there eventually!

thanks

James

[-- Attachment #2: Type: text/html, Size: 2362 bytes --]

^ permalink raw reply	[flat|nested] 147+ messages in thread

* (no subject)
@ 2004-04-19  7:27 Jan van Rensburg
  0 siblings, 0 replies; 147+ messages in thread
From: Jan van Rensburg @ 2004-04-19  7:27 UTC (permalink / raw)
  To: xen-devel, brianw

Brian,

I've done basically the same thing with the Xen FAQ. I've watched the 
list and updated the FAQ as new questions came along. In order to 
centralize the Xen documentation, won't you pull the Xen FAQ into the 
wiki? It can be found here:
http://xen.epiuse.com/xen-faq.txt

Once you're done that I'll replace the FAQ with an automatic redirect 
to your page. The FAQ was last updated about 3 months ago (Sorry 
everybody about that! Work got a bit hectic).

Jan



> Message: 1
> Date: Sun, 18 Apr 2004 12:31:02 -0500 (CDT)
> From: "Brian Wolfe" <brianw@terrabox.com>
> To: xen-devel@lists.sourceforge.net
> Subject: [Xen-devel] xen wiki site available http://xen.terrabox.com
>
> http://xen.terrabox.com
>
> I will attempt to keep the site updated based on the xen-devel list
> traffic. If anyone wants to contribute, feel free. Eventually I will 
> get
> the main sections locked down. But until then, i'm leaving them open so
> that anyone that gets bored can easilly update, correct, etc what I 
> have
> up there.
>
> The ultimate goal of the wiki site is to provide as much information 
> about
> Xen as possible in a format that is easilly understood.
>
> Curent sections planned:
>   Resource links as the homepage (downloads, official docs, Distro
> Packages, FAQs, mailing lists, companies offering xen based hosting)
>   Documentation: Official text files, paginated with cross links, and 
> man
> pages of every program/daemon/config file.
>   Debian Packages: sources.list entries
>   Xen FAQ: Standard paginated faq of common questions from xen-devel.
>   Mailing Lists: list of sites archiving xen mailing lists and
> subscription management links.
>   Companies offering xen hosting: table of company, url, price range, 
> and
> notes.
>
> It is my ultimate goal to provide an easilly maintained resource that 
> will
> serve as the basis of the end user/administrator documentation as well 
> as
> FAQ and other associated resources.
>
> Any advice is desired and welcome, especially considering that I am 
> new to
> phpwiki. :)
>
> -- 
> Brian Wolfe           | Phone 1-(214)-764-1204
> President,            | Email  brianw@terrabox.com
> TerraBox.com Inc.     |



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

^ permalink raw reply	[flat|nested] 147+ messages in thread

end of thread, other threads:[~2018-11-19 17:34 UTC | newest]

Thread overview: 147+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-17 12:20 (no subject) Safa Hamza
2016-03-18 11:34 ` Safa Hamza
  -- strict thread matches above, loose matches on Subject: below --
2018-11-19 17:26 Razvan Cojocaru
2018-11-19 17:34 ` Razvan Cojocaru
2017-11-15 15:29 futurelieswithin
2017-08-25  5:16 Chao Gao
2017-07-28  5:27 Manonmani
2017-07-26 19:04 Raviprasad Gurikar
2017-04-04 11:29 Seraphime Kirkovski
2017-02-27 18:12 Dmitry Rockosov
2017-03-06 10:48 ` George Dunlap
2017-02-17 17:17 dhara buch
2017-02-20 17:56 ` Dario Faggioli
2017-02-17 10:47 Norbert Manthey
2017-02-17 11:35 ` Andrew Cooper
     [not found] <1484304406-10820-2-git-send-email-nicolas.dichtel@6wind.com>
     [not found] ` <3131144.4Ej3KFWRbz@wuerfel>
     [not found]   ` <1484304406-10820-1-git-send-email-nicolas.dichtel@6wind.com>
2017-01-13 15:36     ` David Howells
2017-01-13 15:43     ` David Howells
2016-12-29  0:56 Ronald Rojas
2017-01-04  1:10 ` Stefano Stabellini
2016-11-28 17:18 Ronald Rojas
2016-07-16 11:51 姚 忠将
2016-07-07  9:36 George Dunlap
2016-07-07 11:03 ` Dario Faggioli
2016-07-07 12:48   ` George Dunlap
2016-07-07 15:42     ` Dario Faggioli
2016-10-31 10:33     ` Ian Jackson
2016-05-19 14:34 Roger Pau Monné
2016-02-25 12:38 Ayushi Arora
2015-12-07 17:27 Ian Jackson
2015-08-05 13:27 [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id Martin Pohlack
2015-08-05 14:06 ` (no subject) Martin Pohlack
2015-01-06 17:17 Konrad Rzeszutek Wilk
2014-12-19  9:53 Minalkumar Patel
2014-12-19  9:59 ` Ian Campbell
2014-02-13 23:47 Zir Blazer
2014-02-13 16:01 Simon Martin
2014-02-13 16:10 ` Andrew Cooper
2014-02-13 17:27   ` Don Slutz
2013-12-31 15:15 Konrad Rzeszutek Wilk
2013-12-17 18:35 Ian Jackson
2013-12-18 11:19 ` George Dunlap
2013-12-18 13:35   ` Ian Campbell
2014-01-07 13:55     ` Ian Campbell
2013-12-15  7:58 Adel Amani
2013-11-13 19:02 Jim Durand
2013-11-18 14:17 ` George Dunlap
2013-09-13 16:59 David Vrabel
2013-08-14  2:28 yvxiang
2013-08-14  2:31 ` yvxiang
2013-08-14  2:57 ` agya naila
2013-07-04 11:32 Tim Deegan
2013-06-28 16:10 ` [PATCH 08/10] xen: arm: add scope to dsb and dmb macros Ian Campbell
2013-07-04 11:44   ` (no subject) Tim Deegan
2013-06-26 11:42 Divya Kapil
2013-06-26 11:54 ` Ian Campbell
2013-06-16 13:45 wei.liu2
2013-05-14 15:11 Feng Tang
2013-05-03  8:48 Lars Kurth
2013-04-21 22:26 Lonnie Cumberland
     [not found] <CAHyyzzTtK+LbxOh2r_X0=Zd2FsTxoAiLLaWahv5FY-QZnQxhLQ@mail.gmail.com>
     [not found] ` <CAHyyzzSO0vY3LquDjXVAeV3U9sLnAY28+iADzsOLFkMGcJHLOQ@mail.gmail.com>
     [not found]   ` <CAHyyzzSDqmBNWmyRKFijei8YrJD5i40AJ9mcxxnme9CeCLZX2g@mail.gmail.com>
     [not found]     ` <CAHyyzzQcjzeWv-Z6SBOb8Ra0u6BOMzjKV3Ze482rMmMHkAMccw@mail.gmail.com>
     [not found]       ` <CAHyyzzQsh30y7-4M1xmJc+8p-EcqS0+jaibpTrXxTQi92iGDgw@mail.gmail.com>
2013-04-10 15:28         ` jacek burghardt
2013-04-10  6:57 Mina Jafari
2013-03-15  7:40 digvijay chauhan
2013-03-15  9:59 ` Ian Campbell
2013-03-15 11:18 ` Pasi Kärkkäinen
2013-01-08 21:51 Rushikesh Jadhav
2012-11-15 12:08 Tim Deegan
2012-11-15 23:04 ` Aravindh Puthiyaparambil
2013-04-22 21:56 ` Cutter 409
2013-04-23  8:49   ` Tim Deegan
2012-07-27 23:02 lmw
2012-07-14  4:16 张智
2012-07-19 10:24 ` Tim Deegan
2012-04-15  6:09 Lin Ming
2012-04-05 18:26 Francisco Rocha
2012-04-05 19:36 ` Wei Huang
2012-04-05 20:17   ` Francisco Rocha
2012-04-05 20:27     ` Wei Huang
2012-04-05 20:43       ` Francisco Rocha
2012-04-06 14:53         ` Francisco Rocha
2012-04-06 14:51           ` Wei Huang
2012-04-06 15:02             ` Francisco Rocha
2012-04-06 15:14             ` Konrad Rzeszutek Wilk
2012-04-06 16:09               ` Francisco Rocha
2012-02-24 18:54 Ian Jackson
2012-02-17 19:15 Ian Jackson
2011-10-17  7:40 Paolo Bonzini
2011-10-17 17:05 ` Konrad Rzeszutek Wilk
2011-10-17 21:02   ` Ian Campbell
2011-10-18  7:13   ` Paolo Bonzini
2011-10-06 13:11 Pratik shinde
2011-10-06 13:18 ` Andrew Cooper
2011-07-27  8:33 Grant McWilliams
2011-06-21  3:39 Attila Jecs
2011-06-21 13:20 ` Konrad Rzeszutek Wilk
2011-04-04  6:18 Novik, Alex
2011-03-20 22:27 Keshav Darak
2010-11-16 11:12 Ken Ash
2010-10-07  2:46 Mike Viau
2010-10-07 10:43 ` Stefano Stabellini
2010-10-07 13:43   ` George Shuklin
2010-10-07 14:21     ` Ian Campbell
2010-10-07 16:54       ` George Shuklin
2010-10-07 14:02 ` Ian Campbell
2010-04-16 10:59 Jiang, Yunhong
2009-10-09 21:47 Eads, Joshua Michael (S&T-Student)
2009-01-23  6:45 Alexia Benington
2008-11-19 22:29 Bowen, Clair
2008-11-19 22:36 ` James Harper
2008-10-10 12:27 Swapna Shingre
2008-09-18  7:10 James Song
2007-06-11 10:35 Gautham Kampalapur Shankar, TLS, Chennai
2007-06-11 10:53 ` pradeep singh rautela
2006-10-09 11:55 Timo Benk
2006-07-17 14:44 Li, Xin B
2006-06-07 23:48 vineet chadha
2006-06-02 13:23 Kevin Tronkowski
2006-04-06 22:26 Nivedita Singhvi
2006-02-10  8:55 Li, Xin B
2005-11-19 22:44 Purav Saraiya
2005-10-02  2:59 Prashanth Radhakrishnan
2005-09-29  5:55 Li, Chengyuan
2005-09-23 19:07 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-24  0:28 ` Christian Limpach
2005-09-21 20:49 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 20:52 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 21:18 ` Christian Limpach
2005-09-19 19:20 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 19:58 ` Christian Limpach
2005-09-19 16:57 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 16:49 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 17:39 ` Christian Limpach
2005-09-19 15:29 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 16:09 ` Christian Limpach
2005-09-19 13:43 Magenheimer, Dan (HP Labs Fort Collins)
2005-09-19 14:18 ` Christian Limpach
2005-09-19 14:30 ` Jerone Young
2005-09-19 15:34   ` Mark Williamson
2005-07-05 22:54 Igor Feoktistov
2005-06-26  3:26 Reiner Sailer
2005-04-28  4:11 田冠华
2005-04-28  4:10 田冠华
2005-04-18 16:43 tarawa1943
2005-04-18 17:07 ` Keir Fraser
2005-01-22 16:20 Ian Pratt
2005-01-21 17:38 Adam Heath
2005-01-21 17:35 Adam Heath
2004-12-31 15:43 M.A. Williamson
2004-08-20 12:09 James Harper
2004-04-19  7:27 Jan van Rensburg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).