Re: [libvirt] New QEMU daemon for persistent reservations

On 11/09/2017 12:46, Daniel P. Berrange wrote: >> So the helper is a bit different from QEMU with respect to both SELinux >> MCS labeling and the devices cgroup. Access limitation comes from only >> ever operating on devices that have been passed on the socket. SELinux >> MCS could be used so

Re: [libvirt] New QEMU daemon for persistent reservations

On 29/08/2017 14:41, Daniel P. Berrange wrote: > On Tue, Aug 22, 2017 at 06:27:40PM +0200, Paolo Bonzini wrote: >> Hi all, >> >> I am adding a new daemon to QEMU, that QEMU can connect to in order to >> issue persistent reservation commands. > > Can you e

Re: [libvirt] New QEMU daemon for persistent reservations

On 10/09/2017 11:38, Paolo Bonzini wrote: > The daemon can then be > placed in the same devices cgroup and SELinux MCS category as QEMU. At least regarding the devices cgroup, this is wrong, sorry (the socket can be given an MCS category to restrict who connects to it, but not the daemon).

Re: [libvirt] New QEMU daemon for persistent reservations

On 28/08/2017 13:11, Michal Privoznik wrote: > On 08/25/2017 12:41 AM, Paolo Bonzini wrote: >> On 22/08/2017 18:27, Paolo Bonzini wrote: >>> Hi all, > > Hey, sorry for late reply. I was enjoying my PTO by not reading e-mails :-) Me too! >>> >>> I am

Re: [libvirt] New QEMU daemon for persistent reservations

On 22/08/2017 18:27, Paolo Bonzini wrote: > Hi all, > > I am adding a new daemon to QEMU, that QEMU can connect to in order to > issue persistent reservation commands. > > The daemon can only issue the commands on file descriptor that QEMU > already has. In addition normal

[libvirt] New QEMU daemon for persistent reservations

Hi all, I am adding a new daemon to QEMU, that QEMU can connect to in order to issue persistent reservation commands. The daemon can only issue the commands on file descriptor that QEMU already has. In addition normal users shouldn't have access to the daemon's Unix socket in /run, so the

Re: [libvirt] [Qemu-devel] change x86 default machine type to Q35?

On 11/07/2017 16:42, Kevin Wolf wrote: >>> Concerning QEMU, could we maybe simply emit a warning a la >>> >>> "you did not specify a machine type with the -M option, so you are >>> currently running the the 'pc' machine type. Please note that >>> future >>> versions of QEMU might use the

[libvirt] Reminder: CFP: KVM Forum 2017

Just a quick reminder that the CFP is going to close in a week. Paolo On 02/05/2017 12:42, Paolo Bonzini wrote: > > KVM Forum 2017: Call For Participation > October 25-27, 2017 - Hilton Prague - Prague, Czech Republic

[libvirt] CFP: KVM Forum 2017

KVM Forum 2017: Call For Participation October 25-27, 2017 - Hilton Prague - Prague, Czech Republic (All submissions must be received before midnight June 15, 2017) =

Re: [libvirt] [PATCHv3 1/6] conf: add to

On 27/04/2017 16:07, Ján Tomko wrote: > And if apic:qemu,ioapic:qemu is only for debugging, the element > can be dropped too. > > 'ioapic' is also more specific (so if kernel-irqchip starts to be useful > on other archs, libvirt might need a new element?). Yeah, using architecture-specific

Re: [libvirt] [PATCHv3 1/6] conf: add to

On 26/04/2017 11:36, Peter Xu wrote: >> Possible values are off, split or on. > Hi, Ján, > > Thanks you for cced me. One tiny comment on irqchip mode... > > Here could user specify irqchip=off from libvirt side? IIUC that might > be dangerous since userspace APIC should only be for debugging

Re: [libvirt] [PATCH REPOST v2 0/3] Add callback mech for qemu and nodedev

On 22/02/2017 15:11, Daniel P. Berrange wrote: > On Wed, Feb 22, 2017 at 03:10:00PM +0100, Paolo Bonzini wrote: >> >> >> On 22/02/2017 14:46, Daniel P. Berrange wrote: >>> On Wed, Feb 22, 2017 at 02:38:32PM +0100, Paolo Bonzini wrote: >>>> >>>&

Re: [libvirt] [PATCH REPOST v2 0/3] Add callback mech for qemu and nodedev

On 22/02/2017 14:46, Daniel P. Berrange wrote: > On Wed, Feb 22, 2017 at 02:38:32PM +0100, Paolo Bonzini wrote: >> >> >> On 22/02/2017 11:05, Daniel P. Berrange wrote: >>> I'd also suggest just assigning the whole vHBA >> >> What do you mean by "

