> From: Zhao, Yu [mailto:yu.z...@intel.com]
> Sent: 18 December 2008 02:14
> To: Fischer, Anna
> Cc: Jesse Barnes; linux-...@vger.kernel.org; Chiang, Alexander;
> Helgaas, Bjorn; grund...@parisc-linux.org; g...@kroah.com;
> mi...@elte.hu; matt...@wil.cx; randy.dun...@oracle.com;
> rdre...@cisco.com
Charles Duffy wrote:
> Zhang, Yang wrote:
>> Hi
>> Please drop former.
>> This is the modify patch for save nvram.
>> I add the new command line arg of "-nvram file" to specify the
>> location Of the file. Without the arg ,it will save the nvram in the
>> current dir and named as "nvram.dat". Also,
Jesse Barnes wrote:
On Wednesday, December 17, 2008 11:51 am Greg KH wrote:
On Wed, Dec 17, 2008 at 11:42:54AM -0800, Jesse Barnes wrote:
I really don't want the SR-IOV stuff to sit out another merge cycle
though... Arg.
Why, is there some rush to get it in? As there is no in-kernel users of
Matthew Wilcox wrote:
On Tue, Dec 16, 2008 at 03:23:53PM -0800, Jesse Barnes wrote:
I applied 1-9 to my linux-next branch; and at least patch #10 needs a respin,
I still object to #2. We should have the flexibility to have 'struct
resource's that are not in this array in the pci_dev. I would
Fischer, Anna wrote:
I have two minor comments on this topic.
1) Currently the PF driver is called before the kernel initializes VFs and
their resources, and the current API does not allow the PF driver to
detect that easily if the allocation of the VFs and their resources
has succeeded or not.
>From 8b98bbdd71c979b4d63591f1542d3a3afabbff22 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang
Date: Thu, 18 Dec 2008 10:06:31 +0800
Subject: [PATCH] KVM: Qemu : Fix build breakage for ia64.
Signed-off-by: Xiantao Zhang
---
qemu/qemu-kvm.c |2 ++
qemu/target-ia64/helper.c |5 +++
Bugs item #2443886, was opened at 2008-12-17 18:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2443886&group_id=180599
Please note that this message will contain a full copy
Le mercredi 17 décembre 2008 à 22:58 +0100, Sebastian Herbszt a écrit :
> Laurent Vivier wrote:
> > This series of patches adds a nice BIOS startup splash screen.
> >
> > It adds a "-splash" option allowing to specify the picture file name (a
> > 640x480 (or less) and true color PNG) to
> > displ
Carl-Daniel Hailfinger wrote:
On 16.12.2008 22:51, Laurent Vivier wrote:
But in fact, my first idea was to read the image data from the
configuration device (which is always possible with LOGO_CMD_OFFSET),
but when I saw how it has been done in VirtualBox, I though it was a
good idea.
Vbox use
Anthony Liguori wrote:
Paul Brook wrote:
BTW, why does qemu not carry all bochs bios source? For reference, but
also to fully comply with the LGPL (pointing to the original source is
not sufficient when delivering binaries - like e.g. bios.bin...).
If this is really an issue, then I stron
Laurent Vivier wrote:
This series of patches adds a nice BIOS startup splash screen.
It adds a "-splash" option allowing to specify the picture file name (a 640x480 (or less) and true color PNG) to
display. You can enable/disable fade in,
fade out and bootmenu. The time to display the image ca
On Wed, Dec 17, 2008 at 02:56:05PM -0600, Anthony Liguori wrote:
> Glauber Costa wrote:
>> This patch introduces a kvm version of cpu_physical_memory_rw.
>> The main motivation is to bypass tcg version, which contains
>> tcg-specific code, as well as data structures not used by kvm,
>> such as l1_p
Glauber Costa wrote:
This patch introduces a kvm version of cpu_physical_memory_rw.
The main motivation is to bypass tcg version, which contains
tcg-specific code, as well as data structures not used by kvm,
such as l1_phys_map.
In this patch, I'm using a runtime selection of which function
to c
Glauber Costa wrote:
introduce cpu_physical_memory_do_io, which handles
the mmio part of cpu_physical_memory_rw. KVM can use
it to do mmio, since mmio is essentially the same for
both KVM and tcg.
Signed-off-by: Glauber Costa
---
cpu-all.h |2 +
exec.c| 89 +++
Glauber Costa wrote:
set phys_offset correctly for the whole vga area when unmapping linear vram
(for vga optimization). We first register the old pieces as unassigned
memory, to make things easier for kvm (and possibly other slot based
implementations in the future). Replacing the region directl
set phys_offset correctly for the whole vga area when unmapping linear vram
(for vga optimization). We first register the old pieces as unassigned
memory, to make things easier for kvm (and possibly other slot based
implementations in the future). Replacing the region directly would
make the slot m
introduce cpu_physical_memory_do_io, which handles
the mmio part of cpu_physical_memory_rw. KVM can use
it to do mmio, since mmio is essentially the same for
both KVM and tcg.
Signed-off-by: Glauber Costa
---
cpu-all.h |2 +
exec.c| 89 ++
Hi,
This series replaces some of the tcg memory handling functions,
like cpu_physical_memory_rw and cpu_register_physical_memory
by kvm versions.
I believe this approach pays, because it'll reduce the dependency
that kvm, xen, etc have on the tcg part of qemu. My mid term goal
with it is to be a
This patch introduces a kvm version of cpu_physical_memory_rw.
The main motivation is to bypass tcg version, which contains
tcg-specific code, as well as data structures not used by kvm,
such as l1_phys_map.
In this patch, I'm using a runtime selection of which function
to call, but the mid-term g
record slot used in last lookup. For the common mmio case,
we'll usually access the same memory slot repeatedly.
Signed-off-by: Glauber Costa
---
kvm-all.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index b432e14..51fc3ed 100644
---
Since now we have our own memory read/write function, we don't
depend on all of tcg data structures anymore. So, instead of filling
them up, bypass it altogether by using kvm_set_phys mem alone.
To do that, we now have to provide our own way to get page
information given the address. (kvm_get_phys
On Wednesday, December 17, 2008 11:51 am Greg KH wrote:
> On Wed, Dec 17, 2008 at 11:42:54AM -0800, Jesse Barnes wrote:
> > I really don't want the SR-IOV stuff to sit out another merge cycle
> > though... Arg.
>
> Why, is there some rush to get it in? As there is no in-kernel users of
> it, I don
On Wed, Dec 17, 2008 at 11:42:54AM -0800, Jesse Barnes wrote:
>
> I really don't want the SR-IOV stuff to sit out another merge cycle though...
>
> Arg.
Why, is there some rush to get it in? As there is no in-kernel users of
it, I don't see the problem with postponing it until someone actuall
On Wednesday, December 17, 2008 11:05 am Rose, Gregory V wrote:
> -Original Message-
> From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
>
> On Wednesday, December 17, 2008 8:44 am Rose, Gregory V wrote:
> > As noted in the attached email to the netdev list, we (e1000_devel) will
> > sup
Jeremy Fitzhardinge wrote:
> Which dom0 kernel are you using? Is it based on my pvops-based dom0 work?
The kernel I'm currently using is an ad-hoc patchwork of changes to the 2.6.18
Xen Dom0 kernel that was available back in August. The folks from OTC in Intel
(Zhao Yu and his team) would b
Rose, Gregory V wrote:
-Original Message-
From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
On Wednesday, December 17, 2008 8:44 am Rose, Gregory V wrote:
As noted in the attached email to the netdev list, we (e1000_devel) will
support the API.
Do you think you'll have th
Bugs item #2441883, was opened at 2008-12-17 20:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2441883&group_id=180599
Please note that this message will contain a full copy
On Wednesday, December 17, 2008 8:44 am Rose, Gregory V wrote:
> As noted in the attached email to the netdev list, we (e1000_devel) will
> support the API.
Do you think you'll have those changes ready for 2.6.29? Would merging core
SR-IOV support now make that any more likely?
Thanks,
Jesse
--
On Wednesday, December 17, 2008 3:42 am Fischer, Anna wrote:
> I have two minor comments on this topic.
>
> 1) Currently the PF driver is called before the kernel initializes VFs and
> their resources, and the current API does not allow the PF driver to
> detect that easily if the allocation of the
-Original Message-
From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
On Wednesday, December 17, 2008 8:44 am Rose, Gregory V wrote:
> As noted in the attached email to the netdev list, we (e1000_devel) will
> support the API.
Do you think you'll have those changes ready for 2.6.29?
Jan Kiszka wrote:
Anthony Liguori wrote:
But please, this is not an issue worth even discussing here. It is only
relevant for people distributing QEMU and it's up to those people to
consult with their legal teams to determine whether they need to do
anything special.
And why complicat
Zhang, Yang wrote:
Hi
Please drop former.
This is the modify patch for save nvram.
I add the new command line arg of "-nvram file" to specify the location
Of the file. Without the arg ,it will save the nvram in the current dir
and named as "nvram.dat". Also, it will read the saved file "nvram.
Anthony Liguori wrote:
> Jan Kiszka wrote:
>> Paul Brook wrote:
>>
BTW, why does qemu not carry all bochs bios source? For reference, but
also to fully comply with the LGPL (pointing to the original source is
not sufficient when delivering binaries - like e.g. bios.bin...).
A: No.
Q: Should I include quotations after my reply?
On Wed, Dec 17, 2008 at 08:44:03AM -0800, Rose, Gregory V wrote:
> As noted in the attached email to the netdev list, we (e1000_devel) will
> support the API.
Great, will you have patches for the existing e1000 drivers soon to use
it? Or wi
On Wednesday, December 17, 2008 6:15 am Matthew Wilcox wrote:
> On Tue, Dec 16, 2008 at 03:23:53PM -0800, Jesse Barnes wrote:
> > I applied 1-9 to my linux-next branch; and at least patch #10 needs a
> > respin,
>
> I still object to #2. We should have the flexibility to have 'struct
> resource's
Paul Brook wrote:
BTW, why does qemu not carry all bochs bios source? For reference, but
also to fully comply with the LGPL (pointing to the original source is
not sufficient when delivering binaries - like e.g. bios.bin...).
If this is really an issue, then I strongly suggest we fix it by
Jan Kiszka wrote:
Paul Brook wrote:
BTW, why does qemu not carry all bochs bios source? For reference, but
also to fully comply with the LGPL (pointing to the original source is
not sufficient when delivering binaries - like e.g. bios.bin...).
If this is really an issue, then I strongl
On 17.12.2008 14:55, Gleb Natapov wrote:
> On Wed, Dec 17, 2008 at 02:45:38PM +0100, Jan Kiszka wrote:
>
>> Paul Brook wrote:
>>
> Modern BIOSes have splash screens. I don't see why our BIOS shouldn't
> have one too.
>
Crap PC BIOSes have splash screens because
As noted in the attached email to the netdev list, we (e1000_devel) will
support the API.
- Greg Rose
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of
Greg KH
Sent: Tuesday, December 16, 2008 10:06 PM
To: Jike Song
Cc: Jesse Barnes; Zhao
Sorry to post again, As I see the email I posted is "[Empty message]"
in mailling list.
The message from xen console through serial.
---
Connected to localhost.
Escape character is '^]'.
(XEN) Xen vers
Paul Brook wrote:
>> BTW, why does qemu not carry all bochs bios source? For reference, but
>> also to fully comply with the LGPL (pointing to the original source is
>> not sufficient when delivering binaries - like e.g. bios.bin...).
>
> If this is really an issue, then I strongly suggest we fix
The message from xen console through serial.
---
Connected to localhost.
Escape character is '^]'.
(XEN) Xen version 3.2-1 (Debian 3.2.1-2) (wa...@debian.org) (gcc
version 4.3.1 (Debian 4.3.1-2) ) Sat J
On 17.12.2008 14:09, Laurent Vivier wrote:
> Le mercredi 17 décembre 2008 à 01:10 +0100, Carl-Daniel Hailfinger a
> écrit :
>
>> On 16.12.2008 22:51, Laurent Vivier wrote:
>>
>>> Le mardi 16 décembre 2008 à 22:46 +0200, Blue Swirl a écrit :
>>>
>>>
On 12/16/08, Anthony Liguor
> BTW, why does qemu not carry all bochs bios source? For reference, but
> also to fully comply with the LGPL (pointing to the original source is
> not sufficient when delivering binaries - like e.g. bios.bin...).
If this is really an issue, then I strongly suggest we fix it by moving the
bios in
Jan Kiszka wrote:
> ...
> BTW, why does qemu not carry all bochs bios source? For reference, but
> also to fully comply with the LGPL (pointing to the original source is
> not sufficient when delivering binaries - like e.g. bios.bin...).
OK, reading the diff more carefully told me that it's releas
Gerd Hoffmann wrote:
> Jan Kiszka wrote:
>> Yes, please. I hate this artificial delay, specifically as I have to do
>> a lot of short boot tests where this contributes noticeably to their
>> execution time. But, as usual, it didn't hurt enough to make me hack a
>> patch yet. I'm willing to do this
Gleb Natapov wrote:
> On Wed, Dec 17, 2008 at 02:45:38PM +0100, Jan Kiszka wrote:
>> Paul Brook wrote:
> Modern BIOSes have splash screens. I don't see why our BIOS shouldn't
> have one too.
Crap PC BIOSes have splash screens because they're horribly slow
and otherwise printing l
Jan Kiszka wrote:
> Yes, please. I hate this artificial delay, specifically as I have to do
> a lot of short boot tests where this contributes noticeably to their
> execution time. But, as usual, it didn't hurt enough to make me hack a
> patch yet. I'm willing to do this if we can agree on how it s
Anthony Liguori writes:
> This patch implements posix-aio using pthreads. It immediately
> eliminates the need for fd pooling.
Well in principle I think I approve. Having read the discussion I
think emulation of preadv/pwritev with pread/pwrite is probably fine.
However I did want to make one c
On Wed, Dec 17, 2008 at 12:25:32AM +0300, Evgeniy Polyakov wrote:
> On Tue, Dec 16, 2008 at 08:57:27AM +0200, Gleb Natapov (g...@redhat.com)
> wrote:
> > > Another approach is to implement that virtio backend with netlink based
> > > userspace interface (like using connector or genetlink). This do
Paul Brook wrote:
>>> Modern BIOSes have splash screens. I don't see why our BIOS shouldn't
>>> have one too.
>> Crap PC BIOSes have splash screens because they're horribly slow
>> and otherwise printing lots of irrelevant scary junk at users. The
>> best BIOS 'splash' screen is one which never ap
On Tue, Dec 16, 2008 at 03:23:53PM -0800, Jesse Barnes wrote:
> I applied 1-9 to my linux-next branch; and at least patch #10 needs a respin,
I still object to #2. We should have the flexibility to have 'struct
resource's that are not in this array in the pci_dev. I would like to
see the SR-IOV
On Wed, Dec 17, 2008 at 01:18:57PM +, Paul Brook wrote:
> > > Modern BIOSes have splash screens. I don't see why our BIOS shouldn't
> > > have one too.
> >
> > Crap PC BIOSes have splash screens because they're horribly slow
> > and otherwise printing lots of irrelevant scary junk at users. Th
On Wed, Dec 17, 2008 at 02:45:38PM +0100, Jan Kiszka wrote:
> Paul Brook wrote:
> >>> Modern BIOSes have splash screens. I don't see why our BIOS shouldn't
> >>> have one too.
> >> Crap PC BIOSes have splash screens because they're horribly slow
> >> and otherwise printing lots of irrelevant scary
On Tue, Dec 16, 2008 at 10:06:54PM +0200, Blue Swirl wrote:
> On 12/16/08, Laurent Vivier wrote:
> > This series of patches adds a nice BIOS startup splash screen.
> >
> > It adds a "-splash" option allowing to specify the picture file name (a
> > 640x480 (or less) and true color PNG) to display
Alexander Graf wrote:
>Does it work if you convert the image to an uncompressed one? There
>was this one bug fixed in qemu upstream by Gleb and Kevin recently,
>causing compressed qcow2 images to completely break.
Yes, that could be it. I converted to a plain qcow2 image, and it works
fine. O
Christian Ehrhardt wrote:
Your band aid should be fine. Yes, it's ugly, but this will be in
flux as we merge with upstream qemu. Please resend it with a signoff.
still ugly, but in a proper patch style now :-)
Applied, thanks.
--
error compiling committee.c: too many arguments to funct
> > Modern BIOSes have splash screens. I don't see why our BIOS shouldn't
> > have one too.
>
> Crap PC BIOSes have splash screens because they're horribly slow
> and otherwise printing lots of irrelevant scary junk at users. The
> best BIOS 'splash' screen is one which never appears unless there
Christian Ehrhardt wrote:
This patch series updates the gdbstub support for kvm.
Patch 1&2 introduce basic powerpc support while patch 3 fixes gdbstub generic
code that was broken in a qemu merge.
Please rebase, as the recent debug changes probably affect this area.
--
error compiling commi
Avi Kivity wrote:
Christian Ehrhardt wrote:
Hi, this patch breaks all non x86 architectures as
libkvm/libkvm-x86.c has the only implementation of the alias
functionality.
Until now only qemu-kvm-x86 has called that functions, but since this
patch the generic qemu-kvm.c calls them which leads t
Le mercredi 17 décembre 2008 à 01:10 +0100, Carl-Daniel Hailfinger a
écrit :
> On 16.12.2008 22:51, Laurent Vivier wrote:
> > Le mardi 16 décembre 2008 à 22:46 +0200, Blue Swirl a écrit :
> >
> >> On 12/16/08, Anthony Liguori wrote:
> >>
> >>> Blue Swirl wrote:
> >>>
> >
> >
> >>
Christian Ehrhardt wrote:
Hi, this patch breaks all non x86 architectures as libkvm/libkvm-x86.c
has the only implementation of the alias functionality.
Until now only qemu-kvm-x86 has called that functions, but since this
patch the generic qemu-kvm.c calls them which leads to unresolved
symbol
Jan Kiszka wrote:
Changes since last round:
- Fix non-x86 stubs in qemu-kvm-*.c (Christian Ehrhardt)
As usual, find the patches also at git://git.kiszka.org/kvm-userspace.git
gdb-queue
Applied all, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe
Jan Kiszka wrote:
This is the kernel part of the guest debugging / debug register
emulation patch series.
Changes since last round (was v1, skipped v2 to remain in sync with user
space series):
- Reworked patch 3 (single-stepping over STI / MOV SS on VMX)
- Rebased over latest git
Meanwhile b
Yiyi Hu wrote:
Host info:
h...@hs ~ $ uname -a
Linux Hs 2.6.27-gentoo-r6 #1 SMP Mon Dec 15 11:43:12 CST 2008 x86_64
AMD Athlon(tm) X2 Dual Core Processor BE-2350 AuthenticAMD GNU/Linux
KVM is version 81. Installed from portage.
The guest is 64bit debian lenny, Within guest, we install the xen s
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org] On Behalf Of Jesse Barnes
> Sent: 16 December 2008 23:24
> To: Yu Zhao
> Cc: linux-...@vger.kernel.org; Chiang, Alexander; Helgaas, Bjorn;
> grund...@parisc-linux.org; g...@kroah.com; mi...@elte.hu;
> matt...@wil.cx
On Tue, Dec 16, 2008 at 02:28:29PM -0600, Anthony Liguori wrote:
> Blue Swirl wrote:
> >On 12/16/08, Laurent Vivier wrote:
> >
> >>This series of patches adds a nice BIOS startup splash screen.
> >>
> >> It adds a "-splash" option allowing to specify the picture file name (a
> >> 640x480 (or le
On Dec 17, 2008, at 12:19 AM, Ross McKay wrote:
G'day,
I must be doing something wrong, because it sounds like everyone
else is
happy about kvm-81.
My Windows XP guests now constantly show "Delayed Write Failed"
popups.
The problem vanishes when I revert to kvm-80, which I didn't have a
Hollis Blanchard wrote:
PowerPC KVM support was accepted into upstream qemu. To ease the merge
conflicts, you should apply this patch to remove all traces of PowerPC
KVM code from kvm-userspace before the next qemu pull.
Applied, thanks.
--
error compiling committee.c: too many arguments t
Mark McLoughlin wrote:
On Tue, 2008-12-16 at 21:38 +0200, Avi Kivity wrote:
The recent qemu merged does not allow net.h to include kvm code (due to
a dependency on cpu.h). This means I had to drop the
kvm_sleep_begin()/kvm_sleep_end() around the packet send (which, btw,
makes the whole thi
Anthony Liguori wrote:
Avi Kivity wrote:
hThe recent qemu merged does not allow net.h to include kvm code (due
to a dependency on cpu.h). This means I had to drop the
kvm_sleep_begin()/kvm_sleep_end() around the packet send (which, btw,
makes the whole thing vulnerable to hotunplug; we need r
On Tue, 2008-12-16 at 21:38 +0200, Avi Kivity wrote:
> The recent qemu merged does not allow net.h to include kvm code (due to
> a dependency on cpu.h). This means I had to drop the
> kvm_sleep_begin()/kvm_sleep_end() around the packet send (which, btw,
> makes the whole thing vulnerable to hot
Courtay Olivier wrote:
> Hi,
>
> I have retry to use PCI device assignment with kvm-81 (already with a
> 2.6.28-rc8 ).
>
> The result is better, my guest OS (Windows XP) boot and see the
> network card.
> After install the driver, the device seems to be OK.
> But it seems that the network card
Hi,
I have retry to use PCI device assignment with kvm-81 (already with a
2.6.28-rc8 ).
The result is better, my guest OS (Windows XP) boot and see the network card.
After install the driver, the device seems to be OK.
But it seems that the network card can not sent packet on network.
The networ
74 matches
Mail list logo
