[Qemu-devel] [RFC PATCH] arm: implement cache/shareability attribute bits for PAR registers

On a successful address translation instruction, PAR is supposed to contain cacheability and shareability attributes determined by the translation. Previous versions of QEMU returned 0 for these bits (in line with the general strategy of ignoring caches and memory attributes), but some guests may

Re: [Qemu-devel] [RFC PATCH] arm: implement cache/shareability attribute bits for PAR registers

scribes (e.g. in the pseudocode for AArch32.S1AttrDecode and > >AArch64.S1AttrDecode) to the union interpreting mair_el[0] and > >mair_el[1]. > > Where the AArch64.S1AttrDecode() pseudocode says MAIR[] this is > MAIR[S1TranslationRegime()], which in QEMU terms is >

[Qemu-devel] [PATCH v2] arm: implement cache/shareability attribute bits for PAR registers

On a successful address translation instruction, PAR is supposed to contain cacheability and shareability attributes determined by the translation. We previously returned 0 for these bits (in line with the general strategy of ignoring caches and memory attributes), but some guest OSes may depend on

Re: [Qemu-devel] [PATCH] BCM2837 and machine raspi3

> From: Qemu-devel On Behalf Of bzt bzt > Sent: Sunday, 22 October 2017 06:21 > > I've added support for "-M raspi3" to qemu. This is my first patch, I hope > it's okay. The github repo is here: https://github.com/bztsrc/qemu-raspi3 > in case my patch does

[Qemu-devel] [RFC v2] e1000: Faulty tx checksum offload corrupts packets

Sometimes with quite undesirable results, since the QEMU e1000 device doesn't work as described above. Instead, the QEMU e1000 device maintains only one context in its state structure. When it receives a transmit context descriptor from the driver, it overwrites the context parameters regard

[Qemu-devel] [RFC v2] e1000: Faulty tx checksum offload corrupts packets

ction, aka E1G6023E.sys) does in certain cases. Sometimes with quite undesirable results, since the QEMU e1000 device doesn't work as described above. Instead, the QEMU e1000 device maintains only one context in its state structure. When it receives a transmit context descriptor from the driver, it

Re: [Qemu-devel] [PATCH] BCM2837 and machine raspi3

ugh it would be clearer to separate in advance. Again, I've asked > Peter > about this, but had no response. As I see having a parametrised single > function > is simplier for now, but could lead to a messy code later when all the SoC > features will be added. But I'm ain

Re: [Qemu-devel] [RFC v2] e1000: Faulty tx checksum offload corrupts packets