Re: [libvirt] [PATCH REPOST v2 0/3] Add callback mech for qemu and nodedev

On 22/02/2017 11:05, Daniel P. Berrange wrote: > I'd also suggest just assigning the whole vHBA What do you mean by "assigning the whole vHBA"? There is no concept of a vHBA as e.g. a PCI virtual function. > , but We can still make > it possible for a mgmt app to dynamically add/remove LUNS

Re: [libvirt] [PATCH] char: drop data written to a disconnected pty

On 31/01/2017 14:45, Ed Swierk wrote: > When a serial port writes data to a pty that's disconnected, drop the > data and return the length dropped. This avoids triggering pointless > retries in callers like the 16550A serial_xmit(), and causes > qemu_chr_fe_write() to write all data to the log

Re: [libvirt] [PATCH] char: drop data written to a disconnected pty

On 31/01/2017 14:19, Ed Swierk wrote: > Either way, when a pty is disconnected data will get dropped, whether > by the pty backend (as proposed) or by the serial port device or other > frontend (as currently). > > The only difference from a user's perspective is whether the dropped > data gets

Re: [libvirt] char: Logging serial pty output when disconnected

On 31/01/2017 04:39, Daniel P. Berrange wrote: > On Mon, Jan 30, 2017 at 08:58:25PM -0800, Ed Swierk wrote: >> On Fri, Jan 27, 2017 at 1:40 AM, Daniel P. Berrange >> wrote: >>> On Thu, Jan 26, 2017 at 05:07:16PM -0800, Ed Swierk wrote: Currently qemu_chr_fe_write()

Re: [libvirt] Exporting kvm_max_guest_tsc_khz to userspace (was Re: [PATCH 4/4] kvm: Allow migration with invtsc)

On 11/01/2017 14:26, Eduardo Habkost wrote: > On Mon, Jan 09, 2017 at 03:58:11PM +0100, Paolo Bonzini wrote: >> >> >> On 08/01/2017 21:28, Eduardo Habkost wrote: >>>> Well just export KVM_GET_TSC_KHZ in a QMP command right? Its pretty >>>> easy. >

Re: [libvirt] TSC frequency configuration & invtsc migration (was Re: [PATCH 4/4] kvm: Allow migration with invtsc)

On 05/01/2017 14:00, Daniel P. Berrange wrote: >> If you do this unconditionally, you have another problem: if >> tsc-frequency is set explicitly, migration is only possible if >> TSC frequency of the destination matches[1], or if TSC scaling is >> supported by the destination. It's a good idea

Re: [libvirt] TSC frequency configuration & invtsc migration (was Re: [PATCH 4/4] kvm: Allow migration with invtsc)

On 05/01/2017 11:48, Marcelo Tosatti wrote: >> Host A has TSC scaling, host B doesn't have TSC scaling. We want >> to be able to start the VM on host A, and migrate to B. In this >> case, the only possible solution is to use B's frequency when >> starting the VM. The QEMU process doesn't have

Re: [libvirt] Exporting kvm_max_guest_tsc_khz to userspace (was Re: [PATCH 4/4] kvm: Allow migration with invtsc)

On 08/01/2017 21:28, Eduardo Habkost wrote: >> Well just export KVM_GET_TSC_KHZ in a QMP command right? Its pretty >> easy. >> >> Let me know if you need any help coding or testing. > I just found out that KVM doesn't provide something that QEMU and > libvirt need: the value of

Re: [libvirt] [Qemu-devel] [PATCH v4 01/11] tests: Add test case for x86 feature parsing compatibility

On 30/09/2016 20:33, Eduardo Habkost wrote: > On Fri, Sep 30, 2016 at 09:55:33AM +0200, Paolo Bonzini wrote: >> >> >> On 29/09/2016 23:14, Eduardo Habkost wrote: >>> + * "-foo" overrides "+foo" >>> + * "[+-]foo" overr

Re: [libvirt] [PATCH v4 11/11] target-i386: Return runnability information on query-cpu-definitions

