Although linkspeed and duplex can be set in a linux guest via 'ethtool -s',
this requires custom ethtool commands for virtio-net by default.
Introduce a new feature flag, VIRTIO_NET_F_SPEED_DUPLEX, which allows
the hypervisor to export a linkspeed and duplex setting. The user can
subsequently over
A subsequent patch to add support for setting linkspeed/duplex in
virtio-net, requires a few definitions from ethtool.h, which ends up
pulling in kernel.h and sysinfo.h as well.
Signed-off-by: Jason Baron
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc: virtio-...@lists.oasis-open.org
---
include/s
Hi,
Linux can now read linkspeed and duplex settings as set by the
hypervisor:
faa9b39 virtio_net: propagate linkspeed/duplex settings from the hypervisor
This series thus adds qemu support.
Also, this patchset depends on this header sync:
https://lists.gnu.org/archive/html/qemu-devel/2018-02
On 03/06/2018 01:15 PM, Michael S. Tsirkin wrote:
> On Tue, Mar 06, 2018 at 12:53:14PM -0500, Jason Baron wrote:
>>
>>
>> On 03/02/2018 12:54 PM, Michael S. Tsirkin wrote:
>>> On Thu, Mar 01, 2018 at 10:46:33PM -0500, Jason Baron wrote:
Pull in definitions for SPEED_UNKNOWN, DUPLEX_UNKNOWN,
Public bug reported:
I'm using the latest Arch Linux installation ISO as a live system and
start QEMU with the following command:
$ qemu-system-x86_64 -enable-kvm -boot d -cdrom
~/isos/archlinux-2018.03.01-x86_64.iso -m 512 -vnc :0 -k en-us
Then I use Vinagre to connect to the guest s
1 AM
> > To: Josh Kunz; Aleksandar Markovic; milos.stojano...@rt-rk.com
> > Cc: marlies.r...@gmail.com; qemu-devel@nongnu.org; riku.voi...@iki.fi;
> > qemu-triv...@nongnu.org; Peter Maydell; Shu-Chun Weng; Aleksandar
> Markovic
> > Subject: [EXTERNAL]Re: [Qemu-devel] p
On Donnerstag, 29. August 2019 18:27:30 CEST Greg Kurz wrote:
> > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> > index 586a6dccba..8cc65c2c67 100644
> > --- a/hw/9pfs/9p.c
> > +++ b/hw/9pfs/9p.c
> > @@ -572,10 +572,18 @@ static void coroutine_fn virtfs_reset(V9fsPDU *pdu)
> >
> >
On Donnerstag, 29. August 2019 18:55:28 CEST Greg Kurz wrote:
> > diff --git a/fsdev/qemu-fsdev-opts.c b/fsdev/qemu-fsdev-opts.c
> > index 7c31af..07a18c6e48 100644
> > --- a/fsdev/qemu-fsdev-opts.c
> > +++ b/fsdev/qemu-fsdev-opts.c
> > @@ -31,7 +31,9 @@ stati
*errp)>
> > }
> > fsdev_throttle_cleanup(s->ctx.fst);
> > g_free(s->tag);
> >
> > + qpp_table_destroy(&s->qpp_table);
> >
> > g_free(s->ctx.fs_root);
> >
> > }
> >
> >
On Donnerstag, 29. August 2019 19:02:34 CEST Greg Kurz wrote:
> On Thu, 22 Aug 2019 15:18:54 -0700 (PDT)
>
> no-re...@patchew.org wrote:
> > Patchew URL:
> > https://patchew.org/QEMU/cover.1566503584.git.qemu_...@crudebyte.com/
> >
> >
> >
> > Hi,
&
On Freitag, 30. August 2019 13:48:27 CEST Greg Kurz wrote:
> > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> > > index 8cc65c2c67..39c6c2a894 100644
> > > --- a/hw/9pfs/9p.c
> > > +++ b/hw/9pfs/9p.c
> >
> > [snip]
> >
> > > @@ -1940,6 +2041,19 @@ static int coroutine_fn v9fs_do_readdir(V9fsPDU
> >
; > > Ok to have a function for this instead of open-coding but I'd
> > > like to see qpp_table_init() for consistency.
> >
> > Well, these are just qht_init() one-liners, but if you really want to have
> > dedicated, local init functions for them, okay.
&g
On Montag, 2. September 2019 13:49:34 CEST Greg Kurz wrote:
> On Sun, 01 Sep 2019 20:56:16 +0200
>
> Christian Schoenebeck wrote:
> > On Freitag, 30. August 2019 14:22:38 CEST Greg Kurz wrote:
> > > Some more comments below.
> >
> > [snip]
> >
> > > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
>
> > > no-re...@patchew.org wrote:
> > > > Patchew URL:
> > > > https://patchew.org/QEMU/cover.1566503584.git.qemu_...@crudebyte.com/
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > This series seem
/gdb/General-Query-Packets.html#General-Query-Packets
On Mon, Aug 26, 2019 at 1:29 AM Laurent Vivier wrote:
> Le 17/08/2019 à 01:34, Josh Kunz via Qemu-devel a écrit :
> > This is needed to support debugging PIE ELF binaries running under QEMU
> > user mode. Currently, `c
On Dienstag, 3. September 2019 21:38:15 CEST Eric Blake wrote:
> On 9/2/19 5:29 PM, Christian Schoenebeck via Qemu-devel wrote:
> >>>>> === OUTPUT BEGIN ===
> >>>>> 1/4 Checking commit bb69de63f788 (9p: Treat multiple devices on one
> >>>>>
-by: Antonios Motakis
[CS: - Rebased to https://github.com/gkurz/qemu/commits/9p-next
(SHA1 7fc4c49e91).
- Added virtfs option 'multidevs', original patch simply did the inode
remapping without being asked.
- Updated hash calls to new xxhash API.
- Upd
001000] (28 bits)
Hence minBits=6 maxBits=28
Signed-off-by: Christian Schoenebeck
---
hw/9pfs/9p.c | 268 +--
hw/9pfs/9p.h | 44 -
2 files changed, 279 insertions(+), 33 deletions(-)
diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index d9be2d45d3..37abcdb71e 100644
--- a/hw/9pfs/9p.c
+++ b
This is v7 of a proposed patch set for fixing file ID collisions with 9pfs.
v6->v7:
* Rebased to https://github.com/gkurz/qemu/commits/9p-next
(SHA1 7fc4c49e91).
* Be pedantic and abort with error on wrong value for new command line
argument 'multidevs'.
* Adjust
fails, we still have 48 bits available in the QID
path to fall back to a less memory efficient full mapping.
Signed-off-by: Antonios Motakis
[CS: - Rebased to https://github.com/gkurz/qemu/commits/9p-next
(SHA1 7fc4c49e91).
- Updated hash calls to new xxhash API.
- Removed
On Mittwoch, 4. September 2019 15:02:30 CEST Christian Schoenebeck wrote:
> > > Well, mailman is handling this correctly. It replaces the "From:" field
> > > with a placeholder and instead adds my actual email address as
> > > "Reply-To:" field. That's the common way to handle this on mailing
> > >
Gentle ping
On Tue, Aug 27, 2019, 11:24 Sam Eiderman wrote:
> v1:
>
> Non-standard logical geometries break under QEMU.
>
> A virtual disk which contains an operating system which depends on
> logical geometries (consistent values being reported from BIOS INT13
> AH=08) w
Hi Mark,
> From: Mark
> Sent: Sunday, 10 February 2019 08:58
> Subject: [v3 PATCH] hw/arm/bcm2835_peripherals: add bcm283x sp804-alike
> timer
Thanks for the patch. The integration with bcm2835_peripherals looks good, but
hopefully one of the QEMU maintainers can give you a review
On 01.02.2019 12:14, Markus Armbruster wrote:
Julia Suvorova via Qemu-devel writes:
The whitelist option allows to run a reduced monitor with a subset of
QMP commands. This allows the monitor to run in secure mode, which is
For a value of "secure". I'm not saying this
On 11.02.2019 18:51, Daniel P. Berrangé wrote:
On Thu, Jan 31, 2019 at 03:03:21PM -0600, Eric Blake wrote:
On 1/31/19 2:26 PM, Julia Suvorova via Qemu-devel wrote:
The whitelist option allows to run a reduced monitor with a subset of
QMP commands. This allows the monitor to run in secure
/devel/blkdebug.txt| 35 ++--
qapi/block-core.json | 31 ++
tests/qemu-iotests/071 | 63
tests/qemu-iotests/071.out | 31 ++
5 files changed, 226 insertions(+), 13 deletions(-)
diff --git a/block
, it
didn't get reviewed in time for the next version bump, so you have to
resubmit." With a fast moving project, this is nonsense. If you're
looking at the code, you should have access to the git history as well
to determine the version.
True, but these comments are used to generate d
There is no need for signedness on these QID fields for 9p.
Signed-off-by: Antonios Motakis
Signed-off-by: Christian Schoenebeck
---
fsdev/9p-marshal.h | 6 +++---
hw/9pfs/9p.c | 6 +++---
hw/9pfs/trace-events | 14 +++---
3 files changed, 13 insertions(+), 13 deletions(-)
The QID path should uniquely identify a file. However, the
inode of a file is currently used as the QID path, which
on its own only uniquely identifies wiles within a device.
Here we track the device hosting the 9pfs share, in order
to prevent security issues with QID path collisions from
other dev
it a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index e6e410972f..46c9f11384 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -26,6 +26,7 @@
#include "migration/blocker.h"
#include "sysemu/qtest.h"
#include "qemu/xxhash.h"
+#include
int open_fd_hw;
int
device id.
Signed-off-by: Antonios Motakis
Signed-off-by: Christian Schoenebeck
---
fsdev/file-op-9p.h | 1 +
fsdev/qemu-fsdev-opts.c | 7 +++-
fsdev/qemu-fsdev.c | 6 +++
hw/9pfs/9p.c| 105 ++--
hw/9pfs/9p.h| 12
stat_to_qid attempts via qid_path_prefixmap to map unique files (which are
identified by 64 bit inode nr and 32 bit device id) to a 64 QID path value.
However this implementation makes some assumptions about inode number
generation on the host.
If qid_path_prefixmap fails, we still have 48 bits av
" command
line parameter, but I guess I wait for this qemu patch set to get through.
Christian Schoenebeck (5):
9p: unsigned type for type, version, path
9p: Treat multiple devices on one export as an error
9p: Added virtfs option "remap_inodes"
9p: stat_to_qid: implement s
On Donnerstag, 27. Juni 2019 18:12:03 CEST Greg Kurz wrote:
> On Wed, 26 Jun 2019 20:25:55 +0200
> Christian Schoenebeck via Qemu-devel wrote:
> > There is no need for signedness on these QID fields for 9p.
> >
> > Signed-off-by: Antonios Motakis
>
> You shoul
On Donnerstag, 27. Juni 2019 19:26:22 CEST Greg Kurz wrote:
> On Wed, 26 Jun 2019 20:30:41 +0200
>
> Christian Schoenebeck via Qemu-devel wrote:
> > The QID path should uniquely identify a file. However, the
> > inode of a file is currently used as the QID path, whic
On Freitag, 28. Juni 2019 12:21:20 CEST Greg Kurz wrote:
> > +static int qid_path_fullmap(V9fsPDU *pdu, const struct stat *stbuf,
> > +uint64_t *path)
> > +{
> > +QpfEntry lookup = {
> > +.dev = stbuf->st_dev,
> > +.ino = stbuf->st_ino
> > +}, *va
On Freitag, 28. Juni 2019 12:09:31 CEST Greg Kurz wrote:
> On Wed, 26 Jun 2019 20:42:13 +0200
>
> Christian Schoenebeck via Qemu-devel wrote:
> > To support multiple devices on the 9p share, and avoid
> > qid path collisions we take the device id as input
> > to gene
+++- hw/9pfs/9p.h
> > | 67 ++-
> > 2 files changed, 312 insertions(+), 22 deletions(-)
> >
> > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> > index e6e410972f..46c9f11384 100644
> > --- a/hw/9pfs/9p.c
> > +++ b/hw/9pfs/9p
lper command. It runs with root
> privileges, which provides the same level of functionality as "local"
> with security_model=passthrough. It also chroot() into the shared
> folder for extra security. But it is slower since it all requests
> still go through the virtio-9p
On Freitag, 28. Juni 2019 16:56:15 CEST Christian Schoenebeck via Qemu-devel
> > > + */
> > > +#define EXP_GOLOMB_K0
> > > +
> > > +# if !EXP_GOLOMB_K
> > > +
> > > +/** @brief Exponential Golomb algorithm limited to the case k=0.
> &g
Signed-off-by: Chen Zhang
---
hw/vfio/pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index dc3479c..c5e6fe6 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -44,7 +44,7 @@
#define TYPE_VFIO_PCI "vfio-pci"
#define PCI_VFIO(obj)OBJ
> I’ve got a couple of “undelivered mail returned to sender” mails for Sam
> recently, but anyway...
- shmuel.eider...@oracle.com
+ sam...@google.com
> It doesn’t look like any caller actually passes a NULL @dev, so why not
> drop the @suffix part?
Just copied it from the bootindex implementatio
nd avoid qid path collisions we take the device id as input to
generate a unique QID path. The lowest 48 bits of the path will be set
equal to the file inode, and the top bits will be uniquely assigned based
on the top 16 bits of the inode and the device id.
Signed-off-by: Antonios Motakis
[CS: -
available in the QID
path to fall back to a less memory efficient full mapping.
Signed-off-by: Antonios Motakis
[CS: - Rebased to https://github.com/gkurz/qemu/commits/9p-next
(SHA1 177fd3b6a8).
- Updated hash calls to new xxhash API.
- Removed unnecessary parantheses in
The QID path should uniquely identify a file. However, the
inode of a file is currently used as the QID path, which
on its own only uniquely identifies files within a device.
Here we track the device hosting the 9pfs share, in order
to prevent security issues with QID path collisions from
other dev
This is v6 of a proposed patch set for fixing file ID collisions with 9pfs.
v5->v6:
* Rebased to https://github.com/gkurz/qemu/commits/9p-next
(SHA1 177fd3b6a8).
* Replaced previous boolean option 'remap_inodes' by tertiary option
'multidevs=remap|forbid|warn
choenebeck
---
hw/9pfs/9p.c | 247 ---
hw/9pfs/9p.h | 34 +++-
2 files changed, 251 insertions(+), 30 deletions(-)
diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 728641fb7f..0359469cfa 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -2
> @@ -213,11 +221,18 @@ static void scsi_qdev_realize(DeviceState *qdev, Error
> **errp)
> static void scsi_qdev_unrealize(DeviceState *qdev, Error **errp)
> {
> SCSIDevice *dev = SCSI_DEVICE(qdev);
> +Error *local_err = NULL;
>
> if (dev->vmsentry) {
> qemu_del_vm_change_
> Only scsi-hd has the lchs properties, though, so what’s the purpose of
> defining the unrealize function for all other classes?
>
> Max
- shmuel.eider...@oracle.com
+ sam...@google.com
The only purpose is to already have them mapped to the correct existing
function, in case it will be used late
On Wed, Aug 21, 2019 at 2:28 AM Laurent Vivier wrote:
> Le 19/08/2019 à 23:46, Josh Kunz via Qemu-devel a écrit :
> > Hi all,
> >
> > I have also experienced issues with SIGRTMIN + 1, and am interested in
> > moving this patch forwards. Anything I can do here to help
v1:
Non-standard logical geometries break under QEMU.
A virtual disk which contains an operating system which depends on
logical geometries (consistent values being reported from BIOS INT13
AH=08) will most likely break under QEMU/SeaBIOS if it has non-standard
logical geometries - for example
c
@@ -35,6 +35,7 @@
#include "hw/block/block.h"
#include "hw/qdev-properties.h"
#include "sysemu/dma.h"
+#include "sysemu/sysemu.h"
#include "qemu/cutils.h"
#include "trace.h"
@@ -2402,6 +2403,16 @@ static void scsi_realize(SCSID
From: Sam Eiderman
Using fw_cfg, supply logical CHS values directly from QEMU to the BIOS.
Non-standard logical geometries break under QEMU.
A virtual disk which contains an operating system which depends on
logical geometries (consistent values being reported from BIOS INT13
AH=08) will most
From: Sam Eiderman
Add an interface to provide direct logical CHS values for boot devices.
We will use this interface in the next commits.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
---
bootdevice.c| 55 +
From: Sam Eiderman
Fixing tabbing in block related macros.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
---
hw/ide/qdev.c| 2 +-
include/hw/block/block.h | 16
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/hw/id
From: Sam Eiderman
We will need to add LCHS removal logic to scsi-hd's unrealize() in the
next commit.
Signed-off-by: Sam Eiderman
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
---
hw/scsi/scsi-bus.c | 16
include/hw/scsi/scsi.h | 1 +
781,7 @@ tests/ide-test$(EXESUF): tests/ide-test.o $(libqos-pc-obj-y)
tests/ahci-test$(EXESUF): tests/ahci-test.o $(libqos-pc-obj-y)
qemu-img$(EXESUF)
tests/ipmi-kcs-test$(EXESUF): tests/ipmi-kcs-test.o
tests/ipmi-bt-test$(EXESUF): tests/ipmi-bt-test.o
-tests/hd-geo-test$(EXESUF): tests/hd-geo-t
From: Sam Eiderman
Add logical geometry variables to BlockConf.
A user can now supply "lcyls", "lheads" & "lsecs" for any HD device
that supports CHS ("cyls", "heads", "secs").
These devices include:
* ide-hd
* scsi-hd
* virtio-blk-pci
In future commits we will use the provided LCH
From: Sam Eiderman
Move device name construction to a separate function.
We will reuse this function in the following commit to pass logical CHS
parameters through fw_cfg much like we currently pass bootindex.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
---
Hi list,
currently the 9p implementation in qemu causes inode number collisions on
guest OS level if the directory exported by 9p consists on host level of more
than one file system being mounted inside that exported directory tree; which
leads to severe misbehaviours on guest side with all
On Samstag, 30. März 2019 17:47:51 CET Greg Kurz wrote:
> Maybe have a look at this tentative to fix QID collisions:
>
> https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02283.html
Interesting! My idea would have been different, based on my presumption that
the amount of device
---
arch/x86/configs/x86_64_defconfig |5 +
drivers/char/Makefile |1 +
drivers/char/forwarder/Makefile|8 +
drivers/char/forwarder/forwarder.h | 103 ++
drivers/char/forwarder/forwarder_drv.c | 2104
fs/open.c
works with different GPU although the current proof of concept only
works with Intel GPU.
2. This shows as a kernel patch. The actual qemu diff is nested in
tools/forward/qemu.diff
3. The basic idea is: under Linux, most applications use GPU acceleration with
help of MESA library. And MESA library inte
her two copies of NSWindow.h this machine has.
>>
>> thanks
>> -- PMM
> This was really odd.
>
> I tried to figure out what was wrong with the toolchain and run `xcode-select
> --install` and `xcode-select --switch`. After the this, clang failed like
> what you mentioned.
>
> I had to re-configure qemu with --extra-cflags="-isysroot `xcrun
> --show-sdk-path`”, forcing clang to use the correct SDK root, and then it
> would compile.
>
> Thanks and best regards,
ping
http://patchwork.ozlabs.org/patch/1059842/
> On Mar 27, 2019, at 10:00 AM, Chen Zhang wrote:
>
>
>
>> On Mar 27, 2019, at 12:20 AM, Peter Maydell wrote:
>>
>> On Thu, 21 Mar 2019 at 07:10, Chen Zhang wrote:
>>>
>>> In fullscreen mode, the window property of cocoaView may not be the k
The following patches fixed absolute and relative input device issues on macOS
Mojave.
Chen Zhang (2):
ui/cocoa: Fix absolute input device grabbing issue on Mojave
ui/cocoa: Fix mouse grabbing in fullscreen mode for relative input
device
ui/cocoa.m | 50 +
In fullscreen mode, the window property of cocoaView may not be the key
window, and the current implementation would not grab mouse in fullscreen
mode after user ungrabs cursor in fullscreen mode with hot-key, and left
clicks the relative input devices to re-grab it.
This patch used value of isFul
This patches fixed boundary check methods for cursor in normal and
fullscreen modes with/without Zoom-to-Fit on Mojave.
On Mojave, absolute input device, i.e. tablet, had trouble re-grabbing
the cursor in re-entry into the virtual screen area. In some cases,
the `window` property of NSEvent object
On Thu, Apr 11, 2019 at 11:11 PM Yuval Shaia wrote:
>
> On Thu, Apr 11, 2019 at 08:34:20PM +0300, Yuval Shaia wrote:
> > On Thu, Apr 11, 2019 at 05:24:08PM +, Jason Gunthorpe wrote:
> > > On Thu, Apr 11, 2019 at 07:02:15PM +0200, Cornelia Huck wrote:
> > > > On Thu, 11 Apr 2019 14:01:54 +0300
ping
> On Apr 8, 2019, at 10:04 AM, Chen Zhang wrote:
>
> The following patches fixed absolute and relative input device issues on
> macOS Mojave.
>
> Chen Zhang (2):
> ui/cocoa: Fix absolute input device grabbing issue on Mojave
> ui/cocoa: Fix mouse grabbing in fullscreen mode for relati
Hi Dave, thank you for looking.
> Can you give me an example of where you would use it?
We use it in our host memory sharing device. I used the existing
macros for all fields I could, but unfortunately some state does not fit
into them. We use this new macro to save/load memory
allocators (for no
Hi Peter,
> In any case, migration state on the wire needs to be
> architecture/endianness/
Could you please point how the proposed change is
architecture/endianness/ dependent?
> implementation-independent,
Could you please elaborate, what "implementation"
you mean here?
> so you can't just s
Got gdb for ppc64 to work and connect to qemu... Here is what I am
getting when doing a "info all-registers"
r0 0x0 0
r1 0xf1000816b0036890 17365889056675948688
r2 0x32b5d2053173536
r3 0x3385
>From qemu monitor :
(qemu) info tlb
info tlb
SLB ESIDVSID
0 0x0800 0x04002400
3 0xf10005000800 0x40500400
4 0xf1001800 0x41000400
5 0xf10008000800 0x4080040
This is the result at the same breakpoint under 3.1.0 (note the
difference in the TLB) (notably Segment Lookaside Buffer entry #1)
(qemu) info tlb
info tlb
SLB ESIDVSID
0 0x0800 0x04002400
1 0xf0002800 0x000802001080
3
TCG version).
Apologies for anyone receiving notifications for this, but I'd really
like this to work !
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1829682
Title:
QEMU PPC SYSTEM regression -
:04 04 97fe7c5db103c5426f25f2741db918e8cbc03b75
ed55cf6abd483aa01974c18d613461cc9e80e2c3 M hw
:04 04 4d51166be64bc71a72bd60eaa412aadc2117fc4c
614be9f9c87d20f7a2c23921a37d771a8956ee7c M include
--
You received this bug notification because you are a member of qemu-
devel-ml
For info :
I tried Removing the SPAPR H_HOME_NODE_ASSOCIATIVITY H-call support (Not
saying it shouldn't be implemented for CPU hotplug support) and AIX 7.2
boots again. with the latest QEMU (as of
8c1ecb590497b0349c550607db923972b37f6963 - git pulled 2019/05/29 @
around 06H30 GMT)
There mu
On 30.05.2019 17:07, Paolo Bonzini wrote:
On 30/05/19 10:42, Kevin Wolf wrote:
Am 27.05.2019 um 11:23 hat Stefan Hajnoczi geschrieben:
qemu_aio_get() does not zero allocated memory. Explicitly initialize
laiocb->co to prevent an uninitialized memory access in
qemu_laio_process_completion().
N
Callback-based laio_submit() and laio_cancel() were left after
rewriting Linux AIO backend to coroutines in hope that they would be
used in other code that could bypass coroutines. They can be safely
removed because they have not been used since that time.
Signed-off-by: Julia Suvorova
---
block
n error to the client
> > > instead
> > > and possibly printing out some useful messages in the QEMU log. Then, on
> > > top of that, you can start introducing hashing and variable prefix
> > > length.
> >
> > So you want that as its own patch serie
The following patches fixed issues of absolute and relative input devices
on macOS Mojave.
Chen Zhang (2):
ui/cocoa: Fix absolute input device grabbing issue on Mojave
ui/cocoa: Fix mouse grabbing in fullscreen mode for relative input
device
ui/cocoa.m | 50 +
On Mojave, absolute input device, i.e. tablet, had trouble re-grabbing
the cursor in re-entry into the virtual screen area. In some cases,
the `window` property of NSEvent object was nil after cursor exiting from
window, hinting that the `-locationInWindow` method would return value in
screen coor
In fullscreen mode, the window property of cocoaView may not be the key
window, and the current implementation would not re-grab cursor by left click
in fullscreen mode after ungrabbed in fullscreen mode with hot-key ctrl-opt-g.
This patch used value of isFullscreen as a short-cirtuit condition fo
In fullscreen mode, the window property of cocoaView may not be the key
window, and the current implementation would not re-grab cursor by left click
in fullscreen mode after ungrabbed in fullscreen mode with hot-key ctrl-opt-g.
This patch used value of isFullscreen as a short-cirtuit condition fo
On Mojave, absolute input device, i.e. tablet, had trouble re-grabbing
the cursor in re-entry into the virtual screen area. In some cases,
the `window` property of NSEvent object was nil after cursor exiting from
window, hinting that the `-locationInWindow` method would return value in
screen coor
The following patches fixed issues of absolute and relative input devices on
macOS Mojave.
Chen Zhang (2):
ui/cocoa: Fix absolute input device grabbing issue on Mojave
ui/cocoa: Fix mouse grabbing in fullscreen mode for relative input
device
ui/cocoa.m | 50 +
All,
Submitting proposal :
Per Power ISA 3.02B Book III at pages 1029 and 1030, bit 15 of the
slbmfee and slbmfev instructions is now assigned to an implementation
specific bit and is no longer reserved - meaning it can be set to 1 but
can probably be safely ignored.
2.07B still indicates b
My previous message might have felt through the cracks due to some
improper formating.
diff --git a/target/ppc/translate.c b/target/ppc/translate.c
index 4a5de28036..85f8b147ba 100644
--- a/target/ppc/translate.c
+++ b/target/ppc/translate.c
@@ -7064,8 +7064,8 @@ GE
Allow bit 15 to be 1 in the slbmfee and slbmfev in TCG
as per Power ISA 3.0B (Power 9) Book III pages 1029 and 1030.
Per this specification, bit 15 is implementation specific
so it may be 1, but can probably ne safely ignored.
Power ISA 2.07B (Power 7/Power 8) indicates the bit is
reserved but so
) but I couldn't find any e-mail address.
This is the original patch, correct ?
https://github.com/zhuowei/qemu/commit/c5f305c5d0cd336b2bb31cab8a70f90b72905a1e
Indeed !
After speaking with some QEMU folks on irc, it is okay to ignore the lack
of S-o-b because the patch is trivial. But t
Ivan Warren
---
The original creator of the patch is "Zhuowei Zhang"
(https://twitter.com/zhuowei) but I couldn't find any e-mail address.
This is the original patch, correct ?
https://github.com/zhuowei/qemu/commit/c5f305c5d0cd336b2bb31cab8a70f90b72905a1e
Indeed !
After speaki
7;remap_inodes' in
qemu-options.hx.
* Capture root_ino in v9fs_device_realize_common() as well, not just the
device id.
* Added function dirent_to_qid().
* Fixed v9fs_do_readdir() having exposed info outside export root with
'..' entry (no matter if inode rem
stat_to_qid attempts via qid_path_prefixmap to map unique files (which are
identified by 64 bit inode nr and 32 bit device id) to a 64 QID path value.
However this implementation makes some assumptions about inode number
generation on the host.
If qid_path_prefixmap fails, we still have 48 bits av
There is no need for signedness on these QID fields for 9p.
Signed-off-by: Antonios Motakis
[CS: - Also make QID type unsigned.
- Adjust donttouch_stat() to new types.
- Adjust trace-events to new types. ]
Signed-off-by: Christian Schoenebeck
---
fsdev/9p-marshal.h | 6 +++---
hw/9
hen running out of prefixes in
qid_path_prefixmap().
- Fixed definition of QPATH_INO_MASK.
- Dropped unnecessary parantheses in qpp_lookup_func().
- Dropped unnecessary g_malloc0() result checks. ]
Signed-off-by: Christian Schoenebeck
---
fsdev/file-op-9p.h | 1 +
fsdev/qem
The QID path should uniquely identify a file. However, the
inode of a file is currently used as the QID path, which
on its own only uniquely identifies files within a device.
Here we track the device hosting the 9pfs share, in order
to prevent security issues with QID path collisions from
other dev
choenebeck
---
hw/9pfs/9p.c | 247 ---
hw/9pfs/9p.h | 34 +++-
2 files changed, 251 insertions(+), 30 deletions(-)
diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 549e279462..5bbd3e2d14 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -2
On Mittwoch, 3. Juli 2019 13:13:26 CEST Christian Schoenebeck wrote:
> To support multiple devices on the 9p share, and avoid
> qid path collisions we take the device id as input
[snip]
> - Fixed v9fs_do_readdir() having exposed info outside
>export root with '..' entry.
[snip]
> diff
On 12.02.2019 10:13, Markus Armbruster wrote:
Julia Suvorova via Qemu-devel writes:
On 01.02.2019 12:14, Markus Armbruster wrote:
Julia Suvorova via Qemu-devel writes:
The whitelist option allows to run a reduced monitor with a subset of
QMP commands. This allows the monitor to run in
1101 - 1200 of 1356 matches
Mail list logo
