-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Wednesday, January 09, 2013 11:05 AM
To: Pandarathil, Vijaymohan R
Cc: Bjorn Helgaas; Gleb Natapov; kvm@vger.kernel.org; qemu-
de...@nongnu.org; linux-...@vger.kernel.org;
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Wednesday, January 09, 2013 10:08 AM
To: Pandarathil, Vijaymohan R
Cc: Bjorn Helgaas; Gleb Natapov; kvm@vger.kernel.org; qemu-
de...@nongnu.org; linux-...@vger.kernel.org;
-Original Message-
From: Blue Swirl [mailto:blauwir...@gmail.com]
Sent: Wednesday, January 09, 2013 1:23 PM
To: Pandarathil, Vijaymohan R
Cc: Alex Williamson; Bjorn Helgaas; Gleb Natapov; linux-
p...@vger.kernel.org; qemu-de...@nongnu.org; kvm@vger.kernel.org; linux-
Patches 1 to 3 are trivial.
Patch 4 is the main cause of the increased lines, but I think the new
code makes it easier to understand why each condition in
__kvm_set_memory_region() is there.
If you don't agree with patch 4, please consider taking the rest of the
series at this time.
Takuya
This makes the separation between the sanity checks and the rest of the
code a bit clearer.
Signed-off-by: Takuya Yoshikawa yoshikawa_takuya...@lab.ntt.co.jp
---
virt/kvm/kvm_main.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/virt/kvm/kvm_main.c
Don't need the check for deleting an existing slot or just modifiying
the flags.
Signed-off-by: Takuya Yoshikawa yoshikawa_takuya...@lab.ntt.co.jp
---
virt/kvm/kvm_main.c | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/virt/kvm/kvm_main.c
One such variable, slot, is enough for holding a pointer temporarily.
We also remove another local variable named slot, which is limited in
a block, since it is confusing to have the same name in this function.
Signed-off-by: Takuya Yoshikawa yoshikawa_takuya...@lab.ntt.co.jp
---
KVM_SET_USER_MEMORY_REGION forces __kvm_set_memory_region() to identify
what kind of change is being requested by checking the parameters. The
current code does this checking at various points in code and each
condition used there is not easy to understand at first glance.
This patch
On Thu, Jan 10, 2013 at 10:51:57PM +0800, ak...@redhat.com wrote:
@@ -349,6 +351,13 @@ static int virtio_net_handle_mac(VirtIONet *n, uint8_t
cmd,
{
struct virtio_net_ctrl_mac mac_data;
+if (cmd == VIRTIO_NET_CTRL_MAC_ADDR_SET elem-out_num == 2) {
+/* Set MAC address
On Fri, Jan 11, 2013 at 02:37:15AM +, Zhang, Yang Z wrote:
Gleb Natapov wrote on 2013-01-10:
On Thu, Jan 10, 2013 at 08:32:06AM +, Zhang, Yang Z wrote:
Gleb Natapov wrote on 2013-01-10:
On Thu, Jan 10, 2013 at 03:26:07PM +0800, Yang Zhang wrote:
From: Yang Zhang
Bit 9 of MSR_IA32_VMX_PROCBASED_CTLS2 is
virtual interrupt delivery.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/scripts/kvm/vmxcap b/scripts/kvm/vmxcap
index cbe6440..0b23f77 100755
--- a/scripts/kvm/vmxcap
+++ b/scripts/kvm/vmxcap
@@ -147,6 +147,7 @@ controls = [
On Fri, Jan 11, 2013 at 04:18:22AM +0800, Xiao Guangrong wrote:
On 01/11/2013 03:48 AM, Marcelo Tosatti wrote:
On Fri, Jan 11, 2013 at 02:05:33AM +0800, Xiao Guangrong wrote:
On 01/11/2013 01:26 AM, Marcelo Tosatti wrote:
On Tue, Jan 08, 2013 at 02:38:36PM +0800, Xiao Guangrong wrote:
The
On Fri, Jan 11, 2013 at 02:16:11AM +0800, Xiao Guangrong wrote:
On 01/11/2013 01:30 AM, Marcelo Tosatti wrote:
On Tue, Jan 08, 2013 at 02:38:36PM +0800, Xiao Guangrong wrote:
The current reexecute_instruction can not well detect the failed
instruction
emulation. It allows guest to retry
On Thu, Jan 10, 2013 at 07:36:28PM -0200, Marcelo Tosatti wrote:
Hi,
Getting into good shape.
On Thu, Jan 10, 2013 at 03:26:08PM +0800, Yang Zhang wrote:
From: Yang Zhang yang.z.zh...@intel.com
Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
manually, which is
On 01/11/2013 09:15 PM, Marcelo Tosatti wrote:
This is cryptic. Its not obvious at all for someone modifying the code,
for example.
Can you please clear it explicitly?
Sure, this is the patch to apply your idea, is it good to you? :)
On 1/10/2013 11:46 PM, Michael S. Tsirkin wrote:
On Fri, Jan 11, 2013 at 12:53:07PM +1030, Rusty Russell wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Thu, Jan 10, 2013 at 10:45:39PM +0800, ak...@redhat.com wrote:
From: Amos Kong ak...@redhat.com
Currenly mac is programmed byte by
W dniu 09.01.2013 11:15, Gleb Natapov pisze:
On Tue, Jan 08, 2013 at 09:45:35PM +0100, Artur Samborski wrote:
W dniu 08.01.2013 00:00, Marcelo Tosatti pisze:
On Mon, Jan 07, 2013 at 06:13:22PM +0100, Artur Samborski wrote:
Hello,
When i try to run FreeBSD-amd64 on more than 1 vcpu in
On 11.01.2013, at 02:10, Scott Wood wrote:
On 01/10/2013 06:35:02 PM, Marcelo Tosatti wrote:
On Thu, Jan 10, 2013 at 04:40:12PM -0600, Scott Wood wrote:
On 01/10/2013 04:28:01 PM, Marcelo Tosatti wrote:
Or just have KVM_SET_PPC_DEVICE_ADDRESS. Is there a downside to that?
Besides the
On Thu, Jan 10, 2013 at 11:40:07PM -0700, Matthew Ogilvie wrote:
On Tue, Jan 08, 2013 at 09:31:19AM +0200, Gleb Natapov wrote:
On Mon, Jan 07, 2013 at 06:17:22PM -0600, mmogi...@miniinfo.net wrote:
On Mon, 7 Jan 2013 11:39:18 +0200, Gleb Natapov g...@redhat.com wrote:
On Wed, Dec 26,
On Fri, 2013-01-11 at 08:45 +, Pandarathil, Vijaymohan R wrote:
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Wednesday, January 09, 2013 11:05 AM
To: Pandarathil, Vijaymohan R
Cc: Bjorn Helgaas; Gleb Natapov; kvm@vger.kernel.org; qemu-
On Fri, 2013-01-11 at 08:53 +, Pandarathil, Vijaymohan R wrote:
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Wednesday, January 09, 2013 10:08 AM
To: Pandarathil, Vijaymohan R
Cc: Bjorn Helgaas; Gleb Natapov; kvm@vger.kernel.org; qemu-
On Fri, Jan 11, 2013 at 07:36:44AM +, Zhang, Yang Z wrote:
Gleb Natapov wrote on 2013-01-10:
On Thu, Jan 10, 2013 at 12:22:51PM +, Zhang, Yang Z wrote:
Gleb Natapov wrote on 2013-01-10:
On Thu, Jan 10, 2013 at 11:54:21AM +, Zhang, Yang Z wrote:
The right logic should be:
On Thu, Jan 10, 2013 at 04:06:45PM +, Marc Zyngier wrote:
+int kvm_psci_call(struct kvm_vcpu *vcpu)
+{
+ unsigned long psci_fn = *vcpu_reg(vcpu, 0) ~((u32) 0);
+ unsigned long val;
+
+ switch (psci_fn) {
+ case KVM_PSCI_FN_CPU_OFF:
+
On 11/01/13 17:12, Russell King - ARM Linux wrote:
On Thu, Jan 10, 2013 at 04:06:45PM +, Marc Zyngier wrote:
+int kvm_psci_call(struct kvm_vcpu *vcpu)
+{
+unsigned long psci_fn = *vcpu_reg(vcpu, 0) ~((u32) 0);
+unsigned long val;
+
+switch (psci_fn) {
+case
On Fri, Jan 11, 2013 at 12:24 PM, Marc Zyngier marc.zyng...@arm.com wrote:
On 11/01/13 17:12, Russell King - ARM Linux wrote:
On Thu, Jan 10, 2013 at 04:06:45PM +, Marc Zyngier wrote:
+int kvm_psci_call(struct kvm_vcpu *vcpu)
+{
+unsigned long psci_fn = *vcpu_reg(vcpu, 0) ~((u32) 0);
On Fri, Jan 11, 2013 at 12:33:15PM -0500, Christoffer Dall wrote:
On Fri, Jan 11, 2013 at 12:24 PM, Marc Zyngier marc.zyng...@arm.com wrote:
On 11/01/13 17:12, Russell King - ARM Linux wrote:
On Thu, Jan 10, 2013 at 04:06:45PM +, Marc Zyngier wrote:
+int kvm_psci_call(struct kvm_vcpu
On 11/01/13 17:33, Christoffer Dall wrote:
On Fri, Jan 11, 2013 at 12:24 PM, Marc Zyngier marc.zyng...@arm.com wrote:
On 11/01/13 17:12, Russell King - ARM Linux wrote:
On Thu, Jan 10, 2013 at 04:06:45PM +, Marc Zyngier wrote:
+int kvm_psci_call(struct kvm_vcpu *vcpu)
+{
+unsigned
On Fri, Jan 11, 2013 at 12:43 PM, Marc Zyngier marc.zyng...@arm.com wrote:
On 11/01/13 17:33, Christoffer Dall wrote:
On Fri, Jan 11, 2013 at 12:24 PM, Marc Zyngier marc.zyng...@arm.com wrote:
On 11/01/13 17:12, Russell King - ARM Linux wrote:
On Thu, Jan 10, 2013 at 04:06:45PM +, Marc
On Fri, Jan 11, 2013 at 12:48:45PM -0500, Christoffer Dall wrote:
again, that's why I suggest returning a bool instead. You just said
it: it's a basic handled/not-handled state. Why do you want to return
-EINVAL if that's not propogated anywhere?
We have a well established principle throughout
Move inside irq_lock protection.
void kvm_unregister_irq_ack_notifier(struct kvm *kvm,
@@ -270,6 +291,7 @@ void kvm_unregister_irq_ack_notifier(struct kvm *kvm,
hlist_del_init_rcu(kian-link);
mutex_unlock(kvm-irq_lock);
synchronize_rcu();
+
On Fri, Jan 11, 2013 at 12:57 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Jan 11, 2013 at 12:48:45PM -0500, Christoffer Dall wrote:
again, that's why I suggest returning a bool instead. You just said
it: it's a basic handled/not-handled state. Why do you want to return
On 11/01/13 17:48, Christoffer Dall wrote:
On Fri, Jan 11, 2013 at 12:43 PM, Marc Zyngier marc.zyng...@arm.com wrote:
On 11/01/13 17:33, Christoffer Dall wrote:
On Fri, Jan 11, 2013 at 12:24 PM, Marc Zyngier marc.zyng...@arm.com wrote:
On 11/01/13 17:12, Russell King - ARM Linux wrote:
On
On Fri, Jan 11, 2013 at 01:07:31PM -0500, Christoffer Dall wrote:
The _very_ good reason here, is that we have two success cases: return
to guest and return to user space. As I said, we can save this state
in another bit somewhere and change all the KVM/ARM code to do so, but
the KVM guys back
On Fri, Jan 11, 2013 at 1:14 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Jan 11, 2013 at 01:07:31PM -0500, Christoffer Dall wrote:
The _very_ good reason here, is that we have two success cases: return
to guest and return to user space. As I said, we can save this state
On Fri, Jan 11, 2013 at 1:09 PM, Marc Zyngier marc.zyng...@arm.com wrote:
On 11/01/13 17:48, Christoffer Dall wrote:
On Fri, Jan 11, 2013 at 12:43 PM, Marc Zyngier marc.zyng...@arm.com wrote:
On 11/01/13 17:33, Christoffer Dall wrote:
On Fri, Jan 11, 2013 at 12:24 PM, Marc Zyngier
On Fri, Jan 11, 2013 at 08:46:35AM -0700, Alex Williamson wrote:
On Fri, 2013-01-11 at 08:45 +, Pandarathil, Vijaymohan R wrote:
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Wednesday, January 09, 2013 11:05 AM
To: Pandarathil,
On Fri, Jan 11, 2013 at 02:26:51AM -0500, Christoffer Dall wrote:
On 10/01/2013, at 20.10, Scott Wood scottw...@freescale.com wrote:
On 01/10/2013 06:35:02 PM, Marcelo Tosatti wrote:
On Thu, Jan 10, 2013 at 04:40:12PM -0600, Scott Wood wrote:
On 01/10/2013 04:28:01 PM, Marcelo Tosatti
On 11.01.2013, at 19:39, Marcelo Tosatti wrote:
On Fri, Jan 11, 2013 at 02:26:51AM -0500, Christoffer Dall wrote:
On 10/01/2013, at 20.10, Scott Wood scottw...@freescale.com wrote:
On 01/10/2013 06:35:02 PM, Marcelo Tosatti wrote:
On Thu, Jan 10, 2013 at 04:40:12PM -0600, Scott Wood wrote:
On 10.01.2013, at 23:28, Marcelo Tosatti wrote:
On Wed, Jan 09, 2013 at 10:37:20PM +0100, Alexander Graf wrote:
We can start to introduce (and fix ARM) with a generic ioctl in the MPIC
patches then.
The ioctl is already generic, except for its name.
It's making a few wrong
Can you make KVM_SET_ARM_DEVICE address extensible?
Add some reserved space and a flags field.
Can't we do this for the new ioctl that we all would agree on rather than the
interim one that's only a short term solution for a greater problem?
Alex
OK.
--
To unsubscribe from this
On Fri, Jan 11, 2013 at 2:18 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
Can you make KVM_SET_ARM_DEVICE address extensible?
Add some reserved space and a flags field.
Can't we do this for the new ioctl that we all would agree on rather than
the interim one that's only a short term
On Fri, Jan 11, 2013 at 10:12:58PM +0800, Xiao Guangrong wrote:
On 01/11/2013 09:15 PM, Marcelo Tosatti wrote:
This is cryptic. Its not obvious at all for someone modifying the code,
for example.
Can you please clear it explicitly?
Sure, this is the patch to apply your idea, is
On 01/11/2013 09:42:55 AM, Alexander Graf wrote:
On 11.01.2013, at 02:10, Scott Wood wrote:
struct kvm_device_attr {
__u32 device;
This needs some semantic specification. Is device a constant value?
Is it the return value of CREATE_IRQCHIP?
As proposed, it's up to the architecture to
Am 11.01.2013 um 21:11 schrieb Scott Wood scottw...@freescale.com:
On 01/11/2013 09:42:55 AM, Alexander Graf wrote:
On 11.01.2013, at 02:10, Scott Wood wrote:
struct kvm_device_attr {
__u32 device;
This needs some semantic specification. Is device a constant value? Is it
the return
44 matches
Mail list logo
