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