> 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
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
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
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
> }
> 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,
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
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 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 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
; 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
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/
&
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
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
qemu_format_nic_info_str(qemu_get_queue(s->nic), (uint8_t
*)macaddr);
+s->mac_change_flags = 0;
}
}
Any thoughts?
-vlad
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
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
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
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
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/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
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
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/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
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
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
>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
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
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
---
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/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
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
> ---
>
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 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
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
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
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
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 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:
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
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
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/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
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
>
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
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
>
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
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
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(-)
>
{
>
> 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
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
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:
** 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
** 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
;s not attached.
Vlad
Thiemo Seufer wrote:
Vlad Lungu wrote:
I know some of you will laugh, but:
- QEMU malta emulation is not really complete, to put it mildly
Out of curiosity, what parts did you miss?
Like, for example, the PCI stuff. So I can use the network card.
And yes, I am aware of YAMON.
- the QEMU
db) cont
Continuing.
That's dirty alright, but not exactly quick. You kind of need gdb :-)
Vlad
that porting to
(-M malta) should not be that hard, and I think there is some PCI
support already in U-boot.
Vlad
way :-(
BTW, what's the status on the latest 2.4 patch I sent you?
Vlad
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
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
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
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:
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
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
no signoff. I'll re-branch and do a 3-part (GOT,NE2000,qemu)
patchset .
Vlad
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
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:
>>
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 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
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/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
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:
>> +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;
>
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
>
> 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
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
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
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
+AnnounceTimer *timer = (AnnounceTimer *)opaque;
>
> Cast from void * is never needed.
>
OK
Thanks
-vlad
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
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
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'
> @@ -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)
>> {
>> -
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
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
>
>
> 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
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
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
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
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
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
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
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
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];
>>
>>
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) {
>>>> -
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
1 - 100 of 105 matches
Mail list logo
