Hi
On Wed, Aug 24, 2022 at 1:43 PM Bin Meng wrote:
>
> From: Xuzhou Cheng
>
> The combination of GENERIC_WRITE and FILE_SHARE_READ options does
> not allow the same file to be opened again by CreateFile() from
> another QEMU process with the same options when the previous QEMU
> process still
When irqfd is enabled, we bypass QEMU's irq emulation and let KVM to
directly assert the irq. However, KVM is not aware of the device's MSI-x
masking status. Add MSI-x mask bookkeeping in NVMe emulation and
detach the corresponding irqfd when the certain vector is masked.
Signed-off-by: Jinhao
When the new option 'irq-eventfd' is turned on, the IO emulation code
signals an eventfd when it want to (de)assert an irq. The main loop
eventfd handler does the actual irq (de)assertion. This paves the way
for iothread support since QEMU's interrupt emulation is not thread
safe.
Asserting and
Use KVM's irqfd to send interrupts when possible. This approach is
thread safe. Moreover, it does not have the inter-thread communication
overhead of plain event notifiers since handler callback are called
in the same system call as irqfd write.
Signed-off-by: Jinhao Fan
---
hw/nvme/ctrl.c | 50
This patch series changes qemu-nvme's interrupt emulation to use event
notifiers, which can ensure thread-safe interrupt delivery when iothread
is used. In the first patche, I convert qemu-nvme's IO emulation
logic to send irq via eventfd, so that the actual assertion and
deassertion is always
On 23.08.22 21:22, Stefan Hajnoczi wrote:
> On Tue, Aug 23, 2022 at 10:01:59AM +0200, David Hildenbrand wrote:
>> On 23.08.22 00:24, Stefan Hajnoczi wrote:
>>> Register guest RAM using BlockRAMRegistrar and set the
>>> BDRV_REQ_REGISTERED_BUF flag so block drivers can optimize memory
>>> accesses
On Sun, 31 Jul 2022 18:21:38 +0200
Julia Suvorova wrote:
> Introduce the 64-bit entry point. Since we no longer have a total
> number of structures, stop checking for the new ones at the EOF
> structure (type 127).
needs fixing checkpatch warnings
other than that
Reviewed-by: Igor Mammedov
On 24.08.22 21:55, Peter Maydell wrote:
> On Wed, 24 Aug 2022 at 17:43, David Hildenbrand wrote:
>> One idea is doing another pass over the list at the end (after possible
>> merging of sections) and making sure everything is page-aligned.
>>
>> Another idea is specifying somehow that that memory
- Original Message -
> From: "eperezma"
> To: "Guo Zhi"
> Cc: "jasowang" , "sgarzare" ,
> "Michael Tsirkin" ,
> "qemu-devel@nongnu.org Developers"
> Sent: Monday, August 22, 2022 10:08:32 PM
> Subject: Re: [RFC 1/2] virtio: expose used buffers
> On Thu, Aug 18, 2022 at 5:13 PM Guo
On Wednesday, 24 August, 2022, 04:46:21 pm IST, Fiona Ebner
wrote:
>Reported by one of our users running into the failing assert():
>https://forum.proxmox.com/threads/114011/#post-492916
>
>- assert(VMXNET3_MIN_MTU <= s->mtu && s->mtu < VMXNET3_MAX_MTU);
>+ assert(VMXNET3_MIN_MTU <= s->mtu &&
On 8/25/22 02:33, Richard Henderson wrote:
On 8/24/22 10:32, Paolo Bonzini wrote:
+static void decode_group_0x63(DisasContext *s, CPUX86State *env,
X86OpEntry *entry, uint8_t *b)
+{
+ static X86OpEntry arpl = X86_OP_ENTRY2(ARPL, E,w, G,w, .special =
X86_SPECIAL_ProtMode);
+ static
On 8/25/22 02:27, Richard Henderson wrote:
If you were sharing this with the old decoder, and thus needed to retain
it, that would be one thing. But there's no shared prefix or postfix in
this function, so you might as well split each case into the functions.
Yes, absolutely.
Paolo
On 8/25/22 02:23, Richard Henderson wrote:
+ op->v = v;
+}
Surely this assignment...
+static void gen_writeback(DisasContext *s, X86DecodedOp *op)
+{
...
+ case X86_ALU_GPR:
+ gen_op_mov_reg_v(s, op->ot, op->n, s->T0);
... can be used here instead of hard-coding T0. It
On 8/25/22 03:47, Richard Henderson wrote:
On 8/24/22 10:31, Paolo Bonzini wrote:
diff --git a/target/i386/tcg/decode-old.c.inc b/target/i386/tcg/decode-old.c.inc
index 603642d6e1..fb86855501 100644
--- a/target/i386/tcg/decode-old.c.inc
+++ b/target/i386/tcg/decode-old.c.inc
@@ -1808,10
On 8/25/22 02:12, Richard Henderson wrote:
Surely it would be just as readable as
static const X86OpEntry onebyte[256] = {
/*
* Table A-2: One-byte Opcode Map: 00H — F7H
*/
[0x00] = X86_OP_ENTRY2(ADD, E,b, G,b),
[0x01] = X86_OP_ENTRY2(ADD, E,v, G,v),
...
On 8/25/22 01:01, Richard Henderson wrote:
One notable
difference is that the new decoder always sign-extends 8-bit immediates,
so for example a "cmpb $e9, %dl" instruction will subtract $0xfff...fffe9
from the temporary value. This is the way Intel intended "Ib" immediates
to work, and there's
On Thu, Aug 25, 2022 at 2:38 AM Si-Wei Liu wrote:
>
>
>
> On 8/23/2022 9:27 PM, Jason Wang wrote:
> >
> > 在 2022/8/20 01:13, Eugenio Pérez 写道:
> >> It was returned as error before. Instead of it, simply update the
> >> corresponding field so qemu can send it in the migration data.
> >>
> >>
On Thu, Aug 18, 2022 at 11:13 PM Guo Zhi wrote:
>
> Follow VIRTIO 1.1 spec, we can only writing out a single used ring for a
> batch of descriptors, and only notify guest when the batch of
> descriptors have all been used.
Yes, but I don't see anything that is related to the "exposing used
On Thu, Aug 18, 2022 at 11:13 PM Guo Zhi wrote:
>
> In virtio-spec 1.1, new feature bit VIRTIO_F_IN_ORDER was introduced.
> When this feature has been negotiated, virtio driver will use
> descriptors in ring order: starting from offset 0 in the table, and
> wrapping around at the end of the
201 - 219 of 219 matches
Mail list logo
