On 2024-02-07 16:02, Jan Beulich wrote:
> On 04.01.2024 14:16, Jan Beulich wrote:
> > On 22.12.2023 16:49, Neowutran wrote:
> >> Full logs without my patch to set allow-memory-relocate
> >> (https://github.com/neowutran/qubes-vmm-xen/blob/allowmemoryrelocate/ALLOWMEMOR
ing qemu-xen support to stubdomain. Adjust libxl__spawn_stub_dm() to
> be consistent in this regard.
>
> Reported-by: Neowutran
> Signed-off-by: Marek Marczykowski-Górecki
> ---
> tools/libs/light/libxl_dm.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --gi
> > '''
> >
> > And the associated result is:
> >
> > (d22) NEOWUTRAN pci.c: pci_mem_end: -67108864
> > (d22) NEOWUTRAN pci.c: pci_mem_start: -268435456
> > (d22) NEOWUTRAN pci.c: allow_memory_relocate: 0
> > (d22) NEOWUTRAN pci.
On 2023-12-19 17:12, Jan Beulich wrote:
> On 16.12.2023 08:01, Neowutran wrote:
> > I am wondering if the variable "allow_memory_relocate" is still
> > relevant today and if its default value is still relevant.
> > Should it be defined to 0 by default instead of 1 (
st memory can
be trashed by the hvmloader.
Due to this issue, it is impossible to passthrough a large PCI device to a HVM
with a lot of ram.
(https://github.com/QubesOS/qubes-issues/issues/4321).
(Forcing "allow_memory_relocate" to be 0 seems to solve the issue
linked)
Thanks,
Neowutran
��
ow_memory_relocate" have been
defined to 1 for qemu-traditional support. As of today, should this default
value still be "1" ?
- Does something have changed regarding "At the moment qemu-xen can't deal with
relocated memory regions." ? / something else should be modified ?
Many thanks,
Neowutran
��
c...@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To:
Hello,
Thanks a lot for all the details and explainations ! :)
On 2023-11-27 11:11, Andrew Cooper wrote:
> On 24/11/2023 7:54 pm, Neo
Content-D��
isposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <81f6bbd5-0487-461a-af1a-dbb6ead47...@citrix.com>
On 2023-11-18 11:11, Andrew Cooper wrote:
> On 18/11/2023 3:04 am, Elliott Mitchell wrote:
> > On Fri, Nov 17, 2023 at 11:12:37AM +0100, Neowutran wrote:
e cluster mode on an
> > > x2APIC where that mode was broken for physical interrupts?
> >
> > No, not realy, x2apic_phys was already forced to true if
> > acpi_gbl_FADT.flags & ACPI_FADT_APIC_PHYSICAL is set on the FADT (I
> > just delete that line in this same chunk and
> > >> I was taking a look at the BIOS manual for this motherboard and noticed
> > >> a mention of a "Local APIC Mode" setting. Four values are listed
> > >> "Compatibility", "xAPIC", "x2APIC", and "Auto".
>
> This does appear to be an improvement. With this the system boots if
> the
On 2022-12-19 09:12, Jan Beulich wrote:
> On 18.12.2022 22:47, Elliott Mitchell wrote:
> > On Sun, Dec 18, 2022 at 01:14:07PM +0100, Neowutran wrote:
> >> xen/x86: prevent overflow with high frequency TSCs
> >>
> >> PrÀ
omote tsc_khz to a 64-bit type b
correctly.
Signed-off-by: Neowutran
---
Changed since v1:
* smaller commit message
* using uint64_t instead of u64
* added signed-off-by tag
---
xen/arch/x86/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index b01acd390d..
xen/arch/x86/time.c: Bug fix - Integer overflow when cpu frequency > u32 max
value.
What is was trying to do: I was trying to install QubesOS on my new computer
(AMD zen4 processor). Guest VM were unusably slow / unusable.
What is the issue: The cpu frequency reported is wrong for linux guest in
13 matches
Mail list logo
