RSS support.")
Cc: sta...@vger.kernel.org
Cc: qemu-devel@nongnu.org
Signed-off-by: Breno Leitao
Reviewed-by: Heng Qi
Reviewed-by: Xuan Zhuo
Signed-off-by: David S. Miller
Signed-off-by: Vlad Poenaru
---
drivers/net/virtio_net.c | 25 +
1 file changed, 21 insertio
AGL lower banner which is cropping out
> the main display.
Yes, like I've said, but apparently I've substituted landscape w/
portrait, applications are designed to accommodate portrait orientation.
The panels, are added dynamically by homescreen.
>
> On Fri, 23 Oct 2020 at 13:32,
On Fri, Oct 23, 2020 at 12:52:17PM +0100, Alex Bennée wrote:
>
> Gerd Hoffmann writes:
>
> > Hi,
> >
> >> [2.930300] [drm] virgl 3d acceleration not supported by host
> >
> > Nope, not active.
> >
> >> -display gtk,show-cursor=on \
> >
> > Needs -display gtk,gl=on for opengl support.
ets-proto.c | 855
> +
> util/qemu-sockets.c | 71 +++-
> 5 files changed, 916 insertions(+), 21 deletions(-)
> create mode 100644 tests/test-sockets-proto.c
>
Series Reviewed-by: Vlad Yasevich
-vlad
On 06/01/2017 03:02 AM, Jason Wang wrote:
>
>
> On 2017年05月31日 02:57, Dr. David Alan Gilbert wrote:
>> * Vlad Yasevich (vyase...@redhat.com) wrote:
>>> On 05/26/2017 12:03 AM, Jason Wang wrote:
>>>> On 2017年05月25日 02:05, Vladislav Yasevich wrote:
>>
tm);
>> +timer_free(timer->tm);
>> +qemu_mutex_destroy(&timer->active_lock);
>
> Can you explain what makes this safe; we're not
> holding the lock at this point are we? Are we guaranteed
> that no one else will try and take it?
> Either way i
> @@ -212,21 +212,19 @@ static void qemu_announce_self_iter(NICState *nic,
>> void *opaque)
>> qemu_send_packet_raw(qemu_get_queue(nic), buf, len);
>> }
>>
>> -
>> static void qemu_announce_self_once(void *opaque)
>> {
>> -
he 'migrate_set_parameters' command.
I can do that.
>
>> diff --git a/qapi-schema.json b/qapi-schema.json
>> index 2030087..126b09d 100644
>> --- a/qapi-schema.json
>> +++ b/qapi-schema.json
>> @@ -654,6 +654,25 @@
>>'returns'
On 05/30/2017 10:24 AM, Juan Quintela wrote:
> Vlad Yasevich wrote:
>> On 05/30/2017 06:11 AM, Juan Quintela wrote:
>>> Vladislav Yasevich wrote:
>>>> Add a qmp command that can trigger guest announcements.
>>>>
>>>> Based on work of G
if (err) {
>> +error_report_err(err);
>> +}
>> +}
>
>
> My understanding is that this the "cool way" to spell this nowadays is:
>
> hmp_handle_error(mon, &err);
>
> Just in case you want to change it.
>
Thanks. I must have used an older function as base. I'll check it out.
-vlad
+AnnounceTimer *timer = (AnnounceTimer *)opaque;
>
> Cast from void * is never needed.
>
OK
Thanks
-vlad
qemu_announce_self(&announce_params);
>
> Are I missreading qemu_annouce_self()?
> My reading is that it passes announce_params to a timer (i.e. async
> function), but here announce_params is a local variable here, no?
>
The AnnounceTimer holds a copy since each timer may have it's own values.
Thanks
-vlad
e_announce_parameters(AnnounceParameters *params, Error
>> **errp)
>> +{
>> +if (params->has_initial &&
>> +(params->initial < 1 || params->initial > 10)) {
>
> This is independent of this patch, but we really need a macro:
> CHECK(field, mininum, maximum)
>
> We repeat this left and right.
>
>> +void qemu_set_announce_parameters(AnnounceParameters *announce_params,
>> + AnnounceParameters *params)
>
>> +void qmp_announce_set_parameters(AnnounceParameters *params, Error **errp)
>
> Really similar functions name. I assume by know that the 1st function
> is used somewhere else in the series.
>
Yes, the first function is going to be used later.
Thanks
-vlad
ters announce_params = { 0 };
> qemu_set_announce_parameters(&announce_params, qemu_get_announce_params());
>
Ok.
>> +
>> +if (has_params)
>> +qemu_set_announce_parameters(&announce_params, params);
>> +
>> +qemu_announce_self(&announce_params);
>> +}
> The QMP changes look okay. Do you have a testsuite covering the new QMP
> command somewhere in the series?
>
There is basic test in patch 12.
Thanks
-vlad
>
> Why are we creating an enum here? Without reading further, it looks
> like you plan on using the enum to delineate members of a union? But
> that feels like it will be overly complicated. A struct should be
> sufficient (each parameter being an optional member of the struct, where
> you can supply as many or as few on input, but all are reported on output).
>
I end up using them for the HMP interface. If it's better, I can move this
definition to the HMP patch.
Thanks
-vlad
ote in his original series for the
description.
Dave, if you have any text to add as to why migration might need to tweak this,
I'd
appreciate it.
Thanks
-vlad
>> +int64_t self_announce_delay(AnnounceTimer *timer)
>> {
>> -assert(round < SELF_ANNOUNCE_ROUNDS && round > 0);
>> -/* delay 50ms, 150ms, 250ms, ... */
>> -return 50 + (SELF_ANNOUNCE_ROUNDS - round - 1) * 100;
>> +int64_t ret;
>
ation to succeed.
>
> For compatibility purpose, this property is disabled for machine
> types v2.9 and older.
>
> Cc: Aaron Conole
> Suggested-by: Michael S. Tsirkin
> Signed-off-by: Maxime Coquelin
Reviewed-by: Vlad Yasevich
-vlad
> ---
>
> Tests performed:
On 05/12/2017 03:24 PM, Dr. David Alan Gilbert wrote:
> * Vlad Yasevich (vyase...@redhat.com) wrote:
>> On 02/20/2017 07:16 PM, Germano Veit Michel wrote:
>>> qemu_announce_self() is triggered by qemu at the end of migrations
>>> to update the network regarding t
now you add in a possibility of a lot of packets being
sent for
each timeout (RARP, GARP, NA, IGMPv4 Reports, IGMPv6 Reports [even worse if
MLD1 is used]).
As you can see, this can get rather ugly...
I think we need timer user here. Migration and QMP being two to begin with.
Each
one would get a
On 05/02/2017 06:41 AM, Dr. David Alan Gilbert wrote:
> * Vlad Yasevich (vyase...@redhat.com) wrote:
>> On 03/30/2017 11:26 AM, Dr. David Alan Gilbert wrote:
>>> * Vlad Yasevich (vyase...@redhat.com) wrote:
>>>> On 03/30/2017 10:53 AM, Dr. David Alan Gilbert wrote
On 03/30/2017 11:26 AM, Dr. David Alan Gilbert wrote:
> * Vlad Yasevich (vyase...@redhat.com) wrote:
>> On 03/30/2017 10:53 AM, Dr. David Alan Gilbert wrote:
>>> * Vlad Yasevich (vyase...@redhat.com) wrote:
>>>> On 03/30/2017 04:24 AM, Dr. David Alan Gilbert wro
On 03/30/2017 10:53 AM, Dr. David Alan Gilbert wrote:
> * Vlad Yasevich (vyase...@redhat.com) wrote:
>> On 03/30/2017 04:24 AM, Dr. David Alan Gilbert wrote:
>>> * Vladislav Yasevich (vyase...@redhat.com) wrote:
>>>> virtio announcements seem to run on its own timer
>
> So this switch seems wrong to me: by the time VM is started
> on destination all timers might have expired.
>
That explains what I am seeing now. Hmm... may be combining them this way
isn't the right approach. I think I'll leave RARPs alone and export an ab
t the moment the QEMU RARPs
> are sent at the end of migration, while the Virtio ARPs are sent
> when the guest starts running which is quite a bit later.
>
> In many ways the 'when the guest starts' is better, given that libvirt
> etc has had a chance to reconfigure the networking, but I'm not that
> sure if it's safe to move the existing one - I had considered *adding*
> another shot of the current mechanism after the guest is started.
>
Yes, the timing of things have been giving me some issues, but I wanted to post
this patch to get some comments just like this one..
I've wondered why they qemu one happens before the guest starts running.
> I certainly think it's wrong to do the virtio announce at the earlier
> point.
>
I see.
> See also Germano's thread of being able to retrigger the announce
> at arbitrary points, and the series I posted a couple of days ago
> to extend the length/timing of the announce.
>
That's kind of what prompted me to do try this. The issue with just
exposing qemu_announce_self() is that RARPS just aren't enough in
some cases (vlans, multicast). This attempts to add the callback
like Jason mentioned, but then we get timer interactions between the
virtio-net timers and qemu one.
-vlad
> Dave
>
>> --
>> 2.7.4
>>
>>
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
>
Resubmitted with errors fixed.
Regards,
Vlad
On 12/21/2016 01:01 AM, no-re...@patchew.org wrote:
> Hi,
>
> Your series seems to have some coding style problems. See output below for
> more information:
>
> Subject: [Qemu-devel] [PATCHv4] multiboot: copy the cmdline ver
get_opt_value() truncates the value at the first comma
Use memcpy() instead
Unescape the module filename and parameters with get_opt_value()
before calling mb_add_cmdline()
Signed-off-by: Vlad Lungu
---
hw/i386/multiboot.c | 21 +++--
1 file changed, 11 insertions(+), 10
get_opt_value() truncates the value at the first comma
Use memcpy() instead
Unescape the module filename and parameters with get_opt_value()
before calling mb_add_cmdline()
Signed-off-by: Vlad Lungu
---
hw/i386/multiboot.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions
On 12/18/2016 10:25 PM, Eduardo Habkost wrote:
> On Thu, Dec 15, 2016 at 02:32:04PM +0200, Vlad Lungu wrote:
>> get_opt_value() truncates the value at the first comma
>> Use memcpy() instead
>> Unescape the module filename and parameters with get_opt_value()
>> be
get_opt_value() truncates the value at the first comma
Use memcpy() instead
Unescape the module filename and parameters with get_opt_value()
before calling mb_add_cmdline()
Signed-off-by: Vlad Lungu
---
hw/i386/multiboot.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions
On 12/15/2016 02:29 PM, Paolo Bonzini wrote:
>
> On 15/12/2016 12:34, Vlad Lungu wrote:
>>
>> On 12/15/2016 12:56 PM, Paolo Bonzini wrote:
>>> On 15/12/2016 11:03, Vlad Lungu wrote:
>>>>
>>>> if (initrd_filename) {
>>>> -
On 12/15/2016 12:56 PM, Paolo Bonzini wrote:
>
> On 15/12/2016 11:03, Vlad Lungu wrote:
>>
>> if (initrd_filename) {
>> -char *next_initrd, not_last;
>> +char *next_initrd, not_last, tmpbuf[strlen(initrd_filename) + 1];
>>
>>
get_opt_value() truncates the value at the first comma
Use memcpy() instead
Unescape the module filename and parameters with get_opt_value()
before calling mb_add_cmdline()
Signed-off-by: Vlad Lungu
---
hw/i386/multiboot.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions
Sorry about replying to myself, I only had one coffee today.
There is no need for mb_add_modstring(), we can simply do
get_opt_value(tmpbuf,..) then mb_add_cmdline(&mbs, tmpbuf)
Regards,
Vlad
On 12/15/2016 11:45 AM, Vlad Lungu wrote:
> get_opt_value() truncates the value at the firs
get_opt_value() truncates the value at the first comma
Rename mb_add_cmdline() to mb_add_modstring()
Unescape filename too
Add new mb_add_cmdline() using memcpy()
Signed-off-by: Vlad Lungu
---
hw/i386/multiboot.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions
memcpy for the cmdline, with
get_opt_value() for the modules and also unescapes the filename for
get_image_size()/load_image() . You still can't have spaces in filenames,
so maybe a new scheme should be devised for this.
Regards,
Vlad
get_opt_value() truncates the value at the first comma
Use memcpy() instead
Signed-off-by: Vlad Lungu
---
hw/i386/multiboot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/multiboot.c b/hw/i386/multiboot.c
index 387caa6..b4495ad 100644
--- a/hw/i386/multiboot.c
get_opt_value() truncates the value at the first comma.
Use memcpy() instead.
Signed-off-by: Vlad Lungu
---
hw/i386/multiboot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/multiboot.c b/hw/i386/multiboot.c
index 387caa6..b4495ad 100644
--- a/hw/i386/multiboot.c
On 08/31/2015 11:15 PM, Jason Wang wrote:
>
>
> On 08/31/2015 10:24 PM, Vlad Yasevich wrote:
>> On 08/31/2015 05:59 AM, Jason Wang wrote:
>>>
>>> On 08/28/2015 10:06 PM, Vladislav Yasevich wrote:
>>>> In standard operation mode, when the receive
{
>
> can guarantee there's no overwriting?
>
The problem is the calculation of avail. When the buffer is full,
avail will be the the size of the receive buffer. So the test
above will be false because the driver thinks there is actually
enough room.
With his patch, 'avail' will be calculated to 0.
-vlad
139: correctly track full receive buffer in standard mode
>
Self nack. The second patch is wrong. Will resubmit when fixed.
-vlad
> hw/net/rtl8139.c | 44 +++-
> 1 file changed, 39 insertions(+), 5 deletions(-)
>
s,
>> uint32_t val)
>> /* this value is off by 16 */
>> s->RxBufPtr = MOD2(val + 0x10, s->RxBufferSize);
>>
>> +/* We just read data, clear full buffer state */
>> +rtl8139_set_rxbuf_full(s, false);
>> +
>> /* more buffer space may be available so try to receive */
>> qemu_flush_queued_packets(qemu_get_queue(s->nic));
>
> What if the guest writes this register while we're in C+ mode?
>
In C+ mode the guest uses a descriptor ring instead of liner buffer so a well
behaved
C+ guest wouldn't write this value. Validated this with a linux guest.
I guess a malicious guest could do this, but then it could do a lot of other
things too.
-vlad
call.
Isn't that already there. A few drivers already return 0 to trigger a requeue.
What's
missing?
>
> Is rtl8139_RxBufPtr_write() guaranteed to be called when the guest
> refills rx buffers?
>
It calls it on read, once it's consumed a packet, to advance to the next packet
in the
buffer.
-vlad
gmentation for tap interface?
No. Those features are set by qemu when the guest is created and
mirror any features that are supported by the guest. So, if the guest
virtio doesn't have that feature, neither will the tap device.
Which kernel version are you using on the host?
-vlad
>
g) on the tap. If not, then someone else is
fragmenting
packets and you need to find who.
-vlad
> Pls copy me in all the replies as I am not on the list.
>
> # brctl show
> bridge name bridge id STP enabled interfaces
> br-vx 8000.323a9146
he if you turn off the link on the backend, the link to the VM
stays
up but can't really reach the network.
Now, you could say "Don't do this" and document it, but it's still ugly and
causes
issues.
We could disable the link state change on backends and only allow it on NIC
type devices.
That would also solve this.
-vlad
>
> Stefan
>
ld you try the kernel from
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
turn the offloads back on and see if the problem is solved?
Thanks
-vlad
> That's it, it is impossible to use Trusty acting as a QEmu 2.0
> Hypervisor (metapakage `ubuntu-virt-server`), to make a basic v
avem/net.git
turn the offloads back on and see if the problem is solved?
Thanks
-vlad
> That's it, it is impossible to use Trusty acting as a QEmu 2.0
> Hypervisor (metapakage `ubuntu-virt-server`), to make a basic virtual
> tagged network within itself. QEmu 2.X guest does not rou
On 04/02/2014 11:29 AM, Michael S. Tsirkin wrote:
> On Wed, Apr 02, 2014 at 11:25:32AM -0400, Vlad Yasevich wrote:
>> On 04/02/2014 11:03 AM, Michael S. Tsirkin wrote:
>>> On Wed, Apr 02, 2014 at 10:57:08AM -0400, Vlad Yasevich wrote:
>>>> On 04/02/2014
On 04/02/2014 11:03 AM, Michael S. Tsirkin wrote:
> On Wed, Apr 02, 2014 at 10:57:08AM -0400, Vlad Yasevich wrote:
>> On 04/02/2014 06:46 AM, Yan Vugenfirer wrote:
>>>
>>> On Apr 2, 2014, at 11:51 AM, Michael S. Tsirkin wrote:
>>>
>>>> On Thu, Nov 2
On 04/02/2014 06:46 AM, Yan Vugenfirer wrote:
>
> On Apr 2, 2014, at 11:51 AM, Michael S. Tsirkin wrote:
>
>> On Thu, Nov 21, 2013 at 09:05:51PM -0500, Vlad Yasevich wrote:
>>> When a link change occurs on a backend (like tap), we currently do
>>> not prop
On 04/02/2014 04:51 AM, Michael S. Tsirkin wrote:
> On Thu, Nov 21, 2013 at 09:05:51PM -0500, Vlad Yasevich wrote:
>> When a link change occurs on a backend (like tap), we currently do
>> not propage such change to the nic. As a result, when someone turns
>> off a link
> }
> vhost_net_ack_features(tap_get_vhost_net(nc->peer), features);
> }
> +
> +if ((1 << VIRTIO_NET_F_CTRL_VLAN) & features) {
> +memset(n->vlans, 0, MAX_VLAN >> 3);
> +} else {
> +memset(n->vlans, 0xff,
iption seems a bit confusing to me. The value
we are returning describes whether or not qemu is performing
vlan filtering. I am not sure if it has any bearing on what
management may be doing.
I think the idea is that management, in the future, would look at
this value and make some decision abou
On 02/18/2014 05:06 AM, Michael S. Tsirkin wrote:
> On Mon, Feb 17, 2014 at 11:58:11AM -0500, Vlad Yasevich wrote:
>> On 02/17/2014 11:56 AM, Eric Blake wrote:
>>> On 02/17/2014 09:52 AM, Eric Blake wrote:
>>>> On 02/16/2014 07:27 PM, Amos Kong wrote:
>>>&g
gt;> Indentation is now off.
>>
>>> - "main-mac": main macaddr string (json-string)
>>> -- "vlan-table": a json-array of active vlan id
>>> +- "vlan-table": a json-array of active vlan id (optoinal)
>>
>> s/optoinal/optional/
&
; the vlan-talbe optional.
^^
table.
One question I have from the API perspective is can we suddenly change
something to be optional? If there are any users of this ,
wouldn't they have to change now to check the existence of this
list?
Thanks
-vlad
> [1] http://lists.n
On 11/22/2013 04:47 AM, Jason Wang wrote:
> On 11/22/2013 04:04 AM, Vlad Yasevich wrote:
>> e1000 provides a E1000_RAH_AV bit on every complete write
>> to the Receive Address Register. We can use this bit
>> 2 ways:
>> 1) To trigger HMP notifications. When the bit is
ce windows will not configure the link-local IPv4 address, and
when the link is turned on, the proper address address is configured.
Signed-off-by: Vlad Yasevich
---
net/net.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/net/net.c b/net/net.c
ind
mac address has been
completely written. Simple set a flag whenever mac has changed
and at the next transition of 9346 register from Write to Normal
mode, we update the HMP.
Signed-off-by: Vlad Yasevich
---
hw/i386/pc_piix.c| 4
hw/i386/pc_q35.c | 4
hw/net/rtl8139.c
the Receive Address Register, so that we would not try
to match received traffic to this address when it is
not completely set.
Signed-off-by: Vlad Yasevich
---
hw/net/e1000.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/hw/net/e1000.c b/hw/net/e1000
easy, but rtl8139
isn't as nice.
Please take a look and I'd like to hear your comments.
Thanks
-vlad
Vlad Yasevich (2):
e1000: Use Address_Available bit as HW latch
rtl8139: update HMP only when the address is fully written
hw/i386/pc_piix.c| 4
hw/i386/pc_q35.c | 4
On 11/11/2013 02:50 AM, Paolo Bonzini wrote:
> Il 11/11/2013 06:18, Jason Wang ha scritto:
>> On 11/08/2013 10:13 AM, Vlad Yasevich wrote:
>>> It is currently possible to specify things like:
>>> -device e1000,netdev=foo,vlan=1
>>> With this usage, whichev
On 11/18/2013 05:40 PM, Alex Williamson wrote:
> On Mon, 2013-11-18 at 17:07 -0500, Vlad Yasevich wrote:
>> On 11/18/2013 04:33 PM, Alex Williamson wrote:
>>> On Mon, 2013-11-18 at 15:57 -0500, Vlad Yasevich wrote:
>>>> On 11/18/2013 03:33 PM, Alex Williamson wrote:
On 11/18/2013 04:33 PM, Alex Williamson wrote:
> On Mon, 2013-11-18 at 15:57 -0500, Vlad Yasevich wrote:
>> On 11/18/2013 03:33 PM, Alex Williamson wrote:
>>> On Mon, 2013-11-18 at 15:09 -0500, Vlad Yasevich wrote:
>>>> On 11/18/2013 02:58 PM, Alex Williamson wrote:
On 11/18/2013 03:33 PM, Alex Williamson wrote:
> On Mon, 2013-11-18 at 15:09 -0500, Vlad Yasevich wrote:
>> On 11/18/2013 02:58 PM, Alex Williamson wrote:
>>> On Mon, 2013-11-18 at 21:47 +0200, Michael S. Tsirkin wrote:
>>>> This reverts commit cd5be5829c
more
thoroughly.
The patch that was applied was controversial and more then 1 person
expressed reservations.
-vlad
>
> None of these change the behavior of hardware, they only change when the
> monitor gets told about mac address changes. I'd suggest either add the
> emulation
ibly revisit for 1.8.
>
> Reported-by: Vlad Yasevich
> Cc: Amos Kong
> Cc: Alex Williamson
Reviewed-by: Vlad Yasevich ---
> hw/net/e1000.c | 2 +-
> hw/net/rtl8139.c | 5 -
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/hw/net/e1000.c b/hw/net/e10
On 11/18/2013 02:42 PM, Michael S. Tsirkin wrote:
> On Mon, Nov 18, 2013 at 12:33:20PM -0500, Vlad Yasevich wrote:
>> On 11/18/2013 10:02 AM, Michael S. Tsirkin wrote:
>>> On Tue, Nov 05, 2013 at 07:17:18PM +0800, Amos Kong wrote:
>>>> We currently just update the HMP
nic to update HMP NIC
>> info when every bit is changed. It will be same as virtio-net.
>>
>> Signed-off-by: Amos Kong
>
> Vlad here told me he did some research and this
> does not actually match hardware behaviour
> for either e1000 or rtl8139.
>
> Vlad, would y
On 11/18/2013 10:32 AM, Amos Kong wrote:
> object_get_canonical_path() returns a gchar*, it should be freeed by the
> caller.
>
> Signed-off-by: Amos Kong
Reviewed-by: Vlad Yasevich
-vlad
> ---
> v2: put gchar *path inside rxfilter_notify_enabled block
> ---
>
On 11/18/2013 08:47 AM, Amos Kong wrote:
> object_get_canonical_path() returns a gchar*, it should be freeed by the
> caller.
>
> Signed-off-by: Amos Kong
Reviewed-by: Vlad Yasevich
-vlad
> ---
> hw/net/virtio-net.c | 8
> 1 file changed, 4 insertions(+), 4 d
Save the result of the call to object_get_cannonical_path()
so we can free it.
Signed-off-by: Vlad Yasevich
---
v1->v2: Builds and works :)
qom/object.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/qom/object.c b/qom/object.c
index b617f26..fc19cf6 100644
--- a/
On 11/15/2013 12:06 PM, Vlad Yasevich wrote:
Save the result of the call to object_get_cannonical_path()
so we can free it.
Signed-off-by: Vlad Yasevich
---
qom/object.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/qom/object.c b/qom/object.c
index b617f26
Save the result of the call to object_get_cannonical_path()
so we can free it.
Signed-off-by: Vlad Yasevich
---
qom/object.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/qom/object.c b/qom/object.c
index b617f26..21b6f87 100644
--- a/qom/object.c
+++ b/qom/object.c
>rxfilter_notify_enabled = 0;
+}
+}
Please fix the memory leak:
object_get_canonical_path() returns a gchar* that the caller must free.
Wow, this memory leak is all over the place and not just in this patch.
-vlad
nit = pc_q35_init_1_7,
};
Hi Michael
Shouldn't the '.alias' be removed from the 1.7 machine?
Thanks
-vlad
-#define PC_Q35_1_6_MACHINE_OPTIONS PC_Q35_MACHINE_OPTIONS
+#define PC_Q35_1_6_MACHINE_OPTIONS PC_Q35_1_7_MACHINE_OPTIONS
static QEMUMachine pc_q35_machine_v1_6
On 11/13/2013 03:00 PM, Michael S. Tsirkin wrote:
On Wed, Nov 13, 2013 at 11:21:18AM -0500, Vlad Yasevich wrote:
On 11/10/2013 07:11 AM, Michael S. Tsirkin wrote:
On Fri, Nov 08, 2013 at 02:42:27PM -0500, Vlad Yasevich wrote:
What about this approach? This only updates the monitory when all
On 11/10/2013 07:11 AM, Michael S. Tsirkin wrote:
On Fri, Nov 08, 2013 at 02:42:27PM -0500, Vlad Yasevich wrote:
What about this approach? This only updates the monitory when all the
bits have been written to.
-vlad
Thanks!
Some comments below.
-- >8 --
Subject: [PATCH] e1000/rtl8
t find anything in the docs.
Otherwise, looks good to me.
Reviewed-by: Vlad Yasevich
-vlad
s = iov_to_buf(iov, iov_cnt, 0, &mac_data.entries,
sizeof(mac_data.entries));
@@ -629,19 +629,19 @@ static int virtio_net_handle_mac(VirtIONet *n, uint8_t
cmd,
}
On 11/08/2013 10:43 PM, Amos Kong wrote:
On Fri, Nov 08, 2013 at 02:42:27PM -0500, Vlad Yasevich wrote:
What about this approach? This only updates the monitory when all the
bits have been written to.
Hi Vlad,
Looks good to me.
Using this patch, we don't need to care the writing orde
On 11/10/2013 07:11 AM, Michael S. Tsirkin wrote:
On Fri, Nov 08, 2013 at 02:42:27PM -0500, Vlad Yasevich wrote:
What about this approach? This only updates the monitory when all the
bits have been written to.
-vlad
Thanks!
Some comments below.
-- >8 --
Subject: [PATCH] e1000/rtl8
What about this approach? This only updates the monitory when all the
bits have been written to.
-vlad
-- >8 --
Subject: [PATCH] e1000/rtl8139: update HMP NIC when every bit is written
We currently just update the HMP NIC info when the last bit of macaddr
is written. This assumes that gu
On 11/08/2013 11:07 AM, Vlad Yasevich wrote:
Commit 921ac5d0f3a0df869db5ce4edf752f51d8b1596a
virtio-net: remove layout assumptions for ctrl vq
introduced a regression where the multicast address filter
entries are written to the beginning of the mac table array,
thus overwriting any
the filter.
The multicast addresses should be written after all the
unicast addresses.
Signed-off-by: Vlad Yasevich
---
hw/net/virtio-net.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 22dbd05..94e8b68 100644
--- a/hw/net
a segmentation fault on exit in qemu_free_net_client.
That patch treates the above command line options as invalid and
generates an error at start-up.
Signed-off-by: Vlad Yasevich
---
hw/core/qdev-properties-system.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/hw/core/qdev
ting half-complete state is not the right thing, IMO. Right now,
it's doesn't have much impact, but if we start writing these addresses
to the host nic, then this will have a much bigger impact as I said above.
-vlad
Alex
I would say let's leave e1000/rtl8139 well alone unless
we s
qemu_format_nic_info_str(qemu_get_queue(s->nic), (uint8_t
*)macaddr);
+s->mac_change_flags = 0;
}
}
Any thoughts?
-vlad
QEMU 0.15.0 fixes the problem.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/721793
Title:
QEMU freezes on startup (100% CPU utilization)
Status in QEMU:
New
Bug description:
0.12.5 was the l
** Attachment added: "2.6.35.11 kernel config"
https://bugs.launchpad.net/qemu/+bug/721793/+attachment/1859875/+files/config.gz
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/721793
Title:
QEMU
** Attachment added: "Strace log"
https://bugs.launchpad.net/bugs/721793/+attachment/1859874/+files/strace-qemu.log.gz
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/721793
Title:
QEMU freezes o
Public bug reported:
0.12.5 was the last version of QEMU that runs ok and boots any os image.
0.13.0-0.14.0 just freeze, and the only thing I see is a black screen and both
of them make it use 100% of CPU also.
Both kernels 2.6.35.11 and 2.6.37.1 with and without PAE support.
tested commands:
no signoff. I'll re-branch and do a 3-part (GOT,NE2000,qemu)
patchset .
Vlad
Now with board config file included, so it can be built :-)
Thiemo, I'll think about the memory size issue and get back to you on that.
How about a git repo for U-Boot, if this thing takes off?
Vlad
---
diff --git a/Makef
> Vlad Lungu wrote:
> [snip]
>>>> put some info somewhere (RAM, register,
>>>> emulated DIP-dwitch), like RAM size, endianness of the CPU.
>>>>
>>>
>>> Endianness is rather pointless. If your U-Boot binary doesn't explode
>&g
Thiemo Seufer wrote:
Vlad Lungu wrote:
Thiemo Seufer wrote:
Vlad Lungu wrote:
[snip]
+long int initdram(int board_type)
+{
+ /* Sdram is setup by assembler code */
+ /* If memory could be changed, we should return the true value
here */
+ return
Thiemo Seufer wrote:
Vlad Lungu wrote:
[snip]
+long int initdram(int board_type)
+{
+ /* Sdram is setup by assembler code */
+ /* If memory could be changed, we should return the true value
here */
+ return MEM_SIZE*1024*1024;
Qemu gets the amount of
Thiemo Seufer wrote:
Vlad Lungu wrote:
Fix for mips GOT relocation bug, NE2000 bugs, add support for qemu -M mips
target.
[snip]
diff --git a/board/qemu-mips/config.mk b/board/qemu-mips/config.mk
[snip]
+#
+# AMD development board AMD Alchemy DbAu1x00, MIPS32 core
Fix for mips GOT relocation bug, NE2000 bugs, add support for qemu -M mips target.
Patch is against U-Boot master branch.
--
diff --git a/Makefile b/Makefile
index 85885b1..8f650d2 100644
--- a/Makefile
+++ b/Makef
Vlad Lungu wrote:
lol, replying to myself
Blue Swirl wrote:
Someone could port OpenBIOS or LinuxBIOS to MIPS.
Well, just FYI:
I sort-of-ported U-Boot to Qemu (-M mips). Network performance sucks for
some reason (hard enough that tftp-booting a kernel is impossible) and I
didn't
1 - 100 of 105 matches
Mail list logo
