On Mon, Feb 1, 2021 at 10:07 AM Programmingkid
wrote:
>
>
>
> > On Feb 1, 2021, at 9:48 AM, Dan Streetman wrote:
> >
> > On Mon, Feb 1, 2021 at 9:23 AM Programmingkid
> > wrote:
> >>
> >> When trying to build QEMU I see this error:
> &g
branches.
> Aborting
>
> What I do to see this error:
> ./configure --target-list=i386-softmmu
Sorry, I don't see that error, what commit are you building from?
>
> I did some bisecting and found out this is the patch that causes the problem:
>
> commit 7d7dbf9dc15be6
validated when using --with-git-submodules=validate
and are only ignored when using --with-git-submodules=ignore.
Signed-off-by: Dan Streetman
---
v1: https://lists.gnu.org/archive/html/qemu-devel/2020-10/msg04799.html
changes since v1:
- add --help output explaining --with-git-submodules valid val
Hi, just a ping to try to keep this alive, does the patch look ok? I
can rebase it on the latest git if so (and if needed)
On Fri, Oct 16, 2020 at 4:39 PM Dan Streetman wrote:
>
> Replace the --enable-git-update and --disable-git-update configure params
> with the param --with-git-s
On Fri, Oct 2, 2020 at 9:11 AM Daniel P. Berrangé wrote:
>
> On Wed, Sep 30, 2020 at 09:28:54PM -0400, Dan Streetman wrote:
> > On Tue, Sep 22, 2020 at 12:34 PM Daniel P. Berrangé
> > wrote:
> > >
> > > On Wed, Jul 29, 2020 at 03:58:29PM -0400, Dan Street
not want to enable the
'git_update' mode; with the current code, that's not possible even
if the downstream package specifies --disable-git-update.
Signed-off-by: Dan Streetman
---
Makefile | 26 ++-
configure
On Tue, Sep 22, 2020 at 12:34 PM Daniel P. Berrangé wrote:
>
> On Wed, Jul 29, 2020 at 03:58:29PM -0400, Dan Streetman wrote:
> > The --disable-git-update configure param sets git_update=no, but
> > some later checks only look for the .git dir. This changes the
> > --
rent code, that's not possible even
if the downstream package specifies --disable-git-update.
Signed-off-by: Dan Streetman
---
Resend; this was sent twice before:
https://lists.nongnu.org/archive/html/qemu-trivial/2020-07/msg00180.html
https://lists.nongnu.org/archive/html/qemu-devel/20
rent code, that's not possible even
if the downstream package specifies --disable-git-update.
Signed-off-by: Dan Streetman
---
Note this is a rebased resend of a previous email to qemu-trivial:
https://lists.nongnu.org/archive/html/qemu-trivial/2020-07/msg00180.html
Makefile |
On Thu, Sep 19, 2019 at 5:34 AM Philippe Mathieu-Daudé
wrote:
>
> On 9/18/19 11:56 PM, Dan Streetman wrote:
> > On Wed, Sep 18, 2019 at 4:34 PM Alex Bennée wrote:
> >>
> >> Dan Streetman writes:
> >>
> >>> From: Dan Streetman
> >>&
On Wed, Sep 18, 2019 at 4:34 PM Alex Bennée wrote:
>
>
> Dan Streetman writes:
>
> > From: Dan Streetman
> >
> > There is currently no default machine type for arm so one must be specified
> > with --machine. This sets the 'virt' machine type as
On Tue, Sep 17, 2019 at 1:24 PM Dan Streetman
wrote:
>
> From: Dan Streetman
>
> There is currently no default machine type for arm so one must be specified
> with --machine. This sets the 'virt' machine type as default.
just to clarify why anyone would care if the
From: Dan Streetman
There is currently no default machine type for arm so one must be specified
with --machine. This sets the 'virt' machine type as default.
Signed-off-by: Dan Streetman
---
hw/arm/virt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/arm/virt.c b/hw/arm/vi
see bug 1829245 for regression introduced by this patch; these patches
will be reverted from xenial, and then re-uploaded along with a patch
for the regression in bug 1829380
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bug
On a Xenial DPDK setup with the proposed qemu version (1:2.5+dfsg-
5ubuntu10.37), I created a VM and attached a vhost-user interface to it
using this xml:
$ cat vm3-iface2.xml
the OVS interface was created with:
# ovs-vsctl add-port br1 vhu2 -- set Interface vhu2 t
@sil2100 yes I agree, let's wait longer before releasing. We have the
Canonical customer performing testing with the package, and we can run
some additional sanity checks as well. The config coming from the
customer is an openstack setup using OVS, so that's what we will setup
and perform sanity
clarification: by "original reporter" I mean the customer of Canonical,
reporting the problem to us.
** Tags removed: verification-mitaka-needed verification-needed
verification-needed-xenial verification-ocata-needed
** Tags added: verification-done verification-done-xenial
verification-mitaka-
This has been verified by the original reporter to fix the problem of
qemu crashing.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1823458
Title:
race condition between vhost_net_stop and CHR_EVENT
** Patch added: "lp1823458-ocata.debdiff"
https://bugs.launchpad.net/cloud-archive/+bug/1823458/+attachment/5258683/+files/lp1823458-ocata.debdiff
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/182
uca: workaround patches are needed in mitaka and ocata. Mitaka can pull
from Xenial build as usual, and debdiff for Ocata attached. Other UCA
releases are later than 2.9 and so are fixed with the upstream fix
mentioned in the description.
--
You received this bug notification because you are a
Note as mentioned in the description, it appears this was fixed upstream
by commit e7c83a885f8, which is included starting in version 2.9.
However, this commit depends on at least commit 5345fdb4467, and likely
more other previous commits, which make widespread code changes and are
unsuitable to ba
Fix Released
** Changed in: qemu (Ubuntu Bionic)
Status: In Progress => Fix Released
** Changed in: qemu (Ubuntu Trusty)
Status: In Progress => Won't Fix
** Changed in: qemu (Ubuntu Disco)
Assignee: Dan Streetman (ddstreet) => (unassigned)
** Changed in: qemu (Ub
On Mon, Apr 22, 2019 at 10:59 PM Jason Wang wrote:
>
>
> On 2019/4/23 上午4:14, Dan Streetman wrote:
> > On Sun, Apr 21, 2019 at 10:50 PM Jason Wang wrote:
> >>
> >> On 2019/4/17 上午2:46, Dan Streetman wrote:
> >>> From: Dan Streetman
> >&
On Fri, Apr 19, 2019 at 7:14 PM Michael S. Tsirkin wrote:
>
> On Tue, Apr 16, 2019 at 02:46:23PM -0400, Dan Streetman wrote:
> > From: Dan Streetman
> >
> > Buglink: https://launchpad.net/bugs/1823458
> >
> > There is a race condition when using th
On Sun, Apr 21, 2019 at 10:50 PM Jason Wang wrote:
>
>
> On 2019/4/17 上午2:46, Dan Streetman wrote:
> > From: Dan Streetman
> >
> > Buglink: https://launchpad.net/bugs/1823458
> >
> > There is a race condition when using the vhost-user driver, between
From: Dan Streetman
Buglink: https://launchpad.net/bugs/1823458
There is a race condition when using the vhost-user driver, between a guest
shutdown and the vhost-user interface being closed. This is explained in
more detail at the bug link above; the short explanation is the vhost-user
device
From: Dan Streetman
Buglink: https://launchpad.net/bugs/1823458
Currently, a user CHR_EVENT_CLOSED event will cause net_vhost_user_event()
to call vhost_user_cleanup(), which calls vhost_net_cleanup() for all
its queues. However, vhost_net_cleanup() must never be called like
this for fully
From: Dan Streetman
Buglink: https://launchpad.net/bugs/1823458
This is a race condition between the normal shutdown of a guest
and the handling of its vhost-user net being externally closed.
It's explained in more detail at the bug link; the short version
is that there are 2 problems, fix
** Description changed:
[impact]
on shutdown of a guest, there is a race condition that results in qemu
crashing instead of normally shutting down. The bt looks similar to
this (depending on the specific version of qemu, of course; this is
taken from 2.5 version of qemu):
(gdb)
test builds in https://launchpad.net/~ddstreet/+archive/ubuntu/lp1823458
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1823458
Title:
race condition between vhost_net_stop and CHR_EVENT_CLOSED on s
** Description changed:
[impact]
on shutdown of a guest, there is a race condition that results in qemu
crashing instead of normally shutting down. The bt looks similar to
this (depending on the specific version of qemu, of course; this is
taken from 2.5 version of qemu):
(gdb)
=> Dan Streetman (ddstreet)
** Also affects: qemu
Importance: Undecided
Status: New
** Changed in: qemu
Status: New => In Progress
** Changed in: qemu
Assignee: (unassigned) => Dan Streetman (ddstreet)
--
You received this bug notification because you are a member
** Tags added: sts-sponsor-ddstreet
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1818880
Title:
Deadlock when detaching network interface
Status in Ubuntu Cloud Archive:
Confirmed
Status in QEM
BTW this is the stacktrace I get from a Xenial guest on Xenial host:
[0.00] BUG: unable to handle kernel paging request at c904
[0.00] IP: [] hpet_enable.part.13+0x23/0x2a5
[0.00] PGD 171629ab067 PUD 171629ac067 PMD 171629ad067 PTE
8000fed00073
[0.0
You don't need a >1TB host to spin up a >1TB guest. Unless you're using
pci passthru (and/or SRIOV), or something else that requires qemu to
alloc and pin all guest mem, you can simply overcommit; normal guests
don't require mem pre-allocation or pinning.
On your host do this to allow overcommitt
And with non-massive mem (so the guest actually boots up), the guest
does show only 40 bits of phys mem addressing, so qemu will definitely
have to increase that to be able to provide >1TB of phys mem to the
guest (assuming qemu doesn't adjust that dynamically based on the total
mem provided to the
36 matches
Mail list logo