On 29/09/2016 23:14, Eduardo Habkost wrote: > +/* Return the feature property name for a feature flag bit */ > +static const char *x86_cpu_feature_name(FeatureWord w, int bitnr) > +{ > +/* XSAVE components are automatically enabled by other features, > + * so return the original feature

Re: [libvirt] [PATCH v4 09/11] target-i386: x86_cpu_load_features() function

On 29/09/2016 23:14, Eduardo Habkost wrote: > +/* Load CPUID data based on configureured features > + */ Typo ("configureured") and also unnecessarily breaking the comment on two lines. Paolo > +static void x86_cpu_load_features(X86CPU *cpu, Error **errp) -- libvir-list mailing list

Re: [libvirt] [PATCH v4 01/11] tests: Add test case for x86 feature parsing compatibility

On 29/09/2016 23:14, Eduardo Habkost wrote: > + * "-foo" overrides "+foo" > + * "[+-]foo" overrides "foo=..." Is this something that people are actually using? Can we detect it and deprecate it in 2.8, and drop it in 2.9? Paolo > + * "foo_bar" should be translated to "foo-bar"

Re: [libvirt] [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration

On 20/09/2016 17:14, Daniel P. Berrange wrote: > Any VM which > uses the separate namespace is tainted, which means if theres a bug > report we'll require the reported to remove whatever config caused > the tainting and then reproduce the problem. > > If the vendor specific mdev parameters are

Re: [libvirt] [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration

On 20/09/2016 16:58, Daniel P. Berrange wrote: > > > As I've said in my earlier reply - libvirt will *NOT* support passing > > > arbitrary vendor specific parameters as a blob via the XML. Everything > > > that appears in the XML must be *fully* specified and explicitly > > > represented in the

Re: [libvirt] [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration

On 20/09/2016 16:41, Daniel P. Berrange wrote: > As I've said in my earlier reply - libvirt will *NOT* support passing > arbitrary vendor specific parameters as a blob via the XML. Everything > that appears in the XML must be *fully* specified and explicitly > represented in the XML as a

Re: [libvirt] [RFC v2] libvirt vGPU QEMU integration

On 19/09/2016 23:36, Alex Williamson wrote: > On Tue, 20 Sep 2016 02:05:52 +0530 > Kirti Wankhede wrote: >> 'fb_length': >> Read-only file. Mandatory. >> Returns {K,M,G}, size of framebuffer. > > This can't be mandatory, it's only relevant to vGPU devices, vGPUs

Re: [libvirt] [Qemu-devel] qapi DEVICE_DELETED event issued *before* instance_finalize?!

On 06/09/2016 16:02, Laine Stump wrote: >>> >> It seems like this is just pointing out another flaw in the semantics >> of DEVICE_DELETED, a device can linger without a device id, so there's >> no way to reference it via QMP. > > Ah, right. I hadn't caught that. Yeah, since it's the device id

Re: [libvirt] [Qemu-devel] qapi DEVICE_DELETED event issued *before* instance_finalize?!

On 06/09/2016 04:18, Alex Williamson wrote: > On Mon, 5 Sep 2016 11:36:55 +0200 > Paolo Bonzini <pbonz...@redhat.com> wrote: >> DEVICE_DELETED does have a meaning: management cannot talk to the device >> anymore in QMP once it is raised. > > It seems like this is

Re: [libvirt] [Qemu-devel] qapi DEVICE_DELETED event issued *before* instance_finalize?!

On 05/09/2016 11:23, Markus Armbruster wrote: >> > >> > On the other hand, it is clearly documented that the DEVICE_DELETED >> > event is sent as soon as guest acknowledges completion of device >> > removal. So libvirt's buggy if we'd follow documentation strictly. But >> > then again, I don't

Re: [libvirt] [Qemu-devel] [PATCH v7 0/4] Add Mediated device support

On 03/09/2016 13:57, John Ferlan wrote: After creating the vGPU, if required by the host driver, all the other type ids would disappear from "virsh nodedev-dumpxml pci__86_00_0" too. >>> >>> Not wanting to make assumptions, but this reads as if I create one type >>> 11 vGPU, then I

Re: [libvirt] [Qemu-devel] [PATCH v7 0/4] Add Mediated device support

On 03/09/2016 01:57, Laine Stump wrote: >> >> mdevs do not exist on the host (they do not have a driver on the host >> because they are not PCI devices) so they do need any management. At >> least I hope that's good news. :) > > What's your definition of "management"? They don't need the same

Re: [libvirt] [Qemu-devel] [PATCH v7 0/4] Add Mediated device support

On 03/09/2016 13:56, John Ferlan wrote: > On 09/02/2016 05:48 PM, Paolo Bonzini wrote: >> On 02/09/2016 20:33, Kirti Wankhede wrote: >>> We could even do: >>>>> >>>>> echo $UUID1:$GROUPA > create >>>>> >>>>> w

Re: [libvirt] [Qemu-devel] [PATCH v7 0/4] Add Mediated device support

On 02/09/2016 20:33, Kirti Wankhede wrote: > We could even do: >> > >> > echo $UUID1:$GROUPA > create >> > >> > where $GROUPA is the group ID of a previously created mdev device into >> > which $UUID1 is to be created and added to the same group. > >From the point of view of libvirt, I think

Re: [libvirt] [Qemu-devel] [PATCH v7 0/4] Add Mediated device support

On 02/09/2016 22:19, John Ferlan wrote: > We don't have such a pool for GPU's (yet) - although I suppose they > could just become a class of storage pools. > > The issue being nodedev device objects are not saved between reboots. > They are generated on the fly. Hence the "create-nodedev' API -

Re: [libvirt] [Qemu-devel] [PATCH v7 0/4] Add Mediated device support

On 02/09/2016 19:15, Kirti Wankhede wrote: > On 9/2/2016 3:35 PM, Paolo Bonzini wrote: >> >> my-vgpu >> pci__86_00_0 >> >> >>0695d332-7831-493f-9e71-1c85c8911a08 >> >> >> >> After c

Re: [libvirt] [Qemu-devel] [PATCH v7 0/4] Add Mediated device support

On 02/09/2016 07:21, Kirti Wankhede wrote: > On 9/2/2016 10:18 AM, Michal Privoznik wrote: > > Okay, maybe I'm misunderstanding something. I just thought that users > > will consult libvirt's nodedev driver (e.g. virsh nodedev-list && virsh > > nodedev-dumpxml $id) to fetch vGPU capabilities and

Re: [libvirt] RFC: Qemu/SeaBIOS/VGA/PXE upgrades vs. longterm-snapshot/migration

On 29/08/2016 08:57, Philipp Hahn wrote: > Hello, > > If my understanding of migration/snapshots is correct, the > target/loading VM must be a clone of the source/saving VM, that is have > the same devices, RAM/PCI layout, etc. In the past I have had several > issues with Qemu, when the

Re: [libvirt] [PATCH 0/2] qemu: use -display none instead of -nographic

On 07/07/2016 11:59, Michal Privoznik wrote: > BTW: there are lots of '-nographic' in our > tests/qemuxml2argvdata/qemuxml2argv-*.args files, do we want to update > those to have '-display none' instead? Possibly, but to do that you'd have to add the capability to all the tests. It would be

Re: [libvirt] [PATCH 2/2] qemu: generate -display none

On 05/07/2016 14:59, Daniel P. Berrange wrote: > > if (!def->ngraphics) { > > -virCommandAddArg(cmd, "-nographic"); > > +if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DISPLAY)) { > > +virCommandAddArg(cmd, "-display"); > > +virCommandAddArg(cmd, "none"); > >

[libvirt] [PATCH 1/2] qemu: detect -display

Add a new capability for the -display command line option, which has been present since QEMU 1.0. Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> --- src/qemu/qemu_capabilities.c| 4 src/qemu/qemu_capabilities.h| 1 +

[libvirt] [PATCH 0/2] qemu: use -display none instead of -nographic

-display none is preferrable to -nographic which (in addition to disabling graphics output) redirects the serial port to stdio and on OpenBIOS enables the firmware's serial console. Paolo Bonzini (2): qemu: detect -display qemu: generate -display none src/qemu/qemu_capabilities.c

[libvirt] [PATCH 2/2] qemu: generate -display none

This is preferrable to -nographic which (in addition to disabling graphics output) redirects the serial port to stdio and on OpenBIOS enables the firmware's serial console. Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> --- src/qemu/qemu_command.c| 7

Re: [libvirt] [PATCH v2 3/3] KVM: VMX: enable guest access to LMCE related MSRs

On 20/06/2016 03:49, Haozhong Zhang wrote: > Thanks for the explanation! > > If we disable LMCE in QEMU by default (even for -cpu host), will it > still be a problem? That is, > > - pc-2.7 can continue to run on old kernels unless users explicitly > require LMCE > > - existing libvirt VM

Re: [libvirt] [edk2] KVM Forum 2016: Call For Participation

On 10/03/2016 19:09, Paolo Bonzini wrote: > === > IMPORTANT DATES > === > Notification: May 27, 2015 On behalf of the program committee, I apologize for the delay in sending out the notifications. If you need to know in advance whether your talk has b

Re: [libvirt] RFC: virtio-rng and /dev/urandom

> Also, I do not believe /dev/urandom is FIPS compliant. Finally, the refill > policy is different, so it is not really true the algorithm is the same. > > All in all, other than a seed value it really doesn't make any sense. Of > course, none of this matters on newer Intel hardware ;) Right,

[libvirt] KVM Forum 2016: Call For Participation

= KVM Forum 2016: Call For Participation August 24-26, 2016 - Westin Harbor Castle - Toronto, Canada (All submissions must be received before midnight May 1, 2016) =

Re: [libvirt] [PATCH] qemu: add support for LSI SAS1068 (aka MPT Fusion) SCSI controller

- Original Message - > From: "John Ferlan" <jfer...@redhat.com> > To: "Paolo Bonzini" <pbonz...@redhat.com>, libvir-list@redhat.com > Sent: Monday, February 22, 2016 3:00:19 PM > Subject: Re: [libvirt] [PATCH] qemu: add support for LSI

Re: [libvirt] [PATCH] qemu: add support for LSI SAS1068 (aka MPT Fusion) SCSI controller

On 11/02/2016 11:48, Paolo Bonzini wrote: > This does nothing more than adding the new device and capability. > The device is present since QEMU 2.6.0. > > Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> > --- > src/qemu/qemu_capabilities.c

[libvirt] [PATCH] qemu: add support for LSI SAS1068 (aka MPT Fusion) SCSI controller

This does nothing more than adding the new device and capability. The device is present since QEMU 2.6.0. Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> --- src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + sr

Re: [libvirt] high outage times for qemu virtio network links during live migration, trying to debug

On 26/01/2016 17:41, Chris Friesen wrote: > I'm using libvirt (1.2.12) with qemu (2.2.0) in the context of OpenStack. > > If I live-migrate a guest with virtio network interfaces, I see a > ~1200msec delay in processing the network packets, and several hundred > of them get dropped. I get the

Re: [libvirt] high outage times for qemu virtio network links during live migration, trying to debug

On 26/01/2016 18:21, Chris Friesen wrote: >>> >>> My question is, why doesn't qemu continue processing virtio packets >>> while the dirty page scanning and memory transfer over the network is >>> proceeding? >> >> QEMU (or vhost) _are_ processing virtio traffic, because otherwise you'd >> have

Re: [libvirt] high outage times for qemu virtio network links during live migration, trying to debug

On 26/01/2016 18:49, Chris Friesen wrote: >> >> That doesn't exclude a bug somewhere in net/ code. It doesn't pinpoint >> it to QEMU or vhost-net. >> >> In any case, what I would do is to use tracing at all levels (guest >> kernel, QEMU, host kernel) for packet rx and tx, and find out at which

Re: [libvirt] FD passing for chardevs and chardev backend multiplexing

On 09/12/2015 12:19, Daniel P. Berrange wrote: > > > Now in practice this doesn't work, because qmp_chardev_open_file() > > > passes the O_CREAT|O_TRUNC flags in, which means the qemu_open() > > > call will fail when using the pipe FD pased in via fdsets. > > > > Is it just the O_TRUNC that is

Re: [libvirt] [QEMU PATCH] target-i386: Disable rdtscp on Opteron_G* CPU models

On 13/11/2015 20:07, Eduardo Habkost wrote: > KVM can't virtualize rdtscp on AMD CPUs yet, so there's no point > in enabling it by default on AMD CPU models, as all we are > getting are confused users because of the "host doesn't support > requested feature" warnings. > > Disable rdtscp on

Re: [libvirt] [PATCH 1/2] conf: add crash to hyperv features

On 11/11/2015 10:09, Denis V. Lunev wrote: > QEMU accepts this option through HyperV set of CPU options. > Thus your proposal means that in this case we will have to add > this option to CPU part of the command line from devices > part. > > Is this correct? > > And, finally, 'no', this is not

Re: [libvirt] [PATCH v2 17/17] qemu: assume various QEMU 0.10 features are always available

On 10/11/2015 00:28, John Ferlan wrote: >} else if (STRPREFIX(arg, "-hd") || >STRPREFIX(arg, "-sd") || >STRPREFIX(arg, "-fd") || >STREQ(arg, "-cdrom")) { > WANT_VALUE(); -sd is for sdcards, not SCSI, so it should be

Re: [libvirt] [PATCH 1/2] conf: add crash to hyperv features

On 05/11/2015 14:54, Dmitry Andreev wrote: >> >>> Add crash CPU feature for Hyper-V. Hyper-V crash MSR's can be used >>> by Hyper-V based guests to notify about occurred guest crash. >>> >>> XML: >>> >>> >>> >>> >>> >> Sounds like this is related to an existing panic device we

Re: [libvirt] CharUDP - Connection refused

On 04/10/2015 17:01, poma wrote: > > qemu-system-x86_64 ... \ > -chardev > udp,id=charserial0,host=127.0.0.1,port=4555,localaddr=127.0.0.1,localport=4556 > \ > -device isa-serial,chardev=charserial0,id=serial0 > > > # netstat -an | grep 4555 > udp0 0 127.0.0.1:4556

Re: [libvirt] [PATCH] target-i386: Enable "check" mode by default

On 26/08/2015 18:50, Eduardo Habkost wrote: > Current default behavior of QEMU is to silently disable features that > are not supported by the host when a CPU model is requested in the > command-line. This means that in addition to risking breaking guest ABI > by default, we are silent about it.

Re: [libvirt] [PATCH V3 2/3] virtio-blk: fail get_features when both scsi and 1.0 were set

On 22/07/2015 13:46, Daniel P. Berrange wrote: IIUC, the SCSI passthrough feature for virtio-blk is enabled by setting the 'scsi=on' property on the virtio-blk device, which is exposed by libvirt with XML: disk type='block' device='lun' driver name='qemu' type='raw'/

Re: [libvirt] KVM Forum 2015 Call for Participation

A friendly reminder that KVM Forum 2015 accepts proposal submissions until next Friday. Thanks on behalf of the KVM Forum 2015 Program Committee. Paolo On 11/03/2015 18:53, Paolo Bonzini wrote: = KVM Forum 2015: Call

[libvirt] Changing media on network disks (was Re: can't bot from scsi http cdrom)

On 13/04/2015 14:34, Vasiliy Tolstov wrote: Thanks! This is works fine. Last question - does it possible to create empty cdrom with type='network'? I'm try this, but libvrit complains with error: disk type='network' device='cdrom' driver name='qemu' type='raw'/

Re: [libvirt] [PATCH v4 4/4] migration: Expose 'cancelling' status to user

On 09/03/2015 07:45, zhanghailiang wrote: 'cancelling' status was introduced by commit 51cf4c1a, mainly to avoid a possible start of a new migration process while the previous one still exists. But we didn't expose this status to user, instead we returned the 'active' state. Here, we

[libvirt] KVM Forum 2015 Call for Participation

= KVM Forum 2015: Call For Participation August 19-21, 2015 - Sheraton Seattle - Seattle, WA (All submissions must be received before midnight May 1, 2015) = KVM is an

Re: [libvirt] [PATCH] qemu: Drop OVMF whitelist

On 19/11/2014 18:20, Michal Privoznik wrote: As discussed on the upstream list, it's better not to make this kind of predictions in libvirt. It may happen that qemu learns how to enable OVMF on other architectures too and we shouldn't try to chase that. Signed-off-by: Michal Privoznik

Re: [libvirt] [PATCH] qemu: Use AAVMF as UEFI default on ARMs

On 01/12/2014 16:44, Cole Robinson wrote: -#define VIR_QEMU_LOADER_FILE_PATH /usr/share/OVMF/OVMF_CODE.fd -#define VIR_QEMU_NVRAM_FILE_PATH /usr/share/OVMF/OVMF_VARS.fd +#if defined(__arm__) || defined(__aarch64__) +# define VIR_QEMU_LOADER_FILE_PATH /usr/share/AAVMF/AAVMF_CODE.fd +#

Re: [libvirt] NBD TLS support in QEMU

Il 08/10/2014 20:16, Wouter Verhelst ha scritto: @@ -242,10 +242,13 @@ Option types * NBD_OPT_EXPORT_NAME (1) Choose the export which the client would like to use, and end option haggling. Data: name of the export, free-form UTF8 text (subject to limitations by server

Re: [libvirt] [PATCH v4] Add machine parameter qemu-kvm-migration for live migrate compatibility with qemu-kvm

Il 29/09/2014 09:02, Markus Armbruster ha scritto: If you were just objecting to the fact that pc-1.0 was made to be an alias of either one or the other at compile time, simply drop the second patch of the v2 patchset. I was objecting to making pc-1.0 special. There's nothing special in

Re: [libvirt] [Qemu-devel] [PATCH v4] Add machine parameter qemu-kvm-migration for live migrate compatibility with qemu-kvm

If you were just objecting to the fact that pc-1.0 was made to be an alias of either one or the other at compile time, simply drop the second patch of the v2 patchset. I was objecting to making pc-1.0 special. There's nothing special in pc-1.0, other machine types also had

Re: [libvirt] [PATCH v4] Add machine parameter qemu-kvm-migration for live migrate compatibility with qemu-kvm

Il 05/10/2014 14:48, Michael S. Tsirkin ha scritto: In fact, if the pc_piix bits are dropped from the patch, you get a generic patchset that does exactly what you ask, correct? Downstream can then enable qemu-kvm compatibility by adding: -global cirrus-vga.vgamem_mb=16 -global

Re: [libvirt] NBD TLS support in QEMU

Il 01/10/2014 22:23, Wouter Verhelst ha scritto: Hi, On Fri, Sep 05, 2014 at 03:26:09PM +0200, Wouter Verhelst wrote: Tunneling the entire protocol inside an SSL connection doesn't fix that; if an attacker is able to hijack your TCP connections and change flags, then this attacker is also

Re: [libvirt] NBD TLS support in QEMU

Il 02/10/2014 13:05, Daniel P. Berrange ha scritto: On Wed, Oct 01, 2014 at 10:23:26PM +0200, Wouter Verhelst wrote: Hi, On Fri, Sep 05, 2014 at 03:26:09PM +0200, Wouter Verhelst wrote: Tunneling the entire protocol inside an SSL connection doesn't fix that; if an attacker is able to hijack

Re: [libvirt] [Qemu-devel] [PATCH v3 2/2] Add configure option --enable-pc-1-0-qemu-kvm

Il 22/09/2014 17:24, Markus Armbruster ha scritto: You're right. However, this particular horse left the barn a long time ago: the pc-* machine types differ in qemu-kvm and upstream QEMU. Sure, when qemu-kvm was merged back into QEMU, its machine type variants were dropped. But they live

Re: [libvirt] [PATCH v1 3/3] qemu: Automatically create NVRAM store

Il 08/08/2014 12:17, Michal Privoznik ha scritto: When using split UEFI image, it may come handy if libvirt manages per domain _VARS file automatically. While the _CODE file is RO and can be shared among multiple domains, you certainly don't want to do that on the _VARS file. This latter one

Re: [libvirt] [PATCH v1 2/3] qemu: Implement extended loader and nvram

Il 08/08/2014 12:17, Michal Privoznik ha scritto: +if (loader-nvram) { +virBufferFreeAndReset(buf); +virBufferAsprintf(buf, + file=%s,if=pflash,format=raw,unit=1, + loader-nvram); + +

Re: [libvirt] [PATCH v1 2/3] qemu: Implement extended loader and nvram

Il 08/08/2014 14:26, Michal Privoznik ha scritto: Note that other machines may not need unit=1, for example pseries doesn't need it (it uses -bios for the firmware, not -drive if=pflash). It would be nice to make this easily configurable. Is there a table anywhere where I can see what

Re: [libvirt] [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm

Il 29/07/2014 15:03, Serge E. Hallyn ha scritto: And from there I think the thing to do will be to introduce a transient alternate package that has the pc-1.0 alias pointing ot pc-1.0-qemu-kvm This should be done in the main package, too. and depends on the legacy pxe rom. If you can make

Re: [libvirt] [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm

Il 29/07/2014 15:27, Serge Hallyn ha scritto: Quoting Paolo Bonzini (pbonz...@redhat.com): Il 29/07/2014 15:03, Serge E. Hallyn ha scritto: And from there I think the thing to do will be to introduce a transient alternate package that has the pc-1.0 alias pointing ot pc-1.0-qemu-kvm

Re: [libvirt] [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm

Il 29/07/2014 15:39, Alex Bligh ha scritto: I'm not sure either. You could simply package the 12.04 ipxe ROMs into 14.04, and add a note about getting the sources for GPL friendliness. This would be my preference (or in Ubuntu's case, add it to the ipxe-qemu package) but I think it should

Re: [libvirt] [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm

Il 29/07/2014 15:56, Alex Bligh ha scritto: On 29 Jul 2014, at 14:42, Paolo Bonzini pbonz...@redhat.com wrote: Il 29/07/2014 15:39, Alex Bligh ha scritto: I'm not sure either. You could simply package the 12.04 ipxe ROMs into 14.04, and add a note about getting the sources for GPL

Re: [libvirt] [PATCH 1/2] qemu: add vhost-scsi-pci definitions

Il 24/07/2014 05:24, Nicholas A. Bellinger ha scritto: From: Mike Perez thin...@gmail.com This patch adds the necessary definitions to support vhost-scsi-pci and VIR_DOMAIN_CONTROLLER_MODEL_SCSI_VHOST_SCSI in QEMU = v1.5.x code. This includes: - Add QEMU_CAPS_VHOST_SCSI - Add

Re: [libvirt] KVM Forum 2014 Call for Participation (reminder)

The deadline is coming in three days! Paolo Il 16/06/2014 18:08, Paolo Bonzini ha scritto: = KVM Forum 2014: Call For Participation October 14-16, 2014 - Congress Centre Düsseldorf - Düsseldorf, Germany (All submissions must

Re: [libvirt] OVMF exposure in libvirt

Il 18/07/2014 15:01, Michal Privoznik ha scritto: On 14.07.2014 16:12, Paolo Bonzini wrote: Il 14/07/2014 11:27, Daniel P. Berrange ha scritto: -drive file=img_1,if=pflash,format=raw,readonly \ -drive file=img_2,if=pflash,format=raw It's safer to add ,unit=0 and ,unit=1 too. We

Re: [libvirt] OVMF exposure in libvirt

Il 14/07/2014 11:27, Daniel P. Berrange ha scritto: -drive file=img_1,if=pflash,format=raw,readonly \ -drive file=img_2,if=pflash,format=raw It's safer to add ,unit=0 and ,unit=1 too. We already use loader/ for specifying alternative BIOS blobs for the QEMU -bios arg. Since you

Re: [libvirt] OVMF exposure in libvirt

Il 14/07/2014 16:43, Daniel P. Berrange ha scritto: -drive file=img_1,if=pflash,format=raw,readonly \ -drive file=img_2,if=pflash,format=raw It's safer to add ,unit=0 and ,unit=1 too. Is there any compelling reason to make the unit numbers user configurable. Are they guest ABI

Re: [libvirt] [Qemu-devel] [PATCH v4 04/29] NUMA: convert -numa option to use OptsVisitor

Il 16/06/2014 16:08, Eduardo Habkost ha scritto: Is there some capability probing mechanism that can be used by management to detect the new feature? No, there isn't. Paolo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Qemu-devel] [PATCH v4 04/29] NUMA: convert -numa option to use OptsVisitor

Il 16/06/2014 16:23, Eric Blake ha scritto: On 06/16/2014 08:16 AM, Paolo Bonzini wrote: Il 16/06/2014 16:08, Eduardo Habkost ha scritto: Is there some capability probing mechanism that can be used by management to detect the new feature? No, there isn't. Not even query-command-line

Re: [libvirt] [Qemu-devel] [PATCH v4 04/29] NUMA: convert -numa option to use OptsVisitor

Il 16/06/2014 17:39, Eduardo Habkost ha scritto: No, this is a (backwards-compatible) extension to how the option is parsed. But numa started appearing on query-command-line-options only after this patch got applied. It is not the semantics I would expect from query-command-line-options, but

[libvirt] KVM Forum 2014 Call for Participation

= KVM Forum 2014: Call For Participation October 14-16, 2014 - Congress Centre Düsseldorf - Düsseldorf, Germany (All submissions must be received before midnight July 27, 2014)

Re: [libvirt] [Qemu-devel] [PATCHv2 3/4] qemu: fix RTC_CHANGE event for clock offset='variable' basis='utc'/

Il 23/05/2014 15:35, Markus Armbruster ha scritto: Luiz Capitulino lcapitul...@redhat.com writes: On Fri, 23 May 2014 00:50:38 -0300 Marcelo Tosatti mtosa...@redhat.com wrote: Then the guest triggers an RTC update, so qemu sends an event, but the event is lost. Then libvirtd starts again,

Re: [libvirt] Configure virtio-scsi options via libvirt

Il 08/05/2014 09:24, Mike Perez ha scritto: On 10:08 Wed 07 May , Stefan Hajnoczi wrote: On Tue, May 06, 2014 at 04:13:50PM -0700, Mike Perez wrote: I would like be able to configure virtio-scsi options num_queues, max_sectors, and cmd_per_lun via libvirt. Are there any plans to have this

Re: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing

Il 02/05/2014 16:43, Eduardo Habkost ha scritto: The first thing I considered was making icc-bus user-creatable. Then I noticed it wouldn't work because object-add always add objects to /objects, not inside the qdev hierarchy (that's where device_add looks for the bus). So, allowing device_add

Re: [libvirt] [RFC PATCH v2 3/3] qemu: memory pre-pinning support for RDMA migration

Il 04/04/2014 22:46, Eric Blake ha scritto: I'm still not seeing what's wrong with depending on the version number since other features are also depending on the version number. Every feature where we have to guess based on version number is due to a bug in qemu for not providing enough

Re: [libvirt] [PATCH] add flag to enforce hugepage backing of guest RAM

Il 09/04/2014 17:12, Daniel P. Berrange ha scritto: On Tue, Apr 08, 2014 at 03:06:13PM -0300, Marcelo Tosatti wrote: On Mon, Mar 17, 2014 at 09:39:54AM +, Daniel P. Berrange wrote: We recently had a bunch more feature requests around huge page support in libvirt, so I think it is

Re: [libvirt] [PATCH] migration: Fix possible bug for migrate cancel

Il 28/03/2014 10:18, Gonglei (Arei) ha scritto: Can you please give more details at how you are triggering the problem with libvirt? I think Paolo is probably right - the bug is more likely to be in libvirt not expecting the race and not recovering correctly when the race occurs, than

Re: [libvirt] [Qemu-devel] [PATCH] migration: Fix possible bug for migrate cancel

Il 28/03/2014 12:30, Dr. David Alan Gilbert ha scritto: Another reason for doing it in libvirt is that the serialization between cancellation and completion of migration ultimately is controlled by libvirt's lock. Doing this in QEMU makes it harder to reason about concurrency. I think you

Re: [libvirt] [PATCH 0/3] ABI change: change group name of option table to match with option name

Il 27/03/2014 03:38, Amos Kong ha scritto: This patchset changes group names of option tables to match with option name, this breakes ABI, release note was updated. Amos Kong (3): only add qemu_tpmdev_opts when CONFIG_TPM is defined abort QEMU if group name in option table doesn't match

<    1   2   3   4   5   6   7   8   >