Ping?
Paolo
Il 25/10/2012 20:35, Paolo Bonzini ha scritto:
On Thu, Oct 25, 2012 at 09:37:39AM +0200, Paolo Bonzini wrote:
Il 24/10/2012 18:47, Tejun Heo ha scritto:
So, I'm still not convinced we need to go forward with full
configurability. All use cases you described can be covered
Il 31/10/2012 22:22, Tejun Heo ha scritto:
Hello, Paolo.
On Thu, Oct 25, 2012 at 02:35:20PM -0400, Paolo Bonzini wrote:
Disabling filters if opened by root and tranfering via SCM_RIGHTS
would be the simplest interface-wise (there's no new interface at
all). Would that be too dangerous
Il 02/11/2012 17:51, Tejun Heo ha scritto:
What disturbs me is that it's a completely new interface to userland
and at the same a very limited one at that. So, yeah, it's
bothersome. I personally would prefer SCM_RIGHTS behavior change +
hard coded filters per device class.
I
filtering is desired.
This is a partial (and massaged) revert of commit 018e044 (block: get
rid of queue-private command filter, 2009-06-26).
Cc: linux-s...@vger.kernel.org
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
block/blk-sysfs.c |2 ++
block/bsg.c|2 +-
block
Using /dev/sg for scanners is blocked from unprivileged users. Reimplement
this using customizable command filters, so that the sysfs knobs will work
in this case too.
Cc: linux-s...@vger.kernel.org
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
v1-v2: OOM check [Alan Cox
v1-v2: add OOM and capability checks
Paolo Bonzini (3):
block: add back queue-private command filter
scsi: create an all-zero filter for scanners
block: add back command filter modification via sysfs
Documentation/block/queue-sysfs.txt | 16 +
block/Kconfig | 10
anyway never enabled
(they were always #if 0-ed), the different API is not a problem.
Cc: linux-s...@vger.kernel.org
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
v2-v3: OOM and capability check [Alan Cox]
Documentation/block/queue-sysfs.txt | 16 ++
block/Kconfig
Il 25/09/2012 17:35, David Howells ha scritto:
Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Generate a certificate that is valid from a few minutes before the
wallclock time. It's a certificate policy question not a kernel hackery
one.
That doesn't seem to be possible with openssl req. What
Il 03/10/2012 08:44, Rusty Russell ha scritto:
There's a reason I haven't done this. I really, really dislike my
implemention isn't broken feature bits. We could have an infinite
number of them, for each bug in each device.
However, this bug affects (almost) all implementations and (almost)
Il 04/10/2012 02:11, Rusty Russell ha scritto:
There's a reason I haven't done this. I really, really dislike my
implemention isn't broken feature bits. We could have an infinite
number of them, for each bug in each device.
However, this bug affects (almost) all implementations and
Il 25/09/2012 17:30, Paolo Bonzini ha scritto:
The set of use cases for SG_IO is quite variable that no single filter can
accomodate all of them. The current filter is tailored very much to
CD burning, and includes many MMC-specific commands that may have
other meanings in different standards
Il 04/10/2012 14:51, Rusty Russell ha scritto:
Paolo Bonzini pbonz...@redhat.com writes:
Il 04/10/2012 02:11, Rusty Russell ha scritto:
There's a reason I haven't done this. I really, really dislike my
implemention isn't broken feature bits. We could have an infinite
number of them
Il 04/10/2012 09:44, Rusty Russell ha scritto:
-In particular, no implementation should use the descriptor
-boundaries to determine the size of any header in a request.[footnote:
-The current qemu device implementations mistakenly insist that
-the first descriptor cover the header in these
Il 05/10/2012 07:43, Rusty Russell ha scritto:
struct virtio_scsi_req_cmd {
// Read-only
u8 lun[8];
u64 id;
u8 task_attr;
u8 prio;
u8 crn;
char cdb[cdb_size];
char dataout[];
// Write-only part
Il 02/11/2012 18:53, Tejun Heo ha scritto:
Hello, Paolo.
On Fri, Nov 02, 2012 at 06:49:43PM +0100, Paolo Bonzini wrote:
No rule is really absolute. To me, it seems the suggested in-kernel
per-device command code filter is both too big for the given problem
Is it? 150 lines of code
Il 03/11/2012 15:50, Alan Cox ha scritto:
It's not really about the lines of code. It adds a new userland
visible interface. As for the long list of commands, it depends on
how you write it but even if it's textually long it's still very
simple in terms of actual complexity.
Sure, but its
variable gfp_mask
virtio-scsi: use pr_err instead of printk
virtio-scsi: create a separate work queue for virtio-scsi
virtio-scsi: tidy up the goto label in init()
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Paolo Bonzini pbonz...@redhat.com
Cc: Rusty Russell ru
In one use case, the administrator then needs the ability to configure
devices easily, for example to be much more restrictive on non-MMC
devices. It must be done with the same tools it uses for other
aspects of the policy---which will be a combination of DAC (Unix
permissions and ACLs)
Il 18/10/2012 20:05, Andy Lutomirski ha scritto:
Unless something is rather buggy in kernel land (and I don't think it
is), once EPOLL_CTL_DEL has returned, no call to epoll_wait that starts
*after* EPOLL_CTL_DEL finishes will return that object. This suggests
an RCU-like approach: once
Il 19/10/2012 15:29, Paul Holland ha scritto:
A disadvantage of solutions in this direction, which was not preset in
Paton's patch, is that all calls to epoll_wait would need to specify some
timeout value (!= -1) to guarantee that they each come out of epoll_wait
and execute the pass the buck
Il 09/10/2012 06:59, Rusty Russell ha scritto:
Paolo Bonzini pbonz...@redhat.com writes:
Il 05/10/2012 07:43, Rusty Russell ha scritto:
That's good. But virtio_blk's scsi command is insoluble AFAICT. As I
said to Anthony, the best rules are always and never, so I'd really
rather not have
Il 11/10/2012 08:41, Bryan Venteicher ha scritto:
This is analogous to commit a1b383870a made by Rusty Russell to all
the VirtIO headers at the time. This eases the use of the header as
is by other OSes.
Signed-off-by: Bryan Venteicher bry...@daemoninthecloset.org
Acked-by: Paolo Bonzini
Il 12/10/2012 00:37, Rusty Russell ha scritto:
Michael S. Tsirkin m...@redhat.com writes:
On Thu, Oct 11, 2012 at 10:33:31AM +1030, Rusty Russell wrote:
OK. Well, Anthony wants qemu to be robust in this regard, so I am
tempted to rework all the qemu drivers to handle arbitrary layouts.
They
On Thu, Oct 25, 2012 at 09:37:39AM +0200, Paolo Bonzini wrote:
Il 24/10/2012 18:47, Tejun Heo ha scritto:
So, I'm still not convinced we need to go forward with full
configurability. All use cases you described can be covered with
per-class static filters + simple override switch
tgt-tgt_lock while invoking
the calls to virtio_ring.c:virtqueue_add_buf() and friends.
This bug was originally introduced in v3.5-rc7 code with:
commit 2bd37f0fde99cbf8b78fb55f1128e8c3a63cf1da
Author: Paolo Bonzini pbonz...@redhat.com
Date: Wed Jun 13 16:56:34 2012 +0200
[SCSI
:
return ret;
Acked-by: Paolo Bonzini pbonz...@redhat.com
Paolo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
Il 09/11/2012 20:31, Nicholas A. Bellinger ha scritto:
That's done on purpose. After you do virtqueue_add_buf, you don't need
the sg list anymore, nor the lock that protects it. The cover letter is
at https://lkml.org/lkml/2012/6/13/295 and had this text:
This series reorganizes the
: Ric Wheeler rwhee...@redhat.com
Cc: Tejun Heo t...@kernel.org
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
v2-v3: change bitmap filter to boolean
block/blk-sysfs.c | 32
block/scsi_ioctl.c |2 +-
include/linux/blkdev.h |3 +++
3
was NACKed).
Ok for 3.8?
v2-v3: change bitmap filter to boolean
Paolo Bonzini (2):
sg_io: pass request_queue to blk_verify_command
sg_io: introduce unpriv_sgio queue flag
block/blk-sysfs.c | 32
block/bsg.c|2 +-
block/scsi_ioctl.c |9
...@redhat.com
Cc: Tejun Heo t...@kernel.org
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
v2-v3: separated from block: add back queue-private command filter
block/bsg.c|2 +-
block/scsi_ioctl.c |7 ---
drivers/scsi/sg.c |3 ++-
include/linux/blkdev.h
The only thing that would avoid this is to either tell the compiler to
never put esi/edi in memory (which I think is not possibly across
different versions of gcc) or to always generate a single asm section
for all the different cases.
Use __asm__ (%esi) and __asm__ (%edi). It is not guaranteed
Il 04/10/2011 21:34, Greg KH ha scritto:
diff --git a/drivers/staging/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
similarity index 99%
rename from drivers/staging/hv/hyperv_vmbus.h
rename to drivers/hv/hyperv_vmbus.h
index 3d2d836..8261cb6 100644
--- a/drivers/staging/hv/hyperv_vmbus.h
Il 13/07/2012 15:13, KY Srinivasan ha scritto:
Somone was trying to be funny, I guess.
KY, I suppose you have access to Hyper-V code or can ask someone who does.
Is this signature actually used in the Hyper-V host code?
It is still early in the morning here and pardon me if I am not
code via unit attention.
This will be discarded by the high-level driver for non-removable
units. I sent a separate patch to deal with it for removable
units.
Paolo
Paolo Bonzini (2):
virtio-scsi: fix parsing of hotplug/hot-unplug LUN number
virtio-scsi: support online resizing of disks
capacity change from 22548578304 to 23622320128
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
drivers/scsi/virtio_scsi.c | 31 ++-
include/linux/virtio_scsi.h |2 ++
2 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b
to report at least one
of No medium and/or a Medium may have changed, so restrict
our attention to those.
This patch fixes resizing a removable medium with virtio-scsi.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
drivers/scsi/scsi_lib.c |7 +--
1 files changed, 5 insertions(+), 2
Hotplug/hot-unplug of a LUN whose number is greater than 255
uses the flat format for LUNs, which has bit 14 set. Clear
the bit when parsing the event structs.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
drivers/scsi/virtio_scsi.c |8 ++-
1 files changed, 6 insertions(+), 1
Il 16/07/2012 18:18, James Bottomley ha scritto:
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index b583277..6d8ca08 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -843,8 +843,11 @@ void scsi_io_completion(struct scsi_cmnd *cmd,
unsigned int
Il 17/07/2012 09:45, James Bottomley ha scritto:
On Mon, 2012-07-16 at 19:20 +0200, Paolo Bonzini wrote:
Il 16/07/2012 18:18, James Bottomley ha scritto:
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index b583277..6d8ca08 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers
Il 17/07/2012 10:29, Asias He ha scritto:
So, vhost-blk at least saves ~6 syscalls for us in each request.
Are they really 6? If I/O is coalesced by a factor of 3, for example
(i.e. each exit processes 3 requests), it's really 2 syscalls per request.
Also, is there anything we can improve?
Il 17/07/2012 10:40, James Bottomley ha scritto:
It's not specific to virtio-scsi, in fact I expect that virtio-scsi will
be almost always used with non-removable disks.
However, QEMU's SCSI target is not used just for virtio-scsi (for
example it can be used for USB storage), and it
Il 17/07/2012 11:11, James Bottomley ha scritto:
We don't do stuff just because the standards allows it; just the
opposite: we try to use the smallest implementations from the standards
we can get away with just because the more things we do, the more
exceptions and broken devices we come
Il 17/07/2012 11:21, Asias He ha scritto:
It depends. Like vhost-scsi, vhost-blk has the problem of a crippled
feature set: no support for block device formats, non-raw protocols,
etc. This makes it different from vhost-net.
Data-plane qemu also has this cripppled feature set problem, no?
Il 17/07/2012 11:45, Michael S. Tsirkin ha scritto:
So it begs the question, is it going to be used in production, or just a
useful reference tool?
Sticking to raw already makes virtio-blk faster, doesn't it?
In that vhost-blk looks to me like just another optimization option.
Ideally I
Il 17/07/2012 12:49, Michael S. Tsirkin ha scritto:
Ok, that would make more sense. One difference between vhost-blk and
vhost-net is that for vhost-blk there are also management actions that
would trigger the switch, for example a live snapshot.
So a prerequisite for vhost-blk would be that
Il 17/07/2012 14:21, James Bottomley ha scritto:
Yes, I realize failing only on specific sense codes as I did it in the
patch is not going to work. However, the other way round is not
problematic (explicitly allow some sense codes, fail on all others).
Heh, I once thought that, but there's
Il 17/07/2012 14:48, Michael S. Tsirkin ha scritto:
On Tue, Jul 17, 2012 at 01:03:39PM +0100, Stefan Hajnoczi wrote:
On Tue, Jul 17, 2012 at 12:54 PM, Michael S. Tsirkin m...@redhat.com wrote:
Knowing the answer to that is important before anyone can say whether
this approach is good or not.
Il 17/07/2012 18:36, Christoph Hellwig ha scritto:
There's no such thing in the market today as a removable disk that's
resizeable. Removable disks are for things like backup cartridges and
ageing jazz drives. Worse: most removeable devices today are USB card
readers whose standards
Il 17/07/2012 20:49, Mike Christie ha scritto:
Not sure if we are talking about the same thing.
So can virtio-scsi send a UA with asc/ascq that indicates the lun
changed size? Other drivers do this. I updated Hannes's patches the
other day to support UAs like those in userspace.
I
KVM does not use the activity state VMCS field, and does not support
it in nested VMX either (the corresponding bits in the misc VMX feature
MSR are zero). Fail entry if the activity state is set to anything but
active.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
arch/x86/kvm/vmx.c | 5
to read and write the corresponding VMCS field on L1/L2 transitions,
either.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
v1-v2: remove read/write of vmcs12-guest_activity_state,
use GUEST_ACTIVITY_ACTIVE.
arch/x86/kvm/vmx.c | 7 +--
1 file changed, 5 insertions(+), 2
And a fourth ping comes...
Jon, the next time I read it seems likely to be picked up fairly soon
(http://lwn.net/Articles/535075/), I'll picture the author of the patch
attempting open-heart surgery on a long-red-haired voodoo doll!
Paolo
Il 04/04/2013 20:18, Paolo Bonzini ha scritto:
Il 22/03
Il 22/03/2013 23:30, Paolo Bonzini ha scritto:
Il 20/02/2013 17:12, Paolo Bonzini ha scritto:
Il 06/02/2013 16:15, Paolo Bonzini ha scritto:
This series regards the whitelist that is used for the SG_IO ioctl. This
whitelist has three problems:
* the bitmap of allowed commands is designed
...@redhat.com
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
---
virt/kvm/eventfd.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index adb17f2..93e5b05 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -577,6 +577,7
Il 05/04/2013 09:10, Hu Tao ha scritto:
pvpanic device is a qemu simulated device through which guest panic
event is sent to host.
Signed-off-by: Hu Tao hu...@cn.fujitsu.com
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Matthew, it would be nice to include this in 3.10.
The implementation
Il 29/03/2013 09:34, Hu Tao ha scritto:
pvpanic device is a qemu simulated device through which guest panic
event is sent to host.
Signed-off-by: Hu Tao hu...@cn.fujitsu.com
---
ref: http://lists.nongnu.org/archive/html/qemu-devel/2013-03/msg05297.html
drivers/platform/x86/Kconfig |
Il 15/03/2013 16:29, Xiao Guangrong ha scritto:
+/*
+ * spte bits of bit 3 ~ bit 11 are used as low 9 bits of
+ * generation, the bits of bits 52 ~ bit 61 are used as
+ * high 12 bits of generation.
+ */
High 10 bits.
How often does the generation number change? Especially with Takuya's
Il 19/03/2013 12:32, James Bottomley ha scritto:
On Tue, 2013-03-19 at 17:57 +0800, Wanlong Gao wrote:
From: Paolo Bonzini pbonz...@redhat.com
virtio_scsi_target_state is now empty. We will find new uses for it in
the next few patches, so this patch does not drop it completely.
However
The CS base was initialized to 0 on VMX (wrong, but usually overridden
by userspace before starting) or 0xf on SVM. The correct value is
0x, and VMX is able to emulate it now, so use it.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
arch/x86/kvm/svm.c | 8 +---
arch/x86
APIC_DEST_SELF, which has a double effect: first,
the ICR2 register is not used and the 32-bit field of KVM_INTERRUPT is
enough; second, it ensures that the valid range of the irq field is
distinct in the userspace-APIC and kernel-APIC cases.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Il 19/03/2013 19:13, Gleb Natapov ha scritto:
There is no way for userspace to inject interrupts into a VCPU's
local APIC, which is important in order to inject INITs coming from
the chipset. KVM_INTERRUPT is currently disabled when the in-kernel
local APIC is used, so we can repurpose
Il 19/03/2013 19:50, Gleb Natapov ha scritto:
On Tue, Mar 19, 2013 at 07:39:24PM +0100, Paolo Bonzini wrote:
Il 19/03/2013 19:13, Gleb Natapov ha scritto:
There is no way for userspace to inject interrupts into a VCPU's
local APIC, which is important in order to inject INITs coming from
Il 20/03/2013 02:46, Venkatesh Srinivas ha scritto:
This looks pretty good!
I rather like the (lack of) locking in I/O completion (around the req
count vs. target/queue binding). It is unfortunate that you need to hold
the per-target lock in virtscsi_pick_vq() though; have any idea
how much
Il 20/02/2013 17:12, Paolo Bonzini ha scritto:
Il 06/02/2013 16:15, Paolo Bonzini ha scritto:
This series regards the whitelist that is used for the SG_IO ioctl. This
whitelist has three problems:
* the bitmap of allowed commands is designed for MMC devices (roughly,
play/burn CDs without
Il 20/03/2013 08:56, Wanlong Gao ha scritto:
This one does not apply on top of virtio-next + patch 1-4 in this series.
I'm very sorry.
This fault is because I modified the 4/5 from
/* if the affinity hint is set for virtqueues */
to
/* If the affinity hint is set for virtqueues */
by
Il 25/03/2013 08:25, Bart Van Assche ha scritto:
+queue_num = smp_processor_id();
+while (unlikely(queue_num = vscsi-num_queues))
+queue_num -= vscsi-num_queues;
+
+tgt-req_vq = vq = vscsi-req_vqs[queue_num];
+}
+
+
diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_daemon.c
new file mode 100644
index 000..9526995
--- /dev/null
+++ b/tools/hv/hv_vss_daemon.c
@@ -0,0 +1,220 @@
+/*
+ * An implementation of the host initiated guest snapshot for Hyper-V.
+ *
+ *
+ * Copyright (C) 2013,
suggests to send two SIPIs with some time passing
between them; the second SIPI would unblock the VCPU.
The tests in vcpu_needs_reset are organized so that the hypervisor
will go through the same number of compare-and-jump sequences as
before in the common case.
Signed-off-by: Paolo Bonzini pbonz
Il 10/03/2013 12:46, Gleb Natapov ha scritto:
On Sat, Mar 09, 2013 at 07:48:33AM +0100, Paolo Bonzini wrote:
After receiving an INIT signal (either via the local APIC, or through
KVM_SET_MP_STATE), the bootstrap processor should reset immediately
and start execution at 0xfff0. Also, SIPIs
Il 10/03/2013 16:35, Gleb Natapov ha scritto:
However, it would effectively redefine the meaning of
KVM_MP_STATE_INIT_RECEIVED and KVM_MP_STATE_SIPI_RECEIVED, respectively
to KVM_MP_STATE_WAIT_FOR_SIPI and KVM_MP_STATE_RESETTING. I wasn't sure
if this is considered an API change
Il 10/03/2013 19:10, Gleb Natapov ha scritto:
On Sun, Mar 10, 2013 at 06:19:07PM +0100, Paolo Bonzini wrote:
Il 10/03/2013 16:35, Gleb Natapov ha scritto:
However, it would effectively redefine the meaning of
KVM_MP_STATE_INIT_RECEIVED and KVM_MP_STATE_SIPI_RECEIVED, respectively
Il 11/03/2013 11:28, Gleb Natapov ha scritto:
Not really true---we do exit with that state and EINTR when we get a
SIPI. Perhaps that can be changed.
That's implementation detail. We can jump to the beginning of the
function instead. Nowhere we document that entering
at the end of struct virtio_scsi. But we do not
do that, because we will place the virtqueues there in the next patches.
Paolo
Cc: linux-s...@vger.kernel.org
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Wanlong Gao gaowanl...@cn.fujitsu.com
--
To unsubscribe from this list
Il 11/03/2013 12:51, Gleb Natapov ha scritto:
Agreed, but we still have the problem of how to signal from userspace.
For that do you have any other suggestion than mp_state? And if we keep
mp_state to signal from userspace, giving INIT_RECEIVED the
wait-for-SIPI semantics would be
Il 11/03/2013 15:05, Gleb Natapov ha scritto:
On Mon, Mar 11, 2013 at 03:01:40PM +0100, Jan Kiszka wrote:
We are not moving away from mp_state, we are moving away from using
mp_state for signaling because with nested virt INIT does not always
change mp_state, not only that it can change
Il 11/03/2013 14:54, Gleb Natapov ha scritto:
Setting the mp_state to INIT_RECEIVED is that interface, and it already
works, for APs at least. This patch extends it to work for the BSP as well.
It does not for AP either. If AP has vmx on mp_sate should not be set to
INIT_RECEIVED. mp_sate is
Il 11/03/2013 18:20, Gleb Natapov ha scritto:
On Mon, Mar 11, 2013 at 03:28:03PM +0100, Paolo Bonzini wrote:
Il 11/03/2013 14:54, Gleb Natapov ha scritto:
Setting the mp_state to INIT_RECEIVED is that interface, and it already
works, for APs at least. This patch extends it to work for the BSP
Il 28/02/2013 13:13, Hu Tao ha scritto:
This patch enables preservation of cpu runstate during save/load vm.
So when a vm is restored from snapshot, the cpu runstate is restored,
too.
I don't think this feature is worth breaking backwards migration
compatibility. It is usually handled at a
Il 28/02/2013 13:13, Hu Tao ha scritto:
From: Wen Congyang we...@cn.fujitsu.com
The guest should run after resetting it, but it does not run if its
old state is RUN_STATE_INTERNAL_ERROR or RUN_STATE_PAUSED.
We don't set runstate to RUN_STATE_PAUSED when resetting the guest,
so the
Il 28/02/2013 13:13, Hu Tao ha scritto:
The guest will be in this state when it is panicked.
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
Signed-off-by: Hu Tao hu...@cn.fujitsu.com
---
migration.c | 1 +
qapi-schema.json | 6 +-
qmp.c| 3 ++-
vl.c
,
[QEVENT_BALLOON_CHANGE] = BALLOON_CHANGE,
[QEVENT_SPICE_MIGRATE_COMPLETED] = SPICE_MIGRATE_COMPLETED,
+[QEVENT_GUEST_PANICKED] = GUEST_PANICKED,
};
QEMU_BUILD_BUG_ON(ARRAY_SIZE(monitor_event_names) != QEVENT_MAX)
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Paolo
--
To unsubscribe
Il 28/02/2013 13:13, Hu Tao ha scritto:
If the target is x86/x86_64, the guest's kernel will write 0x01 to the
port KVM_PV_EVENT_PORT when it is panciked. This patch introduces a new
qom device kvm_pv_ioport to listen this I/O port, and deal with panicked
event according to panicked_action's
Il 28/02/2013 13:13, Hu Tao ha scritto:
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
Signed-off-by: Hu Tao hu...@cn.fujitsu.com
---
hw/pc_piix.c| 9 -
qemu-options.hx | 3 ++-
vl.c| 4
3 files changed, 14 insertions(+), 2 deletions(-)
We cannot add
Il 03/03/2013 10:17, Gleb Natapov ha scritto:
On Thu, Feb 28, 2013 at 08:13:10PM +0800, Hu Tao wrote:
This series implements a new interface, kvm pv event, to notify host when
some events happen in guest. Right now there is one supported event: guest
panic.
What other event do you have in
Il 04/03/2013 11:43, Gleb Natapov ha scritto:
Anyhow, this does not apply to the next submission of this series. I
think we can agree to the compromise of using ACPI but still read the
port in _STA.
If you want to make ioport configurable I do not see how can we avoid
patching.
I want
Il 04/03/2013 11:59, Gleb Natapov ha scritto:
I want to make the ioport configurable in the device, but the PIIX and
ICH9 (which are what the DSDT is written for) will always use port 0x505.
But the device is not part of PIIX or ICH9.
So is kvmclock, or kvmvapic. I think it makes sense to
Il 04/03/2013 12:20, Gleb Natapov ha scritto:
On Mon, Mar 04, 2013 at 12:10:58PM +0100, Paolo Bonzini wrote:
It is additional device that
may or may not be present depending on a command line. So what if
someone configures debugcon or debugexit to use this port?
I haven't checked if debug
Il 04/03/2013 12:52, Gleb Natapov ha scritto:
Same here, you can remove the panic event port and add debugcon at
0x505. That's the problematic case. But if the user goes to that
length, I think we can honestly say we don't care.
IMO there is a big difference between well know serial ISA
Il 05/03/2013 03:33, Hu Tao ha scritto:
On Mon, Mar 04, 2013 at 10:30:48AM +0100, Paolo Bonzini wrote:
Il 28/02/2013 13:13, Hu Tao ha scritto:
This patch enables preservation of cpu runstate during save/load vm.
So when a vm is restored from snapshot, the cpu runstate is restored,
too.
I
Il 05/03/2013 04:17, Hu Tao ha scritto:
Will
if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
runstate_check(RUN_STATE_SHUTDOWN) ||
runstate_check(RUN_STATE_GUEST_PANICKED)) {
runstate_set(RUN_STATE_PAUSED);
}
be OK? Or I must be
Il 06/03/2013 09:56, Hu Tao ha scritto:
Something like this should work (in SeaBIOS's src/acpi-dsdt-isa.dsl):
Device(PEVT) {
Name(_HID, EisaId(QEMU0001))
OperationRegion(PEOR, SystemIO, 0x505, 0x01)
Field(PEOR, ByteAcc, NoLock, Preserve) {
On Wed, Mar 06, 2013 at 10:07:31AM +0100, Paolo Bonzini wrote:
Il 06/03/2013 09:56, Hu Tao ha scritto:
Something like this should work (in SeaBIOS's
src/acpi-dsdt-isa.dsl):
Device(PEVT) {
Name(_HID, EisaId(QEMU0001))
OperationRegion(PEOR
Il 08/02/2013 05:05, Rusty Russell ha scritto:
Paolo Bonzini pbonz...@redhat.com writes:
The virtqueue_add_buf function has two limitations:
1) it requires the caller to provide all the buffers in a single call;
2) it does not support chained scatterlists: the buffers must be
provided
(including virtio-serial,
all three virtio-net receive paths, and virtio-blk SG_IO which I hadn't
checked for the RFC); anyway this did not bring in new code changes.
Ok for 3.9?
Paolo
Paolo Bonzini (9):
virtio: add functions for piecewise addition of buffers
virtio-blk: reorganize
on
the virtio functions ignoring the end markers in a scatterlist.
The next patch will do the same for the other path.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
drivers/block/virtio_blk.c | 74 ++-
1 files changed, 45 insertions(+), 29 deletions
SCSI command
requests.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
drivers/block/virtio_blk.c | 74 ++-
1 files changed, 38 insertions(+), 36 deletions(-)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 4a31fcc..22deb65
. And it will be particularly useful
when adding multiqueue supoprt, because it keeps the tgt_lock critical
sections very slim while avoiding a proliferation of locks.
Signed-off-by: Wanlong Gao gaowanl...@cn.fujitsu.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
drivers/scsi/virtio_scsi.c
Adding a single direct buffer is a very common case. Introduce
an optimized function for that.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
drivers/char/hw_random/virtio-rng.c |2 +-
drivers/char/virtio_console.c |4 +-
drivers/net/virtio_net.c|2
Eliminate the code duplication between virtqueue_add_buf and
virtqueue_add_sg. That's safe to do now that no devices will
pass scatterlists with a termination marker in the middle.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
drivers/virtio/virtio_ring.c | 159
Prepare for when virtqueue_add_buf will use sg_next instead of
ignoring ending markers.
Note that for_each_sg (and thus virtqueue_add_sg) allows you
to pass a truncated scatterlist that does not have a marker
on the last item. We rely on this in add_recvbuf_mergeable.
Signed-off-by: Paolo
1 - 100 of 12102 matches
Mail list logo