search for: machinetyp

Hello. I'm not able to disable the sata controller on a machine='pc-q35-2.1' type VM. Whenever i delete: <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> it gets added again when i close the editor. The reason i would

...n-migratable device '0000:00:1f.2/ich9_ahci' > > Someone has an idea to solve this? > Yep. You have described the situation perfectly. Here are my notes from libvirt commit c27b0bb171d9bdac10a93492a2a99eaa22746694, which fixed the handling of "default" devices in the Q35 machinetype: sata - a q35 machine always has a sata controller implicitly added at slot 0x1F, function 2. There is no way to avoid this controller, so we always add it. Note that the xml2xml tests for the pcie-root and q35 cases were changed to use DO_TEST_DIFFERENT() so that we can check...

...I'm seeing while migrated similar images to another host. The only way I've been able to change the machine is by first shutting down the vm, making the change, then starting the vm back up. I'd like to avoid that if at all possible. I did find the tool "libvirt-migrate-qemu-machinetype", but it doesn't seem to do what I think it's intended to do -- i.e., it does NOT change the machine type, even after reboot. Perhaps I'm just using it wrong? I performed the following: root:~# libvirt-migrate-qemu-machinetype -t pc-i440fx-1.7 <domain> Waiting up to 10...

...il I looked it up in the source. At libvirt-1.2.22/src/qemu/qemu_command.c: 4916 case VIR_DOMAIN_CONTROLLER_TYPE_IDE: 4917 /* Since we currently only support the integrated IDE controller 4918 * on 440fx, if we ever get to here, it's because some other 4919 * machinetype had an IDE controller specified, or a 440fx had 4920 * multiple ide controllers. 4921 */ 4922 if (qemuDomainMachineIsI440FX(domainDef)) 4923 virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", 4924 _("Only a single I...

...n-migratable device '0000:00:1f.2/ich9_ahci' > > Someone has an idea to solve this? > Yep. You have described the situation perfectly. Here are my notes from libvirt commit c27b0bb171d9bdac10a93492a2a99eaa22746694, which fixed the handling of "default" devices in the Q35 machinetype: sata - a q35 machine always has a sata controller implicitly added at slot 0x1F, function 2. There is no way to avoid this controller, so we always add it. Note that the xml2xml tests for the pcie-root and q35 cases were changed to use DO_TEST_DIFFERENT() so that we can check...

Hello, I noticed that if include\llvm\Support is included alongside Windows.h, there will be many define conflict leading to compilation errors, such as: COFF.h (enum): enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; and winnt.h (same but define): #define IMAGE_FILE_MACHINE_UNKNOWN 0 Of course I could try to avoid to include both (but it's rather difficult and would require lot of refactoring -- we have this clash currently in LLDB MinGW32 port). I was wonde...

Right now, we have: In COFF.h: class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; }; In windows.h: #define IMAGE_FILE_MACHINE_UNKNOWN 0 * If you first include COFF.h and then windows.h, COFF::IMAGE_FILE_MACHINE_UNKNOWN will be preprocessed into COFF:0. * If you first include Windows.h and then COFF.h, COFF.h won't...

I would really appreciate some pointers on what I am doing wrong here. I have a need to run multiple virtual guests which have each their own GPU and some USB controllers passed-through. I am able to run one of the guests like this (assuming vfio stuff has happened elsewhere), but I would prefer to use virsh: kvm -M q35 -m 8192 -cpu host,kvm=off \ -smp 4,sockets=1,cores=4,threads=1 \ -bios

...nbind any host driver and bind vfio-pci to the devices. If 02:00.0 and 02:00.1 are both in iommu group 18, but one of them isn't bound to vfio-pci, qemu will give "some kind of error" when it tries to assign any other device in the group. 2) your example qemu commandline uses the q35 machinetype, but your example libvirt domain uses pc-i440fx-utopic machinetype, so the bus structure is completely different. Assuming a recent enough libvirt, you should be able to create a virtual machine based on q35 and attach the devices to pcie-root (bus 0). You wouldn't be able to add an ioh3420 co...

...ect? On Tue, Aug 27, 2013 at 5:41 PM, Virgile Bello <virgile.bello at gmail.com>wrote: > Hello, > > I noticed that if include\llvm\Support is included alongside Windows.h, > there will be many define conflict leading to compilation errors, such as: > > COFF.h (enum): enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... > }; > > and > > winnt.h (same but define): #define IMAGE_FILE_MACHINE_UNKNOWN 0 > > Of course I could try to avoid to include both (but it's rather difficult > and would require lot of refactoring -- we have this clash current...

On Aug 28, 2013, at 7:05 PM, Virgile Bello <virgile.bello at gmail.com> wrote: > Right now, we have: > In COFF.h: > class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; }; > In windows.h: > #define IMAGE_FILE_MACHINE_UNKNOWN 0 > > * If you first include COFF.h and then windows.h, > COFF::IMAGE_FILE_MACHINE_UNKNOWN > will be preprocessed into > COFF:0. > > * If you first include...

