Xen project Mailing List

2008/11/6 <xen-devel-request@xxxxxxxxxxxxxxxxxxx>

Send Xen-devel mailing list submissions to
xen-devel@xxxxxxxxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.xensource.com/mailman/listinfo/xen-devel
or, via email, send a message with subject or body 'help' to
xen-devel-request@xxxxxxxxxxxxxxxxxxx

You can reach the person managing the list at
xen-devel-owner@xxxxxxxxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Xen-devel digest..."

Today's Topics:

1. Re: Issues in call to get_domain_by_id() (Keir Fraser)
2. Re: [patch 0/6] xenblk: Add O_DIRECT and O_SYNC support. (Joe Jin)
3. Re: [patch 0/6] xenblk: Add O_DIRECT and O_SYNC support.
(Keir Fraser)
4. Re: [patch 0/6] xenblk: Add O_DIRECT and O_SYNC support.
(Keir Fraser)
5. Re: mmx sse emulation (Ashish Bijlani)
6. Re: [patch 0/6] xenblk: Add O_DIRECT and O_SYNC support.
(Keir Fraser)
7. Re: debuggers and hap_gva_to_gfn() in guest_walk.c (Tim Deegan)

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

Message: 1
Date: Thu, 06 Nov 2008 08:39:05 +0000
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Issues in call to get_domain_by_id()
To: <bhavi63@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Message-ID: <C5385DA9.1EED7%keir.fraser@xxxxxxxxxxxxx>
Content-Type: text/plain; charset="US-ASCII"

On 5/11/08 23:56, "bhavani krishnan" <bhavi63@xxxxxxxxx> wrote:

> I am new to xen. I need to write a program which sits in dom0 and reads the
> domU page tables. I basically need a list of virtual pages which are are
> mapped onto a domU at any instant. Please let me know the best approach to do
> this?
>
> Currently I am using control interface (libxc) to get list of pfns by calling
> xc_get_pfn_list. The stupid that I am having now is that if i try to call any
> function (eg: get_domain_by_id) defined in sched.h or xen.h, I get following
> error at compile time
> undefined reference to get_domain_by_id'

You can't get at Xen-internal functions from outside Xen.

-- Keir

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

Message: 2
Date: Thu, 6 Nov 2008 16:23:19 +0800
From: Joe Jin <joe.jin@xxxxxxxxxx>
Subject: Re: [Xen-devel] [patch 0/6] xenblk: Add O_DIRECT and O_SYNC
support.
To: Jens Axboe <jens.axboe@xxxxxxxxxx>
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>,
Xen-devel@xxxxxxxxxxxxxxxxxxx, kurt.hackel@xxxxxxxxxx,
shinya.narahara@xxxxxxxxxx, Joe Jin <joe.jin@xxxxxxxxxx>,
greg.marsden@xxxxxxxxxx, wen.gang.wang@xxxxxxxxxx, Keir Fraser
<keir.fraser@xxxxxxxxxxxxx>
Message-ID: <20081106082319.GA25301@xxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii

