On 11/24/10 03:38, Hidetoshi Seto wrote:
This patch introduce a fallback mechanism for old systems that do not
support utimensat(). This fix build failure with following warnings:
hw/virtio-9p-local.c: In function 'local_utimensat':
hw/virtio-9p-local.c:479: warning: implicit declaration of
On Tue, Nov 23, 2010 at 08:19:07PM -0500, Kevin O'Connor wrote:
Hi Gleb,
On Tue, Nov 23, 2010 at 05:31:41PM +0200, Gleb Natapov wrote:
Anthony, Blue
No comments on this patch series for almost a week. Can it be applied?
My apologies - I haven't had time to review.
On Wed, Nov 17,
On Thursday, November 11, 2010 02:31:06 am Avi Kivity wrote:
Daniel, the buildbot has been fairly effective in keeping qemu-kvm.git
building. I'd like to extend that to kvm.git, especially for non-x86
architectures.
First test builds succeed for x86 and ia64:
On 11/24/2010 12:15 PM, Daniel Gollub wrote:
On Thursday, November 11, 2010 02:31:06 am Avi Kivity wrote:
Daniel, the buildbot has been fairly effective in keeping qemu-kvm.git
building. I'd like to extend that to kvm.git, especially for non-x86
architectures.
First test builds succeed
Am 23.11.2010 15:53, schrieb Stefan Hajnoczi:
On Tue, Nov 23, 2010 at 2:37 PM, Kevin Wolf kw...@redhat.com wrote:
Am 22.11.2010 14:55, schrieb Stefan Hajnoczi:
On Mon, Nov 22, 2010 at 1:38 PM, Juan Quintela quint...@redhat.com wrote:
Please send in any agenda items you are interested in
On Wed, Nov 24, 2010 at 02:49:26PM +0800, lidong chen wrote:
apply the patch, and disable CONFIG_SCHED_DEBUG, the result is worse,
the cpu rate of host os is 143%.
Interesting. What does perf top show?
--
MST
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a
This patchset adds an API test framework. Rather than driving kvm from qemu,
we now have a way of calling the kvm API directly and observing the results.
We can switch to guest mode and back at will and see any micro effects such
as the result of executing particular instructions.
As an
Signed-off-by: Avi Kivity a...@redhat.com
---
Makefile |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index d25e6f2..9b0256d 100644
--- a/Makefile
+++ b/Makefile
@@ -30,11 +30,13 @@ CFLAGS += -O1
CFLAGS += $(autodepend-flags) -g
Introduce exception-safe objects for calling system, vm, and vcpu ioctls.
Signed-off-by: Avi Kivity a...@redhat.com
---
api/kvmxx.cc | 168 ++
api/kvmxx.h | 80 +++
2 files changed, 248 insertions(+), 0
Call a function setting a global variable.
Signed-off-by: Avi Kivity a...@redhat.com
---
config-x86-common.mak |8 +++-
x86/api-sample.cc | 23 +++
2 files changed, 30 insertions(+), 1 deletions(-)
create mode 100644 x86/api-sample.cc
diff --git
This patch provides a way to establish an identity guest which has
a 1:1 gva-hva translation. This allows the host to switch to guest
mode, call a function in the same address space, and return.
Because long mode virtual addresses are 47 bits long, and some hosts
have smaller physical addresses,
On 24.11.2010, at 11:52, Avi Kivity wrote:
Introduce exception-safe objects for calling system, vm, and vcpu ioctls.
Signed-off-by: Avi Kivity a...@redhat.com
FWIW, I still disagree with C++ and believe this code to be hardly readable.
Alex
--
To unsubscribe from this list: send the
On Wed, Nov 24, 2010 at 01:59:14PM +0100, Alexander Graf wrote:
On 24.11.2010, at 11:52, Avi Kivity wrote:
Introduce exception-safe objects for calling system, vm, and vcpu ioctls.
Signed-off-by: Avi Kivity a...@redhat.com
FWIW, I still disagree with C++ and believe this code to
On 11/24/2010 02:18 AM, Avi Kivity wrote:
On 11/23/2010 06:49 PM, Anthony Liguori wrote:
qemu-kvm vcpu threads don't response to SIGSTOP/SIGCONT. Instead of
teaching
them to respond to these signals (which cannot be trapped), use
SIGUSR1 to
approximate the behavior of SIGSTOP/SIGCONT.
The
Hello All,
I am Prasad Joshi, studying in a UK University. As a part of project in the
University, I have decided to add GPGPU support in the KVM using virtio. There
are two parts of supporting GPU in VM
1. GPU as a Graphics Device
2. GPU as a Parallel Programming Device (GPGPU)
For this
On 11/24/2010 04:52 AM, Avi Kivity wrote:
Introduce exception-safe objects for calling system, vm, and vcpu ioctls.
Signed-off-by: Avi Kivitya...@redhat.com
---
api/kvmxx.cc | 168 ++
api/kvmxx.h | 80 +++
2
On 11/24/2010 06:59 AM, Alexander Graf wrote:
On 24.11.2010, at 11:52, Avi Kivity wrote:
Introduce exception-safe objects for calling system, vm, and vcpu ioctls.
Signed-off-by: Avi Kivitya...@redhat.com
FWIW, I still disagree with C++ and believe this code to be hardly readable.
On 11/24/2010 03:58 PM, Anthony Liguori wrote:
On 11/24/2010 02:18 AM, Avi Kivity wrote:
On 11/23/2010 06:49 PM, Anthony Liguori wrote:
qemu-kvm vcpu threads don't response to SIGSTOP/SIGCONT. Instead of
teaching
them to respond to these signals (which cannot be trapped), use
SIGUSR1 to
On 11/24/2010 08:18 AM, Anthony Liguori wrote:
On 11/24/2010 06:59 AM, Alexander Graf wrote:
On 24.11.2010, at 11:52, Avi Kivity wrote:
Introduce exception-safe objects for calling system, vm, and vcpu
ioctls.
Signed-off-by: Avi Kivitya...@redhat.com
FWIW, I still disagree with C++ and
On 11/24/2010 04:10 PM, Anthony Liguori wrote:
On 11/24/2010 04:52 AM, Avi Kivity wrote:
Introduce exception-safe objects for calling system, vm, and vcpu
ioctls.
+
+namespace kvm {
+
+static long check_error(long r)
+{
+if (r == -1) {
+throw errno;
+}
+return r;
+}
It's
On 11/24/2010 02:59 PM, Alexander Graf wrote:
On 24.11.2010, at 11:52, Avi Kivity wrote:
Introduce exception-safe objects for calling system, vm, and vcpu ioctls.
Signed-off-by: Avi Kivitya...@redhat.com
FWIW, I still disagree with C++ and believe this code to be hardly readable.
The
On 11/24/2010 04:18 PM, Anthony Liguori wrote:
On 11/24/2010 06:59 AM, Alexander Graf wrote:
On 24.11.2010, at 11:52, Avi Kivity wrote:
Introduce exception-safe objects for calling system, vm, and vcpu
ioctls.
Signed-off-by: Avi Kivitya...@redhat.com
FWIW, I still disagree with C++ and
On 11/24/2010 06:59 AM, Alexander Graf wrote:
On 24.11.2010, at 11:52, Avi Kivity wrote:
Introduce exception-safe objects for calling system, vm, and vcpu ioctls.
Signed-off-by: Avi Kivitya...@redhat.com
FWIW, I still disagree with C++ and believe this code to be hardly readable.
On 11/24/2010 08:29 AM, Avi Kivity wrote:
On 11/24/2010 04:10 PM, Anthony Liguori wrote:
On 11/24/2010 04:52 AM, Avi Kivity wrote:
Introduce exception-safe objects for calling system, vm, and vcpu
ioctls.
+
+namespace kvm {
+
+static long check_error(long r)
+{
+if (r == -1) {
+throw
On 11/24/2010 04:45 PM, Anthony Liguori wrote:
What would the object do besides adding tons of accessors?
I would think that you'd have a single object that represented the
full CPU state and then you'd have methods that allowed individual
groups to be refreshed.
Something like:
struct
On 11/24/2010 08:53 AM, Avi Kivity wrote:
struct x86_vcpu : public vcpu
{
uint64_t eax;
uint64_t ebx;
uint64_t ecx;
//...
void get_gps(void);
void put_gps(void);
void get_sregs(void);
void put_sregs(void);
std::string repr(void);
};
I'm not of the
On Wed, Nov 24, 2010 at 08:41:26AM -0600, Anthony Liguori wrote:
On 11/24/2010 06:59 AM, Alexander Graf wrote:
On 24.11.2010, at 11:52, Avi Kivity wrote:
Introduce exception-safe objects for calling system, vm, and vcpu ioctls.
Signed-off-by: Avi Kivitya...@redhat.com
FWIW, I still
On 11/24/2010 09:40 AM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 08:41:26AM -0600, Anthony Liguori wrote:
On 11/24/2010 06:59 AM, Alexander Graf wrote:
On 24.11.2010, at 11:52, Avi Kivity wrote:
Introduce exception-safe objects for calling system, vm, and vcpu ioctls.
On 11/24/2010 05:50 PM, Anthony Liguori wrote:
Any sane modern language gives you that. Why C++?
Because I don't think we can implement a reasonable device model using
a garbage collected language. Garbage collection introduces
non-determinism and in QEMU we need to ensure that when
On Wed, Nov 24, 2010 at 09:50:35AM -0600, Anthony Liguori wrote:
On 11/24/2010 09:40 AM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 08:41:26AM -0600, Anthony Liguori wrote:
On 11/24/2010 06:59 AM, Alexander Graf wrote:
On 24.11.2010, at 11:52, Avi Kivity wrote:
Introduce exception-safe
On 11/24/2010 06:12 PM, Gleb Natapov wrote:
Why would we specify a PIIX3 device based on a configuration file?
There is only one PIIX3 device in the world. I don't see a lot of
need to create arbitrary types of devices.
Why deny this flexibility from those who need it for modelling
On Wed, Nov 24, 2010 at 06:14:22PM +0200, Avi Kivity wrote:
On 11/24/2010 06:12 PM, Gleb Natapov wrote:
Why would we specify a PIIX3 device based on a configuration file?
There is only one PIIX3 device in the world. I don't see a lot of
need to create arbitrary types of devices.
On 11/24/2010 06:21 PM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 06:14:22PM +0200, Avi Kivity wrote:
On 11/24/2010 06:12 PM, Gleb Natapov wrote:
Why would we specify a PIIX3 device based on a configuration file?
There is only one PIIX3 device in the world. I don't see a lot of
On 11/24/10 13:59, Alexander Graf wrote:
On 24.11.2010, at 11:52, Avi Kivity wrote:
Introduce exception-safe objects for calling system, vm, and vcpu ioctls.
Signed-off-by: Avi Kivity a...@redhat.com
FWIW, I still disagree with C++ and believe this code to be hardly readable.
YUCK!
On Wed, Nov 24, 2010 at 06:25:44PM +0200, Avi Kivity wrote:
On 11/24/2010 06:21 PM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 06:14:22PM +0200, Avi Kivity wrote:
On 11/24/2010 06:12 PM, Gleb Natapov wrote:
Why would we specify a PIIX3 device based on a configuration file?
On 11/24/2010 06:29 PM, Gleb Natapov wrote:
Besides, as I said, PIIX3 is ISA bridge and this
is what class should implement.
Isn't it an ISA bridge + a few ISA devices?
Why? Because they happen to be on the same silicon? So then in SoC
all devices are in cpu?
PIIX3
On 11/24/2010 06:29 PM, Jes Sorensen wrote:
FWIW, I still disagree with C++ and believe this code to be hardly readable.
YUCK!
It's got :'s all over the place that makes no sense whatsoever :(
You've got two in one sentence! Practice what you preach.
--
error compiling committee.c: too
On 11/24/10 16:50, Anthony Liguori wrote:
On 11/24/2010 09:40 AM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 08:41:26AM -0600, Anthony Liguori wrote:
In real hardware, the i8042 (keyboard controller) is actually
implemented in the PIIX3 which is a chip that is part of the i440fx.
The i440fx
On 11/24/2010 10:12 AM, Gleb Natapov wrote:
Why would we specify a PIIX3 device based on a configuration file?
There is only one PIIX3 device in the world. I don't see a lot of
need to create arbitrary types of devices.
Why deny this flexibility from those who need it for modelling
On 11/24/2010 10:21 AM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 06:14:22PM +0200, Avi Kivity wrote:
On 11/24/2010 06:12 PM, Gleb Natapov wrote:
Why would we specify a PIIX3 device based on a configuration file?
There is only one PIIX3 device in the world. I don't see a lot
On 11/24/10 17:34, Avi Kivity wrote:
On 11/24/2010 06:29 PM, Jes Sorensen wrote:
FWIW, I still disagree with C++ and believe this code to be hardly
readable.
YUCK!
It's got :'s all over the place that makes no sense whatsoever :(
You've got two in one sentence! Practice what you
On 11/24/2010 06:40 PM, Jes Sorensen wrote:
The fact that in physical implementation they sit in the same silicon
does not mean that logically they belong to the same class. PIIX3
is ISA bridge. It doesn't mean it owns devices on the ISA bus it
provides. The information that you are
On Wed, Nov 24, 2010 at 10:43:57AM -0600, Anthony Liguori wrote:
On 11/24/2010 10:21 AM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 06:14:22PM +0200, Avi Kivity wrote:
On 11/24/2010 06:12 PM, Gleb Natapov wrote:
Why would we specify a PIIX3 device based on a configuration file?
There is
On 11/24/2010 06:44 PM, Jes Sorensen wrote:
It's got :'s all over the place that makes no sense whatsoever :(
You've got two in one sentence! Practice what you preach.
If you want to reject my patches due to my broken English, go ahead. At
least it should be somewhat readable.
I was
On 11/24/10 17:47, Avi Kivity wrote:
On 11/24/2010 06:40 PM, Jes Sorensen wrote:
Well the problem here is that the i8042 is in the i440fx.c file, it
shouldn't be there in the first place. The gluing together things in
silicon is really just a way to shorten the wires and make it easier,
they
On Wed, Nov 24, 2010 at 06:33:17PM +0200, Avi Kivity wrote:
On 11/24/2010 06:29 PM, Gleb Natapov wrote:
Besides, as I said, PIIX3 is ISA bridge and this
is what class should implement.
Isn't it an ISA bridge + a few ISA devices?
Why? Because they happen to be on the
On 11/24/2010 10:40 AM, Jes Sorensen wrote:
Well the problem here is that the i8042 is in the i440fx.c file, it
shouldn't be there in the first place. The gluing together things in
silicon is really just a way to shorten the wires and make it easier,
they are still separate devices and as long
On Wed, Nov 24, 2010 at 06:47:28PM +0200, Avi Kivity wrote:
On 11/24/2010 06:40 PM, Jes Sorensen wrote:
The fact that in physical implementation they sit in the same silicon
does not mean that logically they belong to the same class. PIIX3
is ISA bridge. It doesn't mean it owns devices
On 11/24/2010 10:48 AM, Gleb Natapov wrote:
They *aren't* ISA devices. Look at the PIIX3 spec. All of the
ports for these devices are positively decoded and not sent over the
ISA bus.
Over the external ISA bus you mean?
There is no internal ISA bus. The reality is that the PIIX3
On 11/24/2010 06:52 PM, Gleb Natapov wrote:
Plus some magic glue. You can't say it is an ISA bridge. It's
exactly what its spec says it is.
First thing my spec says is Bridge Between the PCI Bus and ISA Bus
It's the first item in a list of features. Be serious.
I couldn't
On 11/24/2010 10:51 AM, Jes Sorensen wrote:
On 11/24/10 17:47, Avi Kivity wrote:
On 11/24/2010 06:40 PM, Jes Sorensen wrote:
Well the problem here is that the i8042 is in the i440fx.c file, it
shouldn't be there in the first place. The gluing together things in
silicon is really just
On 11/24/2010 06:51 PM, Jes Sorensen wrote:
On 11/24/10 17:47, Avi Kivity wrote:
On 11/24/2010 06:40 PM, Jes Sorensen wrote:
Well the problem here is that the i8042 is in the i440fx.c file, it
shouldn't be there in the first place. The gluing together things in
silicon is really just a
On 11/24/2010 06:55 PM, Gleb Natapov wrote:
What you did above is making the exact same mistake as is done with the
current i440fx.c code.
If a real life 440fx has an i8042, then an emulated 440fx should
have an emulated i8042. It's not complicated.
Correct. But it can be achieved
On Wed, Nov 24, 2010 at 06:56:52PM +0200, Avi Kivity wrote:
On 11/24/2010 06:52 PM, Gleb Natapov wrote:
Plus some magic glue. You can't say it is an ISA bridge. It's
exactly what its spec says it is.
First thing my spec says is Bridge Between the PCI Bus and ISA Bus
It's the first
On 11/24/10 17:53, Anthony Liguori wrote:
On 11/24/2010 10:40 AM, Jes Sorensen wrote:
Well the problem is the 10% you are talking about is another 30% loss
because the code is now practically unreadable, plus you open up the can
of worms that people will start using some of the totally
On Wed, Nov 24, 2010 at 10:56:15AM -0600, Anthony Liguori wrote:
On 11/24/2010 10:48 AM, Gleb Natapov wrote:
They *aren't* ISA devices. Look at the PIIX3 spec. All of the
ports for these devices are positively decoded and not sent over the
ISA bus.
Over the external ISA bus you mean?
On 11/24/10 17:59, Avi Kivity wrote:
On 11/24/2010 06:51 PM, Jes Sorensen wrote:
Right we need good design for our C code, which we are lacking to a
large extend. However that has nothing to do with the language, that has
to do with the developers.
I'm sure patches will be welcome.
C++
On 11/24/2010 07:02 PM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 06:56:52PM +0200, Avi Kivity wrote:
On 11/24/2010 06:52 PM, Gleb Natapov wrote:
Plus some magic glue. You can't say it is an ISA bridge. It's
exactly what its spec says it is.
First thing my spec says is
On 11/24/10 18:07, Avi Kivity wrote:
On 11/24/2010 07:02 PM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 06:56:52PM +0200, Avi Kivity wrote:
On 11/24/2010 06:52 PM, Gleb Natapov wrote:
Plus some magic glue. You can't say it is an ISA bridge. It's
exactly what its spec says it
On 11/24/2010 07:06 PM, Jes Sorensen wrote:
On 11/24/10 17:59, Avi Kivity wrote:
On 11/24/2010 06:51 PM, Jes Sorensen wrote:
Right we need good design for our C code, which we are lacking to a
large extend. However that has nothing to do with the language, that has
to do with the
On 11/24/2010 07:10 PM, Jes Sorensen wrote:
On 11/24/10 18:07, Avi Kivity wrote:
On 11/24/2010 07:02 PM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 06:56:52PM +0200, Avi Kivity wrote:
On 11/24/2010 06:52 PM, Gleb Natapov wrote:
Plus some magic glue. You can't say it is an ISA
On 11/24/2010 11:07 AM, Avi Kivity wrote:
On 11/24/2010 07:02 PM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 06:56:52PM +0200, Avi Kivity wrote:
On 11/24/2010 06:52 PM, Gleb Natapov wrote:
Plus some magic glue. You can't say it is an ISA bridge. It's
exactly what its spec says it
On Wed, Nov 24, 2010 at 07:01:00PM +0200, Avi Kivity wrote:
On 11/24/2010 06:55 PM, Gleb Natapov wrote:
What you did above is making the exact same mistake as is done with the
current i440fx.c code.
If a real life 440fx has an i8042, then an emulated 440fx should
have an
On 11/24/10 18:11, Avi Kivity wrote:
On 11/24/2010 07:06 PM, Jes Sorensen wrote:
Sorry but that is utterly and completely bogus! The enforcement is only
as good as the developers and maintainers make it,
class File {
public:
virtual ~File() {}
virtual void read(...) = 0;
On 11/24/2010 07:17 PM, Jes Sorensen wrote:
Anyone wishing to implement this interface is forced to implement read
and write methods (callbacks) with exactly the right signature. The
compiler will complain if they don't. So if File is a good interface,
we can make the compiler force
On 11/24/2010 07:16 PM, Gleb Natapov wrote:
If the i8042 is completely stock, we write
class i440fx {
private:
i8042 kbc;
}
(or the C equivalent)
If it's not completely stock, we substitute some subclass that takes
care of the differences.
And if you want to connect ISA
On 11/24/2010 11:17 AM, Jes Sorensen wrote:
On 11/24/10 18:11, Avi Kivity wrote:
On 11/24/2010 07:06 PM, Jes Sorensen wrote:
Sorry but that is utterly and completely bogus! The enforcement is only
as good as the developers and maintainers make it,
class File {
public:
On 11/24/10 18:25, Avi Kivity wrote:
On 11/24/2010 07:17 PM, Jes Sorensen wrote:
In the mean time we spend our time debugging the runtime because the
virtual functions don't behave as expected. In C we know what is going
on, in C++ it is pray and hope.
That is pure bullshit. All major
On 11/24/2010 06:57 PM, Anthony Liguori wrote:
It's a question of how it is accessed, if it is treated like an ISA
device by the silicon, we should treat it like an ISA device in QEMU,
rather than pretend it is something that it isn't.
Does anyone have any evidence that the i8042 has anything
On 11/24/2010 07:28 PM, Jes Sorensen wrote:
On 11/24/10 18:25, Avi Kivity wrote:
On 11/24/2010 07:17 PM, Jes Sorensen wrote:
In the mean time we spend our time debugging the runtime because the
virtual functions don't behave as expected. In C we know what is going
on, in C++ it is pray
On Wed, Nov 24, 2010 at 10:40:05AM -0600, Anthony Liguori wrote:
On 11/24/2010 10:12 AM, Gleb Natapov wrote:
Why would we specify a PIIX3 device based on a configuration file?
There is only one PIIX3 device in the world. I don't see a lot of
need to create arbitrary types of devices.
Why
On 11/24/2010 07:27 PM, Anthony Liguori wrote:
The alternative in C is:
struct file_operations {
void (*release)(void);
void (*read)(...);
void (*write)(...);
};
struct file {
struct file_operations *ops;
};
If I do:
static file_operations posix_file_ops = {
.read =
On Wed, Nov 24, 2010 at 07:25:08PM +0200, Avi Kivity wrote:
On 11/24/2010 07:17 PM, Jes Sorensen wrote:
Anyone wishing to implement this interface is forced to implement read
and write methods (callbacks) with exactly the right signature. The
compiler will complain if they don't. So
On 11/24/10 18:27, Anthony Liguori wrote:
The compiler won't generate an error. Only upon a call to
file_release() will a null pointer dereference happens whereas in C++,
because this paradigm is structured in the language, the compiler can
help assist you.
Explicit code means you know what
On 11/24/2010 07:33 PM, Gleb Natapov wrote:
But I don't see the point. If you look at my repository, there's
The point is that C++ is ugly language. The short code Avi sent remind
me perl (aka line noise). It is almost impossible to parse it into
what code it actually does. Most symbols are
On Wed, Nov 24, 2010 at 07:39:39PM +0200, Avi Kivity wrote:
On 11/24/2010 07:33 PM, Gleb Natapov wrote:
But I don't see the point. If you look at my repository, there's
The point is that C++ is ugly language. The short code Avi sent remind
me perl (aka line noise). It is almost impossible
On 11/24/2010 07:36 PM, Jes Sorensen wrote:
On 11/24/10 18:27, Anthony Liguori wrote:
The compiler won't generate an error. Only upon a call to
file_release() will a null pointer dereference happens whereas in C++,
because this paradigm is structured in the language, the compiler can
On Wed, Nov 24, 2010 at 07:41:48PM +0200, Avi Kivity wrote:
On 11/24/2010 07:36 PM, Jes Sorensen wrote:
On 11/24/10 18:27, Anthony Liguori wrote:
The compiler won't generate an error. Only upon a call to
file_release() will a null pointer dereference happens whereas in C++,
because
On 11/24/10 18:41, Avi Kivity wrote:
On 11/24/2010 07:36 PM, Jes Sorensen wrote:
On 11/24/10 18:27, Anthony Liguori wrote:
The compiler won't generate an error. Only upon a call to
file_release() will a null pointer dereference happens whereas in C++,
because this paradigm is
On 11/24/2010 11:36 AM, Jes Sorensen wrote:
On 11/24/10 18:27, Anthony Liguori wrote:
The compiler won't generate an error. Only upon a call to
file_release() will a null pointer dereference happens whereas in C++,
because this paradigm is structured in the language, the compiler can
help
From: Borislav Petkov borislav.pet...@amd.com
Add a wbinvd helper for an arbitrary set of CPUs.
Signed-off-by: Borislav Petkov borislav.pet...@amd.com
---
arch/x86/include/asm/smp.h |4 +++-
arch/x86/lib/cache-smp.c | 12
2 files changed, 15 insertions(+), 1 deletions(-)
From: Borislav Petkov borislav.pet...@amd.com
Replace local wbinvd helpers with equivalent x86 library functions.
Signed-off-by: Borislav Petkov borislav.pet...@amd.com
---
arch/x86/kvm/x86.c | 14 +++---
1 files changed, 3 insertions(+), 11 deletions(-)
diff --git
On 11/24/10 18:43, Anthony Liguori wrote:
On 11/24/2010 11:36 AM, Jes Sorensen wrote:
On 11/24/10 18:27, Anthony Liguori wrote:
The compiler won't generate an error. Only upon a call to
file_release() will a null pointer dereference happens whereas in C++,
because this paradigm is
On 11/24/2010 09:44 AM, Borislav Petkov wrote:
From: Borislav Petkov borislav.pet...@amd.com
Add a wbinvd helper for an arbitrary set of CPUs.
Are there any expected users of this other than KVM?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I
On 11/24/2010 07:41 PM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 07:39:39PM +0200, Avi Kivity wrote:
On 11/24/2010 07:33 PM, Gleb Natapov wrote:
But I don't see the point. If you look at my repository, there's
The point is that C++ is ugly language. The short code Avi sent remind
On 11/24/2010 07:36 PM, Gleb Natapov wrote:
That is pure bullshit. All major browsers are written in C++, all
major office suites, one leading free desktop, google, countless
other projects. There is a lot more C++ code in the world than C
code. If virtual functions didn't behave as
On 11/24/2010 07:43 PM, Gleb Natapov wrote:
Explicit code means you know what is going on, it means you can debug it
in gdb and match it. That is a *good* thing!
Implicit code means that you don't need to debug it. The compiler
gets it right every time.
Best joke ever!
Do you
On 11/24/2010 07:43 PM, Jes Sorensen wrote:
On 11/24/10 18:41, Avi Kivity wrote:
On 11/24/2010 07:36 PM, Jes Sorensen wrote:
On 11/24/10 18:27, Anthony Liguori wrote:
The compiler won't generate an error. Only upon a call to
file_release() will a null pointer dereference happens
On 11/24/2010 07:45 PM, Jes Sorensen wrote:
So I take it you avoid switch statements, while, or for loops in your C
code.
Those map easily to assembly code and gdb.
So do virtual functions.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this
On 11/24/2010 11:45 AM, Jes Sorensen wrote:
On 11/24/10 18:43, Anthony Liguori wrote:
On 11/24/2010 11:36 AM, Jes Sorensen wrote:
On 11/24/10 18:27, Anthony Liguori wrote:
The compiler won't generate an error. Only upon a call to
file_release() will a null pointer
On Wed, Nov 24, 2010 at 07:50:44PM +0200, Avi Kivity wrote:
On 11/24/2010 07:43 PM, Gleb Natapov wrote:
Explicit code means you know what is going on, it means you can debug it
in gdb and match it. That is a *good* thing!
Implicit code means that you don't need to debug it. The
On 11/24/2010 11:33 AM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 10:40:05AM -0600, Anthony Liguori wrote:
On 11/24/2010 10:12 AM, Gleb Natapov wrote:
Why would we specify a PIIX3 device based on a configuration file?
There is only one PIIX3 device in the world. I don't
This patch adds checking for read and write intercepts
from/to DRx registers from the KVM instruction emulator
path.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/kvm/svm.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/svm.c
This patch adds intercepts checks for the remaining twobyte
instructions to the KVM instruction emulator.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/kvm/svm.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git
This patch adds intercept checks for all the group 7
instructions to the KVM instruction emulator path.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/kvm/svm.c | 53 +++-
1 files changed, 52 insertions(+), 1 deletions(-)
diff
This patch adds checks for accesses to the descriptor table
base registers to the intruction emulator path of KVM.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/kvm/svm.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git
This patch removes all the old code which handled the nested
selective cr0 write intercepts. This code was only in place
as a work-around until the instruction emulator is capable
of doing the same. This is the case with this patch-set and
so the code can be removed.
Signed-off-by: Joerg Roedel
This patch add intercept checks for emulated one-byte
instructions to the KVM instruction emulation path.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/kvm/svm.c | 36 +---
1 files changed, 33 insertions(+), 3 deletions(-)
diff --git
On Wed, Nov 24, 2010 at 12:49:06PM -0500, H. Peter Anvin wrote:
On 11/24/2010 09:44 AM, Borislav Petkov wrote:
From: Borislav Petkov borislav.pet...@amd.com
Add a wbinvd helper for an arbitrary set of CPUs.
Are there any expected users of this other than KVM?
Not that I know of. I
On Wed, Nov 24, 2010 at 07:50:06PM +0200, Avi Kivity wrote:
On 11/24/2010 07:41 PM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 07:39:39PM +0200, Avi Kivity wrote:
On 11/24/2010 07:33 PM, Gleb Natapov wrote:
But I don't see the point. If you look at my repository, there's
The
1 - 100 of 151 matches
Mail list logo