On Mon, Oct 23, 2017 at 8:28 PM, Jason Wang wrote: > > On 2017年10月24日 08:22, Ed Swierk wrote: > > (Another layer of icing on the cake is that QEMU ignores the > > requirement that a UDP checksum computed as zero be sent as 0x, > > since zero is a special value

[Qemu-devel] [PATCH 2/2] e1000e: Add e1000-ng devices

Implement e1000-compatible devices using the reworked e1000e code: - e1000-ng: Intel 82540EM - e1000-82544gc-ng: Intel 82544GC - e1000-82545em-ng: Intel 82545EM >From a guest's perspective, these should be drop-in replacements for the existing e1000 devices. Among other deficiencies, this versio

[Qemu-devel] [PATCH 0/2] e1000e: Reimplement e1000 as a variant of e1000e

gbe-controller-datasheet.pdf [3] https://lists.nongnu.org/archive/html/qemu-devel/2017-10/msg03008.html This patch series adds a new e1000-ng device but leaves the existing e1000 device alone. Linux 4.1 and Windows 10 e1000 guest drivers recognize the e1000-ng device and successfully pass traffic on a Li

[Qemu-devel] [PATCH 1/2] e1000e: Infrastructure for e1000-ng

Generalize e1000e to support e1000 and other devices with a similar register spec: - plain PCI instead of PCIe, skipping setup of MSI-X, AER, etc. - model-specific PHY ID2, register values and access permissions - model-specific EEPROM template and read/write methods This is just infrastructure,

[Qemu-devel] [Bug 1307225] Re: Running a virtual machine on a Haswell system produces machine check events

d this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1307225 Title: Running a virtual machine on a Haswell system produces machine check events Status in QEMU: Incomplete Bug description: I'm running a virt

[Qemu-devel] [Bug 1681439] Re: qemu-system-x86_64: hw/ide/core.c:685: ide_cancel_dma_sync: Assertion `s->bus->dma->aiocb == NULL' failed.

I cannot reproduce this any more with QEMU 2.9.0. As I do not really have time right now to determine which commit fixed this, feel free to close this bug. I will reopen it in case the issue resurfaces. Thanks for your assistance. -- You received this bug notification because you are a member

[Qemu-devel] Dummy Panel.

Hi I have created a new fork on GitHub https://github.com/flypie/flypie-pi-qemu and an associated project https://github.com/flypie/GDummyPanel the idea as well as getting the Original PI emulation working is to add some facility for simulated IO. This is a demonstration of the latest version

Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository

+ our product manager If I understand correctly, we will need to reconsider things if I included any additional technology in my port. However, I didn't include any additional references/source in my port compared to Veertu, that was not in the qemu code already (e.g., hax-all/kvm-all) so I

Re: [Qemu-devel] [PATCH RESEND v3 0/3] Generic PCIe host bridge INTx determination for INTx routing

e is irqfd is not used along with INTx interrupts and VFIO INTx handlers are executed on userspace leading to an important performance degradation. This issue is witnessed by the following messages; qemu-system-aarch64: -device vfio-pci,host=0006:90:00.0: PCI: Bug - unimplemented PCI INTx rou

Re: [Qemu-devel] [PATCH] multiboot: validate multiboot header address values

On Tue, Sep 5, 2017 at 11:12 AM, Thomas Garnier wrote: > On Tue, Sep 5, 2017 at 10:49 AM, P J P wrote: >> From: Prasad J Pandit >> >> While loading kernel via multiboot-v1 image, (flags & 0x0001) >> indicates that multiboot header contains valid addresses to load >> the kernel image. These a

Re: [Qemu-devel] [PATCH] multiboot: validate multiboot header address values

On Tue, Sep 5, 2017 at 10:49 AM, P J P wrote: > From: Prasad J Pandit > > While loading kernel via multiboot-v1 image, (flags & 0x0001) > indicates that multiboot header contains valid addresses to load > the kernel image. These addresses are used to compute kernel > size and kernel text offs

Re: [Qemu-devel] [PATCH v2] arm: implement cache/shareability attribute bits for PAR registers

> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > Sent: Tuesday, 31 October 2017 03:25 > > On 20 October 2017 at 22:49, Andrew Baumann > wrote: > > On a successful address translation instruction, PAR is supposed to > > contain cacheability and shareability attributes determined by the >

Re: [Qemu-devel] [PATCH v2] arm: implement cache/shareability attribute bits for PAR registers

> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > Sent: Tuesday, 31 October 2017 17:53 > > On 31 October 2017 at 01:23, Andrew Baumann > wrote: > >> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > >> Hi. This is looking pretty good, but I have a few comments below, > >> and we're

[Qemu-devel] [PATCH v3] arm: implement cache/shareability attribute bits for PAR registers

ation/attrs/S2AttrDecode() + * .../S2ConvertAttrsHints() + */ +static uint8_t convert_stage2_attrs(CPUARMState *env, uint8_t s2attrs) +{ +uint8_t hiattr = extract32(s2attrs, 2, 2); +uint8_t loattr = extract32(s2attrs, 0, 2); +uint8_t hihint = 0, lohint = 0; + +if (hiattr != 0) {

Re: [Qemu-devel] [PATCH v3] arm: implement cache/shareability attribute bits for PAR registers

ihint = 0, lohint = 0; > + > +if (hiattr != 0) { /* normal memory */ > +/* TODO: to faithfully emulate S2CacheDisabled() for the case > + * when EL2 is aarch32, we should check HCR2 (not HCR_EL2), but > + * qemu doesn't presently model this register. > +

[Qemu-devel] [PATCH v4] arm: implement cache/shareability attribute bits for PAR registers

On a successful address translation instruction, PAR is supposed to contain cacheability and shareability attributes determined by the translation. We previously returned 0 for these bits (in line with the general strategy of ignoring caches and memory attributes), but some guest OSes may depend on

Re: [Qemu-devel] [PATCH v2 00/43] Windbg supporting

Hi, I just noticed this thread, and the problem sounded very familiar... > From: Ladi Prosek > Sent: Monday, 6 November 2017 07:16 [...] > FS base passes all the checks in windbg_on_load() as the guest kernel > loads and it returns true. QEMU then sends some data over the pipe. >

Re: [Qemu-devel] [PATCH v2 00/43] Windbg supporting

adi Prosek > >> Sent: Monday, 6 November 2017 07:16 > > [...] > >> FS base passes all the checks in windbg_on_load() as the guest kernel > >> loads and it returns true. QEMU then sends some data over the pipe. > >> Windbg doesn't print anything, it&#x

[Qemu-devel] [PATCH] virtio-gpu: fix bug in host memory calculation.

The old code treats bits as bytes when calculating host memory usage. Change it to be consistent with allocation logic in pixman library. Signed-off-by: Tao Wu --- hw/display/virtio-gpu.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/hw/display/virtio-gpu.c b

[Qemu-devel] [PATCH] slirp: don't zero ti_i since we access it later.

The current code looks buggy, we zero ti_i while we access ti_dst/ti_src later. Signed-off-by: Tao Wu --- slirp/tcp_subr.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/slirp/tcp_subr.c b/slirp/tcp_subr.c index dc8b4bbb50..da0d53743f 100644 --- a/slirp/tcp_subr.

[Qemu-devel] [PATCH v2 1/2] e1000e: Infrastructure for e1000-ng

Generalize e1000e to support e1000 and other devices with a similar register spec: - plain PCI instead of PCIe, skipping setup of MSI-X, AER, etc. - model-specific PHY ID2, register values and access permissions - model-specific EEPROM template and read/write methods This is just infrastructure,

[Qemu-devel] [PATCH v2 0/2] e1000e: Reimplement e1000 as a variant of e1000e

gbe-controller-datasheet.pdf [3] https://lists.nongnu.org/archive/html/qemu-devel/2017-10/msg03008.html This patch series adds a new e1000-ng device but leaves the existing e1000 device alone. Linux 4.1 and Windows 10 e1000 guest drivers recognize the e1000-ng device and successfully pass traffic on a Li

[Qemu-devel] [PATCH v2 2/2] e1000e: Add e1000-ng devices

Implement e1000-compatible devices using the reworked e1000e code: - e1000-ng: Intel 82540EM - e1000-82544gc-ng: Intel 82544GC - e1000-82545em-ng: Intel 82545EM >From a guest's perspective, these should be drop-in replacements for the existing e1000 devices. This version has undergone minimal te

[Qemu-devel] [PATCH] virtio-gpu: fix bug in host memory calculation.

The old code treats bits as bytes when calculating host memory usage. Change it to be consistent with allocation logic in pixman library. Signed-off-by: Tao Wu --- hw/display/virtio-gpu.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/hw/display/virtio-gpu.

[Qemu-devel] qemu+virgl on systems without dmabuf and/or GBM

Hi, I am developing using qemu with virglrenderer on linux systems that do not support dmabufs or GBM. I have been successful making this work using glx and ignoring egl/dmabuf/gbm use in qemu. Unfortunately, there is currently no way to configure qemu to use opengl but disable egl/dmabuf/gbm

[Qemu-devel] [Bug 1754295] Re: Incorrect en-us keymap in QEMU 2.11

*** This bug is a duplicate of bug 1738283 *** https://bugs.launchpad.net/bugs/1738283 ** This bug has been marked a duplicate of bug 1738283 'Less than' (<), 'more than' (>), and 'pipe' (|) can't be typed via VNC -- You received this bug noti

Re: [Qemu-devel] [PATCH 7/9] hw/arm/bcm2836: Use correct affinity values for BCM2837

> From: Peter Maydell > Sent: Tuesday, 13 March 2018 08:35 > > The BCM2837 sets the Aff1 field of the MPIDR affinity values for the > CPUs to 0, whereas the BCM2836 uses 0xf. Set this correctly, as it > is required for Linux to boot. > > Signed-off-by: Peter Maydell > --- > hw/arm/bcm2836.c |

Re: [Qemu-devel] [PATCH 1/9] hw/arm/raspi: Don't do board-setup or secure-boot for raspi3

> From: Qemu-devel bounces+andrew.baumann=microsoft@nongnu.org> On Behalf Of Peter > Maydell > Sent: Tuesday, 13 March 2018 08:35 > > For the rpi1 and 2 we want to boot the Linux kernel via some > custom setup code that makes sure that the SMC instruction > acts as a

Re: [Qemu-devel] [PATCH 4/9] hw/arm/bcm2386: Fix parent type of bcm2386

> From: Qemu-devel bounces+andrew.baumann=microsoft@nongnu.org> On Behalf Of Peter > Maydell > Sent: Tuesday, 13 March 2018 08:35 > > The TypeInfo and state struct for bcm2386 disagree about what the > parent class is -- the TypeInfo says it's TYPE_SYS_BUS_DEVI

Re: [Qemu-devel] [PATCH 6/9] hw/arm/bcm2836: Create proper bcm2837 device

> From: Peter Maydell > Sent: Tuesday, 13 March 2018 08:35 > > The bcm2837 is pretty similar to the bcm2836, but it does have > some differences. Notably, the MPIDR affinity aff1 values it > sets for the CPUs are 0x0, rather than the 0xf that the bcm2836 > uses, and if this is wrong Linux will no

Re: [Qemu-devel] [PATCH 5/9] hw/arm/bcm2836: Rename bcm2836 type/struct to bcm283x

> From: Qemu-devel bounces+andrew.baumann=microsoft@nongnu.org> On Behalf Of Peter > Maydell > Sent: Tuesday, 13 March 2018 08:35 > > Our BCM2836 type is really a generic one that can be any of > the bcm283x family. Rename it accordingly. We change only > the names w

Re: [Qemu-devel] [PATCH 8/9] hw/arm/bcm2836: Hardcode correct CPU type

> From: Qemu-devel bounces+andrew.baumann=microsoft@nongnu.org> On Behalf Of Peter > Maydell > Sent: Tuesday, 13 March 2018 08:35 > > Now we have separate types for BCM2386 and BCM2387, we might as well > just hard-code the CPU type they use rather than having it p

[Qemu-devel] [PATCH] net/vde: print error on vde_open() failure

Despite the fact that now when the initialization of vde fails, qemu does not end silently, no informative error is printed. The patch generates an error and pushes it through the calling function. Related bug: https://bugs.launchpad.net/qemu/+bug/676029 Signed-off-by: Julia Suvorova --- net

Re: [Qemu-devel] [Bug 1158912] Re: QEMU Version 1.4.0 - SLIRP hangs VM

Hi, you can close this bug. Ken Sent from Yahoo Mail on Android On Tue, Jan 2, 2018 at 11:19 AM, Thomas Huth<1158...@bugs.launchpad.net> wrote: Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket no

[Qemu-devel] [PATCH net-next v3 1/3] virtio_net: propagate linkspeed/duplex settings from the hypervisor

The ability to set speed and duplex for virtio_net is useful in various scenarios as described here: 16032be virtio_net: add ethtool support for set and get of settings However, it would be nice to be able to set this from the hypervisor, such that virtio_net doesn't require custom guest ethtool

[Qemu-devel] [PATCH v3 3/3] qemu: add linkspeed and duplex settings to virtio-net

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

[Qemu-devel] [PATCH v3 0/3] virtio_net: allow hypervisor to indicate linkspeed and duplex setting

es to over-write the linkspeed/duplex settings with this patch. The 1/3 patch is against net-next, while the 2-3/3 patch are the associated qemu changes that would go in after as update-linux-headers.sh should be run first. So the qemu patches are a demonstration of how I intend this to work. Thank

[Qemu-devel] [PATCH v3 2/3] qemu: virtio-net: use 64-bit values for feature flags

In prepartion for using some of the high order feature bits, make sure that virtio-net uses 64-bit values everywhere. Signed-off-by: Jason Baron Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: virtio-...@lists.oasis-open.org --- hw/net/virtio-net.c| 54 +

Re: [Qemu-devel] [PATCH net-next v3 1/3] virtio_net: propagate linkspeed/duplex settings from the hypervisor

> +VIRTIO_NET_F_MTU, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS, \ >> +VIRTIO_NET_F_SPEED_DUPLEX >> >> static unsigned int features[] = { >> VIRTNET_FEATURES, > > Still missing the update from virtnet_config_changed_work, and I think > it's important

Re: [Qemu-devel] [PATCH net-next v3 1/3] virtio_net: propagate linkspeed/duplex settings from the hypervisor

have configured in the guest via 'ethtool -s' when the link goes down, so that would be a change in behavior, but perhaps that is ok? I think I would prefer to have the link down event still check for VIRTIO_NET_F_SPEED_DUPLEX before changing speed/duplex. That way we still have 2

Re: [Qemu-devel] [PATCH net-next v3 1/3] virtio_net: propagate linkspeed/duplex settings from the hypervisor

would be a >> change in behavior, but perhaps that is ok? > > No - what I am saying is that your patch overwrites the values > set by user when link goes down. > > I suggest limiting this call to when > > if (vi->status & VIRTIO_NET_S_LINK_UP) > &

[Qemu-devel] [PATCH v4 0/3] virtio_net: allow hypervisor to indicate linkspeed and duplex setting

various cases as described here: 16032be virtio_net: add ethtool support for set and get of settings Using 'ethtool -s' continues to over-write the linkspeed/duplex settings with this patch. The 1/3 patch is against net-next, while the 2-3/3 patch are the associated qemu changes that w

[Qemu-devel] [PATCH v4 2/3] qemu: virtio-net: use 64-bit values for feature flags

In prepartion for using some of the high order feature bits, make sure that virtio-net uses 64-bit values everywhere. Signed-off-by: Jason Baron Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: virtio-...@lists.oasis-open.org --- hw/net/virtio-net.c| 55 +

[Qemu-devel] [PATCH net-next v4 1/3] virtio_net: propagate linkspeed/duplex settings from the hypervisor

The ability to set speed and duplex for virtio_net is useful in various scenarios as described here: 16032be virtio_net: add ethtool support for set and get of settings However, it would be nice to be able to set this from the hypervisor, such that virtio_net doesn't require custom guest ethtool

[Qemu-devel] [PATCH v4 3/3] qemu: add linkspeed and duplex settings to virtio-net

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

Re: [Qemu-devel] [PULL 00/18] Net patches

gt; > are available in the git repository at: > > https://github.com/jasowang/qemu.git tags/net-pull-request > > for you to fetch changes up to 0065e915192cdf83c2700bb377e5323c2649476e: > > qemu-doc: Update the deprecation information of -tftp, -bootp,

Re: [Qemu-devel] [PULL 00/18] Net patches

On Mon, Jan 8, 2018 at 7:10 AM, Eric Blake wrote: > > On 01/08/2018 07:30 AM, Ed Swierk via Qemu-devel wrote: > > > Applied, thanks. > > > > PS: just noticed, but "Ed Swierk via Qemu-devel " > > is a bit of an odd Author string to end up in git commit l

Re: [Qemu-devel] [PATCH v3 33/42] hw/arm/bcm2835_peripherals: implement SDHCI Spec v3

> From: Philippe Mathieu-Daudé [mailto:philippe.mathieu.da...@gmail.com] > Sent: Friday, 29 December 2017 09:49 > > Signed-off-by: Philippe Mathieu-Daudé > --- > > Note, the bcm2835 seems to have 1KB minimum blocksize, however the > current > model is implemented with 512B. > > Can someone with

[Qemu-devel] [PATCH] target/i386: hax: Move hax_setup_qemu_emulator.

hax_setup_qemu_emulator reference env->efer which is updated in hax_get_msrs, so it has to be called after hax_get_msrs. This fix the bug that sometimes dump_state show 32 bits regs even in 64 bits mode. Signed-off-by: Tao Wu --- target/i386/hax-all.c | 4 +--- 1 file changed, 1 insertion(+), 3

[Qemu-devel] [PATCH v2 1/3] target/i386: move hflags update code to a function

ed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + */ + +#ifndef TARGET_I386_COMMON_I386_H +#define TARGET_I386_COMMON_I386_H + +#include "qemu/osdep.h" +#include "cpu.h" + +void x86_update_hflags(CPUX86State* env); + +#endif diff --git a

[Qemu-devel] [PATCH v2 2/3] target/i386: hax: change to use x86_update_hflags

(-) diff --git a/target/i386/hax-all.c b/target/i386/hax-all.c index 3ce6950296..dc379373f7 100644 --- a/target/i386/hax-all.c +++ b/target/i386/hax-all.c @@ -31,6 +31,7 @@ #include "qemu-common.h" #include "strings.h" +#include "common_i386.h" #include "ha

[Qemu-devel] [PATCH v2 3/3] target/i386: hax: Move x86_update_hflags.

x86_update_hflags reference env->efer which is updated in hax_get_msrs, so it has to be called after hax_get_msrs. This fix the bug that sometimes dump_state show 32 bits regs even in 64 bits mode. Signed-off-by: Tao Wu --- target/i386/hax-all.c | 4 +--- 1 file changed, 1 insertion(+), 3 deleti

[Qemu-devel] Fan mail

Thanks a lot for this software! Now I can make Windows tutorials without having to buy a new hard drive. (I asked Microsoft support how to install Windows on a hard drive with other operating systems on it. Their reply was to start diskpart, select a drive and type the command "clean".) Regards,

Re: [Qemu-devel] [RfC PATCH] Add udmabuf misc device

On 04/06/2018 03:11 AM, Matt Roper wrote: On Thu, Apr 05, 2018 at 10:32:04PM +0200, Daniel Vetter wrote: Pulling this out of the shadows again. We now also have xen-zcopy from Oleksandr and the hyper dmabuf stuff from Matt and Dongwong. At least from the intel side there seems to be the idea t

Re: [Qemu-devel] [PATCH] vmgenid: allow VM Generation ID modification via QMP/HMP

deletions(-) > > diff --git a/docs/specs/vmgenid.txt b/docs/specs/vmgenid.txt > index aa9f518..04443de 100644 > --- a/docs/specs/vmgenid.txt > +++ b/docs/specs/vmgenid.txt > @@ -240,6 +240,7 @@ The property may be queried via QMP/HMP: >(QEMU) query-vm-generation-id >

[Qemu-devel] [PATCH] use g_path_get_basename instead of basename

-proxy-helper.c | 6 +- hw/s390x/s390-ccw.c | 17 +++-- hw/vfio/ccw.c | 7 +-- hw/vfio/pci.c | 6 -- hw/vfio/platform.c | 6 -- qemu-io.c | 8 +++- qemu-nbd.c | 5 - qga/commands

Re: [Qemu-devel] [PATCH] use g_path_get_basename instead of basename

On 01.03.2018 13:59, Cornelia Huck wrote: > On Thu, 1 Mar 2018 10:47:42 +0100 > Marc-André Lureau wrote: > >> Hi >> >> On Thu, Mar 1, 2018 at 8:08 AM, Julia Suvorova via Qemu-devel >> wrote: >>> basename(3) and dirname(3) modify their argument

Re: [Qemu-devel] [PATCH] use g_path_get_basename instead of basename

On 01.03.2018 14:21, Paolo Bonzini wrote: > On 01/03/2018 11:59, Cornelia Huck wrote: Signed-off-by: Julia Suvorova >>> What about adding a warning for basename()/dirname() usage in >>> scripts/checkpatch.pl ? >> +1 to that. >> > > Good idea indeed. Julia, would you like to send a

Re: [Qemu-devel] [PATCH v4 12/43] misc: remove headers implicitly included

> > -#include > > typedef void (*OPL_TIMERHANDLER)(void *param, int channel, double > interval_Sec); > > diff --git a/bsd-user/main.c b/bsd-user/main.c > index f1b244b59b..efef5ff8c5 100644 > --- a/bsd-user/main.c > +++ b/bsd-user/main.c > @@ -32,7 +32,6 @@ > #

Re: [Qemu-devel] [PATCH 2/2] qemu: add linkspeed and duplex setting to virtio-net

On 12/18/2017 06:34 AM, Yan Vugenfirer wrote: > >> On 14 Dec 2017, at 21:33, Jason Baron via Qemu-devel >> wrote: >> >> Although they can be currently set in linux via 'ethtool -s', this requires >> guest changes, and thus it would be nice to exten

Re: [Qemu-devel] [PATCH 2/2] qemu: add linkspeed and duplex setting to virtio-net

On 12/19/2017 04:19 AM, Yan Vugenfirer wrote: > >> On 18 Dec 2017, at 18:04, Jason Baron via Qemu-devel >> mailto:qemu-devel@nongnu.org>> wrote: >> >> >> >> On 12/18/2017 06:34 AM, Yan Vugenfirer wrote: >>> >>>> On 14 Dec

Re: [Qemu-devel] [PATCH] virtio-pci: Add subsystem-vendor-id property

Hi Michael, > On Dec 19, 2017, at 8:27 PM, Michael S. Tsirkin wrote: > > On Wed, Dec 13, 2017 at 12:26:44AM -0800, b...@skyportsystems.com wrote: >> From: Ben Warren >> >> Now that virtio-win guest drivers provided by non-Redhat vendors need to >> use a different Subsystem Vendor ID value, a w

Re: [Qemu-devel] [PATCH net-next 1/2] virtio_net: allow hypervisor to indicate linkspeed and duplex setting

On 12/20/2017 09:57 AM, Michael S. Tsirkin wrote: > On Thu, Dec 14, 2017 at 02:33:53PM -0500, Jason Baron wrote: >> If the hypervisor exports the link and duplex speed, let's use that instead >> of the default unknown speed. The user can still overwrite it later if >> desired via: 'ethtool -s'. T

Re: [Qemu-devel] [PATCH net-next 1/2] virtio_net: allow hypervisor to indicate linkspeed and duplex setting

On 12/20/2017 12:52 PM, Michael S. Tsirkin wrote: > On Wed, Dec 20, 2017 at 12:07:55PM -0500, Jason Baron wrote: >> >> >> On 12/20/2017 09:57 AM, Michael S. Tsirkin wrote: >>> On Thu, Dec 14, 2017 at 02:33:53PM -0500, Jason Baron wrote: If the hypervisor exports the link and duplex speed, le

Re: [Qemu-devel] [PATCH 2/2] qemu: add linkspeed and duplex setting to virtio-net

On 12/20/2017 09:33 AM, Yan Vugenfirer wrote: > >> On 20 Dec 2017, at 16:31, Michael S. Tsirkin wrote: >> >> On Tue, Dec 19, 2017 at 11:52:39AM -0500, Jason Baron wrote: >>> >>> >>> On 12/19/2017 04:19 AM, Yan Vugenfirer wrote: >>>>

[Qemu-devel] [PATCH 3/3] qemu: add linkspeed and duplex settings to virtio-net

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

[Qemu-devel] [PATCH net-next v2 1/3] virtio_net: propagate linkspeed/duplex settings from the hypervisor

The ability to set speed and duplex for virtio_net in useful in various scenarios as described here: 16032be virtio_net: add ethtool support for set and get of settings However, it would be nice to be able to set this from the hypervisor, such that virtio_net doesn't require custom guest ethtool

[Qemu-devel] [PATCH 2/3] qemu: use 64-bit values for feature flags in virtio-net

In prepartion for using some of the high order feature bits, make sure that virtio-net uses 64-bit values everywhere. Signed-off-by: Jason Baron Cc: "Michael S. Tsirkin" Cc: Jason Wang --- hw/net/virtio-net.c| 54 +- include/hw/virtio/virtio-

[Qemu-devel] [PATCH v2 0/3] virtio_net: allow hypervisor to indicate linkspeed and duplex setting

this patch. The 1/3 patch is against net-next, while the 2-3/3 patch are the associated qemu changes that would go in after as update-linux-headers.sh should be run first. So the qemu patches are a demons

Re: [Qemu-devel] [PATCH net-next v2 1/3] virtio_net: propagate linkspeed/duplex settings from the hypervisor

On 12/27/2017 04:43 PM, David Miller wrote: > From: Jason Baron > Date: Fri, 22 Dec 2017 16:54:01 -0500 > >> The ability to set speed and duplex for virtio_net in useful in various >> scenarios as described here: >> >> 16032be virtio_net: add ethtool support for set and get of settings >> >> Ho

[Qemu-devel] (resend)[PATCH 1/2] ps2: Clear the queue on PS/2 mouse reset and obey device disable

This allows guest's to correctly reinitialize and identify the mouse should the guest decide to re-scan or reset during mouse input events. Signed-off-by: Geoffrey McRae --- hw/input/ps2.c | 4 1 file changed, 4 insertions(+) diff --git a/hw/input/ps2.c b/hw/input/ps2.c index 06f5d2ac4a..6

[Qemu-devel] (resend)[PATCH 2/2] ps2: Fix mouse stream corruption due to lost data

This fixes an issue by adding bounds checking to multi-byte packets where the PS/2 mouse data stream may become corrupted due to data being discarded when the PS/2 ringbuffer is full. Interrupts for Multi-byte responses are postponed until the final byte has been queued. These changes fix a bug w

[Qemu-devel] [PATCHv2 2/2] ps2: Fix mouse stream corruption due to lost data

This fixes an issue by adding bounds checking to multi-byte packets where the PS/2 mouse data stream may become corrupted due to data being discarded when the PS/2 ringbuffer is full. Interrupts for Multi-byte responses are postponed until the final byte has been queued. These changes fix a bug w

[Qemu-devel] [PATCHv2 1/2] ps2: Clear the PS/2 queue and obey disable

This allows guest's to correctly reinitialize and identify the mouse should the guest decide to re-scan or reset during mouse input events. When the guest sends the "Identify" command, due to the PC's hardware architecutre it is impossible to reliably determine the response from the command amongs

[Qemu-devel] [PATCHv3 1/2] ps2: Clear the PS/2 queue and obey disable

This allows guest's to correctly reinitialize and identify the mouse should the guest decide to re-scan or reset during mouse input events. When the guest sends the "Identify" command, due to the PC's hardware architecutre it is impossible to reliably determine the response from the command amongs

[Qemu-devel] [PATCHv3 2/2] ps2: Fix mouse stream corruption due to lost data

This fixes an issue by adding bounds checking to multi-byte packets where the PS/2 mouse data stream may become corrupted due to data being discarded when the PS/2 ringbuffer is full. Interrupts for Multi-byte responses are postponed until the final byte has been queued. These changes fix a bug w

Re: [Qemu-devel] [PATCH] virtio-pci: Add subsystem-vendor-id property

Hi Michael, It looks like this was never applied. Can it be, please? On Wed, Dec 20, 2017 at 9:24 AM, Michael S. Tsirkin wrote: > On Wed, Dec 13, 2017 at 10:07:12AM +, Stefan Hajnoczi wrote: > > On Wed, Dec 13, 2017 at 12:26:44AM -0800, Ben Warren via Qemu-devel > wrote: >

[Qemu-devel] Outreachy intro: micro:bit project

d the Cortex-M0 cpu. I'm very excited to work with QEMU community. Wish me luck! Best regards, Julia Suvorova.

Re: [Qemu-devel] [PATCH v7 1/2] Implement .hex file loader

> This patch adds Intel Hexadecimal Object File format support to > the loader. The file format specification is available here: > http://www.piclist.com/techref/fileext/hex/intel.htm > > The file format is mainly intended for embedded systems > and microcontrollers, such as Micro:bit Arduino, AR

[Qemu-devel] [PATCH 1/4] eth: add speed and duplex definitions

Pull in definitions for SPEED_UNKNOWN, DUPLEX_UNKNOWN, DUPLEX_HALF, and DUPLEX_FULL. Signed-off-by: Jason Baron Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: virtio-...@lists.oasis-open.org --- include/net/eth.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/net/eth.h b/inclu

[Qemu-devel] [PATCH 0/4] virtio-net: allow linkspeed and duplex setting

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. Michael Tsirkin requested that we pull in the linkspeed/duplex defines from include/linux/ethtool.h. I

[Qemu-devel] [PATCH 2/4] rocker: drop local duplex definitions

net/rocker/rocker_fp.c b/hw/net/rocker/rocker_fp.c index 4b3c984..13a14a0 100644 --- a/hw/net/rocker/rocker_fp.c +++ b/hw/net/rocker/rocker_fp.c @@ -16,17 +16,13 @@ #include "qemu/osdep.h" #include "net/clients.h" +#include "net/eth.h" #include "rocker.h" #inclu

[Qemu-devel] [PATCH 4/4] virtio-net: add linkspeed and duplex settings to virtio-net

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

[Qemu-devel] [PATCH 3/4] virtio-net: use 64-bit values for feature flags

In prepartion for using some of the high order feature bits, make sure that virtio-net uses 64-bit values everywhere. Signed-off-by: Jason Baron Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: virtio-...@lists.oasis-open.org --- hw/net/virtio-net.c| 55 +

[Qemu-devel] [PATCH] checkpatch: add a warning for basename/dirname

Signed-off-by: Julia Suvorova --- scripts/checkpatch.pl | 5 + 1 file changed, 5 insertions(+) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 1b4b812..6c4fb42 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -2584,6 +2584,11 @@ sub process {

Re: [Qemu-devel] [PATCH] checkpatch: add a warning for basename/dirname

On 02.03.2018 11:56, Paolo Bonzini wrote: > On 02/03/2018 09:22, Julia Suvorova wrote: >> Signed-off-by: Julia Suvorova >> --- >> scripts/checkpatch.pl | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl >> index 1b4b812..6c4fb42 100755

[Qemu-devel] [PATCH v2] checkpatch: add a warning for basename/dirname

g_path_get_* do the same as g_strdup(basename/dirname(...)) but without modifying the argument. Signed-off-by: Julia Suvorova --- scripts/checkpatch.pl | 5 + 1 file changed, 5 insertions(+) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 1b4b812..a88af61 100755 --- a/scrip

Re: [Qemu-devel] [PATCH 4/4] virtio-net: add linkspeed and duplex settings to virtio-net

On 03/02/2018 02:14 AM, Jason Wang wrote: > > > On 2018年03月02日 11:46, Jason Baron wrote: >> 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_DUP

Re: [Qemu-devel] [PATCH v3] vmgenid: allow VM Generation ID modification via QMP/HMP

On Fri, Mar 2, 2018 at 2:57 AM, Daniel P. Berrangé wrote: > On Fri, Mar 02, 2018 at 10:37:20AM +0200, Or Idgar wrote: > > From: Or Idgar > > > > This patch allow changing the Virtual Machine Generation > > ID through QMP/HMP while the vm guest is running. > > the spec (http://go.microsoft.com/fw

Re: [Qemu-devel] [PATCH 1/4] eth: add speed and duplex definitions

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, DUPLEX_HALF, >> and DUPLEX_FULL. >> >> Signed-off-by: Jason Baron >> Cc: "Michael S. Tsirkin" >> Cc: Jason Wang >> Cc: virt

Re: [Qemu-devel] [PATCH 4/4] virtio-net: add linkspeed and duplex settings to virtio-net

On 03/02/2018 03:22 PM, Michael S. Tsirkin wrote: > On Fri, Mar 02, 2018 at 11:59:00AM -0500, Jason Baron wrote: >> On 03/02/2018 02:14 AM, Jason Wang wrote: >>> >>> >>> On 2018年03月02日 11:46, Jason Baron wrote: Although linkspeed and duplex can be set in a linux guest via 'ethtool -s',

Re: [Qemu-devel] [virtio-dev] [PATCH 4/4] virtio-net: add linkspeed and duplex settings to virtio-net

On 03/04/2018 08:05 AM, Yan Vugenfirer wrote: > > >> On 2 Mar 2018, at 22:19, Michael S. Tsirkin > > wrote: >> >> On Fri, Mar 02, 2018 at 03:14:01PM +0800, Jason Wang wrote: >>> >>> >>> On 2018年03月02日 11:46, Jason Baron wrote: Although linkspeed and duplex can be se

[Qemu-devel] [PATCH v2 2/3] virtio-net: use 64-bit values for feature flags

In prepartion for using some of the high order feature bits, make sure that virtio-net uses 64-bit values everywhere. Signed-off-by: Jason Baron Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: virtio-...@lists.oasis-open.org --- hw/net/virtio-net.c| 55 +

<    6   7   8   9   10   11   12   13   14   >