...at 5:41 PM, Virgile Bello <virgile.bello at gmail.com>wrote: > >> Hello, >> >> I noticed that if include\llvm\Support is included alongside Windows.h, >> there will be many define conflict leading to compilation errors, such as: >> >> COFF.h (enum): enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, >> ... }; >> >> and >> >> winnt.h (same but define): #define IMAGE_FILE_MACHINE_UNKNOWN 0 >> >> Of course I could try to avoid to include both (but it's rather difficult >> and would require lot of refactori...

...rything right after including Windows.h. On Thu, Aug 29, 2013 at 11:08 AM, Nick Kledzik <kledzik at apple.com> wrote: > > On Aug 28, 2013, at 7:05 PM, Virgile Bello <virgile.bello at gmail.com> > wrote: > > Right now, we have: > In COFF.h: > class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, > ... }; }; > In windows.h: > #define IMAGE_FILE_MACHINE_UNKNOWN 0 > > * If you first include COFF.h and then windows.h, > COFF::IMAGE_FILE_MACHINE_UNKNOWN > will be preprocessed into > COFF:0. > > * If you first incl...

...bind vfio-pci to the devices. > If 02:00.0 and 02:00.1 are both in iommu group 18, but one of them isn't > bound to vfio-pci, qemu will give "some kind of error" when it tries to > assign any other device in the group. > > 2) your example qemu commandline uses the q35 machinetype, but your > example libvirt domain uses pc-i440fx-utopic machinetype, so the bus > structure is completely different. Assuming a recent enough libvirt, you > should be able to create a virtual machine based on q35 and attach the > devices to pcie-root (bus 0). You wouldn't be able...

...er including Windows.h. > > > On Thu, Aug 29, 2013 at 11:08 AM, Nick Kledzik <kledzik at apple.com> wrote: > > On Aug 28, 2013, at 7:05 PM, Virgile Bello <virgile.bello at gmail.com> wrote: >> Right now, we have: >> In COFF.h: >> class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; }; >> In windows.h: >> #define IMAGE_FILE_MACHINE_UNKNOWN 0 >> >> * If you first include COFF.h and then windows.h, >> COFF::IMAGE_FILE_MACHINE_UNKNOWN >> will be preprocessed into >> COFF:0. >&...

...;> On Thu, Aug 29, 2013 at 11:08 AM, Nick Kledzik<kledzik at apple.com> wrote: >> >> On Aug 28, 2013, at 7:05 PM, Virgile Bello<virgile.bello at gmail.com> wrote: >> >>> Right now, we have: >>> In COFF.h: >>> class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; }; >>> In windows.h: >>> #define IMAGE_FILE_MACHINE_UNKNOWN 0 >>> >>> * If you first include COFF.h and then windows.h, >>> COFF::IMAGE_FILE_MACHINE_UNKNOWN >>> will be preprocessed into &...

...the packet from passing. For (1) you'd need to run "ebtables -L; iptables -S; nft list ruleset" and look for something suspicious. For (2) can you try changing both the libreelec and the DHCP server vm's ethernet device models from virtio to e1000? (or e1000e if they are q35 machinetypes)? If that works, then change one or the other back and see if it stops working. > should I add another nic with static ip and try to trace the pkts from there? > You mean so you can ssh to the client/libreelec and run tcpdump there agains the interface that's doing dhcp? Is tcpdu...

...mp; Data == E.Data && Private == E.Private); } }; enum class DebugType { None = 0x0, CV = 0x1, /// CodeView PData = 0x2, /// Procedure Data Fixup = 0x4, /// Relocation Table }; struct Configuration { enum ManifestKind { SideBySide, Embed, No }; llvm::COFF::MachineTypes Machine = llvm::COFF::IMAGE_FILE_MACHINE_UNKNOWN; bool Verbose = false; llvm::COFF::WindowsSubsystem Subsystem = llvm::COFF::IMAGE_SUBSYSTEM_UNKNOWN; SymbolBody *Entry = nullptr; bool NoEntry = false; std::string OutputFile; bool DoGC = true; bool DoICF = true; bool Relocatable =...

On Aug 27, 2013, at 5:56 PM, Virgile Bello <virgile.bello at gmail.com> wrote: > Yes of course I understand it was done on purpose. > It's just that it makes it impossible to include COFF.h and Windows.h side by side (which probably wasn't necessary until now). I too am in the camp that it is a feature to use the standard names. For instance doing a search it google or

...t; > At libvirt-1.2.22/src/qemu/qemu_command.c: > > 4916 case VIR_DOMAIN_CONTROLLER_TYPE_IDE: > 4917 /* Since we currently only support the integrated IDE controller > 4918 * on 440fx, if we ever get to here, it's because some other > 4919 * machinetype had an IDE controller specified, or a 440fx had > 4920 * multiple ide controllers. > 4921 */ > 4922 if (qemuDomainMachineIsI440FX(domainDef)) > 4923 virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", > 4924...