Bugs item #2506814, was opened at 2009-01-14 05:38
Message generated for change (Comment added) made by c_jones
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2506814&group_id=180599
Please note that this message will contain a full copy of the comment t
On Fri, Jul 10, 2009 at 4:29 AM, sudhir kumar wrote:
> So is there any plan for adding this patch set in the patch queue? I
> would love to incorporate all the comments if any.
Yup, just was behind on patches.
I added it now - the mailer you are using seems to chew patches fairly
thoroughly thoug
Hi All,
I apologize for the typo in my earlier mail. My first try
failed and I was NOT able to get an IP address.
Please clarify if there is any issue in my setup.
Thanks,
Vinoth.
On Fri, Jul 10, 2009 at 5:47 PM, VinothKumar S wrote:
> Hi ,
>
> My goal is to assign pci d
Hi ,
My goal is to assign pci device using Vt-d capability. I have a
Supermicro Server X8DTU-F motherboard. I verified that it had Vt-d
capability and enabled it in BIOS. Iam using KVM-86 (as I had some
compilation error in KVM-87).
My first try was to use Ubuntu 9.04 (with kvm modules
Li Zefan wrote:
>> +static __kprobes unsigned long fetch_memory(struct pt_regs *regs, void
>> *addr)
>> +{
>> +unsigned long retval;
>
> need a space after local variable declarations.
>
>> +if (probe_kernel_address(addr, retval))
>> +return 0;
>> +return retval;
>> +}
>>
Suresh Siddha writes:
> On Wed, 2009-07-01 at 17:17 -0700, Eric W. Biederman wrote:
>> Suresh Siddha writes:
>> > Among number of experiments you have tried in the past to fix this, have
>> > you tried the experiment of explicitly clearing the remoteIRR by
>> > changing the trigger mode to edge
In this patch, we duplicate most of KVMState in our files. This should be
removed later, when they are 100 % equal. Meanwhile, we fold our kvm_context_t
structure inside it.
To make transition smooth, we still keep a global variable kvm_context
pointing to its position inside the global KVMState.
get rid of kvm_callbacks structure definition
Signed-off-by: Glauber Costa
---
libkvm-all.h | 57 -
1 files changed, 0 insertions(+), 57 deletions(-)
diff --git a/libkvm-all.h b/libkvm-all.h
index 3e3e1b4..01c0486 100644
--- a/libkvm-all
This patch replaces both malloc and malloc+memset sequences
with qemu_malloc and qemu_mallocz. Target is upstream integration
Signed-off-by: Glauber Costa
---
qemu-kvm-x86.c | 31 ---
qemu-kvm.c | 26 +-
2 files changed, 13 insertions(+
Instead, include them from upstream files
Signed-off-by: Glauber Costa
---
Makefile.target |5 ++---
kvm-all.c |2 ++
target-i386/kvm.c |2 ++
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/Makefile.target b/Makefile.target
index 11a6da8..1c0f4ea 100644
---
Make things less confuse, and we have KVM_UPSTREAM to differentiate
between the two versions anyway. kvm-all.c and kvm.c gets compiled now,
but protected with KVM_UPSTREAM too, so no function in there gets visible
in the final binary
Signed-off-by: Glauber Costa
---
Makefile.target | 20
Hi,
This is another step at getting us closer to qemu upstream. I'm getting rid
of USE_KVM, replacing it with the combination of KVM_UPSTREAM and CONFIG_KVM
The goal is to slowly reduce that isolation. To demonstrate what I aim
for, the last patches of the series shares code for breakpoint handli
Drop KVM_UPSTREAM around functions we intend to reuse.
This allow us to share code in kvm-all.c, that is equal in qemu-kvm.c
Signed-off-by: Glauber Costa
CC: Jan Kiszka
---
kvm-all.c |5 ++-
kvm.h |1 +
qemu-kvm.c | 140 +---
Signed-off-by: Glauber Costa
---
qemu-kvm-x86.c |4 ++--
qemu-kvm.c | 27 ++-
qemu-kvm.h |9 ++---
3 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index 48b2e2f..f3890fe 100644
--- a/qemu-kvm-x86.c
+++
Sharing of structures containing each other between libkvm-all.h and
qemu-kmv.h gets a bit messy in this series. So fold them together. libkvm-all.h
has no place in the final schema of things anyway.
Signed-off-by: Glauber Costa
---
kvm.h|1 -
libkvm-all.h | 904
qemu upstream puts kvm information on env. Do that too, since it will
allow us to use CPUState in cpu-specific functions, instead of kvm-specific
types.
Signed-off-by: Glauber Costa
---
qemu-kvm.c |9 +++--
qemu-kvm.h |2 +-
2 files changed, 8 insertions(+), 3 deletions(-)
diff --gi
Hi,
Li Zefan wrote:
>> +Event Profiling
>> +---
>> + You can check the total number of probe hits and probe miss-hits via
>> +/sys/kernel/debug/tracing/kprobe_profile.
>> + The fist column is event name, the second is the number of probe hits,
>
> s/fist/first
Oops, fixed.
>
>> +th
Christoph Hellwig wrote:
On Tue, Jun 23, 2009 at 10:05:14AM +0800, Huang Ying wrote:
- MCE features are initialized when VCPU is intialized according to CPUID.
- A monitor command "mce" is added to inject a MCE.
- A new interrupt mask: CPU_INTERRUPT_MCE is added to inject the MCE.
This
On Tue, Jun 23, 2009 at 10:05:14AM +0800, Huang Ying wrote:
> - MCE features are initialized when VCPU is intialized according to CPUID.
> - A monitor command "mce" is added to inject a MCE.
> - A new interrupt mask: CPU_INTERRUPT_MCE is added to inject the MCE.
This patch (now in the qemu tree) b
Christoph Hellwig wrote:
On Fri, Jul 10, 2009 at 12:29:25PM -0500, Anthony Liguori wrote:
Sorry, I'm not able to follow you here. What is currently queued and
what do you think should be queued? Can you provide links/commit hashes?
Currenly queued:
http://repo.or.cz/w/qemu/
On Fri, Jul 10, 2009 at 07:12:37PM +0200, Kevin Wolf wrote:
> Ok, that makes sense. Will you take care of it once the renaming patch
> is in or should I resend it then?
If Anthony prefers patches I'll stop doing the git trees and you'll
have to repost it. If we continue with the git trees I can a
> As pointed out before, it doesn't break anything but adds a workaround
> for scenarios which are _now_ broken (16/32 bit target code exported as
> 64 bit is widely useless for gdb today). Sorry, but you never explained
> to me how user are _currently_ supposed to debug under that conditions,
> na
On Fri, Jul 10, 2009 at 12:29:25PM -0500, Anthony Liguori wrote:
> Sorry, I'm not able to follow you here. What is currently queued and
> what do you think should be queued? Can you provide links/commit hashes?
Currenly queued:
http://repo.or.cz/w/qemu/aliguori-queue.git?a=commitdiff;
Paul Brook wrote:
> The 32/64-bit switching is just plain wrong, and makes it absolutely
> impossible for a client debugger to work correctly.
As pointed out before, it doesn't break anything but adds a workaround
for scenarios which are _now_ broken (16/32 bit target code exported as
64 bit is w
Paul Brook wrote:
Right, that part I'm okay with. But the vCont based gdb model presumes
a unified address space which while usually true for kernel address
spaces, isn't universally true and certainly not true when PC is in
userspace. That's what I understood to be the major objection to vCont
> Right, that part I'm okay with. But the vCont based gdb model presumes
> a unified address space which while usually true for kernel address
> spaces, isn't universally true and certainly not true when PC is in
> userspace. That's what I understood to be the major objection to vCont.
The threa
Kevin Wolf wrote:
Last time you said you don't want to get pull requests but rather
patches on the list.
I'm clearly trying to purposefully confuse you :-)
Honestly, I'm just trying to work with people. I saw the pull request,
so I pulled it. I would have been just as happy pulling in the
Christoph Hellwig wrote:
On Fri, Jul 10, 2009 at 11:59:25AM -0500, Anthony Liguori wrote:
If I'm not mistaken, the patch "qemu-io: Implement
bdrv_get_buffer/bdrv_put_buffer" is missing from the queue.
I just did a pull a few hours ago from Christoph's qemu-io tree. I'm
expecting qe
Anthony Liguori wrote:
> Jan Kiszka wrote:
>> That's nothing those patches changes (it's our current and only
>> debugging model for SMP until gdb provides a complete solution).
>>
>
> It Paul agrees, I'll pull it. But my understanding from the previous
> threads and posts was that Paul did no
Christoph Hellwig schrieb:
> On Fri, Jul 10, 2009 at 11:59:25AM -0500, Anthony Liguori wrote:
>>> If I'm not mistaken, the patch "qemu-io: Implement
>>> bdrv_get_buffer/bdrv_put_buffer" is missing from the queue.
>>>
>> I just did a pull a few hours ago from Christoph's qemu-io tree. I'm
>> exp
Anthony Liguori schrieb:
> Kevin Wolf wrote:
>> Anthony Liguori schrieb:
>>
>>> Jan Kiszka wrote:
>>>
Hmm, I must have missed this: Where is your staging tree hosted?
>>> Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan
>>> to move it to git
On Fri, Jul 10, 2009 at 11:59:25AM -0500, Anthony Liguori wrote:
> >If I'm not mistaken, the patch "qemu-io: Implement
> >bdrv_get_buffer/bdrv_put_buffer" is missing from the queue.
> >
>
> I just did a pull a few hours ago from Christoph's qemu-io tree. I'm
> expecting qemu-io patches to go t
Kevin Wolf wrote:
Anthony Liguori schrieb:
Jan Kiszka wrote:
Hmm, I must have missed this: Where is your staging tree hosted?
Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan
to move it to git.qemu.org in the next few days.
If I'm not mistaken,
Jan Kiszka wrote:
Something went wrong during transmission, and I missed that. Just sent
out those two as well.
Thanks, it's now all in staging.
That's nothing those patches changes (it's our current and only
debugging model for SMP until gdb provides a complete solution).
It Paul agr
Stephen Donnelly wrote:
On Thu, Jul 9, 2009 at 6:01 PM, Cam Macdonell wrote:
Is there a corresponding qemu patch for the backend to the guest pci
driver?
Oops right. For some reason I can't my driver patch in patchwork.
http://kerneltrap.org/mailarchive/linux-kvm/2009/5/7/5665734
Thanks f
Kevin Wolf wrote:
Anthony Liguori schrieb:
Jan Kiszka wrote:
Hmm, I must have missed this: Where is your staging tree hosted?
Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan
to move it to git.qemu.org in the next few days.
If I'm not mistaken,
Anthony Liguori schrieb:
> Jan Kiszka wrote:
>> Hmm, I must have missed this: Where is your staging tree hosted?
>>
>
> Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan
> to move it to git.qemu.org in the next few days.
If I'm not mistaken, the patch "qemu-io: Implemen
Anthony Liguori wrote:
> Jan Kiszka wrote:
>> Ah, thanks.
>>
>> OK, then I would like to know the status of my -boot patch queue [1]
>
> I'm stilling waiting for 1/7 and 2/7. Via the link you posted and in my
> inbox, I still don't see those. I do see a 1/2 and a 2/2 but those are
> bios patches
Jan Kiszka wrote:
Ah, thanks.
OK, then I would like to know the status of my -boot patch queue [1]
I'm stilling waiting for 1/7 and 2/7. Via the link you posted and in my
inbox, I still don't see those. I do see a 1/2 and a 2/2 but those are
bios patches. Did you have a numbering issue or
Anthony Liguori wrote:
> Jan Kiszka wrote:
>> Hmm, I must have missed this: Where is your staging tree hosted?
>>
>
> Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan
> to move it to git.qemu.org in the next few days.
Ah, thanks.
OK, then I would like to know the statu
Jan Kiszka wrote:
Hmm, I must have missed this: Where is your staging tree hosted?
Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan
to move it to git.qemu.org in the next few days.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscr
Glauber Costa wrote:
On Tue, Jul 7, 2009 at 4:03 PM, Andy Sy wrote:
I am trying to install Slackware on KVM-based
VPS hosting and keep getting a "LILO keytable read
/ checksum error" upon booting.
Grub-based distros install fine on said VPS.
Apparently certain builds/versions of KVM break
with
On Fri, Jul 10, 2009 at 12:40 PM, Andy Sy wrote:
> Glauber Costa wrote:
>>
>> On Tue, Jul 7, 2009 at 4:03 PM, Andy Sy wrote:
>>>
>>> I am trying to install Slackware on KVM-based
>>> VPS hosting and keep getting a "LILO keytable read
>>> / checksum error" upon booting.
>>>
>>> Grub-based distros in
- "Lukáš Doktor" wrote:
> Hi,
>
> the way how kvm_autotest currently handle pre_command/post_command it
> don't allow to specify more than one command. BASH can handle this
> itself with a small change in the framework , as shown in the
> attachment.
Why do you say the framework doesn't a
Anthony Liguori wrote:
> Markus Armbruster wrote:
>> Anthony Liguori writes:
>>
>> Any hope that -device can make the cut?
>>
> I've got most of the outstanding patches in staging now. The only thing
> missing is the PIIX refactoring from Isaku which I suspect is going to
> fuzz badly. -devic
On Thu, Jul 09, 2009 at 07:19:45PM -0700, Chris Wright wrote:
> * Michael S. Tsirkin (m...@redhat.com) wrote:
> > +struct generic_dev {
>
> I know I commented on this one on an earlier, private version, and naming
> is not my strength... maybe "struct uio_generic_pci_dev" or "struct
> uio_generic_
* Gleb Natapov wrote:
> KVM would like to provide x2APIC interface to a guest without emulating
> interrupt remapping device. The reason KVM prefers guest to use x2APIC
> is that x2APIC interface is better virtualizable and provides better
> performance than mmio xAPIC interface:
>
> - msr
Markus Armbruster wrote:
Anthony Liguori writes:
Any hope that -device can make the cut?
I've got most of the outstanding patches in staging now. The only thing
missing is the PIIX refactoring from Isaku which I suspect is going to
fuzz badly. -device is there.
I'll be testing this tod
Ram Pai wrote:
Problem: It is impossible to feed filenames with the character colon because
qemu interprets such names as a protocol. For example filename scsi:0, is
interpreted as a protocol by name "scsi".
This patch allows user to espace colon characters. For example the above
filename can no
Signed-off-by: Andre Przywara
---
Documentation/kernel-parameters.txt | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index d77fbd8..8ca488d 100644
--- a/Document
In a recent version of linux-next, the function kvm_s390_handle_wait
contains the following code:
add_wait_queue(&vcpu->arch.local_int.wq, &wait);
while (list_empty(&vcpu->arch.local_int.list) &&
list_empty(&vcpu->arch.local_int.float_int->list) &&
Hi,
the way how kvm_autotest currently handle pre_command/post_command it
don't allow to specify more than one command. BASH can handle this
itself with a small change in the framework , as shown in the attachment.
In .cfg file we just change variable from:
pre_command = "command"
to:
pre_c
So is there any plan for adding this patch set in the patch queue? I
would love to incorporate all the comments if any.
On Wed, Jul 8, 2009 at 1:47 PM, sudhir kumar wrote:
> This patch adds the wrapper for ebizzy into autotest. here is the link
> to get a copy of the test tarball.
> http://sourcef
This looks pretty clear now as the two patches do two different
things. The guest large pages support is completely independent of the
host support of large pages for the guest.
patches look good to me. thanks for splitting them.
2009/7/10 Lukáš Doktor :
> After discussion I split the patches.
>
>
After discussion I split the patches.
this patch adds autotest.libhugetlbfs test which tests hugepage support
inside of kvm guest.
Tested by:ldok...@redhat.com on RHEL5.4 with kvm-83-72.el5
Dne 9.7.2009 11:24, Lukáš Doktor napsal(a):
This patch adds kvm_hugepage variant. It prepares the host
After discussion I split the patches.
This patch adds kvm_hugepage variant. It prepares the host system and
start vm with -mem-path option. It does not clean after itself, because
it's impossible to unmount and free hugepages before all guests are
destroyed.
I need to ask you what to do with
I'm sorry this patch has a bug. hugepage variant doesn't allocate enough
memory with stress_boot (stress_boot uses different method to define VMS).
Attached the fixed patch.
Dne 9.7.2009 11:24, Lukáš Doktor napsal(a):
This patch adds kvm_hugepage variant. It prepares the host system and
start v
> +static __kprobes unsigned long fetch_memory(struct pt_regs *regs, void *addr)
> +{
> + unsigned long retval;
need a space after local variable declarations.
> + if (probe_kernel_address(addr, retval))
> + return 0;
> + return retval;
> +}
> +
> +static __kprobes unsigne
58 matches
Mail list logo
