search for: noforc

Displaying 9 results from an estimated 9 matches for "noforc".

Did you mean: nofork
2020 May 14
1
[virtio-dev] [PATCH v3 00/15] virtio-mem: paravirtualized memory
...-device ide-hd,drive=hd \ -drive if=none,id=hd,file=/home/dhildenb/git/Fedora-Cloud-Base-32-1.6.x86_64.qcow2,format=qcow2 \ -m 5g,slots=10,maxmem=6G \ -smp 1 \ -s \ -kernel /home/dhildenb/git/linux/arch/x86/boot/bzImage \ -append "console=ttyS0 rd.shell nokaslr swiotlb=noforce" \ -monitor unix:/var/tmp/monitor,server,nowait Observe how big the initial RAM even is! So this is no DIMM/hotplug/virtio_mem issue. With memory hotplug, it seems to get more likely to trigger if "swiotlb=noforce" is not specified. "swiotlb=noforce" seems to trig...
2020 May 14
2
[virtio-dev] [PATCH v3 00/15] virtio-mem: paravirtualized memory
On 14.05.20 12:02, teawater wrote: > > >> 2020?5?14? 16:48?David Hildenbrand <david at redhat.com> ??? >> >> On 14.05.20 08:44, teawater wrote: >>> Hi David, >>> >>> I got a kernel warning with v2 and v3. >> >> Hi Hui, >> >> thanks for playing with the latest versions. Surprisingly, I can >> reproduce even by
2020 May 14
2
[virtio-dev] [PATCH v3 00/15] virtio-mem: paravirtualized memory
On 14.05.20 12:02, teawater wrote: > > >> 2020?5?14? 16:48?David Hildenbrand <david at redhat.com> ??? >> >> On 14.05.20 08:44, teawater wrote: >>> Hi David, >>> >>> I got a kernel warning with v2 and v3. >> >> Hi Hui, >> >> thanks for playing with the latest versions. Surprisingly, I can >> reproduce even by
2023 May 19
3
[PATCH 2/4] x86: always initialize xen-swiotlb when xen-pcifront is enabling
...> Signed-off-by: Christoph Hellwig <hch at lst.de> > > Doesn't it mean all the PV guests will basically waste 64MB of RAM > by default each if they don't really have PCI devices? If CONFIG_XEN_PCIDEV_FRONTEND is enabled, and the kernel's isn't booted with swiotlb=noforce, yes.
2023 May 22
1
[PATCH 2/4] x86: always initialize xen-swiotlb when xen-pcifront is enabling
...lst.de> >>> >>> Doesn't it mean all the PV guests will basically waste 64MB of RAM >>> by default each if they don't really have PCI devices? >> >> If CONFIG_XEN_PCIDEV_FRONTEND is enabled, and the kernel's isn't booted >> with swiotlb=noforce, yes. > > That's "a bit" unfortunate, since that might be significant part of the > VM memory, or if you have a lot of VMs, a significant part of the host > memory - it quickly adds up. > While I would say PCI passthrough is not very common for PV guests, can > the...
2007 Jun 22
2
fitCopula
I am using R 2.5.0 on windows XP and trying to fit copula. I see the following code works for some users, however my code crashes on the chol. Any suggestions? > mycop <- tCopula(param=0.5, dim=8, dispstr="ex", df=5) > x <- rcopula(mycop, 1000) > myfit <- fitCopula(x, mycop, c(0.6, 10), optim.control=list(trace=1), method="Nelder-Mead")
2020 May 14
0
[virtio-dev] [PATCH v3 00/15] virtio-mem: paravirtualized memory
...4-softmmu/qemu-system-x86_64 -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu host -no-reboot -nographic -device ide-hd,drive=hd -drive if=none,id=hd,file=/home/teawater/old.img,format=raw -kernel /home/teawater/kernel/bk2/arch/x86/boot/bzImage -append "console=ttyS0 root=/dev/sda nokaslr swiotlb=noforce" -m 1g,slots=10,maxmem=2G -smp 1 -s -monitor unix:/home/teawater/qemu/m,server,nowait > > // Setup virtio-mem and plug 256m memory in qemu monitor: > object_add memory-backend-ram,id=mem1,size=256m > device_add virtio-mem-pci,id=vm0,memdev=mem1 > qom-set vm0 requested-size 256...
2020 Jun 05
3
[PATCH RFC v4 00/13] virtio-mem: paravirtualized memory
? 2020/1/9 ??9:48, David Hildenbrand ??: > Ping, > > I'd love to get some feedback on > > a) The remaining MM bits from MM folks (especially, patch #6 and #8). > b) The general virtio infrastructure (esp. uapi in patch #2) from virtio > folks. > > I'm planning to send a proper v1 (!RFC) once I have all necessary MM > acks. In the meanwhile, I will do more
2020 Jun 05
3
[PATCH RFC v4 00/13] virtio-mem: paravirtualized memory
? 2020/1/9 ??9:48, David Hildenbrand ??: > Ping, > > I'd love to get some feedback on > > a) The remaining MM bits from MM folks (especially, patch #6 and #8). > b) The general virtio infrastructure (esp. uapi in patch #2) from virtio > folks. > > I'm planning to send a proper v1 (!RFC) once I have all necessary MM > acks. In the meanwhile, I will do more