progetto linux per game con kvm
-
- Messaggi: 809
- Iscritto il: martedì 10 gennaio 2012, 4:48
Re: progetto linux per game con kvm
Mi so spiegato male , io intendevo più o meno virtualizzato per i giochi non nativi .
Cmq con l'ultima news che ho postato splitteranno la vga in maniera che linux che ne veda una e dar alla macchina virtuale quella virtuale appunto , ora bisgona capire come funziona e cosa si possa fare , perchè suppongo che non si potrà passare una uscita , vedremo
Appunto jena , ogni tanto bisogna staccare dalle cose serie , e il riavvio è una scocciatura
Cmq con l'ultima news che ho postato splitteranno la vga in maniera che linux che ne veda una e dar alla macchina virtuale quella virtuale appunto , ora bisgona capire come funziona e cosa si possa fare , perchè suppongo che non si potrà passare una uscita , vedremo
Appunto jena , ogni tanto bisogna staccare dalle cose serie , e il riavvio è una scocciatura
-
- Messaggi: 809
- Iscritto il: martedì 10 gennaio 2012, 4:48
Re: progetto linux per game con kvm
Per risolvere il problema con la gpu e continuare i test , ho trovato questa patch , mi aiutate ad applicarla? please
ecco a volte sò un pò nabbo , ma proprio un pò
ecco a volte sò un pò nabbo , ma proprio un pò
-
- Messaggi: 745
- Iscritto il: sabato 9 febbraio 2013, 13:39
Re: progetto linux per game con kvm
Patchare i sorgenti! La cosa più noiosa da fare
Devi assicurarti della versione di lib/exe percui è stata fatta la patch, poi crei un file testo facendo la selezione della diff nel link che hai postato, lo salvi come Nome.diff, scarichi i sorgenti li scompatti. Il file sembra sia hw/vfio/pci.c, ora non ricordo bene la procedura di patching ma devi arrivare alla directory superiore "hw" e da lì lanci il comando
patch -p1 Nome.diff
La pacchettizzazione per debian purtroppo non me la ricordo più, prova checkinstall che crea un pacchetto .deb, non è il massimo perlomeno con un paio di colpi di apt-get rimetti tutto a posto.
Devi assicurarti della versione di lib/exe percui è stata fatta la patch, poi crei un file testo facendo la selezione della diff nel link che hai postato, lo salvi come Nome.diff, scarichi i sorgenti li scompatti. Il file sembra sia hw/vfio/pci.c, ora non ricordo bene la procedura di patching ma devi arrivare alla directory superiore "hw" e da lì lanci il comando
patch -p1 Nome.diff
La pacchettizzazione per debian purtroppo non me la ricordo più, prova checkinstall che crea un pacchetto .deb, non è il massimo perlomeno con un paio di colpi di apt-get rimetti tutto a posto.
-
- Messaggi: 809
- Iscritto il: martedì 10 gennaio 2012, 4:48
Re: progetto linux per game con kvm
grazie testo e ti dico se ci riesco a farla e se ci riesco
Non uso debian , ma gentoo altrimenti come potrei imparare ad usare linux così velocemente
ps. non è che mi faresti capire che parte devo prendere di quel log da inserire nel file ?
sò nabbo
Non uso debian , ma gentoo altrimenti come potrei imparare ad usare linux così velocemente
ps. non è che mi faresti capire che parte devo prendere di quel log da inserire nel file ?
sò nabbo
-
- Messaggi: 745
- Iscritto il: sabato 9 febbraio 2013, 13:39
Re: progetto linux per game con kvm
Questo dovrebbe essere il contenuto del file .diff
Ero rimasto a Debian Su Gentoo forse è ancora più facile, gli utenti avanzati usano spesso le patch, dovrebbe esserci un wiki di Gentoo a riguardo.
PS: come detto non ricordo più il sistema di patching esatto, il testo nel riquadro dovrebbe essere corretto, ma non garantisco
Codice: Seleziona tutto
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index ebc1e0a..baae98c 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -154,6 +154,7 @@ typedef struct VFIOPCIDevice {
PCIHostDeviceAddress host;
EventNotifier err_notifier;
EventNotifier req_notifier;
+ int (*resetfn)(struct VFIOPCIDevice *);
uint32_t features;
#define VFIO_FEATURE_ENABLE_VGA_BIT 0
#define VFIO_FEATURE_ENABLE_VGA (1 << VFIO_FEATURE_ENABLE_VGA_BIT)
@@ -3319,6 +3320,162 @@ static void vfio_unregister_req_notifier(VFIOPCIDevice *vdev)
vdev->req_enabled = false;
}
+/*
+ * AMD Radeon PCI config reset, based on Linux:
+ * drivers/gpu/drm/radeon/ci_smc.c:ci_is_smc_running()
+ * drivers/gpu/drm/radeon/radeon_device.c:radeon_pci_config_reset
+ * drivers/gpu/drm/radeon/ci_smc.c:ci_reset_smc()
+ * drivers/gpu/drm/radeon/ci_smc.c:ci_stop_smc_clock()
+ * IDs: include/drm/drm_pciids.h
+ * Registers: http://cgit.freedesktop.org/~agd5f/linux/commit/?id=4e2aa447f6f0
+ *
+ * Bonaire and Hawaii GPUs do not respond to a bus reset. This is a bug in the
+ * hardware that should be fixed on future ASICs. The symptom of this is that
+ * once the accerlated driver loads, Windows guests will bsod on subsequent
+ * attmpts to load the driver, such as after VM reset or shutdown/restart. To
+ * work around this, we do an AMD specific PCI config reset, followed by an SMC
+ * reset. The PCI config reset only works if SMC firmware is running, so we
+ * have a dependency on the state of the device as to whether this reset will
+ * be effective. There are still cases where we won't be able to kick the
+ * device into working, but this greatly improves the usability overall. The
+ * config reset magic is relatively common on AMD GPUs, but the setup and SMC
+ * poking is largely ASIC specific.
+ */
+static bool vfio_radeon_smc_is_running(VFIOPCIDevice *vdev)
+{
+ uint32_t clk, pc_c;
+
+ /*
+ * Registers 200h and 204h are index and data registers for acessing
+ * indirect configuration registers within the device.
+ */
+ vfio_region_write(&vdev->bars[5].region, 0x200, 0x80000004, 4);
+ clk = vfio_region_read(&vdev->bars[5].region, 0x204, 4);
+ vfio_region_write(&vdev->bars[5].region, 0x200, 0x80000370, 4);
+ pc_c = vfio_region_read(&vdev->bars[5].region, 0x204, 4);
+
+ return (!(clk & 1) && (0x20100 <= pc_c));
+}
+
+/*
+ * The scope of a config reset is controlled by a mode bit in the misc register
+ * and a fuse, exposed as a bit in another register. The fuse is the default
+ * (0 = GFX, 1 = whole GPU), the misc bit is a toggle, with the forumula
+ * scope = !(misc ^ fuse), where the resulting scope is defined the same as
+ * the fuse. A truth table therefore tells us that if misc == fuse, we need
+ * to flip the value of the bit in the misc register.
+ */
+static void vfio_radeon_set_gfx_only_reset(VFIOPCIDevice *vdev)
+{
+ uint32_t misc, fuse;
+ bool a, b;
+
+ vfio_region_write(&vdev->bars[5].region, 0x200, 0xc00c0000, 4);
+ fuse = vfio_region_read(&vdev->bars[5].region, 0x204, 4);
+ b = fuse & 64;
+
+ vfio_region_write(&vdev->bars[5].region, 0x200, 0xc0000010, 4);
+ misc = vfio_region_read(&vdev->bars[5].region, 0x204, 4);
+ a = misc & 2;
+
+ if (a == b) {
+ vfio_region_write(&vdev->bars[5].region, 0x204, misc ^ 2, 4);
+ vfio_region_read(&vdev->bars[5].region, 0x204, 4); /* flush */
+ }
+}
+
+static int vfio_radeon_reset(VFIOPCIDevice *vdev)
+{
+ PCIDevice *pdev = &vdev->pdev;
+ int i, ret = 0;
+ uint32_t data;
+
+ /* Defer to a kernel implemented reset */
+ if (vdev->vbasedev.reset_works) {
+ return -ENODEV;
+ }
+
+ /* Enable only memory BAR access */
+ vfio_pci_write_config(pdev, PCI_COMMAND, PCI_COMMAND_MEMORY, 2);
+
+ /* Reset only works if SMC firmware is loaded and running */
+ if (!vfio_radeon_smc_is_running(vdev)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ /* Make sure only the GFX function is reset */
+ vfio_radeon_set_gfx_only_reset(vdev);
+
+ /* AMD PCI config reset */
+ vfio_pci_write_config(pdev, 0x7c, 0x39d5e86b, 4);
+ usleep(100);
+
+ /* Read back the memory size to make sure we're out of reset */
+ for (i = 0; i < 100000; i++) {
+ if (vfio_region_read(&vdev->bars[5].region, 0x5428, 4) != 0xffffffff) {
+ break;
+ }
+ usleep(1);
+ }
+
+ /* Reset SMC */
+ vfio_region_write(&vdev->bars[5].region, 0x200, 0x80000000, 4);
+ data = vfio_region_read(&vdev->bars[5].region, 0x204, 4);
+ data |= 1;
+ vfio_region_write(&vdev->bars[5].region, 0x204, data, 4);
+
+ /* Disable SMC clock */
+ vfio_region_write(&vdev->bars[5].region, 0x200, 0x80000004, 4);
+ data = vfio_region_read(&vdev->bars[5].region, 0x204, 4);
+ data |= 1;
+ vfio_region_write(&vdev->bars[5].region, 0x204, data, 4);
+
+out:
+ /* Restore PCI command register */
+ vfio_pci_write_config(pdev, PCI_COMMAND, 0, 2);
+
+ return ret;
+}
+
+static void vfio_setup_resetfn(VFIOPCIDevice *vdev)
+{
+ PCIDevice *pdev = &vdev->pdev;
+ uint16_t vendor, device;
+
+ vendor = pci_get_word(pdev->config + PCI_VENDOR_ID);
+ device = pci_get_word(pdev->config + PCI_DEVICE_ID);
+
+ switch (vendor) {
+ case 0x1002:
+ switch (device) {
+ /* Bonaire */
+ case 0x6649: /* Bonaire [FirePro W5100] */
+ case 0x6650:
+ case 0x6651:
+ case 0x6658: /* Bonaire XTX [Radeon R7 260X] */
+ case 0x665c: /* Bonaire XT [Radeon HD 7790/8770 / R9 260 OEM] */
+ case 0x665d: /* Bonaire [Radeon R7 200 Series] */
+ /* Hawaii */
+ case 0x67A0: /* Hawaii XT GL [FirePro W9100] */
+ case 0x67A1: /* Hawaii PRO GL [FirePro W8100] */
+ case 0x67A2:
+ case 0x67A8:
+ case 0x67A9:
+ case 0x67AA:
+ case 0x67B0: /* Hawaii XT [Radeon R9 290X] */
+ case 0x67B1: /* Hawaii PRO [Radeon R9 290] */
+ case 0x67B8:
+ case 0x67B9:
+ case 0x67BA:
+ case 0x67BE:
+ vdev->resetfn = vfio_radeon_reset;
+ break;
+ }
+ break;
+ }
+}
+
static int vfio_initfn(PCIDevice *pdev)
{
VFIOPCIDevice *vdev = DO_UPCAST(VFIOPCIDevice, pdev, pdev);
@@ -3467,6 +3624,7 @@ static int vfio_initfn(PCIDevice *pdev)
vfio_register_err_notifier(vdev);
vfio_register_req_notifier(vdev);
+ vfio_setup_resetfn(vdev);
return 0;
@@ -3514,6 +3672,10 @@ static void vfio_pci_reset(DeviceState *dev)
vfio_pci_pre_reset(vdev);
+ if (vdev->resetfn && !vdev->resetfn(vdev)) {
+ goto post_reset;
+ }
+
if (vdev->vbasedev.reset_works &&
(vdev->has_flr || !vdev->has_pm_reset) &&
!ioctl(vdev->vbasedev.fd, VFIO_DEVICE_RESET)) {
PS: come detto non ricordo più il sistema di patching esatto, il testo nel riquadro dovrebbe essere corretto, ma non garantisco
-
- Messaggi: 809
- Iscritto il: martedì 10 gennaio 2012, 4:48
Re: progetto linux per game con kvm
Ah ok , se è esatta , allora ho capito che comincia proprio con "diff" thx
Ho scelto gentoo solo per avere già tutti gli strumenti necessari per la compilazione , vista la mia tendenza ad esplorare , e sopratutto una cosa o la capisci come funziona o non lo farà mai XD
hw/vfio/pci.c non mi trova nulla , potrebbe essere che sia questo? drivers/vfio/pci/vfio_pci.c
OT:
per le patch metto questo link , che le spiega :P
Ho scelto gentoo solo per avere già tutti gli strumenti necessari per la compilazione , vista la mia tendenza ad esplorare , e sopratutto una cosa o la capisci come funziona o non lo farà mai XD
hw/vfio/pci.c non mi trova nulla , potrebbe essere che sia questo? drivers/vfio/pci/vfio_pci.c
OT:
per le patch metto questo link , che le spiega :P
-
- Messaggi: 745
- Iscritto il: sabato 9 febbraio 2013, 13:39
Re: progetto linux per game con kvm
Eh no, il sorgente in tuo possesso deve avere lo stesso tree e revisione usata per fare la patch. Però solo ora mi sono accorto che il link dove viene data la patch è del 2015, non credo sia la stessa versione che hai tu con Gentoo. Detto questo di quale libreria stiamo parlando ? Così mi faccio una idea più esatta.hw/vfio/pci.c non mi trova nulla , potrebbe essere che sia questo? drivers/vfio/pci/vfio_pci.c
-
- Messaggi: 809
- Iscritto il: martedì 10 gennaio 2012, 4:48
Re: progetto linux per game con kvm
Grazie dell'aiuto , la patch è per qemu mi applica solo l'ultima parte delle 4 :\
ho provato a cercare nel file quello che cercava la patch in altre righe ma , mi perdo
ho provato a cercare nel file quello che cercava la patch in altre righe ma , mi perdo
-
- Messaggi: 745
- Iscritto il: sabato 9 febbraio 2013, 13:39
Re: progetto linux per game con kvm
La versione dei sorgenti ? Appena posso gli dò una occhiata. Nel frattempo cercando qualcosa a riguardo ho trovato questo blog, non sò se lo conosci ma sembra utile alla causa del passthrough
http://vfio.blogspot.it/
Edit: come non detto. lo conosci perchè in un post su AMD rimanda al tuo stesso link. Sò 'na volpe
http://vfio.blogspot.it/
Edit: come non detto. lo conosci perchè in un post su AMD rimanda al tuo stesso link. Sò 'na volpe
-
- Messaggi: 745
- Iscritto il: sabato 9 febbraio 2013, 13:39
Re: progetto linux per game con kvm
Sono andato sul sito di qemu ed ho scaricato i sorgenti di tutte le versioni stabili. Ho trovato il file col giusto path ma:
ver. 2.8.0 mi dà i passi 123 falliti il 4 ok
ver. 2.7.1 passi 1-3 ko 2-4 ok
ver. 2.6.2 idem
ver. 2.5.1.1 idem
Temo che quella è una patch di qualche release unstable non confermata, nella maillist non vedo evoluzioni sull'argomento Girocciando ho trovato qesto risalente a 5 msi fà, cprobabilmente le hai già viste ma come detto sono le più recenti che ho trovato (finora):
qui c'è una guida quasi passo passo
http://arseniyshestakov.com/2016/03/31/ ... x-restart/
per ubuntu, ma c'è la persona nominata nel primo link TGiFallen che ha inserito una patch
https://ubuntuforums.org/archive/index. ... 66916.html
la pagina git del tipo del primo blog
https://gist.github.com/ArseniyShestako ... 65ebaa6781
Non parlano proprio del reset bus ma dello switch tra schede, in *teoria* dovrebbe riguardare anche l'azione di nostro interesse
ver. 2.8.0 mi dà i passi 123 falliti il 4 ok
ver. 2.7.1 passi 1-3 ko 2-4 ok
ver. 2.6.2 idem
ver. 2.5.1.1 idem
Temo che quella è una patch di qualche release unstable non confermata, nella maillist non vedo evoluzioni sull'argomento Girocciando ho trovato qesto risalente a 5 msi fà, cprobabilmente le hai già viste ma come detto sono le più recenti che ho trovato (finora):
qui c'è una guida quasi passo passo
http://arseniyshestakov.com/2016/03/31/ ... x-restart/
per ubuntu, ma c'è la persona nominata nel primo link TGiFallen che ha inserito una patch
https://ubuntuforums.org/archive/index. ... 66916.html
la pagina git del tipo del primo blog
https://gist.github.com/ArseniyShestako ... 65ebaa6781
Non parlano proprio del reset bus ma dello switch tra schede, in *teoria* dovrebbe riguardare anche l'azione di nostro interesse