On 2008-11-06 09:17, Jens Axboe wrote:
> On Wed, Nov 05 2008, Keir Fraser wrote:
> > On 5/11/08 20:16, "Jens Axboe" <jens.axboe@xxxxxxxxxx> wrote:
> >
> > >>> Does blkback propagate unplug events downwards?
> > >>
> > >> Not sure what that means. blkback does its own limited queue plugging to try
> > >> to develop usefully schedulable batches of I/O. There's no concept of
> > >> plugging across the blkfront/blkback interface.
> > >
> > > So once you leave your queuing loop, you unplug the below device? Or
> > > just point me at the source...
> >
> > The tree's at http://xenbits.xensource.com/linux-2.6.18-xen.hg
> >
> > You can clone it or browse it there.
> >
> > The medium- to long-term issue is just to make sure that Jeremy's port of
> > blkback into upstream Linux (which he's probably working on at the moment)
> > doesn't perpetuate the bio violations. But I guess we should fix 2.6.18 too
> > since others base their own Xen patchsets on it still (e.g., for dom0
> > support).
>
> Ah thanks! Perhaps we can talk Joe into snipping the bio_alloc() changes
> out of his patch #2 - Joe, just the bio_alloc() and submit_bio() stuff,
> you don't have to include the bio_set changes.
>

Thanks, will get rid of it.

Joe

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

Message: 3
Date: Thu, 06 Nov 2008 08:44:27 +0000
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [patch 0/6] xenblk: Add O_DIRECT and O_SYNC
support.
To: Jens Axboe <jens.axboe@xxxxxxxxxx>
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>,
Xen-devel@xxxxxxxxxxxxxxxxxxx, kurt.hackel@xxxxxxxxxx,
shinya.narahara@xxxxxxxxxx, Joe Jin <joe.jin@xxxxxxxxxx>,
greg.marsden@xxxxxxxxxx, wen.gang.wang@xxxxxxxxxx
Message-ID: <C5385EEB.1EEDA%keir.fraser@xxxxxxxxxxxxx>
Content-Type: text/plain; charset="US-ASCII"

On 6/11/08 08:17, "Jens Axboe" <jens.axboe@xxxxxxxxxx> wrote:

>> The medium- to long-term issue is just to make sure that Jeremy's port of
>> blkback into upstream Linux (which he's probably working on at the moment)
>> doesn't perpetuate the bio violations. But I guess we should fix 2.6.18 too
>> since others base their own Xen patchsets on it still (e.g., for dom0
>> support).
>
> Ah thanks! Perhaps we can talk Joe into snipping the bio_alloc() changes
> out of his patch #2 - Joe, just the bio_alloc() and submit_bio() stuff,
> you don't have to include the bio_set changes.

But Joe's patch still queues up bios into an array, the same as ever?

-- Keir

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

Message: 4
Date: Thu, 06 Nov 2008 09:26:32 +0000
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [patch 0/6] xenblk: Add O_DIRECT and O_SYNC
support.
To: Jens Axboe <jens.axboe@xxxxxxxxxx>
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>,
Xen-devel@xxxxxxxxxxxxxxxxxxx, kurt.hackel@xxxxxxxxxx,
shinya.narahara@xxxxxxxxxx, Joe Jin <joe.jin@xxxxxxxxxx>,
greg.marsden@xxxxxxxxxx, wen.gang.wang@xxxxxxxxxx
Message-ID: <C53868C8.1EFEE%keir.fraser@xxxxxxxxxxxxx>
Content-Type: text/plain; charset="US-ASCII"

On 6/11/08 08:51, "Jens Axboe" <jens.axboe@xxxxxxxxxx> wrote:

> I guess he needs that for waiting on them, but it really should just do:
>
> struct bio *bio = NULL;
>
> loop {
> if (bio) {
> submit_bio(bio, ...);
> bio = NULL;
> }
> bio = bio_alloc(...);
> ...
> }
>
> if (bio)
> submit_bio(bio, ...);
>
> and be done with it.

Yes, I can put together a patch for that easily enough, I think.

-- Keir

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

Message: 5
Date: Thu, 6 Nov 2008 05:16:58 -0500
From: "Ashish Bijlani" <ashish.bijlani@xxxxxxxxx>
Subject: Re: [Xen-devel] mmx sse emulation
To: xen-devel@xxxxxxxxxxxxxxxxxxx
Message-ID:
<ec55b17e0811060216j702f42c4x29468758a02f5df0@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1

in an attempt to emulate mmx/sse instructions from within xen, i tried
setting EM and NE bit in CR0 to have mmx/sse instructions fault into
xen. however, the hvm guest doesn't boot after that. also, i don't get
any "device_not_available_fault" any ideas what could be wrong? am i
missing something?

this is what i've done :-

int hvm_set_cr0(unsigned long value) {
...
value &= ~HVM_CR0_GUEST_RESERVED_BITS;

value |= (X86_CR0_EM | X86_CR0_NE); // EMULATE FPU

/* ET is reserved and should be always be 1. */
value |= X86_CR0_ET;
...
}

I run system with dom0 4 vcpus on 0-2 cpu cores and hvm 1 vcpu on the
3rd cpu core

-Ashish
On Wed, Nov 5, 2008 at 10:10 AM, mats petersson <mats@xxxxxxxxxxxxxxxxx> wrote:
> 2008/11/5 Ashish Bijlani <ashish.bijlani@xxxxxxxxx>
>>
>> If I'm not wrong, Bochs emulates SSE/MMX instructions and qemu uses
>> dynamic translation. Does this mean that I use SSE/MMX emulation code
>> from Bochs to put under x86_emulate? or am I missing something?
>> Thanks.
>>
>> On Wed, Nov 5, 2008 at 5:34 AM, Ashish Bijlani <ashish.bijlani@xxxxxxxxx>
>> wrote:
>> > Hi Andre,
>> >
>> > You are absolutely right. All hardware virtualization capable machines
>> > have recent simd technology built-in. However, I'm just trying to
>> > evaluate a case when HVM guests rely on the virtual hardware platform
>> > and not on the actual hardware platform. Precisely, what would be the
>> > performance gain/loss if hypervisor has to emulate the functionality.
>
> The performance loss would be HUGE. First of all, you'd fall into the
> hypervisor and get back out again, which takes a fair few cycles (like more
> than 100x or more that of a single instruction). Then you have to emulate
> the actual instruction itself, which will be the small part of the ovehead.
>
> Many SSE/MMX/3DNow! instructions execute in 1-2 clockcycles. My guess would
> be that it would reduce any SSE optimized code to a crawl (like in the order
> of 100-1000x slower). Such an application would be much better off running
> in x87 mode.
>
> I was looking at doing SSE/MMX emulation in x86_emulate a long time ago, but
> the purpose of that wasn't to emulate SSE/MMX as such, but rather allow
> SSE/MMX to access emulated hardware (such as video memory).
>
> --
> Mats
>>
>> -Ashish
>>
>> On Wed, Nov 5, 2008 at 4:59 AM, Andre Przywara <andre.przywara@xxxxxxx>
>> wrote:
>>> Ashish Bijlani wrote:
>>>>
>>>> Hi,
>>>>
>>>> I want to emulate mmx/sse for hvm guests when applications inside hvm
>>>> guests are compiled for mmx/sse but the underlying hardware doesn't
>>>> support mmx/sse.
>>>
>>> First: HVM guests require a virtualization capable processor. AFAIK all
>>> these processors support at least SSE2 (if not SSE3). So why do you want
>>> to
>>> emulate these instructions?
>>> Second: Applications should check the CPUID bit before using instruction
>>> set
>>> extension. So, if the host processor does not support MMX/SSE, the guest
>>> shouldn't see this bit, too. And I doubt that you are faster with
>>> emulating
>>> SSE compared to legacy x87-FPU executed natively.
>>>
>>> So, what is the use-case of your proposal? Or am I missing something
>>> here?
>>>
>>> Regards,
>>> Andre.
>>>
>>>> What is the best place to do this? i'm looking at
>>>>
>>>> x86_emulate but i dunno if that is the best place to put the emulation
>>>> layer. any suggestions?? also, currently movq emulation is present in
>>>> x86_emulate for handling mmio. however, i realized that get_fpu fails
>>>> if the hardware doesn't have mmx capability. is it true or am i
>>>> missing something here?
>>>>
>>>> Thanks,
>>>> Ashish
>>>
>>> --
>>> Andre Przywara
>>> AMD-OSRC (Dresden)
>>> Tel: x84917
>>>
>>>
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
>

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

Message: 6
Date: Thu, 06 Nov 2008 10:33:48 +0000
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [patch 0/6] xenblk: Add O_DIRECT and O_SYNC
support.
To: Jens Axboe <jens.axboe@xxxxxxxxxx>
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>,
Xen-devel@xxxxxxxxxxxxxxxxxxx, kurt.hackel@xxxxxxxxxx,
shinya.narahara@xxxxxxxxxx, Joe Jin <joe.jin@xxxxxxxxxx>,
greg.marsden@xxxxxxxxxx, wen.gang.wang@xxxxxxxxxx
Message-ID: <C538788C.1EFF4%keir.fraser@xxxxxxxxxxxxx>
Content-Type: text/plain; charset="US-ASCII"

On 6/11/08 09:29, "Jens Axboe" <jens.axboe@xxxxxxxxxx> wrote:

>>> and be done with it.
>>
>> Yes, I can put together a patch for that easily enough, I think.
>
> Should be easy enough. Also be sure to defer any unplugging of the
> device until the very end, to still make a lot of room for merging and
> sorting.

http://xenbits.xensource.com/staging/linux-2.6.18-xen.hg c/s 723

-- Keir

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

Message: 7
Date: Thu, 6 Nov 2008 10:51:57 +0000
From: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel] debuggers and hap_gva_to_gfn() in
guest_walk.c
To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Cc: mukesh.rathor@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx
Message-ID: <20081106105157.GC25331@xxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=iso-8859-1

At 21:56 +0000 on 05 Nov (1225922197), Keir Fraser wrote:
> This looks like a bug in hap_gva_to_gfn(). It should probably be using
> gfn_to_mfn() rather than gfn_to_mfn_current(). Tim, can you confirm?

In the current codebase, it's correct (all callers of paging_gva_to_gfn()
call with v == current) but changing it to use gfn_to_mfn() seems
more correcter.

Tim.

> On 5/11/08 21:44, "Mukesh Rathor" <mukesh.rathor@xxxxxxxxxx> wrote:
>
> >
> > Debugger/s would like to keep it's #ifdefs in xen minimal. Following would
> > help...
> >
> > hap_gva_to_gfn():
> >
> >
> > + if (v== current)
> > mfn = mfn_x(gfn_to_mfn_current(gpfn, &p2mt));
> > + else
> > + mfn = mfn_x(gfn_to_mfn_foreign(v->domain, gpfn, &p2mt));
> >
> >
> > Thanks,
> > Mukesh
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
>
>

--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

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

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

End of Xen-devel Digest, Vol 45, Issue 22
*****************************************

[Xen-devel] Modif. in Xen